* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: David Miller @ 2016-10-13 14:43 UTC (permalink / raw)
To: dledford; +Cc: pabeni, linux-rdma, sean.hefty, hal.rosenstock, netdev
In-Reply-To: <20ace6ee-b9e4-073c-56e7-29b2c50ae2d5@redhat.com>
From: Doug Ledford <dledford@redhat.com>
Date: Thu, 13 Oct 2016 10:35:35 -0400
> On 10/13/2016 10:24 AM, David Miller wrote:
>> From: Paolo Abeni <pabeni@redhat.com>
>> Date: Tue, 11 Oct 2016 19:15:44 +0200
>>
>>> After the commit 9207f9d45b0a ("net: preserve IP control block
>>> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
>>> That destroy the IPoIB address information cached there,
>>> causing a severe performance regression, as better described here:
>>>
>>> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>>>
>>> This change moves the data cached by the IPoIB driver from the
>>> skb control lock into the IPoIB hard header, as done before
>>> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
>>> and use skb->cb to stash LL addresses").
>>> In order to avoid GRO issue, on packet reception, the IPoIB driver
>>> stash into the skb a dummy pseudo header, so that the received
>>> packets have actually a hard header matching the declared length.
>>> Also the connected mode maximum mtu is reduced by 16 bytes to
>>> cope with the increased hard header len.
>>>
>>> After this commit, IPoIB performances are back to pre-regression
>>> value.
>>>
>>> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
>>> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>>
>> Not providing an accurate hard_header_len causes many problems.
>>
>> In fact we recently fixed the mlxsw driver to stop doing this.
>>
>
> Sure, but there are too many users of the cb struct, and whatever
> problems you are saying there are by lying about the hard header len are
> dwarfed by the problems caused by the inability to store the ll address
> anywhere between hard_header and send time.
IB wants to pass addressing information between layers, it needs to
find a safe way to do that. The currently propsoed patch does not
meet this criteria.
Pushing metadata before the head of the SKB data pointer is illegal,
as the layers in between might want to push protocol headers, mirror
the packet to another interface, etc.
So this "metadata in SKB data" approach is buggy too.
^ permalink raw reply
* Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change
From: David Miller @ 2016-10-13 14:46 UTC (permalink / raw)
To: zach.brown
Cc: f.fainelli, mlindner, stephen, netdev, linux-kernel, devel,
florian.c.schilhabel, Larry.Finger, gregkh, rpurdie, j.anaszewski,
linux-leds, andrew
In-Reply-To: <1476217580-21229-4-git-send-email-zach.brown@ni.com>
From: Zach Brown <zach.brown@ni.com>
Date: Tue, 11 Oct 2016 15:26:20 -0500
> From: Josh Cartwright <josh.cartwright@ni.com>
>
> Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
> create a set of led triggers for each instantiated PHY device. There is
> one LED trigger per link-speed, per-phy.
>
> This allows for a user to configure their system to allow a set of LEDs
> to represent link state changes on the phy.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
...
> + static const char * const name_suffix[] = {
> + "10Mbps",
> + "100Mbps",
> + "1Gbps",
> + "2.5Gbps",
> + "10Gbps",
This choice of both the array size and the speeds to support seems
entirely arbitrary and is inappropriate for a generic driver of this
kind.
This seems to be hard coding this to support the list of speeds
supported by whatever driver you want to use with this new LED
facility, and sorry that's not how we build nice generic pieces of
infrastructure.
Thanks.
^ permalink raw reply
* Re: [PATCH] qed: Fix to use list_for_each_entry_safe() when delete items
From: David Miller @ 2016-10-13 14:40 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: weiyj.lk, Ariel.Elior, weiyongjun1, netdev
In-Reply-To: <BL2PR07MB2306E19AD9C9FE46992E12A78DDC0@BL2PR07MB2306.namprd07.prod.outlook.com>
From: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Date: Thu, 13 Oct 2016 14:14:40 +0000
>> > Since we will remove items off the list using list_del() we need to
>> > use a safe version of the list_for_each_entry() macro aptly named
>> > list_for_each_entry_safe().
>> >
>> > Fixes: 0a7fb11c23c0 ("qed: Add Light L2 support")
>> > Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
>>
>> Can the QED maintainers please review this simple fix?
>>
>> In my opinion 4 days is sufficient time in which to expect a reasonable review to
>> occur, let me know if you disagree. :-)
>
> Sorry about that; The high holy days are killing our productivity. :-(
> I did ACK v1, though [and v2 was purely semantic change].
Indeed, I just noticed that, thanks!
^ permalink raw reply
* Re: [PATCH net] netvsc: fix checksum on UDP IPV6
From: David Miller @ 2016-10-13 14:48 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, netdev
In-Reply-To: <20161011140307.15fd390b@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 11 Oct 2016 14:03:07 -0700
> The software calculation of UDP checksum in Netvsc driver was
> only handling IPv4 case. By using skb_checksum_help() instead
> all protocols can be handled. Rearrange code to eliminate goto
> and look like other drivers.
>
> This is a temporary solution; recent versions of Window Server etc
> do support UDP checksum offload, just need to do the appropriate negotiation
> with host to validate before using. This will be done in later patch.
>
> Please queue this for -stable as well.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied and queued up for -stable, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next v2] bridge: add address and vlan to fdb warning messages
From: David Miller @ 2016-10-13 14:50 UTC (permalink / raw)
To: roopa; +Cc: stephen, nikolay, netdev
In-Reply-To: <1476227576-14405-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Tue, 11 Oct 2016 16:12:56 -0700
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch adds vlan and address to warning messages printed
> in the bridge fdb code for debuggability.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Applied, thanks Roopa.
^ permalink raw reply
* Re: [PATCH] qed: fix old-style function definition
From: David Miller @ 2016-10-13 14:53 UTC (permalink / raw)
To: Yuval.Mintz
Cc: arnd, Yuval.Mintz, Ariel.Elior, everest-linux-l2, Ram.Amrani,
netdev, linux-kernel
In-Reply-To: <BL2PR07MB230694B607619C4DFBB90B7F8DDC0@BL2PR07MB2306.namprd07.prod.outlook.com>
From: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Date: Thu, 13 Oct 2016 14:15:51 +0000
>> > The definition of qed_get_rdma_ops() is not a prototype unless we add
>> > 'void' here, as indicated by this W=1 warning:
>> >
>> > drivers/net/ethernet/qlogic/qed/qed_roce.c: In function ‘qed_get_rdma_ops’:
>> > drivers/net/ethernet/qlogic/qed/qed_roce.c:2950:28: error: old-style
>> > function definition [-Werror=old-style-definition]
>> >
>> > Fixes: abd49676c707 ("qed: Add RoCE ll2 & GSI support")
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> Again, Qlogic folks, please properly review patches posted against your driver.
>>
>> Thanks.
>
> Sorry, managed to miss this one.
> Acked-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
Applied.
^ permalink raw reply
* Re: [Patch net] net_sched: reorder pernet ops and act ops registrations
From: David Miller @ 2016-10-13 14:27 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, kjlx, jhs
In-Reply-To: <1476208605-16199-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 11 Oct 2016 10:56:45 -0700
> Krister reported a kernel NULL pointer dereference after
> tcf_action_init_1() invokes a_o->init(), it is a race condition
> where one thread calling tcf_register_action() to initialize
> the netns data after putting act ops in the global list and
> the other thread searching the list and then calling
> a_o->init(net, ...).
>
> Fix this by moving the pernet ops registration before making
> the action ops visible. This is fine because: a) we don't
> rely on act_base in pernet ops->init(), b) in the worst case we
> have a fully initialized netns but ops is still not ready so
> new actions still can't be created.
>
> Reported-by: Krister Johansen <kjlx@templeofstupid.com>
> Tested-by: Krister Johansen <kjlx@templeofstupid.com>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: axienet: Remove unused parameter from __axienet_device_reset
From: Tobias Klauser @ 2016-10-13 14:40 UTC (permalink / raw)
To: Michal Simek; +Cc: Anirudha Sarangi, John Linn, Sören Brinkmann, netdev
In-Reply-To: <9b966409-bdd5-08d1-564e-d7900b4707d1@xilinx.com>
On 2016-10-13 at 14:23:49 +0200, Michal Simek <michal.simek@xilinx.com> wrote:
> On 13.10.2016 13:28, Tobias Klauser wrote:
> > The dev parameter passed to __axienet_device_reset() is not used inside
> > the function, so remove it.
> >
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> > ---
> > drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 11 +++++------
> > 1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> > index 35f9f9742a48..c688d68c39aa 100644
> > --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> > +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> > @@ -431,8 +431,7 @@ static void axienet_setoptions(struct net_device *ndev, u32 options)
> > lp->options |= options;
> > }
> >
> > -static void __axienet_device_reset(struct axienet_local *lp,
> > - struct device *dev, off_t offset)
> > +static void __axienet_device_reset(struct axienet_local *lp, off_t offset)
> > {
> > u32 timeout;
> > /* Reset Axi DMA. This would reset Axi Ethernet core as well. The reset
> > @@ -468,8 +467,8 @@ static void axienet_device_reset(struct net_device *ndev)
> > u32 axienet_status;
> > struct axienet_local *lp = netdev_priv(ndev);
> >
> > - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_TX_CR_OFFSET);
> > - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_RX_CR_OFFSET);
> > + __axienet_device_reset(lp, XAXIDMA_TX_CR_OFFSET);
> > + __axienet_device_reset(lp, XAXIDMA_RX_CR_OFFSET);
> >
> > lp->max_frm_size = XAE_MAX_VLAN_FRAME_SIZE;
> > lp->options |= XAE_OPTION_VLAN;
> > @@ -1338,8 +1337,8 @@ static void axienet_dma_err_handler(unsigned long data)
> > axienet_iow(lp, XAE_MDIO_MC_OFFSET, (mdio_mcreg &
> > ~XAE_MDIO_MC_MDIOEN_MASK));
> >
> > - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_TX_CR_OFFSET);
> > - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_RX_CR_OFFSET);
> > + __axienet_device_reset(lp, XAXIDMA_TX_CR_OFFSET);
> > + __axienet_device_reset(lp, XAXIDMA_RX_CR_OFFSET);
> >
> > axienet_iow(lp, XAE_MDIO_MC_OFFSET, mdio_mcreg);
> > axienet_mdio_wait_until_ready(lp);
> >
>
> Can you please send this directly to mainline?
> And put my:
> Reviewed-by: Michal Simek <michal.simek@xilinx.com>
The netdev mailing list was Cc'ed on the patch, so it should end up in
davem's patch queue.
Thanks
^ permalink raw reply
* Re: [PATCH net 0/3] s390 network driver patches
From: David Miller @ 2016-10-13 15:00 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens
In-Reply-To: <cover.1476263985.git.ursula.braun@de.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Wed, 12 Oct 2016 12:38:48 +0200
> here are 3 small patches for the s390 network drivers netiucv and lcs.
> They are built for the net-tree.
Series applied, thanks.
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 15:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, Andy Lutomirski,
David S. Miller, Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476366354.4904.31.camel@sipsolutions.net>
On (10/13/16 15:45), Johannes Berg wrote:
> On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
> >
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> > >
> > > That truly sounds like something we'd rather avoid in the TX/RX
> > > paths though, which should perform well.
> >
> > didn't fix.
>
> It couldn't, since the new helpers weren't used in mac80211 in those
> patches yet.
indeed. I thought they were.
> > FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> > >> 39) == 130
>
> The question, though, is why precisely that fails in the crypto code.
> Can you send the Oops report itself?
kernel: BUG: unable to handle kernel NULL pointer dereference at (null)
kernel: IP: [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: PGD 0
kernel:
kernel: Oops: 0000 [#1] PREEMPT SMP
kernel: Modules linked in: nls_iso8859_1 nls_cp437 vfat fat mousedev psmouse serio_raw atkbd libps2 i915 coretemp i2c_algo_bit hwmon crc32c_intel mxm_wmi drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect iwlmvm sysimgblt fb_sys_fops i2c_i801 cfbcopyarea ie31200_edac drm iwlwifi i2c
kernel: CPU: 3 PID: 245 Comm: irq/28-iwlwifi Not tainted 4.8.0-next-20161013-dbg-00002-ge789862-dirty #112
kernel: task: ffff88041bf01800 task.stack: ffffc900002d0000
kernel: RIP: 0010:[<ffffffff8146d2f4>] [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: RSP: 0018:ffffc900002d3770 EFLAGS: 00010246
kernel: RAX: ffffc900002d3930 RBX: ffff8804133cf606 RCX: 0000000000082000
kernel: RDX: 0000000000000000 RSI: 0000000000000018 RDI: 0000000000000a02
kernel: RBP: ffffc900002d39b8 R08: 00000000000005e4 R09: 00000004100002d3
kernel: R10: 000000000000001c R11: ffff8803e66d2d20 R12: ffff8804191c2780
kernel: R13: ffffc900002d39f0 R14: ffff8804133cf022 R15: 1ffff9200005a6ee
kernel: FS: 0000000000000000(0000) GS:ffff88041ea00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000000 CR3: 0000000001805000 CR4: 00000000001406e0
kernel: Stack:
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
kernel: Call Trace:
kernel: [<ffffffff8145c405>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
kernel: [<ffffffff81476cd8>] ieee80211_rx_handlers+0x7df/0x1c1d
kernel: [<ffffffff814790c8>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
kernel: [<ffffffff814792e7>] ? ieee80211_rx_napi+0x168/0x7b6
kernel: [<ffffffff8147960a>] ieee80211_rx_napi+0x48b/0x7b6
kernel: [<ffffffff8123729e>] ? debug_smp_processor_id+0x17/0x19
kernel: [<ffffffffa01cfe3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
kernel: [<ffffffffa01c9c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
kernel: [<ffffffffa0131bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
kernel: [<ffffffffa0133027>] iwl_pcie_irq_handler+0x46f/0x65f [iwlwifi]
kernel: [<ffffffff810893d0>] ? irq_finalize_oneshot+0xd4/0xd4
kernel: [<ffffffff810893ed>] irq_thread_fn+0x1d/0x34
kernel: [<ffffffff81089661>] irq_thread+0xe6/0x1bb
kernel: [<ffffffff810894e6>] ? wake_threads_waitq+0x2c/0x2c
kernel: [<ffffffff8108957b>] ? irq_thread_dtor+0x95/0x95
kernel: [<ffffffff8105d762>] kthread+0xfc/0x104
kernel: [<ffffffff8107d36c>] ? put_lock_stats.isra.9+0xe/0x20
kernel: [<ffffffff8105d666>] ? kthread_create_on_node+0x3f/0x3f
kernel: [<ffffffff814b2852>] ret_from_fork+0x22/0x30
kernel: Code: 01 ca 49 89 d1 48 89 d1 48 c1 ea 23 48 8b 14 d5 80 23 63 82 49 c1 e9 0c 48 c1 e9 1b 48 85 d2 74 0a 0f b6 c9 48 c1 e1 04 48 01 ca <48> 8b 12 49 c1 e1 06 b9 00 00 00 80 89 7d 80 89 75 84 48 8b 3d
kernel: RIP [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
kernel: RSP <ffffc900002d3770>
kernel: CR2: 0000000000000000
kernel: ---[ end trace 3cd1fcd496516f72 ]---
-ss
^ permalink raw reply
* Re: [PATCH (net.git) 2/2] stmmac: fix error check when init ptp
From: David Miller @ 2016-10-13 15:01 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, linux-kernel, alexandre.torgue, rayagond
In-Reply-To: <1476279724-11817-2-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Wed, 12 Oct 2016 15:42:04 +0200
> This patch fixes a problem when propagated the
> failure of ptp_clock_register to open function.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH (net.git) 1/2] stmmac: fix ptp init for gmac4
From: David Miller @ 2016-10-13 15:01 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, linux-kernel, alexandre.torgue, rayagond
In-Reply-To: <1476279724-11817-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Wed, 12 Oct 2016 15:42:03 +0200
> The gmac 4.x version has not extended descriptors
> (that are available on 3.x instead of).
> While initializing the PTP module, the advanced PTP was
> enabled in case of extended descriptors. This cannot be
> applied for 4.x version where only the hardware capability
> register has to show if the feature is present.
> Patch also adds some extra netdev_(debug/inof) to better
> dump the configuration.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xen-netback: fix type mismatch warning
From: David Miller @ 2016-10-13 15:02 UTC (permalink / raw)
To: arnd; +Cc: wei.liu2, netdev, linux-kernel, paul.durrant, david.vrabel,
xen-devel
In-Reply-To: <20161012145434.2493788-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 12 Oct 2016 16:54:01 +0200
> Wiht the latest rework of the xen-netback driver, we get a warning
> on ARM about the types passed into min():
>
> drivers/net/xen-netback/rx.c: In function 'xenvif_rx_next_chunk':
> include/linux/kernel.h:739:16: error: comparison of distinct pointer types lacks a cast [-Werror]
>
> The reason is that XEN_PAGE_SIZE is not size_t here. There
> is no actual bug, and we can easily avoid the warning using the
> min_t() macro instead of min().
>
> Fixes: eb1723a29b9a ("xen-netback: refactor guest rx")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH net-next] Documentation/networking: update git urls to use https over http
From: Alexander Alemayhu @ 2016-10-13 15:09 UTC (permalink / raw)
To: netdev, corbet; +Cc: linux-doc, linux-kernel, Alexander Alemayhu
This fixes the following errors when trying to clone the urls:
Cloning into 'net'...
fatal: repository 'http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/' not found
Cloning into 'net-next'...
fatal: repository 'http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/' not found
Cloning into 'linux'...
fatal: repository 'http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/' not found
Cloning into 'stable-queue'...
fatal: repository 'http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/' not found
Signed-off-by: Alexander Alemayhu <alexander@alemayhu.com>
---
Documentation/networking/netdev-FAQ.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt
index 0fe1c6e0dbcd..a20b2fae942b 100644
--- a/Documentation/networking/netdev-FAQ.txt
+++ b/Documentation/networking/netdev-FAQ.txt
@@ -29,8 +29,8 @@ A: There are always two trees (git repositories) in play. Both are driven
Linus, and net-next is where the new code goes for the future release.
You can find the trees here:
- http://git.kernel.org/?p=linux/kernel/git/davem/net.git
- http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git
+ https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
+ https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
Q: How often do changes from these trees make it to the mainline Linus tree?
@@ -76,7 +76,7 @@ Q: So where are we now in this cycle?
A: Load the mainline (Linus) page here:
- http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
and note the top of the "tags" section. If it is rc1, it is early
in the dev cycle. If it was tagged rc7 a week ago, then a release
@@ -123,7 +123,7 @@ A: Normally Greg Kroah-Hartman collects stable commits himself, but
It contains the patches which Dave has selected, but not yet handed
off to Greg. If Greg already has the patch, then it will be here:
- http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
A quick way to find whether the patch is in this stable-queue is
to simply clone the repo, and then git grep the mainline commit ID, e.g.
--
2.10.1
^ permalink raw reply related
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: Paolo Abeni @ 2016-10-13 15:17 UTC (permalink / raw)
To: David Miller; +Cc: linux-rdma, dledford, sean.hefty, hal.rosenstock, netdev
In-Reply-To: <20161013.102432.1450901395774429343.davem@davemloft.net>
On Thu, 2016-10-13 at 10:24 -0400, David Miller wrote:
> From: Paolo Abeni <pabeni@redhat.com>
> Date: Tue, 11 Oct 2016 19:15:44 +0200
>
> > After the commit 9207f9d45b0a ("net: preserve IP control block
> > during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
> > That destroy the IPoIB address information cached there,
> > causing a severe performance regression, as better described here:
> >
> > http://marc.info/?l=linux-kernel&m=146787279825501&w=2
> >
> > This change moves the data cached by the IPoIB driver from the
> > skb control lock into the IPoIB hard header, as done before
> > the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
> > and use skb->cb to stash LL addresses").
> > In order to avoid GRO issue, on packet reception, the IPoIB driver
> > stash into the skb a dummy pseudo header, so that the received
> > packets have actually a hard header matching the declared length.
> > Also the connected mode maximum mtu is reduced by 16 bytes to
> > cope with the increased hard header len.
> >
> > After this commit, IPoIB performances are back to pre-regression
> > value.
> >
> > Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>
> Not providing an accurate hard_header_len causes many problems.
>
> In fact we recently fixed the mlxsw driver to stop doing this.
AFAICS the mlxsw did a different thing, adding an additional header in
the xmit function and pushing packets in the network stack with a mac
length different from the declared hard header length
The hard header specified by the IPoIB driver is build in the create()
header_ops and its length matches the mac header length of the packets
pushed into the network stack by such driver. GRO works correctly on top
of that. From the networking stack PoV the hard_header_len should be
'accurate'.
Can you please give more details on the problem that may arise from
this ?
thank you,
Paolo
^ permalink raw reply
* Re: [PATCH net] Revert "net: Add driver helper functions to determine checksum offloadability"
From: Jonathan Cooper @ 2016-10-13 15:06 UTC (permalink / raw)
To: David Miller, stephen; +Cc: tom, netdev
In-Reply-To: <20161013.103548.511298911926565246.davem@davemloft.net>
On 13/10/16 15:35, David Miller wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Tue, 11 Oct 2016 13:04:09 -0700
>
>> This reverts commit 6ae23ad36253a8033c5714c52b691b84456487c5.
>>
>> The code has been in kernel since 4.4 but there are no in tree
>> code that uses. Unused code is broken code, remove it.
>>
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Tom if you have any real plans to develop on this work at all in
> the immediate future, please speak up now.
>
> Otherwise I'm applying Stephen's patch.
>
> Thanks.
We've used this in our overlay support, which we plan to upstream in the
next month or two (or at least Soon(tm)),
so we'd rather it stayed in otherwise we'll just have to reimplement it.
Jon
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: Doug Ledford @ 2016-10-13 15:20 UTC (permalink / raw)
To: David Miller
Cc: pabeni-H+wXaHxf7aLQT0dZR+AlfA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161013.104314.1842951254979604965.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2951 bytes --]
On 10/13/2016 10:43 AM, David Miller wrote:
> From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Thu, 13 Oct 2016 10:35:35 -0400
>
>> On 10/13/2016 10:24 AM, David Miller wrote:
>>> From: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> Date: Tue, 11 Oct 2016 19:15:44 +0200
>>>
>>>> After the commit 9207f9d45b0a ("net: preserve IP control block
>>>> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
>>>> That destroy the IPoIB address information cached there,
>>>> causing a severe performance regression, as better described here:
>>>>
>>>> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>>>>
>>>> This change moves the data cached by the IPoIB driver from the
>>>> skb control lock into the IPoIB hard header, as done before
>>>> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
>>>> and use skb->cb to stash LL addresses").
>>>> In order to avoid GRO issue, on packet reception, the IPoIB driver
>>>> stash into the skb a dummy pseudo header, so that the received
>>>> packets have actually a hard header matching the declared length.
>>>> Also the connected mode maximum mtu is reduced by 16 bytes to
>>>> cope with the increased hard header len.
>>>>
>>>> After this commit, IPoIB performances are back to pre-regression
>>>> value.
>>>>
>>>> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
>>>> Signed-off-by: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>
>>> Not providing an accurate hard_header_len causes many problems.
>>>
>>> In fact we recently fixed the mlxsw driver to stop doing this.
>>>
>>
>> Sure, but there are too many users of the cb struct, and whatever
>> problems you are saying there are by lying about the hard header len are
>> dwarfed by the problems caused by the inability to store the ll address
>> anywhere between hard_header and send time.
>
> IB wants to pass addressing information between layers, it needs to
> find a safe way to do that.
We *had* a safe way to do that. It got broken. What about increasing
the size of skb->cb? Or adding a skb->dgid that is a
u8[INFINIBAND_ALEN]? Or a more generic skb->dest_ll_addr that is sized
to hold the dest address for any link layer?
> Pushing metadata before the head of the SKB data pointer is illegal,
> as the layers in between might want to push protocol headers,
That's a total non-issue for us. There are no headers that protocols
can add before ours.
> mirror
> the packet to another interface
Doesn't that then mean that the headers specific to this interface
should be stripped before the mirror? If so, I believe the way Paolo
did this patch, that is what will be done.
>, etc.
>
> So this "metadata in SKB data" approach is buggy too.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 15:04 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Johannes Berg, Andy Lutomirski, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <20161013150011.GA437@swordfish>
On (10/14/16 00:00), Sergey Senozhatsky wrote:
> kernel: [<ffffffff8145c405>] ieee80211_crypto_ccmp_decrypt+0x204/0x298
> kernel: [<ffffffff81476cd8>] ieee80211_rx_handlers+0x7df/0x1c1d
> kernel: [<ffffffff814790c8>] ieee80211_prepare_and_rx_handle+0xdc2/0xe79
> kernel: [<ffffffff814792e7>] ? ieee80211_rx_napi+0x168/0x7b6
> kernel: [<ffffffff8147960a>] ieee80211_rx_napi+0x48b/0x7b6
> kernel: [<ffffffff8123729e>] ? debug_smp_processor_id+0x17/0x19
> kernel: [<ffffffffa01cfe3b>] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm]
> kernel: [<ffffffffa01c9c49>] iwl_mvm_rx+0x7e/0x98 [iwlmvm]
> kernel: [<ffffffffa0131bca>] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi]
> kernel: [<ffffffffa0133027>] iwl_pcie_irq_handler+0x46f/0x65f [iwlwifi]
> kernel: [<ffffffff810893d0>] ? irq_finalize_oneshot+0xd4/0xd4
> kernel: [<ffffffff810893ed>] irq_thread_fn+0x1d/0x34
> kernel: [<ffffffff81089661>] irq_thread+0xe6/0x1bb
> kernel: [<ffffffff810894e6>] ? wake_threads_waitq+0x2c/0x2c
> kernel: [<ffffffff8108957b>] ? irq_thread_dtor+0x95/0x95
> kernel: [<ffffffff8105d762>] kthread+0xfc/0x104
> kernel: [<ffffffff8107d36c>] ? put_lock_stats.isra.9+0xe/0x20
> kernel: [<ffffffff8105d666>] ? kthread_create_on_node+0x3f/0x3f
> kernel: [<ffffffff814b2852>] ret_from_fork+0x22/0x30
> kernel: Code: 01 ca 49 89 d1 48 89 d1 48 c1 ea 23 48 8b 14 d5 80 23 63 82 49 c1 e9 0c 48 c1 e9 1b 48 85 d2 74 0a 0f b6 c9 48 c1 e1 04 48 01 ca <48> 8b 12 49 c1 e1 06 b9 00 00 00 80 89 7d 80 89 75 84 48 8b 3d
> kernel: RIP [<ffffffff8146d2f4>] ieee80211_aes_ccm_decrypt+0x107/0x27f
ffffffff8146d1ed <ieee80211_aes_ccm_decrypt>:
ffffffff8146d1ed: e8 9e 67 04 00 callq ffffffff814b3990 <__fentry__>
ffffffff8146d1f2: 55 push %rbp
ffffffff8146d1f3: 48 89 e5 mov %rsp,%rbp
ffffffff8146d1f6: 41 57 push %r15
ffffffff8146d1f8: 41 56 push %r14
ffffffff8146d1fa: 49 89 ce mov %rcx,%r14
ffffffff8146d1fd: 41 55 push %r13
ffffffff8146d1ff: 41 54 push %r12
ffffffff8146d201: 53 push %rbx
ffffffff8146d202: 48 83 c4 80 add $0xffffffffffffff80,%rsp
ffffffff8146d206: 8b 47 04 mov 0x4(%rdi),%eax
ffffffff8146d209: 48 8d 48 50 lea 0x50(%rax),%rcx
ffffffff8146d20d: 48 83 c0 5e add $0x5e,%rax
ffffffff8146d211: 48 c1 e8 03 shr $0x3,%rax
ffffffff8146d215: 48 c1 e0 03 shl $0x3,%rax
ffffffff8146d219: 48 29 c4 sub %rax,%rsp
ffffffff8146d21c: 4c 8d 7c 24 07 lea 0x7(%rsp),%r15
ffffffff8146d221: 49 c1 ef 03 shr $0x3,%r15
ffffffff8146d225: 4d 85 c0 test %r8,%r8
ffffffff8146d228: 4a 8d 04 fd 00 00 00 lea 0x0(,%r15,8),%rax
ffffffff8146d22f: 00
ffffffff8146d230: 48 89 85 70 ff ff ff mov %rax,-0x90(%rbp)
ffffffff8146d237: 75 0a jne ffffffff8146d243 <ieee80211_aes_ccm_decrypt+0x56>
ffffffff8146d239: b8 ea ff ff ff mov $0xffffffea,%eax
ffffffff8146d23e: e9 1a 02 00 00 jmpq ffffffff8146d45d <ieee80211_aes_ccm_decrypt+0x270>
ffffffff8146d243: 31 c0 xor %eax,%eax
ffffffff8146d245: 49 89 fc mov %rdi,%r12
ffffffff8146d248: 49 89 f5 mov %rsi,%r13
ffffffff8146d24b: 4c 89 85 58 ff ff ff mov %r8,-0xa8(%rbp)
ffffffff8146d252: 4a 8d 3c fd 00 00 00 lea 0x0(,%r15,8),%rdi
ffffffff8146d259: 00
ffffffff8146d25a: be 03 00 00 00 mov $0x3,%esi
ffffffff8146d25f: 4c 89 cb mov %r9,%rbx
ffffffff8146d262: 48 89 95 60 ff ff ff mov %rdx,-0xa0(%rbp)
ffffffff8146d269: f3 aa rep stos %al,%es:(%rdi)
ffffffff8146d26b: 48 8d 85 78 ff ff ff lea -0x88(%rbp),%rax
ffffffff8146d272: 48 89 c7 mov %rax,%rdi
ffffffff8146d275: 48 89 85 68 ff ff ff mov %rax,-0x98(%rbp)
ffffffff8146d27c: e8 46 06 dc ff callq ffffffff8122d8c7 <sg_init_table>
ffffffff8146d281: 48 8b 95 60 ff ff ff mov -0xa0(%rbp),%rdx
ffffffff8146d288: 41 b9 00 00 00 80 mov $0x80000000,%r9d
ffffffff8146d28e: 48 8b 0d 7b cd 39 00 mov 0x39cd7b(%rip),%rcx # ffffffff8180a010 <phys_base>
ffffffff8146d295: 48 8b 85 68 ff ff ff mov -0x98(%rbp),%rax
ffffffff8146d29c: 4c 8b 85 58 ff ff ff mov -0xa8(%rbp),%r8
ffffffff8146d2a3: 0f b7 32 movzwl (%rdx),%esi
ffffffff8146d2a6: 48 83 c2 02 add $0x2,%rdx
ffffffff8146d2aa: 89 d7 mov %edx,%edi
ffffffff8146d2ac: 81 e7 ff 0f 00 00 and $0xfff,%edi
ffffffff8146d2b2: 66 c1 c6 08 rol $0x8,%si
ffffffff8146d2b6: 4c 01 ca add %r9,%rdx
ffffffff8146d2b9: 0f b7 f6 movzwl %si,%esi
ffffffff8146d2bc: 72 0a jb ffffffff8146d2c8 <ieee80211_aes_ccm_decrypt+0xdb>
ffffffff8146d2be: 48 b9 00 00 00 80 ff movabs $0x77ff80000000,%rcx
ffffffff8146d2c5: 77 00 00
ffffffff8146d2c8: 48 01 ca add %rcx,%rdx
ffffffff8146d2cb: 49 89 d1 mov %rdx,%r9
ffffffff8146d2ce: 48 89 d1 mov %rdx,%rcx
ffffffff8146d2d1: 48 c1 ea 23 shr $0x23,%rdx
ffffffff8146d2d5: 48 8b 14 d5 80 23 63 mov -0x7d9cdc80(,%rdx,8),%rdx
ffffffff8146d2dc: 82
ffffffff8146d2dd: 49 c1 e9 0c shr $0xc,%r9
ffffffff8146d2e1: 48 c1 e9 1b shr $0x1b,%rcx
ffffffff8146d2e5: 48 85 d2 test %rdx,%rdx
ffffffff8146d2e8: 74 0a je ffffffff8146d2f4 <ieee80211_aes_ccm_decrypt+0x107>
ffffffff8146d2ea: 0f b6 c9 movzbl %cl,%ecx
ffffffff8146d2ed: 48 c1 e1 04 shl $0x4,%rcx
ffffffff8146d2f1: 48 01 ca add %rcx,%rdx
ffffffff8146d2f4: 48 8b 12 mov (%rdx),%rdx
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ffffffff8146d2f7: 49 c1 e1 06 shl $0x6,%r9
ffffffff8146d2fb: b9 00 00 00 80 mov $0x80000000,%ecx
ffffffff8146d300: 89 7d 80 mov %edi,-0x80(%rbp)
ffffffff8146d303: 89 75 84 mov %esi,-0x7c(%rbp)
ffffffff8146d306: 48 8b 3d 03 cd 39 00 mov 0x39cd03(%rip),%rdi # ffffffff8180a010 <phys_base>
ffffffff8146d30d: 48 83 e2 fc and $0xfffffffffffffffc,%rdx
ffffffff8146d311: 49 01 d1 add %rdx,%r9
ffffffff8146d314: 48 8b 95 78 ff ff ff mov -0x88(%rbp),%rdx
-ss
^ permalink raw reply
* Re: [PATCH net] Revert "net: Add driver helper functions to determine checksum offloadability"
From: Jonathan Cooper @ 2016-10-13 15:31 UTC (permalink / raw)
To: David Miller, stephen; +Cc: tom, netdev
In-Reply-To: <20161013.103548.511298911926565246.davem@davemloft.net>
On 13/10/16 15:35, David Miller wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Tue, 11 Oct 2016 13:04:09 -0700
>
>> This reverts commit 6ae23ad36253a8033c5714c52b691b84456487c5.
>>
>> The code has been in kernel since 4.4 but there are no in tree
>> code that uses. Unused code is broken code, remove it.
>>
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Tom if you have any real plans to develop on this work at all in
> the immediate future, please speak up now.
>
> Otherwise I'm applying Stephen's patch.
>
> Thanks.
Oops, nope, I tell a lie. We used it initially and then realised we
didn't strictly
need it since we only advertise IP_CSUM and IPV6_CSUM of inner
packets, so we should never be presented with a packet we'd need to
call the helper for. So we're not using it after all.
Jon
^ permalink raw reply
* Re: [PATCH] net: axienet: Remove unused parameter from __axienet_device_reset
From: Michal Simek @ 2016-10-13 15:02 UTC (permalink / raw)
To: Tobias Klauser, Michal Simek
Cc: Anirudha Sarangi, John Linn, Sören Brinkmann, netdev
In-Reply-To: <20161013144046.GW8952@distanz.ch>
On 13.10.2016 16:40, Tobias Klauser wrote:
> On 2016-10-13 at 14:23:49 +0200, Michal Simek <michal.simek@xilinx.com> wrote:
>> On 13.10.2016 13:28, Tobias Klauser wrote:
>>> The dev parameter passed to __axienet_device_reset() is not used inside
>>> the function, so remove it.
>>>
>>> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>>> ---
>>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 11 +++++------
>>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
>>> index 35f9f9742a48..c688d68c39aa 100644
>>> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
>>> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
>>> @@ -431,8 +431,7 @@ static void axienet_setoptions(struct net_device *ndev, u32 options)
>>> lp->options |= options;
>>> }
>>>
>>> -static void __axienet_device_reset(struct axienet_local *lp,
>>> - struct device *dev, off_t offset)
>>> +static void __axienet_device_reset(struct axienet_local *lp, off_t offset)
>>> {
>>> u32 timeout;
>>> /* Reset Axi DMA. This would reset Axi Ethernet core as well. The reset
>>> @@ -468,8 +467,8 @@ static void axienet_device_reset(struct net_device *ndev)
>>> u32 axienet_status;
>>> struct axienet_local *lp = netdev_priv(ndev);
>>>
>>> - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_TX_CR_OFFSET);
>>> - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_RX_CR_OFFSET);
>>> + __axienet_device_reset(lp, XAXIDMA_TX_CR_OFFSET);
>>> + __axienet_device_reset(lp, XAXIDMA_RX_CR_OFFSET);
>>>
>>> lp->max_frm_size = XAE_MAX_VLAN_FRAME_SIZE;
>>> lp->options |= XAE_OPTION_VLAN;
>>> @@ -1338,8 +1337,8 @@ static void axienet_dma_err_handler(unsigned long data)
>>> axienet_iow(lp, XAE_MDIO_MC_OFFSET, (mdio_mcreg &
>>> ~XAE_MDIO_MC_MDIOEN_MASK));
>>>
>>> - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_TX_CR_OFFSET);
>>> - __axienet_device_reset(lp, &ndev->dev, XAXIDMA_RX_CR_OFFSET);
>>> + __axienet_device_reset(lp, XAXIDMA_TX_CR_OFFSET);
>>> + __axienet_device_reset(lp, XAXIDMA_RX_CR_OFFSET);
>>>
>>> axienet_iow(lp, XAE_MDIO_MC_OFFSET, mdio_mcreg);
>>> axienet_mdio_wait_until_ready(lp);
>>>
>>
>> Can you please send this directly to mainline?
>> And put my:
>> Reviewed-by: Michal Simek <michal.simek@xilinx.com>
>
> The netdev mailing list was Cc'ed on the patch, so it should end up in
> davem's patch queue.
ah ok. I missed that.
Then we are good.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change
From: Zach Brown @ 2016-10-13 15:42 UTC (permalink / raw)
To: David Miller
Cc: f.fainelli, mlindner, stephen, netdev, linux-kernel, devel,
florian.c.schilhabel, Larry.Finger, gregkh, rpurdie, j.anaszewski,
linux-leds, andrew
In-Reply-To: <20161013.104634.2079376697690971907.davem@davemloft.net>
On Thu, Oct 13, 2016 at 10:46:34AM -0400, David Miller wrote:
> From: Zach Brown <zach.brown@ni.com>
> Date: Tue, 11 Oct 2016 15:26:20 -0500
>
> > From: Josh Cartwright <josh.cartwright@ni.com>
> >
> > Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
> > create a set of led triggers for each instantiated PHY device. There is
> > one LED trigger per link-speed, per-phy.
> >
> > This allows for a user to configure their system to allow a set of LEDs
> > to represent link state changes on the phy.
> >
> > Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> > Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
> > Signed-off-by: Zach Brown <zach.brown@ni.com>
> ...
> > + static const char * const name_suffix[] = {
> > + "10Mbps",
> > + "100Mbps",
> > + "1Gbps",
> > + "2.5Gbps",
> > + "10Gbps",
>
> This choice of both the array size and the speeds to support seems
> entirely arbitrary and is inappropriate for a generic driver of this
> kind.
>
> This seems to be hard coding this to support the list of speeds
> supported by whatever driver you want to use with this new LED
> facility, and sorry that's not how we build nice generic pieces of
> infrastructure.
>
> Thanks.
The speeds listed are the speeds found in the phy_speed_to_str function in phy.c.
They are also the speeds found in the struct phy_setting settings array,
which is commented with
"/* A mapping of all SUPPORTED settings to speed/duplex */"
We believed they represented the commonly supported speeds of phys.
Do you have suggestions on how to better handle the choice of the array size
and the speeds?
Thanks.
^ permalink raw reply
* Re: [PATCH v6] net: ip, diag -- Add diag interface for raw sockets
From: David Ahern @ 2016-10-13 15:43 UTC (permalink / raw)
To: Cyrill Gorcunov, David Miller
Cc: netdev, eric.dumazet, jhs, linux-kernel, kuznet, jmorris,
yoshfuji, kaber, avagin, stephen
In-Reply-To: <20161013071648.GA1946@uranus.lan>
On 10/13/16 1:16 AM, Cyrill Gorcunov wrote:
> On Wed, Oct 12, 2016 at 07:55:04PM -0400, David Miller wrote:
>> From: Cyrill Gorcunov <gorcunov@gmail.com>
>> Date: Wed, 12 Oct 2016 09:53:29 +0300
>>
>>> I can't rename the field, neither a can use union.
>>
>> Remind me again what is wrong with using an anonymous union?
>
> Anon union would be a preferred but Eric pointed me that even
> though it might cause problems (https://patchwork.kernel.org/patch/9353365/)
>
> | Note that some programs could fail to compile with the added union
> | anyway.
> |
> | Some gcc versions are unable to compile a static init with an union
> |
> | struct inet_diag_req_v2 foo = { .pad = 0, sdiag_family = AF_INET, };
> |
> | When I cooked my recent fq commit I simply removed a pad and replaced
> | it :
> |
> | git show fefa569a9d4bc4 -- include
>
That commit suggests it is acceptable to just rename the pad field, which is the simplest approach.
^ permalink raw reply
* Re: [PATCH] net: limit a number of namespaces which can be cleaned up concurrently
From: Eric W. Biederman @ 2016-10-13 15:49 UTC (permalink / raw)
To: Andrei Vagin
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
David S. Miller
In-Reply-To: <1476293579-28582-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> writes:
> From: Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
>
> The operation of destroying netns is heavy and it is executed under
> net_mutex. If many namespaces are destroyed concurrently, net_mutex can
> be locked for a long time. It is impossible to create a new netns during
> this period of time.
This may be the right approach or at least the right approach to bound
net_mutex hold times but I have to take exception to calling network
namespace cleanup heavy.
The only particularly time consuming operation I have ever found are calls to
synchronize_rcu/sycrhonize_sched/synchronize_net.
Ideally we can search those out calls in the network namespace cleanup
operations and figuroue out how to eliminate those operations or how to
stack them.
> In our days when userns allows to create network namespaces to
> unprivilaged users, it may be a real problem.
Sorting out syncrhonize_rcu calls will be a much larger
and much more effective improvement than your patch here.
> On my laptop (fedora 24, i5-5200U, 12GB) 1000 namespaces requires about
> 300MB of RAM and are being destroyed for 8 seconds.
>
> In this patch, a number of namespaces which can be cleaned up
> concurrently is limited by 32. net_mutex is released after handling each
> portion of net namespaces and then it is locked again to handle the next
> one. It allows other users to lock it without waiting for a long
> time.
>
> I am not sure whether we need to add a sysctl to costomize this limit.
> Let me know if you think it's required.
We definitely don't need an extra sysctl.
Eric
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
> ---
> net/core/net_namespace.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 989434f..33dd3b7 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -406,10 +406,20 @@ static void cleanup_net(struct work_struct *work)
> struct net *net, *tmp;
> struct list_head net_kill_list;
> LIST_HEAD(net_exit_list);
> + int i = 0;
>
> /* Atomically snapshot the list of namespaces to cleanup */
> spin_lock_irq(&cleanup_list_lock);
> - list_replace_init(&cleanup_list, &net_kill_list);
> + list_for_each_entry_safe(net, tmp, &cleanup_list, cleanup_list)
> + if (++i == 32)
> + break;
> + if (i == 32) {
> + list_cut_position(&net_kill_list,
> + &cleanup_list, &net->cleanup_list);
> + queue_work(netns_wq, work);
> + } else {
> + list_replace_init(&cleanup_list, &net_kill_list);
> + }
> spin_unlock_irq(&cleanup_list_lock);
>
> mutex_lock(&net_mutex);
^ permalink raw reply
* RE: [PATCH] qed: Fix to use list_for_each_entry_safe() when delete items
From: Mintz, Yuval @ 2016-10-13 14:14 UTC (permalink / raw)
To: David Miller, weiyj.lk@gmail.com
Cc: Ariel.Elior@qlogic.com, weiyongjun1@huawei.com,
netdev@vger.kernel.org
In-Reply-To: <20161013.094725.657883863089600176.davem@davemloft.net>
> > Since we will remove items off the list using list_del() we need to
> > use a safe version of the list_for_each_entry() macro aptly named
> > list_for_each_entry_safe().
> >
> > Fixes: 0a7fb11c23c0 ("qed: Add Light L2 support")
> > Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
>
> Can the QED maintainers please review this simple fix?
>
> In my opinion 4 days is sufficient time in which to expect a reasonable review to
> occur, let me know if you disagree. :-)
Sorry about that; The high holy days are killing our productivity. :-(
I did ACK v1, though [and v2 was purely semantic change].
^ permalink raw reply
* RE: [PATCH] qed: fix old-style function definition
From: Mintz, Yuval @ 2016-10-13 14:15 UTC (permalink / raw)
To: David Miller, arnd@arndb.de
Cc: Yuval.Mintz@qlogic.com, Ariel.Elior@qlogic.com,
everest-linux-l2@qlogic.com, Amrani, Ram, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20161013.095532.1238800778112994579.davem@davemloft.net>
> > The definition of qed_get_rdma_ops() is not a prototype unless we add
> > 'void' here, as indicated by this W=1 warning:
> >
> > drivers/net/ethernet/qlogic/qed/qed_roce.c: In function ‘qed_get_rdma_ops’:
> > drivers/net/ethernet/qlogic/qed/qed_roce.c:2950:28: error: old-style
> > function definition [-Werror=old-style-definition]
> >
> > Fixes: abd49676c707 ("qed: Add RoCE ll2 & GSI support")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Again, Qlogic folks, please properly review patches posted against your driver.
>
> Thanks.
Sorry, managed to miss this one.
Acked-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.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