[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081123.172014.78676422.davem@davemloft.net>
Date: Sun, 23 Nov 2008 17:20:14 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: dada1@...mosbay.com
Cc: ilpo.jarvinen@...sinki.fi, netdev@...r.kernel.org
Subject: Re: net-next/unix: BUG: using smp_processor_id() in preemptible
From: Eric Dumazet <dada1@...mosbay.com>
Date: Sun, 23 Nov 2008 04:32:30 +0100
> [PATCH] net: make sock_prot_inuse_add() preempt safe
>
> Ilpo Järvinen reported that commit a8076d8db98de6da61394b2e942320e4612643ac
> (net: af_unix should update its inuse counter) was triggering
> a warning in smp_processor_id(), being called in a preemptible code.
>
> Fix is to make sock_prot_inuse_add() safe in this regard. This fix
> can be reverted when new percpu infrastructure is ready, allowing
> a cpu to safely do a increment/decrement on a percpu var.
>
> Signed-off-by: Eric Dumazet <dada1@...mosbay.com>
Eric, you added this bug by starting to use this interface in
situations where BH's were not disabled.
Ever existing use adhered to that rule.
If you therefore want to call this interface in new locations,
you have to make sure those locations follow the rule too.
Making it expensive for all the existing cases which were already
safe, is not the way to fix this. And saying some future not-merged
change justifies this added cost is besides the point.
What is valid is getting rid of the BH disables you need to add
to net/unix/af_unix.c et al.'s call sites, once those percpu patches
are added. Not the other way around.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists