shaper.c: fix locking
Subsystems (2)
PATCH 1/1 shaper.c: fix locking
o use a semaphore instead of an opencoded and racy lock
o move locking out of shaper_kick and into the callers - most just released the lock before calling shaper_kick
o remove in_interrupt() tests. from ->close we can always block, from ->hard_start_xmit and timer context never
include/linux/if_shaper.h +1 -2
@@ -23,7 +23,7 @@__u32 shapeclock;unsigned long recovery;/* Time we can next clock a packet out on an empty queue */ -unsigned long locked; +struct semaphore sem;struct net_device_stats stats;struct net_device *dev; int (*hard_start_xmit) (struct sk_buff *skb,
@@ -38,7 +38,6 @@int (*hard_header_cache)(struct neighbour *neigh,struct hh_cache *hh);void (*header_cache_update)(struct hh_cache *hh,struct net_device *dev,unsigned char * haddr);struct net_device_stats * (*get_stats)(struct net_device *dev); -wait_queue_head_t wait_queue;struct timer_list timer; };
drivers/net/shaper.c +19 -67
147 lines not on this page · raw message
David S. Miller
maintainerFrom: Christoph Hellwig <[email protected]>
Subject: [PATCH] shaper.c: fix locking
Date: Fri, 27 May 2005 13:54:50 +0200
Quoted 5 lines
o use a semaphore instead of an opencoded and racy lock
o move locking out ofshaper_kickand into the callers - most just released the lock before callingshaper_kick
o removein_interrupt()tests. from ->close we can always block, from ->hard_start_xmit and timer context never
Do you really want to use a semaphore for a lock taken %99 of the time in software IRQ context, which obviously cannot sleep?
Quoted 10 lines · David S. Miller
From: Christoph Hellwig <[email protected]>
Subject: [PATCH]shaper.c: fix locking
Date: Fri, 27 May 2005 13:54:50 +0200Quoted 5 lines
o use a semaphore instead of an opencoded and racy lock
o move locking out ofshaper_kickand into the callers - most just released the lock before callingshaper_kick
o removein_interrupt()tests. from ->close we can always block, from ->hard_start_xmit and timer context never
Quoted 3 lines
Do you really want to use a semaphore for a lock taken %99 of the time in software IRQ context, which obviously cannot sleep?
I want to change as little as possible from the previous variant ;-)
David S. Miller
maintainerFrom: Christoph Hellwig <[email protected]>
Date: Wed, 1 Jun 2005 07:21:50 +0200
Quoted 11 lines · David S. Miller
Quoted 10 lines
From: Christoph Hellwig <[email protected]>
Subject: [PATCH]shaper.c: fix locking
Date: Fri, 27 May 2005 13:54:50 +0200Quoted 5 lines
o use a semaphore instead of an opencoded and racy lock
o move locking out ofshaper_kickand into the callers - most just released the lock before callingshaper_kick
o removein_interrupt()tests. from ->close we can always block, from ->hard_start_xmit and timer context never
Quoted 5 lines
Quoted 3 lines
Do you really want to use a semaphore for a lock taken %99 of the time in software IRQ context, which obviously cannot sleep?
I want to change as little as possible from the previous variant ;-)
Fair enough, patch applied. If this driver breaks as a result of these changes, you get to keep the pieces ok? :-)
Quoted 2 lines · David S. Miller
Fair enough, patch applied. If this driver breaks as a result of these changes, you get to keep the pieces ok? :-)
The question is anyone really using this driver? ;->
cheers,
jamal