* Re: [net-next 01/02] ixgb: eliminate checkstack warnings
From: David Miller @ 2011-09-23 17:56 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: jesse.brandeburg, netdev, gospo
In-Reply-To: <1316779890-32436-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Sep 2011 05:11:29 -0700
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> Really trivial fix, use kmalloc/kfree instead of stack space.
> use static const instead of const to further reduce stack usage.
>
> V2: reflect changes suggested by Joe Perches
>
> before:
> [jbrandeb@jbrandeb-mobl2 linux-2.6]$ make checkstack|grep '\[ixgb\]'
> 0x00000fc1 ixgb_set_multi [ixgb]: 768
> 0x00001031 ixgb_set_multi [ixgb]: 768
> 0x000010f2 ixgb_set_multi [ixgb]: 768
> 0x061c ixgb_check_options [ixgb]: 448
> 0x09c3 ixgb_check_options [ixgb]: 448
> 0x0000649e ixgb_set_ringparam [ixgb]: 192
> 0x0000130d ixgb_xmit_frame [ixgb]: 184
> 0x000019e0 ixgb_xmit_frame [ixgb]: 184
> 0x00002267 ixgb_clean [ixgb]: 152
> 0x00002673 ixgb_clean [ixgb]: 152
>
> after:
> 0x000064ee ixgb_set_ringparam [ixgb]: 192
> 0x0000135d ixgb_xmit_frame [ixgb]: 184
> 0x00001a30 ixgb_xmit_frame [ixgb]: 184
> 0x000022b7 ixgb_clean [ixgb]: 152
> 0x000026c3 ixgb_clean [ixgb]: 152
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next 02/02] ixgb: finish conversion to ndo_fix_features
From: David Miller @ 2011-09-23 17:56 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: mirq-linux, netdev, gospo
In-Reply-To: <1316779890-32436-2-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Sep 2011 05:11:30 -0700
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Finish conversion to unified ethtool ops: convert get_flags.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next 0/8 v2][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-09-23 17:57 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1316794367-23265-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Sep 2011 09:12:39 -0700
> The following series contains updates to ixgbe and PCI. The PCI patch
> is a small update to add a flag to indicate when a device has been
> assigned by KVM. The ixgbe patches consist of the following:
>
> - reconfigure SR-IOV init to take advantage of the new pci flag
> - DCB cleanups/fixes
> - add WOL support for x540
> - a few cleanup/fixes
>
> -v2 Fixed up comment in the PCI patch based on feedback from Ian Campbell
>
> The following are changes since commit 9c9b1f24f2aa31a3cea94939edc551f68ebadc89:
> net/phy: add IC+ IP101A and support APS.
> and are available in the git repository at:
> git://github.com/Jkirsher/net-next.git
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH next 0/4] Pull request for 'davem-next.r8169' branch
From: David Miller @ 2011-09-23 17:55 UTC (permalink / raw)
To: romieu; +Cc: netdev, nic_swsd, hayeswang
In-Reply-To: <20110922210202.GA16362@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 22 Sep 2011 23:02:02 +0200
> Please pull from branch 'davem-next.r8169' in repository
>
> git://violet.fr.zoreil.com/romieu/linux davem-next.r8169
>
> to get the changes below.
Pulled, thanks Francois.
^ permalink raw reply
* Re: [PATCH v5 0/3] add fec support for imx6q
From: David Miller @ 2011-09-23 17:56 UTC (permalink / raw)
To: shawn.guo; +Cc: netdev, linux-arm-kernel, patches
In-Reply-To: <1316779968-21390-1-git-send-email-shawn.guo@linaro.org>
From: Shawn Guo <shawn.guo@linaro.org>
Date: Fri, 23 Sep 2011 20:12:45 +0800
> This series adds imx6q enet support. The imx6q enet is a derivative of
> imx28 enet controller. It fixes the frame endian issue found on imx28,
> and adds 1 Gbps support.
All applied.
^ permalink raw reply
* Re: [net-next 01/02] ixgb: eliminate checkstack warnings
From: Joe Perches @ 2011-09-23 17:59 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Jesse Brandeburg, netdev, gospo
In-Reply-To: <1316779890-32436-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Fri, 2011-09-23 at 05:11 -0700, Jeff Kirsher wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> Really trivial fix, use kmalloc/kfree instead of stack space.
> use static const instead of const to further reduce stack usage.
>
> V2: reflect changes suggested by Joe Perches
This is a less than complete commit log as
the patch also converts a local #define
of IXGB_ETH_LENGTH_OF_ADDRESS to ETH_ALEN
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Konrad Rzeszutek Wilk @ 2011-09-23 18:00 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T, Ian Campbell, davem@davemloft.net,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C518D57@orsmsx508.amr.corp.intel.com>
On Fri, Sep 23, 2011 at 10:04:59AM -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Friday, September 23, 2011 9:43 AM
> > To: Kirsher, Jeffrey T
> > Cc: Rose, Gregory V; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> > netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> > Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> > assigned by KVM
> >
> > On Fri, Sep 23, 2011 at 08:45:09AM -0700, Jeff Kirsher wrote:
> > > On Fri, 2011-09-23 at 08:11 -0700, Rose, Gregory V wrote:
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > Sent: Friday, September 23, 2011 8:04 AM
> > > > > To: Rose, Gregory V
> > > > > Cc: Kirsher, Jeffrey T; davem@davemloft.net; konrad.wilk@oracle.com;
> > Jesse
> > > > > Barnes; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > pci@vger.kernel.org
> > > > > Subject: RE: [net-next 1/8] pci: Add flag indicating device has been
> > > > > assigned by KVM
> > > > >
> > > > > On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > > > Sent: Friday, September 23, 2011 12:28 AM
> > > > > > > To: Kirsher, Jeffrey T
> > > > > > > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse Barnes;
> > Rose,
> > > > > > > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > > > pci@vger.kernel.org
> > > > > > > Subject: Re: [net-next 1/8] pci: Add flag indicating device has
> > been
> > > > > > > assigned by KVM
> > > > > > >
> > > > > > > I suppose by that measure the comment could be less KVM
> > specific:
> > > > > > > > + /* Provide indication device is assigned by KVM */
> > > > > > > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > > > > >
> > > > > > We can resubmit with a more generic comment, maybe this:
> > > > > >
> > > > > > /* Provide indication device is assigned by a Virtual Machine
> > Manager */
> > > > >
> > > > > Sounds good to me.
> > > >
> > > > Dave, Jeff,
> > > >
> > > > Should I resubmit the patch or would it be more convenient to post a
> > follow on patch that fixes up the comment? Either way is fine by me.
> > > >
> > > > - Greg
> > > >
> > >
> > > let's fix up the patch in my tree and add Jesse Barnes's ACK at the same
> > > time.
> >
> > Were are the patches now? I am kind of curious to see the changes to the
> > xen pciback.
> >
> >
>
> Version 2 of this patch with the modified comment was just posted to netdev. Ian Campbell had mentioned that the Xen pciback driver should be modified to use this flag but I don't believe any patches for it have been created yet.
http://marc.info/?i=20110729165446.GA6731@dumpdata.com
?
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Fixes
From: Anirban Chakraborty @ 2011-09-23 18:10 UTC (permalink / raw)
To: Anirban Chakraborty; +Cc: David Miller, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1315937179-22383-3-git-send-email-anirban.chakraborty@qlogic.com>
Dave,
Do you want me to respin the patches based on current net-next and resubmit it?
thanks,
Anirban
On Sep 13, 2011, at 11:06 AM, Anirban Chakraborty wrote:
> Please apply the series to net-next. Thanks.
>
> -Anirban
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Fixes
From: David Miller @ 2011-09-23 18:24 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <09109E3F-C661-4429-A7CF-6D9C01C3171B@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Fri, 23 Sep 2011 11:10:19 -0700
> Do you want me to respin the patches based on current net-next and resubmit it?
No need, I just haven't gotten to those patches yet.
But since you bring it up I've applied them now, thanks.
^ permalink raw reply
* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-09-23 18:24 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kirsher, Jeffrey T, Ian Campbell, davem@davemloft.net,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <20110923180025.GA6251@phenom.oracle.com>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, September 23, 2011 11:00 AM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> assigned by KVM
>
> On Fri, Sep 23, 2011 at 10:04:59AM -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Friday, September 23, 2011 9:43 AM
> > > To: Kirsher, Jeffrey T
> > > Cc: Rose, Gregory V; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> > > netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> > > Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> > > assigned by KVM
> > >
> > > On Fri, Sep 23, 2011 at 08:45:09AM -0700, Jeff Kirsher wrote:
> > > > On Fri, 2011-09-23 at 08:11 -0700, Rose, Gregory V wrote:
> > > > > > -----Original Message-----
> > > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > > Sent: Friday, September 23, 2011 8:04 AM
> > > > > > To: Rose, Gregory V
> > > > > > Cc: Kirsher, Jeffrey T; davem@davemloft.net;
> konrad.wilk@oracle.com;
> > > Jesse
> > > > > > Barnes; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > > pci@vger.kernel.org
> > > > > > Subject: RE: [net-next 1/8] pci: Add flag indicating device has
> been
> > > > > > assigned by KVM
> > > > > >
> > > > > > On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > > > > > Sent: Friday, September 23, 2011 12:28 AM
> > > > > > > > To: Kirsher, Jeffrey T
> > > > > > > > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse
> Barnes;
> > > Rose,
> > > > > > > > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > > > > > pci@vger.kernel.org
> > > > > > > > Subject: Re: [net-next 1/8] pci: Add flag indicating device
> has
> > > been
> > > > > > > > assigned by KVM
> > > > > > > >
> > > > > > > > I suppose by that measure the comment could be less KVM
> > > specific:
> > > > > > > > > + /* Provide indication device is assigned by KVM */
> > > > > > > > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t)
> 4,
> > > > > > >
> > > > > > > We can resubmit with a more generic comment, maybe this:
> > > > > > >
> > > > > > > /* Provide indication device is assigned by a Virtual Machine
> > > Manager */
> > > > > >
> > > > > > Sounds good to me.
> > > > >
> > > > > Dave, Jeff,
> > > > >
> > > > > Should I resubmit the patch or would it be more convenient to post
> a
> > > follow on patch that fixes up the comment? Either way is fine by me.
> > > > >
> > > > > - Greg
> > > > >
> > > >
> > > > let's fix up the patch in my tree and add Jesse Barnes's ACK at the
> same
> > > > time.
> > >
> > > Were are the patches now? I am kind of curious to see the changes to
> the
> > > xen pciback.
> > >
> > >
> >
> > Version 2 of this patch with the modified comment was just posted to
> netdev. Ian Campbell had mentioned that the Xen pciback driver should be
> modified to use this flag but I don't believe any patches for it have been
> created yet.
>
> http://marc.info/?i=20110729165446.GA6731@dumpdata.com
>
I'm not sure who generated the patches to xen-pciback. It wasn't me and I couldn't tell from the links you provided who did generate that patch. I don't see it now though.
- Greg
^ permalink raw reply
* [PATCH net/stable] can bcm: fix tx_setup off-by-one errors
From: Oliver Hartkopp @ 2011-09-23 18:23 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, stable, Andre Naujoks
This patch fixes two off-by-one errors that canceled each other out.
Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
the count of frames to be sent by one. This did not show up the first time
tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
Invoking a second tx_setup on the same item led to a reduced (by 1) number of
sent frames.
Reported-by: Andre Naujoks <nautsch@gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/net/can/bcm.c b/net/can/bcm.c
index d6c8ae5..c9cdb8d 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -365,9 +365,6 @@ static void bcm_tx_timeout_tsklet(unsigned long data)
bcm_send_to_user(op, &msg_head, NULL, 0);
}
- }
-
- if (op->kt_ival1.tv64 && (op->count > 0)) {
/* send (next) frame */
bcm_can_tx(op);
@@ -970,8 +967,9 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
/* spec: send can_frame when starting timer */
op->flags |= TX_ANNOUNCE;
- if (op->kt_ival1.tv64 && (op->count > 0)) {
- /* op->count-- is done in bcm_tx_timeout_handler */
+ /* only start timer when having more frames than sent below */
+ if (op->kt_ival1.tv64 && (op->count > 1)) {
+ /* op->count-- is done in bcm_tx_timeout_tsklet */
hrtimer_start(&op->timer, op->kt_ival1,
HRTIMER_MODE_REL);
} else
@@ -979,8 +977,11 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
HRTIMER_MODE_REL);
}
- if (op->flags & TX_ANNOUNCE)
+ if (op->flags & TX_ANNOUNCE) {
bcm_can_tx(op);
+ if (op->kt_ival1.tv64 && (op->count > 0))
+ op->count--;
+ }
return msg_head->nframes * CFSIZ + MHSIZ;
}
^ permalink raw reply related
* Re: [PATCH net-next 0/2] qlcnic: Fixes
From: Anirban Chakraborty @ 2011-09-23 18:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <20110923.142437.1502065492072634583.davem@davemloft.net>
On Sep 23, 2011, at 11:24 AM, David Miller wrote:
> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> Date: Fri, 23 Sep 2011 11:10:19 -0700
>
>> Do you want me to respin the patches based on current net-next and resubmit it?
>
> No need, I just haven't gotten to those patches yet.
>
> But since you bring it up I've applied them now, thanks.
Thanks a lot.
-Anirban
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Konrad Rzeszutek Wilk @ 2011-09-23 19:05 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T, Ian Campbell, davem@davemloft.net,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C518E23@orsmsx508.amr.corp.intel.com>
> > > Version 2 of this patch with the modified comment was just posted to
> > netdev. Ian Campbell had mentioned that the Xen pciback driver should be
> > modified to use this flag but I don't believe any patches for it have been
> > created yet.
> >
> > http://marc.info/?i=20110729165446.GA6731@dumpdata.com
> >
>
> I'm not sure who generated the patches to xen-pciback. It wasn't me and I couldn't tell from the links you provided who did generate that patch. I don't see it now though.
I provided it.
And I asked for a git tree so I could double check that it actually
worked as I don't have the full set of your patches.
Can you provide me a link to your public git tree or just repost it once more?
>
> - Greg
^ permalink raw reply
* Re: [PATCH] tcp: ECN blackhole should not force quickack mode
From: Ilpo Järvinen @ 2011-09-23 19:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Jerry Chu, Jamal Hadi Salim, Jim Gettys,
Dave Taht
In-Reply-To: <1316757739.2560.12.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 616 bytes --]
On Fri, 23 Sep 2011, Eric Dumazet wrote:
> While playing with a new ADSL box at home, I discovered that ECN
> blackhole can trigger suboptimal quickack mode on linux : We send one
> ACK for each incoming data frame, without any delay and eventual
> piggyback.
>
> This is because TCP_ECN_check_ce() considers that if no ECT is seen on a
> segment, this is because this segment was a retransmit.
>
> Refine this heuristic and apply it only if we seen ECT in a previous
> segment, to detect ECN blackhole at IP level.
This seems sensible thing to do.
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
--
i.
^ permalink raw reply
* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-09-23 19:20 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kirsher, Jeffrey T, Ian Campbell, davem@davemloft.net,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <20110923190537.GA18850@phenom.oracle.com>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, September 23, 2011 12:06 PM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; Ian Campbell; davem@davemloft.net; Jesse Barnes;
> netdev@vger.kernel.org; gospo@redhat.com; linux-pci@vger.kernel.org
> Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> assigned by KVM
>
> > > > Version 2 of this patch with the modified comment was just posted to
> > > netdev. Ian Campbell had mentioned that the Xen pciback driver should
> be
> > > modified to use this flag but I don't believe any patches for it have
> been
> > > created yet.
> > >
> > > http://marc.info/?i=20110729165446.GA6731@dumpdata.com
> > >
> >
> > I'm not sure who generated the patches to xen-pciback. It wasn't me and
> I couldn't tell from the links you provided who did generate that patch.
> I don't see it now though.
>
> I provided it.
>
> And I asked for a git tree so I could double check that it actually
> worked as I don't have the full set of your patches.
>
> Can you provide me a link to your public git tree or just repost it once
> more?
Ah, I get it now.
Jeff Kirsher is the maintainer of our git trees. Hopefully he'll come around and provide that info for you soon.
- Greg
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Maciej Żenczykowski @ 2011-09-23 19:33 UTC (permalink / raw)
To: Casey Schaufler; +Cc: netdev, linux-security-module, James Morris
In-Reply-To: <4E7CB5A9.2020303@schaufler-ca.com>
> Under what circumstances would a process that requires the
> new capability not require CAP_NET_ADMIN? Is there a real
> case where a process would be expected to require only this
> new capability? Adding new capability values is somewhat
> perilous and the granularity you are proposing, that of
> controlling a single bit, would explode the list of
> capabilities into the hundreds if it were applied throughout
> the kernel.
CAP_NET_ADMIN is a huge hammer, it allows one to totally
reconfigure the networking subsystem.
In a containerized multi-user/job environment, you do not want
something like an instance of a load-balanced web server, proxy
or dns server being able to do that - policy/configuration decisions
should be left up to the administrator and/or machine management
daemon(s). Each of these can make use of transparent sockets
(in various ways, mostly in coordination with large scale load balancing).
You also do not want one user running in one container being able
to sniff (CAP_NET_RAW) traffic from another user (hence CAP_NET_RAW
isn't an acceptable substitute).
One could conceivably use network namespaces for seperation, but
in this particular case they are _way_ too overkill (and also add too
much overhead).
This might be *just* a single bit in the socket, but this bit effectively
controls whether you can do certain types of privileged operations
on the socket in question - and it gets tested in various places throughout
the networking stack.
Hopefully, this answers your question.
- Maciej
^ permalink raw reply
* tg3: BMC stops responding in 3.0
From: Arkadiusz Miśkiewicz @ 2011-09-23 19:45 UTC (permalink / raw)
To: Matt Carlson, Michael Chan; +Cc: netdev
Hi,
I was using 2.6.38.8 and recently tried to switch to 3.0.4 on Tyan S2891
platform.
This platform uses tg3:
tg3 0000:0a:09.1: eth1: Tigon3 [partno(BCM95704) rev 2003] (PCIX:133MHz:64-
bit) MAC address 00:e0:81:33:5e:af
tg3 0000:0a:09.1: eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet)
(WireSpeed[1], EEE[0])
tg3 0000:0a:09.1: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:0a:09.1: eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
With 2.6.38.8 everything was working fine. With 3.0.4 there is a problem. As
soon as tg3 module is loaded or eth0 configured (can't tell which one since
the machine is 400km away from me and I have no way to play with it other than
ipmi or ssh) BMC stops responding (so all ipmitool commands over LAN stop
working). Normal tg3 activity is not affected - I can ssh-in without a problem
etc but ipmi over lan doesn't work.
From ssh console "ipmitool lan print" works, shows data but for example after
"ipmitool mc reset cold" it doesn't recover - ipmitool returns "Invalid
channel: 255". I have to reboot to 2.6.38.8 and then issue "ipmitool mc reset
cold" to recover.
Any idea which tg3 change could break this? Can't bisect this due remote
access only.
I was hoping that maybe 9e975cc291d80d5e4562d6bed15ec171e896d69b
"tg3: Fix io failures after chip reset" will fix things for me but no - this
doesn't help.
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* GRE devices and MULTICAST flag.
From: Ben Greear @ 2011-09-23 19:56 UTC (permalink / raw)
To: netdev
I was under the impression that GRE tunnels could support MULTICAST
traffic, but the MULTICAST flag is not set. This is making the xorp
router crap out because it checks the MULTICAST flag and will
not start multicast on the interface if it's not set....
Is it supposed to be set?
7: gre0: <NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
link/gre 0.0.0.0 brd 0.0.0.0
8: netb: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
link/gre 192.168.100.223 peer 192.168.100.138
inet 10.0.1.1/32 scope global netb
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: GRE devices and MULTICAST flag.
From: Ben Greear @ 2011-09-23 20:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <4E7CE473.3000304@candelatech.com>
On 09/23/2011 12:56 PM, Ben Greear wrote:
> I was under the impression that GRE tunnels could support MULTICAST
> traffic, but the MULTICAST flag is not set. This is making the xorp
> router crap out because it checks the MULTICAST flag and will
> not start multicast on the interface if it's not set....
>
> Is it supposed to be set?
>
> 7: gre0: <NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
> link/gre 0.0.0.0 brd 0.0.0.0
> 8: netb: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
> link/gre 192.168.100.223 peer 192.168.100.138
> inet 10.0.1.1/32 scope global netb
Well, ifconfig netb multicast seems to add the flag,
so maybe all is as it should be.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH net] bonding: properly stop queuing work when requested
From: Andy Gospodarek @ 2011-09-23 20:53 UTC (permalink / raw)
To: netdev
During a test where a pair of bonding interfaces using ARP monitoring
were both brought up and torn down (with an rmmod) repeatedly, a panic
in the timer code was noticed. I tracked this down and determined that
any of the bonding functions that ran as workqueue handlers and requeued
more work might not properly exit when the module was removed.
There was a flag protected by the bond lock called kill_timers that is
set when the interface goes down or the module is removed, but many of
the functions that monitor link status now unlock the bond lock to take
rtnl first. There is a chance that another CPU running the rmmod could
get the lock and set kill_timers after the first check has passed.
This patch does not allow any function to queue work that will make
itself run unless kill_timers is not set. I also noticed while doing
this work that bond_resend_igmp_join_requests did not have a check for
kill_timers, so I added the needed call there as well.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Reported-by: Liang Zheng <lzheng@redhat.com>
---
drivers/net/bonding/bond_3ad.c | 3 ++-
drivers/net/bonding/bond_alb.c | 3 ++-
drivers/net/bonding/bond_main.c | 13 ++++++++-----
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index a047eb9..47b928e 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -2168,7 +2168,8 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
}
re_arm:
- queue_delayed_work(bond->wq, &bond->ad_work, ad_delta_in_ticks);
+ if (!bond->kill_timers)
+ queue_delayed_work(bond->wq, &bond->ad_work, ad_delta_in_ticks);
out:
read_unlock(&bond->lock);
}
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 7f8b20a..c172028 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -1440,7 +1440,8 @@ void bond_alb_monitor(struct work_struct *work)
}
re_arm:
- queue_delayed_work(bond->wq, &bond->alb_work, alb_delta_in_ticks);
+ if (!bond->kill_timers)
+ queue_delayed_work(bond->wq, &bond->alb_work, alb_delta_in_ticks);
out:
read_unlock(&bond->lock);
}
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 43f2ea5..6d79b78 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -777,6 +777,9 @@ static void bond_resend_igmp_join_requests(struct bonding *bond)
read_lock(&bond->lock);
+ if (bond->kill_timers)
+ goto out;
+
/* rejoin all groups on bond device */
__bond_resend_igmp_join_requests(bond->dev);
@@ -790,9 +793,9 @@ static void bond_resend_igmp_join_requests(struct bonding *bond)
__bond_resend_igmp_join_requests(vlan_dev);
}
- if (--bond->igmp_retrans > 0)
+ if ((--bond->igmp_retrans > 0) && !bond->kill_timers)
queue_delayed_work(bond->wq, &bond->mcast_work, HZ/5);
-
+out:
read_unlock(&bond->lock);
}
@@ -2538,7 +2541,7 @@ void bond_mii_monitor(struct work_struct *work)
}
re_arm:
- if (bond->params.miimon)
+ if (bond->params.miimon && !bond->kill_timers)
queue_delayed_work(bond->wq, &bond->mii_work,
msecs_to_jiffies(bond->params.miimon));
out:
@@ -2886,7 +2889,7 @@ void bond_loadbalance_arp_mon(struct work_struct *work)
}
re_arm:
- if (bond->params.arp_interval)
+ if (bond->params.arp_interval && !bond->kill_timers)
queue_delayed_work(bond->wq, &bond->arp_work, delta_in_ticks);
out:
read_unlock(&bond->lock);
@@ -3154,7 +3157,7 @@ void bond_activebackup_arp_mon(struct work_struct *work)
bond_ab_arp_probe(bond);
re_arm:
- if (bond->params.arp_interval)
+ if (bond->params.arp_interval && !bond->kill_timers)
queue_delayed_work(bond->wq, &bond->arp_work, delta_in_ticks);
out:
read_unlock(&bond->lock);
^ permalink raw reply related
* Re: [net-next 01/11] ixgb: convert to ndo_fix_features
From: Michał Mirosław @ 2011-09-23 20:56 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev@vger.kernel.org
In-Reply-To: <1316476968.2184.14.camel@jtkirshe-mobl>
On Mon, Sep 19, 2011 at 05:02:47PM -0700, Jeff Kirsher wrote:
> On Sat, 2011-09-17 at 06:21 -0700, Michał Mirosław wrote:
>> [patch finishing ixgb conversion to hw_features]
> Thanks Michal, I have added the patch to my queue.
I see that only a single driver left: igbvf. What's the status
on its conversion?
Best Regards,
Michał Mirosław
^ permalink raw reply
* [PATCH net-next] sky2: manage irq better on single port card
From: Stephen Hemminger @ 2011-09-23 21:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Most sky2 hardware only has a single port, although some variations of the
chip support two interfaces. For the single port case, use the standard
Ethernet driver convention of allocating IRQ when device is brought up
rather than at probe time.
Also, change the error handling of dual port cards so that if second
port can not be brought up, then just fail. No point in continuing, since
the failure is most certainly because of out of memory.
The dual port sky2 device has a single irq and a single status ring,
therefore it has a single NAPI object shared by both ports.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/ethernet/marvell/sky2.c 2011-09-22 21:59:11.371091630 -0700
+++ b/drivers/net/ethernet/marvell/sky2.c 2011-09-23 13:40:42.627132176 -0700
@@ -148,6 +148,7 @@ static const unsigned rxqaddr[] = { Q_R1
static const u32 portirq_msk[] = { Y2_IS_PORT_1, Y2_IS_PORT_2 };
static void sky2_set_multicast(struct net_device *dev);
+static irqreturn_t sky2_intr(int irq, void *dev_id);
/* Access to PHY via serial interconnect */
static int gm_phy_write(struct sky2_hw *hw, unsigned port, u16 reg, u16 val)
@@ -1715,6 +1716,27 @@ static void sky2_hw_up(struct sky2_port
sky2_rx_start(sky2);
}
+/* Setup device IRQ and enable napi to process */
+static int sky2_setup_irq(struct sky2_hw *hw, const char *name)
+{
+ struct pci_dev *pdev = hw->pdev;
+ int err;
+
+ err = request_irq(pdev->irq, sky2_intr,
+ (hw->flags & SKY2_HW_USE_MSI) ? 0 : IRQF_SHARED,
+ name, hw);
+ if (err)
+ dev_err(&pdev->dev, "cannot assign irq %d\n", pdev->irq);
+ else {
+ napi_enable(&hw->napi);
+ sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
+ sky2_read32(hw, B0_IMSK);
+ }
+
+ return err;
+}
+
+
/* Bring up network interface. */
static int sky2_up(struct net_device *dev)
{
@@ -1730,6 +1752,10 @@ static int sky2_up(struct net_device *de
if (err)
goto err_out;
+ /* With single port, IRQ is setup when device is brought up */
+ if (hw->ports == 1 && (err = sky2_setup_irq(hw, dev->name)))
+ goto err_out;
+
sky2_hw_up(sky2);
/* Enable interrupts from phy/mac for port */
@@ -2091,8 +2117,13 @@ static int sky2_down(struct net_device *
sky2_read32(hw, B0_IMSK) & ~portirq_msk[sky2->port]);
sky2_read32(hw, B0_IMSK);
- synchronize_irq(hw->pdev->irq);
- napi_synchronize(&hw->napi);
+ if (hw->ports == 1) {
+ napi_disable(&hw->napi);
+ free_irq(hw->pdev->irq, hw);
+ } else {
+ synchronize_irq(hw->pdev->irq);
+ napi_synchronize(&hw->napi);
+ }
sky2_hw_down(sky2);
@@ -4798,7 +4829,7 @@ static const char *sky2_name(u8 chipid,
static int __devinit sky2_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
- struct net_device *dev;
+ struct net_device *dev, *dev1;
struct sky2_hw *hw;
int err, using_dac = 0, wol_default;
u32 reg;
@@ -4924,33 +4955,26 @@ static int __devinit sky2_probe(struct p
netif_napi_add(dev, &hw->napi, sky2_poll, NAPI_WEIGHT);
- err = request_irq(pdev->irq, sky2_intr,
- (hw->flags & SKY2_HW_USE_MSI) ? 0 : IRQF_SHARED,
- hw->irq_name, hw);
- if (err) {
- dev_err(&pdev->dev, "cannot assign irq %d\n", pdev->irq);
- goto err_out_unregister;
- }
- sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
- napi_enable(&hw->napi);
-
sky2_show_addr(dev);
if (hw->ports > 1) {
- struct net_device *dev1;
-
- err = -ENOMEM;
dev1 = sky2_init_netdev(hw, 1, using_dac, wol_default);
- if (dev1 && (err = register_netdev(dev1)) == 0)
- sky2_show_addr(dev1);
- else {
- dev_warn(&pdev->dev,
- "register of second port failed (%d)\n", err);
- hw->dev[1] = NULL;
- hw->ports = 1;
- if (dev1)
- free_netdev(dev1);
+ if (!dev1) {
+ err = -ENOMEM;
+ goto err_out_unregister;
}
+
+ err = register_netdev(dev1);
+ if (err) {
+ dev_err(&pdev->dev, "cannot register second net device\n");
+ goto err_out_free_dev1;
+ }
+
+ err = sky2_setup_irq(hw, hw->irq_name);
+ if (err)
+ goto err_out_unregister_dev1;
+
+ sky2_show_addr(dev1);
}
setup_timer(&hw->watchdog_timer, sky2_watchdog, (unsigned long) hw);
@@ -4961,6 +4985,10 @@ static int __devinit sky2_probe(struct p
return 0;
+err_out_unregister_dev1:
+ unregister_netdev(dev1);
+err_out_free_dev1:
+ free_netdev(dev1);
err_out_unregister:
if (hw->flags & SKY2_HW_USE_MSI)
pci_disable_msi(pdev);
@@ -5000,13 +5028,18 @@ static void __devexit sky2_remove(struct
unregister_netdev(hw->dev[i]);
sky2_write32(hw, B0_IMSK, 0);
+ sky2_read32(hw, B0_IMSK);
sky2_power_aux(hw);
sky2_write8(hw, B0_CTST, CS_RST_SET);
sky2_read8(hw, B0_CTST);
- free_irq(pdev->irq, hw);
+ if (hw->ports > 1) {
+ napi_disable(&hw->napi);
+ free_irq(pdev->irq, hw);
+ }
+
if (hw->flags & SKY2_HW_USE_MSI)
pci_disable_msi(pdev);
pci_free_consistent(pdev, hw->st_size * sizeof(struct sky2_status_le),
^ permalink raw reply
* Re: GRE devices and MULTICAST flag.
From: David Lamparter @ 2011-09-23 21:16 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4E7CEF4D.6080309@candelatech.com>
On Fri, Sep 23, 2011 at 01:42:53PM -0700, Ben Greear wrote:
> On 09/23/2011 12:56 PM, Ben Greear wrote:
> > I was under the impression that GRE tunnels could support MULTICAST
> > traffic, but the MULTICAST flag is not set. This is making the xorp
> > router crap out because it checks the MULTICAST flag and will
> > not start multicast on the interface if it's not set....
> >
> > Is it supposed to be set?
> >
> > 7: gre0: <NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
> > link/gre 0.0.0.0 brd 0.0.0.0
> > 8: netb: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
> > link/gre 192.168.100.223 peer 192.168.100.138
> > inet 10.0.1.1/32 scope global netb
>
> Well, ifconfig netb multicast seems to add the flag,
> so maybe all is as it should be.
I distinctively remember that the MULTICAST flag is supposed to be an
input to the kernel, not a feature-indication flag output. I'm quite
unsure where I picked this up, but I remember using it in that way that
xorp does and then finding out it's wrong.
-David
^ permalink raw reply
* [PATCH] ipv6-multicast: Fix memory leak in IPv6 multicast.
From: greearb @ 2011-09-23 23:11 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
If reg_vif_xmit cannot find a routing entry, be sure to
free the skb before returning the error.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 82a8099... e9a8df9... M net/ipv6/ip6mr.c
net/ipv6/ip6mr.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 82a8099..e9a8df9 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -696,8 +696,10 @@ static netdev_tx_t reg_vif_xmit(struct sk_buff *skb,
int err;
err = ip6mr_fib_lookup(net, &fl6, &mrt);
- if (err < 0)
+ if (err < 0) {
+ kfree_skb(skb);
return err;
+ }
read_lock(&mrt_lock);
dev->stats.tx_bytes += skb->len;
--
1.7.3.4
^ permalink raw reply related
* Re: BUG_ON -> WARN_ON in tcp_fragment
From: Nandita Dukkipati @ 2011-09-24 0:43 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Netdev
In-Reply-To: <alpine.DEB.2.00.1109231032450.28649@melkinpaasi.cs.helsinki.fi>
+netdev
Thanks, Ilpo.
On Fri, Sep 23, 2011 at 1:01 AM, Ilpo Järvinen
<ilpo.jarvinen@helsinki.fi> wrote:
>
> On Thu, 22 Sep 2011, Nandita Dukkipati wrote:
>
> > I am observing several instances hitting the BUG_ON(len > skb->len) in
> > tcp_fragment on older kernels. The function passing incorrect arguments is
> > tcp_mark_head_lost. I saw your patch changing BUG_ON to WARN_ON in this
> > patch. That's a good change, however I am trying to put in some amount of
> > debugging information to get to the root cause.
>
> Right, that change won't cure the cause. I was able to determine that some
> invariant must be violated to trigger this. However, the lack of
> information about the state of variables in tcp_mark_head_lost prevented
> me known exactly what is wrong (not to speak of from where the problem
> originates, I certainly tried to read some other code too but so far
> I've not been able to figure it out). I never remembered to do the debug
> patch while I would have had time (and I'm sitting at the computer).
>
> > Given that (packets - oldcnt) < tcp_skb_pcount, it should follow that
> > (packets - oldcnt) * mss < skb->len.
> >
> > 1) Is it possible that the skb has multiple small packets each smaller than
> > mss, in which case we shouldn't expect the above relation to hold?
>
> It should not happen because we recalculate on each retransmission using
> effective MSS. SACK block combines skbs but should only do that for
> S-bit'ed skbs requiring reneging at minimum to get them flying again and
> still they're retransmitted through with the same eff MSS check being
> done. However, I've seen some indications that there could be some bug in
> this as some drivers had to circumvent for the case of very small
> MSS'ed super skb (pcount > 1) because some hardware fails to handle that.
> I've no idea how such segments can be constructed atm but it certainly
> seems that you might be on the right tracks.
>
> If you're seeing them it would be easy to do sanity checks in
> tcp_mark_head_lost instead of tcp_fragment and trigger printouts with more
> verbose information. However, it might not solve the quest for the cause
> as this might only be symptom but certainly is still a good initial step.
>
> > If not, then it appears to be one of the two cases -
> > 2) mss updated in the midst of recovery (path mtu discovery?), without
> > corresponding updates of skb->gso_segs or skb-?gso_size?
>
> This is not relevant, as mss is stored into skb and we fetch it from
> there: mss = skb_shinfo(skb)->gso_size. All such mss changes only affect
> newly generated stuff.
>
> > 3) skb->len is inaccurately updated st some point.
>
> This is another possibility. But due to the other bug report I'm more
> inclined towards the first option. Also, I think this would lead to some
> noisy truesize inconsitency but I'm not the expert in those calculations
> :-D.
>
> > Your thoughts on which of these is a plausible scenario (or something other
> > than these!) would be great.
>
> Some pcount/cnt_hint misvalue might also explain something.
>
> --
> i.
^ 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