public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Greg KH <greg@kroah.com>
Cc: Wen Xiong <wendyx@us.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: [ patch 4/7] drivers/serial/jsm: new serial device driver
Date: Wed, 9 Mar 2005 16:11:08 +0000	[thread overview]
Message-ID: <20050309161108.F25398@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20050308064424.GF17022@kroah.com>; from greg@kroah.com on Mon, Mar 07, 2005 at 10:44:25PM -0800

On Mon, Mar 07, 2005 at 10:44:25PM -0800, Greg KH wrote:
> On Mon, Mar 07, 2005 at 05:46:51PM -0500, Wen Xiong wrote:
> > +static ssize_t jsm_tty_baud_show(struct class_device *class_dev, char *buf)
> > +{
> > +	struct jsm_channel *ch;
> > +
> > +	if (class_dev) {
> > +		ch = class_get_devdata(class_dev);
> > +		if ( ch && (ch->ch_bd->state == BOARD_READY))
> > +		return snprintf(buf, PAGE_SIZE, "%d\n", ch->ch_old_baud);
> > +	}
> > +
> > +	return -EINVAL;
> > +}
> > +static CLASS_DEVICE_ATTR(baud, S_IRUGO, jsm_tty_baud_show, NULL);
> 
> No, please delete these, and the other sysfs files that duplicate the
> same info that you can get by using the standard Linux termios calls.
> There is no need for them here.

Greg, there's several other points about why the above is Bad(tm).

"class_dev" will always be non-null.

Note that this (and similar code) is racy.  Consider what happens when
the class device is removed (and the class devdata is NULL'd or kfree'd)
while another process on another CPU reads from one of these sysfs files.
*BANG*.

Also, if a class device attribute method is going to access data outside
the same allocation which the class device is a part of, you *absolutely*
*must* have some form of locking.

Also note that the formatting of these snippets of code is abismal.
There is a missing tab which makes it very non-readable.

With all of the above comments, it should be something like:

+static ssize_t jsm_tty_baud_show(struct class_device *class_dev, char *buf)
+{
+	struct jsm_channel *ch;
+	int ret = -EINVAL;
+
+	down(&some_lock);
+	ch = class_get_devdata(class_dev);
+	if (ch && (ch->ch_bd->state == BOARD_READY))
+		ret = snprintf(buf, PAGE_SIZE, "%d\n", ch->ch_old_baud);
+	up(&some_lock);
+
+	return ret;
+}
+static CLASS_DEVICE_ATTR(baud, S_IRUGO, jsm_tty_baud_show, NULL);

where "some_lock" is also taken in the device unregistration path, at
the point where the class devdata is NULL'd out.  (which the driver is
also missing.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

  parent reply	other threads:[~2005-03-09 16:14 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-27 23:39 [ patch 4/7] drivers/serial/jsm: new serial device driver Wen Xiong
2005-02-28  3:21 ` Christoph Hellwig
2005-02-28  6:39 ` Greg KH
2005-03-04 21:08   ` Wen Xiong
2005-03-04 22:01     ` Greg KH
2005-03-07 22:46       ` Wen Xiong
2005-03-08  6:44         ` Greg KH
2005-03-08 18:55           ` Wen Xiong
2005-03-08 23:58             ` Greg KH
2005-03-09 15:47               ` Wen Xiong
2005-03-09 16:35                 ` Greg KH
2005-03-09 17:18                   ` Wen Xiong
2005-03-09 18:58                     ` Greg KH
2005-03-11 15:29                       ` [ patch 1/5] " Wen Xiong
2005-03-12 13:06                         ` Domen Puncer
2005-03-14 17:35                           ` Wen Xiong
2005-03-14 20:24                             ` Domen Puncer
2005-03-14 21:24                               ` Wen Xiong
2005-03-11 15:32                       ` [ patch 2/5] " Wen Xiong
2005-03-30 14:55                         ` Russell King
2005-03-11 15:38                       ` [ patch 3/5] " Wen Xiong
2005-03-11 15:53                         ` Arjan van de Ven
2005-03-11 16:39                           ` Wen Xiong
2005-03-11 16:46                             ` Arjan van de Ven
2005-03-11 22:34                               ` Wen Xiong
2005-03-30 15:01                                 ` Russell King
2005-03-11 15:38                       ` [ patch 4/5] " Wen Xiong
2005-03-11 15:38                       ` [ patch 5/5] " Wen Xiong
2005-03-09 16:11           ` Russell King [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-03-08 21:47 [ patch 4/7] " Kilau, Scott
2005-03-09  0:02 ` Greg KH
2005-03-09 16:16 ` Russell King
2005-03-09  2:36 Kilau, Scott
2005-03-09  5:50 ` Greg KH

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=20050309161108.F25398@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wendyx@us.ibm.com \
    /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