On Sep 4, 2019, at 4:23 PM, Saeed Mahameed wrote:
some allocations require parameters that should remain valid and
constant across the whole reconfiguration procedure such
params.num_channels, so they must be done inside the lock.
You could always check if those parameters have changed once u
On Wed, 2019-09-04 at 09:38 -0700, Jonathan Lemon wrote:
> On 4 Sep 2019, at 0:39, Eric Dumazet wrote:
>
> > On 9/3/19 11:55 PM, Jonathan Lemon wrote:
> > > How appropriate is it to hold the rtnl_lock() across a sleepable
> > > memory allocation? On one hand it's just a mutex, but it would
> > >
On 4 Sep 2019, at 0:39, Eric Dumazet wrote:
On 9/3/19 11:55 PM, Jonathan Lemon wrote:
How appropriate is it to hold the rtnl_lock() across a sleepable
memory allocation? On one hand it's just a mutex, but it would
seem like it could block quite a few things.
Sure, all GFP_KERNEL allocations
On 9/3/19 11:55 PM, Jonathan Lemon wrote:
> How appropriate is it to hold the rtnl_lock() across a sleepable
> memory allocation? On one hand it's just a mutex, but it would
> seem like it could block quite a few things.
>
Sure, all GFP_KERNEL allocations can sleep for quite a while.
On the
How appropriate is it to hold the rtnl_lock() across a sleepable
memory allocation? On one hand it's just a mutex, but it would
seem like it could block quite a few things.
--
Jonathan
