* Re: [PATCH net-next V2 1/9] liquidio CN23XX: HW config for VF support
From: David Miller @ 2016-10-20 18:13 UTC (permalink / raw)
To: rvatsavayi
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
felix.manlunas
In-Reply-To: <1476942046-18789-2-git-send-email-rvatsavayi@caviumnetworks.com>
From: Raghu Vatsavayi <rvatsavayi@caviumnetworks.com>
Date: Wed, 19 Oct 2016 22:40:38 -0700
> +/* Default behaviour of Liquidio is to provide one queue per VF. But Liquidio
> + * can also provide multiple queues to each VF. If user wants to change the
> + * default behaviour HW should be provided configuration info at init time,
> + * based on which it will create control queues for communicating with FW.
> + */
> +static u32 max_vfs[2] = { 0, 0 };
> +module_param_array(max_vfs, int, NULL, 0444);
> +MODULE_PARM_DESC(max_vfs, "Assign two comma-separated unsigned integers that specify max number of VFs for PF0 (left of the comma) and PF1 (right of the comma); for 23xx only. By default HW will configure as many VFs as queues after allocating PF queues.To increase queues for VF use this parameter. Use sysfs to create these VFs.");
> +
> +static unsigned int num_queues_per_pf[2] = { 0, 0 };
> +module_param_array(num_queues_per_pf, uint, NULL, 0444);
> +MODULE_PARM_DESC(num_queues_per_pf, "two comma-separated unsigned integers that specify number of queues per PF0 (left of the comma) and PF1 (right of the comma); for 23xx only");
> +
> static int ptp_enable = 1;
We cannot continue to allow drivers to add custom module parameters to
control this. It is the worst user experience possible.
We need a tree-wide generic, consistent, manner in which to configure
and control this kind of thing.
^ permalink raw reply
* Re: [PATCH] net: fec: drop check for clk==NULL before calling clk_*
From: David Miller @ 2016-10-20 18:20 UTC (permalink / raw)
To: u.kleine-koenig; +Cc: fugang.duan, kernel, netdev
In-Reply-To: <20161020082827.598-1-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu, 20 Oct 2016 10:28:27 +0200
> clk_prepare, clk_enable and their counterparts (at least the common clk
> ones, but also most others) do check for the clk being NULL anyhow (and
> return 0 then), so there is no gain when the caller checks, too.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] netfilter: don't permit unprivileged writes to global state via sysctls
From: Pablo Neira Ayuso @ 2016-10-20 18:22 UTC (permalink / raw)
To: Jann Horn
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, netdev, netfilter-devel
In-Reply-To: <1474669264-3283-1-git-send-email-jann@thejh.net>
On Sat, Sep 24, 2016 at 12:21:04AM +0200, Jann Horn wrote:
> This prevents the modification of nf_conntrack_max in unprivileged network
> namespaces. For unprivileged network namespaces, ip_conntrack_max is kept
> as a readonly sysctl in order to minimize potential compatibility issues.
>
> This patch should apply cleanly to the net tree.
For the record: This patch looks good to me, but this legacy
ip_conntrack sysctl code is now gone.
I don't know what is the procedure to get this to -stable branches now
that this cannot be pushed upstream.
> Signed-off-by: Jann Horn <jann@thejh.net>
> ---
> net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
> index ae1a71a..a639e94 100644
> --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
> +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
> @@ -358,6 +358,9 @@ static int ipv4_init_net(struct net *net)
> if (!in->ctl_table)
> return -ENOMEM;
>
> + if (net->user_ns != &init_user_ns)
> + in->ctl_table[0].mode = 0444;
> +
> in->ctl_table[0].data = &nf_conntrack_max;
> in->ctl_table[1].data = &net->ct.count;
> in->ctl_table[2].data = &nf_conntrack_htable_size;
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH net-next v2 3/9] net: use core MTU range checking in wireless drivers
From: Johannes Berg @ 2016-10-20 18:22 UTC (permalink / raw)
To: Jarod Wilson, linux-kernel
Cc: netdev, linux-wireless, Maya Erez, Simon Kelley,
Stanislav Yakovlev, Inaky Perez-Gonzalez
In-Reply-To: <20161020175524.6184-4-jarod@redhat.com>
On Thu, 2016-10-20 at 13:55 -0400, Jarod Wilson wrote:
> - set max_mtu in wil6210 driver
> - set max_mtu in atmel driver
> - set min/max_mtu in cisco airo driver, remove airo_change_mtu
> - set min/max_mtu in ipw2100/ipw2200 drivers, remove
> libipw_change_mtu
> - set min/max_mtu in p80211netdev, remove wlan_change_mtu
> - set min/max_mtu in net/mac80211/iface.c and remove ieee80211_change_mtu
For the mac80211 part,
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Dave, I'm assuming you'll pick this up, but if you prefer not to I can
also coordinate with Kalle to take this through our trees.
johannes
^ permalink raw reply
* Re: [PATCH net-next] net: phy: aquantia: add PHY ID of AQR106 and AQR107
From: David Miller @ 2016-10-20 18:25 UTC (permalink / raw)
To: shh.xie; +Cc: netdev, f.fainelli, Shaohui.Xie
In-Reply-To: <1476952231-39131-1-git-send-email-shh.xie@gmail.com>
From: <shh.xie@gmail.com>
Date: Thu, 20 Oct 2016 16:30:31 +0800
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
>
> The AQR106 and AQR107 can use the existing driver.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bnx2x: Replace semaphore stats_lock with mutex
From: David Miller @ 2016-10-20 18:27 UTC (permalink / raw)
To: binoy.jayan; +Cc: ariel.elior, arnd, netdev, linux-kernel
In-Reply-To: <1476953532-2019-1-git-send-email-binoy.jayan@linaro.org>
From: Binoy Jayan <binoy.jayan@linaro.org>
Date: Thu, 20 Oct 2016 14:22:12 +0530
> stats_lock is used as a simple mutex
No, it is not.
> @@ -1976,8 +1973,8 @@ int bnx2x_stats_safe_exec(struct bnx2x *bp,
> /* Wait for statistics to end [while blocking further requests],
> * then run supplied function 'safely'.
> */
> - rc = down_timeout(&bp->stats_lock, HZ / 10);
> - if (unlikely(rc)) {
> + rc = mutex_trylock(&bp->stats_lock);
> + if (unlikely(!rc)) {
It uses timeouts therefore this conversion is not 1 to 1.
You're losing functionality and potentially adding a regression.
^ permalink raw reply
* Re: [PATCH 1/4] kconfig: introduce the "imply" keyword
From: Nicolas Pitre @ 2016-10-20 18:29 UTC (permalink / raw)
To: Edward Cree
Cc: John Stultz, Richard Cochran, Yann E MORIN, Thomas Gleixner,
Josh Triplett, netdev, linux-kbuild, linux-kernel
In-Reply-To: <fea29738-142d-0cb8-da85-cf376d1158e7@solarflare.com>
On Thu, 20 Oct 2016, Edward Cree wrote:
> On 20/10/16 18:04, Nicolas Pitre wrote:
> > On Thu, 20 Oct 2016, Edward Cree wrote:
> >> Also, I don't think having any FOO=y should preclude BAZ=m. Suppose both
> >> FOO and FOO2 imply BAZ, FOO=y and FOO2=m.
> > Some people didn't like the fact that you could turn a driver from m to
> > y and silently lose some features if they were provided by a subsystem
> > that also used to be m, which arguably is not the same as being
> > explicitly disabled. With "select" this is not a problem as the target
> > symbol is also promoted to y in that case, so I wanted to preserve that
> > property.
> Right, but that's an argument for pushing the subsystem's default to y,
> not for preventing changing the subsystem back to m afterwards.
> >> Then if BAZ-features are only
> >> desired for driver FOO2, BAz=m makes sense.
> > In that case it would make more sense to add a config option related to
> > FOO asking if BAZ features are desired for that driver (there is already
> > one occurrence of that with PTP). Or you could simply drop the "imply"
> > statement from the FOO config entry.
> But the desire is a property of the user, not of the driver. If you're
> willing to add CONFIG_FOO_BAZ to every combination of (driver, subsystem)
> then "imply" becomes unnecessary, doesn't it?
Absolutely. And if that's something that inspires you please be my
guest. So far, though, this apparently didn't inspire the majority of
driver authors who preferred to have a smaller set of config options and
forcefully pull in the BAZ features with a "select". But "select" comes
with its set of evils which "imply" is meant to overcome.
> Conversely, if you *don't*
> want to have to do that, then "imply" needs to only ever deal in defaults,
> not in limitations.
As I explained, It still has to prevent BAZ=m if FOO moves from m to y
otherwise this would effectively have the same result as BAZ=n in
practice and that is not what people expect if BAZ actually isn't n in
your .config file. That's why "select" also has that particular
semantic.
Here "imply" is meant to be a weaker form of "select". If you prefer
not to have that limitation imposed by either "select" and "imply" then
simply don't use them at all. Nothing forces you to use any of them if
your code can cope with any config combination.
In those cases where "imply" is used, you could drop it altogether
already. But that's for driver authors to decide. If they went with
"select" in the first place, there might be a reason, and "imply" is
there to preserve that reason, semantically at least, without the
handcuff effect that "select" imposes on the whole thing.
> >> There is also the case of drivers with the ability to detect at runtime
> >> whether BAZ is present, rather than making the decision at build time, but
> >> I'm not sure how common that is.
> > Right now that's how PTP support is done. Drivers can optimize things
> > at build time, but most of them simply cope with a NULL return from
> > ptp_clock_register(). Hence the imply statement becomes a big
> > configuration hint rather than some hard build dependency.
> Right, so those drivers can use PTP if they're y and PTP is m, as long
> as the PTP module is loaded when they probe.
Not at the moment. There is no way for PTP to dynamically signal to
interested drivers its presence at run time. And drivers, when
built-in, typically probe their hardware during the boot process even
before you have the chance to load any module. If that ever changes,
then the imply or select statement could simply be dropped.
> But current "imply" semantics won't allow that...
And that's on purpose.
> I think that Josh's suggestion (have the UI warn you if you set BAZ to m
> while FOO=y) is the right approach, but I also think it should be done
> now rather than at some unspecified future time.
Please advocate this with kconfig UI authors. My recursion stack is
already quite deep.
> Otherwise you forbid
> potentially valid configs.
Like I said, if FOO=y and BAZ=m is a valid config, all you have to do is
omit "imply BAZ" or "select BAZ" from the FOO config entry. It's as
simple as that.
Nicolas
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Cong Wang @ 2016-10-20 18:29 UTC (permalink / raw)
To: Stephen Smalley
Cc: Linux Kernel Network Developers, Elad Raz, Paul Moore,
Richard Guy Briggs
In-Reply-To: <2707c52d-88ec-7b93-f96e-eeaffc952c9c@tycho.nsa.gov>
On Thu, Oct 20, 2016 at 7:58 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/20/2016 02:52 AM, Cong Wang wrote:
>> A kernel warning inside __local_bh_enable_ip() was reported by people
>> running SELinux, this is caused due to some SELinux functions
>> (indirectly) call peernet2id() with IRQ disabled in process context,
>> when we re-enable BH with IRQ disabled kernel complains. Shut up this
>> warning by saving IRQ context in peernet2id(), BH is still implicitly
>> disabled.
>
> Not sure this suffices; kill_fasync() -> send_sigio() ->
> send_sigio_to_task() -> sigio_perm() -> security_file_send_sigiotask()
> -> selinux_file_send_sigiotask() -> ... -> audit_log() -> ... ->
> peernet2id()
Oh, this is a new one. kill_fasync() is called in IRQ handler, so we actually
do multicast in IRQ context.... It makes no sense, netlink multicast could
be very expensive if we have many listeners.
I am Cc'ing Richard who added that multicast in audit_log_end(). It seems
not easy to just move the multicast to a workqueue, since the skb is copied
from audit_buffer which is freed immediately after that, probably need another
queue like audit_skb_queue.
^ permalink raw reply
* Re: [PATCH] ipv6: properly prevent temp_prefered_lft sysctl race
From: David Miller @ 2016-10-20 18:29 UTC (permalink / raw)
To: jbohac; +Cc: julia.lawall, kuznet, jmorris, yoshfuji, kaber, netdev,
kbuild-all
In-Reply-To: <20161020102926.ysgqdjghmvc573s4@dwarf.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Thu, 20 Oct 2016 12:29:26 +0200
> The check for an underflow of tmp_prefered_lft is always false
> because tmp_prefered_lft is unsigned. The intention of the check
> was to guard against racing with an update of the
> temp_prefered_lft sysctl, potentially resulting in an underflow.
>
> As suggested by David Miller, the best way to prevent the race is
> by reading the sysctl variable using READ_ONCE.
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
> Reported-by: Julia Lawall <julia.lawall@lip6.fr>
> Fixes: 76506a986dc3 ("IPv6: fix DESYNC_FACTOR")
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net v3] net: add recursion limit to GRO
From: David Miller @ 2016-10-20 18:32 UTC (permalink / raw)
To: sd; +Cc: netdev, eric.dumazet, tom, jbenc, hannes
In-Reply-To: <7429d1a2eaceec5e4563be8c67e86e1a515f21b5.1476971359.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Thu, 20 Oct 2016 15:58:02 +0200
> Currently, GRO can do unlimited recursion through the gro_receive
> handlers. This was fixed for tunneling protocols by limiting tunnel GRO
> to one level with encap_mark, but both VLAN and TEB still have this
> problem. Thus, the kernel is vulnerable to a stack overflow, if we
> receive a packet composed entirely of VLAN headers.
>
> This patch adds a recursion counter to the GRO layer to prevent stack
> overflow. When a gro_receive function hits the recursion limit, GRO is
> aborted for this skb and it is processed normally. This recursion
> counter is put in the GRO CB, but could be turned into a percpu counter
> if we run out of space in the CB.
>
> Thanks to Vladimír Beneš <vbenes@redhat.com> for the initial bug report.
>
> Fixes: CVE-2016-7039
> Fixes: 9b174d88c257 ("net: Add Transparent Ethernet Bridging GRO support.")
> Fixes: 66e5133f19e9 ("vlan: Add GRO support for non hardware accelerated vlan")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Reviewed-by: Jiri Benc <jbenc@redhat.com>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH 0/4] make POSIX timers optional with some Kconfig help
From: Nicolas Pitre @ 2016-10-20 18:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: John Stultz, Richard Cochran, Yann E MORIN, Josh Triplett, netdev,
linux-kbuild, linux-kernel
In-Reply-To: <alpine.DEB.2.20.1610201145310.5073@nanos>
On Thu, 20 Oct 2016, Thomas Gleixner wrote:
> On Wed, 19 Oct 2016, Nicolas Pitre wrote:
> > Therefore this series also includes kconfig changes to implement a new
> > keyword to express some reverse dependencies like "select" does, named
> > "imply", and still allowing for the target config symbol to be disabled
> > if the user or a direct dependency says so.
>
> That's really nice work! Thanks for doing that. It makes the whole thing
> more palatable.
Thanks.
Now I'd need some review tags... ;-)
Nicolas
^ permalink raw reply
* Re: [PATCH] netfilter: don't permit unprivileged writes to global state via sysctls
From: David Miller @ 2016-10-20 18:37 UTC (permalink / raw)
To: pablo; +Cc: jann, kuznet, jmorris, yoshfuji, netdev, netfilter-devel
In-Reply-To: <20161020182224.GA10999@salvia>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 20 Oct 2016 20:22:24 +0200
> On Sat, Sep 24, 2016 at 12:21:04AM +0200, Jann Horn wrote:
>> This prevents the modification of nf_conntrack_max in unprivileged network
>> namespaces. For unprivileged network namespaces, ip_conntrack_max is kept
>> as a readonly sysctl in order to minimize potential compatibility issues.
>>
>> This patch should apply cleanly to the net tree.
>
> For the record: This patch looks good to me, but this legacy
> ip_conntrack sysctl code is now gone.
>
> I don't know what is the procedure to get this to -stable branches now
> that this cannot be pushed upstream.
In the commit message for the -stable submission simply say "Not
applicable" in the upstream commit reference. Like:
[ Upstream commit: Not applicable ]
or something like that.
^ permalink raw reply
* Re: [PATCH net-next v2 3/9] net: use core MTU range checking in wireless drivers
From: David Miller @ 2016-10-20 18:38 UTC (permalink / raw)
To: johannes
Cc: jarod, linux-kernel, netdev, linux-wireless, qca_merez, simon,
stas.yakovlev, inaky.perez-gonzalez
In-Reply-To: <1476987755.14078.3.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 20 Oct 2016 20:22:35 +0200
> On Thu, 2016-10-20 at 13:55 -0400, Jarod Wilson wrote:
>> - set max_mtu in wil6210 driver
>> - set max_mtu in atmel driver
>> - set min/max_mtu in cisco airo driver, remove airo_change_mtu
>> - set min/max_mtu in ipw2100/ipw2200 drivers, remove
>> libipw_change_mtu
>> - set min/max_mtu in p80211netdev, remove wlan_change_mtu
>> - set min/max_mtu in net/mac80211/iface.c and remove ieee80211_change_mtu
>
> For the mac80211 part,
>
> Acked-by: Johannes Berg <johannes@sipsolutions.net>
>
> Dave, I'm assuming you'll pick this up, but if you prefer not to I can
> also coordinate with Kalle to take this through our trees.
Yeah I'll get this, thanks for asking.
^ permalink raw reply
* Re: [PATCH net] bpf, test: fix ld_abs + vlan push/pop stress test
From: David Miller @ 2016-10-20 18:39 UTC (permalink / raw)
To: daniel; +Cc: alexei.starovoitov, netdev
In-Reply-To: <24f37bd819eceb02c56fc5a6fcd5b8450b1db36a.1476976082.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 20 Oct 2016 17:13:53 +0200
> After commit 636c2628086e ("net: skbuff: Remove errornous length
> validation in skb_vlan_pop()") mentioned test case stopped working,
> throwing a -12 (ENOMEM) return code. The issue however is not due to
> 636c2628086e, but rather due to a buggy test case that got uncovered
> from the change in behaviour in 636c2628086e.
>
> The data_size of that test case for the skb was set to 1. In the
> bpf_fill_ld_abs_vlan_push_pop() handler bpf insns are generated that
> loop with: reading skb data, pushing 68 tags, reading skb data,
> popping 68 tags, reading skb data, etc, in order to force a skb
> expansion and thus trigger that JITs recache skb->data. Problem is
> that initial data_size is too small.
>
> While before 636c2628086e, the test silently bailed out due to the
> skb->len < VLAN_ETH_HLEN check with returning 0, and now throwing an
> error from failing skb_ensure_writable(). Set at least minimum of
> ETH_HLEN as an initial length so that on first push of data, equivalent
> pop will succeed.
>
> Fixes: 4d9c5c53ac99 ("test_bpf: add bpf_skb_vlan_push/pop() tests")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCH 0/4] STM32F429: Add Ethernet fixes
From: David Miller @ 2016-10-20 18:41 UTC (permalink / raw)
To: alexandre.torgue-qxv4g6HH51o
Cc: peppe.cavallaro-qxv4g6HH51o,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
robh-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476976886-23781-1-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
From: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Date: Thu, 20 Oct 2016 17:21:22 +0200
> This series adds several fixes for Ethernet for stm32f429 MCU.
> First 2 patches have already been reviewed some months ago when
> stm32 Ethernet glue has been pushed (I added in this series to keep
> history). Fixes are:
> -Change DT to be compliant to stm32 ethernet glue binding
> -Add phy-handle to correctly use mdio subnode
> -Remove WoL support
I'm assuming this will be merged via the ARM tree.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: [RFC PATCH net-next] bpf: fix potential percpu map overcopy to user.
From: William Tu @ 2016-10-20 18:41 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Daniel Borkmann, Linux Kernel Network Developers
In-Reply-To: <20161020165807.GB97796@ast-mbp.thefacebook.com>
On Thu, Oct 20, 2016 at 9:58 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu, Oct 20, 2016 at 06:04:38PM +0200, Daniel Borkmann wrote:
>>
>> diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
>> index ee384f0..d4832e8 100644
>> --- a/tools/testing/selftests/bpf/test_maps.c
>> +++ b/tools/testing/selftests/bpf/test_maps.c
>> @@ -25,6 +25,33 @@
>>
>> static int map_flags;
>>
>> +static unsigned int num_possible_cpus(void)
>> +{
>> + static const char *fcpu = "/sys/devices/system/cpu/possible";
>> + unsigned int val, possible_cpus = 0;
>> + char buff[128];
>> + FILE *fp;
>> +
>> + fp = fopen(fcpu, "r");
>> + if (!fp) {
>> + printf("Failed to open %s: '%s'!\n", fcpu, strerror(errno));
>> + exit(1);
>> + }
>> +
>> + while (fgets(buff, sizeof(buff), fp)) {
>> + if (sscanf(buff, "%*u-%u", &val) == 1)
>> + possible_cpus = val;
>> + }
>
> looks great to me.
> Could you move it into bpf_sys.h or somehow make it common in libbpf
> and reuse it in samples/bpf/ ?
> Since quite a few samples need this fix as well.
> Thanks!
>
Looks good to me. I tested it and it works fine.
Thanks!
William
^ permalink raw reply
* Re: [PATCH net] net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels
From: David Miller @ 2016-10-20 18:44 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot
In-Reply-To: <1476981139-28889-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 20 Oct 2016 09:32:19 -0700
> For a kernel that is being kexec'd we re-enable the integrated GPHY in
> order for the subsequent MDIO bus scan to succeed and properly bind to
> the bcm7xxx PHY driver. If we did not do that, the GPHY would be shut
> down by the time the MDIO driver is probing the bus, and it would fail
> to read the correct PHY OUI and therefore bind to an appropriate PHY
> driver. Later on, this would cause DSA not to be able to successfully
> attach to the PHY, and the interface would not be created at all.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, but I have to wonder...
If enabling the GPHY is necessary for proper probing, why isn't the
kexec kernel enabling it properly?
^ permalink raw reply
* Re: [PATCH net] udp: must lock the socket in udp_disconnect()
From: David Miller @ 2016-10-20 18:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: sploving1, netdev
In-Reply-To: <1476981580.7065.15.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 20 Oct 2016 09:39:40 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Baozeng Ding reported KASAN traces showing uses after free in
> udp_lib_get_port() and other related UDP functions.
>
> A CONFIG_DEBUG_PAGEALLOC=y kernel would eventually crash.
>
> I could write a reproducer with two threads doing :
>
> static int sock_fd;
> static void *thr1(void *arg)
> {
> for (;;) {
> connect(sock_fd, (const struct sockaddr *)arg,
> sizeof(struct sockaddr_in));
> }
> }
>
> static void *thr2(void *arg)
> {
> struct sockaddr_in unspec;
>
> for (;;) {
> memset(&unspec, 0, sizeof(unspec));
> connect(sock_fd, (const struct sockaddr *)&unspec,
> sizeof(unspec));
> }
> }
>
> Problem is that udp_disconnect() could run without holding socket lock,
> and this was causing list corruptions.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Baozeng Ding <sploving1@gmail.com>
Applied, sounds like I should queue this up for -stable too right?
^ permalink raw reply
* Re: [PATCH net] net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels
From: Florian Fainelli @ 2016-10-20 18:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andrew, vivien.didelot
In-Reply-To: <20161020.144431.1484493400918018326.davem@davemloft.net>
On 10/20/2016 11:44 AM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Thu, 20 Oct 2016 09:32:19 -0700
>
>> For a kernel that is being kexec'd we re-enable the integrated GPHY in
>> order for the subsequent MDIO bus scan to succeed and properly bind to
>> the bcm7xxx PHY driver. If we did not do that, the GPHY would be shut
>> down by the time the MDIO driver is probing the bus, and it would fail
>> to read the correct PHY OUI and therefore bind to an appropriate PHY
>> driver. Later on, this would cause DSA not to be able to successfully
>> attach to the PHY, and the interface would not be created at all.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Applied, but I have to wonder...
>
> If enabling the GPHY is necessary for proper probing, why isn't the
> kexec kernel enabling it properly?
The GPHY enable control is unfortunately located in the switch register
block space and is dependent upon the switch port to be
enabled/accessible, which the DSA layer won't create if the GPHY is not
successfully probed and bound to a PHY driver. It did not appear that
probe deferral could help solve that problem, since MDIO and switch are
reasonable independent from each other.
This was the easiest way I could come up with, without requiring DT
changes and references to register blocks that are not quite relevant to
each other.
HTH
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v12 5/9] openvswitch: add processing of L3 packets
From: Pravin Shelar @ 2016-10-20 18:48 UTC (permalink / raw)
To: Jiri Benc; +Cc: ovs dev, Linux Kernel Network Developers, Simon Horman
In-Reply-To: <20161019185206.7347e189@griffin>
On Wed, Oct 19, 2016 at 9:52 AM, Jiri Benc <jbenc@redhat.com> wrote:
> On Tue, 18 Oct 2016 22:13:45 -0700, Pravin Shelar wrote:
>> On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
>> > - skb_reset_network_header(skb);
>> > + skb->protocol = parse_ethertype(skb);
>>
>> I am not sure about changing skb->protocol here.
>> By changing this skb loosing information about packet type. Therefore
>> if packet re-enters OVS (through different bridge), this packet would
>> look like L3 packet. function key_extract_mac_proto() would not see
>> TEB type packet.
>
> This should be okay. If the packet is sent out to an Ethernet interface
> (whatever interface it is), skb->protocol needs to contain the payload
> type. We're not interested in ETH_P_TEB. If the packet is sent out to
> an ARPHRD_NONE interface, ETH_P_TEB is pushed back.
>
I see, vport send is restoring the skb protocol field. It should be fine then.
> Basically, what we're doing here is unconditionally converting
> ETH_P_TEB packets *coming from ARPHRD_NONE interfaces* (this is
> important) into regular Ethernet packets. Which is exactly what we want.
>
> Am I missing something?
>
> Jiri
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH -next] dwc_eth_qos: use dev_kfree_skb_any instead of dev_kfree_skb
From: David Miller @ 2016-10-20 18:48 UTC (permalink / raw)
To: weiyj.lk; +Cc: lars.persson, weiyongjun1, netdev
In-Reply-To: <1476982789-27821-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 20 Oct 2016 16:59:49 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Replace dev_kfree_skb with dev_kfree_skb_any in dwceqos_start_xmit()
> which can be called from hard irq context (netpoll) and from
> other contexts. dwceqos_start_xmit() only frees skbs that it has
> dropped.
>
> This is detected by Coccinelle semantic patch.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] net: ethernet: mediatek: use dev_kfree_skb_any instead of dev_kfree_skb
From: David Miller @ 2016-10-20 18:48 UTC (permalink / raw)
To: weiyj.lk
Cc: nbd, blogic, matthias.bgg, weiyongjun1, netdev, linux-arm-kernel,
linux-mediatek
In-Reply-To: <1476982832-27932-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 20 Oct 2016 17:00:32 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Replace dev_kfree_skb with dev_kfree_skb_any in mtk_start_xmit()
> which can be called from hard irq context (netpoll) and from
> other contexts. mtk_start_xmit() only frees skbs that it has
> dropped.
>
> This is detected by Coccinelle semantic patch.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] myri10ge: fix typo in parameter description
From: David Miller @ 2016-10-20 18:48 UTC (permalink / raw)
To: weiyj.lk; +Cc: hykim, weiyongjun1, netdev
In-Reply-To: <1476982916-28139-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 20 Oct 2016 17:01:56 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix typo in parameter description.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv4: disable BH in set_ping_group_range()
From: David Miller @ 2016-10-20 18:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, salo, xiyou.wangcong
In-Reply-To: <1476984408.7065.21.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 20 Oct 2016 10:26:48 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> In commit 4ee3bd4a8c746 ("ipv4: disable BH when changing ip local port
> range") Cong added BH protection in set_local_port_range() but missed
> that same fix was needed in set_ping_group_range()
>
> Fixes: b8f1a55639e6 ("udp: Add function to make source port for UDP tunnels")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Eric Salo <salo@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 0/4] make POSIX timers optional with some Kconfig help
From: Josh Triplett @ 2016-10-20 18:51 UTC (permalink / raw)
To: Nicolas Pitre
Cc: John Stultz, Richard Cochran, Yann E MORIN, Thomas Gleixner,
netdev, linux-kbuild, linux-kernel
In-Reply-To: <1476920573-14384-1-git-send-email-nicolas.pitre@linaro.org>
On Wed, Oct 19, 2016 at 07:42:49PM -0400, Nicolas Pitre wrote:
> Many embedded systems don't need the full POSIX timer support.
> Configuring them out provides a nice kernel image size reduction.
>
> When POSIX timers are configured out, the PTP clock subsystem should be
> left out as well. However a bunch of ethernet drivers currently *select*
> the later in their Kconfig entries. Therefore some more work was needed
> to break that hard dependency from those drivers without preventing their
> usage altogether.
>
> Therefore this series also includes kconfig changes to implement a new
> keyword to express some reverse dependencies like "select" does, named
> "imply", and still allowing for the target config symbol to be disabled
> if the user or a direct dependency says so.
>
> How to deal with the dependencies across three subsystems for potential
> upstream merging needs to be figured out.
This looks good to me, and I like the new "imply" approach.
I'd still like to see a more general solution for reporting the use of
compiled-out syscalls, but I don't think that needs to block this patch
series.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
^ 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