search for: range_start

Hi everyone, It seems like every time I want to evaluate a possibly undefined variable I have to use defined? to see that it exists first, so I can''t simply have -- if params[:range_start] > 3 or something like it. I need to have -- if defined? params[:range_start] && params[:range_start] > 3 I can''t even have -- if params[:range_start].nil? This is really annoying - is there anyway to avoid this? Thanks, Daniel Higginbotham

...eval (eval.c:461) ==32503== by 0x8160DA7: do_begin (eval.c:1174) ==32503== by 0x815F0EB: Rf_eval (eval.c:461) ==32503== by 0x8162210: Rf_applyClosure (eval.c:667) The leaked blocks are allocated in iinternal_function build_range_exp() at 5200 /* Use realloc since mbcset->range_starts and mbcset->range_ends 5201 are NULL if *range_alloc == 0. */ 5202 new_array_start = re_realloc (mbcset->range_starts, wchar_t, 5203 new_nranges); 5204 new_array_end = re_realloc (mbcset->range_e...

...: 12,599,585 bytes in 5,915 blocks. ==28643== suppressed: 0 bytes in 0 blocks. ==28643== Reachable blocks (those to which a pointer was found) are not shown. ==28643== To see them, rerun with: --show-reachable=yes The flagged memory block is the range_ends component of mbcset. I think that range_starts was also being leaked, but valgrind was combining the two. It looks like the cpp macro _LIBC is not defined when I compile R in this Linux box. regex.c defines range_ends and range_starts as different types, depending on the value of _LIBC, and it allocates space for them in either case. Howev...

...=> ''255'', :octet2 => ''255'', :octet3 => ''254'', :octet4 => ''0'' }, :range_start => ''10'', :range_end => ''100''} assert_response :success puts NetworkSegment.find(:all).size end It seems that creating a new network_segment in my test is not working. Yet, I am not sure why. $ ruby test/funct...

...locks. > ==28643== suppressed: 0 bytes in 0 blocks. > ==28643== Reachable blocks (those to which a pointer was found) are not shown. > ==28643== To see them, rerun with: --show-reachable=yes > > The flagged memory block is the range_ends component of mbcset. > I think that range_starts was also being leaked, but valgrind was > combining the two. > > It looks like the cpp macro _LIBC is not defined when I compile > R in this Linux box. regex.c defines range_ends and range_starts > as different types, depending on the value of _LIBC, and it allocates > space for...

