Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
In-Reply-To: <20200729111120.GA2638@hirez.programming.kicks-ass.net>
References: <20200729111120.GA2638@hirez.programming.kicks-ass.net> <20200721195132.GJ10769@hirez.programming.kicks-ass.net> <202006142054.C00B3E9C9@keescook> <20200612183450.4189588-1-keescook@chromium.org> <7be4d56b-0406-099b-e505-02e074c5173e@huawei.com> <544539.1595328664@warthog.procyon.org.uk> <202007211144.A68C31D@keescook> <3211866.1595933798@warthog.procyon.org.uk>
To:     peterz@infradead.org
Cc:     dhowells@redhat.com, Kees Cook <keescook@chromium.org>,
        Xiaoming Ni <nixiaoming@huawei.com>,
        David Windsor <dwindsor@gmail.com>,
        Hans Liljestrand <ishkamiel@gmail.com>,
        Elena Reshetova <elena.reshetova@intel.com>,
        Paul Moore <paul@paul-moore.com>, edumazet@google.com,
        paulmck@kernel.org, shakeelb@google.com,
        James Morris <jamorris@linux.microsoft.com>,
        alex.huangjianhui@huawei.com, dylix.dailei@huawei.com,
        chenzefeng2@huawei.com, linux-kernel@vger.kernel.org,
        Will Deacon <will@kernel.org>
Subject: Re: [RFC][PATCH] locking/refcount: Provide __refcount API to obtain the old value
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4041519.1596055297.1@warthog.procyon.org.uk>
Date:   Wed, 29 Jul 2020 21:41:37 +0100
Message-ID: <4041520.1596055297@warthog.procyon.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

peterz@infradead.org wrote:

> I'm not entirely sure what you mean with interpret, provided you don't
> trigger a refcount fail, the number will be just what you expect and
> would get from refcount_read(). If you do trigger a fail, you'll get a
> negative value.

That's fine.  I seem to remember talk about the possibility that the number
wouldn't necessarily bottom out at zero - for instance if it was arranged such
that the overflow flag was set on an overflow or underflow so that it could be
trapped on (using INTO or TRAPV, for example).

David