* [PATCH -next] net: netcp: drop kfree for memory allocated with devm_kzalloc
From: Wei Yongjun @ 2016-10-22 12:32 UTC (permalink / raw)
To: Wingman Kwok, Murali Karicheri; +Cc: Wei Yongjun, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
It's not necessary to free memory allocated with devm_kzalloc in the
remove path and using kfree leads to a double free.
Fixes: 84640e27f230 ("net: netcp: Add Keystone NetCP core ethernet
driver")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/ti/netcp_core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 11609d5..2fb5b6d 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -2058,7 +2058,6 @@ static void netcp_delete_interface(struct netcp_device *netcp_device,
if (module->release)
module->release(intf_modpriv->module_priv);
list_del(&intf_modpriv->intf_list);
- kfree(intf_modpriv);
}
WARN(!list_empty(&netcp->module_head), "%s interface module list is not empty!\n",
ndev->name);
@@ -2153,7 +2152,6 @@ static int netcp_remove(struct platform_device *pdev)
dev_dbg(&pdev->dev, "Removing module \"%s\"\n", module->name);
module->remove(netcp_device, inst_modpriv->module_priv);
list_del(&inst_modpriv->inst_list);
- kfree(inst_modpriv);
}
/* now that all modules are removed, clean up the interfaces */
^ permalink raw reply related
* Re: [PATCH net-next 09/15] ethernet/dlink: use core min/max MTU checking
From: Stefan Richter @ 2016-10-22 9:54 UTC (permalink / raw)
To: Jarod Wilson; +Cc: Denis Kirjanov, linux-kernel, netdev
In-Reply-To: <20161018150452.GU14983@redhat.com>
On Oct 18 Jarod Wilson wrote:
> On Tue, Oct 18, 2016 at 04:45:51PM +0300, Denis Kirjanov wrote:
> > On 10/17/16, Jarod Wilson <jarod@redhat.com> wrote:
[...]
> > > --- a/drivers/net/ethernet/dlink/sundance.c
> > > +++ b/drivers/net/ethernet/dlink/sundance.c
> > > @@ -580,6 +580,10 @@ static int sundance_probe1(struct pci_dev *pdev,
> > > dev->ethtool_ops = ðtool_ops;
> > > dev->watchdog_timeo = TX_TIMEOUT;
> > >
> > > + /* MTU range: 68 - 8191 */
> > > + dev->min_mtu = ETH_MIN_MTU;
> > > + dev->max_mtu = 8191;
> > > +
> > ICPlus datasheet defines the max frame size like 0x1514 or 0x4491
> > based on the RcvLargeFrames bit in the MACCtrl0 register
>
> I do anticipate this patchset might bring to light some inaccuracies in
> min/max mtu values currently implemented in various drivers, but for the
> moment, I'm going for 100% identical behavior with what's currently in the
> driver, and if you'll look down below...
>
> > > pci_set_drvdata(pdev, dev);
> > >
> > > i = register_netdev(dev);
> > > @@ -713,8 +717,6 @@ static int sundance_probe1(struct pci_dev *pdev,
> > >
> > > static int change_mtu(struct net_device *dev, int new_mtu)
> > > {
> > > - if ((new_mtu < 68) || (new_mtu > 8191)) /* Set by RxDMAFrameLen */
>
> ^^^^
> The 8191 was simply transplanted from right here. I think altering the
> value should be the subject of a separate patch.
You transplanted the value but dropped the comment. Though Denis' reply
sounds like the comment should have been /* FIXME, set by RxDMAFrameLen */.
--
Stefan Richter
-======----- =-=- =-==-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers
From: Stefan Richter @ 2016-10-22 9:36 UTC (permalink / raw)
To: Jarod Wilson
Cc: Sabrina Dubroca, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Faisal Latif,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Cliff Whickman, Robin Holt,
Jes Sorensen, Marek Lindner, Simon Wunderlich, Antonio Quartulli
In-Reply-To: <20161020031641.GJ18569-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Oct 19 Jarod Wilson wrote:
> On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> > On Oct 19 Sabrina Dubroca wrote:
> > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
> > > [...]
> > > > diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
> > > > index 309311b..b5f125c 100644
> > > > --- a/drivers/firewire/net.c
> > > > +++ b/drivers/firewire/net.c
> > > > @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
> > > > return NETDEV_TX_OK;
> > > > }
> > > >
> > > > -static int fwnet_change_mtu(struct net_device *net, int new_mtu)
> > > > -{
> > > > - if (new_mtu < 68)
> > > > - return -EINVAL;
> > > > -
> > > > - net->mtu = new_mtu;
> > > > - return 0;
> > > > -}
> > > > -
> > >
> > > This doesn't do any upper bound checking.
> >
> > I need to check more closely, but I think the RFC 2734 encapsulation spec
> > and our implementation do not impose a particular upper limit. Though I
> > guess it's bad to let userland set arbitrarily large values here.
>
> In which case, that would suggest using IP_MAX_MTU (65535) here.
Probably. I (or somebody) need to check the spec and the code once more.
[...]
> > > > @@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit,
> > > > max_mtu = (1 << (card->max_receive + 1))
> > > > - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > > > net->mtu = min(1500U, max_mtu);
> > > > + net->min_mtu = ETH_MIN_MTU;
> > > > + net->max_mtu = net->mtu;
> > >
> > > But that will now prevent increasing the MTU above the initial value?
> >
> > Indeed, therefore NAK.
>
> However, there's an explicit calculation for 'max_mtu' right there that I
> glazed right over. It would seem perhaps *that* should be used for
> net->max_mtu here, no?
No. This 'max_mtu' here is not the absolute maximum. It is only an
initial MTU which has the property that link fragmentation is not
going to happen (if all other peers will at least as capable as this
node).
--
Stefan Richter
-======----- =-=- =-==-
http://arcgraph.de/sr/
--
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
* [PATCH] batman-adv: Revert "use core MTU range checking in misc drivers"
From: Sven Eckelmann @ 2016-10-22 7:46 UTC (permalink / raw)
To: netdev; +Cc: davem, b.a.t.m.a.n, linux-kernel, Sven Eckelmann, Jarod Wilson
The maximum MTU is defined via the slave devices of an batman-adv
interface. Thus it is not possible to calculate the max_mtu during the
creation of the batman-adv device when no slave devices are attached. Doing
so would for example break non-fragmentation setups which then
(incorrectly) allow an MTU of 1500 even when underlying device cannot
transport 1500 bytes + batman-adv headers.
Checking the dynamically calculated max_mtu via the minimum of the slave
devices MTU during .ndo_change_mtu is also used by the bridge interface.
Cc: Jarod Wilson <jarod@redhat.com>
Fixes: b3e3893e1253 ("net: use core MTU range checking in misc drivers")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
Original patch + my comment: https://patchwork.ozlabs.org/patch/684722/
I just got informed about this patch when it was already applied in net-next.
So I can only ask for an revet of the batman-adv parts
net/batman-adv/soft-interface.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 112679d..49e16b6 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -158,6 +158,17 @@ static int batadv_interface_set_mac_addr(struct net_device *dev, void *p)
return 0;
}
+static int batadv_interface_change_mtu(struct net_device *dev, int new_mtu)
+{
+ /* check ranges */
+ if ((new_mtu < 68) || (new_mtu > batadv_hardif_min_mtu(dev)))
+ return -EINVAL;
+
+ dev->mtu = new_mtu;
+
+ return 0;
+}
+
/**
* batadv_interface_set_rx_mode - set the rx mode of a device
* @dev: registered network device to modify
@@ -909,6 +920,7 @@ static const struct net_device_ops batadv_netdev_ops = {
.ndo_vlan_rx_add_vid = batadv_interface_add_vid,
.ndo_vlan_rx_kill_vid = batadv_interface_kill_vid,
.ndo_set_mac_address = batadv_interface_set_mac_addr,
+ .ndo_change_mtu = batadv_interface_change_mtu,
.ndo_set_rx_mode = batadv_interface_set_rx_mode,
.ndo_start_xmit = batadv_interface_tx,
.ndo_validate_addr = eth_validate_addr,
@@ -975,7 +987,6 @@ struct net_device *batadv_softif_create(struct net *net, const char *name)
dev_net_set(soft_iface, net);
soft_iface->rtnl_link_ops = &batadv_link_ops;
- soft_iface->max_mtu = batadv_hardif_min_mtu(soft_iface);
ret = register_netdevice(soft_iface);
if (ret < 0) {
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] net: skip genenerating uevents for network namespaces that are exiting
From: Andrey Vagin @ 2016-10-22 7:37 UTC (permalink / raw)
To: Cong Wang
Cc: LKML, Linux Containers, Linux Kernel Network Developers,
David S. Miller, Eric W . Biederman
In-Reply-To: <CANaxB-zo4YW7o-Ebe08B_L_f8Wyp6tMWc-rBRt8-4sSc1Y=tgg@mail.gmail.com>
Hi Cong,
On Thu, Oct 20, 2016 at 10:25 PM, Andrey Vagin <avagin@openvz.org> wrote:
> On Thu, Oct 20, 2016 at 8:10 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Thu, Oct 20, 2016 at 7:46 PM, Andrei Vagin <avagin@openvz.org> wrote:
>>> No one can see these events, because a network namespace can not be
>>> destroyed, if it has sockets.
>>>
>>
>> Are you sure? kobject_uevent_env() seems sending uevents to all
>> network namespaces.
>
> kobj_bcast_filter() checks that a kobject namespace is equal to a
> socket namespace.
Today I've checked that it really works as I read from the source code.
I use this tool to read events:
https://gist.github.com/avagin/430ba431fc2972002df40ebe6a048b36
And I see that events from non-network devices are delivered to all sockets,
but events from network devices are delivered only to sockets from
a network namespace where a device is operated.
Thanks,
Andrei
>
>
>> _______________________________________________
>> Containers mailing list
>> Containers@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [net-next,v2,7/9] net: use core MTU range checking in misc drivers
From: Sven Eckelmann @ 2016-10-22 7:17 UTC (permalink / raw)
To: Jarod Wilson
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Stefan Richter, Faisal Latif, Cliff Whickman, Robin Holt,
Jes Sorensen, Marek Lindner, Simon Wunderlich, Antonio Quartulli,
Sathya Prakash, Chaitra P B, Suganath Prabu Subramani,
MPT-FusionLinux.pdl-dY08KVG/lbpWk0Htik3J/w, Sebastian Reichel,
Felipe Balbi, Arvid Brodin, Remi Denis-Courmont
In-Reply-To: <20161020175524.6184-8-jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]
On Donnerstag, 20. Oktober 2016 13:55:22 CEST Jarod Wilson wrote:
[...]
> batman-adv:
> - set max_mtu
> - remove batadv_interface_change_mtu
> - initialization is a little async, not 100% certain that max_mtu is set
> in the optimal place, don't have hardware to test with
batman-adv is creating a virtual interface - so there are no
hardware requirements (ok, ethernet compatible hardware - even
when only virtual/emulated).
[...]
> diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
> index 49e16b6..112679d 100644
> --- a/net/batman-adv/soft-interface.c
> +++ b/net/batman-adv/soft-interface.c
> @@ -158,17 +158,6 @@ static int batadv_interface_set_mac_addr(struct net_device *dev, void *p)
> return 0;
> }
>
> -static int batadv_interface_change_mtu(struct net_device *dev, int new_mtu)
> -{
> - /* check ranges */
> - if ((new_mtu < 68) || (new_mtu > batadv_hardif_min_mtu(dev)))
> - return -EINVAL;
> -
> - dev->mtu = new_mtu;
> -
> - return 0;
> -}
> -
> /**
> * batadv_interface_set_rx_mode - set the rx mode of a device
> * @dev: registered network device to modify
> @@ -920,7 +909,6 @@ static const struct net_device_ops batadv_netdev_ops = {
> .ndo_vlan_rx_add_vid = batadv_interface_add_vid,
> .ndo_vlan_rx_kill_vid = batadv_interface_kill_vid,
> .ndo_set_mac_address = batadv_interface_set_mac_addr,
> - .ndo_change_mtu = batadv_interface_change_mtu,
> .ndo_set_rx_mode = batadv_interface_set_rx_mode,
> .ndo_start_xmit = batadv_interface_tx,
> .ndo_validate_addr = eth_validate_addr,
> @@ -987,6 +975,7 @@ struct net_device *batadv_softif_create(struct net *net, const char *name)
> dev_net_set(soft_iface, net);
>
> soft_iface->rtnl_link_ops = &batadv_link_ops;
> + soft_iface->max_mtu = batadv_hardif_min_mtu(soft_iface);
>
> ret = register_netdevice(soft_iface);
> if (ret < 0) {
This looks bogus to me. You are now setting max_mtu during initialization of
the virtual interface. But at this time no slave interfaces were added to the
master batman-adv interface. So the batadv_hardif_min_mtu will not return the
correct value here. Especially if you don't have fragmentation enabled.
So this change looks like a bug to me
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] flow_dissector: avoid uninitialized variable access
From: Jiri Pirko @ 2016-10-22 6:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Arnd Bergmann, David S. Miller, Alexander Duyck, Tom Herbert,
Jiri Pirko, Hadar Hen Zion, Gao Feng, Eric Garver, Amir Vadai,
Network Development, Linux Kernel Mailing List
In-Reply-To: <CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com>
Sat, Oct 22, 2016 at 03:48:48AM CEST, torvalds@linux-foundation.org wrote:
>On Fri, Oct 21, 2016 at 9:31 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> I don't see how vlan could be used uninitialized. But I understand that
>> this is impossible for gcc to track it. Please just use uninitialized_var()
>
>Actually, I think we should never use "uninitialized_var()" except
>possibly for arrays or structures that gcc can complain about.
>
>It's a horrible thing to use, in that it adds extra cruft to the
>source code, and then shuts up a compiler warning (even the _reliable_
>warnings from gcc).
>
>It's much better to just initialize the variable, and if gcc some day
>gets smarter and sees that it is unnecessary and always overwritten,
>so much the better. The cost of initializing a single word is
>basically zero.
On the other hand, I would agrue that initializing a var to "some" value
that is never used might confuse the reader. He would naturally try to
understand the reason for that exact value in initialization.
^ permalink raw reply
* [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Shrijeet Mukherjee @ 2016-10-22 4:07 UTC (permalink / raw)
To: mst, tom; +Cc: netdev, shm, roopa, nikolay
This patch adds support for xdp ndo and also inserts the xdp program
call into the merged RX buffers and big buffers paths
* The small packet skb receive is skipped for now
* No TX for now
Signed-off-by: Shrijeet Mukherjee <shrijeet@gmail.com>
---
drivers/net/virtio_net.c | 133 ++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 127 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index fad84f3..d5af3f7 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <linux/virtio.h>
#include <linux/virtio_net.h>
+#include <linux/bpf.h>
#include <linux/scatterlist.h>
#include <linux/if_vlan.h>
#include <linux/slab.h>
@@ -81,6 +82,8 @@ struct receive_queue {
struct napi_struct napi;
+ struct bpf_prog *xdp_prog;
+
/* Chain pages by the private ptr. */
struct page *pages;
@@ -324,6 +327,51 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
return skb;
}
+/* this function is not called from the receive_buf path directly as
+ * we want to use the page model for rx merge buffer and big buffers
+ * and not use the fast path for driving skb's around
+ */
+static inline u32 do_xdp_prog(struct virtnet_info *vi,
+ struct receive_queue *rq,
+ void *buf, int offset, int len)
+{
+ struct bpf_prog *xdp_prog;
+ struct xdp_buff xdp;
+ int hdr_padded_len;
+ u32 act;
+
+ /* A bpf program gets first chance to drop the packet. It may
+ * read bytes but not past the end of the frag.
+ */
+
+ xdp_prog = rcu_dereference(rq->xdp_prog);
+ if (xdp_prog) {
+ if (vi->mergeable_rx_bufs)
+ hdr_padded_len = sizeof(
+ struct virtio_net_hdr_mrg_rxbuf);
+ else
+ hdr_padded_len = sizeof(struct padded_vnet_hdr);
+
+ buf = (void *)((unsigned long)buf + offset + hdr_padded_len);
+
+ xdp.data = buf;
+ xdp.data_end = xdp.data + len;
+
+ act = bpf_prog_run_xdp(xdp_prog, &xdp);
+ switch (act) {
+ case XDP_PASS:
+ return XDP_PASS;
+ case XDP_TX:
+ case XDP_ABORTED:
+ case XDP_DROP:
+ return XDP_DROP;
+ default:
+ bpf_warn_invalid_xdp_action(act);
+ }
+ }
+ return XDP_PASS;
+}
+
static struct sk_buff *receive_small(struct virtnet_info *vi, void *buf, unsigned int len)
{
struct sk_buff * skb = buf;
@@ -341,8 +389,14 @@ static struct sk_buff *receive_big(struct net_device *dev,
unsigned int len)
{
struct page *page = buf;
- struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
+ struct sk_buff *skb;
+ u32 act;
+ act = do_xdp_prog(vi, rq, buf, 0, len);
+ if (act == XDP_DROP)
+ goto err;
+
+ skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
if (unlikely(!skb))
goto err;
@@ -366,13 +420,22 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
struct page *page = virt_to_head_page(buf);
int offset = buf - page_address(page);
unsigned int truesize = max(len, mergeable_ctx_to_buf_truesize(ctx));
+ u32 act;
+ struct sk_buff *head_skb, *curr_skb;
- struct sk_buff *head_skb = page_to_skb(vi, rq, page, offset, len,
- truesize);
- struct sk_buff *curr_skb = head_skb;
+ act = do_xdp_prog(vi, rq, buf, offset, len);
+ /* controversial, but alternative is to create an SKB anyway then */
+ if (act == XDP_DROP) {
+ put_page(page);
+ return NULL;
+ }
+
+ head_skb = page_to_skb(vi, rq, page, offset, len, truesize);
+ curr_skb = head_skb;
if (unlikely(!curr_skb))
goto err_skb;
+
while (--num_buf) {
int num_skb_frags;
@@ -388,6 +451,13 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
buf = mergeable_ctx_to_buf_address(ctx);
page = virt_to_head_page(buf);
+ offset = buf - page_address(page);
+
+ act = do_xdp_prog(vi, rq, buf, offset, len);
+ if (act != XDP_PASS) {
+ put_page(page);
+ continue;
+ }
num_skb_frags = skb_shinfo(curr_skb)->nr_frags;
if (unlikely(num_skb_frags == MAX_SKB_FRAGS)) {
@@ -409,7 +479,6 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
head_skb->len += len;
head_skb->truesize += truesize;
}
- offset = buf - page_address(page);
if (skb_can_coalesce(curr_skb, num_skb_frags, page, offset)) {
put_page(page);
skb_coalesce_rx_frag(curr_skb, num_skb_frags - 1,
@@ -1430,6 +1499,52 @@ static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
+static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct bpf_prog *old_prog;
+ int i;
+
+ if (prog) {
+ prog = bpf_prog_add(prog, vi->max_queue_pairs - 1);
+ if (IS_ERR(prog))
+ return PTR_ERR(prog);
+ }
+
+ for (i = 0; i < vi->max_queue_pairs; i++) {
+ old_prog = rcu_dereference(vi->rq[i].xdp_prog);
+ rcu_assign_pointer(vi->rq[i].xdp_prog, prog);
+ if (old_prog)
+ bpf_prog_put(old_prog);
+ }
+
+ return 0;
+}
+
+static int virtnet_xdp_query(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ int i;
+
+ for (i = 0; i < vi->max_queue_pairs; i++) {
+ if (vi->rq[i].xdp_prog)
+ return 1;
+ }
+ return 0;
+}
+
+static int virtnet_xdp(struct net_device *dev, struct netdev_xdp *xdp)
+{
+ switch (xdp->command) {
+ case XDP_SETUP_PROG:
+ return virtnet_xdp_set(dev, xdp->prog);
+ case XDP_QUERY_PROG:
+ return virtnet_xdp_query(dev);
+ default:
+ return -EINVAL;
+ }
+}
+
static const struct net_device_ops virtnet_netdev = {
.ndo_open = virtnet_open,
.ndo_stop = virtnet_close,
@@ -1447,6 +1562,7 @@ static const struct net_device_ops virtnet_netdev = {
#ifdef CONFIG_NET_RX_BUSY_POLL
.ndo_busy_poll = virtnet_busy_poll,
#endif
+ .ndo_xdp = virtnet_xdp,
};
static void virtnet_config_changed_work(struct work_struct *work)
@@ -1503,11 +1619,17 @@ static void virtnet_free_queues(struct virtnet_info *vi)
static void free_receive_bufs(struct virtnet_info *vi)
{
+ struct bpf_prog *old_prog;
int i;
for (i = 0; i < vi->max_queue_pairs; i++) {
while (vi->rq[i].pages)
__free_pages(get_a_page(&vi->rq[i], GFP_KERNEL), 0);
+
+ old_prog = rcu_dereference(vi->rq[i].xdp_prog);
+ RCU_INIT_POINTER(vi->rq[i].xdp_prog, NULL);
+ if (old_prog)
+ bpf_prog_put(old_prog);
}
}
@@ -1878,7 +2000,6 @@ static int virtnet_probe(struct virtio_device *vdev)
if (virtnet_change_mtu(dev, mtu))
__virtio_clear_bit(vdev, VIRTIO_NET_F_MTU);
}
-
if (vi->any_header_sg)
dev->needed_headroom = vi->hdr_len;
--
2.1.4
^ permalink raw reply related
* Re: [Patch net] net: saving irq context for peernet2id()
From: Cong Wang @ 2016-10-22 3:53 UTC (permalink / raw)
To: David Miller
Cc: Paul Moore, Richard Guy Briggs, Stephen Smalley,
Linux Kernel Network Developers, Elad Raz
In-Reply-To: <20161021.163342.2187677530255875866.davem@davemloft.net>
On Fri, Oct 21, 2016 at 1:33 PM, David Miller <davem@davemloft.net> wrote:
> From: Paul Moore <paul@paul-moore.com>
> Date: Fri, 21 Oct 2016 16:15:00 -0400
>
>> However, that's not the case is it? Unless I missed something, the
>> fix that Cong Wang is advocating (rework the audit multicast code), is
>> a change that I have said I'm not going to accept during the -rc
>> phase. It has been a few days now and no alternate fix has been
>> proposed, I'll give it a few more hours ...
>
> It really is the right way to fix this though.
>
> Nothing should be emitting netlink messages, potentially en-masse
> to a multicast group or broadcast, in hardware interrupt context.
+1
>
> I know it's been said that only systemd receives these things, so
> that point doesn't need to be remade again.
>
> We have many weeks until -final is released so I really don't
> understand the reluctance at a slightly more involved fix in -rc2. In
> fact this is the most optimal time to try it this way, as we'll have
> the maximum amount of time for it to have exposure for testing before
> -final.
Exactly, this is how release candidates work and this is why Linus usually
puts 6 or 7 rc's before a final release, so that we have 6/7 weeks to fix bugs
(and bugs of bug fixes of course) from the merge window.
It is very common we have hidden bugs before a merge window, since they
were just sitting in a subsystem maintainer's tree, more testers come in after
merge window, a bug like this one is clearly a cross-subsystem one, and
-rc2 a perfect time to fix it. This is how we work for years.
Audit subsystem is in a different world with the rest of us. Sigh.
^ permalink raw reply
* Re: [PATCH] netns: revert "netns: avoid disabling irq for netns id"
From: Cong Wang @ 2016-10-22 3:38 UTC (permalink / raw)
To: Paul Moore; +Cc: Linux Kernel Network Developers, Elad Raz, Stephen Smalley
In-Reply-To: <147710095406.17836.12069093425270216381.stgit@localhost>
On Fri, Oct 21, 2016 at 6:49 PM, Paul Moore <pmoore@redhat.com> wrote:
> Eventually we should be able to reintroduce this code once we have
> rewritten the audit multicast code to queue messages much the same
> way we do for unicast messages. A tracking issue for this can be
> found below:
NAK.
1) This will be forgotten by Paul.
2) There is already a fix which is considered as a rework by Paul.
3) -rc2 is Paul's personal deadline, not ours.
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Cong Wang @ 2016-10-22 3:34 UTC (permalink / raw)
To: Paul Moore
Cc: David Miller, Richard Guy Briggs, Stephen Smalley,
Linux Kernel Network Developers, Elad Raz
In-Reply-To: <CAHC9VhTzYQ3ZTnecZNQe7v5VTqSWsJeRCL+Qhwfk-nEuRQ-D5Q@mail.gmail.com>
On Fri, Oct 21, 2016 at 6:55 PM, Paul Moore <paul@paul-moore.com> wrote:
> It's the end of my day, and commitments over the weekend will limit
> how much additional testing/work I can do so I went ahead and just
> posted a simple revert to netdev, it should be in your inbox already.
> Please fix this, either through a revert, or preferably some other fix
> we haven't thought of yet, in time for -rc2.
Creative artificial deadline! Next time pick -rc1 please so that no single
fix can go in after merge window!!
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Cong Wang @ 2016-10-22 3:26 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, Linux Kernel Network Developers, Elad Raz,
Richard Guy Briggs
In-Reply-To: <CAHC9VhRQ9YAr9eHYg2HWusuCZd714tK6SSr3Et8beb77w37TUA@mail.gmail.com>
On Fri, Oct 21, 2016 at 1:03 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Fri, Oct 21, 2016 at 2:02 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Fri, Oct 21, 2016 at 9:19 AM, Paul Moore <paul@paul-moore.com> wrote:
>>> On Thu, Oct 20, 2016 at 7:35 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>>> This is what I did in the follow up patch. I attach the updated version
>>>> in this email for you to review ...
>>>
>>> I think there is still some confusion. The second patch you posted
>>> still has two queues with potentially duplicated (minus the length
>>> tweaks) skbs.
>>
>> The current code without my patch is already this, the only difference
>> is there is no queue for multicast case, duplication is already there.
>
> The difference is the period of time where the skbs are duplicated.
> You patch duplicates the skb and then queues them, I'm suggesting
> putting a single skb in the queue and then only duplicating it once it
> has been pulled off the queue.
I never disagree, the only thing you never explain is why we must do
it in this patch rather than a patch later?
>
>> So, why do you expect me to fix two problems in one patch? This
>> is totally unfair, it is probably based on your eager to revert...
>
> All I've been asking for this week is a fix before -rc2 is released; I
Why -rc2? Not -rc3 ... -rc7? Why should we, as a community, care
about a release candidate and specifically -rc2? If that is your own
schedule, why not cooperating with Linus' schedule to make other
people like me easy?
> think I've been pretty clear and consistent about that. At the start
> of the week I didn't care if it was a revert or some other fix, so
> long as the fix was relatively small and easily verified/tested. I
> did say that if we got to the end of the week and we didn't have a
> solution in place I would advocate for a revert. It's Friday
> afternoon as I type this.
Blame the one who makes things unnecessarily complicated, please.
I am all for it.
>
> I've also been pretty clear from the very beginning that I don't
> consider a rework of the audit multicast code to be a candidate for
> 4.9-rcX, that is -next material as far as I'm concerned. I'll readily
Calling a change of 30 lines a rework?? OMG... We definitely have
different definitions for rework. Many stable backports are more than
this size... (I know the number of lines can't tell everything, but it tells
something.)
> admit that perhaps I'm more conservative than most maintainers, but I
> take that approach to try to keep from breaking other subsystems (and
> avoid situations like these, because this thread is so much fun after
> all).
I totally understand your conservative, but in the meantime, please be
rational. If -rc7 is the final RC, then we have 5 weeks away.
>>> What I am talking about is queuing the skb in audit_log_end(), without
>>> any modification, waking up the kauditd_thread, and then letting the
>>> kauditd_thread() function do both the netlink multicast and unicast
>>> sends, complete with the skb_copy() and length tweaks. This way we
>>> only queue one copy of the skb. To help make this more clear, I'll
>>> work up a patch and CC you.
>>
>> Sure, I hate the skb_copy() too since it could be in a IRQ handler,
>> I didn't remove it because that would make the patch more complicated
>> than the current one. We can always improve this later for the next merge
>> window, can't we? Why are you pushing something irrelevant to my
>> patch to make it unnecessarily complicated?
>
> I don't even know where to begin ... please just re-read what I've
> said above as well as previously this week. I just want a simple fix
> for 4.9-rc. I'm not going to sign-off/ack a rework of the audit
> multicast code for 4.9-rc.
Calling a 30-line patch a rework is just unfair.
>
>>> However, let me say this one more time: this is *NOT* a change I want
>>> to make during the -rcX cycle, this is a change that we should do for
>>> -next and submit during the next merge window after is has been tested
>>> and soaked in linux-next. Given where we are at right now - it's
>>> Friday and I expect -rc2 on Sunday - I think the best course of action
>>> is to revert the original patch and move on. I'm going to do that now
>>> and I'll submit it to netdev as soon as I've done some basic sanity
>>> checks.
>>
>> The problem with this is: I would have to revert this revert for the next
>> merge window, in the end you would have the following in git log:
>>
>> 1) original one
>> 2) revert
>> 3) audit fix
>> 4) revert the above revert
>>
>> comparing with:
>>
>> 1) original one
>> 2) audit fix
>>
>> You just want to make things unnecessarily complicated.
>
> No. What I want, (one more time) is a fix in -rc2.
You have a fix, you refuse, you consider it as a rework. It's your problem.
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Paul Moore @ 2016-10-22 1:55 UTC (permalink / raw)
To: David Miller; +Cc: rgb, xiyou.wangcong, Stephen Smalley, netdev, e
In-Reply-To: <CAHC9VhTm7Qc0FwEE35c5uyfWz-5DH1mKQtHGYrNVhPHm9ze34Q@mail.gmail.com>
On Fri, Oct 21, 2016 at 4:53 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Fri, Oct 21, 2016 at 4:33 PM, David Miller <davem@davemloft.net> wrote:
>> From: Paul Moore <paul@paul-moore.com>
>> Date: Fri, 21 Oct 2016 16:15:00 -0400
>>
>>> However, that's not the case is it? Unless I missed something, the
>>> fix that Cong Wang is advocating (rework the audit multicast code), is
>>> a change that I have said I'm not going to accept during the -rc
>>> phase. It has been a few days now and no alternate fix has been
>>> proposed, I'll give it a few more hours ...
>>
>> It really is the right way to fix this though.
>>
>> Nothing should be emitting netlink messages, potentially en-masse
>> to a multicast group or broadcast, in hardware interrupt context.
>>
>> I know it's been said that only systemd receives these things, so
>> that point doesn't need to be remade again.
>
> I think it is also worth noting that this code has been doing it this
> way for some time now. I say this not to advocate that it is correct,
> only that there hasn't been a demonstrated problem until Cong Wang's
> patch.
>
>> We have many weeks until -final is released so I really don't
>> understand the reluctance at a slightly more involved fix in -rc2. In
>> fact this is the most optimal time to try it this way, as we'll have
>> the maximum amount of time for it to have exposure for testing before
>> -final.
>
> Well, I understand what you are trying to say, but the maximum amount
> of time for exposure/testing would be to put it in -next. The audit
> netlink code needs a rework, but introducing such a change in the -rc
> kernels is not something I'm going to do, especially when the change
> which triggered the regression is an optimization that can be easily
> reverted ... or fixed, but the only two options I've heard mentioned
> are the audit multicast rework and the revert; if someone has a third
> option I'm listening ...
It's the end of my day, and commitments over the weekend will limit
how much additional testing/work I can do so I went ahead and just
posted a simple revert to netdev, it should be in your inbox already.
Please fix this, either through a revert, or preferably some other fix
we haven't thought of yet, in time for -rc2.
Thanks.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH] netns: revert "netns: avoid disabling irq for netns id"
From: Paul Moore @ 2016-10-22 1:49 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Elad Raz, Stephen Smalley
From: Paul Moore <paul@paul-moore.com>
This reverts commit bc51dddf98c9 ("netns: avoid disabling irq for
netns id") as it was found to cause problems with systems running
SELinux/audit, see the mailing list thread below:
* http://marc.info/?t=147694653900002&r=1&w=2
Eventually we should be able to reintroduce this code once we have
rewritten the audit multicast code to queue messages much the same
way we do for unicast messages. A tracking issue for this can be
found below:
* https://github.com/linux-audit/audit-kernel/issues/23
Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
Reported-by: Elad Raz <e@eladraz.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
net/core/net_namespace.c | 35 ++++++++++++++++++++---------------
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 989434f..f61c0e0 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -215,13 +215,14 @@ static void rtnl_net_notifyid(struct net *net, int cmd, int id);
*/
int peernet2id_alloc(struct net *net, struct net *peer)
{
+ unsigned long flags;
bool alloc;
int id;
- spin_lock_bh(&net->nsid_lock);
+ spin_lock_irqsave(&net->nsid_lock, flags);
alloc = atomic_read(&peer->count) == 0 ? false : true;
id = __peernet2id_alloc(net, peer, &alloc);
- spin_unlock_bh(&net->nsid_lock);
+ spin_unlock_irqrestore(&net->nsid_lock, flags);
if (alloc && id >= 0)
rtnl_net_notifyid(net, RTM_NEWNSID, id);
return id;
@@ -230,11 +231,12 @@ int peernet2id_alloc(struct net *net, struct net *peer)
/* This function returns, if assigned, the id of a peer netns. */
int peernet2id(struct net *net, struct net *peer)
{
+ unsigned long flags;
int id;
- spin_lock_bh(&net->nsid_lock);
+ spin_lock_irqsave(&net->nsid_lock, flags);
id = __peernet2id(net, peer);
- spin_unlock_bh(&net->nsid_lock);
+ spin_unlock_irqrestore(&net->nsid_lock, flags);
return id;
}
EXPORT_SYMBOL(peernet2id);
@@ -249,17 +251,18 @@ bool peernet_has_id(struct net *net, struct net *peer)
struct net *get_net_ns_by_id(struct net *net, int id)
{
+ unsigned long flags;
struct net *peer;
if (id < 0)
return NULL;
rcu_read_lock();
- spin_lock_bh(&net->nsid_lock);
+ spin_lock_irqsave(&net->nsid_lock, flags);
peer = idr_find(&net->netns_ids, id);
if (peer)
get_net(peer);
- spin_unlock_bh(&net->nsid_lock);
+ spin_unlock_irqrestore(&net->nsid_lock, flags);
rcu_read_unlock();
return peer;
@@ -422,17 +425,17 @@ static void cleanup_net(struct work_struct *work)
for_each_net(tmp) {
int id;
- spin_lock_bh(&tmp->nsid_lock);
+ spin_lock_irq(&tmp->nsid_lock);
id = __peernet2id(tmp, net);
if (id >= 0)
idr_remove(&tmp->netns_ids, id);
- spin_unlock_bh(&tmp->nsid_lock);
+ spin_unlock_irq(&tmp->nsid_lock);
if (id >= 0)
rtnl_net_notifyid(tmp, RTM_DELNSID, id);
}
- spin_lock_bh(&net->nsid_lock);
+ spin_lock_irq(&net->nsid_lock);
idr_destroy(&net->netns_ids);
- spin_unlock_bh(&net->nsid_lock);
+ spin_unlock_irq(&net->nsid_lock);
}
rtnl_unlock();
@@ -561,6 +564,7 @@ static int rtnl_net_newid(struct sk_buff *skb, struct nlmsghdr *nlh)
{
struct net *net = sock_net(skb->sk);
struct nlattr *tb[NETNSA_MAX + 1];
+ unsigned long flags;
struct net *peer;
int nsid, err;
@@ -581,15 +585,15 @@ static int rtnl_net_newid(struct sk_buff *skb, struct nlmsghdr *nlh)
if (IS_ERR(peer))
return PTR_ERR(peer);
- spin_lock_bh(&net->nsid_lock);
+ spin_lock_irqsave(&net->nsid_lock, flags);
if (__peernet2id(net, peer) >= 0) {
- spin_unlock_bh(&net->nsid_lock);
+ spin_unlock_irqrestore(&net->nsid_lock, flags);
err = -EEXIST;
goto out;
}
err = alloc_netid(net, peer, nsid);
- spin_unlock_bh(&net->nsid_lock);
+ spin_unlock_irqrestore(&net->nsid_lock, flags);
if (err >= 0) {
rtnl_net_notifyid(net, RTM_NEWNSID, err);
err = 0;
@@ -711,10 +715,11 @@ static int rtnl_net_dumpid(struct sk_buff *skb, struct netlink_callback *cb)
.idx = 0,
.s_idx = cb->args[0],
};
+ unsigned long flags;
- spin_lock_bh(&net->nsid_lock);
+ spin_lock_irqsave(&net->nsid_lock, flags);
idr_for_each(&net->netns_ids, rtnl_net_dumpid_one, &net_cb);
- spin_unlock_bh(&net->nsid_lock);
+ spin_unlock_irqrestore(&net->nsid_lock, flags);
cb->args[0] = net_cb.idx;
return skb->len;
^ permalink raw reply related
* Re: [PATCH] flow_dissector: avoid uninitialized variable access
From: Linus Torvalds @ 2016-10-22 1:48 UTC (permalink / raw)
To: Jiri Pirko
Cc: Arnd Bergmann, David S. Miller, Alexander Duyck, Tom Herbert,
Jiri Pirko, Hadar Hen Zion, Gao Feng, Eric Garver, Amir Vadai,
Network Development, Linux Kernel Mailing List
In-Reply-To: <20161021163118.GA2155@nanopsycho.orion>
On Fri, Oct 21, 2016 at 9:31 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>
> I don't see how vlan could be used uninitialized. But I understand that
> this is impossible for gcc to track it. Please just use uninitialized_var()
Actually, I think we should never use "uninitialized_var()" except
possibly for arrays or structures that gcc can complain about.
It's a horrible thing to use, in that it adds extra cruft to the
source code, and then shuts up a compiler warning (even the _reliable_
warnings from gcc).
It's much better to just initialize the variable, and if gcc some day
gets smarter and sees that it is unnecessary and always overwritten,
so much the better. The cost of initializing a single word is
basically zero.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] net: phy: broadcom: Update Auxiliary Control Register macros
From: Joel Stanley @ 2016-10-22 0:41 UTC (permalink / raw)
To: Xo Wang
Cc: Florian Fainelli, davem, jaedon.shin, netdev, linux-kernel,
OpenBMC Maillist
In-Reply-To: <1477070413-92621-2-git-send-email-xow@google.com>
On Sat, Oct 22, 2016 at 3:50 AM, Xo Wang <xow@google.com> wrote:
> Add the RXD-to-RXC skew (delay) time bit in the Miscellaneous Control
> shadow register and a mask for the shadow selector field.
>
> Remove a re-definition of MII_BCM54XX_AUXCTL_SHDWSEL_AUXCTL.
>
> Signed-off-by: Xo Wang <xow@google.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Cheers,
Joel
> ---
> include/linux/brcmphy.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: broadcom: Add support for BCM54612E
From: Joel Stanley @ 2016-10-22 0:40 UTC (permalink / raw)
To: Xo Wang
Cc: Florian Fainelli, davem, jaedon.shin, netdev, linux-kernel,
OpenBMC Maillist
In-Reply-To: <1477070413-92621-3-git-send-email-xow@google.com>
On Sat, Oct 22, 2016 at 3:50 AM, Xo Wang <xow@google.com> wrote:
> This PHY has internal delays enabled after reset. This clears the
> internal delay enables unless the interface specifically requests them.
>
> Signed-off-by: Xo Wang <xow@google.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Cheers,
Joel
> ---
> drivers/net/phy/broadcom.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/brcmphy.h | 1 +
> 2 files changed, 49 insertions(+)
^ permalink raw reply
* Re: [PATCH] flow_dissector: avoid uninitialized variable access
From: Arnd Bergmann @ 2016-10-21 22:16 UTC (permalink / raw)
To: Jiri Pirko
Cc: David S. Miller, Alexander Duyck, Tom Herbert, Jiri Pirko,
Hadar Hen Zion, Gao Feng, Eric Garver, Amir Vadai, netdev,
linux-kernel
In-Reply-To: <5467015.N4DG5uA0DU@wuerfel>
On Friday, October 21, 2016 11:05:45 PM CEST Arnd Bergmann wrote:
>
> Can you explain why "dissector_uses_key(flow_dissector,
> FLOW_DISSECTOR_KEY_VLAN) && skb_vlan_tag_present(skb)" implies
> "eth_type_vlan(proto))"?
>
> If I add uninitialized_var() here, I would at least put that in
> a comment here.
Found it now myself: if skb_vlan_tag_present(skb), then we don't
access 'vlan', otherwise we know it is initialized because
eth_type_vlan(proto) has to be true.
> On a related note, I also don't see how
> "dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_VLAN)"
> implies that skb is non-NULL. I guess this is related to the
> first one.
I'm still unsure about this one.
I also found something else that is suspicious: 'vlan' points
to the local _vlan variable, but that has gone out of scope
by the time we access the pointer, which doesn't seem safe.
Arnd
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: broadcom: Add support for BCM54612E
From: Florian Fainelli @ 2016-10-21 21:31 UTC (permalink / raw)
To: Xo Wang; +Cc: davem, jaedon.shin, netdev, linux-kernel, openbmc, joel
In-Reply-To: <1477070413-92621-3-git-send-email-xow@google.com>
On 10/21/2016 10:20 AM, Xo Wang wrote:
> This PHY has internal delays enabled after reset. This clears the
> internal delay enables unless the interface specifically requests them.
>
> Signed-off-by: Xo Wang <xow@google.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Cross checked with the datasheet, this all looks correct to me, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH 1/2] net: phy: broadcom: Update Auxiliary Control Register macros
From: Florian Fainelli @ 2016-10-21 21:27 UTC (permalink / raw)
To: Xo Wang; +Cc: davem, jaedon.shin, netdev, linux-kernel, openbmc, joel
In-Reply-To: <1477070413-92621-2-git-send-email-xow@google.com>
On 10/21/2016 10:20 AM, Xo Wang wrote:
> Add the RXD-to-RXC skew (delay) time bit in the Miscellaneous Control
> shadow register and a mask for the shadow selector field.
>
> Remove a re-definition of MII_BCM54XX_AUXCTL_SHDWSEL_AUXCTL.
>
> Signed-off-by: Xo Wang <xow@google.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net 2/2] net: dsa: bcm_sf2: Do not rely on kexec_in_progress
From: Florian Fainelli @ 2016-10-21 21:21 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-kernel, ebiederm, kexec, Florian Fainelli
In-Reply-To: <1477084916-26327-1-git-send-email-f.fainelli@gmail.com>
After discussing with Eric, it turns out that, while using
kexec_in_progress is a nice optimization, which prevents us from always
powering on the integrated PHY, let's just turn it on in the shutdown
path.
This removes a dependency on kexec_in_progress which, according to Eric
should not be used by modules
Fixes: 2399d6143f85 ("net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 077a24541584..e3ee27ce13dd 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -30,7 +30,6 @@
#include <linux/etherdevice.h>
#include <net/switchdev.h>
#include <linux/platform_data/b53.h>
-#include <linux/kexec.h>
#include "bcm_sf2.h"
#include "bcm_sf2_regs.h"
@@ -1141,9 +1140,11 @@ static void bcm_sf2_sw_shutdown(struct platform_device *pdev)
/* For a kernel about to be kexec'd we want to keep the GPHY on for a
* successful MDIO bus scan to occur. If we did turn off the GPHY
* before (e.g: port_disable), this will also power it back on.
+ *
+ * Do not rely on kexec_in_progress, just power the PHY on.
*/
if (priv->hw_params.num_gphy == 1)
- bcm_sf2_gphy_enable_set(priv->dev->ds, kexec_in_progress);
+ bcm_sf2_gphy_enable_set(priv->dev->ds, true);
}
#ifdef CONFIG_PM_SLEEP
--
2.7.4
^ permalink raw reply related
* [PATCH net 1/2] Revert "kexec: Export kexec_in_progress to modules"
From: Florian Fainelli @ 2016-10-21 21:21 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-kernel, ebiederm, kexec, Florian Fainelli
In-Reply-To: <1477084916-26327-1-git-send-email-f.fainelli@gmail.com>
This reverts commit 97dcaa0fcfd24daa9a36c212c1ad1d5a97759212. Based on
the review discussion with Eric, we will come up with a different fix
for the bcm_sf2 driver which does not make it rely on the
kexec_in_progress value.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
kernel/kexec_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 786ab85a5452..561675589511 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -59,7 +59,6 @@ size_t vmcoreinfo_max_size = sizeof(vmcoreinfo_data);
/* Flag to indicate we are going to kexec a new kernel */
bool kexec_in_progress = false;
-EXPORT_SYMBOL_GPL(kexec_in_progress);
/* Location of the reserved area for the crash kernel */
--
2.7.4
^ permalink raw reply related
* [PATCH net 0/2] net: dsa: bcm_sf2: Do not rely on kexec_in_progress
From: Florian Fainelli @ 2016-10-21 21:21 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Florian Fainelli, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA
David, Eric,
These are the two patches following the discussing we had on kexec_in_progress.
Feel free to apply or discard them, thanks!
Florian Fainelli (2):
Revert "kexec: Export kexec_in_progress to modules"
net: dsa: bcm_sf2: Do not rely on kexec_in_progress
drivers/net/dsa/bcm_sf2.c | 5 +++--
kernel/kexec_core.c | 1 -
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next v6 3/3] udp: use it's own memory accounting schema
From: Eric Dumazet @ 2016-10-21 21:14 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, James Morris,
Trond Myklebust, Alexander Duyck, Daniel Borkmann, Eric Dumazet,
Tom Herbert, Hannes Frederic Sowa, Edward Cree,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <530de0874eb7bbe1dbdaa4e8ccbb56d917ee598f.1477043395.git.pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Fri, 2016-10-21 at 13:55 +0200, Paolo Abeni wrote:
> Completely avoid default sock memory accounting and replace it
> with udp-specific accounting.
>
> Since the new memory accounting model encapsulates completely
> the required locking, remove the socket lock on both enqueue and
> dequeue, and avoid using the backlog on enqueue.
>
> Be sure to clean-up rx queue memory on socket destruction, using
> udp its own sk_destruct.
>
> Tested using pktgen with random src port, 64 bytes packet,
> wire-speed on a 10G link as sender and udp_sink as the receiver,
> using an l4 tuple rxhash to stress the contention, and one or more
> udp_sink instances with reuseport.
>
> nr readers Kpps (vanilla) Kpps (patched)
> 1 170 440
Acked-by: Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Thanks a lot guys.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v6 2/3] udp: implement memory accounting helpers
From: Eric Dumazet @ 2016-10-21 21:13 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, David S. Miller, James Morris, Trond Myklebust,
Alexander Duyck, Daniel Borkmann, Eric Dumazet, Tom Herbert,
Hannes Frederic Sowa, Edward Cree, linux-nfs
In-Reply-To: <4d2e0fc8f5c3d1309b0fb71bc65a2719a8e82825.1477043395.git.pabeni@redhat.com>
On Fri, 2016-10-21 at 13:55 +0200, Paolo Abeni wrote:
> Avoid using the generic helpers.
> Use the receive queue spin lock to protect the memory
> accounting operation, both on enqueue and on dequeue.
>
> On dequeue perform partial memory reclaiming, trying to
> leave a quantum of forward allocated memory.
>
> On enqueue use a custom helper, to allow some optimizations:
> - use a plain spin_lock() variant instead of the slightly
> costly spin_lock_irqsave(),
> - avoid dst_force check, since the calling code has already
> dropped the skb dst
> - avoid orphaning the skb, since skb_steal_sock() already did
> the work for us
>
> The above needs custom memory reclaiming on shutdown, provided
> by the udp_destruct_sock().
Acked-by: Eric Dumazet <edumazet@google.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