[PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Paul Mundt]

Caught with the sh allmodconfig:

	ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
	make[2]: *** [__modpost] Error 1
	make[1]: *** [modules] Error 2
	make: *** [sub-make] Error 2

find_last_bit.o is currently built with lib-y, which ends up breaking
the nfs module build after the ("nfs41: free slot") commit. Move it
to obj-y so the EXPORT_SYMBOL() actually has some effect.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Cc: Benny Halevy <bhalevy@panasas.com>
Cc: Andy Adamson <andros@netapp.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>

---

diff --git a/lib/Makefile b/lib/Makefile
index d6edd67..33a40e4 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -38,7 +38,7 @@ lib-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o
 lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
 lib-$(CONFIG_GENERIC_FIND_FIRST_BIT) += find_next_bit.o
 lib-$(CONFIG_GENERIC_FIND_NEXT_BIT) += find_next_bit.o
-lib-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o
+obj-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o
 obj-$(CONFIG_GENERIC_HWEIGHT) += hweight.o
 obj-$(CONFIG_LOCK_KERNEL) += kernel_lock.o
 obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Benny Halevy]

On Apr. 16, 2009, 6:07 +0300, Paul Mundt <lethal@linux-sh.org> wrote:
> Caught with the sh allmodconfig:
> 
> 	ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
> 	make[2]: *** [__modpost] Error 1
> 	make[1]: *** [modules] Error 2
> 	make: *** [sub-make] Error 2
> 
> find_last_bit.o is currently built with lib-y, which ends up breaking
> the nfs module build after the ("nfs41: free slot") commit. Move it
> to obj-y so the EXPORT_SYMBOL() actually has some effect.
> 
> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
> Cc: Benny Halevy <bhalevy@panasas.com>

ACK. and thanks!

FYI, Fred's original patch can be found here:
http://patchwork.kernel.org/patch/14572/

It is also queued in the linux-pnfs tree:
http://git.linux-nfs.org/?p=bhalevy/linux-pnfs.git;a=commitdiff;h=1e3a7552d9de2ba101b76deed99605f0145fc4d5
but I haven't submitted it to Trond since I expected
it to get upstream (and to -next) via linux-kbuild.

Trond, would you like to pull this change to your nfsv41 branch?
(should appear before "nfs41: free slot" as Paul noticed)

Benny

> Cc: Andy Adamson <andros@netapp.com>
> Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
> 
> ---
> 
> diff --git a/lib/Makefile b/lib/Makefile
> index d6edd67..33a40e4 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -38,7 +38,7 @@ lib-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o
>  lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
>  lib-$(CONFIG_GENERIC_FIND_FIRST_BIT) += find_next_bit.o
>  lib-$(CONFIG_GENERIC_FIND_NEXT_BIT) += find_next_bit.o
> -lib-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o
> +obj-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o
>  obj-$(CONFIG_GENERIC_HWEIGHT) += hweight.o
>  obj-$(CONFIG_LOCK_KERNEL) += kernel_lock.o
>  obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Paul Mundt]

On Thu, Apr 16, 2009 at 11:11:02AM +0300, Benny Halevy wrote:
> On Apr. 16, 2009, 6:07 +0300, Paul Mundt <lethal@linux-sh.org> wrote:
> > Caught with the sh allmodconfig:
> > 
> > 	ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
> > 	make[2]: *** [__modpost] Error 1
> > 	make[1]: *** [modules] Error 2
> > 	make: *** [sub-make] Error 2
> > 
> > find_last_bit.o is currently built with lib-y, which ends up breaking
> > the nfs module build after the ("nfs41: free slot") commit. Move it
> > to obj-y so the EXPORT_SYMBOL() actually has some effect.
> > 
> > Signed-off-by: Paul Mundt <lethal@linux-sh.org>
> > Cc: Benny Halevy <bhalevy@panasas.com>
> 
> ACK. and thanks!
> 
> FYI, Fred's original patch can be found here:
> http://patchwork.kernel.org/patch/14572/
> 
> It is also queued in the linux-pnfs tree:
> http://git.linux-nfs.org/?p=bhalevy/linux-pnfs.git;a=commitdiff;h=1e3a7552d9de2ba101b76deed99605f0145fc4d5
> but I haven't submitted it to Trond since I expected
> it to get upstream (and to -next) via linux-kbuild.
> 
> Trond, would you like to pull this change to your nfsv41 branch?
> (should appear before "nfs41: free slot" as Paul noticed)
> 
Ok, so we have two different trivial patches for fixing the same thing,
and a week later it is still broken.

