Re: [PATCH v5 6/9] ALSA: virtio: PCM substream operators
On Fri, 26 Feb 2021 21:19:58 +0100, Anton Yakovlev wrote: > > On 25.02.2021 21:30, Takashi Iwai wrote:> On Thu, 25 Feb 2021 20:02:50 > +0100, > > Michael S. Tsirkin wrote: > >> > > [snip] > > >> If you want to merge it yourself instead, also please say so. > > > > I don't mind who take the patches, although it looks more fitting to > > merge through sound git tree if judging from the changes put in > > sound/* directory. > > Then should I update the MAINTAINERS and add Takashi instead of > Michael, or should I put both of you there? No need for that, I'm already named as the generic sound/* stuff maintainer. And, it's rather more about how the merge gets pushed up to upstream. In general, the stuff belonging to a subsystem goes via the subsystem tree, e.g. Mark has been maintaining ASoC stuff in his tree while it gets merged sound.git tree to Linus. Similarly, it's fine if Michael wants to keep a sub-subsystem tree for virtio_snd, too. But keeping a dedicated git repo for a single driver isn't often worthwhile. Of course, it's no strict rule, and I don't mind if anybody has a strong reason to process in other ways, too. Just let me know. thanks, Takashi
[PATCH] iommu/vt-d: Fix status code for Allocate/Free PASID command
As per Intel vt-d spec, Rev 3.0 (section 10.4.45 "Virtual Command Response
Register"), the status code of "No PASID available" error in response to
the Allocate PASID command is 2, not 1. The same for "Invalid PASID" error
in response to the Free PASID command.
We will otherwise see confusing kernel log under the command failure from
guest side. Fix it.
Fixes: 24f27d32ab6b ("iommu/vt-d: Enlightened PASID allocation")
Signed-off-by: Zenghui Yu
---
drivers/iommu/intel/pasid.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/pasid.h b/drivers/iommu/intel/pasid.h
index 97dfcffbf495..444c0bec221a 100644
--- a/drivers/iommu/intel/pasid.h
+++ b/drivers/iommu/intel/pasid.h
@@ -30,8 +30,8 @@
#define VCMD_VRSP_IP 0x1
#define VCMD_VRSP_SC(e)(((e) >> 1) & 0x3)
#define VCMD_VRSP_SC_SUCCESS 0
-#define VCMD_VRSP_SC_NO_PASID_AVAIL1
-#define VCMD_VRSP_SC_INVALID_PASID 1
+#define VCMD_VRSP_SC_NO_PASID_AVAIL2
+#define VCMD_VRSP_SC_INVALID_PASID 2
#define VCMD_VRSP_RESULT_PASID(e) (((e) >> 8) & 0xf)
#define VCMD_CMD_OPERAND(e)((e) << 8)
/*
--
2.19.1
Re: [PATCH 3/7] perf cs-etm: Save aux records in each etm queue
On Fri, Feb 12, 2021 at 04:45:09PM +0200, James Clark wrote:
> The aux records will be used set the bounds of decoding in a
> later commit. In the future we may also want to use the flags
> of each record to control decoding.
>
> Do these need to be saved in their entirety, or can pointers
> to each record safely be saved instead for later access?
Rather than introudcing the perf record list, I just wander if we can
use easier method to fix this problem. So below is the rough idea
(though I don't really verify it):
The essential information we need is what's the valid buffer length can
be used for decoding. Though cs_etm_queue::buf_len tracks the buffer
length, but it's the buffer length is for the whole AUX buffer, and
which belongs to multiple "PERF_RECORD_AUX" events. So we cannot decode
at once for the whole trace data in the AUX trace buffer, on the other
hand, the incoming "PERF_RECORD_AUX" event can guide the CoreSight
decoder it should decode how much buffer size. At the end, the trace
data can be decoded step by step based on the incoming "PERF_RECORD_AUX"
events.
I'd like to propose to add a new field "cs_etm_queue::buf_rec_len", it
stands for the record length based on the RECORD_AUX event. In
theory, this value should be always less than "cs_etm_queue::buf_len".
When every time the "PERF_RECORD_AUX" event is coming, we find out the
corresponding queue (so this can be applied for "1:1" or "N:1" models
for source and sink), and accumulate "perf_record_aux::aux_size" into
"cs_etm_queue::buf_rec_len".
At the decoder side, it decreases "etmq->buf_rec_len" until to zero for
the current round of decoding (see cs_etm__decode_data_block()). Since
all the "PERF_RECORD_AUX" event will be processed before
"PERF_RECORD_EXIT" event, so we don't worry the tail trace data will be
ignored.
The main reason for this suggestion is it don't need to change the
significant logic in current code. I will try to do experiment for this
idea and share back.
James, if you think I miss anything, please correct me as needed.
Thanks!
Leo
> Signed-off-by: James Clark
> ---
> tools/perf/util/cs-etm.c | 32 +---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 8f8b448632fb..88b541b2a804 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -92,12 +92,16 @@ struct cs_etm_queue {
> /* Conversion between traceID and index in traceid_queues array */
> struct intlist *traceid_queues_list;
> struct cs_etm_traceid_queue **traceid_queues;
> + int aux_record_list_len;
> + int aux_record_list_idx;
> + struct perf_record_aux *aux_record_list;
> };
>
> /* RB tree for quick conversion between traceID and metadata pointers */
> static struct intlist *traceid_list;
>
> -static int cs_etm__update_queues(struct cs_etm_auxtrace *etm, int cpu);
> +static int cs_etm__update_queues(struct cs_etm_auxtrace *etm, int cpu,
> + struct perf_record_aux *aux_record);
> static int cs_etm__process_queues(struct cs_etm_auxtrace *etm);
> static int cs_etm__process_timeless_queues(struct cs_etm_auxtrace *etm,
> pid_t tid);
> @@ -585,6 +589,7 @@ static void cs_etm__free_queue(void *priv)
>
> cs_etm_decoder__free(etmq->decoder);
> cs_etm__free_traceid_queues(etmq);
> + free(etmq->aux_record_list);
> free(etmq);
> }
>
> @@ -759,6 +764,19 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct
> cs_etm_auxtrace *etm)
> return NULL;
> }
>
> +static int cs_etm__save_aux_record(struct cs_etm_queue *etmq,
> +struct perf_record_aux *aux_record)
> +{
> + etmq->aux_record_list = reallocarray(etmq->aux_record_list,
> + etmq->aux_record_list_len+1,
> + sizeof(*etmq->aux_record_list));
> + if (!etmq->aux_record_list)
> + return -ENOMEM;
> +
> + etmq->aux_record_list[etmq->aux_record_list_len++] = *aux_record;
> + return 0;
> +}
> +
> static int cs_etm__search_first_timestamp(struct cs_etm_queue *etmq)
> {
> int ret = 0;
> @@ -865,7 +883,7 @@ static int cs_etm__setup_queues(struct cs_etm_auxtrace
> *etm)
> return 0;
> }
>
> -static int cs_etm__update_queues(struct cs_etm_auxtrace *etm, int cpu)
> +static int cs_etm__update_queues(struct cs_etm_auxtrace *etm, int cpu,
> struct perf_record_aux *aux)
> {
> int ret;
> if (etm->queues.new_data) {
> @@ -875,6 +893,14 @@ static int cs_etm__update_queues(struct cs_etm_auxtrace
> *etm, int cpu)
> return ret;
> }
>
> + /* In timeless mode, cpu is set to -1, and a single aux buffer is
> filled */
> + if (cpu < 0)
> + cpu = 0;
> +
> + ret = cs_etm__save_aux_record(etm->queues.queue_array[cpu].priv, aux);
> + if
Re: [PATCH] compiler.h: Raise minimum version of GCC to 5.1 for arm64
Hi Linus, On Fri, Jan 15, 2021 at 3:43 AM Linus Torvalds wrote: > > On Thu, Jan 14, 2021 at 12:18 AM Ard Biesheuvel wrote: > > > > So if the arguments are piling up, what is holding us back, other than > > inertia? > > I think we can most certainly just try increasing the minimum version > to 5.1 in the next merge window and see. Just a friendly reminder. It will be nice to increase the minimum GCC version to GCC 5.x globally. Now, the version check has been moved to scripts/cc-version.sh, which is invoked from Kconfig. If you decide to do this, please update 'gcc_min_version' in that file. I'd like to suggest GCC 5.2 instead of 5.1 so that we can drop the following line from arch/powerpc/Kconfig. if GCC_VERSION >= 50200 # plugin support on gcc <= 5.1 is buggy on PPC > > Note that banning 4.9 for arm64 and banning it in general should be > > two different changes in any case, as the former will need to be > > backported to -stable kernels as well. > > Yes. The arm64 issue is a clear and known bug, plus I suspect gcc-4.9 > is ridiculously old in the arm64 ecosystem anyway. > > So the arm64 issue is a bug-fix, the follow-up of just upgrading gcc > requirements in general would be a "keep up with the times, and allow > those variable declarations in loops". > > Linus -- Best Regards Masahiro Yamada
Re: [PATCH v2] kbuild: fix UNUSED_KSYMS_WHITELIST for Clang LTO
On Sat, Feb 27, 2021 at 7:55 AM Masahiro Yamada wrote:
>
> On Fri, Feb 26, 2021 at 6:26 PM Sedat Dilek wrote:
> >
> > On Fri, Feb 26, 2021 at 7:26 AM Masahiro Yamada
> > wrote:
> > >
> > > Commit fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> > > does not work as expected if the .config file has already specified
> > > CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list" before enabling
> > > CONFIG_LTO_CLANG.
> > >
> > > So, the user-supplied whitelist and LTO-specific white list must be
> > > independent of each other.
> > >
> > > I refactored the shell script so CONFIG_MODVERSIONS and CONFIG_CLANG_LTO
> > > handle whitelists in the same way.
> > >
> > > Fixes: fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > Changes in v2:
> > > - Rebase on top of Arnd's patch:
> > > https://lore.kernel.org/lkml/20210225143456.3829513-1-a...@kernel.org/
> > >
> > > init/Kconfig| 1 -
> > > scripts/gen_autoksyms.sh| 35 -
> > > scripts/lto-used-symbollist.txt | 6 --
> >
> > People who want to use their own "white-listed" (allow-listed)
> > symbollist-file can do that via
> > CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list".
> > Correct?
> >
> > Why do you delete the default "scripts/lto-used-symbollist.txt" file
> > and remove the default in the appropriate Kconfig for people who want
> > to enable Clang-(Thin)LTO?
> > These people should now use
> > CONFIG_UNUSED_KSYMS_WHITELIST="scripts/lto-used-symbollist.txt"?
> > But again - the file was deleted with your patch.
> > Do I miss something?
>
> I think so.
>
> I moved those symbols to scripts/gen_autoksyms.sh
>
OK, I have overseen hat.
- Sedat -
Re: [PATCH v2] kbuild: fix UNUSED_KSYMS_WHITELIST for Clang LTO
On Fri, Feb 26, 2021 at 6:26 PM Sedat Dilek wrote:
>
> On Fri, Feb 26, 2021 at 7:26 AM Masahiro Yamada wrote:
> >
> > Commit fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> > does not work as expected if the .config file has already specified
> > CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list" before enabling
> > CONFIG_LTO_CLANG.
> >
> > So, the user-supplied whitelist and LTO-specific white list must be
> > independent of each other.
> >
> > I refactored the shell script so CONFIG_MODVERSIONS and CONFIG_CLANG_LTO
> > handle whitelists in the same way.
> >
> > Fixes: fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > Changes in v2:
> > - Rebase on top of Arnd's patch:
> > https://lore.kernel.org/lkml/20210225143456.3829513-1-a...@kernel.org/
> >
> > init/Kconfig| 1 -
> > scripts/gen_autoksyms.sh| 35 -
> > scripts/lto-used-symbollist.txt | 6 --
>
> People who want to use their own "white-listed" (allow-listed)
> symbollist-file can do that via
> CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list".
> Correct?
>
> Why do you delete the default "scripts/lto-used-symbollist.txt" file
> and remove the default in the appropriate Kconfig for people who want
> to enable Clang-(Thin)LTO?
> These people should now use
> CONFIG_UNUSED_KSYMS_WHITELIST="scripts/lto-used-symbollist.txt"?
> But again - the file was deleted with your patch.
> Do I miss something?
I think so.
I moved those symbols to scripts/gen_autoksyms.sh
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 0/2] irqchip: add support for BCM6345 interrupt controller
Hi all, Apparently these patches were flagged as “Not Applicable” without an explanation. Why? https://patchwork.kernel.org/project/linux-mips/patch/20210224075640.20465-2-nolt...@gmail.com/ https://patchwork.kernel.org/project/linux-mips/patch/20210224075640.20465-3-nolt...@gmail.com/ Best regards, Álvaro. > El 24 feb 2021, a las 8:56, Álvaro Fernández Rojas > escribió: > > This interrupt controller is present on bcm63xx SoCs in order to generate > interrupts based on GPIO status changes. > > v3: pass dt_binding_check. > v2: fix documentation title typo. > > Álvaro Fernández Rojas (2): > dt-bindings: interrupt-controller: document BCM6345 external interrupt >controller > irqchip: add support for BCM6345 external interrupt controller > > .../brcm,bcm6345-ext-intc.yaml| 78 + > drivers/irqchip/Kconfig | 4 + > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-bcm6345-ext.c | 271 ++ > 4 files changed, 354 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-ext-intc.yaml > create mode 100644 drivers/irqchip/irq-bcm6345-ext.c > > -- > 2.20.1 >
Re: [PATCH v2] mips: smp-bmips: fix CPU mappings
Hi all,
Apparently, this patch was flagged as "Not Applicable" without an explanation.
Why?
https://patchwork.kernel.org/project/linux-mips/patch/20210224073336.32265-1-nolt...@gmail.com/
Best regarss,
Álvaro.
> El 24 feb 2021, a las 8:33, Álvaro Fernández Rojas
> escribió:
>
> When booting bmips with SMP enabled on a BCM6358 running on CPU #1 instead of
> CPU #0, the current CPU mapping code produces the following:
> - smp_processor_id(): 0
> - cpu_logical_map(0): 1
> - cpu_number_map(0): 1
>
> This is because SMP isn't supported on BCM6358 since it has a shared TLB, so
> it is disabled and max_cpus is decreased from 2 to 1.
>
> Signed-off-by: Álvaro Fernández Rojas
> Reviewed-by: Florian Fainelli
> ---
> v2: Fix duplicated line
>
> arch/mips/kernel/smp-bmips.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
> index 359b176b665f..b6ef5f7312cf 100644
> --- a/arch/mips/kernel/smp-bmips.c
> +++ b/arch/mips/kernel/smp-bmips.c
> @@ -134,17 +134,24 @@ static void __init bmips_smp_setup(void)
> if (!board_ebase_setup)
> board_ebase_setup = _ebase_setup;
>
> - __cpu_number_map[boot_cpu] = 0;
> - __cpu_logical_map[0] = boot_cpu;
> -
> - for (i = 0; i < max_cpus; i++) {
> - if (i != boot_cpu) {
> - __cpu_number_map[i] = cpu;
> - __cpu_logical_map[cpu] = i;
> - cpu++;
> + if (max_cpus > 1) {
> + __cpu_number_map[boot_cpu] = 0;
> + __cpu_logical_map[0] = boot_cpu;
> +
> + for (i = 0; i < max_cpus; i++) {
> + if (i != boot_cpu) {
> + __cpu_number_map[i] = cpu;
> + __cpu_logical_map[cpu] = i;
> + cpu++;
> + }
> + set_cpu_possible(i, 1);
> + set_cpu_present(i, 1);
> }
> - set_cpu_possible(i, 1);
> - set_cpu_present(i, 1);
> + } else {
> + __cpu_number_map[0] = boot_cpu;
> + __cpu_logical_map[0] = 0;
> + set_cpu_possible(0, 1);
> + set_cpu_present(0, 1);
> }
> }
>
> --
> 2.20.1
>
Re: [PATCH v1 01/12] gna: add driver module
On Fri, Feb 26, 2021 at 07:29:39PM +0100, Maciej Kwapulinski wrote: > > Andy Shevchenko writes: > > > On Tue, Feb 16, 2021 at 6:11 PM Maciej Kwapulinski > > wrote: > >> > > >> +#define GNA_DRV_VER"1.2.0" > > > > Nowadays the version is the Git SHA sum. > > > > right, "version" is present in about 7% of all modules And it should be removed from them. > do You mean version should be skipped over (automatically generated) > srcversion field? or maybe You suggest any (better) technique? Drop it entirely from the driver code, it means nothing when the driver is merged into the kernel tree. thanks, greg k-h
[PATCH] kbuild: make -s option take precedence over V=
'make -s' should be really silent. However, 'make -s V=1' prints noisy log messages from some shell scripts. Of course, the combination of -s and V=1 is odd, but the build system needs to do the right thing even if a user gives strange input. If -s is given, KBUILD_VERBOSE should be forced to 0. Signed-off-by: Masahiro Yamada --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 6ecd0d22e608..0a655469cafb 100644 --- a/Makefile +++ b/Makefile @@ -96,6 +96,7 @@ endif ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),) quiet=silent_ + KBUILD_VERBOSE = 0 endif export quiet Q KBUILD_VERBOSE -- 2.27.0
BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! (2)
Hello, syzbot found the following issue on: HEAD commit:557c223b selftests/bpf: No need to drop the packet when th.. git tree: bpf console output: https://syzkaller.appspot.com/x/log.txt?x=156409a8d0 kernel config: https://syzkaller.appspot.com/x/.config?x=2b8307379601586a dashboard link: https://syzkaller.appspot.com/bug?extid=9bbbacfbf1e04d5221f7 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+9bbbacfbf1e04d522...@syzkaller.appspotmail.com netlink: 'syz-executor.4': attribute type 10 has an invalid length. BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! turning off the locking correctness validator. CPU: 1 PID: 22786 Comm: syz-executor.4 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0xfa/0x151 lib/dump_stack.c:120 add_chain_cache kernel/locking/lockdep.c:3540 [inline] lookup_chain_cache_add kernel/locking/lockdep.c:3621 [inline] validate_chain kernel/locking/lockdep.c:3642 [inline] __lock_acquire.cold+0x3af/0x3b4 kernel/locking/lockdep.c:4900 lock_acquire kernel/locking/lockdep.c:5510 [inline] lock_acquire+0x1ab/0x730 kernel/locking/lockdep.c:5475 do_write_seqcount_begin_nested include/linux/seqlock.h:520 [inline] do_write_seqcount_begin include/linux/seqlock.h:545 [inline] psi_group_change+0x123/0x8d0 kernel/sched/psi.c:707 psi_task_change+0x142/0x220 kernel/sched/psi.c:807 psi_enqueue kernel/sched/stats.h:82 [inline] enqueue_task kernel/sched/core.c:1590 [inline] activate_task kernel/sched/core.c:1613 [inline] ttwu_do_activate+0x25b/0x660 kernel/sched/core.c:2991 ttwu_queue kernel/sched/core.c:3188 [inline] try_to_wake_up+0x60e/0x14a0 kernel/sched/core.c:3466 wake_up_worker kernel/workqueue.c:837 [inline] insert_work+0x2a0/0x370 kernel/workqueue.c:1346 __queue_work+0x5c1/0xf00 kernel/workqueue.c:1497 __queue_delayed_work+0x1c8/0x270 kernel/workqueue.c:1644 mod_delayed_work_on+0xdd/0x1e0 kernel/workqueue.c:1718 mod_delayed_work include/linux/workqueue.h:537 [inline] addrconf_mod_dad_work net/ipv6/addrconf.c:328 [inline] addrconf_dad_start net/ipv6/addrconf.c:4013 [inline] addrconf_add_linklocal+0x321/0x590 net/ipv6/addrconf.c:3186 addrconf_addr_gen+0x3a4/0x3e0 net/ipv6/addrconf.c:3313 addrconf_dev_config+0x26c/0x410 net/ipv6/addrconf.c:3360 addrconf_notify+0x362/0x23e0 net/ipv6/addrconf.c:3593 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2063 call_netdevice_notifiers_extack net/core/dev.c:2075 [inline] call_netdevice_notifiers net/core/dev.c:2089 [inline] dev_open net/core/dev.c:1592 [inline] dev_open+0x132/0x150 net/core/dev.c:1580 team_port_add drivers/net/team/team.c:1210 [inline] team_add_slave+0xa53/0x1c20 drivers/net/team/team.c:1967 do_set_master+0x1c8/0x220 net/core/rtnetlink.c:2519 do_setlink+0x920/0x3a70 net/core/rtnetlink.c:2715 __rtnl_newlink+0xdc6/0x1710 net/core/rtnetlink.c:3376 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2348 ___sys_sendmsg+0xf3/0x170 net/socket.c:2402 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2435 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x465ef9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f2db3282188 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0056bf60 RCX: 00465ef9 RDX: RSI: 21c0 RDI: 0004 RBP: 004bcd1c R08: R09: R10: R11: 0246 R12: 0056bf60 R13: 7ffea3f3a6af R14: 7f2db3282300 R15: 00022000 team0: Device ipvlan0 failed to register rx_handler --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[git pull] vfs.git misc stuff
Assorted stuff pile - no common topic here. One trivial conflict in Documentation/filesystems/porting.rst The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for you to fetch changes up to 6f24784f00f2b5862b367caeecc5cca22a77faa3: whack-a-mole: don't open-code iminor/imajor (2021-02-23 10:25:29 -0500) Al Viro (3): audit_alloc_mark(): don't open-code ERR_CAST() 9p: fix misuse of sscanf() in v9fs_stat2inode() whack-a-mole: don't open-code iminor/imajor Eric Biggers (2): vfs: don't unnecessarily clone write access for writable fds fs/inode.c: make inode_init_always() initialize i_ino to 0 Documentation/filesystems/porting.rst | 7 + arch/sh/boards/mach-landisk/gio.c | 6 ++-- drivers/block/loop.c | 2 +- drivers/dax/super.c| 2 +- drivers/rtc/rtc-m41t80.c | 4 +-- drivers/s390/char/vmur.c | 2 +- drivers/staging/vme/devices/vme_user.c | 12 fs/9p/vfs_inode.c | 21 ++ fs/gfs2/inode.c| 4 +-- fs/inode.c | 1 + fs/jfs/super.c | 1 - fs/namespace.c | 53 +- include/linux/mount.h | 1 - kernel/audit_fsnotify.c| 2 +- 14 files changed, 53 insertions(+), 65 deletions(-)
[PATCH] nios2: add arch/nios2/Kbuild
Use the standard obj-y form to specify the sub-directories under arch/nios2/. No functional change intended. Signed-off-by: Masahiro Yamada --- arch/nios2/Kbuild | 2 ++ arch/nios2/Makefile | 3 +-- 2 files changed, 3 insertions(+), 2 deletions(-) create mode 100644 arch/nios2/Kbuild diff --git a/arch/nios2/Kbuild b/arch/nios2/Kbuild new file mode 100644 index ..98b454beae92 --- /dev/null +++ b/arch/nios2/Kbuild @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-y += kernel/ mm/ platform/ diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile index 52c03e60b114..f06ac8c6c7ea 100644 --- a/arch/nios2/Makefile +++ b/arch/nios2/Makefile @@ -40,8 +40,7 @@ KBUILD_CFLAGS += -G 0 head-y := arch/nios2/kernel/head.o libs-y += arch/nios2/lib/ $(LIBGCC) -core-y += arch/nios2/kernel/ arch/nios2/mm/ -core-y += arch/nios2/platform/ +core-y += arch/nios2/ INSTALL_PATH ?= /tftpboot nios2-boot := arch/$(ARCH)/boot -- 2.27.0
[PATCH] hexagon: add arch/hexagon/Kbuild
Use the standard obj-y form to specify the sub-directories under arch/hexagon/. No functional change intended. Signed-off-by: Masahiro Yamada --- arch/hexagon/Kbuild | 2 ++ arch/hexagon/Makefile | 5 + 2 files changed, 3 insertions(+), 4 deletions(-) create mode 100644 arch/hexagon/Kbuild diff --git a/arch/hexagon/Kbuild b/arch/hexagon/Kbuild new file mode 100644 index ..8421baba1351 --- /dev/null +++ b/arch/hexagon/Kbuild @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-y += kernel/ mm/ lib/ diff --git a/arch/hexagon/Makefile b/arch/hexagon/Makefile index c168c6980d05..80583548b81e 100644 --- a/arch/hexagon/Makefile +++ b/arch/hexagon/Makefile @@ -34,7 +34,4 @@ LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name 2>/dev/null) libs-y += $(LIBGCC) head-y := arch/hexagon/kernel/head.o - -core-y += arch/hexagon/kernel/ \ - arch/hexagon/mm/ \ - arch/hexagon/lib/ +core-y += arch/hexagon/ -- 2.27.0
arch/sh/kernel/ftrace.c:274:25: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 3fb6d0e00efc958d01c2f109c8453033a2d96796
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for
__chk_{user,io}_ptr()
date: 6 months ago
config: sh-randconfig-s031-20210227 (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-241-geaceeafa-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5fc436f06eef54ef512ea55a9db8eb9f2e76959
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e5fc436f06eef54ef512ea55a9db8eb9f2e76959
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
arch/sh/kernel/ftrace.c:50:9: sparse: sparse: incorrect type in argument 1
(different address spaces) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned char * @@
arch/sh/kernel/ftrace.c:50:9: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/ftrace.c:50:9: sparse: got unsigned char *
arch/sh/kernel/ftrace.c:57:9: sparse: sparse: incorrect type in argument 1
(different address spaces) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned char * @@
arch/sh/kernel/ftrace.c:57:9: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/ftrace.c:57:9: sparse: got unsigned char *
>> arch/sh/kernel/ftrace.c:274:25: sparse: sparse: incorrect type in argument 1
>> (different address spaces) @@ expected void const volatile [noderef]
>> __iomem *ptr @@ got unsigned long * @@
arch/sh/kernel/ftrace.c:274:25: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/ftrace.c:274:25: sparse: got unsigned long *
>> arch/sh/kernel/ftrace.c:277:9: sparse: sparse: incorrect type in argument 1
>> (different base types) @@ expected void const volatile [noderef] __iomem
>> *ptr @@ got unsigned long ip @@
arch/sh/kernel/ftrace.c:277:9: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/ftrace.c:277:9: sparse: got unsigned long ip
arch/sh/kernel/ftrace.c:368:17: sparse: sparse: incorrect type in argument 1
(different address spaces) @@ expected void const volatile [noderef]
__iomem *ptr @@ got unsigned long *parent @@
arch/sh/kernel/ftrace.c:368:17: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/ftrace.c:368:17: sparse: got unsigned long *parent
vim +274 arch/sh/kernel/ftrace.c
327933f5d6cdf0 Matt Fleming 2009-07-11 265
327933f5d6cdf0 Matt Fleming 2009-07-11 266 static int
ftrace_mod(unsigned long ip, unsigned long old_addr,
327933f5d6cdf0 Matt Fleming 2009-07-11 267 unsigned
long new_addr)
327933f5d6cdf0 Matt Fleming 2009-07-11 268 {
327933f5d6cdf0 Matt Fleming 2009-07-11 269unsigned char
code[MCOUNT_INSN_SIZE];
327933f5d6cdf0 Matt Fleming 2009-07-11 270
fe557319aa06c2 Christoph Hellwig 2020-06-17 271if
(copy_from_kernel_nofault(code, (void *)ip, MCOUNT_INSN_SIZE))
327933f5d6cdf0 Matt Fleming 2009-07-11 272return -EFAULT;
327933f5d6cdf0 Matt Fleming 2009-07-11 273
327933f5d6cdf0 Matt Fleming 2009-07-11 @274if (old_addr !=
__raw_readl((unsigned long *)code))
327933f5d6cdf0 Matt Fleming 2009-07-11 275return -EINVAL;
327933f5d6cdf0 Matt Fleming 2009-07-11 276
327933f5d6cdf0 Matt Fleming 2009-07-11 @277__raw_writel(new_addr,
ip);
327933f5d6cdf0 Matt Fleming 2009-07-11 278return 0;
327933f5d6cdf0 Matt Fleming 2009-07-11 279 }
327933f5d6cdf0 Matt Fleming 2009-07-11 280
:: The code at line 274 was first introduced by commit
:: 327933f5d6cdf083284d3c06e0370d1de464aef4 sh: Function graph tracer
support
:: TO: Matt Fleming
:: CC: Paul Mundt
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] copy_file_range.2: Kernel v5.12 updates
On Sat, Feb 27, 2021 at 12:19 AM Alejandro Colomar (man-pages)
wrote:
>
> Hello Amir, Luis,
>
> On 2/24/21 5:10 PM, Amir Goldstein wrote:
> > On Wed, Feb 24, 2021 at 4:22 PM Luis Henriques wrote:
> >>
> >> Update man-page with recent changes to this syscall.
> >>
> >> Signed-off-by: Luis Henriques
> >> ---
> >> Hi!
> >>
> >> Here's a suggestion for fixing the manpage for copy_file_range(). Note
> >> that
> >> I've assumed the fix will hit 5.12.
> >>
> >> man2/copy_file_range.2 | 10 +-
> >> 1 file changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/man2/copy_file_range.2 b/man2/copy_file_range.2
> >> index 611a39b8026b..b0fd85e2631e 100644
> >> --- a/man2/copy_file_range.2
> >> +++ b/man2/copy_file_range.2
> >> @@ -169,6 +169,9 @@ Out of memory.
> >> .B ENOSPC
> >> There is not enough space on the target filesystem to complete the copy.
> >> .TP
> >> +.B EOPNOTSUPP
>
> I'll add the kernel version here:
>
> .BR EOPNOTSUPP " (since Linux 5.12)"
Error could be returned prior to 5.3 and would be probably returned
by future stable kernels 5.3..5.12 too
>
> >> +The filesystem does not support this operation >> +.TP
> >> .B EOVERFLOW
> >> The requested source or destination range is too large to represent in
> >> the
> >> specified data types.
> >> @@ -187,7 +190,7 @@ refers to an active swap file.
> >> .B EXDEV
> >> The files referred to by
> >> .IR fd_in " and " fd_out
> >> -are not on the same mounted filesystem (pre Linux 5.3).
> >> +are not on the same mounted filesystem (pre Linux 5.3 and post Linux
> >> 5.12).
>
> I'm not sure that 'mounted' adds any value here. Would you remove the
> word here?
See rename(2). 'mounted' in this context is explained there.
HOWEVER, it does not fit here.
copy_file_range() IS allowed between two mounts of the same filesystem instance.
To make things more complicated, it appears that cross mount clone is not
allowed via FICLONE/FICLONERANGE ioctl, so ioctl_ficlonerange(2) man page
also uses the 'mounted filesystem' terminology for EXDEV
As things stand now, because of the fallback to clone logic,
copy_file_range() provides a way for users to clone across different mounts
of the same filesystem instance, which they cannot do with the FICLONE ioctl.
Fun :)
BTW, I don't know if preventing cross mount clone was done intentionally,
but as I wrote in a comment in the code once:
/*
* FICLONE/FICLONERANGE ioctls enforce that src and dest files are on
* the same mount. Practically, they only need to be on the same file
* system.
*/
>
> It reads as if two separate devices with the same filesystem type would
> still give this error.
>
> Per the LWN.net article Amir shared, this is permitted ("When called
> from user space, copy_file_range() will only try to copy a file across
> filesystems if the two are of the same type").
>
> This behavior was slightly different before 5.3 AFAICR (was it?) ("until
> then, copy_file_range() refused to copy between files that were not
> located on the same filesystem."). If that's the case, I'd specify the
> difference, or more probably split the error into two, one before 5.3,
> and one since 5.12.
>
True.
> >
> > I think you need to drop the (Linux range) altogether.
>
> I'll keep the range. Users of 5.3..5.11 might be surprised if the
> filesystems are different and they don't get an error, I think.
>
> I reworded it to follow other pages conventions:
>
> .BR EXDEV " (before Linux 5.3; or since Linux 5.12)"
>
> which renders as:
>
> EXDEV (before Linux 5.3; or since Linux 5.12)
>The files referred to by fd_in and fd_out are not on
>the same mounted filesystem.
>
drop 'mounted'
>
> > What's missing here is the NFS cross server copy use case.
> > Maybe:
> >
> > ...are not on the same mounted filesystem and the source and target
> > filesystems
> > do not support cross-filesystem copy.
>
> Yes.
>
> Again, this wasn't true before 5.3, right?
>
Right.
Actually, v5.3 provides the vfs capabilities for filesystems to support
cross fs copy. I am not sure if NFS already implements cross fs copy in
v5.3 and not sure about cifs. Need to get input from nfs/cis developers
or dig in the release notes for server-side copy.
> >
> > You may refer the reader to VERSIONS section where it will say which
> > filesystems support cross-fs copy as of kernel version XXX (i.e. cifs and
> > nfs).
> >
> >> .SH VERSIONS
> >> The
> >> .BR copy_file_range ()
> >> @@ -202,6 +205,11 @@ Applications should target the behaviour and
> >> requirements of 5.3 kernels.
> >> .PP
> >> First support for cross-filesystem copies was introduced in Linux 5.3.
> >> Older kernels will return -EXDEV when cross-filesystem copies are
> >> attempted.
> >> +.PP
> >> +After Linux 5.12, support for copies between different filesystems was
> >> dropped.
> >> +However, individual filesystems may still provide
> >> +.BR copy_file_range ()
> >>
[PATCH] ia64: add arch/ia64/Kbuild
Use the standard obj-y form to specify the sub-directories under arch/ia64/. No functional change intended. Signed-off-by: Masahiro Yamada --- arch/ia64/Kbuild | 3 +++ arch/ia64/Makefile | 3 +-- 2 files changed, 4 insertions(+), 2 deletions(-) create mode 100644 arch/ia64/Kbuild diff --git a/arch/ia64/Kbuild b/arch/ia64/Kbuild new file mode 100644 index ..e77cc76d228c --- /dev/null +++ b/arch/ia64/Kbuild @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-y += kernel/ mm/ +obj-$(CONFIG_IA64_SGI_UV) += uv/ diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile index 467b7e7f967c..096d5500e6a4 100644 --- a/arch/ia64/Makefile +++ b/arch/ia64/Makefile @@ -47,8 +47,7 @@ KBUILD_CFLAGS += $(cflags-y) head-y := arch/ia64/kernel/head.o libs-y += arch/ia64/lib/ -core-y += arch/ia64/kernel/ arch/ia64/mm/ -core-$(CONFIG_IA64_SGI_UV) += arch/ia64/uv/ +core-y += arch/ia64/ drivers-y += arch/ia64/pci/ arch/ia64/hp/common/ -- 2.27.0
[PATCH] ia64: remove redundant READELF from arch/ia64/Makefile
READELF is defined by the top Makefile. Signed-off-by: Masahiro Yamada --- arch/ia64/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile index 3e9da5e6c3bd..467b7e7f967c 100644 --- a/arch/ia64/Makefile +++ b/arch/ia64/Makefile @@ -14,7 +14,6 @@ KBUILD_DEFCONFIG := generic_defconfig NM := $(CROSS_COMPILE)nm -B -READELF := $(CROSS_COMPILE)readelf CHECKFLAGS += -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__ -- 2.27.0
Re: [PATCH] RISC-V: Enable CPU Hotplug in defconfigs
On Mon, 08 Feb 2021 21:46:20 PST (-0800), Anup Patel wrote: The CPU hotplug support has been tested on QEMU, Spike, and SiFive Unleashed so let's enable it by default in RV32 and RV64 defconfigs. Signed-off-by: Anup Patel --- arch/riscv/configs/defconfig | 1 + arch/riscv/configs/rv32_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 8c3d1e451703..6c0625aa96c7 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -17,6 +17,7 @@ CONFIG_BPF_SYSCALL=y CONFIG_SOC_SIFIVE=y CONFIG_SOC_VIRT=y CONFIG_SMP=y +CONFIG_HOTPLUG_CPU=y CONFIG_JUMP_LABEL=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y diff --git a/arch/riscv/configs/rv32_defconfig b/arch/riscv/configs/rv32_defconfig index 2c2cda6cc1c5..8dd02b842fef 100644 --- a/arch/riscv/configs/rv32_defconfig +++ b/arch/riscv/configs/rv32_defconfig @@ -18,6 +18,7 @@ CONFIG_SOC_SIFIVE=y CONFIG_SOC_VIRT=y CONFIG_ARCH_RV32I=y CONFIG_SMP=y +CONFIG_HOTPLUG_CPU=y CONFIG_JUMP_LABEL=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y Sorry about that. I missed a handful of things, I'll send this out tomorrow.
Re: [PATCH] arm64: vmlinux.lds.S: keep .entry.tramp.text section
On 2021-02-26, Kees Cook wrote: On Fri, Feb 26, 2021 at 03:03:39PM +0100, Arnd Bergmann wrote: From: Arnd Bergmann When building with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, I sometimes see an assertion ld.lld: error: Entry trampoline text too big Heh, "too big" seems a weird report for having it discarded. :) Any idea on this Fangrui? ( I see this is https://github.com/ClangBuiltLinux/linux/issues/1311 ) This diagnostic is from an ASSERT in arch/arm64/kernel/vmlinux.lds ASSERT((__entry_tramp_text_end - __entry_tramp_text_start) == (1 << 16), "Entry trampoline text too big") In our case (aarch64-linux-gnu-ld or LLD, --gc-sections), all the input sections with this name are discarded, so the output section is either absent (GNU ld) or empty (LLD). KEEP makes the sections GC roots, and it is appropriate to use here. However, I worry that many other KEEP keywords in vmlinux.lds are unnecessary: https://lore.kernel.org/linux-arm-kernel/20210226211323.arkvjnr4hifxa...@google.com/ git log -S KEEP -- include/asm-generic/vmlinux.lds.h => there is quite a bit unjustified usage. Sure, adding KEEP (GC root) is easy and works around problems, but it not good for CONFIG_LD_DEAD_CODE_DATA_ELIMINATION. Reviewed-by: Fangrui Song This happens when any reference to the trampoline is discarded at link time. Marking the section as KEEP() avoids the assertion, but I have not figured out whether this is the correct solution for the underlying problem. Signed-off-by: Arnd Bergmann As a work-around, it seems fine to me. Reviewed-by: Kees Cook -Kees --- arch/arm64/kernel/vmlinux.lds.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index 926cdb597a45..c5ee9d5842db 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -96,7 +96,7 @@ jiffies = jiffies_64; #define TRAMP_TEXT \ . = ALIGN(PAGE_SIZE); \ __entry_tramp_text_start = .; \ - *(.entry.tramp.text)\ + KEEP(*(.entry.tramp.text)) \ . = ALIGN(PAGE_SIZE); \ __entry_tramp_text_end = .; #else -- 2.29.2 -- Kees Cook
Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA
On Fri, 26 Feb 2021 19:41:40 PST (-0800), hu...@google.com wrote:
On Fri, 26 Feb 2021, Palmer Dabbelt wrote:
On Fri, 26 Feb 2021 17:31:40 PST (-0800), hu...@google.com wrote:
> On Fri, 26 Feb 2021, Andrew Morton wrote:
> > On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt
> > wrote:
> > > From: Palmer Dabbelt
> > >
> > > This is only useful under CONFIG_NUMA. IIUC skipping the check is the
> > > right thing to do here, as without CONFIG_NUMA there will never be any
> > > large node distances on non-NUMA systems.
> > >
> > > I expected this to manifest as a link failure under (!CONFIG_NUMA &&
> > > CONFIG_TRANSPARENT_HUGE_PAGES), but I'm not actually seeing that. I
> > > think the reference is just getting pruned before it's checked, but I
> > > didn't get that from reading the code so I'm worried I'm missing
> > > something.
> > >
> > > Either way, this is necessary to guard the definition of
> > > node_reclaim_distance with CONFIG_NUMA.
> > >
> > > Signed-off-by: Palmer Dabbelt
> > > ---
> > > mm/khugepaged.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > index a7d6cb912b05..b1bf191c3a54 100644
> > > --- a/mm/khugepaged.c
> > > +++ b/mm/khugepaged.c
> > > @@ -819,8 +819,10 @@ static bool khugepaged_scan_abort(int nid)
> > > for (i = 0; i < MAX_NUMNODES; i++) {
> > > if (!khugepaged_node_load[i])
> > > continue;
> > > +#ifdef CONFIG_NUMA
> > > if (node_distance(nid, i) > node_reclaim_distance)
> > > return true;
> > > +#endif
> > > }
> > > return false;
> > > }
> >
> > This makes the entire loop a no-op. Perhaps Kirill can help take a
> > look at removing unnecessary code in khugepaged.c when CONFIG_NUMA=n?
>
> First lines of khugepaged_scan_abort() say
>if (!node_reclaim_mode)
>return false;
>
> And include/linux/swap.h says
> #ifdef CONFIG_NUMA
> extern int node_reclaim_mode;
> extern int sysctl_min_unmapped_ratio;
> extern int sysctl_min_slab_ratio;
> #else
> #define node_reclaim_mode 0
> #endif
>
> So, no need for an #ifdef CONFIG_NUMA inside khugepaged_scan_abort().
Ah, thanks, I hadn't seen that. That certainly explains the lack of an
undefined reference.
That said: do we generally rely on DCE to prune references to undefined
symbols? This particular one seems like it'd get reliably deleted, but it
seems like a fragile thing to do in general. This kind of stuff would
certainly make some code easier to write, though.
Yes, the kernel build very much depends on the optimizer eliminating
dead code, in many many places. We do prefer to keep the #ifdefs to
the header files as much as possible.
OK, makes sense. Thanks!
I don't really care all that much, though, as I was just sending this along
due to some build failure report from a user that I couldn't reproduce. It
looked like they had some out-of-tree stuff, so in this case I'm fine on
fixing this being their problem.
I didn't see your 2/2 at the time; but wouldn't be surprised if that
needs 1/2, to avoid an error on undeclared node_reclaim_distance before
the optimizer comes into play. If so, best just to drop 2/2 too.
Ya, definitely. Sorry for the noise!
Re: [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers from trace events
On Fri, 2021-02-26 at 18:33 -0500, Steven Rostedt wrote: > On Fri, 26 Feb 2021 14:21:00 -0800 > Linus Torvalds wrote: > > > > The second patch handles strings "%s" [..] > > > > Doing this at runtime really feels like the wrong thing to do. > > > > It won't even protect us from what happened - people like me and > > Andrew won't even run those tracepoints in the first place, so we > > won't notice. > > > > It really would be much better in every respect to have this done by > > checkpatch, I think. > > They are not mutually exclusive. We could have both. One thing that's nice > about this patch is that it removes the possibility of a real bug. That is, > it will catch the dereferencing of a string that is not valid, WARN about > it, but it wont try to dereference it (outside of the > strcpy_from_kernel_nofault()). And hopefully the warning and lack of data > they want, will have this get caught during development. > > Also, there's cases that %s is allowed to reference data that I don't know > if checkpatch would be able to differentiate. It's not obvious to me how to do that.
Re: [RFC PATCH 1/8] RISC-V: Enable CPU_IDLE drivers
Hi Alex,
On Fri, Feb 26, 2021 at 6:46 PM Alex Ghiti wrote:
>
> Hi Anup,
>
> Le 2/21/21 à 4:37 AM, Anup Patel a écrit :
> > We force select CPU_PM and provide asm/cpuidle.h so that we can
> > use CPU IDLE drivers for Linux RISC-V kernel.
> >
> > Signed-off-by: Anup Patel
> > ---
> > arch/riscv/Kconfig| 7 +++
> > arch/riscv/configs/defconfig | 7 +++
> > arch/riscv/configs/rv32_defconfig | 4 ++--
> > arch/riscv/include/asm/cpuidle.h | 24
> > arch/riscv/kernel/process.c | 3 ++-
> > 5 files changed, 38 insertions(+), 7 deletions(-)
> > create mode 100644 arch/riscv/include/asm/cpuidle.h
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index fe6862b06ead..4901200b6b6c 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -37,6 +37,7 @@ config RISCV
> > select CLONE_BACKWARDS
> > select CLINT_TIMER if !MMU
> > select COMMON_CLK
> > + select CPU_PM if CPU_IDLE
> > select EDAC_SUPPORT
> > select GENERIC_ARCH_TOPOLOGY if SMP
> > select GENERIC_ATOMIC64 if !64BIT
> > @@ -430,4 +431,10 @@ source "kernel/power/Kconfig"
> >
> > endmenu
> >
> > +menu "CPU Power Management"
> > +
> > +source "drivers/cpuidle/Kconfig"
> > +
> > +endmenu
> > +
> > source "drivers/firmware/Kconfig"
> > diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> > index 6c0625aa96c7..dc4927c0e44b 100644
> > --- a/arch/riscv/configs/defconfig
> > +++ b/arch/riscv/configs/defconfig
> > @@ -13,11 +13,13 @@ CONFIG_USER_NS=y
> > CONFIG_CHECKPOINT_RESTORE=y
> > CONFIG_BLK_DEV_INITRD=y
> > CONFIG_EXPERT=y
> > +# CONFIG_SYSFS_SYSCALL is not set
> > CONFIG_BPF_SYSCALL=y
> > CONFIG_SOC_SIFIVE=y
> > CONFIG_SOC_VIRT=y
> > CONFIG_SMP=y
> > CONFIG_HOTPLUG_CPU=y
> > +CONFIG_CPU_IDLE=y
> > CONFIG_JUMP_LABEL=y
> > CONFIG_MODULES=y
> > CONFIG_MODULE_UNLOAD=y
> > @@ -65,10 +67,9 @@ CONFIG_HW_RANDOM=y
> > CONFIG_HW_RANDOM_VIRTIO=y
> > CONFIG_SPI=y
> > CONFIG_SPI_SIFIVE=y
> > +# CONFIG_PTP_1588_CLOCK is not set
> > CONFIG_GPIOLIB=y
> > CONFIG_GPIO_SIFIVE=y
> > -# CONFIG_PTP_1588_CLOCK is not set
> > -CONFIG_POWER_RESET=y
>
> Why do you remove this config ?
Argh, I don't know how this got here. I will remove
this change in the next revision. Thanks for catching.
>
> > CONFIG_DRM=y
> > CONFIG_DRM_RADEON=y
> > CONFIG_DRM_VIRTIO_GPU=y
> > @@ -132,5 +133,3 @@ CONFIG_DEBUG_BLOCK_EXT_DEVT=y
> > # CONFIG_FTRACE is not set
> > # CONFIG_RUNTIME_TESTING_MENU is not set
> > CONFIG_MEMTEST=y
> > -# CONFIG_SYSFS_SYSCALL is not set
> > -CONFIG_EFI=y
>
> And this is one too ? If those removals are intentional, maybe you can
> add something about that in the commit description ?
I will remove this change as well.
>
> > diff --git a/arch/riscv/configs/rv32_defconfig
> > b/arch/riscv/configs/rv32_defconfig
> > index 8dd02b842fef..332e43a4a2c3 100644
> > --- a/arch/riscv/configs/rv32_defconfig
> > +++ b/arch/riscv/configs/rv32_defconfig
> > @@ -13,12 +13,14 @@ CONFIG_USER_NS=y
> > CONFIG_CHECKPOINT_RESTORE=y
> > CONFIG_BLK_DEV_INITRD=y
> > CONFIG_EXPERT=y
> > +# CONFIG_SYSFS_SYSCALL is not set
> > CONFIG_BPF_SYSCALL=y
> > CONFIG_SOC_SIFIVE=y
> > CONFIG_SOC_VIRT=y
> > CONFIG_ARCH_RV32I=y
> > CONFIG_SMP=y
> > CONFIG_HOTPLUG_CPU=y
> > +CONFIG_CPU_IDLE=y
> > CONFIG_JUMP_LABEL=y
> > CONFIG_MODULES=y
> > CONFIG_MODULE_UNLOAD=y
> > @@ -67,7 +69,6 @@ CONFIG_HW_RANDOM_VIRTIO=y
> > CONFIG_SPI=y
> > CONFIG_SPI_SIFIVE=y
> > # CONFIG_PTP_1588_CLOCK is not set
> > -CONFIG_POWER_RESET=y
> > CONFIG_DRM=y
> > CONFIG_DRM_RADEON=y
> > CONFIG_DRM_VIRTIO_GPU=y
> > @@ -131,4 +132,3 @@ CONFIG_DEBUG_BLOCK_EXT_DEVT=y
> > # CONFIG_FTRACE is not set
> > # CONFIG_RUNTIME_TESTING_MENU is not set
> > CONFIG_MEMTEST=y
> > -# CONFIG_SYSFS_SYSCALL is not set
> > diff --git a/arch/riscv/include/asm/cpuidle.h
> > b/arch/riscv/include/asm/cpuidle.h
> > new file mode 100644
> > index ..1042d790e446
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/cpuidle.h
> > @@ -0,0 +1,24 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2021 Allwinner Ltd
> > + * Copyright (C) 2021 Western Digital Corporation or its affiliates.
> > + */
> > +
> > +#ifndef _ASM_RISCV_CPUIDLE_H
> > +#define _ASM_RISCV_CPUIDLE_H
> > +
> > +#include
> > +#include
> > +
> > +static inline void cpu_do_idle(void)
> > +{
> > + /*
> > + * Add mb() here to ensure that all
> > + * IO/MEM access are completed prior
>
> accessES ?
Okay will update.
>
> > + * to enter WFI.
> > + */
> > + mb();
> > + wait_for_interrupt();
> > +}
> > +
> > +#endif
> > diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
> > index dd5f985b1f40..b5b51fd26624 100644
> > --- a/arch/riscv/kernel/process.c
> > +++ b/arch/riscv/kernel/process.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
Re: [PATCH] RISC-V: Enable CPU Hotplug in defconfigs
Hi Palmer, On Fri, Feb 19, 2021 at 12:45 PM Palmer Dabbelt wrote: > > On Mon, 08 Feb 2021 21:46:20 PST (-0800), Anup Patel wrote: > > The CPU hotplug support has been tested on QEMU, Spike, and SiFive > > Unleashed so let's enable it by default in RV32 and RV64 defconfigs. > > > > Signed-off-by: Anup Patel > > --- > > arch/riscv/configs/defconfig | 1 + > > arch/riscv/configs/rv32_defconfig | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig > > index 8c3d1e451703..6c0625aa96c7 100644 > > --- a/arch/riscv/configs/defconfig > > +++ b/arch/riscv/configs/defconfig > > @@ -17,6 +17,7 @@ CONFIG_BPF_SYSCALL=y > > CONFIG_SOC_SIFIVE=y > > CONFIG_SOC_VIRT=y > > CONFIG_SMP=y > > +CONFIG_HOTPLUG_CPU=y > > CONFIG_JUMP_LABEL=y > > CONFIG_MODULES=y > > CONFIG_MODULE_UNLOAD=y > > diff --git a/arch/riscv/configs/rv32_defconfig > > b/arch/riscv/configs/rv32_defconfig > > index 2c2cda6cc1c5..8dd02b842fef 100644 > > --- a/arch/riscv/configs/rv32_defconfig > > +++ b/arch/riscv/configs/rv32_defconfig > > @@ -18,6 +18,7 @@ CONFIG_SOC_SIFIVE=y > > CONFIG_SOC_VIRT=y > > CONFIG_ARCH_RV32I=y > > CONFIG_SMP=y > > +CONFIG_HOTPLUG_CPU=y > > CONFIG_JUMP_LABEL=y > > CONFIG_MODULES=y > > CONFIG_MODULE_UNLOAD=y > > Thanks, this is on for-next. This patch was missed in your PR for Linux-5.12-rc1 Regards, Anup
Re: [RFC PATCH] USB:XHCI:Modify XHCI driver for USB2.0 controller
On 2021/2/27 11:38, liulongfang wrote: > On 2021/2/27 0:30, Alan Stern wrote: >> On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: >>> Our current XHCI hardware controller has been customized to only >>> support USB 2.0 ports. When using the current xhci driver, an xhci >>> controller device and an ehci controller device will be created >>> automatically. >> >> That sentence makes no sense at all. An EHCI controller device is a >> piece of hardware. How can an xHCI driver, which is a piece of >> software, create a piece of hardware? >> >> Alan Stern >> . >> > The hardware device is a complete USB3.0 controller, On the hardware, only the hardware connection of the USB2.0 port has been opened > but I hope to support a USB2.0-only mode through software configuration. > Thanks. > Longfang Liu > . > Thanks. Longfang Liu
Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA
On Fri, 26 Feb 2021, Palmer Dabbelt wrote:
> On Fri, 26 Feb 2021 17:31:40 PST (-0800), hu...@google.com wrote:
> > On Fri, 26 Feb 2021, Andrew Morton wrote:
> > > On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt
> > > wrote:
> > > > From: Palmer Dabbelt
> > > >
> > > > This is only useful under CONFIG_NUMA. IIUC skipping the check is the
> > > > right thing to do here, as without CONFIG_NUMA there will never be any
> > > > large node distances on non-NUMA systems.
> > > >
> > > > I expected this to manifest as a link failure under (!CONFIG_NUMA &&
> > > > CONFIG_TRANSPARENT_HUGE_PAGES), but I'm not actually seeing that. I
> > > > think the reference is just getting pruned before it's checked, but I
> > > > didn't get that from reading the code so I'm worried I'm missing
> > > > something.
> > > >
> > > > Either way, this is necessary to guard the definition of
> > > > node_reclaim_distance with CONFIG_NUMA.
> > > >
> > > > Signed-off-by: Palmer Dabbelt
> > > > ---
> > > > mm/khugepaged.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > > index a7d6cb912b05..b1bf191c3a54 100644
> > > > --- a/mm/khugepaged.c
> > > > +++ b/mm/khugepaged.c
> > > > @@ -819,8 +819,10 @@ static bool khugepaged_scan_abort(int nid)
> > > > for (i = 0; i < MAX_NUMNODES; i++) {
> > > > if (!khugepaged_node_load[i])
> > > > continue;
> > > > +#ifdef CONFIG_NUMA
> > > > if (node_distance(nid, i) > node_reclaim_distance)
> > > > return true;
> > > > +#endif
> > > > }
> > > > return false;
> > > > }
> > >
> > > This makes the entire loop a no-op. Perhaps Kirill can help take a
> > > look at removing unnecessary code in khugepaged.c when CONFIG_NUMA=n?
> >
> > First lines of khugepaged_scan_abort() say
> > if (!node_reclaim_mode)
> > return false;
> >
> > And include/linux/swap.h says
> > #ifdef CONFIG_NUMA
> > extern int node_reclaim_mode;
> > extern int sysctl_min_unmapped_ratio;
> > extern int sysctl_min_slab_ratio;
> > #else
> > #define node_reclaim_mode 0
> > #endif
> >
> > So, no need for an #ifdef CONFIG_NUMA inside khugepaged_scan_abort().
>
> Ah, thanks, I hadn't seen that. That certainly explains the lack of an
> undefined reference.
>
> That said: do we generally rely on DCE to prune references to undefined
> symbols? This particular one seems like it'd get reliably deleted, but it
> seems like a fragile thing to do in general. This kind of stuff would
> certainly make some code easier to write, though.
Yes, the kernel build very much depends on the optimizer eliminating
dead code, in many many places. We do prefer to keep the #ifdefs to
the header files as much as possible.
>
> I don't really care all that much, though, as I was just sending this along
> due to some build failure report from a user that I couldn't reproduce. It
> looked like they had some out-of-tree stuff, so in this case I'm fine on
> fixing this being their problem.
I didn't see your 2/2 at the time; but wouldn't be surprised if that
needs 1/2, to avoid an error on undeclared node_reclaim_distance before
the optimizer comes into play. If so, best just to drop 2/2 too.
Hugh
Re: [PATCH v3] x86/fault: Send a SIGBUS to user process always for hwpoison page access.
On Wed, Feb 24, 2021 at 8:47 PM Aili Yao wrote: > > On Tue, 23 Feb 2021 08:42:59 -0800 > "Luck, Tony" wrote: > > > On Tue, Feb 23, 2021 at 07:33:46AM -0800, Andy Lutomirski wrote: > > > > > > > On Feb 23, 2021, at 4:44 AM, Aili Yao wrote: > > > > > > > > On Fri, 5 Feb 2021 17:01:35 +0800 > > > > Aili Yao wrote: > > > > > > > >> When one page is already hwpoisoned by MCE AO action, processes may not > > > >> be killed, processes mapping this page may make a syscall include this > > > >> page and result to trigger a VM_FAULT_HWPOISON fault, as it's in kernel > > > >> mode it may be fixed by fixup_exception, current code will just return > > > >> error code to user code. > > > >> > > > >> This is not sufficient, we should send a SIGBUS to the process and log > > > >> the info to console, as we can't trust the process will handle the > > > >> error > > > >> correctly. > > > >> > > > >> Suggested-by: Feng Yang > > > >> Signed-off-by: Aili Yao > > > >> --- > > > >> arch/x86/mm/fault.c | 62 + > > > >> 1 file changed, 40 insertions(+), 22 deletions(-) > > > >> > > > > Hi luto; > > > > Is there any feedback? > > > > > > At the very least, this needs a clear explanation of why your proposed > > > behavior is better than the existing behavior. > > > > The explanation is buried in that "can't trust the process" line. > > > > E.g. user space isn't good about checking for failed write(2) syscalls. > > So if the poison was in a user buffer passed to write(fd, buffer, count) > > sending a SIGBUS would be the action if they read the poison directly, > > so it seems reasonable to send the same signal if the kernel read their > > poison for them. > > > > It would avoid users that didn't check the return value merrily proceeding > > as if everything was ok. > > Hi luto: >I will add more infomation: >Even if the process will check return value of syscall like write, I don't > think > process will take proper action for this. >In test example, the return value will be errno is 14 (Bad Address), the > process may not realize > this is a hw issue, and may take wrong action not as expected. >And totally, A hw error will rarely happen, and the hw error hitting this > branch will be > more unlikely, the impaction without this patch is quite minor, but this is > still not good enough, we should > make it better, right? There are a few issues I can imagine: Some programs may use read(2), write(2), etc as ways to check if memory is valid without getting a signal. They might not want signals, which means that this feature might need to be configurable. It's worth making sure that this doesn't end up sending duplicate signals. If nothing else, this would impact the vsyscall emulation code. Programs that get a signal might expect that the RIP that the signal frame points to is the instruction that caused the signal and that the instruction faulted without side effects. For SIGSEGV, I would be especially nervous about this. Maybe SIGBUS is safer. For SIGSEGV, it's entirely valid to look at CR2 / si_fault_addr, fix it up, and return. This would be completely *invalid* with your patch. I'm not sure what to do about this. --Andy
Re: [RFC PATCH] USB:XHCI:Modify XHCI driver for USB2.0 controller
On 2021/2/27 0:30, Alan Stern wrote: > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: >> Our current XHCI hardware controller has been customized to only >> support USB 2.0 ports. When using the current xhci driver, an xhci >> controller device and an ehci controller device will be created >> automatically. > > That sentence makes no sense at all. An EHCI controller device is a > piece of hardware. How can an xHCI driver, which is a piece of > software, create a piece of hardware? > > Alan Stern > . > The hardware device is a complete USB3.0 controller, but I hope to support a USB2.0-only mode through software configuration. Thanks. Longfang Liu
Re: [PATCH] Fix zero_user_segments() with start > end
Matthew Wilcox writes:
> On Sat, Feb 27, 2021 at 01:11:35AM +0900, OGAWA Hirofumi wrote:
>> zero_user_segments() is used from __block_write_begin_int(), for
>> example like the following
>>
>> zero_user_segments(page, 4096, 1024, 512, 918)
>>
>> But new zero_user_segments() implements for HIGMEM + TRANSPARENT_HUGEPAGE
>> doesn't handle "start > end" case correctly, and hits BUG_ON(). (we
>> can fix __block_write_begin_int() instead though, it is the old and
>> multiple usage)
>
> Why don't we just take out the BUG_ON instead? The function doesn't
> actually do the wrong thing.
end1 is underflow with
if (start1 >= PAGE_SIZE) {
start1 -= PAGE_SIZE;
end1 -= PAGE_SIZE;
}
>> Also it calls kmap_atomic() unnecessary while start == end == 0.
>
> I'm OK with that. It always used to do that.
Old one is only one page, so it is always necessary if start1/end1 or
start2/end2 is valid range. But this one is multiple pages, so there are
completely unnecessary pages possibly.
>> Cc:
>> Signed-off-by: OGAWA Hirofumi
>
> Fixes: 0060ef3b4e6d ("mm: support THPs in zero_user_segments")
OK.
--
OGAWA Hirofumi
Re: [PATCH v9 9/9] certs: Add support for using elliptic curve keys for signing modules
在 2021/2/26 0:08, Stefan Berger 写道: From: Stefan Berger diff --git a/certs/Makefile b/certs/Makefile index 3fe6b73786fa..c487d7021c54 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -69,6 +69,18 @@ else SIGNER = -signkey $(obj)/signing_key.key endif # CONFIG_IMA_APPRAISE_MODSIG Is there anything wrong in this patch? I can't apply it when I use 'git am '. errors like below: error: certs/Kconfig: does not match index error: patch failed: certs/Makefile:69 error: certs/Makefile: patch does not apply Thanks
Re: [RFC PATCH] USB:XHCI:Modify XHCI driver for USB2.0 controller
On 2021/2/26 17:22, Mathias Nyman wrote:
> On 26.2.2021 10.21, Longfang Liu wrote:
>> Our current XHCI hardware controller has been customized to only
>> support USB 2.0 ports. When using the current xhci driver, an xhci
>> controller device and an ehci controller device will be created
>> automatically. We want the driver to create only one ehci controller.
>> After modifying the driver as follows, an error will occur.
>> Is there any other modification method?
>
> The xhci driver relies on the existence of both a main and a shared hcd.
> One hcd for handing USB 2 (and slower) and the other for USB 3 devices.
>
> As one example xhci_run(hcd) needs to be called for both hcds, first call
> sets up things, second one calls xhci_start() that makes the controller run.
>
> It's probably possible to modify the driver to support xHCI hosts with only
> USB 2 ports, but requires a lot more work.
>
>>
>> Signed-off-by: Longfang Liu
>> ---
>> drivers/usb/host/xhci-pci.c | 15 ++-
>> 1 file changed, 2 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>> index ef513c2..7296aad 100644
>> --- a/drivers/usb/host/xhci-pci.c
>> +++ b/drivers/usb/host/xhci-pci.c
>> @@ -364,26 +364,15 @@ static int xhci_pci_probe(struct pci_dev *dev, const
>> struct pci_device_id *id)
>> /* USB 2.0 roothub is stored in the PCI device now. */
>> hcd = dev_get_drvdata(>dev);
>> xhci = hcd_to_xhci(hcd);
>> -xhci->shared_hcd = usb_create_shared_hcd(_pci_hc_driver, >dev,
>> - pci_name(dev), hcd);
>> -if (!xhci->shared_hcd) {
>> -retval = -ENOMEM;
>> -goto dealloc_usb2_hcd;
>> -}
>> -
>> +xhci->shared_hcd = NULL;
>> retval = xhci_ext_cap_init(xhci);
>> if (retval)
>> goto put_usb3_hcd;
>>
>> -retval = usb_add_hcd(xhci->shared_hcd, dev->irq,
>> +retval = usb_add_hcd(xhci->main_hcd, dev->irq,
>> IRQF_SHARED);
>> if (retval)
>> goto put_usb3_hcd;
>> -/* Roothub already marked as USB 3.0 speed */
>> -
>> -if (!(xhci->quirks & XHCI_BROKEN_STREAMS) &&
>> -HCC_MAX_PSA(xhci->hcc_params) >= 4)
>> -xhci->shared_hcd->can_do_streams = 1;
>>
>> /* USB-2 and USB-3 roothubs initialized, allow runtime pm suspend */
>> pm_runtime_put_noidle(>dev);
>>
>
> Something like the above could of course not be accepted upstream. We can't
> break existing
> functionality to support one modified xHCI.
>
> Thanks
> Mathias
> .
>
Thanks very much.
Longfang Liu
Re: [RFC PATCH] USB:XHCI:Modify XHCI driver for USB2.0 controller
On 2021/2/26 16:38, Greg KH wrote: > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote: >> Our current XHCI hardware controller has been customized to only >> support USB 2.0 ports. > > That sounds like a spec violation, right? Why do you want to do this? > > greg k-h > . > I hope to support a USB2.0-only mode on the XHCI controller through software configuration. Thanks. Longfang Liu
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:284:9: sparse: sparse: incorrect type in argument 1 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 3fb6d0e00efc958d01c2f109c8453033a2d96796
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for
__chk_{user,io}_ptr()
date: 6 months ago
config: sh-randconfig-s032-20210226 (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-241-geaceeafa-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5fc436f06eef54ef512ea55a9db8eb9f2e76959
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e5fc436f06eef54ef512ea55a9db8eb9f2e76959
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> arch/sh/kernel/cpu/sh2a/setup-sh7206.c:284:9: sparse: sparse: incorrect type
>> in argument 1 (different base types) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:284:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:284:9: sparse: got unsigned int
>> arch/sh/kernel/cpu/sh2a/setup-sh7206.c:284:9: sparse: sparse: incorrect type
>> in argument 1 (different base types) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:284:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:284:9: sparse: got unsigned int
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:287:9: sparse: sparse: incorrect type
in argument 1 (different base types) @@ expected void const volatile
[noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:287:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:287:9: sparse: got unsigned int
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:287:9: sparse: sparse: incorrect type
in argument 1 (different base types) @@ expected void const volatile
[noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:287:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/setup-sh7206.c:287:9: sparse: got unsigned int
vim +284 arch/sh/kernel/cpu/sh2a/setup-sh7206.c
698aa99da5f5e2 Magnus Damm 2009-04-30 280
698aa99da5f5e2 Magnus Damm 2009-04-30 281 void __init
plat_early_device_setup(void)
698aa99da5f5e2 Magnus Damm 2009-04-30 282 {
698aa99da5f5e2 Magnus Damm 2009-04-30 283 /* enable CMT clock */
698aa99da5f5e2 Magnus Damm 2009-04-30 @284
__raw_writeb(__raw_readb(STBCR4) & ~0x04, STBCR4);
:: The code at line 284 was first introduced by commit
:: 698aa99da5f5e2b4c666fd21ab77306f0225b8f5 sh: sh2/sh2a 16-bit CMT
platform data
:: TO: Magnus Damm
:: CC: Paul Mundt
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] drivers: firmware: efi: fix Kconfig dependency on CRYPTO
When EFI_EMBEDDED_FIRMWARE is enabled, and CRYPTO is not enabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for CRYPTO_LIB_SHA256 Depends on [n]: CRYPTO [=n] Selected by [y]: - EFI_EMBEDDED_FIRMWARE [=y] && EFI [=y] This is because EFI_EMBEDDED_FIRMWARE selects CRYPTO_LIB_SHA256 without selecting or depending on CRYPTO, despite CRYPTO_LIB_SHA256 depending on CRYPTO. Signed-off-by: Julian Braha --- drivers/firmware/efi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig index 2c3dac5ecb36..f914da9845ac 100644 --- a/drivers/firmware/efi/Kconfig +++ b/drivers/firmware/efi/Kconfig @@ -248,6 +248,7 @@ endmenu config EFI_EMBEDDED_FIRMWARE bool depends on EFI + select CRYPTO select CRYPTO_LIB_SHA256 config UEFI_CPER -- 2.27.0
Re: [PATCH] RISC-V: Make NUMA depend on SMP
On Fri, 26 Feb 2021 17:03:53 PST (-0800), wangkefeng.w...@huawei.com wrote:
On 2021/2/27 4:25, Palmer Dabbelt wrote:
From: Palmer Dabbelt
In theory these are orthogonal, but in practice all NUMA systems are
SMP. NUMA && !SMP doesn't build, everyone else is coupling them, and I
don't really see any value in supporting that configuration.
Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform")
Suggested-by: Andrew Morton
Suggested-by: Atish Patra
Signed-off-by: Palmer Dabbelt
Reported-and-Tested-by: Kefeng Wang
Ah, thanks, I forged I'd said no to this earlier ;)
---
This is on fixes.
---
arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a998babc1237..85d626b8ce5e 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -314,6 +314,7 @@ endchoice
# Common NUMA Features
config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
+ depends on SMP
select GENERIC_ARCH_NUMA
select OF_NUMA
select ARCH_SUPPORTS_NUMA_BALANCING
[PATCH V2 net] net: phy: fix save wrong speed and duplex problem if autoneg is on
From: Guangbin Huang
If phy uses generic driver and autoneg is on, enter command
"ethtool -s eth0 speed 50" will not change phy speed actually, but
command "ethtool eth0" shows speed is 50Mb/s because phydev->speed
has been set to 50 and no update later.
And duplex setting has same problem too.
However, if autoneg is on, phy only changes speed and duplex according to
phydev->advertising, but not phydev->speed and phydev->duplex. So in this
case, phydev->speed and phydev->duplex don't need to be set in function
phy_ethtool_ksettings_set() if autoneg is on.
Fixes: 51e2a3846eab ("PHY: Avoid unnecessary aneg restarts")
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
V1->V2: add a Fixes tag
---
drivers/net/phy/phy.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 1be07e4..fc2e7cb 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -276,14 +276,16 @@ int phy_ethtool_ksettings_set(struct phy_device *phydev,
phydev->autoneg = autoneg;
- phydev->speed = speed;
+ if (autoneg == AUTONEG_DISABLE) {
+ phydev->speed = speed;
+ phydev->duplex = duplex;
+ }
linkmode_copy(phydev->advertising, advertising);
linkmode_mod_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
phydev->advertising, autoneg == AUTONEG_ENABLE);
- phydev->duplex = duplex;
phydev->master_slave_set = cmd->base.master_slave_cfg;
phydev->mdix_ctrl = cmd->base.eth_tp_mdix_ctrl;
--
2.7.4
Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA
On Fri, 26 Feb 2021 17:31:40 PST (-0800), hu...@google.com wrote:
On Fri, 26 Feb 2021, Andrew Morton wrote:
On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt wrote:
> From: Palmer Dabbelt
>
> This is only useful under CONFIG_NUMA. IIUC skipping the check is the
> right thing to do here, as without CONFIG_NUMA there will never be any
> large node distances on non-NUMA systems.
>
> I expected this to manifest as a link failure under (!CONFIG_NUMA &&
> CONFIG_TRANSPARENT_HUGE_PAGES), but I'm not actually seeing that. I
> think the reference is just getting pruned before it's checked, but I
> didn't get that from reading the code so I'm worried I'm missing
> something.
>
> Either way, this is necessary to guard the definition of
> node_reclaim_distance with CONFIG_NUMA.
>
> Signed-off-by: Palmer Dabbelt
> ---
> mm/khugepaged.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index a7d6cb912b05..b1bf191c3a54 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -819,8 +819,10 @@ static bool khugepaged_scan_abort(int nid)
>for (i = 0; i < MAX_NUMNODES; i++) {
>if (!khugepaged_node_load[i])
>continue;
> +#ifdef CONFIG_NUMA
>if (node_distance(nid, i) > node_reclaim_distance)
>return true;
> +#endif
>}
>return false;
> }
This makes the entire loop a no-op. Perhaps Kirill can help take a
look at removing unnecessary code in khugepaged.c when CONFIG_NUMA=n?
First lines of khugepaged_scan_abort() say
if (!node_reclaim_mode)
return false;
And include/linux/swap.h says
#ifdef CONFIG_NUMA
extern int node_reclaim_mode;
extern int sysctl_min_unmapped_ratio;
extern int sysctl_min_slab_ratio;
#else
#define node_reclaim_mode 0
#endif
So, no need for an #ifdef CONFIG_NUMA inside khugepaged_scan_abort().
Ah, thanks, I hadn't seen that. That certainly explains the lack of an
undefined reference.
That said: do we generally rely on DCE to prune references to undefined
symbols? This particular one seems like it'd get reliably deleted, but it
seems like a fragile thing to do in general. This kind of stuff would
certainly make some code easier to write, though.
I don't really care all that much, though, as I was just sending this along due
to some build failure report from a user that I couldn't reproduce. It looked
like they had some out-of-tree stuff, so in this case I'm fine on fixing this
being their problem.
RE: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS
On Fri, Feb 26, 2021 at 2:35 PM -0800, Andrew Lunn wrote: > On Mon, Feb 15, 2021 at 11:38:21AM -0800, Don Bollinger wrote: > > optoe is an i2c based driver that supports read/write access to all > > the pages (tables) of MSA standard SFP and similar devices (conforming > > to the SFF-8472 spec), MSA standard QSFP and similar devices > > (conforming to the SFF-8636 spec) and CMIS and similar devices > > (conforming to the Common Management Interface Specfication). > > Hi Don > > Please make sure you Cc: netdev. This is networking stuff. Will do. > And we have seen this code before, and the netdev Maintainers have > argued against it before. Yes, though I have tried to make it more acceptable, and also more useful to you... > > These devices provide identification, operational status and control > > registers via an EEPROM model. These devices support one or 3 fixed > > pages > > (128 bytes) of data, and one page that is selected via a page register > > on the first fixed page. Thus the driver's main task is to map these > > pages onto a simple linear address space for user space management > applications. > > See the driver code for a detailed layout. > > I assume you have seen the work NVIDIA submitted last week? This idea of > linear pages is really restrictive and we are moving away from it. No, I haven't seen it. I can't seem to locate anything in the past month on LMKL from NVIDIA. Please point me to it. What are you using instead of mapping the pages into a linear address space? Perhaps I can provide a different interface to call with some other mapping. > > The EEPROM data is accessible to user space and kernel consumers via > > the nvmem interface. > > ethtool -m ? This is actually below ethtool. Ethtool has to fetch the data from the eeprom using an appropriate i2c interface (these are defined to be i2c devices). And, to fetch the data from any but the first 256 bytes the code ethtool calls must deal with the page register on the device. This driver handles the page register, for both SFP and QSFP/CMIS devices. This driver would be a useful path for ethtool to use when someone decides to make that data available. Note for example, CMIS devices put the DOM data (per-channel Tx power, Rx Power, laser bias) on page 0x11. When you want that data, you'll have to go past 256 bytes and deal with the page register. optoe will do that for you. > In the past, this code has been NACKed because it does not integrate into > the networking stack. Is this attempt any different? Yes. I have updated the driver with all the latest changes in at24.c, the primary eeprom driver. That update includes use of the nvmem interface, which means this driver can now be called by kernel code. I believe it would be useful and easy to replace the sfp.c code that accesses the eeprom with nvmem calls to this driver. By doing so, you will be able to access the additional pages of data on those devices. You would also get the benefit of sharing common code the other eeprom drivers. As part of that cleanup, the explicit sysfs creation of an eeprom device has been removed. Full disclosure, the nvmem interface creates that device now. > Thanks > Andrew One more point, I have been requested by the SONiC team to upstream this driver. It is on their short list of kernel code that is not upstream, and they want to fix that. They are not consumers of the netdev interface, but they (and other NOS providers) have a need for a driver to access the eeprom data. Greg KH was involved in that request, and I related your concerns to him, as well as my position that this is an eeprom driver with partners that need it independent of netdev. His response: GKH> I can't remember the actual patch anymore, but you are right, it's "just" GKH> poking around in the EEPROM for the device, and doing what you want in GKH> userspace, which really should be fine. Submit it and I'll be glad to review it GKH> under that type of functionality being added. He didn't say he would override your position, but he suggested it was appropriate to submit it. So, here it is. Thus: 1. There are existing NOS platforms that need and use this functionality, they want it in the upstream kernel. 2. This driver is better than sfp.c, and could easily be plugged in to improve netdev and ethtool access to SFP/QSFP/CMIS EEPROM data. Don
arch/arm/boot/compressed/fdt_check_mem_start.c:62:10: warning: no previous prototype for function 'fdt_check_mem_start'
Hi Geert, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3fb6d0e00efc958d01c2f109c8453033a2d96796 commit: 0673cb38951215060d7993b43ad3c45cd413c2c3 ARM: 9045/1: uncompress: Validate start of physical memory against passed DTB date: 4 weeks ago config: arm-randconfig-r003-20210226 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project b889ef4214bc6dc8880fdd4badc0dcd9a3197753) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm cross compiling tool for clang build # apt-get install binutils-arm-linux-gnueabi # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0673cb38951215060d7993b43ad3c45cd413c2c3 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 0673cb38951215060d7993b43ad3c45cd413c2c3 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> arch/arm/boot/compressed/fdt_check_mem_start.c:62:10: warning: no previous >> prototype for function 'fdt_check_mem_start' [-Wmissing-prototypes] uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt) ^ arch/arm/boot/compressed/fdt_check_mem_start.c:62:1: note: declare 'static' if the function is not intended to be used outside of this translation unit uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt) ^ static 1 warning generated. vim +/fdt_check_mem_start +62 arch/arm/boot/compressed/fdt_check_mem_start.c 46 47 /* 48 * Check the start of physical memory 49 * 50 * Traditionally, the start address of physical memory is obtained by masking 51 * the program counter. However, this does require that this address is a 52 * multiple of 128 MiB, precluding booting Linux on platforms where this 53 * requirement is not fulfilled. 54 * Hence validate the calculated address against the memory information in the 55 * DTB, and, if out-of-range, replace it by the real start address. 56 * To preserve backwards compatibility (systems reserving a block of memory 57 * at the start of physical memory, kdump, ...), the traditional method is 58 * always used if it yields a valid address. 59 * 60 * Return value: start address of physical memory to use 61 */ > 62 uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt) --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] net: bridge: Fix jump_label config
On 2021/2/27 4:19, Cong Wang wrote:
On Thu, Feb 25, 2021 at 5:39 PM Kefeng Wang wrote:
On 2021/2/26 5:22, Cong Wang wrote:
On Wed, Feb 24, 2021 at 8:03 AM Kefeng Wang wrote:
HAVE_JUMP_LABLE is removed by commit e9666d10a567 ("jump_label: move
'asm goto' support test to Kconfig"), use CONFIG_JUMP_LABLE instead
of HAVE_JUMP_LABLE.
Fixes: 971502d77faa ("bridge: netfilter: unroll NF_HOOK helper in bridge input
path")
Signed-off-by: Kefeng Wang
Hmm, why do we have to use a macro here? static_key_false() is defined
in both cases, CONFIG_JUMP_LABEL=y or CONFIG_JUMP_LABEL=n.
It seems that all nf_hooks_needed related are using the macro,
see net/netfilter/core.c and include/linux/netfilter.h,
#ifdef CONFIG_JUMP_LABEL
struct static_key nf_hooks_needed[NFPROTO_NUMPROTO][NF_MAX_HOOKS];
EXPORT_SYMBOL(nf_hooks_needed);
#endif
nf_static_key_inc()/nf_static_key_dec()
Same question: why? Clearly struct static_key is defined in both cases:
Ok, I mean that I don't change the original logic, but that's no need
this macro actually,
it could be built with or without CONFIG_JUMP_LABEL, only increased the
size a little bit.
#else
struct static_key {
atomic_t enabled;
};
#endif /* CONFIG_JUMP_LABEL */
Thanks.
Current mainline
Has anyone seen this? I was running some xfstests today on current mainline (ran same tests yesterday and multiple times last week on 5.11 and did not see this) and hit this multiple times [ 287.702292] [ cut here ] [ 287.702296] WARNING: CPU: 5 PID: 8223 at drivers/gpu/drm/ttm/ttm_bo.c:512 ttm_bo_release+0x2f7/0x350 [ttm] [ 287.702309] Modules linked in: cifs ccm md4 cmac nls_utf8 libarc4 libdes rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel virtio_balloon ip_tables xfs qxl drm_ttm_helper ttm drm_kms_helper cec drm virtio_net net_failover floppy failover virtio_blk virtio_console crc32c_intel qemu_fw_cfg [last unloaded: cifs] [ 287.702352] CPU: 5 PID: 8223 Comm: kworker/5:50 Tainted: GW 5.11.0 #1 [ 287.702355] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 287.702357] Workqueue: events qxl_gc_work [qxl] [ 287.702362] RIP: 0010:ttm_bo_release+0x2f7/0x350 [ttm] [ 287.702367] Code: e9 6a fd ff ff e8 c9 e7 46 eb e9 92 fd ff ff 49 8b 7f 90 b9 30 75 00 00 31 d2 be 01 00 00 00 e8 1f 0b 47 eb 49 8b 47 e0 eb a1 <0f> 0b 49 8d 77 08 41 c7 87 94 00 00 00 00 00 00 00 31 d2 4c 89 f7 [ 287.702370] RSP: 0018:b2c2c877fda8 EFLAGS: 00010202 [ 287.702372] RAX: 0001 RBX: 000c RCX: 000d [ 287.702373] RDX: 0001 RSI: 0246 RDI: c035a0e8 [ 287.702374] RBP: 922102e4c688 R08: 92210f996050 R09: 922110ac5938 [ 287.702376] R10: R11: 922100469240 R12: 922110ac5e80 [ 287.702377] R13: 92210b5509d0 R14: 92210b550800 R15: 92210b550968 [ 287.702383] FS: () GS:92252bd4() knlGS: [ 287.702385] CS: 0010 DS: ES: CR0: 80050033 [ 287.702386] CR2: 55617142e5d0 CR3: 000334610005 CR4: 003706e0 [ 287.702400] DR0: DR1: DR2: [ 287.702401] DR3: DR6: fffe0ff0 DR7: 0400 [ 287.702403] Call Trace: [ 287.702408] qxl_bo_unref+0x3a/0x50 [qxl] [ 287.702414] qxl_release_free_list+0x49/0x90 [qxl] [ 287.702419] qxl_release_free+0x72/0xe0 [qxl] [ 287.702423] qxl_garbage_collect+0xd1/0x180 [qxl] [ 287.702427] process_one_work+0x1c0/0x390 [ 287.702438] worker_thread+0x30/0x390 [ 287.702441] ? process_one_work+0x390/0x390 [ 287.702444] kthread+0x117/0x130 [ 287.702448] ? kthread_park+0x90/0x90 [ 287.702450] ret_from_fork+0x22/0x30 [ 287.702457] ---[ end trace 03e19399d00180a1 ]--- [ 287.702539] [ cut here ] -- Thanks, Steve
Re: [PATCH 5.10 00/23] 5.10.19-rc1 review
On 2021/2/26 14:44, Hanjun Guo wrote: Hi Greg, On 2021/2/25 17:53, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.10.19 release. There are 23 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 27 Feb 2021 09:25:06 +. Anything received after that time might be too late. It takes longer time to set up our test farm than I expected, for now we can run test on x86 for stable 5.10, test for ARM64 server and other stable kernels (4.19 and 5.4) is in progress (needs more machines and a rack in the data center), please give us a bit more time to get things ready. Here is the test results for x86, compiled and booted OK, also no regressions for the functional test [1] (the failed ones are the mismatch of the testcase and the test environment, not the kernel failures), Although 5.10.19 is released, it's better to report the ARM64 test results as well: Testcase Result Summary: total_num: 4732 succeed_num: 4732 failed_num: 0 timeout_num: 0 Thanks Hanjun
Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA
On Fri, 26 Feb 2021, Andrew Morton wrote:
> On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt wrote:
> > From: Palmer Dabbelt
> >
> > This is only useful under CONFIG_NUMA. IIUC skipping the check is the
> > right thing to do here, as without CONFIG_NUMA there will never be any
> > large node distances on non-NUMA systems.
> >
> > I expected this to manifest as a link failure under (!CONFIG_NUMA &&
> > CONFIG_TRANSPARENT_HUGE_PAGES), but I'm not actually seeing that. I
> > think the reference is just getting pruned before it's checked, but I
> > didn't get that from reading the code so I'm worried I'm missing
> > something.
> >
> > Either way, this is necessary to guard the definition of
> > node_reclaim_distance with CONFIG_NUMA.
> >
> > Signed-off-by: Palmer Dabbelt
> > ---
> > mm/khugepaged.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index a7d6cb912b05..b1bf191c3a54 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -819,8 +819,10 @@ static bool khugepaged_scan_abort(int nid)
> > for (i = 0; i < MAX_NUMNODES; i++) {
> > if (!khugepaged_node_load[i])
> > continue;
> > +#ifdef CONFIG_NUMA
> > if (node_distance(nid, i) > node_reclaim_distance)
> > return true;
> > +#endif
> > }
> > return false;
> > }
>
> This makes the entire loop a no-op. Perhaps Kirill can help take a
> look at removing unnecessary code in khugepaged.c when CONFIG_NUMA=n?
First lines of khugepaged_scan_abort() say
if (!node_reclaim_mode)
return false;
And include/linux/swap.h says
#ifdef CONFIG_NUMA
extern int node_reclaim_mode;
extern int sysctl_min_unmapped_ratio;
extern int sysctl_min_slab_ratio;
#else
#define node_reclaim_mode 0
#endif
So, no need for an #ifdef CONFIG_NUMA inside khugepaged_scan_abort().
Hugh
Re: [PATCH net] net: phy: fix save wrong speed and duplex problem if autoneg is on
On 2021/2/27 8:53, Andrew Lunn wrote: On Fri, Feb 26, 2021 at 03:44:42PM +0800, Huazhong Tan wrote: From: Guangbin Huang If phy uses generic driver and autoneg is on, enter command "ethtool -s eth0 speed 50" will not change phy speed actually, but command "ethtool eth0" shows speed is 50Mb/s because phydev->speed has been set to 50 and no update later. And duplex setting has same problem too. However, if autoneg is on, phy only changes speed and duplex according to phydev->advertising, but not phydev->speed and phydev->duplex. So in this case, phydev->speed and phydev->duplex don't need to be set in function phy_ethtool_ksettings_set() if autoneg is on. Signed-off-by: Guangbin Huang Signed-off-by: Huazhong Tan I'm not sure, but i think this happens after commit 51e2a3846eab18711f4eb59cd0a4c33054e2980a Author: Trent Piepho Date: Wed Sep 24 10:55:46 2008 + PHY: Avoid unnecessary aneg restarts The PHY's aneg is configured and restarted whenever the link is brought up, e.g. when DHCP is started after the kernel has booted. This can take the link down for several seconds while auto-negotiation is redone. If the advertised features haven't changed, then it shouldn't be necessary to bring down the link and start auto-negotiation over again. genphy_config_advert() is enhanced to return 0 when the advertised features haven't been changed and >0 when they have been. genphy_config_aneg() then uses this information to not call genphy_restart_aneg() if there has been no change. Before then, i think autoneg was unconditionally restarted, and so the speed would get overwritten when autoneg completed. After this patch, since autoneg is not being changed when only speed is set, autoneg is not triggered. Andrew Thanks. .
Re: [PATCH net] net: phy: fix save wrong speed and duplex problem if autoneg is on
On 2021/2/27 7:56, Jakub Kicinski wrote: On Fri, 26 Feb 2021 15:44:42 +0800 Huazhong Tan wrote: From: Guangbin Huang If phy uses generic driver and autoneg is on, enter command "ethtool -s eth0 speed 50" will not change phy speed actually, but command "ethtool eth0" shows speed is 50Mb/s because phydev->speed has been set to 50 and no update later. And duplex setting has same problem too. However, if autoneg is on, phy only changes speed and duplex according to phydev->advertising, but not phydev->speed and phydev->duplex. So in this case, phydev->speed and phydev->duplex don't need to be set in function phy_ethtool_ksettings_set() if autoneg is on. Can we get a Fixes tag for this one? How far back does this behavior date? will add a fixes tag in V2, thanks. .
Re: [f2fs-dev] [PATCH v3] f2fs: compress: Allow modular (de)compression algorithms
On 2021/2/26 23:51, Geert Uytterhoeven wrote:
If F2FS_FS is modular, enabling the compressions options
F2FS_FS_{LZ4,LZ4HZ,LZO,LZORLE,ZSTD} will make the (de)compression
algorithms {LZ4,LZ4HC,LZO,ZSTD}_{,DE}COMPRESS builtin instead of
modular, as the former depend on an intermediate boolean
F2FS_FS_COMPRESSION, which in-turn depends on tristate F2FS_FS.
Indeed, if a boolean symbol A depends directly on a tristate symbol B
and selects another tristate symbol C:
tristate B
tristate C
bool A
depends on B
select C
and B is modular, then C will also be modular.
However, if there is an intermediate boolean D in the dependency chain
between A and B:
tristate B
tristate C
bool D
depends on B
bool A
depends on D
select C
then the modular state won't propagate from B to C, and C will be
builtin instead of modular.
As modular dependency propagation through intermediate symbols is
obscure, fix this in a robust way by moving the selection of tristate
(de)compression algorithms from the boolean compression options to the
tristate main F2FS_FS option.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Chao Yu
Thanks,
Re: [PATCH] RISC-V: Make NUMA depend on SMP
On 2021/2/27 4:25, Palmer Dabbelt wrote:
From: Palmer Dabbelt
In theory these are orthogonal, but in practice all NUMA systems are
SMP. NUMA && !SMP doesn't build, everyone else is coupling them, and I
don't really see any value in supporting that configuration.
Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform")
Suggested-by: Andrew Morton
Suggested-by: Atish Patra
Signed-off-by: Palmer Dabbelt
Reported-and-Tested-by: Kefeng Wang
---
This is on fixes.
---
arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a998babc1237..85d626b8ce5e 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -314,6 +314,7 @@ endchoice
# Common NUMA Features
config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
+ depends on SMP
select GENERIC_ARCH_NUMA
select OF_NUMA
select ARCH_SUPPORTS_NUMA_BALANCING
Re: [PATCH 13/13] arm64: dts: qcom: Add sc7180-lazor-coachz skus
Hi,
On Fri, Feb 26, 2021 at 10:45 AM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2021-02-25 14:13:10)
> > diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
> > b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
> > new file mode 100644
> > index ..5def9953d82b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
> > @@ -0,0 +1,249 @@
> [...]
> > +
> > +/*
> > + * There's no SAR sensor, so i2c5 is re-purposed. We leave the
> > + * proximity@28 node under i2c5 (from trogdor.dtsi) since it's "disabled"
> > + * and doesn't hurt.
> > + */
> > +i2c_wlc: {
> > + /* Currently not connected to anything; see b/168652326 */
> > +};
>
> Can we remove this? As far as I know this will always be this way and
> thus doesn't provide anything meaningful to leave this bug comment here
> that doesn't work for people.
Yeah, that sounds good. We just want to delete this whole comment and the node.
That seems like enough reason to repost the series. I'll plan to do
it early next week. Of course, I wouldn't object to any of these
things:
* This patch landing and having the node and I'll do a follow-up patch
to remove it.
* Bjorn removing the comment and node as he applies.
-Doug
Re: [PATCH v2 2/3] mm: Force update of mem cgroup soft limit tree on usage excess
On 2/26/21 12:52 AM, Michal Hocko wrote: >> >> Michal, >> >> Let's take an extreme case where memcg 1 always generate the >> first event and memcg 2 generates the rest of 128*8-1 events >> and the pattern repeat. > > I do not follow. Events are per-memcg, aren't they? > __this_cpu_read(memcg->vmstats_percpu->targets[target]); > [...] > __this_cpu_write(memcg->vmstats_percpu->targets[target], next); > You are right. My previous reasoning is incorrect as the sampling is done per memcg. I'll do some additional debugging on why memcg is not on the tree. Tim
Re: [PATCH net] net: phy: fix save wrong speed and duplex problem if autoneg is on
On Fri, Feb 26, 2021 at 03:44:42PM +0800, Huazhong Tan wrote: > From: Guangbin Huang > > If phy uses generic driver and autoneg is on, enter command > "ethtool -s eth0 speed 50" will not change phy speed actually, but > command "ethtool eth0" shows speed is 50Mb/s because phydev->speed > has been set to 50 and no update later. > > And duplex setting has same problem too. > > However, if autoneg is on, phy only changes speed and duplex according to > phydev->advertising, but not phydev->speed and phydev->duplex. So in this > case, phydev->speed and phydev->duplex don't need to be set in function > phy_ethtool_ksettings_set() if autoneg is on. > > Signed-off-by: Guangbin Huang > Signed-off-by: Huazhong Tan I'm not sure, but i think this happens after commit 51e2a3846eab18711f4eb59cd0a4c33054e2980a Author: Trent Piepho Date: Wed Sep 24 10:55:46 2008 + PHY: Avoid unnecessary aneg restarts The PHY's aneg is configured and restarted whenever the link is brought up, e.g. when DHCP is started after the kernel has booted. This can take the link down for several seconds while auto-negotiation is redone. If the advertised features haven't changed, then it shouldn't be necessary to bring down the link and start auto-negotiation over again. genphy_config_advert() is enhanced to return 0 when the advertised features haven't been changed and >0 when they have been. genphy_config_aneg() then uses this information to not call genphy_restart_aneg() if there has been no change. Before then, i think autoneg was unconditionally restarted, and so the speed would get overwritten when autoneg completed. After this patch, since autoneg is not being changed when only speed is set, autoneg is not triggered. Andrew
[PATCH 3/3] nvmem: core: nvmem_cell_read() should return the true size
If we look at the gpu speed bin currently in sc7180.dtsi:
gpu_speed_bin: gpu_speed_bin@1d2 {
reg = <0x1d2 0x2>;
bits = <5 8>;
};
We can see that this is an 8-bit value. However we had to specify the
"reg" as 16 bits because the value was spread out over two bytes.
It doesn't make sense to expose the fact that the value was spread out
over two bytes to the client. Let's use the number of bits to return
the length to the client.
NOTE: this change has the potential to break clients! Hopefully this
breakage will be lessened (or eliminated) with the previous patch
("nvmem: core: Allow nvmem_cell_read_u16/32/64 to read smaller
cells"), but it is possible for anyone directly calling
nvmem_cell_read(). From a quick audit of mainline I don't _see_ any
problems. Most cases won't change at all (number of bits matched the
length) and the big case that will change is the Qualcomm "CPR" driver
which seems to handle the length properly (it could probably be
simplified now, actually).
Signed-off-by: Douglas Anderson
---
drivers/nvmem/core.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 8602390bb124..00454d841a7f 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1379,6 +1379,7 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
void *buf, size_t *len)
{
int rc;
+ size_t bytes;
rc = nvmem_reg_read(nvmem, cell->offset, buf, cell->bytes);
@@ -1386,11 +1387,15 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
return rc;
/* shift bits in-place */
- if (cell->bit_offset || cell->nbits)
+ if (cell->bit_offset || cell->nbits) {
nvmem_shift_read_buffer_in_place(cell, buf);
+ bytes = DIV_ROUND_UP(cell->nbits, 8);
+ } else {
+ bytes = cell->bytes;
+ }
if (len)
- *len = cell->bytes;
+ *len = bytes;
return 0;
}
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH 2/3] nvmem: core: Allow nvmem_cell_read_u16/32/64 to read smaller cells
The current way that cell "length" is specified for nvmem cells is a
little fuzzy. For instance, let's look at the gpu speed bin currently
in sc7180.dtsi:
gpu_speed_bin: gpu_speed_bin@1d2 {
reg = <0x1d2 0x2>;
bits = <5 8>;
};
This is an 8-bit value (as specified by the "bits" field). However,
it has a "length" of 2 (bytes), presumably because the value spans
across two bytes.
When querying this value right now, it's hard for a client to know if
they should be calling nvmem_cell_read_u16() or nvmem_cell_read_u8().
Today they must call nvmem_cell_read_u16() because the "length" of the
cell was 2 (bytes). However, if a later SoC ever came around and
didn't span across 2 bytes it would be unclear. If a later Soc
specified, for instance:
gpu_speed_bin: gpu_speed_bin@100 {
reg = <0x100 0x1>;
bits = <0 8>;
};
...then the caller would need to change to try calling
nvmem_cell_read_u8() because the u16 version would fail.
Let's solve this by allowing clients to read a "larger" value. We'll
just fill it in with 0. If a client truly wants to know exactly how
big the cell was they can fall back to calling nvmem_cell_read()
directly.
NOTE: current implementation assumes that cells are little endian when
up-casting the size, but that's already pretty implicit in the way
nvmem works now anyway. See nvmem_shift_read_buffer_in_place(). Let's
document this but not do any auto-conversions just in case there was
an instance where someone was using this API to read big endian data
on a big endian machine and it happened to be working because there
was no bit offset.
Signed-off-by: Douglas Anderson
---
I will freely admit that I always end up thinking in circles and
getting dizzy when I think too much about endian considerations. If
anyone has better intuition than I do and see that I've goofed this up
then please yell.
drivers/nvmem/core.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index a5ab1e0c74cf..8602390bb124 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1534,12 +1534,14 @@ static int nvmem_cell_read_common(struct device *dev,
const char *cell_id,
nvmem_cell_put(cell);
return PTR_ERR(buf);
}
- if (len != count) {
+ if (len > count) {
kfree(buf);
nvmem_cell_put(cell);
return -EINVAL;
+ } else if (len != count) {
+ memset(val + len, 0, count - len);
}
- memcpy(val, buf, count);
+ memcpy(val, buf, len);
kfree(buf);
nvmem_cell_put(cell);
@@ -1564,6 +1566,11 @@ EXPORT_SYMBOL_GPL(nvmem_cell_read_u8);
/**
* nvmem_cell_read_u16() - Read a cell value as a u16
*
+ * This function can be used to read any cell value 16-bits or less. If
+ * this function needs to upcast (or if the cell was stored in nvmem with
+ * a bit offset) it will assume that the cell is little endian. Clients
+ * should generally call le16_to_cpu() on the returned value.
+ *
* @dev: Device that requests the nvmem cell.
* @cell_id: Name of nvmem cell to read.
* @val: pointer to output value.
@@ -1579,6 +1586,11 @@ EXPORT_SYMBOL_GPL(nvmem_cell_read_u16);
/**
* nvmem_cell_read_u32() - Read a cell value as a u32
*
+ * This function can be used to read any cell value 32-bits or less. If
+ * this function needs to upcast (or if the cell was stored in nvmem with
+ * a bit offset) it will assume that the cell is little endian. Clients
+ * should generally call le32_to_cpu() on the returned value.
+ *
* @dev: Device that requests the nvmem cell.
* @cell_id: Name of nvmem cell to read.
* @val: pointer to output value.
@@ -1594,6 +1606,11 @@ EXPORT_SYMBOL_GPL(nvmem_cell_read_u32);
/**
* nvmem_cell_read_u64() - Read a cell value as a u64
*
+ * This function can be used to read any cell value 64-bits or less. If
+ * this function needs to upcast (or if the cell was stored in nvmem with
+ * a bit offset) it will assume that the cell is little endian. Clients
+ * should generally call le64_to_cpu() on the returned value.
+ *
* @dev: Device that requests the nvmem cell.
* @cell_id: Name of nvmem cell to read.
* @val: pointer to output value.
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH 1/3] drm/msm: Fix speed-bin support not to access outside valid memory
When running the latest kernel on an sc7180 with KASAN I got this
splat:
BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644
Read of size 4 at addr ff8088f36100 by task kworker/7:1/58
CPU: 7 PID: 58 Comm: kworker/7:1 Not tainted 5.11.0+ #3
Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
Workqueue: events deferred_probe_work_func
Call trace:
dump_backtrace+0x0/0x3a8
show_stack+0x24/0x30
dump_stack+0x174/0x1e0
print_address_description+0x70/0x2e4
kasan_report+0x178/0x1bc
__asan_report_load4_noabort+0x44/0x50
a6xx_gpu_init+0x618/0x644
adreno_bind+0x26c/0x438
This is because the speed bin is defined like this:
gpu_speed_bin: gpu_speed_bin@1d2 {
reg = <0x1d2 0x2>;
bits = <5 8>;
};
As you can see the "length" is 2 bytes. That means that the nvmem
subsystem allocates only 2 bytes. The GPU code, however, was casting
the pointer allocated by nvmem to a (u32 *) and dereferencing. That's
not so good.
Let's fix this to just use the nvmem_cell_read_u16() accessor function
which simplifies things and also gets rid of the splat.
Let's also put an explicit conversion from little endian in place just
to make things clear. The nvmem subsystem today is assuming little
endian and this makes it clear. Specifically, the way the above sc7180
cell is interpreted:
NVMEM:
++++++
| .. | 0x1d3 | 0x1d2 | .. | 0x000 |
++++++
^ ^
msb lsb
You can see that the least significant data is at the lower address
which is little endian.
NOTE: someone who is truly paying attention might wonder about me
picking the "u16" version of this accessor instead of the "u8" (since
the value is 8 bits big) or the u32 version (just for fun). At the
moment you need to pick the accessor that exactly matches the length
the cell was specified as in the device tree. Hopefully future
patches to the nvmem subsystem will fix this.
Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
1 file changed, 8 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ba8e9d3cf0fe..0e2024defd79 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1350,35 +1350,20 @@ static int a6xx_set_supported_hw(struct device *dev,
struct a6xx_gpu *a6xx_gpu,
u32 revn)
{
struct opp_table *opp_table;
- struct nvmem_cell *cell;
u32 supp_hw = UINT_MAX;
- void *buf;
-
- cell = nvmem_cell_get(dev, "speed_bin");
- /*
-* -ENOENT means that the platform doesn't support speedbin which is
-* fine
-*/
- if (PTR_ERR(cell) == -ENOENT)
- return 0;
- else if (IS_ERR(cell)) {
- DRM_DEV_ERROR(dev,
- "failed to read speed-bin. Some OPPs may not be
supported by hardware");
- goto done;
- }
+ u16 speedbin;
+ int ret;
- buf = nvmem_cell_read(cell, NULL);
- if (IS_ERR(buf)) {
- nvmem_cell_put(cell);
+ ret = nvmem_cell_read_u16(dev, "speed_bin", );
+ if (ret) {
DRM_DEV_ERROR(dev,
- "failed to read speed-bin. Some OPPs may not be
supported by hardware");
+ "failed to read speed-bin (%d). Some OPPs may not
be supported by hardware",
+ ret);
goto done;
}
+ speedbin = le16_to_cpu(speedbin);
- supp_hw = fuse_to_supp_hw(dev, revn, *((u32 *) buf));
-
- kfree(buf);
- nvmem_cell_put(cell);
+ supp_hw = fuse_to_supp_hw(dev, revn, speedbin);
done:
opp_table = dev_pm_opp_set_supported_hw(dev, _hw, 1);
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH 0/3] nvmem: Bring a tiny bit of sanity to reading 16/32/64 bits from nvmem
This series was inspried by a KASAN warning that I got at bootup caused by the GPU driver on my system interfacing with the nvmem API incorrectly. I have posted a fix for the GPU driver but looking at this nvmem entry made me question how the nvmem API was supposed to work. I've proposed some improvements and these seem better (to me) than any of: - Open coding logic like that in "cpr.c" in the GPU driver. - Ignoring the problem and just forcing everyone in the future to always specify a length of "2" for the GPU speed bin cells. - Ignoring the problem and specifying a length of "4" for the GPU speed bin cells. About applying the patches. - GPU patch can land on its own. No need for the nvmem patches. - nvmem patches can land on their own too. - If the second nvmem patch lands without the first, however, it will break the GPU patch. Douglas Anderson (3): drm/msm: Fix speed-bin support not to access outside valid memory nvmem: core: Allow nvmem_cell_read_u16/32/64 to read smaller cells nvmem: core: nvmem_cell_read() should return the true size drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++ drivers/nvmem/core.c | 30 ++ 2 files changed, 34 insertions(+), 27 deletions(-) -- 2.30.1.766.gb4fecdf3b7-goog
Re: [PATCH v2] media: add a subsystem profile documentation
Hi Mauro- On 2/25/21 5:41 AM, Mauro Carvalho Chehab wrote: > Document the basic policies of the media subsystem profile. > > Signed-off-by: Mauro Carvalho Chehab > --- > > v2: fix the Documentation/*/media directories > > > Documentation/driver-api/media/index.rst | 2 + > .../media/maintainer-entry-profile.rst| 161 ++ > .../maintainer/maintainer-entry-profile.rst | 1 + > 3 files changed, 164 insertions(+) > create mode 100644 > Documentation/driver-api/media/maintainer-entry-profile.rst > > diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst > b/Documentation/driver-api/media/maintainer-entry-profile.rst > new file mode 100644 > index ..6318be833bfb > --- /dev/null > +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst > @@ -0,0 +1,161 @@ > +Media Subsystem Profile > +=== > + > +Overview > + > + > +The media subsystem covers support for a variety of devices: stream > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC > +and media pipeline control. > + > +It covers, mainly, the contents of those directories: > + > + - drivers/media > + - drivers/staging/media > + - Documentation/admin-guide/media > + - Documentation/driver-api/media > + - Documentation/userspace-api/media > + - include/media > + > +Both media userspace and Kernel APIs are documented and should be kept in > +sync with the API changes. It means that all patches that add new > +features to the subsystem should also bring changes to the corresponding > +API files. > + > +Due to the size and wide scope of the media subsystem, media's > +maintainership model is to have sub-maintainers that have a broad > +knowledge of a specific aspect of the subsystem. It is the sub-maintainers' > +task to review the patches, providing feedback to users if the patches are > +following the subsystem rules and are properly using the media kernel and > +userspace APIs. > + > +Patches for the media subsystem should be sent to the media mailing list > +at linux-me...@vger.kernel.org as plain text only e-mail. Emails with > +HTML will be automatically rejected by the mail server. It could be wise > +to also copy the sub-maintainer(s). > + > +Media's workflow is heavily based on Patchwork, meaning that, once a patch > +is submitted, it should appear at: > + > + - https://patchwork.linuxtv.org/project/linux-media/list/ > + > +If it doesn't automatically appear there after a few minutes, then > +probably something got wrong on your submission. Please check if the > +email is in plain text only and if your emailer is not mangling with > +whitespaces before complaining or submitting them again. > + > +Sub-maintainers > > + > +At the media subsystem, we have a group of experienced developers that > +are responsible for doing the code reviews at the drivers (called > +sub-maintainers), and another senior developer responsible for the > +subsystem as a hole. For core changes, whenever possible, multiple > +media (sub-)maintainers do the review. > + > +The sub-maintainers work on specific areas of the subsystem, as > +described below: > + > +Digital TV: > + Sean Young > + > +HDMI CEC: > + Hans Verkuil > + > +Media controller drivers: > + Laurent Pinchart > + > +Remote Controllers: > + Sean Young > + > +Sensor drivers: > + Sakari Ailus > + > +V4L2 drivers: > + Hans Verkuil > + > +Submit Checklist Addendum > +- > + > +Patches that change the Open Firmware/Device Tree bindings should be > +reviewed by the Device Tree maintainers. So, DT maintainers should be > +c/c when those are submitted. Cc:ed > + > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ > +that should be used in order to check if the drivers are properly > +implementing the media APIs. > + > +Those tests need to pass before the patches go upstream. > + > +Also, please notice that we build the Kernel with:: > + > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 > CHECK=check_script > + > +Where the check script is:: > + > + #!/bin/bash > + /devel/smatch/smatch -p=kernel $@ >&2 > + /devel/sparse/sparse $@ >&2 > + > +Be sure to not introduce new warnings on your patches without a > +very good reason. > + > +Style Cleanup Patches > ++ > + > +Style-cleanups are welcome when they come together with other changes Style cleanups > +at the files where the style changes will affect. > + > +We may accept pure standalone style-cleanups, but they should ideally style cleanups, > +be one patch for the hole subsystem (if the cleanup is low volume), whole (or entire) > +or at least be grouped per directory. So, for example, if you're doing doing a > +big cleanup change set at drivers under drivers/media,
Re: [PATCH v8 20/22] counter: Implement events_queue_size sysfs attribute
On Fri, Feb 26, 2021 at 06:14:12PM -0600, David Lechner wrote:
> On 2/25/21 6:03 PM, William Breathitt Gray wrote:
> > On Sun, Feb 21, 2021 at 03:51:40PM +, Jonathan Cameron wrote:
> >> On Thu, 18 Feb 2021 19:32:16 +0900
> >> William Breathitt Gray wrote:
> >>
> >>> On Sun, Feb 14, 2021 at 06:11:46PM +, Jonathan Cameron wrote:
> On Fri, 12 Feb 2021 21:13:44 +0900
> William Breathitt Gray wrote:
>
> > The events_queue_size sysfs attribute provides a way for users to
> > dynamically configure the Counter events queue size for the Counter
> > character device interface. The size is in number of struct
> > counter_event data structures. The number of elements will be rounded-up
> > to a power of 2 due to a requirement of the kfifo_alloc function called
> > during reallocation of the queue.
> >
> > Cc: Oleksij Rempel
> > Signed-off-by: William Breathitt Gray
> > ---
> > Documentation/ABI/testing/sysfs-bus-counter | 8 +++
> > drivers/counter/counter-chrdev.c| 23 +++
> > drivers/counter/counter-chrdev.h| 2 ++
> > drivers/counter/counter-sysfs.c | 25 +
> > 4 files changed, 58 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-counter
> > b/Documentation/ABI/testing/sysfs-bus-counter
> > index 847e96f19d19..f6cb2a8b08a7 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-counter
> > +++ b/Documentation/ABI/testing/sysfs-bus-counter
> > @@ -212,6 +212,14 @@ Description:
> > both edges:
> > Any state transition.
> >
> > +What: /sys/bus/counter/devices/counterX/events_queue_size
> > +KernelVersion: 5.13
> > +Contact: linux-...@vger.kernel.org
> > +Description:
> > + Size of the Counter events queue in number of struct
> > + counter_event data structures. The number of elements
> > will be
> > + rounded-up to a power of 2.
> > +
> > What: /sys/bus/counter/devices/counterX/name
> > KernelVersion:5.2
> > Contact: linux-...@vger.kernel.org
> > diff --git a/drivers/counter/counter-chrdev.c
> > b/drivers/counter/counter-chrdev.c
> > index 16f02df7f73d..53eea894e13f 100644
> > --- a/drivers/counter/counter-chrdev.c
> > +++ b/drivers/counter/counter-chrdev.c
> > @@ -375,6 +375,29 @@ void counter_chrdev_remove(struct counter_device
> > *const counter)
> > cdev_del(>chrdev);
> > }
> >
> > +int counter_chrdev_realloc_queue(struct counter_device *const counter,
> > +size_t queue_size)
> > +{
> > + int err;
> > + DECLARE_KFIFO_PTR(events, struct counter_event);
> > + unsigned long flags;
> > +
> > + /* Allocate new events queue */
> > + err = kfifo_alloc(, queue_size, GFP_ATOMIC);
>
> Is there any potential for losing events?
> >>>
> >>> We take the events_list_lock down below so we're safe against missing an
> >>> event, but past events currently unread in the queue will be lost.
> >>>
> >>> Shortening the size of the queue is inherently a destructive process if
> >>> we have more events in the current queue than can fit in the new queue.
> >>> Because we a liable to lose some events in such a case, I think it's
> >>> best to keep the behavior of this reallocation consistent and have it
> >>> provide a fresh empty queue every time, as opposed to sometimes dropping
> >>> events and sometimes not.
> >>>
> >>> I also suspect an actual user would be setting the size of their queue
> >>> to the required amount before they begin watching events, rather than
> >>> adjusting it sporadically during a live operation.
> >>>
> >>
> >> Absolutely agree. As such I wonder if you are better off enforcing this
> >> behaviour? If the cdev is open for reading, don't allow the fifo to be
> >> resized.
> >>
> >> Jonathan
> >
> > I can't really think of a good reason not to, so let's enforce it: if
> > the cdev is open, then we'll return an EINVAL if the user attempts to
> > resize the queue.
> >
> > What is a good way to check for this condition? Should I just call
> > kref_read() and see if it's greater than 1? For example, in
> > counter_chrdev_realloc_queue():
> >
> > if (kref_read(>dev.kobj.kref) > 1)
> > return -EINVAL;
> >
> > William Breathitt Gray
> >
>
> Wouldn't EBUSY make more sense?
Yes, EBUSY would be better here because the operation isn't necessarily
invalid, just unavailable because someone else has the cdev open.
William Breathitt Gray
signature.asc
Description: PGP signature
[PATCH] ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits
From: Colin Ian King
Currently the mask operation on variable conf is just 3 bits so
the switch statement case value of 8 is unreachable dead code.
The function daio_mgr_dao_init can be passed a 4 bit value,
function dao_rsc_init calls it with conf set to:
conf = (desc->msr & 0x7) | (desc->passthru << 3);
so clearly when desc->passthru is set to 1 then conf can be
at least 8.
Fix this by changing the mask to 0xf.
Fixes: 8cc72361481f ("ALSA: SB X-Fi driver merge")
Signed-off-by: Colin Ian King
---
sound/pci/ctxfi/cthw20k2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/ctxfi/cthw20k2.c b/sound/pci/ctxfi/cthw20k2.c
index a855fb8c58bd..55af8ef29838 100644
--- a/sound/pci/ctxfi/cthw20k2.c
+++ b/sound/pci/ctxfi/cthw20k2.c
@@ -991,7 +991,7 @@ static int daio_mgr_dao_init(void *blk, unsigned int idx,
unsigned int conf)
if (idx < 4) {
/* S/PDIF output */
- switch ((conf & 0x7)) {
+ switch ((conf & 0xf)) {
case 1:
set_field(>txctl[idx], ATXCTL_NUC, 0);
break;
--
2.30.0
Re: [PATCH v8 20/22] counter: Implement events_queue_size sysfs attribute
On 2/25/21 6:03 PM, William Breathitt Gray wrote:
On Sun, Feb 21, 2021 at 03:51:40PM +, Jonathan Cameron wrote:
On Thu, 18 Feb 2021 19:32:16 +0900
William Breathitt Gray wrote:
On Sun, Feb 14, 2021 at 06:11:46PM +, Jonathan Cameron wrote:
On Fri, 12 Feb 2021 21:13:44 +0900
William Breathitt Gray wrote:
The events_queue_size sysfs attribute provides a way for users to
dynamically configure the Counter events queue size for the Counter
character device interface. The size is in number of struct
counter_event data structures. The number of elements will be rounded-up
to a power of 2 due to a requirement of the kfifo_alloc function called
during reallocation of the queue.
Cc: Oleksij Rempel
Signed-off-by: William Breathitt Gray
---
Documentation/ABI/testing/sysfs-bus-counter | 8 +++
drivers/counter/counter-chrdev.c| 23 +++
drivers/counter/counter-chrdev.h| 2 ++
drivers/counter/counter-sysfs.c | 25 +
4 files changed, 58 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-counter
b/Documentation/ABI/testing/sysfs-bus-counter
index 847e96f19d19..f6cb2a8b08a7 100644
--- a/Documentation/ABI/testing/sysfs-bus-counter
+++ b/Documentation/ABI/testing/sysfs-bus-counter
@@ -212,6 +212,14 @@ Description:
both edges:
Any state transition.
+What: /sys/bus/counter/devices/counterX/events_queue_size
+KernelVersion: 5.13
+Contact: linux-...@vger.kernel.org
+Description:
+ Size of the Counter events queue in number of struct
+ counter_event data structures. The number of elements will be
+ rounded-up to a power of 2.
+
What: /sys/bus/counter/devices/counterX/name
KernelVersion:5.2
Contact: linux-...@vger.kernel.org
diff --git a/drivers/counter/counter-chrdev.c b/drivers/counter/counter-chrdev.c
index 16f02df7f73d..53eea894e13f 100644
--- a/drivers/counter/counter-chrdev.c
+++ b/drivers/counter/counter-chrdev.c
@@ -375,6 +375,29 @@ void counter_chrdev_remove(struct counter_device *const
counter)
cdev_del(>chrdev);
}
+int counter_chrdev_realloc_queue(struct counter_device *const counter,
+size_t queue_size)
+{
+ int err;
+ DECLARE_KFIFO_PTR(events, struct counter_event);
+ unsigned long flags;
+
+ /* Allocate new events queue */
+ err = kfifo_alloc(, queue_size, GFP_ATOMIC);
Is there any potential for losing events?
We take the events_list_lock down below so we're safe against missing an
event, but past events currently unread in the queue will be lost.
Shortening the size of the queue is inherently a destructive process if
we have more events in the current queue than can fit in the new queue.
Because we a liable to lose some events in such a case, I think it's
best to keep the behavior of this reallocation consistent and have it
provide a fresh empty queue every time, as opposed to sometimes dropping
events and sometimes not.
I also suspect an actual user would be setting the size of their queue
to the required amount before they begin watching events, rather than
adjusting it sporadically during a live operation.
Absolutely agree. As such I wonder if you are better off enforcing this
behaviour? If the cdev is open for reading, don't allow the fifo to be
resized.
Jonathan
I can't really think of a good reason not to, so let's enforce it: if
the cdev is open, then we'll return an EINVAL if the user attempts to
resize the queue.
What is a good way to check for this condition? Should I just call
kref_read() and see if it's greater than 1? For example, in
counter_chrdev_realloc_queue():
if (kref_read(>dev.kobj.kref) > 1)
return -EINVAL;
William Breathitt Gray
Wouldn't EBUSY make more sense?
[PATCH v3 1/3] lockdep: add lockdep_assert_not_held()
Some kernel functions must be called without holding a specific lock.
Add lockdep_assert_not_held() to be used in these functions to detect
incorrect calls while holding a lock.
lockdep_assert_not_held() provides the opposite functionality of
lockdep_assert_held() which is used to assert calls that require
holding a specific lock.
Incorporates suggestions from Peter Zijlstra to avoid misfires when
lockdep_off() is employed.
The need for lockdep_assert_not_held() came up in a discussion on
ath10k patch. ath10k_drain_tx() and i915_vma_pin_ww() are examples
of functions that can use lockdep_assert_not_held().
Link:
https://lore.kernel.org/lkml/37a29c383bff2fb1605241ee6c7c9be3784fb3c6.1613171185.git.sk...@linuxfoundation.org/
Link: https://lore.kernel.org/linux-wireless/871rdmu9z9@codeaurora.org/
Signed-off-by: Shuah Khan
---
include/linux/lockdep.h | 11 ---
kernel/locking/lockdep.c | 6 +-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 7b7ebf2e28ec..dbd9ea846b36 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -301,8 +301,12 @@ extern void lock_unpin_lock(struct lockdep_map *lock,
struct pin_cookie);
#define lockdep_depth(tsk) (debug_locks ? (tsk)->lockdep_depth : 0)
-#define lockdep_assert_held(l) do {\
- WARN_ON(debug_locks && !lockdep_is_held(l));\
+#define lockdep_assert_held(l) do {\
+ WARN_ON(debug_locks && lockdep_is_held(l) == 0);\
+ } while (0)
+
+#define lockdep_assert_not_held(l) do {\
+ WARN_ON(debug_locks && lockdep_is_held(l) == 1);\
} while (0)
#define lockdep_assert_held_write(l) do {\
@@ -393,7 +397,8 @@ extern int lockdep_is_held(const void *);
#define lockdep_is_held_type(l, r) (1)
#define lockdep_assert_held(l) do { (void)(l); } while (0)
-#define lockdep_assert_held_write(l) do { (void)(l); } while (0)
+#define lockdep_assert_not_held(l) do { (void)(l); } while (0)
+#define lockdep_assert_held_write(l) do { (void)(l); } while (0)
#define lockdep_assert_held_read(l)do { (void)(l); } while (0)
#define lockdep_assert_held_once(l)do { (void)(l); } while (0)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c6d0c1dc6253..818d0ceed3eb 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -5539,8 +5539,12 @@ noinstr int lock_is_held_type(const struct lockdep_map
*lock, int read)
unsigned long flags;
int ret = 0;
+ /*
+* avoid false negative lockdep_assert_held() and
+* lockdep_assert_not_held()
+*/
if (unlikely(!lockdep_enabled()))
- return 1; /* avoid false negative lockdep_assert_held() */
+ return -1;
raw_local_irq_save(flags);
check_flags(flags);
--
2.27.0
[PATCH v3 3/3] ath10k: detect conf_mutex held ath10k_drain_tx() calls
ath10k_drain_tx() must not be called with conf_mutex held as workers can
use that also. Add call to lockdep_assert_not_held() on conf_mutex to
detect if conf_mutex is held by the caller.
The idea for this patch stemmed from coming across the comment block
above the ath10k_drain_tx() while reviewing the conf_mutex holds during
to debug the conf_mutex lock assert in ath10k_debug_fw_stats_request().
Adding detection to assert on conf_mutex hold will help detect incorrect
usages that could lead to locking problems when async worker routines try
to call this routine.
Link:
https://lore.kernel.org/lkml/37a29c383bff2fb1605241ee6c7c9be3784fb3c6.1613171185.git.sk...@linuxfoundation.org/
Link: https://lore.kernel.org/linux-wireless/871rdmu9z9@codeaurora.org/
Acked-by: Kalle Valo
Signed-off-by: Shuah Khan
---
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index bb6c5ee43ac0..5ce4f8d038b9 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4727,6 +4727,8 @@ static void ath10k_mac_op_wake_tx_queue(struct
ieee80211_hw *hw,
/* Must not be called with conf_mutex held as workers can use that also. */
void ath10k_drain_tx(struct ath10k *ar)
{
+ lockdep_assert_not_held(>conf_mutex);
+
/* make sure rcu-protected mac80211 tx path itself is drained */
synchronize_net();
--
2.27.0
[PATCH v3 2/3] lockdep: add lockdep lock state defines
Adds defines for lock state returns from lock_is_held_type() based on
Johannes Berg's suggestions as it make it easier to read and maintain
the lock states. These are defines and a enum to avoid changes to
lock_is_held_type() and lockdep_is_held() return types.
Updates to lock_is_held_type() and __lock_is_held() to use the new
defines.
Link:
https://lore.kernel.org/lkml/37a29c383bff2fb1605241ee6c7c9be3784fb3c6.1613171185.git.sk...@linuxfoundation.org/
Link: https://lore.kernel.org/linux-wireless/871rdmu9z9@codeaurora.org/
Signed-off-by: Shuah Khan
---
include/linux/lockdep.h | 11 +--
kernel/locking/lockdep.c | 11 ++-
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index dbd9ea846b36..17805aac0e85 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -268,6 +268,11 @@ extern void lock_acquire(struct lockdep_map *lock,
unsigned int subclass,
extern void lock_release(struct lockdep_map *lock, unsigned long ip);
+/* lock_is_held_type() returns */
+#define LOCK_STATE_UNKNOWN -1
+#define LOCK_STATE_NOT_HELD0
+#define LOCK_STATE_HELD1
+
/*
* Same "read" as for lock_acquire(), except -1 means any.
*/
@@ -302,11 +307,13 @@ extern void lock_unpin_lock(struct lockdep_map *lock,
struct pin_cookie);
#define lockdep_depth(tsk) (debug_locks ? (tsk)->lockdep_depth : 0)
#define lockdep_assert_held(l) do {\
- WARN_ON(debug_locks && lockdep_is_held(l) == 0);\
+ WARN_ON(debug_locks && \
+ lockdep_is_held(l) == LOCK_STATE_NOT_HELD); \
} while (0)
#define lockdep_assert_not_held(l) do {\
- WARN_ON(debug_locks && lockdep_is_held(l) == 1);\
+ WARN_ON(debug_locks && \
+ lockdep_is_held(l) == LOCK_STATE_HELD); \
} while (0)
#define lockdep_assert_held_write(l) do {\
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 818d0ceed3eb..f5a8200f24f1 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include
@@ -5252,13 +5253,13 @@ int __lock_is_held(const struct lockdep_map *lock, int
read)
if (match_held_lock(hlock, lock)) {
if (read == -1 || hlock->read == read)
- return 1;
+ return LOCK_STATE_HELD;
- return 0;
+ return LOCK_STATE_NOT_HELD;
}
}
- return 0;
+ return LOCK_STATE_NOT_HELD;
}
static struct pin_cookie __lock_pin_lock(struct lockdep_map *lock)
@@ -5537,14 +5538,14 @@ EXPORT_SYMBOL_GPL(lock_release);
noinstr int lock_is_held_type(const struct lockdep_map *lock, int read)
{
unsigned long flags;
- int ret = 0;
+ int ret = LOCK_STATE_NOT_HELD;
/*
* avoid false negative lockdep_assert_held() and
* lockdep_assert_not_held()
*/
if (unlikely(!lockdep_enabled()))
- return -1;
+ return LOCK_STATE_UNKNOWN;
raw_local_irq_save(flags);
check_flags(flags);
--
2.27.0
[PATCH v3 0/3] Add lockdep_assert_not_held()
Some kernel functions must not be called holding a specific lock. Doing so could lead to locking problems. Currently these routines call lock_is_held() to check for lock hold followed by WARN_ON. Adding a common lockdep interface will help reduce the duplication of this logic in the rest of the kernel. Add lockdep_assert_not_held() to be used in these functions to detect incorrect calls while holding a lock. lockdep_assert_not_held() provides the opposite functionality of lockdep_assert_held() which is used to assert calls that require holding a specific lock. The need for lockdep_assert_not_held() came up in a discussion on ath10k patch. ath10k_drain_tx() and i915_vma_pin_ww() are examples of functions that can use lockdep_assert_not_held(). Link: https://lore.kernel.org/lkml/37a29c383bff2fb1605241ee6c7c9be3784fb3c6.1613171185.git.sk...@linuxfoundation.org/ Link: https://lore.kernel.org/linux-wireless/871rdmu9z9@codeaurora.org/ This patch series adds lockdep_assert_not_held() and uses it in the second patch in ath10k_drain_tx() function. Changes since v2: -- Fixed coding style issues -- Patch 2 uses new lock states in __lock_is_held() and lock_is_held_type Patch 1 incorporates suggestions from Peter Zijlstra on v1 series to avoid misfires when lockdep_off() is employed. Patch 2 Johannes Berg's suggestions as it make it easier to read and maintain the lock states. These are defines and a enum to avoid changes to lock_is_held_type() and lockdep_is_held() return types. Patch 2 is a separate patch because it adds defines to lockdep.h and kernel/locking/lockdep.c now includes lockdep.h - decided make this a separate patch just in case issues related to header dependencies pop up. I can combine Patches 1&2 if that is preferred. Patch 3 uses the new interface in ath10k_drain_tx() function. Added Kalle Valo's Ack from v1 for this change. Tested on the mainline from yesterday. Shuah Khan (3): lockdep: add lockdep_assert_not_held() lockdep: add lockdep lock state defines ath10k: detect conf_mutex held ath10k_drain_tx() calls drivers/net/wireless/ath/ath10k/mac.c | 2 ++ include/linux/lockdep.h | 18 +++--- kernel/locking/lockdep.c | 15 ++- 3 files changed, 27 insertions(+), 8 deletions(-) -- 2.27.0
Re: possible deadlock in sk_clone_lock
On Fri, Feb 26, 2021 at 3:14 PM Mike Kravetz wrote:
>
> Cc: Michal
>
> On 2/26/21 2:44 PM, Shakeel Butt wrote:
> > On Fri, Feb 26, 2021 at 2:09 PM syzbot
> > wrote:
>
> >> other info that might help us debug this:
> >>
> >> Possible interrupt unsafe locking scenario:
> >>
> >>CPU0CPU1
> >>
> >> lock(hugetlb_lock);
> >>local_irq_disable();
> >>lock(slock-AF_INET);
> >>lock(hugetlb_lock);
> >>
> >> lock(slock-AF_INET);
> >>
> >> *** DEADLOCK ***
> >
> > This has been reproduced on 4.19 stable kernel as well [1] and there
> > is a reproducer as well.
> >
> > It seems like sendmsg(MSG_ZEROCOPY) from a buffer backed by hugetlb. I
> > wonder if we just need to make hugetlb_lock softirq-safe.
> >
> > [1] https://syzkaller.appspot.com/bug?extid=6383ce4b0b8ec575ad93
>
> Thanks Shakeel,
>
> Commit c77c0a8ac4c5 ("mm/hugetlb: defer freeing of huge pages if in non-task
> context") attempted to address this issue. It uses a work queue to
> acquire hugetlb_lock if the caller is !in_task().
>
> In another recent thread, there was the suggestion to change the
> !in_task to in_atomic.
>
> I need to do some research on the subtle differences between in_task,
> in_atomic, etc. TBH, I 'thought' !in_task would prevent the issue
> reported here. But, that obviously is not the case.
I think the freeing is happening in the process context in this report
but it is creating the lock chain from softirq-safe slock to
irq-unsafe hugetlb_lock. So, two solutions I can think of are: (1)
always defer the freeing of hugetlb pages to a work queue or (2) make
hugetlb_lock softirq-safe.
[PATCH] scsi: vmw_pvscsi: Update maintainer
The entries in the source files are removed as well. Signed-off-by: Vishal Bhakta --- MAINTAINERS | 2 +- drivers/scsi/vmw_pvscsi.c | 2 -- drivers/scsi/vmw_pvscsi.h | 2 -- 3 files changed, 1 insertion(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 97c8f2bb8de2..eb9480220e1d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18999,7 +18999,7 @@ S: Maintained F: drivers/infiniband/hw/vmw_pvrdma/ VMware PVSCSI driver -M: Jim Gill +M: Vishal Bhakta M: VMware PV-Drivers L: linux-s...@vger.kernel.org S: Maintained diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c index 081f54ab7d86..8a79605d9652 100644 --- a/drivers/scsi/vmw_pvscsi.c +++ b/drivers/scsi/vmw_pvscsi.c @@ -17,8 +17,6 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * - * Maintained by: Jim Gill - * */ #include diff --git a/drivers/scsi/vmw_pvscsi.h b/drivers/scsi/vmw_pvscsi.h index 75966d3f326e..51a82f7803d3 100644 --- a/drivers/scsi/vmw_pvscsi.h +++ b/drivers/scsi/vmw_pvscsi.h @@ -17,8 +17,6 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * - * Maintained by: Jim Gill - * */ #ifndef _VMW_PVSCSI_H_ -- 2.25.1
Re: [PATCH net] net: phy: fix save wrong speed and duplex problem if autoneg is on
On Fri, 26 Feb 2021 15:44:42 +0800 Huazhong Tan wrote: > From: Guangbin Huang > > If phy uses generic driver and autoneg is on, enter command > "ethtool -s eth0 speed 50" will not change phy speed actually, but > command "ethtool eth0" shows speed is 50Mb/s because phydev->speed > has been set to 50 and no update later. > > And duplex setting has same problem too. > > However, if autoneg is on, phy only changes speed and duplex according to > phydev->advertising, but not phydev->speed and phydev->duplex. So in this > case, phydev->speed and phydev->duplex don't need to be set in function > phy_ethtool_ksettings_set() if autoneg is on. Can we get a Fixes tag for this one? How far back does this behavior date?
Re: [PATCH v2 0/3] Add some perf support for mips
Em Fri, Feb 26, 2021 at 09:11:17AM +0800, Tiezhu Yang escreveu:
> On 02/25/2021 09:12 PM, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Feb 25, 2021 at 10:10:12AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Feb 25, 2021 at 09:49:56AM -0300, Arnaldo Carvalho de Melo
> > > escreveu:
> > > > Em Wed, Feb 24, 2021 at 10:16:55AM -0300, Arnaldo Carvalho de Melo
> > > > escreveu:
> > > > > Em Mon, Feb 22, 2021 at 02:43:39PM +0800, Tiezhu Yang escreveu:
> > > > > > On 02/04/2021 11:35 AM, Tiezhu Yang wrote:
> > > > > > > v2: add R26 and R27 to the enum perf_event_mips_regs in patch #1
> > > > > > >
> > > > > > > Tiezhu Yang (3):
> > > > > > > MIPS: kernel: Support extracting off-line stack traces from
> > > > > > > user-space
> > > > > > > with perf
> > > > > > > perf tools: Support mips unwinding and dwarf-regs
> > > > > > > perf tools: Generate mips syscalls_n64.c syscall table
> > > > > > Hi Arnaldo,
> > > > > >
> > > > > > The kernel part patch #1 has been merged.
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1ddc96bd42da
> > > > > >
> > > > > > Could the perf tool patches #2 and #3 have a chance to be merged
> > > > > > before
> > > > > > 5.12-rc1?
> > > > > > If yes, we can use this feature in 5.12-rc1.
> > > > > Thanks, applied, should make it into 5.12-rc1.
> > > > First we'll have to fix this problem:
> > > >
> > > >2812.45 debian:experimental-x-mips64 : FAIL gcc version 10.2.1
> > > > 20201224 (Debian 10.2.1-3)
> > > > from builtin-diff.c:12:
> > > > /git/linux/tools/perf/arch/mips/include/perf_regs.h:7:10: fatal
> > > > error: asm/perf_regs.h: No such file or directory
> > > > 7 | #include
> > > >| ^
> > > > compilation terminated.
> > > > In file included from util/perf_regs.h:30,
> > > > from util/event.h:15,
> > > > from util/branch.h:15,
> > > > from util/callchain.h:8,
> > > > from builtin-record.c:16:
> > > > /git/linux/tools/perf/arch/mips/include/perf_regs.h:7:10: fatal
> > > > error: asm/perf_regs.h: No such file or directory
>
> Sorry for the late reply. I asked for a leave yesterday.
>
> asm/perf_regs.h is a new added file in the patch #1,
> the patch link is:
> https://lore.kernel.org/patchwork/patch/1375477/
> the commit is:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/perf_regs.h?id=1ddc96bd42da
>
> So we should build patch #2 based on patch #1.
yeah, my bad, since perf wasn't supported on MIPS, how could cross build
environments have the needed files? Stopid me, sorry. :-) I'll
retest after adding the needed files to my test containers.
- Arnaldo
> Thanks,
> Tiezhu
>
> > > I'm not finding it in the debian cross build packages:
> > >
> > > root@d77a78c0aa1c:/# apt-file find perf_regs.h | grep cross
> > > linux-libc-dev-amd64-cross: /usr/x86_64-linux-gnu/include/asm/perf_regs.h
> > > linux-libc-dev-arm64-cross: /usr/aarch64-linux-gnu/include/asm/perf_regs.h
> > > linux-libc-dev-armel-cross: /usr/arm-linux-gnueabi/include/asm/perf_regs.h
> > > linux-libc-dev-armhf-cross:
> > > /usr/arm-linux-gnueabihf/include/asm/perf_regs.h
> > > linux-libc-dev-i386-cross: /usr/i686-linux-gnu/include/asm/perf_regs.h
> > > linux-libc-dev-powerpc-cross:
> > > /usr/powerpc-linux-gnu/include/asm/perf_regs.h
> > > linux-libc-dev-ppc64-cross:
> > > /usr/powerpc64-linux-gnu/include/asm/perf_regs.h
> > > linux-libc-dev-ppc64el-cross:
> > > /usr/powerpc64le-linux-gnu/include/asm/perf_regs.h
> > > linux-libc-dev-riscv64-cross:
> > > /usr/riscv64-linux-gnu/include/asm/perf_regs.h
> > > linux-libc-dev-s390x-cross: /usr/s390x-linux-gnu/include/asm/perf_regs.h
> > > linux-libc-dev-x32-cross: /usr/x86_64-linux-gnux32/include/asm/perf_regs.h
> > > root@d77a78c0aa1c:/#
> > >
> > > Ideas?
> > Trying with:
> >
> > [perfbuilder@five x-mips]$ db
> > acmel/linux-perf-tools-build-ubuntu:19.10-x-mips
> > STEP 1: FROM ubuntu:21.04
> > STEP 2: MAINTAINER Arnaldo Carvalho de Melo
> > STEP 3: ENV ARCH mips
> > STEP 4: ENV TARGET mips-linux-gnu
> > STEP 5: ENV CROSS_COMPILE=${TARGET}-
> > STEP 6: RUN apt-get -y update && apt-get -y install make gcc-${TARGET}
> > g++-${TARGET} flex bison git python3 && apt-get -y install curl wget
> > bzip2 xz-utils file && export ELFUTILS_VER=0.173 && export
> > ZLIB_VER=1.2.11 && export INSTALLDIR=/usr/${TARGET} && export
> > PATH=$INSTALLDIR/bin:$PATH && export TARGETMACH=${TARGET} && export
> > CROSS=${TARGET}- && export CC=${CROSS}gcc && export LD=${CROSS}ld
> > && export AS=${CROSS}as && wget -q
> > http://zlib.net/zlib-${ZLIB_VER}.tar.gz && wget -q
> > https://fedorahosted.org/releases/e/l/elfutils/${ELFUTILS_VER}/elfutils-${ELFUTILS_VER}.tar.bz2
> > && tar xf zlib-${ZLIB_VER}.tar.gz && cd
Re: [PATCH] perf buildid-cache: Add test for PE executable
Em Thu, Feb 25, 2021 at 09:35:04PM +0100, Jiri Olsa escreveu:
> On Wed, Feb 24, 2021 at 02:59:16PM -0500, Nicholas Fraser wrote:
> > From 9fd0b3889f00ad13662879767d833309d8a035b6 Mon Sep 17 00:00:00 2001
> > From: Nicholas Fraser
> > Date: Thu, 18 Feb 2021 13:24:03 -0500
> > Subject: [PATCH] perf buildid-cache: Add test for PE executable
> >
> > This builds on the previous changes to tests/shell/buildid.sh, adding
> > tests for a PE file. It adds it to the build-id cache manually and, if
> > Wine is available, runs it under "perf record" and verifies that it was
> > added automatically.
> >
> > If wine is not installed, only warnings are printed; the test can still
> > exit 0.
> >
> > Signed-off-by: Nicholas Fraser
>
> works nicely now, thanks
>
> Acked-by: Jiri Olsa
Thanks for checking it, but if you did a review, i.e. if you looked at
the code, made suggestions, the submitter acted upon those changes, you
looked again, etc, shouldn't this be a more appropriate:
Reviewed-by: Jiri Olsa
?
I think we need to make these tags reflect more what really happened,
i.e. if you just glanced over and thought, quickly, that it seems
okayish, then Acked-by is what we should use, but if you gone thru the
trouble of actually _looking hard_ at it, sometimes multiple times, then
we should really use Reviewed-by and not take that lightly.
- Arnaldo
> jirka
>
> > ---
> > tools/perf/tests/shell/buildid.sh | 65 +++
> > 1 file changed, 58 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/perf/tests/shell/buildid.sh
> > b/tools/perf/tests/shell/buildid.sh
> > index 416af614bbe0..f05670d1e39e 100755
> > --- a/tools/perf/tests/shell/buildid.sh
> > +++ b/tools/perf/tests/shell/buildid.sh
> > @@ -14,18 +14,56 @@ if ! [ -x "$(command -v cc)" ]; then
> > exit 2
> > fi
> >
> > +# check what we need to test windows binaries
> > +add_pe=1
> > +run_pe=1
> > +if ! perf version --build-options | grep -q 'libbfd: .* on '; then
> > + echo "WARNING: perf not built with libbfd. PE binaries will not be
> > tested."
> > + add_pe=0
> > + run_pe=0
> > +fi
> > +if ! which wine > /dev/null; then
> > + echo "WARNING: wine not found. PE binaries will not be run."
> > + run_pe=0
> > +fi
> > +
> > +# set up wine
> > +if [ ${run_pe} -eq 1 ]; then
> > + wineprefix=$(mktemp -d /tmp/perf.wineprefix.XXX)
> > + export WINEPREFIX=${wineprefix}
> > + # clear display variables to prevent wine from popping up dialogs
> > + unset DISPLAY
> > + unset WAYLAND_DISPLAY
> > +fi
> > +
> > ex_md5=$(mktemp /tmp/perf.ex.MD5.XXX)
> > ex_sha1=$(mktemp /tmp/perf.ex.SHA1.XXX)
> > +ex_pe=$(dirname $0)/../pe-file.exe
> >
> > echo 'int main(void) { return 0; }' | cc -Wl,--build-id=sha1 -o ${ex_sha1}
> > -x c -
> > echo 'int main(void) { return 0; }' | cc -Wl,--build-id=md5 -o ${ex_md5}
> > -x c -
> >
> > -echo "test binaries: ${ex_sha1} ${ex_md5}"
> > +echo "test binaries: ${ex_sha1} ${ex_md5} ${ex_pe}"
> >
> > check()
> > {
> > - id=`readelf -n ${1} 2>/dev/null | grep 'Build ID' | awk '{print $3}'`
> > -
> > + case $1 in
> > + *.exe)
> > + # We don't have a tool that can pull a nicely formatted
> > build-id out of
> > + # a PE file, but we can extract the whole section with objcopy
> > and
> > + # format it ourselves. The .buildid section is a Debug Directory
> > + # containing a CodeView entry:
> > + #
> > https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#debug-directory-image-only
> > + #
> > https://github.com/dotnet/runtime/blob/da94c022576a5c3bbc0e896f006565905eb137f9/docs/design/specs/PE-COFF.md
> > + # The build-id starts at byte 33 and must be rearranged into a
> > GUID.
> > + id=`objcopy -O binary --only-section=.buildid $1 /dev/stdout | \
> > + cut -c 33-48 | hexdump -ve '/1 "%02x"' | \
> > + sed
> > 's@^\(..\)\(..\)\(..\)\(..\)\(..\)\(..\)\(..\)\(..\)\(.*\)0a$@\4\3\2\1\6\5\8\7\9@'`
> > + ;;
> > + *)
> > + id=`readelf -n ${1} 2>/dev/null | grep 'Build ID' | awk '{print
> > $3}'`
> > + ;;
> > + esac
> > echo "build id: ${id}"
> >
> > link=${build_id_dir}/.build-id/${id:0:2}/${id:2}
> > @@ -50,7 +88,7 @@ check()
> > exit 1
> > fi
> >
> > - ${perf} buildid-cache -l | grep $id
> > + ${perf} buildid-cache -l | grep ${id}
> > if [ $? -ne 0 ]; then
> > echo "failed: ${id} is not reported by \"perf buildid-cache
> > -l\""
> > exit 1
> > @@ -79,16 +117,20 @@ test_record()
> > {
> > data=$(mktemp /tmp/perf.data.XXX)
> > build_id_dir=$(mktemp -d /tmp/perf.debug.XXX)
> > + log=$(mktemp /tmp/perf.log.XXX)
> > perf="perf --buildid-dir ${build_id_dir}"
> >
> > - ${perf} record --buildid-all -o ${data} ${1}
> > + echo "running: perf record $@"
> > + ${perf} record --buildid-all -o ${data} $@ &> ${log}
> > if [ $? -ne 0
Re: [PATCH v2 1/1] net: fec: ptp: avoid register access when ipg clock is disabled
On Fri, 26 Feb 2021 07:23:31 -0800 Richard Cochran wrote: > On Thu, Feb 25, 2021 at 10:15:16PM +0100, Heiko Thiery wrote: > > When accessing the timecounter register on an i.MX8MQ the kernel hangs. > > This is only the case when the interface is down. This can be reproduced > > by reading with 'phc_ctrl eth0 get'. > > > > Like described in the change in 91c0d987a9788dcc5fe26baafd73bf9242b68900 > > the igp clock is disabled when the interface is down and leads to a > > system hang. > > > > So we check if the ptp clock status before reading the timecounter > > register. > > > > Signed-off-by: Heiko Thiery > > --- > > v2: > > - add mutex (thanks to Richard) > > > > v3: > > I did a mistake and did not test properly > > - add parenteses > > - fix the used variable On Fri, 26 Feb 2021 08:22:50 +0100 Heiko Thiery wrote: > Sorry for the noise. But just realized that I sent a v3 version of the > patch but forgot to update the subject line (still v2). Should I > resend it with the correct subject? No need, looks like patchwork caught the right version. > Acked-by: Richard Cochran Applied, thanks!
Re: [PATCH] net: phy: make mdio_bus_phy_suspend/resume as __maybe_unused
On Thu, 25 Feb 2021 23:53:20 +0100 Andrew Lunn wrote:
> On Thu, Feb 25, 2021 at 03:57:27PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When CONFIG_PM_SLEEP is disabled, the compiler warns about unused
> > functions:
> >
> > drivers/net/phy/phy_device.c:273:12: error: unused function
> > 'mdio_bus_phy_suspend' [-Werror,-Wunused-function]
> > static int mdio_bus_phy_suspend(struct device *dev)
> > drivers/net/phy/phy_device.c:293:12: error: unused function
> > 'mdio_bus_phy_resume' [-Werror,-Wunused-function]
> > static int mdio_bus_phy_resume(struct device *dev)
> >
> > The logic is intentional, so just mark these two as __maybe_unused
> > and remove the incorrect #ifdef.
> >
> > Fixes: 4c0d2e96ba05 ("net: phy: consider that suspend2ram may cut off PHY
> > power")
> > Signed-off-by: Arnd Bergmann
>
> Reviewed-by: Andrew Lunn
Applied, thanks!
Re: [PATCH] perf tools: Move feature cleanup under tools/build
Em Wed, Feb 24, 2021 at 04:08:31PM +0100, Jiri Olsa escreveu:
> Arnaldo reported issue for following build command:
>
> $ rm -rf /tmp/krava; mkdir /tmp/krava; make O=/tmp/krava clean
> CLEANconfig
> /bin/sh: line 0: cd: /tmp/krava/feature/: No such file or directory
> ../../scripts/Makefile.include:17: *** output directory
> "/tmp/krava/feature/" does not exist. Stop.
> make[1]: *** [Makefile.perf:1010: config-clean] Error 2
> make: *** [Makefile:90: clean] Error 2
>
> The problem is that now that we include scripts/Makefile.include
> in feature's Makefile (which is fine and needed), we need to ensure
> the OUTPUT directory exists, before executing (out of tree) clean
> command.
Thanks, tested and applied.
- Arnaldo
> Removing the feature's cleanup from perf Makefile and fixing
> feature's cleanup under build Makefile, so it now checks that
> there's existing OUTPUT directory before calling the clean.
>
> Cc: Sedat Dilek
> Fixes: 211a741cd3e1 ("tools: Factor Clang, LLC and LLVM utils definitions")
> Reported-by: Arnaldo Carvalho de Melo
> Signed-off-by: Jiri Olsa
> ---
> tools/build/Makefile | 8 +++-
> tools/perf/Makefile.perf | 10 +-
> 2 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/tools/build/Makefile b/tools/build/Makefile
> index bae48e6fa995..5ed41b96fcde 100644
> --- a/tools/build/Makefile
> +++ b/tools/build/Makefile
> @@ -30,12 +30,18 @@ build := -f $(srctree)/tools/build/Makefile.build
> dir=. obj
>
> all: $(OUTPUT)fixdep
>
> +# Make sure there's anything to clean,
> +# feature contains check for existing OUTPUT
> +TMP_O := $(if $(OUTPUT),$(OUTPUT)/feature,./)
> +
> clean:
> $(call QUIET_CLEAN, fixdep)
> $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name
> '\.*.cmd' -delete -o -name '\.*.d' -delete
> $(Q)rm -f $(OUTPUT)fixdep
> $(call QUIET_CLEAN, feature-detect)
> - $(Q)$(MAKE) -C feature/ clean >/dev/null
> +ifneq ($(wildcard $(TMP_O)),)
> + $(Q)$(MAKE) -C feature OUTPUT=$(TMP_O) clean >/dev/null
> +endif
>
> $(OUTPUT)fixdep-in.o: FORCE
> $(Q)$(MAKE) $(build)=fixdep
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 5345ac70cd83..536f6f90af92 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -1001,14 +1001,6 @@ $(INSTALL_DOC_TARGETS):
>
> ### Cleaning rules
>
> -#
> -# This is here, not in Makefile.config, because Makefile.config does
> -# not get included for the clean target:
> -#
> -config-clean:
> - $(call QUIET_CLEAN, config)
> - $(Q)$(MAKE) -C $(srctree)/tools/build/feature/ $(if
> $(OUTPUT),OUTPUT=$(OUTPUT)feature/,) clean >/dev/null
> -
> python-clean:
> $(python-clean)
>
> @@ -1048,7 +1040,7 @@ endif # BUILD_BPF_SKEL
> bpf-skel-clean:
> $(call QUIET_CLEAN, bpf-skel) $(RM) -r $(SKEL_TMP_OUT) $(SKELETONS)
>
> -clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean
> $(LIBSUBCMD)-clean $(LIBPERF)-clean config-clean fixdep-clean python-clean
> bpf-skel-clean
> +clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean
> $(LIBSUBCMD)-clean $(LIBPERF)-clean fixdep-clean python-clean bpf-skel-clean
> $(call QUIET_CLEAN, core-objs) $(RM) $(LIBPERF_A)
> $(OUTPUT)perf-archive $(OUTPUT)perf-with-kcore $(LANG_BINDINGS)
> $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name
> '\.*.cmd' -delete -o -name '\.*.d' -delete
> $(Q)$(RM) $(OUTPUT).config-detected
> --
> 2.29.2
>
--
- Arnaldo
Re: [PATCH net] net: dsa: mt7530: don't build GPIO support if !GPIOLIB
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Fri, 26 Feb 2021 14:32:26 +0800 you wrote: > The new GPIO support may be optional at runtime, but it requires > building against gpiolib: > > ERROR: modpost: "gpiochip_get_data" [drivers/net/dsa/mt7530.ko] > undefined! > ERROR: modpost: "devm_gpiochip_add_data_with_key" > [drivers/net/dsa/mt7530.ko] undefined! > > [...] Here is the summary with links: - [net] net: dsa: mt7530: don't build GPIO support if !GPIOLIB https://git.kernel.org/netdev/net/c/63c75c053b41 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH] drivers/media/usb/gspca/stv06xx: fix memory leak
Syzbot reported memory leak in hdcs_probe_1x00()[1].
hdcs_probe_1x00() allocates memory for struct hdcs, but if hdcs_init() fails in
gspca_dev_probe2()
this memory becomes leaked.
int gspca_dev_probe2(struct usb_interface *intf,
const struct usb_device_id *id,
const struct sd_desc *sd_desc,
int dev_size,
struct module *module)
{
...
ret = sd_desc->config(gspca_dev, id);
if (ret < 0)
goto out;
ret = sd_desc->init(gspca_dev);
if (ret < 0)
goto out;
...
out:
if (gspca_dev->input_dev)
input_unregister_device(gspca_dev->input_dev);
v4l2_ctrl_handler_free(gspca_dev->vdev.ctrl_handler);
v4l2_device_unregister(_dev->v4l2_dev);
kfree(gspca_dev->usb_buf);
kfree(gspca_dev);
return ret;
}
Reported-by: syzbot+e7f4c64a4248a0340...@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin
Change-Id: Ia198671177ee346de61780813025110c7c491d7a
---
drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c
b/drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c
index 5a47dcbf1c8e..24df13b33a02 100644
--- a/drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c
+++ b/drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c
@@ -485,7 +485,7 @@ static int hdcs_init(struct sd *sd)
stv_bridge_init[i][1]);
}
if (err < 0)
- return err;
+ goto error;
/* sensor soft reset */
hdcs_reset(sd);
@@ -496,12 +496,12 @@ static int hdcs_init(struct sd *sd)
stv_sensor_init[i][1]);
}
if (err < 0)
- return err;
+ goto error;
/* Enable continuous frame capture, bit 2: stop when frame complete */
err = stv06xx_write_sensor(sd, HDCS_REG_CONFIG(sd), BIT(3));
if (err < 0)
- return err;
+ goto error;
/* Set PGA sample duration
(was 0x7E for the STV602, but caused slow framerate with HDCS-1020) */
@@ -512,9 +512,13 @@ static int hdcs_init(struct sd *sd)
err = stv06xx_write_sensor(sd, HDCS_TCTRL,
(HDCS_ADC_START_SIG_DUR << 5) | hdcs->psmp);
if (err < 0)
- return err;
+ goto error;
return hdcs_set_size(sd, hdcs->array.width, hdcs->array.height);
+
+error:
+ kfree(hdcs);
+ return err;
}
static int hdcs_dump(struct sd *sd)
--
2.25.1
[PATCH] drivers/media/usb/gspca/stv06xx: fix memory leak
Syzbot reported memory leak in hdcs_probe_1x00()[1].
hdcs_probe_1x00() allocates memory for struct hdcs, but if hdcs_init() fails in
gspca_dev_probe2()
this memory becomes leaked.
int gspca_dev_probe2(struct usb_interface *intf,
const struct usb_device_id *id,
const struct sd_desc *sd_desc,
int dev_size,
struct module *module)
{
...
ret = sd_desc->config(gspca_dev, id);
if (ret < 0)
goto out;
ret = sd_desc->init(gspca_dev);
if (ret < 0)
goto out;
...
out:
if (gspca_dev->input_dev)
input_unregister_device(gspca_dev->input_dev);
v4l2_ctrl_handler_free(gspca_dev->vdev.ctrl_handler);
v4l2_device_unregister(_dev->v4l2_dev);
kfree(gspca_dev->usb_buf);
kfree(gspca_dev);
return ret;
}
Reported-by: syzbot+e7f4c64a4248a0340...@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin
Change-Id: Ia198671177ee346de61780813025110c7c491d7a
---
drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c
b/drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c
index 5a47dcbf1c8e..24df13b33a02 100644
--- a/drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c
+++ b/drivers/media/usb/gspca/stv06xx/stv06xx_hdcs.c
@@ -485,7 +485,7 @@ static int hdcs_init(struct sd *sd)
stv_bridge_init[i][1]);
}
if (err < 0)
- return err;
+ goto error;
/* sensor soft reset */
hdcs_reset(sd);
@@ -496,12 +496,12 @@ static int hdcs_init(struct sd *sd)
stv_sensor_init[i][1]);
}
if (err < 0)
- return err;
+ goto error;
/* Enable continuous frame capture, bit 2: stop when frame complete */
err = stv06xx_write_sensor(sd, HDCS_REG_CONFIG(sd), BIT(3));
if (err < 0)
- return err;
+ goto error;
/* Set PGA sample duration
(was 0x7E for the STV602, but caused slow framerate with HDCS-1020) */
@@ -512,9 +512,13 @@ static int hdcs_init(struct sd *sd)
err = stv06xx_write_sensor(sd, HDCS_TCTRL,
(HDCS_ADC_START_SIG_DUR << 5) | hdcs->psmp);
if (err < 0)
- return err;
+ goto error;
return hdcs_set_size(sd, hdcs->array.width, hdcs->array.height);
+
+error:
+ kfree(hdcs);
+ return err;
}
static int hdcs_dump(struct sd *sd)
--
2.25.1
Re: [PATCH 1/3] net: mscc: ocelot: select NET_DEVLINK
On Thu, 25 Feb 2021 15:38:31 +0100 Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Without this option, the driver fails to link:
>
> ld.lld: error: undefined symbol: devlink_sb_register
> [...]
>
> Fixes: f59fd9cab730 ("net: mscc: ocelot: configure watermarks using
> devlink-sb")
> Signed-off-by: Arnd Bergmann
Applied patch 1 and 2, I'll take Qingfang's patch for mt7530, thanks!
Re: [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers from trace events
On Fri, 26 Feb 2021 14:21:00 -0800 Linus Torvalds wrote: > > The second patch handles strings "%s" [..] > > Doing this at runtime really feels like the wrong thing to do. > > It won't even protect us from what happened - people like me and > Andrew won't even run those tracepoints in the first place, so we > won't notice. > > It really would be much better in every respect to have this done by > checkpatch, I think. They are not mutually exclusive. We could have both. One thing that's nice about this patch is that it removes the possibility of a real bug. That is, it will catch the dereferencing of a string that is not valid, WARN about it, but it wont try to dereference it (outside of the strcpy_from_kernel_nofault()). And hopefully the warning and lack of data they want, will have this get caught during development. Also, there's cases that %s is allowed to reference data that I don't know if checkpatch would be able to differentiate. As for the other pointer dereferences (the first patch), those get caught at boot up if they are compiled in. That is, you don't need to have the events enabled. The boot up code will do the verification on all events that are loaded (allyesconfig will catch all of them, which I need to try to boot with this code). -- Steve
[PATCH] media: i2c: adp1653: fix error handling from a call to adp1653_get_fault
From: Colin Ian King
The error check on rval from the call to adp1653_get_fault currently
returns if rval is non-zero. This appears to be incorrect as the
following if statement checks for various bit settings in rval so
clearly rval is expected to be non-zero at that point. Coverity
flagged the if statement up as deadcode. Fix this so the error
return path only occurs when rval is negative.
Addresses-Coverity: ("Logically dead code")
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Signed-off-by: Colin Ian King
---
drivers/media/i2c/adp1653.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 522a0b10e415..1a4878385394 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -170,7 +170,7 @@ static int adp1653_set_ctrl(struct v4l2_ctrl *ctrl)
int rval;
rval = adp1653_get_fault(flash);
- if (rval)
+ if (rval < 0)
return rval;
if ((rval & (ADP1653_REG_FAULT_FLT_SCP |
ADP1653_REG_FAULT_FLT_OT |
--
2.30.0
Re: possible deadlock in sk_clone_lock
Cc: Michal
On 2/26/21 2:44 PM, Shakeel Butt wrote:
> On Fri, Feb 26, 2021 at 2:09 PM syzbot
> wrote:
>> other info that might help us debug this:
>>
>> Possible interrupt unsafe locking scenario:
>>
>>CPU0CPU1
>>
>> lock(hugetlb_lock);
>>local_irq_disable();
>>lock(slock-AF_INET);
>>lock(hugetlb_lock);
>>
>> lock(slock-AF_INET);
>>
>> *** DEADLOCK ***
>
> This has been reproduced on 4.19 stable kernel as well [1] and there
> is a reproducer as well.
>
> It seems like sendmsg(MSG_ZEROCOPY) from a buffer backed by hugetlb. I
> wonder if we just need to make hugetlb_lock softirq-safe.
>
> [1] https://syzkaller.appspot.com/bug?extid=6383ce4b0b8ec575ad93
Thanks Shakeel,
Commit c77c0a8ac4c5 ("mm/hugetlb: defer freeing of huge pages if in non-task
context") attempted to address this issue. It uses a work queue to
acquire hugetlb_lock if the caller is !in_task().
In another recent thread, there was the suggestion to change the
!in_task to in_atomic.
I need to do some research on the subtle differences between in_task,
in_atomic, etc. TBH, I 'thought' !in_task would prevent the issue
reported here. But, that obviously is not the case.
--
Mike Kravetz
Re: [RFC 00/19] Rework support for i.MX8MQ interconnect with devfreq
Hi, You missed sending the patches to linux-pm mailing list. On next version, please send it linux-pm. Thanks, Chanwoo Choi On 21. 2. 20. 오전 12:59, Abel Vesa wrote: This has been on my queue for quite some time now. It is more of a proof-of-concept. This rework is done with the compatibility of future i.MX platforms in mind. For example, the i.MX8MP platform has multiple NoCs. This patchsets prepares the imx interconnect and imx devfreq for that too. As of now, none of the drivers involved are being used and there is no icc consumer on any off the i.MX platforms. Basically, the steps taken here are the following: 1. Make the dram_apb clock "reparantable" from kernel. This is needed in order to keep track of the actual parent of the dram_apb clock in the kernel clock hierarchy. Note that the actual switch is done EL3 (TF-A). 2. Rework the imx-bus so the actual link between the icc and the NoCs or the pl301s is not tightly coupled. This allows us to have as many NoCs as necessary but also allows as to use the same driver for the pl301s. The pl301s have their own clocks too, so we need to reduce their rates too. 3. Rework the imx8m-ddrc driver. Remove the support for dts defined OPPs. The EL3 provides those. So instead of havingi to keep the OPP table in both EL3 and kernel in sync, we rely on what the EL3 gives us. Also, when the platform suspends, the bus needs to be running at highest rate, otherwise there is a chance it might not resume anymore. By adding the late system sleep PM ops we can handle that easily. 4. Rework the imx interconnect driver to use the fsl,icc-id instead of the robust imx_icc_node_adj_desc for linking with the target node. By adding the fsl,icc-id property to all the NoC and pl301 dts nodes, we can link each icc node to their corresponding NoC, pl301 or dram. Basically, when the imx interconnect platform specific driver probes, it will take each node defined for that platform and look-up the corresponding dts node based on the id and add that as the qos device. 5. Added the fec and usdhc as icc consumers. This is just as an example. All the other consumers can be added later. Basically, each consumer will add a path to their device node and in the driver will have to handle that icc path accordingly. Abel Vesa (19): clk: imx8mq: Replace critical with ignore_unused flag for dram_apb clock dt-bindings: interconnect: imx8mq: Add missing pl301 and SAI ids devfreq: imx-bus: Switch governor to powersave devfreq: imx-bus: Decouple imx-bus from icc made devfreq: imx8m-ddrc: Change governor to powersave devfreq: imx8m-ddrc: Use the opps acquired from EL3 devfreq: imx8m-ddrc: Add late system sleep PM ops interconnect: imx: Switch from imx_icc_node_adj_desc to fsl,icc-id node assignment interconnect: imx8: Remove the imx_icc_node_adj_desc interconnect: imx8mq: Add the pl301_per_m and pl301_wakeup nodes and subnodes interconnect: imx8mq: Add of_match_table interconnect: imx: Add imx_icc_get_bw and imx_icc_aggregate functions arm64: dts: imx8mq: Add fsl,icc-id property to ddrc node arm64: dts: imx8mq: Add fsl,icc-id to noc node arm64: dts: imx8mq: Add all pl301 nodes arm64: dts: imx8mq: Add the interconnect node arm64: dts: imx8mq: Add interconnect properties to icc consumer nodes net: ethernet: fec_main: Add interconnect support mmc: sdhci-esdhc-imx: Add interconnect support arch/arm64/boot/dts/freescale/imx8mq.dtsi | 200 +- drivers/clk/imx/clk-imx8mq.c | 2 +- drivers/devfreq/imx-bus.c | 42 + drivers/devfreq/imx8m-ddrc.c | 75 +++- drivers/interconnect/imx/imx.c| 92 +- drivers/interconnect/imx/imx.h| 19 +- drivers/interconnect/imx/imx8mm.c | 32 ++-- drivers/interconnect/imx/imx8mn.c | 28 +-- drivers/interconnect/imx/imx8mq.c | 59 --- drivers/mmc/host/sdhci-esdhc-imx.c| 26 +++ drivers/net/ethernet/freescale/fec.h | 3 + drivers/net/ethernet/freescale/fec_main.c | 19 ++ include/dt-bindings/interconnect/imx8mq.h | 9 + scripts/dtc/fdtoverlay| Bin 0 -> 61280 bytes 14 files changed, 393 insertions(+), 213 deletions(-) create mode 100755 scripts/dtc/fdtoverlay
Re: [PATCH net-next RFC v4] net: hdlc_x25: Queue outgoing LAPB frames
On Fri, Feb 26, 2021 at 6:21 AM Martin Schiller wrote: > > I have now had a look at it. It works as expected. > I just wonder if it would not be more appropriate to call > the lapb_register() already in x25_hdlc_open(), so that the layer2 > (lapb) can already "work" before the hdlc_x25 interface is up. I think it's better not to keep LAPB running unless hdlc_x25 is up. If I am the user, I would expect that when I change the X.25 interface to the DOWN state, the LAPB protocol would be completely stopped and the LAPB layer would not generate any new frames anymore (even if the other side wants to connect), and when I change the X.25 interface back to the UP state, it would be a fresh new start for the LAPB protocol. > Also, I have a hard time assessing if such a wrap is really enforceable. Sorry. I don't understand what you mean. What "wrap" are you referring to? > Unfortunately I have no idea how many users there actually are.
Re: #pragma once (was Re: incoming)
On Fri, Feb 26, 2021 at 01:53:48PM -0800, Linus Torvalds wrote:
> On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan wrote:
> >
> > I want to sent treewide "#pragma once" conversion:
>
> Are there *any* advantages to it?
>
> It's non-standard,
It is effectively standard:
https://en.wikipedia.org/wiki/Pragma_once#Portability
and I'll spare UAPI headers from conversion.
> and the historical argument for it ("it can reduce
> compile times because the preprocessor doesn't open the file twice" is
> pure and utter hogwash. Any preprocessor worth its salt does the same
> thing for the standard and traditional #ifndef/#define guard sequence.
>
> Honestly, "#pragma once" was always a hack for bad preprocessors that
> weren't smart enough to just figure it out from the regular guarding
> macros.
>
> I can't imagine that any preprocessor that incompetent exists any
> more, and if i does, we sure shouldn't be using it.
>
> So #pragma once seems to have no actual advantages.
The advantage is removing busywork that is include guards.
There are rules and schemes about how to create guard macro.
Should it be prefixed by underscore?
Should it be prefixed by two underscores?
Should it be full path uppercased or just last path component?
Should the guard macro be lowercased?
Should it be changed when header is moved?
Should trailing #endif contain comment?
Should #define be just #define or "#define FOO 1"?
I've even seen advice (or an IDE doing that) that is should contain
timestamp of a header creation time to minimise collisions (implying
collisions could happen as could typos as could broken guards)
All this zoo of styles and made up mental work is completely avoided
by using #pragma once:
1) put #pragma once on the first line
or
2) put #pragma once on the second line after SPDX banner
and that's it.
No fuss, no filled up preprocessor hashtables, no implicit arguing
about styles. And way less LOC:
18092 files changed, 18883 insertions(+), 99841 deletions(-)
Now if old school header guard is necessary it can be used like in
good old times.
Nobody would miss include guards.
Re: [PATCH v8] pgo: add clang's Profile Guided Optimization infrastructure
On Fri, Feb 26, 2021 at 2:20 PM Bill Wendling wrote: > > From: Sami Tolvanen > > Enable the use of clang's Profile-Guided Optimization[1]. To generate a > profile, the kernel is instrumented with PGO counters, a representative > workload is run, and the raw profile data is collected from > /sys/kernel/debug/pgo/profraw. > > The raw profile data must be processed by clang's "llvm-profdata" tool > before it can be used during recompilation: > > $ cp /sys/kernel/debug/pgo/profraw vmlinux.profraw > $ llvm-profdata merge --output=vmlinux.profdata vmlinux.profraw > > Multiple raw profiles may be merged during this step. > > The data can now be used by the compiler: > > $ make LLVM=1 KCFLAGS=-fprofile-use=vmlinux.profdata ... > > This initial submission is restricted to x86, as that's the platform we > know works. This restriction can be lifted once other platforms have > been verified to work with PGO. > > Note that this method of profiling the kernel is clang-native, unlike > the clang support in kernel/gcov. > > [1] https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization > > Signed-off-by: Sami Tolvanen > Co-developed-by: Bill Wendling > Signed-off-by: Bill Wendling I forgot to add these tags: Tested-by: Nick Desaulniers Reviewed-by: Nick Desaulniers > --- > v8: - Rebased on top-of-tree. > v7: - Fix minor build failure reported by Sedat. > v6: - Add better documentation about the locking scheme and other things. > - Rename macros to better match the same macros in LLVM's source code. > v5: - Correct padding calculation, discovered by Nathan Chancellor. > v4: - Remove non-x86 Makfile changes and se "hweight64" instead of using our > own popcount implementation, based on Nick Desaulniers's comment. > v3: - Added change log section based on Sedat Dilek's comments. > v2: - Added "__llvm_profile_instrument_memop" based on Nathan Chancellor's > testing. > - Corrected documentation, re PGO flags when using LTO, based on Fangrui > Song's comments. > --- > Documentation/dev-tools/index.rst | 1 + > Documentation/dev-tools/pgo.rst | 127 + > MAINTAINERS | 9 + > Makefile | 3 + > arch/Kconfig | 1 + > arch/x86/Kconfig | 1 + > arch/x86/boot/Makefile| 1 + > arch/x86/boot/compressed/Makefile | 1 + > arch/x86/crypto/Makefile | 4 + > arch/x86/entry/vdso/Makefile | 1 + > arch/x86/kernel/vmlinux.lds.S | 2 + > arch/x86/platform/efi/Makefile| 1 + > arch/x86/purgatory/Makefile | 1 + > arch/x86/realmode/rm/Makefile | 1 + > arch/x86/um/vdso/Makefile | 1 + > drivers/firmware/efi/libstub/Makefile | 1 + > include/asm-generic/vmlinux.lds.h | 44 +++ > kernel/Makefile | 1 + > kernel/pgo/Kconfig| 35 +++ > kernel/pgo/Makefile | 5 + > kernel/pgo/fs.c | 389 ++ > kernel/pgo/instrument.c | 189 + > kernel/pgo/pgo.h | 203 ++ > scripts/Makefile.lib | 10 + > 24 files changed, 1032 insertions(+) > create mode 100644 Documentation/dev-tools/pgo.rst > create mode 100644 kernel/pgo/Kconfig > create mode 100644 kernel/pgo/Makefile > create mode 100644 kernel/pgo/fs.c > create mode 100644 kernel/pgo/instrument.c > create mode 100644 kernel/pgo/pgo.h > > diff --git a/Documentation/dev-tools/index.rst > b/Documentation/dev-tools/index.rst > index f7809c7b1ba9..8d6418e85806 100644 > --- a/Documentation/dev-tools/index.rst > +++ b/Documentation/dev-tools/index.rst > @@ -26,6 +26,7 @@ whole; patches welcome! > kgdb > kselftest > kunit/index > + pgo > > > .. only:: subproject and html > diff --git a/Documentation/dev-tools/pgo.rst b/Documentation/dev-tools/pgo.rst > new file mode 100644 > index ..b7f11d8405b7 > --- /dev/null > +++ b/Documentation/dev-tools/pgo.rst > @@ -0,0 +1,127 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +=== > +Using PGO with the Linux kernel > +=== > + > +Clang's profiling kernel support (PGO_) enables profiling of the Linux kernel > +when building with Clang. The profiling data is exported via the ``pgo`` > +debugfs directory. > + > +.. _PGO: > https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization > + > + > +Preparation > +=== > + > +Configure the kernel with: > + > +.. code-block:: make > + > + CONFIG_DEBUG_FS=y > + CONFIG_PGO_CLANG=y > + > +Note that kernels compiled with profiling flags will be significantly larger > +and run slower. > + > +Profiling data will only become accessible once debugfs has been mounted: > + > +.. code-block:: sh > + > + mount -t debugfs none /sys/kernel/debug > + > + >
Re: KASAN: use-after-free Read in __cpuhp_state_remove_instance
syzbot has found a reproducer for the following issue on: HEAD commit:d01f2f7e Add linux-next specific files for 20210226 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=17208f22d0 kernel config: https://syzkaller.appspot.com/x/.config?x=a1746d2802a82a05 dashboard link: https://syzkaller.appspot.com/bug?extid=38769495e847cea2dcca syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1087f2bcd0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14b83722d0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+38769495e847cea2d...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in __hlist_del include/linux/list.h:835 [inline] BUG: KASAN: use-after-free in hlist_del include/linux/list.h:852 [inline] BUG: KASAN: use-after-free in __cpuhp_state_remove_instance+0x58b/0x5b0 kernel/cpu.c:2002 Read of size 8 at addr 888013928898 by task syz-executor929/8420 CPU: 1 PID: 8420 Comm: syz-executor929 Not tainted 5.11.0-next-20210226-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0xfa/0x151 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 __hlist_del include/linux/list.h:835 [inline] hlist_del include/linux/list.h:852 [inline] __cpuhp_state_remove_instance+0x58b/0x5b0 kernel/cpu.c:2002 cpuhp_state_remove_instance_nocalls include/linux/cpuhotplug.h:407 [inline] io_wq_create+0x6ca/0xbf0 fs/io-wq.c:1056 io_init_wq_offload fs/io_uring.c:7792 [inline] io_uring_alloc_task_context+0x1bf/0x6a0 fs/io_uring.c:7811 io_uring_add_task_file+0x261/0x350 fs/io_uring.c:8773 io_uring_install_fd fs/io_uring.c:9381 [inline] io_uring_create fs/io_uring.c:9532 [inline] io_uring_setup+0x14c7/0x2be0 fs/io_uring.c:9571 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43eec9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7fff25216ba8 EFLAGS: 0246 ORIG_RAX: 01a9 RAX: ffda RBX: 00400488 RCX: 0043eec9 RDX: 0043eec9 RSI: 2040 RDI: 74c1 RBP: 00402eb0 R08: R09: R10: R11: 0246 R12: 00402f40 R13: R14: 004ac018 R15: 00400488 Allocated by task 8420: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:427 [inline] kasan_kmalloc mm/kasan/common.c:506 [inline] kasan_kmalloc mm/kasan/common.c:465 [inline] __kasan_kmalloc+0x99/0xc0 mm/kasan/common.c:515 kmalloc include/linux/slab.h:554 [inline] kzalloc include/linux/slab.h:684 [inline] io_wq_create+0xc0/0xbf0 fs/io-wq.c:1002 io_init_wq_offload fs/io_uring.c:7792 [inline] io_uring_alloc_task_context+0x1bf/0x6a0 fs/io_uring.c:7811 io_uring_add_task_file+0x261/0x350 fs/io_uring.c:8773 io_uring_install_fd fs/io_uring.c:9381 [inline] io_uring_create fs/io_uring.c:9532 [inline] io_uring_setup+0x14c7/0x2be0 fs/io_uring.c:9571 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 8420: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357 kasan_slab_free mm/kasan/common.c:360 [inline] kasan_slab_free mm/kasan/common.c:325 [inline] __kasan_slab_free+0xf5/0x130 mm/kasan/common.c:367 kasan_slab_free include/linux/kasan.h:199 [inline] slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x72/0x1b0 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kfree+0xe5/0x7b0 mm/slub.c:4213 io_wq_destroy fs/io-wq.c:1091 [inline] io_wq_put+0x4d0/0x6d0 fs/io-wq.c:1098 io_wq_create+0x92d/0xbf0 fs/io-wq.c:1053 io_init_wq_offload fs/io_uring.c:7792 [inline] io_uring_alloc_task_context+0x1bf/0x6a0 fs/io_uring.c:7811 io_uring_add_task_file+0x261/0x350 fs/io_uring.c:8773 io_uring_install_fd fs/io_uring.c:9381 [inline] io_uring_create fs/io_uring.c:9532 [inline] io_uring_setup+0x14c7/0x2be0 fs/io_uring.c:9571 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Last potentially related work creation: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:345 insert_work+0x48/0x370 kernel/workqueue.c:1331 __queue_work+0x5c1/0xf00 kernel/workqueue.c:1497 queue_work_on+0xae/0xc0 kernel/workqueue.
Re: [PATCH v2] block: Add bio_max_segs
On 2/26/21 1:38 PM, Matthew Wilcox wrote: > > This seems to have missed the merge window ;-( It ain't over yet, and I haven't shipped my final bits for 5.12 for block yet... I'll queue it up. -- Jens Axboe
[PATCH 2/2] media: v4l2-async: Safely unregister an non-registered async subdev
From: Laurent Pinchart
Make the V4L2 async framework a bit more robust by allowing to
unregister a non-registered async subdev. Otherwise the
v4l2_async_cleanup() will attempt to delete the async subdev from the
subdev_list with the corresponding list_head not initialized.
Signed-off-by: Laurent Pinchart
---
drivers/media/v4l2-core/v4l2-async.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 37cc0263b273..2347b7ac54d4 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -750,6 +750,9 @@ EXPORT_SYMBOL(v4l2_async_register_subdev);
void v4l2_async_unregister_subdev(struct v4l2_subdev *sd)
{
+ if (list_is_null(>async_list))
+ return;
+
mutex_lock(_lock);
__v4l2_async_notifier_unregister(sd->subdev_notifier);
--
Regards,
Laurent Pinchart
[PATCH 1/2] list: Add list_is_null() to check if a list_head has been initialized
From: Laurent Pinchart
The new function checks if the list_head prev and next pointers are
NULL, in order to see if a list_head that has been zeroed when allocated
has been initialized with INIT_LIST_HEAD() or added to a list.
This can be used in cleanup functions that want to support being safely
called when an object has not been initialized, to return immediately.
In most cases other fields of the object can be checked for this
purpose, but in some cases a list_head field is the only option.
Signed-off-by: Laurent Pinchart
---
include/linux/list.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/list.h b/include/linux/list.h
index 85c92555e31f..e4fc6954de3b 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -29,6 +29,19 @@ static inline void INIT_LIST_HEAD(struct list_head *list)
list->prev = list;
}
+/**
+ * list_is_null - check if a list_head has been initialized
+ * @list: the list
+ *
+ * Check if the list_head prev and next pointers are NULL. This is useful to
+ * see if a list_head that has been zeroed when allocated has been initialized
+ * with INIT_LIST_HEAD() or added to a list.
+ */
+static inline bool list_is_null(struct list_head *list)
+{
+ return list->prev == NULL && list->next == NULL;
+}
+
#ifdef CONFIG_DEBUG_LIST
extern bool __list_add_valid(struct list_head *new,
struct list_head *prev,
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] KVM: vmx/pmu: Fix dummy check if lbr_desc->event is created
On Wed, Feb 24, 2021, Xu, Like wrote:
> On 2021/2/24 1:15, Sean Christopherson wrote:
> > On Tue, Feb 23, 2021, Like Xu wrote:
> > > If lbr_desc->event is successfully created, the intel_pmu_create_
> > > guest_lbr_event() will return 0, otherwise it will return -ENOENT,
> > > and then jump to LBR msrs dummy handling.
> > >
> > > Fixes: 1b5ac3226a1a ("KVM: vmx/pmu: Pass-through LBR msrs when the guest
> > > LBR event is ACTIVE")
> > > Signed-off-by: Like Xu
> > > ---
> > > arch/x86/kvm/vmx/pmu_intel.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
> > > index d1df618cb7de..d6a5fe19ff09 100644
> > > --- a/arch/x86/kvm/vmx/pmu_intel.c
> > > +++ b/arch/x86/kvm/vmx/pmu_intel.c
> > > @@ -320,7 +320,7 @@ static bool intel_pmu_handle_lbr_msrs_access(struct
> > > kvm_vcpu *vcpu,
> > > if (!intel_pmu_is_valid_lbr_msr(vcpu, index))
> > > return false;
> > > - if (!lbr_desc->event && !intel_pmu_create_guest_lbr_event(vcpu))
> > > + if (!lbr_desc->event && intel_pmu_create_guest_lbr_event(vcpu))
> > > goto dummy;
...
> > AFAICT, event contention would lead to a #GP crash in the host due to
> > lbr_desc->event being dereferenced, no?
>
> a #GP crash in the host ？Can you share more understanding about it ?
The original code is will dereference a null lbr_desc->event if
intel_pmu_create_guest_lbr_event() fails.
if (!lbr_desc->event && intel_pmu_create_guest_lbr_event(vcpu)) <-
falls through
goto dummy;
/*
* Disable irq to ensure the LBR feature doesn't get reclaimed by the
* host at the time the value is read from the msr, and this avoids the
* host LBR value to be leaked to the guest. If LBR has been reclaimed,
* return 0 on guest reads.
*/
local_irq_disable();
if (lbr_desc->event->state == PERF_EVENT_STATE_ACTIVE) { <-
kaboom
if (read)
rdmsrl(index, msr_info->data);
else
wrmsrl(index, msr_info->data);
__set_bit(INTEL_PMC_IDX_FIXED_VLBR,
vcpu_to_pmu(vcpu)->pmc_in_use);
local_irq_enable();
return true;
}
Re: possible deadlock in sk_clone_lock
On Fri, Feb 26, 2021 at 2:09 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:577c2835 Add linux-next specific files for 20210224
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=137cef82d0
> kernel config: https://syzkaller.appspot.com/x/.config?x=e9bb3d369b3bf49
> dashboard link: https://syzkaller.appspot.com/bug?extid=506c8a2a115201881d45
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+506c8a2a115201881...@syzkaller.appspotmail.com
>
> =
> WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
> 5.11.0-next-20210224-syzkaller #0 Not tainted
> -
> syz-executor.3/15411 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire:
> 8c0a0e18 (hugetlb_lock){+.+.}-{2:2}, at: spin_lock
> include/linux/spinlock.h:354 [inline]
> 8c0a0e18 (hugetlb_lock){+.+.}-{2:2}, at: __free_huge_page+0x4cd/0xc10
> mm/hugetlb.c:1390
>
> and this task is already holding:
> 88802391c720 (slock-AF_INET){+.-.}-{2:2}, at: spin_lock
> include/linux/spinlock.h:354 [inline]
> 88802391c720 (slock-AF_INET){+.-.}-{2:2}, at: __tcp_close+0x6d9/0x1170
> net/ipv4/tcp.c:2788
> which would create a new lock dependency:
> (slock-AF_INET){+.-.}-{2:2} -> (hugetlb_lock){+.+.}-{2:2}
>
> but this new dependency connects a SOFTIRQ-irq-safe lock:
> (slock-AF_INET){+.-.}-{2:2}
>
> ... which became SOFTIRQ-irq-safe at:
> lock_acquire kernel/locking/lockdep.c:5510 [inline]
> lock_acquire+0x1ab/0x730 kernel/locking/lockdep.c:5475
> __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
> _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
> spin_lock include/linux/spinlock.h:354 [inline]
> sk_clone_lock+0x296/0x1070 net/core/sock.c:1913
> inet_csk_clone_lock+0x21/0x4c0 net/ipv4/inet_connection_sock.c:830
> tcp_create_openreq_child+0x30/0x16d0 net/ipv4/tcp_minisocks.c:460
> tcp_v4_syn_recv_sock+0x10c/0x1460 net/ipv4/tcp_ipv4.c:1526
> tcp_check_req+0x616/0x1860 net/ipv4/tcp_minisocks.c:772
> tcp_v4_rcv+0x221a/0x3780 net/ipv4/tcp_ipv4.c:2001
> ip_protocol_deliver_rcu+0x5c/0x8a0 net/ipv4/ip_input.c:204
> ip_local_deliver_finish+0x20a/0x370 net/ipv4/ip_input.c:231
> NF_HOOK include/linux/netfilter.h:301 [inline]
> NF_HOOK include/linux/netfilter.h:295 [inline]
> ip_local_deliver+0x1b3/0x200 net/ipv4/ip_input.c:252
> dst_input include/net/dst.h:458 [inline]
> ip_sublist_rcv_finish+0x9a/0x2c0 net/ipv4/ip_input.c:551
> ip_list_rcv_finish.constprop.0+0x514/0x6e0 net/ipv4/ip_input.c:601
> ip_sublist_rcv net/ipv4/ip_input.c:609 [inline]
> ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644
> __netif_receive_skb_list_ptype net/core/dev.c:5408 [inline]
> __netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5456
> __netif_receive_skb_list net/core/dev.c:5508 [inline]
> netif_receive_skb_list_internal+0x777/0xd70 net/core/dev.c:5618
> gro_normal_list net/core/dev.c:5772 [inline]
> gro_normal_list net/core/dev.c:5768 [inline]
> napi_complete_done+0x1f1/0x820 net/core/dev.c:6474
> virtqueue_napi_complete+0x2c/0xc0 drivers/net/virtio_net.c:334
> virtnet_poll+0xae2/0xd90 drivers/net/virtio_net.c:1455
> __napi_poll+0xaf/0x440 net/core/dev.c:6892
> napi_poll net/core/dev.c:6959 [inline]
> net_rx_action+0x801/0xb40 net/core/dev.c:7036
> __do_softirq+0x29b/0x9f6 kernel/softirq.c:345
> invoke_softirq kernel/softirq.c:221 [inline]
> __irq_exit_rcu kernel/softirq.c:422 [inline]
> irq_exit_rcu+0x134/0x200 kernel/softirq.c:434
> common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
> asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:623
> tomoyo_domain_quota_is_ok+0x2f1/0x550 security/tomoyo/util.c:1093
> tomoyo_supervisor+0x2f2/0xf00 security/tomoyo/common.c:2089
> tomoyo_audit_path_log security/tomoyo/file.c:168 [inline]
> tomoyo_path_permission security/tomoyo/file.c:587 [inline]
> tomoyo_path_permission+0x270/0x3a0 security/tomoyo/file.c:573
> tomoyo_path_perm+0x39e/0x400 security/tomoyo/file.c:838
> tomoyo_path_symlink+0x94/0xe0 security/tomoyo/tomoyo.c:200
> security_path_symlink+0xdf/0x150 security/security.c:1119
> do_symlinkat+0x123/0x300 fs/namei.c:4201
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> to a SOFTIRQ-irq-unsafe lock:
> (hugetlb_lock){+.+.}-{2:2}
>
> ... which became SOFTIRQ-irq-unsafe at:
> ...
> lock_acquire kernel/locking/lockdep.c:5510 [inline]
> lock_acquire+0x1ab/0x730 kernel/locking/lockdep.c:5475
> __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
> _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
> spin_lock include/linux/spinlock.h:354 [inline]
> hugetlb_overcommit_handler+0x260/0x3e0 mm/hugetlb.c:3448
>
Re: Question about the "EXPERIMENTAL" tag for dax in XFS
On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote: > > On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote: > > On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote: > > > > > > On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote: > > > > On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong > > > > wrote: > > > > > > > > > > On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com > > > > > wrote: > > > > > > Hi, guys > > > > > > > > > > > > Beside this patchset, I'd like to confirm something about the > > > > > > "EXPERIMENTAL" tag for dax in XFS. > > > > > > > > > > > > In XFS, the "EXPERIMENTAL" tag, which is reported in waring message > > > > > > when we mount a pmem device with dax option, has been existed for a > > > > > > while. It's a bit annoying when using fsdax feature. So, my > > > > > > initial > > > > > > intention was to remove this tag. And I started to find out and > > > > > > solve > > > > > > the problems which prevent it from being removed. > > > > > > > > > > > > As is talked before, there are 3 main problems. The first one is > > > > > > "dax > > > > > > semantics", which has been resolved. The rest two are "RMAP for > > > > > > fsdax" and "support dax reflink for filesystem", which I have been > > > > > > working on. > > > > > > > > > > > > > > > > > > > > > So, what I want to confirm is: does it means that we can remove the > > > > > > "EXPERIMENTAL" tag when the rest two problem are solved? > > > > > > > > > > Yes. I'd keep the experimental tag for a cycle or two to make sure > > > > > that > > > > > nothing new pops up, but otherwise the two patchsets you've sent close > > > > > those two big remaining gaps. Thank you for working on this! > > > > > > > > > > > Or maybe there are other important problems need to be fixed before > > > > > > removing it? If there are, could you please show me that? > > > > > > > > > > That remains to be seen through QA/validation, but I think that's it. > > > > > > > > > > Granted, I still have to read through the two patchsets... > > > > > > > > I've been meaning to circle back here as well. > > > > > > > > My immediate concern is the issue Jason recently highlighted [1] with > > > > respect to invalidating all dax mappings when / if the device is > > > > ripped out from underneath the fs. I don't think that will collide > > > > with Ruan's implementation, but it does need new communication from > > > > driver to fs about removal events. > > > > > > > > [1]: > > > > http://lore.kernel.org/r/capcyv4i+pzhyziepf2pah0dt5jdfkmkdx-3usqy1fahf6lp...@mail.gmail.com > > > > > > Oh, yay. > > > > > > The XFS shutdown code is centred around preventing new IO from being > > > issued - we don't actually do anything about DAX mappings because, > > > well, I don't think anyone on the filesystem side thought they had > > > to do anything special if pmem went away from under it. > > > > > > My understanding -was- that the pmem removal invalidates > > > all the ptes currently mapped into CPU page tables that point at > > > the dax device across the system. THe vmas that manage these > > > mappings are not really something the filesystem really manages, > > > but a function of the mm subsystem. What the filesystem cares about > > > is that it gets page faults triggered when a change of state occurs > > > so that it can remap the page to it's backing store correctly. > > > > > > IOWs, all the mm subsystem needs to when pmem goes away is clear the > > > CPU ptes, because then when then when userspace tries to access the > > > mapped DAX pages we get a new page fault. In processing the fault, the > > > filesystem will try to get direct access to the pmem from the block > > > device. This will get an ENODEV error from the block device because > > > because the backing store (pmem) has been unplugged and is no longer > > > there... > > > > > > AFAICT, as long as pmem removal invalidates all the active ptes that > > > point at the pmem being removed, the filesystem doesn't need to > > > care about device removal at all, DAX or no DAX... > > > > How would the pmem removal do that without walking all the active > > inodes in the fs at the time of shutdown and call > > unmap_mapping_range(inode->i_mapping, 0, 0, 1)? > > Which then immediately ends up back at the vmas that manage the ptes > to unmap them. > > Isn't finding the vma(s) that map a specific memory range exactly > what the rmap code in the mm subsystem is supposed to address? rmap can lookup only vmas from a virt address relative to a given mm_struct. The driver has neither the list of mm_struct objects nor virt addresses to do a lookup. All it knows is that someone might have mapped pages through the fsdax interface. To me this looks like a notifier that fires from memunmap_pages() after dev_pagemap_kill() to notify any block_device associated with that dev_pagemap() to say that any dax mappings arranged through this block_device are now invalid. The reason to do this
Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS
On Mon, Feb 15, 2021 at 11:38:21AM -0800, Don Bollinger wrote: > optoe is an i2c based driver that supports read/write access to all > the pages (tables) of MSA standard SFP and similar devices (conforming > to the SFF-8472 spec), MSA standard QSFP and similar devices (conforming > to the SFF-8636 spec) and CMIS and similar devices (conforming to the > Common Management Interface Specfication). Hi Don Please make sure you Cc: netdev. This is networking stuff. And we have seen this code before, and the netdev Maintainers have argued against it before. > These devices provide identification, operational status and control > registers via an EEPROM model. These devices support one or 3 fixed pages > (128 bytes) of data, and one page that is selected via a page register on > the first fixed page. Thus the driver's main task is to map these pages > onto a simple linear address space for user space management applications. > See the driver code for a detailed layout. I assume you have seen the work NVIDIA submitted last week? This idea of linear pages is really restrictive and we are moving away from it. > The EEPROM data is accessible to user space and kernel consumers via the > nvmem interface. ethtool -m ? In the past, this code has been NACKed because it does not integrate into the networking stack. Is this attempt any different? Thanks Andrew
Re: [GIT PULL] (swiotlb) stable/for-linus-5.12
The pull request you sent on Fri, 26 Feb 2021 11:00:08 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git > stable/for-linus-5.12 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ef9856a734af9bc71e5a8554374380e200fe7fc4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] OpenRISC updates for 5.12
The pull request you sent on Sat, 27 Feb 2021 06:56:19 +0900: > g...@github.com:openrisc/linux.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a3905af5be36b9aa9f17657a02eeb2a08e939c13 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] pcmcia updates for v5.12
The pull request you sent on Fri, 26 Feb 2021 06:50:29 +0100: > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git pcmcia-next has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/360db2b422f16305e5b8523b4b730521fbc8fb5d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] CIFS/SMB3 Fixes
The pull request you sent on Fri, 26 Feb 2021 00:24:14 -0600: > git://git.samba.org/sfrench/cifs-2.6.git tags/5.12-smb3-part1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c19798af2e66d9d3eb1060873bb435ea8bf4ad2e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] LEDs changes for 5.12-rc1
The pull request you sent on Fri, 26 Feb 2021 13:18:48 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/ > tags/leds-5.12-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fecfd015394e9151f535d675e115fba967bddb3f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] s390 patches for the 5.12 merge window #2
The pull request you sent on Fri, 26 Feb 2021 21:02:08 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.12-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e7270e47a09e83051da7b2bee71be00741860ec4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Documentation fixes for 5.12
The pull request you sent on Fri, 26 Feb 2021 11:54:04 -0700: > git://git.lwn.net/linux.git tags/docs-5.12-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3fb6d0e00efc958d01c2f109c8453033a2d96796 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH v3] cxl: Make loop variable be 'i' instead of 'j'
.. otherwise people spend extra cycles looking for the
inner loop and wondering 'why j'?
This was an oversight when initial work was rebased
so let's fix it here.
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: Initial posting
v2: Fix per Dan's request
v3: Duh, don't initialize i in the loop, but do it outside of it.
---
drivers/cxl/mem.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 244cb7d89678..e7246e585e62 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -698,7 +698,7 @@ static int cxl_query_cmd(struct cxl_memdev *cxlmd,
struct device *dev = >dev;
struct cxl_mem_command *cmd;
u32 n_commands;
- int j = 0;
+ int i;
dev_dbg(dev, "Query IOCTL\n");
@@ -713,13 +713,14 @@ static int cxl_query_cmd(struct cxl_memdev *cxlmd,
* otherwise, return max(n_commands, total commands) cxl_command_info
* structures.
*/
+ i = 0;
cxl_for_each_cmd(cmd) {
const struct cxl_command_info *info = >info;
- if (copy_to_user(>commands[j++], info, sizeof(*info)))
+ if (copy_to_user(>commands[i++], info, sizeof(*info)))
return -EFAULT;
- if (j == n_commands)
+ if (i == n_commands)
break;
}
--
2.29.2
Re: [PATCH v8 0/3] pinctrl: pinmux: Add pinmux-select debugfs file
On Sat, Feb 20, 2021 at 12:27:47PM -0800, Drew Fustini wrote: > This series first converts the debugfs files in the pinctrl subsystem to > octal permissions and then adds a new debugfs file "pinmux-select". > > Group name and function name can be written to "pinmux-select" which > will cause the pin function for the specified group to be activated on > the pin controller. > > The final patch in this series documents the debugfs files for pinctrl. > > Notes for PATCH v8: > - add 'Reviewed-by:' from Geert Uytterhoeven for pinmux-select patch > - add 'Tested-by:' from Geert Uytterhoeven for pinmux-select patch > - change pinmux-select format to '' based on > feedback from Geert > - rephrase parts of documentation per Geert's comments > > Notes for PATCH v7: > - add 'Reviewed-by:' from Andy Shevchenko for pinmux-select patch > - add 'Reviewed-by:' from Andy Shevchenko for documentation patch > - add 'Reviewed-by:' from Tony Lindgren to all patches > - change order of '#include ' per Andy's suggestion > - change PINMUX_SELECT_MAX back to 128 as I had accidentally changed it > to 50 and Andy pointed this out. > - grammer fixes as suggested by Andy > - rework assignment of fsel and ret from pinmux_func_name_to_selector() > - rework assignment of gsel and ret from pinctrl_get_group_selector() > > Notes for PATCH v6: > - add 'Suggested-by:' for Joe Perches to octal permissions patch > - add 'Reviewed-by:' from Andy and Geert to octal permissions patch > - reword example in the pinmux-select patch per Andy's advice > - indent the example output per Andy's advice > - remove usage error messages as Andy advised it is too verbose > - return -ENOMEM when write is too big for the input buffer per Andy's advice > - handle whitespace before, in between, and after the function name and > group name as suggested by Andy > - rename free_buf to exit_free_buf per Andy's advice > - add documentation patch to series which documents the debugfs files > for the pinctrl subsystem including the new pinmux-select file > > Notes for PATCH v5: > - convert permissions from symbolic to octal for debugfs_create_file() > calls in core.c that Joe Perches pointed out I had missed > - Linus W: please let me know if I should break this series apart as you > already applied an earlier version of octal conversion patch today [1] > - switch from sscanf() to just pointing to function name and group name > inside of the buffer. This also avoids having to allocate additional > buffers for fname and gname. Geert and Andy highlighted this security > issue and Andy suggested code to use instead of sscanf(). > - switch from devm_kfree() to kfree() after Dan Carpenter warned me > - remove .read from pinmux_select_ops per Geert since it is write only > - add usage format to error when unable find fname or gname in buffer > > Notes for PATCH v4: > - correct the commit message in the second patch to reference function > and group name instead of integer selectors. Apologies for not fixing > that in v3 > - fix typos in cover letter > > Notes for PATCH v3: > - add Suggested-by: Andy Shevchenko to the "pinctrl: use to octal > permissions for debugfs files" patch > - change the octal permissions from 0400 to 0444 to correctly match the > symbolic permissions (thanks to Joe Perches and Geert Uytterhoeven) > - note that S_IFREG flag is added to the mode in __debugfs_create_file() > (thanks to Andy for highlighting this and Joe for suggesting I should > add a note to the commit message) > - fix order of the goto labels so that the buffers are freed correctly > as suggested by Dan Carpenter > - move from devm_kzalloc() to kzalloc() as the buffers are only used > inside the pinmux_select() function and not related to the lifetime > of the pin controller device (thanks to Andy for pointing this out) > - correct the pinmux-select example in commit message to use the > function and group name instead of selector (thanks to Geert) > > Notes for PATCH v2: > - create patch series that includes patch to switch all the debugfs > files in pinctrl subsystem over to octal permission > - write function name and group name, instead of error-prone selector > numbers, to the 'pinmux-select' file > - switch from static to dynamic allocation for the kernel buffer filled > by strncpy_from_user() > - look up function selector from function name using > pinmux_func_name_to_selector() > - validate group name with get_function_groups() and match_string() > - look up selector for group name with pinctrl_get_group_selector() > > Notes for PATCH v1: > - posted seperate patch to switch all the debugfs files in pinctrl > subsystem over to octal permission > - there is no existing documentation for any of the debugfs enteries for > pinctrl, so it seemed to have a bigger scope than just this patch. I > also noticed that rst documentation is confusingly named "pinctl" (no > 'r') and started thread about that [2]. Linus suggested
Re: [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers from trace events
On Fri, Feb 26, 2021 at 11:07 AM Steven Rostedt wrote: > > The first patch scans the print fmts of the trace events looking for > dereferencing pointers from %p*, and making sure that they refer back > to the trace event itself. > > The second patch handles strings "%s" [..] Doing this at runtime really feels like the wrong thing to do. It won't even protect us from what happened - people like me and Andrew won't even run those tracepoints in the first place, so we won't notice. It really would be much better in every respect to have this done by checkpatch, I think. Linus
Re: [PATCH] ext4: Add xattr commands to compat ioctl handler
On Fri, Feb 26, 2021 at 02:14:41PM -0800, Sarthak Kukreti wrote:
> This allows 32-bit userspace utils to use FS_IOC_FSGETXATTR and
> FS_IOC_FSSETXATTR on a 64-bit kernel.
>
> Signed-off-by: Sarthak Kukreti
> ---
> fs/ext4/ioctl.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index f0381876a7e5b..055c26296ab46 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -1371,6 +1371,8 @@ long ext4_compat_ioctl(struct file *file, unsigned int
> cmd, unsigned long arg)
> return -EFAULT;
> return ext4_ioctl_group_add(file, );
> }
> + case EXT4_IOC_FSGETXATTR:
> + case EXT4_IOC_FSSETXATTR:
> case EXT4_IOC_MOVE_EXT:
> case EXT4_IOC_RESIZE_FS:
> case FITRIM:
These were already added to the list by commit a54d8d34d235
("ext4: Add EXT4_IOC_FSGETXATTR/EXT4_IOC_FSSETXATTR to compat_ioctl").
- Eric
