mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dave Olien <dmo@osdl.org>
Cc: marcelo@conectiva.com.br, alan@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] DAC960 open with O_NONBLOCK
Date: Mon, 21 Apr 2003 18:37:52 +0100	[thread overview]
Message-ID: <20030421183752.A8782@infradead.org> (raw)
In-Reply-To: <20030421172402.GA26863@osdl.org>; from dmo@osdl.org on Mon, Apr 21, 2003 at 10:24:04AM -0700

On Mon, Apr 21, 2003 at 10:24:04AM -0700, Dave Olien wrote:
> This "special" file descriptor is created when the driver's open method
> is called with for block special file for controller 0, disk 0,
> with the O_NONBLOCK flag set.  In thsi case, the driver's open method
> bypasses all checks for a disk associated with that file, and doesn't
> increment any reference counts.
> 
> The problem comes at close() time.  This driver code apparently originated
> with linux 2.2, where driver operations were all "file operations".
> In linux 2.2, the driver release method was passed the file descriptor
> that has the O_NONBLOCK flag set.  The release method knows then to not
> decrement reference counts, etc.
>
> In linux 2.4, driver release methods still have a file descriptor argument.
> But, the kernel NEVER passes a non-NULL file argument to the release method.
> So, the DAC960 driver doesn't know that the release method is being called
> for this "special" file descriptor, and improperly decrements reference
> counts.  This makes subsequent opens now work right.

I just went over the same code in 2.5 - the reference counts are
entirely superflous, you can just nuke them.

> I don't like this "special file descriptor" method.  I would have much
> rather created an entry in /proc or something to support these pass through
> commands.  But I imagine there are applications out there that expect
> these special file descriptors.  On the other hand, this HAS been
> broken throught the life on linux 2.4.

What applications?

> I'll be submitting a similar patch to linux 2.5 shortly.

Don't even bother.  Linux 2.5 is the place to fix this issue
correctly.


  reply	other threads:[~2003-04-21 17:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-21 17:24 Dave Olien
2003-04-21 17:37 ` Christoph Hellwig [this message]
2003-04-21 19:01   ` Dave Olien
2003-04-21 19:04     ` Christoph Hellwig
2003-04-21 20:14     ` Alan Cox
2003-04-21 21:35       ` Dave Olien

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=20030421183752.A8782@infradead.org \
    --to=hch@infradead.org \
    --cc=alan@redhat.com \
    --cc=dmo@osdl.org \
    --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

all inboxes | Powered by JetHome®