Re: [RFC][PATCH] preempt: Debug for possible missed preemptionchecks

From: Stephen Rothwell
Date: Sat Jan 18 2014 - 19:53:20 EST

Hi Steve,

On Sat, 18 Jan 2014 18:44:01 -0500 Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Thu, 16 Jan 2014 21:12:14 -0800
> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Thu, 16 Jan 2014 23:57:51 -0500 Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >
> > > When PROVE_LOCKING and PREEMPT is configured, the preempt state
> > > tracking is active. Testing this out, I added a module that did the
> > > following:
> >
> > So I assume your kernel at least has no instances of this bug, so we
> > don't need the patch ;) It *is* a fairly daft thing to do.
> >
> > Maybe stick it in -next for a few months, see if anyone hits it?
> Do you have any objections if I add this change to my for-next branch?
> I'll do it as a merge as I do not plan on having it go into the next
> release. But this is an extension to lockdep that when both
> PROVE_LOCKING and PREEMPT are enabled, it can catch a certain bug. But
> as Andrew has stated, it did not find any in the kernel that I'm
> running.
> What I propose is to have this go into linux-next, as I assume that
> people test it with PROVE_LOCKING and PREEMPT enabled, and if someone
> adds this bug this patch will catch it (if the bug path is taken).
> Hopefully it would be reported and we know two things. One, someone
> added a bug, and two, this patch is useful to add to mainline.
> Here's the catch 22, it may not be worth adding to mainline if it never
> catches any bugs. But we wont know that unless we add it to mainline.
> Maybe adding it to linux-next might be good enough for now.

Given that the merge window will probably open today or tomorrow, I would
prefer any new code not intended for 3.14 not be added to linux-next
until after v3.14-rc1 to avoid unneeded conflicts. If, however, Andrew
thinks it is still worth the (maybe minimal) pain, then fine.
Stephen Rothwell sfr@xxxxxxxxxxxxxxxx

Attachment: pgp00000.pgp
Description: PGP signature