[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0910142338500.9428@localhost.localdomain>
Date: Wed, 14 Oct 2009 23:43:54 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Arnd Bergmann <arndbergmann@...glemail.com>
cc: LKML <linux-kernel@...r.kernel.org>,
Mike Frysinger <vapier@...too.org>
Subject: Re: [patch 11/28] nvram: Drop the bkl from nvram_llseek()
On Tue, 13 Oct 2009, Arnd Bergmann wrote:
> On Monday 12 October 2009, Frederic Weisbecker wrote:
> > On Sun, Oct 11, 2009 at 11:50:24PM +0200, Arnd Bergmann wrote:
> > >
> > > There are various *_operations structures that have a .ioctl pointer.
> > > While there are a lot of struct file_operations with a locked .ioctl
> > > operation, stuff like block_device_operations does not hold the
> > > BKL in .ioctl but in .locked_ioctl.
> >
> > Oh right. Thanks for the tip.
> >
>
> FWIW, I've done a grep through the current source tree, this should be
> the full list of all .ioctl methods in struct file_operations, a total
> of 141 instances in 2.6.32-rc4.
>
> When we do a pushdown of the BKL into these functions, we can kill off
> the file operation.
>
> Arnd <><
>
> arch/blackfin/mach-bf561/coreb.c: .ioctl = coreb_ioctl,
That one is scary. The BKL is protecting against parallel ioctl
operations, but the operation on the sys control registers is not
protected against other operations on the same registers in
arch/blackfin/mach-bf561/smp.c. IPI code does not take the BKL
afaict. Mike ?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists