[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1285036359.17389.1568914389549.JavaMail.zimbra@efficios.com>
Date: Thu, 19 Sep 2019 13:33:09 -0400 (EDT)
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Will Deacon <will@...nel.org>
Cc: Michael Kerrisk <mtk.manpages@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
paulmck <paulmck@...ux.ibm.com>, Ingo Molnar <mingo@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Russell King, ARM Linux" <linux@...linux.org.uk>,
Chris Metcalf <cmetcalf@...hip.com>,
Chris Lameter <cl@...ux.com>, Kirill Tkhai <tkhai@...dex.ru>,
Mike Galbraith <efault@....de>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH 4/4] Fix: sched/membarrier: p->mm->membarrier_state
racy load (v2)
----- On Sep 19, 2019, at 12:26 PM, Will Deacon will@...nel.org wrote:
[...]
>>
>> The current wording from membarrier(2) is:
>>
>> The "expedited" commands complete faster than the non-expedited
>> ones; they never block, but have the downside of causing extra
>> overhead.
>>
>> We could simply remove the "; they never block" part then ?
>
> I think so, yes. That or, "; they do not voluntarily block" or something
> like that. Maybe look at other man pages for inspiration ;)
OK, let's tackle the man-pages part after the fix reaches mainline though.
[...]
>
> I reckon you'll be fine using GFP_KERNEL and returning -ENOMEM on allocation
> failure. This shouldn't happen in practice and it removes the fallback
> path.
Works for me! I'll prepare an updated patchset.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Powered by blists - more mailing lists