* Re: [PATCH RFC v3 0/5] Support fraglist GRO/GSO
From: David Miller @ 2019-09-19 11:18 UTC (permalink / raw)
To: steffen.klassert; +Cc: marcelo.leitner, willemdebruijn.kernel, netdev, pabeni
In-Reply-To: <20190919110125.GN2879@gauss3.secunet.de>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 19 Sep 2019 13:01:25 +0200
> If the packet data of all the fraglist GRO skbs are backed by a
> page fragment then we could just do the same by iterating with
> skb_walk_frags(). I'm not a driver expert and might be misstaken,
> but it looks like that could be done with existing hardware that
> supports segmentation offload.
Having to add frag list as well as page frag iterating in a driver is
quite a bit of logic, and added complexity.
If the frag list SKBs are indeed backed by a page, you could just as
easily coalesce everything into the page frag array of the first SKB.
^ permalink raw reply
* CONFIG_NET_TC_SKB_EXT
From: David Miller @ 2019-09-19 11:21 UTC (permalink / raw)
To: paulb; +Cc: netdev
As Linus pointed out, the Kconfig logic for CONFIG_NET_TC_SKB_EXT
is really not acceptable.
It should not be enabled by default at all.
Instead the actual users should turn it on or depend upon it, which in
this case seems to be OVS.
Please fix this, thank you.
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2019-09-19 11:22 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <CAHk-=whSTx4ofABCgWVe_2Kfo3CV6kSkBSRQBR-o5=DefgXnUQ@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 18 Sep 2019 13:37:57 -0700
> Hmm. This adds that NET_TC_SKB_EXT config thing, and makes it "default y".
>
> Why?
>
> It's also done in a crazy way:
>
> + depends on NET_CLS_ACT
> + default y if NET_CLS_ACT
I agree.
I've asked Paul Blakey, who added this, to make it depend upon OpenVSWwtch
or whatever else uses it.
^ permalink raw reply
* Re: [PATCH 00/20] Add support for Silicon Labs WiFi chip WF200 and further
From: Greg Kroah-Hartman @ 2019-09-19 11:25 UTC (permalink / raw)
To: Jerome Pouiller
Cc: devel@driverdev.osuosl.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kalle Valo,
David S . Miller, David Le Goff
In-Reply-To: <20190919105153.15285-1-Jerome.Pouiller@silabs.com>
On Thu, Sep 19, 2019 at 10:52:34AM +0000, Jerome Pouiller wrote:
> From: Jérôme Pouiller <jerome.pouiller@silabs.com>
>
> Hello all,
>
> This series add support for Silicon Labs WiFi chip WF200 and further:
>
> https://www.silabs.com/documents/public/data-sheets/wf200-datasheet.pdf
>
> This driver is an export from:
>
> https://github.com/SiliconLabs/wfx-linux-driver/
>
> I squashed all commits from github (it definitely does not make sense to
> import history). Then I split it in comprehensible (at least try to be)
> commits. I hope it will help readers to understand driver architecture.
> IMHO, firsts commits are clean enough to be reviewed. Things get more
> difficult when I introduce mac8011 API. I tried to extract important
> parts like Rx/Tx process but, big and complex patches seem unavoidable
> in this part.
>
> Architecture itself is described in commit messages.
>
> The series below is aligned on version 2.3.1 on github. If compare this
> series with github, you will find traditional differences between
> external and a in-tree driver: Documentation, build infrastructure,
> etc... In add, I dropped all code in CONFIG_WFX_SECURE_LINK. Indeed,
> "Secure Link" feature depends on mbedtls and I don't think to pull
> mbedtls in kernel is an option (see "To be done" below).
>
>
> What need to be done in this driver to leave staging area?
>
> - I kept wfx_version.h in order to ensure synchronization with github
> waiting for development goes entirely in kernel
That should be removed soon.
> - I also kept compatibility code for earlier Linux kernel version. I
> may drop it in future. Maybe I will maintain compatibility with
> older kernels in a external set of patches.
That has to be dropped for the in-kernel version.
The rest of these are fine, can you add this list in a TODO file for
this directory like the other staging drivers have?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] usbnet: sanity checking of packet sizes and device mtu
From: David Miller @ 2019-09-19 11:27 UTC (permalink / raw)
To: oneukum; +Cc: netdev
In-Reply-To: <20190919082309.23365-1-oneukum@suse.com>
From: Oliver Neukum <oneukum@suse.com>
Date: Thu, 19 Sep 2019 10:23:08 +0200
> After a reset packet sizes and device mtu can change and need
> to be reevaluated to calculate queue sizes.
> Malicious devices can set this to zero and we divide by it.
> Introduce sanity checking.
>
> Reported-and-tested-by: syzbot+6102c120be558c885f04@syzkaller.appspotmail.com
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v8 1/7] nfc: pn533: i2c: "pn532" as dt compatible string
From: David Miller @ 2019-09-19 11:32 UTC (permalink / raw)
To: poeschel
Cc: swinslow, tglx, kstewart, allison, opensource, netdev,
linux-kernel, johan, horms
In-Reply-To: <20190919091645.16439-1-poeschel@lemonage.de>
As we are in the merge window, the net-next tree is closed, as shown
also at:
http://vger.kernel.org/~davem/net-next.html
Please resubmit this after the merge window when the net-next tree opens
back up.
Please also provide an appropriate "[PATCH 0/N]" header posting
explaining what the patch series is doing, how it is doing it, and
why it is doing it that way.
Thank you.
^ permalink raw reply
* Re: [PATCH RFC v3 0/5] Support fraglist GRO/GSO
From: Steffen Klassert @ 2019-09-19 11:36 UTC (permalink / raw)
To: David Miller; +Cc: marcelo.leitner, willemdebruijn.kernel, netdev, pabeni
In-Reply-To: <20190919.131816.1861650130627229336.davem@davemloft.net>
On Thu, Sep 19, 2019 at 01:18:16PM +0200, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Thu, 19 Sep 2019 13:01:25 +0200
>
> > If the packet data of all the fraglist GRO skbs are backed by a
> > page fragment then we could just do the same by iterating with
> > skb_walk_frags(). I'm not a driver expert and might be misstaken,
> > but it looks like that could be done with existing hardware that
> > supports segmentation offload.
>
> Having to add frag list as well as page frag iterating in a driver is
> quite a bit of logic, and added complexity.
>
> If the frag list SKBs are indeed backed by a page, you could just as
> easily coalesce everything into the page frag array of the first SKB.
That is true indeed. Fraglist GRO is more optimized to the case
where we still need the skb arround the packet data. I.e. if it
can't be offloaded.
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Marc Zyngier @ 2019-09-19 11:39 UTC (permalink / raw)
To: Paolo Bonzini, Jianyong Wu (Arm Technology China),
netdev@vger.kernel.org, yangbo.lu@nxp.com, john.stultz@linaro.org,
tglx@linutronix.de, sean.j.christopherson@intel.com,
richardcochran@gmail.com, Mark Rutland, Will Deacon,
Suzuki Poulose
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China),
nd, linux-arm-kernel@lists.infradead.org
In-Reply-To: <ef6ab8bd-41ad-88f8-9cfd-dc749ca65310@redhat.com>
On 19/09/2019 12:07, Paolo Bonzini wrote:
> On 19/09/19 11:46, Jianyong Wu (Arm Technology China) wrote:
>>> On 18/09/19 11:57, Jianyong Wu (Arm Technology China) wrote:
>>>> Paolo Bonzini wrote:
>>>>> This is not Y2038-safe. Please use ktime_get_real_ts64 instead, and
>>>>> split the 64-bit seconds value between val[0] and val[1].
>>
>> Val[] should be long not u32 I think, so in arm64 I can avoid that Y2038_safe, but
>> also need rewrite for arm32.
>
> I don't think there's anything inherently wrong with u32 val[], and as
> you notice it lets you reuse code between arm and arm64. It's up to you
> and Marc to decide.
>
>>>>> However, it seems to me that the new function is not needed and you
>>>>> can just use ktime_get_snapshot. You'll get the time in
>>>>> systime_snapshot->real and the cycles value in systime_snapshot->cycles.
>>>>
>>>> See patch 5/6, I need both counter cycle and clocksource,
>>> ktime_get_snapshot seems only offer cycles.
>>>
>>> No, patch 5/6 only needs the current clock (ptp_sc.cycles is never accessed).
>>> So you could just use READ_ONCE(tk->tkr_mono.clock).
>>>
>> Yeah, patch 5/6 just need clocksource, but I think tk->tkr_mono.clock can't read in external like module,
>> So I need an API to expose clocksource.
>>
>>> However, even then I don't think it is correct to use ptp_sc.cs blindly in patch
>>> 5. I think there is a misunderstanding on the meaning of
>>> system_counterval.cs as passed to get_device_system_crosststamp.
>>> system_counterval.cs is not the active clocksource; it's the clocksource on
>>> which system_counterval.cycles is based.
>>>
>>
>> I think we can use system_counterval_t as pass current clocksource to system_counterval_t.cs and its
>> corresponding cycles to system_counterval_t.cycles. is it a big problem?
>
> Yes, it is. Because...
>
>>> Hypothetically, the clocksource could be one for which ptp_sc.cycles is _not_
>>> a cycle value. If you set system_counterval.cs to the system clocksource,
>>> get_device_system_crosststamp will return a bogus value.
>>
>> Yeah, but in patch 3/6, we have a corresponding pair of clock source and cycle value. So I think there will be no
>> that problem in this patch set.
>> In the implementation of get_device_system_crosststamp:
>> "
>> ...
>> if (tk->tkr_mono.clock != system_counterval.cs)
>> return -ENODEV;
>> ...
>> "
>> We need tk->tkr_mono.clock passed to get_device_system_crosststamp, just like patch 3/6 do, otherwise will return error.
>
> ... if the hypercall returns an architectural timer value, you must not
> pass tk->tkr.mono.clock to get_device_system_crosststamp: you must pass
> &clocksource_counter. This way, PTP is disabled when using any other
> clocksource.
>
>>> So system_counterval.cs should be set to something like
>>> &clocksource_counter (from drivers/clocksource/arm_arch_timer.c).
>>> Perhaps the right place to define kvm_arch_ptp_get_clock_fn is in that file?
>>>
>> I have checked that ptp_sc.cs is arch_sys_counter.
>> Also move the module API to arm_arch_timer.c will looks a little
>> ugly and it's not easy to be accept by arm side I think.
>
> I don't think it's ugly but more important, using tk->tkr_mono.clock is
> incorrect. See how the x86 code hardcodes &kvm_clock, it's the same for
> ARM.
Not really. The guest kernel is free to use any clocksource it wishes.
In some cases, it is actually desirable (like these broken systems that
cannot use an in-kernel irqchip...). Maybe it is that on x86 the guest
only uses the kvm_clock, but that's a much harder sell on ARM. The fact
that ptp_kvm assumes that the clocksource is fixed doesn't seem correct
in that case.
M.
--
Jazz is not dead, it just smells funny...
^ permalink raw reply
* Re: [PATCH 00/20] Add support for Silicon Labs WiFi chip WF200 and further
From: Arend Van Spriel @ 2019-09-19 11:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jerome Pouiller
Cc: devel@driverdev.osuosl.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kalle Valo,
David S . Miller, David Le Goff
In-Reply-To: <20190919112508.GA3037175@kroah.com>
On 9/19/2019 1:25 PM, Greg Kroah-Hartman wrote:
>> - I also kept compatibility code for earlier Linux kernel version. I
>> may drop it in future. Maybe I will maintain compatibility with
>> older kernels in a external set of patches.
> That has to be dropped for the in-kernel version.
There is no need to maintain such compatibility. You basically get it
for free with the linux-backports project [1].
Regards,
Arend
[1] https://backports.wiki.kernel.org/index.php/Main_Page
^ permalink raw reply
* [PATCH] iwlwifi: fix building without CONFIG_THERMAL
From: Arnd Bergmann @ 2019-09-19 11:55 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo
Cc: Arnd Bergmann, linux-wireless, netdev, linux-kernel
The iwl_mvm_send_temp_report_ths_cmd() function is now called without
CONFIG_THERMAL, but not defined:
ERROR: "iwl_mvm_send_temp_report_ths_cmd" [drivers/net/wireless/intel/iwlwifi/mvm/iwlmvm.ko] undefined!
Move that function out of the #ifdef as well and change it so
that empty data gets sent even if no thermal device was
registered.
Fixes: 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
No idea if this does what was intended in the commit that introduced
the link failure, please see for youself.
---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 4 ++--
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 843d00bf2bd5..1b4139372e57 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -542,7 +542,6 @@ struct iwl_mvm_tt_mgmt {
bool throttle;
};
-#ifdef CONFIG_THERMAL
/**
*struct iwl_mvm_thermal_device - thermal zone related data
* @temp_trips: temperature thresholds for report
@@ -555,6 +554,7 @@ struct iwl_mvm_thermal_device {
struct thermal_zone_device *tzone;
};
+#ifdef CONFIG_THERMAL
/*
* struct iwl_mvm_cooling_device
* @cur_state: current state
@@ -1034,8 +1034,8 @@ struct iwl_mvm {
/* Thermal Throttling and CTkill */
struct iwl_mvm_tt_mgmt thermal_throttle;
-#ifdef CONFIG_THERMAL
struct iwl_mvm_thermal_device tz_device;
+#ifdef CONFIG_THERMAL
struct iwl_mvm_cooling_device cooling_dev;
#endif
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 32a708301cfc..6d717bb65ab7 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -549,7 +549,6 @@ int iwl_mvm_ctdp_command(struct iwl_mvm *mvm, u32 op, u32 state)
return 0;
}
-#ifdef CONFIG_THERMAL
static int compare_temps(const void *a, const void *b)
{
return ((s16)le16_to_cpu(*(__le16 *)a) -
@@ -564,7 +563,7 @@ int iwl_mvm_send_temp_report_ths_cmd(struct iwl_mvm *mvm)
lockdep_assert_held(&mvm->mutex);
if (!mvm->tz_device.tzone)
- return -EINVAL;
+ goto send;
/* The driver holds array of temperature trips that are unsorted
* and uncompressed, the FW should get it compressed and sorted
@@ -607,6 +606,7 @@ int iwl_mvm_send_temp_report_ths_cmd(struct iwl_mvm *mvm)
return ret;
}
+#ifdef CONFIG_THERMAL
static int iwl_mvm_tzone_get_temp(struct thermal_zone_device *device,
int *temperature)
{
--
2.20.0
^ permalink raw reply related
* Re: [PATCH] iwlwifi: fix building without CONFIG_THERMAL
From: Luca Coelho @ 2019-09-19 11:58 UTC (permalink / raw)
To: Arnd Bergmann, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20190919115612.1924937-1-arnd@arndb.de>
On Thu, 2019-09-19 at 13:55 +0200, Arnd Bergmann wrote:
> The iwl_mvm_send_temp_report_ths_cmd() function is now called without
> CONFIG_THERMAL, but not defined:
>
> ERROR: "iwl_mvm_send_temp_report_ths_cmd" [drivers/net/wireless/intel/iwlwifi/mvm/iwlmvm.ko] undefined!
>
> Move that function out of the #ifdef as well and change it so
> that empty data gets sent even if no thermal device was
> registered.
>
> Fixes: 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> No idea if this does what was intended in the commit that introduced
> the link failure, please see for youself.
Thanks for the fix, Arnd! We already sent a fix for this though[1] and
Kalle has already queued it for v5.3.
[1] https://patchwork.kernel.org/patch/11150431/
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] ieee802154: atusb: fix use-after-free at disconnect
From: Johan Hovold @ 2019-09-19 12:12 UTC (permalink / raw)
To: Stefan Schmidt
Cc: Alexander Aring, David S. Miller, linux-wpan, netdev,
linux-kernel, andreyknvl, syzkaller-bugs, Johan Hovold, stable,
syzbot+f4509a9138a1472e7e80
The disconnect callback was accessing the hardware-descriptor private
data after having having freed it.
Fixes: 7490b008d123 ("ieee802154: add support for atusb transceiver")
Cc: stable <stable@vger.kernel.org> # 4.2
Cc: Alexander Aring <alex.aring@gmail.com>
Reported-by: syzbot+f4509a9138a1472e7e80@syzkaller.appspotmail.com
Signed-off-by: Johan Hovold <johan@kernel.org>
---
#syz test: https://github.com/google/kasan.git f0df5c1b
drivers/net/ieee802154/atusb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
index ceddb424f887..0dd0ba915ab9 100644
--- a/drivers/net/ieee802154/atusb.c
+++ b/drivers/net/ieee802154/atusb.c
@@ -1137,10 +1137,11 @@ static void atusb_disconnect(struct usb_interface *interface)
ieee802154_unregister_hw(atusb->hw);
+ usb_put_dev(atusb->usb_dev);
+
ieee802154_free_hw(atusb->hw);
usb_set_intfdata(interface, NULL);
- usb_put_dev(atusb->usb_dev);
pr_debug("%s done\n", __func__);
}
--
2.23.0
^ permalink raw reply related
* Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Paolo Bonzini @ 2019-09-19 12:13 UTC (permalink / raw)
To: Marc Zyngier, Jianyong Wu (Arm Technology China),
netdev@vger.kernel.org, yangbo.lu@nxp.com, john.stultz@linaro.org,
tglx@linutronix.de, sean.j.christopherson@intel.com,
richardcochran@gmail.com, Mark Rutland, Will Deacon,
Suzuki Poulose
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China),
nd, linux-arm-kernel@lists.infradead.org
In-Reply-To: <a1b554b8-4417-5305-3419-fe71a8c50842@kernel.org>
On 19/09/19 13:39, Marc Zyngier wrote:
>> I don't think it's ugly but more important, using tk->tkr_mono.clock is
>> incorrect. See how the x86 code hardcodes &kvm_clock, it's the same for
>> ARM.
> Not really. The guest kernel is free to use any clocksource it wishes.
Understood, in fact it's the same on x86.
However, for PTP to work, the cycles value returned by the clocksource
must match the one returned by the hypercall. So for ARM
get_device_system_crosststamp must receive the arch timer clocksource,
so that it will return -ENODEV if the active clocksource is anything else.
Paolo
> In some cases, it is actually desirable (like these broken systems that
> cannot use an in-kernel irqchip...). Maybe it is that on x86 the guest
> only uses the kvm_clock, but that's a much harder sell on ARM. The fact
> that ptp_kvm assumes that the clocksource is fixed doesn't seem correct
> in that case.
^ permalink raw reply
* Re: [PATCH net-next] tcp: force a PSH flag on TSO packets
From: Or Gerlitz @ 2019-09-19 12:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, Soheil Hassas Yeganeh,
Neal Cardwell, Yuchung Cheng, Daniel Borkmann, Tariq Toukan
In-Reply-To: <20190910214928.220727-1-edumazet@google.com>
On Wed, Sep 11, 2019 at 12:54 AM Eric Dumazet <edumazet@google.com> wrote:
> When tcp sends a TSO packet, adding a PSH flag on it
> reduces the sojourn time of GRO packet in GRO receivers.
>
> This is particularly the case under pressure, since RX queues
> receive packets for many concurrent flows.
>
> A sender can give a hint to GRO engines when it is
> appropriate to flush a super-packet, especially when pacing
Hi Eric,
Is this correct that we add here the push flag for the tcp header template
from which all the tcp headers for SW GSO packets will be generated?
Wouldn't that cause a too early flush on GRO engines at the receiver side?
Or.
^ permalink raw reply
* Re: [PATCH bpf v2] libbpf: Remove getsockopt() check for XDP_OPTIONS
From: Daniel Borkmann @ 2019-09-19 12:31 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Alexei Starovoitov, netdev, bpf, Björn Töpel,
Yonghong Song
In-Reply-To: <20190916123342.49928-1-toke@redhat.com>
On Mon, Sep 16, 2019 at 02:33:42PM +0200, Toke Høiland-Jørgensen wrote:
> The xsk_socket__create() function fails and returns an error if it cannot
> get the XDP_OPTIONS through getsockopt(). However, support for XDP_OPTIONS
> was not added until kernel 5.3, so this means that creating XSK sockets
> always fails on older kernels.
>
> Since the option is just used to set the zero-copy flag in the xsk struct,
> and that flag is not really used for anything yet, just remove the
> getsockopt() call until a proper use for it is introduced.
>
> Suggested-by: Yonghong Song <yhs@fb.com>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Applied, thanks!
^ permalink raw reply
* Re: KASAN: use-after-free Read in atusb_disconnect
From: syzbot @ 2019-09-19 12:32 UTC (permalink / raw)
To: alex.aring, andreyknvl, davem, johan, linux-kernel, linux-wpan,
netdev, stable, stefan, syzkaller-bugs
In-Reply-To: <20190919121234.30620-1-johan@kernel.org>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+f4509a9138a1472e7e80@syzkaller.appspotmail.com
Tested on:
commit: f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git
kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
dashboard link: https://syzkaller.appspot.com/bug?extid=f4509a9138a1472e7e80
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=10f3ebb5600000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* Re: [PATCH net-next] tcp: force a PSH flag on TSO packets
From: David Miller @ 2019-09-19 12:32 UTC (permalink / raw)
To: gerlitz.or
Cc: edumazet, netdev, eric.dumazet, soheil, ncardwell, ycheng, daniel,
tariqt
In-Reply-To: <CAJ3xEMhh=Ow-fZqnPtxUyZsCN89dRmy=NcaO+iK+iZZYBdZbqA@mail.gmail.com>
From: Or Gerlitz <gerlitz.or@gmail.com>
Date: Thu, 19 Sep 2019 15:17:54 +0300
> On Wed, Sep 11, 2019 at 12:54 AM Eric Dumazet <edumazet@google.com> wrote:
>> When tcp sends a TSO packet, adding a PSH flag on it
>> reduces the sojourn time of GRO packet in GRO receivers.
>>
>> This is particularly the case under pressure, since RX queues
>> receive packets for many concurrent flows.
>>
>> A sender can give a hint to GRO engines when it is
>> appropriate to flush a super-packet, especially when pacing
>
> Hi Eric,
>
> Is this correct that we add here the push flag for the tcp header template
> from which all the tcp headers for SW GSO packets will be generated?
>
> Wouldn't that cause a too early flush on GRO engines at the receiver side?
I thought segmentation offload mechanism are not supposed to propagate
the PSH to all of the packets.
^ permalink raw reply
* Re: [PATCH bpf] xsk: relax UMEM headroom alignment
From: Daniel Borkmann @ 2019-09-19 12:33 UTC (permalink / raw)
To: Björn Töpel
Cc: ast, netdev, Björn Töpel, magnus.karlsson,
magnus.karlsson, bpf, jonathan.lemon
In-Reply-To: <20190918075739.19451-1-bjorn.topel@gmail.com>
On Wed, Sep 18, 2019 at 09:57:39AM +0200, Björn Töpel wrote:
> From: Björn Töpel <bjorn.topel@intel.com>
>
> This patch removes the 64B alignment of the UMEM headroom. There is
> really no reason for it, and having a headroom less than 64B should be
> valid.
>
> Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt")
> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf 0/2] bpf: BTF fixes
From: Daniel Borkmann @ 2019-09-19 12:33 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: davem, netdev, bpf, kernel-team
In-Reply-To: <20190917174538.1295523-1-ast@kernel.org>
On Tue, Sep 17, 2019 at 10:45:36AM -0700, Alexei Starovoitov wrote:
> Two trivial BTF fixes.
>
> Alexei Starovoitov (2):
> bpf: fix BTF verification of enums
> bpf: fix BTF limits
>
> include/uapi/linux/btf.h | 4 ++--
> kernel/bpf/btf.c | 5 ++---
> 2 files changed, 4 insertions(+), 5 deletions(-)
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] stmmac: selftest: avoid large stack usage
From: Arnd Bergmann @ 2019-09-19 12:34 UTC (permalink / raw)
To: Jose Abreu
Cc: Giuseppe Cavallaro, Alexandre Torgue, David S. Miller,
Maxime Coquelin, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <BN8PR12MB3266E044DDF00F227B9B191CD3890@BN8PR12MB3266.namprd12.prod.outlook.com>
On Thu, Sep 19, 2019 at 9:58 AM Jose Abreu <Jose.Abreu@synopsys.com> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sep/18/2019, 20:54:34 (UTC+00:00)
>
> > + if (!cfg || !cfg->enable) {
> > value &= ~XGMAC_RSSE;
> > writel(value, ioaddr + XGMAC_RSS_CTRL);
> > return 0;
> > }
> >
> > for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
> > - ret = dwxgmac2_rss_write_reg(ioaddr, true, i, *key++);
> > + if (cfg)
> > + ret = dwxgmac2_rss_write_reg(ioaddr, true, i, cfg->key[i]);
> > + else
> > + ret = dwxgmac2_rss_write_reg(ioaddr, true, i, 0);
> > +
> > if (ret)
> > return ret;
> > }
> >
> > for (i = 0; i < ARRAY_SIZE(cfg->table); i++) {
> > - ret = dwxgmac2_rss_write_reg(ioaddr, false, i, cfg->table[i]);
> > + if (cfg)
> > + ret = dwxgmac2_rss_write_reg(ioaddr, false, i, cfg->table[i]);
> > + else
> > + ret = dwxgmac2_rss_write_reg(ioaddr, false, i, 0);
> > +
>
> I don't get these "if (cfg)" checks. You already check earlier if cfg is
> NULL and return if so. I don't think you need these extra checks.
Ah, you are right, I missed the 'return 0', that makes it much easier.
> Also, your subject line should be something like: "net: stmmac:
> selftests: ..."
I think both styles is common for network drivers, though I think most
just leave out the 'net:'. I changed it in v2 now.
Arnd
^ permalink raw reply
* [PATCH] [v2] net: stmmac: selftest: avoid large stack usage
From: Arnd Bergmann @ 2019-09-19 12:33 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin
Cc: Arnd Bergmann, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
Putting a struct stmmac_rss object on the stack is a bad idea,
as it exceeds the warning limit for a stack frame on 32-bit architectures:
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1221:12: error: stack frame size of 1208 bytes in function '__stmmac_test_l3filt' [-Werror,-Wframe-larger-than=]
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1338:12: error: stack frame size of 1208 bytes in function '__stmmac_test_l4filt' [-Werror,-Wframe-larger-than=]
As the object is the trivial empty case, change the called function
to accept a NULL pointer to mean the same thing and remove the
large variable in the two callers.
Fixes: 4647e021193d ("net: stmmac: selftests: Add selftest for L3/L4 Filters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: simply configure function, based on feedback from Jose
---
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 5 ++---
.../net/ethernet/stmicro/stmmac/stmmac_selftests.c | 14 ++++----------
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index d5173dd02a71..2b277b2c586b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -523,19 +523,18 @@ static int dwxgmac2_rss_configure(struct mac_device_info *hw,
struct stmmac_rss *cfg, u32 num_rxq)
{
void __iomem *ioaddr = hw->pcsr;
- u32 *key = (u32 *)cfg->key;
int i, ret;
u32 value;
value = readl(ioaddr + XGMAC_RSS_CTRL);
- if (!cfg->enable) {
+ if (!cfg || !cfg->enable) {
value &= ~XGMAC_RSSE;
writel(value, ioaddr + XGMAC_RSS_CTRL);
return 0;
}
for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
- ret = dwxgmac2_rss_write_reg(ioaddr, true, i, *key++);
+ ret = dwxgmac2_rss_write_reg(ioaddr, true, i, cfg->key[i]);
if (ret)
return ret;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index c56e89e1ae56..9c8d210b2d6a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -1233,12 +1233,9 @@ static int __stmmac_test_l3filt(struct stmmac_priv *priv, u32 dst, u32 src,
return -EOPNOTSUPP;
if (!priv->dma_cap.l3l4fnum)
return -EOPNOTSUPP;
- if (priv->rss.enable) {
- struct stmmac_rss rss = { .enable = false, };
-
- stmmac_rss_configure(priv, priv->hw, &rss,
+ if (priv->rss.enable)
+ stmmac_rss_configure(priv, priv->hw, NULL,
priv->plat->rx_queues_to_use);
- }
dissector = kzalloc(sizeof(*dissector), GFP_KERNEL);
if (!dissector) {
@@ -1357,12 +1354,9 @@ static int __stmmac_test_l4filt(struct stmmac_priv *priv, u32 dst, u32 src,
return -EOPNOTSUPP;
if (!priv->dma_cap.l3l4fnum)
return -EOPNOTSUPP;
- if (priv->rss.enable) {
- struct stmmac_rss rss = { .enable = false, };
-
- stmmac_rss_configure(priv, priv->hw, &rss,
+ if (priv->rss.enable)
+ stmmac_rss_configure(priv, priv->hw, NULL,
priv->plat->rx_queues_to_use);
- }
dissector = kzalloc(sizeof(*dissector), GFP_KERNEL);
if (!dissector) {
--
2.20.0
^ permalink raw reply related
* Re: [PATCH RFC v3 0/5] Support fraglist GRO/GSO
From: Or Gerlitz @ 2019-09-19 12:37 UTC (permalink / raw)
To: Steffen Klassert, Edward Cree, Willem de Bruijn
Cc: Linux Netdev List, Paolo Abeni
In-Reply-To: <20190918072517.16037-1-steffen.klassert@secunet.com>
On Wed, Sep 18, 2019 at 2:48 PM Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> This patchset adds support to do GRO/GSO by chaining packets
> of the same flow at the SKB frag_list pointer. This avoids
> the overhead to merge payloads into one big packet, and
> on the other end, if GSO is needed it avoids the overhead
> of splitting the big packet back to the native form.
>
> Patch 1 Enables UDP GRO by default.
>
> Patch 2 adds a netdev feature flag to enable listifyed GRO,
> this implements one of the configuration options discussed
> at netconf 2019.
[..]
The slide say that linked packets travel together though the stack.
This sounds somehow similar to the approach suggested by Ed
for skb lists. I wonder what we can say on cases where each of the
approaches would function better.
Or.
^ permalink raw reply
* RE: [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad
From: zhangsha (A) @ 2019-09-19 12:46 UTC (permalink / raw)
To: Jay Vosburgh, zaharov@selectel.ru
Cc: vfalico@gmail.com, andy@greyhouse.net, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, yuehaibing,
hunongda, Chenzhendong (alex)
In-Reply-To: <10098.1568880711@nyx>
> -----Original Message-----
> From: Jay Vosburgh [mailto:jay.vosburgh@canonical.com]
> Sent: 2019年9月19日 16:12
> To: zhangsha (A) <zhangsha.zhang@huawei.com>
> Cc: vfalico@gmail.com; andy@greyhouse.net; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; yuehaibing
> <yuehaibing@huawei.com>; hunongda <hunongda@huawei.com>;
> Chenzhendong (alex) <alex.chen@huawei.com>
> Subject: Re: [PATCH v3] bonding: force enable lacp port after link state
> recovery for 802.3ad
>
> zhangsha (A) <zhangsha.zhang@huawei.com> wrote:
>
> >> -----Original Message-----
> >> From: zhangsha (A)
> >> Sent: 2019年9月18日 21:06
> >> To: jay.vosburgh@canonical.com; vfalico@gmail.com;
> >> andy@greyhouse.net; davem@davemloft.net; netdev@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; yuehaibing <yuehaibing@huawei.com>;
> >> hunongda <hunongda@huawei.com>; Chenzhendong (alex)
> >> <alex.chen@huawei.com>; zhangsha (A) <zhangsha.zhang@huawei.com>
> >> Subject: [PATCH v3] bonding: force enable lacp port after link state
> >> recovery for 802.3ad
> >>
> >> From: Sha Zhang <zhangsha.zhang@huawei.com>
> >>
> >> After the commit 334031219a84 ("bonding/802.3ad: fix slave link
> >> initialization transition states") merged, the slave's link status
> >> will be changed to BOND_LINK_FAIL from BOND_LINK_DOWN in the
> following scenario:
> >> - Driver reports loss of carrier and
> >> bonding driver receives NETDEV_DOWN notifier
> >> - slave's duplex and speed is zerod and
> >> its port->is_enabled is cleard to 'false';
> >> - Driver reports link recovery and
> >> bonding driver receives NETDEV_UP notifier;
> >> - If speed/duplex getting failed here, the link status
> >> will be changed to BOND_LINK_FAIL;
> >> - The MII monotor later recover the slave's speed/duplex
> >> and set link status to BOND_LINK_UP, but remains
> >> the 'port->is_enabled' to 'false'.
> >>
> >> In this scenario, the lacp port will not be enabled even its speed
> >> and duplex are valid. The bond will not send LACPDU's, and its state is
> 'AD_STATE_DEFAULTED'
> >> forever. The simplest fix I think is to call
> >> bond_3ad_handle_link_change() in bond_miimon_commit, this function
> >> can enable lacp after port slave speed check.
> >> As enabled, the lacp port can run its state machine normally after link
> recovery.
> >>
> >> Signed-off-by: Sha Zhang <zhangsha.zhang@huawei.com>
> >> ---
> >> drivers/net/bonding/bond_main.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/bonding/bond_main.c
> >> b/drivers/net/bonding/bond_main.c index 931d9d9..76324a5 100644
> >> --- a/drivers/net/bonding/bond_main.c
> >> +++ b/drivers/net/bonding/bond_main.c
> >> @@ -2206,7 +2206,8 @@ static void bond_miimon_commit(struct bonding
> >> *bond)
> >> */
> >> if (BOND_MODE(bond) == BOND_MODE_8023AD &&
> >> slave->link == BOND_LINK_UP)
> >> -
> >> bond_3ad_adapter_speed_duplex_changed(slave);
> >> + bond_3ad_handle_link_change(slave,
> >> + BOND_LINK_UP);
> >> continue;
> >>
> >> case BOND_LINK_UP:
> >
> >Hi, David,
> >I have replied your email for a while, I guess you may miss my email, so I
> resend it.
> >The following link address is the last email, please review the new one again,
> thank you.
> >https://patchwork.ozlabs.org/patch/1151915/
> >
> >Last time, you doubted this is a driver specific problem, I prefer to
> >believe it's not because I find the commit 4d2c0cda, its log says "
> >Some NIC drivers don't have correct speed/duplex settings at the time
> >they send NETDEV_UP notification ...".
> >
> >Anyway, I think the lacp status should be fixed correctly, since
> >link-monitoring (miimon) set SPEED/DUPLEX right here.
>
> I suspect this is going to be related to the concurrent discussion with
> Aleksei, and would like to see the instrumentation results from his tests before
> adding another change to attempt to resolve this.
>
> Also, what device are you using for your testing, and are you able to
> run the instrumentation patch that I provided to Aleksei and provide its results?
>
> -J
>
Yes, I think it's the same problem.
I am using a Huawei hinic card with kernel 4.19 and got the same message and the
weird system mac "00:00:00:00:00:00":
"link status definitely down for interface eth6, disabling it
link status up again after 0 ms for interface eth6"
I will run your instrumentation patch, but maybe I need more times.
In fact, I have tried to reproduce the problem for thousands of times, but never succeeded.
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH net v3] net/sched: cls_api: Fix nooffloaddevcnt counter when indr block call success
From: Or Gerlitz @ 2019-09-19 12:50 UTC (permalink / raw)
To: wenxu, Pieter Jansen van Vuuren, Oz Shlomo
Cc: David Miller, Linux Netdev List, Roi Dayan, Paul Blakey,
Jiri Pirko
In-Reply-To: <1568882232-12847-1-git-send-email-wenxu@ucloud.cn>
On Thu, Sep 19, 2019 at 11:39 AM <wenxu@ucloud.cn> wrote:
>
> From: wenxu <wenxu@ucloud.cn>
>
> A vxlan or gretap device offload through indr block methord. If the device
nit: method --> method
> successfully bind with a real hw through indr block call, It also add
> nooffloadcnt counter. This counter will lead the rule add failed in
> fl_hw_replace_filter-->tc_setup_cb_call with skip_sw flags.
wait.. indirect tc callbacks are typically used to do hw offloading
for decap rules (tunnel key unset action) set on SW devices (gretap, vxlan).
However, AFAIK, it's been couple of years since the kernel doesn't support
skip_sw for such rules. Did we enable it again? when? I am somehow
far from the details, so copied some folks..
Or.
>
> In the tc_setup_cb_call will check the nooffloaddevcnt and skip_sw flags
> as following:
> if (block->nooffloaddevcnt && err_stop)
> return -EOPNOTSUPP;
>
> So with this patch, if the indr block call success, it will not modify
> the nooffloaddevcnt counter.
>
> Fixes: 7f76fa36754b ("net: sched: register callbacks for indirect tc block binds")
> Signed-off-by: wenxu <wenxu@ucloud.cn>
> ---
> v3: rebase to the net
>
> net/sched/cls_api.c | 30 +++++++++++++++++-------------
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 32577c2..c980127 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -607,11 +607,11 @@ static void tc_indr_block_get_and_ing_cmd(struct net_device *dev,
> tc_indr_block_ing_cmd(dev, block, cb, cb_priv, command);
> }
>
> -static void tc_indr_block_call(struct tcf_block *block,
> - struct net_device *dev,
> - struct tcf_block_ext_info *ei,
> - enum flow_block_command command,
> - struct netlink_ext_ack *extack)
> +static int tc_indr_block_call(struct tcf_block *block,
> + struct net_device *dev,
> + struct tcf_block_ext_info *ei,
> + enum flow_block_command command,
> + struct netlink_ext_ack *extack)
> {
> struct flow_block_offload bo = {
> .command = command,
> @@ -621,10 +621,15 @@ static void tc_indr_block_call(struct tcf_block *block,
> .block_shared = tcf_block_shared(block),
> .extack = extack,
> };
> +
> INIT_LIST_HEAD(&bo.cb_list);
>
> flow_indr_block_call(dev, &bo, command);
> - tcf_block_setup(block, &bo);
> +
> + if (list_empty(&bo.cb_list))
> + return -EOPNOTSUPP;
> +
> + return tcf_block_setup(block, &bo);
> }
>
> static bool tcf_block_offload_in_use(struct tcf_block *block)
> @@ -681,8 +686,6 @@ static int tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
> goto no_offload_dev_inc;
> if (err)
> goto err_unlock;
> -
> - tc_indr_block_call(block, dev, ei, FLOW_BLOCK_BIND, extack);
> up_write(&block->cb_lock);
> return 0;
>
> @@ -691,9 +694,10 @@ static int tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
> err = -EOPNOTSUPP;
> goto err_unlock;
> }
> + err = tc_indr_block_call(block, dev, ei, FLOW_BLOCK_BIND, extack);
> + if (err)
> + block->nooffloaddevcnt++;
> err = 0;
> - block->nooffloaddevcnt++;
> - tc_indr_block_call(block, dev, ei, FLOW_BLOCK_BIND, extack);
> err_unlock:
> up_write(&block->cb_lock);
> return err;
> @@ -706,8 +710,6 @@ static void tcf_block_offload_unbind(struct tcf_block *block, struct Qdisc *q,
> int err;
>
> down_write(&block->cb_lock);
> - tc_indr_block_call(block, dev, ei, FLOW_BLOCK_UNBIND, NULL);
> -
> if (!dev->netdev_ops->ndo_setup_tc)
> goto no_offload_dev_dec;
> err = tcf_block_offload_cmd(block, dev, ei, FLOW_BLOCK_UNBIND, NULL);
> @@ -717,7 +719,9 @@ static void tcf_block_offload_unbind(struct tcf_block *block, struct Qdisc *q,
> return;
>
> no_offload_dev_dec:
> - WARN_ON(block->nooffloaddevcnt-- == 0);
> + err = tc_indr_block_call(block, dev, ei, FLOW_BLOCK_UNBIND, NULL);
> + if (err)
> + WARN_ON(block->nooffloaddevcnt-- == 0);
> up_write(&block->cb_lock);
> }
>
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v4 1/3] kernel/notifier.c: intercepting duplicate registrations to avoid infinite loops
From: Xiaoming Ni @ 2019-09-19 12:55 UTC (permalink / raw)
To: Greg KH
Cc: akpm, vvs, torvalds, adobriyan, anna.schumaker, arjan, bfields,
chuck.lever, davem, jlayton, luto, mingo, Nadia.Derbey, paulmck,
semen.protsenko, stern, tglx, trond.myklebust, viresh.kumar,
stable, dylix.dailei, yuehaibing, linux-kernel, linux-nfs, netdev
In-Reply-To: <20190919063615.GA2069346@kroah.com>
On 2019/9/19 14:36, Greg KH wrote:
> On Thu, Sep 19, 2019 at 10:58:06AM +0800, Xiaoming Ni wrote:
>> Registering the same notifier to a hook repeatedly can cause the hook
>> list to form a ring or lose other members of the list.
>>
>> case1: An infinite loop in notifier_chain_register() can cause soft lockup
>> atomic_notifier_chain_register(&test_notifier_list, &test1);
>> atomic_notifier_chain_register(&test_notifier_list, &test1);
>> atomic_notifier_chain_register(&test_notifier_list, &test2);
>>
>> case2: An infinite loop in notifier_chain_register() can cause soft lockup
>> atomic_notifier_chain_register(&test_notifier_list, &test1);
>> atomic_notifier_chain_register(&test_notifier_list, &test1);
>> atomic_notifier_call_chain(&test_notifier_list, 0, NULL);
>>
>> case3: lose other hook test2
>> atomic_notifier_chain_register(&test_notifier_list, &test1);
>> atomic_notifier_chain_register(&test_notifier_list, &test2);
>> atomic_notifier_chain_register(&test_notifier_list, &test1);
>>
>> case4: Unregister returns 0, but the hook is still in the linked list,
>> and it is not really registered. If you call notifier_call_chain
>> after ko is unloaded, it will trigger oops.
>>
>> If the system is configured with softlockup_panic and the same
>> hook is repeatedly registered on the panic_notifier_list, it
>> will cause a loop panic.
>>
>> Add a check in notifier_chain_register(),
>> Intercepting duplicate registrations to avoid infinite loops
>>
>> Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
>> Reviewed-by: Vasily Averin <vvs@virtuozzo.com>
>> ---
>> kernel/notifier.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
>
thanks for your guidance
I thought that as long as the code exists in the stable branch, it should be copied to stable@kernel.org
it is my mistake,
These patches are intended to be sent to the main line.
Should I resend it again?
> </formletter>
>
> Same thing goes for all of the patches in this series.
>
> thanks,
>
> greg k-h
>
> .
>
thanks
Xiaoming Ni
^ 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