[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] fix misc issues related toallowingsupport of more CPUs
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 22.09.08 16:02 >>> >On 22/9/08 09:35, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote: > >> On 22/9/08 08:46, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote: >> >>>> Why must it be WARN_ON()? You think you could specify strings so long that >>>> they overflow 32 bits? You've got other problems in that case. >>> >>> No, that's not the reason. It's because of how bitmap_scnprintf() and >>> bitmap_scnlistprintf() work - they can (validly, assuming that the code >>> having been derived from Linux and still being that way in Linux, hence >>> apparently considered correct) pass negative sizes to scnprintf(), and >>> hence it must not kill the system to actually do so. >> >> The obvious answer would be to fix the bogus callers. Or consider negative >> size to be a valid input. Warning on what callers consider valid behaviour >> is just weird. I would say the former (fix the callers) is the better way to >> go here; presumably they just need to clamp the size parameter. > >Further to this, actually I think the callers in bitmap.c are correct. >Assuming len<=buflen at the start of the bitmap_scn*() functions (valid >since buflen is non-negative and len == 0 at function start) then we'll >never have len>buflen because scnprintf() truncates its return value to be >less than its size parameter, which is always buflen-len. Ah, right - while I looked at this difference to snprintf(), I then forgot about it again. Thanks for spotting and clarifying, Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |