From: Russell King <rmk@arm.linux.org.uk>
To: BALBIR SINGH <balbir.singh@wipro.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Patch: Fix serial module use count (2.4.16 _and_ 2.5)
Date: Thu, 29 Nov 2001 15:37:20 +0000 [thread overview]
Message-ID: <20011129153720.C6214@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20011129131059.A6214@flint.arm.linux.org.uk> <3C063CB3.4090708@wipro.com>
In-Reply-To: <3C063CB3.4090708@wipro.com>; from balbir.singh@wipro.com on Thu, Nov 29, 2001 at 07:18:35PM +0530
On Thu, Nov 29, 2001 at 07:18:35PM +0530, BALBIR SINGH wrote:
> The current code on my system 2.5.0 looks like
>
> if (!page) {
> MOD_DEC_USE_COUNT;
> return -ENOMEM;
> }
>
>
> I was wondering that if the open failed with something like this
>
> open(/dev/ttyS0, args) = -ENOMEM;
>
> why would somebody call close on /dev/ttyS0? If you call close on
> a descriptor that failed to open, it is *BAD* code.
Err,
close(-ENOMEM);
What's that going to close? Hint: you _can't_ close a descriptor that
failed to open, since you don't have a descriptor to close. You can
only try to close an error code, but that's not going to make it anywhere
near the kernel driver level.
> I am assuming
> that the tty layer that talks to the serial driver calls rs_close().
Correct.
> The same thing applies to the code below. I think that the open routine
> should instead set tty->driver_data to NULL upon failure.
Here's an example why that'd be real bad:
1. process A opens /dev/ttyS0 as a normal device. This initialises
tty->driver_data.
2. process B tries to open /dev/cua0
3. process B fails with -EBUSY since the normal device is open and active
(see block_til_ready)
4. since rs_open failed, we set tty->driver_data to be NULL (note that this
is the same tty device pointer as (1) above.
5. process A writes to /dev/ttyS0
6. rs_write does the following:
struct async_struct *info = (struct async_struct *)tty->driver_data;
7. Oops.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next prev parent reply other threads:[~2001-11-29 15:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-29 13:10 Patch: Fix serial module use count (2.4.16 _and_ 2.5) Russell King
2001-11-29 13:48 ` BALBIR SINGH
2001-11-29 15:37 ` Russell King [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-11-29 16:06 Balbir Singh
2001-11-29 16:17 ` Russell King
2001-11-30 4:25 ` BALBIR SINGH
2001-11-30 9:36 ` Russell King
2001-11-30 22:19 ` Mike Fedyk
2001-11-30 23:06 ` Russell King
2001-12-01 0:20 ` Mike Fedyk
2001-11-29 18:03 ` Jeff Randall
2001-11-29 18:12 ` Russell King
2001-11-29 18:44 ` Jeff Randall
2001-11-29 19:05 ` James Simmons
2001-11-30 10:44 ` Maciej W. Rozycki
2001-11-30 10:56 ` Russell King
2001-11-30 12:11 ` Maciej W. Rozycki
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=20011129153720.C6214@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=balbir.singh@wipro.com \
--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.