* pull-request: wireless-drivers-next 2017-04-27
From: Kalle Valo @ 2017-04-27 9:41 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request for net-next, more info in the tag below. This
should be the last pull request to net-next for 4.12. Please let me know
if there are any problems.
Kalle
The following changes since commit 7acedaf5c4355f812cfef883ac28bf15f7d9205e:
net: move xdp_prog field in RX cache lines (2017-04-25 16:25:36 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-04-27
for you to fetch changes up to 47d272f0f9887343f4e4d31bb22910b141b96654:
Merge tag 'iwlwifi-next-for-kalle-2017-04-26' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next (2017-04-26 14:21:00 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.12
Few remaining patches for 4.12 submitted during the last week.
Major changes:
iwlwifi
* the firmware for 7265D and 3168 NICs is frozen at version 29
* more support for the upcoming A000 series
----------------------------------------------------------------
Colin Ian King (1):
orinoco: fix spelling mistake: "Registerred" -> "Registered"
Dor Shaish (1):
iwlwifi: mvm: freeze 7265D and 3168 on API version 29
Haim Dreyfuss (1):
iwlwifi: mvm: Ignore wifi mcc update in the driver while associated
James Hughes (2):
brcmfmac: Ensure pointer correctly set if skb data location changes
brcmfmac: Make skb header writable before use
Johannes Berg (6):
iwlwifi: mvm: make iwl_run_unified_mvm_ucode() static
iwlwifi: mvm: avoid variable shadowing
iwlwifi: pcie: remove superfluous trans->dev assignment
iwlwifi: don't leak memory on allocation failure
iwlwifi: remove module loading failure message
iwlwifi: pcie: apply no-reclaim logic only to group 0
Kalle Valo (1):
Merge tag 'iwlwifi-next-for-kalle-2017-04-26' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Larry Finger (1):
rtlwifi: rtl8821ae: setup 8812ae RFE according to device type
Liad Kaufman (2):
iwlwifi: pcie: support debug applying on a000 hw
iwlwifi: gen2: support nmi triggering from host
Maksim Salau (1):
orinoco_usb: Fix buffer on stack
Mordechai Goodstein (1):
iwlwifi: mvm: scan: avoid "big" prints
Pan Bian (3):
mt7601u: check return value of alloc_skb
libertas: check return value of alloc_workqueue
rndis_wlan: add return value validation
Sara Sharon (12):
iwlwifi: mvm: support new rate flags
iwlwifi: mvm: don't reserve queue in TVQM mode
iwlwifi: mvm: map cab_queue to different txq_id
iwlwifi: mvm: move internally to use bigger INVALID_TXQ
iwlwifi: mvm: remove color definition
iwlwifi: mvm: use defines instead of variables for shared dwell times
iwlwifi: mvm: remove references to queue_info in new TX path
iwlwifi: mvm: support station type API
iwlwifi: move to 512 queues
iwlwifi: rename wait_for_tx_queues_empty
iwlwifi: mvm: memset binding before setting values
iwlwifi: adjust NVM parsing APIs for new a000 method
Sharon Dvir (2):
iwlwifi: mvm: check if returned value is NULL
iwlwifi: mvm: handle possible BIOS bug
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 23 +--
drivers/net/wireless/intel/iwlwifi/dvm/lib.c | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 15 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-io.c | 3 +
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 32 ++-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 16 +-
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 10 +-
drivers/net/wireless/intel/iwlwifi/mvm/binding.c | 4 +-
.../net/wireless/intel/iwlwifi/mvm/fw-api-mac.h | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rs.h | 28 ++-
.../net/wireless/intel/iwlwifi/mvm/fw-api-sta.h | 38 ++--
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 161 ++++++++-------
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 11 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 37 ++--
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 10 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 11 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 86 +++-----
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 229 ++++++++++++++-------
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 7 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 13 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 96 ++++++---
.../net/wireless/intel/iwlwifi/pcie/ctxt-info.c | 4 +
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 7 +-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 5 +-
drivers/net/wireless/intersil/orinoco/main.c | 2 +-
.../net/wireless/intersil/orinoco/orinoco_usb.c | 21 +-
drivers/net/wireless/marvell/libertas/if_spi.c | 5 +
drivers/net/wireless/mediatek/mt7601u/mcu.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 122 +++++++++--
.../net/wireless/realtek/rtlwifi/rtl8821ae/reg.h | 1 +
drivers/net/wireless/rndis_wlan.c | 4 +
42 files changed, 671 insertions(+), 388 deletions(-)
^ permalink raw reply
* Re: [PATCH] net: macb: fix phy interrupt parsing
From: Nicolas Ferre @ 2017-04-27 9:36 UTC (permalink / raw)
To: Alexandre Belloni, David S . Miller; +Cc: Bartosz Folta, netdev, linux-kernel
In-Reply-To: <20170426100628.14493-1-alexandre.belloni@free-electrons.com>
Le 26/04/2017 à 12:06, Alexandre Belloni a écrit :
> Since 83a77e9ec415, the phydev irq is explicitly set to PHY_POLL when
> there is no pdata. It doesn't work on DT enabled platforms because the
> phydev irq is already set by libphy before.
>
> Fixes: 83a77e9ec415 ("net: macb: Added PCI wrapper for Platform Driver.")
Means 4.10+
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Seems a good candidate for net stable.
Bye,
> ---
> drivers/net/ethernet/cadence/macb.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index e131ecd17ab9..004223a866fe 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -432,15 +432,17 @@ static int macb_mii_probe(struct net_device *dev)
> }
>
> pdata = dev_get_platdata(&bp->pdev->dev);
> - if (pdata && gpio_is_valid(pdata->phy_irq_pin)) {
> - ret = devm_gpio_request(&bp->pdev->dev, pdata->phy_irq_pin,
> - "phy int");
> - if (!ret) {
> - phy_irq = gpio_to_irq(pdata->phy_irq_pin);
> - phydev->irq = (phy_irq < 0) ? PHY_POLL : phy_irq;
> + if (pdata) {
> + if (gpio_is_valid(pdata->phy_irq_pin)) {
> + ret = devm_gpio_request(&bp->pdev->dev,
> + pdata->phy_irq_pin, "phy int");
> + if (!ret) {
> + phy_irq = gpio_to_irq(pdata->phy_irq_pin);
> + phydev->irq = (phy_irq < 0) ? PHY_POLL : phy_irq;
> + }
> + } else {
> + phydev->irq = PHY_POLL;
> }
> - } else {
> - phydev->irq = PHY_POLL;
> }
>
> /* attach the mac to the phy */
>
--
Nicolas Ferre
^ permalink raw reply
* 50854 netdev
From: gestu @ 2017-04-27 9:32 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 87611415.zip --]
[-- Type: application/zip, Size: 1270 bytes --]
^ permalink raw reply
* Re: [PATCH v1 net-next 0/6] Extend socket timestamping API
From: Miroslav Lichvar @ 2017-04-27 9:28 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Willem de Bruijn, Soheil Hassas Yeganeh, Keller, Jacob E,
Denny Page, Jiri Benc
In-Reply-To: <20170426165435.GA21114@localhost.localdomain>
On Wed, Apr 26, 2017 at 06:54:35PM +0200, Richard Cochran wrote:
> On Wed, Apr 26, 2017 at 04:50:29PM +0200, Miroslav Lichvar wrote:
> > This patchset adds new options to the timestamping API that will be
> > useful for NTP implementations and possibly other applications.
>
> Are there any userland ntp patches floating around to exercise the new
> HW time stamping option?
I'm not sure if anyone is working on support for HW timestamping in
ntp. With chrony, you can test it with an experimental code in the
hwts branch of https://github.com/mlichvar/chrony.
$ ./configure --enable-debug && make
# ./chronyd -d -d 'hwtimestamp *' 'server pool.ntp.org iburst' |& grep TIMESTAMP
TX SCM_TIMESTAMPING: swts=1493285228.512531924 hwts=0.000000000
TX SCM_TIMESTAMPING: swts=0.000000000 hwts=1493285226.073103885
SCM_TIMESTAMPING_PKTINFO: if=2 len=90
RX SCM_TIMESTAMPING: swts=1493285228.530657351 hwts=1493285226.091054104
TX SCM_TIMESTAMPING: swts=1493285230.553457791 hwts=0.000000000
TX SCM_TIMESTAMPING: swts=0.000000000 hwts=1493285228.113705104
SCM_TIMESTAMPING_PKTINFO: if=2 len=90
RX SCM_TIMESTAMPING: swts=1493285230.582817079 hwts=1493285228.142890229
--
Miroslav Lichvar
^ permalink raw reply
* Re: [PATCH net] xfrm: calculate L4 checksums also for GSO case before encrypting packets
From: Steffen Klassert @ 2017-04-27 9:04 UTC (permalink / raw)
To: Ansis Atteka; +Cc: Ansis Atteka, netdev
In-Reply-To: <CAMQa7Bgn58eWhwH-tOJcoNoF7ATs5yBpAyu1rR4JN5=8pBdaMA@mail.gmail.com>
On Fri, Apr 21, 2017 at 02:45:17PM -0700, Ansis Atteka wrote:
>
> I removed Geneve tunneling from equation and tried to run a simple
> iperf underlay UDP test while IPsec was still enabled to observe
> issues with the udp4_ufo_fragment() case.
>
> Unfortunately, as can be seen from kernel tracer output below, I was
> unable to come up with a test case where udp4_ufo_fragment function
> would ever be invoked while IPsec is enabled:
>
> admin1@ubuntu1:~/xfrm_test/net$ ifconfig em2.4001 | grep "inet addr"
> inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
> admin1@ubuntu1:~/xfrm_test/net$ ethtool -k em2.4001 | grep
> udp-fragmentation-offload
> udp-fragmentation-offload: on
> admin1@ubuntu1:~/xfrm_test/net$ sudo trace-cmd record -p
> function_graph -c -F iperf -c 192.168.1.2 -u -l20000
> admin1@ubuntu1:~/xfrm_test/net$ trace-cmd report | grep udp4
> admin1@ubuntu1:~/xfrm_test/net$
>
>
> Nevertheless, after disabling IPsec and leaving everything else the
> same, I start to see that udp4_ufo_fragment() gets invoked:
>
> admin1@ubuntu1:~/xfrm_test/net$ trace-cmd report | grep udp4
> iperf-25466 [004] 242431.203307: funcgraph_entry:
> 0.113 us | udp4_hwcsum();
> iperf-25466 [004] 242431.203360: funcgraph_entry:
> |
> udp4_ufo_fragment() {
> iperf-25466 [004] 242431.508436: funcgraph_entry:
> 0.080 us | udp4_hwcsum();
> iperf-25466 [004] 242431.508542: funcgraph_entry:
> |
> udp4_ufo_fragment() {
>
>
> However, non-IPsec case really does not have this ESP packet
> corruption problem, because then the packets are in plain and can
> utilize checksum offloads. Do we really have a problem there for
> IPsec?
Probably not, at least locally generated packets don't do
ufo if they have an IPsec route. So it seems to be ok to
leave udp4_ufo_fragment as it is.
^ permalink raw reply
* Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
From: Jason A. Donenfeld @ 2017-04-27 9:21 UTC (permalink / raw)
To: Netdev, LKML, David Laight, kernel-hardening, David Miller
Cc: Jason A. Donenfeld
In-Reply-To: <20170425184734.26563-1-Jason@zx2c4.com>
Hey Dave,
David Laight and I have been discussing offlist. It occurred to both
of us that this could just be turned into a loop because perhaps this
is actually just tail-recursive. Upon further inspection, however, the
way the current algorithm works, it's possible that each of the
fraglist skbs has its own fraglist, which would make this into tree
recursion, which is why in the first place I wanted to place that
limit on it. If that's the case, then the patch I proposed above is
the best way forward. However, perhaps there's the chance that
fraglist skbs having separate fraglists are actually forbidden? Is
this the case? Are there other parts of the API that enforce this
contract? Is it something we could safely rely on here? If you say
yes, I'll send a v7 that makes this into a non-recursive loop.
Regards,
Jason
^ permalink raw reply
* Re: ipsec doesn't route TCP with 4.11 kernel
From: Steffen Klassert @ 2017-04-27 8:42 UTC (permalink / raw)
To: Cong Wang
Cc: Don Bowman, linux-kernel@vger.kernel.org, Herbert Xu,
Linux Kernel Network Developers
In-Reply-To: <CAM_iQpWT5tF5+LpoTP98JNJ=440jEkxHFkn8=jtAsZgondN49A@mail.gmail.com>
On Wed, Apr 26, 2017 at 10:01:34PM -0700, Cong Wang wrote:
> (Cc'ing netdev and IPSec maintainers)
>
> On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman <db@donbowman.ca> wrote:
> > I'm not sure how to describe this.
> >
> > 4.11rc2 worked, after that, no.
We had some recent IPsec GRO changes, this could influence TCP.
But these changes were introduced before rc2. If I read this correct,
the regression was introduced between rc2 and rc3, right?
> >
> > My ipsec tunnel comes up ok.
When talking about IPsec, I guess you use ESP, right?
> > ICMP works. UDP works. But TCP, the
> > sender [which is the ipsec client] does not reach the destination.
> >
> > Its not a routing rule issue (since ICMP/UDP work).
> > Its not a traffic selector just selecting TCP (I think) since ipsec
> > status shows just a subnet, no protocol.
> >
> > Using tcpdump:
> > # iptables -t mangle -I PREROUTING -m policy --pol ipsec --dir in -j
> > NFLOG --nflog-group 5
> > # iptables -t mangle -I POSTROUTING -m policy --pol ipsec --dir out -j
> > NFLOG --nflog-group 5
> > # tcpdump -s 0 -n -i nflog:5
> >
> > I see that it thinks it is sending the TCP packet, but the server end
> > does not receive.
> >
> > Does anyone have any suggestion to try?
If it is a GRO issue, then it is on the receive side, could you do
tcpdump on the receiving interface to see what you get there?
What shows /proc/net/xfrm_stat?
Can you do 'ip -s x s' to see if the SAs are used?
Do you have INET_ESP_OFFLOAD enabled?
^ permalink raw reply
* Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta
From: Sricharan R @ 2017-04-27 8:54 UTC (permalink / raw)
To: Joerg Roedel, Ralph Sennhauser
Cc: Rafael J. Wysocki, Bjorn Helgaas, linux-acpi, linux-kernel,
linux-pci, Thomas Petazzoni, netdev
In-Reply-To: <20170427084427.GV5077@suse.de>
Hi Joerg,
On 4/27/2017 2:14 PM, Joerg Roedel wrote:
> Sricharan,
>
> On Wed, Apr 26, 2017 at 06:15:08PM +0200, Ralph Sennhauser wrote:
>> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time
>> for platform/amba/pci bus devices") causes a kernel panic as in the log
>> below on an armada-385. Reverting the commit fixes the issue.
>
> Any insight here? I tend to revert the patch in my tree, or is there a
> quick and easy fix?
I am checking on this manually to see what could be going wrong in the
driver. From logs i could not conclude directly. I will need some
more testing help (i will ask for) to root cause this.
Regards,
Sricharan
>
>
>
> Joerg
>
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta
From: Joerg Roedel @ 2017-04-27 8:44 UTC (permalink / raw)
To: Ralph Sennhauser
Cc: Sricharan R, Rafael J. Wysocki, Bjorn Helgaas, linux-acpi,
linux-kernel, linux-pci, Thomas Petazzoni, netdev
In-Reply-To: <20170426181508.687b52af@gmail.com>
Sricharan,
On Wed, Apr 26, 2017 at 06:15:08PM +0200, Ralph Sennhauser wrote:
> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time
> for platform/amba/pci bus devices") causes a kernel panic as in the log
> below on an armada-385. Reverting the commit fixes the issue.
Any insight here? I tend to revert the patch in my tree, or is there a
quick and easy fix?
Joerg
^ permalink raw reply
* Re: [PATCH] net: hso: register netdev later to avoid a race condition
From: Johan Hovold @ 2017-04-27 8:44 UTC (permalink / raw)
To: Andreas Kemnade
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, joe-6d6DIl74uiNBDgjK7y7TUQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8,
hns-xXXSsgcRVICgSpxsJD1C4w, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493227600-10102-1-git-send-email-andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org>
On Wed, Apr 26, 2017 at 07:26:40PM +0200, Andreas Kemnade wrote:
> If the netdev is accessed before the urbs are initialized,
> there will be NULL pointer dereferences. That is avoided by
> registering it when it is fully initialized.
> Reported-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> Signed-off-by: Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org>
> ---
> drivers/net/usb/hso.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index 93411a3..00067a0 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -2534,13 +2534,6 @@ static struct hso_device *hso_create_net_device(struct usb_interface *interface,
> SET_NETDEV_DEV(net, &interface->dev);
> SET_NETDEV_DEVTYPE(net, &hso_type);
>
> - /* registering our net device */
> - result = register_netdev(net);
> - if (result) {
> - dev_err(&interface->dev, "Failed to register device\n");
> - goto exit;
> - }
> -
> /* start allocating */
> for (i = 0; i < MUX_BULK_RX_BUF_COUNT; i++) {
> hso_net->mux_bulk_rx_urb_pool[i] = usb_alloc_urb(0, GFP_KERNEL);
> @@ -2560,6 +2553,13 @@ static struct hso_device *hso_create_net_device(struct usb_interface *interface,
>
> add_net_device(hso_dev);
>
> + /* registering our net device */
> + result = register_netdev(net);
> + if (result) {
> + dev_err(&interface->dev, "Failed to register device\n");
> + goto exit;
This all looks good, but you should consider cleaning up the error
handling of this function as a follow-up as we should not be
deregistering netdevs that have never been registered (e.g. if a
required endpoint is missing or if registration fails for some reason).
But just to be clear, this problem existed also before this change.
> + }
> +
> hso_log_port(hso_dev);
>
> hso_create_rfkill(hso_dev, interface);
Reviewed-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: xdp_redirect ifindex vs port. Was: best API for returning/setting egress port?
From: Jesper Dangaard Brouer @ 2017-04-27 8:41 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Alexei Starovoitov, John Fastabend, Alexei Starovoitov,
Daniel Borkmann, Daniel Borkmann, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org, brouer
In-Reply-To: <20170426205544.GA40859@C02RW35GFVH8>
On Wed, 26 Apr 2017 16:55:44 -0400
Andy Gospodarek <andy@greyhouse.net> wrote:
> On Wed, Apr 26, 2017 at 10:58:45AM -0700, Alexei Starovoitov wrote:
> > On 4/26/17 9:35 AM, John Fastabend wrote:
> > >
> > > > As Alexei also mentioned before, ifindex vs port makes no real
> > > > difference seen from the bpf program side. It is userspace's
> > > > responsibility to add ifindex/port's to the bpf-maps, according to how
> > > > the bpf program "policy" want to "connect" these ports. The
> > > > port-table system add one extra step, of also adding this port to the
> > > > port-table (which lives inside the kernel).
> > > >
> > >
> > > I'm not sure I understand the "lives inside the kernel" bit. I assumed
> > > the 'map' should be a bpf map and behave like any other bpf map.
> > >
> > > I wanted a new map to be defined, something like this from the bpf programmer
> > > side.
> > >
> > > struct bpf_map_def SEC("maps") port_table =
> > > .type = BPF_MAP_TYPE_PORT_CONNECTION,
> > > .key_size = sizeof(u32),
> > > .value_size = BPF_PORT_CONNECTION_SIZE,
> > > .max_entries = 256,
> > > };
> >
> > I like the idea.
> > We have prog_array, perf_event_array, cgroup_array map specializations.
> > This one can be new netdev_array with some new bpf_redirect-like helper
> > accessing it.
> >
> > > > When loading the XDP program, we also need to pass along a port table
> > > > "id" this XDP program is associated with (and if it doesn't exists you
> > > > create it). And your userspace "control-plane" application also need
> > > > to know this port table "id", when adding a new port.
> > >
> > > So the user space application that is loading the program also needs
> > > to handle this map. This seems correct to me. But I don't see the
> > > value in making some new port table when we already have well understood
> > > framework for maps.
> >
> > +1
> >
> > > >
> > > > The concept of having multiple port tables is key. As this implies we
> > > > can have several simultaneous "data-planes" that is *isolated* from
> > > > each-other. Think about how network-namespaces/containers want
> > > > isolation. A subtle thing I'm afraid to mention, is that oppose to the
> > > > ifindex model, a port table with mapping to a net_device pointer, would
> > > > allow (faster) delivery into the container's inner net_device, which
> > > > sort of violates the isolation, but I would argue it is not a problem
> > > > as this net_device pointer could only be added from a process within the
> > > > namespace. I like this feature, but it could easily be disallowed via
> > > > port insertion-time validation.
> > > >
> > >
> > > I think the above optimization should be allowed. And agree multiple port
> > > tables (maps?) is needed. Again all this points to using standard maps
> > > logic in my mind. For permissions and different domains, which I think
> > > you were starting to touch on, it looks like we could extend the pinning API.
> > > At the moment it does an inode_permission(inode, MAY_WRITE) check but I
> > > presume this could be extended. None of this would be needed in v1 and
> > > could be added subsequently. read-only maps seems doable.
> >
> > this is great idea. Once BPF_MAP_TYPE_NETDEV_ARRAY is populated
> > the user space can make it readonly to prevent further changes.
> >
> > From user space it can be done similar to perf_events/cgroups as well.
> > bpf_map_update_elem(&netdev_array, &port_num, &ifindex)
> > should work.
> > For bpf_map_lookup_elem() from such netdev_array we can return
> > ifindex back.
> > The bpf_map_show_fdinfo() can be customized as well to pretty print
> > ifindexes of netdevs stored in there.
> >
>
> I agree with both of you on all of these points. Having the port
> redirection in a new type of map and/or array seems like the way to go.
>
> I understood Jesper's perspecitive when thinking about a way to pass a
> port-table id down, but I think the idea that the userspace loader code
> defining the maps is going to be the one making this link is the right
> idea and handling things like ifindex changes (rather than identifiers
> that perform lookups in other tables) is going to have to be yet another
> exercise left up to the...user. :-)
>
I love this idea. Integrating the port table closer with the bpf-maps
infrastructure makes sense. This gives me a place to hook the code into,
instead of (re)inventing a new infrastructure for this port table, and the
interface will be more natural from a bpf-API point of view.
When registering/attaching a XDP/bpf program, we would just send the
file-descriptor for this port-map along (like we do with the bpf_prog
FD). Plus, it own ingress-port number this program is in the port-map.
It is not clear to me, in-which-data-structure on the kernel-side we
store this reference to the port-map and ingress-port. As today we only
have the "raw" struct bpf_prog pointer. I see several options:
1. Create a new xdp_prog struct that contains existing bpf_prog,
a port-map pointer and ingress-port. (IMHO easiest solution)
2. Just create a new pointer to port-map and store it in driver rx-ring
struct (like existing bpf_prog), but this create a race-challenge
replacing (cmpxchg) the program (or perhaps it's not a problem as it
runs under rcu and RTNL-lock).
3. Extend bpf_prog to store this port-map and ingress-port, and have a
fast-way to access it. I assume it will be accessible via
bpf_prog->bpf_prog_aux->used_maps[X] but it will be too slow for XDP.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* RE: [PATCH net] driver/net: Fix possible memleaks when fail to register_netdevice
From: Gao Feng @ 2017-04-27 8:33 UTC (permalink / raw)
To: 'Herbert Xu'
Cc: jiri, davem, kuznet, jmorris, yoshfuji, kaber, steffen.klassert,
netdev, 'Gao Feng'
In-Reply-To: <20170427081559.GA1058@gondor.apana.org.au>
> From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> Sent: Thursday, April 27, 2017 4:16 PM
> On Tue, Apr 25, 2017 at 08:01:50PM +0800, gfree.wind@foxmail.com wrote:
> > From: Gao Feng <fgao@ikuai8.com>
> >
[...]
>
> This has the potential of creating future bugs, because there is no
guarantee
> that the ndo_init function has been invoked at all.
>
> Wouldn't it be safer to move the freeing from the destructors into their
> ndo_uninit functions instead?
I considered about this solution, I am not sure if it is safe to move the
freeing from destructors into ndo_uninit.
Because when the free action is done in ndo_uninit, it is earlier than
destructor.
I am not sure if it break the design of original driver.
I just tested the team driver before. It is ok to free all mems in
ndo_uninit.
Is it possible that anyone are using the net_dev after ndo_uninit ?
If no one, i would like to update the patch.
Could you give me some guide please?
Regards
Feng
>
> Thanks,
> --
^ permalink raw reply
* Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()
From: Johannes Berg @ 2017-04-27 8:22 UTC (permalink / raw)
To: Bjorn Andersson, Eugene Krasnikov, Kalle Valo
Cc: Andy Gross, David Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Nicolas Dechesne
In-Reply-To: <20170426220444.10539-1-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn,
> struct wcn36xx_dxe_ch *ch)
> info = IEEE80211_SKB_CB(ctl->skb);
> if (!(info->flags &
> IEEE80211_TX_CTL_REQ_TX_STATUS)) {
> /* Keep frame until TX status comes
> */
> - ieee80211_free_txskb(wcn->hw, ctl-
> >skb);
> + ieee80211_tx_status(wcn->hw, ctl-
> >skb);
>
I don't think this is a good idea. This code intentionally checked if
TX status was requested, and if not then it doesn't go to the effort of
building it.
As it is with your patch, it'll go and report the TX status without any
TX status information - which is handled in wcn36xx_dxe_tx_ack_ind()
for those frames needing it.
johannes
^ permalink raw reply
* Re: [PATCH net] driver/net: Fix possible memleaks when fail to register_netdevice
From: Herbert Xu @ 2017-04-27 8:15 UTC (permalink / raw)
To: gfree.wind
Cc: jiri, davem, kuznet, jmorris, yoshfuji, kaber, steffen.klassert,
netdev, Gao Feng
In-Reply-To: <1493121710-27910-1-git-send-email-gfree.wind@foxmail.com>
On Tue, Apr 25, 2017 at 08:01:50PM +0800, gfree.wind@foxmail.com wrote:
> From: Gao Feng <fgao@ikuai8.com>
>
> These drivers allocate kinds of resources in init routine, and free
> some resources in the destructor of net_device. It may cause memleak
> when some errors happen after register_netdevice invokes the init
> callback. Because only the uninit callback is invoked in the error
> handler of register_netdevice, but the destructor not. As a result,
> some resources are lost forever.
>
> Now invokes the destructor instead of free_netdev somewhere, and free
> the left resources in the newlink func when fail to register_netdevice.
>
> Signed-off-by: Gao Feng <fgao@ikuai8.com>
This has the potential of creating future bugs, because there
is no guarantee that the ndo_init function has been invoked at
all.
Wouldn't it be safer to move the freeing from the destructors
into their ndo_uninit functions instead?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH net-next] net: bridge: Fix improper taking over HW learned FDB
From: Arkadi Sharshevsky @ 2017-04-27 8:08 UTC (permalink / raw)
To: netdev
Cc: davem, stephen, bridge, Arkadi Sharshevsky, Ido Schimmel,
Nikolay Aleksandrov
Commit 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb
entries") added the ability to "take over an entry which was previously
learned via HW when it shows up from a SW port".
However, if an entry was learned via HW and then a control packet
(e.g., ARP request) was trapped to the CPU, the bridge driver will
update the entry and remove the externally learned flag, although the
entry is still present in HW. Instead, only clear the externally learned
flag in case of roaming.
Fixes: 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb entries")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Arkadi Sharashevsky <arkadis@mellanox.com>
Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/bridge/br_fdb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 5a40a87..ab0c7cc 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -589,14 +589,14 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source,
if (unlikely(source != fdb->dst)) {
fdb->dst = source;
fdb_modified = true;
+ /* Take over HW learned entry */
+ if (unlikely(fdb->added_by_external_learn))
+ fdb->added_by_external_learn = 0;
}
if (now != fdb->updated)
fdb->updated = now;
if (unlikely(added_by_user))
fdb->added_by_user = 1;
- /* Take over HW learned entry */
- if (unlikely(fdb->added_by_external_learn))
- fdb->added_by_external_learn = 0;
if (unlikely(fdb_modified))
fdb_notify(br, fdb, RTM_NEWNEIGH);
}
--
2.4.11
^ permalink raw reply related
* pull-request: can-next 2017-04-25
From: Marc Kleine-Budde @ 2017-04-27 7:54 UTC (permalink / raw)
To: netdev; +Cc: David Miller, kernel@pengutronix.de, linux-can@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 1318 bytes --]
Hello David,
this is a pull request of 1 patch for net-next/master.
This patch by Oliver Hartkopp fixes the build of the broad cast manager
with CONFIG_PROC_FS disabled.
regards,
Marc
---
The following changes since commit b1513c35317c106a1588f3ab32f6888f0e2afd71:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-04-26 22:39:08 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-4.12-20170427
for you to fetch changes up to c2701b370e6b4d0022043691b5ac7adad015e4fc:
can: fix CAN BCM build with CONFIG_PROC_FS disabled (2017-04-27 09:34:13 +0200)
----------------------------------------------------------------
linux-can-next-for-4.12-20170427
----------------------------------------------------------------
Oliver Hartkopp (1):
can: fix CAN BCM build with CONFIG_PROC_FS disabled
net/can/bcm.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] can: fix CAN BCM build with CONFIG_PROC_FS disabled
From: Marc Kleine-Budde @ 2017-04-27 7:52 UTC (permalink / raw)
To: Oliver Hartkopp, linux-can, davem, rdunlap; +Cc: netdev
In-Reply-To: <20170426181434.9635-1-socketcan@hartkopp.net>
[-- Attachment #1.1: Type: text/plain, Size: 1119 bytes --]
On 04/26/2017 08:14 PM, Oliver Hartkopp wrote:
> The introduced namespace support moved the BCM variables for procfs into a
> per-net data structure. This leads to a build failure with disabled procfs:
>
> on x86_64:
>
> when CONFIG_PROC_FS is not enabled:
>
> ../net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'
>
> http://marc.info/?l=linux-can&m=149321842526524&w=2
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied to can-next.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 4/6] bpf: track if the bpf program was loaded with SYS_ADMIN capabilities
From: kbuild test robot @ 2017-04-27 7:27 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: kbuild-all, netdev, ast, daniel, jbenc, aconole
In-Reply-To: <20170426182419.14574-5-hannes@stressinduktion.org>
[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]
Hi Hannes,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Hannes-Frederic-Sowa/bpf-list-all-loaded-ebpf-programs-in-proc-bpf-programs/20170427-090839
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
lib/test_bpf.c: In function 'generate_filter':
>> lib/test_bpf.c:5613:8: error: too few arguments to function 'bpf_prog_alloc'
fp = bpf_prog_alloc(bpf_prog_size(flen), 0);
^~~~~~~~~~~~~~
In file included from lib/test_bpf.c:20:0:
include/linux/filter.h:619:18: note: declared here
struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags,
^~~~~~~~~~~~~~
vim +/bpf_prog_alloc +5613 lib/test_bpf.c
10f18e0b Daniel Borkmann 2014-05-23 5607 *err, fprog.len);
10f18e0b Daniel Borkmann 2014-05-23 5608 return NULL;
64a8946b Alexei Starovoitov 2014-05-08 5609 }
10f18e0b Daniel Borkmann 2014-05-23 5610 break;
10f18e0b Daniel Borkmann 2014-05-23 5611
10f18e0b Daniel Borkmann 2014-05-23 5612 case INTERNAL:
60a3b225 Daniel Borkmann 2014-09-02 @5613 fp = bpf_prog_alloc(bpf_prog_size(flen), 0);
10f18e0b Daniel Borkmann 2014-05-23 5614 if (fp == NULL) {
10f18e0b Daniel Borkmann 2014-05-23 5615 pr_cont("UNEXPECTED_FAIL no memory left\n");
10f18e0b Daniel Borkmann 2014-05-23 5616 *err = -ENOMEM;
:::::: The code at line 5613 was first introduced by commit
:::::: 60a3b2253c413cf601783b070507d7dd6620c954 net: bpf: make eBPF interpreter images read-only
:::::: TO: Daniel Borkmann <dborkman@redhat.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38891 bytes --]
^ permalink raw reply
* Re: [PATCH net] xfrm: do the garbage collection after flushing policy
From: Steffen Klassert @ 2017-04-27 7:27 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Herbert Xu, fw
In-Reply-To: <b55e4ad516bc1be8fe70f68de028a4b32055e43f.1493019219.git.lucien.xin@gmail.com>
On Mon, Apr 24, 2017 at 03:33:39PM +0800, Xin Long wrote:
> Now xfrm garbage collection can be triggered by 'ip xfrm policy del'.
> These is no reason not to do it after flushing policies, especially
> considering that 'garbage collection deferred' is only triggered
> when it reaches gc_thresh.
>
> It's no good that the policy is gone but the xdst still hold there.
> The worse thing is that xdst->route/orig_dst is also hold and can
> not be released even if the orig_dst is already expired.
>
> This patch is to do the garbage collection if there is any policy
> removed in xfrm_policy_flush.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied to the ipsec tree, thanks!
^ permalink raw reply
* Re: [RFC net-next 2/2] bpf: Test for bpf_prog ID and BPF_PROG_GET_NEXT_ID
From: Alexander Alemayhu @ 2017-04-27 7:23 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Daniel Borkmann, Hannes Frederic Sowa, Alexei Starovoitov,
kernel-team
In-Reply-To: <20170427062449.80290-3-kafai@fb.com>
On Wed, Apr 26, 2017 at 11:24:49PM -0700, Martin KaFai Lau wrote:
> Add test to exercise the bpf_prog id generation
> and iteration.
>
Could test_prog_id be a function in tools/testing/selftests/bpf/test_progs.c
instead? bpf_prog_load is already available there.
--
Mit freundlichen Grüßen
Alexander Alemayhu
^ permalink raw reply
* [PATCH net-next v2] net: ipv6: make sure multicast packets are not forwarded beyond the different scopes
From: Donatas Abraitis @ 2017-04-27 7:12 UTC (permalink / raw)
To: davem; +Cc: netdev, stable, donatas.abraitis
RFC4291 2.7 Routers must not forward any multicast packets
beyond of the scope indicated by the scop field in the
destination multicast address.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
---
net/ipv6/ip6_input.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 9ee208a..cbe5eef 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -165,6 +165,14 @@ int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt
IPV6_ADDR_MC_SCOPE(&hdr->daddr) == 0)
goto err;
+ /* RFC4291 2.7
+ * Routers must not forward any multicast packets beyond of the scope
+ * indicated by the scop field in the destination multicast address.
+ */
+ if (ipv6_addr_is_multicast(&hdr->daddr) &&
+ IPV6_ADDR_MC_SCOPE(&hdr->daddr) != IPV6_ADDR_MC_SCOPE(&hdr->saddr))
+ goto err;
+
/*
* RFC4291 2.7
* Multicast addresses must not be used as source addresses in IPv6
--
2.10.0
^ permalink raw reply related
* Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions
From: Christoph Hellwig @ 2017-04-27 6:53 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Christoph Hellwig, linux-kernel, linux-crypto, linux-media,
dri-devel, intel-gfx, linux-raid, linux-mmc, linux-nvdimm,
linux-scsi, open-iscsi, megaraidlinux.pdl, sparmaintainer, devel,
target-devel, netdev, linux-rdma, dm-devel, Martin K. Petersen,
James E.J. Bottomley, Jens Axboe, Greg Kroah-Hartman,
Dan Williams, Ross Zwisler
In-Reply-To: <4736d44e-bbcf-5d59-a1a9-317d0f4da847@deltatee.com>
On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote:
> Ok, well for starters I think you are mistaken about kmap being able to
> fail. I'm having a hard time finding many users of that function that
> bother to check for an error when calling it.
A quick audit of the arch code shows you're right - kmap can't fail
anywhere anymore.
> The main difficulty we
> have now is that neither of those functions are expected to fail and we
> need them to be able to in cases where the page doesn't map to system
> RAM. This patch series is trying to address it for users of scatterlist.
> I'm certainly open to other suggestions.
I think you'll need to follow the existing kmap semantics and never
fail the iomem version either. Otherwise you'll have a special case
that's almost never used that has a different error path.
> There are a fair number of cases in the kernel that do something like:
>
> if (something)
> x = kmap(page);
> else
> x = kmap_atomic(page);
> ...
> if (something)
> kunmap(page)
> else
> kunmap_atomic(x)
>
> Which just seems cumbersome to me.
Passing a different flag based on something isn't really much better.
> In any case, if you can accept an sg_kmap and sg_kmap_atomic api just
> say so and I'll make the change. But I'll still need a flags variable
> for SG_MAP_MUST_NOT_FAIL to support legacy cases that have no fail path
> and both of those functions will need to be pretty nearly replicas of
> each other.
Again, wrong way. Suddenly making things fail for your special case
that normally don't fail is a receipe for bugs.
^ permalink raw reply
* Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it
From: Christoph Hellwig @ 2017-04-27 6:47 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Christoph Hellwig, Byczkowski, Jakub, Bjorn Helgaas,
Cabiddu, Giovanni, Benedetto, Salvatore, Marciniszyn, Mike,
Dalessandro, Dennis, Derek Chickles, Satanand Burla,
Felix Manlunas, Raghu Vatsavayi, Kirsher, Jeffrey T,
linux-pci@vger.kernel.org, qat-linux,
linux-crypto@vger.kernel.org,
"linux-rdma@vger.kernel.org" <l
In-Reply-To: <20170425193955.GC29024@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Apr 25, 2017 at 02:39:55PM -0500, Bjorn Helgaas wrote:
> This still leaves these:
>
> [PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it
> [PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating it
> [PATCH 7/7] liquidio: use pcie_flr instead of duplicating it
>
> I haven't seen any response to 4 and 6. Felix reported an unused
> variable in 7. Let me know if you'd like me to do anything with
> these.
Now that Jeff ACKed 4 it might be worth to add it to the pci tree last
minute. I'll resend liquidio and qat to the respective maintainers for
the next merge window.
^ permalink raw reply
* RE: [iproute2] iplink: add support for IFLA_CARRIER attribute
From: 张胜举 @ 2017-04-27 6:35 UTC (permalink / raw)
To: 'Stephen Hemminger'; +Cc: netdev
In-Reply-To: <20170426080732.51f56b8c@xeon-e3>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, April 26, 2017 11:08 PM
> To: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> Cc: netdev@vger.kernel.org
> Subject: Re: [iproute2] iplink: add support for IFLA_CARRIER attribute
>
> On Wed, 26 Apr 2017 15:08:39 +0800
> Zhang Shengju <zhangshengju@cmss.chinamobile.com> wrote:
>
> > Add support to set IFLA_CARRIER attribute.
> >
> > Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> > ---
> > ip/iplink.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/ip/iplink.c b/ip/iplink.c index 866ad72..263bfdd 100644
> > --- a/ip/iplink.c
> > +++ b/ip/iplink.c
> > @@ -72,6 +72,7 @@ void iplink_usage(void)
> > " [ allmulticast { on | off } ]\n"
> > " [ promisc { on | off } ]\n"
> > " [ trailers { on | off } ]\n"
> > + " [ carrier { on | off } ]\n"
> > " [ txqueuelen PACKETS ]\n"
> > " [ name NEWNAME ]\n"
> > " [ address LLADDR ]\n"
> > @@ -673,6 +674,17 @@ int iplink_parse(int argc, char **argv, struct
> iplink_req *req,
> > req->i.ifi_flags |= IFF_NOARP;
> > else
> > return on_off("arp", *argv);
> > + } else if (strcmp(*argv, "carrier") == 0) {
> > + int carrier;
> > + NEXT_ARG();
> > + if (strcmp(*argv, "on") == 0)
> > + carrier = 1;
> > + else if (strcmp(*argv, "off") == 0)
> > + carrier = 0;
> > + else
> > + return on_off("carrier", *argv);
> > +
> > + addattr8(&req->n, sizeof(*req), IFLA_CARRIER,
> carrier);
> > } else if (strcmp(*argv, "vf") == 0) {
> > struct rtattr *vflist;
> >
>
> The general policy of ip link command is all options should be invertable.
Yes, so I add 'on' and 'off' subcommand to make sure that it can be
invertable.
> There are some VPN's that use this to save and restore state. So if you
add
> an option to set something there should be similar output under the
detailed
> show command.
Currently, "show command" already can display 'carrier' status. Such as:
dummy0: <NO-CARRIER...>
^ permalink raw reply
* Re: [PATCH net-next v8 2/3] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jiri Pirko @ 2017-04-27 6:30 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: davem, xiyou.wangcong, eric.dumazet, netdev, Simon Horman,
Benjamin LaHaise
In-Reply-To: <b32fb2fb-ffb1-aee8-5f1d-1f1e3c82b347@mojatatu.com>
Wed, Apr 26, 2017 at 10:07:08PM CEST, jhs@mojatatu.com wrote:
>On 17-04-26 09:56 AM, Jiri Pirko wrote:
>> Wed, Apr 26, 2017 at 03:14:38PM CEST, jhs@mojatatu.com wrote:
>> > On 17-04-26 08:08 AM, Jiri Pirko wrote:
>
>[..]
>
[...]
>
>> > Again: You are looking at this from a manageability point of view which
>> > is useful but not the only input into a design. If i can squeeze more
>> > data without killing usability - I am all for it. It just doesnt
>> > compute that it is ok to use a flag per attribute because it looks
>> > beautiful.
>>
>> Hmm. Now that I'm thinking about it, why don't we have NLA_FLAGS with
>> couple of helpers around it? It will be obvious what the attr is, all
>> kernel code would use the same helpers. Would be nice.
>>
>
>I think to have flags at that level is useful but it
>is a different hierarchy level. I am not sure the
>"actions dump large messages" is a fit for that level.
Jamal, the idea is to have exactly what you want to have. Only does not
use NLA_U32 attr for that but a special attr NLA_FLAGS which would have
well defined semantics and set of helpers to work with and enforce it.
Then, this could be easily reused in other subsystem that uses netlink
^ 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