On Thu, 2010-08-26 at 09:32 +0200, Lukas Kolbe wrote: Hi,
> > > I was finally able to identify the patch series that introduced the fix > > > (they were introduced to -stable in 2.6.33.2): > > > > > > cb63112 net: add __must_check to sk_add_backlog > > > a12a9a2 net: backlog functions rename > > > 51c5db4 x25: use limited socket backlog > > > c531ab2 tipc: use limited socket backlog > > > 37d60aa sctp: use limited socket backlog > > > 9b3d968 llc: use limited socket backlog > > > 230401e udp: use limited socket backlog > > > 20a92ec tcp: use limited socket backlog > > > ab9dd05 net: add limit for socket backlog > > > > > > After applying these to 2.6.32.17, I wasn't able to trigger the failure > > > anymore. > > > > What "failure"? > > > > > 230401e didn't apply cleanly with git cherry-pick on top of 2.6.32.17, > > > so there might be some additional work needed. > > > > > > @Greg: would it be possible to have these fixes in the next 2.6.32? See > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592187#69 for details: > > > they fix a guest network crash during heavy nfs-io using virtio. > > > > These are a lot of patches, looking like they are adding a new feature. > > I would need to get the ack of the network maintainer before I can add > > them. > > > > David? > > I don't mean to nag (hm well, maybe I do) and I know you were busy > preparing the guard-page fixes, but what's the status of this? In the > meantime, we triggered this bug also on barebone hardware using nfs over > tcp with default [rw]sizes of about 1MiB. On the real hardware, the > kernel oopsed, not only the network stack ... > > With these patches applied, everything works smoothly. I'd really love > to see a stable 2.6.32 ... Is there anything I can do to help reaching a decision with this issue? Regards, Lukas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org