All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: John Kacur <jkacur@redhat.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,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] input: remove BKL from uinput open function
Date: Tue, 2 Feb 2010 21:07:49 -0800	[thread overview]
Message-ID: <20100203050749.GA22110@core.coreip.homeip.net> (raw)
In-Reply-To: <520f0cf11002011518y22c2f097s87872e7b5b1690d7@mail.gmail.com>

On Tue, Feb 02, 2010 at 12:18:35AM +0100, John Kacur wrote:
> 
> Sorry, maybe I am doing a poor job of explaining myself. My question
> was whether your driver needs to call uinput_release() or not if it
> went through your proposed error path, because that is where you have
> the call to the uinput_destroy_device() function.
> After taking a fresh look at your code I don't believe that it does.
> However, you could still hoist your code that calls nonseekable_open()
> above all that init stuff in uinput_open(), just under the return
> -ENOMEM if you think that it could fail.
> However, I still think that nonseekable_open() is designed from the
> "get-go" to never fail, so I think your code is unnecessarily
> complicated, by just a little bit. It will still work, so you decide
> which to go with. I'm fine with either way.
>

OK, so how about the patch below? If it is accepted I will just switch
to

	nonseekable_open(inode, file);
	return 0;

style. I gonna add Al and akpm to CC to see if the patch will stick...

-- 
Dmitry

VFS: clarify that nonseekable_open() will never fail

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 fs/open.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)


diff --git a/fs/open.c b/fs/open.c
index 040cef7..02ceb73 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1200,7 +1200,9 @@ EXPORT_SYMBOL(generic_file_open);
 
 /*
  * This is used by subsystems that don't want seekable
- * file descriptors
+ * file descriptors. The function is not supposed to ever fail, the only
+ * reason it returns an 'int' and not 'void' is so that it can be plugged
+ * directly into file_operations structure.
  */
 int nonseekable_open(struct inode *inode, struct file *filp)
 {

  reply	other threads:[~2010-02-03  5:08 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
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 [this message]
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=20100203050749.GA22110@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=cascardo@holoscopio.com \
    --cc=jkacur@redhat.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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.