...format; @@ -298,7 +309,7 @@ set_integer: if (ch == '^' && !(flags & FL_INV)) { matchinv = 1; } else { - set_bit((unsigned char)ch, matchmap); + set_bit(matchmap, (unsigned char)ch); state = st_match; } break; @@ -310,18 +321,18 @@ set_integer: range_start = (unsigned char)ch; state = st_match_range; } else { - set_bit((unsigned char)ch, matchmap); + set_bit(matchmap, (unsigned char)ch); } break; case st_match_range: /* %[ match after - */ if (ch == ']') { - set_bit((unsigned char)'-', matchmap); /* -...

...c_cpu_device_pagetables)(struct hmm_mirror *mirror, - const struct hmm_update *update); + const struct mmu_notifier_range *update); }; /* diff --git a/mm/hmm.c b/mm/hmm.c index 16b6731a34db..b810a4fa3de9 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -165,7 +165,6 @@ static int hmm_invalidate_range_start(struct mmu_notifier *mn, { struct hmm *hmm = container_of(mn, struct hmm, mmu_notifier); struct hmm_mirror *mirror; - struct hmm_update update; struct hmm_range *range; unsigned long flags; int ret = 0; @@ -173,15 +172,10 @@ static int hmm_invalidate_range_start(struct mmu_notifier *mn,...

...ld break or continue, it doesn't much matter how to recover from a broken driver, but since we did the WARN_ON this should sanitize the ret to EAGAIN or 0 Humm. Actually having looked this some more, I wonder if this is a problem: I see in __oom_reap_task_mm(): if (mmu_notifier_invalidate_range_start_nonblock(&range)) { tlb_finish_mmu(&tlb, range.start, range.end); ret = false; continue; } unmap_page_range(&tlb, vma, range.start, range.end, NULL); mmu_notifier_invalidate_range_end(&range); Which looks like it creates an unbalanced start/end pairing if any s...

...hope its just a stupid >> mistake I just can't spot though. > > This is probably my fault in how I explained things, I seem to have had > a bug in my code. > > Let me try again. > > mas_walk(&mas) will go to the range of mas.index > It will set mas.index = range_start > It will set mas.last = range_end > It will return entry in that range. > > Your code is walking to addr (0xc0000, say) > You get NULL > and the range is now: mas.index = 0, mas.last = ULONG_MAX > > You set mas.last = 0xc0000 + 0x40000 -1 > You store your va in the r...

...vice + * instance). However, we still suggest syncing the + * diff so that we can get within the target range. + */ + s64 nr_to_write = + (!config_pages(vb) ? LONG_MAX : -diff); + struct writeback_control wbc = { + .sync_mode = WB_SYNC_ALL, + .nr_to_write = nr_to_write, + .range_start = 0, + .range_end = LLONG_MAX, + }; + sync_inode(&the_inode.inode, &wbc); + } + update_balloon_size(vb); + } + return 0; +} + +static ssize_t virtballoon_attr_show(struct device *dev, + struct device_attribute *attr, + char *buf); + +static DEVICE_ATTR(total_memory,...

...vice + * instance). However, we still suggest syncing the + * diff so that we can get within the target range. + */ + s64 nr_to_write = + (!config_pages(vb) ? LONG_MAX : -diff); + struct writeback_control wbc = { + .sync_mode = WB_SYNC_ALL, + .nr_to_write = nr_to_write, + .range_start = 0, + .range_end = LLONG_MAX, + }; + sync_inode(&the_inode.inode, &wbc); + } + update_balloon_size(vb); + } + return 0; +} + +static ssize_t virtballoon_attr_show(struct device *dev, + struct device_attribute *attr, + char *buf); + +static DEVICE_ATTR(total_memory,...

...(!config_pages(vb) ? LONG_MAX : -diff); > >> + struct writeback_control wbc = { > >> + .sync_mode = WB_SYNC_ALL, > >> + .nr_to_write = nr_to_write, > >> + .range_start = 0, > >> + .range_end = LLONG_MAX, > >> + }; > >> + sync_inode(&the_inode.inode, &wbc); > >> + } > >> + update_balloon_size(vb); > >> + } &g...

...(!config_pages(vb) ? LONG_MAX : -diff); > >> + struct writeback_control wbc = { > >> + .sync_mode = WB_SYNC_ALL, > >> + .nr_to_write = nr_to_write, > >> + .range_start = 0, > >> + .range_end = LLONG_MAX, > >> + }; > >> + sync_inode(&the_inode.inode, &wbc); > >> + } > >> + update_balloon_size(vb); > >> + } &g...

Main reason for refactor is no ovirt-node-image binary image allowed in fedora. Removed ks files, now in ovirt-node-recipe, which is subpackage of ovirt-node. Removed tools, these are now in ovirt-node-recipe which is subpackage of ovirt-node.

Main reason for refactor is no ovirt-node-image binary image allowed in fedora. Moves tools and kickstart files form ovirt-node-image to subpackage ovirt-node-recipe. Removes old sub packages form ovirt-node, stateless, logos, selinux. Modifies init scripts to meet Fedora packaging guidelines: added status, reload, and lockfile, rhbz: 514221 Added License file.

A character device for accessing (in user-space) pages that have been granted by other domains. Signed-off-by: Derek Murray <Derek.Murray@cl.cam.ac.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others are simple linear search lists. Of the ones I checked they largely seem to have various kinds of races, bugs and poor implementatio...

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others are simple linear search lists. Of the ones I checked they largely seem to have various kinds of races, bugs and poor implementatio...