On Tue, Dec 01, 2020 at 03:42:38PM +0100, Pablo Neira Ayuso wrote:
> On Mon, Nov 30, 2020 at 08:48:28PM +0200, Vladimir Oltean wrote:
> [...]
> > There are 2 separate classes of problems:
> > - We already have two ways of protecting pure readers: via RCU and via
> > the rwlock. It doesn't help if
On Mon, Nov 30, 2020 at 08:48:28PM +0200, Vladimir Oltean wrote:
[...]
> There are 2 separate classes of problems:
> - We already have two ways of protecting pure readers: via RCU and via
> the rwlock. It doesn't help if we also add a second way of locking out
> pure writers. We need to first c
On Mon, Nov 30, 2020 at 11:20:23PM +0100, Eric Dumazet wrote:
> On Mon, Nov 30, 2020 at 10:53 PM Vladimir Oltean wrote:
> >
> > On Mon, Nov 30, 2020 at 10:46:00PM +0100, Eric Dumazet wrote:
> > > You can not use dev_base_lock() or RCU and call an ndo_get_stats64()
> > > that could sleep.
> > >
> >
On Mon, Nov 30, 2020 at 10:46:00PM +0100, Eric Dumazet wrote:
> You can not use dev_base_lock() or RCU and call an ndo_get_stats64()
> that could sleep.
>
> You can not for example start changing bonding, since bond_get_stats()
> could be called from non-sleepable context (net/core/net-procfs.c)
>
On 11/30/2020 11:32 AM, Vladimir Oltean wrote:
> -[cut here]-
> From 93ffc25f30849aaf89e50e58d32b0b047831f94d Mon Sep 17 00:00:00 2001
> From: Vladimir Oltean
> Date: Mon, 30 Nov 2020 02:49:25 +0200
> Subject: [PATCH] parisc/led: retrieve
On Mon, Nov 30, 2020 at 10:00:16PM +0100, Eric Dumazet wrote:
> On Mon, Nov 30, 2020 at 9:50 PM Vladimir Oltean wrote:
> >
> > On Mon, Nov 30, 2020 at 09:43:01PM +0100, Eric Dumazet wrote:
> > > Understood, but really dev_base_lock can only be removed _after_ we
> > > convert all usages to somethi
On Mon, Nov 30, 2020 at 09:43:01PM +0100, Eric Dumazet wrote:
> Understood, but really dev_base_lock can only be removed _after_ we
> convert all usages to something else (mutex based, and preferably not
> the global RTNL)
Sure.
A large part of getting rid of dev_base_lock seems to be just:
- dele
On Mon, Nov 30, 2020 at 09:29:15PM +0100, Eric Dumazet wrote:
> On Mon, Nov 30, 2020 at 9:26 PM Vladimir Oltean wrote:
> >
> > On Mon, Nov 30, 2020 at 12:21:29PM -0800, Stephen Hemminger wrote:
> > > if device is in a private list (in bond device), the way to handle
> > > this is to use dev_hold()
On Mon, Nov 30, 2020 at 12:21:29PM -0800, Stephen Hemminger wrote:
> if device is in a private list (in bond device), the way to handle
> this is to use dev_hold() to keep a ref count.
Correct, dev_hold is a tool that can also be used. But it is a tool that
does not solve the general problem - onl
On Mon, 30 Nov 2020 21:46:17 +0200
Vladimir Oltean wrote:
> On Mon, Nov 30, 2020 at 08:22:01PM +0100, Eric Dumazet wrote:
> > And ?
> >
> > A bonding device can absolutely maintain a private list, ready for
> > bonding ndo_get_stats() use, regardless
> > of register/unregister logic.
> >
> > bond
On 11/30/20 8:46 PM, Vladimir Oltean wrote:
> On Mon, Nov 30, 2020 at 08:22:01PM +0100, Eric Dumazet wrote:
>> And ?
>>
>> A bonding device can absolutely maintain a private list, ready for
>> bonding ndo_get_stats() use, regardless
>> of register/unregister logic.
>>
>> bond_for_each_slave() is
On Mon, Nov 30, 2020 at 08:22:01PM +0100, Eric Dumazet wrote:
> And ?
>
> A bonding device can absolutely maintain a private list, ready for
> bonding ndo_get_stats() use, regardless
> of register/unregister logic.
>
> bond_for_each_slave() is simply a macro, you can replace it by something else.
On Mon, Nov 30, 2020 at 08:22:01PM +0100, Eric Dumazet wrote:
> On Mon, Nov 30, 2020 at 8:03 PM Vladimir Oltean wrote:
> > On Mon, Nov 30, 2020 at 08:00:40PM +0100, Eric Dumazet wrote:
> > > On 11/30/20 7:48 PM, Vladimir Oltean wrote:
> > > > diff --git a/drivers/net/bonding/bond_main.c
> > > > b
On Mon, Nov 30, 2020 at 08:00:40PM +0100, Eric Dumazet wrote:
>
>
> On 11/30/20 7:48 PM, Vladimir Oltean wrote:
> > On Mon, Nov 30, 2020 at 10:14:05AM -0800, Jakub Kicinski wrote:
> >> On Mon, 30 Nov 2020 11:41:10 +0100 Eric Dumazet wrote:
> So dev_base_lock dates back to the Big Kernel Lock b
On 11/30/20 7:48 PM, Vladimir Oltean wrote:
> On Mon, Nov 30, 2020 at 10:14:05AM -0800, Jakub Kicinski wrote:
>> On Mon, 30 Nov 2020 11:41:10 +0100 Eric Dumazet wrote:
So dev_base_lock dates back to the Big Kernel Lock breakup back in Linux
2.4
(ie before my time). The time has c
On Mon, Nov 30, 2020 at 10:14:05AM -0800, Jakub Kicinski wrote:
> On Mon, 30 Nov 2020 11:41:10 +0100 Eric Dumazet wrote:
> > > So dev_base_lock dates back to the Big Kernel Lock breakup back in Linux
> > > 2.4
> > > (ie before my time). The time has come to get rid of it.
> > >
> > > The use is sy
On Mon, 30 Nov 2020 11:41:10 +0100 Eric Dumazet wrote:
> > So dev_base_lock dates back to the Big Kernel Lock breakup back in Linux 2.4
> > (ie before my time). The time has come to get rid of it.
> >
> > The use is sysfs is because could be changed to RCU. There have been issues
> > in the past wi
On Sun, 29 Nov 2020 22:58:17 +0200
Vladimir Oltean wrote:
> [ resent, had forgot to copy the list ]
>
> Hi,
>
> net/core/dev.c has this to say about the locking rules around the network
> interface lists (dev_base_head, and I can only assume that it also applies to
> the per-ifindex hash table
[ resent, had forgot to copy the list ]
Hi,
net/core/dev.c has this to say about the locking rules around the network
interface lists (dev_base_head, and I can only assume that it also applies to
the per-ifindex hash table dev_index_head and the per-name hash table
dev_name_head):
/*
* The @dev
19 matches
Mail list logo
