From: Peter Hurley <peter@hurleysoftware.com> To: Tejun Heo <tj@kernel.org> Cc: laijs@cn.fujitsu.com, linux-kernel@vger.kernel.org, Stefan Richter <stefanr@s5r6.in-berlin.de>, linux1394-devel@lists.sourceforge.net, Chris Boot <bootc@bootc.net>, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org Subject: Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK Date: Thu, 20 Feb 2014 21:07:27 -0500 [thread overview] Message-ID: <5306B4DF.4000901@hurleysoftware.com> (raw) In-Reply-To: <20140221015935.GF6897@htj.dyndns.org> On 02/20/2014 08:59 PM, Tejun Heo wrote: > Hello, > > On Thu, Feb 20, 2014 at 08:44:46PM -0500, Peter Hurley wrote: >>> +static void fw_device_workfn(struct work_struct *work) >>> +{ >>> + struct fw_device *device = container_of(to_delayed_work(work), >>> + struct fw_device, work); >> >> I think this needs an smp_rmb() here. > > The patch is equivalent transformation and the whole thing is > guaranteed to have gone through pool->lock. No explicit rmb > necessary. The spin_unlock_irq(&pool->lock) only guarantees completion of memory operations _before_ the unlock; memory operations which occur _after_ the unlock may be speculated before the unlock. IOW, unlock is not a memory barrier for operations that occur after. >> IOW, the beginning of the work function should act like a barrier in >> the same way that queue_work_on() (et. al.) already does. > > workqueue already has enough barriers; otherwise, the whole kernel > would have crumbled long time ago. See above. Regards, Peter Hurley
WARNING: multiple messages have this Message-ID (diff)
From: Peter Hurley <peter@hurleysoftware.com> To: Tejun Heo <tj@kernel.org> Cc: laijs@cn.fujitsu.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, linux1394-devel@lists.sourceforge.net, target-devel@vger.kernel.org Subject: Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK Date: Thu, 20 Feb 2014 21:07:27 -0500 [thread overview] Message-ID: <5306B4DF.4000901@hurleysoftware.com> (raw) In-Reply-To: <20140221015935.GF6897@htj.dyndns.org> On 02/20/2014 08:59 PM, Tejun Heo wrote: > Hello, > > On Thu, Feb 20, 2014 at 08:44:46PM -0500, Peter Hurley wrote: >>> +static void fw_device_workfn(struct work_struct *work) >>> +{ >>> + struct fw_device *device = container_of(to_delayed_work(work), >>> + struct fw_device, work); >> >> I think this needs an smp_rmb() here. > > The patch is equivalent transformation and the whole thing is > guaranteed to have gone through pool->lock. No explicit rmb > necessary. The spin_unlock_irq(&pool->lock) only guarantees completion of memory operations _before_ the unlock; memory operations which occur _after_ the unlock may be speculated before the unlock. IOW, unlock is not a memory barrier for operations that occur after. >> IOW, the beginning of the work function should act like a barrier in >> the same way that queue_work_on() (et. al.) already does. > > workqueue already has enough barriers; otherwise, the whole kernel > would have crumbled long time ago. See above. Regards, Peter Hurley ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
next prev parent reply other threads:[~2014-02-21 2:07 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-20 20:44 [PATCHSET wq/for-3.15] workqueue: remove PREPARE_[DELAYED_]WORK() Tejun Heo 2014-02-20 20:44 ` [PATCH 1/9] wireless/rt2x00: don't use PREPARE_WORK in rt2800usb.c Tejun Heo 2014-03-07 15:26 ` Tejun Heo 2014-02-20 20:44 ` [PATCH 2/9] ps3-vuart: don't use PREPARE_WORK Tejun Heo 2014-02-20 20:44 ` Tejun Heo 2014-02-21 23:19 ` Geoff Levand 2014-02-21 23:19 ` Geoff Levand 2014-02-20 20:44 ` [PATCH 3/9] floppy: don't use PREPARE_[DELAYED_]WORK Tejun Heo 2014-02-21 9:37 ` Jiri Kosina 2014-02-20 20:44 ` [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK Tejun Heo 2014-02-20 20:44 ` Tejun Heo 2014-02-21 1:44 ` Peter Hurley 2014-02-21 1:59 ` Tejun Heo 2014-02-21 2:07 ` Peter Hurley [this message] 2014-02-21 2:07 ` Peter Hurley 2014-02-21 2:13 ` Tejun Heo 2014-02-21 5:13 ` Peter Hurley 2014-02-21 10:03 ` Tejun Heo 2014-02-21 12:51 ` Peter Hurley 2014-02-21 12:51 ` Peter Hurley 2014-02-21 13:06 ` Tejun Heo 2014-02-21 16:53 ` Peter Hurley 2014-02-21 16:57 ` Tejun Heo 2014-02-21 23:01 ` Peter Hurley 2014-02-21 23:18 ` Tejun Heo 2014-02-21 23:46 ` Peter Hurley 2014-02-22 14:38 ` Tejun Heo 2014-02-22 14:38 ` Tejun Heo 2014-02-22 14:48 ` Peter Hurley 2014-02-22 18:43 ` James Bottomley 2014-02-22 18:48 ` Peter Hurley 2014-02-22 18:48 ` Peter Hurley 2014-02-22 18:52 ` James Bottomley 2014-02-22 19:03 ` Peter Hurley 2014-02-22 19:03 ` Peter Hurley 2014-02-23 1:23 ` memory-barriers.txt again (was Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK) Stefan Richter 2014-02-23 16:37 ` Paul E. McKenney 2014-02-23 16:37 ` Paul E. McKenney 2014-02-23 20:35 ` Peter Hurley 2014-02-23 23:50 ` Paul E. McKenney 2014-02-24 0:09 ` Peter Hurley 2014-02-24 16:26 ` Paul E. McKenney 2014-02-24 16:26 ` Paul E. McKenney 2014-02-24 0:32 ` Stefan Richter 2014-02-24 16:27 ` Paul E. McKenney 2014-02-23 20:05 ` [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK James Bottomley 2014-02-23 22:32 ` Peter Hurley 2014-02-21 20:45 ` Stefan Richter 2014-02-21 20:45 ` Stefan Richter 2014-03-05 21:34 ` Stefan Richter 2014-03-07 15:18 ` Tejun Heo 2014-03-07 15:26 ` [PATCH UPDATED " Tejun Heo 2014-03-07 15:26 ` Tejun Heo 2014-02-20 20:44 ` [PATCH 5/9] usb: " Tejun Heo 2014-02-20 20:59 ` Greg Kroah-Hartman 2014-02-21 15:06 ` Alan Stern 2014-02-21 15:07 ` Tejun Heo 2014-02-22 14:59 ` [PATCH v2 " Tejun Heo 2014-02-22 15:14 ` Alan Stern 2014-02-22 15:20 ` Peter Hurley 2014-02-22 15:37 ` Tejun Heo 2014-02-22 23:03 ` Alan Stern 2014-02-23 4:29 ` Tejun Heo 2014-02-20 20:44 ` [PATCH 6/9] nvme: don't use PREPARE_WORK Tejun Heo 2014-02-20 20:44 ` Tejun Heo 2014-03-07 15:26 ` Tejun Heo 2014-03-07 15:26 ` Tejun Heo 2014-02-20 20:44 ` [PATCH 7/9] afs: " Tejun Heo 2014-03-07 15:27 ` Tejun Heo 2014-02-20 20:44 ` [PATCH 8/9] staging/fwserial: " Tejun Heo 2014-02-21 15:13 ` Peter Hurley 2014-02-20 20:44 ` [PATCH 9/9] workqueue: remove PREPARE_[DELAYED_]WORK() Tejun Heo 2014-03-07 15:27 ` Tejun Heo 2014-02-20 22:00 ` [PATCH 7/9] afs: don't use PREPARE_WORK David Howells 2014-02-20 22:46 ` Tejun Heo
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=5306B4DF.4000901@hurleysoftware.com \ --to=peter@hurleysoftware.com \ --cc=bootc@bootc.net \ --cc=laijs@cn.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=linux1394-devel@lists.sourceforge.net \ --cc=stefanr@s5r6.in-berlin.de \ --cc=target-devel@vger.kernel.org \ --cc=tj@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: linkBe 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.