| To: | jmoyer@xxxxxxxxxx |
|---|---|
| Subject: | Re: [PATCH 4/7] netpoll: fix ->poll() locking |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Fri, 22 Apr 2005 15:52:18 -0700 |
| Cc: | mpm@xxxxxxxxxxx, jgarzik@xxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <17001.31150.194263.732284@xxxxxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <4.454130102@xxxxxxxxxxx> <5.454130102@xxxxxxxxxxx> <17001.31150.194263.732284@xxxxxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Fri, 22 Apr 2005 18:24:46 -0400 Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > ==> Regarding [PATCH 4/7] netpoll: fix ->poll() locking; Matt Mackall > <mpm@xxxxxxxxxxx> adds: > > mpm> Introduce a per-client poll lock and flag. The lock assures we never > mpm> have more than one caller in dev->poll(). The flag provides recursion > mpm> avoidance on UP where the lock disappears. > > I don't think it makes sense to have the poll lock associated with a struct > netpoll. There should be a 1 to 1 relationship from netdev to netpoll, but I see no problems with a many to 1 relationship from netdev to netpoll, that is perfectly legal. It would give more stringent locking on dev->poll() invocations, not forget to lock when necessary. The only thing which is wrong is that netpoll_setup() should verify that netdev->np is NULL, and if it is not it should return an error. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [PATCH][SCTP] Use ipv6_addr_any rather than ipv6_addr_type in sctp_v6_is_any()., Sridhar Samudrala |
|---|---|
| Next by Date: | Re: [PATCH 4/7] netpoll: fix ->poll() locking, Jeff Moyer |
| Previous by Thread: | Re: [PATCH 4/7] netpoll: fix ->poll() locking, Jeff Moyer |
| Next by Thread: | Re: [PATCH 4/7] netpoll: fix ->poll() locking, Jeff Moyer |
| Indexes: | [Date] [Thread] [Top] [All Lists] |