Re: [PATCH] rtl8xxxu: Fix device info for RTL8192EU devices
Pascal Terjan wrote: > Based on 2001:3319 and 2357:0109 which I used to test the fix and > 0bda:818b and 2357:0108 for which I found efuse dumps online. > > == 2357:0109 == > === Before === > Vendor: Realtek > Product: \x03802.11n NI > Serial: > === After === > Vendor: Realtek > Product: 802.11n NIC > Serial not available. > > == 2001:3319 == > === Before === > Vendor: Realtek > Product: Wireless N > Serial: no USB Adap > === After === > Vendor: Realtek > Product: Wireless N Nano USB Adapter > Serial not available. > > Signed-off-by: Pascal Terjan Can someone review this, please? Patch set to Deferred. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210323193617.3748164-1-pter...@google.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rsi: fix error return code of rsi_load_9116_firmware()
Jia-Ju Bai wrote: > When kmemdup() returns NULL to ta_firmware, no error return code of > rsi_load_9116_firmware() is assigned. > To fix this bug, status is assigned with -ENOMEM in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210307083445.21322-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ti: wlcore: fix error return code of wl1271_cmd_build_ps_poll()
Jia-Ju Bai wrote: > When ieee80211_pspoll_get() returns NULL to skb, no error return code of > wl1271_cmd_build_ps_poll() is assigned. > To fix this bug, ret is assigned with -ENOMEM in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210307082906.20950-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ti: wlcore: fix error return code of wl1271_suspend()
Jia-Ju Bai wrote: > When wl is NULL, no error return code of wl1271_suspend() is assigned. > To fix this bug, ret is assigned with -EINVAL in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210306143600.19676-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] marvell: libertas_tf: fix error return code of if_usb_prog_firmware()
Jia-Ju Bai wrote: > When check_fwfile_format() fails, no error return code of > if_usb_prog_firmware() is assigned. > To fix this bug, ret is assigned with -EINVAL as error return code. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210305033115.6015-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH 2/2] kconfig: highlight xconfig 'comment' lines with '***'
Mark Kconfig "comment" lines with "*** ***" so that it is clear that these lines are comments and not some kconfig item that cannot be modified. This is helpful in some menus to be able to provide a menu "sub-heading" for groups of similar config items. This also makes the comments be presented in a way that is similar to menuconfig and nconfig. Signed-off-by: Randy Dunlap Cc: Masahiro Yamada Cc: linux-kbu...@vger.kernel.org --- scripts/kconfig/qconf.cc |1 + 1 file changed, 1 insertion(+) --- linux-next-20210416.orig/scripts/kconfig/qconf.cc +++ linux-next-20210416/scripts/kconfig/qconf.cc @@ -122,6 +122,7 @@ void ConfigItem::updateMenu(void) goto set_prompt; case P_COMMENT: setIcon(promptColIdx, QIcon()); + prompt = "*** " + prompt + " ***"; goto set_prompt; default: ;
[PATCH 1/2] kconfig: highlight gconfig 'comment' lines with '***'
Mark Kconfig "comment" lines with "*** ***"
so that it is clear that these lines are comments and not some
kconfig item that cannot be modified.
This is helpful in some menus to be able to provide a menu
"sub-heading" for groups of similar config items.
This also makes the comments be presented in a way that is
similar to menuconfig and nconfig.
Signed-off-by: Randy Dunlap
Cc: Masahiro Yamada
Cc: linux-kbu...@vger.kernel.org
---
scripts/kconfig/gconf.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- linux-next-20210416.orig/scripts/kconfig/gconf.c
+++ linux-next-20210416/scripts/kconfig/gconf.c
@@ -1048,8 +1048,13 @@ static gchar **fill_row(struct menu *men
g_free(row[i]);
bzero(row, sizeof(row));
+ ptype = menu->prompt ? menu->prompt->type : P_UNKNOWN;
+
row[COL_OPTION] =
- g_strdup_printf("%s %s", menu_get_prompt(menu),
+ g_strdup_printf("%s %s %s %s",
+ ptype == P_COMMENT ? "***" : "",
+ menu_get_prompt(menu),
+ ptype == P_COMMENT ? "***" : "",
sym && !sym_has_value(sym) ? "(NEW)" : "");
if (opt_mode == OPT_ALL && !menu_is_visible(menu))
@@ -1060,7 +1065,6 @@ static gchar **fill_row(struct menu *men
else
row[COL_COLOR] = g_strdup("Black");
- ptype = menu->prompt ? menu->prompt->type : P_UNKNOWN;
switch (ptype) {
case P_MENU:
row[COL_PIXBUF] = (gchar *) xpm_menu;
Re: [PATCH 1/2] srcu: Fix broken node geometry after early ssp init
On Sat, Apr 17, 2021 at 03:16:49PM +0200, Frederic Weisbecker wrote: > On Wed, Apr 14, 2021 at 08:55:38AM -0700, Paul E. McKenney wrote: > > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h > > > index 75ed367d5b60..24db97cbf76b 100644 > > > --- a/kernel/rcu/rcu.h > > > +++ b/kernel/rcu/rcu.h > > > @@ -278,6 +278,7 @@ extern void resched_cpu(int cpu); > > > extern int rcu_num_lvls; > > > extern int num_rcu_lvl[]; > > > extern int rcu_num_nodes; > > > +extern bool rcu_geometry_initialized; > > > > Can this be a static local variable inside rcu_init_geometry()? > > > > After all, init_srcu_struct() isn't called all that often, and its overhead > > is such that an extra function call and check is going to hurt it. This > > of course requires removing __init from rcu_init_geometry(), but it is not > > all that large, so why not just remove the __init? > > > > But if we really are worried about reclaiming rcu_init_geometry()'s > > instructions (maybe we are?), then rcu_init_geometry() can be split > > into a function that just does the check (which is not __init) and the > > remainder of the function, which could remain __init. > > There you go: Queued, thank you! Thanx, Paul > --- > From: Frederic Weisbecker > Date: Wed, 31 Mar 2021 16:10:36 +0200 > Subject: [PATCH] srcu: Fix broken node geometry after early ssp init > > An ssp initialized before rcu_init_geometry() will have its snp hierarchy > based on CONFIG_NR_CPUS. > > Once rcu_init_geometry() is called, the nodes distribution is shrinked > and optimized toward meeting the actual possible number of CPUs detected > on boot. > > Later on, the ssp that was initialized before rcu_init_geometry() is > confused and sometimes refers to its initial CONFIG_NR_CPUS based node > hierarchy, sometimes to the new num_possible_cpus() based one instead. > For example each of its sdp->mynode remain backward and refer to the > early node leaves that may not exist anymore. On the other hand the > srcu_for_each_node_breadth_first() refers to the new node hierarchy. > > There are at least two bad possible outcomes to this: > > 1) a) A callback enqueued early on an sdp is recorded pending on > sdp->mynode->srcu_data_have_cbs in srcu_funnel_gp_start() with > sdp->mynode pointing to a deep leaf (say 3 levels). > >b) The grace period ends after rcu_init_geometry() which shrinks the > nodes level to a single one. srcu_gp_end() walks through the new > snp hierarchy without ever reaching the old leaves so the callback > is never executed. > >This is easily reproduced on an 8 CPUs machine with >CONFIG_NR_CPUS >= 32 and "rcupdate.rcu_self_test=1". The >srcu_barrier() after early tests verification never completes and >the boot hangs: > > [ 5413.141029] INFO: task swapper/0:1 blocked for more than 4915 > seconds. > [ 5413.147564] Not tainted 5.12.0-rc4+ #28 > [ 5413.151927] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 5413.159753] task:swapper/0 state:D stack:0 pid:1 ppid: > 0 flags:0x4000 > [ 5413.168099] Call Trace: > [ 5413.170555] __schedule+0x36c/0x930 > [ 5413.174057] ? wait_for_completion+0x88/0x110 > [ 5413.178423] schedule+0x46/0xf0 > [ 5413.181575] schedule_timeout+0x284/0x380 > [ 5413.185591] ? wait_for_completion+0x88/0x110 > [ 5413.189957] ? mark_held_locks+0x61/0x80 > [ 5413.193882] ? mark_held_locks+0x61/0x80 > [ 5413.197809] ? _raw_spin_unlock_irq+0x24/0x50 > [ 5413.202173] ? wait_for_completion+0x88/0x110 > [ 5413.206535] wait_for_completion+0xb4/0x110 > [ 5413.210724] ? srcu_torture_stats_print+0x110/0x110 > [ 5413.215610] srcu_barrier+0x187/0x200 > [ 5413.219277] ? rcu_tasks_verify_self_tests+0x50/0x50 > [ 5413.224244] ? rdinit_setup+0x2b/0x2b > [ 5413.227907] rcu_verify_early_boot_tests+0x2d/0x40 > [ 5413.232700] do_one_initcall+0x63/0x310 > [ 5413.236541] ? rdinit_setup+0x2b/0x2b > [ 5413.240207] ? rcu_read_lock_sched_held+0x52/0x80 > [ 5413.244912] kernel_init_freeable+0x253/0x28f > [ 5413.249273] ? rest_init+0x250/0x250 > [ 5413.252846] kernel_init+0xa/0x110 > [ 5413.256257] ret_from_fork+0x22/0x30 > > 2) An ssp that gets initialized before rcu_init_geometry() and used >afterward will always have stale rdp->mynode references, resulting in >callbacks to be missed in srcu_gp_end(), just like in the previous >scenario. > > Solve this with initializing nodes geometry whenever an struct srcu_state > happens to be initialized before rcu_init(). This way we make sure the > RCU nodes hierarchy is properly built and distributed before the nodes > of an struct srcu_state are allocated. > > Suggested-by: Paul E. McKenney > Signed-off-by: Frederic Weisbecker > Cc: Boqun Feng > Cc: Lai
[Patch] blk-wbt: fix a divide-by-zero error in rwb_arm_timer()
From: Cong Wang
We hit a divide error in rwb_arm_timer() and crash dump shows
rqd->scale_step is 16777215 (0xff in hex), so the expression
"(rqd->scale_step + 1) << 8)" is 0x1, which is just beyond
32-bit integer range, hence it is truncated to 0 and int_sqrt(0)
returns 0 too, so we end up passing 0 as a divisor to div_u64().
Looking at the assembly code generated:
add$0x1,%edi
shl$0x8,%edi
movslq %edi,%rdi
mov0x10(%rbx),%rdi
xor%edx,%edx
mov%eax,%ecx
shl$0x4,%rdi
mov%rdi,%rax
div%rcx
we notice that the left shift is still using 32 bit register %edi,
because the type of rqd->scale_step is 'int'. But actually int_sqrt()
takes 'long' as a parameter, so the temporary result should fit well
at least on x86_64. Fix this by explicitly casting the expression to
u64 and call int_sqrt64() to avoid any ambiguity on 32 bit.
After this patch, the assembly code looks correct:
add$0x1,%edi
movslq %edi,%rdi
shl$0x8,%rdi
mov0x10(%rbx),%rdi
xor%edx,%edx
mov%eax,%ecx
shl$0x4,%rdi
mov%rdi,%rax
div%rcx
Fixes: e34cbd307477 ("blk-wbt: add general throttling mechanism")
Cc: Jens Axboe
Cc: Fam Zheng
Cc: Xiongchun Duan
Signed-off-by: Cong Wang
---
block/blk-wbt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-wbt.c b/block/blk-wbt.c
index 42aed0160f86..5157ca86574f 100644
--- a/block/blk-wbt.c
+++ b/block/blk-wbt.c
@@ -337,7 +337,7 @@ static void rwb_arm_timer(struct rq_wb *rwb)
* though.
*/
rwb->cur_win_nsec = div_u64(rwb->win_nsec << 4,
- int_sqrt((rqd->scale_step + 1) << 8));
+ int_sqrt64((u64)(rqd->scale_step + 1)
<< 8));
} else {
/*
* For step < 0, we don't want to increase/decrease the
--
2.25.1
Re: PROBLEM: DoS Attack on Fragment Cache
On Sat, Apr 17, 2021 at 10:26:30PM -0400, Matt Corallo wrote: > Sure, there are better ways to handle the reassembly cache overflowing, but > that is pretty unrelated to the fact that waiting 30 full seconds for a > fragment to come in doesn't really make sense in today's networks (the 30 > second delay that is used today appears to even be higher than RFC 791 > suggested in 1981!). Not exactly actually, because you forget the TTL here. With most hosts sending an initial TTL around 64, after crossing 10-15 hops it's still around 50 so that would result in ~50 seconds by default, even according to the 40 years old RFC791. The 15s there was the absolute minimum. While I do agree that we shouldn't keep them that long nowadays, we can't go too low without risking to break some slow transmission stacks (SLIP/PPP over modems for example). In addition even cutting that in 3 will remain trivially DoSable. > You get a lot more bang for your buck if you don't wait > around so long (or we could restructure things to kick out the oldest > fragments, but that is a lot more work, and probably extra indexes that just > aren't worth it). Kicking out oldest ones is a bad approach in a system made only of independent elements, because it tends to result in a lot of damage once all of them behave similarly. I.e. if you need to kick out an old entry in valid traffic, it's because you do need to wait that long, and if all datagrams need to wait that long, then new datagrams systematically prevent the oldest one from being reassembled, and none gest reassembled. With a random approach at least your success ratio converges towards 1/e (i.e. 36%) which is better. Willy
Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board
On Sat, Apr 17, 2021 at 8:36 PM Atish Patra wrote:
>
> On Mon, Mar 29, 2021 at 10:04 AM Vitaly Wool wrote:
> >
> > On Sat, Mar 27, 2021 at 6:24 PM Alex Ghiti wrote:
> > >
> > > Hi Atish,
> > >
> > > Le 3/3/21 à 3:02 PM, Atish Patra a écrit :
> > > > Add initial DTS for Microchip ICICLE board having only
> > > > essential devices (clocks, sdhci, ethernet, serial, etc).
> > > > The device tree is based on the U-Boot patch.
> > > >
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> > > >
> > > > Signed-off-by: Atish Patra
> > > > ---
> > > > arch/riscv/boot/dts/Makefile | 1 +
> > > > arch/riscv/boot/dts/microchip/Makefile| 2 +
> > > > .../microchip/microchip-mpfs-icicle-kit.dts | 72
> > > > .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
> > > > 4 files changed, 404 insertions(+)
> > > > create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> > > > create mode 100644
> > > > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > > >
> > > > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > > > index 7ffd502e3e7b..fe996b88319e 100644
> > > > --- a/arch/riscv/boot/dts/Makefile
> > > > +++ b/arch/riscv/boot/dts/Makefile
> > > > @@ -1,5 +1,6 @@
> > > > # SPDX-License-Identifier: GPL-2.0
> > > > subdir-y += sifive
> > > > subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan
> > > > +subdir-y += microchip
> > > >
> > > > obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > > > diff --git a/arch/riscv/boot/dts/microchip/Makefile
> > > > b/arch/riscv/boot/dts/microchip/Makefile
> > > > new file mode 100644
> > > > index ..622b12771fd3
> > > > --- /dev/null
> > > > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > > > @@ -0,0 +1,2 @@
> > > > +# SPDX-License-Identifier: GPL-2.0
> > > > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > >
> > > I'm playing (or trying to...) with XIP_KERNEL and I had to add the
> > > following to have the device tree actually builtin the kernel:
> > >
> > > diff --git a/arch/riscv/boot/dts/microchip/Makefile
> > > b/arch/riscv/boot/dts/microchip/Makefile
> > > index 622b12771fd3..855c1502d912 100644
> > > --- a/arch/riscv/boot/dts/microchip/Makefile
> > > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > > @@ -1,2 +1,3 @@
> > > # SPDX-License-Identifier: GPL-2.0
> > > dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > > +obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y))
> > >
> > > Alex
> >
> > Yes, I believe this is necessary for BUILTIN_DTB to work on Polarfire,
> > regardless of whether the kernel is XIP or not.
> >
>
> But there is no usecase for BUILTIN_DTB for polarfire except XIP kernel.
> The bootloaders for polarfire is capable of providing a DTB to kernel.
>
> If XIP kernel is enabled, the following line in
> arch/riscv/boot/dts/Makefile should take care of things
>
(Sorry. The mail was sent by mistake earlier with incomplete response)
Otherwise, we need a similar change for unleashed as well. No ?
>
> > Best regards,
> >Vitaly
> >
> > > > diff --git
> > > > a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > > new file mode 100644
> > > > index ..ec79944065c9
> > > > --- /dev/null
> > > > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > > @@ -0,0 +1,72 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/* Copyright (c) 2020 Microchip Technology Inc */
> > > > +
> > > > +/dts-v1/;
> > > > +
> > > > +#include "microchip-mpfs.dtsi"
> > > > +
> > > > +/* Clock frequency (in Hz) of the rtcclk */
> > > > +#define RTCCLK_FREQ 100
> > > > +
> > > > +/ {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > + model = "Microchip PolarFire-SoC Icicle Kit";
> > > > + compatible = "microchip,mpfs-icicle-kit";
> > > > +
> > > > + chosen {
> > > > + stdout-path =
> > > > + };
> > > > +
> > > > + cpus {
> > > > + timebase-frequency = ;
> > > > + };
> > > > +
> > > > + memory@8000 {
> > > > + device_type = "memory";
> > > > + reg = <0x0 0x8000 0x0 0x4000>;
> > > > + clocks = < 26>;
> > > > + };
> > > > +
> > > > + soc {
> > > > + };
> > > > +};
> > > > +
> > > > + {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > + {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > + {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > + {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > + {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > + {
> > > > + phy-mode = "sgmii";
> > > > + phy-handle = <>;
> > > > +
Re: [PATCH 5/9] sched: prctl() core-scheduling interface
On Wed, Apr 07, 2021 at 07:00:33PM +0200, Peter Zijlstra wrote: > On Thu, Apr 01, 2021 at 03:10:17PM +0200, Peter Zijlstra wrote: > > > Current hard-coded policies are: > > > > - a user can clear the cookie of any process they can set a cookie for. > >Lack of a cookie *might* be a security issue if cookies are being used > >for that. > > ChromeOS people, what are you doing about this? syscall/prctl filtering? Yes, in ChromeOS, we allow the prctl(2) syscall only before entering the seccomp sandbox. Once we enter the sandbox, we do not allow the prctl(2). This has the nice design that the security is enforced on entering the sandbox, and prior to entering the sandbox, no permissions need be given. Let me know if that makes sense and if you had any other questions. thanks, -Joel
Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board
On Mon, Mar 29, 2021 at 10:04 AM Vitaly Wool wrote:
>
> On Sat, Mar 27, 2021 at 6:24 PM Alex Ghiti wrote:
> >
> > Hi Atish,
> >
> > Le 3/3/21 à 3:02 PM, Atish Patra a écrit :
> > > Add initial DTS for Microchip ICICLE board having only
> > > essential devices (clocks, sdhci, ethernet, serial, etc).
> > > The device tree is based on the U-Boot patch.
> > >
> > > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> > >
> > > Signed-off-by: Atish Patra
> > > ---
> > > arch/riscv/boot/dts/Makefile | 1 +
> > > arch/riscv/boot/dts/microchip/Makefile| 2 +
> > > .../microchip/microchip-mpfs-icicle-kit.dts | 72
> > > .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
> > > 4 files changed, 404 insertions(+)
> > > create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> > > create mode 100644
> > > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > >
> > > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > > index 7ffd502e3e7b..fe996b88319e 100644
> > > --- a/arch/riscv/boot/dts/Makefile
> > > +++ b/arch/riscv/boot/dts/Makefile
> > > @@ -1,5 +1,6 @@
> > > # SPDX-License-Identifier: GPL-2.0
> > > subdir-y += sifive
> > > subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan
> > > +subdir-y += microchip
> > >
> > > obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > > diff --git a/arch/riscv/boot/dts/microchip/Makefile
> > > b/arch/riscv/boot/dts/microchip/Makefile
> > > new file mode 100644
> > > index ..622b12771fd3
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > > @@ -0,0 +1,2 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> >
> > I'm playing (or trying to...) with XIP_KERNEL and I had to add the
> > following to have the device tree actually builtin the kernel:
> >
> > diff --git a/arch/riscv/boot/dts/microchip/Makefile
> > b/arch/riscv/boot/dts/microchip/Makefile
> > index 622b12771fd3..855c1502d912 100644
> > --- a/arch/riscv/boot/dts/microchip/Makefile
> > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > @@ -1,2 +1,3 @@
> > # SPDX-License-Identifier: GPL-2.0
> > dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > +obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y))
> >
> > Alex
>
> Yes, I believe this is necessary for BUILTIN_DTB to work on Polarfire,
> regardless of whether the kernel is XIP or not.
>
But there is no usecase for BUILTIN_DTB for polarfire except XIP kernel.
The bootloaders for polarfire is capable of providing a DTB to kernel.
If XIP kernel is enabled, the following line in
arch/riscv/boot/dts/Makefile should take care of things
> Best regards,
>Vitaly
>
> > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > new file mode 100644
> > > index ..ec79944065c9
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > > @@ -0,0 +1,72 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/* Copyright (c) 2020 Microchip Technology Inc */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "microchip-mpfs.dtsi"
> > > +
> > > +/* Clock frequency (in Hz) of the rtcclk */
> > > +#define RTCCLK_FREQ 100
> > > +
> > > +/ {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + model = "Microchip PolarFire-SoC Icicle Kit";
> > > + compatible = "microchip,mpfs-icicle-kit";
> > > +
> > > + chosen {
> > > + stdout-path =
> > > + };
> > > +
> > > + cpus {
> > > + timebase-frequency = ;
> > > + };
> > > +
> > > + memory@8000 {
> > > + device_type = "memory";
> > > + reg = <0x0 0x8000 0x0 0x4000>;
> > > + clocks = < 26>;
> > > + };
> > > +
> > > + soc {
> > > + };
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + phy-mode = "sgmii";
> > > + phy-handle = <>;
> > > + phy0: ethernet-phy@8 {
> > > + reg = <8>;
> > > + ti,fifo-depth = <0x01>;
> > > + };
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > + phy-mode = "sgmii";
> > > + phy-handle = <>;
> > > + phy1: ethernet-phy@9 {
> > > + reg = <9>;
> > > + ti,fifo-depth = <0x01>;
> > > + };
> > > +};
> > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > >
[PATCH v3 2/2] cpupower: Fix amd cpu (family >= 0x17) active state issue
From: xufuhai
If the read_msr function is executed by a non-root user, the function returns
-1, which means that there is no permission to access /dev/cpu/%d/msr, but
cpufreq_has_boost_support should also return -1 immediately, and should not
follow the original logic to return 0, which will cause amd The cpupower tool
returns the boost active state as 0.
Reproduce procedure:
cpupower frequency-info
Reported-by: yangrui
Signed-off-by: xufuhai
Signed-off-by: chenguanqiao
Signed-off-by: lishujin
Reviewed-by: Thomas Renninger
---
tools/power/cpupower/utils/helpers/misc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/tools/power/cpupower/utils/helpers/misc.c
b/tools/power/cpupower/utils/helpers/misc.c
index fc6e34511721..565f8c414396 100644
--- a/tools/power/cpupower/utils/helpers/misc.c
+++ b/tools/power/cpupower/utils/helpers/misc.c
@@ -16,7 +16,7 @@
int cpufreq_has_boost_support(unsigned int cpu, int *support, int *active,
int *states)
{
- int ret;
+ int ret = 0;
unsigned long long val;
*support = *active = *states = 0;
@@ -30,18 +30,21 @@ int cpufreq_has_boost_support(unsigned int cpu, int
*support, int *active,
*/
if (cpupower_cpu_info.caps & CPUPOWER_CAP_AMD_CPB_MSR) {
- if (!read_msr(cpu, MSR_AMD_HWCR, )) {
+ /*
+* no permission to access /dev/cpu/%d/msr, return -1
immediately,
+* and should not follow the original logic to return 0
+*/
+ ret = read_msr(cpu, MSR_AMD_HWCR, );
+ if (!ret) {
if (!(val & CPUPOWER_AMD_CPBDIS))
*active = 1;
}
} else {
ret = amd_pci_get_num_boost_states(active, states);
- if (ret)
- return ret;
}
} else if (cpupower_cpu_info.caps & CPUPOWER_CAP_INTEL_IDA)
*support = *active = 1;
- return 0;
+ return ret;
}
int cpupower_intel_get_perf_bias(unsigned int cpu)
--
2.24.3 (Apple Git-128)
Re: [git pull] drm/vmwgfx fixes for 5.12-rc8
The pull request you sent on Sun, 18 Apr 2021 09:48:56 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-18 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/aba5970c4da0059ed8052188a341a85ac8845d6f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] SCSI fixes for 5.12-rc6
The pull request you sent on Sat, 17 Apr 2021 18:46:43 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c98ff1d013d2d53911c4b3e8ba14c7cd141cf1ed Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v4 0/5] Add Microchip PolarFire Soc Support
On Mon, Mar 29, 2021 at 9:17 PM Palmer Dabbelt wrote: > > On Wed, 03 Mar 2021 12:02:48 PST (-0800), Atish Patra wrote: > > This series adds minimal support for Microchip Polar Fire Soc Icicle kit. > > It is rebased on v5.12-rc1 and depends on clock support. > > Only MMC and ethernet drivers are enabled via this series. > > The idea here is to add the foundational patches so that other drivers > > can be added to on top of this. The device tree may change based on > > feedback on bindings of individual driver support patches. > > > > This series has been tested on Qemu and Polar Fire Soc Icicle kit. > > It depends on the updated clock-series[2] and macb fix[3]. > > The series is also tested by Lewis from Microchip. > > > > The series can also be found at. > > https://github.com/atishp04/linux/tree/polarfire_support_upstream_v4 > > > > [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html > > [2] https://www.spinics.net/lists/linux-clk/msg54579.html > > > > Changes from v3->v4: > > 1. Fixed few DT specific issues. > > 2. Rebased on top of new clock driver. > > 3. SD card functionality is verified. > > > > Changes from v2->v3: > > 1. Fixed a typo in dt binding. > > 2. Included MAINTAINERS entry for PolarFire SoC. > > 3. Improved the dts file by using lowercase clock names and keeping phy > >details in board specific dts file. > > > > Changes from v1->v2: > > 1. Modified the DT to match the device tree in U-Boot. > > 2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled > >as it allows larger storage option for linux distros. > > > > Atish Patra (4): > > RISC-V: Add Microchip PolarFire SoC kconfig option > > dt-bindings: riscv: microchip: Add YAML documentation for the > > PolarFire SoC > > RISC-V: Initial DTS for Microchip ICICLE board > > RISC-V: Enable Microchip PolarFire ICICLE SoC > > > > Conor Dooley (1): > > MAINTAINERS: add microchip polarfire soc support > > > > .../devicetree/bindings/riscv/microchip.yaml | 27 ++ > > MAINTAINERS | 8 + > > arch/riscv/Kconfig.socs | 7 + > > arch/riscv/boot/dts/Makefile | 1 + > > arch/riscv/boot/dts/microchip/Makefile| 2 + > > .../microchip/microchip-mpfs-icicle-kit.dts | 72 > > .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++ > > arch/riscv/configs/defconfig | 4 + > > 8 files changed, 450 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml > > create mode 100644 arch/riscv/boot/dts/microchip/Makefile > > create mode 100644 > > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > I had this left in my inbox waiting for either some reviews to come in or a > v2, > but I don't see any. Did I miss something? > Sorry for the late reply. I am on vacation until May. I think I saw all the patches have already been reviewed. Let me know if it is not the case. > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish
Re: [PATCH v4 1/2] binfmt_flat: allow not offsetting data start
On 17/4/21 2:54 pm, Damien Le Moal wrote:
On 2021/04/17 13:52, Greg Ungerer wrote:
On 17/4/21 11:10 am, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap between the text and data sections
always exists. For architectures which cannot support a such gap
between the text and data sections (e.g. riscv nommu), flat binary
programs cannot be executed.
To allow an architecture to request no data start offset to allow for
contiguous text and data sections for binaries flagged with
FLAT_FLAG_RAM, introduce the new config option
CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET. Using this new option, the
macro DATA_START_OFFSET_WORDS is conditionally defined in binfmt_flat.c
to MAX_SHARED_LIBS for architectures tolerating or needing the data
start offset (CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET disabled case)
and to 0 when CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET is enabled.
DATA_START_OFFSET_WORDS is used in load_flat_file() to calculate the
data section length and start position.
Signed-off-by: Damien Le Moal
---
fs/Kconfig.binfmt | 3 +++
fs/binfmt_flat.c | 19 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index c6f1c8c1934e..06fb7a93a1bd 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -112,6 +112,9 @@ config BINFMT_FLAT_ARGVP_ENVP_ON_STACK
config BINFMT_FLAT_OLD_ALWAYS_RAM
bool
+config BINFMT_FLAT_NO_DATA_START_OFFSET
+ bool
+
config BINFMT_FLAT_OLD
bool "Enable support for very old legacy flat binaries"
depends on BINFMT_FLAT
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index b9c658e0548e..1dc68dfba3e0 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -74,6 +74,12 @@
#define MAX_SHARED_LIBS (1)
#endif
+#ifdef CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET
+#define DATA_START_OFFSET_WORDS(0)
+#else
+#define DATA_START_OFFSET_WORDS(MAX_SHARED_LIBS)
+#endif
+
struct lib_info {
struct {
unsigned long start_code; /* Start of text
segment */
@@ -560,6 +566,7 @@ static int load_flat_file(struct linux_binprm *bprm,
* it all together.
*/
if (!IS_ENABLED(CONFIG_MMU) && !(flags &
(FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
+
Random white space change...
Don't worry about re-spinning though, I will just edit this chunk out.
Oops. Sorry about that. I should have better checked :)
/*
* this should give us a ROM ptr, but if it doesn't we don't
* really care
@@ -576,7 +583,8 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
- len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long);
+ len = data_len + extra +
+ DATA_START_OFFSET_WORDS * sizeof(unsigned long);
len = PAGE_ALIGN(len);
realdatastart = vm_mmap(NULL, 0, len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0);
@@ -591,7 +599,7 @@ static int load_flat_file(struct linux_binprm *bprm,
goto err;
}
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(unsigned long),
+ DATA_START_OFFSET_WORDS * sizeof(unsigned long),
FLAT_DATA_ALIGN);
pr_debug("Allocated data+bss+stack (%u bytes): %lx\n",
@@ -622,7 +630,8 @@ static int load_flat_file(struct linux_binprm *bprm,
memp_size = len;
} else {
- len = text_len + data_len + extra + MAX_SHARED_LIBS * sizeof(u32);
+ len = text_len + data_len + extra +
+ DATA_START_OFFSET_WORDS * sizeof(u32);
len = PAGE_ALIGN(len);
textpos = vm_mmap(NULL, 0, len,
PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0);
@@ -638,7 +647,7 @@ static int load_flat_file(struct linux_binprm *bprm,
realdatastart = textpos + ntohl(hdr->data_start);
datapos = ALIGN(realdatastart +
- MAX_SHARED_LIBS * sizeof(u32),
+ DATA_START_OFFSET_WORDS * sizeof(u32),
FLAT_DATA_ALIGN);
reloc = (__be32 __user *)
@@ -714,7 +723,7 @@ static int load_flat_file(struct linux_binprm *bprm,
ret = result;
pr_err("Unable to read code+data+bss, errno %d\n", ret);
vm_munmap(textpos, text_len + data_len + extra +
- MAX_SHARED_LIBS * sizeof(u32));
+
Re: PROBLEM: DoS Attack on Fragment Cache
Sure, there are better ways to handle the reassembly cache overflowing, but that is pretty unrelated to the fact that waiting 30 full seconds for a fragment to come in doesn't really make sense in today's networks (the 30 second delay that is used today appears to even be higher than RFC 791 suggested in 1981!). You get a lot more bang for your buck if you don't wait around so long (or we could restructure things to kick out the oldest fragments, but that is a lot more work, and probably extra indexes that just aren't worth it). Matt On 4/17/21 21:38, Keyu Man wrote: Willy's words make sense to me and I agree that the existing fragments should be evicted when the new one comes in and the cache is full. Though the attacker can still leverage this to flush the victim's cache, as mentioned previously, since fragments are likely to be assembled in a very short time, it would be hard to launch the attack(evicting the legit fragment before it's assembled requires a large packet sending rate). And this seems better than the existing solution (drop all incoming fragments when full). Keyu On Sat, Apr 17, 2021 at 6:30 PM Matt Corallo wrote: See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s" (and the two resends of it) - given the size of the default cache (4MB) and the time that it takes before we flush the cache (30 seconds) you only need about 1Mbps of fragments to hit this issue. While DoS attacks are concerning, its also incredibly practical (and I do) hit this issue in normal non-adversarial conditions. Matt On 4/17/21 03:50, Willy Tarreau wrote: On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote: How about at least allow the existing queue to finish? Currently a tiny new fragment would potentially invalid all previous fragments by letting them timeout without allowing the fragments to come in to finish the assembly. Because this is exactly the principle of how attacks are built: reserve resources claiming that you'll send everything so that others can't make use of the resources that are reserved to you. The best solution precisely is *not* to wait for anyone to finish, hence *not* to reserve valuable resources that are unusuable by others. Willy
Re: [PATCH 12/12] dt-bindings: soc: qcom: aoss: Delete unused power-domain definitions
Quoting Sibi Sankar (2021-04-16 05:03:58) > Delete unused power-domain definitions exposed by AOSS QMP. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 10/12] arm64: dts: qcom: sm8250: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:56) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8250 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 11/12] arm64: dts: qcom: sm8350: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:57) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8350 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 09/12] arm64: dts: qcom: sm8150: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:55) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8150 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 08/12] arm64: dts: qcom: sdm845: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:54) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SDM845 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 07/12] arm64: dts: qcom: sc7280: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:53) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SC7280 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 06/12] arm64: dts: qcom: sc7180: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:52) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SC7180 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 02/12] soc: qcom: aoss: Drop power domain support
Quoting Sibi Sankar (2021-04-16 05:03:48) > The load state resources are expected to follow the life cycle of the > remote processor it tracks. However, modeling load state resources as > power-domains result in them getting turned off during system suspend > and thereby falling out of sync with the remote processors that are still > on. Fix this by replacing load state resource control through the generic > qmp message send interface instead. > > Signed-off-by: Sibi Sankar > --- Is it possible to keep this code around for a cycle so that there isn't the chance that someone is using the deprecated DT bindings with a new kernel? I worry that ripping the code out will cause them angst. Certainly we have to keep the code in place until DT is updated, so this patch should come last?
Re: [PATCH V2 5/9] platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake
On Sat, 2021-04-17 at 10:52 +0200, Hans de Goede wrote:
> Hi David,
>
> On 4/17/21 5:12 AM, David E. Box wrote:
> > From: Gayatri Kammela
> >
> > Platforms that support low power modes (LPM) such as Tiger Lake
> > maintain
> > requirements for each sub-state that a readable in the PMC.
> > However, unlike
> > LPM status registers, requirement registers are not memory mapped
> > but are
> > available from an ACPI _DSM. Collect the requirements for Tiger
> > Lake using
> > the _DSM method and store in a buffer.
> >
> > Signed-off-by: Gayatri Kammela
> > Co-developed-by: David E. Box
> > Signed-off-by: David E. Box
> > Reviewed-by: Hans de Goede
>
> Erm, I did not give my "Reviewed-by: Hans de Goede <
> hdego...@redhat.com>"
> for this patch, because it still needed some work.
>
> Next time please only add my Reviewed-by to patches where I
> explicitly replied with a Reviewed-by.
Sure thing. Sorry about that.
David
> The same goes for patch 7/9
>
> Regards,
>
> Hans
>
>
>
> > ---
> >
> > V2: - Move buffer allocation so that it does not need to be
> > freed
> > (which was missing anyway) when an error is encountered.
> > - Use label to free out_obj after errors
> > - Use memcpy instead of memcpy_fromio for ACPI memory
> >
> > drivers/platform/x86/intel_pmc_core.c | 56
> > +++
> > drivers/platform/x86/intel_pmc_core.h | 2 +
> > 2 files changed, 58 insertions(+)
> >
> > diff --git a/drivers/platform/x86/intel_pmc_core.c
> > b/drivers/platform/x86/intel_pmc_core.c
> > index 0e59a84b51bf..97efe9a6bd01 100644
> > --- a/drivers/platform/x86/intel_pmc_core.c
> > +++ b/drivers/platform/x86/intel_pmc_core.c
> > @@ -23,7 +23,9 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -31,6 +33,9 @@
> >
> > #include "intel_pmc_core.h"
> >
> > +#define ACPI_S0IX_DSM_UUID "57a6512e-3979-4e9d-9708-
> > ff13b2508972"
> > +#define ACPI_GET_LOW_MODE_REGISTERS1
> > +
> > /* PKGC MSRs are common across Intel Core SoCs */
> > static const struct pmc_bit_map msr_map[] = {
> > {"Package C2", MSR_PKG_C2_RESIDENCY},
> > @@ -590,6 +595,53 @@ static const struct pmc_reg_map tgl_reg_map =
> > {
> > .etr3_offset = ETR3_OFFSET,
> > };
> >
> > +static void pmc_core_get_tgl_lpm_reqs(struct platform_device
> > *pdev)
> > +{
> > + struct pmc_dev *pmcdev = platform_get_drvdata(pdev);
> > + const int num_maps = pmcdev->map->lpm_num_maps;
> > + size_t lpm_size = LPM_MAX_NUM_MODES * num_maps * 4;
> > + union acpi_object *out_obj;
> > + struct acpi_device *adev;
> > + guid_t s0ix_dsm_guid;
> > + u32 *lpm_req_regs, *addr;
> > +
> > + adev = ACPI_COMPANION(>dev);
> > + if (!adev)
> > + return;
> > +
> > + guid_parse(ACPI_S0IX_DSM_UUID, _dsm_guid);
> > +
> > + out_obj = acpi_evaluate_dsm(adev->handle, _dsm_guid,
> > 0,
> > + ACPI_GET_LOW_MODE_REGISTERS,
> > NULL);
> > + if (out_obj && out_obj->type == ACPI_TYPE_BUFFER) {
> > + int size = out_obj->buffer.length;
> > +
> > + if (size != lpm_size) {
> > + acpi_handle_debug(adev->handle,
> > + "_DSM returned unexpected buffer
> > size,"
> > + " have %d, expect %ld\n", size,
> > lpm_size);
> > + goto free_acpi_obj;
> > + }
> > + } else {
> > + acpi_handle_debug(adev->handle,
> > + "_DSM function 0 evaluation
> > failed\n");
> > + goto free_acpi_obj;
> > + }
> > +
> > + addr = (u32 *)out_obj->buffer.pointer;
> > +
> > + lpm_req_regs = devm_kzalloc(>dev, lpm_size *
> > sizeof(u32),
> > + GFP_KERNEL);
> > + if (!lpm_req_regs)
> > + goto free_acpi_obj;
> > +
> > + memcpy(lpm_req_regs, addr, lpm_size);
> > + pmcdev->lpm_req_regs = lpm_req_regs;
> > +
> > +free_acpi_obj:
> > + ACPI_FREE(out_obj);
> > +}
> > +
> > static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int
> > reg_offset)
> > {
> > return readl(pmcdev->regbase + reg_offset);
> > @@ -1424,10 +1476,14 @@ static int pmc_core_probe(struct
> > platform_device *pdev)
> > return -ENOMEM;
> >
> > mutex_init(>lock);
> > +
> > pmcdev->pmc_xram_read_bit =
> > pmc_core_check_read_lock_bit(pmcdev);
> > pmc_core_get_low_power_modes(pmcdev);
> > pmc_core_do_dmi_quirks(pmcdev);
> >
> > + if (pmcdev->map == _reg_map)
> > + pmc_core_get_tgl_lpm_reqs(pdev);
> > +
> > /*
> > * On TGL, due to a hardware limitation, the GBE LTR blocks
> > PC10 when
> > * a cable is attached. Tell the PMC to ignore it.
> > diff --git
Re: [PATCH 03/12] dt-bindings: remoteproc: qcom: pas: Add QMP bindings
Quoting Sibi Sankar (2021-04-16 05:03:49) > Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains > exposed by the AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 04/12] dt-bindings: remoteproc: qcom: Add QMP bindings
Quoting Sibi Sankar (2021-04-16 05:03:50) > Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains > exposed by the AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 01/12] dt-bindings: soc: qcom: aoss: Drop power-domain bindings
Quoting Sibi Sankar (2021-04-16 05:03:47) > Drop power-domain bindings exposed by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH v4 05/13] module: Add printk formats to add module build ID to stacktraces
Quoting Jessica Yu (2021-04-15 06:04:35)
> +++ Stephen Boyd [09/04/21 18:52 -0700]:
> >diff --git a/include/linux/module.h b/include/linux/module.h
> >index 59f094fa6f74..4bf869f6c944 100644
> >--- a/include/linux/module.h
> >+++ b/include/linux/module.h
> >@@ -11,6 +11,7 @@
> >
> > #include
> > #include
> >+#include
> > #include
> > #include
> > #include
> >@@ -367,6 +368,9 @@ struct module {
> > /* Unique handle for this module */
> > char name[MODULE_NAME_LEN];
> >
> >+ /* Module build ID */
> >+ unsigned char build_id[BUILD_ID_SIZE_MAX];
>
> Hi Stephen,
>
> Since this field is not used when !CONFIG_STACKTRACE_BUILD_ID, I
> would prefer to wrap this in an ifdef, similar to the other
> CONFIG-dependent fields in struct module. This makes it explicit under
> what conditions (i.e. config) the field is meant to be used.
Ok will do.
> >diff --git a/kernel/module.c b/kernel/module.c
> >index 30479355ab85..6f5bc1b046a5 100644
> >--- a/kernel/module.c
> >+++ b/kernel/module.c
> >@@ -2770,6 +2771,20 @@ static void add_kallsyms(struct module *mod, const
> >struct load_info *info)
> > }
> > mod->core_kallsyms.num_symtab = ndst;
> > }
> >+
> >+static void init_build_id(struct module *mod, const struct load_info *info)
> >+{
> >+ const Elf_Shdr *sechdr;
> >+ unsigned int i;
> >+
> >+ for (i = 0; i < info->hdr->e_shnum; i++) {
> >+ sechdr = >sechdrs[i];
> >+ if (!sect_empty(sechdr) && sechdr->sh_type == SHT_NOTE &&
> >+ !build_id_parse_buf((void *)sechdr->sh_addr,
> >mod->build_id,
> >+ sechdr->sh_size))
> >+ break;
> >+ }
>
> If mod->build_id is not used when !CONFIG_STACKTRACE_BUILD_ID, then we
> don't need to look for it. I would be fine with wrapping the function
> body in an ifdef (similar to what we currently do in
> del_usage_links() and do_mod_ctors()).
Ok, done.
>
> >+}
> > #else
> > static inline void layout_symtab(struct module *mod, struct load_info *info)
> > {
> >@@ -2778,6 +2793,10 @@ static inline void layout_symtab(struct module *mod,
> >struct load_info *info)
> > static void add_kallsyms(struct module *mod, const struct load_info *info)
> > {
> > }
> >+
> >+static void init_build_id(struct module *mod, const struct load_info *info)
> >+{
> >+}
> > #endif /* CONFIG_KALLSYMS */
> >
> > static void dynamic_debug_setup(struct module *mod, struct _ddebug *debug,
> > unsigned int num)
> >@@ -4004,6 +4023,7 @@ static int load_module(struct load_info *info, const
> >char __user *uargs,
> > goto free_arch_cleanup;
> > }
> >
> >+ init_build_id(mod, info);
> > dynamic_debug_setup(mod, info->debug, info->num_debug);
> >
> > /* Ftrace init must be called in the MODULE_STATE_UNFORMED state */
> >@@ -4235,7 +4255,7 @@ void * __weak
> >dereference_module_function_descriptor(struct module *mod,
> > const char *module_address_lookup(unsigned long addr,
> > unsigned long *size,
> > unsigned long *offset,
> >- char **modname,
> >+ char **modname, const unsigned char **modbuildid,
> > char *namebuf)
> > {
> > const char *ret = NULL;
> >@@ -4246,6 +4266,8 @@ const char *module_address_lookup(unsigned long addr,
> > if (mod) {
> > if (modname)
> > *modname = mod->name;
> >+ if (modbuildid)
> >+ *modbuildid = mod->build_id;
>
> Then maybe we can set *modbuildid = NULL in the case of
> !CONFIG_STACKTRACE_BUILD_ID, similar to the kernel case in
> kallsyms_lookup_buildid().
>
Sounds good. It means that some more ifdefs are probably required vs.
making the array size be 0 when the config is disabled but that isn't a
big problem for me. I'm reworking the code now and will test and then
send v5 shortly. Thanks!
[GIT PULL] SCSI fixes for 5.12-rc6
This libsas fix is for a problem that occurs when trying to change the
cache type of an ATA device and the libiscsi one is a regression fix
from this merge window.
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Jolly Shah (1):
scsi: libsas: Reset num_scatter if libata marks qc as NODATA
Mike Christie (1):
scsi: iscsi: Fix iSCSI cls conn state
And the diffstat:
drivers/scsi/libiscsi.c | 26 +++---
drivers/scsi/libsas/sas_ata.c | 9 -
drivers/scsi/scsi_transport_iscsi.c | 18 +++---
3 files changed, 22 insertions(+), 31 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 7ad11e42306d..bfd2aaa9b66b 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3179,9 +3179,10 @@ fail_mgmt_tasks(struct iscsi_session *session, struct
iscsi_conn *conn)
}
}
-static void iscsi_start_session_recovery(struct iscsi_session *session,
-struct iscsi_conn *conn, int flag)
+void iscsi_conn_stop(struct iscsi_cls_conn *cls_conn, int flag)
{
+ struct iscsi_conn *conn = cls_conn->dd_data;
+ struct iscsi_session *session = conn->session;
int old_stop_stage;
mutex_lock(>eh_mutex);
@@ -3239,27 +3240,6 @@ static void iscsi_start_session_recovery(struct
iscsi_session *session,
spin_unlock_bh(>frwd_lock);
mutex_unlock(>eh_mutex);
}
-
-void iscsi_conn_stop(struct iscsi_cls_conn *cls_conn, int flag)
-{
- struct iscsi_conn *conn = cls_conn->dd_data;
- struct iscsi_session *session = conn->session;
-
- switch (flag) {
- case STOP_CONN_RECOVER:
- cls_conn->state = ISCSI_CONN_FAILED;
- break;
- case STOP_CONN_TERM:
- cls_conn->state = ISCSI_CONN_DOWN;
- break;
- default:
- iscsi_conn_printk(KERN_ERR, conn,
- "invalid stop flag %d\n", flag);
- return;
- }
-
- iscsi_start_session_recovery(session, conn, flag);
-}
EXPORT_SYMBOL_GPL(iscsi_conn_stop);
int iscsi_conn_bind(struct iscsi_cls_session *cls_session,
diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 024e5a550759..8b9a39077dba 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -201,18 +201,17 @@ static unsigned int sas_ata_qc_issue(struct
ata_queued_cmd *qc)
memcpy(task->ata_task.atapi_packet, qc->cdb, qc->dev->cdb_len);
task->total_xfer_len = qc->nbytes;
task->num_scatter = qc->n_elem;
+ task->data_dir = qc->dma_dir;
+ } else if (qc->tf.protocol == ATA_PROT_NODATA) {
+ task->data_dir = DMA_NONE;
} else {
for_each_sg(qc->sg, sg, qc->n_elem, si)
xfer += sg_dma_len(sg);
task->total_xfer_len = xfer;
task->num_scatter = si;
- }
-
- if (qc->tf.protocol == ATA_PROT_NODATA)
- task->data_dir = DMA_NONE;
- else
task->data_dir = qc->dma_dir;
+ }
task->scatter = qc->sg;
task->ata_task.retry_count = 1;
task->task_state_flags = SAS_TASK_STATE_PENDING;
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index bebfb355abdf..21a2d997a72e 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2470,10 +2470,22 @@ static void iscsi_if_stop_conn(struct iscsi_cls_conn
*conn, int flag)
* it works.
*/
mutex_lock(_mutex);
+ switch (flag) {
+ case STOP_CONN_RECOVER:
+ conn->state = ISCSI_CONN_FAILED;
+ break;
+ case STOP_CONN_TERM:
+ conn->state = ISCSI_CONN_DOWN;
+ break;
+ default:
+ iscsi_cls_conn_printk(KERN_ERR, conn,
+ "invalid stop flag %d\n", flag);
+ goto unlock;
+ }
+
conn->transport->stop_conn(conn, flag);
- conn->state = ISCSI_CONN_DOWN;
+unlock:
mutex_unlock(_mutex);
-
}
static void stop_conn_work_fn(struct work_struct *work)
@@ -2961,7 +2973,7 @@ static int iscsi_if_ep_disconnect(struct iscsi_transport
*transport,
mutex_lock(>ep_mutex);
conn->ep = NULL;
mutex_unlock(>ep_mutex);
- conn->state = ISCSI_CONN_DOWN;
+ conn->state = ISCSI_CONN_FAILED;
}
transport->ep_disconnect(ep);
Re: [PATCH V2 5/9] platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake
On Sat, 2021-04-17 at 11:00 +0200, Hans de Goede wrote:
> Hi,
>
> On 4/17/21 5:12 AM, David E. Box wrote:
> > From: Gayatri Kammela
> >
> > Platforms that support low power modes (LPM) such as Tiger Lake
> > maintain
> > requirements for each sub-state that a readable in the PMC.
> > However, unlike
> > LPM status registers, requirement registers are not memory mapped
> > but are
> > available from an ACPI _DSM. Collect the requirements for Tiger
> > Lake using
> > the _DSM method and store in a buffer.
> >
> > Signed-off-by: Gayatri Kammela
> > Co-developed-by: David E. Box
> > Signed-off-by: David E. Box
> > Reviewed-by: Hans de Goede
> > ---
> >
> > V2: - Move buffer allocation so that it does not need to be
> > freed
> > (which was missing anyway) when an error is encountered.
> > - Use label to free out_obj after errors
> > - Use memcpy instead of memcpy_fromio for ACPI memory
> >
> > drivers/platform/x86/intel_pmc_core.c | 56
> > +++
> > drivers/platform/x86/intel_pmc_core.h | 2 +
> > 2 files changed, 58 insertions(+)
> >
> > diff --git a/drivers/platform/x86/intel_pmc_core.c
> > b/drivers/platform/x86/intel_pmc_core.c
> > index 0e59a84b51bf..97efe9a6bd01 100644
> > --- a/drivers/platform/x86/intel_pmc_core.c
> > +++ b/drivers/platform/x86/intel_pmc_core.c
> > @@ -23,7 +23,9 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -31,6 +33,9 @@
> >
> > #include "intel_pmc_core.h"
> >
> > +#define ACPI_S0IX_DSM_UUID "57a6512e-3979-4e9d-9708-
> > ff13b2508972"
> > +#define ACPI_GET_LOW_MODE_REGISTERS1
> > +
> > /* PKGC MSRs are common across Intel Core SoCs */
> > static const struct pmc_bit_map msr_map[] = {
> > {"Package C2", MSR_PKG_C2_RESIDENCY},
> > @@ -590,6 +595,53 @@ static const struct pmc_reg_map tgl_reg_map =
> > {
> > .etr3_offset = ETR3_OFFSET,
> > };
> >
> > +static void pmc_core_get_tgl_lpm_reqs(struct platform_device
> > *pdev)
> > +{
> > + struct pmc_dev *pmcdev = platform_get_drvdata(pdev);
> > + const int num_maps = pmcdev->map->lpm_num_maps;
> > + size_t lpm_size = LPM_MAX_NUM_MODES * num_maps * 4;
>
> The type of lpm_size should be an u32, so that it matches
> the type of out_obj->buffer.length.
>
> > + union acpi_object *out_obj;
> > + struct acpi_device *adev;
> > + guid_t s0ix_dsm_guid;
> > + u32 *lpm_req_regs, *addr;
> > +
> > + adev = ACPI_COMPANION(>dev);
> > + if (!adev)
> > + return;
> > +
> > + guid_parse(ACPI_S0IX_DSM_UUID, _dsm_guid);
> > +
> > + out_obj = acpi_evaluate_dsm(adev->handle, _dsm_guid,
> > 0,
> > + ACPI_GET_LOW_MODE_REGISTERS,
> > NULL);
> > + if (out_obj && out_obj->type == ACPI_TYPE_BUFFER) {
> > + int size = out_obj->buffer.length;
>
> out_obj->buffer.length is an u32, please make this an u32 too.
>
> > +
> > + if (size != lpm_size) {
> > + acpi_handle_debug(adev->handle,
> > + "_DSM returned unexpected buffer
> > size,"
> > + " have %d, expect %ld\n", size,
> > lpm_size);
>
> And use %u here (twice), this should also fix the warnings reported
> by the kernel test robot.
>
> If there are no objections against the suggested changes, then I can
> fix this up while merging this.
>
> Please let me know if the suggested changes are ok with you.
Changes are good with me. Thanks for the fixup.
David
>
> Regards,
>
> Hans
>
>
> > + goto free_acpi_obj;
> > + }
> > + } else {
> > + acpi_handle_debug(adev->handle,
> > + "_DSM function 0 evaluation
> > failed\n");
> > + goto free_acpi_obj;
> > + }
> > +
> > + addr = (u32 *)out_obj->buffer.pointer;
> > +
> > + lpm_req_regs = devm_kzalloc(>dev, lpm_size *
> > sizeof(u32),
> > + GFP_KERNEL);
> > + if (!lpm_req_regs)
> > + goto free_acpi_obj;
> > +
> > + memcpy(lpm_req_regs, addr, lpm_size);
> > + pmcdev->lpm_req_regs = lpm_req_regs;
> > +
> > +free_acpi_obj:
> > + ACPI_FREE(out_obj);
> > +}
> > +
> > static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int
> > reg_offset)
> > {
> > return readl(pmcdev->regbase + reg_offset);
> > @@ -1424,10 +1476,14 @@ static int pmc_core_probe(struct
> > platform_device *pdev)
> > return -ENOMEM;
> >
> > mutex_init(>lock);
> > +
> > pmcdev->pmc_xram_read_bit =
> > pmc_core_check_read_lock_bit(pmcdev);
> > pmc_core_get_low_power_modes(pmcdev);
> > pmc_core_do_dmi_quirks(pmcdev);
> >
> > + if (pmcdev->map == _reg_map)
> > + pmc_core_get_tgl_lpm_reqs(pdev);
> > +
> >
Re: PROBLEM: DoS Attack on Fragment Cache
Willy's words make sense to me and I agree that the existing fragments should be evicted when the new one comes in and the cache is full. Though the attacker can still leverage this to flush the victim's cache, as mentioned previously, since fragments are likely to be assembled in a very short time, it would be hard to launch the attack(evicting the legit fragment before it's assembled requires a large packet sending rate). And this seems better than the existing solution (drop all incoming fragments when full). Keyu On Sat, Apr 17, 2021 at 6:30 PM Matt Corallo wrote: > > See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from > 30s" (and the two resends of it) - given > the size of the default cache (4MB) and the time that it takes before we > flush the cache (30 seconds) you only need > about 1Mbps of fragments to hit this issue. While DoS attacks are concerning, > its also incredibly practical (and I do) > hit this issue in normal non-adversarial conditions. > > Matt > > On 4/17/21 03:50, Willy Tarreau wrote: > > On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote: > >> How about at least allow the existing queue to finish? Currently a tiny new > >> fragment would potentially invalid all previous fragments by letting them > >> timeout without allowing the fragments to come in to finish the assembly. > > > > Because this is exactly the principle of how attacks are built: reserve > > resources claiming that you'll send everything so that others can't make > > use of the resources that are reserved to you. The best solution precisely > > is *not* to wait for anyone to finish, hence *not* to reserve valuable > > resources that are unusuable by others. > > > > Willy > >
Re: [PATCH 0/9] sched: Core scheduling interfaces
On Tue, Apr 06, 2021 at 10:16:12AM -0400, Tejun Heo wrote: > Hello, > > On Mon, Apr 05, 2021 at 02:46:09PM -0400, Joel Fernandes wrote: > > Yeah, its at http://lore.kernel.org/r/20200822030155.ga414...@google.com > > as mentioned above, let me know if you need any more details about > > usecase. > > Except for the unspecified reason in usecase 4, I don't see why cgroup is in > the picture at all. This doesn't really have much to do with hierarchical > resource distribution. Besides, yes, you can use cgroup for logical > structuring and identificaiton purposes but in those cases the interactions > and interface should be with the original subsystem while using cgroup IDs > or paths as parameters - see tracing and bpf for examples. Personally for ChromeOS, we need only the per-task interface. Considering that the second argument of this prctl is a command, I don't see why we cannot add a new command PR_SCHED_CORE_CGROUP_SHARE to do what Tejun is saying (in the future). In order to not block ChromeOS and other "per-task interface" usecases, I suggest we keep the CGroup interface for a later time (whether that's through prctl or the CGroups FS way which Tejun dislikes) and move forward with per-task interface only initially. Peter, any thoughts on this? thanks, - Joel
Re: PROBLEM: DoS Attack on Fragment Cache
See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s" (and the two resends of it) - given the size of the default cache (4MB) and the time that it takes before we flush the cache (30 seconds) you only need about 1Mbps of fragments to hit this issue. While DoS attacks are concerning, its also incredibly practical (and I do) hit this issue in normal non-adversarial conditions. Matt On 4/17/21 03:50, Willy Tarreau wrote: On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote: How about at least allow the existing queue to finish? Currently a tiny new fragment would potentially invalid all previous fragments by letting them timeout without allowing the fragments to come in to finish the assembly. Because this is exactly the principle of how attacks are built: reserve resources claiming that you'll send everything so that others can't make use of the resources that are reserved to you. The best solution precisely is *not* to wait for anyone to finish, hence *not* to reserve valuable resources that are unusuable by others. Willy
Re: [PATCH] media: atomisp: silence "dubious: !x | !y" warning
On Sat, Apr 17, 2021 at 08:56:13PM +0200, Mauro Carvalho Chehab wrote: > Em Sat, 17 Apr 2021 21:06:27 +0530 > Ashish Kalra escreveu: > > > Upon running sparse, "warning: dubious: !x | !y" is brought to notice > > for this file. Logical and bitwise OR are basically the same in this > > context so it doesn't cause a runtime bug. But let's change it to > > logical OR to make it cleaner and silence the Sparse warning. > > > > Signed-off-by: Ashish Kalra > > --- > > .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > index 358cb7d2cd4c..3b850bb2d39d 100644 > > --- > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > +++ > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( > > unsigned int ds_log2 = 0; > > unsigned int out_width; > > > > - if ((!out_info) | (!vf_info)) > > + if ((!out_info) || (!vf_info)) > > > While here, please get rid of the unneeded parenthesis: > > if (!out_info || !vf_info) > > > > return -EINVAL; > > > > out_width = out_info->res.width; > > > > Thanks, > Mauro Updated Patch as per your feedback Thanks Ashish >From 770317157c3a7abf2fda1d71b0bd651c33bf0bfa Mon Sep 17 00:00:00 2001 From: Ashish Kalra Date: Sun, 18 Apr 2021 06:52:03 +0530 Subject: [PATCH] media: atomisp: silence "dubious: !x | !y" warning Upon running sparse, "warning: dubious: !x | !y" is brought to notice for this file. Logical and bitwise OR are basically the same in this context so it doesn't cause a runtime bug. But let's change it to logical OR to make it cleaner and silence the Sparse warning. Signed-off-by: Ashish Kalra --- .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c index 358cb7d2cd4c..71c3e7dac052 100644 --- a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c +++ b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( unsigned int ds_log2 = 0; unsigned int out_width; - if ((!out_info) | (!vf_info)) + if (!out_info || !vf_info) return -EINVAL; out_width = out_info->res.width; -- 2.25.1
Re: [PATCH] media: atomisp: silence "dubious: !x | !y" warning
On Sat, Apr 17, 2021 at 09:31:32PM +, David Laight wrote: > From: Mauro Carvalho Chehab > > Sent: 17 April 2021 19:56 > > > > Em Sat, 17 Apr 2021 21:06:27 +0530 > > Ashish Kalra escreveu: > > > > > Upon running sparse, "warning: dubious: !x | !y" is brought to notice > > > for this file. Logical and bitwise OR are basically the same in this > > > context so it doesn't cause a runtime bug. But let's change it to > > > logical OR to make it cleaner and silence the Sparse warning. > > The old code is very likely to by slightly more efficient. > > It may not matter here, but it might in a really hot path. > > Since !x | !y and !x || !y always have the same value > why is sparse complaining at all. > > David This warning is coming from sparse as per below explanation As the name suggests, a "bitwise" expression is one that is restricted to only a certain "bitwise" operations that make sense within that class. In particular, you can't mix a "bitwise" class with a normal integer expression Warning: int __bitwise i; int __bitwise j; the two variables "i" and "j" are _not_ compatible, simply because they were declared separately, while in the case of int __bitwise i, j; they _are_ compatible. https://yarchive.net/comp/linux/sparse.html > > > > > > > Signed-off-by: Ashish Kalra > > > --- > > > .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git > > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > > index 358cb7d2cd4c..3b850bb2d39d 100644 > > > --- > > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > > +++ > > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > > @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( > > > unsigned int ds_log2 = 0; > > > unsigned int out_width; > > > > > > - if ((!out_info) | (!vf_info)) > > > + if ((!out_info) || (!vf_info)) > > > > > > While here, please get rid of the unneeded parenthesis: > > > > if (!out_info || !vf_info) > > > > > > > return -EINVAL; > > > > > > out_width = out_info->res.width; > > > > > > > > Thanks, > > Mauro > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales) >
[tip:timers/core] BUILD SUCCESS 2d036dfa5f10df9782f5278fc591d79d283c1fad
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core branch HEAD: 2d036dfa5f10df9782f5278fc591d79d283c1fad posix-timers: Preserve return value in clock_adjtime32() elapsed time: 724m configs tested: 100 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig powerpc pcm030_defconfig powerpc pasemi_defconfig m68k amiga_defconfig ia64 tiger_defconfig mips decstation_64_defconfig powerpcicon_defconfig powerpc arches_defconfig armvexpress_defconfig powerpc eiger_defconfig shhp6xx_defconfig armtrizeps4_defconfig mips gcw0_defconfig arm aspeed_g5_defconfig xtensasmp_lx200_defconfig powerpc sbc8548_defconfig sh rts7751r2dplus_defconfig powerpc ppc44x_defconfig arm bcm2835_defconfig powerpcsocrates_defconfig arm rpc_defconfig arm footbridge_defconfig armneponset_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a003-20210417 x86_64 randconfig-a002-20210417 x86_64 randconfig-a005-20210417 x86_64 randconfig-a001-20210417 x86_64 randconfig-a006-20210417 x86_64 randconfig-a004-20210417 i386 randconfig-a003-20210417 i386 randconfig-a006-20210417 i386 randconfig-a001-20210417 i386 randconfig-a005-20210417 i386 randconfig-a004-20210417 i386 randconfig-a002-20210417 i386 randconfig-a015-20210417 i386 randconfig-a014-20210417 i386 randconfig-a013-20210417 i386 randconfig-a012-20210417 i386 randconfig-a016-20210417 i386 randconfig-a011-20210417 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a014-20210417 x86_64 randconfig-a015-20210417 x86_64 randconfig-a011-20210417 x86_64 randconfig-a013-20210417 x86_64 randconfig-a012-20210417 x86_64 randconfig-a016
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
On Sat, Apr 17, 2021 at 03:11:49PM -0700, Linus Torvalds wrote:
> On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote:
> >
> > No, wait - we have non-NULL buf->prev_reclen, so we'll hit
> > with buf->error completely ignored. Nevermind.
>
> Yeah, I'm pretty sure I even tested that -EINTR case at one point.
>
> Of course, it could easily have gotten broken again, so that's not a
> strong argument.
>
> That said, the "buf->err" handling has always been very confusing, and
> it would be lovely to get rid of that confusion.
>
> I don't remember why we did it that way, but I think it's because
> low-level filesystems ended up changing the error that the filldir()
> function returned or something like that.
Propagating errors from e.g. filldir() out through ->iterate() instances
turns out to be painful. If anything, considering that there's a lot
more ->iterate/->iterate_shared instances that ->actor ones, it would
make sense to change the calling conventions for the latter. IOW,
stop pretending that they return an error value and just have them
return a bool: "should the caller keep going".
Here's what I've got sitting in a local branch; not sure if it would
be better to invert the rules, though - I went for "should we keep
going", but we could do "should we stop" instead.
Change calling conventions for filldir_t
filldir_t instances (directory iterators callbacks) used to return 0 for
"OK, keep going" or -E... for "stop". Note that it's *NOT* how the
error values are reported - the rules for those are callback-dependent
and ->iterate{,_shared}() instances only care about zero vs. non-zero
(look at emit_dir() and friends).
So let's just return bool - it's less confusing that way.
Signed-off-by: Al Viro
---
diff --git a/Documentation/filesystems/porting.rst
b/Documentation/filesystems/porting.rst
index 0302035781be..268c2ac616d1 100644
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@ -890,3 +890,14 @@ been called or returned with non -EIOCBQUEUED code.
mnt_want_write_file() can now only be paired with mnt_drop_write_file(),
whereas previously it could be paired with mnt_drop_write() as well.
+
+---
+
+*mandatory*
+
+filldir_t (readdir callbacks) calling conventions have changed. Instead of
+returning 0 or -E... it returns bool now. true means "keep going" (as 0 used
+to to) and false - "no more" (as -E... in old calling conventions). Rationale:
+callers never looked at specific -E... values anyway. ->iterate() and
+->iterate_shared() instance require no changes at all, all filldir_t ones in
+the tree converted.
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index d5367a1c6300..6864794b663a 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -107,7 +107,7 @@ struct osf_dirent_callback {
int error;
};
-static int
+static bool
osf_filldir(struct dir_context *ctx, const char *name, int namlen,
loff_t offset, u64 ino, unsigned int d_type)
{
@@ -119,11 +119,11 @@ osf_filldir(struct dir_context *ctx, const char *name,
int namlen,
buf->error = -EINVAL; /* only used if we fail */
if (reclen > buf->count)
- return -EINVAL;
+ return false;
d_ino = ino;
if (sizeof(d_ino) < sizeof(ino) && d_ino != ino) {
buf->error = -EOVERFLOW;
- return -EOVERFLOW;
+ return false;
}
if (buf->basep) {
if (put_user(offset, buf->basep))
@@ -140,10 +140,10 @@ osf_filldir(struct dir_context *ctx, const char *name,
int namlen,
dirent = (void __user *)dirent + reclen;
buf->dirent = dirent;
buf->count -= reclen;
- return 0;
+ return true;
Efault:
buf->error = -EFAULT;
- return -EFAULT;
+ return false;
}
SYSCALL_DEFINE4(osf_getdirentries, unsigned int, fd,
diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index 714fcca9af99..aa3bdf389d47 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -24,9 +24,9 @@ static int afs_readdir(struct file *file, struct dir_context
*ctx);
static int afs_d_revalidate(struct dentry *dentry, unsigned int flags);
static int afs_d_delete(const struct dentry *dentry);
static void afs_d_iput(struct dentry *dentry, struct inode *inode);
-static int afs_lookup_one_filldir(struct dir_context *ctx, const char *name,
int nlen,
+static bool afs_lookup_one_filldir(struct dir_context *ctx, const char *name,
int nlen,
loff_t fpos, u64 ino, unsigned dtype);
-static int afs_lookup_filldir(struct dir_context *ctx, const char *name, int
nlen,
+static bool afs_lookup_filldir(struct dir_context *ctx, const char *name, int
nlen,
loff_t fpos, u64 ino, unsigned dtype);
static int afs_create(struct user_namespace *mnt_userns, struct inode *dir,
struct dentry *dentry, umode_t mode, bool excl);
@@ -527,7 +527,7 @@ static int
[PATCH] crypto: camellia: drop duplicate "depends on CRYPTO"
All 5 CAMELLIA crypto driver Kconfig symbols have a duplicate
"depends on CRYPTO" line but they are inside an
"if CRYPTO"/"endif # if CRYPTO" block, so drop the duplicate "depends"
lines.
These 5 symbols still depend on CRYPTO.
Fixes: 584fffc8b196 ("[CRYPTO] kconfig: Ordering cleanup")
Fixes: 0b95ec56ae19 ("crypto: camellia - add assembler implementation for
x86_64")
Fixes: d9b1d2e7e10d ("crypto: camellia - add AES-NI/AVX/x86_64 assembler
implementation of camellia cipher")
Fixes: f3f935a76aa0 ("crypto: camellia - add AVX2/AES-NI/x86_64 assembler
implementation of camellia cipher")
Fixes: c5aac2df6577 ("sparc64: Add DES driver making use of the new des
opcodes.")
Signed-off-by: Randy Dunlap
Cc: Sebastian Siewior
Cc: Jussi Kivilinna
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
---
crypto/Kconfig |5 -
1 file changed, 5 deletions(-)
--- linux-next-20210416.orig/crypto/Kconfig
+++ linux-next-20210416/crypto/Kconfig
@@ -1223,7 +1223,6 @@ config CRYPTO_BLOWFISH_X86_64
config CRYPTO_CAMELLIA
tristate "Camellia cipher algorithms"
- depends on CRYPTO
select CRYPTO_ALGAPI
help
Camellia cipher algorithms module.
@@ -1239,7 +1238,6 @@ config CRYPTO_CAMELLIA
config CRYPTO_CAMELLIA_X86_64
tristate "Camellia cipher algorithm (x86_64)"
depends on X86 && 64BIT
- depends on CRYPTO
select CRYPTO_SKCIPHER
imply CRYPTO_CTR
help
@@ -1256,7 +1254,6 @@ config CRYPTO_CAMELLIA_X86_64
config CRYPTO_CAMELLIA_AESNI_AVX_X86_64
tristate "Camellia cipher algorithm (x86_64/AES-NI/AVX)"
depends on X86 && 64BIT
- depends on CRYPTO
select CRYPTO_SKCIPHER
select CRYPTO_CAMELLIA_X86_64
select CRYPTO_SIMD
@@ -1275,7 +1272,6 @@ config CRYPTO_CAMELLIA_AESNI_AVX_X86_64
config CRYPTO_CAMELLIA_AESNI_AVX2_X86_64
tristate "Camellia cipher algorithm (x86_64/AES-NI/AVX2)"
depends on X86 && 64BIT
- depends on CRYPTO
select CRYPTO_CAMELLIA_AESNI_AVX_X86_64
help
Camellia cipher algorithm module (x86_64/AES-NI/AVX2).
@@ -1291,7 +1287,6 @@ config CRYPTO_CAMELLIA_AESNI_AVX2_X86_64
config CRYPTO_CAMELLIA_SPARC64
tristate "Camellia cipher algorithm (SPARC64)"
depends on SPARC64
- depends on CRYPTO
select CRYPTO_ALGAPI
select CRYPTO_SKCIPHER
help
[PATCH 2/3] rtc: pcf8523: add alarm support
Alarm support requires unconditionally disabling clock out because it is
using the int1 pin.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pcf8523.c | 181 +-
1 file changed, 180 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-pcf8523.c b/drivers/rtc/rtc-pcf8523.c
index fe3ab41d8326..feadab8e3bd3 100644
--- a/drivers/rtc/rtc-pcf8523.c
+++ b/drivers/rtc/rtc-pcf8523.c
@@ -8,10 +8,15 @@
#include
#include
#include
+#include
#define REG_CONTROL1 0x00
#define REG_CONTROL1_CAP_SEL BIT(7)
#define REG_CONTROL1_STOPBIT(5)
+#define REG_CONTROL1_AIEBIT(1)
+
+#define REG_CONTROL2 0x01
+#define REG_CONTROL2_AF BIT(3)
#define REG_CONTROL3 0x02
#define REG_CONTROL3_PM_BLD BIT(7) /* battery low detection disabled */
@@ -30,9 +35,22 @@
#define REG_MONTHS 0x08
#define REG_YEARS0x09
+#define REG_MINUTE_ALARM 0x0a
+#define REG_HOUR_ALARM 0x0b
+#define REG_DAY_ALARM 0x0c
+#define REG_WEEKDAY_ALARM 0x0d
+#define ALARM_DIS BIT(7)
+
#define REG_OFFSET 0x0e
#define REG_OFFSET_MODE BIT(7)
+#define REG_TMR_CLKOUT_CTRL 0x0f
+
+struct pcf8523 {
+ struct rtc_device *rtc;
+ struct i2c_client *client;
+};
+
static int pcf8523_read(struct i2c_client *client, u8 reg, u8 *valuep)
{
struct i2c_msg msgs[2];
@@ -138,6 +156,27 @@ static int pcf8523_set_pm(struct i2c_client *client, u8 pm)
return 0;
}
+static irqreturn_t pcf8523_irq(int irq, void *dev_id)
+{
+ struct pcf8523 *pcf8523 = i2c_get_clientdata(dev_id);
+ u8 value;
+ int err;
+
+ err = pcf8523_read(pcf8523->client, REG_CONTROL2, );
+ if (err < 0)
+ return IRQ_HANDLED;
+
+ if (value & REG_CONTROL2_AF) {
+ value &= ~REG_CONTROL2_AF;
+ pcf8523_write(pcf8523->client, REG_CONTROL2, value);
+ rtc_update_irq(pcf8523->rtc, 1, RTC_IRQF | RTC_AF);
+
+ return IRQ_HANDLED;
+ }
+
+ return IRQ_NONE;
+}
+
static int pcf8523_stop_rtc(struct i2c_client *client)
{
u8 value;
@@ -257,6 +296,111 @@ static int pcf8523_rtc_set_time(struct device *dev,
struct rtc_time *tm)
return pcf8523_start_rtc(client);
}
+static int pcf8523_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *tm)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ u8 start = REG_MINUTE_ALARM, regs[4];
+ struct i2c_msg msgs[2];
+ u8 value;
+ int err;
+
+ msgs[0].addr = client->addr;
+ msgs[0].flags = 0;
+ msgs[0].len = 1;
+ msgs[0].buf =
+
+ msgs[1].addr = client->addr;
+ msgs[1].flags = I2C_M_RD;
+ msgs[1].len = sizeof(regs);
+ msgs[1].buf = regs;
+
+ err = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+ if (err < 0)
+ return err;
+
+ tm->time.tm_sec = 0;
+ tm->time.tm_min = bcd2bin(regs[0] & 0x7F);
+ tm->time.tm_hour = bcd2bin(regs[1] & 0x3F);
+ tm->time.tm_mday = bcd2bin(regs[2] & 0x3F);
+ tm->time.tm_wday = bcd2bin(regs[3] & 0x7);
+
+ err = pcf8523_read(client, REG_CONTROL1, );
+ if (err < 0)
+ return err;
+ tm->enabled = !!(value & REG_CONTROL1_AIE);
+
+ err = pcf8523_read(client, REG_CONTROL2, );
+ if (err < 0)
+ return err;
+ tm->pending = !!(value & REG_CONTROL2_AF);
+
+ return 0;
+}
+
+static int pcf8523_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ u8 value;
+ int err;
+
+ err = pcf8523_read(client, REG_CONTROL1, );
+ if (err < 0)
+ return err;
+
+ value &= REG_CONTROL1_AIE;
+
+ if (enabled)
+ value |= REG_CONTROL1_AIE;
+
+ err = pcf8523_write(client, REG_CONTROL1, value);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int pcf8523_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *tm)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_msg msg;
+ u8 regs[5];
+ int err;
+
+ err = pcf8523_irq_enable(dev, 0);
+ if (err)
+ return err;
+
+ err = pcf8523_write(client, REG_CONTROL2, 0);
+ if (err < 0)
+ return err;
+
+ /* The alarm has no seconds, round up to nearest minute */
+ if (tm->time.tm_sec) {
+ time64_t alarm_time = rtc_tm_to_time64(>time);
+
+ alarm_time += 60 - tm->time.tm_sec;
+ rtc_time64_to_tm(alarm_time, >time);
+ }
+
+ regs[0] = REG_MINUTE_ALARM;
+ regs[1] = bin2bcd(tm->time.tm_min);
+ regs[2] = bin2bcd(tm->time.tm_hour);
+ regs[3] = bin2bcd(tm->time.tm_mday);
+ regs[4] = ALARM_DIS;
+ msg.addr = client->addr;
+ msg.flags = 0;
+ msg.len = sizeof(regs);
+ msg.buf = regs;
+ err = i2c_transfer(client->adapter, , 1);
+ if (err < 0)
+
[PATCH 3/3] rtc: pcf8523: report oscillator failures
Report oscillator failures and invalid date/time on RTC_VL_READ.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pcf8523.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8523.c b/drivers/rtc/rtc-pcf8523.c
index feadab8e3bd3..bb23379bbfc7 100644
--- a/drivers/rtc/rtc-pcf8523.c
+++ b/drivers/rtc/rtc-pcf8523.c
@@ -406,6 +406,8 @@ static int pcf8523_rtc_ioctl(struct device *dev, unsigned
int cmd,
unsigned long arg)
{
struct i2c_client *client = to_i2c_client(dev);
+ unsigned int flags = 0;
+ u8 value;
int ret;
switch (cmd) {
@@ -414,9 +416,16 @@ static int pcf8523_rtc_ioctl(struct device *dev, unsigned
int cmd,
if (ret < 0)
return ret;
if (ret)
- ret = RTC_VL_BACKUP_LOW;
+ flags |= RTC_VL_BACKUP_LOW;
+
+ ret = pcf8523_read(client, REG_SECONDS, );
+ if (ret < 0)
+ return ret;
+
+ if (value & REG_SECONDS_OS)
+ flags |= RTC_VL_DATA_INVALID;
- return put_user(ret, (unsigned int __user *)arg);
+ return put_user(flags, (unsigned int __user *)arg);
default:
return -ENOIOCTLCMD;
--
2.30.2
[PATCH 1/3] rtc: pcf8523: remove useless define
Drop DRIVER_NAME as it is only used once
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pcf8523.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8523.c b/drivers/rtc/rtc-pcf8523.c
index 5e1e7b2a8c9a..fe3ab41d8326 100644
--- a/drivers/rtc/rtc-pcf8523.c
+++ b/drivers/rtc/rtc-pcf8523.c
@@ -9,8 +9,6 @@
#include
#include
-#define DRIVER_NAME "rtc-pcf8523"
-
#define REG_CONTROL1 0x00
#define REG_CONTROL1_CAP_SEL BIT(7)
#define REG_CONTROL1_STOPBIT(5)
@@ -373,7 +371,7 @@ MODULE_DEVICE_TABLE(of, pcf8523_of_match);
static struct i2c_driver pcf8523_driver = {
.driver = {
- .name = DRIVER_NAME,
+ .name = "rtc-pcf8523",
.of_match_table = of_match_ptr(pcf8523_of_match),
},
.probe = pcf8523_probe,
--
2.30.2
Re: [PATCH 05/15] x86: Implement function_nocfi
On Sat, Apr 17, 2021 at 4:53 PM Thomas Gleixner wrote: > > On Sat, Apr 17 2021 at 16:19, Andy Lutomirski wrote: > > On Fri, Apr 16, 2021 at 4:40 PM Kees Cook wrote: > >> Okay, you're saying you want __builtin_gimme_body_p() to be a constant > >> expression for the compiler, not inline asm? > > > > Yes. > > > > I admit that, in the trivial case where the asm code is *not* a > > C-ABI-compliant function, giving a type that doesn't fool the compiler > > into thinking that it might be is probably the best fix. Maybe we > > should standardize something, e.g.: > > > > struct raw_symbol; /* not defined anywhere */ > > #define DECLARE_RAW_SYMBOL(x) struct raw_symbol x[] > > > > and then we write this: > > > > DECLARE_RAW_SYMBOL(entry_SYSCALL_64); > > > > wrmsrl(..., (unsigned long)entry_SYSCALL_64); > > > > It would be a bit nifty if we didn't need a forward declaration, but > > I'm not immediately seeing a way to do this without hacks that we'll > > probably regret; > > > > But this doesn't help the case in which the symbol is an actual > > C-callable function and we want to be able to call it, too. > > The right way to solve this is that the compiler provides a builtin > > function_nocfi() +/- the naming bikeshed > > which works for > > foo = function_nocfi(bar); I agree in general. But right now, we have, in asm/proto.h: void entry_SYSCALL_64(void); and that's pure nonsense. Depending on your point of view, entry_SYSCALL_64 is a symbol that resolves to an integer or it's an array of bytes containing instructions, but it is most definitely not a function void (void). So, regardless of any CFI stuff, I propose that we standardize our handling of prototypes of symbols that are opaque to the C compiler. Here are a couple of choices: Easy one: extern u8 entry_SYSCALL_64[]; Slightly more complicated: struct opaque_symbol; extern struct opaque_symbol entry_SYSCALL_64; The opaque_symbol variant avoids any possible confusion over the weird status of arrays in C, and it's hard to misuse, since struct opaque_symbol is an incomplete type. --Andy
Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang
On Sat, 2021-04-17 at 14:30 -0400, Jes Sorensen wrote: > On 4/17/21 1:52 PM, Kalle Valo wrote: > > "Gustavo A. R. Silva" wrote: > > > > > In preparation to enable -Wimplicit-fallthrough for Clang, fix > > > multiple warnings by replacing /* fall through */ comments with > > > the new pseudo-keyword macro fallthrough; instead of letting the > > > code fall through to the next case. > > > > > > Notice that Clang doesn't recognize /* fall through */ comments as > > > implicit fall-through markings. > > > > > > Link: https://github.com/KSPP/linux/issues/115 > > > Signed-off-by: Gustavo A. R. Silva > > > > Patch applied to wireless-drivers-next.git, thanks. > > > > bf3365a856a1 rtl8xxxu: Fix fall-through warnings for Clang > > > > Sorry this junk patch should not have been applied. I don't believe it's a junk patch. I believe your characterization of it as such is flawed. You don't like the style, that's fine, but: Any code in the kernel should not be a unique style of your own choosing when it could cause various compilers to emit unnecessary warnings. Please remember the kernel code base is a formed by a community with a nominally generally accepted style. There is a real desire in that community to both enable compiler warnings that might show defects and simultaneously avoid unnecessary compiler warnings. This particular change just avoids a possible compiler warning.
Re: mmu.c:undefined reference to `patch__hash_page_A0'
HI-- I no longer see this build error. However: On 2/27/21 2:24 AM, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 3fb6d0e00efc958d01c2f109c8453033a2d96796 > commit: 259149cf7c3c6195e6199e045ca988c31d081cab powerpc/32s: Only build hash > code when CONFIG_PPC_BOOK3S_604 is selected > date: 4 weeks ago > config: powerpc64-randconfig-r013-20210227 (attached as .config) ktr/lkp, this is a PPC32 .config file that is attached, not PPC64. Also: > compiler: powerpc-linux-gcc (GCC) 9.3.0 > 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 > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=259149cf7c3c6195e6199e045ca988c31d081cab > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 259149cf7c3c6195e6199e045ca988c31d081cab > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=powerpc64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >powerpc-linux-ld: arch/powerpc/mm/book3s32/mmu.o: in function > `MMU_init_hw_patch': >>> mmu.c:(.init.text+0x75e): undefined reference to `patch__hash_page_A0' >>> powerpc-linux-ld: mmu.c:(.init.text+0x76a): undefined reference to >>> `patch__hash_page_A0' >>> powerpc-linux-ld: mmu.c:(.init.text+0x776): undefined reference to >>> `patch__hash_page_A1' >powerpc-linux-ld: mmu.c:(.init.text+0x782): undefined reference to > `patch__hash_page_A1' >>> powerpc-linux-ld: mmu.c:(.init.text+0x78e): undefined reference to >>> `patch__hash_page_A2' >powerpc-linux-ld: mmu.c:(.init.text+0x79a): undefined reference to > `patch__hash_page_A2' >>> powerpc-linux-ld: mmu.c:(.init.text+0x7aa): undefined reference to >>> `patch__hash_page_B' >powerpc-linux-ld: mmu.c:(.init.text+0x7b6): undefined reference to > `patch__hash_page_B' >>> powerpc-linux-ld: mmu.c:(.init.text+0x7c2): undefined reference to >>> `patch__hash_page_C' >powerpc-linux-ld: mmu.c:(.init.text+0x7ce): undefined reference to > `patch__hash_page_C' >>> powerpc-linux-ld: mmu.c:(.init.text+0x7da): undefined reference to >>> `patch__flush_hash_A0' >powerpc-linux-ld: mmu.c:(.init.text+0x7e6): undefined reference to > `patch__flush_hash_A0' >>> powerpc-linux-ld: mmu.c:(.init.text+0x7f2): undefined reference to >>> `patch__flush_hash_A1' >powerpc-linux-ld: mmu.c:(.init.text+0x7fe): undefined reference to > `patch__flush_hash_A1' >>> powerpc-linux-ld: mmu.c:(.init.text+0x80a): undefined reference to >>> `patch__flush_hash_A2' >powerpc-linux-ld: mmu.c:(.init.text+0x816): undefined reference to > `patch__flush_hash_A2' >>> powerpc-linux-ld: mmu.c:(.init.text+0x83e): undefined reference to >>> `patch__flush_hash_B' >powerpc-linux-ld: mmu.c:(.init.text+0x84e): undefined reference to > `patch__flush_hash_B' >powerpc-linux-ld: arch/powerpc/mm/book3s32/mmu.o: in function > `update_mmu_cache': >>> mmu.c:(.text.update_mmu_cache+0xa0): undefined reference to `add_hash_page' I do see this build error: powerpc-linux-ld: arch/powerpc/boot/wrapper.a(decompress.o): in function `partial_decompress': decompress.c:(.text+0x1f0): undefined reference to `__decompress' when either CONFIG_KERNEL_LZO=y or CONFIG_KERNEL_LZMA=y but the build succeeds when either CONFIG_KERNEL_GZIP=y or CONFIG_KERNEL_XZ=y I guess that is due to arch/powerpc/boot/decompress.c doing this: #ifdef CONFIG_KERNEL_GZIP # include "decompress_inflate.c" #endif #ifdef CONFIG_KERNEL_XZ # include "xz_config.h" # include "../../../lib/decompress_unxz.c" #endif It would be nice to require one of KERNEL_GZIP or KERNEL_XZ to be set/enabled (maybe unless a uImage is being built?). ta. -- ~Randy
[PATCH v2 3/3] rtc: rtc_update_irq_enable: rework UIE emulation
Now that the core is aware of whether alarms are available, it is possible
to decide whether UIE emulation is required before actually trying to set
the alarm.
This greatly simplifies rtc_update_irq_enable because there is now only one
error value to track and is not relying on the return value of
__rtc_set_alarm anymore.
Tested-by: Łukasz Stelmach
Signed-off-by: Alexandre Belloni
---
Changes in v2:
- Fix possible deadlock when using UIE emulation (no impact on Łukasz' test)
- Remove rc
drivers/rtc/interface.c | 34 ++
1 file changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index dcb34c73319e..9a2bd4947007 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -545,7 +545,7 @@ EXPORT_SYMBOL_GPL(rtc_alarm_irq_enable);
int rtc_update_irq_enable(struct rtc_device *rtc, unsigned int enabled)
{
- int rc = 0, err;
+ int err;
err = mutex_lock_interruptible(>ops_lock);
if (err)
@@ -561,17 +561,21 @@ int rtc_update_irq_enable(struct rtc_device *rtc,
unsigned int enabled)
if (rtc->uie_rtctimer.enabled == enabled)
goto out;
- if (rtc->uie_unsupported) {
- err = -EINVAL;
- goto out;
+ if (rtc->uie_unsupported || !test_bit(RTC_FEATURE_ALARM,
rtc->features)) {
+ mutex_unlock(>ops_lock);
+#ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL
+ return rtc_dev_update_irq_enable_emul(rtc, enabled);
+#else
+ return -EINVAL;
+#endif
}
if (enabled) {
struct rtc_time tm;
ktime_t now, onesec;
- rc = __rtc_read_time(rtc, );
- if (rc)
+ err = __rtc_read_time(rtc, );
+ if (err)
goto out;
onesec = ktime_set(1, 0);
now = rtc_tm_to_ktime(tm);
@@ -585,24 +589,6 @@ int rtc_update_irq_enable(struct rtc_device *rtc, unsigned
int enabled)
out:
mutex_unlock(>ops_lock);
- /*
-* __rtc_read_time() failed, this probably means that the RTC time has
-* never been set or less probably there is a transient error on the
-* bus. In any case, avoid enabling emulation has this will fail when
-* reading the time too.
-*/
- if (rc)
- return rc;
-
-#ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL
- /*
-* Enable emulation if the driver returned -EINVAL to signal that it has
-* been configured without interrupts or they are not available at the
-* moment.
-*/
- if (err == -EINVAL)
- err = rtc_dev_update_irq_enable_emul(rtc, enabled);
-#endif
return err;
}
EXPORT_SYMBOL_GPL(rtc_update_irq_enable);
--
2.30.2
[PATCH v2 2/3] rtc: ds1307: remove flags
flags is now unused, drop it.
Tested-by: Łukasz Stelmach
Reviewed-by: Łukasz Stelmach
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-ds1307.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 76d67c419f7d..089509d0a3a0 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -169,8 +169,6 @@ enum ds_type {
struct ds1307 {
enum ds_typetype;
- unsigned long flags;
-#define HAS_NVRAM 0 /* bit 0 == sysfs file active */
struct device *dev;
struct regmap *regmap;
const char *name;
--
2.30.2
[PATCH v2 1/3] rtc: ds1307: replace HAS_ALARM by RTC_FEATURE_ALARM
The core now has RTC_FEATURE_ALARM for the driver to indicate whether
alarms are available. Use that instead of HAS_ALARM to ensure the alarm
callbacks are not even called.
Tested-by: Łukasz Stelmach
Reviewed-by: Łukasz Stelmach
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-ds1307.c | 42 +++-
1 file changed, 7 insertions(+), 35 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index cd8e438bc9c4..76d67c419f7d 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -171,7 +171,6 @@ struct ds1307 {
enum ds_typetype;
unsigned long flags;
#define HAS_NVRAM 0 /* bit 0 == sysfs file active */
-#define HAS_ALARM 1 /* bit 1 == irq claimed */
struct device *dev;
struct regmap *regmap;
const char *name;
@@ -411,9 +410,6 @@ static int ds1337_read_alarm(struct device *dev, struct
rtc_wkalrm *t)
int ret;
u8 regs[9];
- if (!test_bit(HAS_ALARM, >flags))
- return -EINVAL;
-
/* read all ALARM1, ALARM2, and status registers at once */
ret = regmap_bulk_read(ds1307->regmap, DS1339_REG_ALARM1_SECS,
regs, sizeof(regs));
@@ -454,9 +450,6 @@ static int ds1337_set_alarm(struct device *dev, struct
rtc_wkalrm *t)
u8 control, status;
int ret;
- if (!test_bit(HAS_ALARM, >flags))
- return -EINVAL;
-
dev_dbg(dev, "%s secs=%d, mins=%d, "
"hours=%d, mday=%d, enabled=%d, pending=%d\n",
"alarm set", t->time.tm_sec, t->time.tm_min,
@@ -512,9 +505,6 @@ static int ds1307_alarm_irq_enable(struct device *dev,
unsigned int enabled)
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
- if (!test_bit(HAS_ALARM, >flags))
- return -ENOTTY;
-
return regmap_update_bits(ds1307->regmap, DS1337_REG_CONTROL,
DS1337_BIT_A1IE,
enabled ? DS1337_BIT_A1IE : 0);
@@ -592,9 +582,6 @@ static int rx8130_read_alarm(struct device *dev, struct
rtc_wkalrm *t)
u8 ald[3], ctl[3];
int ret;
- if (!test_bit(HAS_ALARM, >flags))
- return -EINVAL;
-
/* Read alarm registers. */
ret = regmap_bulk_read(ds1307->regmap, RX8130_REG_ALARM_MIN, ald,
sizeof(ald));
@@ -634,9 +621,6 @@ static int rx8130_set_alarm(struct device *dev, struct
rtc_wkalrm *t)
u8 ald[3], ctl[3];
int ret;
- if (!test_bit(HAS_ALARM, >flags))
- return -EINVAL;
-
dev_dbg(dev, "%s, sec=%d min=%d hour=%d wday=%d mday=%d mon=%d "
"enabled=%d pending=%d\n", __func__,
t->time.tm_sec, t->time.tm_min, t->time.tm_hour,
@@ -681,9 +665,6 @@ static int rx8130_alarm_irq_enable(struct device *dev,
unsigned int enabled)
struct ds1307 *ds1307 = dev_get_drvdata(dev);
int ret, reg;
- if (!test_bit(HAS_ALARM, >flags))
- return -EINVAL;
-
ret = regmap_read(ds1307->regmap, RX8130_REG_CONTROL0, );
if (ret < 0)
return ret;
@@ -735,9 +716,6 @@ static int mcp794xx_read_alarm(struct device *dev, struct
rtc_wkalrm *t)
u8 regs[10];
int ret;
- if (!test_bit(HAS_ALARM, >flags))
- return -EINVAL;
-
/* Read control and alarm 0 registers. */
ret = regmap_bulk_read(ds1307->regmap, MCP794XX_REG_CONTROL, regs,
sizeof(regs));
@@ -793,9 +771,6 @@ static int mcp794xx_set_alarm(struct device *dev, struct
rtc_wkalrm *t)
unsigned char regs[10];
int wday, ret;
- if (!test_bit(HAS_ALARM, >flags))
- return -EINVAL;
-
wday = mcp794xx_alm_weekday(dev, >time);
if (wday < 0)
return wday;
@@ -842,9 +817,6 @@ static int mcp794xx_alarm_irq_enable(struct device *dev,
unsigned int enabled)
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
- if (!test_bit(HAS_ALARM, >flags))
- return -EINVAL;
-
return regmap_update_bits(ds1307->regmap, MCP794XX_REG_CONTROL,
MCP794XX_BIT_ALM0_EN,
enabled ? MCP794XX_BIT_ALM0_EN : 0);
@@ -1641,7 +1613,7 @@ static int ds3231_clks_register(struct ds1307 *ds1307)
* Interrupt signal due to alarm conditions and square-wave
* output share same pin, so don't initialize both.
*/
- if (i == DS3231_CLK_SQW && test_bit(HAS_ALARM, >flags))
+ if (i == DS3231_CLK_SQW && test_bit(RTC_FEATURE_ALARM,
ds1307->rtc->features))
continue;
init.name =
[tip:locking/urgent] BUILD SUCCESS 84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/urgent branch HEAD: 84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896 locking/qrwlock: Fix ordering in queued_write_lock_slowpath() elapsed time: 723m configs tested: 119 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig powerpc ebony_defconfig powerpc ksi8560_defconfig powerpc pcm030_defconfig powerpc pasemi_defconfig m68k amiga_defconfig ia64 tiger_defconfig mips decstation_64_defconfig powerpcicon_defconfig powerpc arches_defconfig armvexpress_defconfig powerpc eiger_defconfig shhp6xx_defconfig armtrizeps4_defconfig powerpc motionpro_defconfig powerpc powernv_defconfig sh espt_defconfig m68kmvme147_defconfig sh se7780_defconfig sh lboxre2_defconfig mips gcw0_defconfig arm aspeed_g5_defconfig xtensasmp_lx200_defconfig powerpc sbc8548_defconfig sh rts7751r2dplus_defconfig powerpc ppc44x_defconfig armzeus_defconfig sh se7705_defconfig arm omap2plus_defconfig powerpc mpc83xx_defconfig mips loongson3_defconfig riscv rv32_defconfig i386 alldefconfig armshmobile_defconfig mips pic32mzda_defconfig m68k atari_defconfig openriscdefconfig arm s3c2410_defconfig arm bcm2835_defconfig powerpcsocrates_defconfig arm rpc_defconfig arm footbridge_defconfig armneponset_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a003-20210417 x86_64 randconfig-a002-20210417 x86_64 randconfig-a005-20210417 x86_64 randconfig-a001-20210417 x86_64 randconfig-a006-20210417 x86_64 randconfig-a004-20210417 i386 randconfig-a003-20210417 i386 randconfig-a006-20210417 i386 randconfig-a001-20210417 i386 randconfig-a005-20210417 i386 randconfig-a004-20210417 i386 randconfig-a002-20210417 i386 randconfig-a015-20210417 i386 randconfig-a014-20210417 i386 randconfig-a013-20210417 i386 randconfig-a012-20210417 i386 randconfig-a016-20210417 i386 randconfig-a011-20210417 riscv
[tip:sched/core] BUILD SUCCESS 9406415f46f6127fd31bb66f0260f7a61a8d2786
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core branch HEAD: 9406415f46f6127fd31bb66f0260f7a61a8d2786 sched/debug: Rename the sched_debug parameter to sched_verbose elapsed time: 723m configs tested: 97 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig powerpc ebony_defconfig powerpc ksi8560_defconfig arm davinci_all_defconfig sh se7750_defconfig powerpc pcm030_defconfig arm aspeed_g5_defconfig powerpc eiger_defconfig powerpc mpc834x_mds_defconfig armzeus_defconfig sh se7705_defconfig arm omap2plus_defconfig powerpc mpc83xx_defconfig mips loongson3_defconfig riscv rv32_defconfig i386 alldefconfig armshmobile_defconfig mips pic32mzda_defconfig m68k atari_defconfig openriscdefconfig arm s3c2410_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210417 i386 randconfig-a006-20210417 i386 randconfig-a001-20210417 i386 randconfig-a005-20210417 i386 randconfig-a004-20210417 i386 randconfig-a002-20210417 i386 randconfig-a015-20210417 i386 randconfig-a014-20210417 i386 randconfig-a013-20210417 i386 randconfig-a012-20210417 i386 randconfig-a016-20210417 i386 randconfig-a011-20210417 x86_64 randconfig-a003-20210417 x86_64 randconfig-a002-20210417 x86_64 randconfig-a005-20210417 x86_64 randconfig-a001-20210417 x86_64 randconfig-a006-20210417 x86_64 randconfig-a004-20210417 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a014-20210417 x86_64 randconfig-a015-20210417 x86_64 randconfig-a011-20210417 x86_64 randconfig-a013-20210417 x86_64 randconfig-a012-20210417 x86_64 randconfig-a016-20210417 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH 05/15] x86: Implement function_nocfi
On Sat, Apr 17 2021 at 16:19, Andy Lutomirski wrote:
> On Fri, Apr 16, 2021 at 4:40 PM Kees Cook wrote:
>> Okay, you're saying you want __builtin_gimme_body_p() to be a constant
>> expression for the compiler, not inline asm?
>
> Yes.
>
> I admit that, in the trivial case where the asm code is *not* a
> C-ABI-compliant function, giving a type that doesn't fool the compiler
> into thinking that it might be is probably the best fix. Maybe we
> should standardize something, e.g.:
>
> struct raw_symbol; /* not defined anywhere */
> #define DECLARE_RAW_SYMBOL(x) struct raw_symbol x[]
>
> and then we write this:
>
> DECLARE_RAW_SYMBOL(entry_SYSCALL_64);
>
> wrmsrl(..., (unsigned long)entry_SYSCALL_64);
>
> It would be a bit nifty if we didn't need a forward declaration, but
> I'm not immediately seeing a way to do this without hacks that we'll
> probably regret;
>
> But this doesn't help the case in which the symbol is an actual
> C-callable function and we want to be able to call it, too.
The right way to solve this is that the compiler provides a builtin
function_nocfi() +/- the naming bikeshed
which works for
foo = function_nocfi(bar);
and
static unsigned long foo[] = {
function_nocfi(bar1),
function_nocfi(bar2),
};
which are pretty much the only possible 2 usecases. If the compiler
wants to have function_nocfi_in_code() and function_nocfi_const()
because it can't figure it out on it's own, then I can live with that,
but that's still several orders of magnitudes better than having to work
around it by whatever nasty macro/struct magic.
I don't care about the slightly more unreadable code, but if that
builtin has a descriptive name, then it's even useful for documentary
purposes. And it can be easily grepped for which makes it subject to
static code analysers which can help to detect abuse.
Anything which requires to come up with half baken constructs to work
around the shortcomings of the compiler are wrong to begin with.
Thanks,
tglx
[PATCH] imx-sc: remove .read_alarm
The RTC core properly handles RTC without .read_alarm and doesn't use it to
set alarms. .read_alarm can be safely dropped.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-imx-sc.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c
index cc9fbab4..814d516645e2 100644
--- a/drivers/rtc/rtc-imx-sc.c
+++ b/drivers/rtc/rtc-imx-sc.c
@@ -80,16 +80,6 @@ static int imx_sc_rtc_alarm_irq_enable(struct device *dev,
unsigned int enable)
return imx_scu_irq_group_enable(SC_IRQ_GROUP_RTC, SC_IRQ_RTC, enable);
}
-static int imx_sc_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
-{
- /*
-* SCU firmware does NOT provide read alarm API, but .read_alarm
-* callback is required by RTC framework to support alarm function,
-* so just return here.
-*/
- return 0;
-}
-
static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
{
struct imx_sc_msg_timer_rtc_set_alarm msg;
@@ -127,7 +117,6 @@ static int imx_sc_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
static const struct rtc_class_ops imx_sc_rtc_ops = {
.read_time = imx_sc_rtc_read_time,
.set_time = imx_sc_rtc_set_time,
- .read_alarm = imx_sc_rtc_read_alarm,
.set_alarm = imx_sc_rtc_set_alarm,
.alarm_irq_enable = imx_sc_rtc_alarm_irq_enable,
};
--
2.30.2
Re: [PATCH v8 clocksource 3/5] clocksource: Check per-CPU clock synchronization when marked unstable
On Sat, Apr 17, 2021 at 02:47:18PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 21:36, Paul E. McKenney wrote:
>
> Bah, hit send too quick.
>
> > + cpumask_clear(_ahead);
> > + cpumask_clear(_behind);
> > + preempt_disable();
>
> Daft.
Would migrate_disable() be better?
Yes, I know, in virtual environments, the hypervisor can migrate anyway,
but this does limit the potential damage to one out of the two schedulers.
> > + testcpu = smp_processor_id();
> > + pr_warn("Checking clocksource %s synchronization from CPU %d.\n",
> > cs->name, testcpu);
> > + for_each_online_cpu(cpu) {
> > + if (cpu == testcpu)
> > + continue;
> > + csnow_begin = cs->read(cs);
> > + smp_call_function_single(cpu, clocksource_verify_one_cpu, cs,
> > 1);
> > + csnow_end = cs->read(cs);
>
> As this must run with interrupts enabled, that's a pretty rough
> approximation like measuring wind speed with a wet thumb.
>
> Wouldn't it be smarter to let the remote CPU do the watchdog dance and
> take that result? i.e. split out more of the watchdog code so that you
> can get the nanoseconds delta on that remote CPU to the watchdog.
First, an interrupt, NMI, SMI, vCPU preemption, or whatever could
not cause a false positive. A false negative, perhaps, but no
false positives. Second, in normal operation, these are rare, so that
hitting the (eventual) default of eight CPUs is very likely to result in
tight bounds on the delay-based error for most of those CPUs. Third,
we really need to compare the TSC on one CPU to the TSC on the other
in order to have a very clear indication of a problem, should a real
TSC-synchronization issue arise. In contrast, comparisons against the
watchdog timer will be more complicated and any errors detected will be
quite hard to prove to be due to TSC issues.
Or am I once again missing something?
> > + delta = (s64)((csnow_mid - csnow_begin) & cs->mask);
> > + if (delta < 0)
> > + cpumask_set_cpu(cpu, _behind);
> > + delta = (csnow_end - csnow_mid) & cs->mask;
> > + if (delta < 0)
> > + cpumask_set_cpu(cpu, _ahead);
> > + delta = clocksource_delta(csnow_end, csnow_begin, cs->mask);
> > + cs_nsec = clocksource_cyc2ns(delta, cs->mult, cs->shift);
>
> > + if (firsttime || cs_nsec > cs_nsec_max)
> > + cs_nsec_max = cs_nsec;
> > + if (firsttime || cs_nsec < cs_nsec_min)
> > + cs_nsec_min = cs_nsec;
> > + firsttime = 0;
>
> int64_t cs_nsec_max = 0, cs_nsec_min = LLONG_MAX;
>
> and then the firsttime muck is not needed at all.
Good point, will fix!
And again, thank you for looking all of this over.
Thanx, Paul
[git pull] drm/vmwgfx fixes for 5.12-rc8
Hi Linus, Back from holidays and this was in the cracks (Zack forgot to cc Daniel/lists), I've just piled it onto drm fixes. It contains two regression fixes for vmwgfx, one due to a refactor which meant locks were being used before initialisation, and the other in fixing up some warnings from the core when destroying pinned buffers. Dave. drm-fixes-2021-04-18: drm/vmwgfx fixes for 5.12-rc7 vmwgfx: - fixed unpinning before destruction - lockdep init reordering The following changes since commit 4d2e1288372ccc5ac60290bc10cace49c9bfa6d0: Merge tag 'drm-intel-fixes-2021-04-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-04-15 15:24:17 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-18 for you to fetch changes up to 796b556cbfdbe0d65b9793e63653ad24f9fa033c: Merge tag 'vmwgfx-fixes-2021-04-14' of gitlab.freedesktop.org:zack/vmwgfx into drm-fixes (2021-04-18 09:27:00 +1000) drm/vmwgfx fixes for 5.12-rc7 vmwgfx: - fixed unpinning before destruction - lockdep init reordering Dave Airlie (1): Merge tag 'vmwgfx-fixes-2021-04-14' of gitlab.freedesktop.org:zack/vmwgfx into drm-fixes Zack Rusin (3): drm/vmwgfx: Make sure we unpin no longer needed buffers drm/vmwgfx: Fix the lockdep breakage drm/vmwgfx: Make sure bo's are unpinned before putting them back drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 4 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 + drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 14 ++ 4 files changed, 27 insertions(+), 13 deletions(-)
Re: [PATCH v8 clocksource 3/5] clocksource: Check per-CPU clock synchronization when marked unstable
On Sat, Apr 17, 2021 at 02:28:22PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 21:36, Paul E. McKenney wrote:
> > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> > index 1fc0962c89c0..97eeaf164296 100644
> > --- a/arch/x86/kernel/kvmclock.c
> > +++ b/arch/x86/kernel/kvmclock.c
> > @@ -169,7 +169,7 @@ struct clocksource kvm_clock = {
> > .read = kvm_clock_get_cycles,
> > .rating = 400,
> > .mask = CLOCKSOURCE_MASK(64),
> > - .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> > + .flags = CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_VERIFY_PERCPU,
>
> kvm_clock is not marked with CLOCK_SOURCE_MUST_VERIFY, so what's the
> point of adding this here? It's not subject to be monitored by the
> watchdog muck.
Good point, removed.
> > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> > index f70dffc2771f..56289170753c 100644
> > --- a/arch/x86/kernel/tsc.c
> > +++ b/arch/x86/kernel/tsc.c
> > @@ -1151,7 +1151,8 @@ static struct clocksource clocksource_tsc = {
> > .mask = CLOCKSOURCE_MASK(64),
> > .flags = CLOCK_SOURCE_IS_CONTINUOUS |
> > CLOCK_SOURCE_VALID_FOR_HRES |
> > - CLOCK_SOURCE_MUST_VERIFY,
> > + CLOCK_SOURCE_MUST_VERIFY |
> > + CLOCK_SOURCE_VERIFY_PERCPU,
>
> While this one is part of the horror show.
It probably would be good to decorate other arch's per-CPU clocks
with CLOCK_SOURCE_VERIFY_PERCPU, but no takers thus far.
Thanx, Paul
> > +static u64 csnow_mid;
> > +static cpumask_t cpus_ahead;
> > +static cpumask_t cpus_behind;
> > +
> > +static void clocksource_verify_one_cpu(void *csin)
> > +{
> > + struct clocksource *cs = (struct clocksource *)csin;
> > +
> > + csnow_mid = cs->read(cs);
> > +}
> > +
> > +static void clocksource_verify_percpu(struct clocksource *cs)
> > +{
> > + int64_t cs_nsec, cs_nsec_max, cs_nsec_min;
> > + u64 csnow_begin, csnow_end;
> > + bool firsttime = 1;
> > + int testcpu;
> > + s64 delta;
> > + int cpu;
>
> int testcpu, cpu; :)
>
Re: [PATCH v8 clocksource 2/5] clocksource: Retry clock read if long delays detected
On Sun, Apr 18, 2021 at 01:15:26AM +0200, Thomas Gleixner wrote: > On Sat, Apr 17 2021 at 15:54, Paul E. McKenney wrote: > > On Sat, Apr 17, 2021 at 02:24:23PM +0200, Thomas Gleixner wrote: > >> I so wish we could just delete all of this horror instead of making it > >> more horrible. > > > > Revisit deleting it in five years if there are no issues, whatever > > "issue" might mean in this context? Five years should give time for > > this to propagate to the enterprise distros. > > That does not help with the fact that the broken hardware will still be > around in 5 years from now. Which is what prevents me from deleting the > whole watchdog muck ... Ouch! Sigh... Thanx, Paul
drivers/md/dm-log-writes.c:452:12: warning: stack frame size of 1184 bytes in function 'log_writes_kthread'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 194cf4825638256e9afe1d360831aa5379b3517a commit: 309dca309fc39a9e3c31b916393b74bd174fd74e block: store a block_device pointer in struct bio date: 3 months ago config: powerpc64-randconfig-r032-20210418 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project f549176ad976caa3e19edd036df9a7e12770af7c) 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 powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=309dca309fc39a9e3c31b916393b74bd174fd74e git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 309dca309fc39a9e3c31b916393b74bd174fd74e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :116:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/md/dm-log-writes.c:7: In file included from include/linux/device-mapper.h:11: In file included from include/linux/bio.h:8: In file included from include/linux/highmem.h:10: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :118:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/md/dm-log-writes.c:7: In file included from include/linux/device-mapper.h:11: In file included from include/linux/bio.h:8: In file included from include/linux/highmem.h:10: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :120:1: note: expanded from here __do_outsb ^ arch/powerpc/include/asm/io.h:559:58: note: expanded from macro '__do_outsb' #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~^ In file included from drivers/md/dm-log-writes.c:7: In file included from include/linux/device-mapper.h:11: In file included from include/linux/bio.h:8: In
Re: [PATCH 05/15] x86: Implement function_nocfi
On Fri, Apr 16, 2021 at 4:40 PM Kees Cook wrote: > > > 1. I defined a function in asm. I want to tell clang that this > > function is defined in asm, and for clang to behave accordingly: > > > > .globl func > > func: > > ; do stuff > > > > later: > > > > extern void func(void) [something here]; > > > > There really should be a way to write this correctly such that it > > works regardless of the setting of > > -fsanitize-cfi-canonical-jump-tables. This should not bypass CFI. It > > should *work*, with CFI enforced. If I read all the various things > > you linked correctly, this would be something like __cfi_noncanonical, > > and I reserve the right to think that this is a horrible name. > > Yes, I find the name confusing too. Without noncanonical, we'd need > C call wrappers for every single .S function that had its address > taken. This is very common in crypto, for example. That level of extra > code seemed like a total non-starter. Instead, we just get a few places > we have to mark. The patch you linked doesn't have a noncanonical attribute, though. So I'm not sure how to reliably call into asm from C. (The more I think about it, the less I like "canonical". What is "canonical"? The symbol? The function body? Something else?) > > > 2. I need a raw function pointer, thank you very much. I would like > > to be honest about it, and I don't really want to bypass CFI, but I > > need the actual bits in the actual symbol. > > > > translation unit 1 defines func. Maybe it's C with > > -fsanitize-cfi-canonical-jump-tables, maybe it's C with > > -fno-sanitize-cfi-canonical-jump-tables or however it's spelled, and > > maybe it's plain asm. Now translation unit 2 does: > > > > 2a. Uses a literal symbol, because it's going to modify function text > > or poke an MSR or whatever: > > > > wrmsrl(MSR_WHATEVER, func); > > > > clang needs to give us *some* way to have a correct declaration of > > func such that we can, without resorting to inline asm kludges, get > > the actual bit pattern of the actual symbol. > > We don't want version of a global symbol alias of func that points to > the function body, though; it's only very specific cases where this > should be stripped (MSR, ftrace, etc). > > So, if there were some Clang-specific syntax for this, it would still be > used on a case-by-case basis. It would still be something like: > > wrmsrl(MSR_WAT, __builtin_gimme_body_p(func)); > > Okay, you're saying you want __builtin_gimme_body_p() to be a constant > expression for the compiler, not inline asm? Yes. I admit that, in the trivial case where the asm code is *not* a C-ABI-compliant function, giving a type that doesn't fool the compiler into thinking that it might be is probably the best fix. Maybe we should standardize something, e.g.: struct raw_symbol; /* not defined anywhere */ #define DECLARE_RAW_SYMBOL(x) struct raw_symbol x[] and then we write this: DECLARE_RAW_SYMBOL(entry_SYSCALL_64); wrmsrl(..., (unsigned long)entry_SYSCALL_64); It would be a bit nifty if we didn't need a forward declaration, but I'm not immediately seeing a way to do this without hacks that we'll probably regret; But this doesn't help the case in which the symbol is an actual C-callable function and we want to be able to call it, too.
Re: [PATCH v8 clocksource 2/5] clocksource: Retry clock read if long delays detected
On Sat, Apr 17 2021 at 15:54, Paul E. McKenney wrote: > On Sat, Apr 17, 2021 at 02:24:23PM +0200, Thomas Gleixner wrote: >> I so wish we could just delete all of this horror instead of making it >> more horrible. > > Revisit deleting it in five years if there are no issues, whatever > "issue" might mean in this context? Five years should give time for > this to propagate to the enterprise distros. That does not help with the fact that the broken hardware will still be around in 5 years from now. Which is what prevents me from deleting the whole watchdog muck ... Thanks, tglx
Re: [PATCH] Fix set apic mode from x2apic enabled bit patch
Mike! On Sun, Apr 18 2021 at 00:39, Thomas Gleixner wrote: > If you can't come up with something sensible anytime soon before the > merge window opens then I'm simply going to revert 41e2da9b5e67 and you > can try again for the next cycle. so I just figured out that Boris wasted his time once more to fix that up and redo the commit in question. Won't happen again. Thanks, tglx
Re: build failure of malta_qemu_32r6_defconfig
Hi Thomas, On Fri, Apr 9, 2021 at 1:17 PM Thomas Bogendoerfer wrote: > > On Thu, Apr 08, 2021 at 09:42:11AM +0800, YunQiang Su wrote: > > Sudip Mukherjee 于2021年4月8日周四 上午2:26写道： > > > > > > Hi Thomas, > > > > > > I was building v5.10.28 with malta_qemu_32r6_defconfig and noticed that > > > it fails to build, so tried next-20210407 to see if it has been fixed. > > > But linux-next also has the issue with gcc-10. > > > > > > The error is: > > > > > > ./arch/mips/include/asm/vdso/gettimeofday.h: In function > > > '__vdso_clock_gettime': > > > ./arch/mips/include/asm/vdso/gettimeofday.h:103:2: error: the register > > > 'lo' cannot be clobbered in 'asm' for the current target > > > 103 | asm volatile( > > > | ^~~ > > > > this operation try to save lo and hi register, while they are not > > exisiting on r6. > > We are working on figure out a patch for it. > > looks like there is already a patch in patchwork, which just needs > a workup: > > https://patchwork.kernel.org/project/linux-mips/patch/20200801154401.4177009-1-romain.na...@gmail.com/ Looks like there has been no response to it since last 8 months. Do you want me to respin it and send a proper patch? -- Regards Sudip
Re: [PATCH v8 clocksource 2/5] clocksource: Retry clock read if long delays detected
On Sat, Apr 17, 2021 at 02:24:23PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 21:35, Paul E. McKenney wrote:
> > #define WATCHDOG_INTERVAL (HZ >> 1)
> > #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
> > +#define WATCHDOG_MAX_SKEW (NSEC_PER_SEC >> 6)
>
> That's ~15ms which is a tad large I'd say...
And I have a separate patch queued to crank this down to 125us.
I ran 2,664 hours of rcutorture on this patch, and saw only 18 instances
of delay detected. So 125us works well, but I am not inclined to decrease
it much.
I will try 50us this evening though, just for grins. After all, only
those who have gone too far can possibly tell you how far you can go.
> > static void clocksource_watchdog_work(struct work_struct *work)
> > {
> > @@ -213,9 +214,10 @@ static void clocksource_watchdog_inject_delay(void)
> > static void clocksource_watchdog(struct timer_list *unused)
> > {
> > struct clocksource *cs;
> > - u64 csnow, wdnow, cslast, wdlast, delta;
> > - int64_t wd_nsec, cs_nsec;
> > + u64 csnow, wdnow, wdagain, cslast, wdlast, delta;
> > + int64_t wd_nsec, wdagain_delta, wderr_nsec = 0, cs_nsec;
> > int next_cpu, reset_pending;
> > + int nretries;
> >
> > spin_lock(_lock);
> > if (!watchdog_running)
> > @@ -224,6 +226,7 @@ static void clocksource_watchdog(struct timer_list
> > *unused)
> > reset_pending = atomic_read(_reset_pending);
> >
> > list_for_each_entry(cs, _list, wd_list) {
> > + nretries = 0;
> >
> > /* Clocksource already marked unstable? */
> > if (cs->flags & CLOCK_SOURCE_UNSTABLE) {
> > @@ -232,11 +235,24 @@ static void clocksource_watchdog(struct timer_list
> > *unused)
> > continue;
> > }
> >
> > +retry:
> > local_irq_disable();
> > - csnow = cs->read(cs);
> > - clocksource_watchdog_inject_delay();
> > wdnow = watchdog->read(watchdog);
> > + clocksource_watchdog_inject_delay();
> > + csnow = cs->read(cs);
> > + wdagain = watchdog->read(watchdog);
> > local_irq_enable();
> > + delta = clocksource_delta(wdagain, wdnow, watchdog->mask);
> > + wdagain_delta = clocksource_cyc2ns(delta, watchdog->mult,
> > watchdog->shift);
> > + if (wdagain_delta > WATCHDOG_MAX_SKEW) {
> > + wderr_nsec = wdagain_delta;
> > + if (nretries++ < max_read_retries)
> > + goto retry;
> > + }
> > + if (nretries) {
> > + pr_warn("timekeeping watchdog on CPU%d: %s read-back
> > delay of %lldns, attempt %d\n",
> > + smp_processor_id(), watchdog->name, wderr_nsec,
> > nretries);
> > + }
> >
> > /* Clocksource initialized ? */
> > if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
>
> This can nicely be split out into a read function which avoids brain
> overload when reading. Something like the uncompiled below.
Good point, done, with minor adjustments.
> I so wish we could just delete all of this horror instead of making it
> more horrible.
Revisit deleting it in five years if there are no issues, whatever
"issue" might mean in this context? Five years should give time for
this to propagate to the enterprise distros.
Thanx, Paul
> Thanks,
>
> tglx
> ---
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -124,6 +124,12 @@ static void __clocksource_change_rating(
> #define WATCHDOG_INTERVAL (HZ >> 1)
> #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
>
> +/*
> + * The maximum delay between two consecutive readouts of the watchdog
> + * clocksource to detect SMI,NMI,vCPU preemption.
> + */
> +#define WATCHDOG_MAX_DELAY (100 * NSEC_PER_USEC)
> +
> static void clocksource_watchdog_work(struct work_struct *work)
> {
> /*
> @@ -184,12 +190,37 @@ void clocksource_mark_unstable(struct cl
> spin_unlock_irqrestore(_lock, flags);
> }
>
> +static bool cs_watchdog_read(struct clocksource *cs, u64 *csnow, u64 *wdnow)
> +{
> + unsigned int nretries;
> + u64 wd_end, wd_delta;
> + int64_t wd_delay;
> +
> + for (nretries = 0; nretries < max_read_retries; nretries++) {
> + local_irq_disable();
> + *wdnow = watchdog->read(watchdog);
> + clocksource_watchdog_inject_delay();
> + *csnow = cs->read(cs);
> + wd_end = watchdog->read(watchdog);
> + local_irq_enable();
> +
> + wd_delta = clocksource_delta(wd_end, *wdnow, watchdog->mask);
> + wd_delay = clocksource_cyc2ns(wd_delta, watchdog->mult,
> watchdog->shift);
> + if (wd_delay < WATCHDOG_MAX_DELAY)
> + return true;
> + }
> +
> + pr_warn("timekeeping watchdog on CPU%d: %s read-back delay of %lldns,
> %d attempts\n",
> +
Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
On Sat, Apr 17, 2021 at 09:18:57PM +, David Laight wrote: > Ugly as well. Thank you for expressing your opinion. Again.
Re: [PATCH] Fix set apic mode from x2apic enabled bit patch
Mike!
On Thu, Apr 15 2021 at 17:06, Mike Travis wrote:
I'm slowly getting tired of the fact that every patch coming from you
fails to comply with the minimal requirements of the documented
procedures.
$subject: [PATCH] Fix set apic mode from x2apic enabled bit patch
Documentation clearly states, that there has to be a subsystem
prefix. It's not rocket science to figure it out:
# git log arch/x86/kernel/apic/x2apic_uv_x.c
gives you a pretty good hint that the prefix should be:
x86/platform/uv:
It's not that hard and it's not optional.
Also what the heck means:
Fix set apic mode from x2apic enabled bit patch
Again documentation is very clear about what the subject line, aka git
shortlog of a patch should look like.
This sentence is just word salad and does not give any clue of what this
is about. Even you wont be able to decode this 3 month from now. Simply
because it's word salad.
I don't care what kind of standards you have @hpe, but I very much care
about the standards of the kernel.
> Do not set uv_system_type for hubless UV systems as it tricks the
> is_uv_system function into thinking it's a UV hubbed system and includes
> a UV HUB RTC. This causes UV RTC init to panic on UV hubless systems.
And yet more word salad. Can you please describe the precise technical
problem and not use metaphors of functions which are thinking?
Aside of that this does not describe the change at all. The change is:
> - early_set_apic_mode();
but your changelog blurbs about "thinking it's an UV hubbed system".
How the heck can this make sense for someone who is not part of the @hpe
universe mindset?
> Fixes: 41e2da9b5e67 ("x86/platform/uv: Use x2apic enabled bit as set by BIOS
> to indicate APIC mode")
>
> [41e2da9b5e67 was accepted into tip x86/platform branch but not yet
> pulled into the linus tree.]
Truly useful. The only value of that information is that the maintainer
has to manualy remove it because it's irrelevant for the final commit
message of the change which ends up on top of that commit in that
branch. You can stick this into the section below '---' if you think
it's helpful, but then maintainers and tools can just ignore it.
TBH, it's not helpful at all because tooling already tells us that
41e2da9b5e67 is not in Linus tree and only queued in tip x86/platform.
Commit SHAs are supposed to be unique for a reason...
> Signed-off-by: Mike Travis
> Reviewed-by: Steve Wahl
> Reviewed-by: Dimitri Sivanich
The value of these reviewed-by tags is close to zero because they are
just documenting that the change is ok at the @hpe universe level...
> ---
> arch/x86/kernel/apic/x2apic_uv_x.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
> b/arch/x86/kernel/apic/x2apic_uv_x.c
> index 2e99605f9a05..68ef9abc91f7 100644
> --- a/arch/x86/kernel/apic/x2apic_uv_x.c
> +++ b/arch/x86/kernel/apic/x2apic_uv_x.c
> @@ -413,9 +413,8 @@ static int __init uv_set_system_type(char *_oem_id, char
> *_oem_table_id)
> else
> uv_hubless_system |= 0x8;
>
> - /* Copy OEM Table ID and set APIC Mode */
> + /* Copy OEM Table ID */
> uv_stringify(sizeof(oem_table_id), oem_table_id, _oem_table_id);
> - early_set_apic_mode();
So the patch itself tells me more about what's going on than the
changelog:
Setting up the APIC mode at this place is wrong.
But it does not tell me WHY. Neither does the changelog because of
useless word salad...
If you can't come up with something sensible anytime soon before the
merge window opens then I'm simply going to revert 41e2da9b5e67 and you
can try again for the next cycle.
Thanks,
tglx
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote: > > No, wait - we have non-NULL buf->prev_reclen, so we'll hit > with buf->error completely ignored. Nevermind. Yeah, I'm pretty sure I even tested that -EINTR case at one point. Of course, it could easily have gotten broken again, so that's not a strong argument. That said, the "buf->err" handling has always been very confusing, and it would be lovely to get rid of that confusion. I don't remember why we did it that way, but I think it's because low-level filesystems ended up changing the error that the filldir() function returned or something like that. Linus
Re: [PATCH] block: fix io hung by block throttle
On 4/17/21 3:10 AM, Hillf Danton wrote:
--- a/block/blk-rq-qos.c
+++ b/block/blk-rq-qos.c
@@ -260,19 +260,17 @@ void rq_qos_wait(struct rq_wait *rqw, void *private_data,
.cb = acquire_inflight_cb,
.private_data = private_data,
};
- bool has_sleeper;
- has_sleeper = wq_has_sleeper(>wait);
- if (!has_sleeper && acquire_inflight_cb(rqw, private_data))
+ if (!wq_has_sleeper(>wait)
+ && acquire_inflight_cb(rqw, private_data))
return;
prepare_to_wait_exclusive(>wait, , TASK_UNINTERRUPTIBLE);
- has_sleeper = !wq_has_single_sleeper(>wait);
do {
/* The memory barrier in set_task_state saves us here. */
if (data.got_token)
break;
- if (!has_sleeper && acquire_inflight_cb(rqw, private_data)) {
+ if (acquire_inflight_cb(rqw, private_data)) {
finish_wait(>wait, );
Simply removing !has_sleeper is not enough if it is mandatory before
acquire_inflight_cb() without adding something like a mutex to sieve the
concurrent sleepers out, see below.
--- a/block/blk-rq-qos.c
+++ b/block/blk-rq-qos.c
@@ -260,19 +260,18 @@ void rq_qos_wait(struct rq_wait *rqw, vo
.cb = acquire_inflight_cb,
.private_data = private_data,
};
- bool has_sleeper;
- has_sleeper = wq_has_sleeper(>wait);
- if (!has_sleeper && acquire_inflight_cb(rqw, private_data))
- return;
+ mutex_lock(>mutex);
+
+ if (acquire_inflight_cb(rqw, private_data))
This function is to increase atomic variable rq_wait->inflight. What's
the mutex for?
Thanks,
Junxiao.
+ goto out;
prepare_to_wait_exclusive(>wait, , TASK_UNINTERRUPTIBLE);
- has_sleeper = !wq_has_single_sleeper(>wait);
do {
/* The memory barrier in set_task_state saves us here. */
if (data.got_token)
break;
- if (!has_sleeper && acquire_inflight_cb(rqw, private_data)) {
+ if (acquire_inflight_cb(rqw, private_data)) {
finish_wait(>wait, );
/*
@@ -286,10 +285,11 @@ void rq_qos_wait(struct rq_wait *rqw, vo
break;
}
io_schedule();
- has_sleeper = true;
set_current_state(TASK_UNINTERRUPTIBLE);
} while (1);
finish_wait(>wait, );
+out:
+ mutex_unlock(>mutex);
}
RE: [PATCH] media: atomisp: silence "dubious: !x | !y" warning
From: Mauro Carvalho Chehab > Sent: 17 April 2021 19:56 > > Em Sat, 17 Apr 2021 21:06:27 +0530 > Ashish Kalra escreveu: > > > Upon running sparse, "warning: dubious: !x | !y" is brought to notice > > for this file. Logical and bitwise OR are basically the same in this > > context so it doesn't cause a runtime bug. But let's change it to > > logical OR to make it cleaner and silence the Sparse warning. The old code is very likely to by slightly more efficient. It may not matter here, but it might in a really hot path. Since !x | !y and !x || !y always have the same value why is sparse complaining at all. David > > > > Signed-off-by: Ashish Kalra > > --- > > .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > index 358cb7d2cd4c..3b850bb2d39d 100644 > > --- > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > +++ > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( > > unsigned int ds_log2 = 0; > > unsigned int out_width; > > > > - if ((!out_info) | (!vf_info)) > > + if ((!out_info) || (!vf_info)) > > > While here, please get rid of the unneeded parenthesis: > > if (!out_info || !vf_info) > > > > return -EINVAL; > > > > out_width = out_info->res.width; > > > > Thanks, > Mauro - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 2/2] mm: Indicate pfmemalloc pages in compound_head
On Sat, Apr 17, 2021 at 09:13:45PM +, David Laight wrote:
> > struct {/* page_pool used by netstack */
> > - /**
> > -* @dma_addr: might require a 64-bit value on
> > -* 32-bit architectures.
> > -*/
> > + unsigned long pp_magic;
> > + unsigned long xmi;
> > + unsigned long _pp_mapping_pad;
> > unsigned long dma_addr[2];
> > };
>
> You've deleted the comment.
Yes. It no longer added any value. You can see dma_addr now occupies
two words.
> I also think there should be a comment that dma_addr[0]
> must be aliased to ->index.
That's not a requirement. Moving the pfmemalloc indicator is a
requirement so that we _can_ use index, but there's no requirement about
how index is used.
RE: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
From: Matthew Wilcox
> Sent: 17 April 2021 03:45
>
> Replacement patch to fix compiler warning.
...
> static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
> {
> - return page->dma_addr;
> + dma_addr_t ret = page->dma_addr[0];
> + if (sizeof(dma_addr_t) > sizeof(unsigned long))
> + ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;
Ugly as well.
Why not just replace the (dma_addr_t) cast with a (u64) one?
Looks better than the double shift.
Same could be done for the '>> 32'.
Is there an upper_32_bits() that could be used??
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
RE: [PATCH 2/2] mm: Indicate pfmemalloc pages in compound_head
From: Matthew Wilcox (Oracle)
> Sent: 17 April 2021 00:07
>
> The net page_pool wants to use a magic value to identify page pool pages.
> The best place to put it is in the first word where it can be clearly a
> non-pointer value. That means shifting dma_addr up to alias with ->index,
> which means we need to find another way to indicate page_is_pfmemalloc().
> Since page_pool doesn't want to set its magic value on pages which are
> pfmemalloc, we can use bit 1 of compound_head to indicate that the page
> came from the memory reserves.
>
...
> struct {/* page_pool used by netstack */
> - /**
> - * @dma_addr: might require a 64-bit value on
> - * 32-bit architectures.
> - */
> + unsigned long pp_magic;
> + unsigned long xmi;
> + unsigned long _pp_mapping_pad;
> unsigned long dma_addr[2];
> };
You've deleted the comment.
I also think there should be a comment that dma_addr[0]
must be aliased to ->index.
(Or whatever all the exact requirements are.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH 00/13] [RFC] Rust support
On Thu, Apr 15, 2021 at 2:41 AM wrote: > Regarding compilers, we support Clang-built kernels as well as > `LLVM=1` builds where possible (i.e. as long as supported by > the ClangBuiltLinux project). We also maintain some configurations > of GCC-built kernels working, but they are not intended to be used > at the present time. Having a `bindgen` backend for GCC would be > ideal to improve support for those builds. Sp this effectively means gcc is a second class citizen and even if gcc is supported at some point one needs a super recent gcc *and* rust toolchain to build a rust-enabeled kernel? I understand that this is right now not a big deal, but as soon a non-trival subsystem is rust-only people are forced to upgrade. Don't get me wrong, I'm all for having rust support in Linux. But I'm a bit worried about new dependencies on compiler toolchains. As someone who works a lot with long supported embedded systems I learned that as soon an application gains a hard dependency on clang or rust I'm in trouble. -- Thanks, //richard
Re: [PATCH -next] PCI: remove unused variable rdev
On 4/17/21 04:44, Bixuan Cui wrote:
> Fix the build warning:
>
> drivers/pci/quirks.c: In function ‘quirk_amd_nvme_fixup’:
> drivers/pci/quirks.c:312:18: warning: unused variable ‘rdev’
> [-Wunused-variable]
> struct pci_dev *rdev;
> ^~~~
>
> Fixes: 9597624ef606 ('nvme: put some AMD PCIE downstream NVME device to
> simple suspend/resume path')
> Signed-off-by: Bixuan Cui
Looks good.
Reviewed-by: Chaitanya Kulkarni
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
On Sat, Apr 17, 2021 at 08:30:42PM +, Al Viro wrote:
> and that thing is still there. However, it does *NOT* do what it might
> appear to be doing; it ends up with getdents() returning -EINVAL instead.
> What we need is
> buf->error = -EINTR;
> in addition to that return (in all 3 such places). Do you have any problems
> with
> the following delta?
No, wait - we have non-NULL buf->prev_reclen, so we'll hit
if (buf.prev_reclen) {
struct compat_linux_dirent __user * lastdirent;
lastdirent = (void __user *)buf.current_dir - buf.prev_reclen;
if (put_user(buf.ctx.pos, >d_off))
error = -EFAULT;
else
error = count - buf.count;
}
with buf->error completely ignored. Nevermind.
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
[tytso Cc'd]
On Sat, Apr 17, 2021 at 06:09:44PM +, Al Viro wrote:
> > Al - fairly trivial patch applied, comments?
>
> Should be fine... FWIW, I've a patch in the same area, making those suckers
> return bool. Seeing that they are only ever called via dir_emit(),
> dir_emit_dot()
> and dir_emit_dotdot() and all of those return ->actor(...) == 0...
>
> Anyway, that'd be trivial to rebase on top of yours.
Actually... looking through that patch now I've noticed something fishy:
in 1f60fbe72749 ("ext4: allow readdir()'s of large empty directories to
be interrupted" we had
@@ -169,6 +169,8 @@ static int filldir(struct dir_context *ctx, const char
*name, int namlen,
}
dirent = buf->previous;
if (dirent) {
+ if (signal_pending(current))
+ return -EINTR;
and that thing is still there. However, it does *NOT* do what it might
appear to be doing; it ends up with getdents() returning -EINVAL instead.
What we need is
buf->error = -EINTR;
in addition to that return (in all 3 such places). Do you have any problems
with
the following delta?
diff --git a/fs/readdir.c b/fs/readdir.c
index 19434b3c982c..c742db935847 100644
--- a/fs/readdir.c
+++ b/fs/readdir.c
@@ -239,8 +239,10 @@ static int filldir(struct dir_context *ctx, const char
*name, int namlen,
return -EOVERFLOW;
}
prev_reclen = buf->prev_reclen;
- if (prev_reclen && signal_pending(current))
+ if (prev_reclen && signal_pending(current)) {
+ buf->error = -EINTR;
return -EINTR;
+ }
dirent = buf->current_dir;
prev = (void __user *) dirent - prev_reclen;
if (!user_write_access_begin(prev, reclen + prev_reclen))
@@ -321,8 +323,10 @@ static int filldir64(struct dir_context *ctx, const char
*name, int namlen,
if (reclen > buf->count)
return -EINVAL;
prev_reclen = buf->prev_reclen;
- if (prev_reclen && signal_pending(current))
+ if (prev_reclen && signal_pending(current)) {
+ buf->error = -EINTR;
return -EINTR;
+ }
dirent = buf->current_dir;
prev = (void __user *)dirent - prev_reclen;
if (!user_write_access_begin(prev, reclen + prev_reclen))
@@ -488,8 +492,10 @@ static int compat_filldir(struct dir_context *ctx, const
char *name, int namlen,
return -EOVERFLOW;
}
prev_reclen = buf->prev_reclen;
- if (prev_reclen && signal_pending(current))
+ if (prev_reclen && signal_pending(current)) {
+ buf->error = -EINTR;
return -EINTR;
+ }
dirent = buf->current_dir;
prev = (void __user *) dirent - prev_reclen;
if (!user_write_access_begin(prev, reclen + prev_reclen))
Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
On Sat, Apr 17, 2021 at 09:32:06PM +0300, Ilias Apalodimas wrote:
> > +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t
> > addr)
> > +{
> > + page->dma_addr[0] = addr;
> > + if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > + page->dma_addr[1] = addr >> 16 >> 16;
>
> The 'error' that was reported will never trigger right?
> I assume this was compiled with dma_addr_t as 32bits (so it triggered the
> compilation error), but the if check will never allow this codepath to run.
> If so can we add a comment explaining this, since none of us will remember why
> in 6 months from now?
That's right. I compiled it all three ways -- 32-bit, 64-bit dma, 32-bit long
and 64-bit. The 32/64 bit case turn into:
if (0)
page->dma_addr[1] = addr >> 16 >> 16;
which gets elided. So the only case that has to work is 64-bit dma and
32-bit long.
I can replace this with upper_32_bits().
PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr
Hi, kernel test robot reports: >> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of >> function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration] enable_kernel_fp(); ^ when # CONFIG_PPC_FPU is not set CONFIG_ALTIVEC=y I see at least one other place that does not handle that combination well, here: ../arch/powerpc/lib/sstep.c: In function 'do_vec_load': ../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function 'put_vr' [-Werror=implicit-function-declaration] 637 | put_vr(rn, ); | ^~ ../arch/powerpc/lib/sstep.c: In function 'do_vec_store': ../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration] 660 | get_vr(rn, ); | ^~ Should the code + Kconfigs/Makefiles handle that kind of kernel config or should ALTIVEC always mean PPC_FPU as well? I have patches to fix the build errors with the config as reported but I don't know if that's the right thing to do... thanks. -- ~Randy
Re: [PATCH 3/3] i2c: mediatek: Use scl_int_delay_ns to compensate clock-stretching
On Sat, Apr 17, 2021 at 02:46:52PM +0800, Qii Wang wrote: > The parameters of tSU,STA/tHD,STA/tSU,STOP maybe out of spec due > to device clock-stretch or circuit loss, we could get a suitable > scl_int_delay_ns from i2c_timings to compensate these parameters > to meet the spec via EXT_CONF register. > > Signed-off-by: Qii Wang Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH 2/3] i2c: mediatek: Fix wrong dma sync flag
On Sat, Apr 17, 2021 at 02:46:51PM +0800, Qii Wang wrote:
> The right flag is apdma_sync when apdma remove hand-shake signel.
>
> Signed-off-by: Qii Wang
Added:
Fixes: 05f6f7271a38 ("i2c: mediatek: Fix apdma and i2c hand-shake timeout")
and applied to for-next, thanks!
signature.asc
Description: PGP signature
Re: [PATCH 1/3] i2c: mediatek: Fix send master code at more than 1MHz
On Sat, Apr 17, 2021 at 02:46:50PM +0800, Qii Wang wrote:
> There are some omissions in the previous patch about replacing
> I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and
> need to fix it.
>
> Fixes: b44658e755b5("i2c: mediatek: Send i2c master code at more than 1MHz")
> Signed-off-by: Qii Wang
Applied to for-next, thanks!
signature.asc
Description: PGP signature
[PATCH] capabilities: require CAP_SETFCAP to map uid 0 (v3.2)
A process running as uid 0 but without cap_setfcap currently can simply
unshare a new user namespace with uid 0 mapped to 0. While this task
will not have new capabilities against the parent namespace, there is
a loophole due to the way namespaced file capabilities work. File
capabilities valid in userns 1 are distinguised from file capabilities
valid in userns 2 by the kuid which underlies uid 0. Therefore
the restricted root process can unshare a new self-mapping namespace,
add a namespaced file capability onto a file, then use that file
capability in the parent namespace.
To prevent that, do not allow mapping uid 0 if the process which
opened the uid_map file does not have CAP_SETFCAP, which is the capability
for setting file capabilities.
A further wrinkle: a task can unshare its user namespace, then
open its uid_map file itself, and map (only) its own uid. In this
case we do not have the credential from before unshare, which was
potentially more restricted. So, when creating a user namespace, we
record whether the creator had CAP_SETFCAP. Then we can use that
during map_write().
With this patch:
1. unprivileged user can still unshare -Ur
ubuntu@caps:~$ unshare -Ur
root@caps:~# logout
2. root user can still unshare -Ur
ubuntu@caps:~$ sudo bash
root@caps:/home/ubuntu# unshare -Ur
root@caps:/home/ubuntu# logout
3. root user without CAP_SETFCAP cannot unshare -Ur:
root@caps:/home/ubuntu# /sbin/capsh --drop=cap_setfcap --
root@caps:/home/ubuntu# /sbin/setcap cap_setfcap=p /sbin/setcap
unable to set CAP_SETFCAP effective capability: Operation not permitted
root@caps:/home/ubuntu# unshare -Ur
unshare: write failed /proc/self/uid_map: Operation not permitted
Signed-off-by: Serge Hallyn
Changelog:
* fix logic in the case of writing to another task's uid_map
* rename 'ns' to 'map_ns', and make a file_ns local variable
* use /* comments */
* update the CAP_SETFCAP comment in capability.h
* rename parent_unpriv to parent_can_setfcap (and reverse the
logic)
* remove printks
* clarify (i hope) the code comments
* update capability.h comment
* renamed parent_can_setfcap to parent_could_setfcap
* made the check its own disallowed_0_mapping() fn
* moved the check into new_idmap_permitted
* rename disallowed_0_mapping to verify_root_mapping
* change verify_root_mapping to Christian's suggested flow
---
include/linux/user_namespace.h | 3 ++
include/uapi/linux/capability.h | 3 +-
kernel/user_namespace.c | 66 +++--
3 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 64cf8ebdc4ec..f6c5f784be5a 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -63,6 +63,9 @@ struct user_namespace {
kgid_t group;
struct ns_commonns;
unsigned long flags;
+ /* parent_could_setfcap: true if the creator if this ns had CAP_SETFCAP
+* in its effective capability set at the child ns creation time. */
+ boolparent_could_setfcap;
#ifdef CONFIG_KEYS
/* List of joinable keyrings in this namespace. Modification access of
diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index c6ca33034147..2ddb4226cd23 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -335,7 +335,8 @@ struct vfs_ns_cap_data {
#define CAP_AUDIT_CONTROL30
-/* Set or remove capabilities on files */
+/* Set or remove capabilities on files.
+ Map uid=0 into a child user namespace. */
#define CAP_SETFCAP 31
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index af612945a4d0..2ead291177b0 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -106,6 +106,7 @@ int create_user_ns(struct cred *new)
if (!ns)
goto fail_dec;
+ ns->parent_could_setfcap = cap_raised(new->cap_effective, CAP_SETFCAP);
ret = ns_alloc_inum(>ns);
if (ret)
goto fail_free;
@@ -841,6 +842,61 @@ static int sort_idmaps(struct uid_gid_map *map)
return 0;
}
+/**
+ * verify_root_map() - check the uid 0 mapping
+ * @file: idmapping file
+ * @map_ns: user namespace of the target process
+ * @new_map: requested idmap
+ *
+ * If a process requested a mapping for uid 0 onto uid 0, verify that the
+ * process writing the map had the CAP_SETFCAP capability as the target process
+ * will be able to write fscaps that are valid in ancestor user namespaces.
+ *
+ * Return: true if the mapping is allowed, false if not.
+ */
+static bool verify_root_map(const struct file *file,
+ struct user_namespace *map_ns,
+ struct uid_gid_map *new_map)
+{
+ int idx;
+ const struct user_namespace *file_ns = file->f_cred->user_ns;
+ struct uid_gid_extent *extent0 = NULL;
Re: [PATCH v9 8/8] pwm: pca9685: Add error messages for failed regmap calls
On Thu, Apr 15, 2021 at 02:14:55PM +0200, Clemens Gruber wrote: > Regmap operations can fail if the underlying subsystem is not working > properly (e.g. hogged I2C bus, etc.) > As this is useful information for the user, print an error message if it > happens. > Let probe fail if the first regmap_read or the first regmap_write fails. > > Signed-off-by: Clemens Gruber Acked-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH v9 7/8] pwm: pca9685: Restrict period change for enabled PWMs
On Thu, Apr 15, 2021 at 02:14:54PM +0200, Clemens Gruber wrote: > Previously, the last used PWM channel could change the global prescale > setting, even if other channels are already in use. > > Fix it by only allowing the first enabled PWM to change the global > chip-wide prescale setting. If there is more than one channel in use, > the prescale settings resulting from the chosen periods must match. > > GPIOs do not count as enabled PWMs as they are not using the prescaler > and can't change it. > > Signed-off-by: Clemens Gruber Acked-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH v9 2/8] pwm: pca9685: Support hardware readout
Hello, On Thu, Apr 15, 2021 at 02:14:49PM +0200, Clemens Gruber wrote: > Implement .get_state to read-out the current hardware state. > > The hardware readout may return slightly different values than those > that were set in apply due to the limited range of possible prescale and > counter register values. > > Also note that although the datasheet mentions 200 Hz as default > frequency when using the internal 25 MHz oscillator, the calculated > period from the default prescaler register setting of 30 is 5079040ns. > > Signed-off-by: Clemens Gruber > --- > Changes since v8: > - As we left the math in apply as-is, use DIV_ROUND_DOWN in get_state I first thought this was wrong, because .apply uses ROUND_CLOSEST for period and ROUND_UP for duty. But as the calculation for period is exact this doesn't matter and round-down is indeed correct here. Reviewed-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH 2/4] staging: rtl8188eu: remove constant variable and dead code
Hi Martin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Martin-Kaiser/staging-rtl8188eu-change-bLeisurePs-type-to-bool/20210418-020200
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
71d3edc61e29e45b613b841108688d711846f969
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
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
#
https://github.com/0day-ci/linux/commit/c2b80185c47f9f13ed748eca0df39494668481ee
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Martin-Kaiser/staging-rtl8188eu-change-bLeisurePs-type-to-bool/20210418-020200
git checkout c2b80185c47f9f13ed748eca0df39494668481ee
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1
ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/staging/rtl8188eu/os_dep/rtw_android.c:60: warning: Function
parameter or member 'cmdstr' not described in 'rtw_android_cmdstr_to_num'
>> drivers/staging/rtl8188eu/os_dep/rtw_android.c:60: warning: expecting
>> prototype for functions(). Prototype was for rtw_android_cmdstr_to_num()
>> instead
vim +60 drivers/staging/rtl8188eu/os_dep/rtw_android.c
5adef66acf7370 Larry Finger 2013-08-21 54
5adef66acf7370 Larry Finger 2013-08-21 55 /**
c2b80185c47f9f Martin Kaiser2021-04-17 56 * Local (static) functions
5adef66acf7370 Larry Finger 2013-08-21 57 */
5adef66acf7370 Larry Finger 2013-08-21 58
5adef66acf7370 Larry Finger 2013-08-21 59 int
rtw_android_cmdstr_to_num(char *cmdstr)
5adef66acf7370 Larry Finger 2013-08-21 @60 {
5adef66acf7370 Larry Finger 2013-08-21 61 int cmd_num;
37ad17a4b48ca7 Yamanappagouda Patil 2016-12-22 62
5adef66acf7370 Larry Finger 2013-08-21 63 for (cmd_num = 0;
cmd_num < ANDROID_WIFI_CMD_MAX; cmd_num++)
fd078b42096163 Puranjay Mohan 2019-05-21 64 if
(!strncasecmp(cmdstr, android_wifi_cmd_str[cmd_num],
5adef66acf7370 Larry Finger 2013-08-21 65
strlen(android_wifi_cmd_str[cmd_num])))
5adef66acf7370 Larry Finger 2013-08-21 66 break;
5adef66acf7370 Larry Finger 2013-08-21 67 return cmd_num;
5adef66acf7370 Larry Finger 2013-08-21 68 }
5adef66acf7370 Larry Finger 2013-08-21 69
---
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 v9 1/8] pwm: pca9685: Switch to atomic API
On Thu, Apr 15, 2021 at 02:14:48PM +0200, Clemens Gruber wrote: > The switch to the atomic API goes hand in hand with a few fixes to > previously experienced issues: > - The duty cycle is no longer lost after disable/enable (previously the > OFF registers were cleared in disable and the user was required to > call config to restore the duty cycle settings) > - If one sets a period resulting in the same prescale register value, > the sleep and write to the register is now skipped > - Previously, only the full ON bit was toggled in GPIO mode (and full > OFF cleared if set to high), which could result in both full OFF and > full ON not being set and on=0, off=0, which is not allowed according > to the datasheet > - The OFF registers were reset to 0 in probe, which could lead to the > forbidden on=0, off=0. Fixed by resetting to POR default (full OFF) > > Signed-off-by: Clemens Gruber (I sent my ack to v8 before, but indeed this was the version I intended to ack) Acked-by: Uwe Kleine-König -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
On Sat, Apr 17, 2021 at 12:44 PM Eric Dumazet wrote: > > I thought put_cmsg() callers were from the kernel, with no possibility > for user to abuse this interface trying to push GB of data. My point is that "I thought" is not good enough for the unsafe interfaces. It needs to be "I can see that the arguments are properly verified". That is literally why they are called "unsafe". You need to make the uses obviously safe. Because the functions themselves don't do that. Linus
Re: [PATCHv3] Introduced new tracing mode KCOV_MODE_UNIQUE.
On Fri, Apr 16, 2021 at 10:42 AM Dmitry Vyukov wrote: > > On Sat, Mar 27, 2021 at 3:56 PM Andrey Konovalov wrote: > > > > On Fri, Mar 26, 2021 at 9:52 PM Alexander Lochmann > > wrote: > > > > > > > Hi Alexander, > > > > > It simply stores the executed PCs. > > > The execution order is discarded. > > > Each bit in the shared buffer represents every fourth > > > byte of the text segment. > > > Since a call instruction on every supported > > > architecture is at least four bytes, it is safe > > > to just store every fourth byte of the text segment. > > > > What about jumps? > > KCOV adds call __sanitizer_cov_trace_pc per coverage point. So besides > the instructions in the original code, we also always have this call. Ah, I see. This should be explained in the changelog. This means that a KCOV user will need the kernel binary to recover the actual PCs that were covered, as the information about the lower two bits is lost, right? This needs to be explained as well. Thanks!
[ANNOUNCE] 5.4.109-rt56
Hello RT Folks! I'm pleased to announce the 5.4.109-rt56 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v5.4-rt Head SHA1: a84a83ce44cafc96cb9cf419378a713dcdea00ac Or to build 5.4.109-rt56 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.4.tar.xz https://www.kernel.org/pub/linux/kernel/v5.x/patch-5.4.109.xz https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/patch-5.4.109-rt56.patch.xz You can also build from 5.4.109-rt55 by applying the incremental patch: https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch-5.4.109-rt55-rt56.patch.xz Enjoy! Tom Changes from v5.4.109-rt55: --- Sebastian Andrzej Siewior (1): mm: slub: Don't resize the location tracking cache on PREEMPT_RT Tom Zanussi (1): Linux 5.4.109-rt56 --- localversion-rt | 2 +- mm/slub.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) --- diff --git a/localversion-rt b/localversion-rt index 51b05e9abe6f..fdb0f880c7e9 100644 --- a/localversion-rt +++ b/localversion-rt @@ -1 +1 @@ --rt55 +-rt56 diff --git a/mm/slub.c b/mm/slub.c index 1815e28852fe..0d78368d149a 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4647,6 +4647,9 @@ static int alloc_loc_track(struct loc_track *t, unsigned long max, gfp_t flags) struct location *l; int order; + if (IS_ENABLED(CONFIG_PREEMPT_RT) && flags == GFP_ATOMIC) + return 0; + order = get_order(sizeof(struct location) * max); l = (void *)__get_free_pages(flags, order);
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
On Sat, Apr 17, 2021 at 6:03 PM Linus Torvalds wrote: > > On Fri, Apr 16, 2021 at 12:24 PM Eric Dumazet wrote: > > > > From: Eric Dumazet > > > > We have to loop only to copy u64 values. > > After this first loop, we copy at most one u32, one u16 and one byte. > > As Al mentioned, at least in trivial cases the compiler understands > that the subsequent loops can only be executed once, because earlier > loops made sure that 'len' is always smaller than 2*size. > > But apparently the problem is the slightly more complex cases where > the compiler just messes up and loses sight of that. Oh well. > > So the patch looks fine to me. > > HOWEVER. > > Looking at the put_cmsg() case in net-next, I'm very *VERY* unhappy > about how you use those "unsafe" user access functions. > > Why? Because the point of the "unsafe" is to be a big red flag and > make sure you are very VERY careful with it. > > And that code isn't. > > In particular, what if the "int len" argument is negative? Maybe it > cannot happen, but when it comes to things like those unsafe user > accessors, I really really want to see that all the arguments are > *checked*. > > And you don't. > > You do > > if (!user_write_access_begin(cm, cmlen)) > > ahead of time, and that will do basic range checking, but "cmlen" is > > sizeof(struct cmsghdr) + (len)) > > so it's entirely possible that "cmlen" has a valid value, but "len" > (and thus "cmlen - sizeof(*cm)", which is the length argument to the > unsafe user copy) might be negative and that is never checked. > > End result: I want people to be a LOT more careful when they use those > unsafe user space accessors. You need to make it REALLY REALLY obvious > that everything you do is safe. And it's not at all obvious in the > context of put_cmsg() - the safety currently relies on every single > caller getting it right. I thought put_cmsg() callers were from the kernel, with no possibility for user to abuse this interface trying to push GB of data. Which would be terrible even if we ' fix' possible overflows. Maybe I was wrong. > > So either fix "len" to be some restricted type (ie "unsigned short"), > or make really really sure that "len" is valid (ie never negative, and > the cmlen addition didn't overflow. > > Really. The "unsafe" user accesses are named that way very explicitly, > and for a very very good reason: the safety needs to be guaranteed and > obvious within the context of those accesses. Not within some "oh, > nobody will ever call this with a negative argument" garbage bullshit. > > Linus
Re: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain to zero
On Saturday 17 April 2021 17:19:38 Andrew Lunn wrote: > > Currently this code is implemented in pci_bus_find_domain_nr() function. > > IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB > > of memory. I'm not sure if it is fine or some other tree-based structure > > for allocated domain numbers is needed. > > Hi Pali > > Have a look at lib/idr.c > > Andrew Great! So number allocation is already implemented in kernel (via radix trees).
Re: [PATCH 04/13] Kbuild: Rust support
On Thu, Apr 15, 2021 at 9:43 AM Miguel Ojeda
wrote:
>
> On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers
> wrote:
> >
> > Rather than check the origin (yikes, are we intentionally avoiding env
> > vars?), can this simply be
> > ifneq ($(CLIPPY),)
> > KBUILD_CLIPPY := $(CLIPPY)
> > endif
> >
> > Then you can specify whatever value you want, support command line or
> > env vars, etc.?
>
> I was following the other existing cases like `V`. Masahiro can
> probably answer why they are done like this.
You are asking about this code:
ifeq ("$(origin V)", "command line")
KBUILD_VERBOSE = $(V)
endif
You can pass V=1 from the Make command line,
but not from the environment.
KBUILD_VERBOSE is intended as an environment variable,
but you can use it from the Make command line.
Work:
- make V=1
- make KBUILD_VERBOSE=1
- KBUILD_VERBOSE=1 make
Not work:
- V=1 make
The behavior is like that before I became the maintainer.
In my best guess, the reason is,
V=1 is a useful shorthand of KBUILD_VERBOSE=1,
but it is too short. It should not accidentally
pick up an unintended environment variable.
--
Best Regards
Masahiro Yamada
Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang
On 4/17/21 13:29, Jes Sorensen wrote: > On 3/10/21 3:59 PM, Kees Cook wrote: >> On Wed, Mar 10, 2021 at 02:51:24PM -0500, Jes Sorensen wrote: >>> On 3/10/21 2:45 PM, Kees Cook wrote: On Wed, Mar 10, 2021 at 02:31:57PM -0500, Jes Sorensen wrote: > On 3/10/21 2:14 PM, Kees Cook wrote: >> Hm, this conversation looks like a miscommunication, mainly? I see >> Gustavo, as requested by many others[1], replacing the fallthrough >> comments with the "fallthrough" statement. (This is more than just a >> "Clang doesn't parse comments" issue.) >> >> This could be a tree-wide patch and not bother you, but Greg KH has >> generally advised us to send these changes broken out. Anyway, this >> change still needs to land, so what would be the preferred path? I think >> Gustavo could just carry it for Linus to merge without bothering you if >> that'd be preferred? > > I'll respond with the same I did last time, fallthrough is not C and > it's ugly. I understand your point of view, but this is not the consensus[1] of the community. "fallthrough" is a macro, using the GCC fallthrough attribute, with the expectation that we can move to the C17/C18 "[[fallthrough]]" statement once it is finalized by the C standards body. >>> >>> I don't know who decided on that, but I still disagree. It's an ugly and >>> pointless change that serves little purpose. We shouldn't have allowed >>> the ugly /* fall-through */ comments in either, but at least they didn't >>> mess with the code. I guess when you give someone an inch, they take a mile. >>> >>> Last time this came up, the discussion was that clang refused to fix >>> their brokenness and therefore this nonsense was being pushed into the >>> kernel. It's still a pointless argument, if clang can't fix it's crap, >>> then stop using it. >>> >>> As Kalle correctly pointed out, none of the previous comments to this >>> were addressed, the patches were just reposted as fact. Not exactly a >>> nice way to go about it either. >> >> Do you mean changing the commit log to re-justify these changes? I >> guess that could be done, but based on the thread, it didn't seem to >> be needed. The change is happening to match the coding style consensus >> reached to give the kernel the flexibility to move from a gcc extension >> to the final C standards committee results without having to do treewide >> commits again (i.e. via the macro). > > No, I am questioning why Gustavo continues to push this nonsense that > serves no purpose whatsoever. In addition he has consistently ignored > comments and just keep reposting it. But I guess that is how it works, > ignore feedback, repost junk, repeat. I was asking for feedback here[1] and here[2] after people (you and Kalle) commented on this patch. How is that ignoring people? And -again- why people ignored my requests for feedback in this conversation? It's a mystery to me, honestly. Thanks -- Gustavo [1] https://lore.kernel.org/lkml/20201124160906.GB17735@embeddedor/ [2] https://lore.kernel.org/lkml/e10b2a6a-d91a-9783-ddbe-ea2c10a15...@embeddedor.com/
I wait for your response.
Dear Beloved, How are you doing, hope all is well? Please I am verifying if your email is still working, I have sent you several messages, but could not get any reply from you, would you get back to me? I have an important message for you. Please write me through my private email for more clarification: ( mrsagataarno...@gmail.com ) Warm Regards, Agata Arnoldo.
Re: [PULL REQUEST] i2c for 5.12
The pull request you sent on Sat, 17 Apr 2021 19:18:16 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/194cf4825638256e9afe1d360831aa5379b3517a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] media: atomisp: silence "dubious: !x | !y" warning
Em Sat, 17 Apr 2021 21:06:27 +0530 Ashish Kalra escreveu: > Upon running sparse, "warning: dubious: !x | !y" is brought to notice > for this file. Logical and bitwise OR are basically the same in this > context so it doesn't cause a runtime bug. But let's change it to > logical OR to make it cleaner and silence the Sparse warning. > > Signed-off-by: Ashish Kalra > --- > .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > index 358cb7d2cd4c..3b850bb2d39d 100644 > --- a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > +++ b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( > unsigned int ds_log2 = 0; > unsigned int out_width; > > - if ((!out_info) | (!vf_info)) > + if ((!out_info) || (!vf_info)) While here, please get rid of the unneeded parenthesis: if (!out_info || !vf_info) > return -EINVAL; > > out_width = out_info->res.width; Thanks, Mauro
Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
Hi Matthew,
On Sat, Apr 17, 2021 at 03:45:22AM +0100, Matthew Wilcox wrote:
>
> Replacement patch to fix compiler warning.
>
> From: "Matthew Wilcox (Oracle)"
> Date: Fri, 16 Apr 2021 16:34:55 -0400
> Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
> To: bro...@redhat.com
> Cc: linux-kernel@vger.kernel.org,
> linux...@kvack.org,
> net...@vger.kernel.org,
> linuxppc-...@lists.ozlabs.org,
> linux-arm-ker...@lists.infradead.org,
> linux-m...@vger.kernel.org,
> ilias.apalodi...@linaro.org,
> mcr...@linux.microsoft.com,
> grygorii.stras...@ti.com,
> a...@kernel.org,
> h...@lst.de,
> linux-snps-...@lists.infradead.org,
> mho...@kernel.org,
> mgor...@suse.de
>
> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019. When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
>
> Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> This restores the alignment to that of an unsigned long, and also fixes a
> potential problem where (on a big endian platform), the bit used to denote
> PageTail could inadvertently get set, and a racing get_user_pages_fast()
> could dereference a bogus compound_head().
>
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
> include/linux/mm_types.h | 4 ++--
> include/net/page_pool.h | 12 +++-
> net/core/page_pool.c | 12 +++-
> 3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6613b26a8894..5aacc1c10a45 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
> };
> struct {/* page_pool used by netstack */
> /**
> - * @dma_addr: might require a 64-bit value even on
> + * @dma_addr: might require a 64-bit value on
>* 32-bit architectures.
>*/
> - dma_addr_t dma_addr;
> + unsigned long dma_addr[2];
> };
> struct {/* slab, slob and slub */
> union {
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..ad6154dc206c 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct
> page_pool *pool,
>
> static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
> {
> - return page->dma_addr;
> + dma_addr_t ret = page->dma_addr[0];
> + if (sizeof(dma_addr_t) > sizeof(unsigned long))
> + ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;
> + return ret;
> +}
> +
> +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> +{
> + page->dma_addr[0] = addr;
> + if (sizeof(dma_addr_t) > sizeof(unsigned long))
> + page->dma_addr[1] = addr >> 16 >> 16;
The 'error' that was reported will never trigger right?
I assume this was compiled with dma_addr_t as 32bits (so it triggered the
compilation error), but the if check will never allow this codepath to run.
If so can we add a comment explaining this, since none of us will remember why
in 6 months from now?
> }
>
> static inline bool is_page_pool_compiled_in(void)
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index ad8b0707af04..f014fd8c19a6 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct
> page_pool *pool,
> struct page *page,
> unsigned int dma_sync_size)
> {
> + dma_addr_t dma_addr = page_pool_get_dma_addr(page);
> +
> dma_sync_size = min(dma_sync_size, pool->p.max_len);
> - dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
> + dma_sync_single_range_for_device(pool->p.dev, dma_addr,
>pool->p.offset, dma_sync_size,
>pool->p.dma_dir);
> }
> @@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct
> page_pool *pool,
> put_page(page);
> return NULL;
> }
> - page->dma_addr = dma;
> + page_pool_set_dma_addr(page, dma);
>
> if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
> page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
> @@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool,
> struct page *page)
>*/
> goto skip_dma_unmap;
>
> - dma = page->dma_addr;
> + dma =
Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang
On 4/17/21 1:52 PM, Kalle Valo wrote: > "Gustavo A. R. Silva" wrote: > >> In preparation to enable -Wimplicit-fallthrough for Clang, fix >> multiple warnings by replacing /* fall through */ comments with >> the new pseudo-keyword macro fallthrough; instead of letting the >> code fall through to the next case. >> >> Notice that Clang doesn't recognize /* fall through */ comments as >> implicit fall-through markings. >> >> Link: https://github.com/KSPP/linux/issues/115 >> Signed-off-by: Gustavo A. R. Silva > > Patch applied to wireless-drivers-next.git, thanks. > > bf3365a856a1 rtl8xxxu: Fix fall-through warnings for Clang > Sorry this junk patch should not have been applied. Jes
