* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Changli Gao @ 2011-03-15 1:30 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1103150210370.21929@obet.zrqbmnf.qr>
On Tue, Mar 15, 2011 at 9:16 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
>
> The original tuple may not be updated, but the reply tuple is.
> And we are taking the reply tuple in
>
> tuple_ptr = &ct->tuplehash[IP_CT_DIR_REPLY].tuple;
>
> which is subsequently copied to conn->tuple on the first invocation.
>
> Afterwards, SNAT will update ct->tuplehash[reply].tuple, and so
> conn->tuple is outdated. Calling nf_conntrack_find_get(conn->tuple)
> in count_them would then fail, would it not?
>
After my patch, tuple is only used to look up the corresponding
conntrack. And as you know, one conntrack has two tuples, you can look
up a conntrack by either one. The old implementation uses the
conn->tuple.src.u3 to save target address, so you need to use the
reply tuple to work around the DNAT issue. In my patch, the target
address isn't saved in conn->tuple.src.u3 but in conn->addr, so we can
use the constant tuple in the original direction to look up the
corresponding conntrack in count_them(). No reply tuple involved, no
failed nf_conntrack_find_get().
--
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Jan Engelhardt @ 2011-03-15 1:16 UTC (permalink / raw)
To: Changli Gao; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <AANLkTimBV9x7Y-tUez5VMDoU+8mtaw1f48GV1yxgZ71c@mail.gmail.com>
On Tuesday 2011-03-15 00:49, Changli Gao wrote:
>>>the final tuples will be:
>>>src = home dst = router src=1.2.3.4 dst=192.168.0.1
>>>
>>>However, the tuple saved by connlimit is src=1.2.3.4 dst=home, so this
>>>conn will be removed later as there isn't any conntrack, which has
>>>this tuple in any direction.
>>
>> But I don't yet see how your patch #1 can help. At the time
>> conn->tuple = *tuple is done, *tuple still contains the non-SNATed
>> tuple, and it is never updated again.
>
>In this patch, conn->addr is used to save the destination/source
>address instead of conn->tuple.src.u3, so the conn->tuple is used for
>conntrack lookup only. Just as the original tuple isn't updated, we
>can use it to looking up the associated conntrack all the time.
The original tuple may not be updated, but the reply tuple is.
And we are taking the reply tuple in
tuple_ptr = &ct->tuplehash[IP_CT_DIR_REPLY].tuple;
which is subsequently copied to conn->tuple on the first invocation.
Afterwards, SNAT will update ct->tuplehash[reply].tuple, and so
conn->tuple is outdated. Calling nf_conntrack_find_get(conn->tuple)
in count_them would then fail, would it not?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2011-03-15 0:30 UTC (permalink / raw)
To: David Miller
Cc: Thomas Gleixner, bhutchings, netdev, linux-next, linux-kernel,
mingo, hpa, peterz
In-Reply-To: <alpine.LFD.2.00.1103141053020.2787@localhost6.localdomain6>
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
Hi Dave,
On Mon, 14 Mar 2011 10:56:12 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 14 Mar 2011, Stephen Rothwell wrote:
>
> > On Sun, 13 Mar 2011 22:53:12 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Mon, 14 Mar 2011 16:31:35 +1100
> > >
> > > > Maybe some config option changed ...
> > >
> > > Perhaps GENERIC_HARDIRQS_NO_DEPRECATED?
> >
> > Yep, that has been turned on for powerpc now. I guess you will have the
> > same problem on sparc64 of you merge the net-next and sparc trees ...
>
> Yeah, powerpc alone compiles with GENERIC_HARDIRQS_NO_DEPRECATED as it
> does not have that notify commit.
>
> If you add net which has that notify commit, but not the fix it
> breaks. I wonder whether Dave should pick that fix into net.
So, if you merge the commit 1fb0ef31f428 ("genirq: Fix affinity notifier
fallout") from the tip tree, you will get exactly one new commit and will
fix your tree properly with no adverse effect on anyone else.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] virtio: put last seen used index into ring itself
From: Shirley Ma @ 2011-03-15 0:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rusty Russell, Tom Lendacky, Krishna Kumar2, David Miller, kvm,
netdev, steved, jasowang
In-Reply-To: <a38d4f036fc471c4ea2a5c61e355813576a4ee3a.1300134326.git.mst@redhat.com>
On Mon, 2011-03-14 at 22:30 +0200, Michael S. Tsirkin wrote:
> Generally, the Host end of the virtio ring doesn't need to see where
> Guest is up to in consuming the ring. However, to completely
> understand
> what's going on from the outside, this information must be exposed.
> For example, host can reduce the number of interrupts by detecting
> that the guest is currently handling previous buffers.
>
> Fortunately, we have room to expand: the ring is always a whole number
> of pages and there's hundreds of bytes of padding after the avail ring
> and the used ring, whatever the number of descriptors (which must be a
> power of 2).
>
> We add a feature bit so the guest can tell the host that it's writing
> out the current value there, if it wants to use that.
>
> This is based on a patch by Rusty Russell, with the main difference
> being that we dedicate a feature bit to guest to tell the host it is
> writing the used index. This way we don't need to force host to
> publish
> the last available index until we have a use for it.
>
> Memory barriers use has been rationalized (hopefully correctly).
> To avoid the cost of an extra memory barrier on each update, we only
> commit for the index to be up to date when interrupts
> are enabled.
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/virtio/virtio_ring.c | 25 ++++++++++++++++---------
> include/linux/virtio_ring.h | 11 +++++++++++
> 2 files changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/virtio/virtio_ring.c
> b/drivers/virtio/virtio_ring.c
> index cc2f73e..a6fc537 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -89,9 +89,6 @@ struct vring_virtqueue
> /* Number we've added since last sync. */
> unsigned int num_added;
>
> - /* Last used index we've seen. */
> - u16 last_used_idx;
> -
> /* How to notify other side. FIXME: commonalize hcalls! */
> void (*notify)(struct virtqueue *vq);
>
> @@ -283,12 +280,13 @@ static void detach_buf(struct vring_virtqueue
> *vq, unsigned int head)
>
> static inline bool more_used(const struct vring_virtqueue *vq)
> {
> - return vq->last_used_idx != vq->vring.used->idx;
> + return vring_last_used(vq) != vq->vring.used->idx;
> }
here should be vring_last_used(&vq->vring)
> void *virtqueue_get_buf(struct virtqueue *_vq, unsigned int *len)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
> + struct vring_used_elem *u;
> void *ret;
> unsigned int i;
>
> @@ -308,9 +306,9 @@ void *virtqueue_get_buf(struct virtqueue *_vq,
> unsigned int *len)
> /* Only get used array entries after they have been exposed by
> host. */
> virtio_rmb();
>
> - i = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].id;
> - *len = vq->vring.used->ring[vq->last_used_idx%
> vq->vring.num].len;
> -
> + u = &vq->vring.used->ring[vring_last_used(vq) %
> vq->vring.num];
same here vring_last_used(&vq->vring)
> + i = u->id;
> + *len = u->len;
> if (unlikely(i >= vq->vring.num)) {
> BAD_RING(vq, "id %u out of range\n", i);
> return NULL;
> @@ -323,7 +321,12 @@ void *virtqueue_get_buf(struct virtqueue *_vq,
> unsigned int *len)
> /* detach_buf clears data, so grab it now. */
> ret = vq->data[i];
> detach_buf(vq, i);
> - vq->last_used_idx++;
> + (vring_last_used(vq))++;
> + /* If we expect an interrupt for the next entry, flush out
> + * last used index write. */
> + if (!(vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT))
> + virtio_mb();
> +
> END_USE(vq);
> return ret;
> }
> @@ -346,6 +349,8 @@ bool virtqueue_enable_cb(struct virtqueue *_vq)
> /* We optimistically turn back on interrupts, then check if
> there was
> * more to do. */
> vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_INTERRUPT;
> + /* Besides flags write, this barrier also flushes out
> + * last available index write. */
> virtio_mb();
> if (unlikely(more_used(vq))) {
> END_USE(vq);
> @@ -429,7 +434,7 @@ struct virtqueue *vring_new_virtqueue(unsigned int
> num,
> vq->vq.name = name;
> vq->notify = notify;
> vq->broken = false;
> - vq->last_used_idx = 0;
> + vring_last_used(vq) = 0;
Same here vring_last_used(&vq->vring)
> vq->num_added = 0;
> list_add_tail(&vq->vq.list, &vdev->vqs);
> #ifdef DEBUG
> @@ -471,6 +476,8 @@ void vring_transport_features(struct virtio_device
> *vdev)
> switch (i) {
> case VIRTIO_RING_F_INDIRECT_DESC:
> break;
> + case VIRTIO_RING_F_PUBLISH_USED:
> + break;
> default:
> /* We don't understand this bit. */
> clear_bit(i, vdev->features);
> diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
> index e4d144b..4587ea2 100644
> --- a/include/linux/virtio_ring.h
> +++ b/include/linux/virtio_ring.h
> @@ -29,6 +29,9 @@
> /* We support indirect buffer descriptors */
> #define VIRTIO_RING_F_INDIRECT_DESC 28
>
> +/* The Guest publishes last-seen used index at the end of the avail
> ring. */
> +#define VIRTIO_RING_F_PUBLISH_USED 29
> +
> /* Virtio ring descriptors: 16 bytes. These can chain together via
> "next". */
> struct vring_desc {
> /* Address (guest-physical). */
> @@ -83,6 +86,7 @@ struct vring {
> * __u16 avail_flags;
> * __u16 avail_idx;
> * __u16 available[num];
> + * __u16 last_used_idx;
> *
> * // Padding to the next align boundary.
> * char pad[];
> @@ -93,6 +97,10 @@ struct vring {
> * struct vring_used_elem used[num];
> * };
> */
> +
> +/* We publish the last-seen used index at the end of the available
> ring.
> + * It is at the end for backwards compatibility. */
> +#define vring_last_used(vr) ((vr)->avail->ring[num])
> static inline void vring_init(struct vring *vr, unsigned int num,
> void *p,
> unsigned long align)
> {
> @@ -101,6 +109,9 @@ static inline void vring_init(struct vring *vr,
> unsigned int num, void *p,
> vr->avail = p + num*sizeof(struct vring_desc);
> vr->used = (void *)(((unsigned long)&vr->avail->ring[num] +
> align-1)
> & ~(align - 1));
> + /* Verify that last used index does not spill over the used
> ring. */
> + BUG_ON((void *)&vring_last_used(vr) +
> + sizeof vring_last_used(vr) > (void *)vr->used);
> }
>
> static inline unsigned vring_size(unsigned int num, unsigned long
> align)
> --
> 1.7.3.2.91.g446ac
>
>
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/3] net: dcbnl: Add IEEE app selector value definitions
From: David Miller @ 2011-03-15 0:03 UTC (permalink / raw)
To: john.r.fastabend; +Cc: mark.d.rustad, netdev, shmulikr
In-Reply-To: <20110314190114.12070.94640.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Mon, 14 Mar 2011 12:01:15 -0700
> From: Mark Rustad <mark.d.rustad@intel.com>
>
> This adds defines for the app selector values currently
> defined in the IEEE 802.1Qaz specification.
>
> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] net: dcbnl: Fix misspellings
From: David Miller @ 2011-03-15 0:03 UTC (permalink / raw)
To: john.r.fastabend; +Cc: mark.d.rustad, netdev, shmulikr
In-Reply-To: <20110314190107.12070.90092.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Mon, 14 Mar 2011 12:01:08 -0700
> From: Mark Rustad <mark.d.rustad@intel.com>
>
> Fix a few spelling errors in dcbnl.h.
>
> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] net: dcbnl: Update copyright dates
From: David Miller @ 2011-03-15 0:03 UTC (permalink / raw)
To: john.r.fastabend; +Cc: mark.d.rustad, netdev, shmulikr
In-Reply-To: <20110314190102.12070.21182.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Mon, 14 Mar 2011 12:01:02 -0700
> From: Mark Rustad <mark.d.rustad@intel.com>
>
> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH][v3] dev : fix mtu check when TSO is enabled
From: David Miller @ 2011-03-14 23:59 UTC (permalink / raw)
To: daniel.lezcano; +Cc: eric.dumazet, kaber, nightnord, netdev
In-Reply-To: <1300135190-14093-1-git-send-email-daniel.lezcano@free.fr>
From: Daniel Lezcano <daniel.lezcano@free.fr>
Date: Mon, 14 Mar 2011 21:39:50 +0100
> + len = dev->mtu + dev->hard_header_len + VLAN_HLEN;
> + if (skb->len < len)
> + return true;
This is not a correct translation of the original test:
> - (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
You need to use "<=" in your version, which currently rejects all
full sized frames. :-)
> +
> + /* if TSO is enabled, we don't care about the length as the packet
> + * could be forwarded without being segmented before
> + */
> + if (skb->dev && skb->dev->features & NETIF_F_TSO)
> + return true;
I am trying to understand why you aren't simply checking also if this
is a segmented frame? Perhaps skb_is_gso() && device has NETIF_F_TSO
set?
^ permalink raw reply
* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Changli Gao @ 2011-03-14 23:49 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1103141955180.21929@obet.zrqbmnf.qr>
On Tue, Mar 15, 2011 at 3:00 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Monday 2011-03-14 13:42, Changli Gao wrote:
>
>>
>>Yes, you are correct only when there is no SNAT rule. If there is an
>>SNAT rule:
>>
>>-t nat -A POSTROUTING -p tcp --dport 80 -j SNAT --to-source 192.168.0.1
>>
>>the final tuples will be:
>>src = home dst = router src=1.2.3.4 dst=192.168.0.1
>>
>>However, the tuple saved by connlimit is src=1.2.3.4 dst=home, so this
>>conn will be removed later as there isn't any conntrack, which has
>>this tuple in any direction.
>
> But I don't yet see how your patch #1 can help. At the time
> conn->tuple = *tuple is done, *tuple still contains the non-SNATed
> tuple, and it is never updated again.
>
In this patch, conn->addr is used to save the destination/source
address instead of conn->tuple.src.u3, so the conn->tuple is used for
conntrack lookup only. Just as the original tuple isn't updated, we
can use it to looking up the associated conntrack all the time.
addr: 192.168.0.1
tuple: src = home, dst = router
--
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/2] CS89x0: add QQ2440 networking support
From: David Miller @ 2011-03-14 23:49 UTC (permalink / raw)
To: cavokz; +Cc: akpm, linux-arm-kernel, netdev
In-Reply-To: <20110314134627.GA11935@dandreoli.com>
From: Domenico Andreoli <cavokz@gmail.com>
Date: Mon, 14 Mar 2011 13:46:27 +0000
> this patchset cleans some bit left from the CS89x0_NONISA_IRQ
> transition and then enables the support of CS89x0 on QQ2440.
Both patches applied, thanks.
^ permalink raw reply
* Multicast Fails Over Multipoint GRE Tunnel
From: Doug Kehn @ 2011-03-14 23:34 UTC (permalink / raw)
To: netdev
Hi All,
I'm running kernel version 2.6.36 on ARM XSCALE (big-endian) and multicast over a multipoint GRE tunnel isn't working. For my architecture, this worked on 2.6.26.8. For x86, multicast over a multipoint GRE tunnel worked with kernel version 2.6.31 but failed with version 2.6.35. Multicast over a multipoint GRE tunnel fails because ipgre_header() fails the 'if (iph->daddr)' check and reutrns -t->hlen. ipgre_header() is being called, from neigh_connected_output(), with a non-null daddr; the contents of daddr is zero.
Reverting the ip_gre.c patch posted in http://marc.info/?l=linux-netdev&m=126762491525281&w=2 resolves the problem. (Reviewing the HEAD of net-next-2.6 it appears that ipgre_header() remains unchanged from 2.6.36.)
The configuration used to discover/diagnose the problem:
ip tunnel add tun1 mode gre key 11223344 ttl 64 csum remote any
ip link set dev tun1 up
ip link set dev tun1 multicast on
ip addr flush dev tun1
ip addr add 10.40.92.114/24 broadcast 10.40.92.255 dev tun1
12: tun1: <MULTICAST,NOARP,UP,10000> mtu 1468 qdisc noqueue
link/gre 0.0.0.0 brd 0.0.0.0
inet 10.40.92.114/24 brd 10.40.92.255 scope global tun1
Then attempt:
ping -I tun1 224.0.0.9
Are additional configuration steps now required for multicast over multipoint GRE tunnel or is ipgre_header() in error?
Thanks,
...doug
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] IPVS
From: Simon Horman @ 2011-03-14 23:13 UTC (permalink / raw)
To: Patrick McHardy
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Hans Schillstrom,
Julian Anastasov
In-Reply-To: <4D7E5BBE.7060702@trash.net>
On Mon, Mar 14, 2011 at 07:17:34PM +0100, Patrick McHardy wrote:
> On 13.03.2011 23:44, Simon Horman wrote:
> > Hi Patrick,
> >
> > please consider pulling
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
> > to get the following changes.
> >
> > Jesper Juhl (1):
> > Fix variable assignment in ip_vs_notrack
> >
> > Julian Anastasov (2):
> > ipvs: avoid lookup for fwmark 0
> > ipvs: remove _bh from percpu stats reading
> >
> > Shan Wei (1):
> > netfilter:ipvs: use kmemdup
> >
> > include/net/ip_vs.h | 2 +-
> > net/netfilter/ipvs/ip_vs_ctl.c | 8 +++++---
> > net/netfilter/ipvs/ip_vs_est.c | 8 ++++----
> > net/netfilter/ipvs/ip_vs_pe_sip.c | 9 ++++-----
> > net/netfilter/ipvs/ip_vs_sync.c | 3 +--
> > 5 files changed, 15 insertions(+), 15 deletions(-)
>
> The pull contained quite a lot of other changes. I'm undoing the
> pull for now, please resubmit the patches you actually want me to
> pull. Thanks!
Sorry about that. I will double check things but
the list below looks like the second request that I sent out
yesterday.
>
> Jesper Juhl (1):
> Fix variable assignment in ip_vs_notrack
>
> Julian Anastasov (8):
> ipvs: avoid lookup for fwmark 0
> ipvs: remove _bh from percpu stats reading
> ipvs: move struct netns_ipvs
> ipvs: reorganize tot_stats
> ipvs: properly zero stats and rates
> ipvs: remove unused seqcount stats
> ipvs: optimize rates reading
> ipvs: rename estimator functions
>
> Patrick McHardy (1):
> Merge branch 'master' of git://git.kernel.org/.../horms/lvs-test-2.6
>
> Shan Wei (1):
> netfilter:ipvs: use kmemdup
>
> Simon Horman (14):
> IPVS: Add ip_vs_route_me_harder()
> IPVS: Add sysctl_snat_reroute()
> IPVS: Add sysctl_nat_icmp_send()
> IPVS: Add {sysctl_sync_threshold,period}()
> IPVS: Add sysctl_sync_ver()
> IPVS: Add sysctl_expire_nodest_conn()
> IPVS: Add expire_quiescent_template()
> IPVS: Conditinally use sysctl_lblc{r}_expiration
> IPVS: ip_vs_todrop() becomes a noop when CONFIG_SYSCTL is undefined
> IPVS: Conditional ip_vs_conntrack_enabled()
> IPVS: Minimise ip_vs_leave when CONFIG_SYSCTL is undefined
> IPVS: Conditionally define and use ip_vs_lblc{r}_table
> IPVS: Add __ip_vs_control_{init,cleanup}_sysctl()
> IPVS: Conditionally include sysctl members of struct netns_ipvs
>
^ permalink raw reply
* Re: [PATCH 0/7] TCP CUBIC Hystart fixes
From: David Miller @ 2011-03-14 22:58 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 14 Mar 2011 10:52:11 -0700
> This is the merge of my patches and recent update Sangtae.
> It addresses the problems reported by Lucas Nussbaum that Hystart causes
> poor startup performance over links with lots of buffering.
Ok, I've applied all of this to net-2.6 and did test builds with HZ={100,250,1000}
on both sparc64 and x86.
I'll let it cook for a day or two before pushing it out to Linus.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: David Miller @ 2011-03-14 22:54 UTC (permalink / raw)
To: bhutchings
Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty,
sony.chacko
In-Reply-To: <1300142648.2584.76.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 14 Mar 2011 22:44:08 +0000
> For link settings, that isn't clear, and drivers should simply
> reject invalid combinations.
Ok, makes sense.
Amit please update your patch to silently reject link setting attempts
that are unsupported by the device.
Thanks.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: Ben Hutchings @ 2011-03-14 22:44 UTC (permalink / raw)
To: David Miller
Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty,
sony.chacko
In-Reply-To: <20110314.153240.241445951.davem@davemloft.net>
On Mon, 2011-03-14 at 15:32 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Mon, 14 Mar 2011 22:30:22 +0000
>
> > On Mon, 2011-03-14 at 15:15 -0700, David Miller wrote:
> >> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> >> Date: Fri, 11 Mar 2011 01:50:03 -0800
> >>
> >> > From: Sony Chacko <sony.chacko@qlogic.com>
> >> >
> >> > o Allow setting speed and auto negotiation parameters for GbE ports.
> >> > o Log an error message to indicate duplex setting is not supported in
> >> > the hardware currently.
> >> >
> >> > Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> >> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> >>
> >> The kernel log is not the place to transmit this information.
> >>
> >> Please work with Ben Hutchings who is working for ways to report
> >> this to the user in the proper location, via ethtool.
> >
> > I am? Well, patches welcome, at least.
>
> You were discussing a scheme, I think with Intel folks, about letting
> such changes through then making ethtool re-read the settings and see
> which changes were not integrated by the driver.
>
> Then you'd emit a diagnostic from ethtool over stderr to report any
> such discrepencies.
Only for offload settings, where the API makes it clear which flags the
user is deliberately setting and the kernel or driver can reasonably fix
up others. For link settings, that isn't clear, and drivers should
simply reject invalid combinations.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] ftmac100: use GFP_ATOMIC allocations where needed
From: David Miller @ 2011-03-14 22:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: ratbert.chuang, netdev, linux-kernel, ratbert
In-Reply-To: <1300112791.3423.31.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Mar 2011 15:26:31 +0100
> When running in softirq context, we should use GFP_ATOMIC allocations
> instead of GFP_KERNEL ones.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Po-Yu Chuang <ratbert@faraday-tech.com>
> Acked-by: Po-Yu Chuang <ratbert@faraday-tech.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [patch 1/1] [PATCH] qeth: change some configurations defaults
From: David Miller @ 2011-03-14 22:40 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20110314132127.374926261@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Mon, 14 Mar 2011 14:20:54 +0100
> This patch turns on RX checksum and GRO by default. To improve
> receiving performance and reduce congestion in case of network
> bursts we also increase the default number of inbound buffers.
>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Applied, thanks Frank.
^ permalink raw reply
* Re: [PATCH] bonding: documentation update: mailing lists.
From: David Miller @ 2011-03-14 22:37 UTC (permalink / raw)
To: nicolas.2p.debian; +Cc: fubar, andy, netdev
In-Reply-To: <1300048462-4486-1-git-send-email-nicolas.2p.debian@free.fr>
From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Date: Sun, 13 Mar 2011 21:34:22 +0100
> In commit a6c36ee677607b02d8ecc88e8a12785418b88107 ("bonding: change list
> contact to netdev@vger.kernel.org"), the mailing list for bonding
> developpement was changed from bonding-devel to netdev.
>
> Update the bonding documentation to reflect this change:
>
> - bonding-devel is used for usage discussions (despite the name).
> - netdev is used for developpement discussions.
>
> Also remove the reference to the sourceforge bonding page, which is
> deprecated.
>
> Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Applied, thanks Nicolas.
^ permalink raw reply
* Re: [PATCH] Fix possible null pointer dereference in davinci_cpdma.c
From: David Miller @ 2011-03-14 22:36 UTC (permalink / raw)
To: huzaifas; +Cc: netdev, khilman, cyril
In-Reply-To: <1300091954-10367-1-git-send-email-huzaifas@redhat.com>
From: huzaifas@redhat.com
Date: Mon, 14 Mar 2011 14:09:14 +0530
> From: Huzaifa Sidhpurwala <huzaifas@redhat.com>
>
> Check if chan exists before dereferencing it
>
> Signed-off-by: Huzaifa Sidhpurwala <huzaifas@redhat.com>
Just like your EHEA driver patch, this situation is such that
cpdma_chan_destroy() is never called with a NULL "chan" argument.
Therefore it's better to simply remove the NULL check.
^ permalink raw reply
* Re: [PATCH] Fix possible null pointer dereference in ehea_qmr.c
From: David Miller @ 2011-03-14 22:34 UTC (permalink / raw)
To: huzaifas; +Cc: netdev, leitao
In-Reply-To: <1300088764-9330-1-git-send-email-huzaifas@redhat.com>
From: huzaifas@redhat.com
Date: Mon, 14 Mar 2011 13:16:04 +0530
> From: Huzaifa Sidhpurwala <huzaifas@redhat.com>
>
> If queue is zero, dont reference it
>
> Signed-off-by: Huzaifa Sidhpurwala <huzaifas@redhat.com>
There is no code path where hw_queue_dtor() is called with a NULL
"queue". I've checked all of the code paths.
Therefore it's better to simply remove the NULL check.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: David Miller @ 2011-03-14 22:32 UTC (permalink / raw)
To: bhutchings
Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty,
sony.chacko
In-Reply-To: <1300141822.2584.71.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 14 Mar 2011 22:30:22 +0000
> On Mon, 2011-03-14 at 15:15 -0700, David Miller wrote:
>> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>> Date: Fri, 11 Mar 2011 01:50:03 -0800
>>
>> > From: Sony Chacko <sony.chacko@qlogic.com>
>> >
>> > o Allow setting speed and auto negotiation parameters for GbE ports.
>> > o Log an error message to indicate duplex setting is not supported in
>> > the hardware currently.
>> >
>> > Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
>> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>>
>> The kernel log is not the place to transmit this information.
>>
>> Please work with Ben Hutchings who is working for ways to report
>> this to the user in the proper location, via ethtool.
>
> I am? Well, patches welcome, at least.
You were discussing a scheme, I think with Intel folks, about letting
such changes through then making ethtool re-read the settings and see
which changes were not integrated by the driver.
Then you'd emit a diagnostic from ethtool over stderr to report any
such discrepencies.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: Ben Hutchings @ 2011-03-14 22:30 UTC (permalink / raw)
To: David Miller
Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty,
sony.chacko
In-Reply-To: <20110314.151531.233692938.davem@davemloft.net>
On Mon, 2011-03-14 at 15:15 -0700, David Miller wrote:
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Date: Fri, 11 Mar 2011 01:50:03 -0800
>
> > From: Sony Chacko <sony.chacko@qlogic.com>
> >
> > o Allow setting speed and auto negotiation parameters for GbE ports.
> > o Log an error message to indicate duplex setting is not supported in
> > the hardware currently.
> >
> > Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> The kernel log is not the place to transmit this information.
>
> Please work with Ben Hutchings who is working for ways to report
> this to the user in the proper location, via ethtool.
I am? Well, patches welcome, at least.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: David Miller @ 2011-03-14 22:27 UTC (permalink / raw)
To: msmith; +Cc: netdev
In-Reply-To: <4D7E9558.7030102@cbnco.com>
From: Michael Smith <msmith@cbnco.com>
Date: Mon, 14 Mar 2011 18:23:20 -0400
> David Miller wrote:
>
>> Existing arguments might be large enough to carry more than one piece
>> of information :-)
>
> If it's encoded into another argument, would there be more overhead
> from bit-shifting it out than you'd save by losing an argument?
It sure will if it's the different between the argument being passed
in a register vs. on the stack.
^ permalink raw reply
* Re: [PATCH] af_unix: update locking comment
From: David Miller @ 2011-03-14 22:26 UTC (permalink / raw)
To: dbaluta; +Cc: eric.dumazet, netdev, daniel.baluta
In-Reply-To: <1300047106-8545-1-git-send-email-dbaluta@ixiacom.com>
From: dbaluta@ixiacom.com
Date: Sun, 13 Mar 2011 22:11:46 +0200
> We latch our state using a spinlock not a r/w kind of lock.
>
> Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] NET: cdc-phonet, handle empty phonet header
From: David Miller @ 2011-03-14 22:24 UTC (permalink / raw)
To: remi.denis-courmont
Cc: jslaby, jirislaby, netdev, gregkh, linux-usb, linux-kernel
In-Reply-To: <201103140949.04760.remi.denis-courmont@nokia.com>
From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Mon, 14 Mar 2011 09:49:04 +0200
> On Sunday 13 March 2011 18:54:31 ext Jiri Slaby, you wrote:
>> Currently, for N 5800 XM I get:
>> cdc_phonet: probe of 1-6:1.10 failed with error -22
>>
>> It's because phonet_header is empty. Extra altsetting looks like
>> there:
>> E 05 24 00 01 10 03 24 ab 05 24 06 0a 0b 04 24 fd .$....$..$....$.
>> E 00 .
>>
>> I don't see the header used anywhere so just check if the phonet
>> descriptor is there, not the structure itself.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>> Cc: David S. Miller <davem@davemloft.net>
>
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Also applied, thanks.
^ 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