[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] oxenstored memory leak? seems related with XSA-38



On Tue, 2013-07-16 at 10:56 +0100, David Scott wrote:
> On 16/07/13 10:46, Ian Campbell wrote:
> > On Mon, 2013-07-15 at 13:13 +0100, David Scott wrote:
> >> Hi,
> >>
> >> On 05/07/13 10:07, Liuqiming (John) wrote:
> >>>
> >>> Here is my patch that try to fix this issue.
> >>>
> >>> The whole idea is: add check logic when read from IO ring, and if error 
> >>> happens mark the reading connection as "bad",
> >>> Unless vm reboot, oxenstored will not handle message from this connection 
> >>> any more.
> >>
> >> I think detecting a bad client and avoiding wasting CPU time on it is a
> >> good idea. Is this patch working well for you in your testing?
> >>
> >> In future I wonder whether we should add some form of request
> >> rate-limiting in addition to the per-domain quotas, to prevent one
> >> domain from taking more than it's fair share of xenstored time. I
> >> imagine that a non-malicious domain can still keep xenstored busy with
> >> 'legitimate' traffic (although hopefully it still provides services to
> >> other guests, albeit more slowly)
> >
> > Is this an Ack for this patch, or (leaving aside future work) would you
> > like to see changes before it gets applied?
> 
> I'm happy with this current patch for now, so
> 
> Acked-by: David Scott <dave.scott@xxxxxxxxxxxxx>

Thanks.

John -- Please could you resubmit with a proper changelog and a
Signed-off-by indicating that you agree to the Developer's Certificate
of Origin (described in
http://wiki.xen.org/wiki/Submitting_Xen_Patches). Please include Dave's
ack as well (after your S-o-b).

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.