linux-kernel - RE: [PATCH 01/15] sched: convert sighand_struct.count to refcount

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 23 Oct 2017 10:45:35 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     "mingo@...hat.com" <mingo@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "tj@...nel.org" <tj@...nel.org>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        "lizefan@...wei.com" <lizefan@...wei.com>,
        "acme@...nel.org" <acme@...nel.org>,
        "alexander.shishkin@...ux.intel.com" 
        <alexander.shishkin@...ux.intel.com>,
        "eparis@...hat.com" <eparis@...hat.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "luto@...nel.org" <luto@...nel.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "dvhart@...radead.org" <dvhart@...radead.org>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "axboe@...nel.dk" <axboe@...nel.dk>
Subject: RE: [PATCH 01/15] sched: convert sighand_struct.count to refcount_t

> On Mon, 23 Oct 2017, Reshetova, Elena wrote:
> > > On Fri, 20 Oct 2017, Elena Reshetova wrote:
> > > How did you make sure that these atomic operations have no other
> > > serialization effect and can be replaced with refcount?
> >
> > What serialization effects? Are you taking about smth else than memory
> > ordering?
> 
> Well, the memory ordering constraints can be part of serialization
> mechanisms. Unfortunately they are not well documented ....

Would you be able to point to any documentation or examples of this?
I would be happy to understand more, it is really not smth very straightforward.

The reason I also don't want to confuse people even more with this ordering issue
is that it can be different if you use arch. specific implementation vs. arch. independent.
So, it is not as simple as to say "refcount_t would always result in weak memory ordering",
it really depends what REFCOUNT config option is "on", what arch. you are running on etc.
Nothing to add is that by default refount_t = atomic_t unless you start enabling
the related configs...

> 
> > For memory ordering my current hope is that we can just make refcount_t
> > to use same strict atomic primitives and then it would not make any
> > difference.  I think this would be the simplest way for everyone since I
> > think even some maintainers are having issues understanding all the
> > implications of "relaxed" ordering.
> 
> Well, that would make indeed the conversion simpler because then it is just
> a drop in replacement. Albeit there might be some places which benefit of
> the relaxed ordering as on some architectures strict ordering is expensive.

Well refcount_t was not meant to provide any other benefits from atomic_t apart from
better security guarantees and potentially better written code (less possibilities to do smth
stupid with a smaller API). If someone really have an issue with speed, they should be enabling
arch. specific refcount_t implementation for their arch. anyway and then it is hopefully does
it the best possible/faster way. 

Best Regards,
Elena.

> 
> Thanks,
> 
> 	tglx