Re: [PATCH] pinctrl: sprd: Use define directive for sprd_pinconf_params values
On 1 November 2018 at 08:44, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another:
>
> drivers/pinctrl/sprd/pinctrl-sprd.c:845:19: warning: implicit conversion
> from enumeration type 'enum sprd_pinconf_params' to different
> enumeration type 'enum pin_config_param' [-Wenum-conversion]
> {"sprd,control", SPRD_PIN_CONFIG_CONTROL, 0},
> ~^~~
> drivers/pinctrl/sprd/pinctrl-sprd.c:846:22: warning: implicit conversion
> from enumeration type 'enum sprd_pinconf_params' to different
> enumeration type 'enum pin_config_param' [-Wenum-conversion]
> {"sprd,sleep-mode", SPRD_PIN_CONFIG_SLEEP_MODE, 0},
> ~ ^~
>
> It is expected that pinctrl drivers can extend pin_config_param because
> of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
> isn't an issue. Most drivers that take advantage of this define the
> PIN_CONFIG variables as constants, rather than enumerated values. Do the
> same thing here so that Clang no longer warns.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/138
> Signed-off-by: Nathan Chancellor
> ---
Looks reasonable to me. Thanks.
Reviewed-by: Baolin Wang
--
Baolin Wang
Best Regards
Re: [PATCH] pinctrl: sprd: Use define directive for sprd_pinconf_params values
On 1 November 2018 at 08:44, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another:
>
> drivers/pinctrl/sprd/pinctrl-sprd.c:845:19: warning: implicit conversion
> from enumeration type 'enum sprd_pinconf_params' to different
> enumeration type 'enum pin_config_param' [-Wenum-conversion]
> {"sprd,control", SPRD_PIN_CONFIG_CONTROL, 0},
> ~^~~
> drivers/pinctrl/sprd/pinctrl-sprd.c:846:22: warning: implicit conversion
> from enumeration type 'enum sprd_pinconf_params' to different
> enumeration type 'enum pin_config_param' [-Wenum-conversion]
> {"sprd,sleep-mode", SPRD_PIN_CONFIG_SLEEP_MODE, 0},
> ~ ^~
>
> It is expected that pinctrl drivers can extend pin_config_param because
> of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
> isn't an issue. Most drivers that take advantage of this define the
> PIN_CONFIG variables as constants, rather than enumerated values. Do the
> same thing here so that Clang no longer warns.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/138
> Signed-off-by: Nathan Chancellor
> ---
Looks reasonable to me. Thanks.
Reviewed-by: Baolin Wang
--
Baolin Wang
Best Regards
Re: INFO: rcu detected stall in do_idle
On 31/10/18 18:58, Daniel Bristot de Oliveira wrote: > On 10/31/18 5:40 PM, Juri Lelli wrote: > > On 31/10/18 17:18, Daniel Bristot de Oliveira wrote: > >> On 10/30/18 12:08 PM, luca abeni wrote: > >>> Hi Peter, > >>> > >>> On Tue, 30 Oct 2018 11:45:54 +0100 > >>> Peter Zijlstra wrote: > >>> [...] > > 2. This is related to perf_event_open syscall reproducer does > > before becoming DEADLINE and entering the busy loop. Enabling of > > perf swevents generates lot of hrtimers load that happens in the > > reproducer task context. Now, DEADLINE uses rq_clock() for > > setting deadlines, but rq_clock_task() for doing runtime > > enforcement. In a situation like this it seems that the amount of > > irq pressure becomes pretty big (I'm seeing this on kvm, real hw > > should maybe do better, pain point remains I guess), so rq_clock() > > and rq_clock_task() might become more a more skewed w.r.t. each > > other. Since rq_clock() is only used when setting absolute > > deadlines for the first time (or when resetting them in certain > > cases), after a bit the replenishment code will start to see > > postponed deadlines always in the past w.r.t. rq_clock(). And this > > brings us back to the fact that the task is never stopped, since it > > can't keep up with rq_clock(). > > > > - Not sure yet how we want to address this [1]. We could use > > rq_clock() everywhere, but tasks might be penalized by irq > > pressure (theoretically this would mandate that irqs are > > explicitly accounted for I guess). I tried to use the skew > > between the two clocks to "fix" deadlines, but that puts us at > > risks of de-synchronizing userspace and kernel views of deadlines. > > Hurm.. right. We knew of this issue back when we did it. > I suppose now it hurts and we need to figure something out. > > By virtue of being a real-time class, we do indeed need to have > deadline on the wall-clock. But if we then don't account runtime on > that same clock, but on a potentially slower clock, we get the > problem that we can run longer than our period/deadline, which is > what we're running into here I suppose. > >>> > >>> I might be hugely misunderstanding something here, but in my impression > >>> the issue is just that if the IRQ time is not accounted to the > >>> -deadline task, then the non-deadline tasks might be starved. > >>> > >>> I do not see this as a skew between two clocks, but as an accounting > >>> thing: > >>> - if we decide that the IRQ time is accounted to the -deadline > >>> task (this is what happens with CONFIG_IRQ_TIME_ACCOUNTING disabled), > >>> then the non-deadline tasks are not starved (but of course the > >>> -deadline tasks executes for less than its reserved time in the > >>> period); > >>> - if we decide that the IRQ time is not accounted to the -deadline task > >>> (this is what happens with CONFIG_IRQ_TIME_ACCOUNTING enabled), then > >>> the -deadline task executes for the expected amount of time (about > >>> 60% of the CPU time), but an IRQ load of 40% will starve non-deadline > >>> tasks (this is what happens in the bug that triggered this discussion) > >>> > >>> I think this might be seen as an adimission control issue: when > >>> CONFIG_IRQ_TIME_ACCOUNTING is disabled, the IRQ time is accounted for > >>> in the admission control (because it ends up in the task's runtime), > >>> but when CONFIG_IRQ_TIME_ACCOUNTING is enabled the IRQ time is not > >>> accounted for in the admission test (the IRQ handler becomes some sort > >>> of entity with a higher priority than -deadline tasks, on which no > >>> accounting or enforcement is performed). > >>> > >> > >> I am sorry for taking to long to join in the discussion. > >> > >> I agree with Luca. I've seem this behavior two time before. Firstly when > >> we were > >> trying to make the rt throttling to have a very short runtime for non-rt > >> threads, and then in the proof of concept of the semi-partitioned > >> scheduler. > >> > >> Firstly, I started thinking on this as a skew between both clocks and > >> disabled > >> IRQ_TIME_ACCOUNTING. But by ignoring IRQ accounting, we are assuming that > >> the > >> IRQ runtime will be accounted as the thread's runtime. In other words, we > >> are > >> just sweeping the trash under the rug, where the rug is the worst case > >> execution > >> time estimation/definition (which is an even more complex problem). In the > >> Brazilian part of the Ph.D we are dealing with probabilistic worst case > >> execution time, and to be able to use probabilistic methods, we need to > >> remove > >> the noise of the IRQs in the execution time [1]. So, IMHO, using > >> CONFIG_IRQ_TIME_ACCOUNTING is a good thing. > >> > >> The fact that we have barely no control of the execution of IRQs, at first > >> glance, let us think that the idea of considering an IRQ as a
Re: INFO: rcu detected stall in do_idle
On 31/10/18 18:58, Daniel Bristot de Oliveira wrote: > On 10/31/18 5:40 PM, Juri Lelli wrote: > > On 31/10/18 17:18, Daniel Bristot de Oliveira wrote: > >> On 10/30/18 12:08 PM, luca abeni wrote: > >>> Hi Peter, > >>> > >>> On Tue, 30 Oct 2018 11:45:54 +0100 > >>> Peter Zijlstra wrote: > >>> [...] > > 2. This is related to perf_event_open syscall reproducer does > > before becoming DEADLINE and entering the busy loop. Enabling of > > perf swevents generates lot of hrtimers load that happens in the > > reproducer task context. Now, DEADLINE uses rq_clock() for > > setting deadlines, but rq_clock_task() for doing runtime > > enforcement. In a situation like this it seems that the amount of > > irq pressure becomes pretty big (I'm seeing this on kvm, real hw > > should maybe do better, pain point remains I guess), so rq_clock() > > and rq_clock_task() might become more a more skewed w.r.t. each > > other. Since rq_clock() is only used when setting absolute > > deadlines for the first time (or when resetting them in certain > > cases), after a bit the replenishment code will start to see > > postponed deadlines always in the past w.r.t. rq_clock(). And this > > brings us back to the fact that the task is never stopped, since it > > can't keep up with rq_clock(). > > > > - Not sure yet how we want to address this [1]. We could use > > rq_clock() everywhere, but tasks might be penalized by irq > > pressure (theoretically this would mandate that irqs are > > explicitly accounted for I guess). I tried to use the skew > > between the two clocks to "fix" deadlines, but that puts us at > > risks of de-synchronizing userspace and kernel views of deadlines. > > Hurm.. right. We knew of this issue back when we did it. > I suppose now it hurts and we need to figure something out. > > By virtue of being a real-time class, we do indeed need to have > deadline on the wall-clock. But if we then don't account runtime on > that same clock, but on a potentially slower clock, we get the > problem that we can run longer than our period/deadline, which is > what we're running into here I suppose. > >>> > >>> I might be hugely misunderstanding something here, but in my impression > >>> the issue is just that if the IRQ time is not accounted to the > >>> -deadline task, then the non-deadline tasks might be starved. > >>> > >>> I do not see this as a skew between two clocks, but as an accounting > >>> thing: > >>> - if we decide that the IRQ time is accounted to the -deadline > >>> task (this is what happens with CONFIG_IRQ_TIME_ACCOUNTING disabled), > >>> then the non-deadline tasks are not starved (but of course the > >>> -deadline tasks executes for less than its reserved time in the > >>> period); > >>> - if we decide that the IRQ time is not accounted to the -deadline task > >>> (this is what happens with CONFIG_IRQ_TIME_ACCOUNTING enabled), then > >>> the -deadline task executes for the expected amount of time (about > >>> 60% of the CPU time), but an IRQ load of 40% will starve non-deadline > >>> tasks (this is what happens in the bug that triggered this discussion) > >>> > >>> I think this might be seen as an adimission control issue: when > >>> CONFIG_IRQ_TIME_ACCOUNTING is disabled, the IRQ time is accounted for > >>> in the admission control (because it ends up in the task's runtime), > >>> but when CONFIG_IRQ_TIME_ACCOUNTING is enabled the IRQ time is not > >>> accounted for in the admission test (the IRQ handler becomes some sort > >>> of entity with a higher priority than -deadline tasks, on which no > >>> accounting or enforcement is performed). > >>> > >> > >> I am sorry for taking to long to join in the discussion. > >> > >> I agree with Luca. I've seem this behavior two time before. Firstly when > >> we were > >> trying to make the rt throttling to have a very short runtime for non-rt > >> threads, and then in the proof of concept of the semi-partitioned > >> scheduler. > >> > >> Firstly, I started thinking on this as a skew between both clocks and > >> disabled > >> IRQ_TIME_ACCOUNTING. But by ignoring IRQ accounting, we are assuming that > >> the > >> IRQ runtime will be accounted as the thread's runtime. In other words, we > >> are > >> just sweeping the trash under the rug, where the rug is the worst case > >> execution > >> time estimation/definition (which is an even more complex problem). In the > >> Brazilian part of the Ph.D we are dealing with probabilistic worst case > >> execution time, and to be able to use probabilistic methods, we need to > >> remove > >> the noise of the IRQs in the execution time [1]. So, IMHO, using > >> CONFIG_IRQ_TIME_ACCOUNTING is a good thing. > >> > >> The fact that we have barely no control of the execution of IRQs, at first > >> glance, let us think that the idea of considering an IRQ as a
[GIT PULL] Addition of the I3C subsystem in 4.20 (5.0)?
Hello Greg, Linus, Greg, I didn't get your feedback on v10 of the i3c patchset [1] where I was asking if you'd agree to have this framework merged in 4.20 (I know you were busy with the 4.19 release and after that the Kernel Summit, so that's not a surprise), so I'm sending this PR. It's really not an attempt to bypass you, more like a ping that, if positively acknowledged, might lead to inclusion of the I3C framework in 4.20 (5.0?) :-). Please let me know if you're opposed to the idea. Regards, Boris [1]https://lkml.org/lkml/2018/10/26/552 The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git tags/i3c/for-4.20 for you to fetch changes up to 71e60757e1eab6f7b821585948317961ccdc61d1: dt-bindings: i3c: Document Cadence I3C master bindings (2018-11-01 06:12:05 +0100) Add the I3C framework + an I3C controller driver for Cadence IP Boris Brezillon (7): i3c: Add core I3C infrastructure docs: driver-api: Add I3C documentation i3c: Add sysfs ABI spec dt-bindings: i3c: Document core bindings MAINTAINERS: Add myself as the I3C subsystem maintainer i3c: master: Add driver for Cadence IP dt-bindings: i3c: Document Cadence I3C master bindings Documentation/ABI/testing/sysfs-bus-i3c | 146 ++ Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt | 44 + Documentation/devicetree/bindings/i3c/i3c.txt | 139 ++ Documentation/driver-api/i3c/device-driver-api.rst|9 + Documentation/driver-api/i3c/index.rst| 11 + Documentation/driver-api/i3c/master-driver-api.rst| 10 + Documentation/driver-api/i3c/protocol.rst | 203 +++ Documentation/driver-api/index.rst|1 + MAINTAINERS | 12 + drivers/Kconfig |2 + drivers/Makefile |2 +- drivers/i3c/Kconfig | 24 + drivers/i3c/Makefile |4 + drivers/i3c/device.c | 233 drivers/i3c/internals.h | 26 + drivers/i3c/master.c | 2661 + drivers/i3c/master/Kconfig|6 + drivers/i3c/master/Makefile |1 + drivers/i3c/master/i3c-master-cdns.c | 1671 +++ include/linux/i3c/ccc.h | 385 ++ include/linux/i3c/device.h| 331 + include/linux/i3c/master.h| 648 + include/linux/mod_devicetable.h | 17 + 23 files changed, 6585 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst create mode 100644 Documentation/driver-api/i3c/index.rst create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst create mode 100644 Documentation/driver-api/i3c/protocol.rst create mode 100644 drivers/i3c/Kconfig create mode 100644 drivers/i3c/Makefile create mode 100644 drivers/i3c/device.c create mode 100644 drivers/i3c/internals.h create mode 100644 drivers/i3c/master.c create mode 100644 drivers/i3c/master/Kconfig create mode 100644 drivers/i3c/master/Makefile create mode 100644 drivers/i3c/master/i3c-master-cdns.c create mode 100644 include/linux/i3c/ccc.h create mode 100644 include/linux/i3c/device.h create mode 100644 include/linux/i3c/master.h
[GIT PULL] Addition of the I3C subsystem in 4.20 (5.0)?
Hello Greg, Linus, Greg, I didn't get your feedback on v10 of the i3c patchset [1] where I was asking if you'd agree to have this framework merged in 4.20 (I know you were busy with the 4.19 release and after that the Kernel Summit, so that's not a surprise), so I'm sending this PR. It's really not an attempt to bypass you, more like a ping that, if positively acknowledged, might lead to inclusion of the I3C framework in 4.20 (5.0?) :-). Please let me know if you're opposed to the idea. Regards, Boris [1]https://lkml.org/lkml/2018/10/26/552 The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git tags/i3c/for-4.20 for you to fetch changes up to 71e60757e1eab6f7b821585948317961ccdc61d1: dt-bindings: i3c: Document Cadence I3C master bindings (2018-11-01 06:12:05 +0100) Add the I3C framework + an I3C controller driver for Cadence IP Boris Brezillon (7): i3c: Add core I3C infrastructure docs: driver-api: Add I3C documentation i3c: Add sysfs ABI spec dt-bindings: i3c: Document core bindings MAINTAINERS: Add myself as the I3C subsystem maintainer i3c: master: Add driver for Cadence IP dt-bindings: i3c: Document Cadence I3C master bindings Documentation/ABI/testing/sysfs-bus-i3c | 146 ++ Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt | 44 + Documentation/devicetree/bindings/i3c/i3c.txt | 139 ++ Documentation/driver-api/i3c/device-driver-api.rst|9 + Documentation/driver-api/i3c/index.rst| 11 + Documentation/driver-api/i3c/master-driver-api.rst| 10 + Documentation/driver-api/i3c/protocol.rst | 203 +++ Documentation/driver-api/index.rst|1 + MAINTAINERS | 12 + drivers/Kconfig |2 + drivers/Makefile |2 +- drivers/i3c/Kconfig | 24 + drivers/i3c/Makefile |4 + drivers/i3c/device.c | 233 drivers/i3c/internals.h | 26 + drivers/i3c/master.c | 2661 + drivers/i3c/master/Kconfig|6 + drivers/i3c/master/Makefile |1 + drivers/i3c/master/i3c-master-cdns.c | 1671 +++ include/linux/i3c/ccc.h | 385 ++ include/linux/i3c/device.h| 331 + include/linux/i3c/master.h| 648 + include/linux/mod_devicetable.h | 17 + 23 files changed, 6585 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst create mode 100644 Documentation/driver-api/i3c/index.rst create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst create mode 100644 Documentation/driver-api/i3c/protocol.rst create mode 100644 drivers/i3c/Kconfig create mode 100644 drivers/i3c/Makefile create mode 100644 drivers/i3c/device.c create mode 100644 drivers/i3c/internals.h create mode 100644 drivers/i3c/master.c create mode 100644 drivers/i3c/master/Kconfig create mode 100644 drivers/i3c/master/Makefile create mode 100644 drivers/i3c/master/i3c-master-cdns.c create mode 100644 include/linux/i3c/ccc.h create mode 100644 include/linux/i3c/device.h create mode 100644 include/linux/i3c/master.h
[GIT PULL] fixup dtb Kbuild for C-SKY(csky) Port
Please pull this to fixup dtb Kbuild rules for csky subsystem. The following changes since commit ac435075892e3e651c667b4a9f2267cf3ef1d5a2: Merge tag 'csky-for-linus-4.20' of https://github.com/c-sky/csky-linux (2018-10-29 08:25:00 -0700) are available in the git repository at: https://github.com/c-sky/csky-linux.git tags/csky-for-linus-4.20-fixup-dtb for you to fetch changes up to e8d0c9a726cd1eae410148fcc6a1db23019f0334: csky: use common dtb build rules (2018-11-01 10:52:27 +0800) csky: dtb Kbuild fixup patches for linux-4.20-rc1 These patches are complementary to "C-SKY(csky) Port for Linux 4.20" and fixup dtb Kbuild to follow the new Devicetree dtb build rules. Link: https://lore.kernel.org/lkml/cabggisxiwaqn9qdqpfxewcckkgjfmzfvspgvuhqk7ob404-...@mail.gmail.com/ Signed-off-by: Guo Ren Guo Ren (2): csky: remove builtin-dtb Kbuild csky: use common dtb build rules arch/csky/Kconfig.debug | 10 +- arch/csky/Makefile | 13 + arch/csky/boot/dts/Makefile | 10 -- 3 files changed, 2 insertions(+), 31 deletions(-)
[GIT PULL] fixup dtb Kbuild for C-SKY(csky) Port
Please pull this to fixup dtb Kbuild rules for csky subsystem. The following changes since commit ac435075892e3e651c667b4a9f2267cf3ef1d5a2: Merge tag 'csky-for-linus-4.20' of https://github.com/c-sky/csky-linux (2018-10-29 08:25:00 -0700) are available in the git repository at: https://github.com/c-sky/csky-linux.git tags/csky-for-linus-4.20-fixup-dtb for you to fetch changes up to e8d0c9a726cd1eae410148fcc6a1db23019f0334: csky: use common dtb build rules (2018-11-01 10:52:27 +0800) csky: dtb Kbuild fixup patches for linux-4.20-rc1 These patches are complementary to "C-SKY(csky) Port for Linux 4.20" and fixup dtb Kbuild to follow the new Devicetree dtb build rules. Link: https://lore.kernel.org/lkml/cabggisxiwaqn9qdqpfxewcckkgjfmzfvspgvuhqk7ob404-...@mail.gmail.com/ Signed-off-by: Guo Ren Guo Ren (2): csky: remove builtin-dtb Kbuild csky: use common dtb build rules arch/csky/Kconfig.debug | 10 +- arch/csky/Makefile | 13 + arch/csky/boot/dts/Makefile | 10 -- 3 files changed, 2 insertions(+), 31 deletions(-)
[PATCH v2 2/2] RISC-V: defconfig: Enable printk timestamps
The printk timestamps are very useful information to visually see where kernel is spending time during boot. It also helps us see the timing of hotplug events at runtime. This patch enables printk timestamps in RISC-V defconfig so that we have it enabled by default (similar to other architectures such as x86_64, arm64, etc). Signed-off-by: Anup Patel Acked-by: Olof Johansson --- arch/riscv/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 07fa9ea75fea..ef4f15df9adf 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -76,4 +76,5 @@ CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_ROOT_NFS=y CONFIG_CRYPTO_USER_API_HASH=y +CONFIG_PRINTK_TIME=y # CONFIG_RCU_TRACE is not set -- 2.17.1
[PATCH v2 2/2] RISC-V: defconfig: Enable printk timestamps
The printk timestamps are very useful information to visually see where kernel is spending time during boot. It also helps us see the timing of hotplug events at runtime. This patch enables printk timestamps in RISC-V defconfig so that we have it enabled by default (similar to other architectures such as x86_64, arm64, etc). Signed-off-by: Anup Patel Acked-by: Olof Johansson --- arch/riscv/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 07fa9ea75fea..ef4f15df9adf 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -76,4 +76,5 @@ CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_ROOT_NFS=y CONFIG_CRYPTO_USER_API_HASH=y +CONFIG_PRINTK_TIME=y # CONFIG_RCU_TRACE is not set -- 2.17.1
[PATCH v2 1/2] RISC-V: refresh defconfig
This patch updates defconfig using savedefconfig on Linux-4.19. Signed-off-by: Anup Patel --- arch/riscv/configs/defconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 36473d7dbaac..07fa9ea75fea 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -1,6 +1,3 @@ -CONFIG_SMP=y -CONFIG_PCI=y -CONFIG_PCIE_XILINX=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_IKCONFIG=y @@ -11,10 +8,15 @@ CONFIG_CFS_BANDWIDTH=y CONFIG_CGROUP_BPF=y CONFIG_NAMESPACES=y CONFIG_USER_NS=y +CONFIG_CHECKPOINT_RESTORE=y CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y -CONFIG_CHECKPOINT_RESTORE=y CONFIG_BPF_SYSCALL=y +CONFIG_SMP=y +CONFIG_PCI=y +CONFIG_PCIE_XILINX=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -59,6 +61,7 @@ CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_STORAGE=y CONFIG_USB_UAS=y CONFIG_VIRTIO_MMIO=y +CONFIG_SIFIVE_PLIC=y CONFIG_RAS=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y @@ -72,8 +75,5 @@ CONFIG_NFS_V4=y CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_ROOT_NFS=y -# CONFIG_RCU_TRACE is not set CONFIG_CRYPTO_USER_API_HASH=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -CONFIG_SIFIVE_PLIC=y +# CONFIG_RCU_TRACE is not set -- 2.17.1
[PATCH v2 1/2] RISC-V: refresh defconfig
This patch updates defconfig using savedefconfig on Linux-4.19. Signed-off-by: Anup Patel --- arch/riscv/configs/defconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 36473d7dbaac..07fa9ea75fea 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -1,6 +1,3 @@ -CONFIG_SMP=y -CONFIG_PCI=y -CONFIG_PCIE_XILINX=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_IKCONFIG=y @@ -11,10 +8,15 @@ CONFIG_CFS_BANDWIDTH=y CONFIG_CGROUP_BPF=y CONFIG_NAMESPACES=y CONFIG_USER_NS=y +CONFIG_CHECKPOINT_RESTORE=y CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y -CONFIG_CHECKPOINT_RESTORE=y CONFIG_BPF_SYSCALL=y +CONFIG_SMP=y +CONFIG_PCI=y +CONFIG_PCIE_XILINX=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -59,6 +61,7 @@ CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_STORAGE=y CONFIG_USB_UAS=y CONFIG_VIRTIO_MMIO=y +CONFIG_SIFIVE_PLIC=y CONFIG_RAS=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y @@ -72,8 +75,5 @@ CONFIG_NFS_V4=y CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_ROOT_NFS=y -# CONFIG_RCU_TRACE is not set CONFIG_CRYPTO_USER_API_HASH=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -CONFIG_SIFIVE_PLIC=y +# CONFIG_RCU_TRACE is not set -- 2.17.1
Re: [PATCH v1 2/2] clk: qcom : dispcc: Add support for display port clocks
+ Chandan from Display Port team,
On 10/30/2018 10:03 PM, Stephen Boyd wrote:
Quoting Taniya Das (2018-10-29 23:01:44)
On 10/30/2018 12:13 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-10-28 03:34:55)
On 2018-10-19 16:04, Taniya Das wrote:
On 10/10/2018 2:04 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-10-09 06:57:47)
diff --git a/drivers/clk/qcom/dispcc-sdm845.c
b/drivers/clk/qcom/dispcc-sdm845.c
index 0cc4909..6d3136a 100644
--- a/drivers/clk/qcom/dispcc-sdm845.c
+++ b/drivers/clk/qcom/dispcc-sdm845.c
+ },
+};
+
+static const struct freq_tbl ftbl_disp_cc_mdss_dp_link_clk_src[] = {
+ F(162000, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(27, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(54, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(81, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
Are these in kHz? They really look like it and that's bad. Why do we
need them at all? Just to make sure the display driver picks these
exact
frequencies? It seems like we could just pass whatever number comes in
up to the parent and see what it can do.
Let me check back the reason we had to make this change.
We will need this flag since we reset/power-down the PLL every time we
disconnect/connect the DP cable or during suspend/resume. Only with this
flag, the calls to the PLL driver are properly called.
What does this mean? I wanted to know about the weird frequencies listed
above, and why it can't be done without a frequency table and direct
rates passed up to the parent.
OOps, my bad :(.
We added these changes to handle higher clock rates. These rates when
greater than 4.3Ghz cannot be represented in 32bit variables. For DP, we
already have 5.4G and 8.1GHz freq for VCO clock. We will need these Khz
freq list in clock driver.
Let me check if they can do something like the byte/pixel clocks of
display.
Well then we really should just throw away the freq table here and have
rcg ops that pass the frequency up to the display PLL. Also, those
numbers look like gigabits per second (Gbit/s) for the DP spec which
isn't exactly the same as a clk frequency. What frequency does the PLL
run at for these various DP link speeds?
Could you please help with the above query from Stephen?
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [PATCH v1 2/2] clk: qcom : dispcc: Add support for display port clocks
+ Chandan from Display Port team,
On 10/30/2018 10:03 PM, Stephen Boyd wrote:
Quoting Taniya Das (2018-10-29 23:01:44)
On 10/30/2018 12:13 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-10-28 03:34:55)
On 2018-10-19 16:04, Taniya Das wrote:
On 10/10/2018 2:04 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-10-09 06:57:47)
diff --git a/drivers/clk/qcom/dispcc-sdm845.c
b/drivers/clk/qcom/dispcc-sdm845.c
index 0cc4909..6d3136a 100644
--- a/drivers/clk/qcom/dispcc-sdm845.c
+++ b/drivers/clk/qcom/dispcc-sdm845.c
+ },
+};
+
+static const struct freq_tbl ftbl_disp_cc_mdss_dp_link_clk_src[] = {
+ F(162000, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(27, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(54, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(81, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
Are these in kHz? They really look like it and that's bad. Why do we
need them at all? Just to make sure the display driver picks these
exact
frequencies? It seems like we could just pass whatever number comes in
up to the parent and see what it can do.
Let me check back the reason we had to make this change.
We will need this flag since we reset/power-down the PLL every time we
disconnect/connect the DP cable or during suspend/resume. Only with this
flag, the calls to the PLL driver are properly called.
What does this mean? I wanted to know about the weird frequencies listed
above, and why it can't be done without a frequency table and direct
rates passed up to the parent.
OOps, my bad :(.
We added these changes to handle higher clock rates. These rates when
greater than 4.3Ghz cannot be represented in 32bit variables. For DP, we
already have 5.4G and 8.1GHz freq for VCO clock. We will need these Khz
freq list in clock driver.
Let me check if they can do something like the byte/pixel clocks of
display.
Well then we really should just throw away the freq table here and have
rcg ops that pass the frequency up to the display PLL. Also, those
numbers look like gigabits per second (Gbit/s) for the DP spec which
isn't exactly the same as a clk frequency. What frequency does the PLL
run at for these various DP link speeds?
Could you please help with the above query from Stephen?
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu
On Wed, Oct 31, 2018 at 11:17:48AM -0700, Paul E. McKenney wrote: > On Tue, Oct 30, 2018 at 06:11:19PM -0700, Joel Fernandes wrote: > > Hi Paul, > > > > On Tue, Oct 30, 2018 at 04:43:36PM -0700, Paul E. McKenney wrote: > > > On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote: > > > > Hi Paul, > > > > > > > > On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote: > > > > > As per this thread [1], it seems this smp_mb isn't needed anymore: > > > > > "So the smp_mb() that I was trying to add doesn't need to be there." > > > > > > > > > > So let us remove this part from the memory ordering documentation. > > > > > > > > > > [1] https://lkml.org/lkml/2017/10/6/707 > > > > > > > > > > Signed-off-by: Joel Fernandes (Google) > > > > > > > > I was just checking about this patch. Do you feel it is correct to > > > > remove > > > > this part from the docs? Are you satisified that a barrier isn't needed > > > > there > > > > now? Or did I miss something? > > > > > > Apologies, it got lost in the shuffle. I have now applied it with a > > > bit of rework to the commit log, thank you! > > > > No worries, thanks for taking it! > > > > Just wanted to update you on my progress reading/correcting the docs. The > > 'Memory Ordering' is taking a bit of time so I paused that and I'm focusing > > on finishing all the other low hanging fruit. This activity is mostly during > > night hours after the baby is asleep but some times I also manage to sneak > > it > > into the day job ;-) > > If there is anything I can do to make this a more sustainable task for > you, please do not keep it a secret!!! Thanks a lot, that means a lot to me! Will do! > > BTW I do want to discuss about this smp_mb patch above with you at LPC if > > you > > had time, even though we are removing it from the documentation. I thought > > about it a few times, and I was not able to fully appreciate the need for > > the > > barrier (that is even assuming that complete() etc did not do the right > > thing). Specifically I was wondering same thing Peter said in the above > > thread I think that - if that rcu_read_unlock() triggered all the spin > > locking up the tree of nodes, then why is that locking not sufficient to > > prevent reads from the read-side section from bleeding out? That would > > prevent the reader that just unlocked from seeing anything that happens > > _after_ the synchronize_rcu. > > Actually, I recall an smp_mb() being added, but am not seeing it anywhere > relevant to wait_for_completion(). So I might need to add the smp_mb() > to synchronize_rcu() and remove the patch (retaining the typo fix). :-/ No problem, I'm glad atleast the patch resurfaced the topic of the potential issue :-) > The short form answer is that anything before a grace period on any CPU > must be seen by any CPU as being before anything on any CPU after that > same grace period. This guarantee requires a rather big hammer. > > But yes, let's talk at LPC! Sounds great, looking forward to discussing this. > > Also about GP memory ordering and RCU-tree-locking, I think you mentioned to > > me that the RCU reader-sections are virtually extended both forward and > > backward and whereever it ends, those paths do heavy-weight synchronization > > that should be sufficient to prevent memory ordering issues (such as those > > you mentioned in the Requierments document). That is exactly why we don't > > need explicit barriers during rcu_read_unlock. If I recall I asked you why > > those are not needed. So that answer made sense, but then now on going > > through the 'Memory Ordering' document, I see that you mentioned there is > > reliance on the locking. Is that reliance on locking necessary to maintain > > ordering then? > > There is a "network" of locking augmented by smp_mb__after_unlock_lock() > that implements the all-to-all memory ordering mentioned above. But it > also needs to handle all the possible complete()/wait_for_completion() > races, even those assisted by hypervisor vCPU preemption. I see, so it sounds like the lock network is just a partial solution. For some reason I thought before that complete() was even called on the CPU executing the callback, all the CPUs would have acquired and released a lock in the "lock network" atleast once thus ensuring the ordering (due to the fact that the quiescent state reporting has to travel up the tree starting from the leaves), but I think that's not necessarily true so I see your point now. Did you feel this will violate condition 1. or condition 2. in "Memory-Barrier Guarantees"? Or both? https://www.kernel.org/doc/Documentation/RCU/Design/Requirements/Requirements.html#Memory-Barrier%20Guarantees > > -- > > TODO list of the index file marking which ones I have finished perusing: > > > > arrayRCU.txtDONE > > checklist.txt DONE > > listRCU.txt DONE > > lockdep.txt
Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu
On Wed, Oct 31, 2018 at 11:17:48AM -0700, Paul E. McKenney wrote: > On Tue, Oct 30, 2018 at 06:11:19PM -0700, Joel Fernandes wrote: > > Hi Paul, > > > > On Tue, Oct 30, 2018 at 04:43:36PM -0700, Paul E. McKenney wrote: > > > On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote: > > > > Hi Paul, > > > > > > > > On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote: > > > > > As per this thread [1], it seems this smp_mb isn't needed anymore: > > > > > "So the smp_mb() that I was trying to add doesn't need to be there." > > > > > > > > > > So let us remove this part from the memory ordering documentation. > > > > > > > > > > [1] https://lkml.org/lkml/2017/10/6/707 > > > > > > > > > > Signed-off-by: Joel Fernandes (Google) > > > > > > > > I was just checking about this patch. Do you feel it is correct to > > > > remove > > > > this part from the docs? Are you satisified that a barrier isn't needed > > > > there > > > > now? Or did I miss something? > > > > > > Apologies, it got lost in the shuffle. I have now applied it with a > > > bit of rework to the commit log, thank you! > > > > No worries, thanks for taking it! > > > > Just wanted to update you on my progress reading/correcting the docs. The > > 'Memory Ordering' is taking a bit of time so I paused that and I'm focusing > > on finishing all the other low hanging fruit. This activity is mostly during > > night hours after the baby is asleep but some times I also manage to sneak > > it > > into the day job ;-) > > If there is anything I can do to make this a more sustainable task for > you, please do not keep it a secret!!! Thanks a lot, that means a lot to me! Will do! > > BTW I do want to discuss about this smp_mb patch above with you at LPC if > > you > > had time, even though we are removing it from the documentation. I thought > > about it a few times, and I was not able to fully appreciate the need for > > the > > barrier (that is even assuming that complete() etc did not do the right > > thing). Specifically I was wondering same thing Peter said in the above > > thread I think that - if that rcu_read_unlock() triggered all the spin > > locking up the tree of nodes, then why is that locking not sufficient to > > prevent reads from the read-side section from bleeding out? That would > > prevent the reader that just unlocked from seeing anything that happens > > _after_ the synchronize_rcu. > > Actually, I recall an smp_mb() being added, but am not seeing it anywhere > relevant to wait_for_completion(). So I might need to add the smp_mb() > to synchronize_rcu() and remove the patch (retaining the typo fix). :-/ No problem, I'm glad atleast the patch resurfaced the topic of the potential issue :-) > The short form answer is that anything before a grace period on any CPU > must be seen by any CPU as being before anything on any CPU after that > same grace period. This guarantee requires a rather big hammer. > > But yes, let's talk at LPC! Sounds great, looking forward to discussing this. > > Also about GP memory ordering and RCU-tree-locking, I think you mentioned to > > me that the RCU reader-sections are virtually extended both forward and > > backward and whereever it ends, those paths do heavy-weight synchronization > > that should be sufficient to prevent memory ordering issues (such as those > > you mentioned in the Requierments document). That is exactly why we don't > > need explicit barriers during rcu_read_unlock. If I recall I asked you why > > those are not needed. So that answer made sense, but then now on going > > through the 'Memory Ordering' document, I see that you mentioned there is > > reliance on the locking. Is that reliance on locking necessary to maintain > > ordering then? > > There is a "network" of locking augmented by smp_mb__after_unlock_lock() > that implements the all-to-all memory ordering mentioned above. But it > also needs to handle all the possible complete()/wait_for_completion() > races, even those assisted by hypervisor vCPU preemption. I see, so it sounds like the lock network is just a partial solution. For some reason I thought before that complete() was even called on the CPU executing the callback, all the CPUs would have acquired and released a lock in the "lock network" atleast once thus ensuring the ordering (due to the fact that the quiescent state reporting has to travel up the tree starting from the leaves), but I think that's not necessarily true so I see your point now. Did you feel this will violate condition 1. or condition 2. in "Memory-Barrier Guarantees"? Or both? https://www.kernel.org/doc/Documentation/RCU/Design/Requirements/Requirements.html#Memory-Barrier%20Guarantees > > -- > > TODO list of the index file marking which ones I have finished perusing: > > > > arrayRCU.txtDONE > > checklist.txt DONE > > listRCU.txt DONE > > lockdep.txt
Re: [RFC PATCH] Implement /proc/pid/kill
On Wed, Oct 31, 2018 at 9:23 AM Jann Horn wrote:
>
> +linux-api, Andy Lutomirski, Eric Biederman
>
> On Wed, Oct 31, 2018 at 3:12 AM Daniel Colascione wrote:
> > Add a simple proc-based kill interface. To use /proc/pid/kill, just
> > write the signal number in base-10 ASCII to the kill file of the
> > process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> This is a kernel API change, you should CC the linux-api list.
>
> I think that getting the semantics of this right might be easier if
> you used an ioctl handler instead of a write handler.
>
> > Semantically, /proc/pid/kill works like kill(2), except that the
> > process ID comes from the proc filesystem context instead of from an
> > explicit system call parameter. This way, it's possible to avoid races
> > between inspecting some aspect of a process and that process's PID
> > being reused for some other process.
> >
> > With /proc/pid/kill, it's possible to write a proper race-free and
> > safe pkill(1). An approximation follows. A real program might use
> > openat(2), having opened a process's /proc/pid directory explicitly,
> > with the directory file descriptor serving as a sort of "process
> > handle".
> >
> > #!/bin/bash
> > set -euo pipefail
> > pat=$1
> > for proc_status in /proc/*/status; do (
> > cd $(dirname $proc_status)
> > readarray proc_argv -d'' < cmdline
> > if ((${#proc_argv[@]} > 0)) &&
> >[[ ${proc_argv[0]} = *$pat* ]];
> > then
> > echo 15 > kill
> > fi
> > ) || true; done
> >
> > Signed-off-by: Daniel Colascione
> > ---
> > fs/proc/base.c | 39 +++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index 7e9f07bf260d..923d62b21e67 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -205,6 +205,44 @@ static int proc_root_link(struct dentry *dentry,
> > struct path *path)
> > return result;
> > }
> >
> > +static ssize_t proc_pid_kill_write(struct file *file,
> > + const char __user *buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + ssize_t res;
> > + int sig;
> > + char buffer[4];
> > +
> > + res = -EINVAL;
> > + if (*ppos != 0)
> > + goto out;
> > +
> > + res = -EINVAL;
> > + if (count > sizeof(buffer) - 1)
> > + goto out;
> > +
> > + res = -EFAULT;
> > + if (copy_from_user(buffer, buf, count))
> > + goto out;
> > +
> > + buffer[count] = '\0';
> > + res = kstrtoint(strstrip(buffer), 10, );
> > + if (res)
> > + goto out;
> > +
> > + res = kill_pid(proc_pid(file_inode(file)), sig, 0);
Indeed, you can't do this from .write unless you manage to pass a cred
struct pointer in. ioctl or a new syscall would be better.
--Andy
Re: [PATCH] ata: add Buddha PATA controller driver
Hi Adrian, my fix is evidently incomplete - I just crashed elgar trying to remove the pata_buddha module, sorry. Must've done something silly. So no, can't post a patch to add module_exit just yet. Cheers, Michael Am 31.10.2018 um 23:06 schrieb John Paul Adrian Glaubitz: Hi! On 10/25/18 9:38 PM, John Paul Adrian Glaubitz wrote: Tested-by: John Paul Adrian Glaubitz Michael wants to make some changes to the driver though, I think. He has access to the Amiga 4000, in any case, so he can also test them. @Michael: Can you post an updated version of the driver, rebased for 4.19 and with your patch? Adrian
Re: [RFC PATCH] Implement /proc/pid/kill
On Wed, Oct 31, 2018 at 9:23 AM Jann Horn wrote:
>
> +linux-api, Andy Lutomirski, Eric Biederman
>
> On Wed, Oct 31, 2018 at 3:12 AM Daniel Colascione wrote:
> > Add a simple proc-based kill interface. To use /proc/pid/kill, just
> > write the signal number in base-10 ASCII to the kill file of the
> > process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> This is a kernel API change, you should CC the linux-api list.
>
> I think that getting the semantics of this right might be easier if
> you used an ioctl handler instead of a write handler.
>
> > Semantically, /proc/pid/kill works like kill(2), except that the
> > process ID comes from the proc filesystem context instead of from an
> > explicit system call parameter. This way, it's possible to avoid races
> > between inspecting some aspect of a process and that process's PID
> > being reused for some other process.
> >
> > With /proc/pid/kill, it's possible to write a proper race-free and
> > safe pkill(1). An approximation follows. A real program might use
> > openat(2), having opened a process's /proc/pid directory explicitly,
> > with the directory file descriptor serving as a sort of "process
> > handle".
> >
> > #!/bin/bash
> > set -euo pipefail
> > pat=$1
> > for proc_status in /proc/*/status; do (
> > cd $(dirname $proc_status)
> > readarray proc_argv -d'' < cmdline
> > if ((${#proc_argv[@]} > 0)) &&
> >[[ ${proc_argv[0]} = *$pat* ]];
> > then
> > echo 15 > kill
> > fi
> > ) || true; done
> >
> > Signed-off-by: Daniel Colascione
> > ---
> > fs/proc/base.c | 39 +++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index 7e9f07bf260d..923d62b21e67 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -205,6 +205,44 @@ static int proc_root_link(struct dentry *dentry,
> > struct path *path)
> > return result;
> > }
> >
> > +static ssize_t proc_pid_kill_write(struct file *file,
> > + const char __user *buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + ssize_t res;
> > + int sig;
> > + char buffer[4];
> > +
> > + res = -EINVAL;
> > + if (*ppos != 0)
> > + goto out;
> > +
> > + res = -EINVAL;
> > + if (count > sizeof(buffer) - 1)
> > + goto out;
> > +
> > + res = -EFAULT;
> > + if (copy_from_user(buffer, buf, count))
> > + goto out;
> > +
> > + buffer[count] = '\0';
> > + res = kstrtoint(strstrip(buffer), 10, );
> > + if (res)
> > + goto out;
> > +
> > + res = kill_pid(proc_pid(file_inode(file)), sig, 0);
Indeed, you can't do this from .write unless you manage to pass a cred
struct pointer in. ioctl or a new syscall would be better.
--Andy
Re: [PATCH] ata: add Buddha PATA controller driver
Hi Adrian, my fix is evidently incomplete - I just crashed elgar trying to remove the pata_buddha module, sorry. Must've done something silly. So no, can't post a patch to add module_exit just yet. Cheers, Michael Am 31.10.2018 um 23:06 schrieb John Paul Adrian Glaubitz: Hi! On 10/25/18 9:38 PM, John Paul Adrian Glaubitz wrote: Tested-by: John Paul Adrian Glaubitz Michael wants to make some changes to the driver though, I think. He has access to the Amiga 4000, in any case, so he can also test them. @Michael: Can you post an updated version of the driver, rebased for 4.19 and with your patch? Adrian
Re: [PATCH] RISC-V: defconfig: Enable printk timestamps
On Thu, Nov 1, 2018 at 4:20 AM Olof Johansson wrote: > > On Wed, Oct 31, 2018 at 1:42 PM Palmer Dabbelt wrote: > > > > On Wed, 31 Oct 2018 12:20:40 PDT (-0700), Olof Johansson wrote: > > > On Tue, Oct 30, 2018 at 5:37 AM Anup Patel wrote: > > >> > > >> The printk timestamps are very useful information to visually see > > >> where kernel is spending time during boot. It also helps us see > > >> the timing of hotplug events at runtime. > > >> > > >> This patch enables printk timestamps in RISC-V defconfig so that > > >> we have it enabled by default (similar to other architectures > > >> such as x86_64, arm64, etc). > > >> > > >> Signed-off-by: Anup Patel > > > > > > Acked-by: Olof Johansson > > > > > > For next time: doing a re-format of the defconfig (to shuffle config > > > order), plus changes in the same patch, tends to be a bit fragile. For > > > cases like these, I'd recommend hand-pruning to just flip the one > > > option if needed, and then have Palmer or Andrew refresh the defconfig > > > during a merge window if needed (usually quite rare). > > > > I poked around and it looks like most architectures have this enabled for at > > least one defconfig, with the big architectures having it enabled for all of > > them. > > It's pretty convenient to have it on, and I think those who haven't > probably don't use those defconfigs much. > > > I decided to do a bit of a case study here to try and figure out why some > > architectures have this enabled for some defconfigs but not for others, and > > as > > far as I can tell it's just an oversight. Specifically, looking at sparc32 > > (# > > CONFIG_PRINTK_TIME is not set) vs sparc64 (CONFIG_PRINTK_TIME=y) I can't > > find > > any reason for the difference. sparc32's setting can be traced back to > > I'm not sure sparc32 is overly active these days, which might help explain it? > > > commit 216da721b881838d639a3987bf8a825e6b4aacdd > > Author: David S. Miller > > Date: Sun Dec 17 14:21:34 2006 -0800 > > > > [SPARC]: Update defconfig. > > > > Signed-off-by: David S. Miller > > > > which changes everything in the defconfig, while the sparc64 version dates > > back to > > > > commit 3ebc284d52757cf39788731f8fddd70a89f7fc23 > > Author: David S. Miller > > Date: Mon Jan 9 14:36:49 2006 -0800 > > > > [SPARC64]: Update defconfig. > > > > Signed-off-by: David S. Miller > > > > When we first submitted out port upstream we had an empty defconfig, with > > the > > theory being that we should just pick whatever the default in Kconfig is for > > everything. That's obviously the wrong thing to do because most of those > > options are bogus. At the time I didn't care enough to look because I just > > wanted something to work, but now I find myself asking the question "what > > goes > > in a defconfig?" Is it: > > > > * What I, as the maintainer of arch/riscv, want? That's essentially what > > it is > > now, as we have things like "CONFIG_R8169=y" in there because I happened > > to > > have one sitting around when we needed to plug in an Ethernet card to test > > out PCIe. > > * What distributions expect? There's a major element of this in there right > > now, as half this stuff was just selected because the Debian and Fedora > > guys > > suggested we do so because adding things to the RISC-V defconfig made it > > easier to put together their build scripts. For example, we ended up with > > "CONFIG_EXPERT=y" because some setting necessary for the distros was > > hidden > > behind it -- that seems like an odd default. > > * What users expect? I'm not even sure who users are in this case, as from > > my > > understating most people use distro kernels and don't twiddle Kconfig > > options. > > * What is necessary to work on RISC-V hardware? This seems like the most > > reasonable use for an arch-specific defconfig, and subsumes things like > > "CONFIG_SIFIVE_PLIC=y" because without the PLIC driver nothing will work > > (but > > the PLIC driver shouldn't be enabled by default for all architectures, as > > it's useless everywhere else). > > > > Maybe I've opened up a big can of worms here... It just seems silly to have > > most of our current defconfig be RISC-V specific. > > So, on 32-bit ARM we have heavy defconfig proliferation, and for arm64 > there was a push to only have one defconfig. I'm heavily in favor of > the latter. > > On ARM64, the options turned on, are more or less "what makes the > kernel useful on systems". Anything that would be needed to boot to a > rootfs tends to be =y, while some other things that might be optional > and not used everywhere tends to go in as modules. > > Beyond that, for the most part it is maintainer preference. I've > normally turned on platforms and drivers I need for my boot farm on > the multi*defconfig configs on 32-bit ARM, and the same has been going > for 64-bit. > > Distros will always want something different,
Re: [PATCH] RISC-V: defconfig: Enable printk timestamps
On Thu, Nov 1, 2018 at 4:20 AM Olof Johansson wrote: > > On Wed, Oct 31, 2018 at 1:42 PM Palmer Dabbelt wrote: > > > > On Wed, 31 Oct 2018 12:20:40 PDT (-0700), Olof Johansson wrote: > > > On Tue, Oct 30, 2018 at 5:37 AM Anup Patel wrote: > > >> > > >> The printk timestamps are very useful information to visually see > > >> where kernel is spending time during boot. It also helps us see > > >> the timing of hotplug events at runtime. > > >> > > >> This patch enables printk timestamps in RISC-V defconfig so that > > >> we have it enabled by default (similar to other architectures > > >> such as x86_64, arm64, etc). > > >> > > >> Signed-off-by: Anup Patel > > > > > > Acked-by: Olof Johansson > > > > > > For next time: doing a re-format of the defconfig (to shuffle config > > > order), plus changes in the same patch, tends to be a bit fragile. For > > > cases like these, I'd recommend hand-pruning to just flip the one > > > option if needed, and then have Palmer or Andrew refresh the defconfig > > > during a merge window if needed (usually quite rare). > > > > I poked around and it looks like most architectures have this enabled for at > > least one defconfig, with the big architectures having it enabled for all of > > them. > > It's pretty convenient to have it on, and I think those who haven't > probably don't use those defconfigs much. > > > I decided to do a bit of a case study here to try and figure out why some > > architectures have this enabled for some defconfigs but not for others, and > > as > > far as I can tell it's just an oversight. Specifically, looking at sparc32 > > (# > > CONFIG_PRINTK_TIME is not set) vs sparc64 (CONFIG_PRINTK_TIME=y) I can't > > find > > any reason for the difference. sparc32's setting can be traced back to > > I'm not sure sparc32 is overly active these days, which might help explain it? > > > commit 216da721b881838d639a3987bf8a825e6b4aacdd > > Author: David S. Miller > > Date: Sun Dec 17 14:21:34 2006 -0800 > > > > [SPARC]: Update defconfig. > > > > Signed-off-by: David S. Miller > > > > which changes everything in the defconfig, while the sparc64 version dates > > back to > > > > commit 3ebc284d52757cf39788731f8fddd70a89f7fc23 > > Author: David S. Miller > > Date: Mon Jan 9 14:36:49 2006 -0800 > > > > [SPARC64]: Update defconfig. > > > > Signed-off-by: David S. Miller > > > > When we first submitted out port upstream we had an empty defconfig, with > > the > > theory being that we should just pick whatever the default in Kconfig is for > > everything. That's obviously the wrong thing to do because most of those > > options are bogus. At the time I didn't care enough to look because I just > > wanted something to work, but now I find myself asking the question "what > > goes > > in a defconfig?" Is it: > > > > * What I, as the maintainer of arch/riscv, want? That's essentially what > > it is > > now, as we have things like "CONFIG_R8169=y" in there because I happened > > to > > have one sitting around when we needed to plug in an Ethernet card to test > > out PCIe. > > * What distributions expect? There's a major element of this in there right > > now, as half this stuff was just selected because the Debian and Fedora > > guys > > suggested we do so because adding things to the RISC-V defconfig made it > > easier to put together their build scripts. For example, we ended up with > > "CONFIG_EXPERT=y" because some setting necessary for the distros was > > hidden > > behind it -- that seems like an odd default. > > * What users expect? I'm not even sure who users are in this case, as from > > my > > understating most people use distro kernels and don't twiddle Kconfig > > options. > > * What is necessary to work on RISC-V hardware? This seems like the most > > reasonable use for an arch-specific defconfig, and subsumes things like > > "CONFIG_SIFIVE_PLIC=y" because without the PLIC driver nothing will work > > (but > > the PLIC driver shouldn't be enabled by default for all architectures, as > > it's useless everywhere else). > > > > Maybe I've opened up a big can of worms here... It just seems silly to have > > most of our current defconfig be RISC-V specific. > > So, on 32-bit ARM we have heavy defconfig proliferation, and for arm64 > there was a push to only have one defconfig. I'm heavily in favor of > the latter. > > On ARM64, the options turned on, are more or less "what makes the > kernel useful on systems". Anything that would be needed to boot to a > rootfs tends to be =y, while some other things that might be optional > and not used everywhere tends to go in as modules. > > Beyond that, for the most part it is maintainer preference. I've > normally turned on platforms and drivers I need for my boot farm on > the multi*defconfig configs on 32-bit ARM, and the same has been going > for 64-bit. > > Distros will always want something different,
Re: [LKP] b179f0826c BUG: kernel hang in boot stage
Hi all, On Thu, 1 Nov 2018 09:13:07 +0800 kernel test robot wrote: > > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > commit b179f0826c6a13563c5ce0554c6da6748a1fa699 > Author: Stephen Rothwell > AuthorDate: Mon Oct 29 16:55:21 2018 +1100 > Commit: Stephen Rothwell > CommitDate: Mon Oct 29 16:55:21 2018 +1100 > > Add linux-next specific files for 20181029 > > Signed-off-by: Stephen Rothwell > > a3bbfc79c4 Merge branch 'akpm/master' > b179f0826c Add linux-next specific files for 20181029 > +++---+ > || a3bbfc79c4 | next-20181029 > | > +++---+ > | boot_successes | 33 | 0 > | > | boot_failures | 2 | 30 > | > | BUG:kernel_hang_in_boot_stage | 1 | 30 > | > | IP-Config:Auto-configuration_of_network_failed | 1 | > | > +++---+ That is really hard to believe given that the commit above only adds documentation to the tree :-) $ git log --stat -1 next-20181029 commit b179f0826c6a13563c5ce0554c6da6748a1fa699 (tag: next-20181029) Author: Stephen Rothwell Date: Mon Oct 29 16:55:21 2018 +1100 Add linux-next specific files for 20181029 Signed-off-by: Stephen Rothwell Next/SHA1s| 292 + Next/Trees| 294 + Next/merge.log| 14253 Next/quilt-import.log | 2 + localversion-next | 1 + 5 files changed, 14842 insertions(+) -- Cheers, Stephen Rothwell pgpu3FKyXgGZa.pgp Description: OpenPGP digital signature
Re: [LKP] b179f0826c BUG: kernel hang in boot stage
Hi all, On Thu, 1 Nov 2018 09:13:07 +0800 kernel test robot wrote: > > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > commit b179f0826c6a13563c5ce0554c6da6748a1fa699 > Author: Stephen Rothwell > AuthorDate: Mon Oct 29 16:55:21 2018 +1100 > Commit: Stephen Rothwell > CommitDate: Mon Oct 29 16:55:21 2018 +1100 > > Add linux-next specific files for 20181029 > > Signed-off-by: Stephen Rothwell > > a3bbfc79c4 Merge branch 'akpm/master' > b179f0826c Add linux-next specific files for 20181029 > +++---+ > || a3bbfc79c4 | next-20181029 > | > +++---+ > | boot_successes | 33 | 0 > | > | boot_failures | 2 | 30 > | > | BUG:kernel_hang_in_boot_stage | 1 | 30 > | > | IP-Config:Auto-configuration_of_network_failed | 1 | > | > +++---+ That is really hard to believe given that the commit above only adds documentation to the tree :-) $ git log --stat -1 next-20181029 commit b179f0826c6a13563c5ce0554c6da6748a1fa699 (tag: next-20181029) Author: Stephen Rothwell Date: Mon Oct 29 16:55:21 2018 +1100 Add linux-next specific files for 20181029 Signed-off-by: Stephen Rothwell Next/SHA1s| 292 + Next/Trees| 294 + Next/merge.log| 14253 Next/quilt-import.log | 2 + localversion-next | 1 + 5 files changed, 14842 insertions(+) -- Cheers, Stephen Rothwell pgpu3FKyXgGZa.pgp Description: OpenPGP digital signature
Re: [PATCH v6 0/1] ns: introduce binfmt_misc namespace
On Thu, Nov 1, 2018 at 3:59 AM James Bottomley wrote: > > On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote: > > Hi, > > > > Any comment on this last version? > > > > Any chance to be merged? > > I've got a use case for this: I went to one of the Graphene talks in > Edinburgh and it struck me that we seem to keep reinventing the type of > sandboxing that qemu-user already does. However if you want to do an > x86 on x86 sandbox, you can't currently use the binfmt_misc mechanism > because that has you running *every* binary on the system emulated. > Doing it per user namespace fixes this problem and allows us to at > least cut down on all the pointless duplication. Waait. What? qemu-user does not do "sandboxing". qemu-user makes your code slower and *LESS* secure. As far as I know, qemu-user is only intended for purposes like development and testing.
Re: [PATCH v6 0/1] ns: introduce binfmt_misc namespace
On Thu, Nov 1, 2018 at 3:59 AM James Bottomley wrote: > > On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote: > > Hi, > > > > Any comment on this last version? > > > > Any chance to be merged? > > I've got a use case for this: I went to one of the Graphene talks in > Edinburgh and it struck me that we seem to keep reinventing the type of > sandboxing that qemu-user already does. However if you want to do an > x86 on x86 sandbox, you can't currently use the binfmt_misc mechanism > because that has you running *every* binary on the system emulated. > Doing it per user namespace fixes this problem and allows us to at > least cut down on all the pointless duplication. Waait. What? qemu-user does not do "sandboxing". qemu-user makes your code slower and *LESS* secure. As far as I know, qemu-user is only intended for purposes like development and testing.
linux-next: Tree for Nov 1
Hi all, Please do not add any v4.21/v5.1 code to your linux-next included trees until after the merge window closes. Changes since 20181031: My fixes tree contains this: "drivers: net: include linux/ip.h for iphdr" Non-merge commits (relative to Linus' tree): 790 953 files changed, 41712 insertions(+), 11405 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 291 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a9ac6cc47bbb Merge tag 'fbdev-v4.20' of https://github.com/bzolnier/linux) Merging fixes/master (2941927a2da1 drivers: net: include linux/ip.h for iphdr) Merging kbuild-current/fixes (11743c56785c Merge tag 'rpmsg-v4.20' of git://github.com/andersson/remoteproc) Merging arc-current/for-curr (a75e410a8bc2 ARCv2: boot log unaligned access in use) Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() offset check) Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject stand-alone CHAIN events for PMUv3) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (84df9525b0c2 Linux 4.19) Merging sparc/master (0f0a691f1ef9 sparc64: Remvoe set_fs() from perf_callchain_user().) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (d48051c5b837 net/mlx5e: fix csum adjustments caused by RXFCS) Merging bpf/master (27b31e68bc9f bpf: tcp_bpf_recvmsg should return EAGAIN when nonblocking and no data) Merging ipsec/master (533555e5cbb6 xfrm: Fix error return code in xfrm_output_one()) Merging netfilter/master (29a0dd66e953 netfilter: xt_IDLETIMER: add sysfs filename checking routine) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue size) Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error paths for netlink) Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 vulnerability) Merging sound-current/for-linus (826b5de90c0b ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size) Merging sound-asoc-fixes/for-linus (fec2c565951e Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) Merging regulator-fixes/for-linus (84df9525b0c2 Linux 4.19) Merging spi-fixes/for-linus (83665c6da9d3 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (2edab4df98d9 PCI: Expand the "PF" acronym in Kconfig help text) Merging driver-core.current/driver-core-linus (310c7585e830 Merge tag 'nfsd-4.20' of git://linux-nfs.org/~bfields/linux) Merging tty.current/tty-linus (202dc3cc10b4 serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA) Merging usb.current/usb-linus (310c7585e830 Merge tag 'nfsd-4.20' of git://linux-nfs.org/~bfields/linux) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging sta
linux-next: Tree for Nov 1
Hi all, Please do not add any v4.21/v5.1 code to your linux-next included trees until after the merge window closes. Changes since 20181031: My fixes tree contains this: "drivers: net: include linux/ip.h for iphdr" Non-merge commits (relative to Linus' tree): 790 953 files changed, 41712 insertions(+), 11405 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 291 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a9ac6cc47bbb Merge tag 'fbdev-v4.20' of https://github.com/bzolnier/linux) Merging fixes/master (2941927a2da1 drivers: net: include linux/ip.h for iphdr) Merging kbuild-current/fixes (11743c56785c Merge tag 'rpmsg-v4.20' of git://github.com/andersson/remoteproc) Merging arc-current/for-curr (a75e410a8bc2 ARCv2: boot log unaligned access in use) Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() offset check) Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject stand-alone CHAIN events for PMUv3) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (84df9525b0c2 Linux 4.19) Merging sparc/master (0f0a691f1ef9 sparc64: Remvoe set_fs() from perf_callchain_user().) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (d48051c5b837 net/mlx5e: fix csum adjustments caused by RXFCS) Merging bpf/master (27b31e68bc9f bpf: tcp_bpf_recvmsg should return EAGAIN when nonblocking and no data) Merging ipsec/master (533555e5cbb6 xfrm: Fix error return code in xfrm_output_one()) Merging netfilter/master (29a0dd66e953 netfilter: xt_IDLETIMER: add sysfs filename checking routine) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue size) Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error paths for netlink) Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 vulnerability) Merging sound-current/for-linus (826b5de90c0b ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size) Merging sound-asoc-fixes/for-linus (fec2c565951e Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) Merging regulator-fixes/for-linus (84df9525b0c2 Linux 4.19) Merging spi-fixes/for-linus (83665c6da9d3 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (2edab4df98d9 PCI: Expand the "PF" acronym in Kconfig help text) Merging driver-core.current/driver-core-linus (310c7585e830 Merge tag 'nfsd-4.20' of git://linux-nfs.org/~bfields/linux) Merging tty.current/tty-linus (202dc3cc10b4 serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA) Merging usb.current/usb-linus (310c7585e830 Merge tag 'nfsd-4.20' of git://linux-nfs.org/~bfields/linux) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging sta
Re: linux-next: Tree for Oct 31 (vboxguest)
Hi Arnd,
On Thu, Nov 1, 2018 at 6:42 AM Arnd Bergmann wrote:
>
> On 10/31/18, Randy Dunlap wrote:
> > On 10/30/18 8:59 PM, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Please do not add any v4.21/v5.1 code to your linux-next included trees
> >> until after the merge window closes.
> >>
> >> Changes since 20181030:
> >>
> >
> >
> > on i386:
> >
> > ld: drivers/virt/vboxguest/vboxguest_core.o: in function
> > `vbg_ioctl_hgcm_call':
> > vboxguest_core.c:(.text+0x212b): undefined reference to `vbg_hgcm_call32'
> >
> >
> > Full randconfig file is attached.
> >
> > Reported-by: Randy Dunlap
>
> I ran into the same thing, and lots of others like it; they all go back to
> the -Og compiler option introduced in commit 94c7dfd01652 ("kernel
> hacking: support building kernel with -Og optimization level").
>
>
> I have patches for most of these, but I'd prefer if we could leave
> that patch out of 4.20 for now, and have it in linux-next for merging
> into the next merge window, to give us more time to fix up all the
> regressions. This particular instance is fixed by the patch below.
Hmm, I was considering the -Og support for the current MW,
but it might be better to postpone it for 4.21-rc1...
> Other symptoms caused by the change are tons of 'section mismatch'
> warnings for functions that are no longer automatically inlined, and
> sprintf format string overflow warnings when gcc fails to propagate
> an upper bound on an integer argument that is printed into a fixed
> length string.
>
> Arnd
> ---
> From 8172e650c6797b9cc64c6f7b1c9e5433156290cc Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann
> Date: Wed, 31 Oct 2018 16:24:35 +0100
> Subject: [PATCH] vbox: fix link error with 'gcc -Og'
>
> With the new CONFIG_CC_OPTIMIZE_FOR_DEBUGGING option, we get a link
> error in the vboxguest driver, when that fails to optimize out the
> call to the compat handler:
>
> drivers/virt/vboxguest/vboxguest_core.o: In function `vbg_ioctl_hgcm_call':
> vboxguest_core.c:(.text+0x1f6e): undefined reference to `vbg_hgcm_call32'
>
> Another compile-time check documents better what we want and avoids
> the error.
>
> Signed-off-by: Arnd Bergmann
>
> diff --git a/drivers/virt/vboxguest/vboxguest_core.c
> b/drivers/virt/vboxguest/vboxguest_core.c
> index 3093655c7b92..1475ed5ffcde 100644
> --- a/drivers/virt/vboxguest/vboxguest_core.c
> +++ b/drivers/virt/vboxguest/vboxguest_core.c
> @@ -1312,7 +1312,7 @@ static int vbg_ioctl_hgcm_call(struct vbg_dev *gdev,
> return -EINVAL;
> }
>
> - if (f32bit)
> + if (IS_ENABLED(CONFIG_COMPAT) && f32bit)
> ret = vbg_hgcm_call32(gdev, client_id,
> call->function, call->timeout_ms,
> VBG_IOCTL_HGCM_CALL_PARMS32(call),
Right, but adding the CONFIG_COMPAT guard to both the caller and the callee
looks a bit redundant...
I think most cases causing this kind of problem
rely on the assumption that 'static' functions are inlined.
We can force the compiler to do so
by replacing 'static' with 'static __always_inline'
--
Best Regards
Masahiro Yamada
Re: linux-next: Tree for Oct 31 (vboxguest)
Hi Arnd,
On Thu, Nov 1, 2018 at 6:42 AM Arnd Bergmann wrote:
>
> On 10/31/18, Randy Dunlap wrote:
> > On 10/30/18 8:59 PM, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Please do not add any v4.21/v5.1 code to your linux-next included trees
> >> until after the merge window closes.
> >>
> >> Changes since 20181030:
> >>
> >
> >
> > on i386:
> >
> > ld: drivers/virt/vboxguest/vboxguest_core.o: in function
> > `vbg_ioctl_hgcm_call':
> > vboxguest_core.c:(.text+0x212b): undefined reference to `vbg_hgcm_call32'
> >
> >
> > Full randconfig file is attached.
> >
> > Reported-by: Randy Dunlap
>
> I ran into the same thing, and lots of others like it; they all go back to
> the -Og compiler option introduced in commit 94c7dfd01652 ("kernel
> hacking: support building kernel with -Og optimization level").
>
>
> I have patches for most of these, but I'd prefer if we could leave
> that patch out of 4.20 for now, and have it in linux-next for merging
> into the next merge window, to give us more time to fix up all the
> regressions. This particular instance is fixed by the patch below.
Hmm, I was considering the -Og support for the current MW,
but it might be better to postpone it for 4.21-rc1...
> Other symptoms caused by the change are tons of 'section mismatch'
> warnings for functions that are no longer automatically inlined, and
> sprintf format string overflow warnings when gcc fails to propagate
> an upper bound on an integer argument that is printed into a fixed
> length string.
>
> Arnd
> ---
> From 8172e650c6797b9cc64c6f7b1c9e5433156290cc Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann
> Date: Wed, 31 Oct 2018 16:24:35 +0100
> Subject: [PATCH] vbox: fix link error with 'gcc -Og'
>
> With the new CONFIG_CC_OPTIMIZE_FOR_DEBUGGING option, we get a link
> error in the vboxguest driver, when that fails to optimize out the
> call to the compat handler:
>
> drivers/virt/vboxguest/vboxguest_core.o: In function `vbg_ioctl_hgcm_call':
> vboxguest_core.c:(.text+0x1f6e): undefined reference to `vbg_hgcm_call32'
>
> Another compile-time check documents better what we want and avoids
> the error.
>
> Signed-off-by: Arnd Bergmann
>
> diff --git a/drivers/virt/vboxguest/vboxguest_core.c
> b/drivers/virt/vboxguest/vboxguest_core.c
> index 3093655c7b92..1475ed5ffcde 100644
> --- a/drivers/virt/vboxguest/vboxguest_core.c
> +++ b/drivers/virt/vboxguest/vboxguest_core.c
> @@ -1312,7 +1312,7 @@ static int vbg_ioctl_hgcm_call(struct vbg_dev *gdev,
> return -EINVAL;
> }
>
> - if (f32bit)
> + if (IS_ENABLED(CONFIG_COMPAT) && f32bit)
> ret = vbg_hgcm_call32(gdev, client_id,
> call->function, call->timeout_ms,
> VBG_IOCTL_HGCM_CALL_PARMS32(call),
Right, but adding the CONFIG_COMPAT guard to both the caller and the callee
looks a bit redundant...
I think most cases causing this kind of problem
rely on the assumption that 'static' functions are inlined.
We can force the compiler to do so
by replacing 'static' with 'static __always_inline'
--
Best Regards
Masahiro Yamada
Re: [PATCH v3 4/5] modpost: Changes parameter name to avoid shadowing.
Em qua, 2018-10-31 Ã s 20:24 -0300, Leonardo Bras escreveu: > Em seg, 2018-10-29 Ã s 01:42 +0900, Masahiro Yamada escreveu: > > On Wed, Oct 24, 2018 at 1:05 PM Leonardo Bras > > wrote: > > > Changes the parameter name to avoid shadowing a variable. > > > > > > Signed-off-by: Leonardo Bras > > > > For this one, I'd rather like to see code refactoring > > than renaming the variable. > > > > I will take a closer look. > > What do you suggest to refactor? > I volunteer for this work. > > Leonardo Bras > I refactored the code to move the global variable *modules to a local context at function main, and changed the functions to accept *modules as a parameter. Is that what you had in mind? https://lkml.org/lkml/2018/11/1/725 Thanks for reading, Leonardo Bras
Re: [PATCH v3 4/5] modpost: Changes parameter name to avoid shadowing.
Em qua, 2018-10-31 Ã s 20:24 -0300, Leonardo Bras escreveu: > Em seg, 2018-10-29 Ã s 01:42 +0900, Masahiro Yamada escreveu: > > On Wed, Oct 24, 2018 at 1:05 PM Leonardo Bras > > wrote: > > > Changes the parameter name to avoid shadowing a variable. > > > > > > Signed-off-by: Leonardo Bras > > > > For this one, I'd rather like to see code refactoring > > than renaming the variable. > > > > I will take a closer look. > > What do you suggest to refactor? > I volunteer for this work. > > Leonardo Bras > I refactored the code to move the global variable *modules to a local context at function main, and changed the functions to accept *modules as a parameter. Is that what you had in mind? https://lkml.org/lkml/2018/11/1/725 Thanks for reading, Leonardo Bras
[PATCH 1/1] modpost: Refactor and removes global variable *modules
Refactors the code to accept the modules list as a parameter in
the functions that need it, and moves the variable from the
global scope to the main function scope.
This also fixes the parameter shadowing of add_depends.
Signed-off-by: Leonardo Bras
---
scripts/mod/modpost.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 0d998c54564d..bebe65ed957a 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -118,10 +118,7 @@ void *do_nofail(void *ptr, const char *expr)
return ptr;
}
-/* A list of all modules we processed */
-static struct module *modules;
-
-static struct module *find_module(const char *modname)
+static struct module *find_module(const char *modname, struct module *modules)
{
struct module *mod;
@@ -131,7 +128,7 @@ static struct module *find_module(const char *modname)
return mod;
}
-static struct module *new_module(const char *modname)
+static struct module *new_module(const char *modname, struct module **pmodules)
{
struct module *mod;
char *p;
@@ -149,8 +146,8 @@ static struct module *new_module(const char *modname)
/* add to list */
mod->name = p;
mod->gpl_compatible = -1;
- mod->next = modules;
- modules = mod;
+ mod->next = *pmodules;
+ *pmodules = mod;
return mod;
}
@@ -1929,7 +1926,7 @@ static char *remove_dot(char *s)
return s;
}
-static void read_symbols(const char *modname)
+static void read_symbols(const char *modname, struct module **pmodules)
{
const char *symname;
char *version;
@@ -1941,7 +1938,7 @@ static void read_symbols(const char *modname)
if (!parse_elf(, modname))
return;
- mod = new_module(modname);
+ mod = new_module(modname, pmodules);
/* When there's no vmlinux, don't print warnings about
* unresolved symbols (since there'll be too many ;) */
@@ -1992,7 +1989,8 @@ static void read_symbols(const char *modname)
mod->unres = alloc_symbol("module_layout", 0, mod->unres);
}
-static void read_symbols_from_files(const char *filename)
+static void read_symbols_from_files(const char *filename,
+ struct module **pmodules)
{
FILE *in = stdin;
char fname[PATH_MAX];
@@ -2006,7 +2004,7 @@ static void read_symbols_from_files(const char *filename)
while (fgets(fname, PATH_MAX, in) != NULL) {
if (strends(fname, "\n"))
fname[strlen(fname)-1] = '\0';
- read_symbols(fname);
+ read_symbols(fname, pmodules);
}
if (in != stdin)
@@ -2318,7 +2316,8 @@ static void write_if_changed(struct buffer *b, const char
*fname)
/* parse Module.symvers file. line format:
* 0x12345678symbolmodule[[export]something]
**/
-static void read_dump(const char *fname, unsigned int kernel)
+static void read_dump(const char *fname, unsigned int kernel,
+ struct module **pmodules)
{
unsigned long size, pos = 0;
void *file = grab_file(fname, );
@@ -2347,11 +2346,11 @@ static void read_dump(const char *fname, unsigned int
kernel)
crc = strtoul(line, , 16);
if (*symname == '\0' || *modname == '\0' || *d != '\0')
goto fail;
- mod = find_module(modname);
+ mod = find_module(modname, *pmodules);
if (!mod) {
if (is_vmlinux(modname))
have_vmlinux = 1;
- mod = new_module(modname);
+ mod = new_module(modname, pmodules);
mod->skip = 1;
}
s = sym_add_exported(symname, mod, export_no(export));
@@ -2415,6 +2414,8 @@ int main(int argc, char **argv)
int err;
struct ext_sym_list *extsym_iter;
struct ext_sym_list *extsym_start = NULL;
+ /* A list of all modules we processed */
+ static struct module *modules;
while ((opt = getopt(argc, argv, "i:I:e:mnsST:o:awM:K:E")) != -1) {
switch (opt) {
@@ -2466,21 +2467,21 @@ int main(int argc, char **argv)
}
if (kernel_read)
- read_dump(kernel_read, 1);
+ read_dump(kernel_read, 1, );
if (module_read)
- read_dump(module_read, 0);
+ read_dump(module_read, 0, );
while (extsym_start) {
- read_dump(extsym_start->file, 0);
+ read_dump(extsym_start->file, 0, );
extsym_iter = extsym_start->next;
free(extsym_start);
extsym_start = extsym_iter;
}
while (optind < argc)
- read_symbols(argv[optind++]);
+ read_symbols(argv[optind++], );
if (files_source)
-
[PATCH 1/1] modpost: Refactor and removes global variable *modules
Refactors the code to accept the modules list as a parameter in
the functions that need it, and moves the variable from the
global scope to the main function scope.
This also fixes the parameter shadowing of add_depends.
Signed-off-by: Leonardo Bras
---
scripts/mod/modpost.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 0d998c54564d..bebe65ed957a 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -118,10 +118,7 @@ void *do_nofail(void *ptr, const char *expr)
return ptr;
}
-/* A list of all modules we processed */
-static struct module *modules;
-
-static struct module *find_module(const char *modname)
+static struct module *find_module(const char *modname, struct module *modules)
{
struct module *mod;
@@ -131,7 +128,7 @@ static struct module *find_module(const char *modname)
return mod;
}
-static struct module *new_module(const char *modname)
+static struct module *new_module(const char *modname, struct module **pmodules)
{
struct module *mod;
char *p;
@@ -149,8 +146,8 @@ static struct module *new_module(const char *modname)
/* add to list */
mod->name = p;
mod->gpl_compatible = -1;
- mod->next = modules;
- modules = mod;
+ mod->next = *pmodules;
+ *pmodules = mod;
return mod;
}
@@ -1929,7 +1926,7 @@ static char *remove_dot(char *s)
return s;
}
-static void read_symbols(const char *modname)
+static void read_symbols(const char *modname, struct module **pmodules)
{
const char *symname;
char *version;
@@ -1941,7 +1938,7 @@ static void read_symbols(const char *modname)
if (!parse_elf(, modname))
return;
- mod = new_module(modname);
+ mod = new_module(modname, pmodules);
/* When there's no vmlinux, don't print warnings about
* unresolved symbols (since there'll be too many ;) */
@@ -1992,7 +1989,8 @@ static void read_symbols(const char *modname)
mod->unres = alloc_symbol("module_layout", 0, mod->unres);
}
-static void read_symbols_from_files(const char *filename)
+static void read_symbols_from_files(const char *filename,
+ struct module **pmodules)
{
FILE *in = stdin;
char fname[PATH_MAX];
@@ -2006,7 +2004,7 @@ static void read_symbols_from_files(const char *filename)
while (fgets(fname, PATH_MAX, in) != NULL) {
if (strends(fname, "\n"))
fname[strlen(fname)-1] = '\0';
- read_symbols(fname);
+ read_symbols(fname, pmodules);
}
if (in != stdin)
@@ -2318,7 +2316,8 @@ static void write_if_changed(struct buffer *b, const char
*fname)
/* parse Module.symvers file. line format:
* 0x12345678symbolmodule[[export]something]
**/
-static void read_dump(const char *fname, unsigned int kernel)
+static void read_dump(const char *fname, unsigned int kernel,
+ struct module **pmodules)
{
unsigned long size, pos = 0;
void *file = grab_file(fname, );
@@ -2347,11 +2346,11 @@ static void read_dump(const char *fname, unsigned int
kernel)
crc = strtoul(line, , 16);
if (*symname == '\0' || *modname == '\0' || *d != '\0')
goto fail;
- mod = find_module(modname);
+ mod = find_module(modname, *pmodules);
if (!mod) {
if (is_vmlinux(modname))
have_vmlinux = 1;
- mod = new_module(modname);
+ mod = new_module(modname, pmodules);
mod->skip = 1;
}
s = sym_add_exported(symname, mod, export_no(export));
@@ -2415,6 +2414,8 @@ int main(int argc, char **argv)
int err;
struct ext_sym_list *extsym_iter;
struct ext_sym_list *extsym_start = NULL;
+ /* A list of all modules we processed */
+ static struct module *modules;
while ((opt = getopt(argc, argv, "i:I:e:mnsST:o:awM:K:E")) != -1) {
switch (opt) {
@@ -2466,21 +2467,21 @@ int main(int argc, char **argv)
}
if (kernel_read)
- read_dump(kernel_read, 1);
+ read_dump(kernel_read, 1, );
if (module_read)
- read_dump(module_read, 0);
+ read_dump(module_read, 0, );
while (extsym_start) {
- read_dump(extsym_start->file, 0);
+ read_dump(extsym_start->file, 0, );
extsym_iter = extsym_start->next;
free(extsym_start);
extsym_start = extsym_iter;
}
while (optind < argc)
- read_symbols(argv[optind++]);
+ read_symbols(argv[optind++], );
if (files_source)
-
Re: [PATCH 16/17] prmem: pratomic-long
On Wed, Oct 31, 2018 at 2:10 AM, Peter Zijlstra wrote: > On Tue, Oct 30, 2018 at 04:28:16PM +, Will Deacon wrote: >> On Tue, Oct 30, 2018 at 04:58:41PM +0100, Peter Zijlstra wrote: >> > Like mentioned elsewhere; if you do write_enable() + write_disable() >> > thingies, it all becomes: >> > >> > write_enable(); >> > atomic_foo(); >> > write_disable(); >> > >> > No magic gunk infested duplication at all. Of course, ideally you'd then >> > teach objtool about this (or a GCC plugin I suppose) to ensure any >> > enable reached a disable. >> >> Isn't the issue here that we don't want to change the page tables for the >> mapping of , but instead want to create a temporary writable alias >> at a random virtual address? >> >> So you'd want: >> >> wbar = write_enable(); >> atomic_foo(wbar); >> write_disable(wbar); >> >> which is probably better expressed as a map/unmap API. I suspect this >> would also be the only way to do things for cmpxchg() loops, where you >> want to create the mapping outside of the loop to minimise your time in >> the critical section. > > Ah, so I was thikning that the altnerative mm would have stuff in the > same location, just RW instead of RO. I was hoping for the same location too. That allows use to use a gcc plugin to mark, say, function pointer tables, as read-only, and annotate their rare updates with write_rare() without any recalculation. -Kees -- Kees Cook
Re: [PATCH 16/17] prmem: pratomic-long
On Wed, Oct 31, 2018 at 2:10 AM, Peter Zijlstra wrote: > On Tue, Oct 30, 2018 at 04:28:16PM +, Will Deacon wrote: >> On Tue, Oct 30, 2018 at 04:58:41PM +0100, Peter Zijlstra wrote: >> > Like mentioned elsewhere; if you do write_enable() + write_disable() >> > thingies, it all becomes: >> > >> > write_enable(); >> > atomic_foo(); >> > write_disable(); >> > >> > No magic gunk infested duplication at all. Of course, ideally you'd then >> > teach objtool about this (or a GCC plugin I suppose) to ensure any >> > enable reached a disable. >> >> Isn't the issue here that we don't want to change the page tables for the >> mapping of , but instead want to create a temporary writable alias >> at a random virtual address? >> >> So you'd want: >> >> wbar = write_enable(); >> atomic_foo(wbar); >> write_disable(wbar); >> >> which is probably better expressed as a map/unmap API. I suspect this >> would also be the only way to do things for cmpxchg() loops, where you >> want to create the mapping outside of the loop to minimise your time in >> the critical section. > > Ah, so I was thikning that the altnerative mm would have stuff in the > same location, just RW instead of RO. I was hoping for the same location too. That allows use to use a gcc plugin to mark, say, function pointer tables, as read-only, and annotate their rare updates with write_rare() without any recalculation. -Kees -- Kees Cook
Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall
On 18-10-31 18:15:39, Peter Zijlstra wrote: > On Wed, Oct 31, 2018 at 11:07:22AM -0400, Waiman Long wrote: > > On 10/31/2018 10:10 AM, Peter Zijlstra wrote: > > > On Wed, Oct 31, 2018 at 09:54:17AM +0800, Yi Sun wrote: > > >> On 18-10-23 17:33:28, Yi Sun wrote: > > >>> On 18-10-23 10:51:27, Peter Zijlstra wrote: > > Can you try and explain why vcpu_is_preempted() doesn't work for you? > > >>> I thought HvSpinWaitInfo is used to notify hypervisor the spin number > > >>> which is different with vcpu_is_preempted. So I did not consider > > >>> vcpu_is_preempted. > > >>> > > >>> But HvSpinWaitInfo is a quite simple function and could be combined > > >>> with vcpu_is_preempted together. So I think it is OK to use > > >>> vcpu_is_preempted to make codes clean. I will have a try. > > >> After checking codes, there is one issue to call vcpu_is_preempted. > > >> There are two spin loops in qspinlock_paravirt.h. One loop in > > >> 'pv_wait_node' calls vcpu_is_preempted. But another loop in > > >> 'pv_wait_head_or_lock' does not call vcpu_is_preempted. It also does > > >> not call any other ops of 'pv_lock_ops' in the loop. So I am afraid > > >> we have to add one more ops in 'pv_lock_ops' to do this. > > > Why? Would not something like the below cure that? Waiman, can you have > > > a look at this; I always forget how that paravirt crud works. > > > > There are two major reasons why the vcpu_is_preempt() test isn't done at > > pv_wait_head_or_lock(). First of all, we may not have a valid prev > > pointer after all if it is the first one to enter the queue while the > > lock is busy. Secondly, because of lock stealing, the cpu number pointed > > by a valid prev pointer may not be the actual cpu that is currently > > holding the lock. Another minor reason is that we want to minimize the > > lock transfer latency and so don't want to sleep too early while waiting > > at the queue head. > > So Yi, are you actually seeing a problem? If so, can you give details? Where does the patch come from? I cannot find it through google. Per Waiman's comment, it seems not suitable to call vcpu_is_preempted() in pv_wait_head_or_lock(). So, we cannot make HvSpinWaitInfo notification through vcpu_is_preempted() for such case. Based on that, I suggest to add one more callback function in pv_lock_ops. BTW, which performance test do you suggest? I am trying to test it by AIM7.
Re: [Ocfs2-devel] [PATCH V2] ocfs2: fix dead lock caused by ocfs2_defrag_extent
Hi Larry,
I still have a few tiny comments for your patch, please refer to them.
On 2018/11/1 5:28, Andrew Morton wrote:
>
> Folks, could we please review this patch for upstream inclusion?
>
> Thanks.
>
>
> From: Larry Chen
> Subject: ocfs2: fix deadlock caused by ocfs2_defrag_extent
>
> ocfs2_defrag_extent may fall into deadlock.
>
> ocfs2_ioctl_move_extents
>ocfs2_ioctl_move_extents
> ocfs2_move_extents
>ocfs2_defrag_extent
> ocfs2_lock_allocators_move_extents
>
>ocfs2_reserve_clusters
> inode_lock GLOBAL_BITMAP_SYSTEM_INODE
>
> __ocfs2_flush_truncate_log
> inode_lock GLOBAL_BITMAP_SYSTEM_INODE
>
> As backtrace shows above, ocfs2_reserve_clusters() will call inode_lock
> against the global bitmap if local allocator has not sufficient cluters.
> Once global bitmap could meet the demand, ocfs2_reserve_cluster will
> return success with global bitmap locked.
>
> After ocfs2_reserve_cluster(), if truncate log is full,
> __ocfs2_flush_truncate_log() will definitely fall into deadlock because it
> needs to inode_lock global bitmap, which has already been locked.
>
> To fix this bug, we could remove from ocfs2_lock_allocators_move_extents()
> the code which intends to lock global allocator, and put the removed code
> after __ocfs2_flush_truncate_log().
>
> ocfs2_lock_allocators_move_extents() is refered by 2 places, one is here,
> the other does not need the data allocator context, which means this patch
> does not affect the caller so far.
>
> [lc...@suse.com: rename ocfs2_lock_allocators_move_extents() to
> ocfs2_lock_meta_allocator_move_extents(), add some comments]
>Link:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20180902091455.23862-2D1-2Dlchen-40suse.com=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=C7gAd4uDxlAvTdc0vmU6X8CMk6L2iDY8-HD0qT6Fo7Y=K8aRgOiMescamJW-IuHq-cW4mWedGQv2JTT-2KPy1RI=3fQHFtwgixirPeQ5Px4fRBnd_UcSx3rvSsLKLidwESo=
> Link:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20180827080121.31145-2D1-2Dlchen-40suse.com=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=C7gAd4uDxlAvTdc0vmU6X8CMk6L2iDY8-HD0qT6Fo7Y=K8aRgOiMescamJW-IuHq-cW4mWedGQv2JTT-2KPy1RI=PQOJREyeElsg_1IlINdSGefNqA6w_cUrI1ezdVxyi7o=
> Signed-off-by: Larry Chen
> Cc: Mark Fasheh
> Cc: Joel Becker
> Cc: Junxiao Bi
> Cc: Joseph Qi
> Cc: Changwei Ge
> Signed-off-by: Andrew Morton
> ---
>
> fs/ocfs2/move_extents.c | 40 +++---
> 1 file changed, 25 insertions(+), 15 deletions(-)
>
> --- a/fs/ocfs2/move_extents.c~fix-dead-lock-caused-by-ocfs2_defrag_extent
> +++ a/fs/ocfs2/move_extents.c
> @@ -162,7 +162,7 @@ out:
>* in some cases, we don't need to reserve clusters, just let data_ac
>* be NULL.
>*/
> -static int ocfs2_lock_allocators_move_extents(struct inode *inode,
> +static int ocfs2_lock_meta_allocator_move_extents(struct inode *inode,
> struct ocfs2_extent_tree *et,
> u32 clusters_to_move,
> u32 extents_to_split,
After removing 'reserving clusters logic' out of this function, I suggest to
also change the function header comments.
And I think there is no need for arguments _data_ac_ now.
Otherwise this patch looks sane to me.
Thanks,
Changwei
> @@ -192,13 +192,6 @@ static int ocfs2_lock_allocators_move_ex
> goto out;
> }
>
> - if (data_ac) {
> - ret = ocfs2_reserve_clusters(osb, clusters_to_move, data_ac);
> - if (ret) {
> - mlog_errno(ret);
> - goto out;
> - }
> - }
>
> *credits += ocfs2_calc_extend_credits(osb->sb, et->et_root_el);
>
> @@ -257,10 +250,11 @@ static int ocfs2_defrag_extent(struct oc
> }
> }
>
> - ret = ocfs2_lock_allocators_move_extents(inode, >et, *len, 1,
> - >meta_ac,
> - >data_ac,
> - extra_blocks, );
> + ret = ocfs2_lock_meta_allocator_move_extents(inode, >et,
> + *len, 1,
> + >meta_ac,
> + >data_ac,
> + extra_blocks, );
> if (ret) {
> mlog_errno(ret);
> goto out;
> @@ -283,6 +277,21 @@ static int ocfs2_defrag_extent(struct oc
> }
> }
>
> + /*
> + * Make sure ocfs2_reserve_cluster is called after
> + * __ocfs2_flush_truncate_log, otherwise, dead lock may happen.
> + *
> + * If ocfs2_reserve_cluster is called
> + * before __ocfs2_flush_truncate_log, dead lock on global bitmap
> + * may happen.
> + *
> + */
> + ret =
Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall
On 18-10-31 18:15:39, Peter Zijlstra wrote: > On Wed, Oct 31, 2018 at 11:07:22AM -0400, Waiman Long wrote: > > On 10/31/2018 10:10 AM, Peter Zijlstra wrote: > > > On Wed, Oct 31, 2018 at 09:54:17AM +0800, Yi Sun wrote: > > >> On 18-10-23 17:33:28, Yi Sun wrote: > > >>> On 18-10-23 10:51:27, Peter Zijlstra wrote: > > Can you try and explain why vcpu_is_preempted() doesn't work for you? > > >>> I thought HvSpinWaitInfo is used to notify hypervisor the spin number > > >>> which is different with vcpu_is_preempted. So I did not consider > > >>> vcpu_is_preempted. > > >>> > > >>> But HvSpinWaitInfo is a quite simple function and could be combined > > >>> with vcpu_is_preempted together. So I think it is OK to use > > >>> vcpu_is_preempted to make codes clean. I will have a try. > > >> After checking codes, there is one issue to call vcpu_is_preempted. > > >> There are two spin loops in qspinlock_paravirt.h. One loop in > > >> 'pv_wait_node' calls vcpu_is_preempted. But another loop in > > >> 'pv_wait_head_or_lock' does not call vcpu_is_preempted. It also does > > >> not call any other ops of 'pv_lock_ops' in the loop. So I am afraid > > >> we have to add one more ops in 'pv_lock_ops' to do this. > > > Why? Would not something like the below cure that? Waiman, can you have > > > a look at this; I always forget how that paravirt crud works. > > > > There are two major reasons why the vcpu_is_preempt() test isn't done at > > pv_wait_head_or_lock(). First of all, we may not have a valid prev > > pointer after all if it is the first one to enter the queue while the > > lock is busy. Secondly, because of lock stealing, the cpu number pointed > > by a valid prev pointer may not be the actual cpu that is currently > > holding the lock. Another minor reason is that we want to minimize the > > lock transfer latency and so don't want to sleep too early while waiting > > at the queue head. > > So Yi, are you actually seeing a problem? If so, can you give details? Where does the patch come from? I cannot find it through google. Per Waiman's comment, it seems not suitable to call vcpu_is_preempted() in pv_wait_head_or_lock(). So, we cannot make HvSpinWaitInfo notification through vcpu_is_preempted() for such case. Based on that, I suggest to add one more callback function in pv_lock_ops. BTW, which performance test do you suggest? I am trying to test it by AIM7.
Re: [Ocfs2-devel] [PATCH V2] ocfs2: fix dead lock caused by ocfs2_defrag_extent
Hi Larry,
I still have a few tiny comments for your patch, please refer to them.
On 2018/11/1 5:28, Andrew Morton wrote:
>
> Folks, could we please review this patch for upstream inclusion?
>
> Thanks.
>
>
> From: Larry Chen
> Subject: ocfs2: fix deadlock caused by ocfs2_defrag_extent
>
> ocfs2_defrag_extent may fall into deadlock.
>
> ocfs2_ioctl_move_extents
>ocfs2_ioctl_move_extents
> ocfs2_move_extents
>ocfs2_defrag_extent
> ocfs2_lock_allocators_move_extents
>
>ocfs2_reserve_clusters
> inode_lock GLOBAL_BITMAP_SYSTEM_INODE
>
> __ocfs2_flush_truncate_log
> inode_lock GLOBAL_BITMAP_SYSTEM_INODE
>
> As backtrace shows above, ocfs2_reserve_clusters() will call inode_lock
> against the global bitmap if local allocator has not sufficient cluters.
> Once global bitmap could meet the demand, ocfs2_reserve_cluster will
> return success with global bitmap locked.
>
> After ocfs2_reserve_cluster(), if truncate log is full,
> __ocfs2_flush_truncate_log() will definitely fall into deadlock because it
> needs to inode_lock global bitmap, which has already been locked.
>
> To fix this bug, we could remove from ocfs2_lock_allocators_move_extents()
> the code which intends to lock global allocator, and put the removed code
> after __ocfs2_flush_truncate_log().
>
> ocfs2_lock_allocators_move_extents() is refered by 2 places, one is here,
> the other does not need the data allocator context, which means this patch
> does not affect the caller so far.
>
> [lc...@suse.com: rename ocfs2_lock_allocators_move_extents() to
> ocfs2_lock_meta_allocator_move_extents(), add some comments]
>Link:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20180902091455.23862-2D1-2Dlchen-40suse.com=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=C7gAd4uDxlAvTdc0vmU6X8CMk6L2iDY8-HD0qT6Fo7Y=K8aRgOiMescamJW-IuHq-cW4mWedGQv2JTT-2KPy1RI=3fQHFtwgixirPeQ5Px4fRBnd_UcSx3rvSsLKLidwESo=
> Link:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20180827080121.31145-2D1-2Dlchen-40suse.com=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=C7gAd4uDxlAvTdc0vmU6X8CMk6L2iDY8-HD0qT6Fo7Y=K8aRgOiMescamJW-IuHq-cW4mWedGQv2JTT-2KPy1RI=PQOJREyeElsg_1IlINdSGefNqA6w_cUrI1ezdVxyi7o=
> Signed-off-by: Larry Chen
> Cc: Mark Fasheh
> Cc: Joel Becker
> Cc: Junxiao Bi
> Cc: Joseph Qi
> Cc: Changwei Ge
> Signed-off-by: Andrew Morton
> ---
>
> fs/ocfs2/move_extents.c | 40 +++---
> 1 file changed, 25 insertions(+), 15 deletions(-)
>
> --- a/fs/ocfs2/move_extents.c~fix-dead-lock-caused-by-ocfs2_defrag_extent
> +++ a/fs/ocfs2/move_extents.c
> @@ -162,7 +162,7 @@ out:
>* in some cases, we don't need to reserve clusters, just let data_ac
>* be NULL.
>*/
> -static int ocfs2_lock_allocators_move_extents(struct inode *inode,
> +static int ocfs2_lock_meta_allocator_move_extents(struct inode *inode,
> struct ocfs2_extent_tree *et,
> u32 clusters_to_move,
> u32 extents_to_split,
After removing 'reserving clusters logic' out of this function, I suggest to
also change the function header comments.
And I think there is no need for arguments _data_ac_ now.
Otherwise this patch looks sane to me.
Thanks,
Changwei
> @@ -192,13 +192,6 @@ static int ocfs2_lock_allocators_move_ex
> goto out;
> }
>
> - if (data_ac) {
> - ret = ocfs2_reserve_clusters(osb, clusters_to_move, data_ac);
> - if (ret) {
> - mlog_errno(ret);
> - goto out;
> - }
> - }
>
> *credits += ocfs2_calc_extend_credits(osb->sb, et->et_root_el);
>
> @@ -257,10 +250,11 @@ static int ocfs2_defrag_extent(struct oc
> }
> }
>
> - ret = ocfs2_lock_allocators_move_extents(inode, >et, *len, 1,
> - >meta_ac,
> - >data_ac,
> - extra_blocks, );
> + ret = ocfs2_lock_meta_allocator_move_extents(inode, >et,
> + *len, 1,
> + >meta_ac,
> + >data_ac,
> + extra_blocks, );
> if (ret) {
> mlog_errno(ret);
> goto out;
> @@ -283,6 +277,21 @@ static int ocfs2_defrag_extent(struct oc
> }
> }
>
> + /*
> + * Make sure ocfs2_reserve_cluster is called after
> + * __ocfs2_flush_truncate_log, otherwise, dead lock may happen.
> + *
> + * If ocfs2_reserve_cluster is called
> + * before __ocfs2_flush_truncate_log, dead lock on global bitmap
> + * may happen.
> + *
> + */
> + ret =
[PATCH 1/3] modpost: Refactor and removes global variable *modules
Refactors the code to accept the modules list as a parameter in
the functions that need it, and moves the variable from the
global scope to the main function scope.
This also fixes the parameter shadowing of add_depends.
Signed-off-by: Leonardo Bras
---
scripts/mod/modpost.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 0d998c54564d..bebe65ed957a 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -118,10 +118,7 @@ void *do_nofail(void *ptr, const char *expr)
return ptr;
}
-/* A list of all modules we processed */
-static struct module *modules;
-
-static struct module *find_module(const char *modname)
+static struct module *find_module(const char *modname, struct module *modules)
{
struct module *mod;
@@ -131,7 +128,7 @@ static struct module *find_module(const char *modname)
return mod;
}
-static struct module *new_module(const char *modname)
+static struct module *new_module(const char *modname, struct module **pmodules)
{
struct module *mod;
char *p;
@@ -149,8 +146,8 @@ static struct module *new_module(const char *modname)
/* add to list */
mod->name = p;
mod->gpl_compatible = -1;
- mod->next = modules;
- modules = mod;
+ mod->next = *pmodules;
+ *pmodules = mod;
return mod;
}
@@ -1929,7 +1926,7 @@ static char *remove_dot(char *s)
return s;
}
-static void read_symbols(const char *modname)
+static void read_symbols(const char *modname, struct module **pmodules)
{
const char *symname;
char *version;
@@ -1941,7 +1938,7 @@ static void read_symbols(const char *modname)
if (!parse_elf(, modname))
return;
- mod = new_module(modname);
+ mod = new_module(modname, pmodules);
/* When there's no vmlinux, don't print warnings about
* unresolved symbols (since there'll be too many ;) */
@@ -1992,7 +1989,8 @@ static void read_symbols(const char *modname)
mod->unres = alloc_symbol("module_layout", 0, mod->unres);
}
-static void read_symbols_from_files(const char *filename)
+static void read_symbols_from_files(const char *filename,
+ struct module **pmodules)
{
FILE *in = stdin;
char fname[PATH_MAX];
@@ -2006,7 +2004,7 @@ static void read_symbols_from_files(const char *filename)
while (fgets(fname, PATH_MAX, in) != NULL) {
if (strends(fname, "\n"))
fname[strlen(fname)-1] = '\0';
- read_symbols(fname);
+ read_symbols(fname, pmodules);
}
if (in != stdin)
@@ -2318,7 +2316,8 @@ static void write_if_changed(struct buffer *b, const char
*fname)
/* parse Module.symvers file. line format:
* 0x12345678symbolmodule[[export]something]
**/
-static void read_dump(const char *fname, unsigned int kernel)
+static void read_dump(const char *fname, unsigned int kernel,
+ struct module **pmodules)
{
unsigned long size, pos = 0;
void *file = grab_file(fname, );
@@ -2347,11 +2346,11 @@ static void read_dump(const char *fname, unsigned int
kernel)
crc = strtoul(line, , 16);
if (*symname == '\0' || *modname == '\0' || *d != '\0')
goto fail;
- mod = find_module(modname);
+ mod = find_module(modname, *pmodules);
if (!mod) {
if (is_vmlinux(modname))
have_vmlinux = 1;
- mod = new_module(modname);
+ mod = new_module(modname, pmodules);
mod->skip = 1;
}
s = sym_add_exported(symname, mod, export_no(export));
@@ -2415,6 +2414,8 @@ int main(int argc, char **argv)
int err;
struct ext_sym_list *extsym_iter;
struct ext_sym_list *extsym_start = NULL;
+ /* A list of all modules we processed */
+ static struct module *modules;
while ((opt = getopt(argc, argv, "i:I:e:mnsST:o:awM:K:E")) != -1) {
switch (opt) {
@@ -2466,21 +2467,21 @@ int main(int argc, char **argv)
}
if (kernel_read)
- read_dump(kernel_read, 1);
+ read_dump(kernel_read, 1, );
if (module_read)
- read_dump(module_read, 0);
+ read_dump(module_read, 0, );
while (extsym_start) {
- read_dump(extsym_start->file, 0);
+ read_dump(extsym_start->file, 0, );
extsym_iter = extsym_start->next;
free(extsym_start);
extsym_start = extsym_iter;
}
while (optind < argc)
- read_symbols(argv[optind++]);
+ read_symbols(argv[optind++], );
if (files_source)
-
[PATCH 1/3] modpost: Refactor and removes global variable *modules
Refactors the code to accept the modules list as a parameter in
the functions that need it, and moves the variable from the
global scope to the main function scope.
This also fixes the parameter shadowing of add_depends.
Signed-off-by: Leonardo Bras
---
scripts/mod/modpost.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 0d998c54564d..bebe65ed957a 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -118,10 +118,7 @@ void *do_nofail(void *ptr, const char *expr)
return ptr;
}
-/* A list of all modules we processed */
-static struct module *modules;
-
-static struct module *find_module(const char *modname)
+static struct module *find_module(const char *modname, struct module *modules)
{
struct module *mod;
@@ -131,7 +128,7 @@ static struct module *find_module(const char *modname)
return mod;
}
-static struct module *new_module(const char *modname)
+static struct module *new_module(const char *modname, struct module **pmodules)
{
struct module *mod;
char *p;
@@ -149,8 +146,8 @@ static struct module *new_module(const char *modname)
/* add to list */
mod->name = p;
mod->gpl_compatible = -1;
- mod->next = modules;
- modules = mod;
+ mod->next = *pmodules;
+ *pmodules = mod;
return mod;
}
@@ -1929,7 +1926,7 @@ static char *remove_dot(char *s)
return s;
}
-static void read_symbols(const char *modname)
+static void read_symbols(const char *modname, struct module **pmodules)
{
const char *symname;
char *version;
@@ -1941,7 +1938,7 @@ static void read_symbols(const char *modname)
if (!parse_elf(, modname))
return;
- mod = new_module(modname);
+ mod = new_module(modname, pmodules);
/* When there's no vmlinux, don't print warnings about
* unresolved symbols (since there'll be too many ;) */
@@ -1992,7 +1989,8 @@ static void read_symbols(const char *modname)
mod->unres = alloc_symbol("module_layout", 0, mod->unres);
}
-static void read_symbols_from_files(const char *filename)
+static void read_symbols_from_files(const char *filename,
+ struct module **pmodules)
{
FILE *in = stdin;
char fname[PATH_MAX];
@@ -2006,7 +2004,7 @@ static void read_symbols_from_files(const char *filename)
while (fgets(fname, PATH_MAX, in) != NULL) {
if (strends(fname, "\n"))
fname[strlen(fname)-1] = '\0';
- read_symbols(fname);
+ read_symbols(fname, pmodules);
}
if (in != stdin)
@@ -2318,7 +2316,8 @@ static void write_if_changed(struct buffer *b, const char
*fname)
/* parse Module.symvers file. line format:
* 0x12345678symbolmodule[[export]something]
**/
-static void read_dump(const char *fname, unsigned int kernel)
+static void read_dump(const char *fname, unsigned int kernel,
+ struct module **pmodules)
{
unsigned long size, pos = 0;
void *file = grab_file(fname, );
@@ -2347,11 +2346,11 @@ static void read_dump(const char *fname, unsigned int
kernel)
crc = strtoul(line, , 16);
if (*symname == '\0' || *modname == '\0' || *d != '\0')
goto fail;
- mod = find_module(modname);
+ mod = find_module(modname, *pmodules);
if (!mod) {
if (is_vmlinux(modname))
have_vmlinux = 1;
- mod = new_module(modname);
+ mod = new_module(modname, pmodules);
mod->skip = 1;
}
s = sym_add_exported(symname, mod, export_no(export));
@@ -2415,6 +2414,8 @@ int main(int argc, char **argv)
int err;
struct ext_sym_list *extsym_iter;
struct ext_sym_list *extsym_start = NULL;
+ /* A list of all modules we processed */
+ static struct module *modules;
while ((opt = getopt(argc, argv, "i:I:e:mnsST:o:awM:K:E")) != -1) {
switch (opt) {
@@ -2466,21 +2467,21 @@ int main(int argc, char **argv)
}
if (kernel_read)
- read_dump(kernel_read, 1);
+ read_dump(kernel_read, 1, );
if (module_read)
- read_dump(module_read, 0);
+ read_dump(module_read, 0, );
while (extsym_start) {
- read_dump(extsym_start->file, 0);
+ read_dump(extsym_start->file, 0, );
extsym_iter = extsym_start->next;
free(extsym_start);
extsym_start = extsym_iter;
}
while (optind < argc)
- read_symbols(argv[optind++]);
+ read_symbols(argv[optind++], );
if (files_source)
-
[Patch v2] genirq/matrix: Choose CPU for assigning interrupts based on allocated IRQs
From: Long Li
On a large system with multiple devices of the same class (e.g. NVMe disks,
using managed IRQs), the kernel tends to concentrate their IRQs on several
CPUs.
The issue is that when NVMe calls irq_matrix_alloc_managed(), the assigned
CPU tends to be the first several CPUs in the cpumask, because they check for
cpumap->available that will not change after managed IRQs are reserved.
In irq_matrix->cpumap, "available" is set when IRQs are allocated earlier
in the IRQ allocation process. This value is caculated based on
1. how many unmanaged IRQs are allocated on this CPU
2. how many managed IRQs are reserved on this CPU
But "available" is not accurate in accouting the real IRQs load on a given CPU.
For a managed IRQ, it tends to reserve more than one CPU, based on cpumask in
irq_matrix_reserve_managed. But later when actually allocating CPU for this
IRQ, only one CPU is allocated. Because "available" is calculated at the time
managed IRQ is reserved, it tends to indicate a CPU has more IRQs than it's
actually assigned.
When a managed IRQ is assigned to a CPU in irq_matrix_alloc_managed(), it
decreases "allocated" based on the actually assignment of this IRQ to this CPU.
Unmanaged IRQ also decreases "allocated" after allocating an IRQ on this CPU.
For this reason, checking "allocated" is more accurate than checking
"available" for a given CPU, and result in a more evenly distributed IRQ
across all CPUs.
Signed-off-by: Long Li
Reviewed-by: Michael Kelley
---
kernel/irq/matrix.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 6e6d467f3dec..a51689e3e7c0 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -128,7 +128,7 @@ static unsigned int matrix_alloc_area(struct irq_matrix *m,
struct cpumap *cm,
static unsigned int matrix_find_best_cpu(struct irq_matrix *m,
const struct cpumask *msk)
{
- unsigned int cpu, best_cpu, maxavl = 0;
+ unsigned int cpu, best_cpu, min_allocated = UINT_MAX;
struct cpumap *cm;
best_cpu = UINT_MAX;
@@ -136,11 +136,11 @@ static unsigned int matrix_find_best_cpu(struct
irq_matrix *m,
for_each_cpu(cpu, msk) {
cm = per_cpu_ptr(m->maps, cpu);
- if (!cm->online || cm->available <= maxavl)
+ if (!cm->online || cm->allocated > min_allocated)
continue;
best_cpu = cpu;
- maxavl = cm->available;
+ min_allocated = cm->allocated;
}
return best_cpu;
}
--
2.14.1
[Patch v2] genirq/matrix: Choose CPU for assigning interrupts based on allocated IRQs
From: Long Li
On a large system with multiple devices of the same class (e.g. NVMe disks,
using managed IRQs), the kernel tends to concentrate their IRQs on several
CPUs.
The issue is that when NVMe calls irq_matrix_alloc_managed(), the assigned
CPU tends to be the first several CPUs in the cpumask, because they check for
cpumap->available that will not change after managed IRQs are reserved.
In irq_matrix->cpumap, "available" is set when IRQs are allocated earlier
in the IRQ allocation process. This value is caculated based on
1. how many unmanaged IRQs are allocated on this CPU
2. how many managed IRQs are reserved on this CPU
But "available" is not accurate in accouting the real IRQs load on a given CPU.
For a managed IRQ, it tends to reserve more than one CPU, based on cpumask in
irq_matrix_reserve_managed. But later when actually allocating CPU for this
IRQ, only one CPU is allocated. Because "available" is calculated at the time
managed IRQ is reserved, it tends to indicate a CPU has more IRQs than it's
actually assigned.
When a managed IRQ is assigned to a CPU in irq_matrix_alloc_managed(), it
decreases "allocated" based on the actually assignment of this IRQ to this CPU.
Unmanaged IRQ also decreases "allocated" after allocating an IRQ on this CPU.
For this reason, checking "allocated" is more accurate than checking
"available" for a given CPU, and result in a more evenly distributed IRQ
across all CPUs.
Signed-off-by: Long Li
Reviewed-by: Michael Kelley
---
kernel/irq/matrix.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 6e6d467f3dec..a51689e3e7c0 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -128,7 +128,7 @@ static unsigned int matrix_alloc_area(struct irq_matrix *m,
struct cpumap *cm,
static unsigned int matrix_find_best_cpu(struct irq_matrix *m,
const struct cpumask *msk)
{
- unsigned int cpu, best_cpu, maxavl = 0;
+ unsigned int cpu, best_cpu, min_allocated = UINT_MAX;
struct cpumap *cm;
best_cpu = UINT_MAX;
@@ -136,11 +136,11 @@ static unsigned int matrix_find_best_cpu(struct
irq_matrix *m,
for_each_cpu(cpu, msk) {
cm = per_cpu_ptr(m->maps, cpu);
- if (!cm->online || cm->available <= maxavl)
+ if (!cm->online || cm->allocated > min_allocated)
continue;
best_cpu = cpu;
- maxavl = cm->available;
+ min_allocated = cm->allocated;
}
return best_cpu;
}
--
2.14.1
[GIT PULL] platform-drivers-x86 for 4.20-1
Hi Linus, This tag has a few merge conflicts with some x86/cpu id changes. Stephen Rothwell's merge in next/master is correct, and I have provided an example here as well: git://git.infradead.org/linux-platform-drivers-x86.git pdx86-v4.20-1-merge Thanks, Darren Hart VMware Open Source Technology Center The following changes since commit ff0e9f26288d2daee4950f42b37a3d3d30d36ec1: platform/x86: alienware-wmi: Correct a memory leak (2018-09-10 13:45:43 -0700) are available in the git repository at: git://git.infradead.org/linux-platform-drivers-x86.git tags/platform-drivers-x86-v4.20-1 for you to fetch changes up to 3b692c55e58d06ba9b17c66784cab5a95ba5be9b: HID: asus: only support backlight when it's not driven by WMI (2018-10-31 16:11:40 +0200) platform-drivers-x86 for v4.20-1 Move the Dell dcdbas and dell_rbu drivers into platform/drivers/x86 as they are closely coupled with other drivers in this location. Improve _init* usage for acerhdf and fix some usage issues with messages and module parameters. Simplify asus-wmi by calling ACPI/WMI methods directly, eliminating workqueue overhead, eliminate double reporting of keyboard backlight. Fix wake from USB failure on Bay Trail devices (intel_int0002_vgpio). Notify intel_telemetry users when IPC1 device is not enabled. Update various drivers with new laptop model IDs. Update several intel drivers to use SPDX identifers and order headers alphabetically. The following is an automated git shortlog grouped by driver: Add Intel AtomISP2 dummy / power-management driver: - Add Intel AtomISP2 dummy / power-management driver lg-laptop: - Add LG Gram laptop special features driver HID: - asus: only support backlight when it's not driven by WMI MAINTAINERS: - intel_telemetry: Update maintainers info - intel_pmc_core: Update MAINTAINERS - Update maintainer for dcdbas and dell_rbu - Use my infradead account exclusively for PDx86 work acerhdf: - restructure to allow large BIOS table be __initconst - mark appropriate content with __init prefix - Add BIOS entry for Gateway LT31 v1.3307 - Remove cut-and-paste trap from instructions - Enable ability to list supported systems - clarify modinfo messages for BIOS override asus-wmi: - export function for evaluating WMI methods - Only notify kbd LED hw_change by fn-key pressed - Simplify the keyboard brightness updating process firmware: - dcdbas: include linux/io.h - dcdbas: Move dcdbas to drivers/platform/x86 - dell_rbu: Move dell_rbu to drivers/platform/x86 - dcdbas: Add support for WSMT ACPI table - dell_rbu: Make payload memory uncachable ideapad-laptop: - Add Y530-15ICH to no_hw_rfkill - Use __func__ instead of read_ec_cmd in pr_err intel-hid: - Convert to use SPDX identifier intel-ips: - Convert to use SPDX identifier intel-rst: - Convert to use SPDX identifier - Sort headers alphabetically intel-smartconnect: - Convert to use SPDX identifier - Sort headers alphabetically intel-wmi-thunderbolt: - Add dynamic debugging - Convert to use SPDX identifier intel_bxtwc_tmu: - Convert to use SPDX identifier intel_cht_int33fe: - Convert to use SPDX identifier intel_chtdc_ti_pwrbtn: - Add SPDX identifier intel_int0002_vgpio: - Convert to use SPDX identifier - Implement irq_set_wake - Enable the driver on Bay Trail platforms intel_menlow: - Convert to use SPDX identifier - Sort headers alphabetically intel_mid_powerbtn: - Convert to use SPDX identifier - Remove unnecessary init.h inclusion - Get rid of custom ICPU() macro intel_mid_thermal: - Convert to use SPDX identifier - Sort headers alphabetically intel_oaktrail: - Convert to use SPDX identifier - Sort headers alphabetically intel_pmc: - Convert to use SPDX identifier - Sort headers alphabetically intel_punit_ipc: - Convert to use SPDX identifier - Sort headers alphabetically intel_scu_ipc: - Convert to use SPDX identifier - Sort headers alphabetically intel_telemetry: - Get rid of custom macro - report debugfs failure - Convert to use SPDX identifier intel_turbo_max_3: - Convert to use SPDX identifier - Sort headers alphabetically mlx-platform: - Properly use mlxplat_mlxcpld_msn201x_items touchscreen_dmi: - Add min-x and min-y settings for various models - Add info for the Onda V80 Plus v3 tablet - Add info for the Trekstor Primetab T13B tablet - Add info for the Trekstor Primebook C11 convertible tracing: - Trivia spelling fix containerof() -> container_of() wmi: - declare device_type structure as constant Andy Shevchenko (32): tracing: Trivia spelling fix containerof() -> container_of() MAINTAINERS: Use my infradead account exclusively for PDx86 work platform/x86: intel_mid_powerbtn: Get rid of custom ICPU() macro platform/x86: intel_bxtwc_tmu:
[GIT PULL] platform-drivers-x86 for 4.20-1
Hi Linus, This tag has a few merge conflicts with some x86/cpu id changes. Stephen Rothwell's merge in next/master is correct, and I have provided an example here as well: git://git.infradead.org/linux-platform-drivers-x86.git pdx86-v4.20-1-merge Thanks, Darren Hart VMware Open Source Technology Center The following changes since commit ff0e9f26288d2daee4950f42b37a3d3d30d36ec1: platform/x86: alienware-wmi: Correct a memory leak (2018-09-10 13:45:43 -0700) are available in the git repository at: git://git.infradead.org/linux-platform-drivers-x86.git tags/platform-drivers-x86-v4.20-1 for you to fetch changes up to 3b692c55e58d06ba9b17c66784cab5a95ba5be9b: HID: asus: only support backlight when it's not driven by WMI (2018-10-31 16:11:40 +0200) platform-drivers-x86 for v4.20-1 Move the Dell dcdbas and dell_rbu drivers into platform/drivers/x86 as they are closely coupled with other drivers in this location. Improve _init* usage for acerhdf and fix some usage issues with messages and module parameters. Simplify asus-wmi by calling ACPI/WMI methods directly, eliminating workqueue overhead, eliminate double reporting of keyboard backlight. Fix wake from USB failure on Bay Trail devices (intel_int0002_vgpio). Notify intel_telemetry users when IPC1 device is not enabled. Update various drivers with new laptop model IDs. Update several intel drivers to use SPDX identifers and order headers alphabetically. The following is an automated git shortlog grouped by driver: Add Intel AtomISP2 dummy / power-management driver: - Add Intel AtomISP2 dummy / power-management driver lg-laptop: - Add LG Gram laptop special features driver HID: - asus: only support backlight when it's not driven by WMI MAINTAINERS: - intel_telemetry: Update maintainers info - intel_pmc_core: Update MAINTAINERS - Update maintainer for dcdbas and dell_rbu - Use my infradead account exclusively for PDx86 work acerhdf: - restructure to allow large BIOS table be __initconst - mark appropriate content with __init prefix - Add BIOS entry for Gateway LT31 v1.3307 - Remove cut-and-paste trap from instructions - Enable ability to list supported systems - clarify modinfo messages for BIOS override asus-wmi: - export function for evaluating WMI methods - Only notify kbd LED hw_change by fn-key pressed - Simplify the keyboard brightness updating process firmware: - dcdbas: include linux/io.h - dcdbas: Move dcdbas to drivers/platform/x86 - dell_rbu: Move dell_rbu to drivers/platform/x86 - dcdbas: Add support for WSMT ACPI table - dell_rbu: Make payload memory uncachable ideapad-laptop: - Add Y530-15ICH to no_hw_rfkill - Use __func__ instead of read_ec_cmd in pr_err intel-hid: - Convert to use SPDX identifier intel-ips: - Convert to use SPDX identifier intel-rst: - Convert to use SPDX identifier - Sort headers alphabetically intel-smartconnect: - Convert to use SPDX identifier - Sort headers alphabetically intel-wmi-thunderbolt: - Add dynamic debugging - Convert to use SPDX identifier intel_bxtwc_tmu: - Convert to use SPDX identifier intel_cht_int33fe: - Convert to use SPDX identifier intel_chtdc_ti_pwrbtn: - Add SPDX identifier intel_int0002_vgpio: - Convert to use SPDX identifier - Implement irq_set_wake - Enable the driver on Bay Trail platforms intel_menlow: - Convert to use SPDX identifier - Sort headers alphabetically intel_mid_powerbtn: - Convert to use SPDX identifier - Remove unnecessary init.h inclusion - Get rid of custom ICPU() macro intel_mid_thermal: - Convert to use SPDX identifier - Sort headers alphabetically intel_oaktrail: - Convert to use SPDX identifier - Sort headers alphabetically intel_pmc: - Convert to use SPDX identifier - Sort headers alphabetically intel_punit_ipc: - Convert to use SPDX identifier - Sort headers alphabetically intel_scu_ipc: - Convert to use SPDX identifier - Sort headers alphabetically intel_telemetry: - Get rid of custom macro - report debugfs failure - Convert to use SPDX identifier intel_turbo_max_3: - Convert to use SPDX identifier - Sort headers alphabetically mlx-platform: - Properly use mlxplat_mlxcpld_msn201x_items touchscreen_dmi: - Add min-x and min-y settings for various models - Add info for the Onda V80 Plus v3 tablet - Add info for the Trekstor Primetab T13B tablet - Add info for the Trekstor Primebook C11 convertible tracing: - Trivia spelling fix containerof() -> container_of() wmi: - declare device_type structure as constant Andy Shevchenko (32): tracing: Trivia spelling fix containerof() -> container_of() MAINTAINERS: Use my infradead account exclusively for PDx86 work platform/x86: intel_mid_powerbtn: Get rid of custom ICPU() macro platform/x86: intel_bxtwc_tmu:
Re: [PATCH v6 0/1] ns: introduce binfmt_misc namespace
On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote: > Hi, > > Any comment on this last version? > > Any chance to be merged? I've got a use case for this: I went to one of the Graphene talks in Edinburgh and it struck me that we seem to keep reinventing the type of sandboxing that qemu-user already does. However if you want to do an x86 on x86 sandbox, you can't currently use the binfmt_misc mechanism because that has you running *every* binary on the system emulated. Doing it per user namespace fixes this problem and allows us to at least cut down on all the pointless duplication. James
Re: [PATCH v6 0/1] ns: introduce binfmt_misc namespace
On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote: > Hi, > > Any comment on this last version? > > Any chance to be merged? I've got a use case for this: I went to one of the Graphene talks in Edinburgh and it struck me that we seem to keep reinventing the type of sandboxing that qemu-user already does. However if you want to do an x86 on x86 sandbox, you can't currently use the binfmt_misc mechanism because that has you running *every* binary on the system emulated. Doing it per user namespace fixes this problem and allows us to at least cut down on all the pointless duplication. James
[PATCH] objtool: Support GCC 9 cold subfunction naming scheme
Starting with GCC 8, a lot of unlikely code was moved out of line to "cold" subfunctions in .text.unlikely. For example, the unlikely bits of: irq_do_set_affinity() are moved out to the following subfunction: irq_do_set_affinity.cold.49() Starting with GCC 9, the numbered suffix has been removed. So in the above example, the cold subfunction is instead: irq_do_set_affinity.cold() Tweak the objtool subfunction detection logic so that it detects both GCC 8 and GCC 9 naming schemes. Reported-and-tested-by: Peter Zijlstra (Intel) Acked-by: Peter Zijlstra (Intel) Signed-off-by: Josh Poimboeuf --- tools/objtool/elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index f7082de1ee82..6dbb9fae0f9d 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -301,7 +301,7 @@ static int read_symbols(struct elf *elf) if (sym->type != STT_FUNC) continue; sym->pfunc = sym->cfunc = sym; - coldstr = strstr(sym->name, ".cold."); + coldstr = strstr(sym->name, ".cold"); if (!coldstr) continue; -- 2.17.2
[PATCH] objtool: Support GCC 9 cold subfunction naming scheme
Starting with GCC 8, a lot of unlikely code was moved out of line to "cold" subfunctions in .text.unlikely. For example, the unlikely bits of: irq_do_set_affinity() are moved out to the following subfunction: irq_do_set_affinity.cold.49() Starting with GCC 9, the numbered suffix has been removed. So in the above example, the cold subfunction is instead: irq_do_set_affinity.cold() Tweak the objtool subfunction detection logic so that it detects both GCC 8 and GCC 9 naming schemes. Reported-and-tested-by: Peter Zijlstra (Intel) Acked-by: Peter Zijlstra (Intel) Signed-off-by: Josh Poimboeuf --- tools/objtool/elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index f7082de1ee82..6dbb9fae0f9d 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -301,7 +301,7 @@ static int read_symbols(struct elf *elf) if (sym->type != STT_FUNC) continue; sym->pfunc = sym->cfunc = sym; - coldstr = strstr(sym->name, ".cold."); + coldstr = strstr(sym->name, ".cold"); if (!coldstr) continue; -- 2.17.2
Re: linux-next: build warning in Linus' tree tree
Em Thu, 1 Nov 2018 08:28:20 +1100
Stephen Rothwell escreveu:
> Hi all,
>
> Building Linus' tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> ./usr/include/linux/v4l2-controls.h:1105: found __[us]{8,16,32,64} type
> without #include
>
> Introduced by commit
>
> c27bb30e7b6d ("media: v4l: Add definitions for MPEG-2 slice format and
> metadata")
>
Somehow, I missed this warning. I'll send soon a fix for it.
Thanks,
Mauro
Re: linux-next: build warning in Linus' tree tree
Em Thu, 1 Nov 2018 08:28:20 +1100
Stephen Rothwell escreveu:
> Hi all,
>
> Building Linus' tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> ./usr/include/linux/v4l2-controls.h:1105: found __[us]{8,16,32,64} type
> without #include
>
> Introduced by commit
>
> c27bb30e7b6d ("media: v4l: Add definitions for MPEG-2 slice format and
> metadata")
>
Somehow, I missed this warning. I'll send soon a fix for it.
Thanks,
Mauro
[PATCH -next] firewire: net: remove set but not used variable 'guid'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/firewire/net.c:488:9: warning:
variable ‘guid’ set but not used [-Wunused-but-set-variable]
It not used anymore after commit 6752c8db8e0c ("firewire net, ipv4 arp:
Extend hardware address and remove driver-level packet inspection.")
Signed-off-by: YueHaibing
---
drivers/firewire/net.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 82ba110..5dcb991 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -485,7 +485,6 @@ static int fwnet_finish_incoming_packet(struct net_device
*net,
{
struct fwnet_device *dev;
int status;
- __be64 guid;
switch (ether_type) {
case ETH_P_ARP:
@@ -507,7 +506,6 @@ static int fwnet_finish_incoming_packet(struct net_device
*net,
* Parse the encapsulation header. This actually does the job of
* converting to an ethernet-like pseudo frame header.
*/
- guid = cpu_to_be64(dev->card->guid);
if (dev_hard_header(skb, net, ether_type,
is_broadcast ? net->broadcast : net->dev_addr,
NULL, skb->len) >= 0) {
--
2.7.0
[PATCH -next] firewire: net: remove set but not used variable 'guid'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/firewire/net.c:488:9: warning:
variable ‘guid’ set but not used [-Wunused-but-set-variable]
It not used anymore after commit 6752c8db8e0c ("firewire net, ipv4 arp:
Extend hardware address and remove driver-level packet inspection.")
Signed-off-by: YueHaibing
---
drivers/firewire/net.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 82ba110..5dcb991 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -485,7 +485,6 @@ static int fwnet_finish_incoming_packet(struct net_device
*net,
{
struct fwnet_device *dev;
int status;
- __be64 guid;
switch (ether_type) {
case ETH_P_ARP:
@@ -507,7 +506,6 @@ static int fwnet_finish_incoming_packet(struct net_device
*net,
* Parse the encapsulation header. This actually does the job of
* converting to an ethernet-like pseudo frame header.
*/
- guid = cpu_to_be64(dev->card->guid);
if (dev_hard_header(skb, net, ether_type,
is_broadcast ? net->broadcast : net->dev_addr,
NULL, skb->len) >= 0) {
--
2.7.0
[PATCH -next] edac: i82975x: remove set but not used variable 'dtype'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/edac/i82975x_edac.c:378:16: warning:
variable ‘dtype’ set but not used [-Wunused-but-set-variable]
It never used since introduction in commit
084a4fccef39 ("edac: move dimm properties to struct dimm_info")
Signed-off-by: YueHaibing
---
drivers/edac/i82975x_edac.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/edac/i82975x_edac.c b/drivers/edac/i82975x_edac.c
index 892815e..ae0d8fa 100644
--- a/drivers/edac/i82975x_edac.c
+++ b/drivers/edac/i82975x_edac.c
@@ -375,7 +375,6 @@ static void i82975x_init_csrows(struct mem_ctl_info *mci,
u32 cumul_size, nr_pages;
int index, chan;
struct dimm_info *dimm;
- enum dev_type dtype;
last_cumul_size = 0;
@@ -413,7 +412,6 @@ static void i82975x_init_csrows(struct mem_ctl_info *mci,
* [0-7] for single-channel; i.e. csrow->nr_channels = 1
* [0-3] for dual-channel; i.e. csrow->nr_channels = 2
*/
- dtype = i82975x_dram_type(mch_window, index);
for (chan = 0; chan < csrow->nr_channels; chan++) {
dimm = mci->csrows[index]->channels[chan]->dimm;
--
2.7.0
[PATCH -next] edac: i82975x: remove set but not used variable 'dtype'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/edac/i82975x_edac.c:378:16: warning:
variable ‘dtype’ set but not used [-Wunused-but-set-variable]
It never used since introduction in commit
084a4fccef39 ("edac: move dimm properties to struct dimm_info")
Signed-off-by: YueHaibing
---
drivers/edac/i82975x_edac.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/edac/i82975x_edac.c b/drivers/edac/i82975x_edac.c
index 892815e..ae0d8fa 100644
--- a/drivers/edac/i82975x_edac.c
+++ b/drivers/edac/i82975x_edac.c
@@ -375,7 +375,6 @@ static void i82975x_init_csrows(struct mem_ctl_info *mci,
u32 cumul_size, nr_pages;
int index, chan;
struct dimm_info *dimm;
- enum dev_type dtype;
last_cumul_size = 0;
@@ -413,7 +412,6 @@ static void i82975x_init_csrows(struct mem_ctl_info *mci,
* [0-7] for single-channel; i.e. csrow->nr_channels = 1
* [0-3] for dual-channel; i.e. csrow->nr_channels = 2
*/
- dtype = i82975x_dram_type(mch_window, index);
for (chan = 0; chan < csrow->nr_channels; chan++) {
dimm = mci->csrows[index]->channels[chan]->dimm;
--
2.7.0
make[3]: *** No rule to make target 'arch/mips/boot/dts/brcm/bcm93384wvg.dtb', needed by '__build'.
Hi Rob, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5b7449810ae6d652629c550d3974c8453836d229 commit: 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 kbuild: consolidate Devicetree dtb build rules date: 4 weeks ago config: mips-gpr_defconfig (attached as .config) compiler: mipsel-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=mips All errors (new ones prefixed by >>): >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm93384wvg.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm93384wvg_viper.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm96368mvwg.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm9ejtagprb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97125cbmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97346dbsmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97358svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97360svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97362svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target 'arch/mips/boot/dts/brcm/bcm97420c.dtb', >> needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97425svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97435svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm63268-comtrend-vr-3032u.dtb', needed by >> '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm3368-netgear-cvg834g.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm6358-neufbox4-sercomm.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm6362-neufbox6-sercomm.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/cavium-octeon/octeon_68xx.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target 'arch/mips/boot/dts/img/boston.dtb', >> needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/img/pistachio_marduk.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/ingenic/qi_lb60.dtb', needed by '__build'. >> make[3]: *** No rule to make target 'arch/mips/boot/dts/ingenic/gcw0.dtb', >> needed by '__build'. >> make[3]: *** No rule to make target 'arch/mips/boot/dts/ingenic/ci20.dtb', >> needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/lantiq/easy50712.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/mscc/ocelot_pcb123.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target 'arch/mips/boot/dts/mti/malta.dtb', >> needed by '__build'. >> make[3]: *** No rule to make target 'arch/mips/boot/dts/mti/sead3.dtb', >> needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_evp.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_svp.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_fvp.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_gvp.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_rvp.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target 'arch/mips/boot/dts/ni/169445.dtb', >> needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/pic32/pic32mzda_sk.dtb',
make[3]: *** No rule to make target 'arch/mips/boot/dts/brcm/bcm93384wvg.dtb', needed by '__build'.
Hi Rob, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5b7449810ae6d652629c550d3974c8453836d229 commit: 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 kbuild: consolidate Devicetree dtb build rules date: 4 weeks ago config: mips-gpr_defconfig (attached as .config) compiler: mipsel-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=mips All errors (new ones prefixed by >>): >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm93384wvg.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm93384wvg_viper.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm96368mvwg.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm9ejtagprb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97125cbmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97346dbsmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97358svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97360svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97362svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target 'arch/mips/boot/dts/brcm/bcm97420c.dtb', >> needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97425svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm97435svmb.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm63268-comtrend-vr-3032u.dtb', needed by >> '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm3368-netgear-cvg834g.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm6358-neufbox4-sercomm.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/brcm/bcm6362-neufbox6-sercomm.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/cavium-octeon/octeon_68xx.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target 'arch/mips/boot/dts/img/boston.dtb', >> needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/img/pistachio_marduk.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/ingenic/qi_lb60.dtb', needed by '__build'. >> make[3]: *** No rule to make target 'arch/mips/boot/dts/ingenic/gcw0.dtb', >> needed by '__build'. >> make[3]: *** No rule to make target 'arch/mips/boot/dts/ingenic/ci20.dtb', >> needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/lantiq/easy50712.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/mscc/ocelot_pcb123.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target 'arch/mips/boot/dts/mti/malta.dtb', >> needed by '__build'. >> make[3]: *** No rule to make target 'arch/mips/boot/dts/mti/sead3.dtb', >> needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_evp.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_svp.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_fvp.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_gvp.dtb', needed by '__build'. >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/netlogic/xlp_rvp.dtb', needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target 'arch/mips/boot/dts/ni/169445.dtb', >> needed by '__build'. make[3]: Target '__build' not remade because of errors. -- >> make[3]: *** No rule to make target >> 'arch/mips/boot/dts/pic32/pic32mzda_sk.dtb',
Re: [patch 8/9] posix-clocks: Remove license boiler plate
On Wed, Oct 31, 2018 at 07:21:15PM +0100, Thomas Gleixner wrote: > The SPDX identifier defines the license of the file already. No need for > the boilerplate. > > Signed-off-by: Thomas Gleixner > Cc: Richard Cochran > --- > > @Richard: This file is (C) OMICRON, but I don't have a contact > anymore. That Cochran dude is not longer working there :) > > Do you have a contact? If so, can you please reply to this mail and Cc > him/her. @Cristian and Manfred: We want to replace the license boilerplate with SPDX tags. The file, kernel/time/posix-clock.c, is copyrighted by omicron, and so we need your okay. All that is needed is a reply to this email with an omicron Acked-by tag, like this: Acked-by: Richard Cochran Thanks, Richard > > --- > kernel/time/posix-clock.c | 14 -- > 1 file changed, 14 deletions(-) > > --- a/kernel/time/posix-clock.c > +++ b/kernel/time/posix-clock.c > @@ -3,20 +3,6 @@ > * Support for dynamic clock devices > * > * Copyright (C) 2010 OMICRON electronics GmbH > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > */ > #include > #include > >
Re: [patch 8/9] posix-clocks: Remove license boiler plate
On Wed, Oct 31, 2018 at 07:21:15PM +0100, Thomas Gleixner wrote: > The SPDX identifier defines the license of the file already. No need for > the boilerplate. > > Signed-off-by: Thomas Gleixner > Cc: Richard Cochran > --- > > @Richard: This file is (C) OMICRON, but I don't have a contact > anymore. That Cochran dude is not longer working there :) > > Do you have a contact? If so, can you please reply to this mail and Cc > him/her. @Cristian and Manfred: We want to replace the license boilerplate with SPDX tags. The file, kernel/time/posix-clock.c, is copyrighted by omicron, and so we need your okay. All that is needed is a reply to this email with an omicron Acked-by tag, like this: Acked-by: Richard Cochran Thanks, Richard > > --- > kernel/time/posix-clock.c | 14 -- > 1 file changed, 14 deletions(-) > > --- a/kernel/time/posix-clock.c > +++ b/kernel/time/posix-clock.c > @@ -3,20 +3,6 @@ > * Support for dynamic clock devices > * > * Copyright (C) 2010 OMICRON electronics GmbH > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > */ > #include > #include > >
Re: [PATCH 3/3] kprobes/x86: Simplify indirect-jump check in retpoline
On 2018/10/31 22:00, Peter Zijlstra wrote: On Wed, Oct 31, 2018 at 02:53:20PM +0100, Peter Zijlstra wrote: On Wed, Oct 31, 2018 at 02:01:20PM +0800, Zhenzhong Duan wrote: On 2018/10/30 16:36, Peter Zijlstra wrote: On Mon, Oct 29, 2018 at 11:55:06PM -0700, Zhenzhong Duan wrote: Since CONFIG_RETPOLINE hard depends on compiler support now, so replacing indirect-jump check with the range check is safe in that case. Can we put kprobes on module init text before we run alternatives on it? Forgive me I doesn't understand your question. Do you mean this patch impact kprobes on module init text? In that case we would still see the indirect paravirt calls for example, and we'd still need that cascade you took out. Understood. In another case when loading a non-retpoline module, we suffer the same. Now, I'm not at all sure we're able to use kprobes at those times, so it might be a non-issue. Not sure, but if it's possible then alternative patching may cover the kprobes, it looks like a bug. Hmm, what about the case where we have RETPOLINE runtime disabled? Then the CALL_NOSPEC alternative patches in an indirect call again, and the retpolines are gone. Is RETPOLINE runtime toggle supported in upstream? I don't see such code. Does that not need the __insn_is_indirect_jump() thing? Yes it's needed if RETPOLINE runtime disabled. Based on all above reasons, I'd like to drop this patch. Thanks Zhenzhong
Re: [PATCH 3/3] kprobes/x86: Simplify indirect-jump check in retpoline
On 2018/10/31 22:00, Peter Zijlstra wrote: On Wed, Oct 31, 2018 at 02:53:20PM +0100, Peter Zijlstra wrote: On Wed, Oct 31, 2018 at 02:01:20PM +0800, Zhenzhong Duan wrote: On 2018/10/30 16:36, Peter Zijlstra wrote: On Mon, Oct 29, 2018 at 11:55:06PM -0700, Zhenzhong Duan wrote: Since CONFIG_RETPOLINE hard depends on compiler support now, so replacing indirect-jump check with the range check is safe in that case. Can we put kprobes on module init text before we run alternatives on it? Forgive me I doesn't understand your question. Do you mean this patch impact kprobes on module init text? In that case we would still see the indirect paravirt calls for example, and we'd still need that cascade you took out. Understood. In another case when loading a non-retpoline module, we suffer the same. Now, I'm not at all sure we're able to use kprobes at those times, so it might be a non-issue. Not sure, but if it's possible then alternative patching may cover the kprobes, it looks like a bug. Hmm, what about the case where we have RETPOLINE runtime disabled? Then the CALL_NOSPEC alternative patches in an indirect call again, and the retpolines are gone. Is RETPOLINE runtime toggle supported in upstream? I don't see such code. Does that not need the __insn_is_indirect_jump() thing? Yes it's needed if RETPOLINE runtime disabled. Based on all above reasons, I'd like to drop this patch. Thanks Zhenzhong
[PATCH v1 2/3] clk: tegra: ignore unused vfir clock shared with uartb
From: Marcel Ziswiler
As UARTB and VFIR share their clock enable bit it is rather unwise for
the kernel to turn off the VFIR one should that be unused (and
potentially vice versa but so far there anyway is no VFIR driver).
Without this patch trying to use UARTB with the regular 8250 driver
will freeze as soon as ttyS1 is accessed after boot. Luckily, using the
high-speed Tegra serial driver won't exhibit the issue as clocks are
dynamically enabled/disabled on every access.
This has been reproduced both on Apalis T30 as well as Apalis TK1 but
may be an issue on all Tegra UARTB's which share the clock enable with
VFIR.
Reported-by: Kory Swain
Signed-off-by: Marcel Ziswiler
---
drivers/clk/tegra/clk-tegra-periph.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/tegra/clk-tegra-periph.c
b/drivers/clk/tegra/clk-tegra-periph.c
index cc5275ec2c01..116c74340fb7 100644
--- a/drivers/clk/tegra/clk-tegra-periph.c
+++ b/drivers/clk/tegra/clk-tegra-periph.c
@@ -668,7 +668,7 @@ static struct tegra_periph_init_data periph_clks[] = {
MUX("hda", mux_pllp_pllc_clkm, CLK_SOURCE_HDA, 125,
TEGRA_PERIPH_ON_APB, tegra_clk_hda_8),
MUX("hda2codec_2x", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_HDA2CODEC_2X,
111, TEGRA_PERIPH_ON_APB, tegra_clk_hda2codec_2x),
MUX8("hda2codec_2x", mux_pllp_pllc_plla_clkm, CLK_SOURCE_HDA2CODEC_2X,
111, TEGRA_PERIPH_ON_APB, tegra_clk_hda2codec_2x_8),
- MUX("vfir", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_VFIR, 7,
TEGRA_PERIPH_ON_APB, tegra_clk_vfir),
+ MUX_FLAGS("vfir", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_VFIR, 7,
TEGRA_PERIPH_ON_APB, tegra_clk_vfir, CLK_IGNORE_UNUSED),
MUX("sdmmc1", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC1, 14,
TEGRA_PERIPH_ON_APB, tegra_clk_sdmmc1),
MUX("sdmmc2", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC2, 9,
TEGRA_PERIPH_ON_APB, tegra_clk_sdmmc2),
MUX("sdmmc3", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC3, 69,
TEGRA_PERIPH_ON_APB, tegra_clk_sdmmc3),
--
2.14.5
[PATCH v1 3/3] serial: tegra: fix some spelling mistakes
From: Marcel Ziswiler Fix a few spelling mistakes I stumbled upon while debugging a customers UART issues. Signed-off-by: Marcel Ziswiler --- drivers/tty/serial/serial-tegra.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/tty/serial/serial-tegra.c b/drivers/tty/serial/serial-tegra.c index af2a29cfbbe9..d5269aaaf9b2 100644 --- a/drivers/tty/serial/serial-tegra.c +++ b/drivers/tty/serial/serial-tegra.c @@ -746,7 +746,7 @@ static void tegra_uart_stop_rx(struct uart_port *u) if (!tup->rx_in_progress) return; - tegra_uart_wait_sym_time(tup, 1); /* wait a character interval */ + tegra_uart_wait_sym_time(tup, 1); /* wait one character interval */ ier = tup->ier_shadow; ier &= ~(UART_IER_RDI | UART_IER_RLSI | UART_IER_RTOIE | @@ -887,7 +887,7 @@ static int tegra_uart_hw_init(struct tegra_uart_port *tup) * * EORD is different interrupt than RX_TIMEOUT - RX_TIMEOUT occurs when * the DATA is sitting in the FIFO and couldn't be transferred to the -* DMA as the DMA size alignment(4 bytes) is not met. EORD will be +* DMA as the DMA size alignment (4 bytes) is not met. EORD will be * triggered when there is a pause of the incomming data stream for 4 * characters long. * @@ -1079,7 +1079,7 @@ static void tegra_uart_set_termios(struct uart_port *u, if (tup->rts_active) set_rts(tup, false); - /* Clear all interrupts as configuration is going to be change */ + /* Clear all interrupts as configuration is going to be changed */ tegra_uart_write(tup, tup->ier_shadow | UART_IER_RDI, UART_IER); tegra_uart_read(tup, UART_IER); tegra_uart_write(tup, 0, UART_IER); @@ -1165,10 +1165,10 @@ static void tegra_uart_set_termios(struct uart_port *u, /* update the port timeout based on new settings */ uart_update_timeout(u, termios->c_cflag, baud); - /* Make sure all write has completed */ + /* Make sure all writes have completed */ tegra_uart_read(tup, UART_IER); - /* Reenable interrupt */ + /* Re-enable interrupt */ tegra_uart_write(tup, tup->ier_shadow, UART_IER); tegra_uart_read(tup, UART_IER); -- 2.14.5
[PATCH v1 1/3] clk: tegra: get rid of duplicate defines
From: Marcel Ziswiler Get rid of 3 duplicate defines. Signed-off-by: Marcel Ziswiler --- drivers/clk/tegra/clk-tegra-periph.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/clk/tegra/clk-tegra-periph.c b/drivers/clk/tegra/clk-tegra-periph.c index 38c4eb28c8bf..cc5275ec2c01 100644 --- a/drivers/clk/tegra/clk-tegra-periph.c +++ b/drivers/clk/tegra/clk-tegra-periph.c @@ -79,7 +79,6 @@ #define CLK_SOURCE_3D 0x158 #define CLK_SOURCE_2D 0x15c #define CLK_SOURCE_MPE 0x170 -#define CLK_SOURCE_UARTE 0x1c4 #define CLK_SOURCE_VI_SENSOR 0x1a8 #define CLK_SOURCE_VI 0x148 #define CLK_SOURCE_EPP 0x16c @@ -117,8 +116,6 @@ #define CLK_SOURCE_ISP 0x144 #define CLK_SOURCE_SOR0 0x414 #define CLK_SOURCE_DPAUX 0x418 -#define CLK_SOURCE_SATA_OOB 0x420 -#define CLK_SOURCE_SATA 0x424 #define CLK_SOURCE_ENTROPY 0x628 #define CLK_SOURCE_VI_SENSOR2 0x658 #define CLK_SOURCE_HDMI_AUDIO 0x668 -- 2.14.5
[PATCH v1 2/3] clk: tegra: ignore unused vfir clock shared with uartb
From: Marcel Ziswiler
As UARTB and VFIR share their clock enable bit it is rather unwise for
the kernel to turn off the VFIR one should that be unused (and
potentially vice versa but so far there anyway is no VFIR driver).
Without this patch trying to use UARTB with the regular 8250 driver
will freeze as soon as ttyS1 is accessed after boot. Luckily, using the
high-speed Tegra serial driver won't exhibit the issue as clocks are
dynamically enabled/disabled on every access.
This has been reproduced both on Apalis T30 as well as Apalis TK1 but
may be an issue on all Tegra UARTB's which share the clock enable with
VFIR.
Reported-by: Kory Swain
Signed-off-by: Marcel Ziswiler
---
drivers/clk/tegra/clk-tegra-periph.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/tegra/clk-tegra-periph.c
b/drivers/clk/tegra/clk-tegra-periph.c
index cc5275ec2c01..116c74340fb7 100644
--- a/drivers/clk/tegra/clk-tegra-periph.c
+++ b/drivers/clk/tegra/clk-tegra-periph.c
@@ -668,7 +668,7 @@ static struct tegra_periph_init_data periph_clks[] = {
MUX("hda", mux_pllp_pllc_clkm, CLK_SOURCE_HDA, 125,
TEGRA_PERIPH_ON_APB, tegra_clk_hda_8),
MUX("hda2codec_2x", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_HDA2CODEC_2X,
111, TEGRA_PERIPH_ON_APB, tegra_clk_hda2codec_2x),
MUX8("hda2codec_2x", mux_pllp_pllc_plla_clkm, CLK_SOURCE_HDA2CODEC_2X,
111, TEGRA_PERIPH_ON_APB, tegra_clk_hda2codec_2x_8),
- MUX("vfir", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_VFIR, 7,
TEGRA_PERIPH_ON_APB, tegra_clk_vfir),
+ MUX_FLAGS("vfir", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_VFIR, 7,
TEGRA_PERIPH_ON_APB, tegra_clk_vfir, CLK_IGNORE_UNUSED),
MUX("sdmmc1", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC1, 14,
TEGRA_PERIPH_ON_APB, tegra_clk_sdmmc1),
MUX("sdmmc2", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC2, 9,
TEGRA_PERIPH_ON_APB, tegra_clk_sdmmc2),
MUX("sdmmc3", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_SDMMC3, 69,
TEGRA_PERIPH_ON_APB, tegra_clk_sdmmc3),
--
2.14.5
[PATCH v1 3/3] serial: tegra: fix some spelling mistakes
From: Marcel Ziswiler Fix a few spelling mistakes I stumbled upon while debugging a customers UART issues. Signed-off-by: Marcel Ziswiler --- drivers/tty/serial/serial-tegra.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/tty/serial/serial-tegra.c b/drivers/tty/serial/serial-tegra.c index af2a29cfbbe9..d5269aaaf9b2 100644 --- a/drivers/tty/serial/serial-tegra.c +++ b/drivers/tty/serial/serial-tegra.c @@ -746,7 +746,7 @@ static void tegra_uart_stop_rx(struct uart_port *u) if (!tup->rx_in_progress) return; - tegra_uart_wait_sym_time(tup, 1); /* wait a character interval */ + tegra_uart_wait_sym_time(tup, 1); /* wait one character interval */ ier = tup->ier_shadow; ier &= ~(UART_IER_RDI | UART_IER_RLSI | UART_IER_RTOIE | @@ -887,7 +887,7 @@ static int tegra_uart_hw_init(struct tegra_uart_port *tup) * * EORD is different interrupt than RX_TIMEOUT - RX_TIMEOUT occurs when * the DATA is sitting in the FIFO and couldn't be transferred to the -* DMA as the DMA size alignment(4 bytes) is not met. EORD will be +* DMA as the DMA size alignment (4 bytes) is not met. EORD will be * triggered when there is a pause of the incomming data stream for 4 * characters long. * @@ -1079,7 +1079,7 @@ static void tegra_uart_set_termios(struct uart_port *u, if (tup->rts_active) set_rts(tup, false); - /* Clear all interrupts as configuration is going to be change */ + /* Clear all interrupts as configuration is going to be changed */ tegra_uart_write(tup, tup->ier_shadow | UART_IER_RDI, UART_IER); tegra_uart_read(tup, UART_IER); tegra_uart_write(tup, 0, UART_IER); @@ -1165,10 +1165,10 @@ static void tegra_uart_set_termios(struct uart_port *u, /* update the port timeout based on new settings */ uart_update_timeout(u, termios->c_cflag, baud); - /* Make sure all write has completed */ + /* Make sure all writes have completed */ tegra_uart_read(tup, UART_IER); - /* Reenable interrupt */ + /* Re-enable interrupt */ tegra_uart_write(tup, tup->ier_shadow, UART_IER); tegra_uart_read(tup, UART_IER); -- 2.14.5
[PATCH v1 1/3] clk: tegra: get rid of duplicate defines
From: Marcel Ziswiler Get rid of 3 duplicate defines. Signed-off-by: Marcel Ziswiler --- drivers/clk/tegra/clk-tegra-periph.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/clk/tegra/clk-tegra-periph.c b/drivers/clk/tegra/clk-tegra-periph.c index 38c4eb28c8bf..cc5275ec2c01 100644 --- a/drivers/clk/tegra/clk-tegra-periph.c +++ b/drivers/clk/tegra/clk-tegra-periph.c @@ -79,7 +79,6 @@ #define CLK_SOURCE_3D 0x158 #define CLK_SOURCE_2D 0x15c #define CLK_SOURCE_MPE 0x170 -#define CLK_SOURCE_UARTE 0x1c4 #define CLK_SOURCE_VI_SENSOR 0x1a8 #define CLK_SOURCE_VI 0x148 #define CLK_SOURCE_EPP 0x16c @@ -117,8 +116,6 @@ #define CLK_SOURCE_ISP 0x144 #define CLK_SOURCE_SOR0 0x414 #define CLK_SOURCE_DPAUX 0x418 -#define CLK_SOURCE_SATA_OOB 0x420 -#define CLK_SOURCE_SATA 0x424 #define CLK_SOURCE_ENTROPY 0x628 #define CLK_SOURCE_VI_SENSOR2 0x658 #define CLK_SOURCE_HDMI_AUDIO 0x668 -- 2.14.5
[PATCH v1 0/3] clk/serial tegra: uart related fixes
This series features some UART related clock issue fix and clean-up. Marcel Ziswiler (3): clk: tegra: get rid of duplicate defines clk: tegra: ignore unused vfir clock shared with uartb serial: tegra: fix some spelling mistakes drivers/clk/tegra/clk-tegra-periph.c | 5 + drivers/tty/serial/serial-tegra.c| 10 +- 2 files changed, 6 insertions(+), 9 deletions(-) -- 2.14.5
[PATCH v1 0/3] clk/serial tegra: uart related fixes
This series features some UART related clock issue fix and clean-up. Marcel Ziswiler (3): clk: tegra: get rid of duplicate defines clk: tegra: ignore unused vfir clock shared with uartb serial: tegra: fix some spelling mistakes drivers/clk/tegra/clk-tegra-periph.c | 5 + drivers/tty/serial/serial-tegra.c| 10 +- 2 files changed, 6 insertions(+), 9 deletions(-) -- 2.14.5
Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers
On (10/31/18 13:27), Petr Mladek wrote: > > > > Signed-off-by: Sergey Senozhatsky > > The patch makes sense to me. The locks should stay busted also for > console_flush_on_panic(). > > With the added #include : > > Reviewed-by: Petr Mladek Thanks! Since there are no objections - how shall we route it? Via printk tree? I'd also prefer this patch to be in -stable, it fixes a real issue after all. -ss
Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers
On (10/31/18 13:27), Petr Mladek wrote: > > > > Signed-off-by: Sergey Senozhatsky > > The patch makes sense to me. The locks should stay busted also for > console_flush_on_panic(). > > With the added #include : > > Reviewed-by: Petr Mladek Thanks! Since there are no objections - how shall we route it? Via printk tree? I'd also prefer this patch to be in -stable, it fixes a real issue after all. -ss
[GIT] Sparc
Two small fixes, please pull. Thanks! The following changes since commit 4b42745211af552f170f38a1b97f4a112b5da6b2: Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-10-29 15:37:33 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git for you to fetch changes up to 1f2b5b8e2df4591fbca430aff9c5a072dcc0f408: sparc64: Wire up compat getpeername and getsockname. (2018-10-31 18:30:21 -0700) David S. Miller (2): sparc64: Remvoe set_fs() from perf_callchain_user(). sparc64: Wire up compat getpeername and getsockname. arch/sparc/kernel/perf_event.c | 5 - arch/sparc/kernel/systbls_64.S | 4 ++-- 2 files changed, 2 insertions(+), 7 deletions(-)
Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup
CC Philip, current kbuild test robot maintainer. On Wed, Oct 31, 2018 at 12:12:21PM -0600, Logan Gunthorpe wrote: On 2018-10-31 11:52 a.m., Olof Johansson wrote: I've migrated machines to a new system and that CI is up and running. Right now the emails don't go anywhere but me, but let me know where you want them sent and I'll be happy to do so (probably not linux-riscv due to volume/noise). They're also uploaded to http://arm-soc.lixom.net/buildlogs/riscv/. Since you keep single-patch branches in your tree, and I compile everything for every branch, I've restricted what branches I poll and build. Right now it's "for*" and "riscv*". I think it would also be very nice to get the existing kbuild test robot to start compile testing a few riscv configs. It already does most of the other arches. This would help us catch these kinds of issues even earlier seeing that test robot tests patches on mailing lists and many other repos before Palmer would even pull them into his branch. (Including a repo I routinely push branches to before sending out patches.) I'm not sure who's currently responsible for the robot but I've copied Fenguang who, I believe, set it up originally as well as the kbuild lists. Hopefully he can point us in the right direction to help get this set up. Thanks, Logan
[GIT] Sparc
Two small fixes, please pull. Thanks! The following changes since commit 4b42745211af552f170f38a1b97f4a112b5da6b2: Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-10-29 15:37:33 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git for you to fetch changes up to 1f2b5b8e2df4591fbca430aff9c5a072dcc0f408: sparc64: Wire up compat getpeername and getsockname. (2018-10-31 18:30:21 -0700) David S. Miller (2): sparc64: Remvoe set_fs() from perf_callchain_user(). sparc64: Wire up compat getpeername and getsockname. arch/sparc/kernel/perf_event.c | 5 - arch/sparc/kernel/systbls_64.S | 4 ++-- 2 files changed, 2 insertions(+), 7 deletions(-)
Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup
CC Philip, current kbuild test robot maintainer. On Wed, Oct 31, 2018 at 12:12:21PM -0600, Logan Gunthorpe wrote: On 2018-10-31 11:52 a.m., Olof Johansson wrote: I've migrated machines to a new system and that CI is up and running. Right now the emails don't go anywhere but me, but let me know where you want them sent and I'll be happy to do so (probably not linux-riscv due to volume/noise). They're also uploaded to http://arm-soc.lixom.net/buildlogs/riscv/. Since you keep single-patch branches in your tree, and I compile everything for every branch, I've restricted what branches I poll and build. Right now it's "for*" and "riscv*". I think it would also be very nice to get the existing kbuild test robot to start compile testing a few riscv configs. It already does most of the other arches. This would help us catch these kinds of issues even earlier seeing that test robot tests patches on mailing lists and many other repos before Palmer would even pull them into his branch. (Including a repo I routinely push branches to before sending out patches.) I'm not sure who's currently responsible for the robot but I've copied Fenguang who, I believe, set it up originally as well as the kbuild lists. Hopefully he can point us in the right direction to help get this set up. Thanks, Logan
Re: [Patch v4 3/3] CIFS: Add direct I/O functions to file_operations
made minor cleanup to patch 1 and 2, added Ronnie's reviewed to patch
3, and tentatively merged to cifs-2.6.git for-next
On Wed, Oct 31, 2018 at 5:16 PM Long Li wrote:
>
> From: Long Li
>
> With direct read/write functions implemented, add them to file_operations.
>
> Dircet I/O is used under two conditions:
> 1. When mounting with "cache=none", CIFS uses direct I/O for all user file
> data transfer.
> 2. When opening a file with O_DIRECT, CIFS uses direct I/O for all data
> transfer on this file.
>
> Signed-off-by: Long Li
> ---
> fs/cifs/cifsfs.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> index 62f1662..f18091b 100644
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -1113,9 +1113,8 @@ const struct file_operations cifs_file_strict_ops = {
> };
>
> const struct file_operations cifs_file_direct_ops = {
> - /* BB reevaluate whether they can be done with directio, no cache */
> - .read_iter = cifs_user_readv,
> - .write_iter = cifs_user_writev,
> + .read_iter = cifs_direct_readv,
> + .write_iter = cifs_direct_writev,
> .open = cifs_open,
> .release = cifs_close,
> .lock = cifs_lock,
> @@ -1169,9 +1168,8 @@ const struct file_operations cifs_file_strict_nobrl_ops
> = {
> };
>
> const struct file_operations cifs_file_direct_nobrl_ops = {
> - /* BB reevaluate whether they can be done with directio, no cache */
> - .read_iter = cifs_user_readv,
> - .write_iter = cifs_user_writev,
> + .read_iter = cifs_direct_readv,
> + .write_iter = cifs_direct_writev,
> .open = cifs_open,
> .release = cifs_close,
> .fsync = cifs_fsync,
> --
> 2.7.4
>
--
Thanks,
Steve
Re: [Patch v4 3/3] CIFS: Add direct I/O functions to file_operations
made minor cleanup to patch 1 and 2, added Ronnie's reviewed to patch
3, and tentatively merged to cifs-2.6.git for-next
On Wed, Oct 31, 2018 at 5:16 PM Long Li wrote:
>
> From: Long Li
>
> With direct read/write functions implemented, add them to file_operations.
>
> Dircet I/O is used under two conditions:
> 1. When mounting with "cache=none", CIFS uses direct I/O for all user file
> data transfer.
> 2. When opening a file with O_DIRECT, CIFS uses direct I/O for all data
> transfer on this file.
>
> Signed-off-by: Long Li
> ---
> fs/cifs/cifsfs.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> index 62f1662..f18091b 100644
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -1113,9 +1113,8 @@ const struct file_operations cifs_file_strict_ops = {
> };
>
> const struct file_operations cifs_file_direct_ops = {
> - /* BB reevaluate whether they can be done with directio, no cache */
> - .read_iter = cifs_user_readv,
> - .write_iter = cifs_user_writev,
> + .read_iter = cifs_direct_readv,
> + .write_iter = cifs_direct_writev,
> .open = cifs_open,
> .release = cifs_close,
> .lock = cifs_lock,
> @@ -1169,9 +1168,8 @@ const struct file_operations cifs_file_strict_nobrl_ops
> = {
> };
>
> const struct file_operations cifs_file_direct_nobrl_ops = {
> - /* BB reevaluate whether they can be done with directio, no cache */
> - .read_iter = cifs_user_readv,
> - .write_iter = cifs_user_writev,
> + .read_iter = cifs_direct_readv,
> + .write_iter = cifs_direct_writev,
> .open = cifs_open,
> .release = cifs_close,
> .fsync = cifs_fsync,
> --
> 2.7.4
>
--
Thanks,
Steve
Re: [PATCH AUTOSEL 3.18 22/22] mfd: menelaus: Fix possible race condition and leak
On Thu, Nov 01, 2018 at 01:27:08AM +0100, Alexandre Belloni wrote:
Hello,
On 31/10/2018 19:12:06-0400, Sasha Levin wrote:
- m->rtc = rtc_device_register(DRIVER_NAME,
- >client->dev,
- _rtc_ops, THIS_MODULE);
- if (IS_ERR(m->rtc)) {
+ err = rtc_register_device(m->rtc);
This appeared in v4.13, this will not compile on v3.18.
Indeed, I guess I need more cross-compilers here. Thanks!
--
Thanks,
Sasha
Re: [PATCH AUTOSEL 3.18 22/22] mfd: menelaus: Fix possible race condition and leak
On Thu, Nov 01, 2018 at 01:27:08AM +0100, Alexandre Belloni wrote:
Hello,
On 31/10/2018 19:12:06-0400, Sasha Levin wrote:
- m->rtc = rtc_device_register(DRIVER_NAME,
- >client->dev,
- _rtc_ops, THIS_MODULE);
- if (IS_ERR(m->rtc)) {
+ err = rtc_register_device(m->rtc);
This appeared in v4.13, this will not compile on v3.18.
Indeed, I guess I need more cross-compilers here. Thanks!
--
Thanks,
Sasha
Randomize address space after each fork
Randomize address space after each fork ~~ I might be entirely wrong with what I write and the solution proposed thereafter, yet I want to raise awareness that with current linux kernels it is possible to leak (at least) heap addresses in an attempt to weaken address space layout randomization. The listed example shows [1] code, it completely identifies three bytes of the heap memory mappings, that is enough to weaken aslr in a way to make it unusable over time. One idea is to disallow a process to use the same addresses after a fork and randomize them after each fork just as during execution stage, this will render the attack unusable. I know this sounds nuts but is most probably the most straightforward way to fix the issue. real mapping: 55b118238000-55b11827b000 rw-p [heap] linux kernel leaking the addresses partial: Discover first byte in offset Try Offsets 10 to ff ... Try Offsets 20 to ff ... Offset 239000 Survived ... Offset 24d000 Survived ... Offset 251000 Survived ... Offset 261000 Survived ... Offset 27d000 Survived ... Offset 281000 Survived ... That's quite exact the heap start to end address. My apologies for suggesting only the solution, I'm too stupid to implement this in real life in, i.e. linux itself :) [1] testcase: https://www.exploit-db.com/exploits/45671/ (referring to version 4.4.0-116, x86_64) Have a nice day!
Randomize address space after each fork
Randomize address space after each fork ~~ I might be entirely wrong with what I write and the solution proposed thereafter, yet I want to raise awareness that with current linux kernels it is possible to leak (at least) heap addresses in an attempt to weaken address space layout randomization. The listed example shows [1] code, it completely identifies three bytes of the heap memory mappings, that is enough to weaken aslr in a way to make it unusable over time. One idea is to disallow a process to use the same addresses after a fork and randomize them after each fork just as during execution stage, this will render the attack unusable. I know this sounds nuts but is most probably the most straightforward way to fix the issue. real mapping: 55b118238000-55b11827b000 rw-p [heap] linux kernel leaking the addresses partial: Discover first byte in offset Try Offsets 10 to ff ... Try Offsets 20 to ff ... Offset 239000 Survived ... Offset 24d000 Survived ... Offset 251000 Survived ... Offset 261000 Survived ... Offset 27d000 Survived ... Offset 281000 Survived ... That's quite exact the heap start to end address. My apologies for suggesting only the solution, I'm too stupid to implement this in real life in, i.e. linux itself :) [1] testcase: https://www.exploit-db.com/exploits/45671/ (referring to version 4.4.0-116, x86_64) Have a nice day!
arch/x86/include/asm/rmwcc.h:23:17: error: jump into statement expression
Hi Peter, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5b7449810ae6d652629c550d3974c8453836d229 commit: 7aa54be2976550f17c11a1c3e3630002dea39303 locking/qspinlock, x86: Provide liveness guarantee date: 2 weeks ago config: x86_64-randconfig-j0-10290909 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout 7aa54be2976550f17c11a1c3e3630002dea39303 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from arch/x86/include/asm/atomic.h:5:0, from include/linux/atomic.h:7, from include/linux/crypto.h:20, from arch/x86/kernel/asm-offsets.c:9: arch/x86/include/asm/qspinlock.h: In function 'queued_fetch_set_pending_acquire': >> arch/x86/include/asm/rmwcc.h:23:17: error: jump into statement expression : clobbers : cc_label);\ ^ include/linux/compiler.h:58:42: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^ arch/x86/include/asm/qspinlock.h:18:2: note: in expansion of macro 'if' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ arch/x86/include/asm/rmwcc.h:21:2: note: in expansion of macro 'asm_volatile_goto' asm_volatile_goto (fullop "; j" #cc " %l[cc_label]" \ ^ arch/x86/include/asm/rmwcc.h:54:2: note: in expansion of macro '__GEN_RMWcc' __GEN_RMWcc(op " %[val], " arg0, var, cc, \ ^ arch/x86/include/asm/rmwcc.h:58:2: note: in expansion of macro 'GEN_BINARY_RMWcc_6' GEN_BINARY_RMWcc_6(op, var, cc, vcon, val, "%[var]") ^ arch/x86/include/asm/rmwcc.h:9:30: note: in expansion of macro 'GEN_BINARY_RMWcc_5' #define __RMWcc_CONCAT(a, b) a ## b ^ arch/x86/include/asm/rmwcc.h:10:28: note: in expansion of macro '__RMWcc_CONCAT' #define RMWcc_CONCAT(a, b) __RMWcc_CONCAT(a, b) ^ arch/x86/include/asm/rmwcc.h:60:32: note: in expansion of macro 'RMWcc_CONCAT' #define GEN_BINARY_RMWcc(X...) RMWcc_CONCAT(GEN_BINARY_RMWcc_, RMWcc_ARGS(X))(X) ^ arch/x86/include/asm/qspinlock.h:18:6: note: in expansion of macro 'GEN_BINARY_RMWcc' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ arch/x86/include/asm/rmwcc.h:25:1: note: label 'cc_label' defined here cc_label: c = true; \ ^ include/linux/compiler.h:58:30: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^ arch/x86/include/asm/qspinlock.h:18:2: note: in expansion of macro 'if' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ arch/x86/include/asm/rmwcc.h:54:2: note: in expansion of macro '__GEN_RMWcc' __GEN_RMWcc(op " %[val], " arg0, var, cc, \ ^ arch/x86/include/asm/rmwcc.h:58:2: note: in expansion of macro 'GEN_BINARY_RMWcc_6' GEN_BINARY_RMWcc_6(op, var, cc, vcon, val, "%[var]") ^ arch/x86/include/asm/rmwcc.h:9:30: note: in expansion of macro 'GEN_BINARY_RMWcc_5' #define __RMWcc_CONCAT(a, b) a ## b ^ arch/x86/include/asm/rmwcc.h:10:28: note: in expansion of macro '__RMWcc_CONCAT' #define RMWcc_CONCAT(a, b) __RMWcc_CONCAT(a, b) ^ arch/x86/include/asm/rmwcc.h:60:32: note: in expansion of macro 'RMWcc_CONCAT' #define GEN_BINARY_RMWcc(X...) RMWcc_CONCAT(GEN_BINARY_RMWcc_, RMWcc_ARGS(X))(X) ^ arch/x86/include/asm/qspinlock.h:18:6: note: in expansion of macro 'GEN_BINARY_RMWcc' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ >> arch/x86/include/asm/rmwcc.h:25:1: error: duplicate label 'cc_label' cc_label: c = true; \ ^ include/linux/compiler.h:58:42: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^ arch/x86/include/asm/qspinlock.h:18:2: note: in expansion of macro 'if' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ arch/x86/include/asm/rmwcc.h:54:2: note: in expansion of macro '__GEN_RMWcc' __GEN_RMWcc(op " %[val], " arg0, var, cc, \ ^ arch/x86/include/asm/rmwcc.h:58:2: note: in expansion of macro 'GEN_BINARY_RMWcc_6' GEN_BINARY_RMWcc_6(op, var, cc, vcon, val, "%[var]") ^ arch/x86/include/asm/rmwcc.h:9:30: note: in expansion of macro 'GEN_BINARY_RMWcc_5' #define __RMWcc_CONCAT(a, b) a ## b ^ arch/x86/include/asm/rmwcc.h:10:28: note: in expansion of macro '__RMWcc_CONCAT' #define RMWcc_CONCAT(a, b) __RMWcc_CONCAT(a, b)
arch/x86/include/asm/rmwcc.h:23:17: error: jump into statement expression
Hi Peter, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5b7449810ae6d652629c550d3974c8453836d229 commit: 7aa54be2976550f17c11a1c3e3630002dea39303 locking/qspinlock, x86: Provide liveness guarantee date: 2 weeks ago config: x86_64-randconfig-j0-10290909 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout 7aa54be2976550f17c11a1c3e3630002dea39303 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from arch/x86/include/asm/atomic.h:5:0, from include/linux/atomic.h:7, from include/linux/crypto.h:20, from arch/x86/kernel/asm-offsets.c:9: arch/x86/include/asm/qspinlock.h: In function 'queued_fetch_set_pending_acquire': >> arch/x86/include/asm/rmwcc.h:23:17: error: jump into statement expression : clobbers : cc_label);\ ^ include/linux/compiler.h:58:42: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^ arch/x86/include/asm/qspinlock.h:18:2: note: in expansion of macro 'if' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ arch/x86/include/asm/rmwcc.h:21:2: note: in expansion of macro 'asm_volatile_goto' asm_volatile_goto (fullop "; j" #cc " %l[cc_label]" \ ^ arch/x86/include/asm/rmwcc.h:54:2: note: in expansion of macro '__GEN_RMWcc' __GEN_RMWcc(op " %[val], " arg0, var, cc, \ ^ arch/x86/include/asm/rmwcc.h:58:2: note: in expansion of macro 'GEN_BINARY_RMWcc_6' GEN_BINARY_RMWcc_6(op, var, cc, vcon, val, "%[var]") ^ arch/x86/include/asm/rmwcc.h:9:30: note: in expansion of macro 'GEN_BINARY_RMWcc_5' #define __RMWcc_CONCAT(a, b) a ## b ^ arch/x86/include/asm/rmwcc.h:10:28: note: in expansion of macro '__RMWcc_CONCAT' #define RMWcc_CONCAT(a, b) __RMWcc_CONCAT(a, b) ^ arch/x86/include/asm/rmwcc.h:60:32: note: in expansion of macro 'RMWcc_CONCAT' #define GEN_BINARY_RMWcc(X...) RMWcc_CONCAT(GEN_BINARY_RMWcc_, RMWcc_ARGS(X))(X) ^ arch/x86/include/asm/qspinlock.h:18:6: note: in expansion of macro 'GEN_BINARY_RMWcc' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ arch/x86/include/asm/rmwcc.h:25:1: note: label 'cc_label' defined here cc_label: c = true; \ ^ include/linux/compiler.h:58:30: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^ arch/x86/include/asm/qspinlock.h:18:2: note: in expansion of macro 'if' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ arch/x86/include/asm/rmwcc.h:54:2: note: in expansion of macro '__GEN_RMWcc' __GEN_RMWcc(op " %[val], " arg0, var, cc, \ ^ arch/x86/include/asm/rmwcc.h:58:2: note: in expansion of macro 'GEN_BINARY_RMWcc_6' GEN_BINARY_RMWcc_6(op, var, cc, vcon, val, "%[var]") ^ arch/x86/include/asm/rmwcc.h:9:30: note: in expansion of macro 'GEN_BINARY_RMWcc_5' #define __RMWcc_CONCAT(a, b) a ## b ^ arch/x86/include/asm/rmwcc.h:10:28: note: in expansion of macro '__RMWcc_CONCAT' #define RMWcc_CONCAT(a, b) __RMWcc_CONCAT(a, b) ^ arch/x86/include/asm/rmwcc.h:60:32: note: in expansion of macro 'RMWcc_CONCAT' #define GEN_BINARY_RMWcc(X...) RMWcc_CONCAT(GEN_BINARY_RMWcc_, RMWcc_ARGS(X))(X) ^ arch/x86/include/asm/qspinlock.h:18:6: note: in expansion of macro 'GEN_BINARY_RMWcc' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ >> arch/x86/include/asm/rmwcc.h:25:1: error: duplicate label 'cc_label' cc_label: c = true; \ ^ include/linux/compiler.h:58:42: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^ arch/x86/include/asm/qspinlock.h:18:2: note: in expansion of macro 'if' if (GEN_BINARY_RMWcc(LOCK_PREFIX "btsl", lock->val.counter, c, ^ arch/x86/include/asm/rmwcc.h:54:2: note: in expansion of macro '__GEN_RMWcc' __GEN_RMWcc(op " %[val], " arg0, var, cc, \ ^ arch/x86/include/asm/rmwcc.h:58:2: note: in expansion of macro 'GEN_BINARY_RMWcc_6' GEN_BINARY_RMWcc_6(op, var, cc, vcon, val, "%[var]") ^ arch/x86/include/asm/rmwcc.h:9:30: note: in expansion of macro 'GEN_BINARY_RMWcc_5' #define __RMWcc_CONCAT(a, b) a ## b ^ arch/x86/include/asm/rmwcc.h:10:28: note: in expansion of macro '__RMWcc_CONCAT' #define RMWcc_CONCAT(a, b) __RMWcc_CONCAT(a, b)
Re: sound/pci/hda/patch_ca0132.c:7650:20: error: implicit declaration of function 'pci_iomap'; did you mean 'pcim_iomap'?
On 10/31/18 5:48 PM, kbuild test robot wrote:
> Hi Rakesh,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5b7449810ae6d652629c550d3974c8453836d229
> commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
> extension for legacy HDA codec drivers
> date: 9 weeks ago
> config: sh-allyesconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 6bae5ea9498926440ffc883f3dbceb0adc65e492
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=sh
Hi lkp robot,
I have a (process) question:
Does the above mean that this build failed on 4.19-rc1 9 weeks ago and that
it still fails on 4.19-rc1? Has this .config been tested on v4.19, e.g.?
I have tested this .config on v4.19 and don't see the build error that is
listed here (below). This error happens because CONFIG_PCI is not enabled,
so pci_iomap() is not available. The drivers in sound/pci/hda/ should not
be enabled since CONFIG_PCI is not enabled and indeed, in v4.19, after running
"make oldconfig", those drivers are not enabled, so the build error does not
happen.
None of these Kconfig symbols (from the attached .config file) is enabled
after running "make oldconfig":
CONFIG_SND_HDA=y
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1
CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CA0132=y
CONFIG_SND_HDA_CODEC_CA0132_DSP=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
I conclude that someone has "fixed" the faulty Kconfig file(s) that caused this
problem and that it is no longer a problem.
Or I could be all mussed up. :)
Thanks.
> All errors (new ones prefixed by >>):
>
>sound/pci/hda/patch_ca0132.c: In function 'patch_ca0132':
>>> sound/pci/hda/patch_ca0132.c:7650:20: error: implicit declaration of
>>> function 'pci_iomap'; did you mean 'pcim_iomap'?
>>> [-Werror=implicit-function-declaration]
> spec->mem_base = pci_iomap(codec->bus->pci, 2, 0xC20);
>^
>pcim_iomap
>sound/pci/hda/patch_ca0132.c:7650:18: warning: assignment makes pointer
> from integer without a cast [-Wint-conversion]
> spec->mem_base = pci_iomap(codec->bus->pci, 2, 0xC20);
> ^
>cc1: some warnings being treated as errors
>
> vim +7650 sound/pci/hda/patch_ca0132.c
>
> d5c016b56 Gabriele Martino 2015-05-18 7581
> 95c6e9cb7 Ian Minett 2011-06-15 7582 static int patch_ca0132(struct
> hda_codec *codec)
> 95c6e9cb7 Ian Minett 2011-06-15 7583 {
> 95c6e9cb7 Ian Minett 2011-06-15 7584 struct ca0132_spec *spec;
> a73d511c4 Ian Minett 2012-12-20 7585 int err;
> d5c016b56 Gabriele Martino 2015-05-18 7586 const struct snd_pci_quirk
> *quirk;
> 95c6e9cb7 Ian Minett 2011-06-15 7587
> 4e76a8833 Takashi Iwai 2014-02-25 7588 codec_dbg(codec,
> "patch_ca0132\n");
> 95c6e9cb7 Ian Minett 2011-06-15 7589
> 95c6e9cb7 Ian Minett 2011-06-15 7590 spec = kzalloc(sizeof(*spec),
> GFP_KERNEL);
> 95c6e9cb7 Ian Minett 2011-06-15 7591 if (!spec)
> 95c6e9cb7 Ian Minett 2011-06-15 7592 return -ENOMEM;
> 95c6e9cb7 Ian Minett 2011-06-15 7593 codec->spec = spec;
> 993884f6a Chih-Chung Chang 2013-03-25 7594 spec->codec = codec;
> 95c6e9cb7 Ian Minett 2011-06-15 7595
> 225068ab2 Takashi Iwai 2015-05-29 7596 codec->patch_ops =
> ca0132_patch_ops;
> 225068ab2 Takashi Iwai 2015-05-29 7597 codec->pcm_format_first = 1;
> 225068ab2 Takashi Iwai 2015-05-29 7598 codec->no_sticky_stream = 1;
> 225068ab2 Takashi Iwai 2015-05-29 7599
> d5c016b56 Gabriele Martino 2015-05-18 7600 /* Detect codec quirk */
> d5c016b56 Gabriele Martino 2015-05-18 7601 quirk =
> snd_pci_quirk_lookup(codec->bus->pci, ca0132_quirks);
> d5c016b56 Gabriele Martino 2015-05-18 7602 if (quirk)
> d5c016b56 Gabriele Martino 2015-05-18 7603 spec->quirk =
> quirk->value;
> d5c016b56 Gabriele Martino 2015-05-18 7604 else
> d5c016b56 Gabriele Martino 2015-05-18 7605 spec->quirk =
> QUIRK_NONE;
> d5c016b56 Gabriele Martino 2015-05-18 7606
> e24aa0a4c Takashi Iwai 2014-08-10 7607 spec->dsp_state =
> DSP_DOWNLOAD_INIT;
> a7e76271b Ian Minett 2012-12-20 7608 spec->num_mixers = 1;
> 017310fbe Connor McAdams 2018-05-08
Re: sound/pci/hda/patch_ca0132.c:7650:20: error: implicit declaration of function 'pci_iomap'; did you mean 'pcim_iomap'?
On 10/31/18 5:48 PM, kbuild test robot wrote:
> Hi Rakesh,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5b7449810ae6d652629c550d3974c8453836d229
> commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
> extension for legacy HDA codec drivers
> date: 9 weeks ago
> config: sh-allyesconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 6bae5ea9498926440ffc883f3dbceb0adc65e492
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=sh
Hi lkp robot,
I have a (process) question:
Does the above mean that this build failed on 4.19-rc1 9 weeks ago and that
it still fails on 4.19-rc1? Has this .config been tested on v4.19, e.g.?
I have tested this .config on v4.19 and don't see the build error that is
listed here (below). This error happens because CONFIG_PCI is not enabled,
so pci_iomap() is not available. The drivers in sound/pci/hda/ should not
be enabled since CONFIG_PCI is not enabled and indeed, in v4.19, after running
"make oldconfig", those drivers are not enabled, so the build error does not
happen.
None of these Kconfig symbols (from the attached .config file) is enabled
after running "make oldconfig":
CONFIG_SND_HDA=y
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1
CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CA0132=y
CONFIG_SND_HDA_CODEC_CA0132_DSP=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
I conclude that someone has "fixed" the faulty Kconfig file(s) that caused this
problem and that it is no longer a problem.
Or I could be all mussed up. :)
Thanks.
> All errors (new ones prefixed by >>):
>
>sound/pci/hda/patch_ca0132.c: In function 'patch_ca0132':
>>> sound/pci/hda/patch_ca0132.c:7650:20: error: implicit declaration of
>>> function 'pci_iomap'; did you mean 'pcim_iomap'?
>>> [-Werror=implicit-function-declaration]
> spec->mem_base = pci_iomap(codec->bus->pci, 2, 0xC20);
>^
>pcim_iomap
>sound/pci/hda/patch_ca0132.c:7650:18: warning: assignment makes pointer
> from integer without a cast [-Wint-conversion]
> spec->mem_base = pci_iomap(codec->bus->pci, 2, 0xC20);
> ^
>cc1: some warnings being treated as errors
>
> vim +7650 sound/pci/hda/patch_ca0132.c
>
> d5c016b56 Gabriele Martino 2015-05-18 7581
> 95c6e9cb7 Ian Minett 2011-06-15 7582 static int patch_ca0132(struct
> hda_codec *codec)
> 95c6e9cb7 Ian Minett 2011-06-15 7583 {
> 95c6e9cb7 Ian Minett 2011-06-15 7584 struct ca0132_spec *spec;
> a73d511c4 Ian Minett 2012-12-20 7585 int err;
> d5c016b56 Gabriele Martino 2015-05-18 7586 const struct snd_pci_quirk
> *quirk;
> 95c6e9cb7 Ian Minett 2011-06-15 7587
> 4e76a8833 Takashi Iwai 2014-02-25 7588 codec_dbg(codec,
> "patch_ca0132\n");
> 95c6e9cb7 Ian Minett 2011-06-15 7589
> 95c6e9cb7 Ian Minett 2011-06-15 7590 spec = kzalloc(sizeof(*spec),
> GFP_KERNEL);
> 95c6e9cb7 Ian Minett 2011-06-15 7591 if (!spec)
> 95c6e9cb7 Ian Minett 2011-06-15 7592 return -ENOMEM;
> 95c6e9cb7 Ian Minett 2011-06-15 7593 codec->spec = spec;
> 993884f6a Chih-Chung Chang 2013-03-25 7594 spec->codec = codec;
> 95c6e9cb7 Ian Minett 2011-06-15 7595
> 225068ab2 Takashi Iwai 2015-05-29 7596 codec->patch_ops =
> ca0132_patch_ops;
> 225068ab2 Takashi Iwai 2015-05-29 7597 codec->pcm_format_first = 1;
> 225068ab2 Takashi Iwai 2015-05-29 7598 codec->no_sticky_stream = 1;
> 225068ab2 Takashi Iwai 2015-05-29 7599
> d5c016b56 Gabriele Martino 2015-05-18 7600 /* Detect codec quirk */
> d5c016b56 Gabriele Martino 2015-05-18 7601 quirk =
> snd_pci_quirk_lookup(codec->bus->pci, ca0132_quirks);
> d5c016b56 Gabriele Martino 2015-05-18 7602 if (quirk)
> d5c016b56 Gabriele Martino 2015-05-18 7603 spec->quirk =
> quirk->value;
> d5c016b56 Gabriele Martino 2015-05-18 7604 else
> d5c016b56 Gabriele Martino 2015-05-18 7605 spec->quirk =
> QUIRK_NONE;
> d5c016b56 Gabriele Martino 2015-05-18 7606
> e24aa0a4c Takashi Iwai 2014-08-10 7607 spec->dsp_state =
> DSP_DOWNLOAD_INIT;
> a7e76271b Ian Minett 2012-12-20 7608 spec->num_mixers = 1;
> 017310fbe Connor McAdams 2018-05-08
net/sunrpc/auth_gss/gss_krb5_seal.c:144:14: error: implicit declaration of function 'cmpxchg64'; did you mean 'cmpxchg'?
Hi Arnd,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit: 21924765862a0871908a35cb0e53e2e1c169b888 SUNRPC: use cmpxchg64() in
gss_seq_send64_fetch_and_inc()
date: 4 weeks ago
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 21924765862a0871908a35cb0e53e2e1c169b888
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All errors (new ones prefixed by >>):
net/sunrpc/auth_gss/gss_krb5_seal.c: In function
'gss_seq_send64_fetch_and_inc':
>> net/sunrpc/auth_gss/gss_krb5_seal.c:144:14: error: implicit declaration of
>> function 'cmpxchg64'; did you mean 'cmpxchg'?
>> [-Werror=implicit-function-declaration]
seq_send = cmpxchg64(>seq_send64, old, old + 1);
^
cmpxchg
cc1: some warnings being treated as errors
vim +144 net/sunrpc/auth_gss/gss_krb5_seal.c
136
137 u64
138 gss_seq_send64_fetch_and_inc(struct krb5_ctx *ctx)
139 {
140 u64 old, seq_send = READ_ONCE(ctx->seq_send);
141
142 do {
143 old = seq_send;
> 144 seq_send = cmpxchg64(>seq_send64, old, old + 1);
145 } while (old != seq_send);
146 return seq_send;
147 }
148
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
net/sunrpc/auth_gss/gss_krb5_seal.c:144:14: error: implicit declaration of function 'cmpxchg64'; did you mean 'cmpxchg'?
Hi Arnd,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit: 21924765862a0871908a35cb0e53e2e1c169b888 SUNRPC: use cmpxchg64() in
gss_seq_send64_fetch_and_inc()
date: 4 weeks ago
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 21924765862a0871908a35cb0e53e2e1c169b888
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All errors (new ones prefixed by >>):
net/sunrpc/auth_gss/gss_krb5_seal.c: In function
'gss_seq_send64_fetch_and_inc':
>> net/sunrpc/auth_gss/gss_krb5_seal.c:144:14: error: implicit declaration of
>> function 'cmpxchg64'; did you mean 'cmpxchg'?
>> [-Werror=implicit-function-declaration]
seq_send = cmpxchg64(>seq_send64, old, old + 1);
^
cmpxchg
cc1: some warnings being treated as errors
vim +144 net/sunrpc/auth_gss/gss_krb5_seal.c
136
137 u64
138 gss_seq_send64_fetch_and_inc(struct krb5_ctx *ctx)
139 {
140 u64 old, seq_send = READ_ONCE(ctx->seq_send);
141
142 do {
143 old = seq_send;
> 144 seq_send = cmpxchg64(>seq_send64, old, old + 1);
145 } while (old != seq_send);
146 return seq_send;
147 }
148
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH] pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion from
enumeration type 'enum zynq_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
{"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
~ ^
drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion from
enumeration type 'enum zynq_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
= { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, true),
~~^
./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
macro 'PCONFDUMP'
.param = a, .display = b, .format = c, .has_arg = d \
^
2 warnings generated.
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Signed-off-by: Nathan Chancellor
---
drivers/pinctrl/pinctrl-zynq.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c
index a0daf27042bd..57046c221756 100644
--- a/drivers/pinctrl/pinctrl-zynq.c
+++ b/drivers/pinctrl/pinctrl-zynq.c
@@ -972,14 +972,11 @@ enum zynq_io_standards {
};
/**
- * enum zynq_pin_config_param - possible pin configuration parameters
* @PIN_CONFIG_IOSTANDARD: if the pin can select an IO standard, the argument
to
* this parameter (on a custom format) tells the driver which alternative
* IO standard to use.
*/
-enum zynq_pin_config_param {
- PIN_CONFIG_IOSTANDARD = PIN_CONFIG_END + 1,
-};
+#define PIN_CONFIG_IOSTANDARD (PIN_CONFIG_END + 1)
static const struct pinconf_generic_params zynq_dt_params[] = {
{"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
--
2.19.1
[PATCH] pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion from
enumeration type 'enum zynq_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
{"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
~ ^
drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion from
enumeration type 'enum zynq_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
= { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, true),
~~^
./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
macro 'PCONFDUMP'
.param = a, .display = b, .format = c, .has_arg = d \
^
2 warnings generated.
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Signed-off-by: Nathan Chancellor
---
drivers/pinctrl/pinctrl-zynq.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c
index a0daf27042bd..57046c221756 100644
--- a/drivers/pinctrl/pinctrl-zynq.c
+++ b/drivers/pinctrl/pinctrl-zynq.c
@@ -972,14 +972,11 @@ enum zynq_io_standards {
};
/**
- * enum zynq_pin_config_param - possible pin configuration parameters
* @PIN_CONFIG_IOSTANDARD: if the pin can select an IO standard, the argument
to
* this parameter (on a custom format) tells the driver which alternative
* IO standard to use.
*/
-enum zynq_pin_config_param {
- PIN_CONFIG_IOSTANDARD = PIN_CONFIG_END + 1,
-};
+#define PIN_CONFIG_IOSTANDARD (PIN_CONFIG_END + 1)
static const struct pinconf_generic_params zynq_dt_params[] = {
{"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
--
2.19.1
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote: > On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > > I agree that we need a place for vendor-specific ISA extensions and > > having vendor-specific directories is also good. > > The only sensible answer is that we should not allow vendor specific > extensions in the kernel at all. ... How can this even be possible if a extension includes an extra register set as some domain-specific context? In such a case, kernel should at least process the context during any context switch, just like how it deals with the FP context. > ... We need to standardize cache flushing > and we need to do it soon and not introduce horrible bandaids because > the foundation did not do its work. > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote: > On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > > I agree that we need a place for vendor-specific ISA extensions and > > having vendor-specific directories is also good. > > The only sensible answer is that we should not allow vendor specific > extensions in the kernel at all. ... How can this even be possible if a extension includes an extra register set as some domain-specific context? In such a case, kernel should at least process the context during any context switch, just like how it deals with the FP context. > ... We need to standardize cache flushing > and we need to do it soon and not introduce horrible bandaids because > the foundation did not do its work. > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
[PATCH] rtc: omap: Use define directive for PIN_CONFIG_ACTIVE_HIGH
Clang warns when one enumerated type is implicitly converted to another:
drivers/rtc/rtc-omap.c:574:21: warning: implicit conversion from
enumeration type 'enum rtc_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
{"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0},
~ ^~
drivers/rtc/rtc-omap.c:579:12: warning: implicit conversion from
enumeration type 'enum rtc_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
PCONFDUMP(PIN_CONFIG_ACTIVE_HIGH, "input active high", NULL, false),
~~^
./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
macro 'PCONFDUMP'
.param = a, .display = b, .format = c, .has_arg = d \
^
2 warnings generated.
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/144
Signed-off-by: Nathan Chancellor
---
drivers/rtc/rtc-omap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 320b4a520eb3..bbff0e2deb84 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -566,9 +566,7 @@ static const struct pinctrl_ops rtc_pinctrl_ops = {
.dt_free_map = pinconf_generic_dt_free_map,
};
-enum rtc_pin_config_param {
- PIN_CONFIG_ACTIVE_HIGH = PIN_CONFIG_END + 1,
-};
+#define PIN_CONFIG_ACTIVE_HIGH (PIN_CONFIG_END + 1)
static const struct pinconf_generic_params rtc_params[] = {
{"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0},
--
2.19.1
[PATCH] rtc: omap: Use define directive for PIN_CONFIG_ACTIVE_HIGH
Clang warns when one enumerated type is implicitly converted to another:
drivers/rtc/rtc-omap.c:574:21: warning: implicit conversion from
enumeration type 'enum rtc_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
{"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0},
~ ^~
drivers/rtc/rtc-omap.c:579:12: warning: implicit conversion from
enumeration type 'enum rtc_pin_config_param' to different enumeration
type 'enum pin_config_param' [-Wenum-conversion]
PCONFDUMP(PIN_CONFIG_ACTIVE_HIGH, "input active high", NULL, false),
~~^
./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
macro 'PCONFDUMP'
.param = a, .display = b, .format = c, .has_arg = d \
^
2 warnings generated.
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/144
Signed-off-by: Nathan Chancellor
---
drivers/rtc/rtc-omap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 320b4a520eb3..bbff0e2deb84 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -566,9 +566,7 @@ static const struct pinctrl_ops rtc_pinctrl_ops = {
.dt_free_map = pinconf_generic_dt_free_map,
};
-enum rtc_pin_config_param {
- PIN_CONFIG_ACTIVE_HIGH = PIN_CONFIG_END + 1,
-};
+#define PIN_CONFIG_ACTIVE_HIGH (PIN_CONFIG_END + 1)
static const struct pinconf_generic_params rtc_params[] = {
{"ti,active-high", PIN_CONFIG_ACTIVE_HIGH, 0},
--
2.19.1
[PATCH] pinctrl: lpc18xx: Use define directive for PIN_CONFIG_GPIO_PIN_INT
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/pinctrl-lpc18xx.c:643:29: warning: implicit conversion
from enumeration type 'enum lpc18xx_pin_config_param' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
{"nxp,gpio-pin-interrupt", PIN_CONFIG_GPIO_PIN_INT, 0},
~ ^~~
drivers/pinctrl/pinctrl-lpc18xx.c:648:12: warning: implicit conversion
from enumeration type 'enum lpc18xx_pin_config_param' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
PCONFDUMP(PIN_CONFIG_GPIO_PIN_INT, "gpio pin int", NULL, true),
~~^~~~
./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
macro 'PCONFDUMP'
.param = a, .display = b, .format = c, .has_arg = d \
^
2 warnings generated.
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/140
Signed-off-by: Nathan Chancellor
---
drivers/pinctrl/pinctrl-lpc18xx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-lpc18xx.c
b/drivers/pinctrl/pinctrl-lpc18xx.c
index a14bc5e5fc24..4bee606088e1 100644
--- a/drivers/pinctrl/pinctrl-lpc18xx.c
+++ b/drivers/pinctrl/pinctrl-lpc18xx.c
@@ -631,13 +631,10 @@ static const struct pinctrl_pin_desc lpc18xx_pins[] = {
};
/**
- * enum lpc18xx_pin_config_param - possible pin configuration parameters
* @PIN_CONFIG_GPIO_PIN_INT: route gpio to the gpio pin interrupt
* controller.
*/
-enum lpc18xx_pin_config_param {
- PIN_CONFIG_GPIO_PIN_INT = PIN_CONFIG_END + 1,
-};
+#define PIN_CONFIG_GPIO_PIN_INT(PIN_CONFIG_END + 1)
static const struct pinconf_generic_params lpc18xx_params[] = {
{"nxp,gpio-pin-interrupt", PIN_CONFIG_GPIO_PIN_INT, 0},
--
2.19.1
[PATCH] pinctrl: lpc18xx: Use define directive for PIN_CONFIG_GPIO_PIN_INT
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/pinctrl-lpc18xx.c:643:29: warning: implicit conversion
from enumeration type 'enum lpc18xx_pin_config_param' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
{"nxp,gpio-pin-interrupt", PIN_CONFIG_GPIO_PIN_INT, 0},
~ ^~~
drivers/pinctrl/pinctrl-lpc18xx.c:648:12: warning: implicit conversion
from enumeration type 'enum lpc18xx_pin_config_param' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
PCONFDUMP(PIN_CONFIG_GPIO_PIN_INT, "gpio pin int", NULL, true),
~~^~~~
./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from
macro 'PCONFDUMP'
.param = a, .display = b, .format = c, .has_arg = d \
^
2 warnings generated.
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/140
Signed-off-by: Nathan Chancellor
---
drivers/pinctrl/pinctrl-lpc18xx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-lpc18xx.c
b/drivers/pinctrl/pinctrl-lpc18xx.c
index a14bc5e5fc24..4bee606088e1 100644
--- a/drivers/pinctrl/pinctrl-lpc18xx.c
+++ b/drivers/pinctrl/pinctrl-lpc18xx.c
@@ -631,13 +631,10 @@ static const struct pinctrl_pin_desc lpc18xx_pins[] = {
};
/**
- * enum lpc18xx_pin_config_param - possible pin configuration parameters
* @PIN_CONFIG_GPIO_PIN_INT: route gpio to the gpio pin interrupt
* controller.
*/
-enum lpc18xx_pin_config_param {
- PIN_CONFIG_GPIO_PIN_INT = PIN_CONFIG_END + 1,
-};
+#define PIN_CONFIG_GPIO_PIN_INT(PIN_CONFIG_END + 1)
static const struct pinconf_generic_params lpc18xx_params[] = {
{"nxp,gpio-pin-interrupt", PIN_CONFIG_GPIO_PIN_INT, 0},
--
2.19.1
[PATCH] pinctrl: max77620: Use define directive for max77620_pinconf_param values
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/pinctrl-max77620.c:56:12: warning: implicit conversion
from enumeration type 'enum max77620_pinconf_param' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
.param = MAX77620_ACTIVE_FPS_SOURCE,
^~
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/139
Signed-off-by: Nathan Chancellor
---
drivers/pinctrl/pinctrl-max77620.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-max77620.c
b/drivers/pinctrl/pinctrl-max77620.c
index a7f37063518e..3d05bc1937d4 100644
--- a/drivers/pinctrl/pinctrl-max77620.c
+++ b/drivers/pinctrl/pinctrl-max77620.c
@@ -34,14 +34,12 @@ enum max77620_pin_ppdrv {
MAX77620_PIN_PP_DRV,
};
-enum max77620_pinconf_param {
- MAX77620_ACTIVE_FPS_SOURCE = PIN_CONFIG_END + 1,
- MAX77620_ACTIVE_FPS_POWER_ON_SLOTS,
- MAX77620_ACTIVE_FPS_POWER_DOWN_SLOTS,
- MAX77620_SUSPEND_FPS_SOURCE,
- MAX77620_SUSPEND_FPS_POWER_ON_SLOTS,
- MAX77620_SUSPEND_FPS_POWER_DOWN_SLOTS,
-};
+#define MAX77620_ACTIVE_FPS_SOURCE (PIN_CONFIG_END + 1)
+#define MAX77620_ACTIVE_FPS_POWER_ON_SLOTS (PIN_CONFIG_END + 2)
+#define MAX77620_ACTIVE_FPS_POWER_DOWN_SLOTS (PIN_CONFIG_END + 3)
+#define MAX77620_SUSPEND_FPS_SOURCE(PIN_CONFIG_END + 4)
+#define MAX77620_SUSPEND_FPS_POWER_ON_SLOTS(PIN_CONFIG_END + 5)
+#define MAX77620_SUSPEND_FPS_POWER_DOWN_SLOTS (PIN_CONFIG_END + 6)
struct max77620_pin_function {
const char *name;
--
2.19.1
[PATCH] pinctrl: max77620: Use define directive for max77620_pinconf_param values
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/pinctrl-max77620.c:56:12: warning: implicit conversion
from enumeration type 'enum max77620_pinconf_param' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
.param = MAX77620_ACTIVE_FPS_SOURCE,
^~
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/139
Signed-off-by: Nathan Chancellor
---
drivers/pinctrl/pinctrl-max77620.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-max77620.c
b/drivers/pinctrl/pinctrl-max77620.c
index a7f37063518e..3d05bc1937d4 100644
--- a/drivers/pinctrl/pinctrl-max77620.c
+++ b/drivers/pinctrl/pinctrl-max77620.c
@@ -34,14 +34,12 @@ enum max77620_pin_ppdrv {
MAX77620_PIN_PP_DRV,
};
-enum max77620_pinconf_param {
- MAX77620_ACTIVE_FPS_SOURCE = PIN_CONFIG_END + 1,
- MAX77620_ACTIVE_FPS_POWER_ON_SLOTS,
- MAX77620_ACTIVE_FPS_POWER_DOWN_SLOTS,
- MAX77620_SUSPEND_FPS_SOURCE,
- MAX77620_SUSPEND_FPS_POWER_ON_SLOTS,
- MAX77620_SUSPEND_FPS_POWER_DOWN_SLOTS,
-};
+#define MAX77620_ACTIVE_FPS_SOURCE (PIN_CONFIG_END + 1)
+#define MAX77620_ACTIVE_FPS_POWER_ON_SLOTS (PIN_CONFIG_END + 2)
+#define MAX77620_ACTIVE_FPS_POWER_DOWN_SLOTS (PIN_CONFIG_END + 3)
+#define MAX77620_SUSPEND_FPS_SOURCE(PIN_CONFIG_END + 4)
+#define MAX77620_SUSPEND_FPS_POWER_ON_SLOTS(PIN_CONFIG_END + 5)
+#define MAX77620_SUSPEND_FPS_POWER_DOWN_SLOTS (PIN_CONFIG_END + 6)
struct max77620_pin_function {
const char *name;
--
2.19.1
Re: [PATCH v3 1/8] selftests/resctrl: Add README for resctrl tests
On 10/31/18 2:02 PM, Fenghua Yu wrote: > resctrl tests will be implemented. README is added for the tool first. > > Signed-off-by: Fenghua Yu Hi, > --- > tools/testing/selftests/resctrl/README | 53 > ++ > 1 file changed, 53 insertions(+) > create mode 100644 tools/testing/selftests/resctrl/README > > diff --git a/tools/testing/selftests/resctrl/README > b/tools/testing/selftests/resctrl/README > new file mode 100644 > index ..09851a619547 > --- /dev/null > +++ b/tools/testing/selftests/resctrl/README > @@ -0,0 +1,53 @@ > +resctrl_tests - resctrl file system test suit > + > +Authors: > + Fenghua Yu > + Sai Praneeth Prakhya , > + Arshiya Hayatkhan Pathan > + > +resctrl_tests tests various resctrl functionalities and interfaces including > +both software and hardware. > + > +Currently it supports Memory Bandwidth Monitoring test and Memory Bandwidth > +Allocation test on Intel RDT hardware. More tests will be added in the > future. > +And the test suit can be extended to cover AMD QoS and ARM MPAM hardware suite > +as well. > + > +BUILD > +- cheers. -- ~Randy
Re: [PATCH v3 1/8] selftests/resctrl: Add README for resctrl tests
On 10/31/18 2:02 PM, Fenghua Yu wrote: > resctrl tests will be implemented. README is added for the tool first. > > Signed-off-by: Fenghua Yu Hi, > --- > tools/testing/selftests/resctrl/README | 53 > ++ > 1 file changed, 53 insertions(+) > create mode 100644 tools/testing/selftests/resctrl/README > > diff --git a/tools/testing/selftests/resctrl/README > b/tools/testing/selftests/resctrl/README > new file mode 100644 > index ..09851a619547 > --- /dev/null > +++ b/tools/testing/selftests/resctrl/README > @@ -0,0 +1,53 @@ > +resctrl_tests - resctrl file system test suit > + > +Authors: > + Fenghua Yu > + Sai Praneeth Prakhya , > + Arshiya Hayatkhan Pathan > + > +resctrl_tests tests various resctrl functionalities and interfaces including > +both software and hardware. > + > +Currently it supports Memory Bandwidth Monitoring test and Memory Bandwidth > +Allocation test on Intel RDT hardware. More tests will be added in the > future. > +And the test suit can be extended to cover AMD QoS and ARM MPAM hardware suite > +as well. > + > +BUILD > +- cheers. -- ~Randy
