All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Kacur <jkacur@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] input: remove BKL from uinput open function
Date: Mon, 1 Feb 2010 21:27:22 +0100	[thread overview]
Message-ID: <520f0cf11002011227s74e57673j3922941f7ee87989@mail.gmail.com> (raw)
In-Reply-To: <520f0cf11002011222h134dbf06rf1db612da9a9728@mail.gmail.com>

On Mon, Feb 1, 2010 at 9:22 PM, John Kacur <jkacur@redhat.com> wrote:
> On Sun, Jan 31, 2010 at 6:29 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Sun, Jan 31, 2010 at 05:20:55AM +0100, Arnd Bergmann wrote:
>>> On Sunday 31 January 2010, John Kacur wrote:
>>> > > Sorry, I should have been clearer, but not implementing llseek
>>> > > is the problem I was referring to: When a driver has no explicit
>>> > > .llseek operation in its file operations and does not call
>>> > > nonseekable_open from its open operation, the VFS layer will
>>> > > implicitly use default_llseek, which takes the BKL. We're
>>> > > in the process of changing drivers not to do this, one by one
>>> > > so we can kill the BKL in the end.
>>> > >
>>> >
>>> > I know we've discussed this before, but why wouldn't the following
>>> > make more sense?
>>> >  .llseek         = no_llseek,
>>>
>>> That's one of the possible solutions. Assigning it to generic_file_llseek
>>> also gets rid of the BKL but keeps the current behaviour (calling seek
>>> returns success without having an effect, no_llseek returns -ESPIPE),
>>> while calling nonseekable_open has the other side-effect of making
>>> pread/pwrite fail with -ESPIPE, which is more consistent than
>>> only failing seek.
>>>
>>
>> OK, so how about the patch below (on top of Thadeu's patch)?
>>
>> --
>> Dmitry
>>
>> Input: uinput - use nonseekable_open
>>
>> Seeking does not make sense for uinput so let's use nonseekable_open
>> to mark the device non-seekable.
>>
>> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
>> ---
>>
>>  drivers/input/misc/uinput.c |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>>
>> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
>> index 18206e1..7089151 100644
>> --- a/drivers/input/misc/uinput.c
>> +++ b/drivers/input/misc/uinput.c
>> @@ -278,6 +278,7 @@ static int uinput_create_device(struct uinput_device *udev)
>>  static int uinput_open(struct inode *inode, struct file *file)
>>  {
>>        struct uinput_device *newdev;
>> +       int error;
>>
>>        newdev = kzalloc(sizeof(struct uinput_device), GFP_KERNEL);
>>        if (!newdev)
>> @@ -291,6 +292,12 @@ static int uinput_open(struct inode *inode, struct file *file)
>>
>>        file->private_data = newdev;
>>
>> +       error = nonseekable_open(inode, file);
>> +       if (error) {
>> +               kfree(newdev);
>> +               return error;
>> +       }
>> +
>>        return 0;
>>  }
>>
>>
>
> Hmnn, if you look at nonseekable_open() it will always return 0. I
> think you can just do the following.
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 18206e1..697c0a6 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -291,7 +291,7 @@ static int uinput_open(struct inode *inode, struct file *fil
>
>        file->private_data = newdev;
>
> -       return 0;
> +       return nonseekable_open(inode, file);
>  }
>
> Signed-off-by: John Kacur <jkacur@redhat.com>
>

Btw, Thadeu Lima de Souza Cascardo should just combine that all into
one patch, no point really in making two patches out of that.

  reply	other threads:[~2010-02-01 20:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-29 21:23 [PATCH] input: remove BKL from uinput open function Thadeu Lima de Souza Cascardo
2010-01-30  6:41 ` Arnd Bergmann
2010-01-30  7:22   ` Dmitry Torokhov
2010-01-30 21:57     ` Arnd Bergmann
2010-01-30 23:07       ` John Kacur
2010-01-31  4:20         ` Arnd Bergmann
2010-01-31  5:29           ` Dmitry Torokhov
2010-02-01 20:22             ` John Kacur
2010-02-01 20:22               ` John Kacur
2010-02-01 20:27               ` John Kacur [this message]
2010-02-01 20:46                 ` Thadeu Lima de Souza Cascardo
2010-02-01 21:04                   ` John Kacur
2010-02-01 21:04                     ` John Kacur
2010-02-01 21:21                 ` Dmitry Torokhov
2010-02-01 21:21                   ` Dmitry Torokhov
2010-02-01 21:50                   ` John Kacur
2010-02-01 21:50                     ` John Kacur
2010-02-01 22:08                     ` Dmitry Torokhov
2010-02-01 22:08                       ` Dmitry Torokhov
2010-02-01 23:18                       ` John Kacur
2010-02-01 23:18                         ` John Kacur
2010-02-03  5:07                         ` Dmitry Torokhov
2010-02-04  7:32                           ` Arnd Bergmann
2010-02-05 16:04                             ` John Kacur
2010-01-30  7:57 ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=520f0cf11002011227s74e57673j3922941f7ee87989@mail.gmail.com \
    --to=jkacur@gmail.com \
    --cc=arnd@arndb.de \
    --cc=cascardo@holoscopio.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.