On Thu, 2012-12-20 at 17:50 -0800, Linus Torvalds wrote:
> On Thu, Dec 20, 2012 at 2:38 PM, Eric Paris <eparis@redhat.com> wrote:
> > I believe you would get a build failure after this pull due to the
> > addition of procfs information for *notify fds.  The attached patch from
> > sfr should be applied during the merge to change the spin_lock in that
> > patch to the mutex in this patch.
> 
> I'm not going to bother pulling this.
> 
> It's coming in late in the merge window, it has been rebased days ago,
> and it changes fundamental infrastructure.
> 
> This has been a huge merge window, and this is just too late and too
> surprising. The commits are marked as being written 18 months ago, but
> then the commit date is after the merge window started, and sent the
> day before it closes.
> 
> WTF? If they've waited 18 months, there cannot be this kind of
> last-minute hurry now. Why did you wait until the last minute?

The changes have been in next for about 18 months.  I've just been a
missing maintainer.  I'm back with some time to fix that fact, but I
understand if you want to reject it on that account.  I'm available now
if something goes wrong.  Most of this work was originally done just as
cleanup, but recently people started complaining about the FAT race/NULL
ptr deref.

https://bugzilla.redhat.com/show_bug.cgi?id=768534

Which got me to finally get off my lazy ass.  When looking to send the
pull request on the first day of the window I realized just how far
behind my tree was and that there was a merge conflict for which sfr had
been carrying a patch forever.  With 3.7 less than a day old I figured
3.6 was a good place to go in order to solve the conflict.  Since I
rebased, it obviously needed more testing and some time in -next.  Which
was why I said to you, back on the 11th, that I was planning to send my
pull request today.

http://marc.info/?l=linux-next&m=135526314222685&w=2

It is a locking change, but if anything goes wrong, at least I've got
time without other work commitments over the next 2 weeks to fix them.
If you are wondering about testing, I've written the attached
notification stressor.  On a dual core box it will cause a kernel panic
is about 1 second on your kernel.  With the patch set it doesn't pop...

Your call, but it does fix a real bug that people are reporting today.

-Eric