* Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO
From: Borislav Petkov @ 2017-12-19 18:44 UTC (permalink / raw)
To: Joe Perches
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Falcon, John Allen, Inaky Perez-Gonzalez, linux-wimax,
James Smart, Dick Kennedy, Zhang Rui, Eduardo Valentin,
Martin Schwidefsky, Heiko Carstens, Thomas Gleixner,
H. Peter Anvin, x86, Dmitry Torokhov, James E.J. Bottomley,
Martin K. Petersen
In-Reply-To: <fa30f1ad73f76dafff816df40cacffe613aa2f48.1513706702.git.joe@perches.com>
On Tue, Dec 19, 2017 at 10:15:09AM -0800, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_WO where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) { s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IWUSR\s*|\s*0200\s*)\)?\s*,\s*NULL\s*,\s*\s_store\s*\)/DEVICE_ATTR_WO(\1)/g; print;}'
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/s390/kernel/smp.c | 2 +-
> arch/x86/kernel/cpu/microcode/core.c | 2 +-
> drivers/input/touchscreen/elants_i2c.c | 2 +-
> drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
> drivers/net/wimax/i2400m/sysfs.c | 3 +--
> drivers/scsi/lpfc/lpfc_attr.c | 3 +--
> drivers/thermal/thermal_sysfs.c | 2 +-
> 7 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
> index b8c1a85bcf2d..a919b2f0141d 100644
> --- a/arch/s390/kernel/smp.c
> +++ b/arch/s390/kernel/smp.c
> @@ -1151,7 +1151,7 @@ static ssize_t __ref rescan_store(struct device *dev,
> rc = smp_rescan_cpus();
> return rc ? rc : count;
> }
> -static DEVICE_ATTR(rescan, 0200, NULL, rescan_store);
> +static DEVICE_ATTR_WO(rescan);
> #endif /* CONFIG_HOTPLUG_CPU */
>
> static int __init s390_smp_init(void)
> diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
> index c4fa4a85d4cb..09c74b0560dd 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -560,7 +560,7 @@ static ssize_t pf_show(struct device *dev,
> return sprintf(buf, "0x%x\n", uci->cpu_sig.pf);
> }
>
> -static DEVICE_ATTR(reload, 0200, NULL, reload_store);
> +static DEVICE_ATTR_WO(reload);
> static DEVICE_ATTR(version, 0400, version_show, NULL);
> static DEVICE_ATTR(processor_flags, 0400, pf_show, NULL);
>
# cat /sys/devices/system/cpu/microcode/reload
cat: /sys/devices/system/cpu/microcode/reload: Permission denied
The reason for the code churn being?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH ethtool v2] ethtool: Support for FEC encoding control
From: John W. Linville @ 2017-12-19 18:39 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, oss-drivers, Dustin Byford, Vidya Sagar Ravipati,
Dirk van der Merwe
In-Reply-To: <20171218225741.23783-1-jakub.kicinski@netronome.com>
Applied, thanks!
On Mon, Dec 18, 2017 at 02:57:41PM -0800, Jakub Kicinski wrote:
> From: Dustin Byford <dustin@cumulusnetworks.com>
>
> As FEC settings and different FEC modes are mandatory
> and configurable across various interfaces of 25G/50G/100G/40G,
> the lack of FEC encoding control and reporting today is a source
> for interoperability issues for many vendors
>
> set-fec/show-fec option(s) are designed to provide control and report
> the FEC encoding on the link.
>
> $ethtool --set-fec swp1 encoding [off | RS | BaseR | auto]
>
> Encoding: Types of encoding
> Off : Turning off FEC
> RS : Force RS-FEC encoding
> BaseR : Force BaseR encoding
> Auto : Default FEC settings for drivers, and would represent
> asking the hardware to essentially go into a best effort mode.
>
> Here are a few examples of what we would expect if encoding=auto:
> - if autoneg is on, we are expecting FEC to be negotiated as on or off
> as long as protocol supports it
> - if the hardware is capable of detecting the FEC encoding on it's
> receiver it will reconfigure its encoder to match
> - in absence of the above, the configuration would be set to IEEE
> defaults.
>
> From our understanding, this is essentially what most hardware/driver
> combinations are doing today in the absence of a way for users to
> control the behavior.
>
> $ethtool --show-fec swp1
> FEC parameters for swp1:
> FEC encodings: RS
>
> ethtool devname output:
> $ethtool swp1
> Settings for swp1:
> root@hpe-7712-03:~# ethtool swp18
> Settings for swp18:
> Supported ports: [ FIBRE ]
> Supported link modes: 40000baseCR4/Full
> 40000baseSR4/Full
> 40000baseLR4/Full
> 100000baseSR4/Full
> 100000baseCR4/Full
> 100000baseLR4_ER4/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Supported FEC modes: [RS | BaseR | None | Not reported]
> Advertised link modes: Not reported
> Advertised pause frame use: No
> Advertised auto-negotiation: No
> Advertised FEC modes: [RS | BaseR | None | Not reported]
> Speed: 100000Mb/s
> Duplex: Full
> Port: FIBRE
> PHYAD: 106
> Transceiver: internal
> Auto-negotiation: off
> Link detected: yes
>
> Signed-off-by: Vidya Sagar Ravipati <vidya.chowdary@gmail.com>
> Signed-off-by: Dustin Byford <dustin@cumulusnetworks.com>
> [code style + man page edits + commit message update]
> Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
> ---
> v2:
> - don't break lines after opening parnes.
>
> ethtool.8.in | 31 ++++++++++++++++
> ethtool.c | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 150 insertions(+)
>
> diff --git a/ethtool.8.in b/ethtool.8.in
> index 7ca8bfe43607..9573ffdc985d 100644
> --- a/ethtool.8.in
> +++ b/ethtool.8.in
> @@ -378,6 +378,13 @@ ethtool \- query or control network driver and hardware settings
> .RB [ ap-shared ]
> .RB [ dedicated ]
> .RB [ all ]
> +.HP
> +.B ethtool \-\-show\-fec
> +.I devname
> +.HP
> +.B ethtool \-\-set\-fec
> +.I devname
> +.B4 encoding auto off rs baser
> .
> .\" Adjust lines (i.e. full justification) and hyphenate.
> .ad
> @@ -1070,6 +1077,30 @@ All components dedicated to this interface
> .B all
> All components used by this interface, even if shared
> .RE
> +.TP
> +.B \-\-show\-fec
> +Queries the specified network device for its support of Forward Error Correction.
> +.TP
> +.B \-\-set\-fec
> +Configures Forward Error Correction for the specified network device.
> +
> +Forward Error Correction modes selected by a user are expected to be persisted
> +after any hotplug events. If a module is swapped that does not support the
> +current FEC mode, the driver or firmware must take the link down
> +administratively and report the problem in the system logs for users to correct.
> +.RS 4
> +.TP
> +.A4 encoding auto off rs baser
> +Sets the FEC encoding for the device.
> +.TS
> +nokeep;
> +lB l.
> +auto Use the driver's default encoding
> +off Turn off FEC
> +RS Force RS-FEC encoding
> +BaseR Force BaseR encoding
> +.TE
> +.RE
> .SH BUGS
> Not supported (in part or whole) on all network drivers.
> .SH AUTHOR
> diff --git a/ethtool.c b/ethtool.c
> index 488f6bfb8378..79c076e42c6e 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -542,6 +542,9 @@ static void init_global_link_mode_masks(void)
> ETHTOOL_LINK_MODE_Pause_BIT,
> ETHTOOL_LINK_MODE_Asym_Pause_BIT,
> ETHTOOL_LINK_MODE_Backplane_BIT,
> + ETHTOOL_LINK_MODE_FEC_NONE_BIT,
> + ETHTOOL_LINK_MODE_FEC_RS_BIT,
> + ETHTOOL_LINK_MODE_FEC_BASER_BIT,
> };
> unsigned int i;
>
> @@ -689,6 +692,7 @@ static void dump_link_caps(const char *prefix, const char *an_prefix,
> };
> int indent;
> int did1, new_line_pend, i;
> + int fecreported = 0;
>
> /* Indent just like the separate functions used to */
> indent = strlen(prefix) + 14;
> @@ -740,6 +744,26 @@ static void dump_link_caps(const char *prefix, const char *an_prefix,
> fprintf(stdout, "Yes\n");
> else
> fprintf(stdout, "No\n");
> +
> + fprintf(stdout, " %s FEC modes:", prefix);
> + if (ethtool_link_mode_test_bit(ETHTOOL_LINK_MODE_FEC_NONE_BIT,
> + mask)) {
> + fprintf(stdout, " None");
> + fecreported = 1;
> + }
> + if (ethtool_link_mode_test_bit(ETHTOOL_LINK_MODE_FEC_BASER_BIT,
> + mask)) {
> + fprintf(stdout, " BaseR");
> + fecreported = 1;
> + }
> + if (ethtool_link_mode_test_bit(ETHTOOL_LINK_MODE_FEC_RS_BIT,
> + mask)) {
> + fprintf(stdout, " RS");
> + fecreported = 1;
> + }
> + if (!fecreported)
> + fprintf(stdout, " Not reported");
> + fprintf(stdout, "\n");
> }
> }
>
> @@ -1562,6 +1586,20 @@ static void dump_eeecmd(struct ethtool_eee *ep)
> dump_link_caps("Link partner advertised EEE", "", link_mode, 1);
> }
>
> +static void dump_fec(u32 fec)
> +{
> + if (fec & ETHTOOL_FEC_NONE)
> + fprintf(stdout, " None");
> + if (fec & ETHTOOL_FEC_AUTO)
> + fprintf(stdout, " Auto");
> + if (fec & ETHTOOL_FEC_OFF)
> + fprintf(stdout, " Off");
> + if (fec & ETHTOOL_FEC_BASER)
> + fprintf(stdout, " BaseR");
> + if (fec & ETHTOOL_FEC_RS)
> + fprintf(stdout, " RS");
> +}
> +
> #define N_SOTS 7
>
> static char *so_timestamping_labels[N_SOTS] = {
> @@ -4812,6 +4850,84 @@ static int do_set_phy_tunable(struct cmd_context *ctx)
> return err;
> }
>
> +static int fecmode_str_to_type(const char *str)
> +{
> + int fecmode = 0;
> +
> + if (!str)
> + return fecmode;
> +
> + if (!strcasecmp(str, "auto"))
> + fecmode |= ETHTOOL_FEC_AUTO;
> + else if (!strcasecmp(str, "off"))
> + fecmode |= ETHTOOL_FEC_OFF;
> + else if (!strcasecmp(str, "rs"))
> + fecmode |= ETHTOOL_FEC_RS;
> + else if (!strcasecmp(str, "baser"))
> + fecmode |= ETHTOOL_FEC_BASER;
> +
> + return fecmode;
> +}
> +
> +static int do_gfec(struct cmd_context *ctx)
> +{
> + struct ethtool_fecparam feccmd = { 0 };
> + int rv;
> +
> + if (ctx->argc != 0)
> + exit_bad_args();
> +
> + feccmd.cmd = ETHTOOL_GFECPARAM;
> + rv = send_ioctl(ctx, &feccmd);
> + if (rv != 0) {
> + perror("Cannot get FEC settings");
> + return rv;
> + }
> +
> + fprintf(stdout, "FEC parameters for %s:\n", ctx->devname);
> + fprintf(stdout, "Configured FEC encodings:");
> + dump_fec(feccmd.fec);
> + fprintf(stdout, "\n");
> +
> + fprintf(stdout, "Active FEC encoding:");
> + dump_fec(feccmd.active_fec);
> + fprintf(stdout, "\n");
> +
> + return 0;
> +}
> +
> +static int do_sfec(struct cmd_context *ctx)
> +{
> + char *fecmode_str = NULL;
> + struct ethtool_fecparam feccmd;
> + struct cmdline_info cmdline_fec[] = {
> + { "encoding", CMDL_STR, &fecmode_str, &feccmd.fec},
> + };
> + int changed;
> + int fecmode;
> + int rv;
> +
> + parse_generic_cmdline(ctx, &changed, cmdline_fec,
> + ARRAY_SIZE(cmdline_fec));
> +
> + if (!fecmode_str)
> + exit_bad_args();
> +
> + fecmode = fecmode_str_to_type(fecmode_str);
> + if (!fecmode)
> + exit_bad_args();
> +
> + feccmd.cmd = ETHTOOL_SFECPARAM;
> + feccmd.fec = fecmode;
> + rv = send_ioctl(ctx, &feccmd);
> + if (rv != 0) {
> + perror("Cannot set FEC settings");
> + return rv;
> + }
> +
> + return 0;
> +}
> +
> #ifndef TEST_ETHTOOL
> int send_ioctl(struct cmd_context *ctx, void *cmd)
> {
> @@ -5000,6 +5116,9 @@ static const struct option {
> " [ ap-shared ]\n"
> " [ dedicated ]\n"
> " [ all ]\n"},
> + { "--show-fec", 1, do_gfec, "Show FEC settings"},
> + { "--set-fec", 1, do_sfec, "Set FEC settings",
> + " [ encoding auto|off|rs|baser ]\n"},
> { "-h|--help", 0, show_usage, "Show this help" },
> { "--version", 0, do_version, "Show version number" },
> {}
> --
> 2.15.1
>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net] ip6_gre: remove the incorrect mtu limit for ipgre tap
From: David Miller @ 2017-12-19 18:46 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, jarod
In-Reply-To: <d12e1156851e58e795044739556d858fe4265f18.1513578309.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 18 Dec 2017 14:25:09 +0800
> The same fix as the patch "ip_gre: remove the incorrect mtu limit for
> ipgre tap" is also needed for ip6_gre.
>
> Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ip6_tunnel: get the min mtu properly in ip6_tnl_xmit
From: David Miller @ 2017-12-19 18:46 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev
In-Reply-To: <5a4b92b4ea3263c25d3faa158ea867a6946808a4.1513578381.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 18 Dec 2017 14:26:21 +0800
> Now it's using IPV6_MIN_MTU as the min mtu in ip6_tnl_xmit, but
> IPV6_MIN_MTU actually only works when the inner packet is ipv6.
>
> With IPV6_MIN_MTU for ipv4 packets, the new pmtu for inner dst
> couldn't be set less than 1280. It would cause tx_err and the
> packet to be dropped when the outer dst pmtu is close to 1280.
>
> Jianlin found it by running ipv4 traffic with the topo:
>
> (client) gre6 <---> eth1 (route) eth2 <---> gre6 (server)
>
> After changing eth2 mtu to 1300, the performance became very
> low, or the connection was even broken. The issue also affects
> ip4ip6 and ip6ip6 tunnels.
>
> So if the inner packet is ipv4, 576 should be considered as the
> min mtu.
>
> Note that for ip4ip6 and ip6ip6 tunnels, the inner packet can
> only be ipv4 or ipv6, but for gre6 tunnel, it may also be ARP.
> This patch using 576 as the min mtu for non-ipv6 packet works
> for all those cases.
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ip_gre: remove the incorrect mtu limit for ipgre tap
From: David Miller @ 2017-12-19 18:46 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, jarod
In-Reply-To: <39491900680cdfcf8b0e7e410ba8aa1ba52e1bd2.1513578275.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 18 Dec 2017 14:24:35 +0800
> ipgre tap driver calls ether_setup(), after commit 61e84623ace3
> ("net: centralize net_device min/max MTU checking"), the range
> of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.
>
> It causes the dev mtu of the ipgre tap device to not be greater
> than 1500, this limit value is not correct for ipgre tap device.
>
> Besides, it's .change_mtu already does the right check. So this
> patch is just to set max_mtu as 0, and leave the check to it's
> .change_mtu.
>
> Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking")
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: David Miller @ 2017-12-19 18:48 UTC (permalink / raw)
To: mw
Cc: linux-kernel, linux-arm-kernel, netdev, linux, rafael.j.wysocki,
andrew, f.fainelli, antoine.tenart, thomas.petazzoni,
gregory.clement, ezequiel.garcia, nadavh, neta, ard.biesheuvel,
jaz, tn
In-Reply-To: <1513588684-15647-1-git-send-email-mw@semihalf.com>
From: Marcin Wojtas <mw@semihalf.com>
Date: Mon, 18 Dec 2017 10:17:56 +0100
> Above support configures 1G to use its PHY normally. 10G can work now
> only with the link interrupt mode. Somehow reading of the
> string property in fwnode_mdiobus_child_is_phy works only with
> DT and cannot cope with 10G PHY nodes as in:
> https://pastebin.com/3JnYpU0A
>
> Above root cause will be further checked. In the meantime I will
> appreciate any comments or remarks for the kernel patches.
I would like you to figure this out before these changes go in.
Thanks.
^ permalink raw reply
* Re: [PATCH net] ipv4: Fix use-after-free when flushing FIB tables
From: Ido Schimmel @ 2017-12-19 18:49 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, Ido Schimmel, Netdev, Duyck, Alexander H,
Fengguang Wu, David Ahern, mlxsw
In-Reply-To: <CAKgT0UfnK9ueT3PtD=HKB2f_XhccoVq6HnnQ=vRgEdtM-WUG2Q@mail.gmail.com>
On Tue, Dec 19, 2017 at 09:34:16AM -0800, Alexander Duyck wrote:
> That seems like unneeded complexity when the issue is just the order
> that these were created in versus the order they are freed in. As long
> as we always destroy the one containing the alias before the one that
> has the actual data we don't need to have a reference count. Basically
> the issue is the bring-up and the tear-down order. It isn't something
> that really needs a reference count since it would always be either 1
> or 2. My preference would be to just add a comment explaining that
> local must always be destroyed before the main trie in order to
> guarantee that there are no external references to the data contained
> in main when it is freed.
>
> The one question I have in all this is if I did the bring-up in the
> right order in the first place. I'm wondering if local should be where
> the combined trie lives instead of main. Local is currently destroyed
> after main anyway so I wonder if it wouldn't have been better if
> everything lived in local since from what I can tell it looks like we
> add rules for local first before we do so in main. The complexity of
> that patch would be higher though since the patch would need to be
> much larger and touch multiple files.
I decided to go with the original patch because it resulted in a very
small diff (patch is needed in -stable as well), but I agree with Dave
about it not being explicit enough.
How about I'll send v2 with a comment and then we can try Alex's
suggestion in net-next?
Thanks
^ permalink raw reply
* Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO
From: Joe Perches @ 2017-12-19 18:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Falcon, John Allen, Inaky Perez-Gonzalez, linux-wimax,
James Smart, Dick Kennedy, Zhang Rui, Eduardo Valentin,
Martin Schwidefsky, Heiko Carstens, Thomas Gleixner,
H. Peter Anvin, x86, Dmitry Torokhov, James E.J. Bottomley,
Martin K. Petersen
In-Reply-To: <20171219184441.ixxh757tl44qvk5l@pd.tnic>
On Tue, 2017-12-19 at 19:44 +0100, Borislav Petkov wrote:
> On Tue, Dec 19, 2017 at 10:15:09AM -0800, Joe Perches wrote:
> > Convert DEVICE_ATTR uses to DEVICE_ATTR_WO where possible.
> >
> > Done with perl script:
> >
> > $ git grep -w --name-only DEVICE_ATTR | \
> > xargs perl -i -e 'local $/; while (<>) { s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IWUSR\s*|\s*0200\s*)\)?\s*,\s*NULL\s*,\s*\s_store\s*\)/DEVICE_ATTR_WO(\1)/g; print;}'
[]
> > diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
[]
> > @@ -560,7 +560,7 @@ static ssize_t pf_show(struct device *dev,
> > return sprintf(buf, "0x%x\n", uci->cpu_sig.pf);
> > }
> >
> > -static DEVICE_ATTR(reload, 0200, NULL, reload_store);
> > +static DEVICE_ATTR_WO(reload);
> > static DEVICE_ATTR(version, 0400, version_show, NULL);
> > static DEVICE_ATTR(processor_flags, 0400, pf_show, NULL);
> >
>
> # cat /sys/devices/system/cpu/microcode/reload
> cat: /sys/devices/system/cpu/microcode/reload: Permission denied
Not different behavior. It was and remains write only.
> The reason for the code churn being?
Consistency for easier grep by use-type.
^ permalink raw reply
* Re: [PATCH] net: ks8851: Support DT-provided MAC address
From: David Miller @ 2017-12-19 18:52 UTC (permalink / raw)
To: lukas; +Cc: ben, tristram.ha, david.choi, m.duckeck, netdev
In-Reply-To: <68ae82c3cac7b6e4123fa31140805f7fab93af06.1513591121.git.lukas@wunner.de>
From: Lukas Wunner <lukas@wunner.de>
Date: Mon, 18 Dec 2017 11:17:07 +0100
> Allow the boot loader to specify the MAC address in the device tree
> to override the EEPROM, or in case no EEPROM is present.
>
> Cc: Ben Dooks <ben@simtec.co.uk>
> Cc: Tristram Ha <tristram.ha@micrel.com>
> Cc: David J. Choi <david.choi@micrel.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
Applied to net-next, thank you.
^ permalink raw reply
* Re: pull request: bluetooth-next 2017-12-18
From: David Miller @ 2017-12-19 18:53 UTC (permalink / raw)
To: johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171218102721.GA17768@x1c>
From: Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 18 Dec 2017 11:27:21 +0100
> Here's the first bluetooth-next pull request for the 4.16 kernel.
>
> - hci_ll: multiple cleanups & fixes
> - Remove Gustavo Padovan from the MAINTAINERS file
> - Support BLE Adversing while connected (if the controller can do it)
> - DT updates for TI chips
> - Various other smaller cleanups & fixes
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO
From: Borislav Petkov @ 2017-12-19 18:54 UTC (permalink / raw)
To: Joe Perches
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Falcon, John Allen, Inaky Perez-Gonzalez, linux-wimax,
James Smart, Dick Kennedy, Zhang Rui, Eduardo Valentin,
Martin Schwidefsky, Heiko Carstens, Thomas Gleixner,
H. Peter Anvin, x86, Dmitry Torokhov, James E.J. Bottomley,
Martin K. Petersen
In-Reply-To: <1513709474.1234.66.camel@perches.com>
On Tue, Dec 19, 2017 at 10:51:14AM -0800, Joe Perches wrote:
> > The reason for the code churn being?
>
> Consistency for easier grep by use-type.
Please explain that in the commit message so that we know why it was
changed.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_<foo>
From: Jani Nikula @ 2017-12-19 18:54 UTC (permalink / raw)
To: Joe Perches, linux-arm-kernel, linux-acpi, openipmi-developer,
intel-gfx, linuxppc-dev, netdev, linux-nvme, platform-driver-x86,
linux-s390, esc.storagedev, linux-scsi, linux-pm, linux-serial,
linux-usb, linux-kernel, alsa-devel, linux-omap
Cc: devel, linux-fbdev, linux-sh, dri-devel, linux-input, linux-media
In-Reply-To: <cover.1513706701.git.joe@perches.com>
On Tue, 19 Dec 2017, Joe Perches <joe@perches.com> wrote:
> drivers/gpu/drm/i915/i915_sysfs.c | 12 ++--
For i915,
Acked-by: Jani Nikula <jani.nikula@intel.com>
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Report tid start range correctly for T6
From: David Miller @ 2017-12-19 18:54 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, arjun
In-Reply-To: <1513606522-5245-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Mon, 18 Dec 2017 19:45:22 +0530
> For T6, tid start range should be read from
> LE_DB_ACTIVE_TABLE_START_INDEX_A register.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* [PATCH net] openvswitch: Fix pop_vlan action for double tagged frames
From: Eric Garver @ 2017-12-19 18:57 UTC (permalink / raw)
To: netdev; +Cc: Jiri Benc, ovs-dev
skb_vlan_pop() expects skb->protocol to be a valid TPID for double
tagged frames. As such don't override skb->protocol for normal ethernet
frames when extracting the key.
Fixes: 5108bbaddc37 ("openvswitch: add processing of L3 packets")
Signed-off-by: Eric Garver <e@erig.me>
---
net/openvswitch/flow.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index dbe2379329c5..06d32ba3dd69 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -559,8 +559,9 @@ static int parse_nsh(struct sk_buff *skb, struct sw_flow_key *key)
* of a correct length, otherwise the same as skb->network_header.
* For other key->eth.type values it is left untouched.
*
- * - skb->protocol: the type of the data starting at skb->network_header.
- * Equals to key->eth.type.
+ * - skb->protocol: For Ethernet, the ethertype or VLAN TPID.
+ * For non-Ethernet, the type of the data starting at skb->network_header
+ * (also equal to key->eth.type).
*/
static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
{
@@ -579,6 +580,7 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
return -EINVAL;
skb_reset_network_header(skb);
+ key->eth.type = skb->protocol;
} else {
eth = eth_hdr(skb);
ether_addr_copy(key->eth.src, eth->h_source);
@@ -592,15 +594,14 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
if (unlikely(parse_vlan(skb, key)))
return -ENOMEM;
- skb->protocol = parse_ethertype(skb);
- if (unlikely(skb->protocol == htons(0)))
+ key->eth.type = parse_ethertype(skb);
+ if (unlikely(key->eth.type == htons(0)))
return -ENOMEM;
skb_reset_network_header(skb);
__skb_push(skb, skb->data - skb_mac_header(skb));
}
skb_reset_mac_len(skb);
- key->eth.type = skb->protocol;
/* Network layer. */
if (key->eth.type == htons(ETH_P_IP)) {
--
2.12.0
^ permalink raw reply related
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2017-12-19 18:59 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, linux-arm-kernel, netdev, Russell King - ARM Linux,
Rafael J. Wysocki, Andrew Lunn, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory Clément,
Ezequiel Garcia, nadavh, Neta Zur Hershkovits, Ard Biesheuvel,
Grzegorz Jaszczyk, Tomasz Nowicki
In-Reply-To: <20171219.134810.48027351795338458.davem@davemloft.net>
Hi David,
2017-12-19 19:48 GMT+01:00 David Miller <davem@davemloft.net>:
> From: Marcin Wojtas <mw@semihalf.com>
> Date: Mon, 18 Dec 2017 10:17:56 +0100
>
>> Above support configures 1G to use its PHY normally. 10G can work now
>> only with the link interrupt mode. Somehow reading of the
>> string property in fwnode_mdiobus_child_is_phy works only with
>> DT and cannot cope with 10G PHY nodes as in:
>> https://pastebin.com/3JnYpU0A
>>
>> Above root cause will be further checked. In the meantime I will
>> appreciate any comments or remarks for the kernel patches.
>
> I would like you to figure this out before these changes go in.
>
Of course! v2 will not have such problem, I've been waiting however
for the feedback about the ACPI representation. Anyway, I'm strongly
leaning towards using _ADR/_CID objects in PHY's nodes for ACPI, so
maybe I'll just issue the v2 in order to push the discussion a bit
forward.
Thanks,
Marcin
^ permalink raw reply
* Re: [PATCH net] ipv4: Fix use-after-free when flushing FIB tables
From: David Miller @ 2017-12-19 19:01 UTC (permalink / raw)
To: idosch
Cc: alexander.duyck, idosch, netdev, alexander.h.duyck, fengguang.wu,
dsahern, mlxsw
In-Reply-To: <20171219184913.GA18980@splinter>
From: Ido Schimmel <idosch@idosch.org>
Date: Tue, 19 Dec 2017 20:49:13 +0200
> How about I'll send v2 with a comment and then we can try Alex's
> suggestion in net-next?
Sounds good.
^ permalink raw reply
* Re: [PATCH net-next v5 0/5] Introduce NETIF_F_GRO_HW
From: Marcelo Ricardo Leitner @ 2017-12-19 19:04 UTC (permalink / raw)
To: David Miller; +Cc: michael.chan, netdev, andrew.gospodarek
In-Reply-To: <20171219.105024.1047087594002892419.davem@davemloft.net>
On Tue, Dec 19, 2017 at 10:50:24AM -0500, David Miller wrote:
> From: Michael Chan <michael.chan@broadcom.com>
> Date: Sat, 16 Dec 2017 03:09:39 -0500
>
> > Introduce NETIF_F_GRO_HW feature flag and convert drivers that support
> > hardware GRO to use the new flag.
>
> Series applied, thanks for following through with this work.
Can we clarify on the meaning/expectations of dev_weight? The
documentation currently says:
The maximum number of packets that kernel can handle on a NAPI
interrupt, it's a Per-CPU variable.
I believe 'packets' here refers to packets on the wire.
For drivers doing LRO, we don't have visibility on how many
packets were aggregated so they count as 1, aggregated or not.
But for GRO_HW, drivers implementing it will get a bonus on its
dev_weight because instead of pulling 5 packets in a cycle to create 1
gro'ed skb, it will pull 1 big packet (which includes 5) and count it
as 1.
I understand that for all that matters, the hardware operations
involved on GRO_HW are really for only 1 packet, so it would make
sense to count it as 1. OTOH, this bump may cause additional pressure
in other places as in fact we are allowing more packets in in a given
cycle.
At least qede driver is counting 1 GRO_HW pkt as 1 budget.
Thanks,
Marcelo
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2017-12-18
From: David Miller @ 2017-12-19 19:06 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
luciano.coelho-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <874looktmz.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
From: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Date: Mon, 18 Dec 2017 16:17:24 +0200
> a pull request for 4.16 to net-next tree. This is a big one, but on the
> other hand most of the stuff here has been some time on linux-next so
> hopefully there are no nasty surprises. Even though Arnd just send a
> patch[1] five minutes ago about fixing a wcn36xx build warning, but I
> don't think that's critical enough to hold up this, so I'll send it to
> you in the next pull request.
>
> But this time we actually have a merge conflict due to a000 hardware
> rename in iwlwifi:
>
> CONFLICT (content): Merge conflict in drivers/net/wireless/intel/iwlwifi/pcie/drv.c
>
> The fix is quite straightforward, take the 22000 versions and manually
> add an entry for 0xA0F0 device:
>
> {IWL_PCI_DEVICE(0xA0F0, 0x0000, iwl22000_2ax_cfg_hr)},
>
> I put the 'git diff' output of my test resolution below, hopefully it
> helps. I'll also Cc Luca so he can correct any mistakes I did :)
>
> Please let me know if you have any problems.
Pulled, and thanks for the resolution diff. It helped a lot.
^ permalink raw reply
* Re: [PATCH 0/2 net-next] ibmvnic: Fix and increase maximum TX/RX queues
From: David Miller @ 2017-12-19 19:08 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1513623132-16554-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Mon, 18 Dec 2017 12:52:10 -0600
> This series renames IBMVNIC_MAX_TX_QUEUES to IBMVNIC_MAX_QUEUES since
> it is used to allocate both RX and TX queues. The value is also increased
> to accommodate newer hardware.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] ibmvnic: Include header descriptor support for ARP packets
From: David Miller @ 2017-12-19 19:10 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1513623160-16621-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Mon, 18 Dec 2017 12:52:40 -0600
> In recent tests with new adapters, it was discovered that ARP
> packets were not being properly processed. This patch adds
> support for ARP packet headers to be passed to backing adapters,
> if necessary.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [net 1/1] tipc: fix list sorting bug in function tipc_group_update_member()
From: David Miller @ 2017-12-19 19:10 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1513623785-26566-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 18 Dec 2017 20:03:05 +0100
> When, during a join operation, or during message transmission, a group
> member needs to be added to the group's 'congested' list, we sort it
> into the list in ascending order, according to its current advertised
> window size. However, we miss the case when the member is already on
> that list. This will have the result that the member, after the window
> size has been decremented, might be at the wrong position in that list.
> This again may have the effect that we during broadcast and multicast
> transmissions miss the fact that a destination is not yet ready for
> reception, and we end up sending anyway. From this point on, the
> behavior during the remaining session is unpredictable, e.g., with
> underflowing window sizes.
>
> We now correct this bug by unconditionally removing the member from
> the list before (re-)sorting it in.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
* Re: [PATCH v3 net-next 3/6] net: Add SW fallback infrastructure for offloaded sockets
From: Eric Dumazet @ 2017-12-19 19:12 UTC (permalink / raw)
To: Ilya Lesokhin, netdev, davem
Cc: davejwatson, tom, hannes, borisp, aviadye, liranl
In-Reply-To: <20171218111033.13256-4-ilyal@mellanox.com>
On Mon, 2017-12-18 at 13:10 +0200, Ilya Lesokhin wrote:
> Offloaded sockets rely on the netdev to transform the transmitted
> packets before sending them over the network.
> When a packet from an offloaded socket is looped back or
> rerouted to a different device we need to detect it and
> do the transformation in software
>
> Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
> Signed-off-by: Boris Pismenny <borisp@mellanox.com>
> ---
> include/net/sock.h | 17 +++++++++++++++++
> net/core/dev.c | 4 ++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 9a9047268d37..5397307603ec 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -479,6 +479,9 @@ struct sock {
> void (*sk_error_report)(struct sock *sk);
> int (*sk_backlog_rcv)(struct sock *sk,
> struct sk_buff *skb);
> + struct sk_buff* (*sk_offload_check)(struct sock *sk,
> + struct net_device *dev,
> + struct sk_buff *skb);
> void (*sk_destruct)(struct sock *sk);
> struct sock_reuseport __rcu *sk_reuseport_cb;
> struct rcu_head sk_rcu;
> @@ -2324,6 +2327,20 @@ static inline bool sk_fullsock(const struct sock *sk)
> return (1 << sk->sk_state) & ~(TCPF_TIME_WAIT | TCPF_NEW_SYN_RECV);
> }
>
> +/* Checks if this SKB belongs to an HW offloaded socket
> + * and whether any SW fallbacks are required based on dev.
> + */
> +static inline struct sk_buff *skb_offload_check(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct sock *sk = skb->sk;
> +
> + if (sk && sk_fullsock(sk) && sk->sk_offload_check)
> + skb = sk->sk_offload_check(sk, dev, skb);
> +
> + return skb;
> +}
> +
> /* This helper checks if a socket is a LISTEN or NEW_SYN_RECV
> * SYNACK messages can be attached to either ones (depending on SYNCOOKIE)
> */
> diff --git a/net/core/dev.c b/net/core/dev.c
> index b0eee49a2489..6a78d9046674 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3051,6 +3051,10 @@ static struct sk_buff *validate_xmit_skb(struct sk_buff *skb, struct net_device
> if (unlikely(!skb))
> goto out_null;
>
> + skb = skb_offload_check(skb, dev);
> + if (!skb)
> + goto out_null;
> +
> if (netif_needs_gso(skb, features)) {
> struct sk_buff *segs;
>
How is it going to work with stacked devices (bonding, team, tunnels) ?
^ permalink raw reply
* Re: [PATCH 1/2] net: stmmac: Fix TX timestamp calculation
From: David Miller @ 2017-12-19 19:12 UTC (permalink / raw)
To: megahallon
Cc: netdev, linux-kernel, Jose.Abreu, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <20171218223400.29644-1-megahallon@gmail.com>
From: Fredrik Hallenberg <megahallon@gmail.com>
Date: Mon, 18 Dec 2017 23:33:59 +0100
> When using GMAC4 the value written in PTP_SSIR should be shifted however
> the shifted value is also used in subsequent calculations which results
> in a bad timestamp value.
>
> Signed-off-by: Fredrik Hallenberg <megahallon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: stmmac: Fix bad RX timestamp extraction
From: David Miller @ 2017-12-19 19:12 UTC (permalink / raw)
To: megahallon
Cc: netdev, linux-kernel, Jose.Abreu, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <20171218223400.29644-2-megahallon@gmail.com>
From: Fredrik Hallenberg <megahallon@gmail.com>
Date: Mon, 18 Dec 2017 23:34:00 +0100
> As noted in dwmac4_wrback_get_rx_timestamp_status the timestamp is found
> in the context descriptor following the current descriptor. However the
> current code looks for the context descriptor in the current
> descriptor, which will always fail.
>
> Signed-off-by: Fredrik Hallenberg <megahallon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 1/6] tcp: Add clean acked data hook
From: Eric Dumazet @ 2017-12-19 19:13 UTC (permalink / raw)
To: Ilya Lesokhin, netdev, davem
Cc: davejwatson, tom, hannes, borisp, aviadye, liranl
In-Reply-To: <20171218111033.13256-2-ilyal@mellanox.com>
On Mon, 2017-12-18 at 13:10 +0200, Ilya Lesokhin wrote:
> Called when a TCP segment is acknowledged.
> Could be used by application protocols who hold additional
> metadata associated with the stream data
> This is required by TLS device offload to release
> metadata associated with acknowledged TLS records.
>
> Signed-off-by: Boris Pismenny <borisp@mellanox.com>
> Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
> Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com>
> ---
> include/net/inet_connection_sock.h | 2 ++
> net/ipv4/tcp_input.c | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
> index 8e1bf9ae4a5e..ec405a667a85 100644
> --- a/include/net/inet_connection_sock.h
> +++ b/include/net/inet_connection_sock.h
> @@ -77,6 +77,7 @@ struct inet_connection_sock_af_ops {
> * @icsk_af_ops Operations which are AF_INET{4,6} specific
> * @icsk_ulp_ops Pluggable ULP control hook
> * @icsk_ulp_data ULP private data
> + * @icsk_clean_acked Clean acked data hook
> * @icsk_listen_portaddr_node hash to the portaddr listener hashtable
> * @icsk_ca_state: Congestion control state
> * @icsk_retransmits: Number of unrecovered [RTO] timeouts
> @@ -102,6 +103,7 @@ struct inet_connection_sock {
> const struct inet_connection_sock_af_ops *icsk_af_ops;
> const struct tcp_ulp_ops *icsk_ulp_ops;
> void *icsk_ulp_data;
> + void (*icsk_clean_acked)(struct sock *sk);
> struct hlist_node icsk_listen_portaddr_node;
> unsigned int (*icsk_sync_mss)(struct sock *sk, u32 pmtu);
> __u8 icsk_ca_state:6,
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 4d55c4b338ee..961abc5be84c 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -3592,6 +3592,9 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
> if (!prior_packets)
> goto no_queue;
>
> + if (icsk->icsk_clean_acked)
> + icsk->icsk_clean_acked(sk);
> +
> /* See if we can take anything off of the retransmit queue. */
> flag |= tcp_clean_rtx_queue(sk, prior_fack, prior_snd_una, &sack_state);
>
1) tcp_ack() is already very expensive.
2) Since you do not pass any state here, this looks very suspicious to
me.
^ 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