From: H. Peter Anvin on
On 07/05/2010 12:58 PM, Frederic Weisbecker wrote:
> On Mon, Jul 05, 2010 at 09:52:55PM +0200, Arnd Bergmann wrote:
>> On Monday 05 July 2010 21:48:01 Frederic Weisbecker wrote:
>>> On Mon, Jul 05, 2010 at 12:42:59PM -0700, H. Peter Anvin wrote:
>>>> On 07/05/2010 12:24 PM, Frederic Weisbecker wrote:
>>>>>
>>>>> Peter, if you're fine with this version. May I apply it?
>>>>> Unless you have a tree for autofs.
>>>>>
>>>> Ian Kent is the maintainer of autofs4 and patches for autofs4 should go
>>>> through him (or acked by him.)
>>>>
>>>> autofs 3 is officially unmaintained; I'm more than happy to have you
>>>> push the autofs 3 bits of this patch.
>>>
>>> Sure, I can split up the patch and integrate the autofs 3 part, I'll send
>>> the standalone autofs4 version to Ian.
>>
>> I think in this case it's really more appropriate to change both autofs3
>> and autofs4 together, to avoid interdependencies. Whichever way Ian
>> prefers (ack the patch or take it) would work though.
>>
>> Arnd
>
>
> Yeah indeed. Ian?
>

For what it's worth, feel free to add my:

Acked-by: H. Peter Anvin <hpa(a)zytor.com>

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ian Kent on
On Mon, 2010-07-05 at 21:58 +0200, Frederic Weisbecker wrote:
> On Mon, Jul 05, 2010 at 09:52:55PM +0200, Arnd Bergmann wrote:
> > On Monday 05 July 2010 21:48:01 Frederic Weisbecker wrote:
> > > On Mon, Jul 05, 2010 at 12:42:59PM -0700, H. Peter Anvin wrote:
> > > > On 07/05/2010 12:24 PM, Frederic Weisbecker wrote:
> > > > >
> > > > > Peter, if you're fine with this version. May I apply it?
> > > > > Unless you have a tree for autofs.
> > > > >
> > > > Ian Kent is the maintainer of autofs4 and patches for autofs4 should go
> > > > through him (or acked by him.)
> > > >
> > > > autofs 3 is officially unmaintained; I'm more than happy to have you
> > > > push the autofs 3 bits of this patch.
> > >
> > > Sure, I can split up the patch and integrate the autofs 3 part, I'll send
> > > the standalone autofs4 version to Ian.
> >
> > I think in this case it's really more appropriate to change both autofs3
> > and autofs4 together, to avoid interdependencies. Whichever way Ian
> > prefers (ack the patch or take it) would work though.
> >
> > Arnd
>
>
> Yeah indeed. Ian?

As Peter says the autofs module isn't supported anymore and autofs4 will
replace autofs when I eventually get around to re-doing and re-testing
my patch for that.

So it makes no difference whether the patches are combined, if it breaks
autofs then it probably won't be fixed but it may cause the replacement
to happen sooner.

As far as the patch goes that should be fine and we should be able to
remove the BKL from autofs4 soon after but I'm not brave enough to try
just yet.

Ian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on
On Tuesday 06 July 2010, Ian Kent wrote:
> So it makes no difference whether the patches are combined, if it breaks
> autofs then it probably won't be fixed but it may cause the replacement
> to happen sooner.

Well, the main point of applying the patch now is to avoid breaking the
autofs module when we remove the .ioctl operation.

> As far as the patch goes that should be fine and we should be able to
> remove the BKL from autofs4 soon after but I'm not brave enough to try
> just yet.

Well, the only use of the BKL in autofs4 is in the ioctl function. You
can probably replace that trivially with a global mutex, but from a quick
inspection, even that should not be needed: The only ioctl command in
autofs4 that does not already seem to have adequate locking is
autofs4_get_set_timeout, which is even easier to change and still harmless
if you don't do it at all.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ian Kent on


On 06/07/2010, at 7:35 PM, Arnd Bergmann <arnd(a)arndb.de> wrote:

>
> Well, the only use of the BKL in autofs4 is in the ioctl function. You
> can probably replace that trivially with a global mutex, but from a quick
> inspection, even that should not be needed: The only ioctl command in
> autofs4 that does not already seem to have adequate locking is
> autofs4_get_set_timeout, which is even easier to change and still harmless
> if you don't do it at all.

That's right of course.

Even this shouldn't be a problem as it is called by a single instance, per autofs mount, of the daemon only. A fair amount of effort has gone into trying to make the autofs4 module independent of the BKL over time. However I would still rather not do the change concurrently with the ioctl changes.

Ian
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on
2010/7/6 Ian Kent <raven(a)themaw.net>:
>
>
> On 06/07/2010, at 7:35 PM, Arnd Bergmann <arnd(a)arndb.de> wrote:
>
>>
>> Well, the only use of the BKL in autofs4 is in the ioctl function. You
>> can probably replace that trivially with a global mutex, but from a quick
>> inspection, even that should not be needed: The only ioctl command in
>> autofs4 that does not already seem to have adequate locking is
>> autofs4_get_set_timeout, which is even easier to change and still harmless
>> if you don't do it at all.
>
> That's right of course.
>
> Even this shouldn't be a problem as it is called by a single instance, per autofs mount, of the daemon only. A fair amount of effort has gone into trying to make the autofs4 module independent of the BKL over time. However I would still rather not do the change concurrently with the ioctl changes.
>
> Ian


In any case, can we let you handle this patch for 2.6.36 inclusion?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/