* Re: [Patch v13 4/9] wifi: mac80211: Add support for WBRF features
From: Ilpo Järvinen @ 2023-11-02 12:24 UTC (permalink / raw)
To: Johannes Berg
Cc: Ma Jun, amd-gfx, lenb, davem, edumazet, kuba, pabeni,
alexander.deucher, Lijo.Lazar, mario.limonciello, Netdev,
linux-wireless, LKML, linux-doc, platform-driver-x86, majun,
Evan Quan
In-Reply-To: <b080757463a1f55a38484e3ea39fd3697e98409e.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
On Thu, 2 Nov 2023, Johannes Berg wrote:
> On Thu, 2023-11-02 at 13:55 +0200, Ilpo Järvinen wrote:
>
> > > +static void get_chan_freq_boundary(u32 center_freq, u32 bandwidth, u64 *start, u64 *end)
> > > +{
> > > + bandwidth = MHZ_TO_KHZ(bandwidth);
> > > + center_freq = MHZ_TO_KHZ(center_freq);
> >
> > Please use include/linux/units.h ones for these too.
>
> Now we're feature creeping though - this has existed for *years* in the
> wireless stack with many instances? We can convert them over, I guess,
> but not sure that makes much sense here - we'd want to add such macros
> to units.h, but ... moving them can be independent of this patch?
What new macros you're talking about? Nothing new needs to be added
as there's already KHZ_PER_MHZ so these would just be:
bandwidth *= KHZ_PER_MHZ;
center_freq *= KHZ_PER_MHZ;
Everything can of course be postponed by the argument that some
subsystem specific mechanism has been there before the generic one
but the end of that road won't be pretty... What I was trying to do
here was to point out the new stuff introduced by this series into the
direction of the generic thing.
--
i.
^ permalink raw reply
* Re: [PATCH net-next v2 8/9] microchip: lan865x: add driver support for Microchip's LAN865X MACPHY
From: Ramón Nordin Rodriguez @ 2023-11-02 12:20 UTC (permalink / raw)
To: Parthiban Veerasooran
Cc: davem, edumazet, kuba, pabeni, robh+dt, krzysztof.kozlowski+dt,
conor+dt, corbet, steen.hegelund, rdunlap, horms, casper.casan,
andrew, netdev, devicetree, linux-kernel, linux-doc,
horatiu.vultur, Woojung.Huh, Nicolas.Ferre, UNGLinuxDriver,
Thorsten.Kummermehr
In-Reply-To: <20231023154649.45931-9-Parthiban.Veerasooran@microchip.com>
On Mon, Oct 23, 2023 at 09:16:48PM +0530, Parthiban Veerasooran wrote:
> The LAN8650/1 is designed to conform to the OPEN Alliance 10BASE‑T1x
> MAC‑PHY Serial Interface specification, Version 1.1. The IEEE Clause 4
> MAC integration provides the low pin count standard SPI interface to any
> microcontroller therefore providing Ethernet functionality without
> requiring MAC integration within the microcontroller. The LAN8650/1
> operates as an SPI client supporting SCLK clock rates up to a maximum of
> 25 MHz. This SPI interface supports the transfer of both data (Ethernet
> frames) and control (register access).
>
> By default, the chunk data payload is 64 bytes in size. A smaller payload
> data size of 32 bytes is also supported and may be configured in the
> Chunk Payload Size (CPS) field of the Configuration 0 (OA_CONFIG0)
> register. Changing the chunk payload size requires the LAN8650/1 be reset
> and shall not be done during normal operation.
>
> The Ethernet Media Access Controller (MAC) module implements a 10 Mbps
> half duplex Ethernet MAC, compatible with the IEEE 802.3 standard.
> 10BASE-T1S physical layer transceiver integrated into the LAN8650/1. The
> PHY and MAC are connected via an internal Media Independent Interface
> (MII).
>
> Signed-off-by: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
Hi Parthiban
I've been testing the v2 patches out a bit, at Ferroamp we're planning
on using a dual LAN8650 setup in a product.
First let me say that we'd be happy to assist with testing and
development.
I got some observations that I think this patch is the resonable place
to discuss it, since they seem to be MAC/PHY related.
In order to get a reliable link I'm using the dts snippet below (for an
imx8 cpu)
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
cs-gpios = <0> , <&gpio5 9 GPIO_ACTIVE_LOW>;
status = "okay";
spe1: ethernet@1{
compatible = "microchip,lan865x";
reg = <1>;
interrupt-parent = <&gpio5>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
spi-max-frequency = <50000000>;
oa-tc6{
#address-cells = <1>;
#size-cells = <0>;
oa-cps = <32>;
oa-prote;
oa-dprac;
};
};
};
With this setup I'm getting a maximum throughput of about 90kB/s.
If I increase the chunk size / oa-cps to 64 I get a might higher
throughput ~900kB/s, but after 0-2s I get dump below (or similar).
[ 363.444460] eth0: Transmit protocol error
[ 363.448527] eth0: Transmit buffer underflow
[ 363.452740] eth0: Receive buffer overflow
[ 363.456780] eth0: Header error
[ 363.459869] eth0: Footer frame drop
[ 363.463379] eth0: SPI transfer failed
[ 363.470590] eth0: Receive buffer overflow
[ 363.474631] eth0: Header error
[ 363.477776] eth0: SPI transfer failed
[ 363.482596] eth0: Footer frame drop
[ 369.884680] ------------[ cut here ]------------
[ 369.889336] NETDEV WATCHDOG: eth0 (lan865x): transmit queue 0 timed out 6448 ms
[ 369.896726] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x22c/0x234
[ 369.905023] Modules linked in:
[ 369.908091] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.4.16-gc5e8aa9586d6 #3
[ 369.915241] Hardware name: <Ferroamp dev kit>
[ 369.921169] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 369.928146] pc : dev_watchdog+0x22c/0x234
[ 369.932168] lr : dev_watchdog+0x22c/0x234
[ 369.936190] sp : ffff80000800be20
[ 369.939510] x29: ffff80000800be20 x28: 0000000000000101 x27: ffff80000800bf00
[ 369.946665] x26: ffff8000092469c0 x25: 0000000000001930 x24: ffff800009246000
[ 369.953817] x23: 0000000000000000 x22: ffff000000e883dc x21: ffff000000e88000
[ 369.960971] x20: ffff0000010dc000 x19: ffff000000e88488 x18: ffffffffffffffff
[ 369.968124] x17: 383434362074756f x16: 2064656d69742030 x15: 0720072007200720
[ 369.975276] x14: 0720072007200720 x13: ffff80000925fe88 x12: 0000000000000444
[ 369.982431] x11: 000000000000016c x10: ffff8000092b7e88 x9 : ffff80000925fe88
[ 369.989584] x8 : 00000000ffffefff x7 : ffff8000092b7e88 x6 : 80000000fffff000
[ 369.996738] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 370.003890] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000000dd400
[ 370.011044] Call trace:
[ 370.013496] dev_watchdog+0x22c/0x234
[ 370.017173] call_timer_fn.constprop.0+0x24/0x80
[ 370.021802] __run_timers.part.0+0x1f8/0x244
[ 370.026080] run_timer_softirq+0x3c/0x74
[ 370.030012] __do_softirq+0x10c/0x280
[ 370.033683] ____do_softirq+0x10/0x1c
[ 370.037357] call_on_irq_stack+0x24/0x4c
[ 370.041292] do_softirq_own_stack+0x1c/0x28
[ 370.045484] __irq_exit_rcu+0xe4/0x100
[ 370.049244] irq_exit_rcu+0x10/0x1c
[ 370.052744] el1_interrupt+0x38/0x68
[ 370.056331] el1h_64_irq_handler+0x18/0x24
[ 370.060439] el1h_64_irq+0x64/0x68
[ 370.063851] cpuidle_enter_state+0x134/0x2e0
[ 370.068133] cpuidle_enter+0x38/0x50
[ 370.071719] do_idle+0x1f4/0x264
[ 370.074960] cpu_startup_entry+0x24/0x2c
[ 370.078895] secondary_start_kernel+0x130/0x150
[ 370.083440] __secondary_switched+0xb8/0xbc
[ 370.087634] ---[ end trace 0000000000000000 ]---
Additionally when hotplugging cables, which might not be a realworld
scenario I'm also seeing intermittent watchdog timeouts.
In both scenarios the driver does not recover.
^ permalink raw reply
* Re: [PATCH net 6/7] net: hns3: fix VF reset fail issue
From: Jijie Shao @ 2023-11-02 12:16 UTC (permalink / raw)
To: Paolo Abeni, yisen.zhuang, salil.mehta, davem, edumazet, kuba
Cc: shaojijie, shenjian15, wangjie125, liuyonglong, netdev,
linux-kernel
In-Reply-To: <9bc9514044063bc57155fb786f970ca1d69758b4.camel@redhat.com>
on 2023/11/2 18:45, Paolo Abeni wrote:
> On Sat, 2023-10-28 at 10:59 +0800, Jijie Shao wrote:
>>
>> -static void hclgevf_clear_event_cause(struct hclgevf_dev *hdev, u32 regclr)
>> +static void hclgevf_clear_event_cause(struct hclgevf_dev *hdev, u32 regclr,
>> + bool need_dalay)
>> {
>> +#define HCLGEVF_RESET_DELAY 5
>> +
>> + if (need_dalay)
>> + mdelay(HCLGEVF_RESET_DELAY);
> 5ms delay in an interrupt handler is quite a lot. What about scheduling
> a timer from the IH to clear the register when such delay is needed?
>
> Thanks!
>
> Paolo
Using timer in this case will complicate the code and make maintenance difficult.
We consider reducing the delay time by polling. For example,
the code cycles every 50 us to check whether the write register takes effect.
If yes, the function returns immediately. or the code cycles until 5 ms.
Is this method appropriate?
Thanks!
Jijie
^ permalink raw reply
* Re: [RFC 0/7] vdpa: Add support for iommufd
From: Cindy Lu @ 2023-11-02 12:09 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jasowang, yi.l.liu, jgg, linux-kernel, virtualization, netdev
In-Reply-To: <20231102060151-mutt-send-email-mst@kernel.org>
On Thu, Nov 2, 2023 at 6:02 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, Oct 26, 2023 at 02:48:07PM +0800, Cindy Lu wrote:
> > On Thu, Oct 26, 2023 at 2:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Sun, Sep 24, 2023 at 01:05:33AM +0800, Cindy Lu wrote:
> > > > Hi All
> > > > Really apologize for the delay, this is the draft RFC for
> > > > iommufd support for vdpa, This code provides the basic function
> > > > for iommufd support
> > > >
> > > > The code was tested and passed in device vdpa_sim_net
> > > > The qemu code is
> > > > https://gitlab.com/lulu6/gitlabqemutmp/-/tree/iommufdRFC
> > > > The kernel code is
> > > > https://gitlab.com/lulu6/vhost/-/tree/iommufdRFC
> > > >
> > > > ToDo
> > > > 1. this code is out of date and needs to clean and rebase on the latest code
> > > > 2. this code has some workaround, I Skip the check for
> > > > iommu_group and CACHE_COHERENCY, also some misc issues like need to add
> > > > mutex for iommfd operations
> > > > 3. only test in emulated device, other modes not tested yet
> > > >
> > > > After addressed these problems I will send out a new version for RFC. I will
> > > > provide the code in 3 weeks
> > >
> > > What's the status here?
> > >
> > Hi Michael
> > The code is finished, but I found some bug after adding the support for ASID,
> > will post the new version after this bug is fixed, should be next week
> > Thanks
> > Cindy
>
> The week is almost gone, what's going on?
>
thanks, Micheal, I will send it out tomorrow
Thanks
Cindy
>
> > > --
> > > MST
> > >
>
^ permalink raw reply
* Re: [PATCH v1 net 0/2] dccp/tcp: Relocate security_inet_conn_request().
From: patchwork-bot+netdevbpf @ 2023-11-02 12:10 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, dsahern, kuni1840, netdev, dccp
In-Reply-To: <20231030201042.32885-1-kuniyu@amazon.com>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 30 Oct 2023 13:10:40 -0700 you wrote:
> security_inet_conn_request() reads reqsk's remote address, but it's not
> initialised in some places.
>
> Let's make sure the address is set before security_inet_conn_request().
>
>
> Kuniyuki Iwashima (2):
> dccp: Call security_inet_conn_request() after setting IPv4 addresses.
> dccp/tcp: Call security_inet_conn_request() after setting IPv6
> addresses.
>
> [...]
Here is the summary with links:
- [v1,net,1/2] dccp: Call security_inet_conn_request() after setting IPv4 addresses.
https://git.kernel.org/netdev/net/c/fa2df45af130
- [v1,net,2/2] dccp/tcp: Call security_inet_conn_request() after setting IPv6 addresses.
https://git.kernel.org/netdev/net/c/23be1e0e2a83
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] netlink: fill in missing MODULE_DESCRIPTION()
From: Florian Westphal @ 2023-11-02 12:05 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Jakub Kicinski, davem, netdev, edumazet, pabeni
In-Reply-To: <ZUOP7tOSK2ysyuUc@nanopsycho>
Jiri Pirko <jiri@resnulli.us> wrote:
> Thu, Nov 02, 2023 at 05:57:24AM CET, kuba@kernel.org wrote:
> >W=1 builds now warn if a module is built without
> >a MODULE_DESCRIPTION(). Fill it in for sock_diag.
> >
> >Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>
> It's a bit odd to target -net with this, isn't it?
I had planned to fill the missing descriptions for
all netfilter via next nf.git PR as I consider those as
bug fixes.
Thats the regression risk here?
^ permalink raw reply
* Re: [Patch v13 4/9] wifi: mac80211: Add support for WBRF features
From: Johannes Berg @ 2023-11-02 12:04 UTC (permalink / raw)
To: Ilpo Järvinen, Ma Jun
Cc: amd-gfx, lenb, davem, edumazet, kuba, pabeni, alexander.deucher,
Lijo.Lazar, mario.limonciello, Netdev, linux-wireless, LKML,
linux-doc, platform-driver-x86, majun, Evan Quan
In-Reply-To: <5b8ea81c-dd4c-7f2a-c862-b9a0aab16044@linux.intel.com>
On Thu, 2023-11-02 at 13:55 +0200, Ilpo Järvinen wrote:
[please trim your quotes]
> > +static void get_chan_freq_boundary(u32 center_freq, u32 bandwidth, u64 *start, u64 *end)
> > +{
> > + bandwidth = MHZ_TO_KHZ(bandwidth);
> > + center_freq = MHZ_TO_KHZ(center_freq);
>
> Please use include/linux/units.h ones for these too.
Now we're feature creeping though - this has existed for *years* in the
wireless stack with many instances? We can convert them over, I guess,
but not sure that makes much sense here - we'd want to add such macros
to units.h, but ... moving them can be independent of this patch?
johannes
^ permalink raw reply
* Re: [PATCH] net: stmmac: Wait a bit for the reset to take effect
From: Serge Semin @ 2023-11-02 12:03 UTC (permalink / raw)
To: Bernd Edlinger
Cc: Alexandre Torgue, Jose Abreu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, netdev, linux-stm32,
linux-arm-kernel, linux-kernel@vger.kernel.org
In-Reply-To: <AS8P193MB1285473EE92FEDB65C08C131E4A0A@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM>
On Tue, Oct 31, 2023 at 05:10:24PM +0100, Bernd Edlinger wrote:
>
>
> On 10/31/23 11:32, Serge Semin wrote:
> > On Mon, Oct 30, 2023 at 07:01:11AM +0100, Bernd Edlinger wrote:
> >> otherwise the synopsys_id value may be read out wrong,
> >> because the GMAC_VERSION register might still be in reset
> >> state, for at least 1 us after the reset is de-asserted.
> >
> > From what have you got that delay value?
> >
>
> Just try and error, with very old linux versions and old gcc versions
> the synopsys_id was read out correctly most of the time (but not always),
> with recent linux versions and recnet gcc versions it was read out
> wrongly most of the time, but again not always.
> I don't have access to the VHDL code in question, so I cannot
> tell why it takes so long to get the correct values, I also do not
> have more than a few hardware samples, so I cannot tell how long
> this timeout must be in worst case.
> Experimentally I can tell that the register is read several times
> as zero immediately after the reset is de-asserted, also adding several
> no-ops is not enough, adding a printk is enough, also udelay(1) seems to
> be enough but I tried that not very often, and I have not access to many
> hardware samples to be 100% sure about the necessary delay.
> And since the udelay here is only executed once per device instance,
> it seems acceptable to delay the boot for 10 us.
>
> BTW: my hardware's synopsys id is 0x37.
Well, the delay value is highly hardware-dependent depending on the
IP-core version, generation (MAC1000, GMAC, QoS Eth, XGMAC, XLGMAC,
etc), IP-core synthesize parameters and finally the platform-specific
ref clocks implementation and their rates. So no matter how many you
try to figure out a safest value I guess you won't be able to find out
the common value for all the devices. Though seeing nobody has
reported so far any problem with that then it seems rare among the DW
*MAC* devices. So since you get to a add a very small delay in just a
perf non-critical path it won't hurt for the rest of the platforms.
But please very thoroughly define the problem in the commit message:
what hardware you have (SoC, platform, etc), in what conditions you
see the problem (what you already described in your reply to me), how
you've got to the 10us value, etc. It will be useful in case if
somebody would want for instance make the delay platform-dependent or
whatever.
-Serge(y)
>
>
> Bernd.
>
> > -Serge(y)
> >
> >>
> >> Add a wait for 10 us before continuing to be on the safe side.
> >>
> >> Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
> >> ---
> >> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> index 5801f4d50f95..e485f4db3605 100644
> >> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> @@ -7398,6 +7398,9 @@ int stmmac_dvr_probe(struct device *device,
> >> dev_err(priv->device, "unable to bring out of ahb reset: %pe\n",
> >> ERR_PTR(ret));
> >>
> >> + /* Wait a bit for the reset to take effect */
> >> + udelay(10);
> >> +
> >> /* Init MAC and get the capabilities */
> >> ret = stmmac_hw_init(priv);
> >> if (ret)
> >> --
> >> 2.39.2
> >>
> >>
^ permalink raw reply
* Re: [PATCH net] netlink: fill in missing MODULE_DESCRIPTION()
From: Jiri Pirko @ 2023-11-02 12:02 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, edumazet, pabeni
In-Reply-To: <20231102045724.2516647-1-kuba@kernel.org>
Thu, Nov 02, 2023 at 05:57:24AM CET, kuba@kernel.org wrote:
>W=1 builds now warn if a module is built without
>a MODULE_DESCRIPTION(). Fill it in for sock_diag.
>
>Signed-off-by: Jakub Kicinski <kuba@kernel.org>
It's a bit odd to target -net with this, isn't it?
^ permalink raw reply
* Re: [PATCH net] net/smc: fix documentation of buffer sizes
From: patchwork-bot+netdevbpf @ 2023-11-02 12:00 UTC (permalink / raw)
To: Gerd Bayer
Cc: davem, edumazet, kuba, pabeni, corbet, jaka, wenjia, tonylu,
netdev, linux-doc, linux-kernel
In-Reply-To: <20231030170343.748097-1-gbayer@linux.ibm.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 30 Oct 2023 18:03:43 +0100 you wrote:
> Since commit 833bac7ec392 ("net/smc: Fix setsockopt and sysctl to
> specify same buffer size again") the SMC protocol uses its own
> default values for the smc.rmem and smc.wmem sysctl variables
> which are no longer derived from the TCP IPv4 buffer sizes.
>
> Fixup the kernel documentation to reflect this change, too.
>
> [...]
Here is the summary with links:
- [net] net/smc: fix documentation of buffer sizes
https://git.kernel.org/netdev/net/c/a1602d749097
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Patch v13 4/9] wifi: mac80211: Add support for WBRF features
From: Ilpo Järvinen @ 2023-11-02 11:55 UTC (permalink / raw)
To: Ma Jun
Cc: amd-gfx, lenb, johannes, davem, edumazet, kuba, pabeni,
alexander.deucher, Lijo.Lazar, mario.limonciello, Netdev,
linux-wireless, LKML, linux-doc, platform-driver-x86, majun,
Evan Quan
In-Reply-To: <20231030071832.2217118-5-Jun.Ma2@amd.com>
On Mon, 30 Oct 2023, Ma Jun wrote:
> From: Evan Quan <quanliangl@hotmail.com>
>
> To support the WBRF mechanism, Wifi adapters utilized in the system must
> register the frequencies in use (or unregister those frequencies no longer
> used) via the dedicated calls. So that, other drivers responding to the
> frequencies can take proper actions to mitigate possible interference.
>
> Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> Co-developed-by: Evan Quan <quanliangl@hotmail.com>
> Signed-off-by: Evan Quan <quanliangl@hotmail.com>
> Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
> --
> v1->v2:
> - place the new added member(`wbrf_supported`) in
> ieee80211_local(Johannes)
> - handle chandefs change scenario properly(Johannes)
> - some minor fixes around code sharing and possible invalid input
> checks(Johannes)
> v2->v3:
> - drop unnecessary input checks and intermediate APIs(Mario)
> - Separate some mac80211 common code(Mario, Johannes)
> v3->v4:
> - some minor fixes around return values(Johannes)
> v9->v10:
> - get ranges_in->num_of_ranges set and passed in(Johannes)
> v12:
> - use acpi_amd_wbrf_add_remove to replace the acpi_amd_wbrf_add_exclusion
> acpi_amd_wbrf_remove_exclusion
> v13:
> - Fix the format issue (IIpo Jarvinen)
> - Remove KHZ_TO_HZ and use HZ_PER_KHZ in linux/units.h (IIpo Jarvinen)
> ---
> net/mac80211/Makefile | 2 +
> net/mac80211/chan.c | 9 ++++
> net/mac80211/ieee80211_i.h | 7 +++
> net/mac80211/main.c | 2 +
> net/mac80211/wbrf.c | 95 ++++++++++++++++++++++++++++++++++++++
> 5 files changed, 115 insertions(+)
> create mode 100644 net/mac80211/wbrf.c
>
> diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
> index b8de44da1fb8..d46c36f55fd3 100644
> --- a/net/mac80211/Makefile
> +++ b/net/mac80211/Makefile
> @@ -65,4 +65,6 @@ rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS) += \
>
> mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-y)
>
> +mac80211-y += wbrf.o
> +
> ccflags-y += -DDEBUG
> diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
> index 68952752b599..458469c224ae 100644
> --- a/net/mac80211/chan.c
> +++ b/net/mac80211/chan.c
> @@ -506,11 +506,16 @@ static void _ieee80211_change_chanctx(struct ieee80211_local *local,
>
> WARN_ON(!cfg80211_chandef_compatible(&ctx->conf.def, chandef));
>
> + ieee80211_remove_wbrf(local, &ctx->conf.def);
> +
> ctx->conf.def = *chandef;
>
> /* check if min chanctx also changed */
> changed = IEEE80211_CHANCTX_CHANGE_WIDTH |
> _ieee80211_recalc_chanctx_min_def(local, ctx, rsvd_for);
> +
> + ieee80211_add_wbrf(local, &ctx->conf.def);
> +
> drv_change_chanctx(local, ctx, changed);
>
> if (!local->use_chanctx) {
> @@ -668,6 +673,8 @@ static int ieee80211_add_chanctx(struct ieee80211_local *local,
> lockdep_assert_held(&local->mtx);
> lockdep_assert_held(&local->chanctx_mtx);
>
> + ieee80211_add_wbrf(local, &ctx->conf.def);
> +
> if (!local->use_chanctx)
> local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
>
> @@ -748,6 +755,8 @@ static void ieee80211_del_chanctx(struct ieee80211_local *local,
> }
>
> ieee80211_recalc_idle(local);
> +
> + ieee80211_remove_wbrf(local, &ctx->conf.def);
> }
>
> static void ieee80211_free_chanctx(struct ieee80211_local *local,
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 98ef1fe1226e..1172554bd831 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -1600,6 +1600,8 @@ struct ieee80211_local {
>
> /* extended capabilities provided by mac80211 */
> u8 ext_capa[8];
> +
> + bool wbrf_supported;
> };
>
> static inline struct ieee80211_sub_if_data *
> @@ -2637,4 +2639,9 @@ ieee80211_eht_cap_ie_to_sta_eht_cap(struct ieee80211_sub_if_data *sdata,
> const struct ieee80211_eht_cap_elem *eht_cap_ie_elem,
> u8 eht_cap_len,
> struct link_sta_info *link_sta);
> +
> +void ieee80211_check_wbrf_support(struct ieee80211_local *local);
> +void ieee80211_add_wbrf(struct ieee80211_local *local, struct cfg80211_chan_def *chandef);
> +void ieee80211_remove_wbrf(struct ieee80211_local *local, struct cfg80211_chan_def *chandef);
> +
> #endif /* IEEE80211_I_H */
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index 24315d7b3126..b20bdaac84db 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -1396,6 +1396,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> debugfs_hw_add(local);
> rate_control_add_debugfs(local);
>
> + ieee80211_check_wbrf_support(local);
> +
> rtnl_lock();
> wiphy_lock(hw->wiphy);
>
> diff --git a/net/mac80211/wbrf.c b/net/mac80211/wbrf.c
> new file mode 100644
> index 000000000000..ca3f30b58476
> --- /dev/null
> +++ b/net/mac80211/wbrf.c
> @@ -0,0 +1,95 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Wifi Band Exclusion Interface for WLAN
> + * Copyright (C) 2023 Advanced Micro Devices
> + *
> + */
> +
> +#include <linux/acpi_amd_wbrf.h>
> +#include <linux/units.h>
> +#include <net/cfg80211.h>
> +#include "ieee80211_i.h"
> +
> +void ieee80211_check_wbrf_support(struct ieee80211_local *local)
> +{
> + struct wiphy *wiphy = local->hw.wiphy;
> + struct device *dev;
> +
> + if (!wiphy)
> + return;
> +
> + dev = wiphy->dev.parent;
> + if (!dev)
> + return;
> +
> + local->wbrf_supported = acpi_amd_wbrf_supported_producer(dev);
> + dev_dbg(dev, "WBRF is %s supported\n",
> + local->wbrf_supported ? "" : "not");
> +}
> +
> +static void get_chan_freq_boundary(u32 center_freq, u32 bandwidth, u64 *start, u64 *end)
> +{
> + bandwidth = MHZ_TO_KHZ(bandwidth);
> + center_freq = MHZ_TO_KHZ(center_freq);
Please use include/linux/units.h ones for these too.
--
i.
^ permalink raw reply
* Re: [PATCH] net: ipmr_base: Check iif when returning a (*, G) MFC
From: Yang Sun @ 2023-11-02 11:52 UTC (permalink / raw)
To: Ido Schimmel
Cc: davem, dsahern, edumazet, kuba, pabeni, netdev, nicolas.dichtel
In-Reply-To: <ZUNxcxMq8EW0cVUT@shredder>
> Is this a regression (doesn't seem that way)? If not, the change should
> be targeted at net-next which is closed right now:
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
I see.
> > - if (c->mfc_un.res.ttls[vifi] < 255)
> > + if (c->mfc_parent == vifi && c->mfc_un.res.ttls[vifi] < 255)
> What happens if the route doesn't have an iif (-1)? It won't match
> anymore?
Looks like the mfc_parent can't be -1? There is the check:
if (mfc->mf6cc_parent >= MAXMIFS)
return -ENFILE;
before setting the parent:
c->_c.mfc_parent = mfc->mf6cc_parent;
I wrote this patch thinking (*, G) MFCs could be per iif, similar to the
(S, G) MFCs, like we can add the following MFCs to forward packets from
any address with group destination ff05::aa from if1 to if2, and forward
packets from any address with group destination ff05::aa from if2 to
both if1 and if3.
(::, ff05::aa) Iif: if1 Oifs: if1 if2 State: resolved
(::, ff05::aa) Iif: if2 Oifs: if1 if2 if3 State: resolved
But reading Nicolas's initial commit message again, it seems to me that
(*, G) has to be used together with (*, *) and there should be only one
(*, G) entry per group address and include all relevant interfaces in
the oifs? Like the following:
(::, ::) Iif: if1 Oifs: if1 if2 if3 State: resolved
(::, ff05::aa) Iif: if1 Oifs: if1 if2 if3 State: resolved
Is this how the (*, *|G) MFCs are intended to be used? which means packets
to ff05::aa are forwarded from any one of the interfaces to all the other
interfaces? If this is the intended way it works then my patch would break
things and should be rejected.
Is there a way to achieve the use case I described above? Like having
different oifs for different iif?
Thanks!
On Thu, Nov 2, 2023 at 5:52 PM Ido Schimmel <idosch@idosch.org> wrote:
>
> + Nicolas
>
> On Tue, Oct 31, 2023 at 09:57:56AM +0800, Yang Sun wrote:
> > Looking for a (*, G) MFC returns the first match without checking
> > the iif. This can return a MFC not intended for a packet's iif and
> > forwarding the packet with this MFC will not work correctly.
> >
> > When looking up for a (*, G) MFC, check that the MFC's iif is
> > the same as the packet's iif.
>
> Is this a regression (doesn't seem that way)? If not, the change should
> be targeted at net-next which is closed right now:
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> >
> > Signed-off-by: Yang Sun <sunytt@google.com>
> > ---
> > net/ipv4/ipmr_base.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/ipmr_base.c b/net/ipv4/ipmr_base.c
> > index 271dc03fc6db..5cf7c7088dfe 100644
> > --- a/net/ipv4/ipmr_base.c
> > +++ b/net/ipv4/ipmr_base.c
> > @@ -97,7 +97,7 @@ void *mr_mfc_find_any(struct mr_table *mrt, int vifi, void *hasharg)
> >
> > list = rhltable_lookup(&mrt->mfc_hash, hasharg, *mrt->ops.rht_params);
> > rhl_for_each_entry_rcu(c, tmp, list, mnode) {
> > - if (c->mfc_un.res.ttls[vifi] < 255)
> > + if (c->mfc_parent == vifi && c->mfc_un.res.ttls[vifi] < 255)
>
> What happens if the route doesn't have an iif (-1)? It won't match
> anymore?
>
> > return c;
> >
> > /* It's ok if the vifi is part of the static tree */
> > --
> > 2.42.0.820.g83a721a137-goog
> >
> >
^ permalink raw reply
* Re: [PATCH v2 11/13] ip_tunnel: convert __be16 tunnel flags to bitmaps
From: Alexander Lobakin @ 2023-11-02 11:48 UTC (permalink / raw)
To: Yury Norov, Alexander Potapenko, Jakub Kicinski
Cc: Andy Shevchenko, Rasmus Villemoes, Eric Dumazet, David Ahern,
Przemek Kitszel, Simon Horman, netdev, linux-btrfs, dm-devel,
ntfs3, linux-s390, linux-kernel
In-Reply-To: <ZTJy/7PMX/kGw2EL@yury-ThinkPad>
From: Yury Norov <yury.norov@gmail.com>
Date: Fri, 20 Oct 2023 05:30:55 -0700
> On Fri, Oct 20, 2023 at 09:41:10AM +0200, Alexander Potapenko wrote:
>> On Thu, Oct 19, 2023 at 2:27 AM Jakub Kicinski <kuba@kernel.org> wrote:
>>>
>>> On Mon, 16 Oct 2023 18:52:45 +0200 Alexander Lobakin wrote:
>>>> 40 files changed, 715 insertions(+), 415 deletions(-)
>>>
>>> This already has at least two conflicts with networking if I'm looking
>>> right. Please let the pre-req's go in via Yury's tree and then send
>>> this for net-next in the next release cycle.
(to Kuba) Sounds good!
>>
>> Yury, Andy,
>>
>> The MTE part of my series will need to be reworked, so it might take a while.
>> Shall I maybe send v8 of
>> https://lore.kernel.org/lkml/20231011172836.2579017-1-glider@google.com/
>> (plus the test) separately to unblock Alexander?
>
> You better ask Alexander :). No objections from me.
Sure thing, I need some time to fix the series tho, so take your time :)
And yeah, I've seen that you already sent it.
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH net] net: page_pool: add missing free_percpu when page_pool_init fail
From: patchwork-bot+netdevbpf @ 2023-11-02 11:50 UTC (permalink / raw)
To: Jijie Shao
Cc: hawk, ilias.apalodimas, davem, edumazet, kuba, pabeni, jdamato,
shenjian15, wangjie125, liuyonglong, linyunsheng, netdev,
linux-kernel
In-Reply-To: <20231030091256.2915394-1-shaojijie@huawei.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 30 Oct 2023 17:12:56 +0800 you wrote:
> From: Jian Shen <shenjian15@huawei.com>
>
> When ptr_ring_init() returns failure in page_pool_init(), free_percpu()
> is not called to free pool->recycle_stats, which may cause memory
> leak.
>
> Fixes: ad6fa1e1ab1b ("page_pool: Add recycle stats")
> Signed-off-by: Jian Shen <shenjian15@huawei.com>
> Signed-off-by: Jijie Shao <shaojijie@huawei.com>
>
> [...]
Here is the summary with links:
- [net] net: page_pool: add missing free_percpu when page_pool_init fail
https://git.kernel.org/netdev/net/c/8ffbd1669ed1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v1 net] net: ethtool: Fix documentation of ethtool_sprintf()
From: patchwork-bot+netdevbpf @ 2023-11-02 11:30 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, alexanderduyck, justinstitt, stable
In-Reply-To: <20231028192511.100001-1-andrew@lunn.ch>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sat, 28 Oct 2023 21:25:11 +0200 you wrote:
> This function takes a pointer to a pointer, unlike sprintf() which is
> passed a plain pointer. Fix up the documentation to make this clear.
>
> Fixes: 7888fe53b706 ("ethtool: Add common function for filling out strings")
> Cc: Alexander Duyck <alexanderduyck@fb.com>
> Cc: Justin Stitt <justinstitt@google.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>
> [...]
Here is the summary with links:
- [v1,net] net: ethtool: Fix documentation of ethtool_sprintf()
https://git.kernel.org/netdev/net/c/f55d8e60f109
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: stmmac: Wait a bit for the reset to take effect
From: Paolo Abeni @ 2023-11-02 11:25 UTC (permalink / raw)
To: Bernd Edlinger, Alexandre Torgue, Jose Abreu, David S. Miller,
Eric Dumazet, Jakub Kicinski, Maxime Coquelin, netdev,
linux-stm32, linux-arm-kernel, linux-kernel@vger.kernel.org
In-Reply-To: <AS8P193MB1285DECD77863E02EF45828BE4A1A@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM>
On Mon, 2023-10-30 at 07:01 +0100, Bernd Edlinger wrote:
> otherwise the synopsys_id value may be read out wrong,
> because the GMAC_VERSION register might still be in reset
> state, for at least 1 us after the reset is de-asserted.
>
> Add a wait for 10 us before continuing to be on the safe side.
This looks like a bugfix: you should target explicitly the 'net' tree,
adding such tag into the subj. More importantly you should include a
suitable 'Fixes' tag.
Please send a new revision with the above changes. You can retain the
already collected reviewed tags.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net-next V2] ptp: fix corrupted list in ptp_open
From: Edward Adam Davis @ 2023-11-02 11:16 UTC (permalink / raw)
To: richardcochran
Cc: davem, eadavis, linux-kernel, netdev, reibax,
syzbot+df3f3ef31f60781fa911, syzkaller-bugs
In-Reply-To: <ZULphe-5N0M5x_Kk@hoboy.vegasvil.org>
On Wed, 1 Nov 2023 17:12:53 -0700 Richard Cochran wrote:
>> There is no lock protection when writing ptp->tsevqs in ptp_open(),
>> ptp_release(), which can cause data corruption,
>
>Really? How?
Let me show the corruption that occurs in ptp_open() and ptp_release(),
1. Corruption that appears in ptp_open(),
Link: https://syzkaller.appspot.com/bug?extid=df3f3ef31f60781fa911
list_add corruption. prev->next should be next (ffff88814a1325e8), but was ffff888078d25048. (prev=ffff888078d21048).
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:32!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 7237 Comm: syz-executor182 Not tainted 6.6.0-rc6-next-20231020-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023
RIP: 0010:__list_add_valid_or_report+0xb6/0x100 lib/list_debug.c:32
Code: e8 2f a5 3a fd 0f 0b 48 89 d9 48 c7 c7 40 9d e9 8a e8 1e a5 3a fd 0f 0b 48 89 f1 48 c7 c7 c0 9d e9 8a 48 89 de e8 0a a5 3a fd <0f> 0b 48 89 f2 48 89 d9 48 89 ee 48 c7 c7 40 9e e9 8a e8 f3 a4 3a
RSP: 0018:ffffc90009b3f898 EFLAGS: 00010286
RAX: 0000000000000075 RBX: ffff88814a1325e8 RCX: ffffffff816bb8d9
RDX: 0000000000000000 RSI: ffffffff816c4d42 RDI: 0000000000000005
RBP: ffff88807c7a9048 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000080000000 R11: 0000000000000001 R12: ffff88814a132000
R13: ffffc90009b3f900 R14: ffff888078d21048 R15: ffff88807c7a9048
FS: 0000555556c00380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffef0aa1138 CR3: 000000007d17e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__list_add_valid include/linux/list.h:88 [inline]
__list_add include/linux/list.h:150 [inline]
list_add_tail include/linux/list.h:183 [inline]
ptp_open+0x1c5/0x4f0 drivers/ptp/ptp_chardev.c:122
posix_clock_open+0x17e/0x240 kernel/time/posix-clock.c:134
chrdev_open+0x26d/0x6e0 fs/char_dev.c:414
do_dentry_open+0x8d4/0x18d0 fs/open.c:948
do_open fs/namei.c:3621 [inline]
path_openat+0x1d36/0x2cd0 fs/namei.c:3778
do_filp_open+0x1dc/0x430 fs/namei.c:3808
do_sys_openat2+0x176/0x1e0 fs/open.c:1440
do_sys_open fs/open.c:1455 [inline]
__do_sys_openat fs/open.c:1471 [inline]
__se_sys_openat fs/open.c:1466 [inline]
__x64_sys_openat+0x175/0x210 fs/open.c:1466
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7fc6c2099ae9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffef0aa1238 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc6c2099ae9
RDX: 0000000000000000 RSI: 0000000020000300 RDI: ffffffffffffff9c
RBP: 00000000000f4240 R08: 0000000000000000 R09: 00000000000000a0
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000130fc
R13: 00007ffef0aa124c R14: 00007ffef0aa1260 R15: 00007ffef0aa1250
</TASK>
2. Corruption that appears in ptp_open(),
Link: https://syzkaller.appspot.com/x/log.txt?x=169a58d1680000
list_del corruption. prev->next should be ffff8880280e5048, but was ffff888025dc1048. (prev=ffff88814adb1048)
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:62!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 13142 Comm: syz-executor.2 Not tainted 6.6.0-rc6-next-20231018-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023
RIP: 0010:__list_del_entry_valid_or_report+0x11f/0x1b0
Code: 8f e9 8a e8 c3 d3 3a fd 0f 0b 48 89 ca 48 c7 c7 e0 8f e9 8a e8 b2 d3 3a fd 0f 0b 48 89 c2 48 c7 c7 40 90 e9 8a e8 a1 d3 3a fd <0f> 0b 48 89 d1 48 c7 c7 c0 90 e9 8a 48 89 c2 e8 8d d3 3a fd 0f 0b
RSP: 0018:ffffc90003167e08 EFLAGS: 00010086
RAX: 000000000000006d RBX: ffff8880280e4000 RCX: ffffffff816b9cd9
RDX: 0000000000000000 RSI: ffffffff816c3142 RDI: 0000000000000005
RBP: ffff888023b7c480 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000080000001 R11: 0000000000000001 R12: 0000000000000293
R13: ffff8880280e5008 R14: ffff8880280e5048 R15: ffff8880280e5050
FS: 00005555557e3480(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f350fd98000 CR3: 000000002427a000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ptp_release+0xca/0x2a0
posix_clock_release+0xa4/0x160
__fput+0x270/0xbb0
__fput_sync+0x47/0x50
__x64_sys_close+0x87/0xf0
do_syscall_64+0x3f/0x110
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The above two logs can clearly indicate that there is corruption when
executing the operation of writing ptp->tsevqs in ptp_open() and ptp_release().
>
>> use mutex lock to avoid this
>> issue.
>>
>> Moreover, ptp_release() should not be used to release the queue in ptp_read(),
>> and it should be deleted together.
>>
>> Reported-and-tested-by: syzbot+df3f3ef31f60781fa911@syzkaller.appspotmail.com
>> Fixes: 8f5de6fb2453 ("ptp: support multiple timestamp event readers")
>> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
>> ---
>> drivers/ptp/ptp_chardev.c | 11 +++++++++--
>> drivers/ptp/ptp_clock.c | 3 +++
>> drivers/ptp/ptp_private.h | 1 +
>> 3 files changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
>> index 282cd7d24077..e31551d2697d 100644
>> --- a/drivers/ptp/ptp_chardev.c
>> +++ b/drivers/ptp/ptp_chardev.c
>> @@ -109,6 +109,9 @@ int ptp_open(struct posix_clock_context *pccontext, fmode_t fmode)
>> struct timestamp_event_queue *queue;
>> char debugfsname[32];
>>
>> + if (mutex_lock_interruptible(&ptp->tsevq_mux))
>> + return -ERESTARTSYS;
>> +
>
>This mutex is not needed.
>
>Please don't ignore review comments.
Thanks,
edward
^ permalink raw reply
* Re: [PATCH net] dccp: check for ccid in ccid_hc_tx_send_packet
From: Paolo Abeni @ 2023-11-02 11:14 UTC (permalink / raw)
To: Bragatheswaran Manickavel, davem, edumazet, kuba
Cc: dccp, netdev, linux-kernel, syzbot+c71bc336c5061153b502
In-Reply-To: <20231028144136.3462-1-bragathemanick0908@gmail.com>
On Sat, 2023-10-28 at 20:11 +0530, Bragatheswaran Manickavel wrote:
> ccid_hc_tx_send_packet might be called with a NULL ccid pointer
> leading to a NULL pointer dereference
You should describe how such event could happen.
> Below mentioned commit has similarly changes
> commit 276bdb82dedb ("dccp: check ccid before dereferencing")
>
> Reported-by: syzbot+c71bc336c5061153b502@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=c71bc336c5061153b502
and add a suitable fixes here.
(beyond taking care of other critical code paths, as reported by Eric).
Thanks!
Paolo
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: Fix broken build where char is unsigned
From: Anders Roxell @ 2023-11-02 11:14 UTC (permalink / raw)
To: Björn Töpel
Cc: Andrii Nakryiko, Mykola Lysenko, bpf, Daniel Borkmann, netdev,
Björn Töpel, Alexei Starovoitov, linux-kselftest,
linux-kernel, Larysa Zaremba
In-Reply-To: <20231102103537.247336-1-bjorn@kernel.org>
On 2023-11-02 11:35, Björn Töpel wrote:
> From: Björn Töpel <bjorn@rivosinc.com>
>
> There are architectures where char is not signed. If so, the following
> error is triggered:
>
> | xdp_hw_metadata.c:435:42: error: result of comparison of constant -1 \
> | with expression of type 'char' is always true \
> | [-Werror,-Wtautological-constant-out-of-range-compare]
> | 435 | while ((opt = getopt(argc, argv, "mh")) != -1) {
> | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~
> | 1 error generated.
>
> Correct by changing the char to int.
>
> Fixes: bb6a88885fde ("selftests/bpf: Add options and frags to xdp_hw_metadata")
> Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
Thank you for the patch.
I saw the same failure when I built selftests/bpf for arm64.
With this patch ontop of today's next-20231102, fixes that build issue.
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Cheers,
Anders
> ---
> tools/testing/selftests/bpf/xdp_hw_metadata.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/xdp_hw_metadata.c b/tools/testing/selftests/bpf/xdp_hw_metadata.c
> index 17c0f92ff160..c3ba40d0b9de 100644
> --- a/tools/testing/selftests/bpf/xdp_hw_metadata.c
> +++ b/tools/testing/selftests/bpf/xdp_hw_metadata.c
> @@ -430,7 +430,7 @@ static void print_usage(void)
>
> static void read_args(int argc, char *argv[])
> {
> - char opt;
> + int opt;
>
> while ((opt = getopt(argc, argv, "mh")) != -1) {
> switch (opt) {
>
> base-commit: cb3c6a58be50c65014296aa3455cae0fa1e82eac
> --
> 2.40.1
>
^ permalink raw reply
* Re: [PATCH 1/2][net-next] skbuff: move netlink_large_alloc_large_skb() to skbuff.c
From: Yunsheng Lin @ 2023-11-02 11:01 UTC (permalink / raw)
To: Li RongQing, netdev
In-Reply-To: <20231102062836.19074-1-lirongqing@baidu.com>
On 2023/11/2 14:28, Li RongQing wrote:
> move netlink_alloc_large_skb and netlink_skb_destructor to skbuff.c
> and rename them more generic, so they can be used elsewhere large
> non-contiguous physical memory is needed
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> include/linux/skbuff.h | 3 +++
> net/core/skbuff.c | 40 ++++++++++++++++++++++++++++++++++++++++
> net/netlink/af_netlink.c | 41 ++---------------------------------------
> 3 files changed, 45 insertions(+), 39 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 4174c4b..774a401 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -5063,5 +5063,8 @@ static inline void skb_mark_for_recycle(struct sk_buff *skb)
> ssize_t skb_splice_from_iter(struct sk_buff *skb, struct iov_iter *iter,
> ssize_t maxsize, gfp_t gfp);
>
> +
> +void large_skb_destructor(struct sk_buff *skb);
> +struct sk_buff *alloc_large_skb(unsigned int size, int broadcast);
> #endif /* __KERNEL__ */
> #endif /* _LINUX_SKBUFF_H */
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 4570705..20ffcd5 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -6917,3 +6917,43 @@ ssize_t skb_splice_from_iter(struct sk_buff *skb, struct iov_iter *iter,
> return spliced ?: ret;
> }
> EXPORT_SYMBOL(skb_splice_from_iter);
> +
> +void large_skb_destructor(struct sk_buff *skb)
> +{
> + if (is_vmalloc_addr(skb->head)) {
> + if (!skb->cloned ||
> + !atomic_dec_return(&(skb_shinfo(skb)->dataref)))
> + vfree(skb->head);
> +
> + skb->head = NULL;
There seems to be an assumption that skb returned from
netlink_alloc_large_skb() is not expecting the frag page
for shinfo->frags*, as the above NULL setting will bypass
most of the handling in skb_release_data(),then how can we
ensure that the user is not breaking the assumption if we
make it more generic?
> + }
> + if (skb->sk)
> + sock_rfree(skb);
> +}
> +EXPORT_SYMBOL(large_skb_destructor);
> +
^ permalink raw reply
* Re: [syzbot] [net?] [usb?] INFO: rcu detected stall in nsim_dev_trap_report_work (2)
From: syzbot @ 2023-11-02 10:55 UTC (permalink / raw)
To: davem, eadavis, edumazet, idosch, jiri, kuba, leon, linux-kernel,
linux-rdma, linux-usb, netdev, pabeni, petrm, saeedm,
syzkaller-bugs, tariqt
In-Reply-To: <0000000000009ee19a0609135c34@google.com>
syzbot has bisected this issue to:
commit 644a66c60f02f302d82c3008ae2ffe67cf495383
Author: Jiri Pirko <jiri@nvidia.com>
Date: Fri Jul 29 07:10:36 2022 +0000
net: devlink: convert reload command to take implicit devlink->lock
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13c76cf3680000
start commit: 66f1e1ea3548 Add linux-next specific files for 20231027
git tree: linux-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=10276cf3680000
console output: https://syzkaller.appspot.com/x/log.txt?x=17c76cf3680000
kernel config: https://syzkaller.appspot.com/x/.config?x=2911330219149de4
dashboard link: https://syzkaller.appspot.com/bug?extid=193dae06b6680599fbab
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10b8e977680000
Reported-by: syzbot+193dae06b6680599fbab@syzkaller.appspotmail.com
Fixes: 644a66c60f02 ("net: devlink: convert reload command to take implicit devlink->lock")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: Fix broken build where char is unsigned
From: Larysa Zaremba @ 2023-11-02 10:49 UTC (permalink / raw)
To: Björn Töpel
Cc: Andrii Nakryiko, Mykola Lysenko, bpf, Daniel Borkmann, netdev,
Björn Töpel, Alexei Starovoitov, linux-kselftest,
linux-kernel
In-Reply-To: <20231102103537.247336-1-bjorn@kernel.org>
On Thu, Nov 02, 2023 at 11:35:37AM +0100, Björn Töpel wrote:
> From: Björn Töpel <bjorn@rivosinc.com>
>
> There are architectures where char is not signed. If so, the following
> error is triggered:
>
> | xdp_hw_metadata.c:435:42: error: result of comparison of constant -1 \
> | with expression of type 'char' is always true \
> | [-Werror,-Wtautological-constant-out-of-range-compare]
> | 435 | while ((opt = getopt(argc, argv, "mh")) != -1) {
> | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~
> | 1 error generated.
>
> Correct by changing the char to int.
>
> Fixes: bb6a88885fde ("selftests/bpf: Add options and frags to xdp_hw_metadata")
> Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
Acked-by: Larysa Zaremba <larysa.zaremba@intel.com>
> ---
> tools/testing/selftests/bpf/xdp_hw_metadata.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/xdp_hw_metadata.c b/tools/testing/selftests/bpf/xdp_hw_metadata.c
> index 17c0f92ff160..c3ba40d0b9de 100644
> --- a/tools/testing/selftests/bpf/xdp_hw_metadata.c
> +++ b/tools/testing/selftests/bpf/xdp_hw_metadata.c
> @@ -430,7 +430,7 @@ static void print_usage(void)
>
> static void read_args(int argc, char *argv[])
> {
> - char opt;
> + int opt;
>
> while ((opt = getopt(argc, argv, "mh")) != -1) {
> switch (opt) {
>
> base-commit: cb3c6a58be50c65014296aa3455cae0fa1e82eac
> --
> 2.40.1
>
>
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
From: Vladimir Oltean @ 2023-11-02 10:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Lunn, Florian Fainelli, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <CACRpkdYb6v6dpFFySSHdQ0H+KYRDNr2V4ShZTVA2A0ar_h9D=A@mail.gmail.com>
On Tue, Oct 31, 2023 at 10:22:05PM +0100, Linus Walleij wrote:
> Hi Vladimir,
>
> I got around to testing this too:
>
> # ping -s 1472 192.168.1.137
>
> The result:
>
> SKB before padding:
> 37 (192.168.1.13skb len=1514 headroom=18 headlen=1514 tailroom=260
> mac=(18,14) net=(32,20) trans=52
> shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
> csum(0xd4ef2b1 ip_summed=0 complete_sw=0 valid=0 level=0)
> hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0
> 7): 1472 data bydev name=lan0 feat=0x0002000000005020
> tes
> sk family=2 type=3 proto=1
>
> SKB after padding:
> skb len=1518 headroom=18 headlen=1518 tailroom=256
> mac=(18,14) net=(32,20) trans=52
> shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
> csum(0xd4ef2b1 ip_summed=0 complete_sw=0 valid=0 level=0)
> hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0
> dev name=lan0 feat=0x0002000000005020
> sk family=2 type=3 proto=1
>
> As expected the linear SKB is 4 bytes longer in this case.
Ok, I'm not seeing anything unusual about the skb geometry in the
skb_dump() output.
^ permalink raw reply
* Re: [PATCH net 6/7] net: hns3: fix VF reset fail issue
From: Paolo Abeni @ 2023-11-02 10:45 UTC (permalink / raw)
To: Jijie Shao, yisen.zhuang, salil.mehta, davem, edumazet, kuba
Cc: shenjian15, wangjie125, liuyonglong, netdev, linux-kernel
In-Reply-To: <20231028025917.314305-7-shaojijie@huawei.com>
On Sat, 2023-10-28 at 10:59 +0800, Jijie Shao wrote:
> Currently the reset process in hns3 and firmware watchdog init process is
> asynchronous. We think firmware watchdog initialization is completed
> before VF clear the interrupt source. However, firmware initialization
> may not complete early. So VF will receive multiple reset interrupts
> and fail to reset.
>
> So we add delay before VF interrupt source and 5 ms delay
> is enough to avoid second reset interrupt.
>
> Fixes: 427900d27d86 ("net: hns3: fix the timing issue of VF clearing interrupt sources")
> Signed-off-by: Jijie Shao <shaojijie@huawei.com>
> ---
> .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
> index 1c62e58ff6d8..7b87da031be6 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
> @@ -1924,8 +1924,14 @@ static void hclgevf_service_task(struct work_struct *work)
> hclgevf_mailbox_service_task(hdev);
> }
>
> -static void hclgevf_clear_event_cause(struct hclgevf_dev *hdev, u32 regclr)
> +static void hclgevf_clear_event_cause(struct hclgevf_dev *hdev, u32 regclr,
> + bool need_dalay)
> {
> +#define HCLGEVF_RESET_DELAY 5
> +
> + if (need_dalay)
> + mdelay(HCLGEVF_RESET_DELAY);
5ms delay in an interrupt handler is quite a lot. What about scheduling
a timer from the IH to clear the register when such delay is needed?
Thanks!
Paolo
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
From: Vladimir Oltean @ 2023-11-02 10:45 UTC (permalink / raw)
To: Linus Walleij
Cc: Luiz Angelo Daros de Luca, Andrew Lunn, Florian Fainelli,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <CACRpkdaoBo0S0RgLhacObd3pbjtWAfr6s3oizQAHqdB76gaG5A@mail.gmail.com>
On Wed, Nov 01, 2023 at 09:26:50PM +0100, Linus Walleij wrote:
> On Wed, Nov 1, 2023 at 1:35 PM Luiz Angelo Daros de Luca <luizluca@gmail.com> wrote:
>
> > Sorry but I noticed no issues:
>
> Don't be sorry about that, it's good news because now I know
> where to look, i.e. in the ethernet controller.
Don't look too deeply into the code just yet, just try to see what
happens with dsa_loop on an identical Ethernet controller that isn't
physically attached to a switch.
^ 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