Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.10.17 at 18:43, <ian.jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when 
> unpacking initrd fails"):
>> On 16.10.17 at 17:45, <ian.jackson@xxxxxxxxxxxxx> wrote:
>> > Is there no way to tell that a kernel supports gzipped initrds by
>> > looking at the kernel ?
>> 
>> Well, Linux kernels have config options controlling their ability. So
>> even a modern kernel _could_ be configured to require unzipping.
>> I didn't check whether they announce this anywhere outside the
>> (possibly) embedded .config, but even if they did this would be
>> only Linux then. A solution here shouldn't really be OS-specific imo.
> 
> I guess I was hoping for an ELF note or some multiboot protocol
> element or something.  If it doesn't exist then your proposed general
> approach is probably best.
> 
> I'm afraid I still find the patch less clear than it could be.
> The new semantics of xc_dom_ramdisk_check_size are awkward.  And
> looking at it briefly, I think it might be possible to try the unzip
> even if the size is too large.

I don't think so - xc_dom_ramdisk_check_size() returns 1
whenever decompressed size is above the limit. What I do
admit is that in the case compressed size is larger than
uncompressed size, with the boundary being in between, and
with decompression failing, we may accept something that's
above the limit. Not sure how bad that is though, as the limit
is pretty arbitrary anyway.

> I think a sensible implementation is might have to have a flag
> variable to control "try doing it raw".  And it might be bdest to
> replace xc_dom_ramdisk_check_size with either a function which does
> not bomb out if the limit is exceeded.
> 
> What you are really trying to do here is to pursue two strategies in
> parallel.  And ideally they would not be entangled.

I would have wanted to do things in sequence rather than in
parallel. I can't see how that could work though, in particular
when considering the case mentioned above (uncompressed size
smaller than compressed) - as the space allocation in the guest
can't be reverted, I need to allocate the larger of the two sizes
anyway.

> Maybe there would have to be a comment.

That would be doable, obviously.

> Each of the strategies must rely only on
> functions which don't bomb out, to achieve that.

I'm not sure I understand what "bomb out" is supposed to
mean here. I first thought you meant calls to xc_dom_panic(),
but now I don't think that's what you would mean here (the
more that I'm not introducing that behavior of the function).

So what about Andrew's suggestion of leaving the initrd alone
unconditionally?

Jan


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