Re: [Xen-users] kernel 3.9.2 - xen 4.2.2/4.3rc1 => BUG unable to handle kernel paging request netif_poll+0x49c/0xe8

["Jan Beulich" <JBeulich@suse.com>]

>>> On 17.05.13 at 15:00, Eugene Istomin <e.istomin@edss.ee> wrote:
> Bump, here it is:

Okay, but I think we're still lacking information on what your
Dom0 kernel is.

Ian, Wei - looking at the forward ported as well as the upstream
frontends, I'm wondering if there isn't a fundamental flaw in
..._get_responses(): It allows up to MAX_SKB_FRAGS + 1 slots/
frags, and ..._fill_frags() then fills as many fragments as got
queued onto the respective list. Only after both of them are done,
__pskb_pull_tail() gets invoked reducing the fragment count by
one if the condition is met that made ..._get_responses() bump
the limit by one.

Am I overlooking something? I'm asking because working through
disassembly and register values of the dump Eugene had sent I
clearly see that ..._fill_frags() is processing the 18th fragment,
while in that kernel version MAX_SKB_FRAGS is only 17 (but
possibly, hence the first question above, the Dom0 kernel still is
one with MAX_SKB_FRAGS being 18, or the packet turns out to
be such that it fills 17 fragments and the header is smaller than
RX_COPY_THRESHOLD).

Jan