public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Axel Kittenberger <Axel.Kittenberger@maxxio.at>
Cc: linux-kernel@vger.kernel.org, Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: Patch, forward release() return values to the close() call
Date: Thu, 21 Mar 2002 03:13:39 -0500	[thread overview]
Message-ID: <3C999633.2060104@mandrakesoft.com> (raw)
In-Reply-To: <200203210747.IAA25949@merlin.gams.co.at>

Axel Kittenberger wrote:

>Here goes my liitle patchy, once again :o)
>
>Whats it's about?
>
>When close()ing an charcter device one expects the return value of the 
>charcter drivers release() call to be forwarded to the close() called in 
>userspace. However thats not the case, the kernel swallows the release() 
>value, and always returns 0 to the userspace's close(). (tha char drivers 
>release() function is called in fput() as it would have a void return value)
>
>It may sound weired at first but there are actually device drivers than can 
>fail on close(), in my case it's a driver to program a LCA, the userspace 
>application signals end of data by closing the device, the driver finalizes 
>the download, and the LCA reports if it has accepted it's new program, if not 
>close() should return a non-zero value, indicating the operation did not 
>complete successfully.
>

Do you see how many places call fput() ?   Are you going to audit 
__all__ those paths and prove to us that changing the semantics of 
close(2) in Linux doesn't break things in the kernel or in userland?

Your driver is buggy, if it thinks it can fail f_op->release.

    Jeff







  reply	other threads:[~2002-03-21  8:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-21  7:47 Patch, forward release() return values to the close() call Axel Kittenberger
2002-03-21  8:13 ` Jeff Garzik [this message]
2002-03-21 16:32   ` David Brown
2002-03-22  7:58     ` Axel Kittenberger
2002-03-22 13:51       ` David Brown
2002-03-25  9:50         ` Axel Kittenberger
2002-03-25 13:33           ` David Brown
2002-03-26  8:52             ` Axel Kittenberger
2002-03-21  8:21 ` Jeff Garzik
2002-03-21  8:27 ` Jeff Garzik
2002-03-21  9:10   ` Oliver Neukum
2002-03-21  9:18     ` Jeff Garzik
2002-03-21 10:14       ` Oliver.Neukum
     [not found] <mailman.1016697001.29134.linux-kernel2news@redhat.com>
     [not found] ` <200203211845.g2LIjTu22218@devserv.devel.redhat.com>
2002-03-22  8:06   ` Axel Kittenberger
2002-03-22  8:53     ` Pete Zaitcev

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=3C999633.2060104@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=Axel.Kittenberger@maxxio.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox