Skip to contentSkip to conversation

Can we replace the msleep(250) in dev.c netdev_wait_allrefs?

DISCUSSION Ben Greear 3 participants 6 messages Jan 29, 2013

Subsystems (2)
lore
Share & tools
lore

Ben Greear

author
#0 lore raw

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
#1 lore raw
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 ;)

author
#2 lore raw
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,
Ben

Honestly 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
maintainer
#3 lore raw

From: 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,
Ben

Honestly 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.

#4 lore raw
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.

maintainer
#5 lore raw

From: 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.