search for: idr

Hi, I have the following data: > data[1:20,c(1,2,20)] idr schyear year 1 8 0 1 9 1 1 10 NA 2 4 NA 2 5 -1 2 6 0 2 7 1 2 8 2 2 9 3 2 10 4 2 11 NA 2 12 6 3 4 NA 3 5 -2 3 6 -1 3 7 0 3 8 1 3 9 2 3 10 3...

The <linux/bug.h> was removed from radix-tree.h by the following commit: f5bba9d11a256ad2a1c2f8e7fc6aabe6416b7890. Since that commit, tools/testing/radix-tree/ couldn't pass compilation due to: tools/testing/radix-tree/idr.c:17: undefined reference to WARN_ON_ONCE. This patch adds the bug.h header to idr.h to solve the issue. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Cc: Matthew Wilcox <mawilcox at microsoft.com> Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Jan Kara <jack at suse...

On Wed, 28 Aug 2013 13:44:54 -0700 Kent Overstreet <kmo at daterainc.com> wrote: > > > > What guarantees that this wait will terminate? > > > > > > It seems fairly clear to me from the break statement a couple lines up; > > > if we were passed __GFP_WAIT we terminate iff we succesfully allocated a > > > tag. If we weren't passed

On Wed, 28 Aug 2013 13:44:54 -0700 Kent Overstreet <kmo at daterainc.com> wrote: > > > > What guarantees that this wait will terminate? > > > > > > It seems fairly clear to me from the break statement a couple lines up; > > > if we were passed __GFP_WAIT we terminate iff we succesfully allocated a > > > tag. If we weren't passed

...9, 2017 at 09:55:17PM +0800, Wei Wang wrote: > The <linux/bug.h> was removed from radix-tree.h by the following commit: > f5bba9d11a256ad2a1c2f8e7fc6aabe6416b7890. > > Since that commit, tools/testing/radix-tree/ couldn't pass compilation > due to: tools/testing/radix-tree/idr.c:17: undefined reference to > WARN_ON_ONCE. This patch adds the bug.h header to idr.h to solve the > issue. Thanks; I sent this same patch out yesterday. Unfortunately, you didn't cc the author of this breakage, Masahiro Yamada. I want to highlight that these kinds of header cleanups a...

...9, 2017 at 09:55:17PM +0800, Wei Wang wrote: > The <linux/bug.h> was removed from radix-tree.h by the following commit: > f5bba9d11a256ad2a1c2f8e7fc6aabe6416b7890. > > Since that commit, tools/testing/radix-tree/ couldn't pass compilation > due to: tools/testing/radix-tree/idr.c:17: undefined reference to > WARN_ON_ONCE. This patch adds the bug.h header to idr.h to solve the > issue. Thanks; I sent this same patch out yesterday. Unfortunately, you didn't cc the author of this breakage, Masahiro Yamada. I want to highlight that these kinds of header cleanups a...

Fixup patch, addressing Andrew's review feedback: Signed-off-by: Kent Overstreet <kmo at daterainc.com> --- include/linux/idr.h | 2 +- lib/idr.c | 38 +++++++++++++++++++++----------------- 2 files changed, 22 insertions(+), 18 deletions(-) diff --git a/include/linux/idr.h b/include/linux/idr.h index f0db12b..cdf39be 100644 --- a/include/linux/idr.h +++ b/include/linux/idr.h @@ -267,7 +267,7 @@ struct percpu_...

...gt; explicitly documented in a place where future readers will see them!) *nod* I suppose it should be said explicitly that the gfp_t parameter indicates whether or not to wait until a _tag_ is available, and not some internal memory allocation or something. How's this look? diff --git a/lib/idr.c b/lib/idr.c index 15c021c..a3f8e9a 100644 --- a/lib/idr.c +++ b/lib/idr.c @@ -1288,6 +1288,11 @@ static inline unsigned alloc_local_tag(struct percpu_ida *pool, * Safe to be called from interrupt context (assuming it isn't passed * __GFP_WAIT, of course). * + * @gfp indicates whether or...

