Re: [PATCH 4.19 000/205] 4.19.3-stable review
stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 101 passed with 18 offline, 1 conflict (v4.19.2-206-g857962e4c7ee) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.2-206-g857962e4c7ee/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.2-206-g857962e4c7ee/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.2-206-g857962e4c7ee Git Commit: 857962e4c7ee68cec7bbf720850c80d2ec7e5777 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 66 unique boards, 23 SoC families, 15 builds out of 187 Offline Platforms: arm: omap2plus_defconfig: am335x-boneblack: 1 offline lab sunxi_defconfig: sun5i-r8-chip: 1 offline lab tegra_defconfig: tegra124-jetson-tk1: 1 offline lab bcm2835_defconfig: bcm2835-rpi-b: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab sama5_defconfig: at91-sama5d4_xplained: 1 offline lab multi_v7_defconfig: alpine-db: 1 offline lab am335x-boneblack: 1 offline lab at91-sama5d4_xplained: 1 offline lab exynos5800-peach-pi: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab tegra124-jetson-tk1: 1 offline lab arm64: defconfig: apq8016-sbc: 1 offline lab juno-r2: 1 offline lab meson-gxl-s905d-p230: 1 offline lab meson-gxl-s905x-p212: 1 offline lab mt7622-rfb1: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm64: defconfig: meson-gxbb-p200: lab-baylibre: FAIL lab-baylibre-seattle: PASS --- For more info write to
Re: [PATCH] x86/mm/dump_pagetables: Change to use DEFINE_SHOW_ATTRIBUTE macro
Hi Kees:
I want to listen to you.
--Yangtao
On Tue, Nov 20, 2018 at 8:49 AM Frank Lee wrote:
>
> Hi Dava:
>
> How about just change the ptdump_fops and ptdump_open?
>
> Yours,
> Yangtao
> On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
> >
> > On 11/19/18 7:43 AM, Yangtao Li wrote:
> > > -static const struct file_operations ptdump_curusr_fops = {
> > > - .owner = THIS_MODULE,
> > > - .open = ptdump_open_curusr,
> > > - .read = seq_read,
> > > - .llseek = seq_lseek,
> > > - .release= single_release,
> > > -};
> > > +DEFINE_SHOW_ATTRIBUTE(ptdump_curusr);
> >
> > FWIW, I rather dislike this conversion and the DEFINE_SHOW_ATTRIBUTE()
> > approach in general. It makes it basically impossible to go from
> > ptdump_curusr to ptdump_open_curusr without opening up the macro and
> > reverse-engineering it.
> >
> > My test is that for these macros to be sane, I need to be able to find
> > "ptdump_open_curusr" by grepping for "ptdump_curusr". This fails the test.
> >
> > I don't think saving a few lines of code is worth the obfuscation.
Re: [PATCH 4.19 000/205] 4.19.3-stable review
stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 101 passed with 18 offline, 1 conflict (v4.19.2-206-g857962e4c7ee) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.2-206-g857962e4c7ee/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.2-206-g857962e4c7ee/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.2-206-g857962e4c7ee Git Commit: 857962e4c7ee68cec7bbf720850c80d2ec7e5777 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 66 unique boards, 23 SoC families, 15 builds out of 187 Offline Platforms: arm: omap2plus_defconfig: am335x-boneblack: 1 offline lab sunxi_defconfig: sun5i-r8-chip: 1 offline lab tegra_defconfig: tegra124-jetson-tk1: 1 offline lab bcm2835_defconfig: bcm2835-rpi-b: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab sama5_defconfig: at91-sama5d4_xplained: 1 offline lab multi_v7_defconfig: alpine-db: 1 offline lab am335x-boneblack: 1 offline lab at91-sama5d4_xplained: 1 offline lab exynos5800-peach-pi: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab tegra124-jetson-tk1: 1 offline lab arm64: defconfig: apq8016-sbc: 1 offline lab juno-r2: 1 offline lab meson-gxl-s905d-p230: 1 offline lab meson-gxl-s905x-p212: 1 offline lab mt7622-rfb1: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm64: defconfig: meson-gxbb-p200: lab-baylibre: FAIL lab-baylibre-seattle: PASS --- For more info write to
Re: [PATCH] x86/mm/dump_pagetables: Change to use DEFINE_SHOW_ATTRIBUTE macro
Hi Kees:
I want to listen to you.
--Yangtao
On Tue, Nov 20, 2018 at 8:49 AM Frank Lee wrote:
>
> Hi Dava:
>
> How about just change the ptdump_fops and ptdump_open?
>
> Yours,
> Yangtao
> On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
> >
> > On 11/19/18 7:43 AM, Yangtao Li wrote:
> > > -static const struct file_operations ptdump_curusr_fops = {
> > > - .owner = THIS_MODULE,
> > > - .open = ptdump_open_curusr,
> > > - .read = seq_read,
> > > - .llseek = seq_lseek,
> > > - .release= single_release,
> > > -};
> > > +DEFINE_SHOW_ATTRIBUTE(ptdump_curusr);
> >
> > FWIW, I rather dislike this conversion and the DEFINE_SHOW_ATTRIBUTE()
> > approach in general. It makes it basically impossible to go from
> > ptdump_curusr to ptdump_open_curusr without opening up the macro and
> > reverse-engineering it.
> >
> > My test is that for these macros to be sane, I need to be able to find
> > "ptdump_open_curusr" by grepping for "ptdump_curusr". This fails the test.
> >
> > I don't think saving a few lines of code is worth the obfuscation.
linux-next: build failure after merge of the regulator tree
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "regulator_lock" [drivers/regulator/wm8350-regulator.ko] undefined!
ERROR: "regulator_unlock" [drivers/regulator/wm8350-regulator.ko] undefined!
ERROR: "regulator_unlock" [drivers/regulator/da9210-regulator.ko] undefined!
ERROR: "regulator_lock" [drivers/regulator/da9210-regulator.ko] undefined!
Caused by commit
f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
I have used the regulator tree from next-20181119 for today.
--
Cheers,
Stephen Rothwell
pgpT42Gw0sVkS.pgp
Description: OpenPGP digital signature
Re: [PATCH] x86/mm/dump_pagetables: Change to use DEFINE_SHOW_ATTRIBUTE macro
Hi Dava:
How about just change the ptdump_fops and ptdump_open?
Yours,
Yangtao
On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
>
> On 11/19/18 7:43 AM, Yangtao Li wrote:
> > -static const struct file_operations ptdump_curusr_fops = {
> > - .owner = THIS_MODULE,
> > - .open = ptdump_open_curusr,
> > - .read = seq_read,
> > - .llseek = seq_lseek,
> > - .release= single_release,
> > -};
> > +DEFINE_SHOW_ATTRIBUTE(ptdump_curusr);
>
> FWIW, I rather dislike this conversion and the DEFINE_SHOW_ATTRIBUTE()
> approach in general. It makes it basically impossible to go from
> ptdump_curusr to ptdump_open_curusr without opening up the macro and
> reverse-engineering it.
>
> My test is that for these macros to be sane, I need to be able to find
> "ptdump_open_curusr" by grepping for "ptdump_curusr". This fails the test.
>
> I don't think saving a few lines of code is worth the obfuscation.
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Mon, Nov 19, 2018 at 4:28 PM Andy Lutomirski wrote: > > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote: > > > These tools also care about ioctls. Adding a system call is a pain, > > > but the solution is to make adding system calls less of a pain, not to > > > permanently make the Linux ABI worse. > > > > For user-defined values of "worse" :) > > > > I tend to agree with Tycho here. But I'm wondering if it might be > worth considering a better ioctl. > > /me dons flame-proof hat > > We could do: > > long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, > const void *outbuf, size_t outlen); > > and have a central table in the kernel listing all possible nr values > along with which driver they belong to. We could have a sane > signature and get rid of the nr collision problem. The essential difference between a regular system call and an ioctl is that in the former, the invoked kernel-side code depends on the operation number, and in the latter, the invoked kernel-side code depends on the operation number and file descriptor type. By creating a new kind of collision-free ioctl, all you've done is re-invent the system call, but with a funky calling convention and less operand space. It makes no sense. Previous system call multiplexers --- e.g., socketcall --- are widely regarded as mistakes, and there's no reason to repeat these mistakes. System call numbers are not scarce, and your other proposal to clean up the x86 numbering will make wiring up a new system call less annoying. The *only* purpose of an ioctl is to solve the system call numbering coordination problem --- if the invoked kernel-side code depends on (DRIVER, OPERATION_NUMBER), and DRIVER can vary out-of-tree with ioctl, ioctl lets out-of-tree code expose interfaces. For in-tree code, this problem doesn't exist, so there's no reason to use the awkward ioctl workaround!
Re: [PATCH] x86/mm/dump_pagetables: Change to use DEFINE_SHOW_ATTRIBUTE macro
Hi Dava:
How about just change the ptdump_fops and ptdump_open?
Yours,
Yangtao
On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
>
> On 11/19/18 7:43 AM, Yangtao Li wrote:
> > -static const struct file_operations ptdump_curusr_fops = {
> > - .owner = THIS_MODULE,
> > - .open = ptdump_open_curusr,
> > - .read = seq_read,
> > - .llseek = seq_lseek,
> > - .release= single_release,
> > -};
> > +DEFINE_SHOW_ATTRIBUTE(ptdump_curusr);
>
> FWIW, I rather dislike this conversion and the DEFINE_SHOW_ATTRIBUTE()
> approach in general. It makes it basically impossible to go from
> ptdump_curusr to ptdump_open_curusr without opening up the macro and
> reverse-engineering it.
>
> My test is that for these macros to be sane, I need to be able to find
> "ptdump_open_curusr" by grepping for "ptdump_curusr". This fails the test.
>
> I don't think saving a few lines of code is worth the obfuscation.
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Mon, Nov 19, 2018 at 4:28 PM Andy Lutomirski wrote: > > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote: > > > These tools also care about ioctls. Adding a system call is a pain, > > > but the solution is to make adding system calls less of a pain, not to > > > permanently make the Linux ABI worse. > > > > For user-defined values of "worse" :) > > > > I tend to agree with Tycho here. But I'm wondering if it might be > worth considering a better ioctl. > > /me dons flame-proof hat > > We could do: > > long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, > const void *outbuf, size_t outlen); > > and have a central table in the kernel listing all possible nr values > along with which driver they belong to. We could have a sane > signature and get rid of the nr collision problem. The essential difference between a regular system call and an ioctl is that in the former, the invoked kernel-side code depends on the operation number, and in the latter, the invoked kernel-side code depends on the operation number and file descriptor type. By creating a new kind of collision-free ioctl, all you've done is re-invent the system call, but with a funky calling convention and less operand space. It makes no sense. Previous system call multiplexers --- e.g., socketcall --- are widely regarded as mistakes, and there's no reason to repeat these mistakes. System call numbers are not scarce, and your other proposal to clean up the x86 numbering will make wiring up a new system call less annoying. The *only* purpose of an ioctl is to solve the system call numbering coordination problem --- if the invoked kernel-side code depends on (DRIVER, OPERATION_NUMBER), and DRIVER can vary out-of-tree with ioctl, ioctl lets out-of-tree code expose interfaces. For in-tree code, this problem doesn't exist, so there's no reason to use the awkward ioctl workaround!
linux-next: build failure after merge of the regulator tree
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "regulator_lock" [drivers/regulator/wm8350-regulator.ko] undefined!
ERROR: "regulator_unlock" [drivers/regulator/wm8350-regulator.ko] undefined!
ERROR: "regulator_unlock" [drivers/regulator/da9210-regulator.ko] undefined!
ERROR: "regulator_lock" [drivers/regulator/da9210-regulator.ko] undefined!
Caused by commit
f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
I have used the regulator tree from next-20181119 for today.
--
Cheers,
Stephen Rothwell
pgpT42Gw0sVkS.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/7] regulator: core: Don't double-disable supplies in regulator_disable_deferred()
On 20.11.2018 3:26, Douglas Anderson wrote:
> In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
> regulators locking") disabling of the supply was moved into
> _regulator_disable(). That means regulator_disable_work() shouldn't
> be disabling since that double-disables the supply.
>
> Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/regulator/core.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 0052bbc8c531..63a8af1e2256 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2703,16 +2703,6 @@ static void regulator_disable_work(struct work_struct
> *work)
> regulator_balance_voltage(rdev, PM_SUSPEND_ON);
>
> regulator_unlock_dependent(rdev, _ctx);
> -
> - if (rdev->supply) {
> - for (i = 0; i < count; i++) {
> - ret = regulator_disable(rdev->supply);
> - if (ret != 0) {
> - rdev_err(rdev,
> - "Supply disable failed: %d\n", ret);
> - }
> - }
> - }
> }
>
> /**
>
Good catch!
Reviewed-by: Dmitry Osipenko
Re: [PATCH 3/7] regulator: core: Don't double-disable supplies in regulator_disable_deferred()
On 20.11.2018 3:26, Douglas Anderson wrote:
> In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
> regulators locking") disabling of the supply was moved into
> _regulator_disable(). That means regulator_disable_work() shouldn't
> be disabling since that double-disables the supply.
>
> Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/regulator/core.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 0052bbc8c531..63a8af1e2256 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2703,16 +2703,6 @@ static void regulator_disable_work(struct work_struct
> *work)
> regulator_balance_voltage(rdev, PM_SUSPEND_ON);
>
> regulator_unlock_dependent(rdev, _ctx);
> -
> - if (rdev->supply) {
> - for (i = 0; i < count; i++) {
> - ret = regulator_disable(rdev->supply);
> - if (ret != 0) {
> - rdev_err(rdev,
> - "Supply disable failed: %d\n", ret);
> - }
> - }
> - }
> }
>
> /**
>
Good catch!
Reviewed-by: Dmitry Osipenko
Re: [PATCH] clk: rockchip: fix ID of 8ch clock of I2S1 for rk3328
Hello, Thank you for applying my patch and sorry for mistake... On 2018年11月19日 22:43, Heiko Stuebner wrote: Am Sonntag, 18. November 2018, 05:18:02 CET schrieb Katsuhiro Suzuki: This patch fixes mistakes in HCLK_I2S1_8CH for running I2S1 successfully. Signed-off-by: Katsuhiro Suzuki --- include/dt-bindings/clock/rk3328-cru.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/dt-bindings/clock/rk3328-cru.h b/include/dt-bindings/clock/rk3328-cru.h index a82a0109faff..bcaa4559ab1b 100644 --- a/include/dt-bindings/clock/rk3328-cru.h +++ b/include/dt-bindings/clock/rk3328-cru.h @@ -172,13 +172,14 @@ #define PCLK_HDCP 232 #define PCLK_DCF 233 #define PCLK_SARADC 234 +#define PCLK_ACODECPHY 235 I've dropped this unrelated change and applied the real id fix from the rest of the patch for 4.21 Thanks Heiko Best Regards, --- Katsuhiro Suzuki
Re: [PATCH] clk: rockchip: fix ID of 8ch clock of I2S1 for rk3328
Hello, Thank you for applying my patch and sorry for mistake... On 2018年11月19日 22:43, Heiko Stuebner wrote: Am Sonntag, 18. November 2018, 05:18:02 CET schrieb Katsuhiro Suzuki: This patch fixes mistakes in HCLK_I2S1_8CH for running I2S1 successfully. Signed-off-by: Katsuhiro Suzuki --- include/dt-bindings/clock/rk3328-cru.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/dt-bindings/clock/rk3328-cru.h b/include/dt-bindings/clock/rk3328-cru.h index a82a0109faff..bcaa4559ab1b 100644 --- a/include/dt-bindings/clock/rk3328-cru.h +++ b/include/dt-bindings/clock/rk3328-cru.h @@ -172,13 +172,14 @@ #define PCLK_HDCP 232 #define PCLK_DCF 233 #define PCLK_SARADC 234 +#define PCLK_ACODECPHY 235 I've dropped this unrelated change and applied the real id fix from the rest of the patch for 4.21 Thanks Heiko Best Regards, --- Katsuhiro Suzuki
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Mon, Nov 19, 2018 at 4:33 PM Christian Brauner wrote: > > On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote: > > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote: > > > > These tools also care about ioctls. Adding a system call is a pain, > > > > but the solution is to make adding system calls less of a pain, not to > > > > permanently make the Linux ABI worse. > > > > > > For user-defined values of "worse" :) > > > > > > > I tend to agree with Tycho here. But I'm wondering if it might be > > worth considering a better ioctl. > > > > /me dons flame-proof hat > > > > We could do: > > > > long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, > > const void *outbuf, size_t outlen); > > I'm the writer of this patch so take this with a grain of salt. > I think it is a bad idea to stop this patch and force us to introduce a > new type of ioctl(). I agree completely. > An ioctl() is also not easy to use for this task because we want to add > a siginfo_t argument which I actually think provides value and makes > this interface more useful. > You could always have a struct procfd_kill and pass a pointer to *that*. But sure, it's ugly.
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Mon, Nov 19, 2018 at 4:33 PM Christian Brauner wrote: > > On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote: > > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote: > > > > These tools also care about ioctls. Adding a system call is a pain, > > > > but the solution is to make adding system calls less of a pain, not to > > > > permanently make the Linux ABI worse. > > > > > > For user-defined values of "worse" :) > > > > > > > I tend to agree with Tycho here. But I'm wondering if it might be > > worth considering a better ioctl. > > > > /me dons flame-proof hat > > > > We could do: > > > > long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, > > const void *outbuf, size_t outlen); > > I'm the writer of this patch so take this with a grain of salt. > I think it is a bad idea to stop this patch and force us to introduce a > new type of ioctl(). I agree completely. > An ioctl() is also not easy to use for this task because we want to add > a siginfo_t argument which I actually think provides value and makes > this interface more useful. > You could always have a struct procfd_kill and pass a pointer to *that*. But sure, it's ugly.
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote: > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote: > > > These tools also care about ioctls. Adding a system call is a pain, > > > but the solution is to make adding system calls less of a pain, not to > > > permanently make the Linux ABI worse. > > > > For user-defined values of "worse" :) > > > > I tend to agree with Tycho here. But I'm wondering if it might be > worth considering a better ioctl. > > /me dons flame-proof hat > > We could do: > > long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, > const void *outbuf, size_t outlen); I'm the writer of this patch so take this with a grain of salt. I think it is a bad idea to stop this patch and force us to introduce a new type of ioctl(). An ioctl() is also not easy to use for this task because we want to add a siginfo_t argument which I actually think provides value and makes this interface more useful. > > and have a central table in the kernel listing all possible nr values > along with which driver they belong to. We could have a sane > signature and get rid of the nr collision problem. > > The major problem I see is that u32 isn't really enough to have a sane > way to allow out-of-tree drivers to use this, and that we can't > readily use anything bigger than u32 without indirection because we're > out of syscall argument space.
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote: > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote: > > > These tools also care about ioctls. Adding a system call is a pain, > > > but the solution is to make adding system calls less of a pain, not to > > > permanently make the Linux ABI worse. > > > > For user-defined values of "worse" :) > > > > I tend to agree with Tycho here. But I'm wondering if it might be > worth considering a better ioctl. > > /me dons flame-proof hat > > We could do: > > long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, > const void *outbuf, size_t outlen); I'm the writer of this patch so take this with a grain of salt. I think it is a bad idea to stop this patch and force us to introduce a new type of ioctl(). An ioctl() is also not easy to use for this task because we want to add a siginfo_t argument which I actually think provides value and makes this interface more useful. > > and have a central table in the kernel listing all possible nr values > along with which driver they belong to. We could have a sane > signature and get rid of the nr collision problem. > > The major problem I see is that u32 isn't really enough to have a sane > way to allow out-of-tree drivers to use this, and that we can't > readily use anything bigger than u32 without indirection because we're > out of syscall argument space.
Re: [PATCH 4.19 000/205] 4.19.3-stable review
On 11/19/18 9:25 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.19.3 release. There are 205 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:24:55 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.3-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.19 000/205] 4.19.3-stable review
On 11/19/18 9:25 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.19.3 release. There are 205 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:24:55 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.3-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Mon, 19 Nov 2018, Tim Chen wrote: > On 11/19/2018 05:32 AM, Thomas Gleixner wrote: > > On Fri, 16 Nov 2018, Tim Chen wrote: > >> The protection mode can be specified by the spectre_v2_app2app > >> boot parameter with the following semantics: > >> > >> spectre_v2_app2app= > >>off- Turn off mitigation > >>lite - Protect processes which are marked non-dumpable > >>strict - Protect all processes > >>auto - Kernel selects the mode > > > > Is there any reason why we need yet another naming convention? > > > > pti=on, off, auto > > > > spectre_v2= on, off, auto > > > > spec_store_bypass_disable = on, off, auto, prctl, seccomp > > The "on" option is set by spectre_v2=on so is not specified here. What has spectre_v2=on to do with spectre_v2_app2app=on? Exactly nothing. You can have 'on' for both. The only side effect of spectre_v2=on is that it also forces spectre_v2_app2app to 'on' irrespective of what eventually was added for spectre_v2_app2app= on the command line. > What will you like to name the "lite" and "strict" option instead? 'prctl' and 'on' and if we add 'seccomp' then this is exactly the same as we have for ssbd. > > Can we please have a full documentation for all the spectre_v2 stuff > > similar to l1tf? > > > Sure. Can we do that as a separate patch? I'll need some time > and internal review for any spectre_v2 documentation that's produced. I'm not taking that stuff without proper documentation. I complained about that vs. L1TF and got told that no sysadmin cares, but L1TF has shown that they care very much and appreciate proper documentation. Nobody can oracle the protection scope out of that inconsistent command line maze. Thanks, tglx
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Mon, 19 Nov 2018, Tim Chen wrote: > On 11/19/2018 05:32 AM, Thomas Gleixner wrote: > > On Fri, 16 Nov 2018, Tim Chen wrote: > >> The protection mode can be specified by the spectre_v2_app2app > >> boot parameter with the following semantics: > >> > >> spectre_v2_app2app= > >>off- Turn off mitigation > >>lite - Protect processes which are marked non-dumpable > >>strict - Protect all processes > >>auto - Kernel selects the mode > > > > Is there any reason why we need yet another naming convention? > > > > pti=on, off, auto > > > > spectre_v2= on, off, auto > > > > spec_store_bypass_disable = on, off, auto, prctl, seccomp > > The "on" option is set by spectre_v2=on so is not specified here. What has spectre_v2=on to do with spectre_v2_app2app=on? Exactly nothing. You can have 'on' for both. The only side effect of spectre_v2=on is that it also forces spectre_v2_app2app to 'on' irrespective of what eventually was added for spectre_v2_app2app= on the command line. > What will you like to name the "lite" and "strict" option instead? 'prctl' and 'on' and if we add 'seccomp' then this is exactly the same as we have for ssbd. > > Can we please have a full documentation for all the spectre_v2 stuff > > similar to l1tf? > > > Sure. Can we do that as a separate patch? I'll need some time > and internal review for any spectre_v2 documentation that's produced. I'm not taking that stuff without proper documentation. I complained about that vs. L1TF and got told that no sysadmin cares, but L1TF has shown that they care very much and appreciate proper documentation. Nobody can oracle the protection scope out of that inconsistent command line maze. Thanks, tglx
Very Important
Hello, My name is ms. Reem Al-Hashimi. The UAE minister of state for international cooparation. I got your contact from a certain email database from your country while i was looking for someone to handle a huge financial transaction for me in confidence. Can you receive and invest on behalf of my only son. Please reply to reem2...@daum.net, for more details if you are interested. Regards, Ms. Reem Al-Hashimy
Very Important
Hello, My name is ms. Reem Al-Hashimi. The UAE minister of state for international cooparation. I got your contact from a certain email database from your country while i was looking for someone to handle a huge financial transaction for me in confidence. Can you receive and invest on behalf of my only son. Please reply to reem2...@daum.net, for more details if you are interested. Regards, Ms. Reem Al-Hashimy
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote: > > These tools also care about ioctls. Adding a system call is a pain, > > but the solution is to make adding system calls less of a pain, not to > > permanently make the Linux ABI worse. > > For user-defined values of "worse" :) > I tend to agree with Tycho here. But I'm wondering if it might be worth considering a better ioctl. /me dons flame-proof hat We could do: long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, const void *outbuf, size_t outlen); and have a central table in the kernel listing all possible nr values along with which driver they belong to. We could have a sane signature and get rid of the nr collision problem. The major problem I see is that u32 isn't really enough to have a sane way to allow out-of-tree drivers to use this, and that we can't readily use anything bigger than u32 without indirection because we're out of syscall argument space.
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote: > > These tools also care about ioctls. Adding a system call is a pain, > > but the solution is to make adding system calls less of a pain, not to > > permanently make the Linux ABI worse. > > For user-defined values of "worse" :) > I tend to agree with Tycho here. But I'm wondering if it might be worth considering a better ioctl. /me dons flame-proof hat We could do: long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, const void *outbuf, size_t outlen); and have a central table in the kernel listing all possible nr values along with which driver they belong to. We could have a sane signature and get rid of the nr collision problem. The major problem I see is that u32 isn't really enough to have a sane way to allow out-of-tree drivers to use this, and that we can't readily use anything bigger than u32 without indirection because we're out of syscall argument space.
[PATCH 3/7] regulator: core: Don't double-disable supplies in regulator_disable_deferred()
In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
regulators locking") disabling of the supply was moved into
_regulator_disable(). That means regulator_disable_work() shouldn't
be disabling since that double-disables the supply.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 0052bbc8c531..63a8af1e2256 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2703,16 +2703,6 @@ static void regulator_disable_work(struct work_struct
*work)
regulator_balance_voltage(rdev, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev, _ctx);
-
- if (rdev->supply) {
- for (i = 0; i < count; i++) {
- ret = regulator_disable(rdev->supply);
- if (ret != 0) {
- rdev_err(rdev,
-"Supply disable failed: %d\n", ret);
- }
- }
- }
}
/**
--
2.19.1.1215.g8438c0b245-goog
[PATCH 3/7] regulator: core: Don't double-disable supplies in regulator_disable_deferred()
In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
regulators locking") disabling of the supply was moved into
_regulator_disable(). That means regulator_disable_work() shouldn't
be disabling since that double-disables the supply.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 0052bbc8c531..63a8af1e2256 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2703,16 +2703,6 @@ static void regulator_disable_work(struct work_struct
*work)
regulator_balance_voltage(rdev, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev, _ctx);
-
- if (rdev->supply) {
- for (i = 0; i < count; i++) {
- ret = regulator_disable(rdev->supply);
- if (ret != 0) {
- rdev_err(rdev,
-"Supply disable failed: %d\n", ret);
- }
- }
- }
}
/**
--
2.19.1.1215.g8438c0b245-goog
[PATCH 6/7] regulator: core: Avoid propagating to supplies when possible
When we called regulator_enable() on a regulator we'd end up
propagating that call all the way up the chain every time. This is a
bit of a waste of time. A child regulator already refcounts its own
enables so it should avoid passing on to its parent unless the
refcount transitioned between 0 and 1.
Historically this hasn't been a huge problem since we skipped dealing
with enable for always-on regulators. In a previous patch, however,
we removed the always-on optimization. On one system, the debugfs
regulator_summary was now showing a "use_count" of 33 for a top-level
regulator.
Let's implement this optimization. This turns out to be fairly
trivial with the recent reorganization of the regulator core.
NOTE: as part of this patch I'll make "always-on" regulators start
with a use count of 1. This keeps the counts clean when recursively
resolving regulators.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 23e852d38b88..2eda87520832 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1822,6 +1822,7 @@ static int regulator_resolve_supply(struct regulator_dev
*rdev)
rdev->supply = NULL;
return ret;
}
+ rdev->use_count = 1;
}
return 0;
@@ -2491,7 +2492,7 @@ static int _regulator_enable(struct regulator *regulator)
lockdep_assert_held_once(>mutex.base);
- if (rdev->supply) {
+ if (rdev->use_count == 0 && rdev->supply) {
ret = _regulator_enable(rdev->supply);
if (ret < 0)
return ret;
@@ -2539,7 +2540,7 @@ static int _regulator_enable(struct regulator *regulator)
_regulator_handle_consumer_disable(regulator);
err_disable_supply:
- if (rdev->supply)
+ if (rdev->use_count == 0 && rdev->supply)
_regulator_disable(rdev->supply);
return ret;
@@ -2648,7 +2649,7 @@ static int _regulator_disable(struct regulator *regulator)
if (ret == 0 && rdev->coupling_desc.n_coupled > 1)
ret = regulator_balance_voltage(rdev, PM_SUSPEND_ON);
- if (ret == 0 && rdev->supply)
+ if (ret == 0 && rdev->use_count == 0 && rdev->supply)
ret = _regulator_disable(rdev->supply);
return ret;
--
2.19.1.1215.g8438c0b245-goog
[PATCH 5/7] regulator: core: add enable_count for consumers to debug fs
Now that consumers all keep track of their own enable count, let's add
it into the regulator_summary.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c5da6079e1cb..23e852d38b88 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -5305,8 +5305,11 @@ static void regulator_summary_show_subtree(struct
seq_file *s,
switch (rdev->desc->type) {
case REGULATOR_VOLTAGE:
- seq_printf(s, "%37dmA %5dmV %5dmV",
+ seq_printf(s, "%3d %33dmA%c%5dmV %5dmV",
+ consumer->enable_count,
consumer->uA_load / 1000,
+ consumer->uA_load && !consumer->enable_count
?
+ '*' : ' ',
consumer->voltage[PM_SUSPEND_ON].min_uV /
1000,
consumer->voltage[PM_SUSPEND_ON].max_uV /
1000);
break;
--
2.19.1.1215.g8438c0b245-goog
[PATCH 4/7] regulator: core: Only count load for enabled consumers
In general when the consumer of a regulator requests that the
regulator be disabled it no longer will be drawing much load from the
regulator--it should just be the leakage current and that should be
very close to 0.
Up to this point the regulator framework has continued to count a
consumer's load request for disabled regulators. This has led to code
patterns that look like this:
enable_my_thing():
regular_set_load(reg, load_uA)
regulator_enable(reg)
disable_my_thing():
regulator_disable(reg)
regulator_set_load(reg, 0)
Sometimgs disable_my_thing() sets a nominal (<= 100 uA) load instead
of setting a 0 uA load. I will make the assertion that nearly all (if
not all) places where we set a nominal load of 100 uA or less we end
up with a result that is the same as if we had set a load of 0 uA.
Specifically:
- The whole point of setting the load is to help set the operating
mode of the regulator. Higher loads may need less efficient
operating modes.
- The only time this matters at all is if there is another consumer of
the regulator that wants the regulator on. If there are no other
consumers of the regulator then the regulator will turn off and we
don't care about the operating mode.
- If there's another consumer that actually wants the regulator on
then presumably it is requesting a load that makes our nominal
<= 100 uA load insignificant.
A quick survey of the existing callers to regulator_set_load() to see
how everyone uses it:
--
Places that set a load of 0 on every disable:
drivers/bluetooth/hci_qca.c
drivers/net/wireless/ath/ath10k/snoc.c
drivers/remoteproc/qcom_q6v5_mss.c
drivers/scsi/ufs/ufshcd.c
Places that set a nominal disable load (<= 100 uA):
drivers/gpu/drm/msm/dsi/dsi_host.c:
git grep -A10 'struct msm_dsi_config' | grep -A10 regs | grep '{.*}'
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:
git grep -A10 'struct msm_dsi_phy_cfg' | grep -A10 regs | grep '{.*}'
drivers/gpu/drm/msm/edp/edp_ctrl.c
Places that appear to continue to request load when disabled; I
believe this is not intentional and is a bug. AKA: either the
regulator will be left in a higher power operating mode sometimes when
it doesn't need to or it is understood that there are no other
consumers of these rails and thus the regulator_set_load() shouldn't
have been needed at all (we should just force the regulator to high
power all the time in that case):
drivers/phy/qualcomm/phy-qcom-ufs.c
drivers/phy/qualcomm/phy-qcom-usb-hs.c
drivers/remoteproc/qcom_q6v5_pas.c
drivers/remoteproc/qcom_wcnss.c (*)
drivers/remoteproc/qcom_wcnss_iris.c
(*) Quick glace makes me feel like this driver is buggy since
wcnss_start() enables regulators but wcnss_stop() doesn't disable
them.
--
Given the above argument, I propose changing the regulator core to
only consider loads from consumers that are currently enabled. If
later we find a use case where we really need to count a non-zero load
when a consumer requests that a regulator be disabled we could just
count load like this in the system_load for the regulator. If somehow
that's not possible I suppose we could add consider adding a new API
regulator_set_disabled_load().
In order to accomplish the above, we need to start tracking the enable
count per regulator consumer (it used to be tracked only globally
across all consumers of a given regulator). This means:
- We can (and will) spit errors out for code that used to be invalid
but was never caught before. Specifically if someone leaves a
regulator enabled and calls regulator_put() we'll yell. We'll also
yell if a single consumer calls more disables than enables.
- We now need to deal with "always-on" regulators slightly
differently. It's assumed that an always-on regulator could still
transition between power modes, so if all of the active consumers of
an always-on regulator don't need the regulator on we should still
remove their requested load from the total. The core used to have
some optimizations where it didn't bother keeping track of the
enable counts for always-on regulators because they were, well,
always on. While we could keep the optimization still for some
cases, it's cleaner to just remove it. A later patch will attempt
to get some efficiency back by not propogating enables up
unnecessarily.
Signed-off-by: Douglas Anderson
---
Please give this patch lots of extra review. It seems to work for me,
but I haven't done massive amounts of stress testing on it and I don't
touch every use case of the regulator core. Thanks!
drivers/regulator/core.c | 190 +++
drivers/regulator/internal.h | 2 +
include/linux/regulator/driver.h | 1 -
3 files changed, 142 insertions(+), 51 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 63a8af1e2256..c5da6079e1cb 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -99,7 +99,7 @@ struct
[PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()
In regulator_force_disable() there was a strange loop that looked like:
while (rdev->open_count--)
regulator_disable(rdev->supply);
I'm not totally sure what the goal was for this loop, but it seems
wrong to me. If anything I think maybe we should have been looping
over our use_count, but even that might be a little strange. For now
let's just remove the code and we can add something back in if someone
can explain what's expected.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2eda87520832..963081aba17a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2738,10 +2738,6 @@ int regulator_force_disable(struct regulator *regulator)
regulator_unlock_dependent(rdev, _ctx);
- if (rdev->supply)
- while (rdev->open_count--)
- regulator_disable(rdev->supply);
-
return ret;
}
EXPORT_SYMBOL_GPL(regulator_force_disable);
--
2.19.1.1215.g8438c0b245-goog
[PATCH 6/7] regulator: core: Avoid propagating to supplies when possible
When we called regulator_enable() on a regulator we'd end up
propagating that call all the way up the chain every time. This is a
bit of a waste of time. A child regulator already refcounts its own
enables so it should avoid passing on to its parent unless the
refcount transitioned between 0 and 1.
Historically this hasn't been a huge problem since we skipped dealing
with enable for always-on regulators. In a previous patch, however,
we removed the always-on optimization. On one system, the debugfs
regulator_summary was now showing a "use_count" of 33 for a top-level
regulator.
Let's implement this optimization. This turns out to be fairly
trivial with the recent reorganization of the regulator core.
NOTE: as part of this patch I'll make "always-on" regulators start
with a use count of 1. This keeps the counts clean when recursively
resolving regulators.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 23e852d38b88..2eda87520832 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1822,6 +1822,7 @@ static int regulator_resolve_supply(struct regulator_dev
*rdev)
rdev->supply = NULL;
return ret;
}
+ rdev->use_count = 1;
}
return 0;
@@ -2491,7 +2492,7 @@ static int _regulator_enable(struct regulator *regulator)
lockdep_assert_held_once(>mutex.base);
- if (rdev->supply) {
+ if (rdev->use_count == 0 && rdev->supply) {
ret = _regulator_enable(rdev->supply);
if (ret < 0)
return ret;
@@ -2539,7 +2540,7 @@ static int _regulator_enable(struct regulator *regulator)
_regulator_handle_consumer_disable(regulator);
err_disable_supply:
- if (rdev->supply)
+ if (rdev->use_count == 0 && rdev->supply)
_regulator_disable(rdev->supply);
return ret;
@@ -2648,7 +2649,7 @@ static int _regulator_disable(struct regulator *regulator)
if (ret == 0 && rdev->coupling_desc.n_coupled > 1)
ret = regulator_balance_voltage(rdev, PM_SUSPEND_ON);
- if (ret == 0 && rdev->supply)
+ if (ret == 0 && rdev->use_count == 0 && rdev->supply)
ret = _regulator_disable(rdev->supply);
return ret;
--
2.19.1.1215.g8438c0b245-goog
[PATCH 5/7] regulator: core: add enable_count for consumers to debug fs
Now that consumers all keep track of their own enable count, let's add
it into the regulator_summary.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c5da6079e1cb..23e852d38b88 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -5305,8 +5305,11 @@ static void regulator_summary_show_subtree(struct
seq_file *s,
switch (rdev->desc->type) {
case REGULATOR_VOLTAGE:
- seq_printf(s, "%37dmA %5dmV %5dmV",
+ seq_printf(s, "%3d %33dmA%c%5dmV %5dmV",
+ consumer->enable_count,
consumer->uA_load / 1000,
+ consumer->uA_load && !consumer->enable_count
?
+ '*' : ' ',
consumer->voltage[PM_SUSPEND_ON].min_uV /
1000,
consumer->voltage[PM_SUSPEND_ON].max_uV /
1000);
break;
--
2.19.1.1215.g8438c0b245-goog
[PATCH 4/7] regulator: core: Only count load for enabled consumers
In general when the consumer of a regulator requests that the
regulator be disabled it no longer will be drawing much load from the
regulator--it should just be the leakage current and that should be
very close to 0.
Up to this point the regulator framework has continued to count a
consumer's load request for disabled regulators. This has led to code
patterns that look like this:
enable_my_thing():
regular_set_load(reg, load_uA)
regulator_enable(reg)
disable_my_thing():
regulator_disable(reg)
regulator_set_load(reg, 0)
Sometimgs disable_my_thing() sets a nominal (<= 100 uA) load instead
of setting a 0 uA load. I will make the assertion that nearly all (if
not all) places where we set a nominal load of 100 uA or less we end
up with a result that is the same as if we had set a load of 0 uA.
Specifically:
- The whole point of setting the load is to help set the operating
mode of the regulator. Higher loads may need less efficient
operating modes.
- The only time this matters at all is if there is another consumer of
the regulator that wants the regulator on. If there are no other
consumers of the regulator then the regulator will turn off and we
don't care about the operating mode.
- If there's another consumer that actually wants the regulator on
then presumably it is requesting a load that makes our nominal
<= 100 uA load insignificant.
A quick survey of the existing callers to regulator_set_load() to see
how everyone uses it:
--
Places that set a load of 0 on every disable:
drivers/bluetooth/hci_qca.c
drivers/net/wireless/ath/ath10k/snoc.c
drivers/remoteproc/qcom_q6v5_mss.c
drivers/scsi/ufs/ufshcd.c
Places that set a nominal disable load (<= 100 uA):
drivers/gpu/drm/msm/dsi/dsi_host.c:
git grep -A10 'struct msm_dsi_config' | grep -A10 regs | grep '{.*}'
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:
git grep -A10 'struct msm_dsi_phy_cfg' | grep -A10 regs | grep '{.*}'
drivers/gpu/drm/msm/edp/edp_ctrl.c
Places that appear to continue to request load when disabled; I
believe this is not intentional and is a bug. AKA: either the
regulator will be left in a higher power operating mode sometimes when
it doesn't need to or it is understood that there are no other
consumers of these rails and thus the regulator_set_load() shouldn't
have been needed at all (we should just force the regulator to high
power all the time in that case):
drivers/phy/qualcomm/phy-qcom-ufs.c
drivers/phy/qualcomm/phy-qcom-usb-hs.c
drivers/remoteproc/qcom_q6v5_pas.c
drivers/remoteproc/qcom_wcnss.c (*)
drivers/remoteproc/qcom_wcnss_iris.c
(*) Quick glace makes me feel like this driver is buggy since
wcnss_start() enables regulators but wcnss_stop() doesn't disable
them.
--
Given the above argument, I propose changing the regulator core to
only consider loads from consumers that are currently enabled. If
later we find a use case where we really need to count a non-zero load
when a consumer requests that a regulator be disabled we could just
count load like this in the system_load for the regulator. If somehow
that's not possible I suppose we could add consider adding a new API
regulator_set_disabled_load().
In order to accomplish the above, we need to start tracking the enable
count per regulator consumer (it used to be tracked only globally
across all consumers of a given regulator). This means:
- We can (and will) spit errors out for code that used to be invalid
but was never caught before. Specifically if someone leaves a
regulator enabled and calls regulator_put() we'll yell. We'll also
yell if a single consumer calls more disables than enables.
- We now need to deal with "always-on" regulators slightly
differently. It's assumed that an always-on regulator could still
transition between power modes, so if all of the active consumers of
an always-on regulator don't need the regulator on we should still
remove their requested load from the total. The core used to have
some optimizations where it didn't bother keeping track of the
enable counts for always-on regulators because they were, well,
always on. While we could keep the optimization still for some
cases, it's cleaner to just remove it. A later patch will attempt
to get some efficiency back by not propogating enables up
unnecessarily.
Signed-off-by: Douglas Anderson
---
Please give this patch lots of extra review. It seems to work for me,
but I haven't done massive amounts of stress testing on it and I don't
touch every use case of the regulator core. Thanks!
drivers/regulator/core.c | 190 +++
drivers/regulator/internal.h | 2 +
include/linux/regulator/driver.h | 1 -
3 files changed, 142 insertions(+), 51 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 63a8af1e2256..c5da6079e1cb 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -99,7 +99,7 @@ struct
[PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()
In regulator_force_disable() there was a strange loop that looked like:
while (rdev->open_count--)
regulator_disable(rdev->supply);
I'm not totally sure what the goal was for this loop, but it seems
wrong to me. If anything I think maybe we should have been looping
over our use_count, but even that might be a little strange. For now
let's just remove the code and we can add something back in if someone
can explain what's expected.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2eda87520832..963081aba17a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2738,10 +2738,6 @@ int regulator_force_disable(struct regulator *regulator)
regulator_unlock_dependent(rdev, _ctx);
- if (rdev->supply)
- while (rdev->open_count--)
- regulator_disable(rdev->supply);
-
return ret;
}
EXPORT_SYMBOL_GPL(regulator_force_disable);
--
2.19.1.1215.g8438c0b245-goog
[PATCH 2/7] regulator: core: Don't assume always_on when is_enabled returns err
At boot sometimes regulators (like qcom-rpmh-regulator) will return
-EINVAL if we don't know the enable state of the regulator. We
shouldn't take this to mean that the regulator is an always-on
regulator, but that was what was happening since "-EINVAL" is non-zero
and a few places in the code were not properly checking for errors.
Let's resolve this.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ff5ca185bb8f..0052bbc8c531 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1622,7 +1622,7 @@ static struct regulator *create_regulator(struct
regulator_dev *rdev,
* enable/disable calls.
*/
if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_STATUS) &&
- _regulator_is_enabled(rdev))
+ _regulator_is_enabled(rdev) > 0)
regulator->always_on = true;
regulator_unlock(rdev);
@@ -1811,7 +1811,7 @@ static int regulator_resolve_supply(struct regulator_dev
*rdev)
}
/* Cascade always-on state to supply */
- if (_regulator_is_enabled(rdev)) {
+ if (_regulator_is_enabled(rdev) > 0) {
ret = regulator_enable(rdev->supply);
if (ret < 0) {
_regulator_put(rdev->supply);
--
2.19.1.1215.g8438c0b245-goog
[PATCH 1/7] regulator: core: Properly expose requested_microamps in sysfs
The "requested_microamps" sysfs attribute was only being exposed for "current" regulators. This didn't make sense. Allow it to be exposed always. Signed-off-by: Douglas Anderson --- drivers/regulator/core.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index d7ffd7b12472..ff5ca185bb8f 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -4565,10 +4565,6 @@ static umode_t regulator_attr_is_visible(struct kobject *kobj, if (attr == _attr_bypass.attr) return ops->get_bypass ? mode : 0; - /* some attributes are type-specific */ - if (attr == _attr_requested_microamps.attr) - return rdev->desc->type == REGULATOR_CURRENT ? mode : 0; - /* constraints need specific supporting methods */ if (attr == _attr_min_microvolts.attr || attr == _attr_max_microvolts.attr) -- 2.19.1.1215.g8438c0b245-goog
[PATCH 1/7] regulator: core: Properly expose requested_microamps in sysfs
The "requested_microamps" sysfs attribute was only being exposed for "current" regulators. This didn't make sense. Allow it to be exposed always. Signed-off-by: Douglas Anderson --- drivers/regulator/core.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index d7ffd7b12472..ff5ca185bb8f 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -4565,10 +4565,6 @@ static umode_t regulator_attr_is_visible(struct kobject *kobj, if (attr == _attr_bypass.attr) return ops->get_bypass ? mode : 0; - /* some attributes are type-specific */ - if (attr == _attr_requested_microamps.attr) - return rdev->desc->type == REGULATOR_CURRENT ? mode : 0; - /* constraints need specific supporting methods */ if (attr == _attr_min_microvolts.attr || attr == _attr_max_microvolts.attr) -- 2.19.1.1215.g8438c0b245-goog
[PATCH 2/7] regulator: core: Don't assume always_on when is_enabled returns err
At boot sometimes regulators (like qcom-rpmh-regulator) will return
-EINVAL if we don't know the enable state of the regulator. We
shouldn't take this to mean that the regulator is an always-on
regulator, but that was what was happening since "-EINVAL" is non-zero
and a few places in the code were not properly checking for errors.
Let's resolve this.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ff5ca185bb8f..0052bbc8c531 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1622,7 +1622,7 @@ static struct regulator *create_regulator(struct
regulator_dev *rdev,
* enable/disable calls.
*/
if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_STATUS) &&
- _regulator_is_enabled(rdev))
+ _regulator_is_enabled(rdev) > 0)
regulator->always_on = true;
regulator_unlock(rdev);
@@ -1811,7 +1811,7 @@ static int regulator_resolve_supply(struct regulator_dev
*rdev)
}
/* Cascade always-on state to supply */
- if (_regulator_is_enabled(rdev)) {
+ if (_regulator_is_enabled(rdev) > 0) {
ret = regulator_enable(rdev->supply);
if (ret < 0) {
_regulator_put(rdev->supply);
--
2.19.1.1215.g8438c0b245-goog
Re: [PATCH 4.18 000/171] 4.18.20-stable review
On 11/19/18 9:26 AM, Greg Kroah-Hartman wrote: -- NOTE, this is going to be the last 4.18.y release. After this one it is end-of-life, please move to 4.19.y at this point in time. -- This is the start of the stable review cycle for the 4.18.20 release. There are 171 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:02 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.20-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.18 000/171] 4.18.20-stable review
On 11/19/18 9:26 AM, Greg Kroah-Hartman wrote: -- NOTE, this is going to be the last 4.18.y release. After this one it is end-of-life, please move to 4.19.y at this point in time. -- This is the start of the stable review cycle for the 4.18.20 release. There are 171 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:02 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.20-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On 11/19/2018 04:00 PM, Thomas Gleixner wrote:
> On Tue, 20 Nov 2018, Jiri Kosina wrote:
>
>> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>>
>>> What? IBPB makes tons of sense even without STIBP.
>>
>> On non-SMT, yes. But this patchset ties those two the other (sensible) way
>> around AFAICS ("STIBP iff (IBPB && SMT)").
>
> Errm. No.
>
> The patches disable IBPB if STIBP is not available and that has absolutely
> nothing to do with SMT simply because the static key controlling IBPB is
> only flipped on when both IBPB and STIBP are available.
Ok, I assume you will like this change
@@ -560,7 +559,7 @@ static void __init spectre_v2_select_mitigation(void)
}
app2app_mode = SPECTRE_V2_APP2APP_NONE;
- if (!boot_cpu_has(X86_FEATURE_IBPB) ||
+ if (!boot_cpu_has(X86_FEATURE_IBPB) &&
!boot_cpu_has(X86_FEATURE_STIBP))
goto set_app2app_mode;
before setting the IBPB feature. So we will still do the
IBPB feature set even if STIBP feature is unavailable.
/*
* Initialize Indirect Branch Prediction Barrier if supported
* and not disabled explicitly
*/
if (app2app_mode != SPECTRE_V2_APP2APP_NONE) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
pr_info("Spectre v2 mitigation: Enabling Indirect Branch
Prediction Barrier\n");
}
In that case I'll need to add a static_cpu_has feature flag check when
we are using STIBP and can't assume that when lite mode is on, STIBP is there.
We already check the cpu feature flag in IBPB path so we're good there.
When I first wrote the code, I had in mind that CPU that has one will have
the other. But that assumption is best avoided.
Tim
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On 11/19/2018 04:00 PM, Thomas Gleixner wrote:
> On Tue, 20 Nov 2018, Jiri Kosina wrote:
>
>> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>>
>>> What? IBPB makes tons of sense even without STIBP.
>>
>> On non-SMT, yes. But this patchset ties those two the other (sensible) way
>> around AFAICS ("STIBP iff (IBPB && SMT)").
>
> Errm. No.
>
> The patches disable IBPB if STIBP is not available and that has absolutely
> nothing to do with SMT simply because the static key controlling IBPB is
> only flipped on when both IBPB and STIBP are available.
Ok, I assume you will like this change
@@ -560,7 +559,7 @@ static void __init spectre_v2_select_mitigation(void)
}
app2app_mode = SPECTRE_V2_APP2APP_NONE;
- if (!boot_cpu_has(X86_FEATURE_IBPB) ||
+ if (!boot_cpu_has(X86_FEATURE_IBPB) &&
!boot_cpu_has(X86_FEATURE_STIBP))
goto set_app2app_mode;
before setting the IBPB feature. So we will still do the
IBPB feature set even if STIBP feature is unavailable.
/*
* Initialize Indirect Branch Prediction Barrier if supported
* and not disabled explicitly
*/
if (app2app_mode != SPECTRE_V2_APP2APP_NONE) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
pr_info("Spectre v2 mitigation: Enabling Indirect Branch
Prediction Barrier\n");
}
In that case I'll need to add a static_cpu_has feature flag check when
we are using STIBP and can't assume that when lite mode is on, STIBP is there.
We already check the cpu feature flag in IBPB path so we're good there.
When I first wrote the code, I had in mind that CPU that has one will have
the other. But that assumption is best avoided.
Tim
Re: [PATCH V4] binder: ipc namespace support for android binder
On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote: > On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org > wrote: > ... > > > > A number of us have talked about this in the plumbers Android track, and > > a different proposal for how to solve this has been made that should be > > much more resiliant. So I will drop this patch from my queue and wait > > for the patches based on the discussions we had there. > > > > I think there's some notes/slides on the discussion online somewhere, > > but it hasn't been published as the conference is still happening, > > otherwise I would link to it here... > > Here is a link to the session where you can look at the slides [1]. > There was consensus that "binderfs" (slide 5) was the most promising > -- but would be behind a config option to provide backwards > compatibility for non-container use-cases. > > The etherpad notes are at [2] (look at "Dynamically Allocated Binder > Devices" section) > > Christian Brauner will be sending out more details. Ok, sorry for the delay I got caught up in other work. The idea is to implement binderfs which I'm starting to work on. binderfs will be a separate pseudo-filesystem that will be mountable per-ipc namespace. This has the advantage that the ipc namespace is attached to the superblock of the mount and can be easily retrieved by the binder driver. It also implies that - in contrast to the proposed patch here - an open() on a given binder device will not be able to change the ipc namespace of said devices. The obvious corollary is that you can bind-mount binder devices or the whole binderfs mount between different ipc namespaces and given the right permissions (CAP_IPC_OWNER in the owning userns of the ipcns) can see services on the host which is something that people wanted to be able to do. Additionally, each binderfs mount will come with a binder-control device. This device is functionally similar to loop-control and will allow for dynamic allocation (and possibly deallocation) of binder devices. With this we can remove the restriction to hard-code the number of binder devices at compile time. Backwards compatibility can either be guaranteed by hiding binderfs behind a compile flag or by special-casing the inital binderfs mount to pre-create the standard binder devices. The jury is still out on this. Christian > > -Todd > > [1] https://linuxplumbersconf.org/event/2/contributions/222/ > [2] https://etherpad.openstack.org/p/Android > > > > > thanks, > > > > greg k-h
Re: [PATCH V4] binder: ipc namespace support for android binder
On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote: > On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org > wrote: > ... > > > > A number of us have talked about this in the plumbers Android track, and > > a different proposal for how to solve this has been made that should be > > much more resiliant. So I will drop this patch from my queue and wait > > for the patches based on the discussions we had there. > > > > I think there's some notes/slides on the discussion online somewhere, > > but it hasn't been published as the conference is still happening, > > otherwise I would link to it here... > > Here is a link to the session where you can look at the slides [1]. > There was consensus that "binderfs" (slide 5) was the most promising > -- but would be behind a config option to provide backwards > compatibility for non-container use-cases. > > The etherpad notes are at [2] (look at "Dynamically Allocated Binder > Devices" section) > > Christian Brauner will be sending out more details. Ok, sorry for the delay I got caught up in other work. The idea is to implement binderfs which I'm starting to work on. binderfs will be a separate pseudo-filesystem that will be mountable per-ipc namespace. This has the advantage that the ipc namespace is attached to the superblock of the mount and can be easily retrieved by the binder driver. It also implies that - in contrast to the proposed patch here - an open() on a given binder device will not be able to change the ipc namespace of said devices. The obvious corollary is that you can bind-mount binder devices or the whole binderfs mount between different ipc namespaces and given the right permissions (CAP_IPC_OWNER in the owning userns of the ipcns) can see services on the host which is something that people wanted to be able to do. Additionally, each binderfs mount will come with a binder-control device. This device is functionally similar to loop-control and will allow for dynamic allocation (and possibly deallocation) of binder devices. With this we can remove the restriction to hard-code the number of binder devices at compile time. Backwards compatibility can either be guaranteed by hiding binderfs behind a compile flag or by special-casing the inital binderfs mount to pre-create the standard binder devices. The jury is still out on this. Christian > > -Todd > > [1] https://linuxplumbersconf.org/event/2/contributions/222/ > [2] https://etherpad.openstack.org/p/Android > > > > > thanks, > > > > greg k-h
Cleaning up numbering for new x86 syscalls?
Hi all- We currently have some giant turds in the way that syscalls are numbered. We have the x86_32 table, which is totally sane other than some legacy multiplexers. Then we have the x86_64 table, which is, um, demented: - The numbers don't match x86_32. I have no idea why. - We use bit 30, which triggers in_x32_syscall(). It should have been bit 31, bit I digress. - We have this weird set of extra x32 syscalls that start at 512. Who wants to bet whether we have no bugs if someone does syscall with, say, nr == 512 (i.e. not 512 | BIT(30)) or nr == (16 | BIT(30))? The latter would be non-compat ioctl with in_x32_syscall() set and hence in_compat_syscall() set. - Bloody restart_syscall() has a different number on x86_64 and x64_32, which is a big mess. I propose we consider some subset of the following: 1. Introduce restart_syscall_2(). Make its number be 1024. Maybe someday we could start using it instead of restart_syscall(). The only issue I can see is programs that allow restart_syscall() using seccomp but don't allow the new variant. 2. Introduce an outright ban on new syscalls with nr < 1024. 3. Introduce an outright ban on the addition of new __x32_compat syscalls. If new compat hacks are needed, they can use in_compat_syscall(), thank you very much. 4. Modify the wrappers of the __x32_compat entries so that they will return -ENOSYS if in_x32_syscall() returns false. 5. Adjust the scripts so that we only have to wire up new syscalls once. They'll have a nr above 1024, and they'll have the same nr on all x86 variants. Thoughts?
Cleaning up numbering for new x86 syscalls?
Hi all- We currently have some giant turds in the way that syscalls are numbered. We have the x86_32 table, which is totally sane other than some legacy multiplexers. Then we have the x86_64 table, which is, um, demented: - The numbers don't match x86_32. I have no idea why. - We use bit 30, which triggers in_x32_syscall(). It should have been bit 31, bit I digress. - We have this weird set of extra x32 syscalls that start at 512. Who wants to bet whether we have no bugs if someone does syscall with, say, nr == 512 (i.e. not 512 | BIT(30)) or nr == (16 | BIT(30))? The latter would be non-compat ioctl with in_x32_syscall() set and hence in_compat_syscall() set. - Bloody restart_syscall() has a different number on x86_64 and x64_32, which is a big mess. I propose we consider some subset of the following: 1. Introduce restart_syscall_2(). Make its number be 1024. Maybe someday we could start using it instead of restart_syscall(). The only issue I can see is programs that allow restart_syscall() using seccomp but don't allow the new variant. 2. Introduce an outright ban on new syscalls with nr < 1024. 3. Introduce an outright ban on the addition of new __x32_compat syscalls. If new compat hacks are needed, they can use in_compat_syscall(), thank you very much. 4. Modify the wrappers of the __x32_compat entries so that they will return -ENOSYS if in_x32_syscall() returns false. 5. Adjust the scripts so that we only have to wire up new syscalls once. They'll have a nr above 1024, and they'll have the same nr on all x86 variants. Thoughts?
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Mon, 19 Nov 2018, Andrea Arcangeli wrote: > On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote: > > Here's the current description: > > > > > Setting ... STIBP ... on a logical processor prevents the predicted > > > targets of indirect branches on any logical processor of that core > ^^^ > > > from being controlled by software that executes (or executed > > > previously) on another logical processor of the same core. >^^^ > > > > 1. > > https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors > > I'm not used to official specs in a "insight & deep dive" > blog-post-like webpage, so I didn't notice this deep dive detail. But you might have noticed the wording in: Speculative Execution Side Channel Mitigations Revision 2.0 May 2018 which says: Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor prevents the predicted targets of indirect branches on any logical processor of that core from being controlled by software that executes (or executed previously) on another logical processor of the same core. i.e. exactly what Dave quoted from the deep dive thingy. > You use "any" vs "any" but the spec you quoted still says "any" vs > "another". > > If I shall take the above literally it still means that if I set STIBP > inside SECCOMP, as long as it's set, it prevents indirect branches of > all siblings to be controlled from code outside the SECCOMP jail > running in another sibling (or that run previously in another > sibling). I.e. the "deep dive" stronger semantics of STIBP just mean > the code outside SECCOMP cannot attack itself while the code inside > SECCOMP runs and keeps STIBP set. The point is that when you enable STIBP on any sibling then all siblings of the same core are protected against each other simply because the predictor is shared. Otherwise you would hardly have sibling to sibling influence. Yes, I agree the documentation is lousy, but I also agree with the interpretation from Dave, Andi and Tim. > If this is clarified the concern that remains is that lots of > potentially performance critical stuff runs under SECCOMP but of > course it changes everything in terms of possibly enabling STIBP under > SECCOMP by default, it certainly would make more sense then. Right. If this holds, which I assume, then enabling it for seccomp tasks would make sense. Thanks, tglx
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Mon, 19 Nov 2018, Andrea Arcangeli wrote: > On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote: > > Here's the current description: > > > > > Setting ... STIBP ... on a logical processor prevents the predicted > > > targets of indirect branches on any logical processor of that core > ^^^ > > > from being controlled by software that executes (or executed > > > previously) on another logical processor of the same core. >^^^ > > > > 1. > > https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors > > I'm not used to official specs in a "insight & deep dive" > blog-post-like webpage, so I didn't notice this deep dive detail. But you might have noticed the wording in: Speculative Execution Side Channel Mitigations Revision 2.0 May 2018 which says: Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor prevents the predicted targets of indirect branches on any logical processor of that core from being controlled by software that executes (or executed previously) on another logical processor of the same core. i.e. exactly what Dave quoted from the deep dive thingy. > You use "any" vs "any" but the spec you quoted still says "any" vs > "another". > > If I shall take the above literally it still means that if I set STIBP > inside SECCOMP, as long as it's set, it prevents indirect branches of > all siblings to be controlled from code outside the SECCOMP jail > running in another sibling (or that run previously in another > sibling). I.e. the "deep dive" stronger semantics of STIBP just mean > the code outside SECCOMP cannot attack itself while the code inside > SECCOMP runs and keeps STIBP set. The point is that when you enable STIBP on any sibling then all siblings of the same core are protected against each other simply because the predictor is shared. Otherwise you would hardly have sibling to sibling influence. Yes, I agree the documentation is lousy, but I also agree with the interpretation from Dave, Andi and Tim. > If this is clarified the concern that remains is that lots of > potentially performance critical stuff runs under SECCOMP but of > course it changes everything in terms of possibly enabling STIBP under > SECCOMP by default, it certainly would make more sense then. Right. If this holds, which I assume, then enabling it for seccomp tasks would make sense. Thanks, tglx
Re: [PATCH 4.14 000/124] 4.14.82-stable review
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.82 release. There are 124 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:07 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.82-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.14 000/124] 4.14.82-stable review
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.82 release. There are 124 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:07 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.82-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.9 00/83] 4.9.138-stable review
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.138 release. There are 83 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:13 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.138-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
[PATCH v2 11/15] nds32: define syscall_get_arch()
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since [PATCH 10/13 v2]
arch/nds32/include/asm/syscall.h | 8
include/uapi/linux/audit.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/arch/nds32/include/asm/syscall.h b/arch/nds32/include/asm/syscall.h
index f7e5e86765fe..569149ca25da 100644
--- a/arch/nds32/include/asm/syscall.h
+++ b/arch/nds32/include/asm/syscall.h
@@ -5,6 +5,7 @@
#ifndef _ASM_NDS32_SYSCALL_H
#define _ASM_NDS32_SYSCALL_H 1
+#include
#include
struct task_struct;
struct pt_regs;
@@ -185,4 +186,11 @@ void syscall_set_arguments(struct task_struct *task,
struct pt_regs *regs,
memcpy(>uregs[0] + i, args, n * sizeof(args[0]));
}
+
+static inline int syscall_get_arch(void)
+{
+ return IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)
+ ? AUDIT_ARCH_NDS32BE : AUDIT_ARCH_NDS32;
+}
+
#endif /* _ASM_NDS32_SYSCALL_H */
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 421953fc2f13..b9ce3016e85b 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -400,6 +400,8 @@ enum {
#define AUDIT_ARCH_MIPSEL64(EM_MIPS|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
#define AUDIT_ARCH_MIPSEL64N32 (EM_MIPS|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE|\
__AUDIT_ARCH_CONVENTION_MIPS64_N32)
+#define AUDIT_ARCH_NDS32 (EM_NDS32|__AUDIT_ARCH_LE)
+#define AUDIT_ARCH_NDS32BE (EM_NDS32)
#define AUDIT_ARCH_OPENRISC(EM_OPENRISC)
#define AUDIT_ARCH_PARISC (EM_PARISC)
#define AUDIT_ARCH_PARISC64(EM_PARISC|__AUDIT_ARCH_64BIT)
--
ldv
Re: [PATCH 4.9 00/83] 4.9.138-stable review
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.138 release. There are 83 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:13 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.138-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
[PATCH v2 11/15] nds32: define syscall_get_arch()
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since [PATCH 10/13 v2]
arch/nds32/include/asm/syscall.h | 8
include/uapi/linux/audit.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/arch/nds32/include/asm/syscall.h b/arch/nds32/include/asm/syscall.h
index f7e5e86765fe..569149ca25da 100644
--- a/arch/nds32/include/asm/syscall.h
+++ b/arch/nds32/include/asm/syscall.h
@@ -5,6 +5,7 @@
#ifndef _ASM_NDS32_SYSCALL_H
#define _ASM_NDS32_SYSCALL_H 1
+#include
#include
struct task_struct;
struct pt_regs;
@@ -185,4 +186,11 @@ void syscall_set_arguments(struct task_struct *task,
struct pt_regs *regs,
memcpy(>uregs[0] + i, args, n * sizeof(args[0]));
}
+
+static inline int syscall_get_arch(void)
+{
+ return IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)
+ ? AUDIT_ARCH_NDS32BE : AUDIT_ARCH_NDS32;
+}
+
#endif /* _ASM_NDS32_SYSCALL_H */
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 421953fc2f13..b9ce3016e85b 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -400,6 +400,8 @@ enum {
#define AUDIT_ARCH_MIPSEL64(EM_MIPS|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
#define AUDIT_ARCH_MIPSEL64N32 (EM_MIPS|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE|\
__AUDIT_ARCH_CONVENTION_MIPS64_N32)
+#define AUDIT_ARCH_NDS32 (EM_NDS32|__AUDIT_ARCH_LE)
+#define AUDIT_ARCH_NDS32BE (EM_NDS32)
#define AUDIT_ARCH_OPENRISC(EM_OPENRISC)
#define AUDIT_ARCH_PARISC (EM_PARISC)
#define AUDIT_ARCH_PARISC64(EM_PARISC|__AUDIT_ARCH_64BIT)
--
ldv
[PATCH v2 04/15] elf-em.h: add EM_NDS32
The uapi/linux/audit.h header is going to use EM_NDS32 in order to define AUDIT_ARCH_NDS32 which is needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. The value for EM_NDS32 has been taken from http://www.sco.com/developers/gabi/2012-12-31/ch4.eheader.html Signed-off-by: Dmitry V. Levin --- v2: unchanged since v1 include/uapi/linux/elf-em.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index a4fba79abbb9..ba2e64cdbb6f 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -40,6 +40,8 @@ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ #define EM_TI_C6000140 /* TI C6X DSPs */ #define EM_HEXAGON 164 /* QUALCOMM Hexagon */ +#define EM_NDS32 167 /* Andes Technology compact code size + embedded RISC processor family */ #define EM_AARCH64 183 /* ARM 64 bit */ #define EM_TILEPRO 188 /* Tilera TILEPro */ #define EM_MICROBLAZE 189 /* Xilinx MicroBlaze */ -- ldv
[PATCH v2 04/15] elf-em.h: add EM_NDS32
The uapi/linux/audit.h header is going to use EM_NDS32 in order to define AUDIT_ARCH_NDS32 which is needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. The value for EM_NDS32 has been taken from http://www.sco.com/developers/gabi/2012-12-31/ch4.eheader.html Signed-off-by: Dmitry V. Levin --- v2: unchanged since v1 include/uapi/linux/elf-em.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index a4fba79abbb9..ba2e64cdbb6f 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -40,6 +40,8 @@ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ #define EM_TI_C6000140 /* TI C6X DSPs */ #define EM_HEXAGON 164 /* QUALCOMM Hexagon */ +#define EM_NDS32 167 /* Andes Technology compact code size + embedded RISC processor family */ #define EM_AARCH64 183 /* ARM 64 bit */ #define EM_TILEPRO 188 /* Tilera TILEPro */ #define EM_MICROBLAZE 189 /* Xilinx MicroBlaze */ -- ldv
[PATCH v2 05/15] elf-em.h: add EM_XTENSA
The uapi/linux/audit.h header is going to use EM_XTENSA in order to define AUDIT_ARCH_XTENSA which is needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. The value for EM_XTENSA has been taken from http://www.sco.com/developers/gabi/2012-12-31/ch4.eheader.html Signed-off-by: Dmitry V. Levin Reviewed-by: Max Filippov --- v2: added Reviewed-by to v1 include/uapi/linux/elf-em.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index ba2e64cdbb6f..7b02cf339d8f 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -35,6 +35,7 @@ #define EM_MN10300 89 /* Panasonic/MEI MN10300, AM33 */ #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor */ #define EM_ARCOMPACT 93 /* ARCompact processor */ +#define EM_XTENSA 94 /* Tensilica Xtensa Architecture */ #define EM_BLACKFIN 106 /* ADI Blackfin Processor */ #define EM_UNICORE 110 /* UniCore-32 */ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ -- ldv
[PATCH v2 06/15] m68k: define syscall_get_arch()
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since v1
arch/m68k/include/asm/syscall.h | 12
1 file changed, 12 insertions(+)
create mode 100644 arch/m68k/include/asm/syscall.h
diff --git a/arch/m68k/include/asm/syscall.h b/arch/m68k/include/asm/syscall.h
new file mode 100644
index ..d4d7deda8d50
--- /dev/null
+++ b/arch/m68k/include/asm/syscall.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_M68K_SYSCALL_H
+#define _ASM_M68K_SYSCALL_H
+
+#include
+
+static inline int syscall_get_arch(void)
+{
+ return AUDIT_ARCH_M68K;
+}
+
+#endif /* _ASM_M68K_SYSCALL_H */
--
ldv
[PATCH v2 05/15] elf-em.h: add EM_XTENSA
The uapi/linux/audit.h header is going to use EM_XTENSA in order to define AUDIT_ARCH_XTENSA which is needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. The value for EM_XTENSA has been taken from http://www.sco.com/developers/gabi/2012-12-31/ch4.eheader.html Signed-off-by: Dmitry V. Levin Reviewed-by: Max Filippov --- v2: added Reviewed-by to v1 include/uapi/linux/elf-em.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index ba2e64cdbb6f..7b02cf339d8f 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -35,6 +35,7 @@ #define EM_MN10300 89 /* Panasonic/MEI MN10300, AM33 */ #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor */ #define EM_ARCOMPACT 93 /* ARCompact processor */ +#define EM_XTENSA 94 /* Tensilica Xtensa Architecture */ #define EM_BLACKFIN 106 /* ADI Blackfin Processor */ #define EM_UNICORE 110 /* UniCore-32 */ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ -- ldv
[PATCH v2 06/15] m68k: define syscall_get_arch()
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since v1
arch/m68k/include/asm/syscall.h | 12
1 file changed, 12 insertions(+)
create mode 100644 arch/m68k/include/asm/syscall.h
diff --git a/arch/m68k/include/asm/syscall.h b/arch/m68k/include/asm/syscall.h
new file mode 100644
index ..d4d7deda8d50
--- /dev/null
+++ b/arch/m68k/include/asm/syscall.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_M68K_SYSCALL_H
+#define _ASM_M68K_SYSCALL_H
+
+#include
+
+static inline int syscall_get_arch(void)
+{
+ return AUDIT_ARCH_M68K;
+}
+
+#endif /* _ASM_M68K_SYSCALL_H */
--
ldv
[PATCH v2 03/15] Move EM_UNICORE to uapi/linux/elf-em.h
This should never have been defined in the arch tree to begin with, and now uapi/linux/audit.h header is going to use EM_UNICORE in order to define AUDIT_ARCH_UNICORE which is needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Signed-off-by: Dmitry V. Levin --- v2: unchanged since v1 arch/unicore32/include/asm/elf.h | 3 +-- include/uapi/linux/elf-em.h | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/unicore32/include/asm/elf.h b/arch/unicore32/include/asm/elf.h index 829042d07722..ae66dc1be49e 100644 --- a/arch/unicore32/include/asm/elf.h +++ b/arch/unicore32/include/asm/elf.h @@ -19,6 +19,7 @@ * ELF register definitions.. */ #include +#include typedef unsigned long elf_greg_t; typedef unsigned long elf_freg_t[3]; @@ -28,8 +29,6 @@ typedef elf_greg_t elf_gregset_t[ELF_NGREG]; typedef struct fp_state elf_fpregset_t; -#define EM_UNICORE 110 - #define R_UNICORE_NONE 0 #define R_UNICORE_PC24 1 #define R_UNICORE_ABS322 diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index 91b33833630b..a4fba79abbb9 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -36,6 +36,7 @@ #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor */ #define EM_ARCOMPACT 93 /* ARCompact processor */ #define EM_BLACKFIN 106 /* ADI Blackfin Processor */ +#define EM_UNICORE 110 /* UniCore-32 */ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ #define EM_TI_C6000140 /* TI C6X DSPs */ #define EM_HEXAGON 164 /* QUALCOMM Hexagon */ -- ldv
[PATCH v2 02/15] Move EM_ARCOMPACT and EM_ARCV2 to uapi/linux/elf-em.h
These should never have been defined in the arch tree to begin with, and now uapi/linux/audit.h header is going to use EM_ARCOMPACT and EM_ARCV2 in order to define AUDIT_ARCH_ARCOMPACT and AUDIT_ARCH_ARCV2 which are needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Signed-off-by: Dmitry V. Levin Acked-by: Vineet Gupta --- v2: added Acked-by to [PATCH 02/13 v2] arch/arc/include/asm/elf.h | 6 +- include/uapi/linux/elf-em.h | 2 ++ 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/arc/include/asm/elf.h b/arch/arc/include/asm/elf.h index aa2d6da9d187..2b80c184c9c8 100644 --- a/arch/arc/include/asm/elf.h +++ b/arch/arc/include/asm/elf.h @@ -10,13 +10,9 @@ #define __ASM_ARC_ELF_H #include +#include #include -/* These ELF defines belong to uapi but libc elf.h already defines them */ -#define EM_ARCOMPACT 93 - -#define EM_ARCV2 195 /* ARCv2 Cores */ - #define EM_ARC_INUSE (IS_ENABLED(CONFIG_ISA_ARCOMPACT) ? \ EM_ARCOMPACT : EM_ARCV2) diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index ba3696e3d694..91b33833630b 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -34,6 +34,7 @@ #define EM_M32R88 /* Renesas M32R */ #define EM_MN10300 89 /* Panasonic/MEI MN10300, AM33 */ #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor */ +#define EM_ARCOMPACT 93 /* ARCompact processor */ #define EM_BLACKFIN 106 /* ADI Blackfin Processor */ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ #define EM_TI_C6000140 /* TI C6X DSPs */ @@ -42,6 +43,7 @@ #define EM_TILEPRO 188 /* Tilera TILEPro */ #define EM_MICROBLAZE 189 /* Xilinx MicroBlaze */ #define EM_TILEGX 191 /* Tilera TILE-Gx */ +#define EM_ARCV2 195 /* ARCv2 Cores */ #define EM_RISCV 243 /* RISC-V */ #define EM_BPF 247 /* Linux BPF - in-kernel virtual machine */ #define EM_FRV 0x5441 /* Fujitsu FR-V */ -- ldv
[PATCH v2 01/15] Move EM_HEXAGON to uapi/linux/elf-em.h
This should never have been defined in the arch tree to begin with, and now uapi/linux/audit.h header is going to use EM_HEXAGON in order to define AUDIT_ARCH_HEXAGON which is needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Signed-off-by: Dmitry V. Levin --- v2: unchanged since v1 arch/hexagon/include/asm/elf.h | 6 +- include/uapi/linux/elf-em.h| 1 + 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/hexagon/include/asm/elf.h b/arch/hexagon/include/asm/elf.h index 80311e7b8ca6..d10fbd54ae51 100644 --- a/arch/hexagon/include/asm/elf.h +++ b/arch/hexagon/include/asm/elf.h @@ -23,11 +23,7 @@ #include #include - -/* - * This should really be in linux/elf-em.h. - */ -#define EM_HEXAGON 164 /* QUALCOMM Hexagon */ +#include struct elf32_hdr; diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index 93722e60204c..ba3696e3d694 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -37,6 +37,7 @@ #define EM_BLACKFIN 106 /* ADI Blackfin Processor */ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ #define EM_TI_C6000140 /* TI C6X DSPs */ +#define EM_HEXAGON 164 /* QUALCOMM Hexagon */ #define EM_AARCH64 183 /* ARM 64 bit */ #define EM_TILEPRO 188 /* Tilera TILEPro */ #define EM_MICROBLAZE 189 /* Xilinx MicroBlaze */ -- ldv
[PATCH v2 03/15] Move EM_UNICORE to uapi/linux/elf-em.h
This should never have been defined in the arch tree to begin with, and now uapi/linux/audit.h header is going to use EM_UNICORE in order to define AUDIT_ARCH_UNICORE which is needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Signed-off-by: Dmitry V. Levin --- v2: unchanged since v1 arch/unicore32/include/asm/elf.h | 3 +-- include/uapi/linux/elf-em.h | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/unicore32/include/asm/elf.h b/arch/unicore32/include/asm/elf.h index 829042d07722..ae66dc1be49e 100644 --- a/arch/unicore32/include/asm/elf.h +++ b/arch/unicore32/include/asm/elf.h @@ -19,6 +19,7 @@ * ELF register definitions.. */ #include +#include typedef unsigned long elf_greg_t; typedef unsigned long elf_freg_t[3]; @@ -28,8 +29,6 @@ typedef elf_greg_t elf_gregset_t[ELF_NGREG]; typedef struct fp_state elf_fpregset_t; -#define EM_UNICORE 110 - #define R_UNICORE_NONE 0 #define R_UNICORE_PC24 1 #define R_UNICORE_ABS322 diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index 91b33833630b..a4fba79abbb9 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -36,6 +36,7 @@ #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor */ #define EM_ARCOMPACT 93 /* ARCompact processor */ #define EM_BLACKFIN 106 /* ADI Blackfin Processor */ +#define EM_UNICORE 110 /* UniCore-32 */ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ #define EM_TI_C6000140 /* TI C6X DSPs */ #define EM_HEXAGON 164 /* QUALCOMM Hexagon */ -- ldv
[PATCH v2 02/15] Move EM_ARCOMPACT and EM_ARCV2 to uapi/linux/elf-em.h
These should never have been defined in the arch tree to begin with, and now uapi/linux/audit.h header is going to use EM_ARCOMPACT and EM_ARCV2 in order to define AUDIT_ARCH_ARCOMPACT and AUDIT_ARCH_ARCV2 which are needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Signed-off-by: Dmitry V. Levin Acked-by: Vineet Gupta --- v2: added Acked-by to [PATCH 02/13 v2] arch/arc/include/asm/elf.h | 6 +- include/uapi/linux/elf-em.h | 2 ++ 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/arc/include/asm/elf.h b/arch/arc/include/asm/elf.h index aa2d6da9d187..2b80c184c9c8 100644 --- a/arch/arc/include/asm/elf.h +++ b/arch/arc/include/asm/elf.h @@ -10,13 +10,9 @@ #define __ASM_ARC_ELF_H #include +#include #include -/* These ELF defines belong to uapi but libc elf.h already defines them */ -#define EM_ARCOMPACT 93 - -#define EM_ARCV2 195 /* ARCv2 Cores */ - #define EM_ARC_INUSE (IS_ENABLED(CONFIG_ISA_ARCOMPACT) ? \ EM_ARCOMPACT : EM_ARCV2) diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index ba3696e3d694..91b33833630b 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -34,6 +34,7 @@ #define EM_M32R88 /* Renesas M32R */ #define EM_MN10300 89 /* Panasonic/MEI MN10300, AM33 */ #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor */ +#define EM_ARCOMPACT 93 /* ARCompact processor */ #define EM_BLACKFIN 106 /* ADI Blackfin Processor */ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ #define EM_TI_C6000140 /* TI C6X DSPs */ @@ -42,6 +43,7 @@ #define EM_TILEPRO 188 /* Tilera TILEPro */ #define EM_MICROBLAZE 189 /* Xilinx MicroBlaze */ #define EM_TILEGX 191 /* Tilera TILE-Gx */ +#define EM_ARCV2 195 /* ARCv2 Cores */ #define EM_RISCV 243 /* RISC-V */ #define EM_BPF 247 /* Linux BPF - in-kernel virtual machine */ #define EM_FRV 0x5441 /* Fujitsu FR-V */ -- ldv
[PATCH v2 01/15] Move EM_HEXAGON to uapi/linux/elf-em.h
This should never have been defined in the arch tree to begin with, and now uapi/linux/audit.h header is going to use EM_HEXAGON in order to define AUDIT_ARCH_HEXAGON which is needed to implement syscall_get_arch() which in turn is required to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Signed-off-by: Dmitry V. Levin --- v2: unchanged since v1 arch/hexagon/include/asm/elf.h | 6 +- include/uapi/linux/elf-em.h| 1 + 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/hexagon/include/asm/elf.h b/arch/hexagon/include/asm/elf.h index 80311e7b8ca6..d10fbd54ae51 100644 --- a/arch/hexagon/include/asm/elf.h +++ b/arch/hexagon/include/asm/elf.h @@ -23,11 +23,7 @@ #include #include - -/* - * This should really be in linux/elf-em.h. - */ -#define EM_HEXAGON 164 /* QUALCOMM Hexagon */ +#include struct elf32_hdr; diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h index 93722e60204c..ba3696e3d694 100644 --- a/include/uapi/linux/elf-em.h +++ b/include/uapi/linux/elf-em.h @@ -37,6 +37,7 @@ #define EM_BLACKFIN 106 /* ADI Blackfin Processor */ #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */ #define EM_TI_C6000140 /* TI C6X DSPs */ +#define EM_HEXAGON 164 /* QUALCOMM Hexagon */ #define EM_AARCH64 183 /* ARM 64 bit */ #define EM_TILEPRO 188 /* Tilera TILEPro */ #define EM_MICROBLAZE 189 /* Xilinx MicroBlaze */ -- ldv
Re: [PATCH 4.4 000/160] 4.4.164-stable review
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.164 release. There are 160 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:20 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.164-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.4 000/160] 4.4.164-stable review
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.164 release. There are 160 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:20 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.164-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 3.18 00/90] 3.18.126-stable review
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.126 release. There are 90 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:28 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.126-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y and the diffstat can be found below. thanks, greg k-h Compiled and booted ob my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 3.18 00/90] 3.18.126-stable review
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.126 release. There are 90 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:28 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.126-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y and the diffstat can be found below. thanks, greg k-h Compiled and booted ob my test system. No dmesg regressions. thanks, -- Shuah
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On 11/19/2018 05:32 AM, Thomas Gleixner wrote: > Tim, > > On Fri, 16 Nov 2018, Tim Chen wrote: > >> Add new protection modes for Spectre v2 mitigations against >> Spectre v2 attacks on user processes. There are three modes: >> >> strict mode: >> In this mode, IBPB and STIBP are deployed full >> time to protect all processes. >> >> lite mode: >> In this mode, IBPB and STIBP are only deployed on >> processes marked with TIF_STIBP flag. >> >> none mode: >> In this mode, no mitigations are deployed. >> >> The protection mode can be specified by the spectre_v2_app2app >> boot parameter with the following semantics: >> >> spectre_v2_app2app= >> off- Turn off mitigation >> lite - Protect processes which are marked non-dumpable >> strict - Protect all processes >> auto - Kernel selects the mode > > Is there any reason why we need yet another naming convention? > > pti= on, off, auto > > spectre_v2= on, off, auto > > spec_store_bypass_disable = on, off, auto, prctl, seccomp The "on" option is set by spectre_v2=on so is not specified here. What will you like to name the "lite" and "strict" option instead? > > >> Not specifying this option is equivalent to >> spectre_v2_app2app=auto. > > For better understanding it's nowhere documented what auto does. I'll add the documentation. > >> +spectre_v2_app2app= >> +[X86] Control mitigation of Spectre variant 2 >> +application to application (indirect branch speculation) >> +vulnerability. >> + >> +off- Unconditionally disable mitigations >> +lite - Protect tasks which have requested restricted >> + indirect branch speculation via the >> + PR_SET_SPECULATION_CTRL prctl(). >> +strict - Protect all processes >> +auto - Kernel selects the mode >> + >> +Not specifying this option is equivalent to >> +spectre_v2_app2app=auto. >> + >> +Setting spectre_v2=off will also turn off this >> mitigation. >> + >> +Setting spectre_v2=on implies unconditionally enabling >> +this mitigation. > > Can we please have a full documentation for all the spectre_v2 stuff > similar to l1tf? > Sure. Can we do that as a separate patch? I'll need some time and internal review for any spectre_v2 documentation that's produced. Tim
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On 11/19/2018 05:32 AM, Thomas Gleixner wrote: > Tim, > > On Fri, 16 Nov 2018, Tim Chen wrote: > >> Add new protection modes for Spectre v2 mitigations against >> Spectre v2 attacks on user processes. There are three modes: >> >> strict mode: >> In this mode, IBPB and STIBP are deployed full >> time to protect all processes. >> >> lite mode: >> In this mode, IBPB and STIBP are only deployed on >> processes marked with TIF_STIBP flag. >> >> none mode: >> In this mode, no mitigations are deployed. >> >> The protection mode can be specified by the spectre_v2_app2app >> boot parameter with the following semantics: >> >> spectre_v2_app2app= >> off- Turn off mitigation >> lite - Protect processes which are marked non-dumpable >> strict - Protect all processes >> auto - Kernel selects the mode > > Is there any reason why we need yet another naming convention? > > pti= on, off, auto > > spectre_v2= on, off, auto > > spec_store_bypass_disable = on, off, auto, prctl, seccomp The "on" option is set by spectre_v2=on so is not specified here. What will you like to name the "lite" and "strict" option instead? > > >> Not specifying this option is equivalent to >> spectre_v2_app2app=auto. > > For better understanding it's nowhere documented what auto does. I'll add the documentation. > >> +spectre_v2_app2app= >> +[X86] Control mitigation of Spectre variant 2 >> +application to application (indirect branch speculation) >> +vulnerability. >> + >> +off- Unconditionally disable mitigations >> +lite - Protect tasks which have requested restricted >> + indirect branch speculation via the >> + PR_SET_SPECULATION_CTRL prctl(). >> +strict - Protect all processes >> +auto - Kernel selects the mode >> + >> +Not specifying this option is equivalent to >> +spectre_v2_app2app=auto. >> + >> +Setting spectre_v2=off will also turn off this >> mitigation. >> + >> +Setting spectre_v2=on implies unconditionally enabling >> +this mitigation. > > Can we please have a full documentation for all the spectre_v2 stuff > similar to l1tf? > Sure. Can we do that as a separate patch? I'll need some time and internal review for any spectre_v2 documentation that's produced. Tim
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Tue, 20 Nov 2018, Jiri Kosina wrote: > On Mon, 19 Nov 2018, Dave Hansen wrote: > > > > What? IBPB makes tons of sense even without STIBP. > > > > I'm lost. :) > > > > I don't think anyone is talking about using STIBP *everywhere* that IBPB > > is in-use. > > > > We're just guessing that, if anybody is paranoid enough to ask for IBPB, > > *and* they have SMT, they almost certainly want STIBP too. > > I think you are not lost :) and this is exactly what makes sense, and what > Tim's patchset implements. Tries to implement perhaps. Unless IBPB is never available when STIBP is not available, but according to documentation that's unlikely because STIBP can be unset when the CPU does not support HT at all. Thanks, tglx
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Tue, 20 Nov 2018, Jiri Kosina wrote: > On Mon, 19 Nov 2018, Dave Hansen wrote: > > > > What? IBPB makes tons of sense even without STIBP. > > > > I'm lost. :) > > > > I don't think anyone is talking about using STIBP *everywhere* that IBPB > > is in-use. > > > > We're just guessing that, if anybody is paranoid enough to ask for IBPB, > > *and* they have SMT, they almost certainly want STIBP too. > > I think you are not lost :) and this is exactly what makes sense, and what > Tim's patchset implements. Tries to implement perhaps. Unless IBPB is never available when STIBP is not available, but according to documentation that's unlikely because STIBP can be unset when the CPU does not support HT at all. Thanks, tglx
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>
> > What? IBPB makes tons of sense even without STIBP.
>
> On non-SMT, yes. But this patchset ties those two the other (sensible) way
> around AFAICS ("STIBP iff (IBPB && SMT)").
Errm. No.
The patches disable IBPB if STIBP is not available and that has absolutely
nothing to do with SMT simply because the static key controlling IBPB is
only flipped on when both IBPB and STIBP are available.
For SMT=off STIBP is pointless, but IBPB still makes a lot of sense.
That's a change which is neither documented nor correct.
Thanks,
tglx
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>
> > What? IBPB makes tons of sense even without STIBP.
>
> On non-SMT, yes. But this patchset ties those two the other (sensible) way
> around AFAICS ("STIBP iff (IBPB && SMT)").
Errm. No.
The patches disable IBPB if STIBP is not available and that has absolutely
nothing to do with SMT simply because the static key controlling IBPB is
only flipped on when both IBPB and STIBP are available.
For SMT=off STIBP is pointless, but IBPB still makes a lot of sense.
That's a change which is neither documented nor correct.
Thanks,
tglx
Re: UBSAN: Undefined behaviour in mm/page_alloc.c
Hi1
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned
> int order, int preferred_nid,
> gfp_t alloc_mask; /* The gfp_t that was actually used for
> allocation */
> struct alloc_context ac = { };
>
> +/*
> + * There are several places where we assume that the order
> value is sane
> + * so bail out early if the request is out of bound.
> + */
> +if (unlikely(order >= MAX_ORDER)) {
> +WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
> +return NULL;
> +}
> +
> >>>
> >>> I know "everybody enables CONFIG_DEBUG_VM", but given this is fastpath,
> >>> we could help those who choose not to enable it by using
> >>>
> >>> #ifdef CONFIG_DEBUG_VM
> >>> if (WARN_ON_ONCE(order >= MAX_ORDER && !(gfp_mask & __GFP_NOWARN)))
> >>> return NULL;
> >>> #endif
> >>
> >> Hmm, but that would mean there's still potential undefined behavior for
> >> !CONFIG_DEBUG_VM, so I would prefer not to do it like that.
> >>
> >
> > What does "potential undefined behavior" mean here?
>
> I mean that it becomes undefined once a caller with order >= MAX_ORDER
> appears. Worse if it's directly due to a userspace action, like in this
> case.
We should really check if value from userspace is sane _before_
passing it to alloc_pages(). Anything else is too fragile. Maybe
alloc_pages should do the second check, but...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: UBSAN: Undefined behaviour in mm/page_alloc.c
Hi1
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned
> int order, int preferred_nid,
> gfp_t alloc_mask; /* The gfp_t that was actually used for
> allocation */
> struct alloc_context ac = { };
>
> +/*
> + * There are several places where we assume that the order
> value is sane
> + * so bail out early if the request is out of bound.
> + */
> +if (unlikely(order >= MAX_ORDER)) {
> +WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
> +return NULL;
> +}
> +
> >>>
> >>> I know "everybody enables CONFIG_DEBUG_VM", but given this is fastpath,
> >>> we could help those who choose not to enable it by using
> >>>
> >>> #ifdef CONFIG_DEBUG_VM
> >>> if (WARN_ON_ONCE(order >= MAX_ORDER && !(gfp_mask & __GFP_NOWARN)))
> >>> return NULL;
> >>> #endif
> >>
> >> Hmm, but that would mean there's still potential undefined behavior for
> >> !CONFIG_DEBUG_VM, so I would prefer not to do it like that.
> >>
> >
> > What does "potential undefined behavior" mean here?
>
> I mean that it becomes undefined once a caller with order >= MAX_ORDER
> appears. Worse if it's directly due to a userspace action, like in this
> case.
We should really check if value from userspace is sane _before_
passing it to alloc_pages(). Anything else is too fragile. Maybe
alloc_pages should do the second check, but...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v3 3/3] ALSA: hda: add support for Huawei WMI micmute LED
Hi! > Some of Huawei laptops come with a LED in the micmute key. This patch > enables and disable this LED accordingly. > > Signed-off-by: Ayman Bagabas NAK. We already have a LED subsystem. > +#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP) > +#include > + > +static int (*huawei_wmi_micmute_led_set_func)(bool); > + So we should not be doing this. Thinkpad ACPI module exports its LEDs there, for example. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v3 3/3] ALSA: hda: add support for Huawei WMI micmute LED
Hi! > Some of Huawei laptops come with a LED in the micmute key. This patch > enables and disable this LED accordingly. > > Signed-off-by: Ayman Bagabas NAK. We already have a LED subsystem. > +#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP) > +#include > + > +static int (*huawei_wmi_micmute_led_set_func)(bool); > + So we should not be doing this. Thinkpad ACPI module exports its LEDs there, for example. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Mon, 19 Nov 2018, Dave Hansen wrote: > > What? IBPB makes tons of sense even without STIBP. > > I'm lost. :) > > I don't think anyone is talking about using STIBP *everywhere* that IBPB > is in-use. > > We're just guessing that, if anybody is paranoid enough to ask for IBPB, > *and* they have SMT, they almost certainly want STIBP too. I think you are not lost :) and this is exactly what makes sense, and what Tim's patchset implements. -- Jiri Kosina SUSE Labs
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Mon, 19 Nov 2018, Dave Hansen wrote: > > What? IBPB makes tons of sense even without STIBP. > > I'm lost. :) > > I don't think anyone is talking about using STIBP *everywhere* that IBPB > is in-use. > > We're just guessing that, if anybody is paranoid enough to ask for IBPB, > *and* they have SMT, they almost certainly want STIBP too. I think you are not lost :) and this is exactly what makes sense, and what Tim's patchset implements. -- Jiri Kosina SUSE Labs
Re: [PATCH] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()
On Mon, Nov 19, 2018 at 3:43 PM Dave Hansen wrote: > > On 11/19/18 3:19 PM, Dan Williams wrote: > > Andy wondered why a path that can sleep was using __flush_tlb_all() [1] > > and Dave confirmed the expectation for TLB flush is for modifying / > > invalidating existing pte entries, but not initial population [2]. > > I _think_ this is OK. > > But, could we sprinkle a few WARN_ON_ONCE(p*_present()) calls in there > to help us sleep at night? Makes sense, I'll add those for v2.
Re: [PATCH] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()
On Mon, Nov 19, 2018 at 3:43 PM Dave Hansen wrote: > > On 11/19/18 3:19 PM, Dan Williams wrote: > > Andy wondered why a path that can sleep was using __flush_tlb_all() [1] > > and Dave confirmed the expectation for TLB flush is for modifying / > > invalidating existing pte entries, but not initial population [2]. > > I _think_ this is OK. > > But, could we sprinkle a few WARN_ON_ONCE(p*_present()) calls in there > to help us sleep at night? Makes sense, I'll add those for v2.
Re: Magic Sysrq key option ... What is the option to record the boot logs to my hard disk before i issue a reboot command ?
On Mon, Nov 19, 2018 at 11:31:21AM -0800, Randy Dunlap wrote: > > Yes, all of that. > Having some kind of pstore on x86 would be wonderful. > > kexec/kdump used to be an option also. I haven't tried it lately. Sure, but kexec/kdump won't work to debug a boot failure during early boot. You need to be able to get the root file system mounted at the very least, and usually kexec/kdump doesn't get set up until the init scripts are running. Fortunately, usually only kernel developers need to debug early boot failures, and most of us can usually use serial consoles (for those of us who can't just cheat and use VM's. :-) - Ted
Re: Magic Sysrq key option ... What is the option to record the boot logs to my hard disk before i issue a reboot command ?
On Mon, Nov 19, 2018 at 11:31:21AM -0800, Randy Dunlap wrote: > > Yes, all of that. > Having some kind of pstore on x86 would be wonderful. > > kexec/kdump used to be an option also. I haven't tried it lately. Sure, but kexec/kdump won't work to debug a boot failure during early boot. You need to be able to get the root file system mounted at the very least, and usually kexec/kdump doesn't get set up until the init scripts are running. Fortunately, usually only kernel developers need to debug early boot failures, and most of us can usually use serial consoles (for those of us who can't just cheat and use VM's. :-) - Ted
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Tue, Nov 20, 2018 at 07:37:58AM +0800, kbuild test robot wrote:
> Hi Christian,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc3]
> [cannot apply to next-20181119]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Christian-Brauner/proc-allow-signaling-processes-via-file-descriptors/20181120-063836
> config: riscv-tinyconfig (attached as .config)
> compiler: riscv64-linux-gcc (GCC) 8.1.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=8.1.0 make.cross ARCH=riscv
>
> All errors (new ones prefixed by >>):
>
>kernel/signal.c: In function '__do_sys_procfd_signal':
> >> kernel/signal.c:3341:7: error: implicit declaration of function
> >> 'proc_is_procfd'; did you mean 'clockid_to_fd'?
> >> [-Werror=implicit-function-declaration]
> if (!proc_is_procfd(f.file))
> ^~
On my radar and fixed. This happens when CONFIG_PROC_FS unset.
> clockid_to_fd
>cc1: some warnings being treated as errors
>
> vim +3341 kernel/signal.c
>
> 3314
> 3315/**
> 3316 * sys_procfd_signal - send a signal to a process through a
> process file
> 3317 * descriptor
> 3318 * @fd: the file descriptor of the process
> 3319 * @sig: signal to be sent
> 3320 * @info: the signal info
> 3321 * @flags: future flags to be passed
> 3322 */
> 3323SYSCALL_DEFINE4(procfd_signal, int, fd, int, sig, siginfo_t
> __user *, info,
> 3324int, flags)
> 3325{
> 3326int ret;
> 3327struct pid *pid;
> 3328kernel_siginfo_t kinfo;
> 3329struct fd f;
> 3330
> 3331/* Enforce flags be set to 0 until we add an extension.
> */
> 3332if (flags)
> return -EINVAL;
> 3334
> 3335f = fdget_raw(fd);
> 3336if (!f.file)
> 3337return -EBADF;
> 3338
> 3339ret = -EINVAL;
> 3340/* Is this a process file descriptor? */
> > 3341if (!proc_is_procfd(f.file))
> 3342goto err;
> 3343
> 3344pid = f.file->private_data;
> 3345if (!pid)
> 3346goto err;
> 3347
> 3348if (info) {
> 3349ret = __copy_siginfo_from_user(sig, ,
> info);
> 3350if (unlikely(ret))
> 3351goto err;
> 3352/*
> 3353 * Not even root can pretend to send signals
> from the kernel.
> 3354 * Nor can they impersonate a kill()/tgkill(),
> which adds
> 3355 * source info.
> 3356 */
> 3357ret = -EPERM;
> 3358if ((kinfo.si_code >= 0 || kinfo.si_code ==
> SI_TKILL) &&
> 3359(task_pid(current) != pid))
> 3360goto err;
> 3361} else {
> 3362prepare_kill_siginfo(sig, );
> 3363}
> 3364
> 3365ret = kill_pid_info(sig, , pid);
> 3366
> 3367err:
> 3368fdput(f);
> 3369return ret;
> 3370}
> 3371
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Mon, Nov 19, 2018 at 03:25:41PM -0800, Dave Hansen wrote: > On 11/19/18 3:16 PM, Andrea Arcangeli wrote: > > So you may want to ask why it wasn't written as your "any" vs "any" email: > > Presumably because the authors really and truly meant what they said. I > was not being as careful in my wording as they were. :) > > There is nothing in the spec that says that STIBP disables branch > prediction itself, or that it keeps a thread from influencing *itself*. Just in case, another thing come to mind, what about mistraining the BTB with STIBP set inside the SECCOMP jail and then going to sleep or being migrated by the scheduler to another core which clears STIBP on the core? Can the mistraining happened inside the SECCOMP jail with STIBP set influence the code outside SECCOMP after STIBP is cleared?
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
On Tue, Nov 20, 2018 at 07:37:58AM +0800, kbuild test robot wrote:
> Hi Christian,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc3]
> [cannot apply to next-20181119]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Christian-Brauner/proc-allow-signaling-processes-via-file-descriptors/20181120-063836
> config: riscv-tinyconfig (attached as .config)
> compiler: riscv64-linux-gcc (GCC) 8.1.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=8.1.0 make.cross ARCH=riscv
>
> All errors (new ones prefixed by >>):
>
>kernel/signal.c: In function '__do_sys_procfd_signal':
> >> kernel/signal.c:3341:7: error: implicit declaration of function
> >> 'proc_is_procfd'; did you mean 'clockid_to_fd'?
> >> [-Werror=implicit-function-declaration]
> if (!proc_is_procfd(f.file))
> ^~
On my radar and fixed. This happens when CONFIG_PROC_FS unset.
> clockid_to_fd
>cc1: some warnings being treated as errors
>
> vim +3341 kernel/signal.c
>
> 3314
> 3315/**
> 3316 * sys_procfd_signal - send a signal to a process through a
> process file
> 3317 * descriptor
> 3318 * @fd: the file descriptor of the process
> 3319 * @sig: signal to be sent
> 3320 * @info: the signal info
> 3321 * @flags: future flags to be passed
> 3322 */
> 3323SYSCALL_DEFINE4(procfd_signal, int, fd, int, sig, siginfo_t
> __user *, info,
> 3324int, flags)
> 3325{
> 3326int ret;
> 3327struct pid *pid;
> 3328kernel_siginfo_t kinfo;
> 3329struct fd f;
> 3330
> 3331/* Enforce flags be set to 0 until we add an extension.
> */
> 3332if (flags)
> return -EINVAL;
> 3334
> 3335f = fdget_raw(fd);
> 3336if (!f.file)
> 3337return -EBADF;
> 3338
> 3339ret = -EINVAL;
> 3340/* Is this a process file descriptor? */
> > 3341if (!proc_is_procfd(f.file))
> 3342goto err;
> 3343
> 3344pid = f.file->private_data;
> 3345if (!pid)
> 3346goto err;
> 3347
> 3348if (info) {
> 3349ret = __copy_siginfo_from_user(sig, ,
> info);
> 3350if (unlikely(ret))
> 3351goto err;
> 3352/*
> 3353 * Not even root can pretend to send signals
> from the kernel.
> 3354 * Nor can they impersonate a kill()/tgkill(),
> which adds
> 3355 * source info.
> 3356 */
> 3357ret = -EPERM;
> 3358if ((kinfo.si_code >= 0 || kinfo.si_code ==
> SI_TKILL) &&
> 3359(task_pid(current) != pid))
> 3360goto err;
> 3361} else {
> 3362prepare_kill_siginfo(sig, );
> 3363}
> 3364
> 3365ret = kill_pid_info(sig, , pid);
> 3366
> 3367err:
> 3368fdput(f);
> 3369return ret;
> 3370}
> 3371
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On Mon, Nov 19, 2018 at 03:25:41PM -0800, Dave Hansen wrote: > On 11/19/18 3:16 PM, Andrea Arcangeli wrote: > > So you may want to ask why it wasn't written as your "any" vs "any" email: > > Presumably because the authors really and truly meant what they said. I > was not being as careful in my wording as they were. :) > > There is nothing in the spec that says that STIBP disables branch > prediction itself, or that it keeps a thread from influencing *itself*. Just in case, another thing come to mind, what about mistraining the BTB with STIBP set inside the SECCOMP jail and then going to sleep or being migrated by the scheduler to another core which clears STIBP on the core? Can the mistraining happened inside the SECCOMP jail with STIBP set influence the code outside SECCOMP after STIBP is cleared?
Re: [PATCH] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()
On 11/19/18 3:19 PM, Dan Williams wrote: > Andy wondered why a path that can sleep was using __flush_tlb_all() [1] > and Dave confirmed the expectation for TLB flush is for modifying / > invalidating existing pte entries, but not initial population [2]. I _think_ this is OK. But, could we sprinkle a few WARN_ON_ONCE(p*_present()) calls in there to help us sleep at night?
Re: [PATCH] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()
On 11/19/18 3:19 PM, Dan Williams wrote: > Andy wondered why a path that can sleep was using __flush_tlb_all() [1] > and Dave confirmed the expectation for TLB flush is for modifying / > invalidating existing pte entries, but not initial population [2]. I _think_ this is OK. But, could we sprinkle a few WARN_ON_ONCE(p*_present()) calls in there to help us sleep at night?
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
Hi Christian, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.20-rc3] [cannot apply to next-20181119] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Christian-Brauner/proc-allow-signaling-processes-via-file-descriptors/20181120-063836 config: riscv-tinyconfig (attached as .config) compiler: riscv64-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=8.1.0 make.cross ARCH=riscv All warnings (new ones prefixed by >>): >> :1338:2: warning: #warning syscall procfd_signal not implemented >> [-Wcpp] --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
Hi Christian, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.20-rc3] [cannot apply to next-20181119] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Christian-Brauner/proc-allow-signaling-processes-via-file-descriptors/20181120-063836 config: riscv-tinyconfig (attached as .config) compiler: riscv64-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=8.1.0 make.cross ARCH=riscv All warnings (new ones prefixed by >>): >> :1338:2: warning: #warning syscall procfd_signal not implemented >> [-Wcpp] --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On 11/19/18 3:01 PM, Thomas Gleixner wrote: >> Yes, it wouldn't make sense for having just one of those if a task >> is worried about attack from user space. >> >> I'll document it. > What? IBPB makes tons of sense even without STIBP. I'm lost. :) I don't think anyone is talking about using STIBP *everywhere* that IBPB is in-use. We're just guessing that, if anybody is paranoid enough to ask for IBPB, *and* they have SMT, they almost certainly want STIBP too.
Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes
On 11/19/18 3:01 PM, Thomas Gleixner wrote: >> Yes, it wouldn't make sense for having just one of those if a task >> is worried about attack from user space. >> >> I'll document it. > What? IBPB makes tons of sense even without STIBP. I'm lost. :) I don't think anyone is talking about using STIBP *everywhere* that IBPB is in-use. We're just guessing that, if anybody is paranoid enough to ask for IBPB, *and* they have SMT, they almost certainly want STIBP too.
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
Hi Christian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc3]
[cannot apply to next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Christian-Brauner/proc-allow-signaling-processes-via-file-descriptors/20181120-063836
config: riscv-tinyconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=riscv
All errors (new ones prefixed by >>):
kernel/signal.c: In function '__do_sys_procfd_signal':
>> kernel/signal.c:3341:7: error: implicit declaration of function
>> 'proc_is_procfd'; did you mean 'clockid_to_fd'?
>> [-Werror=implicit-function-declaration]
if (!proc_is_procfd(f.file))
^~
clockid_to_fd
cc1: some warnings being treated as errors
vim +3341 kernel/signal.c
3314
3315 /**
3316 * sys_procfd_signal - send a signal to a process through a process
file
3317 * descriptor
3318 * @fd: the file descriptor of the process
3319 * @sig: signal to be sent
3320 * @info: the signal info
3321 * @flags: future flags to be passed
3322 */
3323 SYSCALL_DEFINE4(procfd_signal, int, fd, int, sig, siginfo_t __user *,
info,
3324 int, flags)
3325 {
3326 int ret;
3327 struct pid *pid;
3328 kernel_siginfo_t kinfo;
3329 struct fd f;
3330
3331 /* Enforce flags be set to 0 until we add an extension. */
3332 if (flags)
return -EINVAL;
3334
3335 f = fdget_raw(fd);
3336 if (!f.file)
3337 return -EBADF;
3338
3339 ret = -EINVAL;
3340 /* Is this a process file descriptor? */
> 3341 if (!proc_is_procfd(f.file))
3342 goto err;
3343
3344 pid = f.file->private_data;
3345 if (!pid)
3346 goto err;
3347
3348 if (info) {
3349 ret = __copy_siginfo_from_user(sig, , info);
3350 if (unlikely(ret))
3351 goto err;
3352 /*
3353 * Not even root can pretend to send signals from the
kernel.
3354 * Nor can they impersonate a kill()/tgkill(), which
adds
3355 * source info.
3356 */
3357 ret = -EPERM;
3358 if ((kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL) &&
3359 (task_pid(current) != pid))
3360 goto err;
3361 } else {
3362 prepare_kill_siginfo(sig, );
3363 }
3364
3365 ret = kill_pid_info(sig, , pid);
3366
3367 err:
3368 fdput(f);
3369 return ret;
3370 }
3371
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v1 2/2] signal: add procfd_signal() syscall
Hi Christian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc3]
[cannot apply to next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Christian-Brauner/proc-allow-signaling-processes-via-file-descriptors/20181120-063836
config: riscv-tinyconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=riscv
All errors (new ones prefixed by >>):
kernel/signal.c: In function '__do_sys_procfd_signal':
>> kernel/signal.c:3341:7: error: implicit declaration of function
>> 'proc_is_procfd'; did you mean 'clockid_to_fd'?
>> [-Werror=implicit-function-declaration]
if (!proc_is_procfd(f.file))
^~
clockid_to_fd
cc1: some warnings being treated as errors
vim +3341 kernel/signal.c
3314
3315 /**
3316 * sys_procfd_signal - send a signal to a process through a process
file
3317 * descriptor
3318 * @fd: the file descriptor of the process
3319 * @sig: signal to be sent
3320 * @info: the signal info
3321 * @flags: future flags to be passed
3322 */
3323 SYSCALL_DEFINE4(procfd_signal, int, fd, int, sig, siginfo_t __user *,
info,
3324 int, flags)
3325 {
3326 int ret;
3327 struct pid *pid;
3328 kernel_siginfo_t kinfo;
3329 struct fd f;
3330
3331 /* Enforce flags be set to 0 until we add an extension. */
3332 if (flags)
return -EINVAL;
3334
3335 f = fdget_raw(fd);
3336 if (!f.file)
3337 return -EBADF;
3338
3339 ret = -EINVAL;
3340 /* Is this a process file descriptor? */
> 3341 if (!proc_is_procfd(f.file))
3342 goto err;
3343
3344 pid = f.file->private_data;
3345 if (!pid)
3346 goto err;
3347
3348 if (info) {
3349 ret = __copy_siginfo_from_user(sig, , info);
3350 if (unlikely(ret))
3351 goto err;
3352 /*
3353 * Not even root can pretend to send signals from the
kernel.
3354 * Nor can they impersonate a kill()/tgkill(), which
adds
3355 * source info.
3356 */
3357 ret = -EPERM;
3358 if ((kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL) &&
3359 (task_pid(current) != pid))
3360 goto err;
3361 } else {
3362 prepare_kill_siginfo(sig, );
3363 }
3364
3365 ret = kill_pid_info(sig, , pid);
3366
3367 err:
3368 fdput(f);
3369 return ret;
3370 }
3371
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
