From: Borislav Petkov
Date: Sat, 22 Dec 2012 19:02:47 +0100
> Top-posting so that the rest can remain untouched.
This bug is fixed in the 'net' tree already by commit:
>From 30e6c9fa93cf3dbc7cc6df1d748ad25e4264545a Mon Sep 17 00:00:00 2001
From: Eric Dumazet
Date: Thu, 20 Dec 2012 17:25:08 +00
On 12/22/2012 12:30 PM, Borislav Petkov wrote:
On Sat, Dec 22, 2012 at 10:10:28AM -0800, Eric Dumazet wrote:
RTNL is a mutex, its perfectly valid to use GFP_KERNEL while holding a
mutex.
Right, sorry. The check fires because we have preemption disabled.
As replied before your mail, fix for t
On Sat, Dec 22, 2012 at 10:10:28AM -0800, Eric Dumazet wrote:
> RTNL is a mutex, its perfectly valid to use GFP_KERNEL while holding a
> mutex.
Right, sorry. The check fires because we have preemption disabled.
> As replied before your mail, fix for the problem is already in David
> tree.
Yep, s
On Sat, 2012-12-22 at 19:02 +0100, Borislav Petkov wrote:
> Top-posting so that the rest can remain untouched.
>
> Right, so AFAICT, something is holding rtnl_mutex (probably some
> rtnetlink traffic) and device_rename() is doing kstrdup with
> GFP_KERNEL which, among others, has __GFP_WAIT and *t
Top-posting so that the rest can remain untouched.
Right, so AFAICT, something is holding rtnl_mutex (probably some
rtnetlink traffic) and device_rename() is doing kstrdup with
GFP_KERNEL which, among others, has __GFP_WAIT and *that* triggers the
might_sleep_if() check in slab_pre_alloc_hook():
On Sat, 2012-12-22 at 11:11 -0600, Larry Finger wrote:
> With kernel 3.8-rc1, I get 2 "BUG: sleeping function called from invalid
> context" reports. These have been present got some time in the 3.7-git
> versions
> and I have tried twice to bisect the problem. Both times, I ended up at a
> mer
6 matches
Mail list logo