...will eventually get the down cpu's tags. We _could_ satisfy > more allocations if we had a notifier - but we'll still meet our > guarantees and it's absolutely not a correctness issue, so I don't think > it's worth the extra code. > > ... > > include/linux/idr.h | 53 +++++++++ > lib/idr.c | 316 +++++++++++++++++++++++++++++++++++++++++++++++++-- I don't think this should be in idr.[ch] at all. It has no relationship with the existing code. Apart from duplicating its functionality :( > > ... > > @@ -243,4 +245,55 @@ s...

...will eventually get the down cpu's tags. We _could_ satisfy > more allocations if we had a notifier - but we'll still meet our > guarantees and it's absolutely not a correctness issue, so I don't think > it's worth the extra code. > > ... > > include/linux/idr.h | 53 +++++++++ > lib/idr.c | 316 +++++++++++++++++++++++++++++++++++++++++++++++++-- I don't think this should be in idr.[ch] at all. It has no relationship with the existing code. Apart from duplicating its functionality :( > > ... > > @@ -243,4 +245,55 @@ s...

...dation.org> Cc: Ingo Molnar <mingo at redhat.com> Cc: Andi Kleen <andi at firstfloor.org> Cc: Jens Axboe <axboe at kernel.dk> Cc: "Nicholas A. Bellinger" <nab at linux-iscsi.org> Signed-off-by: Nicholas Bellinger <nab at linux-iscsi.org> --- include/linux/idr.h | 53 +++++++++ lib/idr.c | 316 +++++++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 361 insertions(+), 8 deletions(-) diff --git a/include/linux/idr.h b/include/linux/idr.h index 871a213..f0db12b 100644 --- a/include/linux/idr.h +++ b/include/linux/idr.h @@ -16,6 +...

...WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * eXtensible Bitmaps provide an unlimited-size sparse bitmap facility. + * All bits are initially zero. + */ + +#include <linux/idr.h> + +struct xb { + struct radix_tree_root xbrt; +}; + +#define XB_INIT { \ + .xbrt = RADIX_TREE_INIT(IDR_RT_MARKER | GFP_NOWAIT), \ +} +#define DEFINE_XB(name) struct xb name = XB_INIT + +static inline void xb_init(struct xb *xb) +{ + INIT_RADIX_TREE(&xb->xbrt, IDR_RT_MARKER | GF...

...WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * eXtensible Bitmaps provide an unlimited-size sparse bitmap facility. + * All bits are initially zero. + */ + +#include <linux/idr.h> + +struct xb { + struct radix_tree_root xbrt; +}; + +#define XB_INIT { \ + .xbrt = RADIX_TREE_INIT(IDR_RT_MARKER | GFP_NOWAIT), \ +} +#define DEFINE_XB(name) struct xb name = XB_INIT + +static inline void xb_init(struct xb *xb) +{ + INIT_RADIX_TREE(&xb->xbrt, IDR_RT_MARKER | GF...

On 12/22/2017 05:03 AM, Matthew Wilcox wrote: > OK, here's a rewrite of xbitmap. > > Compared to the version you sent: > - xb_find_set() is the rewrite I sent out yesterday. > - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find > clear bits. This led to me finding a bug in radix_tree_for_each_tagged(). > - xb_zero() is also a new implementation (replacing xb_clear_bit_range). > It should also be more efficient in deep trees. > - Did not accept your change to xb_set_bit(); I think...

On 12/22/2017 05:03 AM, Matthew Wilcox wrote: > OK, here's a rewrite of xbitmap. > > Compared to the version you sent: > - xb_find_set() is the rewrite I sent out yesterday. > - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find > clear bits. This led to me finding a bug in radix_tree_for_each_tagged(). > - xb_zero() is also a new implementation (replacing xb_clear_bit_range). > It should also be more efficient in deep trees. > - Did not accept your change to xb_set_bit(); I think...

On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote: > +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v) > +{ > + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1, > + GFP_KERNEL); > +} Please don't use idr in new code, use xarray directly > +static int vhost_vdpa_probe(struct device *dev) > +{ > + struct vdpa_device *vdpa = dev_to_vdpa(dev); > + const struct vdpa_config_ops *ops = vdp...

On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote: > +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v) > +{ > + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1, > + GFP_KERNEL); > +} Please don't use idr in new code, use xarray directly > +static int vhost_vdpa_probe(struct device *dev) > +{ > + struct vdpa_device *vdpa = dev_to_vdpa(dev); > + const struct vdpa_config_ops *ops = vdp...

...har *)(FSYS_BUF + 6144)) -#define NAME_BUF ((unsigned char *)(FSYS_BUF + 8192)) +#define RRCONT_BUF ((char *)(FSYS_BUF + 6144)) +#define NAME_BUF ((char *)(FSYS_BUF + 8192)) #define log2 grub_log2 @@ -207,7 +207,7 @@ iso9660_dir (fsi_file_t *ffi, char *dirn rr_len = (idr->length.l - idr->name_len.l - sizeof(struct iso_directory_record) + sizeof(idr->name)); - rr_ptr.ptr = ((unsigned char *)idr + idr->name_len.l + rr_ptr.ptr = ((char *)idr + idr->name_len.l + sizeof(struct iso_directory_record) - sizeof(idr->name...

On Wed, Sep 16, 2015 at 07:29:17PM -0500, Suman Anna wrote: > The virtio core uses a static ida named virtio_index_ida for > assigning index numbers to virtio devices during registration. > The ida core may allocate some internal idr cache layers and > an ida bitmap upon any ida allocation, and all these layers are > truely freed only upon the ida destruction. The virtio_index_ida > is not destroyed at present, leading to a memory leak when using > the virtio core as a module and atleast one virtio device is > re...

On Wed, Sep 16, 2015 at 07:29:17PM -0500, Suman Anna wrote: > The virtio core uses a static ida named virtio_index_ida for > assigning index numbers to virtio devices during registration. > The ida core may allocate some internal idr cache layers and > an ida bitmap upon any ida allocation, and all these layers are > truely freed only upon the ida destruction. The virtio_index_ida > is not destroyed at present, leading to a memory leak when using > the virtio core as a module and atleast one virtio device is > re...