On Tue, Sep 29 2020 at 16:15, Edward Cree wrote:
>> On Mon, Sep 28 2020 at 21:05, Edward Cree wrote:
>>> Only compile-tested so far, because I'm waiting for my kernel to
>>> finish rebuilding with CONFIG_DEBUG_ATOMIC_SLEEP
>
> I've now tested and confirmed that the might_sleep warning goes
> away
> On Mon, Sep 28 2020 at 21:05, Edward Cree wrote:
>> Only compile-tested so far, because I'm waiting for my kernel to
>> finish rebuilding with CONFIG_DEBUG_ATOMIC_SLEEP
I've now tested and confirmed that the might_sleep warning goes
away with this patch.
Thomas, do you want to pull it into v2
On Mon, Sep 28, 2020 at 09:05:52PM +0100, Edward Cree wrote:
> efx_ef10_try_update_nic_stats_vf() used in_interrupt() to figure out
> whether it is safe to sleep (for MCDI) or not.
> The only caller from which it was not is efx_net_stats(), which can be
> invoked under dev_base_lock from net-sysf
On Mon, Sep 28 2020 at 21:05, Edward Cree wrote:
> efx_ef10_try_update_nic_stats_vf() used in_interrupt() to figure out
> whether it is safe to sleep (for MCDI) or not.
> The only caller from which it was not is efx_net_stats(), which can be
> invoked under dev_base_lock from net-sysfs::netstat_s
efx_ef10_try_update_nic_stats_vf() used in_interrupt() to figure out
whether it is safe to sleep (for MCDI) or not.
The only caller from which it was not is efx_net_stats(), which can be
invoked under dev_base_lock from net-sysfs::netstat_show().
So add a new update_stats_atomic() method to struc
