* Re: [PATCH] compiler_attribute: remove CONFIG_ENABLE_MUST_CHECK
From: Miguel Ojeda @ 2020-11-23 17:00 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Jason A. Donenfeld, Shuah Khan, linux-kernel,
open list:KERNEL SELFTEST FRAMEWORK, Network Development,
wireguard, clang-built-linux, Nick Desaulniers
In-Reply-To: <CAK7LNARjU5HTcTjJG1-sQTJBFqohC1O8aAvFs3Hn_sXscH_pdg@mail.gmail.com>
On Mon, Nov 23, 2020 at 4:37 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> I can move it to compiler_attribute.h
>
> This attribute is supported by gcc, clang, and icc.
> https://godbolt.org/z/ehd6so
>
> I can send v2.
>
> I do not mind renaming, but it should be done in a separate patch.
Of course -- sorry, I didn't mean we had to do them now, i.e. we can
do the move and the rename later on, if you prefer.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v4] aquantia: Remove the build_skb path
From: Jakub Kicinski @ 2020-11-23 16:42 UTC (permalink / raw)
To: Ramsay, Lincoln
Cc: Florian Westphal, Igor Russkikh, David S. Miller,
netdev@vger.kernel.org, Dmitry Bogdanov
In-Reply-To: <CY4PR1001MB2311E9770EF466FB922CBB27E8FD0@CY4PR1001MB2311.namprd10.prod.outlook.com>
On Sun, 22 Nov 2020 22:36:22 +0000 Ramsay, Lincoln wrote:
> > (Next time please include in the subject the tree that you're targetting
> > the patch)
>
> I guess you mean like [PATCH master v5] ? Should I be targeting
> something other than the master branch on the main git repo?
> (https://github.com/torvalds/linux.git)
In this case the patch will be merged into the networking tree, and
then travel downstream to Linus. So you want to target this tree:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/
IOW [PATCH net v5].
> > please add a From: line at the beginning of the mail which matches
> > the signoff (or use git-send-email, it'll get it right).
>
> Sure.
>
> > Ah, one more thing, this is the correct fixes tag, right?
> > Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
> > Please add it right before the signoff line.
>
> I didn't quite understand this header... but yeah, I guess that's the
> commit that adds the fast path I am removing.
Yup, it points to the oldest revision of the code where the bug is
present. In your case oldest revision where:
When performing IPv6 forwarding, there is an expectation that SKBs
will have some headroom. When forwarding a packet from the aquantia
driver, this does not always happen, triggering a kernel warning.
> > > Align continuations of the lines under '(' like:
> >
> > I am only changing the leading indent. Am I still expected to satisfy the patch checker?
> >
> > The current patch is very clear about what is happening if you do a diff -w but if I start
> > changing other things to satisfy the checker, that goes away.
>
> Some of the patch checker complaints are only leading whitespace
> (obviously not a problem for diff -w), but 2 of them involve actual
> changes (changing , to ; and moving the first argument from the line
> below to the line above).
I don't think it'll make a huge difference for the review-ability of
this change to heed checkpatch's warnings here.
^ permalink raw reply
* Re: inconsistent lock state in io_file_data_ref_zero
From: Jens Axboe @ 2020-11-23 16:37 UTC (permalink / raw)
To: syzbot, davem, io-uring, johannes.berg, johannes, kuba,
linux-fsdevel, linux-kernel, linux-wireless, netdev,
syzkaller-bugs, viro
In-Reply-To: <000000000000f3332805b4c330c3@google.com>
On 11/23/20 2:55 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 27bba9c5 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11041f1e500000
> kernel config: https://syzkaller.appspot.com/x/.config?x=330f3436df12fd44
> dashboard link: https://syzkaller.appspot.com/bug?extid=1f4ba1e5520762c523c6
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17d9b775500000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=157e4f75500000
>
> The issue was bisected to:
>
> commit dcd479e10a0510522a5d88b29b8f79ea3467d501
> Author: Johannes Berg <johannes.berg@intel.com>
> Date: Fri Oct 9 12:17:11 2020 +0000
>
> mac80211: always wind down STA state
Not sure what is going on with the syzbot bisects recently, they are way
off into the weeds...
Anyway, I think the below should fix it.
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 489ec7272b3e..0f2abbff7eec 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -7194,9 +7181,9 @@ static int io_sqe_files_unregister(struct io_ring_ctx *ctx)
if (!data)
return -ENXIO;
- spin_lock(&data->lock);
+ spin_lock_bh(&data->lock);
ref_node = data->node;
- spin_unlock(&data->lock);
+ spin_unlock_bh(&data->lock);
if (ref_node)
percpu_ref_kill(&ref_node->refs);
@@ -7578,7 +7565,7 @@ static void io_file_data_ref_zero(struct percpu_ref *ref)
data = ref_node->file_data;
ctx = data->ctx;
- spin_lock(&data->lock);
+ spin_lock_bh(&data->lock);
ref_node->done = true;
while (!list_empty(&data->ref_list)) {
@@ -7590,7 +7577,7 @@ static void io_file_data_ref_zero(struct percpu_ref *ref)
list_del(&ref_node->node);
first_add |= llist_add(&ref_node->llist, &ctx->file_put_llist);
}
- spin_unlock(&data->lock);
+ spin_unlock_bh(&data->lock);
if (percpu_ref_is_dying(&data->refs))
delay = 0;
@@ -7713,9 +7700,9 @@ static int io_sqe_files_register(struct io_ring_ctx *ctx, void __user *arg,
}
file_data->node = ref_node;
- spin_lock(&file_data->lock);
+ spin_lock_bh(&file_data->lock);
list_add_tail(&ref_node->node, &file_data->ref_list);
- spin_unlock(&file_data->lock);
+ spin_unlock_bh(&file_data->lock);
percpu_ref_get(&file_data->refs);
return ret;
out_fput:
@@ -7872,10 +7859,10 @@ static int __io_sqe_files_update(struct io_ring_ctx *ctx,
if (needs_switch) {
percpu_ref_kill(&data->node->refs);
- spin_lock(&data->lock);
+ spin_lock_bh(&data->lock);
list_add_tail(&ref_node->node, &data->ref_list);
data->node = ref_node;
- spin_unlock(&data->lock);
+ spin_unlock_bh(&data->lock);
percpu_ref_get(&ctx->file_data->refs);
} else
destroy_fixed_file_ref_node(ref_node);
--
Jens Axboe
^ permalink raw reply related
* [PATCH net] dpaa2-eth: Fix compile error due to missing devlink support
From: Ioana Ciornei @ 2020-11-23 16:35 UTC (permalink / raw)
To: kuba, netdev; +Cc: Ezequiel Garcia, Ioana Ciornei
From: Ezequiel Garcia <ezequiel@collabora.com>
The dpaa2 driver depends on devlink, so it should select
NET_DEVLINK in order to fix compile errors, such as:
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.o: in function `dpaa2_eth_rx_err':
dpaa2-eth.c:(.text+0x3cec): undefined reference to `devlink_trap_report'
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth-devlink.o: in function `dpaa2_eth_dl_info_get':
dpaa2-eth-devlink.c:(.text+0x160): undefined reference to `devlink_info_driver_name_put'
Fixes: ceeb03ad8e22 ("dpaa2-eth: add basic devlink support")
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/net/ethernet/freescale/dpaa2/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/dpaa2/Kconfig b/drivers/net/ethernet/freescale/dpaa2/Kconfig
index c0e05f71826d..ee7a906e30b3 100644
--- a/drivers/net/ethernet/freescale/dpaa2/Kconfig
+++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
@@ -5,6 +5,7 @@ config FSL_DPAA2_ETH
select PHYLINK
select PCS_LYNX
select FSL_XGMAC_MDIO
+ select NET_DEVLINK
help
This is the DPAA2 Ethernet driver supporting Freescale SoCs
with DPAA2 (DataPath Acceleration Architecture v2).
--
2.28.0
^ permalink raw reply related
* Re: [net v3] net/tls: missing received data after fast remote close
From: Jakub Kicinski @ 2020-11-23 16:34 UTC (permalink / raw)
To: Vadim Fedorenko; +Cc: Boris Pismenny, Aviad Yehezkel, netdev
In-Reply-To: <64311360-e363-133c-6862-4de1298942ee@novek.ru>
On Mon, 23 Nov 2020 13:40:46 +0000 Vadim Fedorenko wrote:
> On 20.11.2020 18:26, Jakub Kicinski wrote:
> > On Thu, 19 Nov 2020 18:59:48 +0300 Vadim Fedorenko wrote:
> >> In case when tcp socket received FIN after some data and the
> >> parser haven't started before reading data caller will receive
> >> an empty buffer. This behavior differs from plain TCP socket and
> >> leads to special treating in user-space.
> >> The flow that triggers the race is simple. Server sends small
> >> amount of data right after the connection is configured to use TLS
> >> and closes the connection. In this case receiver sees TLS Handshake
> >> data, configures TLS socket right after Change Cipher Spec record.
> >> While the configuration is in process, TCP socket receives small
> >> Application Data record, Encrypted Alert record and FIN packet. So
> >> the TCP socket changes sk_shutdown to RCV_SHUTDOWN and sk_flag with
> >> SK_DONE bit set. The received data is not parsed upon arrival and is
> >> never sent to user-space.
> >>
> >> Patch unpauses parser directly if we have unparsed data in tcp
> >> receive queue.
> >>
> >> Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
> > Applied, thanks!
> Looks like I missed fixes tag to queue this patch to -stable.
>
> Fixes: c46234ebb4d1 ("tls: RX path for ktls")
I put this on:
Fixes: fcf4793e278e ("tls: check RCV_SHUTDOWN in tls_wait_data")
It's queued for stable, but it needs to hit Linus' tree first, so it'll
take another week or so to show up in stable releases.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Joe Perches, Kees Cook, Jakub Kicinski, alsa-devel,
linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
linux-fbdev, dri-devel, linux-kernel, Nathan Chancellor,
linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
linux-security-module, amd-gfx, linux-stm32, cluster-devel,
linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
tipc-discussion, linux-ext4, linux-media, linux-watchdog, selinux,
linux-arm-msm, intel-gfx, linux-geode, linux-can, linux-block,
linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
linux-hams, ceph-devel, virtualization, linux-arm-kernel,
linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
linux-decnet-user, linux-mmc, linux-renesas-soc, linux-sctp,
linux-usb, netfilter-devel, linux-crypto, patches,
linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
Greg KH
In-Reply-To: <20201123130348.GA3119@embeddedor>
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > >
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions. Very few were logging only.
> > > >
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)? hopefully this isn't a US election
> > > > situation ...
> > >
> > > Gustavo? Are you running for congress now?
> > >
> > > https://lwn.net/Articles/794944/
> >
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
>
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
>
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/
I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.
> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).
Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge. I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.
> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov
Really, no. Something that can't be measured at all doesn't exist.
And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it. Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits. It can be quite impressive if Y is a suitably big
number.
James
^ permalink raw reply
* Re: [PATCH 000/141] Fix fall-through warnings for Clang
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
To: James Bottomley, Miguel Ojeda
Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
linux-atm-general, linux-block, linux-can, linux-cifs,
Linux Crypto Mailing List, linux-decnet-user,
Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
linux-input, linux-integrity, linux-mediatek,
Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
linux-security-module, linux-stm32, linux-usb, linux-watchdog,
linux-wireless, Network Development, netfilter-devel, nouveau,
op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
samba-technical, selinux, target-devel, tipc-discussion,
usb-storage, virtualization, wcn36xx,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), xen-devel,
linux-hardening, Nick Desaulniers, Nathan Chancellor,
Miguel Ojeda
In-Reply-To: <fc45750b6d0277c401015b7aa11e16cd15f32ab2.camel@HansenPartnership.com>
On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
https://www.wired.com/story/open-source-coders-few-tired/
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
It's unclear how to measure value in consistency.
But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.
The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file. That's not a trivial number.
$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446
I think the question you are asking is about trust and how it
effects development.
And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.
^ permalink raw reply
* [PATCH] tools/testing: add kselftest shell helper library
From: Willem de Bruijn @ 2020-11-23 16:25 UTC (permalink / raw)
To: linux-kselftest; +Cc: netdev, kuba, acardace, shuah, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Kselftest expects processes to signal pass/fail/skip through exitcode.
C programs can include kselftest.h for readable definitions.
Add analogous kselftest.sh for shell tests. Extract the existing
definitions from udpgso_bench.sh.
Tested: make TARGETS=net kselftest
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20201113231655.139948-4-acardace@redhat.com/
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
applies cleanly to netnext (f9e425e99b07) and kselftest (v5.10-rc1)
---
tools/testing/selftests/kselftest.sh | 52 +++++++++++++++++++++
tools/testing/selftests/net/udpgso_bench.sh | 42 +----------------
2 files changed, 53 insertions(+), 41 deletions(-)
create mode 100644 tools/testing/selftests/kselftest.sh
diff --git a/tools/testing/selftests/kselftest.sh b/tools/testing/selftests/kselftest.sh
new file mode 100644
index 000000000000..c5a1cff57402
--- /dev/null
+++ b/tools/testing/selftests/kselftest.sh
@@ -0,0 +1,52 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# kselftest shell test support library
+#
+# - Define pass/fail/skip exitcodes
+# - Multiprocess support: aggregate child process results
+
+readonly KSFT_PASS=0
+readonly KSFT_FAIL=1
+readonly KSFT_SKIP=4
+
+readonly GREEN='\033[0;92m'
+readonly YELLOW='\033[0;33m'
+readonly RED='\033[0;31m'
+readonly NC='\033[0m' # No Color
+
+num_pass=0
+num_err=0
+num_skip=0
+
+# Test child process exit code, add to aggregates.
+kselftest_test_exitcode() {
+ local -r exitcode=$1
+
+ if [[ ${exitcode} -eq ${KSFT_PASS} ]]; then
+ num_pass=$(( $num_pass + 1 ))
+ elif [[ ${exitcode} -eq ${KSFT_SKIP} ]]; then
+ num_skip=$(( $num_skip + 1 ))
+ else
+ num_err=$(( $num_err + 1 ))
+ fi
+}
+
+# Exit from main process.
+kselftest_exit() {
+ echo -e "$(basename $0): PASS=${num_pass} SKIP=${num_skip} FAIL=${num_err}"
+
+ if [[ $num_err -ne 0 ]]; then
+ echo -e "$(basename $0): ${RED}FAIL${NC}"
+ exit ${KSFT_FAIL}
+ fi
+
+ if [[ $num_skip -ne 0 ]]; then
+ echo -e "$(basename $0): ${YELLOW}SKIP${NC}"
+ exit ${KSFT_SKIP}
+ fi
+
+ echo -e "$(basename $0): ${GREEN}PASS${NC}"
+ exit ${KSFT_PASS}
+}
+
diff --git a/tools/testing/selftests/net/udpgso_bench.sh b/tools/testing/selftests/net/udpgso_bench.sh
index 80b5d352702e..c1f9affe6cf0 100755
--- a/tools/testing/selftests/net/udpgso_bench.sh
+++ b/tools/testing/selftests/net/udpgso_bench.sh
@@ -3,47 +3,7 @@
#
# Run a series of udpgso benchmarks
-readonly GREEN='\033[0;92m'
-readonly YELLOW='\033[0;33m'
-readonly RED='\033[0;31m'
-readonly NC='\033[0m' # No Color
-
-readonly KSFT_PASS=0
-readonly KSFT_FAIL=1
-readonly KSFT_SKIP=4
-
-num_pass=0
-num_err=0
-num_skip=0
-
-kselftest_test_exitcode() {
- local -r exitcode=$1
-
- if [[ ${exitcode} -eq ${KSFT_PASS} ]]; then
- num_pass=$(( $num_pass + 1 ))
- elif [[ ${exitcode} -eq ${KSFT_SKIP} ]]; then
- num_skip=$(( $num_skip + 1 ))
- else
- num_err=$(( $num_err + 1 ))
- fi
-}
-
-kselftest_exit() {
- echo -e "$(basename $0): PASS=${num_pass} SKIP=${num_skip} FAIL=${num_err}"
-
- if [[ $num_err -ne 0 ]]; then
- echo -e "$(basename $0): ${RED}FAIL${NC}"
- exit ${KSFT_FAIL}
- fi
-
- if [[ $num_skip -ne 0 ]]; then
- echo -e "$(basename $0): ${YELLOW}SKIP${NC}"
- exit ${KSFT_SKIP}
- fi
-
- echo -e "$(basename $0): ${GREEN}PASS${NC}"
- exit ${KSFT_PASS}
-}
+source "$(dirname $0)/../kselftest.sh"
wake_children() {
local -r jobs="$(jobs -p)"
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related
* Re: [PATCH 000/141] Fix fall-through warnings for Clang
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
To: James Bottomley
Cc: Miguel Ojeda, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
linux-kernel,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
amd-gfx list, bridge, ceph-devel, cluster-devel, coreteam, devel,
dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
linux1394-devel, ACPI Devel Maling List, linux-afs, Linux ARM,
linux-arm-msm, linux-atm-general, linux-block, linux-can,
linux-cifs, Linux Crypto Mailing List, linux-decnet-user,
Ext4 Developers List, open list:FRAMEBUFFER LAYER, linux-geode,
linux-gpio, linux-hams, linux-hwmon, linux-i3c,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
linux-iio, linux-input, linux-integrity,
moderated list:ARM/Mediatek SoC..., Linux Media Mailing List,
linux-mmc, Linux-MM, linux-mtd, linux-nfs, linux-rdma,
Linux-Renesas, open list:TARGET SUBSYSTEM, linux-sctp,
linux-security-module, linux-stm32,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:, linux-watchdog,
linux-wireless, Network Development, netfilter-devel, nouveau,
op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
samba-technical, selinux, target-devel, tipc-discussion,
usb-storage, virtualization, wcn36xx,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), xen-devel,
linux-hardening, Nick Desaulniers, Nathan Chancellor,
Miguel Ojeda, Joe Perches
In-Reply-To: <fc45750b6d0277c401015b7aa11e16cd15f32ab2.camel@HansenPartnership.com>
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
[cut]
> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
Right.
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.
Absolutely.
This is just one of the factors involved, but a significant one IMV.
^ permalink raw reply
* [PATCH] nfc: s3fwrn5: use signed integer for parsing GPIO numbers
From: Krzysztof Kozlowski @ 2020-11-23 16:23 UTC (permalink / raw)
To: David S. Miller, Jakub Kicinski, Bongsu Jeon, Krzysztof Kozlowski,
Krzysztof Opasiak, linux-nfc, netdev, linux-kernel
Cc: stable
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned int
because in case of !CONFIG_GPIOLIB such number would be a valid GPIO.
Fixes: c04c674fadeb ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/nfc/s3fwrn5/i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/i2c.c b/drivers/nfc/s3fwrn5/i2c.c
index 0ffa389066a0..ae26594c7302 100644
--- a/drivers/nfc/s3fwrn5/i2c.c
+++ b/drivers/nfc/s3fwrn5/i2c.c
@@ -25,8 +25,8 @@ struct s3fwrn5_i2c_phy {
struct i2c_client *i2c_dev;
struct nci_dev *ndev;
- unsigned int gpio_en;
- unsigned int gpio_fw_wake;
+ int gpio_en;
+ int gpio_fw_wake;
struct mutex mutex;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH V2 net 4/4] net: ena: return error code from ena_xdp_xmit_buff
From: Jakub Kicinski @ 2020-11-23 16:18 UTC (permalink / raw)
To: Shay Agroskin
Cc: netdev, dwmw, zorik, matua, saeedb, msw, aliguori, nafea, gtzalik,
netanel, alisaidi, benh, akiyano, sameehj, ndagan
In-Reply-To: <pj41zl7dqddfkm.fsf@u68c7b5b1d2d758.ant.amazon.com>
On Sun, 22 Nov 2020 09:19:05 +0200 Shay Agroskin wrote:
> Jakub Kicinski <kuba@kernel.org> writes:
>
> > On Thu, 19 Nov 2020 22:28:51 +0200 Shay Agroskin wrote:
> >> The function mistakenly returns NETDEV_TX_OK regardless of the
> >> transmission success. This patch fixes this behavior by
> >> returning the
> >> error code from the function.
> >>
> >> Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action")
> >> Signed-off-by: Shay Agroskin <shayagr@amazon.com>
> >
> > Doesn't seem like a legitimate bug fix, since the only caller of
> > this
> > function ignores its return value.
>
> Hi,
> I plan to use the return value from this function in future patch
> (next-net series), do you think we better send this fix with
> this future patch?
Yes, it's fine to include this in a net-next series. It doesn't fix any
bug that could cause trouble to the users. If you had a fix that
depended on it then maybe, but if you only need it in net-next we can
put it there with clear conscience.
^ permalink raw reply
* Re: [RFC] MAINTAINERS tag for cleanup robot
From: Lukas Bulwahn @ 2020-11-23 16:17 UTC (permalink / raw)
To: Jani Nikula
Cc: James Bottomley, Tom Rix, Joe Perches, clang-built-linux,
linux-hyperv, kvm, linux-fbdev, dri-devel, platform-driver-x86,
ibm-acpi-devel, open list:ASYMMETRIC KEYS, linux-mtd, linux-scsi,
amd-gfx, cluster-devel, linux-acpi, tboot-devel, coreteam,
xen-devel, MPT-FusionLinux.pdl, Linux Media Mailing List,
alsa-devel, intel-gfx, ecryptfs, linux-omap, devel, linux-nfs,
Netdev, linux-usb, linux-wireless, Linux Kernel Mailing List,
linux-bluetooth, netfilter-devel, linux-crypto, patches,
linux-fsdevel, bpf
In-Reply-To: <87y2ism5or.fsf@intel.com>
On Mon, Nov 23, 2020 at 4:52 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Sat, 21 Nov 2020, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > On Sat, 2020-11-21 at 08:50 -0800, trix@redhat.com wrote:
> >> A difficult part of automating commits is composing the subsystem
> >> preamble in the commit log. For the ongoing effort of a fixer
> >> producing
> >> one or two fixes a release the use of 'treewide:' does not seem
> >> appropriate.
> >>
> >> It would be better if the normal prefix was used. Unfortunately
> >> normal is
> >> not consistent across the tree.
> >>
> >>
> >> D: Commit subsystem prefix
> >>
> >> ex/ for FPGA DFL DRIVERS
> >>
> >> D: fpga: dfl:
> >>
> >
> > I've got to bet this is going to cause more issues than it solves.
>
> Agreed.
>
Tom, this a problem only kernel janitors encounter; all other
developers really do not have that issue. The time spent on creating
the patch is much larger than the amount saved if the commit log
header line prefix would be derived automatically. I believe Julia
Lawall, Arnd Bergmann and Nathan Chancellor as long-term
high-frequency janitors do have already scripted approaches to that
issue. Maybe they simply need to share these scripts with you and you
consolidate them and share with everyone?
Also, making clean-up patches cumbersome has a positive side as well;
maintainers are not swamped with fully automated patch submissions.
There have been some bad experiences with some submitters on that in
the past...
> > SCSI uses scsi: <driver>: for drivers but not every driver has a
> > MAINTAINERS entry. We use either scsi: or scsi: core: for mid layer
> > things, but we're not consistent. Block uses blk-<something>: for all
> > of it's stuff but almost no <somtehing>s have a MAINTAINERS entry. So
> > the next thing you're going to cause is an explosion of suggested
> > MAINTAINERs entries.
>
> On the one hand, adoption of new MAINTAINERS entries has been really
> slow. Look at B, C, or P, for instance. On the other hand, if this were
> to get adopted, you'll potentially get conflicting prefixes for patches
> touching multiple files. Then what?
>
> I'm guessing a script looking at git log could come up with better
> suggestions for prefixes via popularity contest than manually maintained
> MAINTAINERS entries. It might not always get it right, but then human
> outsiders aren't going to always get it right either.
>
> Now you'll only need Someone(tm) to write the script. ;)
>
> Something quick like this:
>
> git log --since={1year} --pretty=format:%s -- <FILES> |\
> grep -v "^\(Merge\|Revert\)" |\
> sed 's/:[^:]*$//' |\
> sort | uniq -c | sort -rn | head -5
>
> already gives me results that really aren't worse than some of the
> prefixes invented by drive-by contributors.
>
I agree I do not see the need to introduce something in MAINTAINERS;
from my observations maintaining MAINTAINERS, there is sufficient work
on adoption and maintenance of the existing entries already without
such an yet another additional entry. Some entries are outdated or
wrong and the janitor task of cleaning those up is already enough work
for involved janitors and enough churn for involved maintainers. So a
machine-learned approach as above is probably good enough, but if you
think you need more complex rules try to learn them from the data at
hand... certainly a nice task to do with machine learning on commit
message prefixes.
Lukas
^ permalink raw reply
* Re: [PATCH net] netdevice.h: Fix unintentional disable of ALL_FOR_ALL features on upper device
From: Tariq Toukan @ 2020-11-23 16:15 UTC (permalink / raw)
To: Eric Dumazet, Tariq Toukan
Cc: David S. Miller, Jakub Kicinski, Herbert Xu, netdev,
Moshe Shemesh, Maxim Mikityanskiy, Saeed Mahameed
In-Reply-To: <CANn89iKRVyTZg-tNQvo_Ub-RZ_A+OOQQY8Py3J9fx=NOZXF9Qw@mail.gmail.com>
On 11/23/2020 4:55 PM, Eric Dumazet wrote:
> On Mon, Nov 23, 2020 at 3:13 PM Tariq Toukan <tariqt@nvidia.com> wrote:
>>
>> Calling netdev_increment_features() on upper/master device from
>> netdev_add_tso_features() implies unintentional clearance of ALL_FOR_ALL
>> features supported by all slaves. Fix it by passing ALL_FOR_ALL in
>> addition to ALL_TSO.
>>
>> Fixes: b0ce3508b25e ("bonding: allow TSO being set on bonding master")
>
> I think you should give more details to your bug report, because
> netdev_add_tso_features() is used from different
> places.
>
> Thanks.
>
Right. I'll include these in the re-spin:
Fixes: 247f6d0f8667 ("team: allow TSO being set on master")
Fixes: f902e8812ef6 ("bridge: Add ability to enable TSO")
I wonder though if netdev_increment_features() is expected to clear
features that are not part of the mask.
Thanks.
^ permalink raw reply
* pull-request: wireless-drivers-2020-11-23
From: Kalle Valo @ 2020-11-23 16:10 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
Hi,
here's a pull request to net tree, more info below. Please let me know if there
are any problems.
Kalle
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-2020-11-23
for you to fetch changes up to fe56d05ee6c87f6a1a8c7267affd92c9438249cc:
iwlwifi: mvm: fix kernel panic in case of assert during CSA (2020-11-10 20:45:36 +0200)
----------------------------------------------------------------
wireless-drivers fixes for v5.10
First set of fixes for v5.10. One fix for iwlwifi kernel panic, others
less notable.
rtw88
* fix a bogus test found by clang
iwlwifi
* fix long memory reads causing soft lockup warnings
* fix kernel panic during Channel Switch Announcement (CSA)
* other smaller fixes
MAINTAINERS
* email address updates
----------------------------------------------------------------
Avraham Stern (1):
iwlwifi: mvm: write queue_sync_state only for sync
Chi-Hsien Lin (1):
MAINTAINERS: update maintainers list for Cypress
Emmanuel Grumbach (2):
iwlwifi: mvm: use the HOT_SPOT_CMD to cancel an AUX ROC
iwlwifi: mvm: properly cancel a session protection for P2P
Johannes Berg (2):
iwlwifi: pcie: limit memory read spin time
iwlwifi: pcie: set LTR to avoid completion timeout
Mordechay Goodstein (1):
iwlwifi: sta: set max HE max A-MPDU according to HE capa
Sara Sharon (1):
iwlwifi: mvm: fix kernel panic in case of assert during CSA
Tom Rix (1):
rtw88: fix fw_fifo_addr check
Yan-Hsuan Chuang (1):
MAINTAINERS: update Yan-Hsuan's email address
MAINTAINERS | 9 +-
drivers/net/wireless/intel/iwlwifi/fw/api/sta.h | 10 +-
.../net/wireless/intel/iwlwifi/fw/api/time-event.h | 8 +-
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 10 ++
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 18 ++++
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 103 ++++++++++++++-------
.../wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c | 20 ++++
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 36 +++++--
drivers/net/wireless/realtek/rtw88/fw.c | 2 +-
10 files changed, 164 insertions(+), 57 deletions(-)
^ permalink raw reply
* RE: [EXT] Re: [PATCH v1] net: mvpp2: divide fifo for dts-active ports only
From: Stefan Chulski @ 2020-11-23 16:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: netdev@vger.kernel.org, thomas.petazzoni@bootlin.com,
davem@davemloft.net, Nadav Haklai, Yan Markman,
linux-kernel@vger.kernel.org, kuba@kernel.org, mw@semihalf.com,
andrew@lunn.ch
In-Reply-To: <20201123155148.GX1551@shell.armlinux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Sent: Monday, November 23, 2020 5:52 PM
> To: Stefan Chulski <stefanc@marvell.com>
> Cc: netdev@vger.kernel.org; thomas.petazzoni@bootlin.com;
> davem@davemloft.net; Nadav Haklai <nadavh@marvell.com>; Yan Markman
> <ymarkman@marvell.com>; linux-kernel@vger.kernel.org; kuba@kernel.org;
> mw@semihalf.com; andrew@lunn.ch
> Subject: Re: [EXT] Re: [PATCH v1] net: mvpp2: divide fifo for dts-active ports
> only
>
> On Mon, Nov 23, 2020 at 03:44:05PM +0000, Stefan Chulski wrote:
> > Yes, but this allocation exists also in current code.
> > From HW point of view(MAC and PPv2) maximum supported speed in CP110:
> > port 0 - 10G, port 1 - 2.5G, port 2 - 2.5G.
> > in CP115: port 0 - 10G, port 1 - 5G, port 2 - 2.5G.
> >
> > So this allocation looks correct at least for CP115.
> > Problem that we cannot reallocate FIFO during runtime, after specific speed
> negotiation.
>
> We could do much better. DT has a "max-speed" property for ethernet
> controllers. If we have that property, then I think we should use that to
> determine the initialisation time FIFO allocation.
>
> As I say, on Macchiatobin, the allocations we end up with are just crazy when
> you consider the port speeds that the hardware supports.
> Maybe that should be done as a follow-on patch - but I think it needs to be
> done.
I agree with you. We can use "max-speed" for better FIFO allocations.
I plan to upstream more fixes from the "Marvell" devel branch then I can prepare this patch.
So you OK with this patch and then follow-on improvement?
Regards.
^ permalink raw reply
* Re: [PATCH] drivers: Fix the Raspberry Pi debug version compile
From: Kalle Valo @ 2020-11-23 15:59 UTC (permalink / raw)
To: hby; +Cc: davem, kuba, linux-wireless, netdev, linux-kernel
In-Reply-To: <20201122100606.20289-1-hby2003@163.com>
hby <hby2003@163.com> writes:
> enable the DEBUG in source code, and it will compile fail,
> modify the DEBUG macro, to adapt the compile
>
> Signed-off-by: hby <hby2003@163.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
This has nothing to do with Raspberry Pi, so the title should be:
brmcfmac: fix compile when DEBUG is defined
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 000/141] Fix fall-through warnings for Clang
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
linux-atm-general, linux-block, linux-can, linux-cifs,
Linux Crypto Mailing List, linux-decnet-user,
Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
linux-input, linux-integrity, linux-mediatek,
Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
linux-security-module, linux-stm32, linux-usb, linux-watchdog,
linux-wireless, Network Development, netfilter-devel, nouveau,
op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
samba-technical, selinux, target-devel, tipc-discussion,
usb-storage, virtualization, wcn36xx,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), xen-devel,
linux-hardening, Nick Desaulniers, Nathan Chancellor,
Miguel Ojeda, Joe Perches
In-Reply-To: <CANiq72m22Jb5_+62NnwX8xds2iUdWDMAqD8PZw9cuxdHd95W0A@mail.gmail.com>
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches. Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series. So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time. The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
>
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.
Well, I used git. It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.
> > It's not about the risk of the changes it's about the cost of
> > implementing them. Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes. Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially. But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it. And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
>
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.
We're also complaining about the inability to recruit maintainers:
https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
And burn out:
http://antirez.com/news/129
The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.
> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.
What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.
One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.
James
^ permalink raw reply
* Re: [PATCH] drivers: Fix the Raspberry Pi debug version compile
From: Kalle Valo @ 2020-11-23 15:56 UTC (permalink / raw)
To: byhoo
Cc: davem@davemloft.net, kuba@kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5359213d.1442.175ef72e5b7.Coremail.hby2003@163.com>
byhoo <hby2003@163.com> writes:
> The steps:
> 1. add "#define DEBUG" in
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c line 61.
> 2. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=../Out_Linux
> bcm2835_defconfig
> 3. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=../Out_Linux/
> zImage modules dtbs -j8
>
> Then, it will fail, the compile log described below:
>
> Kernel: arch/arm/boot/zImage is ready MODPOST Module.symvers ERROR:
> modpost: "brcmf_debugfs_add_entry"
> [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko]
> undefined! ERROR: modpost: "brcmf_debugfs_get_devdir"
> [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko]
> undefined! ERROR: modpost: "__brcmf_dbg"
> [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko]
> undefined!
> /home/hby/gitee/linux_origin/Linux/scripts/Makefile.modpost:111:
> recipe for target 'Module.symvers' failed make[2]: ***
> [Module.symvers] Error 1 make[2]: *** Deleting file 'Module.symvers'
> /home/hby/gitee/linux_origin/Linux/Makefile:1390: recipe for target
> 'modules' failed make[1]: *** [modules] Error 2 make[1]: Leaving
> directory '/home/hby/gitee/linux_origin/Out_Linux' Makefile:185:
> recipe for target '__sub-make' failed make: *** [__sub-make] Error 2
Please add this info to the commit log.
And please don't submit HTML emails, the lists will drop those
automatically. See the wiki below for more info.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] entry: Fix boot for !CONFIG_GENERIC_ENTRY
From: Gabriel Krisman Bertazi @ 2020-11-23 15:54 UTC (permalink / raw)
To: Jann Horn
Cc: Arnd Bergmann, Andy Lutomirski, Thomas Gleixner, Naresh Kamboju,
open list, Netdev, bpf, lkft-triage, Linux ARM, Daniel Borkmann,
Kees Cook, Andrii Nakryiko, Song Liu, Yonghong Song,
Andy Lutomirski, Sumit Semwal, Arnd Bergmann, YiFei Zhu
In-Reply-To: <87h7pgqhdf.fsf@collabora.com>
Gabriel Krisman Bertazi <krisman@collabora.com> writes:
> Jann Horn <jannh@google.com> writes:
>> As part of fixing this, it might be a good idea to put "enum
>> syscall_work_bit" behind a "#ifdef CONFIG_GENERIC_ENTRY" to avoid
>> future accidents like this?
>
> Hi Jan, Arnd,
>
> That is correct. This is a copy pasta mistake. My apologies. I didn't
> have a !GENERIC_ENTRY device to test, but just the ifdef would have
> caught it.
I have patched it as suggested. Tested on qemu for arm32 and on bare
metal for x86-64.
Once again, my apologies for the mistake.
-- >8 --
Subject: [PATCH] entry: Fix boot for !CONFIG_GENERIC_ENTRY
A copy-pasta mistake tries to set SYSCALL_WORK flags instead of TIF
flags for !CONFIG_GENERIC_ENTRY. Also, add safeguards to catch this at
compilation time.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
---
include/linux/thread_info.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index 6a597fd5d351..45ad3176e2fa 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -35,6 +35,7 @@ enum {
GOOD_STACK,
};
+#ifdef CONFIG_GENERIC_ENTRY
enum syscall_work_bit {
SYSCALL_WORK_BIT_SECCOMP,
SYSCALL_WORK_BIT_SYSCALL_TRACEPOINT,
@@ -48,6 +49,7 @@ enum syscall_work_bit {
#define SYSCALL_WORK_SYSCALL_TRACE BIT(SYSCALL_WORK_BIT_SYSCALL_TRACE)
#define SYSCALL_WORK_SYSCALL_EMU BIT(SYSCALL_WORK_BIT_SYSCALL_EMU)
#define SYSCALL_WORK_SYSCALL_AUDIT BIT(SYSCALL_WORK_BIT_SYSCALL_AUDIT)
+#endif
#include <asm/thread_info.h>
@@ -127,11 +129,11 @@ static inline int test_ti_thread_flag(struct thread_info *ti, int flag)
clear_bit(SYSCALL_WORK_BIT_##fl, &task_thread_info(t)->syscall_work)
#else
#define set_syscall_work(fl) \
- set_ti_thread_flag(current_thread_info(), SYSCALL_WORK_##fl)
+ set_ti_thread_flag(current_thread_info(), TIF_##fl)
#define test_syscall_work(fl) \
- test_ti_thread_flag(current_thread_info(), SYSCALL_WORK_##fl)
+ test_ti_thread_flag(current_thread_info(), TIF_##fl)
#define clear_syscall_work(fl) \
- clear_ti_thread_flag(current_thread_info(), SYSCALL_WORK_##fl)
+ clear_ti_thread_flag(current_thread_info(), TIF_##fl)
#define set_task_syscall_work(t, fl) \
set_ti_thread_flag(task_thread_info(t), TIF_##fl)
--
2.29.2
^ permalink raw reply related
* Re: [RFC] MAINTAINERS tag for cleanup robot
From: Jani Nikula @ 2020-11-23 15:52 UTC (permalink / raw)
To: James Bottomley, trix, joe, clang-built-linux
Cc: linux-hyperv, kvm, linux-fbdev, dri-devel, platform-driver-x86,
ibm-acpi-devel, keyrings, linux-mtd, linux-scsi, amd-gfx,
cluster-devel, linux-acpi, tboot-devel, coreteam, xen-devel,
MPT-FusionLinux.pdl, linux-media, alsa-devel, intel-gfx, ecryptfs,
linux-omap, devel, linux-nfs, netdev, linux-usb, linux-wireless,
linux-kernel, linux-bluetooth, netfilter-devel, linux-crypto,
patches, linux-fsdevel, bpf
In-Reply-To: <5843ef910b0e86c00d9c0143dec20f93823b016b.camel@HansenPartnership.com>
On Sat, 21 Nov 2020, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> On Sat, 2020-11-21 at 08:50 -0800, trix@redhat.com wrote:
>> A difficult part of automating commits is composing the subsystem
>> preamble in the commit log. For the ongoing effort of a fixer
>> producing
>> one or two fixes a release the use of 'treewide:' does not seem
>> appropriate.
>>
>> It would be better if the normal prefix was used. Unfortunately
>> normal is
>> not consistent across the tree.
>>
>>
>> D: Commit subsystem prefix
>>
>> ex/ for FPGA DFL DRIVERS
>>
>> D: fpga: dfl:
>>
>
> I've got to bet this is going to cause more issues than it solves.
Agreed.
> SCSI uses scsi: <driver>: for drivers but not every driver has a
> MAINTAINERS entry. We use either scsi: or scsi: core: for mid layer
> things, but we're not consistent. Block uses blk-<something>: for all
> of it's stuff but almost no <somtehing>s have a MAINTAINERS entry. So
> the next thing you're going to cause is an explosion of suggested
> MAINTAINERs entries.
On the one hand, adoption of new MAINTAINERS entries has been really
slow. Look at B, C, or P, for instance. On the other hand, if this were
to get adopted, you'll potentially get conflicting prefixes for patches
touching multiple files. Then what?
I'm guessing a script looking at git log could come up with better
suggestions for prefixes via popularity contest than manually maintained
MAINTAINERS entries. It might not always get it right, but then human
outsiders aren't going to always get it right either.
Now you'll only need Someone(tm) to write the script. ;)
Something quick like this:
git log --since={1year} --pretty=format:%s -- <FILES> |\
grep -v "^\(Merge\|Revert\)" |\
sed 's/:[^:]*$//' |\
sort | uniq -c | sort -rn | head -5
already gives me results that really aren't worse than some of the
prefixes invented by drive-by contributors.
> Has anyone actually complained about treewide:?
As Joe said, I'd feel silly applying patches to drivers with that
prefix. If it gets applied by someone else higher up, literally
treewide, then no complaints.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [EXT] Re: [PATCH v1] net: mvpp2: divide fifo for dts-active ports only
From: Russell King - ARM Linux admin @ 2020-11-23 15:51 UTC (permalink / raw)
To: Stefan Chulski
Cc: netdev@vger.kernel.org, thomas.petazzoni@bootlin.com,
davem@davemloft.net, Nadav Haklai, Yan Markman,
linux-kernel@vger.kernel.org, kuba@kernel.org, mw@semihalf.com,
andrew@lunn.ch
In-Reply-To: <CO6PR18MB3873B4205ECAF2383F9539CCB0FC0@CO6PR18MB3873.namprd18.prod.outlook.com>
On Mon, Nov 23, 2020 at 03:44:05PM +0000, Stefan Chulski wrote:
> > > > On Mon, Nov 23, 2020 at 04:52:40PM +0200, stefanc@marvell.com wrote:
> > > > > From: Stefan Chulski <stefanc@marvell.com>
> > > > >
> > > > > Tx/Rx FIFO is a HW resource limited by total size, but shared by
> > > > > all ports of same CP110 and impacting port-performance.
> > > > > Do not divide the FIFO for ports which are not enabled in DTS, so
> > > > > active ports could have more FIFO.
> > > > >
> > > > > The active port mapping should be done in probe before FIFO-init.
> > > >
> > > > It would be nice to know what the effect is from this - is it a
> > > > small or large boost in performance?
> > >
> > > I didn't saw any significant improvement with LINUX bridge or
> > > forwarding, but this reduced PPv2 overruns drops, reduced CRC sent errors
> > with DPDK user space application.
> > > So this improved zero loss throughput. Probably with XDP we would see a
> > similar effect.
> > >
> > > > What is the effect when the ports on a CP110 are configured for 10G,
> > > > 1G, and 2.5G in that order, as is the case on the Macchiatobin board?
> > >
> > > Macchiatobin has two CP's. CP1 has 3 ports, so the distribution of FIFO would
> > be the same as before.
> > > On CP0 which has a single port, all FIFO would be allocated for 10G port.
> >
> > Your code allocates for CP1:
> >
> > 32K to port 0 (the 10G port on Macchiatobin) 8K to port 1 (the 1G dedicated
> > ethernet port on Macchiatobin) 4K to port 2 (the 1G/2.5G SFP port on
> > Macchiatobin)
> >
> > I'm questioning that allocation for port 1 and 2.
>
> Yes, but this allocation exists also in current code.
> From HW point of view(MAC and PPv2) maximum supported speed
> in CP110: port 0 - 10G, port 1 - 2.5G, port 2 - 2.5G.
> in CP115: port 0 - 10G, port 1 - 5G, port 2 - 2.5G.
>
> So this allocation looks correct at least for CP115.
> Problem that we cannot reallocate FIFO during runtime, after specific speed negotiation.
We could do much better. DT has a "max-speed" property for ethernet
controllers. If we have that property, then I think we should use
that to determine the initialisation time FIFO allocation.
As I say, on Macchiatobin, the allocations we end up with are just
crazy when you consider the port speeds that the hardware supports.
Maybe that should be done as a follow-on patch - but I think it
needs to be done.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH v2 net-next] net: page_pool: Add page_pool_put_page_bulk() to page_pool.rst
From: Lorenzo Bianconi @ 2020-11-23 15:45 UTC (permalink / raw)
To: netdev; +Cc: lorenzo.bianconi, davem, kuba, brouer, ilias.apalodimas
Introduce page_pool_put_page_bulk() entry into the API section of
page_pool.rst
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes since v1:
- addressed Ilias's comments
---
Documentation/networking/page_pool.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/networking/page_pool.rst b/Documentation/networking/page_pool.rst
index 43088ddf95e4..a147591ce203 100644
--- a/Documentation/networking/page_pool.rst
+++ b/Documentation/networking/page_pool.rst
@@ -97,6 +97,14 @@ a page will cause no race conditions is enough.
* page_pool_get_dma_dir(): Retrieve the stored DMA direction.
+* page_pool_put_page_bulk(): Tries to refill a number of pages into the
+ ptr_ring cache holding ptr_ring producer lock. If the ptr_ring is full,
+ page_pool_put_page_bulk() will release leftover pages to the page allocator.
+ page_pool_put_page_bulk() is suitable to be run inside the driver NAPI tx
+ completion loop for the XDP_REDIRECT use case.
+ Please note the caller must not use data area after running
+ page_pool_put_page_bulk(), as this function overwrites it.
+
Coding examples
===============
--
2.28.0
^ permalink raw reply related
* RE: [EXT] Re: [PATCH v1] net: mvpp2: divide fifo for dts-active ports only
From: Stefan Chulski @ 2020-11-23 15:44 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: netdev@vger.kernel.org, thomas.petazzoni@bootlin.com,
davem@davemloft.net, Nadav Haklai, Yan Markman,
linux-kernel@vger.kernel.org, kuba@kernel.org, mw@semihalf.com,
andrew@lunn.ch
In-Reply-To: <20201123153332.GW1551@shell.armlinux.org.uk>
> > > On Mon, Nov 23, 2020 at 04:52:40PM +0200, stefanc@marvell.com wrote:
> > > > From: Stefan Chulski <stefanc@marvell.com>
> > > >
> > > > Tx/Rx FIFO is a HW resource limited by total size, but shared by
> > > > all ports of same CP110 and impacting port-performance.
> > > > Do not divide the FIFO for ports which are not enabled in DTS, so
> > > > active ports could have more FIFO.
> > > >
> > > > The active port mapping should be done in probe before FIFO-init.
> > >
> > > It would be nice to know what the effect is from this - is it a
> > > small or large boost in performance?
> >
> > I didn't saw any significant improvement with LINUX bridge or
> > forwarding, but this reduced PPv2 overruns drops, reduced CRC sent errors
> with DPDK user space application.
> > So this improved zero loss throughput. Probably with XDP we would see a
> similar effect.
> >
> > > What is the effect when the ports on a CP110 are configured for 10G,
> > > 1G, and 2.5G in that order, as is the case on the Macchiatobin board?
> >
> > Macchiatobin has two CP's. CP1 has 3 ports, so the distribution of FIFO would
> be the same as before.
> > On CP0 which has a single port, all FIFO would be allocated for 10G port.
>
> Your code allocates for CP1:
>
> 32K to port 0 (the 10G port on Macchiatobin) 8K to port 1 (the 1G dedicated
> ethernet port on Macchiatobin) 4K to port 2 (the 1G/2.5G SFP port on
> Macchiatobin)
>
> I'm questioning that allocation for port 1 and 2.
Yes, but this allocation exists also in current code.
From HW point of view(MAC and PPv2) maximum supported speed
in CP110: port 0 - 10G, port 1 - 2.5G, port 2 - 2.5G.
in CP115: port 0 - 10G, port 1 - 5G, port 2 - 2.5G.
So this allocation looks correct at least for CP115.
Problem that we cannot reallocate FIFO during runtime, after specific speed negotiation.
Regards.
^ permalink raw reply
* [PATCH net-next 00/15] net: phy: add support for shared interrupts (part 3)
From: Ioana Ciornei @ 2020-11-23 15:38 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, Florian Fainelli,
Jakub Kicinski, netdev, linux-kernel
Cc: Ioana Ciornei, Antoine Tenart, Dan Murphy, Divya Koppera,
Hauke Mehrtens, Jerome Brunet, Marek Vasut, Martin Blumenstingl,
Mathias Kresin, Neil Armstrong, Oleksij Rempel, Philippe Schenker
From: Ioana Ciornei <ioana.ciornei@nxp.com>
This patch set aims to actually add support for shared interrupts in
phylib and not only for multi-PHY devices. While we are at it,
streamline the interrupt handling in phylib.
For a bit of context, at the moment, there are multiple phy_driver ops
that deal with this subject:
- .config_intr() - Enable/disable the interrupt line.
- .ack_interrupt() - Should quiesce any interrupts that may have been
fired. It's also used by phylib in conjunction with .config_intr() to
clear any pending interrupts after the line was disabled, and before
it is going to be enabled.
- .did_interrupt() - Intended for multi-PHY devices with a shared IRQ
line and used by phylib to discern which PHY from the package was the
one that actually fired the interrupt.
- .handle_interrupt() - Completely overrides the default interrupt
handling logic from phylib. The PHY driver is responsible for checking
if any interrupt was fired by the respective PHY and choose
accordingly if it's the one that should trigger the link state machine.
From my point of view, the interrupt handling in phylib has become
somewhat confusing with all these callbacks that actually read the same
PHY register - the interrupt status. A more streamlined approach would
be to just move the responsibility to write an interrupt handler to the
driver (as any other device driver does) and make .handle_interrupt()
the only way to deal with interrupts.
Another advantage with this approach would be that phylib would gain
support for shared IRQs between different PHY (not just multi-PHY
devices), something which at the moment would require extending every
PHY driver anyway in order to implement their .did_interrupt() callback
and duplicate the same logic as in .ack_interrupt(). The disadvantage
of making .did_interrupt() mandatory would be that we are slightly
changing the semantics of the phylib API and that would increase
confusion instead of reducing it.
What I am proposing is the following:
- As a first step, make the .ack_interrupt() callback optional so that
we do not break any PHY driver amid the transition.
- Every PHY driver gains a .handle_interrupt() implementation that, for
the most part, would look like below:
irq_status = phy_read(phydev, INTR_STATUS);
if (irq_status < 0) {
phy_error(phydev);
return IRQ_NONE;
}
if (!(irq_status & irq_mask))
return IRQ_NONE;
phy_trigger_machine(phydev);
return IRQ_HANDLED;
- Remove each PHY driver's implementation of the .ack_interrupt() by
actually taking care of quiescing any pending interrupts before
enabling/after disabling the interrupt line.
- Finally, after all drivers have been ported, remove the
.ack_interrupt() and .did_interrupt() callbacks from phy_driver.
This patch set is part 3 (and final) of the entire change set and it
addresses the remaining PHY drivers that have not been migrated
previosly. Also, it finally removed the .did_interrupt() and
.ack_interrupt() callbacks since they are of no use anymore.
I do not have access to most of these PHY's, therefore I Cc-ed the
latest contributors to the individual PHY drivers in order to have
access, hopefully, to more regression testing.
Ioana Ciornei (15):
net: phy: intel-xway: implement generic .handle_interrupt() callback
net: phy: intel-xway: remove the use of .ack_interrupt()
net: phy: icplus: implement generic .handle_interrupt() callback
net: phy: icplus: remove the use .ack_interrupt()
net: phy: meson-gxl: implement generic .handle_interrupt() callback
net: phy: meson-gxl: remove the use of .ack_callback()
net: phy: micrel: implement generic .handle_interrupt() callback
net: phy: micrel: remove the use of .ack_interrupt()
net: phy: national: implement generic .handle_interrupt() callback
net: phy: national: remove the use of the .ack_interrupt()
net: phy: ti: implement generic .handle_interrupt() callback
net: phy: ti: remove the use of .ack_interrupt()
net: phy: qsemi: implement generic .handle_interrupt() callback
net: phy: qsemi: remove the use of .ack_interrupt()
net: phy: remove the .did_interrupt() and .ack_interrupt() callback
drivers/net/phy/dp83640.c | 38 ++++++++++++++++++-
drivers/net/phy/dp83822.c | 54 ++++++++++++++++++---------
drivers/net/phy/dp83848.c | 47 +++++++++++++++++++++++-
drivers/net/phy/dp83867.c | 44 +++++++++++++++++++---
drivers/net/phy/dp83869.c | 42 +++++++++++++++++++--
drivers/net/phy/dp83tc811.c | 53 ++++++++++++++++++++++++++-
drivers/net/phy/icplus.c | 58 +++++++++++++++++++----------
drivers/net/phy/intel-xway.c | 71 +++++++++++++++++++++---------------
drivers/net/phy/meson-gxl.c | 37 +++++++++++++++----
drivers/net/phy/micrel.c | 65 +++++++++++++++++++++++++--------
drivers/net/phy/national.c | 58 ++++++++++++++++++++++-------
drivers/net/phy/phy.c | 48 +-----------------------
drivers/net/phy/phy_device.c | 2 +-
drivers/net/phy/qsemi.c | 42 +++++++++++++++++++--
include/linux/phy.h | 19 ++--------
15 files changed, 497 insertions(+), 181 deletions(-)
Cc: Antoine Tenart <atenart@kernel.org>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Divya Koppera <Divya.Koppera@microchip.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Mathias Kresin <dev@kresin.me>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Philippe Schenker <philippe.schenker@toradex.com>
--
2.28.0
^ permalink raw reply
* [PATCH net-next 04/15] net: phy: icplus: remove the use .ack_interrupt()
From: Ioana Ciornei @ 2020-11-23 15:38 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, Florian Fainelli,
Jakub Kicinski, netdev, linux-kernel
Cc: Ioana Ciornei, Martin Blumenstingl
In-Reply-To: <20201123153817.1616814-1-ciorneiioana@gmail.com>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
In preparation of removing the .ack_interrupt() callback, we must replace
its occurrences (aka phy_clear_interrupt), from the 2 places where it is
called from (phy_enable_interrupts and phy_disable_interrupts), with
equivalent functionality.
This means that clearing interrupts now becomes something that the PHY
driver is responsible of doing, before enabling interrupts and after
clearing them. Make this driver follow the new contract.
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/net/phy/icplus.c | 38 +++++++++++++++++++++++++-------------
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/icplus.c b/drivers/net/phy/icplus.c
index a74ff45fa99c..b632947cbcdf 100644
--- a/drivers/net/phy/icplus.c
+++ b/drivers/net/phy/icplus.c
@@ -272,17 +272,39 @@ static int ip101a_g_config_init(struct phy_device *phydev)
return phy_write(phydev, IP10XX_SPEC_CTRL_STATUS, c);
}
+static int ip101a_g_ack_interrupt(struct phy_device *phydev)
+{
+ int err = phy_read(phydev, IP101A_G_IRQ_CONF_STATUS);
+
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
static int ip101a_g_config_intr(struct phy_device *phydev)
{
u16 val;
+ int err;
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED) {
+ err = ip101a_g_ack_interrupt(phydev);
+ if (err)
+ return err;
- if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
/* INTR pin used: Speed/link/duplex will cause an interrupt */
val = IP101A_G_IRQ_PIN_USED;
- else
+ err = phy_write(phydev, IP101A_G_IRQ_CONF_STATUS, val);
+ } else {
val = IP101A_G_IRQ_ALL_MASK;
+ err = phy_write(phydev, IP101A_G_IRQ_CONF_STATUS, val);
+ if (err)
+ return err;
+
+ err = ip101a_g_ack_interrupt(phydev);
+ }
- return phy_write(phydev, IP101A_G_IRQ_CONF_STATUS, val);
+ return err;
}
static irqreturn_t ip101a_g_handle_interrupt(struct phy_device *phydev)
@@ -305,15 +327,6 @@ static irqreturn_t ip101a_g_handle_interrupt(struct phy_device *phydev)
return IRQ_HANDLED;
}
-static int ip101a_g_ack_interrupt(struct phy_device *phydev)
-{
- int err = phy_read(phydev, IP101A_G_IRQ_CONF_STATUS);
- if (err < 0)
- return err;
-
- return 0;
-}
-
static struct phy_driver icplus_driver[] = {
{
.phy_id = 0x02430d80,
@@ -340,7 +353,6 @@ static struct phy_driver icplus_driver[] = {
/* PHY_BASIC_FEATURES */
.probe = ip101a_g_probe,
.config_intr = ip101a_g_config_intr,
- .ack_interrupt = ip101a_g_ack_interrupt,
.handle_interrupt = ip101a_g_handle_interrupt,
.config_init = &ip101a_g_config_init,
.suspend = genphy_suspend,
--
2.28.0
^ permalink raw reply related
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