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
| ||
|
Date: Tue, 17 Nov 2020 17:38:39 +0000 From: Matthew Wilcox <willy@...radead.org> To: Shuah Khan <skhan@...uxfoundation.org> Cc: corbet@....net, keescook@...omium.org, gregkh@...uxfoundation.org, peterz@...radead.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v2 01/13] seqnum_ops: Introduce Sequence Number Ops On Tue, Nov 17, 2020 at 09:34:24AM -0700, Shuah Khan wrote: > > seqnum_inc() should just return the new value -- seqnum_inc_return is > > too verbose. And do we not need a seqnum_add()? > > I had the patch series with seqnum_inc() all ready to go and then > revisited the choice. My thinking is that matching the current atomic > api that has _inc() and inc_return() might be less confusing. That No, it's more confusing. I know you're converting things from using atomic_t, but you really need to think about this in terms of "What makes sense for this API". Unless you really want to have inc that returns void and inc_return that returns the new value, having only inc_return makes no sense. > being said, I have no problems with making just _inc(). The reason > for 32 and 64 appended is based on comments that it including size > in the api makes it very clear. By putting 32 and 64 in the name of the API, I would contend you're making people think about something that they should not need to think about. > No need for atomic_add() - inc_return() is sufficient for this use-case. I haven't looked at the various potential users of this API, but there are often cases where we account, eg, number of bytes transmitted. There are also cases where read-and-zero would be a useful operation to have. I'm thinking about sampling statistics.
Powered by blists - more mailing lists