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: Sun, 17 Dec 2017 13:47:21 +0000 From: "Wang, Wei W" <wei.w.wang@...el.com> To: Matthew Wilcox <willy@...radead.org>, Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> CC: "virtio-dev@...ts.oasis-open.org" <virtio-dev@...ts.oasis-open.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "qemu-devel@...gnu.org" <qemu-devel@...gnu.org>, "virtualization@...ts.linux-foundation.org" <virtualization@...ts.linux-foundation.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "mst@...hat.com" <mst@...hat.com>, "mhocko@...nel.org" <mhocko@...nel.org>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "mawilcox@...rosoft.com" <mawilcox@...rosoft.com>, "david@...hat.com" <david@...hat.com>, "cornelia.huck@...ibm.com" <cornelia.huck@...ibm.com>, "mgorman@...hsingularity.net" <mgorman@...hsingularity.net>, "aarcange@...hat.com" <aarcange@...hat.com>, "amit.shah@...hat.com" <amit.shah@...hat.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>, "liliang.opensource@...il.com" <liliang.opensource@...il.com>, "yang.zhang.wz@...il.com" <yang.zhang.wz@...il.com>, "quan.xu@...yun.com" <quan.xu@...yun.com>, "nilal@...hat.com" <nilal@...hat.com>, "riel@...hat.com" <riel@...hat.com> Subject: RE: [PATCH v19 3/7] xbitmap: add more operations On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote: > On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: > > Here's the API I'm looking at right now. The user need take no lock; > > the locking (spinlock) is handled internally to the implementation. Another place I saw your comment " The xb_ API requires you to handle your own locking" which seems conflict with the above "the user need take no lock". Doesn't the caller need a lock to avoid concurrent accesses to the ida bitmap? > I looked at the API some more and found some flaws: > - how does xbit_alloc communicate back which bit it allocated? > - What if xbit_find_set() is called on a completely empty array with > a range of 0, ULONG_MAX -- there's no invalid number to return. We'll change it to "bool xb_find_set(.., unsigned long *result)", returning false indicates no "1" bit is found. > - xbit_clear() can't return an error. Neither can xbit_zero(). I found the current xbit_clear implementation only returns 0, and there isn't an error to be returned from this function. In this case, is it better to make the function "void"? > - Need to add __must_check to various return values to discourage sloppy > programming > > So I modify the proposed API we compete with thusly: > > bool xbit_test(struct xbitmap *, unsigned long bit); int __must_check > xbit_set(struct xbitmap *, unsigned long bit, gfp_t); void xbit_clear(struct > xbitmap *, unsigned long bit); int __must_check xbit_alloc(struct xbitmap *, > unsigned long *bit, gfp_t); > > int __must_check xbit_fill(struct xbitmap *, unsigned long start, > unsigned long nbits, gfp_t); void xbit_zero(struct xbitmap *, > unsigned long start, unsigned long nbits); int __must_check > xbit_alloc_range(struct xbitmap *, unsigned long *bit, > unsigned long nbits, gfp_t); > > bool xbit_find_clear(struct xbitmap *, unsigned long *start, unsigned long > max); bool xbit_find_set(struct xbitmap *, unsigned long *start, unsigned > long max); > > (I'm a little sceptical about the API accepting 'max' for the find functions and > 'nbits' in the fill/zero/alloc_range functions, but I think that matches how > people want to use it, and it matches how bitmap.h works) Are you suggesting to rename the current xb_ APIs to the above xbit_ names (with parameter changes)? Why would we need xbit_alloc, which looks like ida_get_new, I think set/clear should be adequate to the current usages. Best, Wei
Powered by blists - more mailing lists