lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20171227143850.nnuatshhezurbu7r@ltop.local> Date: Wed, 27 Dec 2017 15:38:50 +0100 From: Luc Van Oostenryck <luc.vanoostenryck@...il.com> To: Matthew Wilcox <willy@...radead.org> Cc: Josh Triplett <josh@...htriplett.org>, Ross Zwisler <ross.zwisler@...ux.intel.com>, linux-kernel@...r.kernel.org, Dave Hansen <dave.hansen@...el.com>, linux-mm@...ck.org, Matthew Wilcox <mawilcox@...rosoft.com>, linux-sparse@...r.kernel.org Subject: Re: [PATCH 2/2] Introduce __cond_lock_err On Sat, Dec 23, 2017 at 05:06:21AM -0800, Matthew Wilcox wrote: > On Sat, Dec 23, 2017 at 01:39:11AM -0800, Josh Triplett wrote: > > +linux-sparse > > Ehh ... we've probably trimmed too much to give linux-sparse a good summary. > > Here're the important lines from my patch: > > +# define __cond_lock_err(x,c) ((c) ? 1 : ({ __acquire(x); 0; })) > > + return __cond_lock_err(*ptlp, __follow_pte_pmd(mm, address, start, end, > + ptepp, pmdpp, ptlp)); > > This is supposed to be "If "c" is an error value, we don't have a lock, > otherwise we have a lock". And to translate from linux-speak into > sparse-speak: > > # define __acquire(x) __context__(x,1) > > Josh & Ross pointed out (quite correctly) that code which does something like > > if (foo()) > return; > > will work with this, but code that does > > if (foo() < 0) > return; > > will not because we're now returning 1 instead of -ENOMEM (for example). > > So they made the very sensible suggestion that I change the definition > of __cond_lock to: > > # define __cond_lock_err(x,c) ((c) ?: ({ __acquire(x); 0; })) > > Unfortunately, when I do that, the context imbalance warning returns. > As I said below, this is with sparse 0.5.1. I think this __cond_lock_err() is now OK (but some comment about how its use is different from __cond_lock() would be welcome). For the context imbalance, I would really need a concrete example to be able to help more because it depends heavily on what the test is and what code is before and after. If you can point me to a tree, a .config and a specific warning, I'll be glad to take a look. -- Luc Van Oostenryck
Powered by blists - more mailing lists