Re: [Xen-devel] linux 4.19 xenstore memory allocation failure Re: [linux-4.19 test] 135420: regressions - FAIL

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Apr 30, 2019 at 03:33:00PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] linux 4.19 xenstore memory allocation 
> failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> > On 30.04.19 at 15:02, <ian.jackson@xxxxxxxxxx> wrote:
> > > ISTM that there are *two* bugs here:
> > > 
> > >  1. Whatever caused the memory allocation failure
> > 
> > An order-5 allocation is set to fail at any time (afaict). I find it
> > surprising that struct blkfront_ring_info instances (even arrays
> > of them when using multiple rings) get allocated using kcalloc()
> > rather than kvcalloc(), considering the size of the structure
> > (0x140E0 according to the disassembly of the 5.0.1 driver I
> > had to hand).
> 
> I will leave answering this to the blkfront/linux folks...

I think those allocations used to be small enough that kcalloc was
likely fine. Now with multiple rings, and multiple pages per ring
those have grown to a point where kcalloc is not fine anymore. I will
prepare a patch to switch to kvcalloc.

> > >  2. That a memory allocation failure can cause permanent loss of a
> > >      xenstore watch event
> > 
> > Well, isn't it sort of expected that an allocation failure will lead
> > to further problems?
> 
> I would have hoped that it would result in something other than a
> hang.  At worst, blkfront ought to go into a state where it *knows*
> that it is utterly broken and reports this properly.

I haven't yet checked all the possible error paths, but the ones I've
looked at use xenbus_dev_fatal which switches the device state to
closing and writes the error message into xenstore. However closing
state is not an error state, and can be used as part of the normal
flow of a PV device (for example in order to force a reconnection).

I don't think there's a documented way of reporting an unrecoverable
PV frontend error, but I might be mistaken.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel