Can we replace the msleep(250) in dev.c netdev_wait_allrefs?
Subsystems (2)
I think there was a proposal to change it to schedule_timeout_uninterruptible(1); some time ago, but that change never made it upstream (at least not in 3.7.5)?
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 6 lines · Ben Greear
I think there was a proposal to change it to
schedule_timeout_uninterruptible(1); some time ago, but that change never made it upstream (at least not in 3.7.5)?Thanks,
Ben
Honestly we should fix the bug at this point, not hide it.
We could use msleep(2500) to make sure people will complain ;)
Quoted 11 lines · Eric Dumazet
Quoted 6 lines · Ben Greear
I think there was a proposal to change it to
schedule_timeout_uninterruptible(1); some time ago, but that change never made it upstream (at least not in 3.7.5)?Thanks,
BenHonestly we should fix the bug at this point, not hide it.
We could use msleep(2500) to make sure people will complain ;)
Well, few will notice that either, or at least are unlikely to know what to blame.
If we should just never reach that code, maybe a WARN_ON_ONCE() when we do?
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
David Miller
maintainerFrom: Ben Greear <[email protected]>
Date: Tue, 29 Jan 2013 12:24:19 -0800
Quoted 13 lines · Eric Dumazet
Quoted 12 lines · Ben Greear
Quoted 8 lines
I think there was a proposal to change it to
schedule_timeout_uninterruptible(1);
some time ago, but that change never made it upstream (at least not in 3.7.5)?Thanks,
BenHonestly we should fix the bug at this point, not hide it.
Quoted 7 lines
Quoted 1 line
We could use msleep(2500) to make sure people will complain ;)
Well, few will notice that either, or at least are unlikely to know what to blame.
If we should just never reach that code, maybe a
WARN_ON_ONCE()when we do?
If you only notice some time in the future that something has hung in this state, the original message could be lost. Therefore, I definitely prefer that this thing keeps barking into the logs periodically.
Quoted 4 lines · David Miller
If you only notice some time in the future that something has hung in this state, the original message could be lost. Therefore, I definitely prefer that this thing keeps barking into the logs periodically.
Not sure we need the full stack, as it probably contains no useful context / information at this point.
David Miller
maintainerFrom: Eric Dumazet <[email protected]>
Date: Tue, 29 Jan 2013 12:45:30 -0800
Quoted 8 lines · David Miller
Quoted 4 lines
If you only notice some time in the future that something has hung in this state, the original message could be lost. Therefore, I definitely prefer that this thing keeps barking into the logs periodically.
Not sure we need the full stack, as it probably contains no useful context / information at this point.
That's true.