* Re: bridge: Fix IGMP3 report parsing
From: David Miller @ 2010-04-08 4:21 UTC (permalink / raw)
To: herbert; +Cc: netdev, banyeer
In-Reply-To: <20100408040709.GA19944@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 8 Apr 2010 12:07:09 +0800
> On Wed, Apr 07, 2010 at 08:52:48PM -0700, David Miller wrote:
>>
>> If pskb_may_pull() actually does anything non-trivial,
>> skb->data will change and you'll be referring to freed
>> up memory.
>>
>> That's probably why you had the grec assignment where
>> you originally had it in the first place :-)
>
> Heh, you're clearly more awake than I was :)
:-)
> bridge: Fix IGMP3 report parsing
>
> The IGMP3 report parsing is looking at the wrong address for
> group records. This patch fixes it.
>
> Reported-by: Banyeer <banyeer@yahoo.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: bridge: Fix IGMP3 report parsing
From: Herbert Xu @ 2010-04-08 4:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, banyeer
In-Reply-To: <20100407.205248.113724360.davem@davemloft.net>
On Wed, Apr 07, 2010 at 08:52:48PM -0700, David Miller wrote:
>
> If pskb_may_pull() actually does anything non-trivial,
> skb->data will change and you'll be referring to freed
> up memory.
>
> That's probably why you had the grec assignment where
> you originally had it in the first place :-)
Heh, you're clearly more awake than I was :)
bridge: Fix IGMP3 report parsing
The IGMP3 report parsing is looking at the wrong address for
group records. This patch fixes it.
Reported-by: Banyeer <banyeer@yahoo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 6980625..f29ada8 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -723,7 +723,7 @@ static int br_multicast_igmp3_report(struct net_bridge *br,
if (!pskb_may_pull(skb, len))
return -EINVAL;
- grec = (void *)(skb->data + len);
+ grec = (void *)(skb->data + len - sizeof(*grec));
group = grec->grec_mca;
type = grec->grec_type;
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH] bnx2x: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08 4:06 UTC (permalink / raw)
To: eilong; +Cc: fujita.tomonori, netdev, vladz
In-Reply-To: <1270561278.1848.5.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Tue, 6 Apr 2010 16:41:18 +0300
> On Tue, 2010-04-06 at 00:39 -0700, Vladislav Zolotarov wrote:
>> Thanks, Fujita.
>>
>> The patch looks fine. I'll run some regression tests on the patched driver to check that things still work and if it's ok we will ack it shortly.
>>
>> vlad
>>
>>
>
>> > =
>> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
>> > Subject: [PATCH] bnx2x: use the DMA API instead of the pci equivalents
>> >
>> > The DMA API is preferred.
>> >
>> > Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Vlad's testing with this patch were finished successfully.
>
> Thanks Fujita!
> Acked-by: Vladislav Zolotarov <vladz@broadcom.com>
> Acked-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bnx2: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08 4:05 UTC (permalink / raw)
To: fujita.tomonori; +Cc: netdev, mchan
In-Reply-To: <20100402115025A.fujita.tomonori@lab.ntt.co.jp>
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Fri, 2 Apr 2010 11:56:57 +0900
> The DMA API is preferred.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [PATCHv2] virtio-net: move sg off stack
From: David Miller @ 2010-04-08 4:01 UTC (permalink / raw)
To: mst; +Cc: rusty, jpirko, xma, netdev, linux-kernel
In-Reply-To: <20100404130741.GA7500@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 4 Apr 2010 16:07:41 +0300
> Move sg structure off stack and into virtnet_info structure.
> This helps remove extra sg_init_table calls as well as reduce
> stack usage.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Tested-by: Michael S. Tsirkin <mst@redhat.com>
Applied to net-next-2.6, thanks Michael.
^ permalink raw reply
* Re: [PATCH 2/2] benet: fix the misusage of zero dma address
From: David Miller @ 2010-04-08 3:59 UTC (permalink / raw)
To: sathyap; +Cc: fujita.tomonori, subbus, sarveshwarb, ajitk, netdev
In-Reply-To: <20100405082202.GB32671@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 5 Apr 2010 13:52:02 +0530
> On 05/04/10 16:40 +0900, FUJITA Tomonori wrote:
>> > > + wrb->frag_len = 0;
>> > Why does wrb->frag_len need to be reset here?
>> > In the TX path, it is set to the proper value for data wrbs and zero
>> > for dummy and hdr wrbs.
>>
>> I guess that I misunderstood why unmap_tx_frag() checks a dma address.
>> The checking is necessary to avoid calling pci_unamp_* API for dummy
>> hdr wrbs?
> Yes.
>>
>> Anyway, if wrb->frag_len doesn't need to be reset here, the following
>> patch is ok?
> Yes. Thanks.
>
> Acked-by: Sathya Perla <sathyap@serverengines.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/2] benet: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08 3:59 UTC (permalink / raw)
To: sathyap; +Cc: fujita.tomonori, subbus, sarveshwarb, ajitk, netdev
In-Reply-To: <20100405090457.GA2541@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 5 Apr 2010 14:34:57 +0530
> Thanks.
>
> Acked-by: Sathya Perla <sathyap@serverengines.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] 3c503: Fix IRQ probing
From: David Miller @ 2010-04-08 3:56 UTC (permalink / raw)
To: ben; +Cc: p_gortmaker, netdev, 566522, sql7
In-Reply-To: <1270398809.8341.47.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 04 Apr 2010 17:33:29 +0100
> The driver attempts to select an IRQ for the NIC automatically by
> testing which of the supported IRQs are available and then probing
> each available IRQ with probe_irq_{on,off}(). There are obvious race
> conditions here, besides which:
> 1. The test for availability is done by passing a NULL handler, which
> now always returns -EINVAL, thus the device cannot be opened:
> <http://bugs.debian.org/566522>
> 2. probe_irq_off() will report only the first ISA IRQ handled,
> potentially leading to a false negative.
>
> There was another bug that meant it ignored all error codes from
> request_irq() except -EBUSY, so it would 'succeed' despite this
> (possibly causing conflicts with other ISA devices). This was fixed
> by ab08999d6029bb2c79c16be5405d63d2bedbdfea 'WARNING: some
> request_irq() failures ignored in el2_open()', which exposed bug 1.
>
> This patch:
> 1. Replaces the use of probe_irq_{on,off}() with a real interrupt handler
> 2. Adds a delay before checking the interrupt-seen flag
> 3. Disables interrupts on all failure paths
> 4. Distinguishes error codes from the second request_irq() call,
> consistently with the first
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This looks logically fine, but I'm tossing this into net-next-2.6
because of the limited tester space for this driver.
Thanks Ben.
^ permalink raw reply
* Re: [PATCH] cnic: Fix crash during bnx2x MTU change.
From: David Miller @ 2010-04-08 3:54 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1270518241-13750-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Mon, 5 Apr 2010 18:44:01 -0700
> cnic_service_bnx2x() irq handler can be called during chip reset from
> MTU change. Need to check that the cnic's device state is up before
> handling the irq.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: bridge: Fix IGMP3 report parsing
From: David Miller @ 2010-04-08 3:52 UTC (permalink / raw)
To: herbert; +Cc: netdev, banyeer
In-Reply-To: <20100408012634.GC18649@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 8 Apr 2010 09:26:34 +0800
> Hi:
>
> bridge: Fix IGMP3 report parsing
>
> The IGMP3 report parsing is looking at the wrong address for
> group records. This patch fixes it.
>
> Reported-by: Banyeer <banyeer@yahoo.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
I think you're adding as many bugs as you are fixing here :-)
> @@ -719,11 +719,11 @@ static int br_multicast_igmp3_report(struct net_bridge *br,
> len = sizeof(*ih);
>
> for (i = 0; i < num; i++) {
> + grec = (void *)(skb->data + len);
> len += sizeof(*grec);
> if (!pskb_may_pull(skb, len))
> return -EINVAL;
>
> - grec = (void *)(skb->data + len);
> group = grec->grec_mca;
> type = grec->grec_type;
>
If pskb_may_pull() actually does anything non-trivial,
skb->data will change and you'll be referring to freed
up memory.
That's probably why you had the grec assignment where
you originally had it in the first place :-)
^ permalink raw reply
* Re: [PATCH] rfs: Receive Flow Steering
From: Changli Gao @ 2010-04-08 1:37 UTC (permalink / raw)
To: Rick Jones; +Cc: Tom Herbert, Eric Dumazet, davem, netdev
In-Reply-To: <4BB6367D.9090600@hp.com>
On Sat, Apr 3, 2010 at 2:25 AM, Rick Jones <rick.jones2@hp.com> wrote:
> Tom Herbert wrote:
>> The progression in HP-UX was IPS (10.20) (aka RPS) then TOPS (11.0)
>> (aka RFS). We found that IPS was great for
>> single-flow-per-thread-of-execution stuff and that TOPS was better
>> for multiple-flow-per-thread-of-execution stuff. It was long enough
>> ago now that I can safely say for one system-level benchmark not
>> known to be a "networking" benchmark, and without a massive kernel
>> component, TOPS was a 10% win. Not too shabby.
>>
>> It wasn't that IPS wasn't good in its context - just that TOPS was
>> even better.
>>
>> I would assume that with IPS threads would migrate to where packets were
>> being delivered thus giving the same sort of locality TOPS was providing?
>> That would work great without any other constraints (multiple flows per
>> thread, thread CPU bindings, etc.).
>
> Well... that depended - at the time, and still, we were and are also
> encouraging users and app designers to make copious use of
> processor/locality affinity (SMP and NUMA going back far longer in the RISC
> et al space than the x86 space). So, it was and is entirely possible that
> the application thread of execution is hard-bound to a specific
> core/locality. Also, I do not recall if HP-UX was as aggressive about
> waking a process/thread on the processor from which the wake-up came vs on
> the processor on which it last ran.
>
Maybe RPS should be work against process not processor. For packets
forwarding, the process is net_rx softirq.
>> We also preferred the concept of the scheduler giving networking
>> clues as to where to process an application's packets rather than
>> networking trying to tell the scheduler. There was some discussion
>> of out of order worries, but we were willing to trust to the basic
>> soundness of the scheduler - if it was moving threads around willy
>> nilly at a rate able to cause big packet reordering it had
>> fundamental problems that would have to be addressed anyway.
>>
>>
>> I also think scheduler leading networking, like in RPS, is generally more
>> scalable. As for OOO packets, I've spent way to much time trying to
>> convince the bean-counters that a small number of them aren't problematic
>> :-), in the end it's just easier to not introduce new mechanisms that will
>> cause them!
>
> So long as it doesn't drive you to produce new mechanisms heavier than they
> would have otherwise been.
>
> The irony in the case of HP-UX IPS was that it was put in place in response
> to the severe out of order packet problems in HP-UX in 10.X before 10.20 -
> there were multiple netisr processes and only one netisr queue. The other
> little tweak that came along in 10.20 with IPS, was inaddition to having a
> per processor (well, per core in today's parlance) netisr queue, the netisr
> would grab the entire queue under the one spinlock and work off of that.
> That was nice because the code path became more efficient under load - more
> packets processed per spinlock/unlock pair.
>
RPS dispatches packets among all the CPUs permitted fairly, in order
to take full advantage of all the CPU power. The assumption is the cpu
cycles each CPU gives to packet processing are the same. But it isn't
always true as scheduler is mixed in. In this case, scheduler leading
network is a good choice. Maybe we should make softirq threaded under
the control of scheduler. And the number of softirq threads can be
specified by users. By default, the number of the softirq threads are
the same as the number of CPUs, and each thread binds to a special
CPU, to keep the current behavior. If the other tasks aren't
dispatched among the CPUs even, system administrator may increase the
number of softirq thread, and dissolve the thread binding, then there
will be enough schedulable softirq threads for scheduler scheduling.
Oh, maybe there is no need of weighted packets dispatching RPS.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* bridge: Fix IGMP3 report parsing
From: Herbert Xu @ 2010-04-08 1:26 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Banyeer
Hi:
bridge: Fix IGMP3 report parsing
The IGMP3 report parsing is looking at the wrong address for
group records. This patch fixes it.
Reported-by: Banyeer <banyeer@yahoo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 6980625..5f0acfd 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -719,11 +719,11 @@ static int br_multicast_igmp3_report(struct net_bridge *br,
len = sizeof(*ih);
for (i = 0; i < num; i++) {
+ grec = (void *)(skb->data + len);
len += sizeof(*grec);
if (!pskb_may_pull(skb, len))
return -EINVAL;
- grec = (void *)(skb->data + len);
group = grec->grec_mca;
type = grec->grec_type;
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: hackbench regression due to commit 9dfc6e68bfe6e
From: Zhang, Yanmin @ 2010-04-08 1:05 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Lameter, Pekka Enberg, netdev, Tejun Heo, alex.shi,
linux-kernel@vger.kernel.org, Ma, Ling, Chen, Tim C,
Andrew Morton
In-Reply-To: <1270665484.8141.47.camel@edumazet-laptop>
On Wed, 2010-04-07 at 20:38 +0200, Eric Dumazet wrote:
> Le mercredi 07 avril 2010 à 13:20 -0500, Christoph Lameter a écrit :
> > On Wed, 7 Apr 2010, Pekka Enberg wrote:
> >
> > > Oh, sorry, I think it's actually '____cacheline_aligned_in_smp' (with four
> > > underscores) for per-cpu data. Confusing...
> >
> > This does not particulary help to clarify the situation since we are
> > dealing with data that can either be allocated via the percpu allocator or
> > be statically present (kmalloc bootstrap situation).
> >
> > --
>
> Do we have a user program to check actual L1 cache size of a machine ?
If there is no, it's easy to write it as kernel exports the cache stat by
/sys/devices/system/cpu/cpuXXX/cache/indexXXX/
>
> I remember my HP blades have many BIOS options, I would like to make
> sure they are properly set.
>
>
>
^ permalink raw reply
* Re: [GIT PULL] vhost-net fix for 2.6.34-rc3
From: David Miller @ 2010-04-07 23:52 UTC (permalink / raw)
To: mst; +Cc: kvm, virtualization, netdev, linux-kernel, jdike
In-Reply-To: <20100407173502.GA26061@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 7 Apr 2010 20:35:02 +0300
> David,
> The following tree includes a patch fixing an issue with vhost-net in
> 2.6.34-rc3. Please pull for 2.6.34.
Pulled, thanks Michael.
^ permalink raw reply
* Re: [PATCH 1/1] qlcnic: fix set mac addr
From: David Miller @ 2010-04-07 23:51 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1270638114-15323-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Wed, 7 Apr 2010 04:01:54 -0700
> If interface is down, mac address request are not sent to fw
> but it is getting add in driver mac list.
> Driver mac list should be in sync with fw i.e addresses communicated
> to fw.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] r6040: fix r6040_multicast_list
From: David Miller @ 2010-04-07 23:51 UTC (permalink / raw)
To: florian; +Cc: netdev, darkadept
In-Reply-To: <201004071318.48883.florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Wed, 7 Apr 2010 13:18:48 +0200
> As reported in <https://bugzilla.kernel.org/show_bug.cgi?id=15355>, r6040_
> multicast_list currently crashes. This is due a wrong maximum of multicast
> entries. This patch fixes the following issues with multicast:
>
> - number of maximum entries if off-by-one (4 instead of 3)
>
> - the writing of the hash table index is not necessary and leads to invalid
> values being written into the MCR1 register, so the MAC is simply put in a non
> coherent state
>
> - when we exceed the maximum number of mutlticast address, writing the
> broadcast address should be done in registers MID_1{L,M,H} instead of
> MID_O{L,M,H}, otherwise we would loose the adapter's MAC address
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
Applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH] Caif: Ref counting
From: David Miller @ 2010-04-07 23:50 UTC (permalink / raw)
To: alan; +Cc: sjur.brandeland, netdev
In-Reply-To: <20100407141319.318ebb6f@lxorguk.ukuu.org.uk>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Wed, 7 Apr 2010 14:13:19 +0100
> caif: tty's are kref objects so take a reference
>
> From: Alan Cox <alan@linux.intel.com>
>
> I don't think this can be abused in this case but do things properly.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Also applied, thanks Alan.
^ permalink raw reply
* Re: [PATCH] CAIF: write check
From: David Miller @ 2010-04-07 23:49 UTC (permalink / raw)
To: alan; +Cc: sjur.brandeland, netdev
In-Reply-To: <20100407141703.7c0a4a65@lxorguk.ukuu.org.uk>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Wed, 7 Apr 2010 14:17:03 +0100
> caif: check write operations
>
> From: Alan Cox <alan@linux.intel.com>
>
> write is optional for a tty device. Check that we have a write op rather
> than calling NULL.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Applied, thanks Alan.
^ permalink raw reply
* Re: [PATCH v3 0/4] xfrm: add x86 CONFIG_COMPAT support
From: David Miller @ 2010-04-07 23:48 UTC (permalink / raw)
To: kaber; +Cc: fw, netdev, johannes
In-Reply-To: <4BBC8C8F.9020907@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 07 Apr 2010 15:45:51 +0200
> Florian Westphal wrote:
>> David Miller <davem@davemloft.net> wrote:
>>> From: Florian Westphal <fw@strlen.de>
>>> Date: Tue, 6 Apr 2010 00:27:07 +0200
>>
>> [..]
>>
>>>> I sent a patch that solved this by adding a sys_compat_write syscall
>>>> and a ->compat_aio_write() to struct file_operations to the
>>>> vfs mailing list, but that patch was ignored by the vfs people,
>>>> and the x86 folks did not exactly like the idea either.
>>>>
>>>> So this leaves three alternatives:
>>>> 1 - drop the whole idea and keep the current status.
>>>> 2 - Add new structure definitions (with new numbering) that would work
>>>> everywhere, keep the old ones for backwards compatibility (This
>>>> was suggested by Arnd Bergmann).
>
> Given that there is only a quite small number of users of this
> interface, that would in my opinion be the best way.
Can you explain that line of reasoning?
It's not that there are only "3 or 4 tools" using these interfaces,
it's the fact that 32-bit binaries of those tools are on millions and
millions of systems out there.
^ permalink raw reply
* Re: [Bugme-new] [Bug 15682] New: XFRM is not updating RTAX_ADVMSS metric
From: David Miller @ 2010-04-07 23:47 UTC (permalink / raw)
To: herbert; +Cc: hadi, akpm, netdev, bugzilla-daemon, bugme-daemon,
eduardo.panisset
In-Reply-To: <20100407135446.GA13394@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 7 Apr 2010 21:54:46 +0800
> Dave, what do you think about us starting to update ADVMSS on
> the fly, just like the MTU?
This sounds fine.
> The only risk is that existing users who are forcing ADVMSS to
> a value higher than what it would otherwise be would now get a
> lower value, if they're not using the "lock" keyword.
>
> This shouldn't be fatal as it would only result in smaller packets
> which should still work, and they can always start using the
> "lock" keyword to get back the old behaviour.
And if we get them to fix their kit and use the lock setting,
it'll work in older kernels too.
^ permalink raw reply
* Re: linux-next: Tree for April 7 (net/core/dev_addr_lists)
From: David Miller @ 2010-04-07 23:46 UTC (permalink / raw)
To: randy.dunlap; +Cc: eric.dumazet, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100407105049.0f812b27.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Wed, 7 Apr 2010 10:50:49 -0700
> On Wed, 07 Apr 2010 19:38:09 +0200 Eric Dumazet wrote:
>
>> [PATCH net-next-2.6] net: include linux/proc_fs.h in dev_addr_lists.c
>>
>> As pointed by Randy Dunlap, we must include linux/proc_fs.h in
>> net/core/dev_addr_lists.c, regardless of CONFIG_PROC_FS
>>
>> Reported-by: Randy Dunlap <randy.dunlap@oracle.com>,
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-04-07
From: David Miller @ 2010-04-07 23:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100407.164224.60848141.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 07 Apr 2010 16:42:24 -0700 (PDT)
> I guess nobody takes me seriously when I say tone down the rate
> of fixes to the absolute minimum.
>
> Oh well, what can I do, if even the most core people can't be bothered
> to listen to my requests.
Sorry, I take back this rant.
The set of fixes actually looks quite reasonable.
:-)
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-04-07
From: David Miller @ 2010-04-07 23:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100407182832.GA2995@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 7 Apr 2010 14:28:32 -0400
> Here is a batch of fixes intended for 2.6.34. Included is a variable
> initialization required for some ath9k hardware to function reliably,
> some RCU annotation to avoid some warnings in mac80211, and a fix for
> a regression relating to 802.11s mesh networking. Also included are
> several iwlwifi fixes, include the elimination of an order-4 allocation
> during resume, avoidance of a the BUG_ON in the rate scaling routines,
> and the elimination of a DMA API warning during module removal.
> The iwlwifi patches are a little larger than I would like, but the
> fixes seem legitimate and worthwhile to me.
I guess nobody takes me seriously when I say tone down the rate
of fixes to the absolute minimum.
Oh well, what can I do, if even the most core people can't be bothered
to listen to my requests.
And people wonder why we need 8 or 9 RCs to get a release out.
Pulled.
^ permalink raw reply
* Re: [PATCH] net: fix definition of netdev_for_each_mc_addr()
From: David Miller @ 2010-04-07 23:40 UTC (permalink / raw)
To: proski; +Cc: netdev
In-Reply-To: <20100407220100.13604.6636.stgit@mj.roinet.com>
From: Pavel Roskin <proski@gnu.org>
Date: Wed, 07 Apr 2010 18:01:52 -0400
> The first argument should be called ha, not mclist. All callers use the
> name "ha", but if they used a different name, there would be a compile
> error.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/1] NET: usb: Adding URB_ZERO_PACKET flag to usbnet.c
From: Elina Pasheva @ 2010-04-07 23:07 UTC (permalink / raw)
To: David Brownell
Cc: Rory Filer, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Miller
In-Reply-To: <201004071414.33917.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
On Wed, 2010-04-07 at 14:14 -0700, David Brownell wrote:
> On Tuesday 06 April 2010, you wrote:
> Recall that the reason to avoid sending zero length packts
> (ZLPs) is that many systems don't cope well with them...
>
> The ""don't cope well" can be at the hardware level,
> or drivers not limited to device firmware. I've seen
> the failures be very context-dependent .... as in, one
> standalone ZLP might work, but mix it in with back-to-back
> delivery of other packets and trouble ensues...
>
> In short, it's hard to know which combinations of
> hardware an firmware would need it .... versus which
> ones it would break.
>
> ... and thus risky to try sending ZLPs through systems
> shere for many years) we've carefully avoided doing that.
>
>
> - Dave
>
Hi Dave,
Nice to hear your opinion on this matter. Are you recommending our patch
be retracted? If so, we can look at other ways to fix the problem when a
zero length packet is missing.
Regards,
Elina
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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