* Re: [PATCH 07/10] RDMA/cxgb4: DB Drop Recovery for RDMA and LLD queues.
From: David Miller @ 2011-10-24 21:12 UTC (permalink / raw)
To: vipul-ut6Up61K2wZBDgjK7y7TUQ
Cc: swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW,
roland-BHEL68pLQRGGvPXPguhicg, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, divy-ut6Up61K2wZBDgjK7y7TUQ,
dm-ut6Up61K2wZBDgjK7y7TUQ, kumaras-ut6Up61K2wZBDgjK7y7TUQ
In-Reply-To: <4EA5814F.6080801-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
From: Vipul Pandya <vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Date: Mon, 24 Oct 2011 20:46:31 +0530
> 1. We would like to recommend that all the patches get included in
> Roland's infiniband tree since it has build dependencies.
This is fine with me. It just means that Roland's tree has to have
net-next included in it already, because otherwise the paths to
the cxgb4 driver under drivers/net won't be right.
--
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: Kernel driver r8169 not working for Realtek 8111E onboard network card
From: Francois Romieu @ 2011-10-24 21:10 UTC (permalink / raw)
To: Adrian George Sav; +Cc: netdev@vger.kernel.org
In-Reply-To: <1319482444.38178.YahooMailNeo@web161917.mail.bf1.yahoo.com>
Adrian George Sav <adi_sav@yahoo.com> :
> I don't know what you mean by "current -rc", the release candidate version
> of the kernel or maybe of the driver ?
Recent 3.1-rc kernel. You can go with 3.1 now.
[...]
> Trying to solve this, I installed the latest version of ubuntu, because I
> saw it has a new kernel, 3.0.0.12, but no improvement.
See below.
[...]
> [ 0.000000] Linux version 3.0.0-12-generic (buildd@vernadsky) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 (Ubuntu 3.0.0-12.20-generic 3.0.4)
[...]
> [ 1.893490] r8169 0000:07:00.0: eth0: RTL8168b/8111b at 0xf802e000, f4:6d:04:40:36:6f, XID 0c900800 IRQ 48
^^^^^^^^^^^^^^
If it was recent enough, the kernel would say "RTL8168evl/8111evl".
If you want to use jumbo frames, you will have to use David Miller's -next
branch or wait for 3.1-rc1.
--
Ueimor
^ permalink raw reply
* Re: Bug#645308: tg3 broken for NetXtreme 5714S in squeeze 6.0.3 installer
From: Matt Carlson @ 2011-10-24 21:24 UTC (permalink / raw)
To: Ben Hutchings
Cc: Matthew Carlson, Michael Chan, 645308@bugs.debian.org, Marc Haber,
netdev
In-Reply-To: <1319199579.2918.42.camel@deadeye>
On Fri, Oct 21, 2011 at 05:19:39AM -0700, Ben Hutchings wrote:
> On Fri, 2011-10-21 at 11:08 +0200, Marc Haber wrote:
> > On Fri, Oct 21, 2011 at 11:00:46AM +0200, Marc Haber wrote:
> > > On Thu, Oct 20, 2011 at 05:28:34AM +0100, Ben Hutchings wrote:
> > > > I don't see any changes that would obviously change the way this device
> > > > is reconfigured during a down/up cycle. There were some changes to
> > > > power management that should just let the PCI core do some work that the
> > > > driver used to, but it's possible that the result isn't quite the same.
> > > > I built a module with those reverted; source and binary attached. Could
> > > > you test that? I checked that d-i does include an insmod command.
> > >
> > > The squeeze 6.0.3 installer with the shipped tg3.ko replaced with
> > > yours boots and networks just fine without any workaround and without
> > > manual interaction.
> >
> > I was a bit fast on that. The interface now fails right in the middle
> > of installation and needs the modprobe -r, modprobe stunt to network
> > again.
>
> Matt, Michael,
>
> The tg3 driver has regressed for the 5714S since Linux 2.6.32. Marc
> Haber found this in the backported version included in our stable
> update, but also confirmed it in Linux 3.0.
>
> Bringing the interface down and then up again (which the installer does
> for some reason) can leave it unable to pass traffic (possibly after
> working for a few packets) until the module is reloaded.
>
> I asked Marc to check whether reverting the power management changes
> (071697e2bcd8dff2af4d6fdd6525c2324f89553b,
> d237d9ecf06a00f0ebca657958cf2a1e92940796) made a difference, but it
> doesn't seem to.
>
> There is more information in the bug log at
> <http://bugs.debian.org/645308>.
Where can I get the sources for this driver? Commit
9e975cc291d80d5e4562d6bed15ec171e896d69b, entitled
"tg3: Fix io failures after chip reset" has been a common source of
problems.
^ permalink raw reply
* Re: [PATCH] TCP: remove TCP_DEBUG
From: David Miller @ 2011-10-24 21:35 UTC (permalink / raw)
To: fbl; +Cc: netdev, dpmcgee, kuznet, jmorris, yoshfuji, kaber, linux-kernel
In-Reply-To: <1319480110-20361-1-git-send-email-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Mon, 24 Oct 2011 16:15:10 -0200
> It was enabled by default and the messages guarded
> by the define are useful.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
Applied, thanks Flavio.
^ permalink raw reply
* RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
From: Rose, Gregory V @ 2011-10-24 21:51 UTC (permalink / raw)
To: Roopa Prabhu, Michael S. Tsirkin
Cc: netdev@vger.kernel.org, sri@us.ibm.com, dragos.tatulea@gmail.com,
arnd@arndb.de, kvm@vger.kernel.org, davem@davemloft.net,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <CACAF939.37AAD%roprabhu@cisco.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Roopa Prabhu
> Sent: Monday, October 24, 2011 11:15 AM
> To: Michael S. Tsirkin
> Cc: netdev@vger.kernel.org; sri@us.ibm.com; dragos.tatulea@gmail.com;
> arnd@arndb.de; kvm@vger.kernel.org; davem@davemloft.net;
> mchan@broadcom.com; dwang2@cisco.com; shemminger@vyatta.com;
> eric.dumazet@gmail.com; kaber@trash.net; benve@cisco.com; Rose, Gregory V
> Subject: Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address
> filtering support for passthru mode
>
> On 10/23/11 10:47 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> >> AFAIK, there is no netdev interface to install per queue hw
> >> filters for a multi queue interface. And also I dont know of any hw
> >> that provides an interface to set hw filters on a per queue basis.
> >
> > VMDq hardware would support this, no?
> >
> Am not really sure. This patch uses netdev to pass filters to hw. And I
> don't see any netdev infrastructure that would support per queue filters.
> Maybe Greg (CC'ed) or anyone else from Intel can answer this.
> Greg, michael had brought up this question during first version of these
> patches as well. Will be nice to get the VMDq requirements for propagating
> guest filters to hw clarified. Do you see any special VMDq nic requirement
> we can cover in this patch. This is for VMDq queues directly connected to
> guest nics. Thanks.
So far as I know there is no support for VMDq in the Linux kernel and while I know some folks have been working on it I can't really speak to that work or their plans. Much would depend on the implementation.
For now it makes sense to me to get support for multiple MAC and VLAN filters per virtual function (or virtual nic) and it seems to me you're going in the right direction for this. We'll have a look at your next set of patches and take it from there.
- Greg
^ permalink raw reply
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Bradley Peterson @ 2011-10-24 21:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: e1000-devel, netdev, Bruce Allan, Jesse Brandeburg, John Ronciak
In-Reply-To: <1318910393.2571.47.camel@edumazet-laptop>
On Mon, Oct 17, 2011 at 10:59 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 18 octobre 2011 à 05:51 +0200, Eric Dumazet a écrit :
>> Le mardi 18 octobre 2011 à 04:24 +0200, Eric Dumazet a écrit :
>>
>> > diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
>> > index eae542a..d0197e3 100644
>> > --- a/drivers/net/ppp/pptp.c
>> > +++ b/drivers/net/ppp/pptp.c
>> > @@ -305,11 +305,16 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
>> > }
>> >
>> > header = (struct pptp_gre_header *)(skb->data);
>> > + headersize = sizeof(*header);
>> >
>> > /* test if acknowledgement present */
>> > if (PPTP_GRE_IS_A(header->ver)) {
>> > - __u32 ack = (PPTP_GRE_IS_S(header->flags)) ?
>> > - header->ack : header->seq; /* ack in different place if S = 0 */
>> > + __u32 ack;
>> > +
>> > + if (!pskb_may_pull(skb, headersize))
>> > + goto drop;
>>
>> Oh well, this is buggy, I need to set header again, I'll send an updated
>> patch
>>
>
> [PATCH v2] pptp: pptp_rcv_core() misses pskb_may_pull() call
>
> e1000e uses paged frags, so any layer incorrectly pulling bytes from skb
> can trigger a BUG in skb_pull()
>
> [951.142737] [<ffffffff813d2f36>] skb_pull+0x15/0x17
> [951.142737] [<ffffffffa0286824>] pptp_rcv_core+0x126/0x19a [pptp]
> [951.152725] [<ffffffff813d17c4>] sk_receive_skb+0x69/0x105
> [951.163558] [<ffffffffa0286993>] pptp_rcv+0xc8/0xdc [pptp]
> [951.165092] [<ffffffffa02800a3>] gre_rcv+0x62/0x75 [gre]
> [951.165092] [<ffffffff81410784>] ip_local_deliver_finish+0x150/0x1c1
> [951.177599] [<ffffffff81410634>] ? ip_local_deliver_finish+0x0/0x1c1
> [951.177599] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> [951.177599] [<ffffffff81410996>] ip_local_deliver+0x51/0x55
> [951.177599] [<ffffffff814105b9>] ip_rcv_finish+0x31a/0x33e
> [951.177599] [<ffffffff8141029f>] ? ip_rcv_finish+0x0/0x33e
> [951.204898] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> [951.214651] [<ffffffff81410bb5>] ip_rcv+0x21b/0x246
>
> pptp_rcv_core() is a nice example of a function assuming everything it
> needs is available in skb head.
>
> Reported-by: Bradley Peterson <despite@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> drivers/net/ppp/pptp.c | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
> index eae542a..29730fd 100644
> --- a/drivers/net/ppp/pptp.c
> +++ b/drivers/net/ppp/pptp.c
> @@ -305,11 +305,18 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
> }
>
> header = (struct pptp_gre_header *)(skb->data);
> + headersize = sizeof(*header);
>
> /* test if acknowledgement present */
> if (PPTP_GRE_IS_A(header->ver)) {
> - __u32 ack = (PPTP_GRE_IS_S(header->flags)) ?
> - header->ack : header->seq; /* ack in different place if S = 0 */
> + __u32 ack;
> +
> + if (!pskb_may_pull(skb, headersize))
> + goto drop;
> + header = (struct pptp_gre_header *)(skb->data);
> +
> + /* ack in different place if S = 0 */
> + ack = PPTP_GRE_IS_S(header->flags) ? header->ack : header->seq;
>
> ack = ntohl(ack);
>
> @@ -318,21 +325,18 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
> /* also handle sequence number wrap-around */
> if (WRAPPED(ack, opt->ack_recv))
> opt->ack_recv = ack;
> + } else {
> + headersize -= sizeof(header->ack);
> }
> -
> /* test if payload present */
> if (!PPTP_GRE_IS_S(header->flags))
> goto drop;
>
> - headersize = sizeof(*header);
> payload_len = ntohs(header->payload_len);
> seq = ntohl(header->seq);
>
> - /* no ack present? */
> - if (!PPTP_GRE_IS_A(header->ver))
> - headersize -= sizeof(header->ack);
> /* check for incomplete packet (length smaller than expected) */
> - if (skb->len - headersize < payload_len)
> + if (!pskb_may_pull(skb, headersize + payload_len))
> goto drop;
>
> payload = skb->data + headersize;
>
>
>
This patch has been working for me. 5 days uptime, with no crashes.
Thanks for your help!
Bradley Peterson
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH] caif: fix cfcnfg_add_phy_layer() leaks
From: Jesper Juhl @ 2011-10-24 22:01 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David S. Miller, Sjur Braendeland
There are two locations where we 'goto out' after having allocated
memory for 'phyinfo' but have not yet assigned it to anything. At the
'out:' label we'll exit from the function and 'phyinfo' will go out of
scope and thus we leak the memory we allocated.
This patch frees the memory before jumping to 'out:', thus fixing the
leaks.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
net/caif/cfcnfg.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
compile tested only.
diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
index 52fe33b..b25dc02 100644
--- a/net/caif/cfcnfg.c
+++ b/net/caif/cfcnfg.c
@@ -499,6 +499,7 @@ got_phyid:
cfserl_create(CFPHYTYPE_FRAG, phyid, stx);
if (!phy_driver) {
pr_warn("Out of memory\n");
+ kfree(phyinfo);
goto out;
}
break;
@@ -506,6 +507,7 @@ got_phyid:
phy_driver = NULL;
break;
default:
+ kfree(phyinfo);
goto out;
}
phy_layer->id = phyid;
--
1.7.7
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH net-next] w5300: add WIZnet W5300 Ethernet driver
From: David Miller @ 2011-10-24 22:21 UTC (permalink / raw)
To: kth3321; +Cc: linux-kernel, netdev, romieu, suhwan, bongbong
In-Reply-To: <1319272916-5541-1-git-send-email-kth3321@gmail.com>
From: Taehun Kim <kth3321@gmail.com>
Date: Sat, 22 Oct 2011 17:41:56 +0900
> +struct wiz_private {
> + void __iomem *base;
> + struct net_device *dev;
> + u8 rxbuf_conf[MAX_SOCK_NUM];
> + u8 txbuf_conf[MAX_SOCK_NUM];
> + struct net_device_stats stats;
> + struct napi_struct napi;
> + spinlock_t lock;
> + u32 msg_enable;
> +};
You don't need to have a private net_device_stats, just use the
one in struct net_device, and then you can also get rid of your
private ->ndo_get_stats() method.
^ permalink raw reply
* Re: [non-quoted-printable PATCH] Fix caif BUG() with network namespaces
From: David Miller @ 2011-10-24 22:28 UTC (permalink / raw)
To: sjurbren; +Cc: david.woodhouse, netdev
In-Reply-To: <CAJK669ar5ASsX+wEv2EwwaeBoHYtr3Uq+sG1RWroViYGOVgytw@mail.gmail.com>
From: Sjur Brændeland <sjurbren@gmail.com>
Date: Mon, 24 Oct 2011 17:51:54 +0200
> Hi David,
>
>> The caif code will register its own pernet_operations, and then register
>> a netdevice_notifier. Each time the netdevice_notifier is triggered,
>> it'll do some stuff... including a lookup of its own pernet stuff with
>> net_generic().
>>
>> If the net_generic() call ever returns NULL, the caif code will BUG().
>> That doesn't seem *so* unreasonable, I suppose — it does seem like it
>> should never happen.
>>
>> However, it *does* happen. When we clone a network namespace,
>> setup_net() runs through all the pernet_operations one at a time. It
>> gets to loopback before it gets to caif. And loopback_net_init()
>> registers a netdevice... while caif hasn't been initialised. So the caif
>> netdevice notifier triggers, and immediately goes BUG().
>>
>> I'm not entirely sure how best to fix this in the general case. Perhaps
>> the netdevice_notifier registration should be pernet too, rather than
>> global? Or perhaps we should suppress the notifier calls during
>> setup_net() and flush them at the end after everything has been
>> initialised?
>>
>> But really, I'm inclined to just take the simple approach. Make
>> caif_device_notify() *not* go looking for its pernet data structures if
>> the device it's being notified about isn't a caif device in the first
>> place. This simple patch is sufficient to avoid the problem, and is
>> probably good enough.
>> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>
> Thank you for analyzing and fixing this David, this looks good to me.
> Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
David W., the copy that ended up in patchwork was using DOS newlines:
http://patchwork.ozlabs.org/patch/121250/
Click on Download "mbox" to see what I mean.
Can you get your email configuration straightened out before
resubmitting this patch a third time?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/4] be2net: fixes
From: David Miller @ 2011-10-24 22:35 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1319460303-25560-1-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Mon, 24 Oct 2011 18:14:59 +0530
> Pls apply.
>
> Sathya Perla (4):
> be2net: add vlan/rx-mode/flow-control config to be_setup()
> be2net: refactor VF setup/teardown code into be_vf_setup/clear()
> be2net: don't create multiple TXQs in BE2
> be2net: don't create multiple RX/TX rings in multi channel mode
Applied, but many of your commit messages were poorly formatted (lines
exceeding 80 columns) and patches #1 and #2 had several trailing
whitespace errors.
I fixed this all up, but you have to be better than this.
^ permalink raw reply
* Re: |PATCH net-next] tg3: add tx_dropped counter
From: David Miller @ 2011-10-24 22:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, mcarlson, mchan
In-Reply-To: <1319478783.3064.4.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 24 Oct 2011 19:53:03 +0200
> If a frame cant be transmitted, it is silently discarded.
>
> Add a counter to report these errors to user.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] caif: fix cfcnfg_add_phy_layer() leaks
From: David Miller @ 2011-10-24 22:36 UTC (permalink / raw)
To: jj; +Cc: netdev, linux-kernel, sjur.brandeland
In-Reply-To: <alpine.LNX.2.00.1110242359160.19795@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Tue, 25 Oct 2011 00:01:00 +0200 (CEST)
> There are two locations where we 'goto out' after having allocated
> memory for 'phyinfo' but have not yet assigned it to anything. At the
> 'out:' label we'll exit from the function and 'phyinfo' will go out of
> scope and thus we leak the memory we allocated.
>
> This patch frees the memory before jumping to 'out:', thus fixing the
> leaks.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
The code in net-next looks a lot different, please see if the issue
still exists there and resubmit if so, thanks!
^ permalink raw reply
* Re: [PATCH] cls_flow: Add tunnel support to the flow classifier
From: David Miller @ 2011-10-24 22:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: dan, netdev
In-Reply-To: <1319428781.2517.26.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 24 Oct 2011 05:59:41 +0200
> [PATCH net-next] net_sched: cls_flow: use skb_header_pointer()
>
> Dan Siemon would like to add tunnelling support to cls_flow
>
> This preliminary patch introduces use of skb_header_pointer() to help
> this task, while avoiding skb head reallocation because of deep packet
> inspection.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: Do not use routes from locally generated RAs
From: David Miller @ 2011-10-24 22:37 UTC (permalink / raw)
To: andi; +Cc: netdev
In-Reply-To: <1319388071-21323-1-git-send-email-andi@collax.com>
From: Andreas Hofmeister <andi@collax.com>
Date: Sun, 23 Oct 2011 18:41:11 +0200
> When hybrid mode is enabled (accept_ra == 2), the kernel also sees RAs
> generated locally. This is useful since it allows the kernel to auto-configure
> its own interface addresses.
>
> However, if 'accept_ra_defrtr' and/or 'accept_ra_rtr_pref' are set and the
> locally generated RAs announce the default route and/or other route information,
> the kernel happily inserts bogus routes with its own address as gateway.
>
> With this patch, adding routes from an RA will be skiped when the RAs source
> address matches any local address, just as if 'accept_ra_defrtr' and
> 'accept_ra_rtr_pref' were set to 0.
Please make a fresh full resubmission of this patch and add an
appropriate Signed-off-by: tag to your commit message.
Thanks.
^ permalink raw reply
* Account Support !!!
From: Webmail Helpdest Support Centre @ 2011-10-24 22:29 UTC (permalink / raw)
Dear Webmail & Mail Subscriber,
This is to notify you that we are presently working on our webmail & Mail User Accounts
Owner for safety, We are having congestions due to the anonymous
registration of accounts so we are shutting down some accounts that are no more active
and your account might be deleted or suspended within 24 hours for security reasons if
you
do not respond to this mail.
We are sending this email to you so that you can verify and let us know if you still
want to use this account. If you are still interested please confirm your account by
filling the space below.
To complete your account verification, you must reply to ( web.account@gmx.com ) this
email immediately and enter your account details below.
Username: (**************)
Password: (**************)
Date Of Birth(************).
Failure to do this will immediately render your account deactivated from our database.
We apologise for the inconvenience that this will cause you during this period, but
trust you understand that our primary concern is for our customers and for the security
of
their data. our customers are totally secure
Thank you for your understanding.
Copyright ©2011 Webmail Helpdesk Support Centre.
^ permalink raw reply
* [PATCH] ipv6: Do not use routes from locally generated RAs
From: Andreas Hofmeister @ 2011-10-24 23:09 UTC (permalink / raw)
To: netdev
When hybrid mode is enabled (accept_ra == 2), the kernel also sees RAs
generated locally. This is useful since it allows the kernel to auto-configure
its own interface addresses.
However, if 'accept_ra_defrtr' and/or 'accept_ra_rtr_pref' are set and the
locally generated RAs announce the default route and/or other route information,
the kernel happily inserts bogus routes with its own address as gateway.
With this patch, adding routes from an RA will be skiped when the RAs source
address matches any local address, just as if 'accept_ra_defrtr' and
'accept_ra_rtr_pref' were set to 0.
Signed-off-by: Andreas Hofmeister <andi@collax.com>
---
net/ipv6/ndisc.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 67501b6..00fa46e1 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1226,6 +1226,9 @@ static void ndisc_router_discovery(struct sk_buff *skb)
if (!in6_dev->cnf.accept_ra_defrtr)
goto skip_defrtr;
+ if (ipv6_chk_addr(dev_net(in6_dev->dev), &ipv6_hdr(skb)->saddr, NULL, 0))
+ goto skip_defrtr;
+
lifetime = ntohs(ra_msg->icmph.icmp6_rt_lifetime);
#ifdef CONFIG_IPV6_ROUTER_PREF
@@ -1350,6 +1353,9 @@ skip_linkparms:
goto out;
#ifdef CONFIG_IPV6_ROUTE_INFO
+ if (ipv6_chk_addr(dev_net(in6_dev->dev), &ipv6_hdr(skb)->saddr, NULL, 0))
+ goto skip_routeinfo;
+
if (in6_dev->cnf.accept_ra_rtr_pref && ndopts.nd_opts_ri) {
struct nd_opt_hdr *p;
for (p = ndopts.nd_opts_ri;
@@ -1367,6 +1373,8 @@ skip_linkparms:
&ipv6_hdr(skb)->saddr);
}
}
+
+skip_routeinfo:
#endif
#ifdef CONFIG_IPV6_NDISC_NODETYPE
--
1.7.6.1
^ permalink raw reply related
* (unknown)
From: Mr. Wen Lee @ 2011-10-24 23:03 UTC (permalink / raw)
I am Mr. Wen Lee director of operations of the Bank Of Taipei Taiwan. I have an obscured business proposal for you. Reply if interested.
^ permalink raw reply
* (unknown)
From: Mr. Wen Lee @ 2011-10-24 23:07 UTC (permalink / raw)
I am Mr. Wen Lee director of operations of the Bank Of Taipei Taiwan. I have an obscured business proposal for you. Reply if interested.
^ permalink raw reply
* Re: [PATCH] ipv6: Do not use routes from locally generated RAs
From: David Miller @ 2011-10-24 23:13 UTC (permalink / raw)
To: andi; +Cc: netdev
In-Reply-To: <1319497776-23998-1-git-send-email-andi@collax.com>
From: Andreas Hofmeister <andi@collax.com>
Date: Tue, 25 Oct 2011 01:09:36 +0200
> When hybrid mode is enabled (accept_ra == 2), the kernel also sees RAs
> generated locally. This is useful since it allows the kernel to auto-configure
> its own interface addresses.
>
> However, if 'accept_ra_defrtr' and/or 'accept_ra_rtr_pref' are set and the
> locally generated RAs announce the default route and/or other route information,
> the kernel happily inserts bogus routes with its own address as gateway.
>
> With this patch, adding routes from an RA will be skiped when the RAs source
> address matches any local address, just as if 'accept_ra_defrtr' and
> 'accept_ra_rtr_pref' were set to 0.
>
> Signed-off-by: Andreas Hofmeister <andi@collax.com>
Applied, thanks.
^ permalink raw reply
* (unknown)
From: Mr. Wen Lee @ 2011-10-24 23:09 UTC (permalink / raw)
I am Mr. Wen Lee director of operations of the Bank Of Taipei Taiwan. I have an obscured business proposal for you. Reply if interested.
^ permalink raw reply
* Re: [PATCH v2 2/3] dp83640: use proper function to free transmit time stamping packets
From: David Miller @ 2011-10-24 23:16 UTC (permalink / raw)
To: richardcochran; +Cc: netdev, eric.dumazet, johannes, stable
In-Reply-To: <20111024174724.GA1954@netboy.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Mon, 24 Oct 2011 19:47:25 +0200
> On Mon, Oct 24, 2011 at 02:55:55AM -0400, David Miller wrote:
>> From: Richard Cochran <richardcochran@gmail.com>
>> Date: Fri, 21 Oct 2011 12:49:16 +0200
>>
>> > The previous commit enforces a new rule for handling the cloned packets
>> > for transmit time stamping. These packets must not be freed using any other
>> > function than skb_complete_tx_timestamp. This commit fixes the one and only
>> > driver using this API.
>> >
>> > The driver first appeared in v3.0.
>> >
>> > Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
>> > Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>> > Cc: <stable@vger.kernel.org>
>>
>> In the 'net' tree, which is where you should be targetting these dp83640
>> driver patches, the code looks nothing like what you're patching against.
>>
>> Please respin patches #2 and #3 against current sources.
>
> Okay, but #2 will conflict with
>
> dccaa9e0 dp83640: add time stamp insertion for sync messages
>
> in net-next. Should I also submit a fix for that one?
Ok. I'll just apply those original 2 patches to net-next since Linus
release 3.1 today already.
Thanks.
^ permalink raw reply
* Re: Bug#645308: tg3 broken for NetXtreme 5714S in squeeze 6.0.3 installer
From: Ben Hutchings @ 2011-10-24 23:47 UTC (permalink / raw)
To: Matt Carlson; +Cc: Michael Chan, 645308@bugs.debian.org, Marc Haber, netdev
In-Reply-To: <20111024212409.GA29764@mcarlson.broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]
On Mon, 2011-10-24 at 14:24 -0700, Matt Carlson wrote:
> On Fri, Oct 21, 2011 at 05:19:39AM -0700, Ben Hutchings wrote:
> > On Fri, 2011-10-21 at 11:08 +0200, Marc Haber wrote:
> > > On Fri, Oct 21, 2011 at 11:00:46AM +0200, Marc Haber wrote:
> > > > On Thu, Oct 20, 2011 at 05:28:34AM +0100, Ben Hutchings wrote:
> > > > > I don't see any changes that would obviously change the way this device
> > > > > is reconfigured during a down/up cycle. There were some changes to
> > > > > power management that should just let the PCI core do some work that the
> > > > > driver used to, but it's possible that the result isn't quite the same.
> > > > > I built a module with those reverted; source and binary attached. Could
> > > > > you test that? I checked that d-i does include an insmod command.
> > > >
> > > > The squeeze 6.0.3 installer with the shipped tg3.ko replaced with
> > > > yours boots and networks just fine without any workaround and without
> > > > manual interaction.
> > >
> > > I was a bit fast on that. The interface now fails right in the middle
> > > of installation and needs the modprobe -r, modprobe stunt to network
> > > again.
> >
> > Matt, Michael,
> >
> > The tg3 driver has regressed for the 5714S since Linux 2.6.32. Marc
> > Haber found this in the backported version included in our stable
> > update, but also confirmed it in Linux 3.0.
> >
> > Bringing the interface down and then up again (which the installer does
> > for some reason) can leave it unable to pass traffic (possibly after
> > working for a few packets) until the module is reloaded.
> >
> > I asked Marc to check whether reverting the power management changes
> > (071697e2bcd8dff2af4d6fdd6525c2324f89553b,
> > d237d9ecf06a00f0ebca657958cf2a1e92940796) made a difference, but it
> > doesn't seem to.
> >
> > There is more information in the bug log at
> > <http://bugs.debian.org/645308>.
>
> Where can I get the sources for this driver? Commit
> 9e975cc291d80d5e4562d6bed15ec171e896d69b, entitled
> "tg3: Fix io failures after chip reset" has been a common source of
> problems.
Our current package has Linux 3.0.6 which includes the backport of that
change. However, it is *not* included in my backport to 2.6.32 so it
doesn't explain the original report.
The backported version can be found in:
git://anonscm.debian.org/kernel/linux-2.6.git squeeze
Ben.
--
Ben Hutchings
DNRC Motto: I can please only one person per day.
Today is not your day. Tomorrow isn't looking good either.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [patch net-next V4] net: introduce ethernet teaming device
From: Andy Gospodarek @ 2011-10-25 0:02 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, fubar, andy,
tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl,
benjamin.poirier, jzupka
In-Reply-To: <1319444005-1281-1-git-send-email-jpirko@redhat.com>
On Mon, Oct 24, 2011 at 10:13:25AM +0200, Jiri Pirko wrote:
> This patch introduces new network device called team. It supposes to be
> very fast, simple, userspace-driven alternative to existing bonding
> driver.
>
> Userspace library called libteam with couple of demo apps is available
> here:
> https://github.com/jpirko/libteam
> Note it's still in its dipers atm.
>
> team<->libteam use generic netlink for communication. That and rtnl
> suppose to be the only way to configure team device, no sysfs etc.
>
> Python binding basis for libteam was recently introduced (some need
> still need to be done on it though). Daemon providing arpmon/miimon
> active-backup functionality will be introduced shortly.
> All what's necessary is already implemented in kernel team driver.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
> v3->v4:
> - remove redundant synchronize_rcu from __team_change_mode()
> - revert "set and clear of mode_ops happens per pointer, not per
> byte"
> - extend comment of function __team_change_mode()
>
> v2->v3:
> - team_change_mtu() user rcu version of list traversal to unwind
> - set and clear of mode_ops happens per pointer, not per byte
> - port hashlist changed to be embedded into team structure
> - error branch in team_port_enter() does cleanup now
> - fixed rtln->rtnl
>
> v1->v2:
> - modes are made as modules. Makes team more modular and
> extendable.
> - several commenters' nitpicks found on v1 were fixed
> - several other bugs were fixed.
> - note I ignored Eric's comment about roundrobin port selector
> as Eric's way may be easily implemented as another mode (mode
> "random") in future.
Jiri,
I've been following this work closely since your first post and now to
wonder if you could create a 'team' tree somewhere. It would be nice if
there was a repo that we could clone for testing and a base for others
to help with the development and provide patches.
It also might avoid so much of this back and forth, so that you are not
on v37 by the time the code meets everyones needs. :-)
Once the code goes mainline and Dave pulls your tree, you could then
remove it.
-andy
^ permalink raw reply
* Re: [RFD] Network configuration data in sysfs
From: Alexey Gladkov @ 2011-10-24 23:54 UTC (permalink / raw)
To: Kay Sievers
Cc: David Miller, kirill, netdev, kuznet, jmorris, yoshfuji, kaber,
gregkh
In-Reply-To: <CAPXgP10PZU+xSbQW-CH-E5rCk3-=1k-AvAs=tF8fAnz7QsmJRw@mail.gmail.com>
24.10.2011 16:46, Kay Sievers wrote:
> Kirill, what exactly is the use case? And why what does udev support
> mean in that context?
>
> I doubt that "not having /sbin/ip installed" should be a reason to add
> and expose complex interfaces in /sys, while we already have a
> perfectly working native way to do it.
Adding NETLINK_ROUTE in udev is a way to perform some actions in case
of network events without polling. Now there are only a few specific
daemons (NM, connman etc) that are listen to the netlink socket and
setup the network his own way.
--
Rgrds, legion
^ permalink raw reply
* [PATCH v4 2/9] net: ethtool: break association of ETH_FLAG_* with NETIF_F_*
From: Michał Mirosław @ 2011-10-25 0:36 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Ben Hutchings
In-Reply-To: <cover.1319495301.git.mirq-linux@rere.qmqm.pl>
This is the only place left where dev->features are directly
exposed to userspace.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/core/ethtool.c | 33 +++++++++++++++++++++++----------
1 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index db8a77b..a354919 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -240,32 +240,45 @@ static int ethtool_set_one_feature(struct net_device *dev,
return 0;
}
-/* the following list of flags are the same as their associated
- * NETIF_F_xxx values in include/linux/netdevice.h
- */
-static const u32 flags_dup_features =
- (ETH_FLAG_LRO | ETH_FLAG_RXVLAN | ETH_FLAG_TXVLAN | ETH_FLAG_NTUPLE |
- ETH_FLAG_RXHASH);
+#define ETH_ALL_FLAGS (ETH_FLAG_LRO | ETH_FLAG_RXVLAN | ETH_FLAG_TXVLAN | \
+ ETH_FLAG_NTUPLE | ETH_FLAG_RXHASH)
+#define ETH_ALL_FEATURES (NETIF_F_LRO | NETIF_F_HW_VLAN_RX | \
+ NETIF_F_HW_VLAN_TX | NETIF_F_NTUPLE | NETIF_F_RXHASH)
static u32 __ethtool_get_flags(struct net_device *dev)
{
- return dev->features & flags_dup_features;
+ u32 flags = 0;
+
+ if (dev->features & NETIF_F_LRO) flags |= ETH_FLAG_LRO;
+ if (dev->features & NETIF_F_HW_VLAN_RX) flags |= ETH_FLAG_RXVLAN;
+ if (dev->features & NETIF_F_HW_VLAN_TX) flags |= ETH_FLAG_TXVLAN;
+ if (dev->features & NETIF_F_NTUPLE) flags |= ETH_FLAG_NTUPLE;
+ if (dev->features & NETIF_F_RXHASH) flags |= ETH_FLAG_RXHASH;
+
+ return flags;
}
static int __ethtool_set_flags(struct net_device *dev, u32 data)
{
+ u32 features = 0;
u32 changed;
- if (data & ~flags_dup_features)
+ if (data & ~ETH_ALL_FLAGS)
return -EINVAL;
+ if (data & ETH_FLAG_LRO) features |= NETIF_F_LRO;
+ if (data & ETH_FLAG_RXVLAN) features |= NETIF_F_HW_VLAN_RX;
+ if (data & ETH_FLAG_TXVLAN) features |= NETIF_F_HW_VLAN_TX;
+ if (data & ETH_FLAG_NTUPLE) features |= NETIF_F_NTUPLE;
+ if (data & ETH_FLAG_RXHASH) features |= NETIF_F_RXHASH;
+
/* allow changing only bits set in hw_features */
- changed = (data ^ dev->features) & flags_dup_features;
+ changed = (features ^ dev->features) & ETH_ALL_FEATURES;
if (changed & ~dev->hw_features)
return (changed & dev->hw_features) ? -EINVAL : -EOPNOTSUPP;
dev->wanted_features =
- (dev->wanted_features & ~changed) | (data & dev->hw_features);
+ (dev->wanted_features & ~changed) | (features & changed);
__netdev_update_features(dev);
--
1.7.6.3
^ permalink raw reply related
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