I realize it is a trivial patch, but it does break builds. If folks
aren't going to take these sorts of things more seriously, then their
tree should be dropped after a grace period (say 2 days or so).

Beyond that, it doesn't seem like -next has any sort of coherent policy
for dealing with trivial patches. If the emphasis is on the tree that
introduced the regression to deal with it, then trees need to be
aggressively dropped when these things go unfixed.

Having builds broken for a week for an issue that has been spotted and
fixed by several people is simply unacceptable.

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Benny Halevy]

On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@linux-sh.org> wrote:
> On Thu, Apr 16, 2009 at 11:11:02AM +0300, Benny Halevy wrote:
>> On Apr. 16, 2009, 6:07 +0300, Paul Mundt <lethal@linux-sh.org> wrote:
>>> Caught with the sh allmodconfig:
>>>
>>> 	ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
>>> 	make[2]: *** [__modpost] Error 1
>>> 	make[1]: *** [modules] Error 2
>>> 	make: *** [sub-make] Error 2
>>>
>>> find_last_bit.o is currently built with lib-y, which ends up breaking
>>> the nfs module build after the ("nfs41: free slot") commit. Move it
>>> to obj-y so the EXPORT_SYMBOL() actually has some effect.
>>>
>>> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
>>> Cc: Benny Halevy <bhalevy@panasas.com>
>> ACK. and thanks!
>>
>> FYI, Fred's original patch can be found here:
>> http://patchwork.kernel.org/patch/14572/
>>
>> It is also queued in the linux-pnfs tree:
>> http://git.linux-nfs.org/?p=bhalevy/linux-pnfs.git;a=commitdiff;h=1e3a7552d9de2ba101b76deed99605f0145fc4d5
>> but I haven't submitted it to Trond since I expected
>> it to get upstream (and to -next) via linux-kbuild.
>>
>> Trond, would you like to pull this change to your nfsv41 branch?
>> (should appear before "nfs41: free slot" as Paul noticed)
>>
> Ok, so we have two different trivial patches for fixing the same thing,
> and a week later it is still broken.
> 
> I realize it is a trivial patch, but it does break builds. If folks
> aren't going to take these sorts of things more seriously, then their
> tree should be dropped after a grace period (say 2 days or so).
> 
> Beyond that, it doesn't seem like -next has any sort of coherent policy
> for dealing with trivial patches. If the emphasis is on the tree that
> introduced the regression to deal with it, then trees need to be
> aggressively dropped when these things go unfixed.
> 
> Having builds broken for a week for an issue that has been spotted and
> fixed by several people is simply unacceptable.

Paul, that's a valid point but I don't set these polices.
Trond suggested to just commit this to 2.6.30
and I asked Rusty's Ack here:
http://lkml.org/lkml/2009/4/21/489

Like I said there, I'm not sure who to send this patch to.
Ingo?

Benny

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Paul Mundt]

On Thu, Apr 23, 2009 at 01:12:54PM +0300, Benny Halevy wrote:
> On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@linux-sh.org> wrote:
> > Ok, so we have two different trivial patches for fixing the same thing,
> > and a week later it is still broken.
> > 
> > I realize it is a trivial patch, but it does break builds. If folks
> > aren't going to take these sorts of things more seriously, then their
> > tree should be dropped after a grace period (say 2 days or so).
> > 
> > Beyond that, it doesn't seem like -next has any sort of coherent policy
> > for dealing with trivial patches. If the emphasis is on the tree that
> > introduced the regression to deal with it, then trees need to be
> > aggressively dropped when these things go unfixed.
> > 
> > Having builds broken for a week for an issue that has been spotted and
> > fixed by several people is simply unacceptable.
> 
> Paul, that's a valid point but I don't set these polices.
> Trond suggested to just commit this to 2.6.30
> and I asked Rusty's Ack here:
> http://lkml.org/lkml/2009/4/21/489
> 
> Like I said there, I'm not sure who to send this patch to.
> Ingo?
> 
I was under the impression that a tree that caused a build regression
would be dropped until it had it sorted out, but that seems to be more
the exception than the rule.

-next is good at finding bugs in build configurations folks haven't
considered, which should serve as a pretty good platform for getting
those types of fixes merged quickly, whether it be in to the tree that
caused the regression or -next directly.

