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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan:
> [...] As quite often when changing code I'm not very
> familiar with, I had tried to minimize the amount of changes needed. E.g.
> I did consider dropping xc_dom_ramdisk_check_size() altogether in favor
> of some other function (or even doing what is needed in its only caller),
> but that would have been a larger (both textual and factual) change than
> keeping the function and adding another parameter.

I can see why this seema an attractive approach to unfamiliar code.
But at least in this case I think the results are unsatisfactory.

Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when 
unpacking initrd fails"):
> On 16.10.17 at 18:43, <ian.jackson@xxxxxxxxxxxxx> wrote:
> > 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.

Conceptually what you are trying to do is have two alternative
strategies.  Those two strategies have different limits.  So "the
limit" is not a meaningful concept.

> > 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.

I don't think it can work.  I think you uneed to pursue them in
parallel and keep separate records, for each one, of whether we are
still pursuing it or whether it has failed (and of course its
necessary locals).

> > 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?

That would be a backward incompatible change.  We'd need some kind of
justification to explain why no-one cares about it any more.

Ian.

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