* [PATCH net v1 1/2] net: dsa: lantiq_gswip: Fix start index in gswip_port_fdb()
From: Martin Blumenstingl @ 2022-05-17 19:40 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, andrew, vivien.didelot, f.fainelli, olteanv, davem,
edumazet, kuba, pabeni, Martin Blumenstingl, Hauke Mehrtens
In-Reply-To: <20220517194015.1081632-1-martin.blumenstingl@googlemail.com>
The first N entries in priv->vlans are reserved for managing ports which
are not part of a bridge. Use priv->hw_info->max_ports to consistently
access per-bridge entries at index 7. Starting at
priv->hw_info->cpu_port (6) is harmless in this case because
priv->vlan[6].bridge is always NULL so the comparison result is always
false (which results in this entry being skipped).
Fixes: 58c59ef9e930c4 ("net: dsa: lantiq: Add Forwarding Database access")
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/dsa/lantiq_gswip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 12c15da55664..0c313db23451 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -1360,7 +1360,7 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
struct net_device *bridge = dsa_port_bridge_dev_get(dsa_to_port(ds, port));
struct gswip_priv *priv = ds->priv;
struct gswip_pce_table_entry mac_bridge = {0,};
- unsigned int cpu_port = priv->hw_info->cpu_port;
+ unsigned int max_ports = priv->hw_info->max_ports;
int fid = -1;
int i;
int err;
@@ -1368,7 +1368,7 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
if (!bridge)
return -EINVAL;
- for (i = cpu_port; i < ARRAY_SIZE(priv->vlans); i++) {
+ for (i = max_ports; i < ARRAY_SIZE(priv->vlans); i++) {
if (priv->vlans[i].bridge == bridge) {
fid = priv->vlans[i].fid;
break;
--
2.36.1
^ permalink raw reply related
* [PATCH net v1 0/2] lantiq_gswip: Two small fixes
From: Martin Blumenstingl @ 2022-05-17 19:40 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, andrew, vivien.didelot, f.fainelli, olteanv, davem,
edumazet, kuba, pabeni, Martin Blumenstingl
While updating the Lantiq target in OpenWrt to Linux 5.15 I came across
an FDB related error message. While that still needs to be solved I
found two other small issues on the way.
This series fixes the two minor issues found while revisiting the FDB
code in the lantiq_gswip driver:
- The first patch fixes the start index used in gswip_port_fdb() to
find the entry with the matching bridge. The updated logic is now
consistent with the rest of the driver.
- The second patch fixes a typo in a dev_err() message.
Hauke gave his Acked-by off-list to me before I sent the patches.
Martin Blumenstingl (2):
net: dsa: lantiq_gswip: Fix start index in gswip_port_fdb()
net: dsa: lantiq_gswip: Fix typo in gswip_port_fdb_dump() error print
drivers/net/dsa/lantiq_gswip.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--
2.36.1
^ permalink raw reply
* Re: [PATCH 05/12] net: mana: Set the DMA device max page size
From: Jason Gunthorpe @ 2022-05-17 19:35 UTC (permalink / raw)
To: Long Li
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu,
Dexuan Cui, David S. Miller, Jakub Kicinski, Paolo Abeni,
Leon Romanovsky, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <PH7PR21MB3263EFA8F624F681C3B57636CECE9@PH7PR21MB3263.namprd21.prod.outlook.com>
On Tue, May 17, 2022 at 07:32:51PM +0000, Long Li wrote:
> > Subject: Re: [PATCH 05/12] net: mana: Set the DMA device max page size
> >
> > On Tue, May 17, 2022 at 02:04:29AM -0700, longli@linuxonhyperv.com wrote:
> > > From: Long Li <longli@microsoft.com>
> > >
> > > The system chooses default 64K page size if the device does not
> > > specify the max page size the device can handle for DMA. This do not
> > > work well when device is registering large chunk of memory in that a
> > > large page size is more efficient.
> > >
> > > Set it to the maximum hardware supported page size.
> >
> > For RDMA devices this should be set to the largest segment size an ib_sge can
> > take in when posting work. It should not be the page size of MR. 2M is a weird
> > number for that, are you sure it is right?
>
> Yes, this is the maximum page size used in hardware page tables.
As I said, it should be the size of the sge in the WQE, not the
"hardware page tables"
Jason
^ permalink raw reply
* Re: [PATCH net-next] net: ifdefy the wireless pointers in struct net_device
From: Alexander Aring @ 2022-05-17 19:33 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jakub Kicinski, David S. Miller, Network Development, edumazet,
Paolo Abeni, johannes, Alexander Aring, Stefan Schmidt,
mareklindner, sw, a, sven, linux-wireless, linux-wpan - ML
In-Reply-To: <8e9f1b04-d17b-2812-22bb-e62b5560aa6e@gmail.com>
Hi,
On Mon, May 16, 2022 at 10:13 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 5/16/2022 2:56 PM, Jakub Kicinski wrote:
> > Most protocol-specific pointers in struct net_device are under
> > a respective ifdef. Wireless is the notable exception. Since
> > there's a sizable number of custom-built kernels for datacenter
> > workloads which don't build wireless it seems reasonable to
> > ifdefy those pointers as well.
> >
> > While at it move IPv4 and IPv6 pointers up, those are special
> > for obvious reasons.
> >
> > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>
> Could not we move to an union of pointers in the future since in many
> cases a network device can only have one of those pointers at any given
> time?
note that ieee802154 has also functionality like __dev_get_by_index()
and checks via "if (netdev->ieee802154_ptr)" if it's a wpan interface
or not, guess the solution would be like it's done in wireless then.
- Alex
^ permalink raw reply
* RE: [PATCH 05/12] net: mana: Set the DMA device max page size
From: Long Li @ 2022-05-17 19:32 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu,
Dexuan Cui, David S. Miller, Jakub Kicinski, Paolo Abeni,
Leon Romanovsky, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <20220517145949.GH63055@ziepe.ca>
> Subject: Re: [PATCH 05/12] net: mana: Set the DMA device max page size
>
> On Tue, May 17, 2022 at 02:04:29AM -0700, longli@linuxonhyperv.com wrote:
> > From: Long Li <longli@microsoft.com>
> >
> > The system chooses default 64K page size if the device does not
> > specify the max page size the device can handle for DMA. This do not
> > work well when device is registering large chunk of memory in that a
> > large page size is more efficient.
> >
> > Set it to the maximum hardware supported page size.
>
> For RDMA devices this should be set to the largest segment size an ib_sge can
> take in when posting work. It should not be the page size of MR. 2M is a weird
> number for that, are you sure it is right?
Yes, this is the maximum page size used in hardware page tables.
Long
>
> Jason
^ permalink raw reply
* RE: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list
From: Luck, Tony @ 2022-05-17 19:07 UTC (permalink / raw)
To: Guilherme G. Piccoli, Petr Mladek, Dinh Nguyen
Cc: akpm@linux-foundation.org, bhe@redhat.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com,
linuxppc-dev@lists.ozlabs.org, linux-alpha@vger.kernel.org,
linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-leds@vger.kernel.org, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-pm@vger.kernel.org,
linux-remoteproc@vger.kernel.org, linux-s390@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-um@lists.infradead.org,
linux-xtensa@linux-xtensa.org, netdev@vger.kernel.org,
openipmi-developer@lists.sourceforge.net, rcu@vger.kernel.org,
sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
x86@kernel.org, kernel-dev@igalia.com, kernel@gpiccoli.net,
halves@canonical.com, fabiomirmar@gmail.com,
alejandro.j.jimenez@oracle.com, andriy.shevchenko@linux.intel.com,
arnd@arndb.de, bp@alien8.de, corbet@lwn.net,
d.hatayama@jp.fujitsu.com, dave.hansen@linux.intel.com,
dyoung@redhat.com, Tang, Feng, gregkh@linuxfoundation.org,
mikelley@microsoft.com, hidehiro.kawai.ez@hitachi.com,
jgross@suse.com, john.ogness@linutronix.de, keescook@chromium.org,
luto@kernel.org, mhiramat@kernel.org, mingo@redhat.com,
paulmck@kernel.org, peterz@infradead.org, rostedt@goodmis.org,
senozhatsky@chromium.org, stern@rowland.harvard.edu,
tglx@linutronix.de, vgoyal@redhat.com, vkuznets@redhat.com,
will@kernel.org, Alex Elder, Alexander Gordeev, Anton Ivanov,
Benjamin Herrenschmidt, Bjorn Andersson, Boris Ostrovsky,
Chris Zankel, Christian Borntraeger, Corey Minyard, Dexuan Cui,
H. Peter Anvin, Haiyang Zhang, Heiko Carstens, Helge Deller,
Ivan Kokshaysky, James E.J. Bottomley, James Morse, Johannes Berg,
K. Y. Srinivasan, Mathieu Poirier, Matt Turner,
Mauro Carvalho Chehab, Max Filippov, Michael Ellerman,
Paul Mackerras, Pavel Machek, Richard Weinberger, Robert Richter,
Stefano Stabellini, Stephen Hemminger, Sven Schnelle,
Vasily Gorbik, Wei Liu
In-Reply-To: <62a63fc2-346f-f375-043a-fa21385279df@igalia.com>
> What I'm planning to do in the altera_edac notifier is:
>
> if (kdump_is_set)
> return;
Yes. That's what I think should happen.
-Tony
^ permalink raw reply
* Re: [PATCH v2 01/14] thermal/core: Change thermal_zone_ops to thermal_sensor_ops
From: Rafael J. Wysocki @ 2022-05-17 19:07 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Rafael J. Wysocki, Daniel Lezcano, Daniel Lezcano, Kevin Hilman,
Alexandre Bailon, Linux PM, Linux Kernel Mailing List,
Amit Kucheria, Zhang Rui, Jonathan Corbet, Len Brown,
Raju Rangoju, David S. Miller, Jakub Kicinski, Paolo Abeni,
Ido Schimmel, Petr Machata, Luca Coelho, Kalle Valo,
Peter Kaestle, Hans de Goede, Mark Gross, Sebastian Reichel,
Miquel Raynal, Support Opensource, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Niklas Söderlund, Miri Korenblit, Johannes Berg,
Sumeet Pawnikar, Dan Carpenter, Chuansheng Liu, Jiasheng Jiang,
Antoine Tenart, Andy Shevchenko, open list:DOCUMENTATION,
open list:ACPI THERMAL DRIVER,
open list:CXGB4 ETHERNET DRIVER (CXGB4),
open list:INTEL WIRELESS WIFI LINK (iwlwifi),
open list:ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:RENESAS R-CAR THERMAL DRIVERS
In-Reply-To: <afcc7b08ebe2578d32e6595d258afeec3e73512e.camel@linux.intel.com>
On Tue, May 17, 2022 at 9:02 PM srinivas pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> On Tue, 2022-05-17 at 20:53 +0200, Rafael J. Wysocki wrote:
> > On Tue, May 17, 2022 at 6:51 PM srinivas pandruvada
> > <srinivas.pandruvada@linux.intel.com> wrote:
> > >
> > > On Tue, 2022-05-17 at 17:42 +0200, Rafael J. Wysocki wrote:
> > > > On Sat, May 7, 2022 at 2:55 PM Daniel Lezcano
> > > > <daniel.lezcano@linexp.org> wrote:
> > > > >
> > > > > A thermal zone is software abstraction of a sensor associated
> > > > > with
> > > > > properties and cooling devices if any.
> > > > >
> > > > > The fact that we have thermal_zone and thermal_zone_ops mixed
> > > > > is
> > > > > confusing and does not clearly identify the different
> > > > > components
> > > > > entering in the thermal management process. A thermal zone
> > > > > appears
> > > > > to
> > > > > be a sensor while it is not.
> > > >
> > > > Well, the majority of the operations in thermal_zone_ops don't
> > > > apply
> > > > to thermal sensors. For example, ->set_trips(), -
> > > > >get_trip_type(),
> > > > ->get_trip_temp().
> > > >
> > > In past we discussed adding thermal sensor sysfs with threshold to
> > > notify temperature.
> > >
> > > So sensor can have set/get_threshold() functions instead of the
> > > set/get_trip for zones.
> > >
> > > Like we have /sys/class/thermal_zone* we can have
> > > /sys/class/thermal_sensor*.
> >
> > Exactly, so renaming thermal_zone_ops as thermal_sensor_ops isn't
> > quite helpful in this respect.
> >
> > IMO there should be operations for sensors and there should be
> > operations for thermal zones and those two sets of operations should
> > be different.
> >
> > > Thermal sensor(s) are bound to thermal zones.
> >
> > So I think that this binding should be analogous to the binding
> > between thermal zones and cooling devices.
> >
> > > This can also include multiple sensors in a zone and can create a
> > > virtual sensor also.
> >
> > It can.
> >
> > However, what's the difference between a thermal zone with multiple
> > sensors and a thermal zone with one virtual sensor being an aggregate
> > of multiple physical sensors?
> >
> Either way is fine. A thermal sensor can be aggregate of other sensors.
Agreed.
But the point is that if we go with thermal zones bound to multiple
physical sensors, I don't see much point in using virtual sensors.
And the other way around.
Daniel seems to be preferring the thermal zones bound to multiple
physical sensors approach.
> > Both involve some type of aggregation of temperature values measured
> > by the physical sensors.
> >
> > > > > In order to set the scene for multiple thermal sensors
> > > > > aggregated
> > > > > into
> > > > > a single thermal zone. Rename the thermal_zone_ops to
> > > > > thermal_sensor_ops, that will appear clearyl the thermal zone
> > > > > is
> > > > > not a
> > > > > sensor but an abstraction of one [or multiple] sensor(s).
> > > >
> > > > So I'm not convinced that the renaming mentioned above is
> > > > particularly
> > > > clean either.
> > > >
> > > > IMV the way to go would be to split the thermal sensor
> > > > operations,
> > > > like ->get_temp(), out of thermal_zone_ops.
> > > >
> > > > But then it is not clear what a thermal zone with multiple
> > > > sensors in
> > > > it really means. I guess it would require an aggregation
> > > > function to
> > > > combine the thermal sensors in it that would produce an effective
> > > > temperature to check against the trip points.
> > > >
> > > > Honestly, I don't think that setting a separate set of trips for
> > > > each
> > > > sensor in a thermal zone would make a lot of sense.
> > >
>
^ permalink raw reply
* Re: [PATCH v2 01/14] thermal/core: Change thermal_zone_ops to thermal_sensor_ops
From: srinivas pandruvada @ 2022-05-17 19:02 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Daniel Lezcano, Daniel Lezcano, Kevin Hilman, Alexandre Bailon,
Linux PM, Linux Kernel Mailing List, Amit Kucheria, Zhang Rui,
Jonathan Corbet, Len Brown, Raju Rangoju, David S. Miller,
Jakub Kicinski, Paolo Abeni, Ido Schimmel, Petr Machata,
Luca Coelho, Kalle Valo, Peter Kaestle, Hans de Goede, Mark Gross,
Sebastian Reichel, Miquel Raynal, Support Opensource, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Niklas Söderlund, Miri Korenblit,
Johannes Berg, Sumeet Pawnikar, Dan Carpenter, Chuansheng Liu,
Jiasheng Jiang, Antoine Tenart, Andy Shevchenko,
open list:DOCUMENTATION, open list:ACPI THERMAL DRIVER,
open list:CXGB4 ETHERNET DRIVER (CXGB4),
open list:INTEL WIRELESS WIFI LINK (iwlwifi),
open list:ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:RENESAS R-CAR THERMAL DRIVERS
In-Reply-To: <CAJZ5v0hqN-zKZvWTNPzW2P22Dirmyh99qyycf+US4Z9Yxw9mhA@mail.gmail.com>
On Tue, 2022-05-17 at 20:53 +0200, Rafael J. Wysocki wrote:
> On Tue, May 17, 2022 at 6:51 PM srinivas pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> >
> > On Tue, 2022-05-17 at 17:42 +0200, Rafael J. Wysocki wrote:
> > > On Sat, May 7, 2022 at 2:55 PM Daniel Lezcano
> > > <daniel.lezcano@linexp.org> wrote:
> > > >
> > > > A thermal zone is software abstraction of a sensor associated
> > > > with
> > > > properties and cooling devices if any.
> > > >
> > > > The fact that we have thermal_zone and thermal_zone_ops mixed
> > > > is
> > > > confusing and does not clearly identify the different
> > > > components
> > > > entering in the thermal management process. A thermal zone
> > > > appears
> > > > to
> > > > be a sensor while it is not.
> > >
> > > Well, the majority of the operations in thermal_zone_ops don't
> > > apply
> > > to thermal sensors. For example, ->set_trips(), -
> > > >get_trip_type(),
> > > ->get_trip_temp().
> > >
> > In past we discussed adding thermal sensor sysfs with threshold to
> > notify temperature.
> >
> > So sensor can have set/get_threshold() functions instead of the
> > set/get_trip for zones.
> >
> > Like we have /sys/class/thermal_zone* we can have
> > /sys/class/thermal_sensor*.
>
> Exactly, so renaming thermal_zone_ops as thermal_sensor_ops isn't
> quite helpful in this respect.
>
> IMO there should be operations for sensors and there should be
> operations for thermal zones and those two sets of operations should
> be different.
>
> > Thermal sensor(s) are bound to thermal zones.
>
> So I think that this binding should be analogous to the binding
> between thermal zones and cooling devices.
>
> > This can also include multiple sensors in a zone and can create a
> > virtual sensor also.
>
> It can.
>
> However, what's the difference between a thermal zone with multiple
> sensors and a thermal zone with one virtual sensor being an aggregate
> of multiple physical sensors?
>
Either way is fine. A thermal sensor can be aggregate of other sensors.
> Both involve some type of aggregation of temperature values measured
> by the physical sensors.
>
> > > > In order to set the scene for multiple thermal sensors
> > > > aggregated
> > > > into
> > > > a single thermal zone. Rename the thermal_zone_ops to
> > > > thermal_sensor_ops, that will appear clearyl the thermal zone
> > > > is
> > > > not a
> > > > sensor but an abstraction of one [or multiple] sensor(s).
> > >
> > > So I'm not convinced that the renaming mentioned above is
> > > particularly
> > > clean either.
> > >
> > > IMV the way to go would be to split the thermal sensor
> > > operations,
> > > like ->get_temp(), out of thermal_zone_ops.
> > >
> > > But then it is not clear what a thermal zone with multiple
> > > sensors in
> > > it really means. I guess it would require an aggregation
> > > function to
> > > combine the thermal sensors in it that would produce an effective
> > > temperature to check against the trip points.
> > >
> > > Honestly, I don't think that setting a separate set of trips for
> > > each
> > > sensor in a thermal zone would make a lot of sense.
> >
^ permalink raw reply
* Re: [PATCH v2 01/14] thermal/core: Change thermal_zone_ops to thermal_sensor_ops
From: Rafael J. Wysocki @ 2022-05-17 18:53 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Rafael J. Wysocki, Daniel Lezcano, Daniel Lezcano, Kevin Hilman,
Alexandre Bailon, Linux PM, Linux Kernel Mailing List,
Amit Kucheria, Zhang Rui, Jonathan Corbet, Len Brown,
Raju Rangoju, David S. Miller, Jakub Kicinski, Paolo Abeni,
Ido Schimmel, Petr Machata, Luca Coelho, Kalle Valo,
Peter Kaestle, Hans de Goede, Mark Gross, Sebastian Reichel,
Miquel Raynal, Support Opensource, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Niklas Söderlund, Miri Korenblit, Johannes Berg,
Sumeet Pawnikar, Dan Carpenter, Chuansheng Liu, Jiasheng Jiang,
Antoine Tenart, Andy Shevchenko, open list:DOCUMENTATION,
open list:ACPI THERMAL DRIVER,
open list:CXGB4 ETHERNET DRIVER (CXGB4),
open list:INTEL WIRELESS WIFI LINK (iwlwifi),
open list:ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:RENESAS R-CAR THERMAL DRIVERS
In-Reply-To: <7b1a9f3b5b5087f47bf4839858c7bfebdb60aa2f.camel@linux.intel.com>
On Tue, May 17, 2022 at 6:51 PM srinivas pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> On Tue, 2022-05-17 at 17:42 +0200, Rafael J. Wysocki wrote:
> > On Sat, May 7, 2022 at 2:55 PM Daniel Lezcano
> > <daniel.lezcano@linexp.org> wrote:
> > >
> > > A thermal zone is software abstraction of a sensor associated with
> > > properties and cooling devices if any.
> > >
> > > The fact that we have thermal_zone and thermal_zone_ops mixed is
> > > confusing and does not clearly identify the different components
> > > entering in the thermal management process. A thermal zone appears
> > > to
> > > be a sensor while it is not.
> >
> > Well, the majority of the operations in thermal_zone_ops don't apply
> > to thermal sensors. For example, ->set_trips(), ->get_trip_type(),
> > ->get_trip_temp().
> >
> In past we discussed adding thermal sensor sysfs with threshold to
> notify temperature.
>
> So sensor can have set/get_threshold() functions instead of the
> set/get_trip for zones.
>
> Like we have /sys/class/thermal_zone* we can have
> /sys/class/thermal_sensor*.
Exactly, so renaming thermal_zone_ops as thermal_sensor_ops isn't
quite helpful in this respect.
IMO there should be operations for sensors and there should be
operations for thermal zones and those two sets of operations should
be different.
> Thermal sensor(s) are bound to thermal zones.
So I think that this binding should be analogous to the binding
between thermal zones and cooling devices.
> This can also include multiple sensors in a zone and can create a virtual sensor also.
It can.
However, what's the difference between a thermal zone with multiple
sensors and a thermal zone with one virtual sensor being an aggregate
of multiple physical sensors?
Both involve some type of aggregation of temperature values measured
by the physical sensors.
> > > In order to set the scene for multiple thermal sensors aggregated
> > > into
> > > a single thermal zone. Rename the thermal_zone_ops to
> > > thermal_sensor_ops, that will appear clearyl the thermal zone is
> > > not a
> > > sensor but an abstraction of one [or multiple] sensor(s).
> >
> > So I'm not convinced that the renaming mentioned above is
> > particularly
> > clean either.
> >
> > IMV the way to go would be to split the thermal sensor operations,
> > like ->get_temp(), out of thermal_zone_ops.
> >
> > But then it is not clear what a thermal zone with multiple sensors in
> > it really means. I guess it would require an aggregation function to
> > combine the thermal sensors in it that would produce an effective
> > temperature to check against the trip points.
> >
> > Honestly, I don't think that setting a separate set of trips for each
> > sensor in a thermal zone would make a lot of sense.
>
^ permalink raw reply
* Re: [PATCHv2 net] bonding: fix missed rcu protection
From: Stephen Hemminger @ 2022-05-17 18:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Hangbin Liu, netdev, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, David S . Miller, David Ahern, Jonathan Toppins,
Eric Dumazet, Paolo Abeni, syzbot+92beb3d46aab498710fa,
Vladimir Oltean
In-Reply-To: <20220517105445.355b1d22@kernel.org>
On Tue, 17 May 2022 10:54:45 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> dev_hold() and dev_put() can take NULL these days, for better or worse.
> I think the code simplification is worth making use of that, even tho
> it will make the backport slightly more tricky (perhaps make a not of
> this in the commit message).
Since that is so, would be worth having coccinelle script to cleanup
existing code.
See scripts/coccinelle/ifnullfree.cocci for similar example.
^ permalink raw reply
* Re: [PATCH net-next] net: ifdefy the wireless pointers in struct net_device
From: Johannes Berg @ 2022-05-17 18:16 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Florian Fainelli, davem, netdev, edumazet, pabeni, alex.aring,
stefan, mareklindner, sw, a, sven, linux-wireless, linux-wpan
In-Reply-To: <20220517103758.353c2476@kernel.org>
On Tue, 2022-05-17 at 10:37 -0700, Jakub Kicinski wrote:
> >
> > Then at the very least we'd need some kind of type that we can assign to
> > disambiguate, because today e.g. we have a netdev notifier (and other
> > code) that could get a non-wireless netdev and check like this:
> >
> > static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
> > unsigned long state, void *ptr)
> > {
> > struct net_device *dev = netdev_notifier_info_to_dev(ptr);
> > struct wireless_dev *wdev = dev->ieee80211_ptr;
> > [...]
> > if (!wdev)
> > return NOTIFY_DONE;
>
> Can we use enum netdev_ml_priv_type netdev::ml_priv and
> netdev::ml_priv_type for this?
>
Hm, yeah, I guess we can. I think I'd prefer something along the lines
of the below, then we don't even need the ifdef.
johannes
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index eaf66e57d891..4bd81767c058 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1702,6 +1702,7 @@ enum netdev_priv_flags {
enum netdev_ml_priv_type {
ML_PRIV_NONE,
ML_PRIV_CAN,
+ ML_PRIV_WIFI,
};
/**
@@ -2127,7 +2128,6 @@ struct net_device {
#if IS_ENABLED(CONFIG_AX25)
void *ax25_ptr;
#endif
- struct wireless_dev *ieee80211_ptr;
struct wpan_dev *ieee802154_ptr;
#if IS_ENABLED(CONFIG_MPLS_ROUTING)
struct mpls_dev __rcu *mpls_ptr;
@@ -2235,7 +2235,10 @@ struct net_device {
possible_net_t nd_net;
/* mid-layer private */
- void *ml_priv;
+ union {
+ void *ml_priv;
+ struct wireless_dev *ieee80211_ptr;
+ };
enum netdev_ml_priv_type ml_priv_type;
union {
diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c
index 83fb51b6e299..7b063adacaa6 100644
--- a/net/batman-adv/hard-interface.c
+++ b/net/batman-adv/hard-interface.c
@@ -307,11 +307,7 @@ static bool batadv_is_cfg80211_netdev(struct net_device *net_device)
if (!net_device)
return false;
- /* cfg80211 drivers have to set ieee80211_ptr */
- if (net_device->ieee80211_ptr)
- return true;
-
- return false;
+ return netdev_get_ml_priv(net_device, ML_PRIV_WIFI);
}
/**
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 4980c3a50475..50154f7879b6 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1997,7 +1997,7 @@ int netdev_register_kobject(struct net_device *ndev)
*groups++ = &netstat_group;
#if IS_ENABLED(CONFIG_WIRELESS_EXT) || IS_ENABLED(CONFIG_CFG80211)
- if (ndev->ieee80211_ptr)
+ if (netdev_get_ml_priv(ndev, ML_PRIV_WIFI))
*groups++ = &wireless_group;
#if IS_ENABLED(CONFIG_WIRELESS_EXT)
else if (ndev->wireless_handlers)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 3e5d12040726..9024bd9f7d46 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1369,6 +1369,12 @@ int cfg80211_register_netdevice(struct net_device *dev)
lockdep_assert_held(&rdev->wiphy.mtx);
+ /*
+ * This lets us identify our netdevs in the future,
+ * the driver already set dev->ieee80211_ptr.
+ */
+ netdev_set_ml_priv(dev, wdev, ML_PRIV_WIFI);
+
/* we'll take care of this */
wdev->registered = true;
wdev->registering = true;
@@ -1390,7 +1396,7 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
unsigned long state, void *ptr)
{
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
- struct wireless_dev *wdev = dev->ieee80211_ptr;
+ struct wireless_dev *wdev = netdev_get_ml_priv(dev, ML_PRIV_WIFI);
struct cfg80211_registered_device *rdev;
struct cfg80211_sched_scan_request *pos, *tmp;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8d528b5945d0..3a5a7183b959 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -182,9 +182,12 @@ __cfg80211_rdev_from_attrs(struct net *netns, struct nlattr **attrs)
netdev = __dev_get_by_index(netns, ifindex);
if (netdev) {
- if (netdev->ieee80211_ptr)
- tmp = wiphy_to_rdev(
- netdev->ieee80211_ptr->wiphy);
+ struct wireless_dev *wdev;
+
+ wdev = netdev_get_ml_priv(netdev, ML_PRIV_WIFI);
+
+ if (wdev)
+ tmp = wiphy_to_rdev(wdev->wiphy);
else
tmp = NULL;
@@ -2972,15 +2975,17 @@ static int nl80211_dump_wiphy_parse(struct sk_buff *skb,
struct net_device *netdev;
struct cfg80211_registered_device *rdev;
int ifidx = nla_get_u32(tb[NL80211_ATTR_IFINDEX]);
+ struct wireless_dev *wdev;
netdev = __dev_get_by_index(sock_net(skb->sk), ifidx);
if (!netdev) {
ret = -ENODEV;
goto out;
}
- if (netdev->ieee80211_ptr) {
- rdev = wiphy_to_rdev(
- netdev->ieee80211_ptr->wiphy);
+
+ wdev = netdev_is_wireless(netdev, ML_PRIV_WIFI);
+ if (wdev) {
+ rdev = wiphy_to_rdev(wdev->wiphy);
state->filter_wiphy = rdev->wiphy_idx;
}
}
@@ -3364,8 +3369,9 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
int ifindex = nla_get_u32(info->attrs[NL80211_ATTR_IFINDEX]);
netdev = __dev_get_by_index(genl_info_net(info), ifindex);
- if (netdev && netdev->ieee80211_ptr)
- rdev = wiphy_to_rdev(netdev->ieee80211_ptr->wiphy);
+ wdev = netdev_is_wireless(netdev);
+ if (wdev)
+ rdev = wiphy_to_rdev(wdev->wiphy);
else
netdev = NULL;
}
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index b9678801d848..e1bd3f624e1b 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -2715,6 +2715,7 @@ static struct cfg80211_registered_device *
cfg80211_get_dev_from_ifindex(struct net *net, int ifindex)
{
struct cfg80211_registered_device *rdev;
+ struct wireless_dev *wdev;
struct net_device *dev;
ASSERT_RTNL();
@@ -2722,8 +2723,9 @@ cfg80211_get_dev_from_ifindex(struct net *net, int ifindex)
dev = dev_get_by_index(net, ifindex);
if (!dev)
return ERR_PTR(-ENODEV);
- if (dev->ieee80211_ptr)
- rdev = wiphy_to_rdev(dev->ieee80211_ptr->wiphy);
+ wdev = netdev_get_ml_priv(dev, ML_PRIV_WIFI);
+ if (wdev)
+ rdev = wiphy_to_rdev(wdev->wiphy);
else
rdev = ERR_PTR(-ENODEV);
dev_put(dev);
diff --git a/net/wireless/wext-proc.c b/net/wireless/wext-proc.c
index cadcf8613af2..a7d903729d2e 100644
--- a/net/wireless/wext-proc.c
+++ b/net/wireless/wext-proc.c
@@ -40,7 +40,7 @@ static void wireless_seq_printf_stats(struct seq_file *seq,
stats = &nullstats;
#endif
#ifdef CONFIG_CFG80211
- if (dev->ieee80211_ptr)
+ if (netdev_get_ml_priv(dev, ML_PRIV_WIFI))
stats = &nullstats;
#endif
}
^ permalink raw reply related
* Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list
From: Guilherme G. Piccoli @ 2022-05-17 18:12 UTC (permalink / raw)
To: Luck, Tony, Petr Mladek, Dinh Nguyen
Cc: akpm@linux-foundation.org, bhe@redhat.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com,
linuxppc-dev@lists.ozlabs.org, linux-alpha@vger.kernel.org,
linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-leds@vger.kernel.org, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-pm@vger.kernel.org,
linux-remoteproc@vger.kernel.org, linux-s390@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-um@lists.infradead.org,
linux-xtensa@linux-xtensa.org, netdev@vger.kernel.org,
openipmi-developer@lists.sourceforge.net, rcu@vger.kernel.org,
sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
x86@kernel.org, kernel-dev@igalia.com, kernel@gpiccoli.net,
halves@canonical.com, fabiomirmar@gmail.com,
alejandro.j.jimenez@oracle.com, andriy.shevchenko@linux.intel.com,
arnd@arndb.de, bp@alien8.de, corbet@lwn.net,
d.hatayama@jp.fujitsu.com, dave.hansen@linux.intel.com,
dyoung@redhat.com, Tang, Feng, gregkh@linuxfoundation.org,
mikelley@microsoft.com, hidehiro.kawai.ez@hitachi.com,
jgross@suse.com, john.ogness@linutronix.de, keescook@chromium.org,
luto@kernel.org, mhiramat@kernel.org, mingo@redhat.com,
paulmck@kernel.org, peterz@infradead.org, rostedt@goodmis.org,
senozhatsky@chromium.org, stern@rowland.harvard.edu,
tglx@linutronix.de, vgoyal@redhat.com, vkuznets@redhat.com,
will@kernel.org, Alex Elder, Alexander Gordeev, Anton Ivanov,
Benjamin Herrenschmidt, Bjorn Andersson, Boris Ostrovsky,
Chris Zankel, Christian Borntraeger, Corey Minyard, Dexuan Cui,
H. Peter Anvin, Haiyang Zhang, Heiko Carstens, Helge Deller,
Ivan Kokshaysky, James E.J. Bottomley, James Morse, Johannes Berg,
K. Y. Srinivasan, Mathieu Poirier, Matt Turner,
Mauro Carvalho Chehab, Max Filippov, Michael Ellerman,
Paul Mackerras, Pavel Machek, Richard Weinberger, Robert Richter,
Stefano Stabellini, Stephen Hemminger, Sven Schnelle,
Vasily Gorbik, Wei Liu
In-Reply-To: <06d85642fef24bc482642d669242654b@intel.com>
On 17/05/2022 14:02, Luck, Tony wrote:
>> Tony / Dinh - can I just *skip* this notifier *if kdump* is set or else
>> we run the code as-is? Does that make sense to you?
>
> The "skip" option sounds like it needs some special flag associated with
> an entry on the notifier chain. But there are other notifier chains ... so that
> sounds messy to me.
>
> Just all the notifiers in priority order. If any want to take different actions
> based on kdump status, change the code. That seems more flexible than
> an "all or nothing" approach by skipping.
>
> -Tony
I guess I've expressed myself in a poor way - sorry!
What I'm planning to do in the altera_edac notifier is:
if (kdump_is_set)
return;
/* regular code */
In other words: if the kdump is set, this notifier will be effectively a
nop (although it's gonna be called).
Lemme know your thoughts Tony, if that makes sense.
Thanks,
Guilherme
^ permalink raw reply
* [syzbot] WARNING in nfnetlink_unbind
From: syzbot @ 2022-05-17 18:12 UTC (permalink / raw)
To: ali.abdallah, coreteam, davem, edumazet, fw, kadlec, kuba,
linux-kernel, netdev, netfilter-devel, ozsh, pabeni, pablo, paulb,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: f7b88d9ae91e Merge tag 'linux-can-next-for-5.19-20220516' ..
git tree: net-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=14f791aef00000
kernel config: https://syzkaller.appspot.com/x/.config?x=c05eee2efc702eed
dashboard link: https://syzkaller.appspot.com/bug?extid=afd2d80e495f96049571
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13ba8ae9f00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13ef1295f00000
The issue was bisected to:
commit 2794cdb0b97bfe62d25c996c8afe4832207e78bc
Author: Florian Westphal <fw@strlen.de>
Date: Mon Apr 25 13:15:41 2022 +0000
netfilter: nfnetlink: allow to detect if ctnetlink listeners exist
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13cb5bbef00000
final oops: https://syzkaller.appspot.com/x/report.txt?x=102b5bbef00000
console output: https://syzkaller.appspot.com/x/log.txt?x=17cb5bbef00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+afd2d80e495f96049571@syzkaller.appspotmail.com
Fixes: 2794cdb0b97b ("netfilter: nfnetlink: allow to detect if ctnetlink listeners exist")
------------[ cut here ]------------
WARNING: CPU: 0 PID: 3600 at net/netfilter/nfnetlink.c:703 nfnetlink_unbind net/netfilter/nfnetlink.c:703 [inline]
WARNING: CPU: 0 PID: 3600 at net/netfilter/nfnetlink.c:703 nfnetlink_unbind+0x357/0x3b0 net/netfilter/nfnetlink.c:694
Modules linked in:
CPU: 0 PID: 3600 Comm: syz-executor186 Not tainted 5.18.0-rc6-syzkaller-01545-gf7b88d9ae91e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:nfnetlink_unbind net/netfilter/nfnetlink.c:703 [inline]
RIP: 0010:nfnetlink_unbind+0x357/0x3b0 net/netfilter/nfnetlink.c:694
Code: f9 48 c7 c2 00 0d d8 8a be b7 02 00 00 48 c7 c7 60 0d d8 8a c6 05 91 3d 14 06 01 e8 38 36 9b 01 e9 6e fd ff ff e8 09 66 e8 f9 <0f> 0b 41 c7 04 24 ff ff ff ff e9 9d fe ff ff e8 a5 7a 34 fa e9 dd
RSP: 0018:ffffc90002e8fcf8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88801bd11d80 RSI: ffffffff8790d397 RDI: 0000000000000003
RBP: ffffffff90947640 R08: 0000000000000000 R09: ffffc90002e8fc37
R10: ffffffff8790d1e8 R11: 0000000000000001 R12: ffff8880230b4d20
R13: ffff88814c73b000 R14: ffff888016aab518 R15: ffff888016aab000
FS: 0000555557248300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020001280 CR3: 000000001f866000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
netlink_setsockopt+0x932/0xda0 net/netlink/af_netlink.c:1661
__sys_setsockopt+0x2db/0x6a0 net/socket.c:2227
__do_sys_setsockopt net/socket.c:2238 [inline]
__se_sys_setsockopt net/socket.c:2235 [inline]
__x64_sys_setsockopt+0xba/0x150 net/socket.c:2235
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f37f8e5faf9
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffef051fc88 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f37f8e5faf9
RDX: 0000000000000002 RSI: 000000000000010e RDI: 0000000000000003
RBP: 00007f37f8e23ca0 R08: 0000000000000004 R09: 0000000000000000
R10: 0000000020001280 R11: 0000000000000246 R12: 00007f37f8e23d30
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [syzbot] KASAN: use-after-free Read in nf_confirm
From: syzbot @ 2022-05-17 18:12 UTC (permalink / raw)
To: ali.abdallah, coreteam, davem, edumazet, fw, kadlec, kuba,
linux-kernel, netdev, netfilter-devel, ozsh, pabeni, pablo, paulb,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: d887ae3247e0 octeontx2-pf: Remove unnecessary synchronize_..
git tree: net-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=17f2b659f00000
kernel config: https://syzkaller.appspot.com/x/.config?x=b1aab282dc5dd920
dashboard link: https://syzkaller.appspot.com/bug?extid=793a590957d9c1b96620
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1313dce6f00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=169eb59ef00000
The issue was bisected to:
commit 1397af5bfd7d32b0cf2adb70a78c9a9e8f11d912
Author: Florian Westphal <fw@strlen.de>
Date: Mon Apr 11 11:01:18 2022 +0000
netfilter: conntrack: remove the percpu dying list
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13a8d006f00000
final oops: https://syzkaller.appspot.com/x/report.txt?x=1068d006f00000
console output: https://syzkaller.appspot.com/x/log.txt?x=17a8d006f00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+793a590957d9c1b96620@syzkaller.appspotmail.com
Fixes: 1397af5bfd7d ("netfilter: conntrack: remove the percpu dying list")
==================================================================
BUG: KASAN: use-after-free in __nf_ct_ext_exist include/net/netfilter/nf_conntrack_extend.h:47 [inline]
BUG: KASAN: use-after-free in nf_ct_ext_exist include/net/netfilter/nf_conntrack_extend.h:52 [inline]
BUG: KASAN: use-after-free in nf_ct_ecache_exist include/net/netfilter/nf_conntrack_ecache.h:42 [inline]
BUG: KASAN: use-after-free in nf_conntrack_confirm include/net/netfilter/nf_conntrack_core.h:63 [inline]
BUG: KASAN: use-after-free in nf_confirm+0x575/0x5b0 net/netfilter/nf_conntrack_proto.c:154
Read of size 1 at addr ffff88801b035304 by task kworker/1:0/22
CPU: 1 PID: 22 Comm: kworker/1:0 Not tainted 5.18.0-rc6-syzkaller-01525-gd887ae3247e0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: krxrpcd rxrpc_peer_keepalive_worker
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313
print_report mm/kasan/report.c:429 [inline]
kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
__nf_ct_ext_exist include/net/netfilter/nf_conntrack_extend.h:47 [inline]
nf_ct_ext_exist include/net/netfilter/nf_conntrack_extend.h:52 [inline]
nf_ct_ecache_exist include/net/netfilter/nf_conntrack_ecache.h:42 [inline]
nf_conntrack_confirm include/net/netfilter/nf_conntrack_core.h:63 [inline]
nf_confirm+0x575/0x5b0 net/netfilter/nf_conntrack_proto.c:154
ipv4_confirm+0x17a/0x390 net/netfilter/nf_conntrack_proto.c:182
nf_hook_entry_hookfn include/linux/netfilter.h:142 [inline]
nf_hook_slow+0xc5/0x1f0 net/netfilter/core.c:620
nf_hook+0x1cb/0x5b0 include/linux/netfilter.h:262
NF_HOOK_COND include/linux/netfilter.h:295 [inline]
ip_output+0x21f/0x310 net/ipv4/ip_output.c:430
dst_output include/net/dst.h:451 [inline]
ip_local_out net/ipv4/ip_output.c:126 [inline]
ip_send_skb+0xd4/0x260 net/ipv4/ip_output.c:1571
udp_send_skb+0x6c8/0x11a0 net/ipv4/udp.c:967
udp_sendmsg+0x1bee/0x2760 net/ipv4/udp.c:1254
inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:734
rxrpc_send_keepalive+0x1f6/0x370 net/rxrpc/output.c:665
rxrpc_peer_keepalive_dispatch net/rxrpc/peer_event.c:332 [inline]
rxrpc_peer_keepalive_worker+0x7cf/0xc20 net/rxrpc/peer_event.c:396
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
</TASK>
Allocated by task 2972:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:436 [inline]
____kasan_kmalloc mm/kasan/common.c:515 [inline]
____kasan_kmalloc mm/kasan/common.c:474 [inline]
__kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:524
kmalloc include/linux/slab.h:581 [inline]
kernfs_get_open_node fs/kernfs/file.c:547 [inline]
kernfs_fop_open+0xa3f/0xe00 fs/kernfs/file.c:693
do_dentry_open+0x4a1/0x11e0 fs/open.c:824
do_open fs/namei.c:3476 [inline]
path_openat+0x1c71/0x2910 fs/namei.c:3609
do_filp_open+0x1aa/0x400 fs/namei.c:3636
do_sys_openat2+0x16d/0x4c0 fs/open.c:1213
do_sys_open fs/open.c:1229 [inline]
__do_sys_openat fs/open.c:1245 [inline]
__se_sys_openat fs/open.c:1240 [inline]
__x64_sys_openat+0x13f/0x1f0 fs/open.c:1240
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 22:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:366 [inline]
____kasan_slab_free+0x166/0x1a0 mm/kasan/common.c:328
kasan_slab_free include/linux/kasan.h:200 [inline]
slab_free_hook mm/slub.c:1728 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1754
slab_free mm/slub.c:3510 [inline]
kfree+0xd6/0x4d0 mm/slub.c:4552
nf_conntrack_free+0x100/0x630 net/netfilter/nf_conntrack_core.c:1680
nf_ct_destroy+0x1be/0x320 net/netfilter/nf_conntrack_core.c:610
nf_ct_put include/net/netfilter/nf_conntrack.h:184 [inline]
nf_ct_put include/net/netfilter/nf_conntrack.h:181 [inline]
__nf_ct_resolve_clash+0x624/0x785 net/netfilter/nf_conntrack_core.c:1013
nf_ct_resolve_clash+0x14a/0xa23 net/netfilter/nf_conntrack_core.c:1136
__nf_conntrack_confirm.cold+0x16/0x23e net/netfilter/nf_conntrack_core.c:1284
nf_conntrack_confirm include/net/netfilter/nf_conntrack_core.h:62 [inline]
nf_confirm+0x4ce/0x5b0 net/netfilter/nf_conntrack_proto.c:154
ipv4_confirm+0x17a/0x390 net/netfilter/nf_conntrack_proto.c:182
nf_hook_entry_hookfn include/linux/netfilter.h:142 [inline]
nf_hook_slow+0xc5/0x1f0 net/netfilter/core.c:620
nf_hook+0x1cb/0x5b0 include/linux/netfilter.h:262
NF_HOOK_COND include/linux/netfilter.h:295 [inline]
ip_output+0x21f/0x310 net/ipv4/ip_output.c:430
dst_output include/net/dst.h:451 [inline]
ip_local_out net/ipv4/ip_output.c:126 [inline]
ip_send_skb+0xd4/0x260 net/ipv4/ip_output.c:1571
udp_send_skb+0x6c8/0x11a0 net/ipv4/udp.c:967
udp_sendmsg+0x1bee/0x2760 net/ipv4/udp.c:1254
inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:734
rxrpc_send_keepalive+0x1f6/0x370 net/rxrpc/output.c:665
rxrpc_peer_keepalive_dispatch net/rxrpc/peer_event.c:332 [inline]
rxrpc_peer_keepalive_worker+0x7cf/0xc20 net/rxrpc/peer_event.c:396
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
The buggy address belongs to the object at ffff88801b035300
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 4 bytes inside of
128-byte region [ffff88801b035300, ffff88801b035380)
The buggy address belongs to the physical page:
page:ffffea00006c0d40 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1b035
flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000200 ffffea0000664000 dead000000000005 ffff888010c418c0
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 2967, tgid 2967 (udevd), ts 23818493455, free_ts 23818009574
prep_new_page mm/page_alloc.c:2441 [inline]
get_page_from_freelist+0xba2/0x3e00 mm/page_alloc.c:4182
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5408
alloc_pages+0x1aa/0x310 mm/mempolicy.c:2272
alloc_slab_page mm/slub.c:1799 [inline]
allocate_slab+0x26c/0x3c0 mm/slub.c:1944
new_slab mm/slub.c:2004 [inline]
___slab_alloc+0x8df/0xf20 mm/slub.c:3005
__slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3092
slab_alloc_node mm/slub.c:3183 [inline]
slab_alloc mm/slub.c:3225 [inline]
kmem_cache_alloc_trace+0x310/0x3f0 mm/slub.c:3256
kmalloc include/linux/slab.h:581 [inline]
kernfs_get_open_node fs/kernfs/file.c:547 [inline]
kernfs_fop_open+0xa3f/0xe00 fs/kernfs/file.c:693
do_dentry_open+0x4a1/0x11e0 fs/open.c:824
do_open fs/namei.c:3476 [inline]
path_openat+0x1c71/0x2910 fs/namei.c:3609
do_filp_open+0x1aa/0x400 fs/namei.c:3636
do_sys_openat2+0x16d/0x4c0 fs/open.c:1213
do_sys_open fs/open.c:1229 [inline]
__do_sys_openat fs/open.c:1245 [inline]
__se_sys_openat fs/open.c:1240 [inline]
__x64_sys_openat+0x13f/0x1f0 fs/open.c:1240
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1356 [inline]
free_pcp_prepare+0x549/0xd20 mm/page_alloc.c:1406
free_unref_page_prepare mm/page_alloc.c:3328 [inline]
free_unref_page+0x19/0x6a0 mm/page_alloc.c:3423
__unfreeze_partials+0x17c/0x1a0 mm/slub.c:2523
qlink_free mm/kasan/quarantine.c:157 [inline]
qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:176
kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:283
__kasan_slab_alloc+0xa2/0xc0 mm/kasan/common.c:446
kasan_slab_alloc include/linux/kasan.h:224 [inline]
slab_post_alloc_hook mm/slab.h:749 [inline]
slab_alloc_node mm/slub.c:3217 [inline]
kmem_cache_alloc_node+0x255/0x3f0 mm/slub.c:3267
__alloc_skb+0x215/0x340 net/core/skbuff.c:414
alloc_skb include/linux/skbuff.h:1426 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1191 [inline]
netlink_sendmsg+0x9a2/0xe10 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:734
____sys_sendmsg+0x6eb/0x810 net/socket.c:2460
___sys_sendmsg+0xf3/0x170 net/socket.c:2514
__sys_sendmsg net/socket.c:2543 [inline]
__do_sys_sendmsg net/socket.c:2552 [inline]
__se_sys_sendmsg net/socket.c:2550 [inline]
__x64_sys_sendmsg+0x132/0x220 net/socket.c:2550
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Memory state around the buggy address:
ffff88801b035200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88801b035280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88801b035300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88801b035380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88801b035400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [syzbot] UBSAN: array-index-out-of-bounds in nfnetlink_unbind
From: syzbot @ 2022-05-17 18:12 UTC (permalink / raw)
To: ali.abdallah, coreteam, davem, edumazet, fw, kadlec, kuba,
linux-kernel, netdev, netfilter-devel, ozsh, pabeni, pablo, paulb,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: d887ae3247e0 octeontx2-pf: Remove unnecessary synchronize_..
git tree: net-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=118621f1f00000
kernel config: https://syzkaller.appspot.com/x/.config?x=b1aab282dc5dd920
dashboard link: https://syzkaller.appspot.com/bug?extid=4903218f7fba0a2d6226
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17c775bef00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1428ee59f00000
The issue was bisected to:
commit 2794cdb0b97bfe62d25c996c8afe4832207e78bc
Author: Florian Westphal <fw@strlen.de>
Date: Mon Apr 25 13:15:41 2022 +0000
netfilter: nfnetlink: allow to detect if ctnetlink listeners exist
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14885b35f00000
final oops: https://syzkaller.appspot.com/x/report.txt?x=16885b35f00000
console output: https://syzkaller.appspot.com/x/log.txt?x=12885b35f00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4903218f7fba0a2d6226@syzkaller.appspotmail.com
Fixes: 2794cdb0b97b ("netfilter: nfnetlink: allow to detect if ctnetlink listeners exist")
================================================================================
UBSAN: array-index-out-of-bounds in net/netfilter/nfnetlink.c:697:28
index 10 is out of range for type 'int [10]'
CPU: 1 PID: 3606 Comm: syz-executor222 Not tainted 5.18.0-rc6-syzkaller-01525-gd887ae3247e0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
ubsan_epilogue+0xb/0x50 lib/ubsan.c:151
__ubsan_handle_out_of_bounds.cold+0x62/0x6c lib/ubsan.c:283
nfnetlink_unbind+0x38c/0x3b0 net/netfilter/nfnetlink.c:697
netlink_release+0xa8f/0x1db0 net/netlink/af_netlink.c:773
__sock_release+0xcd/0x280 net/socket.c:650
sock_close+0x18/0x20 net/socket.c:1365
__fput+0x277/0x9d0 fs/file_table.c:317
task_work_run+0xdd/0x1a0 kernel/task_work.c:164
exit_task_work include/linux/task_work.h:37 [inline]
do_exit+0xaff/0x2a00 kernel/exit.c:795
do_group_exit+0xd2/0x2f0 kernel/exit.c:925
__do_sys_exit_group kernel/exit.c:936 [inline]
__se_sys_exit_group kernel/exit.c:934 [inline]
__x64_sys_exit_group+0x3a/0x50 kernel/exit.c:934
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f23ae868639
Code: Unable to access opcode bytes at RIP 0x7f23ae86860f.
RSP: 002b:00007ffe9dd00178 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00007f23ae8dc270 RCX: 00007f23ae868639
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffffffffffc0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f23ae8dc270
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
</TASK>
================================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH v5] net: usb: r8152: Add in new Devices that are supported for Mac-Passthru
From: David Ober @ 2022-05-17 18:05 UTC (permalink / raw)
To: linux-usb, netdev, davem, hayeswang, aaron.ma, bjorn
Cc: markpearson, dober, David Ober
Lenovo Thunderbolt 4 Dock, and other Lenovo USB Docks are using the
original Realtek USB ethernet Vendor and Product IDs
If the Network device is Realtek verify that it is on a Lenovo USB hub
before enabling the passthru feature
This also adds in the device IDs for the Lenovo USB Dongle and one other
USB-C dock
V2 fix formating of code
V3 remove Generic define for Device ID 0x8153 and change it to use value
V4 rearrange defines and case statement to put them in better order
v5 create helper function to do the testing work as suggested
Signed-off-by: David Ober <dober6023@gmail.com>
---
drivers/net/usb/r8152.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c2da3438387c..7389d6ef8569 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -771,7 +771,9 @@ enum rtl8152_flags {
};
#define DEVICE_ID_THINKPAD_THUNDERBOLT3_DOCK_GEN2 0x3082
+#define DEVICE_ID_THINKPAD_USB_C_DONGLE 0x720c
#define DEVICE_ID_THINKPAD_USB_C_DOCK_GEN2 0xa387
+#define DEVICE_ID_THINKPAD_USB_C_DOCK_GEN3 0x3062
struct tally_counter {
__le64 tx_packets;
@@ -9562,6 +9564,29 @@ u8 rtl8152_get_version(struct usb_interface *intf)
}
EXPORT_SYMBOL_GPL(rtl8152_get_version);
+static bool rtl8152_supports_lenovo_macpassthru(struct usb_device *udev)
+{
+ int parent_vendor_id = le16_to_cpu(udev->parent->descriptor.idVendor);
+ int product_id = le16_to_cpu(udev->descriptor.idProduct);
+ int vendor_id = le16_to_cpu(udev->descriptor.idVendor);
+
+ if (vendor_id == VENDOR_ID_LENOVO) {
+ switch (product_id) {
+ case DEVICE_ID_THINKPAD_THUNDERBOLT3_DOCK_GEN2:
+ case DEVICE_ID_THINKPAD_USB_C_DOCK_GEN2:
+ case DEVICE_ID_THINKPAD_USB_C_DOCK_GEN3:
+ case DEVICE_ID_THINKPAD_USB_C_DONGLE:
+ return 1;
+ }
+ } else if (vendor_id == VENDOR_ID_REALTEK && parent_vendor_id == VENDOR_ID_LENOVO) {
+ switch (product_id) {
+ case 0x8153:
+ return 1;
+ }
+ }
+ return 0;
+}
+
static int rtl8152_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -9642,13 +9667,7 @@ static int rtl8152_probe(struct usb_interface *intf,
netdev->hw_features &= ~NETIF_F_RXCSUM;
}
- if (le16_to_cpu(udev->descriptor.idVendor) == VENDOR_ID_LENOVO) {
- switch (le16_to_cpu(udev->descriptor.idProduct)) {
- case DEVICE_ID_THINKPAD_THUNDERBOLT3_DOCK_GEN2:
- case DEVICE_ID_THINKPAD_USB_C_DOCK_GEN2:
- tp->lenovo_macpassthru = 1;
- }
- }
+ tp->lenovo_macpassthru = rtl8152_supports_lenovo_macpassthru(udev);
if (le16_to_cpu(udev->descriptor.bcdDevice) == 0x3011 && udev->serial &&
(!strcmp(udev->serial, "000001000000") ||
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v6 0/3] document dt-schema for some USB Ethernet controllers
From: Rob Herring @ 2022-05-17 18:05 UTC (permalink / raw)
To: Oleksij Rempel
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Krzysztof Kozlowski, kernel, netdev, linux-kernel, devicetree
In-Reply-To: <20220517111505.929722-1-o.rempel@pengutronix.de>
On Tue, May 17, 2022 at 01:15:02PM +0200, Oleksij Rempel wrote:
> changes v6:
> - remove USB hub example from microchip,lan95xx.yaml. We care only about
> ethernet node.
> - use only documented USD ID in example.
> - add Reviewed-by
> - drop board patches, all of them are taken by different subsystem
> maintainers.
>
> changes v5:
> - move compatible string changes to a separate patch
> - add note about possible regressions
>
> changes v4:
> - reword commit logs.
> - add note about compatible fix
>
> Oleksij Rempel (3):
> dt-bindings: net: add schema for ASIX USB Ethernet controllers
> dt-bindings: net: add schema for Microchip/SMSC LAN95xx USB Ethernet
> controllers
> dt-bindings: usb: ci-hdrc-usb2: fix node node for ethernet controller
Series applied, thanks.
Rob
^ permalink raw reply
* [PATCH v4] bpf: Fix KASAN use-after-free Read in compute_effective_progs
From: Tadeusz Struk @ 2022-05-17 18:04 UTC (permalink / raw)
To: andrii.nakryiko
Cc: Tadeusz Struk, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, netdev, bpf, stable, linux-kernel,
syzbot+f264bffdfbd5614f3bb2
In-Reply-To: <CAEf4BzY-p13huoqo6N7LJRVVj8rcjPeP3Cp=KDX4N2x9BkC9Zw@mail.gmail.com>
Syzbot found a Use After Free bug in compute_effective_progs().
The reproducer creates a number of BPF links, and causes a fault
injected alloc to fail, while calling bpf_link_detach on them.
Link detach triggers the link to be freed by bpf_link_free(),
which calls __cgroup_bpf_detach() and update_effective_progs().
If the memory allocation in this function fails, the function restores
the pointer to the bpf_cgroup_link on the cgroup list, but the memory
gets freed just after it returns. After this, every subsequent call to
update_effective_progs() causes this already deallocated pointer to be
dereferenced in prog_list_length(), and triggers KASAN UAF error.
To fix this issue don't preserve the pointer to the prog or link in the
list, but remove it and replace it with a dummy prog without shrinking
the table. The subsequent call to __cgroup_bpf_detach() or
__cgroup_bpf_detach() will correct it.
Cc: "Alexei Starovoitov" <ast@kernel.org>
Cc: "Daniel Borkmann" <daniel@iogearbox.net>
Cc: "Andrii Nakryiko" <andrii@kernel.org>
Cc: "Martin KaFai Lau" <kafai@fb.com>
Cc: "Song Liu" <songliubraving@fb.com>
Cc: "Yonghong Song" <yhs@fb.com>
Cc: "John Fastabend" <john.fastabend@gmail.com>
Cc: "KP Singh" <kpsingh@kernel.org>
Cc: <netdev@vger.kernel.org>
Cc: <bpf@vger.kernel.org>
Cc: <stable@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Link: https://syzkaller.appspot.com/bug?id=8ebf179a95c2a2670f7cf1ba62429ec044369db4
Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")
Reported-by: <syzbot+f264bffdfbd5614f3bb2@syzkaller.appspotmail.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
---
v2: Add a fall back path that removes a prog from the effective progs
table in case detach fails to allocate memory in compute_effective_progs().
v3: Implement the fallback in a separate function purge_effective_progs
v4: Changed purge_effective_progs() to manipulate the array in a similar way
how replace_effective_prog() does it.
---
kernel/bpf/cgroup.c | 68 +++++++++++++++++++++++++++++++++++++++------
1 file changed, 60 insertions(+), 8 deletions(-)
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 128028efda64..6f1a6160c99e 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -681,6 +681,60 @@ static struct bpf_prog_list *find_detach_entry(struct list_head *progs,
return ERR_PTR(-ENOENT);
}
+/**
+ * purge_effective_progs() - After compute_effective_progs fails to alloc new
+ * cgrp->bpf.inactive table we can recover by
+ * recomputing the array in place.
+ *
+ * @cgrp: The cgroup which descendants to travers
+ * @prog: A program to detach or NULL
+ * @link: A link to detach or NULL
+ * @atype: Type of detach operation
+ */
+static void purge_effective_progs(struct cgroup *cgrp, struct bpf_prog *prog,
+ struct bpf_cgroup_link *link,
+ enum cgroup_bpf_attach_type atype)
+{
+ struct cgroup_subsys_state *css;
+ struct bpf_prog_array *progs;
+ struct bpf_prog_list *pl;
+ struct list_head *head;
+ struct cgroup *cg;
+ int pos;
+
+ /* recompute effective prog array in place */
+ css_for_each_descendant_pre(css, &cgrp->self) {
+ struct cgroup *desc = container_of(css, struct cgroup, self);
+
+ if (percpu_ref_is_zero(&desc->bpf.refcnt))
+ continue;
+
+ /* find position of link or prog in effective progs array */
+ for (pos = 0, cg = desc; cg; cg = cgroup_parent(cg)) {
+ if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))
+ continue;
+
+ head = &cg->bpf.progs[atype];
+ list_for_each_entry(pl, head, node) {
+ if (!prog_list_prog(pl))
+ continue;
+ if (pl->prog == prog && pl->link == link)
+ goto found;
+ pos++;
+ }
+ }
+found:
+ BUG_ON(!cg);
+ progs = rcu_dereference_protected(
+ desc->bpf.effective[atype],
+ lockdep_is_held(&cgroup_mutex));
+
+ /* Remove the program from the array */
+ WARN_ONCE(bpf_prog_array_delete_safe_at(progs, pos),
+ "Failed to purge a prog from array at index %d", pos);
+ }
+}
+
/**
* __cgroup_bpf_detach() - Detach the program or link from a cgroup, and
* propagate the change to descendants
@@ -723,8 +777,12 @@ static int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
pl->link = NULL;
err = update_effective_progs(cgrp, atype);
- if (err)
- goto cleanup;
+ if (err) {
+ /* If update affective array failed replace the prog with a dummy prog*/
+ pl->prog = old_prog;
+ pl->link = link;
+ purge_effective_progs(cgrp, old_prog, link, atype);
+ }
/* now can actually delete it from this cgroup list */
list_del(&pl->node);
@@ -736,12 +794,6 @@ static int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
bpf_prog_put(old_prog);
static_branch_dec(&cgroup_bpf_enabled_key[atype]);
return 0;
-
-cleanup:
- /* restore back prog or link */
- pl->prog = old_prog;
- pl->link = link;
- return err;
}
static int cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
--
2.36.1
^ permalink raw reply related
* [PATCH net 1/1] igb: skip phy status check where unavailable
From: Tony Nguyen @ 2022-05-17 18:01 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: Kevin Mitchell, netdev, anthony.l.nguyen, Gurucharan
From: Kevin Mitchell <kevmitch@arista.com>
igb_read_phy_reg() will silently return, leaving phy_data untouched, if
hw->ops.read_reg isn't set. Depending on the uninitialized value of
phy_data, this led to the phy status check either succeeding immediately
or looping continuously for 2 seconds before emitting a noisy err-level
timeout. This message went out to the console even though there was no
actual problem.
Instead, first check if there is read_reg function pointer. If not,
proceed without trying to check the phy status register.
Fixes: b72f3f72005d ("igb: When GbE link up, wait for Remote receiver status condition")
Signed-off-by: Kevin Mitchell <kevmitch@arista.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 34b33b21e0dc..68be2976f539 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5505,7 +5505,8 @@ static void igb_watchdog_task(struct work_struct *work)
break;
}
- if (adapter->link_speed != SPEED_1000)
+ if (adapter->link_speed != SPEED_1000 ||
+ !hw->phy.ops.read_reg)
goto no_wait;
/* wait for Remote receiver status OK */
--
2.35.1
^ permalink raw reply related
* Re: [PATCH net-next] net: ifdefy the wireless pointers in struct net_device
From: Johannes Berg @ 2022-05-17 18:03 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, alex.aring, stefan, mareklindner,
sw, a, sven, linux-wireless, linux-wpan
In-Reply-To: <20220517104443.68756db3@kernel.org>
On Tue, 2022-05-17 at 10:44 -0700, Jakub Kicinski wrote:
>
> Would you be willing to do that as a follow up?
>
Sure.
> Are you talking about
> wifi only or all the proto pointers?
Well it only makes sense if at least two protocols join forces :-)
> As a netdev maintainer I'd like to reduce the divergence in whether
> the proto pointers are ifdef'd or not.
>
Sure, no objection to the ifdef.
johannes
^ permalink raw reply
* [PATCH net 1/2] mptcp: fix checksum byte order
From: Mat Martineau @ 2022-05-17 18:02 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, davem, kuba, edumazet, matthieu.baerts, mptcp,
Mat Martineau
In-Reply-To: <20220517180212.92597-1-mathew.j.martineau@linux.intel.com>
From: Paolo Abeni <pabeni@redhat.com>
The MPTCP code typecasts the checksum value to u16 and
then converts it to big endian while storing the value into
the MPTCP option.
As a result, the wire encoding for little endian host is
wrong, and that causes interoperabilty interoperability
issues with other implementation or host with different endianness.
Address the issue writing in the packet the unmodified __sum16 value.
MPTCP checksum is disabled by default, interoperating with systems
with bad mptcp-level csum encoding should cause fallback to TCP.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/275
Fixes: c5b39e26d003 ("mptcp: send out checksum for DSS")
Fixes: 390b95a5fb84 ("mptcp: receive checksum for DSS")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
---
net/mptcp/options.c | 36 ++++++++++++++++++++++++------------
net/mptcp/protocol.h | 2 +-
net/mptcp/subflow.c | 2 +-
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 325383646f5c..b548cec86c9d 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -107,7 +107,7 @@ static void mptcp_parse_option(const struct sk_buff *skb,
ptr += 2;
}
if (opsize == TCPOLEN_MPTCP_MPC_ACK_DATA_CSUM) {
- mp_opt->csum = (__force __sum16)get_unaligned_be16(ptr);
+ mp_opt->csum = get_unaligned((__force __sum16 *)ptr);
mp_opt->suboptions |= OPTION_MPTCP_CSUMREQD;
ptr += 2;
}
@@ -221,7 +221,7 @@ static void mptcp_parse_option(const struct sk_buff *skb,
if (opsize == expected_opsize + TCPOLEN_MPTCP_DSS_CHECKSUM) {
mp_opt->suboptions |= OPTION_MPTCP_CSUMREQD;
- mp_opt->csum = (__force __sum16)get_unaligned_be16(ptr);
+ mp_opt->csum = get_unaligned((__force __sum16 *)ptr);
ptr += 2;
}
@@ -1240,7 +1240,7 @@ static void mptcp_set_rwin(const struct tcp_sock *tp)
WRITE_ONCE(msk->rcv_wnd_sent, ack_seq);
}
-u16 __mptcp_make_csum(u64 data_seq, u32 subflow_seq, u16 data_len, __wsum sum)
+__sum16 __mptcp_make_csum(u64 data_seq, u32 subflow_seq, u16 data_len, __wsum sum)
{
struct csum_pseudo_header header;
__wsum csum;
@@ -1256,15 +1256,25 @@ u16 __mptcp_make_csum(u64 data_seq, u32 subflow_seq, u16 data_len, __wsum sum)
header.csum = 0;
csum = csum_partial(&header, sizeof(header), sum);
- return (__force u16)csum_fold(csum);
+ return csum_fold(csum);
}
-static u16 mptcp_make_csum(const struct mptcp_ext *mpext)
+static __sum16 mptcp_make_csum(const struct mptcp_ext *mpext)
{
return __mptcp_make_csum(mpext->data_seq, mpext->subflow_seq, mpext->data_len,
~csum_unfold(mpext->csum));
}
+static void put_len_csum(u16 len, __sum16 csum, void *data)
+{
+ __sum16 *sumptr = data + 2;
+ __be16 *ptr = data;
+
+ put_unaligned_be16(len, ptr);
+
+ put_unaligned(csum, sumptr);
+}
+
void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
struct mptcp_out_options *opts)
{
@@ -1340,8 +1350,9 @@ void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
put_unaligned_be32(mpext->subflow_seq, ptr);
ptr += 1;
if (opts->csum_reqd) {
- put_unaligned_be32(mpext->data_len << 16 |
- mptcp_make_csum(mpext), ptr);
+ put_len_csum(mpext->data_len,
+ mptcp_make_csum(mpext),
+ ptr);
} else {
put_unaligned_be32(mpext->data_len << 16 |
TCPOPT_NOP << 8 | TCPOPT_NOP, ptr);
@@ -1392,11 +1403,12 @@ void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
goto mp_capable_done;
if (opts->csum_reqd) {
- put_unaligned_be32(opts->data_len << 16 |
- __mptcp_make_csum(opts->data_seq,
- opts->subflow_seq,
- opts->data_len,
- ~csum_unfold(opts->csum)), ptr);
+ put_len_csum(opts->data_len,
+ __mptcp_make_csum(opts->data_seq,
+ opts->subflow_seq,
+ opts->data_len,
+ ~csum_unfold(opts->csum)),
+ ptr);
} else {
put_unaligned_be32(opts->data_len << 16 |
TCPOPT_NOP << 8 | TCPOPT_NOP, ptr);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index f4ce28bb0fdc..fb40dd676a26 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -723,7 +723,7 @@ void mptcp_token_destroy(struct mptcp_sock *msk);
void mptcp_crypto_key_sha(u64 key, u32 *token, u64 *idsn);
void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hmac);
-u16 __mptcp_make_csum(u64 data_seq, u32 subflow_seq, u16 data_len, __wsum sum);
+__sum16 __mptcp_make_csum(u64 data_seq, u32 subflow_seq, u16 data_len, __wsum sum);
void __init mptcp_pm_init(void);
void mptcp_pm_data_init(struct mptcp_sock *msk);
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 8c37087f0d84..e90fe7eec43a 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -888,7 +888,7 @@ static enum mapping_status validate_data_csum(struct sock *ssk, struct sk_buff *
{
struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
u32 offset, seq, delta;
- u16 csum;
+ __sum16 csum;
int len;
if (!csum_reqd)
--
2.36.1
^ permalink raw reply related
* [PATCH net 0/2] mptcp: Fix checksum byte order on little-endian
From: Mat Martineau @ 2022-05-17 18:02 UTC (permalink / raw)
To: netdev; +Cc: Mat Martineau, davem, kuba, pabeni, edumazet, matthieu.baerts,
mptcp
These patches address a bug in the byte ordering of MPTCP checksums on
little-endian architectures. The __sum16 type is always big endian, but
was being cast to u16 and then byte-swapped (on little-endian archs)
when reading/writing the checksum field in MPTCP option headers.
MPTCP checksums are off by default, but are enabled if one or both peers
request it in the SYN/SYNACK handshake.
The corrected code is verified to interoperate between big-endian and
little-endian machines.
Patch 1 fixes the checksum byte order, patch 2 partially mitigates
interoperation with peers sending bad checksums by falling back to TCP
instead of resetting the connection.
Mat Martineau (1):
mptcp: Do TCP fallback on early DSS checksum failure
Paolo Abeni (1):
mptcp: fix checksum byte order
net/mptcp/options.c | 36 ++++++++++++++++++++++++------------
net/mptcp/protocol.h | 5 +++--
net/mptcp/subflow.c | 23 +++++++++++++++++++----
3 files changed, 46 insertions(+), 18 deletions(-)
base-commit: edf410cb74dc612fd47ef5be319c5a0bcd6e6ccd
--
2.36.1
^ permalink raw reply
* [PATCH net 2/2] mptcp: Do TCP fallback on early DSS checksum failure
From: Mat Martineau @ 2022-05-17 18:02 UTC (permalink / raw)
To: netdev; +Cc: Mat Martineau, davem, kuba, pabeni, edumazet, matthieu.baerts,
mptcp
In-Reply-To: <20220517180212.92597-1-mathew.j.martineau@linux.intel.com>
RFC 8684 section 3.7 describes several opportunities for a MPTCP
connection to "fall back" to regular TCP early in the connection
process, before it has been confirmed that MPTCP options can be
successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
acknowledges the first received data packet with a regular TCP header
(no MPTCP options), fallback is allowed.
If the recipient of that first data packet finds a MPTCP DSS checksum
error, this provides an opportunity to fail gracefully with a TCP
fallback rather than resetting the connection (as might happen if a
checksum failure were detected later).
This commit modifies the checksum failure code to attempt fallback on
the initial subflow of a MPTCP connection, only if it's a failure in the
first data mapping. In cases where the peer initiates the connection,
requests checksums, is the first to send data, and the peer is sending
incorrect checksums (see
https://github.com/multipath-tcp/mptcp_net-next/issues/275), this allows
the connection to proceed as TCP rather than reset.
Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
---
net/mptcp/protocol.h | 3 ++-
net/mptcp/subflow.c | 21 ++++++++++++++++++---
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index fb40dd676a26..5655a63aa6a8 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -443,7 +443,8 @@ struct mptcp_subflow_context {
can_ack : 1, /* only after processing the remote a key */
disposable : 1, /* ctx can be free at ulp release time */
stale : 1, /* unable to snd/rcv data, do not use for xmit */
- local_id_valid : 1; /* local_id is correctly initialized */
+ local_id_valid : 1, /* local_id is correctly initialized */
+ valid_csum_seen : 1; /* at least one csum validated */
enum mptcp_data_avail data_avail;
u32 remote_nonce;
u64 thmac;
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index e90fe7eec43a..be76ada89d96 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -955,11 +955,14 @@ static enum mapping_status validate_data_csum(struct sock *ssk, struct sk_buff *
subflow->map_data_csum);
if (unlikely(csum)) {
MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DATACSUMERR);
- subflow->send_mp_fail = 1;
- MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_MPFAILTX);
+ if (subflow->mp_join || subflow->valid_csum_seen) {
+ subflow->send_mp_fail = 1;
+ MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_MPFAILTX);
+ }
return subflow->mp_join ? MAPPING_INVALID : MAPPING_DUMMY;
}
+ subflow->valid_csum_seen = 1;
return MAPPING_OK;
}
@@ -1141,6 +1144,18 @@ static void subflow_sched_work_if_closed(struct mptcp_sock *msk, struct sock *ss
}
}
+static bool subflow_can_fallback(struct mptcp_subflow_context *subflow)
+{
+ struct mptcp_sock *msk = mptcp_sk(subflow->conn);
+
+ if (subflow->mp_join)
+ return false;
+ else if (READ_ONCE(msk->csum_enabled))
+ return !subflow->valid_csum_seen;
+ else
+ return !subflow->fully_established;
+}
+
static bool subflow_check_data_avail(struct sock *ssk)
{
struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
@@ -1218,7 +1233,7 @@ static bool subflow_check_data_avail(struct sock *ssk)
return true;
}
- if (subflow->mp_join || subflow->fully_established) {
+ if (!subflow_can_fallback(subflow)) {
/* fatal protocol error, close the socket.
* subflow_error_report() will introduce the appropriate barriers
*/
--
2.36.1
^ permalink raw reply related
* Re: [PATCHv2 net] bonding: fix missed rcu protection
From: Jakub Kicinski @ 2022-05-17 17:54 UTC (permalink / raw)
To: Hangbin Liu
Cc: netdev, Jay Vosburgh, Veaceslav Falico, Andy Gospodarek,
David S . Miller, David Ahern, Jonathan Toppins, Eric Dumazet,
Paolo Abeni, syzbot+92beb3d46aab498710fa, Vladimir Oltean
In-Reply-To: <20220517082312.805824-1-liuhangbin@gmail.com>
On Tue, 17 May 2022 16:23:12 +0800 Hangbin Liu wrote:
> + rcu_read_lock();
> real_dev = bond_option_active_slave_get_rcu(bond);
> if (real_dev) {
> + dev_hold(real_dev);
> + rcu_read_unlock();
> ops = real_dev->ethtool_ops;
> phydev = real_dev->phydev;
>
> if (phy_has_tsinfo(phydev)) {
> - return phy_ts_info(phydev, info);
> + ret = phy_ts_info(phydev, info);
> + goto out;
> } else if (ops->get_ts_info) {
> - return ops->get_ts_info(real_dev, info);
> + ret = ops->get_ts_info(real_dev, info);
> + goto out;
> }
> + } else {
> + rcu_read_unlock();
> }
>
> info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE |
> SOF_TIMESTAMPING_SOFTWARE;
> info->phc_index = -1;
>
> - return 0;
> +out:
> + if (real_dev)
> + dev_put(real_dev);
dev_hold() and dev_put() can take NULL these days, for better or worse.
I think the code simplification is worth making use of that, even tho
it will make the backport slightly more tricky (perhaps make a not of
this in the commit message).
^ permalink raw reply
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c
From: Max Staudt @ 2022-05-17 17:52 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Marc Kleine-Budde, Vincent MAILHOL, linux-can, linux-kernel,
netdev
In-Reply-To: <e51a64cd-1130-9c65-2bde-483c63f6aa10@hartkopp.net>
On Tue, 17 May 2022 17:50:03 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> On 17.05.22 17:38, Max Staudt wrote:
> > I'm a bit lost - what would CAN_DEV_SW do?
>
> It should be just *one* enabler of building can-dev-ko
>
> > If it enables can_dropped_invalid_skb(), then the HW drivers would
> > also need to depend on CAN_DEV_SW directly or indirectly, or am I
> > missing something?
>
> And CAN_DEV is another enabler that would build the skb stuff from
> CAN_DEV_SW too (but also the netlink stuff).
>
> That's what I meant with "some Makefile magic" which is then building
> the can-dev.ko with the required features depending on CAN_DEV_SW,
> CAN_DEV, CAN_DEV_RX_OFFLOAD, CAN_CALC_BITTIMING, etc
Ah, I see!
Sounds good :)
Max
^ 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