On Wed, Aug 17, 2016 at 01:43:00PM +0200, Alexander Bluhm wrote: > On Sat, Aug 13, 2016 at 10:59:30AM +0200, Claudio Jeker wrote: > > to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in > > the same function. I see no point in not waiting for a cluster and instead > > chain lots of mbufs together as a consequence. > > The M_WAIT reverts this bugfix: > > ---------------------------- > revision 1.72 > date: 2008/08/07 17:43:37; author: reyk; state: Exp; lines: +2 -2; > don't wait for a free mbuf cluster in sosend() and enter the existing > error handler that was never used before. this fixes a bug that a > userland process might hang if the system ran out of mbuf clusters or > even other unexpected behaviour in the network drivers. > > this bug is very old - it is also found in rev 1.1/stevens v2/44lite2/... > > discussed with many > ok markus@ thib@ dlg@ > ---------------------------- > > First I was also wondering about the M_NOWAIT in process context. > But with the explanation in the commit message it makes sense. Even > if you still think it must be changed, please do it in a spearate > commit and discussion. > > Apart from this OK bluhm@
fair enough. after it is in i do believe it is safe to change it to M_WAITOK. the reason is that pools now keep track of things that are sleeping for memory and will give them an item BEFORE waking them up. previously i believe they were woken up to try and get an item, which could fail as you described because interrupt load could starve sleepers before the wakeup actually happens. mbufs and clusters are allocated out of pools, so they now inherit this behaviour. dlg
