* Re: fscked clock sources revisited
From: jamal @ 2007-07-31 1:23 UTC (permalink / raw)
To: Arjan van de Ven
Cc: netdev, David Miller, Robert.Olsson, Stephen Hemminger,
Patrick McHardy
In-Reply-To: <1185844629.5162.20.camel@localhost>
On Mon, 2007-30-07 at 21:17 -0400, jamal wrote:
> Actually iirc, hpet is not even enabled in the
> kernel -
Sorry, i lied - the config file is on my laptop - it is enabled.
cheers,
jamal
^ permalink raw reply
* Re: fscked clock sources revisited
From: jamal @ 2007-07-31 1:17 UTC (permalink / raw)
To: Arjan van de Ven
Cc: netdev, David Miller, Robert.Olsson, Stephen Hemminger,
Patrick McHardy
In-Reply-To: <1185844218.2683.0.camel@laptopd505.fenrus.org>
On Mon, 2007-30-07 at 18:10 -0700, Arjan van de Ven wrote:
> can you make sure hpet is enabled as well?
Will do next opportunity. Actually iirc, hpet is not even enabled in the
kernel - What are you expecting to see?
cheers,
jamal
^ permalink raw reply
* Re: fscked clock sources revisited
From: Arjan van de Ven @ 2007-07-31 1:10 UTC (permalink / raw)
To: hadi
Cc: netdev, David Miller, Robert.Olsson, Stephen Hemminger,
Patrick McHardy
In-Reply-To: <1185844239.5162.17.camel@localhost>
On Mon, 2007-07-30 at 21:10 -0400, jamal wrote:
> Folks,
>
> I have posted this before but got no good response and i havent had time
> to chase it.
> While doing some batching tests with pktgen and then with a simple
> client server app with udp, it does appear that the clock source used
> matters. Here are some basic runs with plain vanilla 2.6.22-rc4 runs
> with udp. There are five runs per clock source and each result is in
> Mbps.
can you make sure hpet is enabled as well?
^ permalink raw reply
* fscked clock sources revisited
From: jamal @ 2007-07-31 1:10 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Robert.Olsson, Stephen Hemminger, Patrick McHardy
Folks,
I have posted this before but got no good response and i havent had time
to chase it.
While doing some batching tests with pktgen and then with a simple
client server app with udp, it does appear that the clock source used
matters. Here are some basic runs with plain vanilla 2.6.22-rc4 runs
with udp. There are five runs per clock source and each result is in
Mbps.
acpi_pm: 108, 110, 111, 91, 108
tsc: 143, 108, 161, 129, 108
jiffies: 132, 138, 132, 146, 150
jiffies produces better results than tsc which produces better results
than acpi_pm.
Second issue: I cant consistently get two reboots to always boot with
the same clock source.
Any ideas whats going on here? I havent tried with latest tree.
PS:- These results are very easy to validate with iperf or netperf.
cheers,
jamal
^ permalink raw reply
* Re: [2.6 patch] net/unix/af_unix.c: make code static
From: David Miller @ 2007-07-31 1:06 UTC (permalink / raw)
To: bunk; +Cc: mszeredi, netdev, linux-kernel
In-Reply-To: <20070729145852.GA16817@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Sun, 29 Jul 2007 16:58:52 +0200
> The following code can now become static:
> - struct unix_socket_table
> - unix_table_lock
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Also applied, thanks a lot.
^ permalink raw reply
* Re: [2.6 patch] make nf_ct_ipv6_skip_exthdr() static
From: David Miller @ 2007-07-31 1:05 UTC (permalink / raw)
To: bunk; +Cc: yasuyuki.kozakai, kaber, netfilter-devel, netdev, linux-kernel
In-Reply-To: <20070729145846.GZ16817@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Sun, 29 Jul 2007 16:58:46 +0200
> nf_ct_ipv6_skip_exthdr() can now become static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied.
^ permalink raw reply
* Re: [2.6 patch] make pktgen.c:get_ipsec_sa() static and non-inline
From: David Miller @ 2007-07-31 1:04 UTC (permalink / raw)
To: bunk; +Cc: hadi, robert.olsson, linux-kernel, netdev
In-Reply-To: <20070729145840.GY16817@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Sun, 29 Jul 2007 16:58:40 +0200
> Non-static inline code usually doesn't makes sense.
>
> In this case making is static and non-inline is the correct solution.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* RFC: on [ab]use of skb->cb by VLAN code
From: jamal @ 2007-07-31 0:59 UTC (permalink / raw)
To: David Miller; +Cc: Ben Greear, Patrick McHardy, netdev, Matt Carlson
I was going to forget this, but its been playing in the back of my head
and wont go away....
Matt Carlson recently (while fixing the tg3 driver in my batching
patches) pointed to me that skb->cb[] was being used to pass around vlan
data.
This seems like a bad use since there can be a lot of things between
a real hardware driver and something that sets a vlan tag (qdiscs come
to mind).
Creating a new skb field be the reasonable thing to do here but i know
that we are trying to avoid adding new fields. Thoughts?
cheers,
jamal
^ permalink raw reply
* Re: [RESEND][PATCH 3/3] PPPoE: move lock_sock() in pppoe_sendmsg() to the right location
From: David Miller @ 2007-07-31 0:49 UTC (permalink / raw)
To: florz; +Cc: mostrows, netdev
In-Reply-To: <20070729060446.GC27573@florz.florz.dyndns.org>
From: Florian Zumbiehl <florz@florz.de>
Date: Sun, 29 Jul 2007 08:04:46 +0200
> and the last one for now: Acquire the sock lock in pppoe_sendmsg()
> before accessing the sock - and in particular avoid releasing the lock
> even though it hasn't been acquired.
>
> Signed-off-by: Florian Zumbiehl <florz@florz.de>
Also applied, thanks Florian.
^ permalink raw reply
* Re: [RESEND][PATCH 2/3] PPPoX/E: return ENOTTY on unknown ioctl requests
From: David Miller @ 2007-07-31 0:48 UTC (permalink / raw)
To: florz; +Cc: mostrows, netdev
In-Reply-To: <20070729060435.GB27573@florz.florz.dyndns.org>
From: Florian Zumbiehl <florz@florz.de>
Date: Sun, 29 Jul 2007 08:04:36 +0200
> here another patch for the PPPoX/E code that makes sure that ENOTTY is
> returned for unknown ioctl requests rather than 0 (and removes another
> unneeded initializer which I didn't bother creating a separate patch for).
>
> Signed-off-by: Florian Zumbiehl <florz@florz.de>
Applied, thanks Florian.
^ permalink raw reply
* Re: [RESEND][PATCH 1/3] PPPoE: improved hashing routine
From: David Miller @ 2007-07-31 0:47 UTC (permalink / raw)
To: florz; +Cc: mostrows, netdev
In-Reply-To: <20070729060423.GA27573@florz.florz.dyndns.org>
From: Florian Zumbiehl <florz@florz.de>
Date: Sun, 29 Jul 2007 08:04:23 +0200
> Hi,
>
> I'm not sure whether this is really worth it, but it looked so
> extremely inefficient that I couldn't resist - so let's hope providers
> will keep PPPoE around for a while, at least until terabit dsl ;-)
>
> The new code produces the same results as the old version and is
> ~ 3 to 6 times faster for 4-bit hashes on the CPUs I tested.
>
> Florian
>
> ---------------------------------------------------------------------------
> Signed-off-by: Florian Zumbiehl <florz@florz.de>
>
> diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
> index 9e51fcc..954328c 100644
> --- a/drivers/net/pppoe.c
> +++ b/drivers/net/pppoe.c
> @@ -108,19 +108,24 @@ static inline int cmp_addr(struct pppoe_addr *a, unsigned long sid, char *addr)
> (memcmp(a->remote,addr,ETH_ALEN) == 0));
> }
>
> -static int hash_item(unsigned long sid, unsigned char *addr)
> +#if 8%PPPOE_HASH_BITS
> +#error 8 must be a multiple of PPPOE_HASH_BITS
> +#endif
Since PPPOE_HASH_BITS is "4" I would think this check will break the
build. :-)
Anyways, I looked at this myself and half of the problem comes from
the fact that "sid" is passed around as an "unsigned long" throughout
this entire file yet the thing is just a "__u16".
So the first thing to fix is to use __u16 consistently for sid values.
Then the sid hash looks obviously wrong and is easy to fix.
Then you end up with a hash_item() that simply looks like:
static unsigned int hash_item(__u16 sid, unsigned char *addr)
{
unsigned int hash;
hash = (((unsigned int)addr[0] << 24) |
((unsigned int)addr[1] << 16) |
((unsigned int)addr[2] << 8) |
((unsigned int)addr[3] << 0));
hash ^= (((unsigned int)addr[4] << 8) |
((unsigned int)addr[5] << 0));
hash ^= sid;
return ((hash ^ (hash >> 8) ^ (hash >> 16)) &
(PPPOE_HASH_SIZE - 1));
}
which is what I've checked into my tree.
Thanks!
^ permalink raw reply
* Re: [PATCH v3 -mm 9/9] netconsole: Support dynamic reconfiguration using configfs
From: Satyam Sharma @ 2007-07-31 0:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Kernel Mailing List, Keiichi Kii, Netdev, Joel Becker,
Matt Mackall, David Miller
In-Reply-To: <20070730171306.49b49818.akpm@linux-foundation.org>
On Mon, 30 Jul 2007, Andrew Morton wrote:
> On Mon, 30 Jul 2007 08:19:10 +0530
> Satyam Sharma <satyam@infradead.org> wrote:
>
> > +/*
> > + * Wrapper over simple_strtol (base 10) with sanity and range checking.
> > + * We return (signed) long only because we may want to return errors.
> > + * Do not use this to convert numbers that are allowed to be negative.
> > + */
> > +static long strtol10_check_range(const char *cp, long min, long max)
> > +{
> > + long ret;
> > + char *p = (char *) cp;
> > +
> > + WARN_ON(min < 0);
> > + WARN_ON(max < min);
> > +
> > + ret = simple_strtol(p, &p, 10);
> > +
> > + if (*p && (*p != '\n')) {
> > + printk(KERN_ERR "netconsole: invalid input\n");
> > + return -EINVAL;
> > + }
> > + if ((ret < min) || (ret > max)) {
> > + printk(KERN_ERR "netconsole: input %ld must be between "
> > + "%ld and %ld\n", ret, min, max);
> > + return -EINVAL;
> > + }
> > +
> > + return ret;
> > +}
>
> There's probably other code around the place which does this. It might
> be worth making this function a general-purpose thing.
Probably, yes, I thought along similar lines.
[ BTW somewhere in the 9/9 patch I remember having to define a
__U16_MAX as well. That could be pushed out to some generic
or appropriate header as well, possibly. ]
Satyam
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: David Miller @ 2007-07-31 0:25 UTC (permalink / raw)
To: mchan; +Cc: netdev, shemminger, jgarzik, hadi, rusty
In-Reply-To: <1185485889.7922.83.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 26 Jul 2007 14:38:09 -0700
> If the driver wants a simple solution, it can do what you did in the
> patch: wrap the tx cleanup code with netif_tx_lock() and
> netif_tx_unlock().
>
> If a NAPI driver wants to be more clever, it can do something such as
> this in tg3's poll_controller:
>
> if (netif_rx_schedule_prep(dev, &tp->napi)) {
> tg3_tx(tp);
> netif_poll_enable(tp->napi);
> }
Thanks Michael, that's a good suggestion and would work.
In thinking about this some more over the weekend I've decided
that my plan to rip out RX support from netpoll is a bit too
ambitious.
Therefore, for the time being, I'm going to add a special driver
function for netpoll that will allow it to ask the driver to invoke
->poll() over all the NAPI structs assosciated with the netdev.
^ permalink raw reply
* Re: [PATCH v3 -mm 0/9] netconsole: Multiple targets and dynamic reconfigurability
From: Satyam Sharma @ 2007-07-31 0:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Kernel Mailing List, Keiichi Kii, Netdev, Joel Becker,
Matt Mackall, David Miller
In-Reply-To: <20070730171211.97e2f8f0.akpm@linux-foundation.org>
On Mon, 30 Jul 2007, Andrew Morton wrote:
> On Mon, 30 Jul 2007 08:17:41 +0530
> Satyam Sharma <satyam@infradead.org> wrote:
>
> > [0/9] netconsole: Multiple targets and dynamic reconfigurability
> >
> > This is v3 of the patchset
>
> That all looks pretty reasonable, thanks.
>
> Are we all comfortable with the attributions? As I have it now, everything
> will go in as having been authored by yourself. There is no formal (ie:
> understood-by-git) way of recording joint authorship, unfortunately. But one
> can make a record of such things in the changelog.
Ok, making such a record would be good, if possible. I did see that the
"author" field for git commits can have only one entry, unfortunately,
and it turns out "Signed-off-by" and "Acked-by" have other meanings
attached that have to do with the patch-journey-from-author-to-you chain.
But I'd like these to be somehow marked as jointly authored, definitely.
> I'll queue this material up in the to-be-sent-to-davem queue.
Ok, thanks.
Satyam
^ permalink raw reply
* Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses
From: David Miller @ 2007-07-31 0:21 UTC (permalink / raw)
To: yoshfuji
Cc: djohnson+linux-kernel, netdev, linux-kernel, lksctp-developers,
sakkiped
In-Reply-To: <20070726.133452.78498553.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Thu, 26 Jul 2007 13:34:52 -0500 (CDT)
> In article <18087.57717.495366.413571@zeus.sw.starentnetworks.com> (at Wed, 25 Jul 2007 19:49:09 -0400), Dave Johnson <djohnson+linux-kernel@sw.starentnetworks.com> says:
>
> > ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast
> > Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range.
>
> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Ok, I've applied Dave's patch.
Dave, although it's customary and fine to use "+foo-list" email
addresses for mailing list subscriptions and discussions, I
ask that you don't add that cookie to your signoff lines in
patch submissions and I've removed it from your's in this patch.
Thanks a lot.
^ permalink raw reply
* RE: [FIX] NET: Fix sch_api and sch_prio to properly set and detect the root qdisc
From: Waskiewicz Jr, Peter P @ 2007-07-31 0:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber
In-Reply-To: <20070730.171412.38711276.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, July 30, 2007 5:14 PM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org; kaber@trash.net
> Subject: Re: [FIX] NET: Fix sch_api and sch_prio to properly
> set and detect the root qdisc
>
> From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
> Date: Fri, 27 Jul 2007 09:22:11 -0700
>
> > Are these queued for 2.6.24, or are they going to make it into
> > 2.6.23? I know you're busy with patches and NAPI, but I
> was curious.
> > Thanks!
>
> I've applied both fixes and will push them into 2.6.23
Many thanks Dave!
Cheers,
-PJ
^ permalink raw reply
* Re: [FIX] NET: Fix sch_api and sch_prio to properly set and detect the root qdisc
From: David Miller @ 2007-07-31 0:14 UTC (permalink / raw)
To: peter.p.waskiewicz.jr; +Cc: netdev, kaber
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC329034F503E@orsmsx414.amr.corp.intel.com>
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Date: Fri, 27 Jul 2007 09:22:11 -0700
> Are these queued for 2.6.24, or are they going to make it into
> 2.6.23? I know you're busy with patches and NAPI, but I was
> curious. Thanks!
I've applied both fixes and will push them into 2.6.23
^ permalink raw reply
* Re: [PATCH v3 -mm 9/9] netconsole: Support dynamic reconfiguration using configfs
From: Andrew Morton @ 2007-07-31 0:13 UTC (permalink / raw)
To: Satyam Sharma
Cc: Linux Kernel Mailing List, Keiichi Kii, Netdev, Joel Becker,
Matt Mackall, David Miller
In-Reply-To: <20070730024910.10828.44721.sendpatchset@enigma.security.iitk.ac.in>
On Mon, 30 Jul 2007 08:19:10 +0530
Satyam Sharma <satyam@infradead.org> wrote:
> +/*
> + * Wrapper over simple_strtol (base 10) with sanity and range checking.
> + * We return (signed) long only because we may want to return errors.
> + * Do not use this to convert numbers that are allowed to be negative.
> + */
> +static long strtol10_check_range(const char *cp, long min, long max)
> +{
> + long ret;
> + char *p = (char *) cp;
> +
> + WARN_ON(min < 0);
> + WARN_ON(max < min);
> +
> + ret = simple_strtol(p, &p, 10);
> +
> + if (*p && (*p != '\n')) {
> + printk(KERN_ERR "netconsole: invalid input\n");
> + return -EINVAL;
> + }
> + if ((ret < min) || (ret > max)) {
> + printk(KERN_ERR "netconsole: input %ld must be between "
> + "%ld and %ld\n", ret, min, max);
> + return -EINVAL;
> + }
> +
> + return ret;
> +}
There's probably other code around the place which does this. It might
be worth making this function a general-purpose thing.
^ permalink raw reply
* Re: [PATCH v3 -mm 0/9] netconsole: Multiple targets and dynamic reconfigurability
From: Andrew Morton @ 2007-07-31 0:12 UTC (permalink / raw)
To: Satyam Sharma
Cc: Linux Kernel Mailing List, Keiichi Kii, Netdev, Joel Becker,
Matt Mackall, David Miller
In-Reply-To: <20070730024741.10828.48209.sendpatchset@enigma.security.iitk.ac.in>
On Mon, 30 Jul 2007 08:17:41 +0530
Satyam Sharma <satyam@infradead.org> wrote:
> [0/9] netconsole: Multiple targets and dynamic reconfigurability
>
> This is v3 of the patchset
That all looks pretty reasonable, thanks.
Are we all comfortable with the attributions? As I have it now, everything
will go in as having been authored by yourself. There is no formal (ie:
understood-by-git) way of recording joint authorship, unfortunately. But one
can make a record of such things in the changelog.
I'll queue this material up in the to-be-sent-to-davem queue.
^ permalink raw reply
* Re: [PATCH 6/6] [IPV6]: Remove circular dependency on if_inet6.h
From: David Miller @ 2007-07-31 0:06 UTC (permalink / raw)
To: herbert; +Cc: netdev, kaber
In-Reply-To: <E1IDzLo-0000AX-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 26 Jul 2007 17:09:40 +0800
> [IPV6]: Remove circular dependency on if_inet6.h
>
> net/if_inet6.h includes linux/ipv6.h which also tries to include
> net/if_inet6.h. Since the latter only needs it for forward
> declarations, we can fix this by adding the declarations.
>
> A number of files are implicitly including net/if_inet6.h through
> linux/ipv6.h. They also use net/ipv6.h so this patch includes
> net/if_inet6.h there.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Also applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 5/6] [IPV4/IPV6]: Fail registration if inet device construction fails
From: David Miller @ 2007-07-31 0:05 UTC (permalink / raw)
To: herbert; +Cc: netdev, kaber
In-Reply-To: <E1IDzLm-0000AP-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 26 Jul 2007 17:09:38 +0800
> [IPV4/IPV6]: Fail registration if inet device construction fails
>
> Now that netdev notifications can fail, we can use this to signal
> errors during registration for IPv4/IPv6. In particular, if we
> fail to allocate memory for the inet device, we can fail the netdev
> registration.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH 4/6] [NET]: Allow netdev REGISTER/CHANGENAME events to fail
From: David Miller @ 2007-07-31 0:03 UTC (permalink / raw)
To: herbert; +Cc: netdev, kaber
In-Reply-To: <E1IDzLk-0000AI-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 26 Jul 2007 17:09:36 +0800
> [NET]: Allow netdev REGISTER/CHANGENAME events to fail
>
> This patch adds code to allow errors to be passed up from event
> handlers of NETDEV_REGISTER and NETDEV_CHANGENAME. It also adds
> the notifier_from_errno/notifier_to_errnor helpers to pass the
> errno value up to the notifier caller.
>
> If an error is detected when a device is registered, it causes
> that operation to fail. A NETDEV_UNREGISTER will be sent to
> all event handlers.
>
> Similarly if NETDEV_CHANGENAME fails the original name is restored
> and a new NETDEV_CHANGENAME event is sent.
>
> As such all event handlers must be idempotent with respect to
> these events.
>
> When an event handler is registered NETDEV_REGISTER events are
> sent for all devices currently registered. Should any of them
> fail, we will send NETDEV_GOING_DOWN/NETDEV_DOWN/NETDEV_UNREGISTER
> events to that handler for the devices which have already been
> registered with it. The handler registration itself will fail.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
Interesting encoding scheme :-)
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Jeff Garzik @ 2007-07-31 0:00 UTC (permalink / raw)
To: David Miller
Cc: ossthema, netdev, raisch, themann, linux-kernel, linuxppc-dev,
meder, tklein, stefan.roscher, gallatin
In-Reply-To: <20070730.154332.72713181.davem@davemloft.net>
David Miller wrote:
> From: Jeff Garzik <jeff@garzik.org>
> Date: Mon, 30 Jul 2007 12:17:58 -0400
>
>> David, thoughts on merging? I'm not We could stick this into your tree
>> or mine. Whether yours or mine, I would like to keep the driver and
>> net-core patches together in the same git tree.
>
> No objections and I'll stick it into my net-2.6.24 tree once I cut
> that, I'll have the NAPI stuff in there too so I'll keep these two
> merge nightmares out of your hair :-)
Works for me.
Thanks,
Jeff
^ permalink raw reply
* Re: [PATCH 3/6] [NET] loopback: Panic if registration fails
From: David Miller @ 2007-07-30 23:38 UTC (permalink / raw)
To: herbert; +Cc: netdev, kaber
In-Reply-To: <E1IDzLh-0000AB-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 26 Jul 2007 17:09:33 +0800
> [NET] loopback: Panic if registration fails
>
> Because IPv4 and IPv6 both depend on the presence of the loopback device
> to function, failure in registration the loopback device should be fatal.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
It might be nice to tightly integrate the loopback driver into
net/core/dev.c because that is what is happening anyways and it would
allow us to cons the thing up by hand and deal with these dependencies
more reliably.
^ permalink raw reply
* Re: [PATCH 2/6] [NET]: Take dev_base_lock when moving device name hash list entry
From: David Miller @ 2007-07-30 23:36 UTC (permalink / raw)
To: herbert; +Cc: netdev, kaber
In-Reply-To: <E1IDzLe-0000A4-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 26 Jul 2007 17:09:30 +0800
> [NET]: Take dev_base_lock when moving device name hash list entry
>
> When we added name-based hashing the dev_base_lock was designated as the
> lock to take when changing the name hash list. Unfortunately, because
> it was a preexisting lock that just happened to be taken in the right
> spots we neglected to take it in dev_change_name.
>
> The race can affect calles of __dev_get_by_name that do so without taking
> the RTNL. They may end up walking down the wrong hash chain and end up
> missing the device that they're looking for.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Good catch, applied, thanks Herbert.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox