Whoops:
- return __dev_alloc_skb(length, gfp_mask | __GFP_MEMALLOC);
+ return __dev_alloc_skb(length, GFP_ATOMIC|__GFP_MEMALLOC);
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi,
I spent the last day mulling things over and doing research. It seems to me
that the patch as first posted is correct and solves the deadlock, except
that some uses of __GFP_MEMALLOC in __dev_alloc_skb may escape into contexts
where the reserve is not guaranteed to be reclaimed. It may be
On Thursday 04 August 2005 04:21, Martin Josefsson wrote:
> On Thu, 2005-08-04 at 03:36 +1000, Daniel Phillips wrote:
> > I can think of two ways to deal with this:
> >
> > 1) Mindlessly include the entire maximum memory usage of the rx-ring in
> > the reserve requirement (e.g., (maxskbs * (
On Thu, 2005-08-04 at 03:36 +1000, Daniel Phillips wrote:
> I can think of two ways to deal with this:
>
> 1) Mindlessly include the entire maximum memory usage of the rx-ring in
> the reserve requirement (e.g., (maxskbs * (MTU + k)) / PAGE_SIZE).
Would be dependent on the numberof interf
On Wednesday 03 August 2005 16:59, Martin Josefsson wrote:
> On Wed, 3 Aug 2005, Daniel Phillips wrote:
> > Hi,
> >
> > Here is a preliminary patch, not tested at all, just to give everybody a
> > target to aim bricks at.
> >
> > * A new __GFP_MEMALLOC flag gives access to the memalloc reserve.
>
On Wed, 3 Aug 2005, Daniel Phillips wrote:
> Hi,
>
> Here is a preliminary patch, not tested at all, just to give everybody a
> target to aim bricks at.
>
> * A new __GFP_MEMALLOC flag gives access to the memalloc reserve.
>
> * In dev_alloc_skb, if GFP_ATOMIC fails then try again with __GFP_M
Hi,
Here is a preliminary patch, not tested at all, just to give everybody a
target to aim bricks at.
* A new __GFP_MEMALLOC flag gives access to the memalloc reserve.
* In dev_alloc_skb, if GFP_ATOMIC fails then try again with __GFP_MEMALLOC.
* We know an skb was allocated from reserve
