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. -- Cheers, Stephen Rothwell sfr@xxxxxxxxxxxxxxxx
Attachment:
pgpjbpU08HB2C.pgp
Description: PGP signature
