Re: [PATCH v2 1/2] platform/chrome: straighten out cros_ec_get_{next,host}_event() error codes
On Wed, 07 Nov 2018, Brian Norris wrote: > cros_ec_get_next_event() is documented to return 0 for success and > negative for errors. It currently returns negative for some errors, and > non-negative (number of bytes received) for success (including some "no > data available" responses as zero). This mostly works out OK, because the > callers were more or less ignoring the documentation, and only treating > positive values as success (and indepdently checking the modification of > 'wakeup'). > > Let's button this up by avoiding pretending to handle event/wakeup > distinctions when no event info was retrieved (i.e., returned 0 bytes). > And fix the documentation of cros_ec_get_host_event() and > cros_ec_get_next_event() to accurately describe their behavior. > > Signed-off-by: Brian Norris > --- > v1 -> v2: > * don't make as many changes to the API -- just fix the documentation >and a few corner cases instead > --- > drivers/platform/chrome/cros_ec_proto.c | 4 ++-- > include/linux/mfd/cros_ec.h | 6 -- > 2 files changed, 6 insertions(+), 4 deletions(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 1/2] platform/chrome: straighten out cros_ec_get_{next,host}_event() error codes
On Wed, 07 Nov 2018, Brian Norris wrote: > cros_ec_get_next_event() is documented to return 0 for success and > negative for errors. It currently returns negative for some errors, and > non-negative (number of bytes received) for success (including some "no > data available" responses as zero). This mostly works out OK, because the > callers were more or less ignoring the documentation, and only treating > positive values as success (and indepdently checking the modification of > 'wakeup'). > > Let's button this up by avoiding pretending to handle event/wakeup > distinctions when no event info was retrieved (i.e., returned 0 bytes). > And fix the documentation of cros_ec_get_host_event() and > cros_ec_get_next_event() to accurately describe their behavior. > > Signed-off-by: Brian Norris > --- > v1 -> v2: > * don't make as many changes to the API -- just fix the documentation >and a few corner cases instead > --- > drivers/platform/chrome/cros_ec_proto.c | 4 ++-- > include/linux/mfd/cros_ec.h | 6 -- > 2 files changed, 6 insertions(+), 4 deletions(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: tps6586x: Handle interrupts on suspend
On Mon, 05 Nov 2018, Jon Hunter wrote: > Hi Lee, > > On 19/10/2018 14:22, Jon Hunter wrote: > > From: Jonathan Hunter > > > > The tps6586x driver creates an irqchip that is used by its various child > > devices for managing interrupts. The tps6586x-rtc device is one of its > > children that uses the tps6586x irqchip. When using the tps6586x-rtc as > > a wake-up device from suspend, the following is seen: > > > > PM: Syncing filesystems ... done. > > Freezing user space processes ... (elapsed 0.001 seconds) done. > > OOM killer disabled. > > Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. > > Disabling non-boot CPUs ...Hi > > Entering suspend state LP1 > > Enabling non-boot CPUs ... > > CPU1 is up > > tps6586x 3-0034: failed to read interrupt status > > tps6586x 3-0034: failed to read interrupt status > > > > The reason why the tps6586x interrupt status cannot be read is because > > the tps6586x interrupt is not masked during suspend and when the > > tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is > > seen before the i2c controller has been resumed in order to read the > > tps6586x interrupt status. > > > > The tps6586x-rtc driver sets it's interrupt as a wake-up source during > > suspend, which gets propagated to the parent tps6586x interrupt. > > However, the tps6586x-rtc driver cannot disable it's interrupt during > > suspend otherwise we would never be woken up and so the tps6586x must > > disable it's interrupt instead. > > > > Prevent the tps6586x interrupt handler from executing on exiting suspend > > before the i2c controller has been resumed by disabling the tps6586x > > interrupt on entering suspend and re-enabling it on resuming from > > suspend. > > > > Cc: sta...@vger.kernel.org > > > > Signed-off-by: Jon Hunter > > --- > > Thierry and Dmitry have acked/reviewed this, let me know if you have any > comments. Best thing you can do to regain attention on a potentially forgotten submission is to collect any Acks you have accrued (if any) and submit a [RESEND]. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: tps6586x: Handle interrupts on suspend
On Mon, 05 Nov 2018, Jon Hunter wrote: > Hi Lee, > > On 19/10/2018 14:22, Jon Hunter wrote: > > From: Jonathan Hunter > > > > The tps6586x driver creates an irqchip that is used by its various child > > devices for managing interrupts. The tps6586x-rtc device is one of its > > children that uses the tps6586x irqchip. When using the tps6586x-rtc as > > a wake-up device from suspend, the following is seen: > > > > PM: Syncing filesystems ... done. > > Freezing user space processes ... (elapsed 0.001 seconds) done. > > OOM killer disabled. > > Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. > > Disabling non-boot CPUs ...Hi > > Entering suspend state LP1 > > Enabling non-boot CPUs ... > > CPU1 is up > > tps6586x 3-0034: failed to read interrupt status > > tps6586x 3-0034: failed to read interrupt status > > > > The reason why the tps6586x interrupt status cannot be read is because > > the tps6586x interrupt is not masked during suspend and when the > > tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is > > seen before the i2c controller has been resumed in order to read the > > tps6586x interrupt status. > > > > The tps6586x-rtc driver sets it's interrupt as a wake-up source during > > suspend, which gets propagated to the parent tps6586x interrupt. > > However, the tps6586x-rtc driver cannot disable it's interrupt during > > suspend otherwise we would never be woken up and so the tps6586x must > > disable it's interrupt instead. > > > > Prevent the tps6586x interrupt handler from executing on exiting suspend > > before the i2c controller has been resumed by disabling the tps6586x > > interrupt on entering suspend and re-enabling it on resuming from > > suspend. > > > > Cc: sta...@vger.kernel.org > > > > Signed-off-by: Jon Hunter > > --- > > Thierry and Dmitry have acked/reviewed this, let me know if you have any > comments. Best thing you can do to regain attention on a potentially forgotten submission is to collect any Acks you have accrued (if any) and submit a [RESEND]. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] vmscan: return NODE_RECLAIM_NOSCAN in node_reclaim() when CONFIG_NUMA is n
On Mon, Nov 12, 2018 at 09:36:15PM -0800, Matthew Wilcox wrote:
>On Tue, Nov 13, 2018 at 12:17:50PM +0800, Wei Yang wrote:
>> Commit fa5e084e43eb ("vmscan: do not unconditionally treat zones that
>> fail zone_reclaim() as full") changed the return value of node_reclaim().
>> The original return value 0 means NODE_RECLAIM_SOME after this commit.
>>
>> While the return value of node_reclaim() when CONFIG_NUMA is n is not
>> changed. This will leads to call zone_watermark_ok() again.
>>
>> This patch fix the return value by adjusting to NODE_RECLAIM_NOSCAN. Since
>> it is not proper to include "mm/internal.h", just hard coded it.
>
>Since the return value is defined in mm/internal.h that means no code
>outside mm/ can call node_reclaim (nor should it). So let's move both
>of node_reclaim's declarations to mm/internal.h instead of keeping them
>in linux/swap.h.
That's reasonable, thanks.
--
Wei Yang
Help you, Help me
Re: [PATCH] vmscan: return NODE_RECLAIM_NOSCAN in node_reclaim() when CONFIG_NUMA is n
On Mon, Nov 12, 2018 at 09:36:15PM -0800, Matthew Wilcox wrote:
>On Tue, Nov 13, 2018 at 12:17:50PM +0800, Wei Yang wrote:
>> Commit fa5e084e43eb ("vmscan: do not unconditionally treat zones that
>> fail zone_reclaim() as full") changed the return value of node_reclaim().
>> The original return value 0 means NODE_RECLAIM_SOME after this commit.
>>
>> While the return value of node_reclaim() when CONFIG_NUMA is n is not
>> changed. This will leads to call zone_watermark_ok() again.
>>
>> This patch fix the return value by adjusting to NODE_RECLAIM_NOSCAN. Since
>> it is not proper to include "mm/internal.h", just hard coded it.
>
>Since the return value is defined in mm/internal.h that means no code
>outside mm/ can call node_reclaim (nor should it). So let's move both
>of node_reclaim's declarations to mm/internal.h instead of keeping them
>in linux/swap.h.
That's reasonable, thanks.
--
Wei Yang
Help you, Help me
Re: [PATCH] mm/hwpoison: fix incorrect call put_hwpoison_page() when isolate_huge_page() return false
On Tue, Nov 13, 2018 at 03:00:09PM +0800, Yongkai Wu wrote:
> when isolate_huge_page() return false,it won't takes a refcount of page,
> if we call put_hwpoison_page() in that case,we may hit the VM_BUG_ON_PAGE!
>
> Signed-off-by: Yongkai Wu
> ---
> mm/memory-failure.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 0cd3de3..ed09f56 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1699,12 +1699,13 @@ static int soft_offline_huge_page(struct page *page,
> int flags)
> unlock_page(hpage);
>
> ret = isolate_huge_page(hpage, );
> - /*
> - * get_any_page() and isolate_huge_page() takes a refcount each,
> - * so need to drop one here.
> - */
> - put_hwpoison_page(hpage);
> - if (!ret) {
> + if (ret) {
> +/*
> + * get_any_page() and isolate_huge_page() takes a refcount each,
> + * so need to drop one here.
> +*/
> + put_hwpoison_page(hpage);
> + } else {
Hi Yongkai,
Although the current code might look odd, it's OK. We have to release
one refcount whether this isolate_huge_page() succeeds or not, because
the put_hwpoison_page() is cancelling the refcount from get_any_page()
which always succeeds when we enter soft_offline_huge_page().
Let's consider that the isolate_huge_page() fails with your patch applied,
then the refcount taken by get_any_page() is never released after returning
from soft_offline_page(). That will lead to memory leak.
I think that current code comment doesn't explaing it well, so if you
like, you can fix the comment. (If you do that, please check coding style.
scripts/checkpatch.pl will help you.)
Thanks,
Naoya Horiguchi
Re: [PATCH] mm/hwpoison: fix incorrect call put_hwpoison_page() when isolate_huge_page() return false
On Tue, Nov 13, 2018 at 03:00:09PM +0800, Yongkai Wu wrote:
> when isolate_huge_page() return false,it won't takes a refcount of page,
> if we call put_hwpoison_page() in that case,we may hit the VM_BUG_ON_PAGE!
>
> Signed-off-by: Yongkai Wu
> ---
> mm/memory-failure.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 0cd3de3..ed09f56 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1699,12 +1699,13 @@ static int soft_offline_huge_page(struct page *page,
> int flags)
> unlock_page(hpage);
>
> ret = isolate_huge_page(hpage, );
> - /*
> - * get_any_page() and isolate_huge_page() takes a refcount each,
> - * so need to drop one here.
> - */
> - put_hwpoison_page(hpage);
> - if (!ret) {
> + if (ret) {
> +/*
> + * get_any_page() and isolate_huge_page() takes a refcount each,
> + * so need to drop one here.
> +*/
> + put_hwpoison_page(hpage);
> + } else {
Hi Yongkai,
Although the current code might look odd, it's OK. We have to release
one refcount whether this isolate_huge_page() succeeds or not, because
the put_hwpoison_page() is cancelling the refcount from get_any_page()
which always succeeds when we enter soft_offline_huge_page().
Let's consider that the isolate_huge_page() fails with your patch applied,
then the refcount taken by get_any_page() is never released after returning
from soft_offline_page(). That will lead to memory leak.
I think that current code comment doesn't explaing it well, so if you
like, you can fix the comment. (If you do that, please check coding style.
scripts/checkpatch.pl will help you.)
Thanks,
Naoya Horiguchi
Re: [PATCH v5 2/8] mfd: stpmic1: add stpmic1 driver
On Mon, 29 Oct 2018, Pascal PAILLET-LME wrote:
> stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
"STPMIC1 is a PMIC"
> regulators, 3 power switches, a watchdog and an input for a power on key.
>
> Signed-off-by: Pascal Paillet
> ---
> changes in v5:
> * use macro to define regmap register ranges
> * use REGMAP_IRQ_REG marco to define interrupts
> * remove st properties
>
> drivers/mfd/Kconfig | 13 +++
> drivers/mfd/Makefile| 1 +
> drivers/mfd/stpmic1.c | 215
>
> include/linux/mfd/stpmic1.h | 212 +++
> 4 files changed, 444 insertions(+)
> create mode 100644 drivers/mfd/stpmic1.c
> create mode 100644 include/linux/mfd/stpmic1.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 11841f4..07e39a6 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1855,6 +1855,22 @@ config MFD_STM32_TIMERS
> for PWM and IIO Timer. This driver allow to share the
> registers between the others drivers.
>
> +config MFD_STPMIC1
> + tristate "Support for STPMIC1 PMIC"
> + depends on (I2C=y && OF)
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + select MFD_CORE
> + help
> + Support for ST Microelectronics STPMIC1 PMIC. STPMIC1 has power on
> + key, watchdog and regulator functionalities which are supported via
> + the relevant subsystems. This driver provides core support for the
> + STPMIC1, in order to use the actual functionaltiy of the device other
s/,/./
> + drivers must be enabled.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called stpmic1.
> +
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 5856a94..76fff14 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -232,6 +232,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) +=
> intel_soc_pmic_chtdc_ti.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> +obj-$(CONFIG_MFD_STPMIC1)+= stpmic1.o
> obj-$(CONFIG_MFD_SUN4I_GPADC)+= sun4i-gpadc.o
>
> obj-$(CONFIG_MFD_STM32_LPTIMER) += stm32-lptimer.o
> diff --git a/drivers/mfd/stpmic1.c b/drivers/mfd/stpmic1.c
> new file mode 100644
> index 000..2f4fd5e
> --- /dev/null
> +++ b/drivers/mfd/stpmic1.c
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) STMicroelectronics 2018
> +// Author: Pascal Paillet
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define STPMIC1_MAIN_IRQ 0
> +
> +static const struct regmap_range stpmic1_readable_ranges[] = {
> + regmap_reg_range(TURN_ON_SR, VERSION_SR),
> + regmap_reg_range(SWOFF_PWRCTRL_CR, LDO6_STDBY_CR),
> + regmap_reg_range(BST_SW_CR, BST_SW_CR),
> + regmap_reg_range(INT_PENDING_R1, INT_PENDING_R4),
> + regmap_reg_range(INT_CLEAR_R1, INT_CLEAR_R4),
> + regmap_reg_range(INT_MASK_R1, INT_MASK_R4),
> + regmap_reg_range(INT_SET_MASK_R1, INT_SET_MASK_R4),
> + regmap_reg_range(INT_CLEAR_MASK_R1, INT_CLEAR_MASK_R4),
> + regmap_reg_range(INT_SRC_R1, INT_SRC_R1),
> +};
> +
> +static const struct regmap_range stpmic1_writeable_ranges[] = {
> + regmap_reg_range(SWOFF_PWRCTRL_CR, LDO6_STDBY_CR),
> + regmap_reg_range(BST_SW_CR, BST_SW_CR),
> + regmap_reg_range(INT_CLEAR_R1, INT_CLEAR_R4),
> + regmap_reg_range(INT_SET_MASK_R1, INT_SET_MASK_R4),
> + regmap_reg_range(INT_CLEAR_MASK_R1, INT_CLEAR_MASK_R4),
> +};
> +
> +static const struct regmap_range stpmic1_volatile_ranges[] = {
> + regmap_reg_range(TURN_ON_SR, VERSION_SR),
> + regmap_reg_range(WCHDG_CR, WCHDG_CR),
> + regmap_reg_range(INT_PENDING_R1, INT_PENDING_R4),
> + regmap_reg_range(INT_SRC_R1, INT_SRC_R4),
> +};
Nice!
> +static const struct regmap_access_table stpmic1_readable_table = {
> + .yes_ranges = stpmic1_readable_ranges,
> + .n_yes_ranges = ARRAY_SIZE(stpmic1_readable_ranges),
> +};
> +
> +static const struct regmap_access_table stpmic1_writeable_table = {
> + .yes_ranges = stpmic1_writeable_ranges,
> + .n_yes_ranges = ARRAY_SIZE(stpmic1_writeable_ranges),
> +};
> +
> +static const struct regmap_access_table stpmic1_volatile_table = {
> + .yes_ranges = stpmic1_volatile_ranges,
> + .n_yes_ranges = ARRAY_SIZE(stpmic1_volatile_ranges),
> +};
> +
> +const struct regmap_config stpmic1_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .cache_type = REGCACHE_RBTREE,
> + .max_register = PMIC_MAX_REGISTER_ADDRESS,
> + .rd_table = _readable_table,
> + .wr_table = _writeable_table,
> + .volatile_table = _volatile_table,
> +};
> +
> +static const struct regmap_irq stpmic1_irqs[] = {
> +
Re: [PATCH v5 2/8] mfd: stpmic1: add stpmic1 driver
On Mon, 29 Oct 2018, Pascal PAILLET-LME wrote:
> stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
"STPMIC1 is a PMIC"
> regulators, 3 power switches, a watchdog and an input for a power on key.
>
> Signed-off-by: Pascal Paillet
> ---
> changes in v5:
> * use macro to define regmap register ranges
> * use REGMAP_IRQ_REG marco to define interrupts
> * remove st properties
>
> drivers/mfd/Kconfig | 13 +++
> drivers/mfd/Makefile| 1 +
> drivers/mfd/stpmic1.c | 215
>
> include/linux/mfd/stpmic1.h | 212 +++
> 4 files changed, 444 insertions(+)
> create mode 100644 drivers/mfd/stpmic1.c
> create mode 100644 include/linux/mfd/stpmic1.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 11841f4..07e39a6 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1855,6 +1855,22 @@ config MFD_STM32_TIMERS
> for PWM and IIO Timer. This driver allow to share the
> registers between the others drivers.
>
> +config MFD_STPMIC1
> + tristate "Support for STPMIC1 PMIC"
> + depends on (I2C=y && OF)
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + select MFD_CORE
> + help
> + Support for ST Microelectronics STPMIC1 PMIC. STPMIC1 has power on
> + key, watchdog and regulator functionalities which are supported via
> + the relevant subsystems. This driver provides core support for the
> + STPMIC1, in order to use the actual functionaltiy of the device other
s/,/./
> + drivers must be enabled.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called stpmic1.
> +
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 5856a94..76fff14 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -232,6 +232,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) +=
> intel_soc_pmic_chtdc_ti.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> +obj-$(CONFIG_MFD_STPMIC1)+= stpmic1.o
> obj-$(CONFIG_MFD_SUN4I_GPADC)+= sun4i-gpadc.o
>
> obj-$(CONFIG_MFD_STM32_LPTIMER) += stm32-lptimer.o
> diff --git a/drivers/mfd/stpmic1.c b/drivers/mfd/stpmic1.c
> new file mode 100644
> index 000..2f4fd5e
> --- /dev/null
> +++ b/drivers/mfd/stpmic1.c
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) STMicroelectronics 2018
> +// Author: Pascal Paillet
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define STPMIC1_MAIN_IRQ 0
> +
> +static const struct regmap_range stpmic1_readable_ranges[] = {
> + regmap_reg_range(TURN_ON_SR, VERSION_SR),
> + regmap_reg_range(SWOFF_PWRCTRL_CR, LDO6_STDBY_CR),
> + regmap_reg_range(BST_SW_CR, BST_SW_CR),
> + regmap_reg_range(INT_PENDING_R1, INT_PENDING_R4),
> + regmap_reg_range(INT_CLEAR_R1, INT_CLEAR_R4),
> + regmap_reg_range(INT_MASK_R1, INT_MASK_R4),
> + regmap_reg_range(INT_SET_MASK_R1, INT_SET_MASK_R4),
> + regmap_reg_range(INT_CLEAR_MASK_R1, INT_CLEAR_MASK_R4),
> + regmap_reg_range(INT_SRC_R1, INT_SRC_R1),
> +};
> +
> +static const struct regmap_range stpmic1_writeable_ranges[] = {
> + regmap_reg_range(SWOFF_PWRCTRL_CR, LDO6_STDBY_CR),
> + regmap_reg_range(BST_SW_CR, BST_SW_CR),
> + regmap_reg_range(INT_CLEAR_R1, INT_CLEAR_R4),
> + regmap_reg_range(INT_SET_MASK_R1, INT_SET_MASK_R4),
> + regmap_reg_range(INT_CLEAR_MASK_R1, INT_CLEAR_MASK_R4),
> +};
> +
> +static const struct regmap_range stpmic1_volatile_ranges[] = {
> + regmap_reg_range(TURN_ON_SR, VERSION_SR),
> + regmap_reg_range(WCHDG_CR, WCHDG_CR),
> + regmap_reg_range(INT_PENDING_R1, INT_PENDING_R4),
> + regmap_reg_range(INT_SRC_R1, INT_SRC_R4),
> +};
Nice!
> +static const struct regmap_access_table stpmic1_readable_table = {
> + .yes_ranges = stpmic1_readable_ranges,
> + .n_yes_ranges = ARRAY_SIZE(stpmic1_readable_ranges),
> +};
> +
> +static const struct regmap_access_table stpmic1_writeable_table = {
> + .yes_ranges = stpmic1_writeable_ranges,
> + .n_yes_ranges = ARRAY_SIZE(stpmic1_writeable_ranges),
> +};
> +
> +static const struct regmap_access_table stpmic1_volatile_table = {
> + .yes_ranges = stpmic1_volatile_ranges,
> + .n_yes_ranges = ARRAY_SIZE(stpmic1_volatile_ranges),
> +};
> +
> +const struct regmap_config stpmic1_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .cache_type = REGCACHE_RBTREE,
> + .max_register = PMIC_MAX_REGISTER_ADDRESS,
> + .rd_table = _readable_table,
> + .wr_table = _writeable_table,
> + .volatile_table = _volatile_table,
> +};
> +
> +static const struct regmap_irq stpmic1_irqs[] = {
> +
Re: [RFC PATCH v3 10/13] soc: ti: Add MSI domain support for K3 Interrupt Aggregator
Hi Marc, On 06/11/18 2:11 PM, Lokesh Vutla wrote: With the system coprocessor managing the range allocation of the inputs to Interrupt Aggregator, it is difficult to represent the device IRQs from DT. The suggestion is to use MSI in such cases where devices wants to allocate and group interrupts dynamically. Create a MSI domain bus layer that allocates and frees MSIs for a device. APIs that are implemented are as follows: - inta_msi_create_irq_domain() that creates a MSI domain - inta_msi_domain_alloc_group_irqs() that creates MSIs for the specified device and source indexes. All these are expected to be grouped by the parent interrupt controller to MSI domain. - inta_msi_domain_free_group_irqs() frees the grouped irqs. Signed-off-by: Lokesh Vutla This is the initial implementation of MSI layer for the Interrupt Aggregator driver. In case if you have forgotten how the INTA is integrated with TISCI, below is the explanation: Device Index-x Device Index-y | | | | \ / \ / \ (global events) / +---+ | | | INTA | | | +---+ | (vint) | \|/ +---+ | | | INTR | | | +---+ | | \|/ (gic irq) +---+ | | | GIC| | | +---+ Now in the above diagram, Device indexes, global events, vints, gic irqs are managed dynamically in the available ranges for the current host. When a message is sent to system co-processor with the parameters(dev_id, dev_index, global_event, vint, gic_irq), it will: - Program the device index to global event. - Program the global event to vint in INTA (Grouping allowed if needed) - Program the vint to gic irq in INTR All the above configuration is done by sending a single message to system co-processor using TISCI protocol. Coming to software configuration: - gic irq range is managed by INTR driver as there can be devices other than INTA attached to INTR. - Global event range and vint range is managed by INTA driver. Now that device indexes are also managed dynamically by their respective drivers, MSIs are being used for allocation of Linux interrupts. This series tries to implement this allocation sequence using MSIs. I am mainly concerned about the prepare and the unprepare part. Parent interrupts to INTA are allocated and released using this prepare and unprepare callbacks. This might be wrong but I couldn't find a right place for it. Also, compose and write_msi_msg are no ops in this case as msi_msg addr and data are not used. Please take a look at this RFC series and provide your feedback. Thanks and regards, Lokesh --- - May be the same functionaly can be included in platform msi. But I would like to get a feedback on the approach. Changes since v1: - New patch drivers/soc/ti/Kconfig | 6 ++ drivers/soc/ti/Makefile| 1 + drivers/soc/ti/k3_inta_msi.c | 163 + include/linux/irqdomain.h | 1 + include/linux/msi.h| 6 ++ include/linux/soc/ti/k3_inta_msi.h | 21 6 files changed, 198 insertions(+) create mode 100644 drivers/soc/ti/k3_inta_msi.c create mode 100644 include/linux/soc/ti/k3_inta_msi.h diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig index be4570baad96..7640490c2a6a 100644 --- a/drivers/soc/ti/Kconfig +++ b/drivers/soc/ti/Kconfig @@ -73,4 +73,10 @@ config TI_SCI_PM_DOMAINS called ti_sci_pm_domains. Note this is needed early in boot before rootfs may be available. +config K3_INTA_MSI_DOMAIN + bool + select GENERIC_MSI_IRQ_DOMAIN + help + Driver to enable Interrupt Aggregator specific MSI Domain. + endif # SOC_TI diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile index a22edc0b258a..152b195273ee 100644 --- a/drivers/soc/ti/Makefile +++ b/drivers/soc/ti/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA)+= knav_dma.o obj-$(CONFIG_AMX3_PM) += pm33xx.o obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
Re: [RFC PATCH v3 10/13] soc: ti: Add MSI domain support for K3 Interrupt Aggregator
Hi Marc, On 06/11/18 2:11 PM, Lokesh Vutla wrote: With the system coprocessor managing the range allocation of the inputs to Interrupt Aggregator, it is difficult to represent the device IRQs from DT. The suggestion is to use MSI in such cases where devices wants to allocate and group interrupts dynamically. Create a MSI domain bus layer that allocates and frees MSIs for a device. APIs that are implemented are as follows: - inta_msi_create_irq_domain() that creates a MSI domain - inta_msi_domain_alloc_group_irqs() that creates MSIs for the specified device and source indexes. All these are expected to be grouped by the parent interrupt controller to MSI domain. - inta_msi_domain_free_group_irqs() frees the grouped irqs. Signed-off-by: Lokesh Vutla This is the initial implementation of MSI layer for the Interrupt Aggregator driver. In case if you have forgotten how the INTA is integrated with TISCI, below is the explanation: Device Index-x Device Index-y | | | | \ / \ / \ (global events) / +---+ | | | INTA | | | +---+ | (vint) | \|/ +---+ | | | INTR | | | +---+ | | \|/ (gic irq) +---+ | | | GIC| | | +---+ Now in the above diagram, Device indexes, global events, vints, gic irqs are managed dynamically in the available ranges for the current host. When a message is sent to system co-processor with the parameters(dev_id, dev_index, global_event, vint, gic_irq), it will: - Program the device index to global event. - Program the global event to vint in INTA (Grouping allowed if needed) - Program the vint to gic irq in INTR All the above configuration is done by sending a single message to system co-processor using TISCI protocol. Coming to software configuration: - gic irq range is managed by INTR driver as there can be devices other than INTA attached to INTR. - Global event range and vint range is managed by INTA driver. Now that device indexes are also managed dynamically by their respective drivers, MSIs are being used for allocation of Linux interrupts. This series tries to implement this allocation sequence using MSIs. I am mainly concerned about the prepare and the unprepare part. Parent interrupts to INTA are allocated and released using this prepare and unprepare callbacks. This might be wrong but I couldn't find a right place for it. Also, compose and write_msi_msg are no ops in this case as msi_msg addr and data are not used. Please take a look at this RFC series and provide your feedback. Thanks and regards, Lokesh --- - May be the same functionaly can be included in platform msi. But I would like to get a feedback on the approach. Changes since v1: - New patch drivers/soc/ti/Kconfig | 6 ++ drivers/soc/ti/Makefile| 1 + drivers/soc/ti/k3_inta_msi.c | 163 + include/linux/irqdomain.h | 1 + include/linux/msi.h| 6 ++ include/linux/soc/ti/k3_inta_msi.h | 21 6 files changed, 198 insertions(+) create mode 100644 drivers/soc/ti/k3_inta_msi.c create mode 100644 include/linux/soc/ti/k3_inta_msi.h diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig index be4570baad96..7640490c2a6a 100644 --- a/drivers/soc/ti/Kconfig +++ b/drivers/soc/ti/Kconfig @@ -73,4 +73,10 @@ config TI_SCI_PM_DOMAINS called ti_sci_pm_domains. Note this is needed early in boot before rootfs may be available. +config K3_INTA_MSI_DOMAIN + bool + select GENERIC_MSI_IRQ_DOMAIN + help + Driver to enable Interrupt Aggregator specific MSI Domain. + endif # SOC_TI diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile index a22edc0b258a..152b195273ee 100644 --- a/drivers/soc/ti/Makefile +++ b/drivers/soc/ti/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA)+= knav_dma.o obj-$(CONFIG_AMX3_PM) += pm33xx.o obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
Re: [PATCH v5 1/8] dt-bindings: mfd: document stpmic1
On Mon, 29 Oct 2018, Pascal PAILLET-LME wrote: > stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10 Nit: "STPMIC1 is a PMIC". Once corrected, please apply my: For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v5 1/8] dt-bindings: mfd: document stpmic1
On Mon, 29 Oct 2018, Pascal PAILLET-LME wrote: > stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10 Nit: "STPMIC1 is a PMIC". Once corrected, please apply my: For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH RESEND v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
On 13.11.18 08:04, Yogesh Narayan Gaur wrote: > Hi Frieder, > > Thanks for review. > >> -Original Message- >> From: Schrempf Frieder [mailto:frieder.schre...@kontron.de] >> Sent: Wednesday, November 7, 2018 9:52 PM >> To: Yogesh Narayan Gaur ; linux- >> m...@lists.infradead.org; boris.brezil...@bootlin.com; marek.va...@gmail.com; >> broo...@kernel.org; linux-...@vger.kernel.org; devicet...@vger.kernel.org >> Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- >> arm-ker...@lists.infradead.org; computersforpe...@gmail.com; >> frieder.schre...@exceet.de; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH RESEND v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI >> controller >> >> Hi Yogesh, >> >> I didn't have time to look at all of the code, but nevertheless here are some >> comments. >> >> On 23.10.18 10:56, Yogesh Narayan Gaur wrote: >>> - Add driver for NXP FlexSPI host controller >>> >>> (0) What is the FlexSPI controller? >>>FlexSPI is a flexsible SPI host controller which supports two SPI >>>channels and up to 4 external devices. Each channel supports >>>Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional >>>data lines) i.e. FlexSPI acts as an interface to external devices, >>>maximum 4, each with up to 8 bidirectional data lines. >>> >>>It uses new SPI memory interface of the SPI framework to issue >>>flash memory operations to up to four connected flash >>>devices (2 buses with 2 CS each). >>> >>> (1) Tested this driver with the mtd_debug and JFFS2 filesystem utility >>>on NXP LX2160ARDB and LX2160AQDS targets. >>>LX2160ARDB is having two NOR slave device connected on single bus A >>>i.e. A0 and A1 (CS0 and CS1). >>>LX2160AQDS is having two NOR slave device connected on separate buses >>>one flash on A0 and second on B1 i.e. (CS0 and CS3). >>>Verified this driver on following SPI NOR flashes: >>> Micron, mt35xu512ab, [Read - 1 bit mode] >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] >>> >>> Signed-off-by: Yogesh Gaur >>> --- >>> Changes for v4: >>> - Incorporate Boris review comments >>> * Use readl_poll_timeout() instead of busy looping. >>> * Re-define register masking as per comment. >>> * Drop fspi_devtype enum. >>> Changes for v3: >>> - Added endianness flag in platform specific structure instead of DTS. >>> - Modified nxp_fspi_read_ahb(), removed remapping code. >>> - Added Boris and Frieder as Author and provided reference of >>> spi-fsl-qspi.c Changes for v2: >>> - Incorporated Boris review comments. >>> - Remove dependency of driver over connected flash device size. >>> - Modified the logic to select requested CS. >>> - Remove SPI-Octal Macros. >>> >>>drivers/spi/Kconfig| 10 + >>>drivers/spi/Makefile |1 + >>>drivers/spi/spi-nxp-fspi.c | 1158 >> >>>3 files changed, 1169 insertions(+) >>>create mode 100644 drivers/spi/spi-nxp-fspi.c >>> >>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index >>> ad5d68e..68da874 100644 >>> --- a/drivers/spi/Kconfig >>> +++ b/drivers/spi/Kconfig >>> @@ -251,6 +251,16 @@ config SPI_FSL_LPSPI >>> help >>> This enables Freescale i.MX LPSPI controllers in master mode. >>> >>> +config SPI_NXP_FLEXSPI >>> + tristate "NXP Flex SPI controller" >>> + depends on ARCH_LAYERSCAPE || HAS_IOMEM >>> + help >>> + This enables support for the Flex SPI controller in master mode. >>> + Up to four slave devices can be connected on two buses with two >>> + chipselects each. >>> + This controller does not support generic SPI messages and only >>> + supports the high-level SPI memory interface. >>> + >>>config SPI_GPIO >>> tristate "GPIO-based bitbanging SPI Master" >>> depends on GPIOLIB || COMPILE_TEST >>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index >>> cb1f437..52c9f18 100644 >>> --- a/drivers/spi/Makefile >>> +++ b/drivers/spi/Makefile >>> @@ -59,6 +59,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi- >> mpc52xx.o >>>obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o >>>obj-$(CONFIG_SPI_MXS)+= spi-mxs.o >>>obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o >>> +obj-$(CONFIG_SPI_NXP_FLEXSPI) += spi-nxp-fspi.o >>>obj-$(CONFIG_SPI_OC_TINY)+= spi-oc-tiny.o >>>spi-octeon-objs := spi-cavium.o spi-cavium- >> octeon.o >>>obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o >>> diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c >>> new file mode 100644 index 000..e5188b2 >>> --- /dev/null >>> +++ b/drivers/spi/spi-nxp-fspi.c >>> @@ -0,0 +1,1158 @@ >>> +// SPDX-License-Identifier: GPL-2.0+ >>> + >>> +/* >>> + * NXP FlexSPI(FSPI) controller driver. >>> + * >>> + * Copyright 2018 NXP. >>> + * >>> + * FlexSPI is a flexsible SPI host controller which supports two SPI >>> + * channels and up to 4
Re: [PATCH RESEND v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
On 13.11.18 08:04, Yogesh Narayan Gaur wrote: > Hi Frieder, > > Thanks for review. > >> -Original Message- >> From: Schrempf Frieder [mailto:frieder.schre...@kontron.de] >> Sent: Wednesday, November 7, 2018 9:52 PM >> To: Yogesh Narayan Gaur ; linux- >> m...@lists.infradead.org; boris.brezil...@bootlin.com; marek.va...@gmail.com; >> broo...@kernel.org; linux-...@vger.kernel.org; devicet...@vger.kernel.org >> Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- >> arm-ker...@lists.infradead.org; computersforpe...@gmail.com; >> frieder.schre...@exceet.de; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH RESEND v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI >> controller >> >> Hi Yogesh, >> >> I didn't have time to look at all of the code, but nevertheless here are some >> comments. >> >> On 23.10.18 10:56, Yogesh Narayan Gaur wrote: >>> - Add driver for NXP FlexSPI host controller >>> >>> (0) What is the FlexSPI controller? >>>FlexSPI is a flexsible SPI host controller which supports two SPI >>>channels and up to 4 external devices. Each channel supports >>>Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional >>>data lines) i.e. FlexSPI acts as an interface to external devices, >>>maximum 4, each with up to 8 bidirectional data lines. >>> >>>It uses new SPI memory interface of the SPI framework to issue >>>flash memory operations to up to four connected flash >>>devices (2 buses with 2 CS each). >>> >>> (1) Tested this driver with the mtd_debug and JFFS2 filesystem utility >>>on NXP LX2160ARDB and LX2160AQDS targets. >>>LX2160ARDB is having two NOR slave device connected on single bus A >>>i.e. A0 and A1 (CS0 and CS1). >>>LX2160AQDS is having two NOR slave device connected on separate buses >>>one flash on A0 and second on B1 i.e. (CS0 and CS3). >>>Verified this driver on following SPI NOR flashes: >>> Micron, mt35xu512ab, [Read - 1 bit mode] >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] >>> >>> Signed-off-by: Yogesh Gaur >>> --- >>> Changes for v4: >>> - Incorporate Boris review comments >>> * Use readl_poll_timeout() instead of busy looping. >>> * Re-define register masking as per comment. >>> * Drop fspi_devtype enum. >>> Changes for v3: >>> - Added endianness flag in platform specific structure instead of DTS. >>> - Modified nxp_fspi_read_ahb(), removed remapping code. >>> - Added Boris and Frieder as Author and provided reference of >>> spi-fsl-qspi.c Changes for v2: >>> - Incorporated Boris review comments. >>> - Remove dependency of driver over connected flash device size. >>> - Modified the logic to select requested CS. >>> - Remove SPI-Octal Macros. >>> >>>drivers/spi/Kconfig| 10 + >>>drivers/spi/Makefile |1 + >>>drivers/spi/spi-nxp-fspi.c | 1158 >> >>>3 files changed, 1169 insertions(+) >>>create mode 100644 drivers/spi/spi-nxp-fspi.c >>> >>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index >>> ad5d68e..68da874 100644 >>> --- a/drivers/spi/Kconfig >>> +++ b/drivers/spi/Kconfig >>> @@ -251,6 +251,16 @@ config SPI_FSL_LPSPI >>> help >>> This enables Freescale i.MX LPSPI controllers in master mode. >>> >>> +config SPI_NXP_FLEXSPI >>> + tristate "NXP Flex SPI controller" >>> + depends on ARCH_LAYERSCAPE || HAS_IOMEM >>> + help >>> + This enables support for the Flex SPI controller in master mode. >>> + Up to four slave devices can be connected on two buses with two >>> + chipselects each. >>> + This controller does not support generic SPI messages and only >>> + supports the high-level SPI memory interface. >>> + >>>config SPI_GPIO >>> tristate "GPIO-based bitbanging SPI Master" >>> depends on GPIOLIB || COMPILE_TEST >>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index >>> cb1f437..52c9f18 100644 >>> --- a/drivers/spi/Makefile >>> +++ b/drivers/spi/Makefile >>> @@ -59,6 +59,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi- >> mpc52xx.o >>>obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o >>>obj-$(CONFIG_SPI_MXS)+= spi-mxs.o >>>obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o >>> +obj-$(CONFIG_SPI_NXP_FLEXSPI) += spi-nxp-fspi.o >>>obj-$(CONFIG_SPI_OC_TINY)+= spi-oc-tiny.o >>>spi-octeon-objs := spi-cavium.o spi-cavium- >> octeon.o >>>obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o >>> diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c >>> new file mode 100644 index 000..e5188b2 >>> --- /dev/null >>> +++ b/drivers/spi/spi-nxp-fspi.c >>> @@ -0,0 +1,1158 @@ >>> +// SPDX-License-Identifier: GPL-2.0+ >>> + >>> +/* >>> + * NXP FlexSPI(FSPI) controller driver. >>> + * >>> + * Copyright 2018 NXP. >>> + * >>> + * FlexSPI is a flexsible SPI host controller which supports two SPI >>> + * channels and up to 4
Re: [PATCH v6 2/6] mfd: rk808: Add RK817 and RK809 support
On Tue, 30 Oct 2018, Tony Xie wrote:
> The rk809 and rk817 are a Power Management IC (PMIC) for multimedia
"RK809 and RK817"
> and handheld devices. It contains the following components:
s/It contains/They contain/
> - Regulators
> - RTC
> - Clocking
>
> Both RK809 and RK817 chips are using a similar register map,
> so we can reuse the RTC and Clocking and regulators functionality.
By is "Clocking" capitalised, but "regulators" is not?
> Signed-off-by: Tony Xie
> Acked-by: Stephen Boyd
> ---
> drivers/mfd/Kconfig | 6 +-
> drivers/mfd/rk808.c | 225
> +++---
> include/linux/mfd/rk808.h | 172 +++
> 3 files changed, 386 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index b860eb5..f8b1922 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -967,14 +967,14 @@ config MFD_RC5T583
> different functionality of the device.
>
> config MFD_RK808
> - tristate "Rockchip RK805/RK808/RK818 Power Management Chip"
> + tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip"
> depends on I2C && OF
> select MFD_CORE
> select REGMAP_I2C
> select REGMAP_IRQ
> help
> - If you say yes here you get support for the RK805, RK808 and RK818
> - Power Management chips.
> + If you say yes here you get support for the RK805, RK808, RK809,
> + RK817 and RK818 Power Management chips.
> This driver provides common support for accessing the device
> through I2C interface. The device supports multiple sub-devices
> including interrupts, RTC, LDO & DCDC regulators, and onkey.
> diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
> index 216fbf6..9da1035 100644
> --- a/drivers/mfd/rk808.c
> +++ b/drivers/mfd/rk808.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> struct rk808_reg_data {
> int addr;
> @@ -62,6 +63,29 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> return false;
> }
>
> +static bool rk817_is_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /*
> + * Notes:
> + * - Technically the ROUND_30s bit makes RTC_CTRL_REG volatile, but
> + * we don't use that feature. It's better to cache.
> + * - It's unlikely we care that RK808_DEVCTRL_REG is volatile since
> + * bits are cleared in case when we shutoff anyway, but better safe.
This last line does not read well.
> + */
> +
> + switch (reg) {
> + case RK817_SECONDS_REG ... RK817_WEEKS_REG:
> + case RK817_RTC_STATUS_REG:
> + case RK817_INT_STS_REG0:
> + case RK817_INT_STS_REG1:
> + case RK817_INT_STS_REG2:
> + case RK817_SYS_STS:
> + return true;
> + }
> +
> + return true;
> +}
> +
> static const struct regmap_config rk818_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> @@ -86,6 +110,14 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> .volatile_reg = rk808_is_volatile_reg,
> };
>
> +static const struct regmap_config rk817_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = RK817_GPIO_INT_CFG,
> + .cache_type = REGCACHE_NONE,
> + .volatile_reg = rk817_is_volatile_reg,
> +};
> +
> static struct resource rtc_resources[] = {
> {
> .start = RK808_IRQ_RTC_ALARM,
> @@ -94,6 +126,13 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> }
> };
>
> +static struct resource rk817_rtc_resources[] = {
> + {
> + .start = RK817_IRQ_RTC_ALARM,
> + .end= RK817_IRQ_RTC_ALARM,
> + .flags = IORESOURCE_IRQ,
> + }
> +};
Consider converting these to DEFINE_RES_IRQ_NAMED()
> static struct resource rk805_key_resources[] = {
> {
> .start = RK805_IRQ_PWRON_FALL,
> @@ -107,6 +146,19 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> }
> };
>
> +static struct resource rk817_pwrkey_resources[] = {
> + {
> + .start = RK817_IRQ_PWRON_RISE,
> + .end= RK817_IRQ_PWRON_RISE,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = RK817_IRQ_PWRON_FALL,
> + .end= RK817_IRQ_PWRON_FALL,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static const struct mfd_cell rk805s[] = {
> { .name = "rk808-clkout", },
> { .name = "rk808-regulator", },
> @@ -132,6 +184,21 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> },
> };
>
> +static const struct mfd_cell rk817s[] = {
> + { .name = "rk808-clkout",},
> + { .name = "rk808-regulator",},
> + {
> + .name = "rk8xx-pwrkey",
> + .num_resources = ARRAY_SIZE(rk817_pwrkey_resources),
> +
Re: [PATCH v6 2/6] mfd: rk808: Add RK817 and RK809 support
On Tue, 30 Oct 2018, Tony Xie wrote:
> The rk809 and rk817 are a Power Management IC (PMIC) for multimedia
"RK809 and RK817"
> and handheld devices. It contains the following components:
s/It contains/They contain/
> - Regulators
> - RTC
> - Clocking
>
> Both RK809 and RK817 chips are using a similar register map,
> so we can reuse the RTC and Clocking and regulators functionality.
By is "Clocking" capitalised, but "regulators" is not?
> Signed-off-by: Tony Xie
> Acked-by: Stephen Boyd
> ---
> drivers/mfd/Kconfig | 6 +-
> drivers/mfd/rk808.c | 225
> +++---
> include/linux/mfd/rk808.h | 172 +++
> 3 files changed, 386 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index b860eb5..f8b1922 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -967,14 +967,14 @@ config MFD_RC5T583
> different functionality of the device.
>
> config MFD_RK808
> - tristate "Rockchip RK805/RK808/RK818 Power Management Chip"
> + tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip"
> depends on I2C && OF
> select MFD_CORE
> select REGMAP_I2C
> select REGMAP_IRQ
> help
> - If you say yes here you get support for the RK805, RK808 and RK818
> - Power Management chips.
> + If you say yes here you get support for the RK805, RK808, RK809,
> + RK817 and RK818 Power Management chips.
> This driver provides common support for accessing the device
> through I2C interface. The device supports multiple sub-devices
> including interrupts, RTC, LDO & DCDC regulators, and onkey.
> diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
> index 216fbf6..9da1035 100644
> --- a/drivers/mfd/rk808.c
> +++ b/drivers/mfd/rk808.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> struct rk808_reg_data {
> int addr;
> @@ -62,6 +63,29 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> return false;
> }
>
> +static bool rk817_is_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /*
> + * Notes:
> + * - Technically the ROUND_30s bit makes RTC_CTRL_REG volatile, but
> + * we don't use that feature. It's better to cache.
> + * - It's unlikely we care that RK808_DEVCTRL_REG is volatile since
> + * bits are cleared in case when we shutoff anyway, but better safe.
This last line does not read well.
> + */
> +
> + switch (reg) {
> + case RK817_SECONDS_REG ... RK817_WEEKS_REG:
> + case RK817_RTC_STATUS_REG:
> + case RK817_INT_STS_REG0:
> + case RK817_INT_STS_REG1:
> + case RK817_INT_STS_REG2:
> + case RK817_SYS_STS:
> + return true;
> + }
> +
> + return true;
> +}
> +
> static const struct regmap_config rk818_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> @@ -86,6 +110,14 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> .volatile_reg = rk808_is_volatile_reg,
> };
>
> +static const struct regmap_config rk817_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = RK817_GPIO_INT_CFG,
> + .cache_type = REGCACHE_NONE,
> + .volatile_reg = rk817_is_volatile_reg,
> +};
> +
> static struct resource rtc_resources[] = {
> {
> .start = RK808_IRQ_RTC_ALARM,
> @@ -94,6 +126,13 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> }
> };
>
> +static struct resource rk817_rtc_resources[] = {
> + {
> + .start = RK817_IRQ_RTC_ALARM,
> + .end= RK817_IRQ_RTC_ALARM,
> + .flags = IORESOURCE_IRQ,
> + }
> +};
Consider converting these to DEFINE_RES_IRQ_NAMED()
> static struct resource rk805_key_resources[] = {
> {
> .start = RK805_IRQ_PWRON_FALL,
> @@ -107,6 +146,19 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> }
> };
>
> +static struct resource rk817_pwrkey_resources[] = {
> + {
> + .start = RK817_IRQ_PWRON_RISE,
> + .end= RK817_IRQ_PWRON_RISE,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = RK817_IRQ_PWRON_FALL,
> + .end= RK817_IRQ_PWRON_FALL,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static const struct mfd_cell rk805s[] = {
> { .name = "rk808-clkout", },
> { .name = "rk808-regulator", },
> @@ -132,6 +184,21 @@ static bool rk808_is_volatile_reg(struct device *dev,
> unsigned int reg)
> },
> };
>
> +static const struct mfd_cell rk817s[] = {
> + { .name = "rk808-clkout",},
> + { .name = "rk808-regulator",},
> + {
> + .name = "rk8xx-pwrkey",
> + .num_resources = ARRAY_SIZE(rk817_pwrkey_resources),
> +
[PATCH] fork: Fix two -Wmissing-prototypes warnings
We get two warning when building kernel with W=1: kernel/fork.c:167:13: warning: no previous prototype for ‘arch_release_thread_stack’ [-Wmissing-prototypes] kernel/fork.c:779:13: warning: no previous prototype for ‘fork_init’ [-Wmissing-prototypes] Add the missing declaration in head file to fix this. Signed-off-by: Yi Wang --- arch/x86/include/asm/thread_info.h | 1 + include/linux/sched/task.h | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h index 2ff2a30..8621036 100644 --- a/arch/x86/include/asm/thread_info.h +++ b/arch/x86/include/asm/thread_info.h @@ -237,6 +237,7 @@ static inline int arch_within_stack_frames(const void * const stack, extern void arch_task_cache_init(void); extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src); extern void arch_release_task_struct(struct task_struct *tsk); +extern void arch_release_thread_stack(unsigned long *stack); extern void arch_setup_new_exec(void); #define arch_setup_new_exec arch_setup_new_exec #endif /* !__ASSEMBLY__ */ diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h index 108ede9..44c6f15 100644 --- a/include/linux/sched/task.h +++ b/include/linux/sched/task.h @@ -39,6 +39,8 @@ extern void proc_caches_init(void); +extern void fork_init(void); + extern void release_task(struct task_struct * p); #ifdef CONFIG_HAVE_COPY_THREAD_TLS -- 1.8.3.1
[PATCH] fork: Fix two -Wmissing-prototypes warnings
We get two warning when building kernel with W=1: kernel/fork.c:167:13: warning: no previous prototype for ‘arch_release_thread_stack’ [-Wmissing-prototypes] kernel/fork.c:779:13: warning: no previous prototype for ‘fork_init’ [-Wmissing-prototypes] Add the missing declaration in head file to fix this. Signed-off-by: Yi Wang --- arch/x86/include/asm/thread_info.h | 1 + include/linux/sched/task.h | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h index 2ff2a30..8621036 100644 --- a/arch/x86/include/asm/thread_info.h +++ b/arch/x86/include/asm/thread_info.h @@ -237,6 +237,7 @@ static inline int arch_within_stack_frames(const void * const stack, extern void arch_task_cache_init(void); extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src); extern void arch_release_task_struct(struct task_struct *tsk); +extern void arch_release_thread_stack(unsigned long *stack); extern void arch_setup_new_exec(void); #define arch_setup_new_exec arch_setup_new_exec #endif /* !__ASSEMBLY__ */ diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h index 108ede9..44c6f15 100644 --- a/include/linux/sched/task.h +++ b/include/linux/sched/task.h @@ -39,6 +39,8 @@ extern void proc_caches_init(void); +extern void fork_init(void); + extern void release_task(struct task_struct * p); #ifdef CONFIG_HAVE_COPY_THREAD_TLS -- 1.8.3.1
Re: [GIT PULL] PCI changes for v4.20
* Bjorn Helgaas wrote: > PCI changes: > > - Pay attention to device-specific _PXM node values (Jonathan Cameron) There's a new boot regression, my AMD ThreadRipper system (MSI X399 SLI PLUS (MS-7B09)) hangs during early bootup, and I have bisected it down to this commit: bad7dcd94f39: ACPI/PCI: Pay attention to device-specific _PXM node values Reverting it solves the hang. Unfortunately there's no console output when it hangs, even with earlyprintk. It just hangs after the "loading initrd" line. Config is an Ubuntu-ish config with PROVE_LOCKING=y and a few other debug options. All my other testsystems boot fine with similar configs, so it's probably something specific to this system. Thanks, Ingo
[rtnetlink] Potential bug in Linux (rt)netlink code (repost from linux-netdev)?
Hi, I am working on a self-written routing agent (https://github.com/OLSR/OONF) and am stuck on a problem with netlink that I cannot explain with an userspace error. I am using a netlink socket for setting routes (RTM_NEWROUTE/RTM_DELROUTE), querying the kernel for the current routes in the database (via a RTM_GETROUTE dump) and for getting multicast messages for ongoing routing changes. After a few netlink messages I get to the point where the kernel just does not responst to a RTM_NEWROUTE. No error, no answer, despite the NLM_F_ACK flag set)... but sometime when (during shutdown of the routing agent) the program sends another route command (most times a RTM_DELROUTE) I get a single netlink packet with a "successful" response for both the "missing" RTM_NEWROUTE and one for the new RTM DELROUTE sequence number. I am testing two routing agents, each of them in a systemd-nspawn based container connected over a bridge on the host system on a current Debian Testing (kernel 4.18.0-1-amd64). I am directly using the netlink sockets, without any other userspace library in between. I have checked the hexdumps of a couple of netlink messages (including the ones just before the bug happens) by hand and they seem to be okay. When I tried to add a "netlink listener" socket for futher debugging (ip link add nlmon0 type nlmon) the problem vanished until I removed the listener socket again. Any ideas how to debug this problem? Unfortunately I have no short example program to trigger the bug... I have rarely seen the problem for years (once every couple of months), but until a few days ago I never managed to reproduce it. I have asked on linux-netdev but got no reply expect for a question about rate-limitation. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Zanderstrasse 5, 53177 Bonn, Germany Telefon +49 228 50212-469 mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
[rtnetlink] Potential bug in Linux (rt)netlink code (repost from linux-netdev)?
Hi, I am working on a self-written routing agent (https://github.com/OLSR/OONF) and am stuck on a problem with netlink that I cannot explain with an userspace error. I am using a netlink socket for setting routes (RTM_NEWROUTE/RTM_DELROUTE), querying the kernel for the current routes in the database (via a RTM_GETROUTE dump) and for getting multicast messages for ongoing routing changes. After a few netlink messages I get to the point where the kernel just does not responst to a RTM_NEWROUTE. No error, no answer, despite the NLM_F_ACK flag set)... but sometime when (during shutdown of the routing agent) the program sends another route command (most times a RTM_DELROUTE) I get a single netlink packet with a "successful" response for both the "missing" RTM_NEWROUTE and one for the new RTM DELROUTE sequence number. I am testing two routing agents, each of them in a systemd-nspawn based container connected over a bridge on the host system on a current Debian Testing (kernel 4.18.0-1-amd64). I am directly using the netlink sockets, without any other userspace library in between. I have checked the hexdumps of a couple of netlink messages (including the ones just before the bug happens) by hand and they seem to be okay. When I tried to add a "netlink listener" socket for futher debugging (ip link add nlmon0 type nlmon) the problem vanished until I removed the listener socket again. Any ideas how to debug this problem? Unfortunately I have no short example program to trigger the bug... I have rarely seen the problem for years (once every couple of months), but until a few days ago I never managed to reproduce it. I have asked on linux-netdev but got no reply expect for a question about rate-limitation. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Zanderstrasse 5, 53177 Bonn, Germany Telefon +49 228 50212-469 mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
Re: [GIT PULL] PCI changes for v4.20
* Bjorn Helgaas wrote: > PCI changes: > > - Pay attention to device-specific _PXM node values (Jonathan Cameron) There's a new boot regression, my AMD ThreadRipper system (MSI X399 SLI PLUS (MS-7B09)) hangs during early bootup, and I have bisected it down to this commit: bad7dcd94f39: ACPI/PCI: Pay attention to device-specific _PXM node values Reverting it solves the hang. Unfortunately there's no console output when it hangs, even with earlyprintk. It just hangs after the "loading initrd" line. Config is an Ubuntu-ish config with PROVE_LOCKING=y and a few other debug options. All my other testsystems boot fine with similar configs, so it's probably something specific to this system. Thanks, Ingo
RE: [PATCH v5 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox
> -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Monday, November 12, 2018 9:56 AM > To: Jiaying Liang > Cc: jassisinghb...@gmail.com; Michal Simek ; > mark.rutl...@arm.com; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v5 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox > > On Mon, Nov 05, 2018 at 02:37:01PM -0800, Wendy Liang wrote: > > Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block in > > ZynqMP SoC used for the communication between various processor > > systems. > > > > Signed-off-by: Wendy Liang > > --- > > .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 128 > + > > 1 file changed, 128 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt > > > > diff --git > > a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.tx > > t > > b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi- > mailbox.tx > > t > > new file mode 100644 > > index 000..18fd7b4 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi- > mailbo > > +++ x.txt > > @@ -0,0 +1,128 @@ > > +Xilinx IPI Mailbox Controller > > + > > + > > +The Xilinx IPI(Inter Processor Interrupt) mailbox controller is to > > +manage messaging between two Xilinx Zynq UltraScale+ MPSoC IPI > > +agents. Each IPI agent owns registers used for notification and buffers for > message. > > + > > + +-+ > > + | Xilinx ZynqMP IPI Controller| > > + +-+ > > ++--+ > > +ATF| | > > + | | > > + | | > > ++--+ | > > + | | > > + | | > > ++--+ > > ++--+ > > +| ++ ++ | > > +Hardware| | IPI Agent | | IPI Buffers | | > > +| | Registers | || | > > +| || || | > > +| ++ ++ | > > +| | > > +| Xilinx IPI Agent Block | > > ++--+ > > + > > + > > +Controller Device Node: > > +=== > > +Required properties: > > + > > +IPI agent node: > > +- compatible: Shall be: "xlnx,zynqmp-ipi-mailbox" > > +- interrupt-parent:Phandle for the interrupt controller > > +- interrupts: Interrupt information corresponding to the > > + interrupt-names property. > > +- xlnx,ipi-id: local Xilinx IPI agent ID > > +- #address-cells: number of address cells of internal IPI mailbox nodes > > +- #size-cells: number of size cells of internal IPI mailbox > > nodes > > + > > +Internal IPI mailbox node: > > +- reg: IPI buffers address ranges > > +- reg-names: Names of the reg resources. It should have: > > + * local_request_region > > + - IPI request msg buffer written by local and read > > + by remote > > + * local_response_region > > + - IPI response msg buffer written by local and read > > + by remote > > + * remote_request_region > > + - IPI request msg buffer written by remote and read > > + by local > > + * remote_response_region > > + - IPI response msg buffer written by remote and > read > > + by local > > +- #mbox-cells: Shall be 1. It contains: > > + * tx(0) or rx(1) channel > > +- xlnx,ipi-id: remote Xilinx IPI agent ID of which the mailbox > > is > > + connected to. > > + > > +Optional properties: > > + > > +- method: The method of accessing the IPI agent registers. > > + Permitted values are: "smc" and "hvc". Default is > > + "smc". > > + > > +Client Device Node: > > +=== > > +Required properties: > > + > > +- mboxes: Standard property to specify a mailbox > > + (See ./mailbox.txt) > > +- mbox-names: List of identifier strings for each mailbox > > +
RE: [PATCH v5 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox
> -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Monday, November 12, 2018 9:56 AM > To: Jiaying Liang > Cc: jassisinghb...@gmail.com; Michal Simek ; > mark.rutl...@arm.com; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v5 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox > > On Mon, Nov 05, 2018 at 02:37:01PM -0800, Wendy Liang wrote: > > Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block in > > ZynqMP SoC used for the communication between various processor > > systems. > > > > Signed-off-by: Wendy Liang > > --- > > .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 128 > + > > 1 file changed, 128 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt > > > > diff --git > > a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.tx > > t > > b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi- > mailbox.tx > > t > > new file mode 100644 > > index 000..18fd7b4 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi- > mailbo > > +++ x.txt > > @@ -0,0 +1,128 @@ > > +Xilinx IPI Mailbox Controller > > + > > + > > +The Xilinx IPI(Inter Processor Interrupt) mailbox controller is to > > +manage messaging between two Xilinx Zynq UltraScale+ MPSoC IPI > > +agents. Each IPI agent owns registers used for notification and buffers for > message. > > + > > + +-+ > > + | Xilinx ZynqMP IPI Controller| > > + +-+ > > ++--+ > > +ATF| | > > + | | > > + | | > > ++--+ | > > + | | > > + | | > > ++--+ > > ++--+ > > +| ++ ++ | > > +Hardware| | IPI Agent | | IPI Buffers | | > > +| | Registers | || | > > +| || || | > > +| ++ ++ | > > +| | > > +| Xilinx IPI Agent Block | > > ++--+ > > + > > + > > +Controller Device Node: > > +=== > > +Required properties: > > + > > +IPI agent node: > > +- compatible: Shall be: "xlnx,zynqmp-ipi-mailbox" > > +- interrupt-parent:Phandle for the interrupt controller > > +- interrupts: Interrupt information corresponding to the > > + interrupt-names property. > > +- xlnx,ipi-id: local Xilinx IPI agent ID > > +- #address-cells: number of address cells of internal IPI mailbox nodes > > +- #size-cells: number of size cells of internal IPI mailbox > > nodes > > + > > +Internal IPI mailbox node: > > +- reg: IPI buffers address ranges > > +- reg-names: Names of the reg resources. It should have: > > + * local_request_region > > + - IPI request msg buffer written by local and read > > + by remote > > + * local_response_region > > + - IPI response msg buffer written by local and read > > + by remote > > + * remote_request_region > > + - IPI request msg buffer written by remote and read > > + by local > > + * remote_response_region > > + - IPI response msg buffer written by remote and > read > > + by local > > +- #mbox-cells: Shall be 1. It contains: > > + * tx(0) or rx(1) channel > > +- xlnx,ipi-id: remote Xilinx IPI agent ID of which the mailbox > > is > > + connected to. > > + > > +Optional properties: > > + > > +- method: The method of accessing the IPI agent registers. > > + Permitted values are: "smc" and "hvc". Default is > > + "smc". > > + > > +Client Device Node: > > +=== > > +Required properties: > > + > > +- mboxes: Standard property to specify a mailbox > > + (See ./mailbox.txt) > > +- mbox-names: List of identifier strings for each mailbox > > +
Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties
Hi Jacek,
On 12/11/2018 18.02, Jacek Anaszewski wrote:
Support for RGB LEDs, or other variations of LED synchronization
have been approached several times, but without satisfying result
so far.
Generally the problem boils down to the issue of how triggers
should handle multiple synchronized LED class devices in a backwards
compatible way with monochrome LEDs.
At some point the HSV [0] approach was proposed, but there was a problem
with getting uniform colors across devices. Especially white.
Certainly a calibration mechanism would be required.
[0] https://lkml.org/lkml/2017/8/30/423
We do not usually use PWM controlled leds so our calibration has been HW
engineer tuning the resistors for the leds to get acceptable color for
different colors variations.
If one wants to have fixed colors for such device then one could use
this similar method to define them or/and free form interface to enter
RGB values there. Thou with PWM RGB leds you probably want to have more
animation there which probably would require some additional support code.
One way to do atomic PWM RGB color change with sysfs could be:
echo "21 223 242" > color
or
echo "21 223 242" > rgb
or:
echo "r:21 g:232 b:242" > color (or something similar)
and if there is know registered name then just write it to "color" which
would pick registered color rgb values to led instances rgb value.
Now for PWM RGB led one could use "brightness" and "rgb" value to
calculate actual color with some color space formula (like hsv in [0]).
Doing white with RGB LED is a bit hard so usually you want to get RGBW
LED (or RGBAW LED) if "real" white is something that is needed. This
could then be "rgbw" entry and "color" to pick from fixed set.
These presets in device tree for "color" could be considered one way of
doing calibration for particular hardware.
So in device tree for RGB PWM led it could be like:
color-orange {
rgb = <249 197 9>
}
color-warm-white {
rgb = <255 253 249>
}
How would that sound like?
Thank you for the description of your approach.
Predefined DT color definitions make an interesting option. Nonetheless,
your design assumes that for RGB LEDs max_brightness would have to be
always 1.
While it would solve the issue, it wouldn't allow to benefit from
the whole potential of RGB LEDs - think of having adjustable "color
brightness" (like in HSV color model).
What I tried to describe above was that these could also work with HSV
model also with larger brigtness values too.
Let's say we do following sequence to change from off state to user
configured intensity value:
# Turn off leds
echo 0 > brightness
# Select requested color
echo "orange" > color
# Use configured LED intensity from user configuration
echo 84 > brightness
Driver would now use rgb value <249 197 9> and brightness <84> to
calculate (with HSV solution) real PWM values for the led component
colors. With led controller this is probably easier to get linear
feedback but for generic PWM controller you may want to utilize PWM
curve feature like defined for backlight driver.
When thinking this I instantly see my self with thinking PS4's
sliding/pulsing color animation for orange/blue/white. And controlling
this animation steps manually from user space probably is not the best
idea so like with blinking you would need more accurately timed action
within kernel I suppose (or hardware with the support).
With that idea forward:
# Turning animation sequencer off causes instant changes for values
echo "off" > animation-sequencer
# User 1 second for animation (no effect yet as sequencer is off)
echo 1000 > animation-time-ms (or so)
# Turn off leds (instance change)
echo 0 > brightness
# Select requested color (instant change)
echo "orange" > color
# Change to linear animation sequencer
echo "linear" > animation-sequencer
# Now everything from this point is subject to animation sequencer
# Sequencer remember active state and next state (as seen in sysfs)
# Use configured LED intensity from user configuration (no effect yet)
echo 84 > brightness
# Trigger transition sequence
echo load > animation-sequencer
# This would cause 1 second animation from black to orange with user
intensivity of 84
# Wait for transition to complete and some extra
sleep 4
# Change color to blue with animation
echo "blue" > color
echo load > animation-sequencer
# This would cause driver to change from orange to blue in current
intensivity level during 1 second period
# -- end --
Now that went a bit ahead of time but I believe it demonstrates the
potential for this approach with combined with HSL functionality for future.
How abut allowing for providing an array of color intensity/brightness
levels per each color? In the simplest case there could be a single
level per color, but it should be possible to provide up to 255 levels.
I believe that brightness and color should be separate topics.
We have in our devices option in user interface to
Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties
Hi Jacek,
On 12/11/2018 18.02, Jacek Anaszewski wrote:
Support for RGB LEDs, or other variations of LED synchronization
have been approached several times, but without satisfying result
so far.
Generally the problem boils down to the issue of how triggers
should handle multiple synchronized LED class devices in a backwards
compatible way with monochrome LEDs.
At some point the HSV [0] approach was proposed, but there was a problem
with getting uniform colors across devices. Especially white.
Certainly a calibration mechanism would be required.
[0] https://lkml.org/lkml/2017/8/30/423
We do not usually use PWM controlled leds so our calibration has been HW
engineer tuning the resistors for the leds to get acceptable color for
different colors variations.
If one wants to have fixed colors for such device then one could use
this similar method to define them or/and free form interface to enter
RGB values there. Thou with PWM RGB leds you probably want to have more
animation there which probably would require some additional support code.
One way to do atomic PWM RGB color change with sysfs could be:
echo "21 223 242" > color
or
echo "21 223 242" > rgb
or:
echo "r:21 g:232 b:242" > color (or something similar)
and if there is know registered name then just write it to "color" which
would pick registered color rgb values to led instances rgb value.
Now for PWM RGB led one could use "brightness" and "rgb" value to
calculate actual color with some color space formula (like hsv in [0]).
Doing white with RGB LED is a bit hard so usually you want to get RGBW
LED (or RGBAW LED) if "real" white is something that is needed. This
could then be "rgbw" entry and "color" to pick from fixed set.
These presets in device tree for "color" could be considered one way of
doing calibration for particular hardware.
So in device tree for RGB PWM led it could be like:
color-orange {
rgb = <249 197 9>
}
color-warm-white {
rgb = <255 253 249>
}
How would that sound like?
Thank you for the description of your approach.
Predefined DT color definitions make an interesting option. Nonetheless,
your design assumes that for RGB LEDs max_brightness would have to be
always 1.
While it would solve the issue, it wouldn't allow to benefit from
the whole potential of RGB LEDs - think of having adjustable "color
brightness" (like in HSV color model).
What I tried to describe above was that these could also work with HSV
model also with larger brigtness values too.
Let's say we do following sequence to change from off state to user
configured intensity value:
# Turn off leds
echo 0 > brightness
# Select requested color
echo "orange" > color
# Use configured LED intensity from user configuration
echo 84 > brightness
Driver would now use rgb value <249 197 9> and brightness <84> to
calculate (with HSV solution) real PWM values for the led component
colors. With led controller this is probably easier to get linear
feedback but for generic PWM controller you may want to utilize PWM
curve feature like defined for backlight driver.
When thinking this I instantly see my self with thinking PS4's
sliding/pulsing color animation for orange/blue/white. And controlling
this animation steps manually from user space probably is not the best
idea so like with blinking you would need more accurately timed action
within kernel I suppose (or hardware with the support).
With that idea forward:
# Turning animation sequencer off causes instant changes for values
echo "off" > animation-sequencer
# User 1 second for animation (no effect yet as sequencer is off)
echo 1000 > animation-time-ms (or so)
# Turn off leds (instance change)
echo 0 > brightness
# Select requested color (instant change)
echo "orange" > color
# Change to linear animation sequencer
echo "linear" > animation-sequencer
# Now everything from this point is subject to animation sequencer
# Sequencer remember active state and next state (as seen in sysfs)
# Use configured LED intensity from user configuration (no effect yet)
echo 84 > brightness
# Trigger transition sequence
echo load > animation-sequencer
# This would cause 1 second animation from black to orange with user
intensivity of 84
# Wait for transition to complete and some extra
sleep 4
# Change color to blue with animation
echo "blue" > color
echo load > animation-sequencer
# This would cause driver to change from orange to blue in current
intensivity level during 1 second period
# -- end --
Now that went a bit ahead of time but I believe it demonstrates the
potential for this approach with combined with HSL functionality for future.
How abut allowing for providing an array of color intensity/brightness
levels per each color? In the simplest case there could be a single
level per color, but it should be possible to provide up to 255 levels.
I believe that brightness and color should be separate topics.
We have in our devices option in user interface to
RE: [PATCH RESEND v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
Hi Frieder, Thanks for review. > -Original Message- > From: Schrempf Frieder [mailto:frieder.schre...@kontron.de] > Sent: Wednesday, November 7, 2018 9:52 PM > To: Yogesh Narayan Gaur ; linux- > m...@lists.infradead.org; boris.brezil...@bootlin.com; marek.va...@gmail.com; > broo...@kernel.org; linux-...@vger.kernel.org; devicet...@vger.kernel.org > Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- > arm-ker...@lists.infradead.org; computersforpe...@gmail.com; > frieder.schre...@exceet.de; linux-kernel@vger.kernel.org > Subject: Re: [PATCH RESEND v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI > controller > > Hi Yogesh, > > I didn't have time to look at all of the code, but nevertheless here are some > comments. > > On 23.10.18 10:56, Yogesh Narayan Gaur wrote: > > - Add driver for NXP FlexSPI host controller > > > > (0) What is the FlexSPI controller? > > FlexSPI is a flexsible SPI host controller which supports two SPI > > channels and up to 4 external devices. Each channel supports > > Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional > > data lines) i.e. FlexSPI acts as an interface to external devices, > > maximum 4, each with up to 8 bidirectional data lines. > > > > It uses new SPI memory interface of the SPI framework to issue > > flash memory operations to up to four connected flash > > devices (2 buses with 2 CS each). > > > > (1) Tested this driver with the mtd_debug and JFFS2 filesystem utility > > on NXP LX2160ARDB and LX2160AQDS targets. > > LX2160ARDB is having two NOR slave device connected on single bus A > > i.e. A0 and A1 (CS0 and CS1). > > LX2160AQDS is having two NOR slave device connected on separate buses > > one flash on A0 and second on B1 i.e. (CS0 and CS3). > > Verified this driver on following SPI NOR flashes: > > Micron, mt35xu512ab, [Read - 1 bit mode] > > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > > > Signed-off-by: Yogesh Gaur > > --- > > Changes for v4: > > - Incorporate Boris review comments > >* Use readl_poll_timeout() instead of busy looping. > >* Re-define register masking as per comment. > >* Drop fspi_devtype enum. > > Changes for v3: > > - Added endianness flag in platform specific structure instead of DTS. > > - Modified nxp_fspi_read_ahb(), removed remapping code. > > - Added Boris and Frieder as Author and provided reference of > > spi-fsl-qspi.c Changes for v2: > > - Incorporated Boris review comments. > > - Remove dependency of driver over connected flash device size. > > - Modified the logic to select requested CS. > > - Remove SPI-Octal Macros. > > > > drivers/spi/Kconfig| 10 + > > drivers/spi/Makefile |1 + > > drivers/spi/spi-nxp-fspi.c | 1158 > > > 3 files changed, 1169 insertions(+) > > create mode 100644 drivers/spi/spi-nxp-fspi.c > > > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index > > ad5d68e..68da874 100644 > > --- a/drivers/spi/Kconfig > > +++ b/drivers/spi/Kconfig > > @@ -251,6 +251,16 @@ config SPI_FSL_LPSPI > > help > > This enables Freescale i.MX LPSPI controllers in master mode. > > > > +config SPI_NXP_FLEXSPI > > + tristate "NXP Flex SPI controller" > > + depends on ARCH_LAYERSCAPE || HAS_IOMEM > > + help > > + This enables support for the Flex SPI controller in master mode. > > + Up to four slave devices can be connected on two buses with two > > + chipselects each. > > + This controller does not support generic SPI messages and only > > + supports the high-level SPI memory interface. > > + > > config SPI_GPIO > > tristate "GPIO-based bitbanging SPI Master" > > depends on GPIOLIB || COMPILE_TEST > > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index > > cb1f437..52c9f18 100644 > > --- a/drivers/spi/Makefile > > +++ b/drivers/spi/Makefile > > @@ -59,6 +59,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi- > mpc52xx.o > > obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o > > obj-$(CONFIG_SPI_MXS) += spi-mxs.o > > obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o > > +obj-$(CONFIG_SPI_NXP_FLEXSPI) += spi-nxp-fspi.o > > obj-$(CONFIG_SPI_OC_TINY) += spi-oc-tiny.o > > spi-octeon-objs := spi-cavium.o spi-cavium- > octeon.o > > obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o > > diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c > > new file mode 100644 index 000..e5188b2 > > --- /dev/null > > +++ b/drivers/spi/spi-nxp-fspi.c > > @@ -0,0 +1,1158 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > + > > +/* > > + * NXP FlexSPI(FSPI) controller driver. > > + * > > + * Copyright 2018 NXP. > > + * > > + * FlexSPI is a flexsible SPI host controller which supports two SPI > > + * channels and up to 4 external devices. Each channel supports > > + * Single/Dual/Quad/Octal mode data transfer (1/2/4/8
RE: [PATCH RESEND v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
Hi Frieder, Thanks for review. > -Original Message- > From: Schrempf Frieder [mailto:frieder.schre...@kontron.de] > Sent: Wednesday, November 7, 2018 9:52 PM > To: Yogesh Narayan Gaur ; linux- > m...@lists.infradead.org; boris.brezil...@bootlin.com; marek.va...@gmail.com; > broo...@kernel.org; linux-...@vger.kernel.org; devicet...@vger.kernel.org > Cc: r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; linux- > arm-ker...@lists.infradead.org; computersforpe...@gmail.com; > frieder.schre...@exceet.de; linux-kernel@vger.kernel.org > Subject: Re: [PATCH RESEND v4 1/5] spi: spi-mem: Add driver for NXP FlexSPI > controller > > Hi Yogesh, > > I didn't have time to look at all of the code, but nevertheless here are some > comments. > > On 23.10.18 10:56, Yogesh Narayan Gaur wrote: > > - Add driver for NXP FlexSPI host controller > > > > (0) What is the FlexSPI controller? > > FlexSPI is a flexsible SPI host controller which supports two SPI > > channels and up to 4 external devices. Each channel supports > > Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional > > data lines) i.e. FlexSPI acts as an interface to external devices, > > maximum 4, each with up to 8 bidirectional data lines. > > > > It uses new SPI memory interface of the SPI framework to issue > > flash memory operations to up to four connected flash > > devices (2 buses with 2 CS each). > > > > (1) Tested this driver with the mtd_debug and JFFS2 filesystem utility > > on NXP LX2160ARDB and LX2160AQDS targets. > > LX2160ARDB is having two NOR slave device connected on single bus A > > i.e. A0 and A1 (CS0 and CS1). > > LX2160AQDS is having two NOR slave device connected on separate buses > > one flash on A0 and second on B1 i.e. (CS0 and CS3). > > Verified this driver on following SPI NOR flashes: > > Micron, mt35xu512ab, [Read - 1 bit mode] > > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > > > Signed-off-by: Yogesh Gaur > > --- > > Changes for v4: > > - Incorporate Boris review comments > >* Use readl_poll_timeout() instead of busy looping. > >* Re-define register masking as per comment. > >* Drop fspi_devtype enum. > > Changes for v3: > > - Added endianness flag in platform specific structure instead of DTS. > > - Modified nxp_fspi_read_ahb(), removed remapping code. > > - Added Boris and Frieder as Author and provided reference of > > spi-fsl-qspi.c Changes for v2: > > - Incorporated Boris review comments. > > - Remove dependency of driver over connected flash device size. > > - Modified the logic to select requested CS. > > - Remove SPI-Octal Macros. > > > > drivers/spi/Kconfig| 10 + > > drivers/spi/Makefile |1 + > > drivers/spi/spi-nxp-fspi.c | 1158 > > > 3 files changed, 1169 insertions(+) > > create mode 100644 drivers/spi/spi-nxp-fspi.c > > > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index > > ad5d68e..68da874 100644 > > --- a/drivers/spi/Kconfig > > +++ b/drivers/spi/Kconfig > > @@ -251,6 +251,16 @@ config SPI_FSL_LPSPI > > help > > This enables Freescale i.MX LPSPI controllers in master mode. > > > > +config SPI_NXP_FLEXSPI > > + tristate "NXP Flex SPI controller" > > + depends on ARCH_LAYERSCAPE || HAS_IOMEM > > + help > > + This enables support for the Flex SPI controller in master mode. > > + Up to four slave devices can be connected on two buses with two > > + chipselects each. > > + This controller does not support generic SPI messages and only > > + supports the high-level SPI memory interface. > > + > > config SPI_GPIO > > tristate "GPIO-based bitbanging SPI Master" > > depends on GPIOLIB || COMPILE_TEST > > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index > > cb1f437..52c9f18 100644 > > --- a/drivers/spi/Makefile > > +++ b/drivers/spi/Makefile > > @@ -59,6 +59,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi- > mpc52xx.o > > obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o > > obj-$(CONFIG_SPI_MXS) += spi-mxs.o > > obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o > > +obj-$(CONFIG_SPI_NXP_FLEXSPI) += spi-nxp-fspi.o > > obj-$(CONFIG_SPI_OC_TINY) += spi-oc-tiny.o > > spi-octeon-objs := spi-cavium.o spi-cavium- > octeon.o > > obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o > > diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c > > new file mode 100644 index 000..e5188b2 > > --- /dev/null > > +++ b/drivers/spi/spi-nxp-fspi.c > > @@ -0,0 +1,1158 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > + > > +/* > > + * NXP FlexSPI(FSPI) controller driver. > > + * > > + * Copyright 2018 NXP. > > + * > > + * FlexSPI is a flexsible SPI host controller which supports two SPI > > + * channels and up to 4 external devices. Each channel supports > > + * Single/Dual/Quad/Octal mode data transfer (1/2/4/8
Re: [PATCH 1/3] gpio: mockup: fix indicated direction
Hello Bartosz, On Mon, Nov 12, 2018 at 03:14:31PM +0100, Bartosz Golaszewski wrote: > > > As I said before: it is and should be fixed in this specific case. > > > This isn't real hardware. Not being "real hardware" is hardly an argument that matters here. > > Not sure if we agree here yet. What do you want to fix? The driver or > > the test? > > > > In my eyes test driven development is great. But if something breaks > > because the test is wrong, please don't "fix" the system to repair the > > test, but modify the test to be able to handle reality. > > > > No, we don't have an agreement. You think I should fix the test, I > think the dummy driver should continue behaving like before. It's arguable if after your patch the driver behaves as before. IMHO the initial direction was output from the start before. This was just shadowed by the an inconsitency that was fixed some time ago. > Given that there's no real hardware behind, the direction of newly > created dummy lines has always been deterministic - input. Certain > tests have been relying on it. I want to keep on doing it. There's no > harm. It's not broken logic as the very purpose of this module is to > allow for easy testing of the UAPI. > > So unless something *else* is wrong with this patch, I intend to push > it upstream. Note I don't oppose to the patch as is. Just the motiviation is wrong and I'd do both: Modify the mockup driver to start with direction=input and modify the tests to not expect this. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH 1/3] gpio: mockup: fix indicated direction
Hello Bartosz, On Mon, Nov 12, 2018 at 03:14:31PM +0100, Bartosz Golaszewski wrote: > > > As I said before: it is and should be fixed in this specific case. > > > This isn't real hardware. Not being "real hardware" is hardly an argument that matters here. > > Not sure if we agree here yet. What do you want to fix? The driver or > > the test? > > > > In my eyes test driven development is great. But if something breaks > > because the test is wrong, please don't "fix" the system to repair the > > test, but modify the test to be able to handle reality. > > > > No, we don't have an agreement. You think I should fix the test, I > think the dummy driver should continue behaving like before. It's arguable if after your patch the driver behaves as before. IMHO the initial direction was output from the start before. This was just shadowed by the an inconsitency that was fixed some time ago. > Given that there's no real hardware behind, the direction of newly > created dummy lines has always been deterministic - input. Certain > tests have been relying on it. I want to keep on doing it. There's no > harm. It's not broken logic as the very purpose of this module is to > allow for easy testing of the UAPI. > > So unless something *else* is wrong with this patch, I intend to push > it upstream. Note I don't oppose to the patch as is. Just the motiviation is wrong and I'd do both: Modify the mockup driver to start with direction=input and modify the tests to not expect this. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [RFC PATCH v2 1/2] x86/fpu: detect AVX task
On 2018/11/12 23:46, Dave Hansen wrote:
> On 11/11/18 9:38 PM, Li, Aubrey wrote:
>
>>> Do we want this, or do we want something more time-based?
>>>
>> This counter is introduced here to solve the race of context switch and
>> VZEROUPPER. 3 context switches mean the same thread is on-off CPU 3 times.
>> Due to scheduling latency, 3 jiffies could only happen AVX task on-off just
>> 1 time. So IMHO the context switches number is better here.
>
> Imagine we have a HZ=1000 system where AVX_STATE_DECAY_COUNT=3. That
> means that a task can be marked as a non-AVX-512-user after not using it
> for ~3 ms. But, with HZ=250, that's ~12ms.
>From the other side, if we set a 4ms decay, when HZ=1000, context switch count
is 4, that means, we have 4 times of chance to maintain the AVX state, that is,
we are able to filter 4 times init state reset out. But if HZ = 250, the context
switch is 1, we only have 1 time of chance to filter init state reset out.
>
> Also, don't forget that we have context switches from the timer
> interrupt, but also from normal old operations that sleep.
>
> Let's say our AVX-512 app was doing:
>
> while (foo) {
> do_avx_512();
> read(pipe, buf, len);
> read(pipe, buf, len);
> read(pipe, buf, len);
> }
>
> And all three pipe reads context-switched the task. That loop could
> finish in way under 3HZ, but still end up in do_avx_512() each time with
> fpu...avx->state=0.
Yeah, we are trying to address a prediction according to the historical pattern,
so you always can make a pattern to beat the prediction pattern. But in
practice,
I measured tensorflow with AVX512 enabled, linpack with AVX512, and a micro
benchmark, the current 3 context switches decay works well enough.
>
> BTW, I don't have a great solution for this. I was just pointing out
> one of the pitfalls from using context switch counts so strictly.
I really don't think time-based is better than the count in this case.
+/*
* Highest level per task FPU state data structure that
* contains the FPU register state plus various FPU
* state fields:
@@ -303,6 +312,14 @@ struct fpu {
unsigned char initialized;
/*
+ * @avx_state:
+ *
+ * This data structure indicates whether this context
+ * contains AVX states
+ */
>>>
>>> Yeah, that's precisely what fpu->state.xsave.xfeatures does. :)
>>> I see, will refine in the next version
>
> One other thought about the new 'avx_state':
>
> fxregs_state (which is a part of the XSAVE state) has some padding and
> 'sw_reserved' areas. You *might* be able to steal some space there.
> Not that this is a huge space eater, but why waste the space if we don't
> have to?
>
IMHO, I prefer not adding any extra thing into a data structure associated
with a hardware table. Let me try to work out a new version to see if it can
satisfy you.
Thanks,
-Aubrey
Re: [RFC PATCH v2 1/2] x86/fpu: detect AVX task
On 2018/11/12 23:46, Dave Hansen wrote:
> On 11/11/18 9:38 PM, Li, Aubrey wrote:
>
>>> Do we want this, or do we want something more time-based?
>>>
>> This counter is introduced here to solve the race of context switch and
>> VZEROUPPER. 3 context switches mean the same thread is on-off CPU 3 times.
>> Due to scheduling latency, 3 jiffies could only happen AVX task on-off just
>> 1 time. So IMHO the context switches number is better here.
>
> Imagine we have a HZ=1000 system where AVX_STATE_DECAY_COUNT=3. That
> means that a task can be marked as a non-AVX-512-user after not using it
> for ~3 ms. But, with HZ=250, that's ~12ms.
>From the other side, if we set a 4ms decay, when HZ=1000, context switch count
is 4, that means, we have 4 times of chance to maintain the AVX state, that is,
we are able to filter 4 times init state reset out. But if HZ = 250, the context
switch is 1, we only have 1 time of chance to filter init state reset out.
>
> Also, don't forget that we have context switches from the timer
> interrupt, but also from normal old operations that sleep.
>
> Let's say our AVX-512 app was doing:
>
> while (foo) {
> do_avx_512();
> read(pipe, buf, len);
> read(pipe, buf, len);
> read(pipe, buf, len);
> }
>
> And all three pipe reads context-switched the task. That loop could
> finish in way under 3HZ, but still end up in do_avx_512() each time with
> fpu...avx->state=0.
Yeah, we are trying to address a prediction according to the historical pattern,
so you always can make a pattern to beat the prediction pattern. But in
practice,
I measured tensorflow with AVX512 enabled, linpack with AVX512, and a micro
benchmark, the current 3 context switches decay works well enough.
>
> BTW, I don't have a great solution for this. I was just pointing out
> one of the pitfalls from using context switch counts so strictly.
I really don't think time-based is better than the count in this case.
+/*
* Highest level per task FPU state data structure that
* contains the FPU register state plus various FPU
* state fields:
@@ -303,6 +312,14 @@ struct fpu {
unsigned char initialized;
/*
+ * @avx_state:
+ *
+ * This data structure indicates whether this context
+ * contains AVX states
+ */
>>>
>>> Yeah, that's precisely what fpu->state.xsave.xfeatures does. :)
>>> I see, will refine in the next version
>
> One other thought about the new 'avx_state':
>
> fxregs_state (which is a part of the XSAVE state) has some padding and
> 'sw_reserved' areas. You *might* be able to steal some space there.
> Not that this is a huge space eater, but why waste the space if we don't
> have to?
>
IMHO, I prefer not adding any extra thing into a data structure associated
with a hardware table. Let me try to work out a new version to see if it can
satisfy you.
Thanks,
-Aubrey
RE: [PATCH] mtd: spi-nor: cast to u64 to avoid uint overflows
Hi Huijin, I guess this is the v2 of previously send patch [1], please follow version information in patch submission. -- Regards Yogesh Gaur [1] https://patchwork.ozlabs.org/patch/961197/ > -Original Message- > From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of > Huijin Park > Sent: Tuesday, November 13, 2018 10:49 AM > To: Boris Brezillon > Cc: Marek Vasut ; linux-...@lists.infradead.org; > linux-kernel@vger.kernel.org; bbanghj.p...@gmail.com; Huijin Park > > Subject: [PATCH] mtd: spi-nor: cast to u64 to avoid uint overflows > > From: "huijin.park" > > The "params->size" is defined as "u64". > And "info->sector_size" and "info->n_sectors" are defined as unsigned int and > u16. > Thus, u64 data might have strange data(loss data) if the result overflows an > unsigned int. > This patch casts "info->sector_size" and "info->n_sectors" to an u64. > > Signed-off-by: huijin.park > --- > drivers/mtd/spi-nor/spi-nor.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index > d9c368c..527f281 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -2459,7 +2459,7 @@ static int spi_nor_init_params(struct spi_nor *nor, > memset(params, 0, sizeof(*params)); > > /* Set SPI NOR sizes. */ > - params->size = info->sector_size * info->n_sectors; > + params->size = (u64)info->sector_size * (u64)info->n_sectors; > params->page_size = info->page_size; > > /* (Fast) Read settings. */ > -- > 1.7.9.5 > > > __ > Linux MTD discussion mailing list > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fmailman%2Flistinfo%2Flinux- > mtd%2Fdata=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7C5efd964 > 86c7244f430b408d649278b65%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > 7C1%7C636776831529836639sdata=A7hiJMpfxXKTyT6yacIougPRGdHg2o > pL492y3sVtQek%3Dreserved=0
RE: [PATCH] mtd: spi-nor: cast to u64 to avoid uint overflows
Hi Huijin, I guess this is the v2 of previously send patch [1], please follow version information in patch submission. -- Regards Yogesh Gaur [1] https://patchwork.ozlabs.org/patch/961197/ > -Original Message- > From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of > Huijin Park > Sent: Tuesday, November 13, 2018 10:49 AM > To: Boris Brezillon > Cc: Marek Vasut ; linux-...@lists.infradead.org; > linux-kernel@vger.kernel.org; bbanghj.p...@gmail.com; Huijin Park > > Subject: [PATCH] mtd: spi-nor: cast to u64 to avoid uint overflows > > From: "huijin.park" > > The "params->size" is defined as "u64". > And "info->sector_size" and "info->n_sectors" are defined as unsigned int and > u16. > Thus, u64 data might have strange data(loss data) if the result overflows an > unsigned int. > This patch casts "info->sector_size" and "info->n_sectors" to an u64. > > Signed-off-by: huijin.park > --- > drivers/mtd/spi-nor/spi-nor.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index > d9c368c..527f281 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -2459,7 +2459,7 @@ static int spi_nor_init_params(struct spi_nor *nor, > memset(params, 0, sizeof(*params)); > > /* Set SPI NOR sizes. */ > - params->size = info->sector_size * info->n_sectors; > + params->size = (u64)info->sector_size * (u64)info->n_sectors; > params->page_size = info->page_size; > > /* (Fast) Read settings. */ > -- > 1.7.9.5 > > > __ > Linux MTD discussion mailing list > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fmailman%2Flistinfo%2Flinux- > mtd%2Fdata=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7C5efd964 > 86c7244f430b408d649278b65%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > 7C1%7C636776831529836639sdata=A7hiJMpfxXKTyT6yacIougPRGdHg2o > pL492y3sVtQek%3Dreserved=0
[PATCH] net/9p: include trans_common.h to fix missing prototype warning.
This silences -Wmissing-prototypes when defining p9_release_pages. Signed-off-by: Adeodato Simó --- net/9p/trans_common.c | 1 + 1 file changed, 1 insertion(+) It was suggested in the kernel-janitors mailing list that silencing -Wmissing-prototypes would make for a worthy cause. https://www.spinics.net/lists/linux-kernel-janitors/msg43981.html Resending w/ Cc: linux-kernel as requested by Dominique. diff --git a/net/9p/trans_common.c b/net/9p/trans_common.c index b718db2085b2..3dff68f05fb9 100644 --- a/net/9p/trans_common.c +++ b/net/9p/trans_common.c @@ -14,6 +14,7 @@ #include #include +#include "trans_common.h" /** * p9_release_pages - Release pages after the transaction. -- 2.19.1
[PATCH] net/9p: include trans_common.h to fix missing prototype warning.
This silences -Wmissing-prototypes when defining p9_release_pages. Signed-off-by: Adeodato Simó --- net/9p/trans_common.c | 1 + 1 file changed, 1 insertion(+) It was suggested in the kernel-janitors mailing list that silencing -Wmissing-prototypes would make for a worthy cause. https://www.spinics.net/lists/linux-kernel-janitors/msg43981.html Resending w/ Cc: linux-kernel as requested by Dominique. diff --git a/net/9p/trans_common.c b/net/9p/trans_common.c index b718db2085b2..3dff68f05fb9 100644 --- a/net/9p/trans_common.c +++ b/net/9p/trans_common.c @@ -14,6 +14,7 @@ #include #include +#include "trans_common.h" /** * p9_release_pages - Release pages after the transaction. -- 2.19.1
[PATCH v5 3/4] mm: convert totalram_pages and totalhigh_pages variables to atomic
totalram_pages and totalhigh_pages are made static inline function. Main motivation was that managed_page_count_lock handling was complicating things. It was discussed in lenght here, https://lore.kernel.org/patchwork/patch/995739/#1181785 So it seemes better to remove the lock and convert variables to atomic, with preventing poteintial store-to-read tearing as a bonus. Suggested-by: Michal Hocko Suggested-by: Vlastimil Babka Signed-off-by: Arun KS Reviewed-by: Konstantin Khlebnikov Acked-by: Michal Hocko Acked-by: Vlastimil Babka --- coccinelle script to make most of the changes, @@ declarer name EXPORT_SYMBOL; symbol totalram_pages; expression e; @@ ( EXPORT_SYMBOL(totalram_pages); | - totalram_pages = e + totalram_pages_set(e) | - totalram_pages += e + totalram_pages_add(e) | - totalram_pages++ + totalram_pages_inc() | - totalram_pages-- + totalram_pages_dec() | - totalram_pages + totalram_pages() ) @@ symbol totalhigh_pages; expression e; @@ ( EXPORT_SYMBOL(totalhigh_pages); | - totalhigh_pages = e + totalhigh_pages_set(e) | - totalhigh_pages += e + totalhigh_pages_add(e) | - totalhigh_pages++ + totalhigh_pages_inc() | - totalhigh_pages-- + totalhigh_pages_dec() | - totalhigh_pages + totalhigh_pages() ) Manaually apply all changes of following files, include/linux/highmem.h include/linux/mm.h include/linux/swap.h mm/highmem.c and for mm/page_alloc.c mannualy apply only below changes, #include #include +#include #include #include #include /* Protect totalram_pages and zone->managed_pages */ static DEFINE_SPINLOCK(managed_page_count_lock); -unsigned long totalram_pages __read_mostly; +atomic_long_t _totalram_pages __read_mostly; unsigned long totalreserve_pages __read_mostly; unsigned long totalcma_pages __read_mostly; --- arch/csky/mm/init.c | 4 ++-- arch/powerpc/platforms/pseries/cmm.c | 10 +- arch/s390/mm/init.c | 2 +- arch/um/kernel/mem.c | 2 +- arch/x86/kernel/cpu/microcode/core.c | 2 +- drivers/char/agp/backend.c| 4 ++-- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 ++-- drivers/hv/hv_balloon.c | 2 +- drivers/md/dm-bufio.c | 2 +- drivers/md/dm-crypt.c | 2 +- drivers/md/dm-integrity.c | 2 +- drivers/md/dm-stats.c | 2 +- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- drivers/misc/vmw_balloon.c| 2 +- drivers/parisc/ccio-dma.c | 4 ++-- drivers/parisc/sba_iommu.c| 4 ++-- drivers/staging/android/ion/ion_system_heap.c | 2 +- drivers/xen/xen-selfballoon.c | 6 +++--- fs/ceph/super.h | 2 +- fs/file_table.c | 2 +- fs/fuse/inode.c | 2 +- fs/nfs/write.c| 2 +- fs/nfsd/nfscache.c| 2 +- fs/ntfs/malloc.h | 2 +- fs/proc/base.c| 2 +- include/linux/highmem.h | 28 +-- include/linux/mm.h| 27 +- include/linux/swap.h | 1 - kernel/fork.c | 2 +- kernel/kexec_core.c | 2 +- kernel/power/snapshot.c | 2 +- mm/highmem.c | 5 ++--- mm/huge_memory.c | 2 +- mm/kasan/quarantine.c | 2 +- mm/memblock.c | 4 ++-- mm/mm_init.c | 2 +- mm/oom_kill.c | 2 +- mm/page_alloc.c | 20 ++- mm/shmem.c| 8 mm/slab.c | 2 +- mm/swap.c | 2 +- mm/util.c | 2 +- mm/vmalloc.c | 4 ++-- mm/workingset.c | 2 +- mm/zswap.c| 4 ++-- net/dccp/proto.c | 2 +- net/decnet/dn_route.c | 2 +- net/ipv4/tcp_metrics.c| 2 +- net/netfilter/nf_conntrack_core.c | 2 +- net/netfilter/xt_hashlimit.c | 2 +- net/sctp/protocol.c | 2 +- security/integrity/ima/ima_kexec.c| 2 +- 53 files changed, 130 insertions(+), 81 deletions(-) diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c index dc07c07..66e5970 100644 --- a/arch/csky/mm/init.c +++ b/arch/csky/mm/init.c @@
[PATCH v5 2/4] mm: convert zone->managed_pages to atomic variable
totalram_pages, zone->managed_pages and totalhigh_pages updates
are protected by managed_page_count_lock, but readers never care
about it. Convert these variables to atomic to avoid readers
potentially seeing a store tear.
This patch converts zone->managed_pages. Subsequent patches will
convert totalram_panges, totalhigh_pages and eventually
managed_page_count_lock will be removed.
Main motivation was that managed_page_count_lock handling was
complicating things. It was discussed in length here,
https://lore.kernel.org/patchwork/patch/995739/#1181785
So it seemes better to remove the lock and convert variables
to atomic, with preventing poteintial store-to-read tearing as
a bonus.
Suggested-by: Michal Hocko
Suggested-by: Vlastimil Babka
Signed-off-by: Arun KS
Reviewed-by: Konstantin Khlebnikov
Acked-by: Michal Hocko
Acked-by: Vlastimil Babka
---
Most of the changes are done by below coccinelle script,
@@
struct zone *z;
expression e1;
@@
(
- z->managed_pages = e1
+ atomic_long_set(>managed_pages, e1)
|
- e1->managed_pages++
+ atomic_long_inc(>managed_pages)
|
- z->managed_pages
+ zone_managed_pages(z)
)
@@
expression e,e1;
@@
- e->managed_pages += e1
+ atomic_long_add(e1, >managed_pages)
@@
expression z;
@@
- z.managed_pages
+ zone_managed_pages()
Then, manually apply following change,
include/linux/mmzone.h
- unsigned long managed_pages;
+ atomic_long_t managed_pages;
+static inline unsigned long zone_managed_pages(struct zone *zone)
+{
+ return (unsigned long)atomic_long_read(>managed_pages);
+}
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
include/linux/mmzone.h| 9 +--
lib/show_mem.c| 2 +-
mm/memblock.c | 2 +-
mm/page_alloc.c | 44 +--
mm/vmstat.c | 4 ++--
6 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 56412b0..c0e55bb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -848,7 +848,7 @@ static int kfd_fill_mem_info_for_cpu(int numa_node_id, int
*avail_size,
*/
pgdat = NODE_DATA(numa_node_id);
for (zone_type = 0; zone_type < MAX_NR_ZONES; zone_type++)
- mem_in_bytes += pgdat->node_zones[zone_type].managed_pages;
+ mem_in_bytes +=
zone_managed_pages(>node_zones[zone_type]);
mem_in_bytes <<= PAGE_SHIFT;
sub_type_hdr->length_low = lower_32_bits(mem_in_bytes);
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 847705a..e73dc31 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -435,7 +435,7 @@ struct zone {
* adjust_managed_page_count() should be used instead of directly
* touching zone->managed_pages and totalram_pages.
*/
- unsigned long managed_pages;
+ atomic_long_t managed_pages;
unsigned long spanned_pages;
unsigned long present_pages;
@@ -524,6 +524,11 @@ enum pgdat_flags {
PGDAT_RECLAIM_LOCKED, /* prevents concurrent reclaim */
};
+static inline unsigned long zone_managed_pages(struct zone *zone)
+{
+ return (unsigned long)atomic_long_read(>managed_pages);
+}
+
static inline unsigned long zone_end_pfn(const struct zone *zone)
{
return zone->zone_start_pfn + zone->spanned_pages;
@@ -814,7 +819,7 @@ static inline bool is_dev_zone(const struct zone *zone)
*/
static inline bool managed_zone(struct zone *zone)
{
- return zone->managed_pages;
+ return zone_managed_pages(zone);
}
/* Returns true if a zone has memory */
diff --git a/lib/show_mem.c b/lib/show_mem.c
index 0beaa1d..eefe67d 100644
--- a/lib/show_mem.c
+++ b/lib/show_mem.c
@@ -28,7 +28,7 @@ void show_mem(unsigned int filter, nodemask_t *nodemask)
continue;
total += zone->present_pages;
- reserved += zone->present_pages - zone->managed_pages;
+ reserved += zone->present_pages -
zone_managed_pages(zone);
if (is_highmem_idx(zoneid))
highmem += zone->present_pages;
diff --git a/mm/memblock.c b/mm/memblock.c
index 7df468c..bbd82ab 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1950,7 +1950,7 @@ void reset_node_managed_pages(pg_data_t *pgdat)
struct zone *z;
for (z = pgdat->node_zones; z < pgdat->node_zones + MAX_NR_ZONES; z++)
- z->managed_pages = 0;
+ atomic_long_set(>managed_pages, 0);
}
void __init reset_all_zones_managed_pages(void)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 173312b..22e6645 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1279,7 +1279,7 @@ static void __init __free_pages_boot_core(struct page
*page, unsigned int order)
[PATCH v5 4/4] mm: Remove managed_page_count spinlock
Now that totalram_pages and managed_pages are atomic varibles, no need
of managed_page_count spinlock. The lock had really a weak consistency
guarantee. It hasn't been used for anything but the update but no reader
actually cares about all the values being updated to be in sync.
Signed-off-by: Arun KS
Reviewed-by: Konstantin Khlebnikov
Acked-by: Michal Hocko
Acked-by: Vlastimil Babka
---
include/linux/mmzone.h | 6 --
mm/page_alloc.c| 5 -
2 files changed, 11 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e73dc31..c71b4d9 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -428,12 +428,6 @@ struct zone {
* Write access to present_pages at runtime should be protected by
* mem_hotplug_begin/end(). Any reader who can't tolerant drift of
* present_pages should get_online_mems() to get a stable value.
-*
-* Read access to managed_pages should be safe because it's unsigned
-* long. Write access to zone->managed_pages and totalram_pages are
-* protected by managed_page_count_lock at runtime. Idealy only
-* adjust_managed_page_count() should be used instead of directly
-* touching zone->managed_pages and totalram_pages.
*/
atomic_long_t managed_pages;
unsigned long spanned_pages;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f8b64cc..26c5e14 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -122,9 +122,6 @@
};
EXPORT_SYMBOL(node_states);
-/* Protect totalram_pages and zone->managed_pages */
-static DEFINE_SPINLOCK(managed_page_count_lock);
-
atomic_long_t _totalram_pages __read_mostly;
EXPORT_SYMBOL(_totalram_pages);
unsigned long totalreserve_pages __read_mostly;
@@ -7065,14 +7062,12 @@ static int __init cmdline_parse_movablecore(char *p)
void adjust_managed_page_count(struct page *page, long count)
{
- spin_lock(_page_count_lock);
atomic_long_add(count, _zone(page)->managed_pages);
totalram_pages_add(count);
#ifdef CONFIG_HIGHMEM
if (PageHighMem(page))
totalhigh_pages_add(count);
#endif
- spin_unlock(_page_count_lock);
}
EXPORT_SYMBOL(adjust_managed_page_count);
--
1.9.1
[PATCH v5 1/4] mm: reference totalram_pages and managed_pages once per function
This patch is in preparation to a later patch which converts totalram_pages
and zone->managed_pages to atomic variables. Please note that re-reading
the value might lead to a different value and as such it could lead to
unexpected behavior. There are no known bugs as a result of the current code
but it is better to prevent from them in principle.
Signed-off-by: Arun KS
Reviewed-by: Konstantin Khlebnikov
Acked-by: Michal Hocko
Acked-by: Vlastimil Babka
---
arch/um/kernel/mem.c | 2 +-
arch/x86/kernel/cpu/microcode/core.c | 5 +++--
drivers/hv/hv_balloon.c | 19 ++-
fs/file_table.c | 7 ---
kernel/fork.c| 5 +++--
kernel/kexec_core.c | 5 +++--
mm/page_alloc.c | 5 +++--
mm/shmem.c | 3 ++-
net/dccp/proto.c | 7 ---
net/netfilter/nf_conntrack_core.c| 7 ---
net/netfilter/xt_hashlimit.c | 5 +++--
net/sctp/protocol.c | 7 ---
12 files changed, 44 insertions(+), 33 deletions(-)
diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
index 1067469..2da2096 100644
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -52,7 +52,7 @@ void __init mem_init(void)
/* this will put all low memory onto the freelists */
memblock_free_all();
max_low_pfn = totalram_pages;
- max_pfn = totalram_pages;
+ max_pfn = max_low_pfn;
mem_init_print_info(NULL);
kmalloc_ok = 1;
}
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index 2637ff0..168fa27 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -434,9 +434,10 @@ static ssize_t microcode_write(struct file *file, const
char __user *buf,
size_t len, loff_t *ppos)
{
ssize_t ret = -EINVAL;
+ unsigned long nr_pages = totalram_pages;
- if ((len >> PAGE_SHIFT) > totalram_pages) {
- pr_err("too much data (max %ld pages)\n", totalram_pages);
+ if ((len >> PAGE_SHIFT) > nr_pages) {
+ pr_err("too much data (max %ld pages)\n", nr_pages);
return ret;
}
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 4163151..f3e7da9 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1090,6 +1090,7 @@ static void process_info(struct hv_dynmem_device *dm,
struct dm_info_msg *msg)
static unsigned long compute_balloon_floor(void)
{
unsigned long min_pages;
+ unsigned long nr_pages = totalram_pages;
#define MB2PAGES(mb) ((mb) << (20 - PAGE_SHIFT))
/* Simple continuous piecewiese linear function:
* max MiB -> min MiB gradient
@@ -1102,16 +1103,16 @@ static unsigned long compute_balloon_floor(void)
*8192 744(1/16)
* 32768 1512(1/32)
*/
- if (totalram_pages < MB2PAGES(128))
- min_pages = MB2PAGES(8) + (totalram_pages >> 1);
- else if (totalram_pages < MB2PAGES(512))
- min_pages = MB2PAGES(40) + (totalram_pages >> 2);
- else if (totalram_pages < MB2PAGES(2048))
- min_pages = MB2PAGES(104) + (totalram_pages >> 3);
- else if (totalram_pages < MB2PAGES(8192))
- min_pages = MB2PAGES(232) + (totalram_pages >> 4);
+ if (nr_pages < MB2PAGES(128))
+ min_pages = MB2PAGES(8) + (nr_pages >> 1);
+ else if (nr_pages < MB2PAGES(512))
+ min_pages = MB2PAGES(40) + (nr_pages >> 2);
+ else if (nr_pages < MB2PAGES(2048))
+ min_pages = MB2PAGES(104) + (nr_pages >> 3);
+ else if (nr_pages < MB2PAGES(8192))
+ min_pages = MB2PAGES(232) + (nr_pages >> 4);
else
- min_pages = MB2PAGES(488) + (totalram_pages >> 5);
+ min_pages = MB2PAGES(488) + (nr_pages >> 5);
#undef MB2PAGES
return min_pages;
}
diff --git a/fs/file_table.c b/fs/file_table.c
index e49af4c..b6e9587 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -380,10 +380,11 @@ void __init files_init(void)
void __init files_maxfiles_init(void)
{
unsigned long n;
- unsigned long memreserve = (totalram_pages - nr_free_pages()) * 3/2;
+ unsigned long nr_pages = totalram_pages;
+ unsigned long memreserve = (nr_pages - nr_free_pages()) * 3/2;
- memreserve = min(memreserve, totalram_pages - 1);
- n = ((totalram_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
+ memreserve = min(memreserve, nr_pages - 1);
+ n = ((nr_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
}
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff..58422c5 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -739,15 +739,16 @@ void __init __weak arch_task_cache_init(void) { }
static
[PATCH v5 0/4] mm: convert totalram_pages, totalhigh_pages and managed pages to atomic
This series convert totalram_pages, totalhigh_pages and zone->managed_pages to atomic variables. The patch was comiple tested on x86(x86_64_defconfig & i386_defconfig) on 4.20-rc2. And memory hotplug tested on arm64, but on an older version of kernel. totalram_pages, zone->managed_pages and totalhigh_pages updates are protected by managed_page_count_lock, but readers never care about it. Convert these variables to atomic to avoid readers potentially seeing a store tear. Main motivation was that managed_page_count_lock handling was complicating things. It was discussed in length here, https://lore.kernel.org/patchwork/patch/995739/#1181785 It seemes better to remove the lock and convert variables to atomic. With the change, preventing poteintial store-to-read tearing comes as a bonus. Changes in v5: - totalram_pgs renamed to nr_pages. https://lore.kernel.org/patchwork/patch/1011293/#1194248 Changes in v4: - Fixed kbuild test robot error. - Modified changelog. - Rebased to 4.20.-rc2 Changes in v3: - Fixed kbuild test robot errors. - Modified changelogs to be more clear. - EXPORT_SYMBOL for _totalram_pages and _totalhigh_pages. Arun KS (4): mm: reference totalram_pages and managed_pages once per function mm: convert zone->managed_pages to atomic variable mm: convert totalram_pages and totalhigh_pages variables to atomic mm: Remove managed_page_count spinlock arch/csky/mm/init.c | 4 +- arch/powerpc/platforms/pseries/cmm.c | 10 ++-- arch/s390/mm/init.c | 2 +- arch/um/kernel/mem.c | 4 +- arch/x86/kernel/cpu/microcode/core.c | 5 +- drivers/char/agp/backend.c| 4 +- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- drivers/hv/hv_balloon.c | 19 +++ drivers/md/dm-bufio.c | 2 +- drivers/md/dm-crypt.c | 2 +- drivers/md/dm-integrity.c | 2 +- drivers/md/dm-stats.c | 2 +- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- drivers/misc/vmw_balloon.c| 2 +- drivers/parisc/ccio-dma.c | 4 +- drivers/parisc/sba_iommu.c| 4 +- drivers/staging/android/ion/ion_system_heap.c | 2 +- drivers/xen/xen-selfballoon.c | 6 +-- fs/ceph/super.h | 2 +- fs/file_table.c | 7 +-- fs/fuse/inode.c | 2 +- fs/nfs/write.c| 2 +- fs/nfsd/nfscache.c| 2 +- fs/ntfs/malloc.h | 2 +- fs/proc/base.c| 2 +- include/linux/highmem.h | 28 ++- include/linux/mm.h| 27 +- include/linux/mmzone.h| 15 +++--- include/linux/swap.h | 1 - kernel/fork.c | 5 +- kernel/kexec_core.c | 5 +- kernel/power/snapshot.c | 2 +- lib/show_mem.c| 2 +- mm/highmem.c | 5 +- mm/huge_memory.c | 2 +- mm/kasan/quarantine.c | 2 +- mm/memblock.c | 6 +-- mm/mm_init.c | 2 +- mm/oom_kill.c | 2 +- mm/page_alloc.c | 72 +-- mm/shmem.c| 7 +-- mm/slab.c | 2 +- mm/swap.c | 2 +- mm/util.c | 2 +- mm/vmalloc.c | 4 +- mm/vmstat.c | 4 +- mm/workingset.c | 2 +- mm/zswap.c| 4 +- net/dccp/proto.c | 7 +-- net/decnet/dn_route.c | 2 +- net/ipv4/tcp_metrics.c| 2 +- net/netfilter/nf_conntrack_core.c | 7 +-- net/netfilter/xt_hashlimit.c | 5 +- net/sctp/protocol.c | 7 +-- security/integrity/ima/ima_kexec.c| 2 +- 57 files changed, 196 insertions(+), 142 deletions(-) -- 1.9.1
[PATCH v5 3/4] mm: convert totalram_pages and totalhigh_pages variables to atomic
totalram_pages and totalhigh_pages are made static inline function. Main motivation was that managed_page_count_lock handling was complicating things. It was discussed in lenght here, https://lore.kernel.org/patchwork/patch/995739/#1181785 So it seemes better to remove the lock and convert variables to atomic, with preventing poteintial store-to-read tearing as a bonus. Suggested-by: Michal Hocko Suggested-by: Vlastimil Babka Signed-off-by: Arun KS Reviewed-by: Konstantin Khlebnikov Acked-by: Michal Hocko Acked-by: Vlastimil Babka --- coccinelle script to make most of the changes, @@ declarer name EXPORT_SYMBOL; symbol totalram_pages; expression e; @@ ( EXPORT_SYMBOL(totalram_pages); | - totalram_pages = e + totalram_pages_set(e) | - totalram_pages += e + totalram_pages_add(e) | - totalram_pages++ + totalram_pages_inc() | - totalram_pages-- + totalram_pages_dec() | - totalram_pages + totalram_pages() ) @@ symbol totalhigh_pages; expression e; @@ ( EXPORT_SYMBOL(totalhigh_pages); | - totalhigh_pages = e + totalhigh_pages_set(e) | - totalhigh_pages += e + totalhigh_pages_add(e) | - totalhigh_pages++ + totalhigh_pages_inc() | - totalhigh_pages-- + totalhigh_pages_dec() | - totalhigh_pages + totalhigh_pages() ) Manaually apply all changes of following files, include/linux/highmem.h include/linux/mm.h include/linux/swap.h mm/highmem.c and for mm/page_alloc.c mannualy apply only below changes, #include #include +#include #include #include #include /* Protect totalram_pages and zone->managed_pages */ static DEFINE_SPINLOCK(managed_page_count_lock); -unsigned long totalram_pages __read_mostly; +atomic_long_t _totalram_pages __read_mostly; unsigned long totalreserve_pages __read_mostly; unsigned long totalcma_pages __read_mostly; --- arch/csky/mm/init.c | 4 ++-- arch/powerpc/platforms/pseries/cmm.c | 10 +- arch/s390/mm/init.c | 2 +- arch/um/kernel/mem.c | 2 +- arch/x86/kernel/cpu/microcode/core.c | 2 +- drivers/char/agp/backend.c| 4 ++-- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 ++-- drivers/hv/hv_balloon.c | 2 +- drivers/md/dm-bufio.c | 2 +- drivers/md/dm-crypt.c | 2 +- drivers/md/dm-integrity.c | 2 +- drivers/md/dm-stats.c | 2 +- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- drivers/misc/vmw_balloon.c| 2 +- drivers/parisc/ccio-dma.c | 4 ++-- drivers/parisc/sba_iommu.c| 4 ++-- drivers/staging/android/ion/ion_system_heap.c | 2 +- drivers/xen/xen-selfballoon.c | 6 +++--- fs/ceph/super.h | 2 +- fs/file_table.c | 2 +- fs/fuse/inode.c | 2 +- fs/nfs/write.c| 2 +- fs/nfsd/nfscache.c| 2 +- fs/ntfs/malloc.h | 2 +- fs/proc/base.c| 2 +- include/linux/highmem.h | 28 +-- include/linux/mm.h| 27 +- include/linux/swap.h | 1 - kernel/fork.c | 2 +- kernel/kexec_core.c | 2 +- kernel/power/snapshot.c | 2 +- mm/highmem.c | 5 ++--- mm/huge_memory.c | 2 +- mm/kasan/quarantine.c | 2 +- mm/memblock.c | 4 ++-- mm/mm_init.c | 2 +- mm/oom_kill.c | 2 +- mm/page_alloc.c | 20 ++- mm/shmem.c| 8 mm/slab.c | 2 +- mm/swap.c | 2 +- mm/util.c | 2 +- mm/vmalloc.c | 4 ++-- mm/workingset.c | 2 +- mm/zswap.c| 4 ++-- net/dccp/proto.c | 2 +- net/decnet/dn_route.c | 2 +- net/ipv4/tcp_metrics.c| 2 +- net/netfilter/nf_conntrack_core.c | 2 +- net/netfilter/xt_hashlimit.c | 2 +- net/sctp/protocol.c | 2 +- security/integrity/ima/ima_kexec.c| 2 +- 53 files changed, 130 insertions(+), 81 deletions(-) diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c index dc07c07..66e5970 100644 --- a/arch/csky/mm/init.c +++ b/arch/csky/mm/init.c @@
[PATCH v5 2/4] mm: convert zone->managed_pages to atomic variable
totalram_pages, zone->managed_pages and totalhigh_pages updates
are protected by managed_page_count_lock, but readers never care
about it. Convert these variables to atomic to avoid readers
potentially seeing a store tear.
This patch converts zone->managed_pages. Subsequent patches will
convert totalram_panges, totalhigh_pages and eventually
managed_page_count_lock will be removed.
Main motivation was that managed_page_count_lock handling was
complicating things. It was discussed in length here,
https://lore.kernel.org/patchwork/patch/995739/#1181785
So it seemes better to remove the lock and convert variables
to atomic, with preventing poteintial store-to-read tearing as
a bonus.
Suggested-by: Michal Hocko
Suggested-by: Vlastimil Babka
Signed-off-by: Arun KS
Reviewed-by: Konstantin Khlebnikov
Acked-by: Michal Hocko
Acked-by: Vlastimil Babka
---
Most of the changes are done by below coccinelle script,
@@
struct zone *z;
expression e1;
@@
(
- z->managed_pages = e1
+ atomic_long_set(>managed_pages, e1)
|
- e1->managed_pages++
+ atomic_long_inc(>managed_pages)
|
- z->managed_pages
+ zone_managed_pages(z)
)
@@
expression e,e1;
@@
- e->managed_pages += e1
+ atomic_long_add(e1, >managed_pages)
@@
expression z;
@@
- z.managed_pages
+ zone_managed_pages()
Then, manually apply following change,
include/linux/mmzone.h
- unsigned long managed_pages;
+ atomic_long_t managed_pages;
+static inline unsigned long zone_managed_pages(struct zone *zone)
+{
+ return (unsigned long)atomic_long_read(>managed_pages);
+}
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
include/linux/mmzone.h| 9 +--
lib/show_mem.c| 2 +-
mm/memblock.c | 2 +-
mm/page_alloc.c | 44 +--
mm/vmstat.c | 4 ++--
6 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 56412b0..c0e55bb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -848,7 +848,7 @@ static int kfd_fill_mem_info_for_cpu(int numa_node_id, int
*avail_size,
*/
pgdat = NODE_DATA(numa_node_id);
for (zone_type = 0; zone_type < MAX_NR_ZONES; zone_type++)
- mem_in_bytes += pgdat->node_zones[zone_type].managed_pages;
+ mem_in_bytes +=
zone_managed_pages(>node_zones[zone_type]);
mem_in_bytes <<= PAGE_SHIFT;
sub_type_hdr->length_low = lower_32_bits(mem_in_bytes);
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 847705a..e73dc31 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -435,7 +435,7 @@ struct zone {
* adjust_managed_page_count() should be used instead of directly
* touching zone->managed_pages and totalram_pages.
*/
- unsigned long managed_pages;
+ atomic_long_t managed_pages;
unsigned long spanned_pages;
unsigned long present_pages;
@@ -524,6 +524,11 @@ enum pgdat_flags {
PGDAT_RECLAIM_LOCKED, /* prevents concurrent reclaim */
};
+static inline unsigned long zone_managed_pages(struct zone *zone)
+{
+ return (unsigned long)atomic_long_read(>managed_pages);
+}
+
static inline unsigned long zone_end_pfn(const struct zone *zone)
{
return zone->zone_start_pfn + zone->spanned_pages;
@@ -814,7 +819,7 @@ static inline bool is_dev_zone(const struct zone *zone)
*/
static inline bool managed_zone(struct zone *zone)
{
- return zone->managed_pages;
+ return zone_managed_pages(zone);
}
/* Returns true if a zone has memory */
diff --git a/lib/show_mem.c b/lib/show_mem.c
index 0beaa1d..eefe67d 100644
--- a/lib/show_mem.c
+++ b/lib/show_mem.c
@@ -28,7 +28,7 @@ void show_mem(unsigned int filter, nodemask_t *nodemask)
continue;
total += zone->present_pages;
- reserved += zone->present_pages - zone->managed_pages;
+ reserved += zone->present_pages -
zone_managed_pages(zone);
if (is_highmem_idx(zoneid))
highmem += zone->present_pages;
diff --git a/mm/memblock.c b/mm/memblock.c
index 7df468c..bbd82ab 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1950,7 +1950,7 @@ void reset_node_managed_pages(pg_data_t *pgdat)
struct zone *z;
for (z = pgdat->node_zones; z < pgdat->node_zones + MAX_NR_ZONES; z++)
- z->managed_pages = 0;
+ atomic_long_set(>managed_pages, 0);
}
void __init reset_all_zones_managed_pages(void)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 173312b..22e6645 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1279,7 +1279,7 @@ static void __init __free_pages_boot_core(struct page
*page, unsigned int order)
[PATCH v5 4/4] mm: Remove managed_page_count spinlock
Now that totalram_pages and managed_pages are atomic varibles, no need
of managed_page_count spinlock. The lock had really a weak consistency
guarantee. It hasn't been used for anything but the update but no reader
actually cares about all the values being updated to be in sync.
Signed-off-by: Arun KS
Reviewed-by: Konstantin Khlebnikov
Acked-by: Michal Hocko
Acked-by: Vlastimil Babka
---
include/linux/mmzone.h | 6 --
mm/page_alloc.c| 5 -
2 files changed, 11 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e73dc31..c71b4d9 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -428,12 +428,6 @@ struct zone {
* Write access to present_pages at runtime should be protected by
* mem_hotplug_begin/end(). Any reader who can't tolerant drift of
* present_pages should get_online_mems() to get a stable value.
-*
-* Read access to managed_pages should be safe because it's unsigned
-* long. Write access to zone->managed_pages and totalram_pages are
-* protected by managed_page_count_lock at runtime. Idealy only
-* adjust_managed_page_count() should be used instead of directly
-* touching zone->managed_pages and totalram_pages.
*/
atomic_long_t managed_pages;
unsigned long spanned_pages;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f8b64cc..26c5e14 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -122,9 +122,6 @@
};
EXPORT_SYMBOL(node_states);
-/* Protect totalram_pages and zone->managed_pages */
-static DEFINE_SPINLOCK(managed_page_count_lock);
-
atomic_long_t _totalram_pages __read_mostly;
EXPORT_SYMBOL(_totalram_pages);
unsigned long totalreserve_pages __read_mostly;
@@ -7065,14 +7062,12 @@ static int __init cmdline_parse_movablecore(char *p)
void adjust_managed_page_count(struct page *page, long count)
{
- spin_lock(_page_count_lock);
atomic_long_add(count, _zone(page)->managed_pages);
totalram_pages_add(count);
#ifdef CONFIG_HIGHMEM
if (PageHighMem(page))
totalhigh_pages_add(count);
#endif
- spin_unlock(_page_count_lock);
}
EXPORT_SYMBOL(adjust_managed_page_count);
--
1.9.1
[PATCH v5 1/4] mm: reference totalram_pages and managed_pages once per function
This patch is in preparation to a later patch which converts totalram_pages
and zone->managed_pages to atomic variables. Please note that re-reading
the value might lead to a different value and as such it could lead to
unexpected behavior. There are no known bugs as a result of the current code
but it is better to prevent from them in principle.
Signed-off-by: Arun KS
Reviewed-by: Konstantin Khlebnikov
Acked-by: Michal Hocko
Acked-by: Vlastimil Babka
---
arch/um/kernel/mem.c | 2 +-
arch/x86/kernel/cpu/microcode/core.c | 5 +++--
drivers/hv/hv_balloon.c | 19 ++-
fs/file_table.c | 7 ---
kernel/fork.c| 5 +++--
kernel/kexec_core.c | 5 +++--
mm/page_alloc.c | 5 +++--
mm/shmem.c | 3 ++-
net/dccp/proto.c | 7 ---
net/netfilter/nf_conntrack_core.c| 7 ---
net/netfilter/xt_hashlimit.c | 5 +++--
net/sctp/protocol.c | 7 ---
12 files changed, 44 insertions(+), 33 deletions(-)
diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
index 1067469..2da2096 100644
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -52,7 +52,7 @@ void __init mem_init(void)
/* this will put all low memory onto the freelists */
memblock_free_all();
max_low_pfn = totalram_pages;
- max_pfn = totalram_pages;
+ max_pfn = max_low_pfn;
mem_init_print_info(NULL);
kmalloc_ok = 1;
}
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index 2637ff0..168fa27 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -434,9 +434,10 @@ static ssize_t microcode_write(struct file *file, const
char __user *buf,
size_t len, loff_t *ppos)
{
ssize_t ret = -EINVAL;
+ unsigned long nr_pages = totalram_pages;
- if ((len >> PAGE_SHIFT) > totalram_pages) {
- pr_err("too much data (max %ld pages)\n", totalram_pages);
+ if ((len >> PAGE_SHIFT) > nr_pages) {
+ pr_err("too much data (max %ld pages)\n", nr_pages);
return ret;
}
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 4163151..f3e7da9 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1090,6 +1090,7 @@ static void process_info(struct hv_dynmem_device *dm,
struct dm_info_msg *msg)
static unsigned long compute_balloon_floor(void)
{
unsigned long min_pages;
+ unsigned long nr_pages = totalram_pages;
#define MB2PAGES(mb) ((mb) << (20 - PAGE_SHIFT))
/* Simple continuous piecewiese linear function:
* max MiB -> min MiB gradient
@@ -1102,16 +1103,16 @@ static unsigned long compute_balloon_floor(void)
*8192 744(1/16)
* 32768 1512(1/32)
*/
- if (totalram_pages < MB2PAGES(128))
- min_pages = MB2PAGES(8) + (totalram_pages >> 1);
- else if (totalram_pages < MB2PAGES(512))
- min_pages = MB2PAGES(40) + (totalram_pages >> 2);
- else if (totalram_pages < MB2PAGES(2048))
- min_pages = MB2PAGES(104) + (totalram_pages >> 3);
- else if (totalram_pages < MB2PAGES(8192))
- min_pages = MB2PAGES(232) + (totalram_pages >> 4);
+ if (nr_pages < MB2PAGES(128))
+ min_pages = MB2PAGES(8) + (nr_pages >> 1);
+ else if (nr_pages < MB2PAGES(512))
+ min_pages = MB2PAGES(40) + (nr_pages >> 2);
+ else if (nr_pages < MB2PAGES(2048))
+ min_pages = MB2PAGES(104) + (nr_pages >> 3);
+ else if (nr_pages < MB2PAGES(8192))
+ min_pages = MB2PAGES(232) + (nr_pages >> 4);
else
- min_pages = MB2PAGES(488) + (totalram_pages >> 5);
+ min_pages = MB2PAGES(488) + (nr_pages >> 5);
#undef MB2PAGES
return min_pages;
}
diff --git a/fs/file_table.c b/fs/file_table.c
index e49af4c..b6e9587 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -380,10 +380,11 @@ void __init files_init(void)
void __init files_maxfiles_init(void)
{
unsigned long n;
- unsigned long memreserve = (totalram_pages - nr_free_pages()) * 3/2;
+ unsigned long nr_pages = totalram_pages;
+ unsigned long memreserve = (nr_pages - nr_free_pages()) * 3/2;
- memreserve = min(memreserve, totalram_pages - 1);
- n = ((totalram_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
+ memreserve = min(memreserve, nr_pages - 1);
+ n = ((nr_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
}
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff..58422c5 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -739,15 +739,16 @@ void __init __weak arch_task_cache_init(void) { }
static
[PATCH v5 0/4] mm: convert totalram_pages, totalhigh_pages and managed pages to atomic
This series convert totalram_pages, totalhigh_pages and zone->managed_pages to atomic variables. The patch was comiple tested on x86(x86_64_defconfig & i386_defconfig) on 4.20-rc2. And memory hotplug tested on arm64, but on an older version of kernel. totalram_pages, zone->managed_pages and totalhigh_pages updates are protected by managed_page_count_lock, but readers never care about it. Convert these variables to atomic to avoid readers potentially seeing a store tear. Main motivation was that managed_page_count_lock handling was complicating things. It was discussed in length here, https://lore.kernel.org/patchwork/patch/995739/#1181785 It seemes better to remove the lock and convert variables to atomic. With the change, preventing poteintial store-to-read tearing comes as a bonus. Changes in v5: - totalram_pgs renamed to nr_pages. https://lore.kernel.org/patchwork/patch/1011293/#1194248 Changes in v4: - Fixed kbuild test robot error. - Modified changelog. - Rebased to 4.20.-rc2 Changes in v3: - Fixed kbuild test robot errors. - Modified changelogs to be more clear. - EXPORT_SYMBOL for _totalram_pages and _totalhigh_pages. Arun KS (4): mm: reference totalram_pages and managed_pages once per function mm: convert zone->managed_pages to atomic variable mm: convert totalram_pages and totalhigh_pages variables to atomic mm: Remove managed_page_count spinlock arch/csky/mm/init.c | 4 +- arch/powerpc/platforms/pseries/cmm.c | 10 ++-- arch/s390/mm/init.c | 2 +- arch/um/kernel/mem.c | 4 +- arch/x86/kernel/cpu/microcode/core.c | 5 +- drivers/char/agp/backend.c| 4 +- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- drivers/hv/hv_balloon.c | 19 +++ drivers/md/dm-bufio.c | 2 +- drivers/md/dm-crypt.c | 2 +- drivers/md/dm-integrity.c | 2 +- drivers/md/dm-stats.c | 2 +- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- drivers/misc/vmw_balloon.c| 2 +- drivers/parisc/ccio-dma.c | 4 +- drivers/parisc/sba_iommu.c| 4 +- drivers/staging/android/ion/ion_system_heap.c | 2 +- drivers/xen/xen-selfballoon.c | 6 +-- fs/ceph/super.h | 2 +- fs/file_table.c | 7 +-- fs/fuse/inode.c | 2 +- fs/nfs/write.c| 2 +- fs/nfsd/nfscache.c| 2 +- fs/ntfs/malloc.h | 2 +- fs/proc/base.c| 2 +- include/linux/highmem.h | 28 ++- include/linux/mm.h| 27 +- include/linux/mmzone.h| 15 +++--- include/linux/swap.h | 1 - kernel/fork.c | 5 +- kernel/kexec_core.c | 5 +- kernel/power/snapshot.c | 2 +- lib/show_mem.c| 2 +- mm/highmem.c | 5 +- mm/huge_memory.c | 2 +- mm/kasan/quarantine.c | 2 +- mm/memblock.c | 6 +-- mm/mm_init.c | 2 +- mm/oom_kill.c | 2 +- mm/page_alloc.c | 72 +-- mm/shmem.c| 7 +-- mm/slab.c | 2 +- mm/swap.c | 2 +- mm/util.c | 2 +- mm/vmalloc.c | 4 +- mm/vmstat.c | 4 +- mm/workingset.c | 2 +- mm/zswap.c| 4 +- net/dccp/proto.c | 7 +-- net/decnet/dn_route.c | 2 +- net/ipv4/tcp_metrics.c| 2 +- net/netfilter/nf_conntrack_core.c | 7 +-- net/netfilter/xt_hashlimit.c | 5 +- net/sctp/protocol.c | 7 +-- security/integrity/ima/ima_kexec.c| 2 +- 57 files changed, 196 insertions(+), 142 deletions(-) -- 1.9.1
RE: [PATCH v2 1/5] mtd: spi-nor: don't drop sfdp data if optional parsers fail
> -Original Message-
> From: tudor.amba...@microchip.com [mailto:tudor.amba...@microchip.com]
> Sent: Friday, November 9, 2018 10:27 PM
> To: boris.brezil...@bootlin.com; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at
> Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; Yogesh
> Narayan Gaur ; cyrille.pitc...@wedev4u.fr;
> tudor.amba...@microchip.com
> Subject: [PATCH v2 1/5] mtd: spi-nor: don't drop sfdp data if optional
> parsers fail
>
> JESD216C states that just the Basic Flash Parameter Table is mandatory.
> Already defined (or future) additional parameter headers and tables are
> optional.
>
> Don't drop already collected sfdp data in case an optional table parser
> fails. In
> case of failing, each optional parser is responsible to roll back to the
> previously
> known spi_nor data.
>
> Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
> Reported-by: Yogesh Gaur
Tested-by: Yogesh Gaur
> Suggested-by: Boris Brezillon
> Signed-off-by: Tudor Ambarus
> ---
> v2: update Fixes tag to point to correct commit
>
> drivers/mtd/spi-nor/spi-nor.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index
> 4a96ee719e5a..2cdf96013689 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -3130,7 +3130,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> if (err)
> goto exit;
>
> - /* Parse other parameter headers. */
> + /* Parse optional parameter tables. */
> for (i = 0; i < header.nph; i++) {
> param_header = _headers[i];
>
> @@ -3143,8 +3143,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> break;
> }
>
> - if (err)
> - goto exit;
> + if (err) {
> + dev_warn(dev, "Failed to parse optional parameter
> table: %04x\n",
> + SFDP_PARAM_HEADER_ID(param_header));
> + /*
> + * Let's not drop all information we extracted so far
> + * if optional table parsers fail. In case of failing,
> + * each optional parser is responsible to roll back to
> + * the previously known spi_nor data.
> + */
> + err = 0;
> + }
> }
>
> exit:
> --
> 2.9.4
RE: [PATCH v2 1/5] mtd: spi-nor: don't drop sfdp data if optional parsers fail
> -Original Message-
> From: tudor.amba...@microchip.com [mailto:tudor.amba...@microchip.com]
> Sent: Friday, November 9, 2018 10:27 PM
> To: boris.brezil...@bootlin.com; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at
> Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; Yogesh
> Narayan Gaur ; cyrille.pitc...@wedev4u.fr;
> tudor.amba...@microchip.com
> Subject: [PATCH v2 1/5] mtd: spi-nor: don't drop sfdp data if optional
> parsers fail
>
> JESD216C states that just the Basic Flash Parameter Table is mandatory.
> Already defined (or future) additional parameter headers and tables are
> optional.
>
> Don't drop already collected sfdp data in case an optional table parser
> fails. In
> case of failing, each optional parser is responsible to roll back to the
> previously
> known spi_nor data.
>
> Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
> Reported-by: Yogesh Gaur
Tested-by: Yogesh Gaur
> Suggested-by: Boris Brezillon
> Signed-off-by: Tudor Ambarus
> ---
> v2: update Fixes tag to point to correct commit
>
> drivers/mtd/spi-nor/spi-nor.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index
> 4a96ee719e5a..2cdf96013689 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -3130,7 +3130,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> if (err)
> goto exit;
>
> - /* Parse other parameter headers. */
> + /* Parse optional parameter tables. */
> for (i = 0; i < header.nph; i++) {
> param_header = _headers[i];
>
> @@ -3143,8 +3143,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> break;
> }
>
> - if (err)
> - goto exit;
> + if (err) {
> + dev_warn(dev, "Failed to parse optional parameter
> table: %04x\n",
> + SFDP_PARAM_HEADER_ID(param_header));
> + /*
> + * Let's not drop all information we extracted so far
> + * if optional table parsers fail. In case of failing,
> + * each optional parser is responsible to roll back to
> + * the previously known spi_nor data.
> + */
> + err = 0;
> + }
> }
>
> exit:
> --
> 2.9.4
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
On Tue, 13 Nov 2018, Michael Schmitz wrote: > > > (It appears that a QEMU-emulated Mac does not benefit from having a > > clocksource that's more accurate than the 'jiffies' clocksource, in > > spite of "clocksource: Switched to clocksource via1".) > > With the current code, kernel log timestamps have 10 ms resolution on > Atari. Time resolution of times reported by initcall_debug is roughly 40 > us. I'd expect that changes with falling back to jiffies only. Might be > worth a try on QEMU Mac. The initcall debug output shows the same precision as my earlier tests with userland. The VIA timer only gets updated when QEMU wants to update it, which seems to be about every 9765 us. Hence, using the 'jiffies' clocksource would be effectively no regression for a virtual Mac. --
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
On Tue, 13 Nov 2018, Michael Schmitz wrote: > > > (It appears that a QEMU-emulated Mac does not benefit from having a > > clocksource that's more accurate than the 'jiffies' clocksource, in > > spite of "clocksource: Switched to clocksource via1".) > > With the current code, kernel log timestamps have 10 ms resolution on > Atari. Time resolution of times reported by initcall_debug is roughly 40 > us. I'd expect that changes with falling back to jiffies only. Might be > worth a try on QEMU Mac. The initcall debug output shows the same precision as my earlier tests with userland. The VIA timer only gets updated when QEMU wants to update it, which seems to be about every 9765 us. Hence, using the 'jiffies' clocksource would be effectively no regression for a virtual Mac. --
Re: [PATCH v3 06/13] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Hi Rob,
On 12/11/18 11:30 PM, Rob Herring wrote:
On Tue, Nov 06, 2018 at 02:10:58PM +0530, Lokesh Vutla wrote:
Add the DT binding documentation for Interrupt router driver.
Signed-off-by: Lokesh Vutla
---
Changes since v2:
- Dropped interrupt-parent from reqired properties description
- Updated the interrupt cells to 4.
.../interrupt-controller/ti,sci-intr.txt | 84 +++
MAINTAINERS | 1 +
2 files changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
new file mode 100644
index ..06e69f8c812c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
@@ -0,0 +1,84 @@
+Texas Instruments K3 Interrupt Router
+=
+
+The Interrupt Router (INTR) module provides a mechanism to mux M
+interrupt inputs to N interrupt outputs, where all M inputs are selectable
+to be driven per N output. There is one register per output (MUXCNTL_N) that
+controls the selection.
+
+
+ Interrupt Router
+ +--+
+ | Inputs Outputs |
++---+| +--+ |
+| GPIO |--->| | irq0 | | Host IRQ
++---+| +--+ | controller
+ |.+-+ | +---+
++---+|.| 0 | |->| IRQ |
+| INTA |--->|.+-+ | +---+
++---+|. . |
+ | +--+ . |
+ | | irqM |+-+ |
+ | +--+| N | |
+ | +-+ |
+ +--+
+
+Configuration of these MUXCNTL_N registers is done by a system controller
+(like the Device Memory and Security Controller on K3 AM654 SoC). System
+controller will keep track of the used and unused registers within the Router.
+Driver should request the system controller to get the range of GIC IRQs
+assigned to the requesting hosts. It is the drivers responsibility to keep
+track of Host IRQs.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Router Node:
+
+- compatible: Must be "ti,sci-intr".
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+ interrupt source. The value should be 4.
+ First cell should contain the TISCI device ID of source
+ Second cell should contain the interrupt source offset
+ within the device
+ Third cell specifies the trigger type as defined
+ in interrupts.txt in this directory.
+ Fourth cell should be 1 if the irq is coming from
+ interrupt aggregator else 0.
+- ti,sci: Phandle to TI-SCI compatible System controller node.
+- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
+- ti,sci-rm-range-girq:TISCI subtype id representing the host irqs
assigned
+ to this interrupt router.
u32 or array?
it is u32.
+
+For more details on TISCI IRQ resource management refer:
+http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
+
+Example:
+
+The following example demonstrates both interrupt router node and the consumer
+node(main gpio) on the AM654 SoC:
+
+main_intr: interrupt-controller@1 {
Unit-address is not valid here without a reg property.
Sure will fix it in next version.
Thanks and regards,
Lokesh
+ compatible = "ti,sci-intr";
+ interrupt-controller;
+ interrupt-parent = <>;
+ #interrupt-cells = <4>;
+ ti,sci = <>;
+ ti,sci-dst-id = <56>;
+ ti,sci-rm-range-girq = <0x1>;
+};
+
+main_gpio0: gpio@60 {
+ ...
+ interrupt-parent = <_intr>;
+ interrupts = <57 256 IRQ_TYPE_EDGE_RISING 0>,
+ <57 257 IRQ_TYPE_EDGE_RISING 0>,
+ <57 258 IRQ_TYPE_EDGE_RISING 0>,
+ <57 259 IRQ_TYPE_EDGE_RISING 0>,
+ <57 260 IRQ_TYPE_EDGE_RISING 0>,
+ <57 261 IRQ_TYPE_EDGE_RISING 0>;
+ ...
+};
diff --git
Re: [PATCH v3 06/13] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Hi Rob,
On 12/11/18 11:30 PM, Rob Herring wrote:
On Tue, Nov 06, 2018 at 02:10:58PM +0530, Lokesh Vutla wrote:
Add the DT binding documentation for Interrupt router driver.
Signed-off-by: Lokesh Vutla
---
Changes since v2:
- Dropped interrupt-parent from reqired properties description
- Updated the interrupt cells to 4.
.../interrupt-controller/ti,sci-intr.txt | 84 +++
MAINTAINERS | 1 +
2 files changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
new file mode 100644
index ..06e69f8c812c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
@@ -0,0 +1,84 @@
+Texas Instruments K3 Interrupt Router
+=
+
+The Interrupt Router (INTR) module provides a mechanism to mux M
+interrupt inputs to N interrupt outputs, where all M inputs are selectable
+to be driven per N output. There is one register per output (MUXCNTL_N) that
+controls the selection.
+
+
+ Interrupt Router
+ +--+
+ | Inputs Outputs |
++---+| +--+ |
+| GPIO |--->| | irq0 | | Host IRQ
++---+| +--+ | controller
+ |.+-+ | +---+
++---+|.| 0 | |->| IRQ |
+| INTA |--->|.+-+ | +---+
++---+|. . |
+ | +--+ . |
+ | | irqM |+-+ |
+ | +--+| N | |
+ | +-+ |
+ +--+
+
+Configuration of these MUXCNTL_N registers is done by a system controller
+(like the Device Memory and Security Controller on K3 AM654 SoC). System
+controller will keep track of the used and unused registers within the Router.
+Driver should request the system controller to get the range of GIC IRQs
+assigned to the requesting hosts. It is the drivers responsibility to keep
+track of Host IRQs.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Router Node:
+
+- compatible: Must be "ti,sci-intr".
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+ interrupt source. The value should be 4.
+ First cell should contain the TISCI device ID of source
+ Second cell should contain the interrupt source offset
+ within the device
+ Third cell specifies the trigger type as defined
+ in interrupts.txt in this directory.
+ Fourth cell should be 1 if the irq is coming from
+ interrupt aggregator else 0.
+- ti,sci: Phandle to TI-SCI compatible System controller node.
+- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
+- ti,sci-rm-range-girq:TISCI subtype id representing the host irqs
assigned
+ to this interrupt router.
u32 or array?
it is u32.
+
+For more details on TISCI IRQ resource management refer:
+http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
+
+Example:
+
+The following example demonstrates both interrupt router node and the consumer
+node(main gpio) on the AM654 SoC:
+
+main_intr: interrupt-controller@1 {
Unit-address is not valid here without a reg property.
Sure will fix it in next version.
Thanks and regards,
Lokesh
+ compatible = "ti,sci-intr";
+ interrupt-controller;
+ interrupt-parent = <>;
+ #interrupt-cells = <4>;
+ ti,sci = <>;
+ ti,sci-dst-id = <56>;
+ ti,sci-rm-range-girq = <0x1>;
+};
+
+main_gpio0: gpio@60 {
+ ...
+ interrupt-parent = <_intr>;
+ interrupts = <57 256 IRQ_TYPE_EDGE_RISING 0>,
+ <57 257 IRQ_TYPE_EDGE_RISING 0>,
+ <57 258 IRQ_TYPE_EDGE_RISING 0>,
+ <57 259 IRQ_TYPE_EDGE_RISING 0>,
+ <57 260 IRQ_TYPE_EDGE_RISING 0>,
+ <57 261 IRQ_TYPE_EDGE_RISING 0>;
+ ...
+};
diff --git
RE: [PATCH 15/23] dt-bindings: pci: mobiveil: change gpio_slave and apb_csr to optional
Hi Rob, Thanks a lot for your ACK! > -Original Message- > From: Rob Herring > Sent: 2018年11月13日 2:13 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; Mingkai Hu > ; M.h. Lian ; Xiaowei Bao > > Subject: Re: [PATCH 15/23] dt-bindings: pci: mobiveil: change gpio_slave and > apb_csr to optional > > On Tue, Nov 06, 2018 at 01:20:41PM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > Change the "gpio_slave" and "apb_csr" to optional, the "gpio_slave" > > is not used in current code, and "apb_csr" is not used by some > > platorms. > > > > Signed-off-by: Hou Zhiqiang > > --- > > Documentation/devicetree/bindings/pci/mobiveil-pcie.txt | 2 ++ > > 1 file changed, 2 insertions(+) > > Acked-by: Rob Herring Regards, Zhiqiang
RE: [PATCH 15/23] dt-bindings: pci: mobiveil: change gpio_slave and apb_csr to optional
Hi Rob, Thanks a lot for your ACK! > -Original Message- > From: Rob Herring > Sent: 2018年11月13日 2:13 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; Mingkai Hu > ; M.h. Lian ; Xiaowei Bao > > Subject: Re: [PATCH 15/23] dt-bindings: pci: mobiveil: change gpio_slave and > apb_csr to optional > > On Tue, Nov 06, 2018 at 01:20:41PM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > Change the "gpio_slave" and "apb_csr" to optional, the "gpio_slave" > > is not used in current code, and "apb_csr" is not used by some > > platorms. > > > > Signed-off-by: Hou Zhiqiang > > --- > > Documentation/devicetree/bindings/pci/mobiveil-pcie.txt | 2 ++ > > 1 file changed, 2 insertions(+) > > Acked-by: Rob Herring Regards, Zhiqiang
[PATCH AUTOSEL 4.19 03/44] cifs: fix return value for cifs_listxattr
From: Ronnie Sahlberg
[ Upstream commit 0c5d6cb6643f48ad3775322f3ebab6c7eb67484e ]
If the application buffer was too small to fit all the names
we would still count the number of bytes and return this for
listxattr. This would then trigger a BUG in usercopy.c
Fix the computation of the size so that we return -ERANGE
correctly when the buffer is too small.
This fixes the kernel BUG for xfstest generic/377
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Steve French
Reviewed-by: Aurelien Aptel
Signed-off-by: Sasha Levin
---
fs/cifs/smb2ops.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index 89985a0a6819..812da3e56a22 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -686,6 +686,7 @@ move_smb2_ea_to_cifs(char *dst, size_t dst_size,
int rc = 0;
unsigned int ea_name_len = ea_name ? strlen(ea_name) : 0;
char *name, *value;
+ size_t buf_size = dst_size;
size_t name_len, value_len, user_name_len;
while (src_size > 0) {
@@ -721,9 +722,10 @@ move_smb2_ea_to_cifs(char *dst, size_t dst_size,
/* 'user.' plus a terminating null */
user_name_len = 5 + 1 + name_len;
- rc += user_name_len;
-
- if (dst_size >= user_name_len) {
+ if (buf_size == 0) {
+ /* skip copy - calc size only */
+ rc += user_name_len;
+ } else if (dst_size >= user_name_len) {
dst_size -= user_name_len;
memcpy(dst, "user.", 5);
dst += 5;
@@ -731,8 +733,7 @@ move_smb2_ea_to_cifs(char *dst, size_t dst_size,
dst += name_len;
*dst = 0;
++dst;
- } else if (dst_size == 0) {
- /* skip copy - calc size only */
+ rc += user_name_len;
} else {
/* stop before overrun buffer */
rc = -ERANGE;
--
2.17.1
[PATCH AUTOSEL 4.19 05/44] nvme-pci: fix conflicting p2p resource adds
From: Keith Busch
[ Upstream commit 9fe5c59ff6a1e5e26a39b75489a1420e7eaaf0b1 ]
The nvme pci driver had been adding its CMB resource to the P2P DMA
subsystem everytime on on a controller reset. This results in the
following warning:
[ cut here ]
nvme :00:03.0: Conflicting mapping in same section
WARNING: CPU: 7 PID: 81 at kernel/memremap.c:155
devm_memremap_pages+0xa6/0x380
...
Call Trace:
pci_p2pdma_add_resource+0x153/0x370
nvme_reset_work+0x28c/0x17b1 [nvme]
? add_timer+0x107/0x1e0
? dequeue_entity+0x81/0x660
? dequeue_entity+0x3b0/0x660
? pick_next_task_fair+0xaf/0x610
? __switch_to+0xbc/0x410
process_one_work+0x1cf/0x350
worker_thread+0x215/0x3d0
? process_one_work+0x350/0x350
kthread+0x107/0x120
? kthread_park+0x80/0x80
ret_from_fork+0x1f/0x30
---[ end trace f7ea76ac6ee72727 ]---
nvme nvme0: failed to register the CMB
This patch fixes this by registering the CMB with P2P only once.
Signed-off-by: Keith Busch
Reviewed-by: Logan Gunthorpe
Signed-off-by: Christoph Hellwig
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
drivers/nvme/host/pci.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index d668682f91df..da18e0ac9fa2 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1647,6 +1647,9 @@ static void nvme_map_cmb(struct nvme_dev *dev)
struct pci_dev *pdev = to_pci_dev(dev->dev);
int bar;
+ if (dev->cmb_size)
+ return;
+
dev->cmbsz = readl(dev->bar + NVME_REG_CMBSZ);
if (!dev->cmbsz)
return;
@@ -2129,7 +2132,6 @@ static void nvme_pci_disable(struct nvme_dev *dev)
{
struct pci_dev *pdev = to_pci_dev(dev->dev);
- nvme_release_cmb(dev);
pci_free_irq_vectors(pdev);
if (pci_is_enabled(pdev)) {
@@ -2577,6 +2579,7 @@ static void nvme_remove(struct pci_dev *pdev)
nvme_stop_ctrl(>ctrl);
nvme_remove_namespaces(>ctrl);
nvme_dev_disable(dev, true);
+ nvme_release_cmb(dev);
nvme_free_host_mem(dev);
nvme_dev_remove_admin(dev);
nvme_free_queues(dev, 0);
--
2.17.1
[PATCH AUTOSEL 4.19 01/44] bfs: add sanity check at bfs_fill_super()
From: Tetsuo Handa
[ Upstream commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e ]
syzbot is reporting too large memory allocation at bfs_fill_super() [1].
Since file system image is corrupted such that bfs_sb->s_start == 0,
bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix
this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and
printf().
[1]
https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96
Link:
http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Reviewed-by: Andrew Morton
Cc: Tigran Aivazian
Cc: Matthew Wilcox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
fs/bfs/inode.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c
index 9a69392f1fb3..d81c148682e7 100644
--- a/fs/bfs/inode.c
+++ b/fs/bfs/inode.c
@@ -350,7 +350,8 @@ static int bfs_fill_super(struct super_block *s, void
*data, int silent)
s->s_magic = BFS_MAGIC;
- if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end)) {
+ if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) ||
+ le32_to_cpu(bfs_sb->s_start) < BFS_BSIZE) {
printf("Superblock is corrupted\n");
goto out1;
}
@@ -359,9 +360,11 @@ static int bfs_fill_super(struct super_block *s, void
*data, int silent)
sizeof(struct bfs_inode)
+ BFS_ROOT_INO - 1;
imap_len = (info->si_lasti / 8) + 1;
- info->si_imap = kzalloc(imap_len, GFP_KERNEL);
- if (!info->si_imap)
+ info->si_imap = kzalloc(imap_len, GFP_KERNEL | __GFP_NOWARN);
+ if (!info->si_imap) {
+ printf("Cannot allocate %u bytes\n", imap_len);
goto out1;
+ }
for (i = 0; i < BFS_ROOT_INO; i++)
set_bit(i, info->si_imap);
--
2.17.1
[PATCH AUTOSEL 4.19 03/44] cifs: fix return value for cifs_listxattr
From: Ronnie Sahlberg
[ Upstream commit 0c5d6cb6643f48ad3775322f3ebab6c7eb67484e ]
If the application buffer was too small to fit all the names
we would still count the number of bytes and return this for
listxattr. This would then trigger a BUG in usercopy.c
Fix the computation of the size so that we return -ERANGE
correctly when the buffer is too small.
This fixes the kernel BUG for xfstest generic/377
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Steve French
Reviewed-by: Aurelien Aptel
Signed-off-by: Sasha Levin
---
fs/cifs/smb2ops.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index 89985a0a6819..812da3e56a22 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -686,6 +686,7 @@ move_smb2_ea_to_cifs(char *dst, size_t dst_size,
int rc = 0;
unsigned int ea_name_len = ea_name ? strlen(ea_name) : 0;
char *name, *value;
+ size_t buf_size = dst_size;
size_t name_len, value_len, user_name_len;
while (src_size > 0) {
@@ -721,9 +722,10 @@ move_smb2_ea_to_cifs(char *dst, size_t dst_size,
/* 'user.' plus a terminating null */
user_name_len = 5 + 1 + name_len;
- rc += user_name_len;
-
- if (dst_size >= user_name_len) {
+ if (buf_size == 0) {
+ /* skip copy - calc size only */
+ rc += user_name_len;
+ } else if (dst_size >= user_name_len) {
dst_size -= user_name_len;
memcpy(dst, "user.", 5);
dst += 5;
@@ -731,8 +733,7 @@ move_smb2_ea_to_cifs(char *dst, size_t dst_size,
dst += name_len;
*dst = 0;
++dst;
- } else if (dst_size == 0) {
- /* skip copy - calc size only */
+ rc += user_name_len;
} else {
/* stop before overrun buffer */
rc = -ERANGE;
--
2.17.1
[PATCH AUTOSEL 4.19 05/44] nvme-pci: fix conflicting p2p resource adds
From: Keith Busch
[ Upstream commit 9fe5c59ff6a1e5e26a39b75489a1420e7eaaf0b1 ]
The nvme pci driver had been adding its CMB resource to the P2P DMA
subsystem everytime on on a controller reset. This results in the
following warning:
[ cut here ]
nvme :00:03.0: Conflicting mapping in same section
WARNING: CPU: 7 PID: 81 at kernel/memremap.c:155
devm_memremap_pages+0xa6/0x380
...
Call Trace:
pci_p2pdma_add_resource+0x153/0x370
nvme_reset_work+0x28c/0x17b1 [nvme]
? add_timer+0x107/0x1e0
? dequeue_entity+0x81/0x660
? dequeue_entity+0x3b0/0x660
? pick_next_task_fair+0xaf/0x610
? __switch_to+0xbc/0x410
process_one_work+0x1cf/0x350
worker_thread+0x215/0x3d0
? process_one_work+0x350/0x350
kthread+0x107/0x120
? kthread_park+0x80/0x80
ret_from_fork+0x1f/0x30
---[ end trace f7ea76ac6ee72727 ]---
nvme nvme0: failed to register the CMB
This patch fixes this by registering the CMB with P2P only once.
Signed-off-by: Keith Busch
Reviewed-by: Logan Gunthorpe
Signed-off-by: Christoph Hellwig
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
drivers/nvme/host/pci.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index d668682f91df..da18e0ac9fa2 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1647,6 +1647,9 @@ static void nvme_map_cmb(struct nvme_dev *dev)
struct pci_dev *pdev = to_pci_dev(dev->dev);
int bar;
+ if (dev->cmb_size)
+ return;
+
dev->cmbsz = readl(dev->bar + NVME_REG_CMBSZ);
if (!dev->cmbsz)
return;
@@ -2129,7 +2132,6 @@ static void nvme_pci_disable(struct nvme_dev *dev)
{
struct pci_dev *pdev = to_pci_dev(dev->dev);
- nvme_release_cmb(dev);
pci_free_irq_vectors(pdev);
if (pci_is_enabled(pdev)) {
@@ -2577,6 +2579,7 @@ static void nvme_remove(struct pci_dev *pdev)
nvme_stop_ctrl(>ctrl);
nvme_remove_namespaces(>ctrl);
nvme_dev_disable(dev, true);
+ nvme_release_cmb(dev);
nvme_free_host_mem(dev);
nvme_dev_remove_admin(dev);
nvme_free_queues(dev, 0);
--
2.17.1
[PATCH AUTOSEL 4.19 01/44] bfs: add sanity check at bfs_fill_super()
From: Tetsuo Handa
[ Upstream commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e ]
syzbot is reporting too large memory allocation at bfs_fill_super() [1].
Since file system image is corrupted such that bfs_sb->s_start == 0,
bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix
this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and
printf().
[1]
https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96
Link:
http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Reviewed-by: Andrew Morton
Cc: Tigran Aivazian
Cc: Matthew Wilcox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
fs/bfs/inode.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c
index 9a69392f1fb3..d81c148682e7 100644
--- a/fs/bfs/inode.c
+++ b/fs/bfs/inode.c
@@ -350,7 +350,8 @@ static int bfs_fill_super(struct super_block *s, void
*data, int silent)
s->s_magic = BFS_MAGIC;
- if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end)) {
+ if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) ||
+ le32_to_cpu(bfs_sb->s_start) < BFS_BSIZE) {
printf("Superblock is corrupted\n");
goto out1;
}
@@ -359,9 +360,11 @@ static int bfs_fill_super(struct super_block *s, void
*data, int silent)
sizeof(struct bfs_inode)
+ BFS_ROOT_INO - 1;
imap_len = (info->si_lasti / 8) + 1;
- info->si_imap = kzalloc(imap_len, GFP_KERNEL);
- if (!info->si_imap)
+ info->si_imap = kzalloc(imap_len, GFP_KERNEL | __GFP_NOWARN);
+ if (!info->si_imap) {
+ printf("Cannot allocate %u bytes\n", imap_len);
goto out1;
+ }
for (i = 0; i < BFS_ROOT_INO; i++)
set_bit(i, info->si_imap);
--
2.17.1
[PATCH AUTOSEL 4.19 04/44] arm64: kprobe: make page to RO mode when allocate it
From: Anders Roxell
[ Upstream commit 966866892cf89d606544bca22d584ba2ef9ec208 ]
Commit 1404d6f13e47 ("arm64: dump: Add checking for writable and exectuable
pages")
has successfully identified code that leaves a page with W+X
permissions.
[3.245140] arm64/mm: Found insecure W+X mapping at address
(ptrval)/0x00d9
[3.245771] WARNING: CPU: 0 PID: 1 at ../arch/arm64/mm/dump.c:232
note_page+0x410/0x420
[3.246141] Modules linked in:
[3.246653] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.19.0-rc5-next-20180928-1-ge70ae259b853-dirty #62
[3.247008] Hardware name: linux,dummy-virt (DT)
[3.247347] pstate: 8005 (Nzcv daif -PAN -UAO)
[3.247623] pc : note_page+0x410/0x420
[3.247898] lr : note_page+0x410/0x420
[3.248071] sp : 0804bcd0
[3.248254] x29: 0804bcd0 x28: 09274000
[3.248578] x27: 0921a000 x26: 80007dfff000
[3.248845] x25: 093f5000 x24: 09526f6a
[3.249109] x23: 0004 x22: 00d91000
[3.249396] x21: 00d9 x20:
[3.249661] x19: 0804bde8 x18: 0400
[3.249924] x17: x16:
[3.250271] x15: x14: 295f5f5f5f6c6176
[3.250594] x13: 7274705f5f5f5f28 x12: 2073736572646461
[3.250941] x11: 20746120676e6970 x10: 70616d20582b5720
[3.251252] x9 : 6572756365736e69 x8 : 3039643030303030
[3.251519] x7 : 3078302f x6 : 095467b2
[3.251802] x5 : x4 :
[3.252060] x3 : x2 :
[3.252323] x1 : 4d151327adc50b00 x0 :
[3.252664] Call trace:
[3.252953] note_page+0x410/0x420
[3.253186] walk_pgd+0x12c/0x238
[3.253417] ptdump_check_wx+0x68/0xf8
[3.253637] mark_rodata_ro+0x68/0x98
[3.253847] kernel_init+0x38/0x160
[3.254103] ret_from_fork+0x10/0x18
kprobes allocates a writable executable page with module_alloc() in
order to store executable code.
Reworked to that when allocate a page it sets mode RO. Inspired by
commit 63fef14fc98a ("kprobes/x86: Make insn buffer always ROX and use
text_poke()").
Suggested-by: Arnd Bergmann
Suggested-by: Ard Biesheuvel
Acked-by: Will Deacon
Acked-by: Masami Hiramatsu
Reviewed-by: Laura Abbott
Signed-off-by: Anders Roxell
[catalin.mari...@arm.com: removed unnecessary casts]
Signed-off-by: Catalin Marinas
Signed-off-by: Sasha Levin
---
arch/arm64/kernel/probes/kprobes.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c
b/arch/arm64/kernel/probes/kprobes.c
index e78c3ef04d95..b5a367d4bba6 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -23,7 +23,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -42,10 +44,21 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
static void __kprobes
post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
+static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
+{
+ void *addrs[1];
+ u32 insns[1];
+
+ addrs[0] = addr;
+ insns[0] = opcode;
+
+ return aarch64_insn_patch_text(addrs, insns, 1);
+}
+
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
/* prepare insn slot */
- p->ainsn.api.insn[0] = cpu_to_le32(p->opcode);
+ patch_text(p->ainsn.api.insn, p->opcode);
flush_icache_range((uintptr_t) (p->ainsn.api.insn),
(uintptr_t) (p->ainsn.api.insn) +
@@ -118,15 +131,15 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
return 0;
}
-static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
+void *alloc_insn_page(void)
{
- void *addrs[1];
- u32 insns[1];
+ void *page;
- addrs[0] = (void *)addr;
- insns[0] = (u32)opcode;
+ page = vmalloc_exec(PAGE_SIZE);
+ if (page)
+ set_memory_ro((unsigned long)page, 1);
- return aarch64_insn_patch_text(addrs, insns, 1);
+ return page;
}
/* arm kprobe: install breakpoint in text */
--
2.17.1
[PATCH AUTOSEL 4.19 04/44] arm64: kprobe: make page to RO mode when allocate it
From: Anders Roxell
[ Upstream commit 966866892cf89d606544bca22d584ba2ef9ec208 ]
Commit 1404d6f13e47 ("arm64: dump: Add checking for writable and exectuable
pages")
has successfully identified code that leaves a page with W+X
permissions.
[3.245140] arm64/mm: Found insecure W+X mapping at address
(ptrval)/0x00d9
[3.245771] WARNING: CPU: 0 PID: 1 at ../arch/arm64/mm/dump.c:232
note_page+0x410/0x420
[3.246141] Modules linked in:
[3.246653] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.19.0-rc5-next-20180928-1-ge70ae259b853-dirty #62
[3.247008] Hardware name: linux,dummy-virt (DT)
[3.247347] pstate: 8005 (Nzcv daif -PAN -UAO)
[3.247623] pc : note_page+0x410/0x420
[3.247898] lr : note_page+0x410/0x420
[3.248071] sp : 0804bcd0
[3.248254] x29: 0804bcd0 x28: 09274000
[3.248578] x27: 0921a000 x26: 80007dfff000
[3.248845] x25: 093f5000 x24: 09526f6a
[3.249109] x23: 0004 x22: 00d91000
[3.249396] x21: 00d9 x20:
[3.249661] x19: 0804bde8 x18: 0400
[3.249924] x17: x16:
[3.250271] x15: x14: 295f5f5f5f6c6176
[3.250594] x13: 7274705f5f5f5f28 x12: 2073736572646461
[3.250941] x11: 20746120676e6970 x10: 70616d20582b5720
[3.251252] x9 : 6572756365736e69 x8 : 3039643030303030
[3.251519] x7 : 3078302f x6 : 095467b2
[3.251802] x5 : x4 :
[3.252060] x3 : x2 :
[3.252323] x1 : 4d151327adc50b00 x0 :
[3.252664] Call trace:
[3.252953] note_page+0x410/0x420
[3.253186] walk_pgd+0x12c/0x238
[3.253417] ptdump_check_wx+0x68/0xf8
[3.253637] mark_rodata_ro+0x68/0x98
[3.253847] kernel_init+0x38/0x160
[3.254103] ret_from_fork+0x10/0x18
kprobes allocates a writable executable page with module_alloc() in
order to store executable code.
Reworked to that when allocate a page it sets mode RO. Inspired by
commit 63fef14fc98a ("kprobes/x86: Make insn buffer always ROX and use
text_poke()").
Suggested-by: Arnd Bergmann
Suggested-by: Ard Biesheuvel
Acked-by: Will Deacon
Acked-by: Masami Hiramatsu
Reviewed-by: Laura Abbott
Signed-off-by: Anders Roxell
[catalin.mari...@arm.com: removed unnecessary casts]
Signed-off-by: Catalin Marinas
Signed-off-by: Sasha Levin
---
arch/arm64/kernel/probes/kprobes.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c
b/arch/arm64/kernel/probes/kprobes.c
index e78c3ef04d95..b5a367d4bba6 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -23,7 +23,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -42,10 +44,21 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
static void __kprobes
post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
+static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
+{
+ void *addrs[1];
+ u32 insns[1];
+
+ addrs[0] = addr;
+ insns[0] = opcode;
+
+ return aarch64_insn_patch_text(addrs, insns, 1);
+}
+
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
/* prepare insn slot */
- p->ainsn.api.insn[0] = cpu_to_le32(p->opcode);
+ patch_text(p->ainsn.api.insn, p->opcode);
flush_icache_range((uintptr_t) (p->ainsn.api.insn),
(uintptr_t) (p->ainsn.api.insn) +
@@ -118,15 +131,15 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
return 0;
}
-static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
+void *alloc_insn_page(void)
{
- void *addrs[1];
- u32 insns[1];
+ void *page;
- addrs[0] = (void *)addr;
- insns[0] = (u32)opcode;
+ page = vmalloc_exec(PAGE_SIZE);
+ if (page)
+ set_memory_ro((unsigned long)page, 1);
- return aarch64_insn_patch_text(addrs, insns, 1);
+ return page;
}
/* arm kprobe: install breakpoint in text */
--
2.17.1
[PATCH AUTOSEL 4.19 19/44] perf unwind: Take pgoff into account when reporting elf to libdwfl
From: Milian Wolff
[ Upstream commit 1fe627da30331024f453faef04d500079b901107 ]
libdwfl parses an ELF file itself and creates mappings for the
individual sections. perf on the other hand sees raw mmap events which
represent individual sections. When we encounter an address pointing
into a mapping with pgoff != 0, we must take that into account and
report the file at the non-offset base address.
This fixes unwinding with libdwfl in some cases. E.g. for a file like:
```
using namespace std;
mutex g_mutex;
double worker()
{
lock_guard guard(g_mutex);
uniform_real_distribution uniform(-1E5, 1E5);
default_random_engine engine;
double s = 0;
for (int i = 0; i < 1000; ++i) {
s += norm(complex(uniform(engine), uniform(engine)));
}
cout << s << endl;
return s;
}
int main()
{
vector> results;
for (int i = 0; i < 1; ++i) {
results.push_back(async(launch::async, worker));
}
return 0;
}
```
Compile it with `g++ -g -O2 -lpthread cpp-locking.cpp -o cpp-locking`,
then record it with `perf record --call-graph dwarf -e
sched:sched_switch`.
When you analyze it with `perf script` and libunwind, you should see:
```
cpp-locking 20038 [005] 54830.236589: sched:sched_switch: prev_comm=cpp-locking
prev_pid=20038 prev_prio=120 prev_state=T ==> next_comm=swapper/5 next_pid=0
next_prio=120
b166fec5 __sched_text_start+0x545
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b166fec5 __sched_text_start+0x545
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b1670208 schedule+0x28
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b16737cc rwsem_down_read_failed+0xec
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b1665e04 call_rwsem_down_read_failed+0x14
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b1672a03 down_read+0x13
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b106bd85 __do_page_fault+0x445
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b18015f5 page_fault+0x45
(/lib/modules/4.14.78-1-lts/build/vmlinux)
7f38e4252591 new_heap+0x101 (/usr/lib/libc-2.28.so)
7f38e4252d0b arena_get2.part.4+0x2fb (/usr/lib/libc-2.28.so)
7f38e4255b1c tcache_init.part.6+0xec (/usr/lib/libc-2.28.so)
7f38e42569e5 __GI___libc_malloc+0x115 (inlined)
7f38e4241790 __GI__IO_file_doallocate+0x90 (inlined)
7f38e424fbbf __GI__IO_doallocbuf+0x4f (inlined)
7f38e424ee47 __GI__IO_file_overflow+0x197 (inlined)
7f38e424df36 _IO_new_file_xsputn+0x116 (inlined)
7f38e4242bfb __GI__IO_fwrite+0xdb (inlined)
7f38e463fa6d std::basic_streambuf
>::sputn(char const*, long)+0x1cd (inlined)
7f38e463fa6d std::ostreambuf_iterator
>::_M_put(char const*, long)+0x1cd (inlined)
7f38e463fa6d std::ostreambuf_iterator
> std::__write(std::ostreambuf_iterator >,
char const*, int)+0x1cd (inlined)
7f38e463fa6d std::ostreambuf_iterator
> std::num_put >
>::_M_insert_float(std::ostreambuf_iterator
7f38e464bd70 std::num_put > >::put(std::ostreambuf_iterator >, std::ios_base&, char, double) const+0x90 (inl>
7f38e464bd70 std::ostream&
std::ostream::_M_insert(double)+0x90 (/usr/lib/libstdc++.so.6.0.25)
563b9cb502f7 std::ostream::operator<<(double)+0xb7 (inlined)
563b9cb502f7 worker()+0xb7
(/ssd/milian/projects/kdab/rnd/hotspot/build/tests/test-clients/cpp-locking/cpp-locking)
563b9cb506fb double std::__invoke_impl(std::__invoke_other, double (*&&)())+0x2b (inlined)
563b9cb506fb std::__invoke_result::type
std::__invoke(double (*&&)())+0x2b (inlined)
563b9cb506fb decltype (__invoke((_S_declval<0ul>)()))
std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>)+0x2b (inlined)
563b9cb506fb std::thread::_Invoker
>::operator()()+0x2b (inlined)
563b9cb506fb
std::__future_base::_Task_setter,
std::__future_base::_Result_base::_Deleter>,
std::thread::_Invoker >, dou>
563b9cb506fb
std::_Function_handler (),
std::__future_base::_Task_setter
563b9cb507e8
std::function ()>::operator()() const+0x28
(inlined)
563b9cb507e8
std::__future_base::_State_baseV2::_M_do_set(std::function ()>*, bool*)+0x28 (/ssd/milian/>
7f38e46d24fe __pthread_once_slow+0xbe (/usr/lib/libpthread-2.28.so)
563b9cb51149 __gthread_once+0xe9 (inlined)
563b9cb51149 void std::call_once ()>*, bool*)>
563b9cb51149
std::__future_base::_State_baseV2::_M_set_result(std::function ()>, bool)+0xe9 (inlined)
563b9cb51149
std::__future_base::_Async_state_impl >, double>::_Async_state_impl(std::thread::_Invoker >&&)::{lambda()#1}::op>
563b9cb51149 void std::__invoke_impl >, double>::_Async_state_impl(std::thread::_Invoker
563b9cb51149
std::__invoke_result >,
[PATCH AUTOSEL 4.19 19/44] perf unwind: Take pgoff into account when reporting elf to libdwfl
From: Milian Wolff
[ Upstream commit 1fe627da30331024f453faef04d500079b901107 ]
libdwfl parses an ELF file itself and creates mappings for the
individual sections. perf on the other hand sees raw mmap events which
represent individual sections. When we encounter an address pointing
into a mapping with pgoff != 0, we must take that into account and
report the file at the non-offset base address.
This fixes unwinding with libdwfl in some cases. E.g. for a file like:
```
using namespace std;
mutex g_mutex;
double worker()
{
lock_guard guard(g_mutex);
uniform_real_distribution uniform(-1E5, 1E5);
default_random_engine engine;
double s = 0;
for (int i = 0; i < 1000; ++i) {
s += norm(complex(uniform(engine), uniform(engine)));
}
cout << s << endl;
return s;
}
int main()
{
vector> results;
for (int i = 0; i < 1; ++i) {
results.push_back(async(launch::async, worker));
}
return 0;
}
```
Compile it with `g++ -g -O2 -lpthread cpp-locking.cpp -o cpp-locking`,
then record it with `perf record --call-graph dwarf -e
sched:sched_switch`.
When you analyze it with `perf script` and libunwind, you should see:
```
cpp-locking 20038 [005] 54830.236589: sched:sched_switch: prev_comm=cpp-locking
prev_pid=20038 prev_prio=120 prev_state=T ==> next_comm=swapper/5 next_pid=0
next_prio=120
b166fec5 __sched_text_start+0x545
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b166fec5 __sched_text_start+0x545
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b1670208 schedule+0x28
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b16737cc rwsem_down_read_failed+0xec
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b1665e04 call_rwsem_down_read_failed+0x14
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b1672a03 down_read+0x13
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b106bd85 __do_page_fault+0x445
(/lib/modules/4.14.78-1-lts/build/vmlinux)
b18015f5 page_fault+0x45
(/lib/modules/4.14.78-1-lts/build/vmlinux)
7f38e4252591 new_heap+0x101 (/usr/lib/libc-2.28.so)
7f38e4252d0b arena_get2.part.4+0x2fb (/usr/lib/libc-2.28.so)
7f38e4255b1c tcache_init.part.6+0xec (/usr/lib/libc-2.28.so)
7f38e42569e5 __GI___libc_malloc+0x115 (inlined)
7f38e4241790 __GI__IO_file_doallocate+0x90 (inlined)
7f38e424fbbf __GI__IO_doallocbuf+0x4f (inlined)
7f38e424ee47 __GI__IO_file_overflow+0x197 (inlined)
7f38e424df36 _IO_new_file_xsputn+0x116 (inlined)
7f38e4242bfb __GI__IO_fwrite+0xdb (inlined)
7f38e463fa6d std::basic_streambuf
>::sputn(char const*, long)+0x1cd (inlined)
7f38e463fa6d std::ostreambuf_iterator
>::_M_put(char const*, long)+0x1cd (inlined)
7f38e463fa6d std::ostreambuf_iterator
> std::__write(std::ostreambuf_iterator >,
char const*, int)+0x1cd (inlined)
7f38e463fa6d std::ostreambuf_iterator
> std::num_put >
>::_M_insert_float(std::ostreambuf_iterator
7f38e464bd70 std::num_put > >::put(std::ostreambuf_iterator >, std::ios_base&, char, double) const+0x90 (inl>
7f38e464bd70 std::ostream&
std::ostream::_M_insert(double)+0x90 (/usr/lib/libstdc++.so.6.0.25)
563b9cb502f7 std::ostream::operator<<(double)+0xb7 (inlined)
563b9cb502f7 worker()+0xb7
(/ssd/milian/projects/kdab/rnd/hotspot/build/tests/test-clients/cpp-locking/cpp-locking)
563b9cb506fb double std::__invoke_impl(std::__invoke_other, double (*&&)())+0x2b (inlined)
563b9cb506fb std::__invoke_result::type
std::__invoke(double (*&&)())+0x2b (inlined)
563b9cb506fb decltype (__invoke((_S_declval<0ul>)()))
std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>)+0x2b (inlined)
563b9cb506fb std::thread::_Invoker
>::operator()()+0x2b (inlined)
563b9cb506fb
std::__future_base::_Task_setter,
std::__future_base::_Result_base::_Deleter>,
std::thread::_Invoker >, dou>
563b9cb506fb
std::_Function_handler (),
std::__future_base::_Task_setter
563b9cb507e8
std::function ()>::operator()() const+0x28
(inlined)
563b9cb507e8
std::__future_base::_State_baseV2::_M_do_set(std::function ()>*, bool*)+0x28 (/ssd/milian/>
7f38e46d24fe __pthread_once_slow+0xbe (/usr/lib/libpthread-2.28.so)
563b9cb51149 __gthread_once+0xe9 (inlined)
563b9cb51149 void std::call_once ()>*, bool*)>
563b9cb51149
std::__future_base::_State_baseV2::_M_set_result(std::function ()>, bool)+0xe9 (inlined)
563b9cb51149
std::__future_base::_Async_state_impl >, double>::_Async_state_impl(std::thread::_Invoker >&&)::{lambda()#1}::op>
563b9cb51149 void std::__invoke_impl >, double>::_Async_state_impl(std::thread::_Invoker
563b9cb51149
std::__invoke_result >,
[PATCH v4 2/3] microblaze: add system call table generation support
The system call tables are in different format in all architecture and it will be difficult to manually add, modify or delete the syscall table entries in the res- pective files. To make it easy by keeping a script and which will generate the uapi header and syscall table file. This change will also help to unify the implemen- tation across all architectures. The system call table generation script is added in kernel/syscalls directory which contain the scripts to generate both uapi header file and system call table files. The syscall.tbl will be input for the scripts. syscall.tbl contains the list of available system calls along with system call number and corresponding entry point. Add a new system call in this architecture will be possible by adding new entry in the syscall.tbl file. Adding a new table entry consisting of: - System call number. - ABI. - System call name. - Entry point name. syscallhdr.sh and syscalltbl.sh will generate uapi header unistd_32.h and syscall_table.h files respectively. Both .sh files will parse the content syscall.tbl to generate the header and table files. unistd_32.h will be included by uapi/asm/unistd.h and syscall_table.h is included by kernel/syscall_table.S - the real system call table. ARM, s390 and x86 architecuture does have similar support. I leverage their implementation to come up with a generic solution. Signed-off-by: Firoz Khan --- arch/microblaze/kernel/syscalls/Makefile | 38 +++ arch/microblaze/kernel/syscalls/syscall.tbl | 410 ++ arch/microblaze/kernel/syscalls/syscallhdr.sh | 36 +++ arch/microblaze/kernel/syscalls/syscalltbl.sh | 32 ++ 4 files changed, 516 insertions(+) create mode 100644 arch/microblaze/kernel/syscalls/Makefile create mode 100644 arch/microblaze/kernel/syscalls/syscall.tbl create mode 100644 arch/microblaze/kernel/syscalls/syscallhdr.sh create mode 100644 arch/microblaze/kernel/syscalls/syscalltbl.sh diff --git a/arch/microblaze/kernel/syscalls/Makefile b/arch/microblaze/kernel/syscalls/Makefile new file mode 100644 index 000..659faef --- /dev/null +++ b/arch/microblaze/kernel/syscalls/Makefile @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0 +kapi := arch/$(SRCARCH)/include/generated/asm +uapi := arch/$(SRCARCH)/include/generated/uapi/asm + +_dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ + $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') + +syscall := $(srctree)/$(src)/syscall.tbl +syshdr := $(srctree)/$(src)/syscallhdr.sh +systbl := $(srctree)/$(src)/syscalltbl.sh + +quiet_cmd_syshdr = SYSHDR $@ + cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \ + '$(syshdr_abis_$(basetarget))' \ + '$(syshdr_pfx_$(basetarget))'\ + '$(syshdr_offset_$(basetarget))' + +quiet_cmd_systbl = SYSTBL $@ + cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \ + '$(systbl_abis_$(basetarget))' \ + '$(systbl_abi_$(basetarget))'\ + '$(systbl_offset_$(basetarget))' + +$(uapi)/unistd_32.h: $(syscall) $(syshdr) + $(call if_changed,syshdr) + +$(kapi)/syscall_table.h: $(syscall) $(systbl) + $(call if_changed,systbl) + +uapisyshdr-y += unistd_32.h +kapisyshdr-y += syscall_table.h + +targets+= $(uapisyshdr-y) $(kapisyshdr-y) + +PHONY += all +all: $(addprefix $(uapi)/,$(uapisyshdr-y)) +all: $(addprefix $(kapi)/,$(kapisyshdr-y)) + @: diff --git a/arch/microblaze/kernel/syscalls/syscall.tbl b/arch/microblaze/kernel/syscalls/syscall.tbl new file mode 100644 index 000..a24d09e --- /dev/null +++ b/arch/microblaze/kernel/syscalls/syscall.tbl @@ -0,0 +1,410 @@ +# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note +# +# system call numbers and entry vectors for microblaze +# +# The format is: +# +# +# The is always "common" for this file +# +0 common restart_syscall sys_restart_syscall +1 common exitsys_exit +2 common forksys_fork +3 common readsys_read +4 common write sys_write +5 common opensys_open +6 common close sys_close +7 common waitpid sys_waitpid +8 common creat sys_creat +9 common linksys_link +10 common unlink sys_unlink +11 common execve sys_execve +12 common chdir sys_chdir +13 common timesys_time +14 common mknod sys_mknod +15 common chmod sys_chmod +16 common lchown sys_lchown +17
[PATCH v4 3/3] microblaze: generate uapi header and system call table files
System call table generation script must be run to gener- ate unistd_32.h and syscall_table.h files. This patch will have changes which will invokes the script. This patch will generate unistd_32.h and syscall_table.h files by the syscall table generation script invoked by microblaze/Makefile and the generated files against the removed files must be identical. The generated uapi header file will be included in uapi/- asm/unistd.h and generated system call table header file will be included by kernel/syscall_table.S file. Signed-off-by: Firoz Khan --- arch/microblaze/Makefile | 3 + arch/microblaze/include/asm/Kbuild| 1 + arch/microblaze/include/uapi/asm/Kbuild | 1 + arch/microblaze/include/uapi/asm/unistd.h | 411 +- arch/microblaze/kernel/syscall_table.S| 406 + 5 files changed, 10 insertions(+), 812 deletions(-) diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile index 0823d29..ddb251a 100644 --- a/arch/microblaze/Makefile +++ b/arch/microblaze/Makefile @@ -79,6 +79,9 @@ all: linux.bin archclean: $(Q)$(MAKE) $(clean)=$(boot) +archheaders: + $(Q)$(MAKE) $(build)=arch/microblaze/kernel/syscalls all + linux.bin linux.bin.gz linux.bin.ub: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ diff --git a/arch/microblaze/include/asm/Kbuild b/arch/microblaze/include/asm/Kbuild index 569ba9e..9c7d1d2 100644 --- a/arch/microblaze/include/asm/Kbuild +++ b/arch/microblaze/include/asm/Kbuild @@ -1,3 +1,4 @@ +generated-y += syscall_table.h generic-y += barrier.h generic-y += bitops.h generic-y += bug.h diff --git a/arch/microblaze/include/uapi/asm/Kbuild b/arch/microblaze/include/uapi/asm/Kbuild index 2c6a6bf..b6656d9 100644 --- a/arch/microblaze/include/uapi/asm/Kbuild +++ b/arch/microblaze/include/uapi/asm/Kbuild @@ -1,6 +1,7 @@ # UAPI Header export list include include/uapi/asm-generic/Kbuild.asm +generated-y += unistd_32.h generic-y += bitsperlong.h generic-y += bpf_perf_event.h generic-y += errno.h diff --git a/arch/microblaze/include/uapi/asm/unistd.h b/arch/microblaze/include/uapi/asm/unistd.h index 1c3f867..3f2d7cb 100644 --- a/arch/microblaze/include/uapi/asm/unistd.h +++ b/arch/microblaze/include/uapi/asm/unistd.h @@ -11,415 +11,6 @@ #ifndef _UAPI_ASM_MICROBLAZE_UNISTD_H #define _UAPI_ASM_MICROBLAZE_UNISTD_H -#define __NR_restart_syscall 0 /* ok */ -#define __NR_exit 1 /* ok */ -#define __NR_fork 2 /* not for no MMU - weird */ -#define __NR_read 3 /* ok */ -#define __NR_write 4 /* ok */ -#define __NR_open 5 /* openat */ -#define __NR_close 6 /* ok */ -#define __NR_waitpid 7 /* waitid */ -#define __NR_creat 8 /* openat */ -#define __NR_link 9 /* linkat */ -#define __NR_unlink10 /* unlinkat */ -#define __NR_execve11 /* ok */ -#define __NR_chdir 12 /* ok */ -#define __NR_time 13 /* obsolete -> sys_gettimeofday */ -#define __NR_mknod 14 /* mknodat */ -#define __NR_chmod 15 /* fchmodat */ -#define __NR_lchown16 /* ok */ -#define __NR_break 17 /* don't know */ -#define __NR_oldstat 18 /* remove */ -#define __NR_lseek 19 /* ok */ -#define __NR_getpid20 /* ok */ -#define __NR_mount 21 /* ok */ -#define __NR_umount22 /* ok */ /* use only umount2 */ -#define __NR_setuid23 /* ok */ -#define __NR_getuid24 /* ok */ -#define __NR_stime 25 /* obsolete -> sys_settimeofday */ -#define __NR_ptrace26 /* ok */ -#define __NR_alarm 27 /* obsolete -> sys_setitimer */ -#define __NR_oldfstat 28 /* remove */ -#define __NR_pause 29 /* obsolete -> sys_rt_sigtimedwait */ -#define __NR_utime 30 /* obsolete -> sys_utimesat */ -#define __NR_stty 31 /* remove */ -#define __NR_gtty 32 /* remove */ -#define __NR_access33 /* faccessat */ -/* can be implemented by sys_setpriority */ -#define __NR_nice 34 -#define __NR_ftime 35 /* remove */ -#define __NR_sync 36 /* ok */ -#define __NR_kill 37 /* ok */ -#define __NR_rename38 /* renameat */ -#define __NR_mkdir 39 /* mkdirat */ -#define __NR_rmdir 40 /* unlinkat */ -#define __NR_dup 41 /* ok */ -#define __NR_pipe 42 /* ok */ -#define __NR_times 43 /* ok */ -#define __NR_prof 44 /* remove */ -#define __NR_brk 45 /* ok -mmu, nommu specific */ -#define __NR_setgid46 /* ok */ -#define __NR_getgid47 /* ok */ -#define __NR_signal48 /* obsolete -> sys_rt_sigaction */ -#define __NR_geteuid 49 /* ok */ -#define __NR_getegid 50 /* ok */ -#define __NR_acct
[PATCH v4 0/3] microblaze: system call table generation support
The purpose of this patch series is, we can easily add/modify/delete system call table support by cha- nging entry in syscall.tbl file instead of manually changing many files. The other goal is to unify the system call table generation support implementation across all the architectures. The system call tables are in different format in all architecture. It will be difficult to manually add, modify or delete the system calls in the resp- ective files manually. To make it easy by keeping a script and which'll generate uapi header file and syscall table file. syscall.tbl contains the list of available system calls along with system call number and correspond- ing entry point. Add a new system call in this arch- itecture will be possible by adding new entry in the syscall.tbl file. Adding a new table entry consisting of: - System call number. - ABI. - System call name. - Entry point name. ARM, s390 and x86 architecuture does exist the sim- ilar support. I leverage their implementation to come up with a generic solution. I have done the same support for work for alpha, ia64, m68k, mips, parisc, powerpc, sh, sparc and xtensa. Below mentioned git repository contains more details about the workflow. https://github.com/frzkhn/system_call_table_generator/ Finally, this is the ground work to solve the Y2038 issue. We need to add two dozen of system calls to solve Y2038 issue. So this patch series will help to add new system calls easily by adding new entry in the syscall.tbl. changes since v3: - changed from generic-y to generated-y in Kbuild. changes since v2: - optimized/updated the syscall table generation scripts. - fixed all mixed indentation issues in syscall.tbl. - added "comments" in syscall_*.tbl. changes since v1: - enclosed __NR_sycalls macro with __KERNEL__. - added missing new line. Firoz Khan (3): microblaze: move __NR_syscalls macro from asm/unistd.h microblaze: add system call table generation support microblaze: generate uapi header and system call table files arch/microblaze/Makefile | 3 + arch/microblaze/include/asm/Kbuild| 1 + arch/microblaze/include/asm/unistd.h | 2 - arch/microblaze/include/uapi/asm/Kbuild | 1 + arch/microblaze/include/uapi/asm/unistd.h | 407 + arch/microblaze/kernel/syscall_table.S| 406 + arch/microblaze/kernel/syscalls/Makefile | 38 +++ arch/microblaze/kernel/syscalls/syscall.tbl | 410 ++ arch/microblaze/kernel/syscalls/syscallhdr.sh | 36 +++ arch/microblaze/kernel/syscalls/syscalltbl.sh | 32 ++ 10 files changed, 526 insertions(+), 810 deletions(-) create mode 100644 arch/microblaze/kernel/syscalls/Makefile create mode 100644 arch/microblaze/kernel/syscalls/syscall.tbl create mode 100644 arch/microblaze/kernel/syscalls/syscallhdr.sh create mode 100644 arch/microblaze/kernel/syscalls/syscalltbl.sh -- 1.9.1
[PATCH v4 1/3] microblaze: move __NR_syscalls macro from asm/unistd.h
__NR_syscalls holds the number of system call exist in microblaze architecture. We have to change the value of __NR_syscalls, if we add or delete a system call. One of the patch in this patch series has a script which will generate a uapi header based on syscall.tbl file. The syscall.tbl file contains the total number of system calls information. So we have two option to update __NR- _syscalls value. 1. Update __NR_syscalls in asm/unistd.h manually by count- ing the no.of system calls. No need to update NR_sys- calls until we either add a new system call or delete existing system call. 2. We can keep this feature it above mentioned script, that will count the number of syscalls and keep it in a generated file. In this case we don't need to expli- citly update __NR_syscalls in asm/unistd.h file. The 2nd option will be the recommended one. For that, I moved the __NR_syscalls macro from asm/unistd.h to uapi- /asm/unistd.h. While __NR_syscalls isn't strictly part of the uapi, having it as part of the generated header to simplifies the implementation. We also need to enclose this macro with #ifdef __KERNEL__ to avoid side effects. Signed-off-by: Firoz Khan --- arch/microblaze/include/asm/unistd.h | 2 -- arch/microblaze/include/uapi/asm/unistd.h | 4 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/microblaze/include/asm/unistd.h b/arch/microblaze/include/asm/unistd.h index f42c40f..9b7c2c4 100644 --- a/arch/microblaze/include/asm/unistd.h +++ b/arch/microblaze/include/asm/unistd.h @@ -38,6 +38,4 @@ #endif /* __ASSEMBLY__ */ -#define __NR_syscalls 401 - #endif /* _ASM_MICROBLAZE_UNISTD_H */ diff --git a/arch/microblaze/include/uapi/asm/unistd.h b/arch/microblaze/include/uapi/asm/unistd.h index 7a9f16a..1c3f867 100644 --- a/arch/microblaze/include/uapi/asm/unistd.h +++ b/arch/microblaze/include/uapi/asm/unistd.h @@ -418,4 +418,8 @@ #define __NR_io_pgetevents 399 #define __NR_rseq 400 +#ifdef __KERNEL__ +#define __NR_syscalls 401 +#endif + #endif /* _UAPI_ASM_MICROBLAZE_UNISTD_H */ -- 1.9.1
[PATCH v4 3/3] microblaze: generate uapi header and system call table files
System call table generation script must be run to gener- ate unistd_32.h and syscall_table.h files. This patch will have changes which will invokes the script. This patch will generate unistd_32.h and syscall_table.h files by the syscall table generation script invoked by microblaze/Makefile and the generated files against the removed files must be identical. The generated uapi header file will be included in uapi/- asm/unistd.h and generated system call table header file will be included by kernel/syscall_table.S file. Signed-off-by: Firoz Khan --- arch/microblaze/Makefile | 3 + arch/microblaze/include/asm/Kbuild| 1 + arch/microblaze/include/uapi/asm/Kbuild | 1 + arch/microblaze/include/uapi/asm/unistd.h | 411 +- arch/microblaze/kernel/syscall_table.S| 406 + 5 files changed, 10 insertions(+), 812 deletions(-) diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile index 0823d29..ddb251a 100644 --- a/arch/microblaze/Makefile +++ b/arch/microblaze/Makefile @@ -79,6 +79,9 @@ all: linux.bin archclean: $(Q)$(MAKE) $(clean)=$(boot) +archheaders: + $(Q)$(MAKE) $(build)=arch/microblaze/kernel/syscalls all + linux.bin linux.bin.gz linux.bin.ub: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ diff --git a/arch/microblaze/include/asm/Kbuild b/arch/microblaze/include/asm/Kbuild index 569ba9e..9c7d1d2 100644 --- a/arch/microblaze/include/asm/Kbuild +++ b/arch/microblaze/include/asm/Kbuild @@ -1,3 +1,4 @@ +generated-y += syscall_table.h generic-y += barrier.h generic-y += bitops.h generic-y += bug.h diff --git a/arch/microblaze/include/uapi/asm/Kbuild b/arch/microblaze/include/uapi/asm/Kbuild index 2c6a6bf..b6656d9 100644 --- a/arch/microblaze/include/uapi/asm/Kbuild +++ b/arch/microblaze/include/uapi/asm/Kbuild @@ -1,6 +1,7 @@ # UAPI Header export list include include/uapi/asm-generic/Kbuild.asm +generated-y += unistd_32.h generic-y += bitsperlong.h generic-y += bpf_perf_event.h generic-y += errno.h diff --git a/arch/microblaze/include/uapi/asm/unistd.h b/arch/microblaze/include/uapi/asm/unistd.h index 1c3f867..3f2d7cb 100644 --- a/arch/microblaze/include/uapi/asm/unistd.h +++ b/arch/microblaze/include/uapi/asm/unistd.h @@ -11,415 +11,6 @@ #ifndef _UAPI_ASM_MICROBLAZE_UNISTD_H #define _UAPI_ASM_MICROBLAZE_UNISTD_H -#define __NR_restart_syscall 0 /* ok */ -#define __NR_exit 1 /* ok */ -#define __NR_fork 2 /* not for no MMU - weird */ -#define __NR_read 3 /* ok */ -#define __NR_write 4 /* ok */ -#define __NR_open 5 /* openat */ -#define __NR_close 6 /* ok */ -#define __NR_waitpid 7 /* waitid */ -#define __NR_creat 8 /* openat */ -#define __NR_link 9 /* linkat */ -#define __NR_unlink10 /* unlinkat */ -#define __NR_execve11 /* ok */ -#define __NR_chdir 12 /* ok */ -#define __NR_time 13 /* obsolete -> sys_gettimeofday */ -#define __NR_mknod 14 /* mknodat */ -#define __NR_chmod 15 /* fchmodat */ -#define __NR_lchown16 /* ok */ -#define __NR_break 17 /* don't know */ -#define __NR_oldstat 18 /* remove */ -#define __NR_lseek 19 /* ok */ -#define __NR_getpid20 /* ok */ -#define __NR_mount 21 /* ok */ -#define __NR_umount22 /* ok */ /* use only umount2 */ -#define __NR_setuid23 /* ok */ -#define __NR_getuid24 /* ok */ -#define __NR_stime 25 /* obsolete -> sys_settimeofday */ -#define __NR_ptrace26 /* ok */ -#define __NR_alarm 27 /* obsolete -> sys_setitimer */ -#define __NR_oldfstat 28 /* remove */ -#define __NR_pause 29 /* obsolete -> sys_rt_sigtimedwait */ -#define __NR_utime 30 /* obsolete -> sys_utimesat */ -#define __NR_stty 31 /* remove */ -#define __NR_gtty 32 /* remove */ -#define __NR_access33 /* faccessat */ -/* can be implemented by sys_setpriority */ -#define __NR_nice 34 -#define __NR_ftime 35 /* remove */ -#define __NR_sync 36 /* ok */ -#define __NR_kill 37 /* ok */ -#define __NR_rename38 /* renameat */ -#define __NR_mkdir 39 /* mkdirat */ -#define __NR_rmdir 40 /* unlinkat */ -#define __NR_dup 41 /* ok */ -#define __NR_pipe 42 /* ok */ -#define __NR_times 43 /* ok */ -#define __NR_prof 44 /* remove */ -#define __NR_brk 45 /* ok -mmu, nommu specific */ -#define __NR_setgid46 /* ok */ -#define __NR_getgid47 /* ok */ -#define __NR_signal48 /* obsolete -> sys_rt_sigaction */ -#define __NR_geteuid 49 /* ok */ -#define __NR_getegid 50 /* ok */ -#define __NR_acct
[PATCH v4 0/3] microblaze: system call table generation support
The purpose of this patch series is, we can easily add/modify/delete system call table support by cha- nging entry in syscall.tbl file instead of manually changing many files. The other goal is to unify the system call table generation support implementation across all the architectures. The system call tables are in different format in all architecture. It will be difficult to manually add, modify or delete the system calls in the resp- ective files manually. To make it easy by keeping a script and which'll generate uapi header file and syscall table file. syscall.tbl contains the list of available system calls along with system call number and correspond- ing entry point. Add a new system call in this arch- itecture will be possible by adding new entry in the syscall.tbl file. Adding a new table entry consisting of: - System call number. - ABI. - System call name. - Entry point name. ARM, s390 and x86 architecuture does exist the sim- ilar support. I leverage their implementation to come up with a generic solution. I have done the same support for work for alpha, ia64, m68k, mips, parisc, powerpc, sh, sparc and xtensa. Below mentioned git repository contains more details about the workflow. https://github.com/frzkhn/system_call_table_generator/ Finally, this is the ground work to solve the Y2038 issue. We need to add two dozen of system calls to solve Y2038 issue. So this patch series will help to add new system calls easily by adding new entry in the syscall.tbl. changes since v3: - changed from generic-y to generated-y in Kbuild. changes since v2: - optimized/updated the syscall table generation scripts. - fixed all mixed indentation issues in syscall.tbl. - added "comments" in syscall_*.tbl. changes since v1: - enclosed __NR_sycalls macro with __KERNEL__. - added missing new line. Firoz Khan (3): microblaze: move __NR_syscalls macro from asm/unistd.h microblaze: add system call table generation support microblaze: generate uapi header and system call table files arch/microblaze/Makefile | 3 + arch/microblaze/include/asm/Kbuild| 1 + arch/microblaze/include/asm/unistd.h | 2 - arch/microblaze/include/uapi/asm/Kbuild | 1 + arch/microblaze/include/uapi/asm/unistd.h | 407 + arch/microblaze/kernel/syscall_table.S| 406 + arch/microblaze/kernel/syscalls/Makefile | 38 +++ arch/microblaze/kernel/syscalls/syscall.tbl | 410 ++ arch/microblaze/kernel/syscalls/syscallhdr.sh | 36 +++ arch/microblaze/kernel/syscalls/syscalltbl.sh | 32 ++ 10 files changed, 526 insertions(+), 810 deletions(-) create mode 100644 arch/microblaze/kernel/syscalls/Makefile create mode 100644 arch/microblaze/kernel/syscalls/syscall.tbl create mode 100644 arch/microblaze/kernel/syscalls/syscallhdr.sh create mode 100644 arch/microblaze/kernel/syscalls/syscalltbl.sh -- 1.9.1
[PATCH v4 1/3] microblaze: move __NR_syscalls macro from asm/unistd.h
__NR_syscalls holds the number of system call exist in microblaze architecture. We have to change the value of __NR_syscalls, if we add or delete a system call. One of the patch in this patch series has a script which will generate a uapi header based on syscall.tbl file. The syscall.tbl file contains the total number of system calls information. So we have two option to update __NR- _syscalls value. 1. Update __NR_syscalls in asm/unistd.h manually by count- ing the no.of system calls. No need to update NR_sys- calls until we either add a new system call or delete existing system call. 2. We can keep this feature it above mentioned script, that will count the number of syscalls and keep it in a generated file. In this case we don't need to expli- citly update __NR_syscalls in asm/unistd.h file. The 2nd option will be the recommended one. For that, I moved the __NR_syscalls macro from asm/unistd.h to uapi- /asm/unistd.h. While __NR_syscalls isn't strictly part of the uapi, having it as part of the generated header to simplifies the implementation. We also need to enclose this macro with #ifdef __KERNEL__ to avoid side effects. Signed-off-by: Firoz Khan --- arch/microblaze/include/asm/unistd.h | 2 -- arch/microblaze/include/uapi/asm/unistd.h | 4 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/microblaze/include/asm/unistd.h b/arch/microblaze/include/asm/unistd.h index f42c40f..9b7c2c4 100644 --- a/arch/microblaze/include/asm/unistd.h +++ b/arch/microblaze/include/asm/unistd.h @@ -38,6 +38,4 @@ #endif /* __ASSEMBLY__ */ -#define __NR_syscalls 401 - #endif /* _ASM_MICROBLAZE_UNISTD_H */ diff --git a/arch/microblaze/include/uapi/asm/unistd.h b/arch/microblaze/include/uapi/asm/unistd.h index 7a9f16a..1c3f867 100644 --- a/arch/microblaze/include/uapi/asm/unistd.h +++ b/arch/microblaze/include/uapi/asm/unistd.h @@ -418,4 +418,8 @@ #define __NR_io_pgetevents 399 #define __NR_rseq 400 +#ifdef __KERNEL__ +#define __NR_syscalls 401 +#endif + #endif /* _UAPI_ASM_MICROBLAZE_UNISTD_H */ -- 1.9.1
[PATCH v4 2/3] microblaze: add system call table generation support
The system call tables are in different format in all architecture and it will be difficult to manually add, modify or delete the syscall table entries in the res- pective files. To make it easy by keeping a script and which will generate the uapi header and syscall table file. This change will also help to unify the implemen- tation across all architectures. The system call table generation script is added in kernel/syscalls directory which contain the scripts to generate both uapi header file and system call table files. The syscall.tbl will be input for the scripts. syscall.tbl contains the list of available system calls along with system call number and corresponding entry point. Add a new system call in this architecture will be possible by adding new entry in the syscall.tbl file. Adding a new table entry consisting of: - System call number. - ABI. - System call name. - Entry point name. syscallhdr.sh and syscalltbl.sh will generate uapi header unistd_32.h and syscall_table.h files respectively. Both .sh files will parse the content syscall.tbl to generate the header and table files. unistd_32.h will be included by uapi/asm/unistd.h and syscall_table.h is included by kernel/syscall_table.S - the real system call table. ARM, s390 and x86 architecuture does have similar support. I leverage their implementation to come up with a generic solution. Signed-off-by: Firoz Khan --- arch/microblaze/kernel/syscalls/Makefile | 38 +++ arch/microblaze/kernel/syscalls/syscall.tbl | 410 ++ arch/microblaze/kernel/syscalls/syscallhdr.sh | 36 +++ arch/microblaze/kernel/syscalls/syscalltbl.sh | 32 ++ 4 files changed, 516 insertions(+) create mode 100644 arch/microblaze/kernel/syscalls/Makefile create mode 100644 arch/microblaze/kernel/syscalls/syscall.tbl create mode 100644 arch/microblaze/kernel/syscalls/syscallhdr.sh create mode 100644 arch/microblaze/kernel/syscalls/syscalltbl.sh diff --git a/arch/microblaze/kernel/syscalls/Makefile b/arch/microblaze/kernel/syscalls/Makefile new file mode 100644 index 000..659faef --- /dev/null +++ b/arch/microblaze/kernel/syscalls/Makefile @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0 +kapi := arch/$(SRCARCH)/include/generated/asm +uapi := arch/$(SRCARCH)/include/generated/uapi/asm + +_dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ + $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') + +syscall := $(srctree)/$(src)/syscall.tbl +syshdr := $(srctree)/$(src)/syscallhdr.sh +systbl := $(srctree)/$(src)/syscalltbl.sh + +quiet_cmd_syshdr = SYSHDR $@ + cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \ + '$(syshdr_abis_$(basetarget))' \ + '$(syshdr_pfx_$(basetarget))'\ + '$(syshdr_offset_$(basetarget))' + +quiet_cmd_systbl = SYSTBL $@ + cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \ + '$(systbl_abis_$(basetarget))' \ + '$(systbl_abi_$(basetarget))'\ + '$(systbl_offset_$(basetarget))' + +$(uapi)/unistd_32.h: $(syscall) $(syshdr) + $(call if_changed,syshdr) + +$(kapi)/syscall_table.h: $(syscall) $(systbl) + $(call if_changed,systbl) + +uapisyshdr-y += unistd_32.h +kapisyshdr-y += syscall_table.h + +targets+= $(uapisyshdr-y) $(kapisyshdr-y) + +PHONY += all +all: $(addprefix $(uapi)/,$(uapisyshdr-y)) +all: $(addprefix $(kapi)/,$(kapisyshdr-y)) + @: diff --git a/arch/microblaze/kernel/syscalls/syscall.tbl b/arch/microblaze/kernel/syscalls/syscall.tbl new file mode 100644 index 000..a24d09e --- /dev/null +++ b/arch/microblaze/kernel/syscalls/syscall.tbl @@ -0,0 +1,410 @@ +# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note +# +# system call numbers and entry vectors for microblaze +# +# The format is: +# +# +# The is always "common" for this file +# +0 common restart_syscall sys_restart_syscall +1 common exitsys_exit +2 common forksys_fork +3 common readsys_read +4 common write sys_write +5 common opensys_open +6 common close sys_close +7 common waitpid sys_waitpid +8 common creat sys_creat +9 common linksys_link +10 common unlink sys_unlink +11 common execve sys_execve +12 common chdir sys_chdir +13 common timesys_time +14 common mknod sys_mknod +15 common chmod sys_chmod +16 common lchown sys_lchown +17
[PATCH AUTOSEL 4.19 24/44] clk: fixed-rate: fix of_node_get-put imbalance
From: Alan Tull
[ Upstream commit 52091c256bdcad0d01e2852a63f19cd2cce6af96 ]
When the fixed rate clock is created by devicetree,
of_clk_add_provider is called. Add a call to
of_clk_del_provider in the remove function to balance
it out.
Signed-off-by: Alan Tull
Fixes: 435779fe1336 ("clk: fixed-rate: Convert into a module platform driver")
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/clk-fixed-rate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index b5c46b3f8764..6d6475c32ee5 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -200,6 +200,7 @@ static int of_fixed_clk_remove(struct platform_device *pdev)
{
struct clk *clk = platform_get_drvdata(pdev);
+ of_clk_del_provider(pdev->dev.of_node);
clk_unregister_fixed_rate(clk);
return 0;
--
2.17.1
[PATCH AUTOSEL 4.19 20/44] um: Give start_idle_thread() a return code
From: Richard Weinberger [ Upstream commit 7ff1e34bbdc15acab823b1ee4240e94623d50ee8 ] Fixes: arch/um/os-Linux/skas/process.c:613:1: warning: control reaches end of non-void function [-Wreturn-type] longjmp() never returns but gcc still warns that the end of the function can be reached. Add a return code and debug aid to detect this impossible case. Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin --- arch/um/os-Linux/skas/process.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c index c94c3bd70ccd..df4a985716eb 100644 --- a/arch/um/os-Linux/skas/process.c +++ b/arch/um/os-Linux/skas/process.c @@ -610,6 +610,11 @@ int start_idle_thread(void *stack, jmp_buf *switch_buf) fatal_sigsegv(); } longjmp(*switch_buf, 1); + + /* unreachable */ + printk(UM_KERN_ERR "impossible long jump!"); + fatal_sigsegv(); + return 0; } void initial_thread_cb_skas(void (*proc)(void *), void *arg) -- 2.17.1
[PATCH AUTOSEL 4.19 23/44] platform/x86: intel_telemetry: report debugfs failure
From: Rajneesh Bhardwaj
[ Upstream commit 8d98b1ef368feeb7720b8b9b6f3bd93f2ad892bc ]
On some Goldmont based systems such as ASRock J3455M the BIOS may not
enable the IPC1 device that provides access to the PMC and PUNIT. In
such scenarios, the IOSS and PSS resources from the platform device can
not be obtained and result in a invalid telemetry_plt_config which is an
internal data structure that holds platform config and is maintained by
the telemetry platform driver.
This is also applicable to the platforms where the BIOS supports IPC1
device under debug configurations but IPC1 is disabled by user or the
policy.
This change allows user to know the reason for not seeing entries under
/sys/kernel/debug/telemetry/* when there is no apparent failure at boot.
Cc: Matt Turner
Cc: Len Brown
Cc: Souvik Kumar Chakravarty
Cc: Kuppuswamy Sathyanarayanan
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198779
Acked-by: Matt Turner
Signed-off-by: Rajneesh Bhardwaj
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
---
drivers/platform/x86/intel_telemetry_debugfs.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c
b/drivers/platform/x86/intel_telemetry_debugfs.c
index ffd0474b0531..1423fa8710fd 100644
--- a/drivers/platform/x86/intel_telemetry_debugfs.c
+++ b/drivers/platform/x86/intel_telemetry_debugfs.c
@@ -951,12 +951,16 @@ static int __init telemetry_debugfs_init(void)
debugfs_conf = (struct telemetry_debugfs_conf *)id->driver_data;
err = telemetry_pltconfig_valid();
- if (err < 0)
+ if (err < 0) {
+ pr_info("Invalid pltconfig, ensure IPC1 device is enabled in
BIOS\n");
return -ENODEV;
+ }
err = telemetry_debugfs_check_evts();
- if (err < 0)
+ if (err < 0) {
+ pr_info("telemetry_debugfs_check_evts failed\n");
return -EINVAL;
+ }
register_pm_notifier(_notifier);
--
2.17.1
[PATCH AUTOSEL 4.19 20/44] um: Give start_idle_thread() a return code
From: Richard Weinberger [ Upstream commit 7ff1e34bbdc15acab823b1ee4240e94623d50ee8 ] Fixes: arch/um/os-Linux/skas/process.c:613:1: warning: control reaches end of non-void function [-Wreturn-type] longjmp() never returns but gcc still warns that the end of the function can be reached. Add a return code and debug aid to detect this impossible case. Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin --- arch/um/os-Linux/skas/process.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c index c94c3bd70ccd..df4a985716eb 100644 --- a/arch/um/os-Linux/skas/process.c +++ b/arch/um/os-Linux/skas/process.c @@ -610,6 +610,11 @@ int start_idle_thread(void *stack, jmp_buf *switch_buf) fatal_sigsegv(); } longjmp(*switch_buf, 1); + + /* unreachable */ + printk(UM_KERN_ERR "impossible long jump!"); + fatal_sigsegv(); + return 0; } void initial_thread_cb_skas(void (*proc)(void *), void *arg) -- 2.17.1
[PATCH AUTOSEL 4.19 23/44] platform/x86: intel_telemetry: report debugfs failure
From: Rajneesh Bhardwaj
[ Upstream commit 8d98b1ef368feeb7720b8b9b6f3bd93f2ad892bc ]
On some Goldmont based systems such as ASRock J3455M the BIOS may not
enable the IPC1 device that provides access to the PMC and PUNIT. In
such scenarios, the IOSS and PSS resources from the platform device can
not be obtained and result in a invalid telemetry_plt_config which is an
internal data structure that holds platform config and is maintained by
the telemetry platform driver.
This is also applicable to the platforms where the BIOS supports IPC1
device under debug configurations but IPC1 is disabled by user or the
policy.
This change allows user to know the reason for not seeing entries under
/sys/kernel/debug/telemetry/* when there is no apparent failure at boot.
Cc: Matt Turner
Cc: Len Brown
Cc: Souvik Kumar Chakravarty
Cc: Kuppuswamy Sathyanarayanan
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198779
Acked-by: Matt Turner
Signed-off-by: Rajneesh Bhardwaj
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
---
drivers/platform/x86/intel_telemetry_debugfs.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c
b/drivers/platform/x86/intel_telemetry_debugfs.c
index ffd0474b0531..1423fa8710fd 100644
--- a/drivers/platform/x86/intel_telemetry_debugfs.c
+++ b/drivers/platform/x86/intel_telemetry_debugfs.c
@@ -951,12 +951,16 @@ static int __init telemetry_debugfs_init(void)
debugfs_conf = (struct telemetry_debugfs_conf *)id->driver_data;
err = telemetry_pltconfig_valid();
- if (err < 0)
+ if (err < 0) {
+ pr_info("Invalid pltconfig, ensure IPC1 device is enabled in
BIOS\n");
return -ENODEV;
+ }
err = telemetry_debugfs_check_evts();
- if (err < 0)
+ if (err < 0) {
+ pr_info("telemetry_debugfs_check_evts failed\n");
return -EINVAL;
+ }
register_pm_notifier(_notifier);
--
2.17.1
[PATCH AUTOSEL 4.19 24/44] clk: fixed-rate: fix of_node_get-put imbalance
From: Alan Tull
[ Upstream commit 52091c256bdcad0d01e2852a63f19cd2cce6af96 ]
When the fixed rate clock is created by devicetree,
of_clk_add_provider is called. Add a call to
of_clk_del_provider in the remove function to balance
it out.
Signed-off-by: Alan Tull
Fixes: 435779fe1336 ("clk: fixed-rate: Convert into a module platform driver")
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/clk-fixed-rate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index b5c46b3f8764..6d6475c32ee5 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -200,6 +200,7 @@ static int of_fixed_clk_remove(struct platform_device *pdev)
{
struct clk *clk = platform_get_drvdata(pdev);
+ of_clk_del_provider(pdev->dev.of_node);
clk_unregister_fixed_rate(clk);
return 0;
--
2.17.1
[PATCH AUTOSEL 4.19 30/44] platform/x86: acerhdf: Add BIOS entry for Gateway LT31 v1.3307
From: Paul Gortmaker
[ Upstream commit 684238d79ad85c5e19a71bb5818e77e329912fbc ]
To fix:
acerhdf: unknown (unsupported) BIOS version Gateway /LT31 /v1.3307 ,
please report, aborting!
As can be seen in the context, the BIOS registers haven't changed in
the previous versions, so the assumption is they won't have changed
in this last update for this somewhat older platform either.
Cc: Peter Feuerer
Cc: Darren Hart
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
Signed-off-by: Andy Shevchenko
Reviewed-by: Peter Feuerer
Signed-off-by: Sasha Levin
---
drivers/platform/x86/acerhdf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index ea22591ee66f..53dfe67807e3 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -233,6 +233,7 @@ static const struct bios_settings bios_tbl[] = {
{"Gateway", "LT31", "v1.3201", 0x55, 0x58, {0x9e, 0x00}, 0},
{"Gateway", "LT31", "v1.3302", 0x55, 0x58, {0x9e, 0x00}, 0},
{"Gateway", "LT31", "v1.3303t", 0x55, 0x58, {0x9e, 0x00}, 0},
+ {"Gateway", "LT31", "v1.3307", 0x55, 0x58, {0x9e, 0x00}, 0},
/* Packard Bell */
{"Packard Bell", "DOA150", "v0.3104", 0x55, 0x58, {0x21, 0x00}, 0},
{"Packard Bell", "DOA150", "v0.3105", 0x55, 0x58, {0x20, 0x00}, 0},
--
2.17.1
[PATCH AUTOSEL 4.19 30/44] platform/x86: acerhdf: Add BIOS entry for Gateway LT31 v1.3307
From: Paul Gortmaker
[ Upstream commit 684238d79ad85c5e19a71bb5818e77e329912fbc ]
To fix:
acerhdf: unknown (unsupported) BIOS version Gateway /LT31 /v1.3307 ,
please report, aborting!
As can be seen in the context, the BIOS registers haven't changed in
the previous versions, so the assumption is they won't have changed
in this last update for this somewhat older platform either.
Cc: Peter Feuerer
Cc: Darren Hart
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
Signed-off-by: Andy Shevchenko
Reviewed-by: Peter Feuerer
Signed-off-by: Sasha Levin
---
drivers/platform/x86/acerhdf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index ea22591ee66f..53dfe67807e3 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -233,6 +233,7 @@ static const struct bios_settings bios_tbl[] = {
{"Gateway", "LT31", "v1.3201", 0x55, 0x58, {0x9e, 0x00}, 0},
{"Gateway", "LT31", "v1.3302", 0x55, 0x58, {0x9e, 0x00}, 0},
{"Gateway", "LT31", "v1.3303t", 0x55, 0x58, {0x9e, 0x00}, 0},
+ {"Gateway", "LT31", "v1.3307", 0x55, 0x58, {0x9e, 0x00}, 0},
/* Packard Bell */
{"Packard Bell", "DOA150", "v0.3104", 0x55, 0x58, {0x21, 0x00}, 0},
{"Packard Bell", "DOA150", "v0.3105", 0x55, 0x58, {0x20, 0x00}, 0},
--
2.17.1
[PATCH AUTOSEL 4.19 27/44] clk: samsung: exynos5420: Enable PERIS clocks for suspend
From: Marek Szyprowski
[ Upstream commit b33228029d842269e17bba591609e83ed422005d ]
Ensure that clocks for core SoC modules (including TZPC0..9 modules)
are enabled for suspend/resume cycle. This fixes suspend/resume
support on Exynos5422-based Odroid XU3/XU4 boards.
Suggested-by: Joonyoung Shim
Signed-off-by: Marek Szyprowski
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Sasha Levin
---
drivers/clk/samsung/clk-exynos5420.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 95e1bf69449b..d4f77c4eb277 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -281,6 +281,7 @@ static const struct samsung_clk_reg_dump
exynos5420_set_clksrc[] = {
{ .offset = GATE_BUS_TOP, .value = 0x, },
{ .offset = GATE_BUS_DISP1, .value = 0x, },
{ .offset = GATE_IP_PERIC, .value = 0x, },
+ { .offset = GATE_IP_PERIS, .value = 0x, },
};
static int exynos5420_clk_suspend(void)
--
2.17.1
[PATCH AUTOSEL 4.19 22/44] afs: Handle EIO from delivery function
From: David Howells
[ Upstream commit 4ac15ea53622272c01954461b4814892b7481b40 ]
Fix afs_deliver_to_call() to handle -EIO being returned by the operation
delivery function, indicating that the call found itself in the wrong
state, by printing an error and aborting the call.
Currently, an assertion failure will occur. This can happen, say, if the
delivery function falls off the end without calling afs_extract_data() with
the want_more parameter set to false to collect the end of the Rx phase of
a call.
The assertion failure looks like:
AFS: Assertion failed
4 == 7 is false
0x4 == 0x7 is false
[ cut here ]
kernel BUG at fs/afs/rxrpc.c:462!
and is matched in the trace buffer by a line like:
kworker/7:3-3226 [007] ...1 85158.030203: afs_io_error: c=0003be0c r=-5 CM_REPLY
Fixes: 98bf40cd99fc ("afs: Protect call->state changes against signals")
Reported-by: Marc Dionne
Signed-off-by: David Howells
Signed-off-by: Sasha Levin
---
fs/afs/rxrpc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 77a83790a31f..2543f24d23f8 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -500,7 +500,6 @@ static void afs_deliver_to_call(struct afs_call *call)
case -EINPROGRESS:
case -EAGAIN:
goto out;
- case -EIO:
case -ECONNABORTED:
ASSERTCMP(state, ==, AFS_CALL_COMPLETE);
goto done;
@@ -509,6 +508,10 @@ static void afs_deliver_to_call(struct afs_call *call)
rxrpc_kernel_abort_call(call->net->socket, call->rxcall,
abort_code, ret, "KIV");
goto local_abort;
+ case -EIO:
+ pr_err("kAFS: Call %u in bad state %u\n",
+ call->debug_id, state);
+ /* Fall through */
case -ENODATA:
case -EBADMSG:
case -EMSGSIZE:
--
2.17.1
[PATCH AUTOSEL 4.19 26/44] fs/exofs: fix potential memory leak in mount option parsing
From: Chengguang Xu
[ Upstream commit 515f1867addaba49c1c6ac73abfaffbc192c1db4 ]
There are some cases can cause memory leak when parsing
option 'osdname'.
Signed-off-by: Chengguang Xu
Signed-off-by: Al Viro
Signed-off-by: Sasha Levin
---
fs/exofs/super.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/exofs/super.c b/fs/exofs/super.c
index 41cf2fbee50d..7d61e3fa378c 100644
--- a/fs/exofs/super.c
+++ b/fs/exofs/super.c
@@ -101,6 +101,7 @@ static int parse_options(char *options, struct
exofs_mountopt *opts)
token = match_token(p, tokens, args);
switch (token) {
case Opt_name:
+ kfree(opts->dev_name);
opts->dev_name = match_strdup([0]);
if (unlikely(!opts->dev_name)) {
EXOFS_ERR("Error allocating dev_name");
@@ -866,8 +867,10 @@ static struct dentry *exofs_mount(struct file_system_type
*type,
int ret;
ret = parse_options(data, );
- if (ret)
+ if (ret) {
+ kfree(opts.dev_name);
return ERR_PTR(ret);
+ }
if (!opts.dev_name)
opts.dev_name = dev_name;
--
2.17.1
[PATCH AUTOSEL 4.19 28/44] apparmor: Fix uninitialized value in aa_split_fqname
From: Zubin Mithra
[ Upstream commit 250f2da49cb8e582215a65c03f50e8ddf5cd119c ]
Syzkaller reported a OOB-read with the stacktrace below. This occurs
inside __aa_lookupn_ns as `n` is not initialized. `n` is obtained from
aa_splitn_fqname. In cases where `name` is invalid, aa_splitn_fqname
returns without initializing `ns_name` and `ns_len`.
Fix this by always initializing `ns_name` and `ns_len`.
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
memcmp+0xe3/0x160 lib/string.c:861
strnstr+0x4b/0x70 lib/string.c:934
__aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209
aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240
aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468
fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844
aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908
aa_label_parse+0x42/0x50 security/apparmor/label.c:1943
aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362
apparmor_setprocattr+0xaa4/0x1150 security/apparmor/lsm.c:658
security_setprocattr+0x66/0xc0 security/security.c:1298
proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555
__vfs_write+0x119/0x9f0 fs/read_write.c:485
vfs_write+0x1fc/0x560 fs/read_write.c:549
ksys_write+0x101/0x260 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: 3b0aaf5866bf ("apparmor: add lib fn to find the "split" for fqnames")
Reported-by: syzbot+61e4b490d9d2da591...@syzkaller.appspotmail.com
Signed-off-by: Zubin Mithra
Reviewed-by: Kees Cook
Signed-off-by: John Johansen
Signed-off-by: Sasha Levin
---
security/apparmor/lib.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/security/apparmor/lib.c b/security/apparmor/lib.c
index 974affe50531..76491e7f4177 100644
--- a/security/apparmor/lib.c
+++ b/security/apparmor/lib.c
@@ -90,10 +90,12 @@ const char *aa_splitn_fqname(const char *fqname, size_t n,
const char **ns_name,
const char *end = fqname + n;
const char *name = skipn_spaces(fqname, n);
- if (!name)
- return NULL;
*ns_name = NULL;
*ns_len = 0;
+
+ if (!name)
+ return NULL;
+
if (name[0] == ':') {
char *split = strnchr([1], end - [1], ':');
*ns_name = skipn_spaces([1], end - [1]);
--
2.17.1
[PATCH AUTOSEL 4.19 27/44] clk: samsung: exynos5420: Enable PERIS clocks for suspend
From: Marek Szyprowski
[ Upstream commit b33228029d842269e17bba591609e83ed422005d ]
Ensure that clocks for core SoC modules (including TZPC0..9 modules)
are enabled for suspend/resume cycle. This fixes suspend/resume
support on Exynos5422-based Odroid XU3/XU4 boards.
Suggested-by: Joonyoung Shim
Signed-off-by: Marek Szyprowski
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Sasha Levin
---
drivers/clk/samsung/clk-exynos5420.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 95e1bf69449b..d4f77c4eb277 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -281,6 +281,7 @@ static const struct samsung_clk_reg_dump
exynos5420_set_clksrc[] = {
{ .offset = GATE_BUS_TOP, .value = 0x, },
{ .offset = GATE_BUS_DISP1, .value = 0x, },
{ .offset = GATE_IP_PERIC, .value = 0x, },
+ { .offset = GATE_IP_PERIS, .value = 0x, },
};
static int exynos5420_clk_suspend(void)
--
2.17.1
[PATCH AUTOSEL 4.19 22/44] afs: Handle EIO from delivery function
From: David Howells
[ Upstream commit 4ac15ea53622272c01954461b4814892b7481b40 ]
Fix afs_deliver_to_call() to handle -EIO being returned by the operation
delivery function, indicating that the call found itself in the wrong
state, by printing an error and aborting the call.
Currently, an assertion failure will occur. This can happen, say, if the
delivery function falls off the end without calling afs_extract_data() with
the want_more parameter set to false to collect the end of the Rx phase of
a call.
The assertion failure looks like:
AFS: Assertion failed
4 == 7 is false
0x4 == 0x7 is false
[ cut here ]
kernel BUG at fs/afs/rxrpc.c:462!
and is matched in the trace buffer by a line like:
kworker/7:3-3226 [007] ...1 85158.030203: afs_io_error: c=0003be0c r=-5 CM_REPLY
Fixes: 98bf40cd99fc ("afs: Protect call->state changes against signals")
Reported-by: Marc Dionne
Signed-off-by: David Howells
Signed-off-by: Sasha Levin
---
fs/afs/rxrpc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 77a83790a31f..2543f24d23f8 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -500,7 +500,6 @@ static void afs_deliver_to_call(struct afs_call *call)
case -EINPROGRESS:
case -EAGAIN:
goto out;
- case -EIO:
case -ECONNABORTED:
ASSERTCMP(state, ==, AFS_CALL_COMPLETE);
goto done;
@@ -509,6 +508,10 @@ static void afs_deliver_to_call(struct afs_call *call)
rxrpc_kernel_abort_call(call->net->socket, call->rxcall,
abort_code, ret, "KIV");
goto local_abort;
+ case -EIO:
+ pr_err("kAFS: Call %u in bad state %u\n",
+ call->debug_id, state);
+ /* Fall through */
case -ENODATA:
case -EBADMSG:
case -EMSGSIZE:
--
2.17.1
[PATCH AUTOSEL 4.19 26/44] fs/exofs: fix potential memory leak in mount option parsing
From: Chengguang Xu
[ Upstream commit 515f1867addaba49c1c6ac73abfaffbc192c1db4 ]
There are some cases can cause memory leak when parsing
option 'osdname'.
Signed-off-by: Chengguang Xu
Signed-off-by: Al Viro
Signed-off-by: Sasha Levin
---
fs/exofs/super.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/exofs/super.c b/fs/exofs/super.c
index 41cf2fbee50d..7d61e3fa378c 100644
--- a/fs/exofs/super.c
+++ b/fs/exofs/super.c
@@ -101,6 +101,7 @@ static int parse_options(char *options, struct
exofs_mountopt *opts)
token = match_token(p, tokens, args);
switch (token) {
case Opt_name:
+ kfree(opts->dev_name);
opts->dev_name = match_strdup([0]);
if (unlikely(!opts->dev_name)) {
EXOFS_ERR("Error allocating dev_name");
@@ -866,8 +867,10 @@ static struct dentry *exofs_mount(struct file_system_type
*type,
int ret;
ret = parse_options(data, );
- if (ret)
+ if (ret) {
+ kfree(opts.dev_name);
return ERR_PTR(ret);
+ }
if (!opts.dev_name)
opts.dev_name = dev_name;
--
2.17.1
[PATCH AUTOSEL 4.19 28/44] apparmor: Fix uninitialized value in aa_split_fqname
From: Zubin Mithra
[ Upstream commit 250f2da49cb8e582215a65c03f50e8ddf5cd119c ]
Syzkaller reported a OOB-read with the stacktrace below. This occurs
inside __aa_lookupn_ns as `n` is not initialized. `n` is obtained from
aa_splitn_fqname. In cases where `name` is invalid, aa_splitn_fqname
returns without initializing `ns_name` and `ns_len`.
Fix this by always initializing `ns_name` and `ns_len`.
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
memcmp+0xe3/0x160 lib/string.c:861
strnstr+0x4b/0x70 lib/string.c:934
__aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209
aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240
aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468
fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844
aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908
aa_label_parse+0x42/0x50 security/apparmor/label.c:1943
aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362
apparmor_setprocattr+0xaa4/0x1150 security/apparmor/lsm.c:658
security_setprocattr+0x66/0xc0 security/security.c:1298
proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555
__vfs_write+0x119/0x9f0 fs/read_write.c:485
vfs_write+0x1fc/0x560 fs/read_write.c:549
ksys_write+0x101/0x260 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: 3b0aaf5866bf ("apparmor: add lib fn to find the "split" for fqnames")
Reported-by: syzbot+61e4b490d9d2da591...@syzkaller.appspotmail.com
Signed-off-by: Zubin Mithra
Reviewed-by: Kees Cook
Signed-off-by: John Johansen
Signed-off-by: Sasha Levin
---
security/apparmor/lib.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/security/apparmor/lib.c b/security/apparmor/lib.c
index 974affe50531..76491e7f4177 100644
--- a/security/apparmor/lib.c
+++ b/security/apparmor/lib.c
@@ -90,10 +90,12 @@ const char *aa_splitn_fqname(const char *fqname, size_t n,
const char **ns_name,
const char *end = fqname + n;
const char *name = skipn_spaces(fqname, n);
- if (!name)
- return NULL;
*ns_name = NULL;
*ns_len = 0;
+
+ if (!name)
+ return NULL;
+
if (name[0] == ':') {
char *split = strnchr([1], end - [1], ':');
*ns_name = skipn_spaces([1], end - [1]);
--
2.17.1
[PATCH AUTOSEL 4.19 36/44] clk: ti: fix OF child-node lookup
From: Johan Hovold
[ Upstream commit 00a461cc32ec27fa7bd9c874a7b36b0c6c542c12 ]
Fix child-node lookup which by using the wrong OF helper was searching
the whole tree depth-first, something which could end up matching an
unrelated node.
Also fix the related node-reference leaks.
Fixes: 5b385a45e001 ("clk: ti: add support for clkctrl aliases")
Signed-off-by: Johan Hovold
Acked-by: Tero Kristo
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/ti/clk.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index 7d22e1af2247..27e0979b3158 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -129,7 +129,7 @@ int ti_clk_setup_ll_ops(struct ti_clk_ll_ops *ops)
void __init ti_dt_clocks_register(struct ti_dt_clk oclks[])
{
struct ti_dt_clk *c;
- struct device_node *node;
+ struct device_node *node, *parent;
struct clk *clk;
struct of_phandle_args clkspec;
char buf[64];
@@ -164,8 +164,12 @@ void __init ti_dt_clocks_register(struct ti_dt_clk oclks[])
continue;
node = of_find_node_by_name(NULL, buf);
- if (num_args)
- node = of_find_node_by_name(node, "clk");
+ if (num_args) {
+ parent = node;
+ node = of_get_child_by_name(parent, "clk");
+ of_node_put(parent);
+ }
+
clkspec.np = node;
clkspec.args_count = num_args;
for (i = 0; i < num_args; i++) {
@@ -173,11 +177,12 @@ void __init ti_dt_clocks_register(struct ti_dt_clk
oclks[])
if (ret) {
pr_warn("Bad tag in %s at %d: %s\n",
c->node_name, i, tags[i]);
+ of_node_put(node);
return;
}
}
clk = of_clk_get_from_provider();
-
+ of_node_put(node);
if (!IS_ERR(clk)) {
c->lk.clk = clk;
clkdev_add(>lk);
--
2.17.1
[PATCH AUTOSEL 4.19 33/44] clk: meson: clk-pll: drop CLK_GET_RATE_NOCACHE where unnecessary
From: Jerome Brunet
[ Upstream commit 2303a9ca693e585a558497ad737728fec97e2b8a ]
CLK_GET_RATE_NOCACHE should only be necessary when the registers
controlling the rate of clock may change outside of CCF. On Amlogic,
it should only be the case for the hdmi pll which is directly controlled
by the display driver (WIP to fix this).
The other plls should not require this flag.
Reviewed-by: Martin Blumenstingl
Tested-by: Martin Blumenstingl
Signed-off-by: Jerome Brunet
Signed-off-by: Sasha Levin
---
drivers/clk/meson/axg.c | 1 -
drivers/clk/meson/gxbb.c| 12
drivers/clk/meson/meson8b.c | 3 ---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
index a95152071087..f24d38c12e09 100644
--- a/drivers/clk/meson/axg.c
+++ b/drivers/clk/meson/axg.c
@@ -96,7 +96,6 @@ static struct clk_regmap axg_sys_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index 86d3ae58e84c..58e4b66bfc55 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -213,7 +213,6 @@ static struct clk_regmap gxbb_fixed_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -276,6 +275,10 @@ static struct clk_regmap gxbb_hdmi_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "hdmi_pll_pre_mult" },
.num_parents = 1,
+ /*
+* Display directly handle hdmi pll registers ATM, we need
+* NOCACHE to keep our view of the clock as accurate as possible
+*/
.flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -334,6 +337,10 @@ static struct clk_regmap gxl_hdmi_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
+ /*
+* Display directly handle hdmi pll registers ATM, we need
+* NOCACHE to keep our view of the clock as accurate as possible
+*/
.flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -371,7 +378,6 @@ static struct clk_regmap gxbb_sys_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -418,7 +424,6 @@ static struct clk_regmap gxbb_gp0_pll = {
.ops = _clk_pll_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -472,7 +477,6 @@ static struct clk_regmap gxl_gp0_pll = {
.ops = _clk_pll_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 7447d96a265f..74697e145dde 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -132,7 +132,6 @@ static struct clk_regmap meson8b_fixed_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -169,7 +168,6 @@ static struct clk_regmap meson8b_vid_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -207,7 +205,6 @@ static struct clk_regmap meson8b_sys_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
--
2.17.1
[PATCH AUTOSEL 4.19 31/44] clk: meson-axg: pcie: drop the mpll3 clock parent
From: Yixun Lan
[ Upstream commit 69b93104c7ec5668019caf5d2dbfd0e182df06db ]
We found the PCIe driver doesn't really work with
the mpll3 clock which is actually reserved for debug,
So drop it from the mux list.
Fixes: 33b89db68236 ("clk: meson-axg: add clocks required by pcie driver")
Tested-by: Jianxin Qin
Signed-off-by: Yixun Lan
Signed-off-by: Jerome Brunet
Signed-off-by: Sasha Levin
---
drivers/clk/meson/axg.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
index 00ce62ad6416..a95152071087 100644
--- a/drivers/clk/meson/axg.c
+++ b/drivers/clk/meson/axg.c
@@ -700,12 +700,14 @@ static struct clk_regmap axg_pcie_mux = {
.offset = HHI_PCIE_PLL_CNTL6,
.mask = 0x1,
.shift = 2,
+ /* skip the parent mpll3, reserved for debug */
+ .table = (u32[]){ 1 },
},
.hw.init = &(struct clk_init_data){
.name = "pcie_mux",
.ops = _regmap_mux_ops,
- .parent_names = (const char *[]){ "mpll3", "pcie_pll" },
- .num_parents = 2,
+ .parent_names = (const char *[]){ "pcie_pll" },
+ .num_parents = 1,
.flags = CLK_SET_RATE_PARENT,
},
};
--
2.17.1
[PATCH AUTOSEL 4.19 40/44] mm: don't raise MEMCG_OOM event due to failed high-order allocation
From: Roman Gushchin [ Upstream commit 7a1adfddaf0d11a39fdcaf6e82a88e9c0586e08b ] It was reported that on some of our machines containers were restarted with OOM symptoms without an obvious reason. Despite there were almost no memory pressure and plenty of page cache, MEMCG_OOM event was raised occasionally, causing the container management software to think, that OOM has happened. However, no tasks have been killed. The following investigation showed that the problem is caused by a failing attempt to charge a high-order page. In such case, the OOM killer is never invoked. As shown below, it can happen under conditions, which are very far from a real OOM: e.g. there is plenty of clean page cache and no memory pressure. There is no sense in raising an OOM event in this case, as it might confuse a user and lead to wrong and excessive actions (e.g. restart the workload, as in my case). Let's look at the charging path in try_charge(). If the memory usage is about memory.max, which is absolutely natural for most memory cgroups, we try to reclaim some pages. Even if we were able to reclaim enough memory for the allocation, the following check can fail due to a race with another concurrent allocation: if (mem_cgroup_margin(mem_over_limit) >= nr_pages) goto retry; For regular pages the following condition will save us from triggering the OOM: if (nr_reclaimed && nr_pages <= (1 << PAGE_ALLOC_COSTLY_ORDER)) goto retry; But for high-order allocation this condition will intentionally fail. The reason behind is that we'll likely fall to regular pages anyway, so it's ok and even preferred to return ENOMEM. In this case the idea of raising MEMCG_OOM looks dubious. Fix this by moving MEMCG_OOM raising to mem_cgroup_oom() after allocation order check, so that the event won't be raised for high order allocations. This change doesn't affect regular pages allocation and charging. Link: http://lkml.kernel.org/r/20181004214050.7417-1-g...@fb.com Signed-off-by: Roman Gushchin Acked-by: David Rientjes Acked-by: Michal Hocko Acked-by: Johannes Weiner Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- Documentation/admin-guide/cgroup-v2.rst | 4 mm/memcontrol.c | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 184193bcb262..5d9939388a78 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1127,6 +1127,10 @@ PAGE_SIZE multiple when read back. disk readahead. For now OOM in memory cgroup kills tasks iff shortage has happened inside page fault. + This event is not raised if the OOM killer is not + considered as an option, e.g. for failed high-order + allocations. + oom_kill The number of processes belonging to this cgroup killed by any kind of OOM killer. diff --git a/mm/memcontrol.c b/mm/memcontrol.c index e79cb59552d9..07c7af6f5e59 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1669,6 +1669,8 @@ static enum oom_status mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int if (order > PAGE_ALLOC_COSTLY_ORDER) return OOM_SKIPPED; + memcg_memory_event(memcg, MEMCG_OOM); + /* * We are in the middle of the charge context here, so we * don't want to block when potentially sitting on a callstack @@ -2250,8 +2252,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, if (fatal_signal_pending(current)) goto force; - memcg_memory_event(mem_over_limit, MEMCG_OOM); - /* * keep retrying as long as the memcg oom killer is able to make * a forward progress or bypass the charge if the oom killer -- 2.17.1
[PATCH AUTOSEL 4.19 32/44] arm64: percpu: Initialize ret in the default case
From: Nathan Chancellor [ Upstream commit b5bb425871186303e6936fa2581521bdd1964a58 ] Clang warns that if the default case is taken, ret will be uninitialized. ./arch/arm64/include/asm/percpu.h:196:2: warning: variable 'ret' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: ^~~ ./arch/arm64/include/asm/percpu.h:200:9: note: uninitialized use occurs here return ret; ^~~ ./arch/arm64/include/asm/percpu.h:157:19: note: initialize the variable 'ret' to silence this warning unsigned long ret, loop; ^ = 0 This warning appears several times while building the erofs filesystem. While it's not strictly wrong, the BUILD_BUG will prevent this from becoming a true problem. Initialize ret to 0 in the default case right before the BUILD_BUG to silence all of these warnings. Reported-by: Prasad Sodagudi Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Dennis Zhou Signed-off-by: Sasha Levin --- arch/arm64/include/asm/percpu.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h index 9234013e759e..21a81b59a0cc 100644 --- a/arch/arm64/include/asm/percpu.h +++ b/arch/arm64/include/asm/percpu.h @@ -96,6 +96,7 @@ static inline unsigned long __percpu_##op(void *ptr, \ : [val] "Ir" (val));\ break; \ default:\ + ret = 0;\ BUILD_BUG();\ } \ \ @@ -125,6 +126,7 @@ static inline unsigned long __percpu_read(void *ptr, int size) ret = READ_ONCE(*(u64 *)ptr); break; default: + ret = 0; BUILD_BUG(); } @@ -194,6 +196,7 @@ static inline unsigned long __percpu_xchg(void *ptr, unsigned long val, : [val] "r" (val)); break; default: + ret = 0; BUILD_BUG(); } -- 2.17.1
[PATCH AUTOSEL 4.19 36/44] clk: ti: fix OF child-node lookup
From: Johan Hovold
[ Upstream commit 00a461cc32ec27fa7bd9c874a7b36b0c6c542c12 ]
Fix child-node lookup which by using the wrong OF helper was searching
the whole tree depth-first, something which could end up matching an
unrelated node.
Also fix the related node-reference leaks.
Fixes: 5b385a45e001 ("clk: ti: add support for clkctrl aliases")
Signed-off-by: Johan Hovold
Acked-by: Tero Kristo
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/ti/clk.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index 7d22e1af2247..27e0979b3158 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -129,7 +129,7 @@ int ti_clk_setup_ll_ops(struct ti_clk_ll_ops *ops)
void __init ti_dt_clocks_register(struct ti_dt_clk oclks[])
{
struct ti_dt_clk *c;
- struct device_node *node;
+ struct device_node *node, *parent;
struct clk *clk;
struct of_phandle_args clkspec;
char buf[64];
@@ -164,8 +164,12 @@ void __init ti_dt_clocks_register(struct ti_dt_clk oclks[])
continue;
node = of_find_node_by_name(NULL, buf);
- if (num_args)
- node = of_find_node_by_name(node, "clk");
+ if (num_args) {
+ parent = node;
+ node = of_get_child_by_name(parent, "clk");
+ of_node_put(parent);
+ }
+
clkspec.np = node;
clkspec.args_count = num_args;
for (i = 0; i < num_args; i++) {
@@ -173,11 +177,12 @@ void __init ti_dt_clocks_register(struct ti_dt_clk
oclks[])
if (ret) {
pr_warn("Bad tag in %s at %d: %s\n",
c->node_name, i, tags[i]);
+ of_node_put(node);
return;
}
}
clk = of_clk_get_from_provider();
-
+ of_node_put(node);
if (!IS_ERR(clk)) {
c->lk.clk = clk;
clkdev_add(>lk);
--
2.17.1
[PATCH AUTOSEL 4.19 33/44] clk: meson: clk-pll: drop CLK_GET_RATE_NOCACHE where unnecessary
From: Jerome Brunet
[ Upstream commit 2303a9ca693e585a558497ad737728fec97e2b8a ]
CLK_GET_RATE_NOCACHE should only be necessary when the registers
controlling the rate of clock may change outside of CCF. On Amlogic,
it should only be the case for the hdmi pll which is directly controlled
by the display driver (WIP to fix this).
The other plls should not require this flag.
Reviewed-by: Martin Blumenstingl
Tested-by: Martin Blumenstingl
Signed-off-by: Jerome Brunet
Signed-off-by: Sasha Levin
---
drivers/clk/meson/axg.c | 1 -
drivers/clk/meson/gxbb.c| 12
drivers/clk/meson/meson8b.c | 3 ---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
index a95152071087..f24d38c12e09 100644
--- a/drivers/clk/meson/axg.c
+++ b/drivers/clk/meson/axg.c
@@ -96,7 +96,6 @@ static struct clk_regmap axg_sys_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index 86d3ae58e84c..58e4b66bfc55 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -213,7 +213,6 @@ static struct clk_regmap gxbb_fixed_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -276,6 +275,10 @@ static struct clk_regmap gxbb_hdmi_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "hdmi_pll_pre_mult" },
.num_parents = 1,
+ /*
+* Display directly handle hdmi pll registers ATM, we need
+* NOCACHE to keep our view of the clock as accurate as possible
+*/
.flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -334,6 +337,10 @@ static struct clk_regmap gxl_hdmi_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
+ /*
+* Display directly handle hdmi pll registers ATM, we need
+* NOCACHE to keep our view of the clock as accurate as possible
+*/
.flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -371,7 +378,6 @@ static struct clk_regmap gxbb_sys_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -418,7 +424,6 @@ static struct clk_regmap gxbb_gp0_pll = {
.ops = _clk_pll_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -472,7 +477,6 @@ static struct clk_regmap gxl_gp0_pll = {
.ops = _clk_pll_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 7447d96a265f..74697e145dde 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -132,7 +132,6 @@ static struct clk_regmap meson8b_fixed_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -169,7 +168,6 @@ static struct clk_regmap meson8b_vid_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
@@ -207,7 +205,6 @@ static struct clk_regmap meson8b_sys_pll = {
.ops = _clk_pll_ro_ops,
.parent_names = (const char *[]){ "xtal" },
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
},
};
--
2.17.1
[PATCH AUTOSEL 4.19 31/44] clk: meson-axg: pcie: drop the mpll3 clock parent
From: Yixun Lan
[ Upstream commit 69b93104c7ec5668019caf5d2dbfd0e182df06db ]
We found the PCIe driver doesn't really work with
the mpll3 clock which is actually reserved for debug,
So drop it from the mux list.
Fixes: 33b89db68236 ("clk: meson-axg: add clocks required by pcie driver")
Tested-by: Jianxin Qin
Signed-off-by: Yixun Lan
Signed-off-by: Jerome Brunet
Signed-off-by: Sasha Levin
---
drivers/clk/meson/axg.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
index 00ce62ad6416..a95152071087 100644
--- a/drivers/clk/meson/axg.c
+++ b/drivers/clk/meson/axg.c
@@ -700,12 +700,14 @@ static struct clk_regmap axg_pcie_mux = {
.offset = HHI_PCIE_PLL_CNTL6,
.mask = 0x1,
.shift = 2,
+ /* skip the parent mpll3, reserved for debug */
+ .table = (u32[]){ 1 },
},
.hw.init = &(struct clk_init_data){
.name = "pcie_mux",
.ops = _regmap_mux_ops,
- .parent_names = (const char *[]){ "mpll3", "pcie_pll" },
- .num_parents = 2,
+ .parent_names = (const char *[]){ "pcie_pll" },
+ .num_parents = 1,
.flags = CLK_SET_RATE_PARENT,
},
};
--
2.17.1
[PATCH AUTOSEL 4.19 40/44] mm: don't raise MEMCG_OOM event due to failed high-order allocation
From: Roman Gushchin [ Upstream commit 7a1adfddaf0d11a39fdcaf6e82a88e9c0586e08b ] It was reported that on some of our machines containers were restarted with OOM symptoms without an obvious reason. Despite there were almost no memory pressure and plenty of page cache, MEMCG_OOM event was raised occasionally, causing the container management software to think, that OOM has happened. However, no tasks have been killed. The following investigation showed that the problem is caused by a failing attempt to charge a high-order page. In such case, the OOM killer is never invoked. As shown below, it can happen under conditions, which are very far from a real OOM: e.g. there is plenty of clean page cache and no memory pressure. There is no sense in raising an OOM event in this case, as it might confuse a user and lead to wrong and excessive actions (e.g. restart the workload, as in my case). Let's look at the charging path in try_charge(). If the memory usage is about memory.max, which is absolutely natural for most memory cgroups, we try to reclaim some pages. Even if we were able to reclaim enough memory for the allocation, the following check can fail due to a race with another concurrent allocation: if (mem_cgroup_margin(mem_over_limit) >= nr_pages) goto retry; For regular pages the following condition will save us from triggering the OOM: if (nr_reclaimed && nr_pages <= (1 << PAGE_ALLOC_COSTLY_ORDER)) goto retry; But for high-order allocation this condition will intentionally fail. The reason behind is that we'll likely fall to regular pages anyway, so it's ok and even preferred to return ENOMEM. In this case the idea of raising MEMCG_OOM looks dubious. Fix this by moving MEMCG_OOM raising to mem_cgroup_oom() after allocation order check, so that the event won't be raised for high order allocations. This change doesn't affect regular pages allocation and charging. Link: http://lkml.kernel.org/r/20181004214050.7417-1-g...@fb.com Signed-off-by: Roman Gushchin Acked-by: David Rientjes Acked-by: Michal Hocko Acked-by: Johannes Weiner Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- Documentation/admin-guide/cgroup-v2.rst | 4 mm/memcontrol.c | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 184193bcb262..5d9939388a78 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1127,6 +1127,10 @@ PAGE_SIZE multiple when read back. disk readahead. For now OOM in memory cgroup kills tasks iff shortage has happened inside page fault. + This event is not raised if the OOM killer is not + considered as an option, e.g. for failed high-order + allocations. + oom_kill The number of processes belonging to this cgroup killed by any kind of OOM killer. diff --git a/mm/memcontrol.c b/mm/memcontrol.c index e79cb59552d9..07c7af6f5e59 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1669,6 +1669,8 @@ static enum oom_status mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int if (order > PAGE_ALLOC_COSTLY_ORDER) return OOM_SKIPPED; + memcg_memory_event(memcg, MEMCG_OOM); + /* * We are in the middle of the charge context here, so we * don't want to block when potentially sitting on a callstack @@ -2250,8 +2252,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, if (fatal_signal_pending(current)) goto force; - memcg_memory_event(mem_over_limit, MEMCG_OOM); - /* * keep retrying as long as the memcg oom killer is able to make * a forward progress or bypass the charge if the oom killer -- 2.17.1
[PATCH AUTOSEL 4.19 32/44] arm64: percpu: Initialize ret in the default case
From: Nathan Chancellor [ Upstream commit b5bb425871186303e6936fa2581521bdd1964a58 ] Clang warns that if the default case is taken, ret will be uninitialized. ./arch/arm64/include/asm/percpu.h:196:2: warning: variable 'ret' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: ^~~ ./arch/arm64/include/asm/percpu.h:200:9: note: uninitialized use occurs here return ret; ^~~ ./arch/arm64/include/asm/percpu.h:157:19: note: initialize the variable 'ret' to silence this warning unsigned long ret, loop; ^ = 0 This warning appears several times while building the erofs filesystem. While it's not strictly wrong, the BUILD_BUG will prevent this from becoming a true problem. Initialize ret to 0 in the default case right before the BUILD_BUG to silence all of these warnings. Reported-by: Prasad Sodagudi Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Dennis Zhou Signed-off-by: Sasha Levin --- arch/arm64/include/asm/percpu.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h index 9234013e759e..21a81b59a0cc 100644 --- a/arch/arm64/include/asm/percpu.h +++ b/arch/arm64/include/asm/percpu.h @@ -96,6 +96,7 @@ static inline unsigned long __percpu_##op(void *ptr, \ : [val] "Ir" (val));\ break; \ default:\ + ret = 0;\ BUILD_BUG();\ } \ \ @@ -125,6 +126,7 @@ static inline unsigned long __percpu_read(void *ptr, int size) ret = READ_ONCE(*(u64 *)ptr); break; default: + ret = 0; BUILD_BUG(); } @@ -194,6 +196,7 @@ static inline unsigned long __percpu_xchg(void *ptr, unsigned long val, : [val] "r" (val)); break; default: + ret = 0; BUILD_BUG(); } -- 2.17.1
