mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oliver Neukum <oliver@neukum.org>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, <laforge@gnumonks.org>,
	greg@kroah.com
Subject: Re: My vision of usbmon
Date: Wed, 22 Dec 2004 21:46:33 +0100	[thread overview]
Message-ID: <200412222146.33279.oliver@neukum.org> (raw)
In-Reply-To: <20041221182514.5ed935e2@lembas.zaitcev.lan>

Am Mittwoch, 22. Dezember 2004 03:25 schrieb Pete Zaitcev:
> On Mon, 20 Dec 2004 15:25:52 +0100, Oliver Neukum <oliver@neukum.org> wrote:
> 
> > Am Montag, 20. Dezember 2004 08:04 schrieb Pete Zaitcev:
> > > +               memcpy(&mbus->shim_ops, ubus->op, sizeof(struct usb_operations));
> > > +               mbus->shim_ops.submit_urb = mon_submit;
> > > +               mbus->saved_op = ubus->op;
> > > +               ubus->op = &mbus->shim_ops;
> > > +               ubus->monitored = 1;
> > 
> > I think you need smp_wmb() here to make sure that an irq taken
> > on another CPU sees the manipulations in the correct order.
> 
> Hmm, it seems you are right. I forgot about reordering issues. I relied on
> op being atomic, but if it points at an uninitialized shim, this will end
> badly. How about this?
> 
>                 memcpy(&mbus->shim_ops, ubus->op, sizeof(struct usb_operations));
>                 mbus->shim_ops.submit_urb = mon_submit;
>                 mbus->saved_op = ubus->op;
>                 smp_mb();       /* ubus->op is not protected by spinlocks */
smp_wmb() would do.

>                 ubus->op = &mbus->shim_ops;
>                 ubus->monitored = 1;
> 
> Generally, the type of coding which requires a use of memory barriers in drivers
> is a bug or a latent bug, so I am sorry for the above. It was a sacrifice to
> make usbmon invisible if it's not actively monitoring. Sorry about that.

That is the best way. It's just a little tricky.

	Regards
		Oliver
 

  parent reply	other threads:[~2004-12-22 20:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-20  7:04 Pete Zaitcev
     [not found] ` <200412201255.59120.oliver@neukum.org>
2004-12-20 12:21   ` [linux-usb-devel] " Pete Zaitcev
2004-12-22  0:57 ` Greg KH
2004-12-22  1:29   ` Pete Zaitcev
2004-12-22  5:06     ` Greg KH
2004-12-22  5:10       ` Greg KH
2004-12-22  1:38   ` Nick Piggin
2004-12-22  5:04     ` Greg KH
2004-12-22  5:34       ` Jeff Garzik
2004-12-22  6:43         ` Greg KH
     [not found] ` <200412201525.52149.oliver@neukum.org>
2004-12-22  2:25   ` Pete Zaitcev
2004-12-22  5:03     ` Greg KH
2004-12-22 20:46     ` Oliver Neukum [this message]
2004-12-23 21:02 Chad Kitching
2005-01-11  1:36 ` 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=200412222146.33279.oliver@neukum.org \
    --to=oliver@neukum.org \
    --cc=greg@kroah.com \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=zaitcev@redhat.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

all inboxes | Powered by JetHome®