On Mon, Feb 04, 2019 at 03:07:26PM -0500, Chuck Lever wrote: > > > > On Feb 4, 2019, at 3:00 PM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Mon, Feb 04, 2019 at 02:49:11PM -0500, Chuck Lever wrote: > >> > >> > >>> On Feb 4, 2019, at 2:46 PM, bfields@xxxxxxxxxxxx wrote: > >>> > >>> On Fri, Feb 01, 2019 at 02:58:14PM -0500, Chuck Lever wrote: > >>>> The key action of xdr_buf_trim() is that it shortens buf->len, the > >>>> length of the xdr_buf' content. The other actions -- shortening the > >>>> head, pages, and tail components -- are actually not necessary. In > >>>> some cases, changing the size of those components corrupts the RPC > >>>> message contained in the buffer. > >>> > >>> That's really burying the lede.... Is there an actual user-visible bug > >>> here? > >> > >> I don't think so. This is more of the form: > >> > >> a) the function does fundamentally the wrong thing, so > >> > >> b) certain changes to this code path result is unexpected and incorrect > >> behavior > >> > >> Thus typically only developers hacking on this code run into a problem. > > > > OK, got it. It'd help just to make it clear in the changelog that that > > this is an accident waiting to happen rather than a current bug (as far > > as we know). > > With said improvement to the changelog, can I add your Acked-by > when I submit this through Anna's tree? Sure, thanks. --b.
