Unserializing ioctl() system calls

Unserializing ioctl() system calls

[Spinka, Kristofer]

I noticed that even in the 2.6.6 code, callers to ioctl 
system call (sys_ioctl in fs/ioctl.c) are serialized with 
{lock,unlock}_kernel().

I realize that many kernel modules, and POSIX for that 
matter, may not be ready to make this more concurrent.

I propose adding a flag to indicate that the underlying 
module would like to support its own concurrency 
management, and thus we avoid grabbing the BKL around the 
f_op->ioctl call.

The default behavior would adhere to existing standards, 
and if the flag is present (in the underlying module), we 
let the module (or modules) handle it.

Reasonable?

   /kristofer

Re: Unserializing ioctl() system calls

[viro]

On Fri, May 21, 2004 at 10:46:45PM -0400, Spinka, Kristofer wrote:
> I noticed that even in the 2.6.6 code, callers to ioctl 
> system call (sys_ioctl in fs/ioctl.c) are serialized with 
> {lock,unlock}_kernel().
> 
> I realize that many kernel modules, and POSIX for that 
> matter, may not be ready to make this more concurrent.
> 
> I propose adding a flag to indicate that the underlying 
> module would like to support its own concurrency 
> management, and thus we avoid grabbing the BKL around the 
> f_op->ioctl call.
> 
> The default behavior would adhere to existing standards, 
> and if the flag is present (in the underlying module), we 
> let the module (or modules) handle it.
> 
> Reasonable?

No.  Flags on drivers are never a good idea.  What's more, if somebody
wants that shit parallelized they can always drop BKL upon entry and
reacquire on exit from their ->ioctl().

RE: Unserializing ioctl() system calls

[Spinka, Kristofer]

It doesn't necessarily have to be a flag on a driver, just an example.

I was more interested in a transitional interface to wean current
modules/code off of any BKL expectations during an ioctl.

Why should the kernel take out the BKL for the module during an ioctl?  Does
the kernel know how long this request might take?

  /kristofer

-----Original Message-----
From: viro@www.linux.org.uk [mailto:viro@www.linux.org.uk] On Behalf Of
viro@parcelfarce.linux.theplanet.co.uk
Sent: Friday, May 21, 2004 7:54 PM
To: Spinka, Kristofer
Cc: linux-kernel@vger.kernel.org
Subject: Re: Unserializing ioctl() system calls

On Fri, May 21, 2004 at 10:46:45PM -0400, Spinka, Kristofer wrote:
> I noticed that even in the 2.6.6 code, callers to ioctl 
> system call (sys_ioctl in fs/ioctl.c) are serialized with 
> {lock,unlock}_kernel().
> 
> I realize that many kernel modules, and POSIX for that 
> matter, may not be ready to make this more concurrent.
> 
> I propose adding a flag to indicate that the underlying 
> module would like to support its own concurrency 
> management, and thus we avoid grabbing the BKL around the 
> f_op->ioctl call.
> 
> The default behavior would adhere to existing standards, 
> and if the flag is present (in the underlying module), we 
> let the module (or modules) handle it.
> 
> Reasonable?

No.  Flags on drivers are never a good idea.  What's more, if somebody
wants that shit parallelized they can always drop BKL upon entry and
reacquire on exit from their ->ioctl().

Re: Unserializing ioctl() system calls

[Andi Kleen]

"Spinka, Kristofer" <kspinka@style.net> writes:

> I noticed that even in the 2.6.6 code, callers to ioctl system call
> (sys_ioctl in fs/ioctl.c) are serialized with {lock,unlock}_kernel().
>
> I realize that many kernel modules, and POSIX for that matter, may not
> be ready to make this more concurrent.

POSIX doesn't care how the kernel implements locking.

> I propose adding a flag to indicate that the underlying module would
> like to support its own concurrency management, and thus we avoid
> grabbing the BKL around the f_op->ioctl call.

Better would be probably a unlocked_ioctl() entry point in f_op. Should
be pretty easy to implement.

There is also the additional issue that on 64bit systems with 32bit
userland the ioctl emulation currently relies on the BKL.

-Andi