Unfortunately it seems like build regressions are more of an afterthought
than a show stopper. I count at least 3 on the sh builds in the last
couple weeks that are all averaging a week or longer to unbreak, while
patches have been available almost immediately.

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Trond Myklebust]

On Thu, 2009-04-23 at 19:29 +0900, Paul Mundt wrote:
> On Thu, Apr 23, 2009 at 01:12:54PM +0300, Benny Halevy wrote:
> > On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@linux-sh.org> wrote:
> > > Ok, so we have two different trivial patches for fixing the same thing,
> > > and a week later it is still broken.
> > > 
> > > I realize it is a trivial patch, but it does break builds. If folks
> > > aren't going to take these sorts of things more seriously, then their
> > > tree should be dropped after a grace period (say 2 days or so).
> > > 
> > > Beyond that, it doesn't seem like -next has any sort of coherent policy
> > > for dealing with trivial patches. If the emphasis is on the tree that
> > > introduced the regression to deal with it, then trees need to be
> > > aggressively dropped when these things go unfixed.
> > > 
> > > Having builds broken for a week for an issue that has been spotted and
> > > fixed by several people is simply unacceptable.
> > 
> > Paul, that's a valid point but I don't set these polices.
> > Trond suggested to just commit this to 2.6.30
> > and I asked Rusty's Ack here:
> > http://lkml.org/lkml/2009/4/21/489
> > 
> > Like I said there, I'm not sure who to send this patch to.
> > Ingo?
> > 
> I was under the impression that a tree that caused a build regression
> would be dropped until it had it sorted out, but that seems to be more
> the exception than the rule.
> 
> -next is good at finding bugs in build configurations folks haven't
> considered, which should serve as a pretty good platform for getting
> those types of fixes merged quickly, whether it be in to the tree that
> caused the regression or -next directly.
> 
> Unfortunately it seems like build regressions are more of an afterthought
> than a show stopper. I count at least 3 on the sh builds in the last
> couple weeks that are all averaging a week or longer to unbreak, while
> patches have been available almost immediately.

In this case, the tree in question is exposing a bug that already exists
in mainline; a function that is explicitly labelled as being exported
for use by arbitrary modules, and yet isn't being compiled into the
kernel. Shooting the messenger isn't going to fix that.

In any case, this patch does not belong in the NFS tree since it touches
generic library code, not NFS code. Benny, if nobody else wants to
shepherd it, then just send it directly to Linus.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Benny Halevy]

On Apr. 23, 2009, 15:59 +0300, Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> On Thu, 2009-04-23 at 19:29 +0900, Paul Mundt wrote:
>> On Thu, Apr 23, 2009 at 01:12:54PM +0300, Benny Halevy wrote:
>>> On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@linux-sh.org> wrote:
>>>> Ok, so we have two different trivial patches for fixing the same thing,
>>>> and a week later it is still broken.
>>>>
>>>> I realize it is a trivial patch, but it does break builds. If folks
>>>> aren't going to take these sorts of things more seriously, then their
>>>> tree should be dropped after a grace period (say 2 days or so).
>>>>
>>>> Beyond that, it doesn't seem like -next has any sort of coherent policy
>>>> for dealing with trivial patches. If the emphasis is on the tree that
>>>> introduced the regression to deal with it, then trees need to be
>>>> aggressively dropped when these things go unfixed.
>>>>
>>>> Having builds broken for a week for an issue that has been spotted and
>>>> fixed by several people is simply unacceptable.
>>> Paul, that's a valid point but I don't set these polices.
>>> Trond suggested to just commit this to 2.6.30
>>> and I asked Rusty's Ack here:
>>> http://lkml.org/lkml/2009/4/21/489
>>>
>>> Like I said there, I'm not sure who to send this patch to.
>>> Ingo?
>>>
>> I was under the impression that a tree that caused a build regression
>> would be dropped until it had it sorted out, but that seems to be more
>> the exception than the rule.
>>
>> -next is good at finding bugs in build configurations folks haven't
>> considered, which should serve as a pretty good platform for getting
>> those types of fixes merged quickly, whether it be in to the tree that
>> caused the regression or -next directly.
>>
>> Unfortunately it seems like build regressions are more of an afterthought
>> than a show stopper. I count at least 3 on the sh builds in the last
>> couple weeks that are all averaging a week or longer to unbreak, while
>> patches have been available almost immediately.
> 
> In this case, the tree in question is exposing a bug that already exists
> in mainline; a function that is explicitly labelled as being exported
> for use by arbitrary modules, and yet isn't being compiled into the
> kernel. Shooting the messenger isn't going to fix that.
> 
> In any case, this patch does not belong in the NFS tree since it touches
> generic library code, not NFS code. Benny, if nobody else wants to
> shepherd it, then just send it directly to Linus.

