From: Duncan Sands <duncan.sands@math.u-psud.fr>
To: Simon Arlott <simon@fire.lp0.eu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [PATCH] cxacru: ADSL state management
Date: Sun, 15 Apr 2007 12:08:59 +0200 [thread overview]
Message-ID: <200704151208.59719.duncan.sands@math.u-psud.fr> (raw)
In-Reply-To: <462172E3.7030408@simon.arlott.org.uk>
Hi Simon,
> +static ssize_t cxacru_sysfs_show_adsl_state(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct usb_interface *intf = to_usb_interface(dev);
> + struct usbatm_data *usbatm_instance = usb_get_intfdata(intf);
> + struct cxacru_data *instance = usbatm_instance->driver_data;
instance could be NULL if cxacru_sysfs_show_adsl_state is called after
the device has been unbound. What prevents this?
> +static ssize_t cxacru_sysfs_store_adsl_state(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t count)
This is not serialized by a lock, so if two or more processes call it
simultaneously then the commands to the modem can be interleaved, which
could (a) leave it in a funky state, and (b) means that the value of poll
could be wrong when you write it to instance->poll_state, eg because the
processes could reach the poll_state writing step in reverse order to the
order in which they reached the sending-commands-to-the-modem step.
> @@ -503,6 +622,7 @@ static int cxacru_atm_start(struct usbatm_data *usbatm_instance,
> struct atm_dev *atm_dev = usbatm_instance->atm_dev;
> */
> int ret;
> + int start_polling = 1;
>
> dbg("cxacru_atm_start");
>
> @@ -522,7 +642,25 @@ static int cxacru_atm_start(struct usbatm_data *usbatm_instance,
> }
>
> /* Start status polling */
> - cxacru_poll_status(&instance->poll_work.work);
> + mutex_lock(&instance->poll_state_serialize);
> + switch (instance->poll_state) {
Can poll_state really have anything else than its initial
value here?
> + mutex_unlock(&instance->poll_state_serialize);
> +
> + if (start_polling)
> + cxacru_poll_status(&instance->poll_work.work);
Between releasing the lock and calling cxacru_poll_status, another
process could have called cxacru_sysfs_store_adsl_state and changed
whether you want to poll or not. I don't know if it matters.
> + mutex_unlock(&instance->poll_state_serialize);
> +
> + if (keep_polling)
> + schedule_delayed_work(&instance->poll_work,
> + round_jiffies_relative(POLL_INTERVAL*HZ));
Likewise.
> @@ -917,8 +1102,20 @@ static void cxacru_unbind(struct usbatm_data *usbatm_instance,
> return;
> }
>
> - while (!cancel_delayed_work(&instance->poll_work))
> - flush_scheduled_work();
> + mutex_lock(&instance->poll_state_serialize);
> + BUG_ON(instance->poll_state == CXPOLL_SHUTDOWN);
> +
> + /* ensure that status polling continues unless
> + * it has already stopped */
Your device has been removed. Why would you want to go on
polling? Especially as your device structures are about to
be freed... By the way, where do you remove the sysfs files?
> + mutex_unlock(&instance->poll_state_serialize);
> +
> + if (is_polling)
> + cancel_rearming_delayed_work(&instance->poll_work);
This looks unreliable, again due to race conditions. Better to always
shoot it down.
Ciao,
Duncan.
next prev parent reply other threads:[~2007-04-15 10:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-15 0:33 Simon Arlott
2007-04-15 10:08 ` Duncan Sands [this message]
2007-04-15 13:57 ` Simon Arlott
2007-04-15 14:20 ` [PATCH (rev 2)] " Simon Arlott
2007-04-15 17:06 ` [PATCH (rev 3)] " Simon Arlott
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=200704151208.59719.duncan.sands@math.u-psud.fr \
--to=duncan.sands@math.u-psud.fr \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=simon@fire.lp0.eu \
/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®