From: Nicholas Piggin <npiggin@gmail.com> To: Will Deacon <will.deacon@arm.com> Cc: Akira Yokosawa <akiyks@gmail.com>, Andrea Parri <andrea.parri@amarulasolutions.com>, Arnd Bergmann <arnd@arndb.de>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Rich Felker <dalias@libc.org>, David Howells <dhowells@redhat.com>, Daniel Lustig <dlustig@nvidia.com>, linux-arch <linux-arch@vger.kernel.org>, Linux List Kernel Mailing <linux-kernel@vger.kernel.org>, "Maciej W. Rozycki" <macro@linux-mips.org>, Luis Chamberlain <mcgrof@kernel.org>, Ingo Molnar <mingo@kernel.org>, Mikulas Patocka <mpatocka@redhat.com>, Michael Ellerman <mpe@ellerman.id.au>, Palmer Dabbelt <palmer@sifive.com>, Paul Burton <paul.burton@mips.com>, "Paul E. McKenney" <paulmck@linux.ibm.com>, Peter Zijlstra <peterz@infradead.org>, Alan Stern <stern@rowland.harvard.edu>, Tony Luck <tony.luck@intel.com>, Linus Torvalds <torvalds@linux-foundation.org>, Yoshinori Sato <ysato@users.sourceforge.jp> Subject: Re: [PATCH v2 17/21] drivers: Remove explicit invocations of mmiowb() Date: Wed, 10 Apr 2019 10:25:20 +1000 [thread overview] Message-ID: <1554855359.817ryayv8z.astroid@bobo.none> (raw) In-Reply-To: <20190409134616.GD2990@fuggles.cambridge.arm.com> Will Deacon's on April 9, 2019 11:46 pm: > Hi Nick, > > On Tue, Apr 09, 2019 at 07:00:52PM +1000, Nicholas Piggin wrote: >> Linus Torvalds's on April 6, 2019 1:50 am: >> > On Fri, Apr 5, 2019 at 4:01 AM Will Deacon <will.deacon@arm.com> wrote: >> >> >> >> mmiowb() is now implied by spin_unlock() on architectures that require >> >> it, so there is no reason to call it from driver code. This patch was >> >> generated using coccinelle: >> >> >> >> @mmiowb@ >> >> @@ >> >> - mmiowb(); >> > >> > So I love the patch series, and think we should just do it, but I do >> > wonder if some of the drivers involved end up relying on memory >> > ordering things (store_release -> load_aquire) and IO ordering rather >> > than using locking... >> >> Hopefully the convention that smp_ prefix does not work for MMIO >> ordering helps there. Drivers relying on that would be broken today >> on powerpc, at least. >> >> > Wouldn't such use now be broken on ia64 SN platforms? Do we care? >> >> Hopefully not too much, what changed since last thread? :) >> >> > So it might be worth noting that a lot of the mmiowb()s here weren't >> > paired with spin_unlock? >> >> I repeat myself, but the correct change is for ia64 to #define wmb to >> mmiowb, then nothing is silently broken, nothing has to be noted, and >> nobody has to care. The ia64/sn2 platform will run a little slower >> that's all. > > That's certainly something for the ia64 maintainers to consider, if they > care about this behaviour. I still have hope that we'll drop ia64 in the > near future :) Well we don't need to for this reason, at least. Wouldn't cost architecture independent code anything. I don't have much opinion about it, but Itaniums of course are still being sold and the latest chip released in 2017. The last Itanium Altix seems more than 10 years old though so it might be reasonable to remove sn2 (if it's causing a big headache). > >> But deliberately breaking sn2 I guess is implicitly acknowledging the >> same end result that I wanted, so fine. >> >> I think it might be an idea to remove all the mmiowb() that obviously >> come before spin_unlock in one big patch, but then submit the rest >> individually to driver maintainers. I could do that rather than ask >> more work from Will, if he and you agree. > > That's an option, I suppose, but I'd much rather just kill off mmiowb() in > one fell swoop and be done with it. I've added the following message to > the commit of the coccinelle patch so any breakage should be easily > rectified: > > | NOTE: mmiowb() has only ever guaranteed ordering in conjunction with > | spin_unlock(). However, pairing each mmiowb() removal in this patch > | with the corresponding call to spin_unlock() is not at all trivial, > | so there is a small chance that this change may regress any drivers > | incorrectly relying on mmiowb() to order MMIO writes between CPUs using > | lock-free synchronisation. If you've ended up bisecting to this commit, > | you can reintroduce the mmiowb() calls using wmb() instead, which should > | restore the old behaviour on all architectures other than some esoteric > | ia64 systems. > > That way we don't have to worry about the long tail of commits removing > undocumented, dangling barriers. > > It's not like we're losing the information about where the mmiowb()s used to > be, so it should be easy to address any fallout (but I'm not really expecting > anything significant, to be honest with you). Well if you feel strongly about it I don't object. Thanks, Nick
WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com> To: Will Deacon <will.deacon@arm.com> Cc: Akira Yokosawa <akiyks@gmail.com>, Andrea Parri <andrea.parri@amarulasolutions.com>, Arnd Bergmann <arnd@arndb.de>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Rich Felker <dalias@libc.org>, David Howells <dhowells@redhat.com>, Daniel Lustig <dlustig@nvidia.com>, linux-arch <linux-arch@vger.kernel.org>, Linux List Kernel Mailing <linux-kernel@vger.kernel.org>, "Maciej W. Rozycki" <macro@linux-mips.org>, Luis Chamberlain <mcgrof@kernel.org>, Ingo Molnar <mingo@kernel.org>, Mikulas Patocka <mpatocka@redhat.com>, Michael Ellerman <mpe@ellerman.id.au>, Palmer Dabbelt <palmer@sifive.com>, Paul Burton <paul.burton@mips.com>, "Paul E. McKenney" <paulmck@linux.ibm.com>, Peter Zijlstra <peterz@infradead.org>, Alan Stern <stern@rowland.harvard.e> Subject: Re: [PATCH v2 17/21] drivers: Remove explicit invocations of mmiowb() Date: Wed, 10 Apr 2019 10:25:20 +1000 [thread overview] Message-ID: <1554855359.817ryayv8z.astroid@bobo.none> (raw) In-Reply-To: <20190409134616.GD2990@fuggles.cambridge.arm.com> Will Deacon's on April 9, 2019 11:46 pm: > Hi Nick, > > On Tue, Apr 09, 2019 at 07:00:52PM +1000, Nicholas Piggin wrote: >> Linus Torvalds's on April 6, 2019 1:50 am: >> > On Fri, Apr 5, 2019 at 4:01 AM Will Deacon <will.deacon@arm.com> wrote: >> >> >> >> mmiowb() is now implied by spin_unlock() on architectures that require >> >> it, so there is no reason to call it from driver code. This patch was >> >> generated using coccinelle: >> >> >> >> @mmiowb@ >> >> @@ >> >> - mmiowb(); >> > >> > So I love the patch series, and think we should just do it, but I do >> > wonder if some of the drivers involved end up relying on memory >> > ordering things (store_release -> load_aquire) and IO ordering rather >> > than using locking... >> >> Hopefully the convention that smp_ prefix does not work for MMIO >> ordering helps there. Drivers relying on that would be broken today >> on powerpc, at least. >> >> > Wouldn't such use now be broken on ia64 SN platforms? Do we care? >> >> Hopefully not too much, what changed since last thread? :) >> >> > So it might be worth noting that a lot of the mmiowb()s here weren't >> > paired with spin_unlock? >> >> I repeat myself, but the correct change is for ia64 to #define wmb to >> mmiowb, then nothing is silently broken, nothing has to be noted, and >> nobody has to care. The ia64/sn2 platform will run a little slower >> that's all. > > That's certainly something for the ia64 maintainers to consider, if they > care about this behaviour. I still have hope that we'll drop ia64 in the > near future :) Well we don't need to for this reason, at least. Wouldn't cost architecture independent code anything. I don't have much opinion about it, but Itaniums of course are still being sold and the latest chip released in 2017. The last Itanium Altix seems more than 10 years old though so it might be reasonable to remove sn2 (if it's causing a big headache). > >> But deliberately breaking sn2 I guess is implicitly acknowledging the >> same end result that I wanted, so fine. >> >> I think it might be an idea to remove all the mmiowb() that obviously >> come before spin_unlock in one big patch, but then submit the rest >> individually to driver maintainers. I could do that rather than ask >> more work from Will, if he and you agree. > > That's an option, I suppose, but I'd much rather just kill off mmiowb() in > one fell swoop and be done with it. I've added the following message to > the commit of the coccinelle patch so any breakage should be easily > rectified: > > | NOTE: mmiowb() has only ever guaranteed ordering in conjunction with > | spin_unlock(). However, pairing each mmiowb() removal in this patch > | with the corresponding call to spin_unlock() is not at all trivial, > | so there is a small chance that this change may regress any drivers > | incorrectly relying on mmiowb() to order MMIO writes between CPUs using > | lock-free synchronisation. If you've ended up bisecting to this commit, > | you can reintroduce the mmiowb() calls using wmb() instead, which should > | restore the old behaviour on all architectures other than some esoteric > | ia64 systems. > > That way we don't have to worry about the long tail of commits removing > undocumented, dangling barriers. > > It's not like we're losing the information about where the mmiowb()s used to > be, so it should be easy to address any fallout (but I'm not really expecting > anything significant, to be honest with you). Well if you feel strongly about it I don't object. Thanks, Nick
next prev parent reply other threads:[~2019-04-10 0:25 UTC|newest] Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-05 13:59 [PATCH v2 00/21] Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb()) Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-10 10:58 ` Ingo Molnar 2019-04-10 10:58 ` Ingo Molnar 2019-04-10 12:28 ` Will Deacon 2019-04-10 12:28 ` Will Deacon 2019-04-10 12:28 ` Will Deacon 2019-04-11 11:00 ` Ingo Molnar 2019-04-11 11:00 ` Ingo Molnar 2019-04-11 22:12 ` Benjamin Herrenschmidt 2019-04-11 22:12 ` Benjamin Herrenschmidt 2019-04-11 22:34 ` Linus Torvalds 2019-04-11 22:34 ` Linus Torvalds 2019-04-12 2:07 ` Benjamin Herrenschmidt 2019-04-12 2:07 ` Benjamin Herrenschmidt 2019-04-12 13:17 ` Will Deacon 2019-04-12 13:17 ` Will Deacon 2019-04-15 4:05 ` Benjamin Herrenschmidt 2019-04-15 4:05 ` Benjamin Herrenschmidt 2019-04-16 9:13 ` Will Deacon 2019-04-16 9:13 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 02/21] asm-generic/mmiowb: Add generic implementation of mmiowb() tracking Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 03/21] arch: Use asm-generic header for asm/mmiowb.h Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 04/21] mmiowb: Hook up mmiowb helpers to spinlocks and generic I/O accessors Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 05/21] ARM/io: Remove useless definition of mmiowb() Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 06/21] arm64/io: " Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 07/21] x86/io: " Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 14:14 ` Thomas Gleixner 2019-04-05 14:14 ` Thomas Gleixner 2019-04-05 13:59 ` [PATCH v2 08/21] nds32/io: " Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 09/21] m68k/io: " Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 10/21] sh/mmiowb: Add unconditional mmiowb() to arch_spin_unlock() Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 11/21] mips/mmiowb: " Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 12/21] ia64/mmiowb: " Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 13/21] powerpc/mmiowb: Hook up mmwiob() implementation to asm-generic code Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 14/21] riscv/mmiowb: " Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 15/21] Documentation: Kill all references to mmiowb() Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 16/21] drivers: Remove useless trailing comments from mmiowb() invocations Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 17/21] drivers: Remove explicit invocations of mmiowb() Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 15:50 ` Linus Torvalds 2019-04-05 15:50 ` Linus Torvalds 2019-04-09 9:00 ` Nicholas Piggin 2019-04-09 9:00 ` Nicholas Piggin 2019-04-09 13:46 ` Will Deacon 2019-04-09 13:46 ` Will Deacon 2019-04-10 0:25 ` Nicholas Piggin [this message] 2019-04-10 0:25 ` Nicholas Piggin 2019-04-05 13:59 ` [PATCH v2 18/21] scsi/qla1280: Remove stale comment about mmiowb() Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 19/21] i40iw: Redefine i40iw_mmiowb() to do nothing Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 20/21] net/ethernet/silan/sc92031: Remove stale comment about mmiowb() Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 13:59 ` [PATCH v2 21/21] arch: Remove dummy mmiowb() definitions from arch code Will Deacon 2019-04-05 13:59 ` Will Deacon 2019-04-05 15:55 ` [PATCH v2 00/21] Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb()) Linus Torvalds 2019-04-05 15:55 ` Linus Torvalds 2019-04-05 16:09 ` Will Deacon 2019-04-05 16:09 ` Will Deacon 2019-04-05 16:15 ` Linus Torvalds 2019-04-05 16:15 ` Linus Torvalds 2019-04-05 16:30 ` Will Deacon 2019-04-05 16:30 ` Will Deacon
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=1554855359.817ryayv8z.astroid@bobo.none \ --to=npiggin@gmail.com \ --cc=akiyks@gmail.com \ --cc=andrea.parri@amarulasolutions.com \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=dalias@libc.org \ --cc=dhowells@redhat.com \ --cc=dlustig@nvidia.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=macro@linux-mips.org \ --cc=mcgrof@kernel.org \ --cc=mingo@kernel.org \ --cc=mpatocka@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=palmer@sifive.com \ --cc=paul.burton@mips.com \ --cc=paulmck@linux.ibm.com \ --cc=peterz@infradead.org \ --cc=stern@rowland.harvard.edu \ --cc=tony.luck@intel.com \ --cc=torvalds@linux-foundation.org \ --cc=will.deacon@arm.com \ --cc=ysato@users.sourceforge.jp \ /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.