* Re: [PATCH]net:8021q:vlan.c Fix pr_info to read on line in the syslog.
From: Ben Greear @ 2011-05-23 20:16 UTC (permalink / raw)
To: David Miller; +Cc: joe, justinmattock, netdev, linux-kernel
In-Reply-To: <20110523.155630.1404321441037491870.davem@davemloft.net>
On 05/23/2011 12:56 PM, David Miller wrote:
> From: Joe Perches<joe@perches.com>
> Date: Mon, 23 May 2011 09:23:01 -0700
>
>> though I think that emitting names on startup isn't necessary and
>> this is enough:
>
> Agreed, it's not like Ben and I are Napoleon or anything...
I'm fine with that as well. It was good for the ego, but I
won't mind not getting emails from folks that accidentally
look at their DSL router logs and assume I wrote (and can debug)
the entire AT&T network :)
Thanks,
Ben
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH]net:8021q:vlan.c Fix pr_info to read on line in the syslog.
From: David Miller @ 2011-05-23 19:56 UTC (permalink / raw)
To: joe; +Cc: justinmattock, netdev, linux-kernel
In-Reply-To: <1306167781.8687.20.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Mon, 23 May 2011 09:23:01 -0700
> though I think that emitting names on startup isn't necessary and
> this is enough:
Agreed, it's not like Ben and I are Napoleon or anything...
^ permalink raw reply
* Re: [PATCH] be2net: hash key for rss-config cmd not set
From: David Miller @ 2011-05-23 19:52 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <249a7eac-6aa7-481d-b7b0-a2a3b144963f@exht1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Mon, 23 May 2011 17:55:27 +0530
> Need a random hash key to effectively hash incoming connections into
> multiple RX rings.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
You're saying you need a random hash key, yet you're assigning
a constant.
Why not use a real random number, via get_random() or similar?
^ permalink raw reply
* Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR
From: Nicolas de Pesloüan @ 2011-05-23 19:48 UTC (permalink / raw)
To: Jiri Pirko
Cc: Eric W. Biederman, Changli Gao, Ben Greear, David Miller, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, Jesse Gross
In-Reply-To: <20110523104339.GA2769@psychotron>
Le 23/05/2011 12:43, Jiri Pirko a écrit :
> Mon, May 23, 2011 at 11:41:22AM CEST, ebiederm@xmission.com wrote:
>> Changli Gao<xiaosuo@gmail.com> writes:
>>
>>> On Mon, May 23, 2011 at 9:45 AM, Eric W. Biederman
>>> <ebiederm@xmission.com> wrote:
>>>>> In another side, is there a specification which defines the
>>>>> hw-accel-vlan-rx?
>>>>
>>>> I don't know.
>>>>
>>>> I have just been trying to clean up the mess since some of the
>>>> hw-accel-vlan code broke my use case, by delivering packets with
>>>> priority but no vlan (aka vlan 0 packets) twice to my pf_packet sockets.
>>>>
>>>
>>> OK. But if we have decided to simulate the hw-accel-vlan-rx, I think
>>> we'd better adjust the place where we put the emulation code. The very
>>> beginnings of netif_rx() and neif_receive_skb() are better. Then rps
>>> can support vlan packets without any change.
>>
>> That sounds nice. Patches are welcome.
>>
>> In principle it should be doable with some code motion. I don't think
>> moving vlan_untag earlier constitutes a bug fix.
>
> I do not think that is doable. Consider multi tagged packets. The place
> just after "another_round" takes care about that.
>
> Btw what's the rationale to move untag to earlier position?
Maybe simply because we try to mimic hw-accel, and hw-accel untagging definitely happens before we
enter __netif_receive_skb and only happens once.
So having software untagging inside the __netif_receive_skb loop looks different.
Nicolas.
^ permalink raw reply
* Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR
From: Nicolas de Pesloüan @ 2011-05-23 19:36 UTC (permalink / raw)
To: Ben Greear
Cc: Eric W. Biederman, David Miller, Jiri Pirko, Changli Gao, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, Jesse Gross
In-Reply-To: <4DDA8C42.3090009@candelatech.com>
Le 23/05/2011 18:33, Ben Greear a écrit :
> On 05/23/2011 02:00 AM, Eric W. Biederman wrote:
>> Ben Greear<greearb@candelatech.com> writes:
>>
>>> I believe we have been getting tagged VLAN packets properly
>>> in our test cases. We would not be creating any VLAN devices
>>> in this case, so perhaps the NIC isn't doing any stripping.
>>>
>>> To me, it seems like we should get the fully tagged packet
>>> without having to go muck with aux-data, though it would
>>> be fine if it were *also* in aux-data.
>>
>> Given that pf_packet is a portable interface that works on multiple OS's
>> I tend to agree. Certainly my users would be happier if they don't
>> have to change their code and not having to change tcpdump would
>> also be nice.
>>
>> I'm not certain exactly where in the code it makes sense to put the
>> vlan header back on for pf_packet sockets. The simplest thing would
>> be just before we run the socket filter. If we don't do the simplest
>> thing this raises the question how do we avoid breaking socket filters
>> that look at the packet data and know there is going to be a vlan
>> header there.
>
> That is going to be tricky, since the VLAN header would adjust
> offsets and users could be using some filter that uses offsets
> with no actual mention of VLANs (but expecting it to take
> the VLAN header into account).
>
>> Still the current situation is better than seeing vlan 0 tagged packets
>> twice.
>>
>> My gut feel says if we can cheaply get the socket filters to act like it
>> sees the vlan tag (where the vlan tag belongs) we should not actually
>> put the vlan tag back on until we copy the packet to userspace.
>
> Maybe keep a count of how many sockets with filters and/or pf_packet
> sockets are open, and how many things are registered in
> the 'ptype_all' chain, and only re-add (or never remove) the header if that is > 0?
>
> (And, let the bridging and other kernel logic deal with vlans
> via auxillary methods as well as checking in-line headers.)
Well, this doesn't sound very different from my previous proposal: if a protocol handler is
registered at parent interface level, can't we simply assume this protocol handler expect the raw
packet?
Also, I think the main problem is that ptype_all and ptype_base deliveries are different in
__netif_receive_skb, for no good reason (at least, to my knowledge).
In http://patchwork.ozlabs.org/patch/85578/, I proposed to process protocol handlers that are
registered on a particular interface inside the loop, then process protocol handlers registered to
NULL upon exit from the loop.
That way, we would have the opportunity to deliver different skb (tagged/untagged) to different
level of interface, while we cross the interface stack.
I know there is a possible performance penalty in this implementation, but this can be fixed by
properly ordering the ptype_all/ptype_base list.
Nicolas.
^ permalink raw reply
* Re: linux-next: Tree for May 23 (infiniband + netlink)
From: Roland Dreier @ 2011-05-23 18:05 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, netdev, linux-next-u79uwXL29TY76Z2rM5mHXA, LKML,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110523094205.4a5651d2.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Mon, May 23, 2011 at 9:42 AM, Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20110520:
>
> when CONFIG_NET is not enabled:
>
> ERROR: "skb_trim" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "netlink_kernel_create" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "netlink_kernel_release" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "netlink_rcv_skb" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "nla_put" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "init_net" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "netlink_dump_start" [drivers/infiniband/core/ib_core.ko] undefined!
> ERROR: "skb_put" [drivers/infiniband/core/ib_core.ko] undefined!
Guess we have to depend on CONFIG_NET now.
I'll fix it up.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [PATCH v3 1/1] igmp: call ip_mc_clear_src() only when we have no users of ip_mc_list
From: David Stevens @ 2011-05-23 17:41 UTC (permalink / raw)
To: Veaceslav Falico
Cc: David Miller, jmorris, kaber, kuznet, linux-kernel, mmarek,
netdev, netdev-owner, pekkas, yoshfuji
In-Reply-To: <20110520162709.GA3497@darkmag.usersys.redhat.com>
netdev-owner@vger.kernel.org wrote on 05/20/2011 09:27:09 AM:
> From: Veaceslav Falico <vfalico@redhat.com>
Looks ok to me:
Acked-by: David L Stevens <dlstevens@us.ibm.com>
>
> So, does this patch seem ok? If yes, I'll send it with the changelog.
>
> ---
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index 1fd3d9c..57ca93a 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -1169,20 +1169,18 @@ static void igmp_group_dropped(struct ip_mc_list
*im)
>
> if (!in_dev->dead) {
> if (IGMP_V1_SEEN(in_dev))
> - goto done;
> + return;
> if (IGMP_V2_SEEN(in_dev)) {
> if (reporter)
> igmp_send_report(in_dev, im, IGMP_HOST_LEAVE_MESSAGE);
> - goto done;
> + return;
> }
> /* IGMPv3 */
> igmpv3_add_delrec(in_dev, im);
>
> igmp_ifc_event(in_dev);
> }
> -done:
> #endif
> - ip_mc_clear_src(im);
> }
>
> static void igmp_group_added(struct ip_mc_list *im)
> @@ -1319,6 +1317,7 @@ void ip_mc_dec_group(struct in_device *in_dev,
> __be32 addr)
> *ip = i->next_rcu;
> in_dev->mc_count--;
> igmp_group_dropped(i);
> + ip_mc_clear_src(i);
>
> if (!in_dev->dead)
> ip_rt_multicast_event(in_dev);
> @@ -1428,7 +1427,8 @@ void ip_mc_destroy_dev(struct in_device *in_dev)
> in_dev->mc_list = i->next_rcu;
> in_dev->mc_count--;
>
> - igmp_group_dropped(i);
> + /* We've dropped the groups in ip_mc_down already */
> + ip_mc_clear_src(i);
> ip_ma_put(i);
> }
> }
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* DEAR WINNER
From: cocacola@4florencehomes.com @ 2011-05-23 16:45 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 27 bytes --]
KINDLY DOWNLOAD ATTACHMENT
[-- Attachment #2: COCA COLA NOTIFICATION.txt --]
[-- Type: application/octet-stream, Size: 873 bytes --]
DEPT COCA-COLA AVENUE
STAMFORD BRIDGE LONDON.
SW1V 3DW UNITED KINGDOM
Attention Winner
This email is to notify you that your email address was
randomly selected and entered into our free Third Category
draws.You have subsequently emerged a winner and therefore
entitled to a substantial amount of 1,000,000.00 Great British
Pounds.kindly confirm receipt of this email, by forwarding
Your Details to the claims department.
Name: Tommy Roger
Email:claimsgroup222@hotmail.co.uk
IMPORTANT FILL OUT THIS WINNERS VERIFICATION FORM BELOW:
FULL NAMES----------
DATE OF BIRTH---------
SEX.----------------
CONTACT ADDRESS----------
COUNTRY--------------------
MOBILE NUMBER--------------
OCCUPATION----------
E-MAIL I.D
Congratulations once again.
Dr. Ian Hill.
Online Co-coordinator
The Coca-Cola Company. Copy Right 2011 All Right Reserve
^ permalink raw reply
* Re: linux-next: Tree for May 23 (infiniband + netlink)
From: Randy Dunlap @ 2011-05-23 16:42 UTC (permalink / raw)
To: Stephen Rothwell, netdev; +Cc: linux-next, LKML, linux-rdma
In-Reply-To: <20110523154518.5e27cfb0.sfr@canb.auug.org.au>
On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20110520:
when CONFIG_NET is not enabled:
ERROR: "skb_trim" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "netlink_kernel_create" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "netlink_kernel_release" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "netlink_rcv_skb" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "nla_put" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "init_net" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "netlink_dump_start" [drivers/infiniband/core/ib_core.ko] undefined!
ERROR: "skb_put" [drivers/infiniband/core/ib_core.ko] undefined!
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR
From: Ben Greear @ 2011-05-23 16:33 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Jiri Pirko, Nicolas de Pesloüan, Changli Gao,
netdev, shemminger, kaber, fubar, eric.dumazet, andy, Jesse Gross
In-Reply-To: <m1y61x94g1.fsf@fess.ebiederm.org>
On 05/23/2011 02:00 AM, Eric W. Biederman wrote:
> Ben Greear<greearb@candelatech.com> writes:
>
>> I believe we have been getting tagged VLAN packets properly
>> in our test cases. We would not be creating any VLAN devices
>> in this case, so perhaps the NIC isn't doing any stripping.
>>
>> To me, it seems like we should get the fully tagged packet
>> without having to go muck with aux-data, though it would
>> be fine if it were *also* in aux-data.
>
> Given that pf_packet is a portable interface that works on multiple OS's
> I tend to agree. Certainly my users would be happier if they don't
> have to change their code and not having to change tcpdump would
> also be nice.
>
> I'm not certain exactly where in the code it makes sense to put the
> vlan header back on for pf_packet sockets. The simplest thing would
> be just before we run the socket filter. If we don't do the simplest
> thing this raises the question how do we avoid breaking socket filters
> that look at the packet data and know there is going to be a vlan
> header there.
That is going to be tricky, since the VLAN header would adjust
offsets and users could be using some filter that uses offsets
with no actual mention of VLANs (but expecting it to take
the VLAN header into account).
> Still the current situation is better than seeing vlan 0 tagged packets
> twice.
>
> My gut feel says if we can cheaply get the socket filters to act like it
> sees the vlan tag (where the vlan tag belongs) we should not actually
> put the vlan tag back on until we copy the packet to userspace.
Maybe keep a count of how many sockets with filters and/or pf_packet
sockets are open, and how many things are registered in
the 'ptype_all' chain, and only re-add (or never remove) the header if that is > 0?
(And, let the bridging and other kernel logic deal with vlans
via auxillary methods as well as checking in-line headers.)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH]net:8021q:vlan.c Fix pr_info to read on line in the syslog.
From: Joe Perches @ 2011-05-23 16:23 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: netdev, davem, linux-kernel
In-Reply-To: <1306166698-2036-1-git-send-email-justinmattock@gmail.com>
On Mon, 2011-05-23 at 09:04 -0700, Justin P. Mattock wrote:
> The patch below changes the pr_info so that it reads on one line in the syslog
> rather than two.
>
> before:
>
> [ 30.438203] 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
> [ 30.441542] All bugs added by David S. Miller <davem@redhat.com>
>
>
> after:
> [ 29.356282] 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> All bugs added by: David S. Miller <davem@redhat.com>
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> net/8021q/vlan.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index b2274d1..02f4d8b 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -673,8 +673,8 @@ static int __init vlan_proto_init(void)
> {
> int err;
>
> - pr_info("%s v%s %s\n", vlan_fullname, vlan_version, vlan_copyright);
> - pr_info("All bugs added by %s\n", vlan_buggyright);
> + pr_info("%s v%s %s All bugs added by: %s\n", vlan_fullname, vlan_version,
> + vlan_copyright, vlan_buggyright);
Might as well avoid the format string then too.
pr_info(vlan_fullname " v" vlan_version " " vlan_copyright
" All bugs added by: " vlan_buggyright "\n");
or just kill the otherwise unused vlan_<foo> variables
pr_info("802.1Q VLAN Support v" vlan_version
" Ben Greear <greearb@candelatech.com>"
" All bugs added by: David S. Miller <davem@redhat.com>\n");
though I think that emitting names on startup isn't necessary and
this is enough:
pr_info("802.1Q VLAN Support v" vlan_version "\n");
^ permalink raw reply
* [PATCH]net:8021q:vlan.c Fix pr_info to read on line in the syslog.
From: Justin P. Mattock @ 2011-05-23 16:04 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-kernel, Justin P. Mattock
The patch below changes the pr_info so that it reads on one line in the syslog
rather than two.
before:
[ 30.438203] 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
[ 30.441542] All bugs added by David S. Miller <davem@redhat.com>
after:
[ 29.356282] 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> All bugs added by: David S. Miller <davem@redhat.com>
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
net/8021q/vlan.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index b2274d1..02f4d8b 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -673,8 +673,8 @@ static int __init vlan_proto_init(void)
{
int err;
- pr_info("%s v%s %s\n", vlan_fullname, vlan_version, vlan_copyright);
- pr_info("All bugs added by %s\n", vlan_buggyright);
+ pr_info("%s v%s %s All bugs added by: %s\n", vlan_fullname, vlan_version,
+ vlan_copyright, vlan_buggyright);
err = register_pernet_subsys(&vlan_net_ops);
if (err < 0)
--
1.7.5.1
^ permalink raw reply related
* Re: [PATCH] be2net: hash key for rss-config cmd not set
From: Ben Hutchings @ 2011-05-23 15:48 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <249a7eac-6aa7-481d-b7b0-a2a3b144963f@exht1.ad.emulex.com>
On Mon, 2011-05-23 at 17:55 +0530, Sathya Perla wrote:
> Need a random hash key to effectively hash incoming connections into
> multiple RX rings.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/benet/be_cmds.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
> index 2463b1c..81654ae 100644
> --- a/drivers/net/benet/be_cmds.c
> +++ b/drivers/net/benet/be_cmds.c
> @@ -1703,7 +1703,8 @@ int be_cmd_rss_config(struct be_adapter *adapter, u8 *rsstable, u16 table_size)
> {
> struct be_mcc_wrb *wrb;
> struct be_cmd_req_rss_config *req;
> - u32 myhash[10];
/* Chosen by a fair dice roll */ ?
> + u32 myhash[10] = {0x0123, 0x4567, 0x89AB, 0xCDEF, 0x01EF,
> + 0x0123, 0x4567, 0x89AB, 0xCDEF, 0x01EF};
> int status;
>
> if (mutex_lock_interruptible(&adapter->mbox_lock))
This is of course less random than the stack garbage you were presumably
using before. Though I don't know to what extent random hash keys are
really a good idea.
I have heard the suggestion that Toeplitz hash keys should in fact be
randomised per-system, so that flows will be hashed to the same queue
numbers on each interface if their hash indirection tales are also the
same. This would presumably be good for bonding with multiple active
links, forwarding, etc., especially when multiple drivers (which
currently have different behaviour) are involved.
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: Pushing the new FW to firmware git
From: David Woodhouse @ 2011-05-23 15:48 UTC (permalink / raw)
To: Vlad Zolotarov; +Cc: netdev@vger.kernel.org
In-Reply-To: <201105231813.00751.vladz@broadcom.com>
On Mon, 2011-05-23 at 18:12 +0300, Vlad Zolotarov wrote:
> David, could u, pls., clarify about the exact procedure of pushing the new FW
> to the firwmware git: when exactly the new firware is going to be fetched to
> the kernel tree?
>
> I'm asking it because I am going to submit a patch that introduces a new FW
> and the new code will simply not work with an old FW.
OK, so the new firmware gets a new filename, and you submit the new
firmware to the linux-firmware.git tree at the same time as you submit
the code changes to the kernel tree.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] ipv6: xfrm6: fix dubious code
From: Ben Hutchings @ 2011-05-23 15:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1306140167.2869.8.camel@edumazet-laptop>
On Mon, 2011-05-23 at 10:42 +0200, Eric Dumazet wrote:
> net/ipv6/xfrm6_tunnel.c: In function ‘xfrm6_tunnel_rcv’:
> net/ipv6/xfrm6_tunnel.c:244:53: warning: the omitted middle operand
> in ?: will always be ‘true’, suggest explicit middle operand
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv6/xfrm6_tunnel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c
> index a6770a0..fb9b0c3 100644
> --- a/net/ipv6/xfrm6_tunnel.c
> +++ b/net/ipv6/xfrm6_tunnel.c
> @@ -241,7 +241,7 @@ static int xfrm6_tunnel_rcv(struct sk_buff *skb)
> __be32 spi;
>
> spi = xfrm6_tunnel_spi_lookup(net, (const xfrm_address_t *)&iph->saddr);
> - return xfrm6_rcv_spi(skb, IPPROTO_IPV6, spi) > 0 ? : 0;
> + return xfrm6_rcv_spi(skb, IPPROTO_IPV6, spi) > 0 ? 1 : 0;
> }
>
> static int xfrm6_tunnel_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
I suspect that this was intended to return the result of xfrm6_rcv_spi()
if > 0. But if it really is intended to return the result of the
inequality, then the '?:' operation is not needed at all.
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
* CPU instruction to calculate tcp checksum and udp integrity?
From: Jon Zhou @ 2011-05-23 15:26 UTC (permalink / raw)
To: netdev@vger.kernel.org, kernelnewbies@kernelnewbies.org
[-- Attachment #1.1: Type: text/plain, Size: 150 bytes --]
hi
now I am using sw to calculate the tcp checksum, is there CPU(nehalem) instruction or NIC /kernel API to do such thing?
thanks a lot
jon
[-- Attachment #1.2: Type: text/html, Size: 964 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply
* Re: [Patch 3/3] net: rename NETDEV_BONDING_DESLAVE to NETDEV_RELEASE
From: Andy Gospodarek @ 2011-05-23 15:17 UTC (permalink / raw)
To: Amerigo Wang; +Cc: netdev, Andy Gospodarek, Neil Horman
In-Reply-To: <1305877152-30970-3-git-send-email-amwang@redhat.com>
On Fri, May 20, 2011 at 03:39:12PM +0800, Amerigo Wang wrote:
> s/NETDEV_BONDING_DESLAVE/NETDEV_RELEASE/ as Andy suggested.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: Andy Gospodarek <andy@greyhouse.net>
> Cc: Neil Horman <nhorman@redhat.com>
>
I know Dave already applied it (so I won't bother with a signed-off-by
line), but thanks for doing this.
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Andy Gospodarek @ 2011-05-23 15:13 UTC (permalink / raw)
To: Américo Wang
Cc: Linux Kernel Network Developers, David Miller, Jay Vosburgh,
Andy Gospodarek
In-Reply-To: <BANLkTimkxi0BofJYv_tRj8Et+OZFu+VfBw@mail.gmail.com>
On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
> Hello, Jay, Andy,
>
> Is there any peculiar reason that bonding code has to stay
> in drivers/net/ directory?
>
> Since bonding and bridge are somewhat similar, both of
> which are used to "bond" two or more devices into one,
> and bridge code is already in net/bridge/, so I think it also
> makes sense to move bonding code into net/bonding/ too.
>
> This could also help to grep the source more easily. :)
>
> What do you think about the patch below?
> (Note, this patch is against net-next-2.6.)
>
I would rather keep the code for bonding in drivers/net since it is
really a pure device (though not directly tied to any specific
hardware) rather than a device + forwarding or management code.
It has bothered me for a long time that the code just to manage the VLAN
and bridge devices sits outside of drivers/net, but I've never proposed
a patch to move the files as I suspect the maintainers of that code
would like to keep it all together. Maybe it is time to do that.
^ permalink raw reply
* Pushing the new FW to firmware git
From: Vlad Zolotarov @ 2011-05-23 15:12 UTC (permalink / raw)
To: David Woodhouse, netdev@vger.kernel.org
David, could u, pls., clarify about the exact procedure of pushing the new FW
to the firwmware git: when exactly the new firware is going to be fetched to
the kernel tree?
I'm asking it because I am going to submit a patch that introduces a new FW
and the new code will simply not work with an old FW.
Thanks in advance,
vlad
^ permalink raw reply
* Re: 2.6.38.x, 2.6.39 sfq? kernel panic in sfq_enqueue
From: Eric Dumazet @ 2011-05-23 15:05 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev, hadi
In-Reply-To: <47b6835144d208dca4c6675f6510fcad@visp.net.lb>
Le lundi 23 mai 2011 à 17:27 +0300, Denys Fedoryshchenko a écrit :
> > Thanks !
> By objdump or he must recompile kernel with DEBUG_INFO and use gdb?
>
>
>
Just objdump of sch_sfq.o (or sch_sfq.ko) file, (to keep existing
offsets), thanks
^ permalink raw reply
* Re: 2.6.38.x, 2.6.39 sfq? kernel panic in sfq_enqueue
From: Denys Fedoryshchenko @ 2011-05-23 14:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, hadi
In-Reply-To: <1306155058.20687.8.camel@edumazet-laptop>
On Mon, 23 May 2011 14:50:58 +0200, Eric Dumazet wrote:
>
> Oh well, false alarm, I am still trying to understand the case.
>
> Some other reports would be appreciated, because here is the strange
> thing :
>
> [ 4461.969603] Code: b6 70 10
> 3b b3 08 01 00 00
> 0f 8d df 01 00 00 jge ....
>
> 41 8b 74 24 28 mov 0x28(%r12),%esi qdisc_pkt_len(skb)
> 01 b3 b4 00 00 00 sch->qstats.backlog +=
> qdisc_pkt_len(skb);
>
> RAX = slot
> R12 = SKB
>
> 48 8b 70 08 mov 0x8(%rax),%rsi slot->skblist_prev
> 49 89 04 24 mov %rax,(%r12) skb->next = (struct
> sk_buff *)slot;
> 49 89 74 24 08 mov %rsi,0x8(%r12) skb->prev =
> slot->skblist_prev;
> 48 8b 70 08 mov 0x8(%rax),%rsi slot->skblist_prev
> (refetch)
>
> <4c> 89 26 mov %r12,(%rsi) slot->skblist_prev->next
> = skb; // CRASH
>
> 0f b6 f2 movzbl %dl,%esi
> 4c 89 60 08 mov %r12,0x8(%rax) slot->skblist_prev =
> skb;
> 48 8d 3c 76 lea
> 48 8d bc fb 90 01 00
>
>
>
> And in your report RAX = R12 !!! (ffff8801172a7d08) I cant see how it
> can happen (Its not even a valid skb address, since an SKB should be
> 64bytes aligned)
>
> If available a disassembly of sfq_enqueue() would be appreciated too
> ;)
>
> Thanks !
By objdump or he must recompile kernel with DEBUG_INFO and use gdb?
^ permalink raw reply
* [PATCH] ethtool: mask out FLOW_EXT
From: Sebastian Pöhn @ 2011-05-23 13:53 UTC (permalink / raw)
To: netdev; +Cc: sebastian.poehn, bhutchings
Sorry for the disclaimer the last time!
The FLOW_EXT bit must be masked out. Otherwise if e.g. vlan is set a
driver receiving the ntuple may not detect the flow_type correctly!
Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
---
diff --git a/ethtool.c b/ethtool.c
index 34fe107..0b7ec05 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -3134,6 +3134,9 @@ static int flow_spec_to_ntuple(struct
ethtool_rx_flow_spec *fsp,
(u64)ntohl(~fsp->m_ext.data[1]);
}
}
+
+ /*Mask out the extended bit, because ntuple does not know it!*/
+ ntuple->flow_type &= ~FLOW_EXT;
return 0;
}
^ permalink raw reply related
* [PATCH] ethtool: Add support for 20G link speed
From: Yaniv Rosner @ 2011-05-23 13:38 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev@vger.kernel.org, eilong
Add support for 20G link speed
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
---
ethtool-copy.h | 5 +++++
ethtool.c | 18 +++++++++++++++++-
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 22215e9..c02a98b 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -749,6 +749,8 @@ enum ethtool_sfeatures_retval_bits {
#define SUPPORTED_10000baseKX4_Full (1 << 18)
#define SUPPORTED_10000baseKR_Full (1 << 19)
#define SUPPORTED_10000baseR_FEC (1 << 20)
+#define SUPPORTED_20000baseMLD2_Full (1 << 21)
+#define SUPPORTED_20000baseKR2_Full (1 << 22)
/* Indicates what features are advertised by the interface. */
#define ADVERTISED_10baseT_Half (1 << 0)
@@ -772,6 +774,9 @@ enum ethtool_sfeatures_retval_bits {
#define ADVERTISED_10000baseKX4_Full (1 << 18)
#define ADVERTISED_10000baseKR_Full (1 << 19)
#define ADVERTISED_10000baseR_FEC (1 << 20)
+#define ADVERTISED_20000baseMLD2_Full (1 << 21)
+#define ADVERTISED_20000baseKR2_Full (1 << 22)
+
/* The following are all involved in forcing a particular link
* mode for the device for setting things. When getting the
diff --git a/ethtool.c b/ethtool.c
index cfdac65..a099a23 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1238,6 +1238,20 @@ static void dump_supported(struct ethtool_cmd *ep)
if (mask & SUPPORTED_10000baseT_Full) {
did1++; fprintf(stdout, "10000baseT/Full ");
}
+ if (did1 && (mask & SUPPORTED_20000baseMLD2_Full)) {
+ fprintf(stdout, "\n");
+ fprintf(stdout, " ");
+ }
+ if (mask & SUPPORTED_20000baseMLD2_Full) {
+ did1++; fprintf(stdout, "20000baseMLD2/Full ");
+ }
+ if (did1 && (mask & SUPPORTED_20000baseKR2_Full)) {
+ fprintf(stdout, "\n");
+ fprintf(stdout, " ");
+ }
+ if (mask & SUPPORTED_20000baseKR2_Full) {
+ did1++; fprintf(stdout, "20000baseKR2/Full ");
+ }
fprintf(stdout, "\n");
fprintf(stdout, " Supports auto-negotiation: ");
@@ -2581,7 +2595,9 @@ static int do_sset(int fd, struct ifreq *ifr)
ADVERTISED_1000baseT_Half |
ADVERTISED_1000baseT_Full |
ADVERTISED_2500baseX_Full |
- ADVERTISED_10000baseT_Full);
+ ADVERTISED_10000baseT_Full |
+ ADVERTISED_20000baseMLD2_Full |
+ ADVERTISED_20000baseKR2_Full);
} else if (advertising_wanted > 0) {
ecmd.advertising = advertising_wanted;
}
--
1.7.1
^ permalink raw reply related
* [PATCH] ehea: Fix multicast registration on semi-promiscuous mode
From: leitao @ 2011-05-23 13:36 UTC (permalink / raw)
To: davem; +Cc: netdev, Breno Leitao
In-Reply-To: <20110520.162801.1310159491178676084.davem@davemloft.net>
Ehea will not register multicast groups in phyp if the physical
interface is in promiscuous mode. But it should register if the
logical port is in promiscuous mode, but the physical port is not.
Ehea physical promiscuous mode is defined by ehea_port->promisc,
while logical port is defined by IFF_PROMISC.
So currently, if the user set the interface in promiscuous mode,
IGMP will not be registred in PHYP, and PHYP will never pass
the multicast packet to the logical port, which is bad
So, this patch just fixes it, assuring that we register in phyp
if the physical port is not on promiscuous mode.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
---
drivers/net/ehea/ehea_main.c | 2 +-
drivers/tty/serial/8250.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index cf79cf7..80027be 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2082,7 +2082,7 @@ static void ehea_set_multicast_list(struct net_device *dev)
struct netdev_hw_addr *ha;
int ret;
- if (dev->flags & IFF_PROMISC) {
+ if (port->promisc) {
ehea_promiscuous(dev, 1);
return;
}
--
1.7.1
^ permalink raw reply related
* Re: [v3 00/39] faster tree-based sysctl implementation
From: Lucian Adrian Grijincu @ 2011-05-23 13:26 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, netdev, Alexey Dobriyan, Octavian Purdila,
David S . Miller
In-Reply-To: <m1mxid7of6.fsf@fess.ebiederm.org>
On Mon, May 23, 2011 at 12:32 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Mostly it is simplicity. There is also the fact that the spin lock is
> used in the implementation of something that is essentially a
> reader/writer lock already.
The amount of time in which the spin lock is held in the current
implementation can be quite large: in __register_sysctl_paths:
https://github.com/mirrors/linux-2.6/blob/v2.6.39/kernel/sysctl.c#L1887
spin_lock(&sysctl_lock);
for (set = header->set; set; set = set->parent)
list_for_each_entry(p, &set->list, ctl_entry)
try_attach(p, header);
spin_unlock(&sysctl_lock);
For N=10^5 headers and try_attach=O(N) it's not a very good locking mechanism.
That's why I opted for a rwlock for each dir's subdirs/tables.
> In that context I'm not certain I am comfortable with separating proc
> inode usage from other proc usage. But I haven't read through that
> section of your code well enough yet to tell if you are making sense.
Proc inode usage (->count) was already separate from other proc usage (->use).
It was not separate from other header references (shared in ->count).
I separated the two because when I call unregister on a header I need
to decide whether to really unregister it (->unregistering=true and no
one can see this header and anything under it any more) or just
decrement a reference.
In the current implementation a header is only created by a
__register_sysctl_paths call and it's clear that at unregister we have
to set ->unregistering.
In my implementation headers are created dynamically to create new
directory elements. I need to know when to unregister such a header
regardless of any possible procfs inode references.
https://github.com/luciang/linux-2.6-new-sysctl/blob/v4-new-sysctl-alg/kernel/sysctl.c#L2390
I pushed a new version:
git://github.com/luciang/linux-2.6-new-sysctl.git v4-new-sysctl-alg
I undid int->u8 for ctl_procfs_refs.
I left the ->permissions hook get it's namespace form current->
because rewriting history for that change trips on too many patches
and a new parameter can be very easily added later when needed. Hope
this is ok with you.
I'd like to send patches for review to archs/drivers/etc. that
register only tables of files, not whole sysctl trees.
The patches don't depend on anything from this series.
Examples:
* http://thread.gmane.org/gmane.linux.kernel/1137032/focus=1137089
* http://thread.gmane.org/gmane.linux.kernel/1137032/focus=1137087
I'd like an OK-GO from you.
--
.
..: Lucian
^ 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