From: H. Peter Anvin on 5 Jul 2010 20:10 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 5 Jul 2010 21:20 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 6 Jul 2010 07:40 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 6 Jul 2010 09:20 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 15 Jul 2010 20:20 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/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: v4l: convert v4l2-dev to unlocked_ioctl Next: Crash in wb_clear_pending() |