Will do.

Regardless, Paul's observation seems valid.
I wonder if linux-next should have a branch or pull a tree
holding trivial fixes fitting no other specific tree...

Benny

> 
> Trond

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Paul Mundt]

On Thu, Apr 23, 2009 at 08:59:49AM -0400, Trond Myklebust wrote:
> On Thu, 2009-04-23 at 19:29 +0900, Paul Mundt wrote:
> > I was under the impression that a tree that caused a build regression
> > would be dropped until it had it sorted out, but that seems to be more
> > the exception than the rule.
> > 
> > -next is good at finding bugs in build configurations folks haven't
> > considered, which should serve as a pretty good platform for getting
> > those types of fixes merged quickly, whether it be in to the tree that
> > caused the regression or -next directly.
> > 
> > Unfortunately it seems like build regressions are more of an afterthought
> > than a show stopper. I count at least 3 on the sh builds in the last
> > couple weeks that are all averaging a week or longer to unbreak, while
> > patches have been available almost immediately.
> 
> In this case, the tree in question is exposing a bug that already exists
> in mainline; a function that is explicitly labelled as being exported
> for use by arbitrary modules, and yet isn't being compiled into the
> kernel. Shooting the messenger isn't going to fix that.
> 
Nor is bantering on semantics going to change the fact that you caused a
build regression and have so far refused to even acknowledge that that is
a problem. If anyone had bothered to test the module build, this would
have shown up immediately and would have rightly been fixed before that
change was merged. Claiming that the two are completely unrelated after
the fact is rather disingenuous, and does nothing to address the process
problem.

> In any case, this patch does not belong in the NFS tree since it touches
> generic library code, not NFS code. Benny, if nobody else wants to
> shepherd it, then just send it directly to Linus.
> 
That's a complete cop-out, if there had been no export at all how would
you have proceeded? How is this situation any different?

I am willing to monitor my builds regularly and send out trivial patches
to fix whatever ends up breaking, but I do expect people who have caused
regressions to take these matters seriously rather than sweep them under
the carpet and pretend like they either don't exist or are somehow
someone else's problem.

Any tree that causes a regression should simply be dropped until it gets
it sorted out, as it's abundantly obvious that people aren't even
prepared to do the bare minimum to keep things working after they've been
pulled from.

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Trond Myklebust]

On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote:
> > In any case, this patch does not belong in the NFS tree since it touches
> > generic library code, not NFS code. Benny, if nobody else wants to
> > shepherd it, then just send it directly to Linus.
> > 
> That's a complete cop-out, if there had been no export at all how would
> you have proceeded? How is this situation any different?

Please see Documentation/SubmittingPatches. If we were requesting a new
kernel feature, I'd go looking for the maintainer and get an ACK or get
said maintainer to include the patch in their tree.

As it is, said kernel feature exists, but is broken. The correct thing
to do is to fix the kernel feature. Sooner, rather than later.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Paul Mundt]

On Thu, Apr 23, 2009 at 09:59:28AM -0400, Trond Myklebust wrote:
> On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote:
> > > In any case, this patch does not belong in the NFS tree since it touches
> > > generic library code, not NFS code. Benny, if nobody else wants to
> > > shepherd it, then just send it directly to Linus.
> > > 
> > That's a complete cop-out, if there had been no export at all how would
> > you have proceeded? How is this situation any different?
> 
> Please see Documentation/SubmittingPatches. If we were requesting a new
> kernel feature, I'd go looking for the maintainer and get an ACK or get
> said maintainer to include the patch in their tree.
> 
> As it is, said kernel feature exists, but is broken. The correct thing
> to do is to fix the kernel feature. Sooner, rather than later.
> 
And until that feature is working, you have absolutely no business
merging crap in to the kernel that uses it. You made an assumption that
it was working, which turned out to be wrong (which you also failed to
validate through any form of testing), and subsequently caused a
regression. Mistakes happen and are expected in -next, refusing to deal
with them at all on the other hand..

The first course of action any responsible maintainer would have taken
would be to revert the offending changeset once the issue was pointed out
until its dependencies were sorted out. Not only have you failed to do
that, you couldn't even be bothered replying to the email with patch that
pointed out the build failure in the first place. This created the
mistaken conclusion that you were actually doing something about the
regression you caused rather than just dismissing it out of hand.

