From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH 2 of 3] xentrace: use tbuf_size for overflow check Date: Tue, 5 Apr 2011 12:19:51 +0200 Message-ID: <20110405101951.GA5943@aepfle.de> References: <3e95e737bc51c2295926.1301508274@localhost> <1301656691.9447.88.camel@elijah> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <1301656691.9447.88.camel@elijah> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap Cc: George Dunlap , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Fri, Apr 01, George Dunlap wrote: > On Wed, 2011-03-30 at 19:04 +0100, Olaf Hering wrote: > > xentrace: use tbuf_size for overflow check > > > > The calculated number of per-cpu trace pages is stored in t_info and > > shared with tools like xentrace. Since its an u16 the value may overflow > > because the current check is based on u32. > > Hmm -- while this is true, it's possible this may change in the future. > If we ever changed t_info.tbuf_size to be u32, then t_buf.prod/cons > would again be the limiting factor. > > Should we perhaps add both checks? I will update the patch to check for both. > > Using the u16 means each cpu could in theory use up to 256MB as trace > > buffer. However such a large allocation will currently fail on x86 due > > to the MAX_ORDER limit. > > FWIW, I don't believe that there's any reason the allocations have to be > contiguous any more. I kept them contiguous to minimize the changes to > the moving parts near a release. But the new system has been pretty > well tested now, so I think looking at non-contiguous allocations may be > worthwhile. This will be a bigger change I think. Added to my todo list. Olaf