* [PATCH 07/10] vmxnet3: remove device counter
From: Stephen Hemminger @ 2013-01-15 17:28 UTC (permalink / raw)
To: David Miller, Shreyas Bhatewara; +Cc: pv-drivers, netdev, Stephen Hemminger
In-Reply-To: <1358270915-32758-1-git-send-email-stephen@networkplumber.org>
An atomic counter of devices present is maintained but never used.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 5 -----
drivers/net/vmxnet3/vmxnet3_int.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 0e55153..1f66a7e 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -43,8 +43,6 @@ static DEFINE_PCI_DEVICE_TABLE(vmxnet3_pciid_table) = {
MODULE_DEVICE_TABLE(pci, vmxnet3_pciid_table);
-static atomic_t devices_found;
-
static int enable_mq = 1;
static int irq_share_mode;
@@ -3005,8 +3003,6 @@ vmxnet3_probe_device(struct pci_dev *pdev,
SET_NETDEV_DEV(netdev, &pdev->dev);
vmxnet3_declare_features(adapter, dma64);
- adapter->dev_number = atomic_read(&devices_found);
-
adapter->share_intr = irq_share_mode;
if (adapter->share_intr == VMXNET3_INTR_BUDDYSHARE &&
adapter->num_tx_queues != adapter->num_rx_queues)
@@ -3057,7 +3053,6 @@ vmxnet3_probe_device(struct pci_dev *pdev,
}
vmxnet3_check_link(adapter, false);
- atomic_inc(&devices_found);
return 0;
err_register:
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 55465ed..3198384 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -352,7 +352,6 @@ struct vmxnet3_adapter {
unsigned long state; /* VMXNET3_STATE_BIT_xxx */
- int dev_number;
int share_intr;
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/10] vmxnet3: remove unused irq_share_mode
From: Stephen Hemminger @ 2013-01-15 17:28 UTC (permalink / raw)
To: David Miller, Shreyas Bhatewara; +Cc: pv-drivers, netdev, Stephen Hemminger
In-Reply-To: <1358270915-32758-1-git-send-email-stephen@networkplumber.org>
This static variable is never set, it initializes to 0 which
is VMXNET3_INTR_BUDDYSHARE, and never changes.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 1f66a7e..45c39cc 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -44,7 +44,6 @@ static DEFINE_PCI_DEVICE_TABLE(vmxnet3_pciid_table) = {
MODULE_DEVICE_TABLE(pci, vmxnet3_pciid_table);
static int enable_mq = 1;
-static int irq_share_mode;
static void
vmxnet3_write_mac_addr(struct vmxnet3_adapter *adapter, u8 *mac);
@@ -3003,9 +3002,9 @@ vmxnet3_probe_device(struct pci_dev *pdev,
SET_NETDEV_DEV(netdev, &pdev->dev);
vmxnet3_declare_features(adapter, dma64);
- adapter->share_intr = irq_share_mode;
- if (adapter->share_intr == VMXNET3_INTR_BUDDYSHARE &&
- adapter->num_tx_queues != adapter->num_rx_queues)
+ if (adapter->num_tx_queues == adapter->num_rx_queues)
+ adapter->share_intr = VMXNET3_INTR_BUDDYSHARE;
+ else
adapter->share_intr = VMXNET3_INTR_DONTSHARE;
vmxnet3_alloc_intr_resources(adapter);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/10] vmxnet3: use static RSS key
From: Stephen Hemminger @ 2013-01-15 17:28 UTC (permalink / raw)
To: David Miller, Shreyas Bhatewara; +Cc: pv-drivers, netdev, Stephen Hemminger
In-Reply-To: <1358270915-32758-1-git-send-email-stephen@networkplumber.org>
Rather than generating a different RSS key on each boot, just use
a predetermined value that will map same flow to same value on
every device for more predictable testing. This is already done
on most hardware drivers.
Initial key value just some arbitrary bits extracted once
from /dev/random.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 45c39cc..9777dc6 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2157,6 +2157,14 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
if (adapter->rss) {
struct UPT1_RSSConf *rssConf = adapter->rss_conf;
+ static const uint8_t rss_key[UPT1_RSS_MAX_KEY_SIZE] = {
+ 0x3b, 0x56, 0xd1, 0x56, 0x13, 0x4a, 0xe7, 0xac,
+ 0xe8, 0x79, 0x09, 0x75, 0xe8, 0x65, 0x79, 0x28,
+ 0x35, 0x12, 0xb9, 0x56, 0x7c, 0x76, 0x4b, 0x70,
+ 0xd8, 0x56, 0xa3, 0x18, 0x9b, 0x0a, 0xee, 0xf3,
+ 0x96, 0xa6, 0x9f, 0x8f, 0x9e, 0x8c, 0x90, 0xc9,
+ };
+
devRead->misc.uptFeatures |= UPT1_F_RSS;
devRead->misc.numRxQueues = adapter->num_rx_queues;
rssConf->hashType = UPT1_RSS_HASH_TYPE_TCP_IPV4 |
@@ -2166,7 +2174,8 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
rssConf->hashFunc = UPT1_RSS_HASH_FUNC_TOEPLITZ;
rssConf->hashKeySize = UPT1_RSS_MAX_KEY_SIZE;
rssConf->indTableSize = VMXNET3_RSS_IND_TABLE_SIZE;
- get_random_bytes(&rssConf->hashKey[0], rssConf->hashKeySize);
+ memcpy(rssConf->hashKey, rss_key, sizeof(rss_key));
+
for (i = 0; i < rssConf->indTableSize; i++)
rssConf->indTable[i] = ethtool_rxfh_indir_default(
i, adapter->num_rx_queues);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/10] vmxnet3: better RSS support
From: Stephen Hemminger @ 2013-01-15 17:28 UTC (permalink / raw)
To: David Miller, Shreyas Bhatewara; +Cc: pv-drivers, netdev, Stephen Hemminger
In-Reply-To: <1358270915-32758-1-git-send-email-stephen@networkplumber.org>
The VMXNET3 device provides RSS hash value for received packets,
but it is not being used.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 9777dc6..b1c90f8 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -1226,6 +1226,11 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
pci_unmap_single(adapter->pdev, rbi->dma_addr, rbi->len,
PCI_DMA_FROMDEVICE);
+#ifdef VMXNET3_RSS
+ if (rcd->rssType != VMXNET3_RCD_RSS_TYPE_NONE &&
+ (adapter->netdev->features & NETIF_F_RXHASH))
+ ctx->skb->rxhash = le32_to_cpu(rcd->rssHash);
+#endif
skb_put(ctx->skb, rcd->len);
/* Immediate refill */
@@ -3022,6 +3027,8 @@ vmxnet3_probe_device(struct pci_dev *pdev,
if (adapter->num_rx_queues > 1 &&
adapter->intr.type == VMXNET3_IT_MSIX) {
adapter->rss = true;
+ netdev->hw_features |= NETIF_F_RXHASH;
+ netdev->features |= NETIF_F_RXHASH;
dev_dbg(&pdev->dev, "RSS is enabled.\n");
} else {
adapter->rss = false;
--
1.7.10.4
^ permalink raw reply related
* Re: small iputils build patch
From: YOSHIFUJI Hideaki @ 2013-01-15 18:24 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: netdev
In-Reply-To: <CADyApD2CxE=mEWKCF9gW=0vGgFkcZZo=DRi-UKP8wNeXMXUifQ@mail.gmail.com>
Arjan van de Ven wrote:
> The ping6 command can use either openssl or gnutls...
> and the Makefile has a bunch of setup for defining which of the two to use.
>
> Unfortunately, the final -D define on the commandline to enable gnutls
> inside the ping6.c file didn't actually make it onto the gcc
> commandline.
> This patch adds the $(DEF_CRYPTO) Makefile variable to fix this gap.
>
> Signed-off-by: Arjan van de Ven <arjanvandeven@gmail.com>
>
Applied, thank you.
--yoshfuji
^ permalink raw reply
* iproute2 man7 patches
From: Stephen Hemminger @ 2013-01-15 17:39 UTC (permalink / raw)
To: Mike Frysinger; +Cc: netdev
Did you look, the only reason man7 exists is that tc-hfsc is in the
wrong place. It should have been in section 8 all along, I will move it.
^ permalink raw reply
* Re: [E1000-devel] [PATCH net-next] igbvf: fix setting addr_assign_type if PF is up
From: Greg Rose @ 2013-01-15 18:31 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Williams, Mitch A, Stefan Assmann, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <20130114222542.GA29729@gospo.rdu.redhat.com>
On Mon, 14 Jan 2013 17:25:42 -0500
Andy Gospodarek <andy@greyhouse.net> wrote:
> On Wed, Jan 09, 2013 at 01:37:45PM -0800, Greg Rose wrote:
> > On Wed, 9 Jan 2013 18:56:36 +0000
> > "Williams, Mitch A" <mitch.a.williams@intel.com> wrote:
> >
> > > > >> When the PF is up and igbvf is loaded the MAC address is not
> > > > >> generated using eth_hw_addr_random(). This results in
> > > > >> addr_assign_type not to be set.
> > > > >> Make sure it gets set.
> > > > >>
> > > > >
> > > > > NAK - In this case, the address may or may not be random. The
> > > > > user may have (and should have!) explicitly set this address
> > > > > from the host to ensure that the VF device receives the same
> > > > > address each time it
> > > > boots.
> > > >
> > > > Maybe you can give me some advice on this then. Why is there
> > > > different behaviour depending on the PF being up or down? The
> > > > problem I'm facing is that if the user did not set a MAC address
> > > > for the VF manually and the PF is up during igbvf_probe it will
> > > > not be labelled as random although it is.
> > > > What about checking IGB_VF_FLAG_PF_SET_MAC and only set
> > > > NET_ADDR_RANDOM if the flag is cleared?
> > > >
> > >
> > > The difference in behavior is because we cannot get any MAC
> > > address at all if the PF is down. The interface won't operate at
> > > all in this case, but if the PF comes up sometime later, we can
> > > start working. The other alternative is to leave the MAC address
> > > as all zeros and forcing the user to assign an address manually.
> > > We chose to use a random address to at least give it a chance of
> > > working once the PF woke up.
> >
> > Having been around at the inception of SR-IOV in Linux I recall that
> > the primary reason we used a random ethernet address was so
> > that the VF could at least work because there was no infrastructure
> > to allow the host administrator to set the MAC address of the VF.
> > This hobbled testing and validation because the user would have to
> > go to each VM and use a command local to the VM to set the VF MAC
> > address to some LAA via ifconfig or ip. When testing large numbers
> > of VFs this was a definite pain.
> >
> > Now that has changed and I wonder if maybe we shouldn't back out the
> > random ethernet address assignment and go ahead with all zeros,
> > leaving the device non-functional until the user has intentionally
> > set either an LAA through the VF itself, or an administratively
> > assigned MAC through the ip tool via the PF.
> >
> > Use of the random MAC address is not recommended by Intel's own best
> > known methods literature, it was used mostly so that we could get
> > the technology working and it should probably be at least
> > considered for deprecation or out right elimination.
> >
>
> It would be great to remove the bits that created random MAC addresses
> for VFs, but wouldn't that break Linus' rule to "not break userspace"
> if it was removed?
It may, I'm not sure but before we make any changes we'd want to do our
due diligence.
>
> There are 2 options that immediately come to mind when looking to
> resolve this:
>
> 1. Use some of the left-over bits in the mailbox messages to pass
> along a flag with the E1000_VF_RESET messages to indicate whether the
> MAC was randomly generated. This would be pretty easy, but there
> could be compatibility issues for a while.
We recently introduced the concept of mailbox message API versions in
our PF and VF drivers to handle this sort of thing. We could probably
leverage that method to introduce a new API version that supports the
additional bits in the reset message. It would only be used if the VF
could negotiate to the proper mailbox message API version with the PF.
>
> 2. Default to a MAC address of all zeros, and as a device with
> all-zeros for a MAC is brought up, randomly create one with
> eth_hw_addr_random. This may not immediately help cases where device
> assignment are a problem, but it would ensure that any device with a
> random MAC as assigned by the kernel, would have NET_ADDR_RANDOM set
> in addr_assign_type.
Thanks for the suggestions. We're considering some changes in this
area but we (Intel) need to give this a lot of thought and right now
we're just in a preliminary discussion mode about it. Stay tuned.
- Greg
>
> --
> 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
* [ 103/221] xen/netfront: improve truesize tracking
From: Greg Kroah-Hartman @ 2013-01-15 18:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ian Campbell, Konrad Rzeszutek Wilk, Greg Kroah-Hartman,
Eric Dumazet, xen-devel, Sander Eikelenboom, annie li, netdev,
David S. Miller, alan
In-Reply-To: <20130115184958.025580322@linuxfoundation.org>
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit d9a58a782e396a0f04e8445b7ba3763c8a48c7fe upstream.
Using RX_COPY_THRESHOLD is incorrect if the SKB is actually smaller
than that. We have already accounted for this in
NETFRONT_SKB_CB(skb)->pull_to so use that instead.
Fixes WARN_ON from skb_try_coalesce.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: annie li <annie.li@oracle.com>
Cc: xen-devel@lists.xen.org
Cc: netdev@vger.kernel.org
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/xen-netfront.c | 27 ++++-----------------------
1 file changed, 4 insertions(+), 23 deletions(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1015,29 +1015,10 @@ err:
i = xennet_fill_frags(np, skb, &tmpq);
/*
- * Truesize approximates the size of true data plus
- * any supervisor overheads. Adding hypervisor
- * overheads has been shown to significantly reduce
- * achievable bandwidth with the default receive
- * buffer size. It is therefore not wise to account
- * for it here.
- *
- * After alloc_skb(RX_COPY_THRESHOLD), truesize is set
- * to RX_COPY_THRESHOLD + the supervisor
- * overheads. Here, we add the size of the data pulled
- * in xennet_fill_frags().
- *
- * We also adjust for any unused space in the main
- * data area by subtracting (RX_COPY_THRESHOLD -
- * len). This is especially important with drivers
- * which split incoming packets into header and data,
- * using only 66 bytes of the main data area (see the
- * e1000 driver for example.) On such systems,
- * without this last adjustement, our achievable
- * receive throughout using the standard receive
- * buffer size was cut by 25%(!!!).
- */
- skb->truesize += skb->data_len - RX_COPY_THRESHOLD;
+ * Truesize is the actual allocation size, even if the
+ * allocation is only partially used.
+ */
+ skb->truesize += PAGE_SIZE * skb_shinfo(skb)->nr_frags;
skb->len += skb->data_len;
if (rx->flags & XEN_NETRXF_csum_blank)
^ permalink raw reply
* [ 121/221] epoll: prevent missed events on EPOLL_CTL_MOD
From: Greg Kroah-Hartman @ 2013-01-15 18:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Kroah-Hartman, alan, Eric Wong, Hans Verkuil, Jiri Olsa,
Jonathan Corbet, Al Viro, Davide Libenzi, Hans de Goede,
Mauro Carvalho Chehab, David Miller, Eric Dumazet, Andrew Morton,
Andreas Voellmy, Junchang(Jason) Wang, Linus Torvalds, netdev,
linux-fsdevel
In-Reply-To: <20130115184958.025580322@linuxfoundation.org>
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Wong <normalperson@yhbt.net>
commit 128dd1759d96ad36c379240f8b9463e8acfd37a1 upstream.
EPOLL_CTL_MOD sets the interest mask before calling f_op->poll() to
ensure events are not missed. Since the modifications to the interest
mask are not protected by the same lock as ep_poll_callback, we need to
ensure the change is visible to other CPUs calling ep_poll_callback.
We also need to ensure f_op->poll() has an up-to-date view of past
events which occured before we modified the interest mask. So this
barrier also pairs with the barrier in wq_has_sleeper().
This should guarantee either ep_poll_callback or f_op->poll() (or both)
will notice the readiness of a recently-ready/modified item.
This issue was encountered by Andreas Voellmy and Junchang(Jason) Wang in:
http://thread.gmane.org/gmane.linux.kernel/1408782/
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Davide Libenzi <davidel@xmailserver.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Voellmy <andreas.voellmy@yale.edu>
Tested-by: "Junchang(Jason) Wang" <junchang.wang@yale.edu>
Cc: netdev@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/eventpoll.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1285,7 +1285,7 @@ static int ep_modify(struct eventpoll *e
* otherwise we might miss an event that happens between the
* f_op->poll() call and the new event set registering.
*/
- epi->event.events = event->events;
+ epi->event.events = event->events; /* need barrier below */
pt._key = event->events;
epi->event.data = event->data; /* protected by mtx */
if (epi->event.events & EPOLLWAKEUP) {
@@ -1296,6 +1296,26 @@ static int ep_modify(struct eventpoll *e
}
/*
+ * The following barrier has two effects:
+ *
+ * 1) Flush epi changes above to other CPUs. This ensures
+ * we do not miss events from ep_poll_callback if an
+ * event occurs immediately after we call f_op->poll().
+ * We need this because we did not take ep->lock while
+ * changing epi above (but ep_poll_callback does take
+ * ep->lock).
+ *
+ * 2) We also need to ensure we do not miss _past_ events
+ * when calling f_op->poll(). This barrier also
+ * pairs with the barrier in wq_has_sleeper (see
+ * comments for wq_has_sleeper).
+ *
+ * This barrier will now guarantee ep_poll_callback or f_op->poll
+ * (or both) will notice the readiness of an item.
+ */
+ smp_mb();
+
+ /*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
^ permalink raw reply
* [PATCH] net: netfilter/xt_CT.c: fix uninitialized variable
From: Cong Ding @ 2013-01-15 18:58 UTC (permalink / raw)
To: Pablo Neira Ayuso, Patrick McHardy, David S. Miller,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
Cc: Cong Ding
If CONFIG_NF_CONNTRACK_ZONES is not defined, the variable ret might be
uninitialized when it goes to err1 through line 125 and 263 respectively.
So I change these goto err1 to return -EINVAL directly.
Signed-off-by: Cong Ding <dinggnu@gmail.com>
---
net/netfilter/xt_CT.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
index 2a08430..941f600 100644
--- a/net/netfilter/xt_CT.c
+++ b/net/netfilter/xt_CT.c
@@ -122,7 +122,7 @@ static int xt_ct_tg_check_v0(const struct xt_tgchk_param *par)
#ifndef CONFIG_NF_CONNTRACK_ZONES
if (info->zone)
- goto err1;
+ return -EINVAL;
#endif
ret = nf_ct_l3proto_try_module_get(par->family);
@@ -260,7 +260,7 @@ static int xt_ct_tg_check_v1(const struct xt_tgchk_param *par)
#ifndef CONFIG_NF_CONNTRACK_ZONES
if (info->zone)
- goto err1;
+ return -EINVAL;
#endif
ret = nf_ct_l3proto_try_module_get(par->family);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] net: netfilter/xt_CT.c: fix uninitialized variable
From: Waskiewicz Jr, Peter P @ 2013-01-15 19:06 UTC (permalink / raw)
To: Cong Ding
Cc: Pablo Neira Ayuso, Patrick McHardy, David S. Miller,
netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1358276314-9536-1-git-send-email-dinggnu@gmail.com>
On Tue, 2013-01-15 at 19:58 +0100, Cong Ding wrote:
> If CONFIG_NF_CONNTRACK_ZONES is not defined, the variable ret might be
> uninitialized when it goes to err1 through line 125 and 263 respectively.
> So I change these goto err1 to return -EINVAL directly.
>
> Signed-off-by: Cong Ding <dinggnu@gmail.com>
> ---
> net/netfilter/xt_CT.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
> index 2a08430..941f600 100644
> --- a/net/netfilter/xt_CT.c
> +++ b/net/netfilter/xt_CT.c
> @@ -122,7 +122,7 @@ static int xt_ct_tg_check_v0(const struct xt_tgchk_param *par)
>
> #ifndef CONFIG_NF_CONNTRACK_ZONES
> if (info->zone)
> - goto err1;
> + return -EINVAL;
> #endif
>
> ret = nf_ct_l3proto_try_module_get(par->family);
> @@ -260,7 +260,7 @@ static int xt_ct_tg_check_v1(const struct xt_tgchk_param *par)
>
> #ifndef CONFIG_NF_CONNTRACK_ZONES
> if (info->zone)
> - goto err1;
> + return -EINVAL;
> #endif
In dropping both goto's, you left the err1 label unused. Wouldn't just
initializing ret to -EINVAL be easier and cleaner? Then you wouldn't be
messing with the flow of the function.
-PJ
^ permalink raw reply
* Re: [PATCH 3/5] soreuseport: UDP/IPv4 implementation
From: Ben Hutchings @ 2013-01-15 19:14 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Tom Herbert, netdev, davem, netdev, eric.dumazet
In-Reply-To: <20130115075803.17ed2bc5@nehalam.linuxnetplumber.net>
On Tue, 2013-01-15 at 07:58 -0800, Stephen Hemminger wrote:
> On Mon, 14 Jan 2013 12:00:23 -0800 (PST)
> Tom Herbert <therbert@google.com> wrote:
>
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index 79c8dbe..1dd1e93 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -139,6 +139,7 @@ static int udp_lib_lport_inuse(struct net *net, __u16 num,
> > {
> > struct sock *sk2;
> > struct hlist_nulls_node *node;
> > + int uid = sock_i_uid(sk);
> >
>
> I am not a namespace expert, but it looks like this might have
> to use from_kuid_munged(). At a minimum it should be:
> kuid_t uid = sock_i_uid(sk);
Right, and the comparison has to be done with uid_eq().
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: netfilter/xt_CT.c: fix uninitialized variable
From: Cong Ding @ 2013-01-15 19:16 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: Pablo Neira Ayuso, Patrick McHardy, David S. Miller,
netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1358276792.1991.121.camel@ppwaskie-mobl2>
On Tue, Jan 15, 2013 at 07:06:51PM +0000, Waskiewicz Jr, Peter P wrote:
> On Tue, 2013-01-15 at 19:58 +0100, Cong Ding wrote:
> > If CONFIG_NF_CONNTRACK_ZONES is not defined, the variable ret might be
> > uninitialized when it goes to err1 through line 125 and 263 respectively.
> > So I change these goto err1 to return -EINVAL directly.
> >
> > Signed-off-by: Cong Ding <dinggnu@gmail.com>
> > ---
> > net/netfilter/xt_CT.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
> > index 2a08430..941f600 100644
> > --- a/net/netfilter/xt_CT.c
> > +++ b/net/netfilter/xt_CT.c
> > @@ -122,7 +122,7 @@ static int xt_ct_tg_check_v0(const struct xt_tgchk_param *par)
> >
> > #ifndef CONFIG_NF_CONNTRACK_ZONES
> > if (info->zone)
> > - goto err1;
> > + return -EINVAL;
> > #endif
> >
> > ret = nf_ct_l3proto_try_module_get(par->family);
> > @@ -260,7 +260,7 @@ static int xt_ct_tg_check_v1(const struct xt_tgchk_param *par)
> >
> > #ifndef CONFIG_NF_CONNTRACK_ZONES
> > if (info->zone)
> > - goto err1;
> > + return -EINVAL;
> > #endif
>
> In dropping both goto's, you left the err1 label unused. Wouldn't just
> initializing ret to -EINVAL be easier and cleaner? Then you wouldn't be
> messing with the flow of the function.
The label err1 are also used in line 130 and 298. I change it to "return
-EINVAL" rather than initialize ret to -EINVAL is to keep it the same as line
115 and 253. Otherwise, we should change line 115 and 253 to be goto err1,
too?
- cong
^ permalink raw reply
* Re: [PATCH] net: netfilter/xt_CT.c: fix uninitialized variable
From: Pablo Neira Ayuso @ 2013-01-15 19:18 UTC (permalink / raw)
To: Cong Ding
Cc: Patrick McHardy, David S. Miller, netfilter-devel, netfilter,
coreteam, netdev, linux-kernel
In-Reply-To: <1358276314-9536-1-git-send-email-dinggnu@gmail.com>
Hi Cong,
On Tue, Jan 15, 2013 at 07:58:34PM +0100, Cong Ding wrote:
> If CONFIG_NF_CONNTRACK_ZONES is not defined, the variable ret might be
> uninitialized when it goes to err1 through line 125 and 263 respectively.
> So I change these goto err1 to return -EINVAL directly.
This is already fixed in the net tree.
http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=4610476d89d53714ca94aae081fa035908bc137a
^ permalink raw reply
* Re: [PATCH 09/10] vmxnet3: use static RSS key
From: Ben Hutchings @ 2013-01-15 19:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Shreyas Bhatewara, pv-drivers, netdev
In-Reply-To: <1358270915-32758-10-git-send-email-stephen@networkplumber.org>
On Tue, 2013-01-15 at 09:28 -0800, Stephen Hemminger wrote:
> Rather than generating a different RSS key on each boot, just use
> a predetermined value that will map same flow to same value on
> every device for more predictable testing. This is already done
> on most hardware drivers.
>
> Initial key value just some arbitrary bits extracted once
> from /dev/random.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
[...]
I agree with the idea, but shouldn't we have just one copy of this key
that drivers can refer to?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next 09/10] bnx2x: Added FW GRO bridging support
From: David Miller @ 2013-01-15 20:09 UTC (permalink / raw)
To: yuvalmin; +Cc: eric.dumazet, netdev, eilong, ariele
In-Reply-To: <50F56178.8000502@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Tue, 15 Jan 2013 16:02:32 +0200
> Considering Eric's response, following with option (1) or (2) seems like the
> right way to go.
>
> Do you want a new patch series which will include a fix for this,
> or will you accept a later fix that sets the gso_segs correctly?
>
> (considering this issue is not introduced in this patch,
> merely isn't being solved by it)
I've merged your patch series as-is to net-next, please work on fixing
the problems Eric has pointed out.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipip: do not use 'err' variable for setting return value
From: Jean Sacren @ 2013-01-15 21:32 UTC (permalink / raw)
To: David Miller; +Cc: sakiwit, netdev
In-Reply-To: <20130115.032008.1473140825117157751.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 15 Jan 2013 03:20:08 -0500
>
> From: Jean Sacren <sakiwit@gmail.com>
> Date: Tue, 15 Jan 2013 01:14:10 -0700
>
> > It's a bit confusing to set 'err' variable inside and outside of the
> > block for the return value of ipip_err(). We don't even need this
> > variable, so clean it all up to spare declaration as well as bunch of
> > unnecessary initializations and jumps.
> >
> > Signed-off-by: Jean Sacren <sakiwit@gmail.com>
>
> It makes the non-error path straight line code.
I thought about the error path, but I realized the error handling code
couldn't be simpler. There is only one error, namely ENOENT, which
warrants no error path. As 'err' variable was used, you were forced to
reset it to zero seven months ago. Again you were forced to reset it to
zero six months ago. As you were doubly forced, finally I came up with
this idea of getting rid of the unnecessary variable.
Also the error handling in the patch is consistent with the way earlier
portion of the function definition does.
> The code as-is is fine, and I'm not applying this patch, sorry.
Thank you for reviewing. This is a rather trivial patch. If patches like
this one are not compelling enough for acceptance, that's fair enough.
--
Jean Sacren
^ permalink raw reply
* RE: Patch for stable: bridge: Pull ip header into skb->data before looking into ip header.
From: Bandi,Sarveshwar @ 2013-01-15 21:36 UTC (permalink / raw)
To: Bandi,Sarveshwar, davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <9D1F9FE58F08ED47AA451ABB038550E91FEB7EB1@CMEXMB2.ad.emulex.com>
Dave,
Did you miss this? Or this is there a different process to request this?
Thanks,
Sarvesh
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Bandi,Sarveshwar
Sent: Friday, January 11, 2013 12:29 PM
To: davem@davemloft.net
Cc: netdev@vger.kernel.org
Subject: Patch for stable: bridge: Pull ip header into skb->data before looking into ip header.
Dave,
Can you please queue the following patch for linux 3.x stable trees?
commit 6caab7b0544e83e6c160b5e80f5a4a7dd69545c7
Author: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Date: Wed Oct 10 01:15:01 2012 +0000
bridge: Pull ip header into skb->data before looking into ip header.
If lower layer driver leaves the ip header in the skb fragment, it needs to
be first pulled into skb->data before inspecting ip header length or ip version
number.
Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thanks,
Sarvesh
--
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
* [PATCH net-next 3/3] net: stmmac: add gmac autonego set for ethtool support
From: Byungho An @ 2013-01-15 21:45 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: 'Giuseppe CAVALLARO', davem, jeffrey.t.kirsher, kgene.kim
This patch adds gmac auto-negotiation setting for ethtool.
If interface is SGMII, TBI or RTBI, gmac's auto-negotiation
enable bit is need to set.
Signed-off-by: Byungho An <bh74.an@samsung.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 1372ce2..457c1a4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -335,6 +335,7 @@ stmmac_set_pauseparam(struct net_device *netdev,
struct phy_device *phy = priv->phydev;
int new_pause = FLOW_OFF;
int ret = 0;
+ int interface = priv->plat->interface;
spin_lock(&priv->lock);
@@ -348,6 +349,10 @@ stmmac_set_pauseparam(struct net_device *netdev,
if (phy->autoneg) {
if (netif_running(netdev))
+ if (interface == PHY_INTERFACE_MODE_SGMII ||
+ interface == PHY_INTERFACE_MODE_TBI ||
+ interface == PHY_INTERFACE_MODE_RTBI)
+ priv->hw->mac->set_autoneg(priv->ioaddr);
ret = phy_start_aneg(phy);
} else
priv->hw->mac->flow_ctrl(priv->ioaddr, phy->duplex,
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next 2/3] net: stmmac: add autoneg complete irq
From: Byungho An @ 2013-01-15 21:49 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: 'Giuseppe CAVALLARO', davem, jeffrey.t.kirsher, kgene.kim
This patch adds auto-negotiation complete irq and ISR.
when the irq is occured it read GMAC_AN_STATUS register
to clear PCSANCIS bit.
Singed-off-by: Byungho An <bh74.an@samsung.com>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 5 +++++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++
4 files changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 72ba769..bc5ce7a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -203,6 +203,7 @@ enum core_specific_irq_mask {
core_irq_tx_path_exit_lpi_mode = 32,
core_irq_rx_path_in_lpi_mode = 64,
core_irq_rx_path_exit_lpi_mode = 128,
+ core_irq_pcs_autoneg_complete = 256,
};
/* DMA HW capabilities */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index a0737b39..0643ed3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -222,6 +222,11 @@ static int dwmac1000_irq_status(void __iomem *ioaddr)
readl(ioaddr + GMAC_PMT);
status |= core_irq_receive_pmt_irq;
}
+ if (unlikely(intr_status & pcs_ane_irq)) {
+ CHIP_DBG(KERN_INFO "GMAC: PCS Auto-negotiation complete\n");
+ readl(ioaddr + GMAC_AN_STATUS);
+ status |= core_irq_pcs_autoneg_complete;
+ }
/* MAC trx/rx EEE LPI entry/exit interrupts */
if (intr_status & lpiis_irq) {
/* Clean LPI interrupt by reading the Reg 12 */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index b05df89..b4220f3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -93,6 +93,7 @@ struct stmmac_priv {
u32 tx_coal_timer;
int use_riwt;
u32 rx_riwt;
+ bool core_pcs_an;
};
extern int phyaddr;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3e28934..0d2afbb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1623,6 +1623,8 @@ static irqreturn_t stmmac_interrupt(int irq, void
*dev_id)
priv->xstats.mmc_rx_csum_offload_irq_n++;
if (status & core_irq_receive_pmt_irq)
priv->xstats.irq_receive_pmt_irq_n++;
+ if (status & core_irq_pcs_autoneg_complete)
+ priv->core_pcs_an = true;
/* For LPI we need to save the tx status */
if (status & core_irq_tx_path_in_lpi_mode) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next 1/3] net: stmmac: add gmac autoneg set for SGMII, TBI, and RTBI
From: Byungho An @ 2013-01-15 22:06 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: 'Giuseppe CAVALLARO', davem, jeffrey.t.kirsher, kgene.kim
This patch adds gmac autoneg set function for SGMII, TBI,
or RTBI interface. In case of PHY's autoneg is set, gmac's
autoneg enable bit should set. After checking phy's autoneg
if phydev's autoneg is '1' gmac's ANE bit set for those
interface.
Signed-off-by: Byungho An <bh74.an@samsung.com>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 11 +++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++++++
3 files changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 186d148..72ba769 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -344,6 +344,7 @@ struct stmmac_ops {
void (*reset_eee_mode) (void __iomem *ioaddr);
void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
void (*set_eee_pls) (void __iomem *ioaddr, int link);
+ void (*set_autoneg) (void __iomem *ioaddr);
};
struct mac_link {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index bfe0226..a0737b39 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -297,6 +297,16 @@ static void dwmac1000_set_eee_timer(void __iomem
*ioaddr, int ls, int tw)
writel(value, ioaddr + LPI_TIMER_CTRL);
}
+static void dwmac1000_set_autoneg(void __iomem *ioaddr)
+{
+ u32 value;
+
+ value = readl(ioaddr + GMAC_AN_CTRL);
+ value |= 0x1000;
+ writel(value, ioaddr + GMAC_AN_CTRL);
+}
+
+
static const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
.rx_ipc = dwmac1000_rx_ipc_enable,
@@ -311,6 +321,7 @@ static const struct stmmac_ops dwmac1000_ops = {
.reset_eee_mode = dwmac1000_reset_eee_mode,
.set_eee_timer = dwmac1000_set_eee_timer,
.set_eee_pls = dwmac1000_set_eee_pls,
+ .set_autoneg = dwmac1000_set_autoneg,
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f07c061..3e28934 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1007,6 +1007,7 @@ static int stmmac_open(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
+ int interface = priv->plat->interface;
clk_prepare_enable(priv->stmmac_clk);
@@ -1041,6 +1042,14 @@ static int stmmac_open(struct net_device *dev)
/* Initialize the MAC Core */
priv->hw->mac->core_init(priv->ioaddr);
+ /* If phy autoneg is on, set gmac autoneg for SGMII, TBI and RTBI*/
+ if (interface == PHY_INTERFACE_MODE_SGMII ||
+ interface == PHY_INTERFACE_MODE_TBI ||
+ interface == PHY_INTERFACE_MODE_RTBI) {
+ if (priv->phydev->autoneg)
+ priv->hw->mac->set_autoneg(priv->ioaddr);
+ }
+
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
IRQF_SHARED, dev->name, dev);
--
1.7.10.4
^ permalink raw reply related
* [ 069/171] epoll: prevent missed events on EPOLL_CTL_MOD
From: Greg Kroah-Hartman @ 2013-01-15 22:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Kroah-Hartman, alan, Eric Wong, Hans Verkuil, Jiri Olsa,
Jonathan Corbet, Al Viro, Davide Libenzi, Hans de Goede,
Mauro Carvalho Chehab, David Miller, Eric Dumazet, Andrew Morton,
Andreas Voellmy, Junchang(Jason) Wang, Linus Torvalds, netdev,
linux-fsdevel
In-Reply-To: <20130115224313.394976595@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Wong <normalperson@yhbt.net>
commit 128dd1759d96ad36c379240f8b9463e8acfd37a1 upstream.
EPOLL_CTL_MOD sets the interest mask before calling f_op->poll() to
ensure events are not missed. Since the modifications to the interest
mask are not protected by the same lock as ep_poll_callback, we need to
ensure the change is visible to other CPUs calling ep_poll_callback.
We also need to ensure f_op->poll() has an up-to-date view of past
events which occured before we modified the interest mask. So this
barrier also pairs with the barrier in wq_has_sleeper().
This should guarantee either ep_poll_callback or f_op->poll() (or both)
will notice the readiness of a recently-ready/modified item.
This issue was encountered by Andreas Voellmy and Junchang(Jason) Wang in:
http://thread.gmane.org/gmane.linux.kernel/1408782/
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Davide Libenzi <davidel@xmailserver.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Voellmy <andreas.voellmy@yale.edu>
Tested-by: "Junchang(Jason) Wang" <junchang.wang@yale.edu>
Cc: netdev@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/eventpoll.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1226,11 +1226,31 @@ static int ep_modify(struct eventpoll *e
* otherwise we might miss an event that happens between the
* f_op->poll() call and the new event set registering.
*/
- epi->event.events = event->events;
+ epi->event.events = event->events; /* need barrier below */
pt._key = event->events;
epi->event.data = event->data; /* protected by mtx */
/*
+ * The following barrier has two effects:
+ *
+ * 1) Flush epi changes above to other CPUs. This ensures
+ * we do not miss events from ep_poll_callback if an
+ * event occurs immediately after we call f_op->poll().
+ * We need this because we did not take ep->lock while
+ * changing epi above (but ep_poll_callback does take
+ * ep->lock).
+ *
+ * 2) We also need to ensure we do not miss _past_ events
+ * when calling f_op->poll(). This barrier also
+ * pairs with the barrier in wq_has_sleeper (see
+ * comments for wq_has_sleeper).
+ *
+ * This barrier will now guarantee ep_poll_callback or f_op->poll
+ * (or both) will notice the readiness of an item.
+ */
+ smp_mb();
+
+ /*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
^ permalink raw reply
* [ 46/71] epoll: prevent missed events on EPOLL_CTL_MOD
From: Greg Kroah-Hartman @ 2013-01-15 22:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Kroah-Hartman, alan, Eric Wong, Hans Verkuil, Jiri Olsa,
Jonathan Corbet, Al Viro, Davide Libenzi, Hans de Goede,
Mauro Carvalho Chehab, David Miller, Eric Dumazet, Andrew Morton,
Andreas Voellmy, Junchang(Jason) Wang, Linus Torvalds,
Ben Hutchings, netdev, linux-fsdevel
In-Reply-To: <20130115225340.367496998@linuxfoundation.org>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
commit 128dd1759d96ad36c379240f8b9463e8acfd37a1 upstream.
EPOLL_CTL_MOD sets the interest mask before calling f_op->poll() to
ensure events are not missed. Since the modifications to the interest
mask are not protected by the same lock as ep_poll_callback, we need to
ensure the change is visible to other CPUs calling ep_poll_callback.
We also need to ensure f_op->poll() has an up-to-date view of past
events which occured before we modified the interest mask. So this
barrier also pairs with the barrier in wq_has_sleeper().
This should guarantee either ep_poll_callback or f_op->poll() (or both)
will notice the readiness of a recently-ready/modified item.
This issue was encountered by Andreas Voellmy and Junchang(Jason) Wang in:
http://thread.gmane.org/gmane.linux.kernel/1408782/
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Davide Libenzi <davidel@xmailserver.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Voellmy <andreas.voellmy@yale.edu>
Tested-by: "Junchang(Jason) Wang" <junchang.wang@yale.edu>
Cc: netdev@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/eventpoll.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1197,10 +1197,30 @@ static int ep_modify(struct eventpoll *e
* otherwise we might miss an event that happens between the
* f_op->poll() call and the new event set registering.
*/
- epi->event.events = event->events;
+ epi->event.events = event->events; /* need barrier below */
epi->event.data = event->data; /* protected by mtx */
/*
+ * The following barrier has two effects:
+ *
+ * 1) Flush epi changes above to other CPUs. This ensures
+ * we do not miss events from ep_poll_callback if an
+ * event occurs immediately after we call f_op->poll().
+ * We need this because we did not take ep->lock while
+ * changing epi above (but ep_poll_callback does take
+ * ep->lock).
+ *
+ * 2) We also need to ensure we do not miss _past_ events
+ * when calling f_op->poll(). This barrier also
+ * pairs with the barrier in wq_has_sleeper (see
+ * comments for wq_has_sleeper).
+ *
+ * This barrier will now guarantee ep_poll_callback or f_op->poll
+ * (or both) will notice the readiness of an item.
+ */
+ smp_mb();
+
+ /*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
^ permalink raw reply
* Re: r8169 rx_missed increasing in bursts (regression)
From: Francois Romieu @ 2013-01-15 22:53 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev
In-Reply-To: <20130115101114.0a59a7cb@vostro>
Timo Teras <timo.teras@iki.fi> :
[...]
> Would it be feasible to make the fifo size a module parameter, or
> somehow autotuned according to available system memory?
If by fifo size you mean descriptor ring size, I can do it through ethtool.
> I also noticed that since recent commits, the dirty_rx is always
> identical cur_rx. Basically, dirty_rx can be just removed. Should I
> send a patch for this?
Yes, please.
--
Ueimor
^ permalink raw reply
* Repeatable kernel splat in 3.3.8+, related to ip_rcv_finish
From: Ben Greear @ 2013-01-16 0:33 UTC (permalink / raw)
To: netdev
I have a reproducible crash (5-15 minutes typically)
in a hacked 3.3.8+ kernel. No proprietary modules, but my normal mix of
networking patches are applied, so it could be my fault.
The crash always appears to be in the ip_rcv_finish method.
On a pervious panic, the 'IP' was 0xFFFFFFFF, and I've seen
it be other similar values before. I'm not sure what this
implies....
Test case is 2000 mac-vlans, resetting about 50 of them at a time
during bringup, while also driving lower-speed NFS traffic on a
mount for each of the already-reset mac-vlans. It takes multiple
minutes for my app to fully reset all of the interfaces and start
traffic, and there are lots and lots of network changes going on
at or just previous to the crashes.
I need the nfs-bind-to-local-ip patches that I carry in my tree to
reproduce this, so I can't run this test on upstream kernels.
I will work on porting these into the 3.7 kernel for testing there
in the meantime.
Does this bug look familiar to anyone?
(gdb) l *(ip_rcv_finish+0x2ea)
0xffffffff814423e6 is in ip_rcv_finish (/home/greearb/git/linux-3.3.dev.y/net/ipv4/ip_input.c:365).
360 skb->len);
361 } else if (rt->rt_type == RTN_BROADCAST)
362 IP_UPD_PO_STATS_BH(dev_net(rt->dst.dev), IPSTATS_MIB_INBCAST,
363 skb->len);
364
365 return dst_input(skb);
366
367 drop:
368 kfree_skb(skb);
369 return NET_RX_DROP;
(gdb)
BUG: unable to handle kernel paging request at 0000001d00088000
IP: [<0000001d00088000>] 0x1d00087fff
PGD 372cb6067 PUD 0
Oops: 0010 [#1] PREEMPT SMP
CPU 11
Modules linked in: nfs nfs_acl auth_rpcgss fscache 8021q garp stp llc lockd sunrpc macvlan pktgen microcode pcspkr i2c_i801 i2c_core i7core_edac e1000e iTCO_wdt
iTCO_vendor_support ioatdma igb dca edac_core uinput ipv6 [last unloaded: scsi_wait_scan]
Pid: 67, comm: ksoftirqd/11 Tainted: G O 3.3.8+ #55 Iron Systems Inc. EE2610R/X8ST3
RIP: 0010:[<0000001d00088000>] [<0000001d00088000>] 0x1d00087fff
RSP: 0018:ffff88040974dc78 EFLAGS: 00010286
RAX: ffff88038526e500 RBX: ffff88038526eb00 RCX: ffff88038526eb00
RDX: 0000000000000020 RSI: 0000000000000002 RDI: ffff88038526eb00
RBP: ffff88040974dca0 R08: ffffffff814420fc R09: 0000000000000000
R10: ffff88040974d710 R11: ffffffff80000000 R12: ffff880357f4fcfc
R13: ffff880409295000 R14: 0000000000000000 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff88041fd60000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000001d00088000 CR3: 00000003958bd000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ksoftirqd/11 (pid: 67, threadinfo ffff88040974c000, task ffff880409741740)
Stack:
ffffffff814423e6 ffff88038526eb00 ffffffff814420fc ffff880409295000
0000000000000000 ffff88040974dcd0 ffffffff8144274e ffff880480000000
ffff880409741740 ffff88038526eb00 ffff880409295000 ffff88040974dd00
Call Trace:
[<ffffffff814423e6>] ? ip_rcv_finish+0x2ea/0x302
[<ffffffff814420fc>] ? inet_del_protocol+0x37/0x37
eth3#739: no IPv6 routers present
[<ffffffff8144274e>] NF_HOOK.clone.1+0x4c/0x53
[<ffffffff814429d9>] ip_rcv+0x237/0x262
[<ffffffff8140ea4f>] __netif_receive_skb+0x477/0x4c0
[<ffffffff8140eb8c>] process_backlog+0xf4/0x1d6
[<ffffffff81410ae8>] net_rx_action+0xad/0x1e9
[<ffffffff8105b105>] __do_softirq+0x86/0x12f
[<ffffffff8105b261>] run_ksoftirqd+0xb3/0x1a6
[<ffffffff8105b1ae>] ? __do_softirq+0x12f/0x12f
[<ffffffff8105b1ae>] ? __do_softirq+0x12f/0x12f
[<ffffffff8106da7d>] kthread+0x84/0x8c
[<ffffffff814cc4e4>] kernel_thread_helper+0x4/0x10
[<ffffffff8106d9f9>] ? __init_kthread_worker+0x37/0x37
[<ffffffff814cc4e0>] ? gs_change+0x13/0x13
Code: Bad RIP value.
RIP [<0000001d00088000>] 0x1d00087fff
RSP <ffff88040974dc78>
CR2: 0000001d00088000
---[ end trace 1d145cfe9c5c5d55 ]---
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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