The nfs tree should be dropped on the floor immediately until this issue
is resolved. 

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Trond Myklebust]

On Thu, 2009-04-23 at 23:12 +0900, Paul Mundt wrote:
> On Thu, Apr 23, 2009 at 09:59:28AM -0400, Trond Myklebust wrote:
> > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote:
> > > > In any case, this patch does not belong in the NFS tree since it touches
> > > > generic library code, not NFS code. Benny, if nobody else wants to
> > > > shepherd it, then just send it directly to Linus.
> > > > 
> > > That's a complete cop-out, if there had been no export at all how would
> > > you have proceeded? How is this situation any different?
> > 
> > Please see Documentation/SubmittingPatches. If we were requesting a new
> > kernel feature, I'd go looking for the maintainer and get an ACK or get
> > said maintainer to include the patch in their tree.
> > 
> > As it is, said kernel feature exists, but is broken. The correct thing
> > to do is to fix the kernel feature. Sooner, rather than later.
> > 
> And until that feature is working, you have absolutely no business
> merging crap in to the kernel that uses it. You made an assumption that
> it was working, which turned out to be wrong (which you also failed to
> validate through any form of testing), and subsequently caused a
> regression. Mistakes happen and are expected in -next, refusing to deal
> with them at all on the other hand..
> 
> The first course of action any responsible maintainer would have taken
> would be to revert the offending changeset once the issue was pointed out
> until its dependencies were sorted out. Not only have you failed to do
> that, you couldn't even be bothered replying to the email with patch that
> pointed out the build failure in the first place. This created the
> mistaken conclusion that you were actually doing something about the
> regression you caused rather than just dismissing it out of hand.
> 
> The nfs tree should be dropped on the floor immediately until this issue
> is resolved. 

Whatever...
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Rusty Russell]

On Fri, 24 Apr 2009 02:08:50 am Trond Myklebust wrote:
> > > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote:
> > > > > In any case, this patch does not belong in the NFS tree since it touches
> > > > > generic library code, not NFS code. Benny, if nobody else wants to
> > > > > shepherd it, then just send it directly to Linus.
...
> > The nfs tree should be dropped on the floor immediately until this issue
> > is resolved. 
> 
> Whatever...

FWIW Trond, I would have taken the patch and pushed it.  It happens: it's
not your fault, but it suddenly became your problem.

And Paul: being right doesn't excuse being an asshole.[1]

Thanks,
Rusty.
[1] As this rule applies to this message, I ponder my own failings.

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Ingo Molnar]

* Rusty Russell <rusty@rustcorp.com.au> wrote:

> On Fri, 24 Apr 2009 02:08:50 am Trond Myklebust wrote:
> > > > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote:
> > > > > > In any case, this patch does not belong in the NFS tree since it touches
> > > > > > generic library code, not NFS code. Benny, if nobody else wants to
> > > > > > shepherd it, then just send it directly to Linus.
> ...
> > > The nfs tree should be dropped on the floor immediately until this issue
> > > is resolved. 
> > 
> > Whatever...
> 
> FWIW Trond, I would have taken the patch and pushed it.  It 
> happens: it's not your fault, but it suddenly became your problem.

To double check things: is it clear now who pushes the fix and when? 
I'm obviously acking it and can push it to Linus if needed.

Thanks,

	Ingo

Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.

[Trond Myklebust]

On Sun, 2009-04-26 at 18:42 +0200, Ingo Molnar wrote:
> * Rusty Russell <rusty@rustcorp.com.au> wrote:
> 
> > On Fri, 24 Apr 2009 02:08:50 am Trond Myklebust wrote:
> > > > > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote:
> > > > > > > In any case, this patch does not belong in the NFS tree since it touches
> > > > > > > generic library code, not NFS code. Benny, if nobody else wants to
> > > > > > > shepherd it, then just send it directly to Linus.
> > ...
> > > > The nfs tree should be dropped on the floor immediately until this issue
> > > > is resolved. 
> > > 
> > > Whatever...
> > 
> > FWIW Trond, I would have taken the patch and pushed it.  It 
> > happens: it's not your fault, but it suddenly became your problem.
> 
> To double check things: is it clear now who pushes the fix and when? 
> I'm obviously acking it and can push it to Linus if needed.

Linus has already merged it as commit
a5422a5111811401f7756345e4c237ff06cf6d1e

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com