Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER
On 29 August 2018 at 20:59, Scott Branden wrote:
> Hi Olof,
>
>
> On 18-08-29 11:44 AM, Olof Johansson wrote:
>>
>> Hi,
>>
>> On Wed, Aug 29, 2018 at 10:21 AM, Scott Branden
>> wrote:
>>>
>>> Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command line
>>> parameter to function with efi loader.
>>>
>>> Required to boot on existing bootloaders that do not support devicetree
>>> provided by the platform or by the bootloader.
>>>
>>> Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option for the
>>> DTB loader")
>>> Signed-off-by: Scott Branden
>>
>> Why did Ard create an option for this if it's just going be turned on
>> in default configs? Doesn't make sense to me.
>>
>> It would help to know what firmware still is crippled and how common
>> it is, since it's been a few years that this has been a requirement by
>> now.
>
> Broadcom NS2 and Stingray in current development and production need this
> option in the kernel enabled in order to boot.
And these production systems run mainline kernels in a defconfig configuration?
The simply reality is that the DTB loader has been deprecated for a
good reason: it was only ever intended as a development hack anyway,
and if we need to treat the EFI stub provided DTB as a first class
citizen, there are things we need to fix to make things works as
expected. For instance, GRUB will put a property in the /chosen node
for the initramfs which will get dropped if you boot with dtb=.
Don't be surprised if some future enhancements of the EFI stub code
depend on !EFI_ARMSTUB_DTB_LOADER. On UEFI systems, DTBs [or ACPI
tables] are used by the firmware to describe itself and the underlying
platform to the OS, and the practice of booting with DTB file images
(taken from the kernel build as well) conflicts with that view. Note
that GRUB still permits you to load DTBs from files (and supports more
sources than just the file system the kernel Image was loaded from).
Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER
On 29 August 2018 at 20:59, Scott Branden wrote:
> Hi Olof,
>
>
> On 18-08-29 11:44 AM, Olof Johansson wrote:
>>
>> Hi,
>>
>> On Wed, Aug 29, 2018 at 10:21 AM, Scott Branden
>> wrote:
>>>
>>> Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command line
>>> parameter to function with efi loader.
>>>
>>> Required to boot on existing bootloaders that do not support devicetree
>>> provided by the platform or by the bootloader.
>>>
>>> Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option for the
>>> DTB loader")
>>> Signed-off-by: Scott Branden
>>
>> Why did Ard create an option for this if it's just going be turned on
>> in default configs? Doesn't make sense to me.
>>
>> It would help to know what firmware still is crippled and how common
>> it is, since it's been a few years that this has been a requirement by
>> now.
>
> Broadcom NS2 and Stingray in current development and production need this
> option in the kernel enabled in order to boot.
And these production systems run mainline kernels in a defconfig configuration?
The simply reality is that the DTB loader has been deprecated for a
good reason: it was only ever intended as a development hack anyway,
and if we need to treat the EFI stub provided DTB as a first class
citizen, there are things we need to fix to make things works as
expected. For instance, GRUB will put a property in the /chosen node
for the initramfs which will get dropped if you boot with dtb=.
Don't be surprised if some future enhancements of the EFI stub code
depend on !EFI_ARMSTUB_DTB_LOADER. On UEFI systems, DTBs [or ACPI
tables] are used by the firmware to describe itself and the underlying
platform to the OS, and the practice of booting with DTB file images
(taken from the kernel build as well) conflicts with that view. Note
that GRUB still permits you to load DTBs from files (and supports more
sources than just the file system the kernel Image was loaded from).
Re: [PATCH] gpio: Add driver for PC Engines APU2/APU3 GPIOs
On 2018-08-24 12:56, Piotr Król wrote: On 08/03/2018 09:08 PM, Andy Shevchenko wrote: Hi Andy, (...) +#define APU_FCH_ACPI_MMIO_BASE 0xFED8 +#define APU_FCH_GPIO_BASE (APU_FCH_ACPI_MMIO_BASE + 0x1500) Wow! Can we see ACPI tables for these boards? Care to share (via some file share service) output of `acpidump -o tables.dat` ? Please find acpidump [1]. FYI I'm PC Engines firmware maintainer (firmware is coreboot based), so I can fix required things. I'm pretty sure that ACPI tables are not in best shape. Thanks for the dump, By the way I have seen that the driver https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-amdpt.c is using the acpi to get the mmio address. I think this is the way to go to get the acpi mmio address in the gpio-apu driver as well. What is the right "acpi_device_id" for the APU3? https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-amdpt.c#L146
Re: [PATCH] gpio: Add driver for PC Engines APU2/APU3 GPIOs
On 2018-08-24 12:56, Piotr Król wrote: On 08/03/2018 09:08 PM, Andy Shevchenko wrote: Hi Andy, (...) +#define APU_FCH_ACPI_MMIO_BASE 0xFED8 +#define APU_FCH_GPIO_BASE (APU_FCH_ACPI_MMIO_BASE + 0x1500) Wow! Can we see ACPI tables for these boards? Care to share (via some file share service) output of `acpidump -o tables.dat` ? Please find acpidump [1]. FYI I'm PC Engines firmware maintainer (firmware is coreboot based), so I can fix required things. I'm pretty sure that ACPI tables are not in best shape. Thanks for the dump, By the way I have seen that the driver https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-amdpt.c is using the acpi to get the mmio address. I think this is the way to go to get the acpi mmio address in the gpio-apu driver as well. What is the right "acpi_device_id" for the APU3? https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-amdpt.c#L146
Re: [PATCH 2/4] tty: Hold tty_ldisc_lock() during tty_reopen()
On Wed, 2018-08-29 at 13:34 +0900, Sergey Senozhatsky wrote: > Hi, > > Cc-ing Benjamin on this. > > On (08/29/18 03:23), Dmitry Safonov wrote: > > BUG: unable to handle kernel paging request at 2260 > > IP: [..] n_tty_receive_buf_common+0x5f/0x86d > > Workqueue: events_unbound flush_to_ldisc > > Call Trace: > > [..] n_tty_receive_buf2 > > [..] tty_ldisc_receive_buf > > [..] flush_to_ldisc > > [..] process_one_work > > [..] worker_thread > > [..] kthread > > [..] ret_from_fork > > Seems that you are not the first one to hit this NULL deref. > > > I think, tty_ldisc_reinit() should be called with ldisc_sem hold for > > writing, which will protect any reader against line discipline changes. > > Per https://lore.kernel.org/patchwork/patch/777220/ > > : Note that we noticed one path that called reinit without the ldisc lock > : held for writing, we added that, but it didn't fix the problem. > > And I guess that Ben meant the same reinit path which you patched: This is too old for me to remember buit yes, there definitely was a bug there... > > @@ -1267,15 +1267,20 @@ static int tty_reopen(struct tty_struct *tty) > > if (test_bit(TTY_EXCLUSIVE, >flags) && !capable(CAP_SYS_ADMIN)) > > return -EBUSY; > > > > - tty->count++; > > + retval = tty_ldisc_lock(tty, 5 * HZ); > > + if (retval) > > + return retval; > > > > + tty->count++; > > if (tty->ldisc) > > - return 0; > > + goto out_unlock; > > > > retval = tty_ldisc_reinit(tty, tty->termios.c_line); > > if (retval) > > tty->count--; > > > > +out_unlock: > > + tty_ldisc_unlock(tty); > > return retval; > > } > > -ss
Re: [PATCH 2/4] tty: Hold tty_ldisc_lock() during tty_reopen()
On Wed, 2018-08-29 at 13:34 +0900, Sergey Senozhatsky wrote: > Hi, > > Cc-ing Benjamin on this. > > On (08/29/18 03:23), Dmitry Safonov wrote: > > BUG: unable to handle kernel paging request at 2260 > > IP: [..] n_tty_receive_buf_common+0x5f/0x86d > > Workqueue: events_unbound flush_to_ldisc > > Call Trace: > > [..] n_tty_receive_buf2 > > [..] tty_ldisc_receive_buf > > [..] flush_to_ldisc > > [..] process_one_work > > [..] worker_thread > > [..] kthread > > [..] ret_from_fork > > Seems that you are not the first one to hit this NULL deref. > > > I think, tty_ldisc_reinit() should be called with ldisc_sem hold for > > writing, which will protect any reader against line discipline changes. > > Per https://lore.kernel.org/patchwork/patch/777220/ > > : Note that we noticed one path that called reinit without the ldisc lock > : held for writing, we added that, but it didn't fix the problem. > > And I guess that Ben meant the same reinit path which you patched: This is too old for me to remember buit yes, there definitely was a bug there... > > @@ -1267,15 +1267,20 @@ static int tty_reopen(struct tty_struct *tty) > > if (test_bit(TTY_EXCLUSIVE, >flags) && !capable(CAP_SYS_ADMIN)) > > return -EBUSY; > > > > - tty->count++; > > + retval = tty_ldisc_lock(tty, 5 * HZ); > > + if (retval) > > + return retval; > > > > + tty->count++; > > if (tty->ldisc) > > - return 0; > > + goto out_unlock; > > > > retval = tty_ldisc_reinit(tty, tty->termios.c_line); > > if (retval) > > tty->count--; > > > > +out_unlock: > > + tty_ldisc_unlock(tty); > > return retval; > > } > > -ss
Re: [PATCH v1] arm64: dts: sdm845: enable tsens thermal zones
On Wed, Aug 29, 2018 at 3:09 PM Daniel Lezcano wrote: > > On 18/07/2018 09:49, Amit Kucheria wrote: > > One thermal zone per cpu is defined > > The thermal zones are very close, especially when the CPUs belong to the > same 'cluster'. Very likely the temperature will propagate from one core > to another core, so when one core reaches the trip0, there is good > chance the other cores will be close and cross the trip0 threshold too. Agreed. Once we have all the thermal and cpufreq bits in place, I'd like to examine optimisations such as a virtual sensor, using the coefficients to add weights, etc. > Having multiple thermal zones, one per CPU, may trigger an interrupts > storm with the passive polling timer delay. I'm working on irq support for tsens that should alleviate that. > Does this board have a cooling device per CPU also ? As Matthias mentioned, DVFS is per cluster (4 cpus to a cluster).
Re: [PATCH v1] arm64: dts: sdm845: enable tsens thermal zones
On Wed, Aug 29, 2018 at 3:09 PM Daniel Lezcano wrote: > > On 18/07/2018 09:49, Amit Kucheria wrote: > > One thermal zone per cpu is defined > > The thermal zones are very close, especially when the CPUs belong to the > same 'cluster'. Very likely the temperature will propagate from one core > to another core, so when one core reaches the trip0, there is good > chance the other cores will be close and cross the trip0 threshold too. Agreed. Once we have all the thermal and cpufreq bits in place, I'd like to examine optimisations such as a virtual sensor, using the coefficients to add weights, etc. > Having multiple thermal zones, one per CPU, may trigger an interrupts > storm with the passive polling timer delay. I'm working on irq support for tsens that should alleviate that. > Does this board have a cooling device per CPU also ? As Matthias mentioned, DVFS is per cluster (4 cpus to a cluster).
[PATCH] ARM: dts: imx6ull: update iomux header
Update i.MX6ULL iomux header according to latest reference manual Rev.1, 11/2017. Signed-off-by: Anson Huang --- arch/arm/boot/dts/imx6ull-pinfunc.h | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h b/arch/arm/boot/dts/imx6ull-pinfunc.h index 3c12a6f..a282a31 100644 --- a/arch/arm/boot/dts/imx6ull-pinfunc.h +++ b/arch/arm/boot/dts/imx6ull-pinfunc.h @@ -27,10 +27,25 @@ #define MX6UL_PAD_CSI_DATA02__UART5_DCE_RTS 0x01EC 0x0478 0x0640 0x8 0x7 /* signals for i.MX6ULL only */ +#define MX6ULL_PAD_UART1_TX_DATA__UART5_DCE_TX0x0084 0x0310 0x 0x9 0x0 #define MX6ULL_PAD_UART1_TX_DATA__UART5_DTE_RX0x0084 0x0310 0x0644 0x9 0x4 #define MX6ULL_PAD_UART1_RX_DATA__UART5_DCE_RX0x0088 0x0314 0x0644 0x9 0x5 -#define MX6ULL_PAD_UART1_CTS_B__UART5_DCE_RTS 0x008C 0x0318 0x0640 0x9 0x3 -#define MX6ULL_PAD_UART1_RTS_B__UART5_DTE_RTS 0x0090 0x031C 0x0640 0x9 0x4 +#define MX6ULL_PAD_UART1_RX_DATA__UART5_DTE_TX0x0088 0x0314 0x 0x9 0x0 +#define MX6ULL_PAD_UART1_CTS_B__UART5_DCE_CTS 0x008C 0x0318 0x 0x9 0x0 +#define MX6ULL_PAD_UART1_CTS_B__UART5_DTE_RTS 0x008C 0x0318 0x0640 0x9 0x3 +#define MX6ULL_PAD_UART1_RTS_B__UART5_DCE_RTS 0x0090 0x031C 0x0640 0x9 0x4 +#define MX6ULL_PAD_UART1_RTS_B__UART5_DTE_CTS 0x0090 0x031C 0x 0x9 0x0 +#define MX6ULL_PAD_UART4_RX_DATA__EPDC_PWRCTRL01 0x00B8 0x0344 0x 0x9 0x0 +#define MX6ULL_PAD_UART5_TX_DATA__EPDC_PWRCTRL02 0x00BC 0x0348 0x 0x9 0x0 +#define MX6ULL_PAD_UART5_RX_DATA__EPDC_PWRCTRL03 0x00C0 0x034C 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_RX_DATA0__EPDC_SDCE040x00C4 0x0350 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_RX_DATA1__EPDC_SDCE050x00C8 0x0354 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_RX_EN__EPDC_SDCE06 0x00CC 0x0358 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_TX_DATA0__EPDC_SDCE070x00D0 0x035C 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_TX_DATA1__EPDC_SDCE080x00D4 0x0360 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_TX_EN__EPDC_SDCE09 0x00D8 0x0364 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_TX_CLK__EPDC_SDOED 0x00DC 0x0368 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_RX_ER__EPDC_SDOEZ0x00E0 0x036C 0x 0x9 0x0 #define MX6ULL_PAD_ENET2_RX_DATA0__EPDC_SDDO080x00E4 0x0370 0x 0x9 0x0 #define MX6ULL_PAD_ENET2_RX_DATA1__EPDC_SDDO090x00E8 0x0374 0x 0x9 0x0 #define MX6ULL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC 0x0378 0x 0x9 0x0 @@ -57,6 +72,8 @@ #define MX6ULL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 0x03E4 0x 0x9 0x0 #define MX6ULL_PAD_LCD_DATA17__EPDC_GDSP 0x015C 0x03E8 0x 0x9 0x0 #define MX6ULL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C 0x03F8 0x 0x9 0x0 +#define MX6ULL_PAD_LCD_DATA22__EPDC_SDCE020x0170 0x03FC 0x 0x9 0x0 +#define MX6ULL_PAD_LCD_DATA23__EPDC_SDCE030x0174 0x0400 0x 0x9 0x0 #define MX6ULL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 0x0460 0x 0x9 0x0 #define MX6ULL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 0x0464 0x 0x9 0x0 #define MX6ULL_PAD_CSI_VSYNC__ESAI_TX4_RX10x01DC 0x0468 0x 0x9 0x0 -- 2.7.4
[PATCH] ARM: dts: imx6ull: update iomux header
Update i.MX6ULL iomux header according to latest reference manual Rev.1, 11/2017. Signed-off-by: Anson Huang --- arch/arm/boot/dts/imx6ull-pinfunc.h | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h b/arch/arm/boot/dts/imx6ull-pinfunc.h index 3c12a6f..a282a31 100644 --- a/arch/arm/boot/dts/imx6ull-pinfunc.h +++ b/arch/arm/boot/dts/imx6ull-pinfunc.h @@ -27,10 +27,25 @@ #define MX6UL_PAD_CSI_DATA02__UART5_DCE_RTS 0x01EC 0x0478 0x0640 0x8 0x7 /* signals for i.MX6ULL only */ +#define MX6ULL_PAD_UART1_TX_DATA__UART5_DCE_TX0x0084 0x0310 0x 0x9 0x0 #define MX6ULL_PAD_UART1_TX_DATA__UART5_DTE_RX0x0084 0x0310 0x0644 0x9 0x4 #define MX6ULL_PAD_UART1_RX_DATA__UART5_DCE_RX0x0088 0x0314 0x0644 0x9 0x5 -#define MX6ULL_PAD_UART1_CTS_B__UART5_DCE_RTS 0x008C 0x0318 0x0640 0x9 0x3 -#define MX6ULL_PAD_UART1_RTS_B__UART5_DTE_RTS 0x0090 0x031C 0x0640 0x9 0x4 +#define MX6ULL_PAD_UART1_RX_DATA__UART5_DTE_TX0x0088 0x0314 0x 0x9 0x0 +#define MX6ULL_PAD_UART1_CTS_B__UART5_DCE_CTS 0x008C 0x0318 0x 0x9 0x0 +#define MX6ULL_PAD_UART1_CTS_B__UART5_DTE_RTS 0x008C 0x0318 0x0640 0x9 0x3 +#define MX6ULL_PAD_UART1_RTS_B__UART5_DCE_RTS 0x0090 0x031C 0x0640 0x9 0x4 +#define MX6ULL_PAD_UART1_RTS_B__UART5_DTE_CTS 0x0090 0x031C 0x 0x9 0x0 +#define MX6ULL_PAD_UART4_RX_DATA__EPDC_PWRCTRL01 0x00B8 0x0344 0x 0x9 0x0 +#define MX6ULL_PAD_UART5_TX_DATA__EPDC_PWRCTRL02 0x00BC 0x0348 0x 0x9 0x0 +#define MX6ULL_PAD_UART5_RX_DATA__EPDC_PWRCTRL03 0x00C0 0x034C 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_RX_DATA0__EPDC_SDCE040x00C4 0x0350 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_RX_DATA1__EPDC_SDCE050x00C8 0x0354 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_RX_EN__EPDC_SDCE06 0x00CC 0x0358 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_TX_DATA0__EPDC_SDCE070x00D0 0x035C 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_TX_DATA1__EPDC_SDCE080x00D4 0x0360 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_TX_EN__EPDC_SDCE09 0x00D8 0x0364 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_TX_CLK__EPDC_SDOED 0x00DC 0x0368 0x 0x9 0x0 +#define MX6ULL_PAD_ENET1_RX_ER__EPDC_SDOEZ0x00E0 0x036C 0x 0x9 0x0 #define MX6ULL_PAD_ENET2_RX_DATA0__EPDC_SDDO080x00E4 0x0370 0x 0x9 0x0 #define MX6ULL_PAD_ENET2_RX_DATA1__EPDC_SDDO090x00E8 0x0374 0x 0x9 0x0 #define MX6ULL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC 0x0378 0x 0x9 0x0 @@ -57,6 +72,8 @@ #define MX6ULL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 0x03E4 0x 0x9 0x0 #define MX6ULL_PAD_LCD_DATA17__EPDC_GDSP 0x015C 0x03E8 0x 0x9 0x0 #define MX6ULL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C 0x03F8 0x 0x9 0x0 +#define MX6ULL_PAD_LCD_DATA22__EPDC_SDCE020x0170 0x03FC 0x 0x9 0x0 +#define MX6ULL_PAD_LCD_DATA23__EPDC_SDCE030x0174 0x0400 0x 0x9 0x0 #define MX6ULL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 0x0460 0x 0x9 0x0 #define MX6ULL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 0x0464 0x 0x9 0x0 #define MX6ULL_PAD_CSI_VSYNC__ESAI_TX4_RX10x01DC 0x0468 0x 0x9 0x0 -- 2.7.4
Re: [RFC PATCH 1/6] x86/alternative: assert text_mutex is taken
at 7:26 PM, Masami Hiramatsu wrote:
> On Wed, 29 Aug 2018 14:00:06 -0700
> Sean Christopherson wrote:
>
>> On Wed, Aug 29, 2018 at 08:44:47PM +, Nadav Amit wrote:
>>> at 1:13 PM, Sean Christopherson wrote:
>>>
On Wed, Aug 29, 2018 at 07:36:22PM +, Nadav Amit wrote:
> at 10:11 AM, Nadav Amit wrote:
>
>> at 1:59 AM, Masami Hiramatsu wrote:
>>
>>> On Wed, 29 Aug 2018 01:11:42 -0700
>>> Nadav Amit wrote:
>>>
Use lockdep to ensure that text_mutex is taken when text_poke() is
called.
Actually it is not always taken, specifically when it is called by
kgdb,
so take the lock in these cases.
>>>
>>> Can we really take a mutex in kgdb context?
>>>
>>> kgdb_arch_remove_breakpoint
>>> <- dbg_deactivate_sw_breakpoints
>>> <- kgdb_reenter_check
>>><- kgdb_handle_exception
>>> <- __kgdb_notify
>>> <- kgdb_ll_trap
>>> <- do_int3
>>> <- kgdb_notify
>>> <- die notifier
>>>
>>> kgdb_arch_set_breakpoint
>>> <- dbg_activate_sw_breakpoints
>>> <- kgdb_reenter_check
>>><- kgdb_handle_exception
>>>...
>>>
>>> Both seems called in exception context, so we can not take a mutex lock.
>>> I think kgdb needs a special path.
>>
>> You are correct, but I don’t want a special path. Presumably text_mutex
>> is
>> guaranteed not to be taken according to the code.
>>
>> So I guess the only concern is lockdep. Do you see any problem if I
>> change
>> mutex_lock() into mutex_trylock()? It should always succeed, and I can
>> add a
>> warning and a failure path if it fails for some reason.
>
> Err.. This will not work. I think I will drop this patch, since I cannot
> find a proper yet simple assertion. Creating special path just for the
> assertion seems wrong.
It's probably worth expanding the comment for text_poke() to call out
the kgdb case and reference kgdb_arch_{set,remove}_breakpoint(), whose
code and comments make it explicitly clear why its safe for them to
call text_poke() without acquiring the lock. Might prevent someone
from going down this path again in the future.
>>>
>>> I thought that the whole point of the patch was to avoid comments, and
>>> instead enforce the right behavior. I don’t understand well enough kgdb
>>> code, so I cannot attest it does the right thing. What happens if
>>> kgdb_do_roundup==0?
>>
>> As is, the comment is wrong because there are obviously cases where
>> text_poke() is called without text_mutex being held. I can't attest
>> to the kgdb code either. My thought was to document the exception so
>> that if someone does want to try and enforce the right behavior they
>> can dive right into the problem instead of having to learn of the kgdb
>> gotcha the hard way. Maybe a FIXME is the right approach?
>
> No, kgdb ensures that the text_mutex has not been held right before
> calling text_poke. So they also take care the text_mutex. I guess
> kgdb_arch_{set,remove}_breakpoint() is supposed to be run under
> a special circumstance, like stopping all other threads/cores.
> In that case, we can just check the text_mutex is not locked.
I assumed so too, but after looking at the code, I am not sure that this is
the case when gdb_do_roundup==0.
> Anyway, kgdb is a very rare courner case. I think if CONFIG_KGDB is
> enabled, lockdep and any assertion should be disabled, since kgdb
> can tweak anything in the kernel with unexpected ways...
Call me lazy, but I really do not want to debug syzkaller failures due to
this issue (now or in the future). If the assertion is known to be
incorrect, even in a corner case, I see no reason to have it and I certainly
do not want to be the one that added it…
Re: [RFC PATCH 1/6] x86/alternative: assert text_mutex is taken
at 7:26 PM, Masami Hiramatsu wrote:
> On Wed, 29 Aug 2018 14:00:06 -0700
> Sean Christopherson wrote:
>
>> On Wed, Aug 29, 2018 at 08:44:47PM +, Nadav Amit wrote:
>>> at 1:13 PM, Sean Christopherson wrote:
>>>
On Wed, Aug 29, 2018 at 07:36:22PM +, Nadav Amit wrote:
> at 10:11 AM, Nadav Amit wrote:
>
>> at 1:59 AM, Masami Hiramatsu wrote:
>>
>>> On Wed, 29 Aug 2018 01:11:42 -0700
>>> Nadav Amit wrote:
>>>
Use lockdep to ensure that text_mutex is taken when text_poke() is
called.
Actually it is not always taken, specifically when it is called by
kgdb,
so take the lock in these cases.
>>>
>>> Can we really take a mutex in kgdb context?
>>>
>>> kgdb_arch_remove_breakpoint
>>> <- dbg_deactivate_sw_breakpoints
>>> <- kgdb_reenter_check
>>><- kgdb_handle_exception
>>> <- __kgdb_notify
>>> <- kgdb_ll_trap
>>> <- do_int3
>>> <- kgdb_notify
>>> <- die notifier
>>>
>>> kgdb_arch_set_breakpoint
>>> <- dbg_activate_sw_breakpoints
>>> <- kgdb_reenter_check
>>><- kgdb_handle_exception
>>>...
>>>
>>> Both seems called in exception context, so we can not take a mutex lock.
>>> I think kgdb needs a special path.
>>
>> You are correct, but I don’t want a special path. Presumably text_mutex
>> is
>> guaranteed not to be taken according to the code.
>>
>> So I guess the only concern is lockdep. Do you see any problem if I
>> change
>> mutex_lock() into mutex_trylock()? It should always succeed, and I can
>> add a
>> warning and a failure path if it fails for some reason.
>
> Err.. This will not work. I think I will drop this patch, since I cannot
> find a proper yet simple assertion. Creating special path just for the
> assertion seems wrong.
It's probably worth expanding the comment for text_poke() to call out
the kgdb case and reference kgdb_arch_{set,remove}_breakpoint(), whose
code and comments make it explicitly clear why its safe for them to
call text_poke() without acquiring the lock. Might prevent someone
from going down this path again in the future.
>>>
>>> I thought that the whole point of the patch was to avoid comments, and
>>> instead enforce the right behavior. I don’t understand well enough kgdb
>>> code, so I cannot attest it does the right thing. What happens if
>>> kgdb_do_roundup==0?
>>
>> As is, the comment is wrong because there are obviously cases where
>> text_poke() is called without text_mutex being held. I can't attest
>> to the kgdb code either. My thought was to document the exception so
>> that if someone does want to try and enforce the right behavior they
>> can dive right into the problem instead of having to learn of the kgdb
>> gotcha the hard way. Maybe a FIXME is the right approach?
>
> No, kgdb ensures that the text_mutex has not been held right before
> calling text_poke. So they also take care the text_mutex. I guess
> kgdb_arch_{set,remove}_breakpoint() is supposed to be run under
> a special circumstance, like stopping all other threads/cores.
> In that case, we can just check the text_mutex is not locked.
I assumed so too, but after looking at the code, I am not sure that this is
the case when gdb_do_roundup==0.
> Anyway, kgdb is a very rare courner case. I think if CONFIG_KGDB is
> enabled, lockdep and any assertion should be disabled, since kgdb
> can tweak anything in the kernel with unexpected ways...
Call me lazy, but I really do not want to debug syzkaller failures due to
this issue (now or in the future). If the assertion is known to be
incorrect, even in a corner case, I see no reason to have it and I certainly
do not want to be the one that added it…
Re: [RFC] perf script: callchain handling is not useful
On Wed, Aug 29, 2018 at 5:33 PM Namhyung Kim wrote: > > Hi, > > On Wed, Aug 29, 2018 at 08:14:12AM -0700, Stephane Eranian wrote: > > On Wed, Aug 29, 2018 at 6:54 AM Arnaldo Carvalho de Melo > > wrote: > > > > > > Em Tue, Aug 28, 2018 at 07:41:31PM -0700, Stephane Eranian escreveu: > > > > Hi, > > > > > > > > I am doing the following simple collection with callchain and load > > > > profiling: > > > > > > > > $ perf record -g -d -e cpu/event=0xd0,umask=0x81/pp my_test_program > > > > > > > > But when I type: > > > > $ perf script -F ip,addr > > > > 9d4821346878 > > > > 9d58df25 > > > > 9d58e054 > > > > 9d5965bb > > > > 9d640650 > > > > 9d697d06 > > > > 9d63ec60 > > > > 9d640322 > > > > 9d64070c > > > > 9d455a60 > > > > 7030c7 > > > > > > > > 9d4638ba84a0 > > > > 9d5df447 > > > > 9d5eaf4a > > > > 9d63e165 > > > > 9d63e439 > > > > 9d697d98 > > > > 9d63ec60 > > > > 9d640322 > > > > 9d64070c > > > > 9d455a60 > > > > 7030c7 > > > > I also see the callchain and it is not clear which is the IP. Further > > > > more parsing becomes more difficult because of multiple lines per > > > > sample. I understand that multiline is likely because of > > > > symbolization. But if I don't want symbolization, it should be > > > > possible to print all in one line. > > > > > > Humm, to have this not break possibly existing scripts, perhaps we can > > > have something like: > > > > > > $ perf script -F ip,-callchain,addr > > > > > > ? > > > > > > And if asked explicitely for the callchain, then it gets added in the > > > same line? > > > > > Yeah, that should do it. > > Thanks. > > I found this: > > $ perf script -h |& grep -A1 hide > -G, --hide-call-graph > When printing symbols do not display call chain > Yes, I had found it too. But my problem is twofold: - ip should not include the callchain - callchain should be printed in a single line That would make things easier to parse. > Thanks, > Namhyung
Re: [RFC] perf script: callchain handling is not useful
On Wed, Aug 29, 2018 at 5:33 PM Namhyung Kim wrote: > > Hi, > > On Wed, Aug 29, 2018 at 08:14:12AM -0700, Stephane Eranian wrote: > > On Wed, Aug 29, 2018 at 6:54 AM Arnaldo Carvalho de Melo > > wrote: > > > > > > Em Tue, Aug 28, 2018 at 07:41:31PM -0700, Stephane Eranian escreveu: > > > > Hi, > > > > > > > > I am doing the following simple collection with callchain and load > > > > profiling: > > > > > > > > $ perf record -g -d -e cpu/event=0xd0,umask=0x81/pp my_test_program > > > > > > > > But when I type: > > > > $ perf script -F ip,addr > > > > 9d4821346878 > > > > 9d58df25 > > > > 9d58e054 > > > > 9d5965bb > > > > 9d640650 > > > > 9d697d06 > > > > 9d63ec60 > > > > 9d640322 > > > > 9d64070c > > > > 9d455a60 > > > > 7030c7 > > > > > > > > 9d4638ba84a0 > > > > 9d5df447 > > > > 9d5eaf4a > > > > 9d63e165 > > > > 9d63e439 > > > > 9d697d98 > > > > 9d63ec60 > > > > 9d640322 > > > > 9d64070c > > > > 9d455a60 > > > > 7030c7 > > > > I also see the callchain and it is not clear which is the IP. Further > > > > more parsing becomes more difficult because of multiple lines per > > > > sample. I understand that multiline is likely because of > > > > symbolization. But if I don't want symbolization, it should be > > > > possible to print all in one line. > > > > > > Humm, to have this not break possibly existing scripts, perhaps we can > > > have something like: > > > > > > $ perf script -F ip,-callchain,addr > > > > > > ? > > > > > > And if asked explicitely for the callchain, then it gets added in the > > > same line? > > > > > Yeah, that should do it. > > Thanks. > > I found this: > > $ perf script -h |& grep -A1 hide > -G, --hide-call-graph > When printing symbols do not display call chain > Yes, I had found it too. But my problem is twofold: - ip should not include the callchain - callchain should be printed in a single line That would make things easier to parse. > Thanks, > Namhyung
Re: [PATCH tip/core/rcu 0/52] Remove rcu_state pointers for v4.20/v5.0
On Wed, Aug 29, 2018 at 09:10:17PM -0700, Paul E. McKenney wrote: > On Wed, Aug 29, 2018 at 08:22:16PM -0700, Paul E. McKenney wrote: > > On Wed, Aug 29, 2018 at 10:00:26PM -0400, Steven Rostedt wrote: > > > On Wed, 29 Aug 2018 15:38:30 -0700 > > > "Paul E. McKenney" wrote: > > > > > > > Hello! > > > > > > > > This commit does RCU-consolidation cleanups that get rid of pointers to > > > > the sole remaining rcu_state structure: > > > > > > > > 1-40: Remove the "rsp" parameter from numerous functions, given that > > > > the corresponding argument will always be _state. > > > > > > Hmm, couldn't 1-40 have been made into a single patch? > > > > They could. I separated them to make finding the inevitable typos easier. > > But at this point, it is easy enough to squash them together, though. > > And please see below for what the resulting diff would look like. Is > this an improvement? Honestly, as long as the result after each commit compiles, I prefer the split version for ease of review.
Re: [PATCH tip/core/rcu 0/52] Remove rcu_state pointers for v4.20/v5.0
On Wed, Aug 29, 2018 at 09:10:17PM -0700, Paul E. McKenney wrote: > On Wed, Aug 29, 2018 at 08:22:16PM -0700, Paul E. McKenney wrote: > > On Wed, Aug 29, 2018 at 10:00:26PM -0400, Steven Rostedt wrote: > > > On Wed, 29 Aug 2018 15:38:30 -0700 > > > "Paul E. McKenney" wrote: > > > > > > > Hello! > > > > > > > > This commit does RCU-consolidation cleanups that get rid of pointers to > > > > the sole remaining rcu_state structure: > > > > > > > > 1-40: Remove the "rsp" parameter from numerous functions, given that > > > > the corresponding argument will always be _state. > > > > > > Hmm, couldn't 1-40 have been made into a single patch? > > > > They could. I separated them to make finding the inevitable typos easier. > > But at this point, it is easy enough to squash them together, though. > > And please see below for what the resulting diff would look like. Is > this an improvement? Honestly, as long as the result after each commit compiles, I prefer the split version for ease of review.
[PATCH 0/3] ARM: dts: am335x: add support for Moxa UC-2100 series
The UC-2100 series open computing platform is designed for industrial embedded
data acquisition and processing applications. In order to fulfill various
industrial applications, there're many boards with different peripheral
devices and wireless modules in this series.
The features of UC-2100 series are:
* eMMC
* SPI flash
* {1,2}x LAN (100/1000 Mbps in option)
* {1,2}x RS-232/422/485 ports, software-selectable
* EEPROM
* TPM 2.0
* Watchdog
* RTC
* User gpio-keys
* User LEDs
* User button
* GPS (option)
* 2x CANBus (option)
* Cellular module (option)
* Mini PCIe form factor with USB signal (option)
* MicroSD slot (option)
SZ Lin (林上智) (3):
ARM: dts: am335x: add common file for UC-2100 series
ARM: dts: am335x: add support for Moxa UC-2101 open platform
ARM: dts: am335x: add support for Moxa UC-2102 open platform
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile| 2 +
.../boot/dts/am335x-moxa-uc-2100-common.dtsi | 249 ++
arch/arm/boot/dts/am335x-moxa-uc-2101.dts | 63 +
arch/arm/boot/dts/am335x-moxa-uc-2102.dts | 200 ++
5 files changed, 517 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2101.dts
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2102.dts
--
2.19.0.rc1
[PATCH 1/3] ARM: dts: am335x: add common file for UC-2100 series
The UC-2100 series consists many boards with different peripheral
devices and wireless modules, hence we fetch common items and
create a common dtsi file to increase reusability. All boards in
UC-2100 series will include this common dtsi file.
Signed-off-by: Wes Huang (黃淵河)
Signed-off-by: Fero JD Zhou (周俊達)
Signed-off-by: SZ Lin (林上智)
---
.../boot/dts/am335x-moxa-uc-2100-common.dtsi | 249 ++
1 file changed, 249 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
diff --git a/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
b/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
new file mode 100644
index ..14f781953475
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MOXA Inc. - https://www.moxa.com/
+ *
+ * Authors: SZ Lin (林上智)
+ * Wes Huang (黃淵河)
+ * Fero JD Zhou (周俊達)
+ */
+
+#include "am33xx.dtsi"
+
+/ {
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ };
+
+ /* Power supply provides a fixed 3.3V @3A */
+ vmmcsd_fixed: vmmcsd-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcsd_fixed";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ };
+
+ buttons: push_button {
+ compatible = "gpio-keys";
+ };
+};
+
+_pinmux {
+ pinctrl-names = "default";
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x988, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c0_sda.i2c0_sda */
+ AM33XX_IOPAD(0x98c, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c0_scl.i2c0_scl */
+ >;
+ };
+
+ push_button_pins: pinmux_push_button {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8e4, PIN_INPUT_PULLDOWN | MUX_MODE7)
/* lcd_hsync.gpio2_23 */
+ >;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)
/* uart0_rxd.uart0_rxd */
+ AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
/* uart0_txd.uart0_txd */
+ >;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins = <
+ /* MDIO */
+ AM33XX_IOPAD(0x948, PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0) /* mdio_data.mdio_data */
+ AM33XX_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ >;
+ };
+
+ mmc1_pins_default: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ /* eMMC */
+ AM33XX_IOPAD(0x800, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad12.mmc1_dat0 */
+ AM33XX_IOPAD(0x804, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad13.mmc1_dat1 */
+ AM33XX_IOPAD(0x808, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad14.mmc1_dat2 */
+ AM33XX_IOPAD(0x80c, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad15.mmc1_dat3 */
+ AM33XX_IOPAD(0x810, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad8.mmc1_dat4 */
+ AM33XX_IOPAD(0x814, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad9.mmc1_dat5 */
+ AM33XX_IOPAD(0x818, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad10.mmc1_dat6 */
+ AM33XX_IOPAD(0x81c, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad11.mmc1_dat7 */
+ AM33XX_IOPAD(0x884, PIN_INPUT_PULLUP | MUX_MODE2)
/* gpmc_csn2.mmc1_cmd */
+ AM33XX_IOPAD(0x880, PIN_INPUT_PULLUP | MUX_MODE2)
/* gpmc_csn1.mmc1_clk */
+ >;
+ };
+
+ spi0_pins: pinmux_spi0 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x950, PIN_INPUT_PULLUP | MUX_MODE0)
/* spi0_sclk.spi0_sclk */
+ AM33XX_IOPAD(0x95c, PIN_INPUT_PULLUP | MUX_MODE0)
/* spi0_cs0.spi0_cs0 */
+ AM33XX_IOPAD(0x954, PIN_INPUT_PULLUP | MUX_MODE0)
/* spi0_d0.spi0_d0 */
+ AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP | MUX_MODE0)
/* spi0_d1.spi0_d1 */
+ >;
+ };
+};
+
+ {
+ /* Console */
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+ clock-frequency = <40>;
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c16";
+ pagesize = <16>;
+ reg = <0x50>;
+
[PATCH 0/3] ARM: dts: am335x: add support for Moxa UC-2100 series
The UC-2100 series open computing platform is designed for industrial embedded
data acquisition and processing applications. In order to fulfill various
industrial applications, there're many boards with different peripheral
devices and wireless modules in this series.
The features of UC-2100 series are:
* eMMC
* SPI flash
* {1,2}x LAN (100/1000 Mbps in option)
* {1,2}x RS-232/422/485 ports, software-selectable
* EEPROM
* TPM 2.0
* Watchdog
* RTC
* User gpio-keys
* User LEDs
* User button
* GPS (option)
* 2x CANBus (option)
* Cellular module (option)
* Mini PCIe form factor with USB signal (option)
* MicroSD slot (option)
SZ Lin (林上智) (3):
ARM: dts: am335x: add common file for UC-2100 series
ARM: dts: am335x: add support for Moxa UC-2101 open platform
ARM: dts: am335x: add support for Moxa UC-2102 open platform
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile| 2 +
.../boot/dts/am335x-moxa-uc-2100-common.dtsi | 249 ++
arch/arm/boot/dts/am335x-moxa-uc-2101.dts | 63 +
arch/arm/boot/dts/am335x-moxa-uc-2102.dts | 200 ++
5 files changed, 517 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2101.dts
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2102.dts
--
2.19.0.rc1
[PATCH 1/3] ARM: dts: am335x: add common file for UC-2100 series
The UC-2100 series consists many boards with different peripheral
devices and wireless modules, hence we fetch common items and
create a common dtsi file to increase reusability. All boards in
UC-2100 series will include this common dtsi file.
Signed-off-by: Wes Huang (黃淵河)
Signed-off-by: Fero JD Zhou (周俊達)
Signed-off-by: SZ Lin (林上智)
---
.../boot/dts/am335x-moxa-uc-2100-common.dtsi | 249 ++
1 file changed, 249 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
diff --git a/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
b/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
new file mode 100644
index ..14f781953475
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MOXA Inc. - https://www.moxa.com/
+ *
+ * Authors: SZ Lin (林上智)
+ * Wes Huang (黃淵河)
+ * Fero JD Zhou (周俊達)
+ */
+
+#include "am33xx.dtsi"
+
+/ {
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ };
+
+ /* Power supply provides a fixed 3.3V @3A */
+ vmmcsd_fixed: vmmcsd-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcsd_fixed";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ };
+
+ buttons: push_button {
+ compatible = "gpio-keys";
+ };
+};
+
+_pinmux {
+ pinctrl-names = "default";
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x988, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c0_sda.i2c0_sda */
+ AM33XX_IOPAD(0x98c, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c0_scl.i2c0_scl */
+ >;
+ };
+
+ push_button_pins: pinmux_push_button {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8e4, PIN_INPUT_PULLDOWN | MUX_MODE7)
/* lcd_hsync.gpio2_23 */
+ >;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)
/* uart0_rxd.uart0_rxd */
+ AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
/* uart0_txd.uart0_txd */
+ >;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins = <
+ /* MDIO */
+ AM33XX_IOPAD(0x948, PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0) /* mdio_data.mdio_data */
+ AM33XX_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ >;
+ };
+
+ mmc1_pins_default: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ /* eMMC */
+ AM33XX_IOPAD(0x800, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad12.mmc1_dat0 */
+ AM33XX_IOPAD(0x804, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad13.mmc1_dat1 */
+ AM33XX_IOPAD(0x808, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad14.mmc1_dat2 */
+ AM33XX_IOPAD(0x80c, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad15.mmc1_dat3 */
+ AM33XX_IOPAD(0x810, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad8.mmc1_dat4 */
+ AM33XX_IOPAD(0x814, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad9.mmc1_dat5 */
+ AM33XX_IOPAD(0x818, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad10.mmc1_dat6 */
+ AM33XX_IOPAD(0x81c, PIN_INPUT_PULLUP | MUX_MODE1)
/* gpmc_ad11.mmc1_dat7 */
+ AM33XX_IOPAD(0x884, PIN_INPUT_PULLUP | MUX_MODE2)
/* gpmc_csn2.mmc1_cmd */
+ AM33XX_IOPAD(0x880, PIN_INPUT_PULLUP | MUX_MODE2)
/* gpmc_csn1.mmc1_clk */
+ >;
+ };
+
+ spi0_pins: pinmux_spi0 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x950, PIN_INPUT_PULLUP | MUX_MODE0)
/* spi0_sclk.spi0_sclk */
+ AM33XX_IOPAD(0x95c, PIN_INPUT_PULLUP | MUX_MODE0)
/* spi0_cs0.spi0_cs0 */
+ AM33XX_IOPAD(0x954, PIN_INPUT_PULLUP | MUX_MODE0)
/* spi0_d0.spi0_d0 */
+ AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP | MUX_MODE0)
/* spi0_d1.spi0_d1 */
+ >;
+ };
+};
+
+ {
+ /* Console */
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+ clock-frequency = <40>;
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c16";
+ pagesize = <16>;
+ reg = <0x50>;
+
Re: [PATCH tip/core/rcu 0/52] Remove rcu_state pointers for v4.20/v5.0
On Wed, Aug 29, 2018 at 08:22:16PM -0700, Paul E. McKenney wrote:
> On Wed, Aug 29, 2018 at 10:00:26PM -0400, Steven Rostedt wrote:
> > On Wed, 29 Aug 2018 15:38:30 -0700
> > "Paul E. McKenney" wrote:
> >
> > > Hello!
> > >
> > > This commit does RCU-consolidation cleanups that get rid of pointers to
> > > the sole remaining rcu_state structure:
> > >
> > > 1-40: Remove the "rsp" parameter from numerous functions, given that
> > > the corresponding argument will always be _state.
> >
> > Hmm, couldn't 1-40 have been made into a single patch?
>
> They could. I separated them to make finding the inevitable typos easier.
> But at this point, it is easy enough to squash them together, though.
And please see below for what the resulting diff would look like. Is
this an improvement?
Thanx, Paul
diff --git a/Documentation/RCU/Design/Data-Structures/Data-Structures.html
b/Documentation/RCU/Design/Data-Structures/Data-Structures.html
index f5120a00f511..772c26a3865a 100644
--- a/Documentation/RCU/Design/Data-Structures/Data-Structures.html
+++ b/Documentation/RCU/Design/Data-Structures/Data-Structures.html
@@ -1372,8 +1372,7 @@ that is, if the CPU is currently idle.
Accessor Functions
The following listing shows the
-rcu_get_root(), rcu_for_each_node_breadth_first,
-rcu_for_each_nonleaf_node_breadth_first(), and
+rcu_get_root(), rcu_for_each_node_breadth_first and
rcu_for_each_leaf_node() function and macros:
@@ -1386,13 +1385,9 @@ Accessor Functions
7 for ((rnp) = (rsp)-node[0]; \
8(rnp) (rsp)-node[NUM_RCU_NODES]; (rnp)++)
9
- 10 #define rcu_for_each_nonleaf_node_breadth_first(rsp, rnp) \
- 11 for ((rnp) = (rsp)-node[0]; \
- 12(rnp) (rsp)-level[NUM_RCU_LVLS - 1]; (rnp)++)
- 13
- 14 #define rcu_for_each_leaf_node(rsp, rnp) \
- 15 for ((rnp) = (rsp)-level[NUM_RCU_LVLS - 1]; \
- 16(rnp) (rsp)-node[NUM_RCU_NODES]; (rnp)++)
+ 10 #define rcu_for_each_leaf_node(rsp, rnp) \
+ 11 for ((rnp) = (rsp)-level[NUM_RCU_LVLS - 1]; \
+ 12(rnp) (rsp)-node[NUM_RCU_NODES]; (rnp)++)
The rcu_get_root() simply returns a pointer to the
@@ -1405,10 +1400,7 @@ macro takes advantage of the layout of the
rcu_node
structures in the rcu_state structure's
-node[] array, performing a breadth-first traversal by
simply traversing the array in order.
-The rcu_for_each_nonleaf_node_breadth_first() macro operates
-similarly, but traverses only the first part of the array, thus excluding
-the leaf rcu_node structures.
-Finally, the rcu_for_each_leaf_node() macro traverses only
+Similarly, the rcu_for_each_leaf_node() macro traverses only
the last part of the array, thus traversing only the leaf
rcu_node structures.
@@ -1416,15 +1408,14 @@ the last part of the array, thus traversing only the
leaf
Quick Quiz:
- What do rcu_for_each_nonleaf_node_breadth_first() and
+ What does
rcu_for_each_leaf_node() do if the rcu_node tree
contains only a single node?
Answer:
In the single-node case,
- rcu_for_each_nonleaf_node_breadth_first() is a no-op
- and rcu_for_each_leaf_node() traverses the single node.
+ rcu_for_each_leaf_node() traverses the single node.
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 4d04683c31b2..2bb77fddc11f 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -329,29 +329,23 @@ static inline void rcu_init_levelspread(int *levelspread,
const int *levelcnt)
}
/* Returns first leaf rcu_node of the specified RCU flavor. */
-#define rcu_first_leaf_node(rsp) ((rsp)->level[rcu_num_lvls - 1])
+#define rcu_first_leaf_node() (rcu_state.level[rcu_num_lvls - 1])
/* Is this rcu_node a leaf? */
#define rcu_is_leaf_node(rnp) ((rnp)->level == rcu_num_lvls - 1)
/* Is this rcu_node the last leaf? */
-#define rcu_is_last_leaf_node(rsp, rnp) ((rnp) == &(rsp)->node[rcu_num_nodes -
1])
+#define rcu_is_last_leaf_node(rnp) ((rnp) == _state.node[rcu_num_nodes -
1])
/*
- * Do a full breadth-first scan of the rcu_node structures for the
+ * Do a full breadth-first scan of the {s,}rcu_node structures for the
* specified rcu_state structure.
*/
-#define rcu_for_each_node_breadth_first(rsp, rnp) \
- for ((rnp) = &(rsp)->node[0]; \
-(rnp) < &(rsp)->node[rcu_num_nodes]; (rnp)++)
-
-/*
- * Do a breadth-first scan of the non-leaf rcu_node structures for the
- * specified rcu_state structure. Note that if there is a singleton
- * rcu_node tree with but one rcu_node structure, this loop is a no-op.
- */
-#define rcu_for_each_nonleaf_node_breadth_first(rsp, rnp) \
- for ((rnp) = &(rsp)->node[0]; !rcu_is_leaf_node(rsp, rnp); (rnp)++)
+#define srcu_for_each_node_breadth_first(sp, rnp) \
+ for ((rnp) = &(sp)->node[0]; \
+(rnp) < &(sp)->node[rcu_num_nodes]; (rnp)++)
+#define rcu_for_each_node_breadth_first(rnp) \
+
Re: [PATCH tip/core/rcu 0/52] Remove rcu_state pointers for v4.20/v5.0
On Wed, Aug 29, 2018 at 08:22:16PM -0700, Paul E. McKenney wrote:
> On Wed, Aug 29, 2018 at 10:00:26PM -0400, Steven Rostedt wrote:
> > On Wed, 29 Aug 2018 15:38:30 -0700
> > "Paul E. McKenney" wrote:
> >
> > > Hello!
> > >
> > > This commit does RCU-consolidation cleanups that get rid of pointers to
> > > the sole remaining rcu_state structure:
> > >
> > > 1-40: Remove the "rsp" parameter from numerous functions, given that
> > > the corresponding argument will always be _state.
> >
> > Hmm, couldn't 1-40 have been made into a single patch?
>
> They could. I separated them to make finding the inevitable typos easier.
> But at this point, it is easy enough to squash them together, though.
And please see below for what the resulting diff would look like. Is
this an improvement?
Thanx, Paul
diff --git a/Documentation/RCU/Design/Data-Structures/Data-Structures.html
b/Documentation/RCU/Design/Data-Structures/Data-Structures.html
index f5120a00f511..772c26a3865a 100644
--- a/Documentation/RCU/Design/Data-Structures/Data-Structures.html
+++ b/Documentation/RCU/Design/Data-Structures/Data-Structures.html
@@ -1372,8 +1372,7 @@ that is, if the CPU is currently idle.
Accessor Functions
The following listing shows the
-rcu_get_root(), rcu_for_each_node_breadth_first,
-rcu_for_each_nonleaf_node_breadth_first(), and
+rcu_get_root(), rcu_for_each_node_breadth_first and
rcu_for_each_leaf_node() function and macros:
@@ -1386,13 +1385,9 @@ Accessor Functions
7 for ((rnp) = (rsp)-node[0]; \
8(rnp) (rsp)-node[NUM_RCU_NODES]; (rnp)++)
9
- 10 #define rcu_for_each_nonleaf_node_breadth_first(rsp, rnp) \
- 11 for ((rnp) = (rsp)-node[0]; \
- 12(rnp) (rsp)-level[NUM_RCU_LVLS - 1]; (rnp)++)
- 13
- 14 #define rcu_for_each_leaf_node(rsp, rnp) \
- 15 for ((rnp) = (rsp)-level[NUM_RCU_LVLS - 1]; \
- 16(rnp) (rsp)-node[NUM_RCU_NODES]; (rnp)++)
+ 10 #define rcu_for_each_leaf_node(rsp, rnp) \
+ 11 for ((rnp) = (rsp)-level[NUM_RCU_LVLS - 1]; \
+ 12(rnp) (rsp)-node[NUM_RCU_NODES]; (rnp)++)
The rcu_get_root() simply returns a pointer to the
@@ -1405,10 +1400,7 @@ macro takes advantage of the layout of the
rcu_node
structures in the rcu_state structure's
-node[] array, performing a breadth-first traversal by
simply traversing the array in order.
-The rcu_for_each_nonleaf_node_breadth_first() macro operates
-similarly, but traverses only the first part of the array, thus excluding
-the leaf rcu_node structures.
-Finally, the rcu_for_each_leaf_node() macro traverses only
+Similarly, the rcu_for_each_leaf_node() macro traverses only
the last part of the array, thus traversing only the leaf
rcu_node structures.
@@ -1416,15 +1408,14 @@ the last part of the array, thus traversing only the
leaf
Quick Quiz:
- What do rcu_for_each_nonleaf_node_breadth_first() and
+ What does
rcu_for_each_leaf_node() do if the rcu_node tree
contains only a single node?
Answer:
In the single-node case,
- rcu_for_each_nonleaf_node_breadth_first() is a no-op
- and rcu_for_each_leaf_node() traverses the single node.
+ rcu_for_each_leaf_node() traverses the single node.
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 4d04683c31b2..2bb77fddc11f 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -329,29 +329,23 @@ static inline void rcu_init_levelspread(int *levelspread,
const int *levelcnt)
}
/* Returns first leaf rcu_node of the specified RCU flavor. */
-#define rcu_first_leaf_node(rsp) ((rsp)->level[rcu_num_lvls - 1])
+#define rcu_first_leaf_node() (rcu_state.level[rcu_num_lvls - 1])
/* Is this rcu_node a leaf? */
#define rcu_is_leaf_node(rnp) ((rnp)->level == rcu_num_lvls - 1)
/* Is this rcu_node the last leaf? */
-#define rcu_is_last_leaf_node(rsp, rnp) ((rnp) == &(rsp)->node[rcu_num_nodes -
1])
+#define rcu_is_last_leaf_node(rnp) ((rnp) == _state.node[rcu_num_nodes -
1])
/*
- * Do a full breadth-first scan of the rcu_node structures for the
+ * Do a full breadth-first scan of the {s,}rcu_node structures for the
* specified rcu_state structure.
*/
-#define rcu_for_each_node_breadth_first(rsp, rnp) \
- for ((rnp) = &(rsp)->node[0]; \
-(rnp) < &(rsp)->node[rcu_num_nodes]; (rnp)++)
-
-/*
- * Do a breadth-first scan of the non-leaf rcu_node structures for the
- * specified rcu_state structure. Note that if there is a singleton
- * rcu_node tree with but one rcu_node structure, this loop is a no-op.
- */
-#define rcu_for_each_nonleaf_node_breadth_first(rsp, rnp) \
- for ((rnp) = &(rsp)->node[0]; !rcu_is_leaf_node(rsp, rnp); (rnp)++)
+#define srcu_for_each_node_breadth_first(sp, rnp) \
+ for ((rnp) = &(sp)->node[0]; \
+(rnp) < &(sp)->node[rcu_num_nodes]; (rnp)++)
+#define rcu_for_each_node_breadth_first(rnp) \
+
[PATCH 2/3] ARM: dts: am335x: add support for Moxa UC-2101 open platform
Add support for Moxa UC-2101 open platform
The UC-2101 computing platform is designed for industrial embedded
data acquisition and processing applications.
The features of UC-2101 are:
* eMMC
* SPI flash
* 1x LAN
* 1x RS-232/422/485 ports, software-selectable
* EEPROM
* TPM 2.0
* Watchdog
* RTC
* User gpio-keys
* User LEDs
* User button
Signed-off-by: Wes Huang (黃淵河)
Signed-off-by: Fero JD Zhou (周俊達)
Signed-off-by: SZ Lin (林上智)
---
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-moxa-uc-2101.dts | 63 +++
3 files changed, 67 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2101.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 2ecc712bf707..c5ca3d6a8099 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -157,6 +157,9 @@ Boards:
- AM335X phyCORE-AM335x: Development kit
compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som",
"ti,am33xx"
+- AM335X UC-2100: Wireless-enabled palm-sized industrial computing platform
+ compatible = "moxa,uc-2101", "ti,am33xx"
+
- AM335X UC-8100-ME-T: Communication-centric industrial computing platform
compatible = "moxa,uc-8100-me-t", "ti,am33xx";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b5bd3de87c33..6167c068601c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -706,6 +706,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-evmsk.dtb \
am335x-icev2.dtb \
am335x-lxm.dtb \
+ am335x-moxa-uc-2101.dtb \
am335x-moxa-uc-8100-me-t.dtb \
am335x-nano.dtb \
am335x-pdu001.dtb \
diff --git a/arch/arm/boot/dts/am335x-moxa-uc-2101.dts
b/arch/arm/boot/dts/am335x-moxa-uc-2101.dts
new file mode 100644
index ..d0c1eea4a6c9
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-moxa-uc-2101.dts
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MOXA Inc. - https://www.moxa.com/
+ *
+ * Authors: SZ Lin (林上智)
+ * Wes Huang (黃淵河)
+ * Fero JD Zhou (周俊達)
+ */
+
+/dts-v1/;
+
+#include "am335x-moxa-uc-2100-common.dtsi"
+
+/ {
+ model = "Moxa UC-2101";
+ compatible = "moxa,uc-2101", "ti,am33xx";
+
+ leds {
+ compatible = "gpio-leds";
+ led1 {
+ label = "UC2100:GREEN:USER";
+ gpios = < 10 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+};
+
+_pinmux {
+ pinctrl-names = "default";
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ AM33XX_IOPAD(0x90c, PIN_INPUT_PULLDOWN | MUX_MODE1)
/* mii1_crs.rmii1_crs_dv */
+ AM33XX_IOPAD(0x910, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxerr.rmii1_rxerr */
+ AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txen.rmii1_txen */
+ AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd1.rmii1_txd1 */
+ AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd0.rmii1_txd0 */
+ AM33XX_IOPAD(0x93c, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd1.rmii1_rxd1 */
+ AM33XX_IOPAD(0x940, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd0.rmii1_rxd0 */
+ AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE0)
/* mii1_refclk.rmii1_refclk */
+ >;
+ };
+
+ spi1_pins: pinmux_spi1 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x964, PIN_INPUT_PULLUP | MUX_MODE4)
/* ecap0_in_pwm0_out.spi1_sclk */
+ AM33XX_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE4)
/* uart1_ctsn.spi1_cs0 */
+ AM33XX_IOPAD(0x968, PIN_INPUT_PULLUP | MUX_MODE4)
/* uart0_ctsn.spi1_d0 */
+ AM33XX_IOPAD(0x96c, PIN_INPUT_PULLUP | MUX_MODE4)
/* uart0_rtsn.spi1_d1 */
+ >;
+ };
+};
+
+_emac0 {
+ status = "okay";
+ phy_id = <_mdio>, <0x4>;
+ phy-mode = "rmii";
+};
+
+_emac1 {
+ status = "disable";
+};
--
2.19.0.rc1
[PATCH 3/3] ARM: dts: am335x: add support for Moxa UC-2102 open platform
Add support for Moxa UC-2102 open platform
The UC-2102 computing platform is designed for industrial embedded
data acquisition and processing applications.
The features of UC-2102 are:
* eMMC
* SPI flash
* 2x LAN
* EEPROM
* TPM 2.0
* Watchdog
* RTC
* User gpio-keys
* User LEDs
* User button
Signed-off-by: Wes Huang (黃淵河)
Signed-off-by: Fero JD Zhou (周俊達)
Signed-off-by: SZ Lin (林上智)
---
.../devicetree/bindings/arm/omap/omap.txt | 2 +-
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-moxa-uc-2102.dts | 200 ++
3 files changed, 202 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2102.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index c5ca3d6a8099..6876eb8263ed 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -158,7 +158,7 @@ Boards:
compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som",
"ti,am33xx"
- AM335X UC-2100: Wireless-enabled palm-sized industrial computing platform
- compatible = "moxa,uc-2101", "ti,am33xx"
+ compatible = "moxa,uc-2101", "moxa,uc-2102", "ti,am33xx"
- AM335X UC-8100-ME-T: Communication-centric industrial computing platform
compatible = "moxa,uc-8100-me-t", "ti,am33xx";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6167c068601c..15d52cabb1a0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -707,6 +707,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-icev2.dtb \
am335x-lxm.dtb \
am335x-moxa-uc-2101.dtb \
+ am335x-moxa-uc-2102.dtb \
am335x-moxa-uc-8100-me-t.dtb \
am335x-nano.dtb \
am335x-pdu001.dtb \
diff --git a/arch/arm/boot/dts/am335x-moxa-uc-2102.dts
b/arch/arm/boot/dts/am335x-moxa-uc-2102.dts
new file mode 100644
index ..94a7ecc9eb9a
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-moxa-uc-2102.dts
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MOXA Inc. - https://www.moxa.com/
+ *
+ * Authors: SZ Lin (林上智)
+ * Wes Huang (黃淵河)
+ * Fero JD Zhou (周俊達)
+ */
+
+/dts-v1/;
+
+#include "am335x-moxa-uc-2100-common.dtsi"
+
+/ {
+ model = "Moxa UC-2102";
+ compatible = "moxa,uc-2102", "ti,am33xx";
+
+ leds {
+ compatible = "gpio-leds";
+ led1 {
+ label = "UC2100:GREEN:USER1";
+ gpios = < 16 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led2 {
+ label = "UC2100:GREEN:USER2";
+ gpios = < 17 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+};
+
+_pinmux {
+ pinctrl-names = "default";
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ AM33XX_IOPAD(0x90c, PIN_INPUT_PULLDOWN | MUX_MODE1)
/* mii1_crs.rmii1_crs_dv */
+ AM33XX_IOPAD(0x910, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxerr.rmii1_rxerr */
+ AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txen.rmii1_txen */
+ AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd1.rmii1_txd1 */
+ AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd0.rmii1_txd0 */
+ AM33XX_IOPAD(0x93c, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd1.rmii1_rxd1 */
+ AM33XX_IOPAD(0x940, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd0.rmii1_rxd0 */
+ AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE0)
/* mii1_refclk.rmii1_refclk */
+
+ /* Slave 2 */
+ AM33XX_IOPAD(0x870, PIN_INPUT_PULLDOWN | MUX_MODE3)
/* gpmc_wait0.rmii2_crs_dv */
+ AM33XX_IOPAD(0x874, PIN_INPUT_PULLDOWN | MUX_MODE3)
/* gpmc_wpn.rmii2_rxer */
+ AM33XX_IOPAD(0x840, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a0.rmii2_txen */
+ AM33XX_IOPAD(0x854, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a5.rmii2_td0 */
+ AM33XX_IOPAD(0x850, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a4.rmii2_td1 */
+ AM33XX_IOPAD(0x86c, PIN_INPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a11.rmii2_rd0 */
+ AM33XX_IOPAD(0x868, PIN_INPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a10.rmii2_rd1 */
+ AM33XX_IOPAD(0x908, PIN_INPUT_PULLDOWN | MUX_MODE1)
/* gmii1_col.rmii2_refclk */
+ >;
+ };
+
+ mmc0_pins_default: pinmux_mmc0_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8f0, PIN_INPUT_PULLUP |
[PATCH 2/3] ARM: dts: am335x: add support for Moxa UC-2101 open platform
Add support for Moxa UC-2101 open platform
The UC-2101 computing platform is designed for industrial embedded
data acquisition and processing applications.
The features of UC-2101 are:
* eMMC
* SPI flash
* 1x LAN
* 1x RS-232/422/485 ports, software-selectable
* EEPROM
* TPM 2.0
* Watchdog
* RTC
* User gpio-keys
* User LEDs
* User button
Signed-off-by: Wes Huang (黃淵河)
Signed-off-by: Fero JD Zhou (周俊達)
Signed-off-by: SZ Lin (林上智)
---
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-moxa-uc-2101.dts | 63 +++
3 files changed, 67 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2101.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 2ecc712bf707..c5ca3d6a8099 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -157,6 +157,9 @@ Boards:
- AM335X phyCORE-AM335x: Development kit
compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som",
"ti,am33xx"
+- AM335X UC-2100: Wireless-enabled palm-sized industrial computing platform
+ compatible = "moxa,uc-2101", "ti,am33xx"
+
- AM335X UC-8100-ME-T: Communication-centric industrial computing platform
compatible = "moxa,uc-8100-me-t", "ti,am33xx";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b5bd3de87c33..6167c068601c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -706,6 +706,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-evmsk.dtb \
am335x-icev2.dtb \
am335x-lxm.dtb \
+ am335x-moxa-uc-2101.dtb \
am335x-moxa-uc-8100-me-t.dtb \
am335x-nano.dtb \
am335x-pdu001.dtb \
diff --git a/arch/arm/boot/dts/am335x-moxa-uc-2101.dts
b/arch/arm/boot/dts/am335x-moxa-uc-2101.dts
new file mode 100644
index ..d0c1eea4a6c9
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-moxa-uc-2101.dts
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MOXA Inc. - https://www.moxa.com/
+ *
+ * Authors: SZ Lin (林上智)
+ * Wes Huang (黃淵河)
+ * Fero JD Zhou (周俊達)
+ */
+
+/dts-v1/;
+
+#include "am335x-moxa-uc-2100-common.dtsi"
+
+/ {
+ model = "Moxa UC-2101";
+ compatible = "moxa,uc-2101", "ti,am33xx";
+
+ leds {
+ compatible = "gpio-leds";
+ led1 {
+ label = "UC2100:GREEN:USER";
+ gpios = < 10 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+};
+
+_pinmux {
+ pinctrl-names = "default";
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ AM33XX_IOPAD(0x90c, PIN_INPUT_PULLDOWN | MUX_MODE1)
/* mii1_crs.rmii1_crs_dv */
+ AM33XX_IOPAD(0x910, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxerr.rmii1_rxerr */
+ AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txen.rmii1_txen */
+ AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd1.rmii1_txd1 */
+ AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd0.rmii1_txd0 */
+ AM33XX_IOPAD(0x93c, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd1.rmii1_rxd1 */
+ AM33XX_IOPAD(0x940, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd0.rmii1_rxd0 */
+ AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE0)
/* mii1_refclk.rmii1_refclk */
+ >;
+ };
+
+ spi1_pins: pinmux_spi1 {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x964, PIN_INPUT_PULLUP | MUX_MODE4)
/* ecap0_in_pwm0_out.spi1_sclk */
+ AM33XX_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE4)
/* uart1_ctsn.spi1_cs0 */
+ AM33XX_IOPAD(0x968, PIN_INPUT_PULLUP | MUX_MODE4)
/* uart0_ctsn.spi1_d0 */
+ AM33XX_IOPAD(0x96c, PIN_INPUT_PULLUP | MUX_MODE4)
/* uart0_rtsn.spi1_d1 */
+ >;
+ };
+};
+
+_emac0 {
+ status = "okay";
+ phy_id = <_mdio>, <0x4>;
+ phy-mode = "rmii";
+};
+
+_emac1 {
+ status = "disable";
+};
--
2.19.0.rc1
[PATCH 3/3] ARM: dts: am335x: add support for Moxa UC-2102 open platform
Add support for Moxa UC-2102 open platform
The UC-2102 computing platform is designed for industrial embedded
data acquisition and processing applications.
The features of UC-2102 are:
* eMMC
* SPI flash
* 2x LAN
* EEPROM
* TPM 2.0
* Watchdog
* RTC
* User gpio-keys
* User LEDs
* User button
Signed-off-by: Wes Huang (黃淵河)
Signed-off-by: Fero JD Zhou (周俊達)
Signed-off-by: SZ Lin (林上智)
---
.../devicetree/bindings/arm/omap/omap.txt | 2 +-
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-moxa-uc-2102.dts | 200 ++
3 files changed, 202 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-moxa-uc-2102.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index c5ca3d6a8099..6876eb8263ed 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -158,7 +158,7 @@ Boards:
compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som",
"ti,am33xx"
- AM335X UC-2100: Wireless-enabled palm-sized industrial computing platform
- compatible = "moxa,uc-2101", "ti,am33xx"
+ compatible = "moxa,uc-2101", "moxa,uc-2102", "ti,am33xx"
- AM335X UC-8100-ME-T: Communication-centric industrial computing platform
compatible = "moxa,uc-8100-me-t", "ti,am33xx";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6167c068601c..15d52cabb1a0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -707,6 +707,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-icev2.dtb \
am335x-lxm.dtb \
am335x-moxa-uc-2101.dtb \
+ am335x-moxa-uc-2102.dtb \
am335x-moxa-uc-8100-me-t.dtb \
am335x-nano.dtb \
am335x-pdu001.dtb \
diff --git a/arch/arm/boot/dts/am335x-moxa-uc-2102.dts
b/arch/arm/boot/dts/am335x-moxa-uc-2102.dts
new file mode 100644
index ..94a7ecc9eb9a
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-moxa-uc-2102.dts
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MOXA Inc. - https://www.moxa.com/
+ *
+ * Authors: SZ Lin (林上智)
+ * Wes Huang (黃淵河)
+ * Fero JD Zhou (周俊達)
+ */
+
+/dts-v1/;
+
+#include "am335x-moxa-uc-2100-common.dtsi"
+
+/ {
+ model = "Moxa UC-2102";
+ compatible = "moxa,uc-2102", "ti,am33xx";
+
+ leds {
+ compatible = "gpio-leds";
+ led1 {
+ label = "UC2100:GREEN:USER1";
+ gpios = < 16 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led2 {
+ label = "UC2100:GREEN:USER2";
+ gpios = < 17 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+};
+
+_pinmux {
+ pinctrl-names = "default";
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ AM33XX_IOPAD(0x90c, PIN_INPUT_PULLDOWN | MUX_MODE1)
/* mii1_crs.rmii1_crs_dv */
+ AM33XX_IOPAD(0x910, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxerr.rmii1_rxerr */
+ AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txen.rmii1_txen */
+ AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd1.rmii1_txd1 */
+ AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd0.rmii1_txd0 */
+ AM33XX_IOPAD(0x93c, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd1.rmii1_rxd1 */
+ AM33XX_IOPAD(0x940, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd0.rmii1_rxd0 */
+ AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE0)
/* mii1_refclk.rmii1_refclk */
+
+ /* Slave 2 */
+ AM33XX_IOPAD(0x870, PIN_INPUT_PULLDOWN | MUX_MODE3)
/* gpmc_wait0.rmii2_crs_dv */
+ AM33XX_IOPAD(0x874, PIN_INPUT_PULLDOWN | MUX_MODE3)
/* gpmc_wpn.rmii2_rxer */
+ AM33XX_IOPAD(0x840, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a0.rmii2_txen */
+ AM33XX_IOPAD(0x854, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a5.rmii2_td0 */
+ AM33XX_IOPAD(0x850, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a4.rmii2_td1 */
+ AM33XX_IOPAD(0x86c, PIN_INPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a11.rmii2_rd0 */
+ AM33XX_IOPAD(0x868, PIN_INPUT_PULLDOWN | MUX_MODE3)
/* gpmc_a10.rmii2_rd1 */
+ AM33XX_IOPAD(0x908, PIN_INPUT_PULLDOWN | MUX_MODE1)
/* gmii1_col.rmii2_refclk */
+ >;
+ };
+
+ mmc0_pins_default: pinmux_mmc0_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8f0, PIN_INPUT_PULLUP |
Re: WARNING in apparmor_secid_to_secctx
syzbot has found a reproducer for the following crash on: HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support' git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=16662cb640 kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 dashboard link: https://syzkaller.appspot.com/bug?extid=21016130b0580a9de3b5 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f20a9640 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10efd7bc40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+21016130b0580a9de...@syzkaller.appspotmail.com random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) [ cut here ] AppArmor WARN apparmor_secid_to_secctx: ((!secdata)): WARNING: CPU: 0 PID: 4682 at security/apparmor/secid.c:82 apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 4682 Comm: syz-executor028 Not tainted 4.19.0-rc1+ #193 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Code: c7 c7 40 66 58 87 e8 6a 6d 0f fe 0f 0b e9 6c fe ff ff e8 3e aa 44 fe 48 c7 c6 80 67 58 87 48 c7 c7 a0 65 58 87 e8 4b 6d 0f fe <0f> 0b e9 3f fe ff ff 48 89 df e8 fc a7 83 fe e9 ed fe ff ff bb f4 RSP: 0018:8801ba5a6d10 EFLAGS: 00010286 RAX: RBX: 8801ba5a6ed0 RCX: RDX: RSI: 8163ac01 RDI: 0001 RBP: 8801ba5a6d30 R08: 8801d9ba2580 R09: ed003b603eca R10: ed003b603eca R11: 8801db01f657 R12: 0001 R13: R14: R15: 8801ba5a6ed0 security_secid_to_secctx+0x63/0xc0 security/security.c:1314 ctnetlink_secctx_size net/netfilter/nf_conntrack_netlink.c:621 [inline] ctnetlink_nlmsg_size net/netfilter/nf_conntrack_netlink.c:659 [inline] ctnetlink_conntrack_event+0x303/0x1470 net/netfilter/nf_conntrack_netlink.c:706 nf_conntrack_eventmask_report+0x55f/0x930 net/netfilter/nf_conntrack_ecache.c:151 nf_conntrack_event_report include/net/netfilter/nf_conntrack_ecache.h:112 [inline] nf_ct_delete+0x33c/0x5d0 net/netfilter/nf_conntrack_core.c:601 nf_ct_iterate_cleanup+0x48c/0x5e0 net/netfilter/nf_conntrack_core.c:1892 nf_ct_iterate_cleanup_net+0x23c/0x2d0 net/netfilter/nf_conntrack_core.c:1974 ctnetlink_flush_conntrack net/netfilter/nf_conntrack_netlink.c:1226 [inline] ctnetlink_del_conntrack+0x66c/0x850 net/netfilter/nf_conntrack_netlink.c:1258 nfnetlink_rcv_msg+0xd88/0x1070 net/netfilter/nfnetlink.c:228 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454 nfnetlink_rcv+0x1c0/0x4d0 net/netfilter/nfnetlink.c:560 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x290 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441189 Code: e8 cc ab 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc388e2108 EFLAGS: 0217 ORIG_RAX: 002e RAX: ffda RBX: RCX: 00441189 RDX: RSI: 20d65000 RDI: 0004 RBP: R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0217 R12: 004020d0 R13: 00402160 R14: R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds..
Re: WARNING in apparmor_secid_to_secctx
syzbot has found a reproducer for the following crash on: HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support' git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=16662cb640 kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 dashboard link: https://syzkaller.appspot.com/bug?extid=21016130b0580a9de3b5 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f20a9640 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10efd7bc40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+21016130b0580a9de...@syzkaller.appspotmail.com random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) [ cut here ] AppArmor WARN apparmor_secid_to_secctx: ((!secdata)): WARNING: CPU: 0 PID: 4682 at security/apparmor/secid.c:82 apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 4682 Comm: syz-executor028 Not tainted 4.19.0-rc1+ #193 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Code: c7 c7 40 66 58 87 e8 6a 6d 0f fe 0f 0b e9 6c fe ff ff e8 3e aa 44 fe 48 c7 c6 80 67 58 87 48 c7 c7 a0 65 58 87 e8 4b 6d 0f fe <0f> 0b e9 3f fe ff ff 48 89 df e8 fc a7 83 fe e9 ed fe ff ff bb f4 RSP: 0018:8801ba5a6d10 EFLAGS: 00010286 RAX: RBX: 8801ba5a6ed0 RCX: RDX: RSI: 8163ac01 RDI: 0001 RBP: 8801ba5a6d30 R08: 8801d9ba2580 R09: ed003b603eca R10: ed003b603eca R11: 8801db01f657 R12: 0001 R13: R14: R15: 8801ba5a6ed0 security_secid_to_secctx+0x63/0xc0 security/security.c:1314 ctnetlink_secctx_size net/netfilter/nf_conntrack_netlink.c:621 [inline] ctnetlink_nlmsg_size net/netfilter/nf_conntrack_netlink.c:659 [inline] ctnetlink_conntrack_event+0x303/0x1470 net/netfilter/nf_conntrack_netlink.c:706 nf_conntrack_eventmask_report+0x55f/0x930 net/netfilter/nf_conntrack_ecache.c:151 nf_conntrack_event_report include/net/netfilter/nf_conntrack_ecache.h:112 [inline] nf_ct_delete+0x33c/0x5d0 net/netfilter/nf_conntrack_core.c:601 nf_ct_iterate_cleanup+0x48c/0x5e0 net/netfilter/nf_conntrack_core.c:1892 nf_ct_iterate_cleanup_net+0x23c/0x2d0 net/netfilter/nf_conntrack_core.c:1974 ctnetlink_flush_conntrack net/netfilter/nf_conntrack_netlink.c:1226 [inline] ctnetlink_del_conntrack+0x66c/0x850 net/netfilter/nf_conntrack_netlink.c:1258 nfnetlink_rcv_msg+0xd88/0x1070 net/netfilter/nfnetlink.c:228 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454 nfnetlink_rcv+0x1c0/0x4d0 net/netfilter/nfnetlink.c:560 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x290 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441189 Code: e8 cc ab 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc388e2108 EFLAGS: 0217 ORIG_RAX: 002e RAX: ffda RBX: RCX: 00441189 RDX: RSI: 20d65000 RDI: 0004 RBP: R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0217 R12: 004020d0 R13: 00402160 R14: R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds..
Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger
Hi Jacek,
On 30 August 2018 at 03:15, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 08/29/2018 11:48 AM, Baolin Wang wrote:
>> Hi Jacek,
>>
>> On 29 August 2018 at 04:25, Jacek Anaszewski
>> wrote:
>>> On 08/25/2018 09:51 AM, Baolin Wang wrote:
On 25 August 2018 at 04:44, Jacek Anaszewski
wrote:
> On 08/24/2018 10:12 PM, Pavel Machek wrote:
>> On Fri 2018-08-24 21:49:50, Jacek Anaszewski wrote:
>>> Hi Pavel,
>>>
>>> On 08/24/2018 12:11 PM, Pavel Machek wrote:
Hi!
> I think that it would be more flexible if software pattern fallback
> was applied in case of pattern_set failure. Otherwise, it would
> lead to the situation where LED class devices that support hardware
> blinking couldn't be applied the same set of patterns as LED class
> devices that don't implement pattern_set. The latter will always have
> to
> resort to using software pattern engine which will accept far greater
> amount of pattern combinations.
>
> In this case we need to discuss on what basis the decision will be
> made on whether hardware or software engine will be used.
>
> Possible options coming to mind:
> - an interface will be provided to determine max difference between
> the settings supported by the hardware and the settings requested by
> the user, that will result in aligning user's setting to the
> hardware
> capabilities
> - the above alignment rate will be predefined instead
> - hardware engine will be used only if user requests supported
> settings
> on the whole span of the requested pattern
> - in each of the above cases it would be worth to think of the
> interface to show the scope of the settings supported by hardware
I'd recommend keeping it simple. We use hardware engine if driver
author thinks pattern is "close enough".
>>>
>>> The thing is that in the ledtrig-pattern v5 implementation there
>>> is no option of using software fallback if pattern_set op
>>> is initialized:
>>>
>>> +if (led_cdev->pattern_set) {
>>> +return led_cdev->pattern_set(led_cdev, data->patterns,
>>> + data->npatterns,
>>> data->repeat);
>>> +}
>>
>> Yeah, that sounds wrong. (Sorry I did not pay enough attention).
>>
>> It pattern_set() returns special error code, it should just continue
>> and use software pattern fallback.
>
> And now we can get back to the issue I was concerned about in the
> email you replied to, i.e. what series of [brightness delta_t] tuples
> should be written to the pattern file to enable hardware breathing
> engine.
OK. So now we've made a consensus to use the software pattern fallback
if failed to set hardware pattern. How about introduce one interface
to convert hardware patterns to software patterns if necessary?
diff --git a/drivers/leds/trigger/ledtrig-pattern.c
b/drivers/leds/trigger/ledtrig-pattern.c
index 63b94a2..d46a641 100644
--- a/drivers/leds/trigger/ledtrig-pattern.c
+++ b/drivers/leds/trigger/ledtrig-pattern.c
@@ -66,8 +66,15 @@ static int pattern_trig_start_pattern(struct
pattern_trig_data *data,
return 0;
if (led_cdev->pattern_set) {
- return led_cdev->pattern_set(led_cdev, data->patterns,
-data->npatterns,
data->repeat);
+ ret = led_cdev->pattern_set(led_cdev, data->patterns,
+ data->npatterns, data->repeat);
+ if (!ret)
+ return 0;
+
+ dev_warn(led_cdev->dev, "Failed to set hardware
pattern\n");
+
+ if (led_cdev->pattern_convert)
+ led_cdev->pattern_convert(led_cdev,
>>>
>>> I can't see how it could help to assess if hw pattern
>>> engine can launch given pattern, and with what accuracy.
>>>
>>> Instead, I propose to add a means for defining whether the pattern
>>> to be set is intended for hardware pattern engine or for software
>>> fallback. It could be either separate sysfs file e.g. hw_pattern,
>>> or a modifier to the pattern written to the pattern file, e,g,
>>>
>>> echo "hw 100 2 200 3 100 2" > pattern
>>>
>>> hw format expected by given driver would have to be described
>>> in the per-driver ABI documentation. All patterns without
>>> "hw" prefix would enable software pattern engine.
>>
>> OK. So I did some optimization based on v5 according to suggestion, if
>> you think this is okay for you, then I will send out the formal v6
>> patch set.
>>
>> 1. echo "hw 100 2 200 3 100 2" > pattern
>> Only for hardware
Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger
Hi Jacek,
On 30 August 2018 at 03:15, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 08/29/2018 11:48 AM, Baolin Wang wrote:
>> Hi Jacek,
>>
>> On 29 August 2018 at 04:25, Jacek Anaszewski
>> wrote:
>>> On 08/25/2018 09:51 AM, Baolin Wang wrote:
On 25 August 2018 at 04:44, Jacek Anaszewski
wrote:
> On 08/24/2018 10:12 PM, Pavel Machek wrote:
>> On Fri 2018-08-24 21:49:50, Jacek Anaszewski wrote:
>>> Hi Pavel,
>>>
>>> On 08/24/2018 12:11 PM, Pavel Machek wrote:
Hi!
> I think that it would be more flexible if software pattern fallback
> was applied in case of pattern_set failure. Otherwise, it would
> lead to the situation where LED class devices that support hardware
> blinking couldn't be applied the same set of patterns as LED class
> devices that don't implement pattern_set. The latter will always have
> to
> resort to using software pattern engine which will accept far greater
> amount of pattern combinations.
>
> In this case we need to discuss on what basis the decision will be
> made on whether hardware or software engine will be used.
>
> Possible options coming to mind:
> - an interface will be provided to determine max difference between
> the settings supported by the hardware and the settings requested by
> the user, that will result in aligning user's setting to the
> hardware
> capabilities
> - the above alignment rate will be predefined instead
> - hardware engine will be used only if user requests supported
> settings
> on the whole span of the requested pattern
> - in each of the above cases it would be worth to think of the
> interface to show the scope of the settings supported by hardware
I'd recommend keeping it simple. We use hardware engine if driver
author thinks pattern is "close enough".
>>>
>>> The thing is that in the ledtrig-pattern v5 implementation there
>>> is no option of using software fallback if pattern_set op
>>> is initialized:
>>>
>>> +if (led_cdev->pattern_set) {
>>> +return led_cdev->pattern_set(led_cdev, data->patterns,
>>> + data->npatterns,
>>> data->repeat);
>>> +}
>>
>> Yeah, that sounds wrong. (Sorry I did not pay enough attention).
>>
>> It pattern_set() returns special error code, it should just continue
>> and use software pattern fallback.
>
> And now we can get back to the issue I was concerned about in the
> email you replied to, i.e. what series of [brightness delta_t] tuples
> should be written to the pattern file to enable hardware breathing
> engine.
OK. So now we've made a consensus to use the software pattern fallback
if failed to set hardware pattern. How about introduce one interface
to convert hardware patterns to software patterns if necessary?
diff --git a/drivers/leds/trigger/ledtrig-pattern.c
b/drivers/leds/trigger/ledtrig-pattern.c
index 63b94a2..d46a641 100644
--- a/drivers/leds/trigger/ledtrig-pattern.c
+++ b/drivers/leds/trigger/ledtrig-pattern.c
@@ -66,8 +66,15 @@ static int pattern_trig_start_pattern(struct
pattern_trig_data *data,
return 0;
if (led_cdev->pattern_set) {
- return led_cdev->pattern_set(led_cdev, data->patterns,
-data->npatterns,
data->repeat);
+ ret = led_cdev->pattern_set(led_cdev, data->patterns,
+ data->npatterns, data->repeat);
+ if (!ret)
+ return 0;
+
+ dev_warn(led_cdev->dev, "Failed to set hardware
pattern\n");
+
+ if (led_cdev->pattern_convert)
+ led_cdev->pattern_convert(led_cdev,
>>>
>>> I can't see how it could help to assess if hw pattern
>>> engine can launch given pattern, and with what accuracy.
>>>
>>> Instead, I propose to add a means for defining whether the pattern
>>> to be set is intended for hardware pattern engine or for software
>>> fallback. It could be either separate sysfs file e.g. hw_pattern,
>>> or a modifier to the pattern written to the pattern file, e,g,
>>>
>>> echo "hw 100 2 200 3 100 2" > pattern
>>>
>>> hw format expected by given driver would have to be described
>>> in the per-driver ABI documentation. All patterns without
>>> "hw" prefix would enable software pattern engine.
>>
>> OK. So I did some optimization based on v5 according to suggestion, if
>> you think this is okay for you, then I will send out the formal v6
>> patch set.
>>
>> 1. echo "hw 100 2 200 3 100 2" > pattern
>> Only for hardware
Re: [PATCH tip/core/rcu 3/3] srcu: Make early-boot call_srcu() reuse workqueue lists
On Wed, Aug 29, 2018 at 10:46:09PM -0400, Steven Rostedt wrote:
> On Wed, 29 Aug 2018 19:07:01 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Aug 29, 2018 at 09:56:16PM -0400, Steven Rostedt wrote:
> > > On Wed, 29 Aug 2018 14:23:13 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > Allocating a list_head structure that is almost never used, and, when
> > > > used, is used only during early boot (rcu_init() and earlier), is a bit
> > > > wasteful. This commit therefore eliminates that list_head in favor of
> > > > the one in the work_struct structure. This is safe because the
> > > > work_struct
> > > > structure cannot be used until after rcu_init() returns.
> > > >
> > > > Reported-by: Steven Rostedt
> > > > Signed-off-by: Paul E. McKenney
> > > > Cc: Tejun Heo
> > > > Cc: Lai Jiangshan
> > > > ---
> > > > include/linux/srcutiny.h | 2 --
> > > > include/linux/srcutree.h | 3 +--
> > > > kernel/rcu/srcutiny.c| 10 +-
> > > > kernel/rcu/srcutree.c| 11 +--
> > > > 4 files changed, 11 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> > > > index 2b5c0822e683..f41d2fb09f87 100644
> > > > --- a/include/linux/srcutiny.h
> > > > +++ b/include/linux/srcutiny.h
> > > > @@ -36,7 +36,6 @@ struct srcu_struct {
> > > > struct rcu_head *srcu_cb_head; /* Pending callbacks: Head. */
> > > > struct rcu_head **srcu_cb_tail; /* Pending callbacks: Tail. */
> > > > struct work_struct srcu_work; /* For driving grace periods. */
> > > > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > > > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > > struct lockdep_map dep_map;
> > > > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > > > @@ -49,7 +48,6 @@ void srcu_drive_gp(struct work_struct *wp);
> > > > .srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),
> > > > \
> > > > .srcu_cb_tail = _cb_head,
> > > > \
> > > > .srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp),
> > > > \
> > > > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),
> > > > \
> > > > __SRCU_DEP_MAP_INIT(name)
> > > > \
> > > > }
> > > >
> > > > diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> > > > index 9cfa4610113a..0ae91b3a7406 100644
> > > > --- a/include/linux/srcutree.h
> > > > +++ b/include/linux/srcutree.h
> > > > @@ -94,7 +94,6 @@ struct srcu_struct {
> > > > /* callback for the
> > > > barrier */
> > > > /* operation. */
> > > > struct delayed_work work;
> > > > - struct list_head srcu_boot_entry; /* Early-boot
> > > > callbacks. */
> > > > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > > struct lockdep_map dep_map;
> > > > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > > > @@ -110,7 +109,7 @@ struct srcu_struct {
> > > > .sda = _name,
> > > > \
> > > > .lock = __SPIN_LOCK_UNLOCKED(name.lock),
> > > > \
> > > > .srcu_gp_seq_needed = -1UL,
> > > > \
> > > > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),
> > > > \
> > > > + .work = __DELAYED_WORK_INITIALIZER(name.work, NULL, 0),
> > > > \
> > >
> > > Thanks!
> >
> > Glad you like it! Does it actually work for you? ;-)
>
> Oh, you want me to actually test it too? ;-)
;-) ;-) ;-)
> I'll try to add that in my todo list tomorrow.
Much appreciated!
Thanx, Paul
> -- Steve
>
> >
> > Thanx, Paul
> >
> > > -- Steve
> > >
> > > > __SRCU_DEP_MAP_INIT(name)
> > > > \
> > > > }
> > > >
> > > > diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> > > > index d233f0c63f6f..b46e6683f8c9 100644
> > > > --- a/kernel/rcu/srcutiny.c
> > > > +++ b/kernel/rcu/srcutiny.c
> > > > @@ -48,7 +48,7 @@ static int init_srcu_struct_fields(struct srcu_struct
> > > > *sp)
> > > > sp->srcu_gp_waiting = false;
> > > > sp->srcu_idx = 0;
> > > > INIT_WORK(>srcu_work, srcu_drive_gp);
> > > > - INIT_LIST_HEAD(>srcu_boot_entry);
> > > > + INIT_LIST_HEAD(>srcu_work.entry);
> > > > return 0;
> > > > }
> > > >
> > > > @@ -185,8 +185,8 @@ void call_srcu(struct srcu_struct *sp, struct
> > > > rcu_head *rhp,
> > > > if (!READ_ONCE(sp->srcu_gp_running)) {
> > > > if (likely(srcu_init_done))
> > > > schedule_work(>srcu_work);
> > > > - else if (list_empty(>srcu_boot_entry))
> > > > - list_add(>srcu_boot_entry, _boot_list);
> > > > +
Re: [PATCH tip/core/rcu 3/3] srcu: Make early-boot call_srcu() reuse workqueue lists
On Wed, Aug 29, 2018 at 10:46:09PM -0400, Steven Rostedt wrote:
> On Wed, 29 Aug 2018 19:07:01 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Aug 29, 2018 at 09:56:16PM -0400, Steven Rostedt wrote:
> > > On Wed, 29 Aug 2018 14:23:13 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > Allocating a list_head structure that is almost never used, and, when
> > > > used, is used only during early boot (rcu_init() and earlier), is a bit
> > > > wasteful. This commit therefore eliminates that list_head in favor of
> > > > the one in the work_struct structure. This is safe because the
> > > > work_struct
> > > > structure cannot be used until after rcu_init() returns.
> > > >
> > > > Reported-by: Steven Rostedt
> > > > Signed-off-by: Paul E. McKenney
> > > > Cc: Tejun Heo
> > > > Cc: Lai Jiangshan
> > > > ---
> > > > include/linux/srcutiny.h | 2 --
> > > > include/linux/srcutree.h | 3 +--
> > > > kernel/rcu/srcutiny.c| 10 +-
> > > > kernel/rcu/srcutree.c| 11 +--
> > > > 4 files changed, 11 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> > > > index 2b5c0822e683..f41d2fb09f87 100644
> > > > --- a/include/linux/srcutiny.h
> > > > +++ b/include/linux/srcutiny.h
> > > > @@ -36,7 +36,6 @@ struct srcu_struct {
> > > > struct rcu_head *srcu_cb_head; /* Pending callbacks: Head. */
> > > > struct rcu_head **srcu_cb_tail; /* Pending callbacks: Tail. */
> > > > struct work_struct srcu_work; /* For driving grace periods. */
> > > > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > > > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > > struct lockdep_map dep_map;
> > > > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > > > @@ -49,7 +48,6 @@ void srcu_drive_gp(struct work_struct *wp);
> > > > .srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),
> > > > \
> > > > .srcu_cb_tail = _cb_head,
> > > > \
> > > > .srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp),
> > > > \
> > > > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),
> > > > \
> > > > __SRCU_DEP_MAP_INIT(name)
> > > > \
> > > > }
> > > >
> > > > diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> > > > index 9cfa4610113a..0ae91b3a7406 100644
> > > > --- a/include/linux/srcutree.h
> > > > +++ b/include/linux/srcutree.h
> > > > @@ -94,7 +94,6 @@ struct srcu_struct {
> > > > /* callback for the
> > > > barrier */
> > > > /* operation. */
> > > > struct delayed_work work;
> > > > - struct list_head srcu_boot_entry; /* Early-boot
> > > > callbacks. */
> > > > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > > struct lockdep_map dep_map;
> > > > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > > > @@ -110,7 +109,7 @@ struct srcu_struct {
> > > > .sda = _name,
> > > > \
> > > > .lock = __SPIN_LOCK_UNLOCKED(name.lock),
> > > > \
> > > > .srcu_gp_seq_needed = -1UL,
> > > > \
> > > > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),
> > > > \
> > > > + .work = __DELAYED_WORK_INITIALIZER(name.work, NULL, 0),
> > > > \
> > >
> > > Thanks!
> >
> > Glad you like it! Does it actually work for you? ;-)
>
> Oh, you want me to actually test it too? ;-)
;-) ;-) ;-)
> I'll try to add that in my todo list tomorrow.
Much appreciated!
Thanx, Paul
> -- Steve
>
> >
> > Thanx, Paul
> >
> > > -- Steve
> > >
> > > > __SRCU_DEP_MAP_INIT(name)
> > > > \
> > > > }
> > > >
> > > > diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> > > > index d233f0c63f6f..b46e6683f8c9 100644
> > > > --- a/kernel/rcu/srcutiny.c
> > > > +++ b/kernel/rcu/srcutiny.c
> > > > @@ -48,7 +48,7 @@ static int init_srcu_struct_fields(struct srcu_struct
> > > > *sp)
> > > > sp->srcu_gp_waiting = false;
> > > > sp->srcu_idx = 0;
> > > > INIT_WORK(>srcu_work, srcu_drive_gp);
> > > > - INIT_LIST_HEAD(>srcu_boot_entry);
> > > > + INIT_LIST_HEAD(>srcu_work.entry);
> > > > return 0;
> > > > }
> > > >
> > > > @@ -185,8 +185,8 @@ void call_srcu(struct srcu_struct *sp, struct
> > > > rcu_head *rhp,
> > > > if (!READ_ONCE(sp->srcu_gp_running)) {
> > > > if (likely(srcu_init_done))
> > > > schedule_work(>srcu_work);
> > > > - else if (list_empty(>srcu_boot_entry))
> > > > - list_add(>srcu_boot_entry, _boot_list);
> > > > +
Re: [PATCH tip/core/rcu 0/52] Remove rcu_state pointers for v4.20/v5.0
On Wed, Aug 29, 2018 at 10:00:26PM -0400, Steven Rostedt wrote: > On Wed, 29 Aug 2018 15:38:30 -0700 > "Paul E. McKenney" wrote: > > > Hello! > > > > This commit does RCU-consolidation cleanups that get rid of pointers to > > the sole remaining rcu_state structure: > > > > 1-40: Remove the "rsp" parameter from numerous functions, given that > > the corresponding argument will always be _state. > > Hmm, couldn't 1-40 have been made into a single patch? They could. I separated them to make finding the inevitable typos easier. But at this point, it is easy enough to squash them together, though. Thanx, Paul > -- Steve > > > > > 41. Remove rcu_data structure's ->rsp field, now that it always > > contains a pointer to rcu_state. > > > > 42. Remove non-flavor-traversal rsp local variable from tree_plugin.h. > > > > 43. Remove the for_each_rcu_flavor() flavor-traversal macro, given > > that there is now only ever one flavor to traverse. > > > > 44. Simplify rcutorture_get_gp_data() based on there now being only > > one rcu_state structure. > > > > 45. Restructure rcu_check_gp_kthread_starvation() based on there > > now being only one rcu_state structure. > > > > 46. Restructure RCU CPU stall warnings based on there now being only > > one rcu_state structure. > > > > 47. Restructure grace-period management code based on there now being > > only one rcu_state structure. > > > > 48. Restructure callback registration/invocation code based on there > > now being only one rcu_state structure. > > > > 49. Restructure quiescent-state and grace-period-nonstart code based > > on there now being only one rcu_state structure. > > > > 50. Restructure rcu_barrier() based on there now being only one > > rcu_state structure. > > > > 51. Restructure initialization code based on there now being only > > one rcu_state structure. > > > > 52. Fix typo in force_qs_rnp()'s parameter's parameter, which was > > located by searching for "rsp". > > > > Thanx, Paul > > > > > > > > Documentation/RCU/Design/Data-Structures/Data-Structures.html | 23 > > kernel/rcu/rcu.h | 28 > > kernel/rcu/srcutree.c |4 > > kernel/rcu/tree.c | 1261 > > -- > > kernel/rcu/tree.h | 29 > > kernel/rcu/tree_exp.h | 209 - > > kernel/rcu/tree_plugin.h | 203 - > > 7 files changed, 784 insertions(+), 973 deletions(-) >
Re: [PATCH tip/core/rcu 0/52] Remove rcu_state pointers for v4.20/v5.0
On Wed, Aug 29, 2018 at 10:00:26PM -0400, Steven Rostedt wrote: > On Wed, 29 Aug 2018 15:38:30 -0700 > "Paul E. McKenney" wrote: > > > Hello! > > > > This commit does RCU-consolidation cleanups that get rid of pointers to > > the sole remaining rcu_state structure: > > > > 1-40: Remove the "rsp" parameter from numerous functions, given that > > the corresponding argument will always be _state. > > Hmm, couldn't 1-40 have been made into a single patch? They could. I separated them to make finding the inevitable typos easier. But at this point, it is easy enough to squash them together, though. Thanx, Paul > -- Steve > > > > > 41. Remove rcu_data structure's ->rsp field, now that it always > > contains a pointer to rcu_state. > > > > 42. Remove non-flavor-traversal rsp local variable from tree_plugin.h. > > > > 43. Remove the for_each_rcu_flavor() flavor-traversal macro, given > > that there is now only ever one flavor to traverse. > > > > 44. Simplify rcutorture_get_gp_data() based on there now being only > > one rcu_state structure. > > > > 45. Restructure rcu_check_gp_kthread_starvation() based on there > > now being only one rcu_state structure. > > > > 46. Restructure RCU CPU stall warnings based on there now being only > > one rcu_state structure. > > > > 47. Restructure grace-period management code based on there now being > > only one rcu_state structure. > > > > 48. Restructure callback registration/invocation code based on there > > now being only one rcu_state structure. > > > > 49. Restructure quiescent-state and grace-period-nonstart code based > > on there now being only one rcu_state structure. > > > > 50. Restructure rcu_barrier() based on there now being only one > > rcu_state structure. > > > > 51. Restructure initialization code based on there now being only > > one rcu_state structure. > > > > 52. Fix typo in force_qs_rnp()'s parameter's parameter, which was > > located by searching for "rsp". > > > > Thanx, Paul > > > > > > > > Documentation/RCU/Design/Data-Structures/Data-Structures.html | 23 > > kernel/rcu/rcu.h | 28 > > kernel/rcu/srcutree.c |4 > > kernel/rcu/tree.c | 1261 > > -- > > kernel/rcu/tree.h | 29 > > kernel/rcu/tree_exp.h | 209 - > > kernel/rcu/tree_plugin.h | 203 - > > 7 files changed, 784 insertions(+), 973 deletions(-) >
Re: [PATCH v3 0/9] Add Reset Controller support for Actions Semi Owl SoCs
On Fri, Aug 10, 2018 at 03:21:04PM +0530, Manivannan Sadhasivam wrote: > This patchset adds Reset Controller (RMU) support for Actions Semi > Owl SoCs, S900 and S700. For the Owl SoCs, RMU has been integrated into > the clock subsystem in hardware. Hence, in software we integrate RMU > support into common clock driver inorder to maintain compatibility. The > syscon approach is not taken into account based on the review by Rob. > > This patch series depends on the recently posted S700 clk series: > "[PATCH v7 0/5] Add clock driver for Actions S700 SoC". For the S700 clk > series, driver and bindings patches are applied through the clk tree. > But the DTS patches are not yet picked up by the platform maintainer, > Andreas. > > Hence, Andreas is expected to pick the DTS patches in this series once > reviewed by the maintainers along with S700 clk DTS patches. > > Because of the absence of the S500 SoC clk support, the reset controller > registration code is added to both S700 and S900 SoC clk drivers for now. > But once S500 clk support is added, the reset controller registration part > will be moved to Owl SoCs common clk code. > Hi Pavel, Just a ping on this patchset! Thanks, Mani > Thanks, > Mani > > Changes in v3: > > * Reverted back the syscon approach based on the review by Rob Herring > * Dropped the MAINTAINERS patch > * Converted reset_map struct definitions to const based on the review by > Philipp > * Fixed S700 header in DT spotted by Parthiban > * Added Reviewed-by tags from Rob for 3 bindings patches > > Changes in v2: > > * Converted the CMU and RMU drivers to syscon for a more cleaner > approach > * Declared the owl_reset_map structs to const > * Used regmap_update_bits instead of a combined regmap_read and write > * Removed unused headers in RMU drivers > * Added MAINTAINERS entry for the RMU driver and bindings > > Manivannan Sadhasivam (9): > clk: actions: Cache regmap info in private clock descriptor > dt-bindings: clock: Add reset controller bindings for Actions Semi Owl > SoCs > dt-bindings: reset: Add binding constants for Actions Semi S700 RMU > dt-bindings: reset: Add binding constants for Actions Semi S900 RMU > arm64: dts: actions: Add Reset Controller support for S700 SoC > arm64: dts: actions: Add Reset Controller support for S900 SoC > clk: actions: Add Actions Semi Owl SoCs Reset Management Unit support > clk: actions: Add Actions Semi S700 SoC Reset Management Unit support > clk: actions: Add Actions Semi S900 SoC Reset Management Unit support > > .../bindings/clock/actions,owl-cmu.txt| 2 + > arch/arm64/boot/dts/actions/s700.dtsi | 2 + > arch/arm64/boot/dts/actions/s900.dtsi | 2 + > drivers/clk/actions/Kconfig | 1 + > drivers/clk/actions/Makefile | 1 + > drivers/clk/actions/owl-common.c | 3 +- > drivers/clk/actions/owl-common.h | 5 +- > drivers/clk/actions/owl-reset.c | 66 ++ > drivers/clk/actions/owl-reset.h | 31 +++ > drivers/clk/actions/owl-s700.c| 55 +++- > drivers/clk/actions/owl-s900.c| 86 ++- > .../dt-bindings/reset/actions,s700-reset.h| 34 > .../dt-bindings/reset/actions,s900-reset.h| 65 ++ > 13 files changed, 347 insertions(+), 6 deletions(-) > create mode 100644 drivers/clk/actions/owl-reset.c > create mode 100644 drivers/clk/actions/owl-reset.h > create mode 100644 include/dt-bindings/reset/actions,s700-reset.h > create mode 100644 include/dt-bindings/reset/actions,s900-reset.h > > -- > 2.17.1 >
Re: [PATCH v3 0/9] Add Reset Controller support for Actions Semi Owl SoCs
On Fri, Aug 10, 2018 at 03:21:04PM +0530, Manivannan Sadhasivam wrote: > This patchset adds Reset Controller (RMU) support for Actions Semi > Owl SoCs, S900 and S700. For the Owl SoCs, RMU has been integrated into > the clock subsystem in hardware. Hence, in software we integrate RMU > support into common clock driver inorder to maintain compatibility. The > syscon approach is not taken into account based on the review by Rob. > > This patch series depends on the recently posted S700 clk series: > "[PATCH v7 0/5] Add clock driver for Actions S700 SoC". For the S700 clk > series, driver and bindings patches are applied through the clk tree. > But the DTS patches are not yet picked up by the platform maintainer, > Andreas. > > Hence, Andreas is expected to pick the DTS patches in this series once > reviewed by the maintainers along with S700 clk DTS patches. > > Because of the absence of the S500 SoC clk support, the reset controller > registration code is added to both S700 and S900 SoC clk drivers for now. > But once S500 clk support is added, the reset controller registration part > will be moved to Owl SoCs common clk code. > Hi Pavel, Just a ping on this patchset! Thanks, Mani > Thanks, > Mani > > Changes in v3: > > * Reverted back the syscon approach based on the review by Rob Herring > * Dropped the MAINTAINERS patch > * Converted reset_map struct definitions to const based on the review by > Philipp > * Fixed S700 header in DT spotted by Parthiban > * Added Reviewed-by tags from Rob for 3 bindings patches > > Changes in v2: > > * Converted the CMU and RMU drivers to syscon for a more cleaner > approach > * Declared the owl_reset_map structs to const > * Used regmap_update_bits instead of a combined regmap_read and write > * Removed unused headers in RMU drivers > * Added MAINTAINERS entry for the RMU driver and bindings > > Manivannan Sadhasivam (9): > clk: actions: Cache regmap info in private clock descriptor > dt-bindings: clock: Add reset controller bindings for Actions Semi Owl > SoCs > dt-bindings: reset: Add binding constants for Actions Semi S700 RMU > dt-bindings: reset: Add binding constants for Actions Semi S900 RMU > arm64: dts: actions: Add Reset Controller support for S700 SoC > arm64: dts: actions: Add Reset Controller support for S900 SoC > clk: actions: Add Actions Semi Owl SoCs Reset Management Unit support > clk: actions: Add Actions Semi S700 SoC Reset Management Unit support > clk: actions: Add Actions Semi S900 SoC Reset Management Unit support > > .../bindings/clock/actions,owl-cmu.txt| 2 + > arch/arm64/boot/dts/actions/s700.dtsi | 2 + > arch/arm64/boot/dts/actions/s900.dtsi | 2 + > drivers/clk/actions/Kconfig | 1 + > drivers/clk/actions/Makefile | 1 + > drivers/clk/actions/owl-common.c | 3 +- > drivers/clk/actions/owl-common.h | 5 +- > drivers/clk/actions/owl-reset.c | 66 ++ > drivers/clk/actions/owl-reset.h | 31 +++ > drivers/clk/actions/owl-s700.c| 55 +++- > drivers/clk/actions/owl-s900.c| 86 ++- > .../dt-bindings/reset/actions,s700-reset.h| 34 > .../dt-bindings/reset/actions,s900-reset.h| 65 ++ > 13 files changed, 347 insertions(+), 6 deletions(-) > create mode 100644 drivers/clk/actions/owl-reset.c > create mode 100644 drivers/clk/actions/owl-reset.h > create mode 100644 include/dt-bindings/reset/actions,s700-reset.h > create mode 100644 include/dt-bindings/reset/actions,s900-reset.h > > -- > 2.17.1 >
Re: [PATCH 0/4] Add HiSilicon Hi3670 SoC and HiKey970 board
On Fri, Aug 10, 2018 at 11:23:35PM +0530, Manivannan Sadhasivam wrote: > This patchset adds support for Hi3670 SoC and HiKey970 board. Hi3670 SoC > is very similar to the Hi3660 SoC with additional NPU support. For now, > only UART6 has been enabled which is configured by the bootloader for > console support. > > HiKey970 board is one of the 96Boards Consumer Edition and AI platform > based on the Hi3670 SoC. > > With this patchset, the Hikey970 board is able to boot into ramdisk with > 8 cores. > Hi Wei, Any update on this patchset? Thanks, Mani > Thanks, > Mani > > Manivannan Sadhasivam (4): > dt-bindings: arm: hisilicon: Add binding for Hi3670 SoC > arm64: dts: Add devicetree for Hisilicon Hi3670 SoC > dt-bindings: arm: hisilicon: Add binding for HiKey970 board > arm64: dts: Add devicetree support for HiKey970 board > > .../bindings/arm/hisilicon/hisilicon.txt | 8 + > arch/arm64/boot/dts/hisilicon/Makefile| 1 + > .../boot/dts/hisilicon/hi3670-hikey970.dts| 35 > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 162 ++ > 4 files changed, 206 insertions(+) > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3670.dtsi > > -- > 2.17.1 >
Re: [PATCH 0/4] Add HiSilicon Hi3670 SoC and HiKey970 board
On Fri, Aug 10, 2018 at 11:23:35PM +0530, Manivannan Sadhasivam wrote: > This patchset adds support for Hi3670 SoC and HiKey970 board. Hi3670 SoC > is very similar to the Hi3660 SoC with additional NPU support. For now, > only UART6 has been enabled which is configured by the bootloader for > console support. > > HiKey970 board is one of the 96Boards Consumer Edition and AI platform > based on the Hi3670 SoC. > > With this patchset, the Hikey970 board is able to boot into ramdisk with > 8 cores. > Hi Wei, Any update on this patchset? Thanks, Mani > Thanks, > Mani > > Manivannan Sadhasivam (4): > dt-bindings: arm: hisilicon: Add binding for Hi3670 SoC > arm64: dts: Add devicetree for Hisilicon Hi3670 SoC > dt-bindings: arm: hisilicon: Add binding for HiKey970 board > arm64: dts: Add devicetree support for HiKey970 board > > .../bindings/arm/hisilicon/hisilicon.txt | 8 + > arch/arm64/boot/dts/hisilicon/Makefile| 1 + > .../boot/dts/hisilicon/hi3670-hikey970.dts| 35 > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 162 ++ > 4 files changed, 206 insertions(+) > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts > create mode 100644 arch/arm64/boot/dts/hisilicon/hi3670.dtsi > > -- > 2.17.1 >
Re: [PATCH 2/2] power: supply: Add Spreadtrum SC2731 charger support
Hi Krzysztof,
On 29 August 2018 at 22:36, Krzysztof Kozlowski wrote:
> I'll try one more time... but without HTML from Gmail. Previous mail
> bounced from lists.
>
> On Tue, 28 Aug 2018 at 11:04, Baolin Wang wrote:
>>
>> This patch adds the SC2731 PMIC switch charger support.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/power/supply/Kconfig |7 +
>> drivers/power/supply/Makefile |1 +
>> drivers/power/supply/sc2731_charger.c | 451
>> +
>> 3 files changed, 459 insertions(+)
>> create mode 100644 drivers/power/supply/sc2731_charger.c
>>
>> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
>> index ff6dab0..f27cf07 100644
>> --- a/drivers/power/supply/Kconfig
>> +++ b/drivers/power/supply/Kconfig
>> @@ -645,4 +645,11 @@ config CHARGER_CROS_USBPD
>> what is connected to USB PD ports from the EC and converts
>> that into power_supply properties.
>>
>> +config CHARGER_SC2731
>> + tristate "Spreadtrum SC2731 charger driver"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + help
>> +Say Y here to enable support for battery charging with SC2731
>> +PMIC chips.
>> +
>> endif # POWER_SUPPLY
>> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
>> index a26b402..767105b 100644
>> --- a/drivers/power/supply/Makefile
>> +++ b/drivers/power/supply/Makefile
>> @@ -85,3 +85,4 @@ obj-$(CONFIG_CHARGER_TPS65217)+= tps65217_charger.o
>> obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>> obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
>> obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
>> +obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
>> diff --git a/drivers/power/supply/sc2731_charger.c
>> b/drivers/power/supply/sc2731_charger.c
>> new file mode 100644
>> index 000..49ae16a
>> --- /dev/null
>> +++ b/drivers/power/supply/sc2731_charger.c
>> @@ -0,0 +1,451 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> slab.h includes looks not needed.
Right. will remove it.
>
>> +#include
>> +#include
>> +#include
>
> Looks not used.
Will remove it.
>
>> +#include
>> +#include
>> +
>> +/* PMIC global registers definition */
>> +#define SC2731_CHARGE_STATUS 0xedc
>> +#define SC2731_CHARGE_FULL BIT(4)
>> +#define SC2731_MODULE_EN1 0xc0c
>> +#define SC2731_CHARGE_EN BIT(5)
>> +
>> +/* SC2731 switch charger registers definition */
>> +#define SC2731_CHG_CFG00x0
>> +#define SC2731_CHG_CFG10x4
>> +#define SC2731_CHG_CFG20x8
>> +#define SC2731_CHG_CFG30xc
>> +#define SC2731_CHG_CFG40x10
>> +#define SC2731_CHG_CFG50x28
>> +
>> +/* SC2731_CHG_CFG0 register definition */
>> +#define SC2731_PRECHG_RNG_SHIFT11
>> +#define SC2731_PRECHG_RNG_MASK GENMASK(12, 11)
>> +
>> +#define SC2731_TERMINATION_VOL_MASKGENMASK(2, 1)
>> +#define SC2731_TERMINATION_VOL_SHIFT 1
>> +#define SC2731_TERMINATION_VOL_CAL_MASKGENMASK(8, 3)
>> +#define SC2731_TERMINATION_VOL_CAL_SHIFT 3
>> +#define SC2731_TERMINATION_CUR_MASKGENMASK(2, 0)
>> +
>> +#define SC2731_CC_EN BIT(13)
>> +#define SC2731_CHARGER_PD BIT(0)
>> +
>> +/* SC2731_CHG_CFG1 register definition */
>> +#define SC2731_CUR_MASKGENMASK(5, 0)
>> +
>> +/* SC2731_CHG_CFG5 register definition */
>> +#define SC2731_CUR_LIMIT_SHIFT 8
>> +#define SC2731_CUR_LIMIT_MASK GENMASK(9, 8)
>> +
>> +#define SC2731_CURRENT_LIMIT_100 100
>> +#define SC2731_CURRENT_LIMIT_500 500
>> +#define SC2731_CURRENT_LIMIT_900 900
>> +#define SC2731_CURRENT_LIMIT_2000 2000
>> +
>> +#define SC2731_CURRENT_PRECHG 450
>> +#define SC2731_CURRENT_STEP50
>
> What units are used for all these currents?
Sorry for confusing, and will add comments to explain these macros or
add one postfix ‘MA’.
>
>> +
>> +struct sc2731_charger_info {
>> + struct device *dev;
>> + struct regmap *regmap;
>> + struct usb_phy *usb_phy;
>> + struct notifier_block usb_notify;
>> + struct power_supply *psy_usb;
>> + bool charging;
>> + u32 base;
>> +};
>> +
>> +static void sc2731_charger_stop_charge(struct sc2731_charger_info *info)
>> +{
>> + regmap_update_bits(info->regmap, info->base + SC2731_CHG_CFG0,
>> + SC2731_CC_EN, 0);
>> +
>> + regmap_update_bits(info->regmap, info->base + SC2731_CHG_CFG0,
>> + SC2731_CHARGER_PD, SC2731_CHARGER_PD);
>> +}
>> +
>> +static int sc2731_charger_start_charge(struct sc2731_charger_info *info)
>> +{
>> + int ret;
>> +
>> + /*
Re: [PATCH 2/2] power: supply: Add Spreadtrum SC2731 charger support
Hi Krzysztof,
On 29 August 2018 at 22:36, Krzysztof Kozlowski wrote:
> I'll try one more time... but without HTML from Gmail. Previous mail
> bounced from lists.
>
> On Tue, 28 Aug 2018 at 11:04, Baolin Wang wrote:
>>
>> This patch adds the SC2731 PMIC switch charger support.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/power/supply/Kconfig |7 +
>> drivers/power/supply/Makefile |1 +
>> drivers/power/supply/sc2731_charger.c | 451
>> +
>> 3 files changed, 459 insertions(+)
>> create mode 100644 drivers/power/supply/sc2731_charger.c
>>
>> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
>> index ff6dab0..f27cf07 100644
>> --- a/drivers/power/supply/Kconfig
>> +++ b/drivers/power/supply/Kconfig
>> @@ -645,4 +645,11 @@ config CHARGER_CROS_USBPD
>> what is connected to USB PD ports from the EC and converts
>> that into power_supply properties.
>>
>> +config CHARGER_SC2731
>> + tristate "Spreadtrum SC2731 charger driver"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + help
>> +Say Y here to enable support for battery charging with SC2731
>> +PMIC chips.
>> +
>> endif # POWER_SUPPLY
>> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
>> index a26b402..767105b 100644
>> --- a/drivers/power/supply/Makefile
>> +++ b/drivers/power/supply/Makefile
>> @@ -85,3 +85,4 @@ obj-$(CONFIG_CHARGER_TPS65217)+= tps65217_charger.o
>> obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>> obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
>> obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
>> +obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
>> diff --git a/drivers/power/supply/sc2731_charger.c
>> b/drivers/power/supply/sc2731_charger.c
>> new file mode 100644
>> index 000..49ae16a
>> --- /dev/null
>> +++ b/drivers/power/supply/sc2731_charger.c
>> @@ -0,0 +1,451 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> slab.h includes looks not needed.
Right. will remove it.
>
>> +#include
>> +#include
>> +#include
>
> Looks not used.
Will remove it.
>
>> +#include
>> +#include
>> +
>> +/* PMIC global registers definition */
>> +#define SC2731_CHARGE_STATUS 0xedc
>> +#define SC2731_CHARGE_FULL BIT(4)
>> +#define SC2731_MODULE_EN1 0xc0c
>> +#define SC2731_CHARGE_EN BIT(5)
>> +
>> +/* SC2731 switch charger registers definition */
>> +#define SC2731_CHG_CFG00x0
>> +#define SC2731_CHG_CFG10x4
>> +#define SC2731_CHG_CFG20x8
>> +#define SC2731_CHG_CFG30xc
>> +#define SC2731_CHG_CFG40x10
>> +#define SC2731_CHG_CFG50x28
>> +
>> +/* SC2731_CHG_CFG0 register definition */
>> +#define SC2731_PRECHG_RNG_SHIFT11
>> +#define SC2731_PRECHG_RNG_MASK GENMASK(12, 11)
>> +
>> +#define SC2731_TERMINATION_VOL_MASKGENMASK(2, 1)
>> +#define SC2731_TERMINATION_VOL_SHIFT 1
>> +#define SC2731_TERMINATION_VOL_CAL_MASKGENMASK(8, 3)
>> +#define SC2731_TERMINATION_VOL_CAL_SHIFT 3
>> +#define SC2731_TERMINATION_CUR_MASKGENMASK(2, 0)
>> +
>> +#define SC2731_CC_EN BIT(13)
>> +#define SC2731_CHARGER_PD BIT(0)
>> +
>> +/* SC2731_CHG_CFG1 register definition */
>> +#define SC2731_CUR_MASKGENMASK(5, 0)
>> +
>> +/* SC2731_CHG_CFG5 register definition */
>> +#define SC2731_CUR_LIMIT_SHIFT 8
>> +#define SC2731_CUR_LIMIT_MASK GENMASK(9, 8)
>> +
>> +#define SC2731_CURRENT_LIMIT_100 100
>> +#define SC2731_CURRENT_LIMIT_500 500
>> +#define SC2731_CURRENT_LIMIT_900 900
>> +#define SC2731_CURRENT_LIMIT_2000 2000
>> +
>> +#define SC2731_CURRENT_PRECHG 450
>> +#define SC2731_CURRENT_STEP50
>
> What units are used for all these currents?
Sorry for confusing, and will add comments to explain these macros or
add one postfix ‘MA’.
>
>> +
>> +struct sc2731_charger_info {
>> + struct device *dev;
>> + struct regmap *regmap;
>> + struct usb_phy *usb_phy;
>> + struct notifier_block usb_notify;
>> + struct power_supply *psy_usb;
>> + bool charging;
>> + u32 base;
>> +};
>> +
>> +static void sc2731_charger_stop_charge(struct sc2731_charger_info *info)
>> +{
>> + regmap_update_bits(info->regmap, info->base + SC2731_CHG_CFG0,
>> + SC2731_CC_EN, 0);
>> +
>> + regmap_update_bits(info->regmap, info->base + SC2731_CHG_CFG0,
>> + SC2731_CHARGER_PD, SC2731_CHARGER_PD);
>> +}
>> +
>> +static int sc2731_charger_start_charge(struct sc2731_charger_info *info)
>> +{
>> + int ret;
>> +
>> + /*
Re: [PATCH 1/2] dt-bindings: power: Add Spreadtrum SC2731 charger documentation
Hi Krzysztof,
On 29 August 2018 at 22:08, Krzysztof Kozlowski wrote:
> On Tue, 28 Aug 2018 at 11:04, Baolin Wang wrote:
>>
>> This patch adds the binding documentation for Spreadtrum SC2731 charger
>> device.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> .../bindings/power/supply/sc2731_charger.txt | 14 ++
>> 1 file changed, 14 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/power/supply/sc2731_charger.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/power/supply/sc2731_charger.txt
>> b/Documentation/devicetree/bindings/power/supply/sc2731_charger.txt
>> new file mode 100644
>> index 000..02b616c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/supply/sc2731_charger.txt
>> @@ -0,0 +1,14 @@
>> +Spreadtrum SC2731 PMIC battery charger binding
>> +
>> +Required properties:
>> + - compatible: Should be "sprd,sc2731-charger".
>> + - reg: Address offset of charger register.
>> + - phys: Contains a phandle to the USB phy.
>> +
>> +Example:
>> +
>> + charger@0 {
>> + compatible = "sprd,sc2731-charger";
>> + reg = <0x0>;
>
> Can you include also few lines of parent node? You use this "reg"
> later as a base address so probably your parent node requires address
> mapping. It would be nice to see it in example.
>
Sorry that I forgot adding the parent node, and will add it in next
version. Thanks.
--
Baolin Wang
Best Regards
Re: [PATCH 1/2] dt-bindings: power: Add Spreadtrum SC2731 charger documentation
Hi Krzysztof,
On 29 August 2018 at 22:08, Krzysztof Kozlowski wrote:
> On Tue, 28 Aug 2018 at 11:04, Baolin Wang wrote:
>>
>> This patch adds the binding documentation for Spreadtrum SC2731 charger
>> device.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> .../bindings/power/supply/sc2731_charger.txt | 14 ++
>> 1 file changed, 14 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/power/supply/sc2731_charger.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/power/supply/sc2731_charger.txt
>> b/Documentation/devicetree/bindings/power/supply/sc2731_charger.txt
>> new file mode 100644
>> index 000..02b616c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/supply/sc2731_charger.txt
>> @@ -0,0 +1,14 @@
>> +Spreadtrum SC2731 PMIC battery charger binding
>> +
>> +Required properties:
>> + - compatible: Should be "sprd,sc2731-charger".
>> + - reg: Address offset of charger register.
>> + - phys: Contains a phandle to the USB phy.
>> +
>> +Example:
>> +
>> + charger@0 {
>> + compatible = "sprd,sc2731-charger";
>> + reg = <0x0>;
>
> Can you include also few lines of parent node? You use this "reg"
> later as a base address so probably your parent node requires address
> mapping. It would be nice to see it in example.
>
Sorry that I forgot adding the parent node, and will add it in next
version. Thanks.
--
Baolin Wang
Best Regards
ASSIST ME TO GET THIS MONEY PLEASE
Good day my dear friend, Let me start by introducing myself. I am Bartholomew Caleb, an accounts officer with Bank of Africa here in Burkina Faso West Africa. I am writing you this letter based on the latest development at my bank whichI will like to bring to your personal edification. ($9million) transfer claim into your bank account. Pleaded,I need your help here, do reply for more details on how we are going to proceed if you are intrested in this grateful oppurtunity. Get back to me at my private email address at, drbartholomewcaleb...@gmail.com Thanks, Dr Bartholomew Caleb, +22663382485.
ASSIST ME TO GET THIS MONEY PLEASE
Good day my dear friend, Let me start by introducing myself. I am Bartholomew Caleb, an accounts officer with Bank of Africa here in Burkina Faso West Africa. I am writing you this letter based on the latest development at my bank whichI will like to bring to your personal edification. ($9million) transfer claim into your bank account. Pleaded,I need your help here, do reply for more details on how we are going to proceed if you are intrested in this grateful oppurtunity. Get back to me at my private email address at, drbartholomewcaleb...@gmail.com Thanks, Dr Bartholomew Caleb, +22663382485.
linux-next: Tree for Aug 30
Hi all, Changes since 20180829: New trees: soundwire and soundwire-fixes Dropped trees: xarray, ida (temporarily) The spi tree lost its build failure. Non-merge commits (relative to Linus' tree): 1087 1284 files changed, 44936 insertions(+), 12978 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (3f16503b7d22 Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (ad1d69735878 Merge tag 'fuse-update-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse) Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()) Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs for v4.18-rc6) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging bpf/master (d65e6c80c6bb Merge branch 'bpf_msg_pull_data-fixes') Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (0434ccdcf883 netfilter: nf_tables: rework ct timeout set support) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging mac80211/master (166ac9d55b0a mac80211: avoid kernel panic when building AMSDU from non-linear SKB) Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1) Merging sound-current/for-linus (8a328ac1f9eb ALSA: hda/realtek - Fix HP Headset Mic can't record) Merging sound-asoc-fixes/for-linus (c4305768a542 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (823f18f8b860 regulator: bd71837: Disable voltage monitoring for LDO3/4) Merging spi-fixes/for-linus (9a92a569272a Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1) Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600:
linux-next: Tree for Aug 30
Hi all, Changes since 20180829: New trees: soundwire and soundwire-fixes Dropped trees: xarray, ida (temporarily) The spi tree lost its build failure. Non-merge commits (relative to Linus' tree): 1087 1284 files changed, 44936 insertions(+), 12978 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (3f16503b7d22 Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (ad1d69735878 Merge tag 'fuse-update-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse) Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()) Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs for v4.18-rc6) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging bpf/master (d65e6c80c6bb Merge branch 'bpf_msg_pull_data-fixes') Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (0434ccdcf883 netfilter: nf_tables: rework ct timeout set support) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging mac80211/master (166ac9d55b0a mac80211: avoid kernel panic when building AMSDU from non-linear SKB) Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1) Merging sound-current/for-linus (8a328ac1f9eb ALSA: hda/realtek - Fix HP Headset Mic can't record) Merging sound-asoc-fixes/for-linus (c4305768a542 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (823f18f8b860 regulator: bd71837: Disable voltage monitoring for LDO3/4) Merging spi-fixes/for-linus (9a92a569272a Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1) Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600:
Re: [PATCH tip/core/rcu 3/3] srcu: Make early-boot call_srcu() reuse workqueue lists
On Wed, 29 Aug 2018 19:07:01 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 29, 2018 at 09:56:16PM -0400, Steven Rostedt wrote:
> > On Wed, 29 Aug 2018 14:23:13 -0700
> > "Paul E. McKenney" wrote:
> >
> > > Allocating a list_head structure that is almost never used, and, when
> > > used, is used only during early boot (rcu_init() and earlier), is a bit
> > > wasteful. This commit therefore eliminates that list_head in favor of
> > > the one in the work_struct structure. This is safe because the
> > > work_struct
> > > structure cannot be used until after rcu_init() returns.
> > >
> > > Reported-by: Steven Rostedt
> > > Signed-off-by: Paul E. McKenney
> > > Cc: Tejun Heo
> > > Cc: Lai Jiangshan
> > > ---
> > > include/linux/srcutiny.h | 2 --
> > > include/linux/srcutree.h | 3 +--
> > > kernel/rcu/srcutiny.c| 10 +-
> > > kernel/rcu/srcutree.c| 11 +--
> > > 4 files changed, 11 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> > > index 2b5c0822e683..f41d2fb09f87 100644
> > > --- a/include/linux/srcutiny.h
> > > +++ b/include/linux/srcutiny.h
> > > @@ -36,7 +36,6 @@ struct srcu_struct {
> > > struct rcu_head *srcu_cb_head; /* Pending callbacks: Head. */
> > > struct rcu_head **srcu_cb_tail; /* Pending callbacks: Tail. */
> > > struct work_struct srcu_work; /* For driving grace periods. */
> > > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > struct lockdep_map dep_map;
> > > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > > @@ -49,7 +48,6 @@ void srcu_drive_gp(struct work_struct *wp);
> > > .srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),\
> > > .srcu_cb_tail = _cb_head, \
> > > .srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp), \
> > > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> > > __SRCU_DEP_MAP_INIT(name) \
> > > }
> > >
> > > diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> > > index 9cfa4610113a..0ae91b3a7406 100644
> > > --- a/include/linux/srcutree.h
> > > +++ b/include/linux/srcutree.h
> > > @@ -94,7 +94,6 @@ struct srcu_struct {
> > > /* callback for the barrier */
> > > /* operation. */
> > > struct delayed_work work;
> > > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > struct lockdep_map dep_map;
> > > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > > @@ -110,7 +109,7 @@ struct srcu_struct {
> > > .sda = _name, \
> > > .lock = __SPIN_LOCK_UNLOCKED(name.lock),\
> > > .srcu_gp_seq_needed = -1UL, \
> > > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> > > + .work = __DELAYED_WORK_INITIALIZER(name.work, NULL, 0), \
> >
> > Thanks!
>
> Glad you like it! Does it actually work for you? ;-)
Oh, you want me to actually test it too? ;-)
I'll try to add that in my todo list tomorrow.
-- Steve
>
> Thanx, Paul
>
> > -- Steve
> >
> > > __SRCU_DEP_MAP_INIT(name) \
> > > }
> > >
> > > diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> > > index d233f0c63f6f..b46e6683f8c9 100644
> > > --- a/kernel/rcu/srcutiny.c
> > > +++ b/kernel/rcu/srcutiny.c
> > > @@ -48,7 +48,7 @@ static int init_srcu_struct_fields(struct srcu_struct
> > > *sp)
> > > sp->srcu_gp_waiting = false;
> > > sp->srcu_idx = 0;
> > > INIT_WORK(>srcu_work, srcu_drive_gp);
> > > - INIT_LIST_HEAD(>srcu_boot_entry);
> > > + INIT_LIST_HEAD(>srcu_work.entry);
> > > return 0;
> > > }
> > >
> > > @@ -185,8 +185,8 @@ void call_srcu(struct srcu_struct *sp, struct
> > > rcu_head *rhp,
> > > if (!READ_ONCE(sp->srcu_gp_running)) {
> > > if (likely(srcu_init_done))
> > > schedule_work(>srcu_work);
> > > - else if (list_empty(>srcu_boot_entry))
> > > - list_add(>srcu_boot_entry, _boot_list);
> > > + else if (list_empty(>srcu_work.entry))
> > > + list_add(>srcu_work.entry, _boot_list);
> > > }
> > > }
> > > EXPORT_SYMBOL_GPL(call_srcu);
> > > @@ -224,8 +224,8 @@ void __init srcu_init(void)
> > > srcu_init_done = true;
> > > while (!list_empty(_boot_list)) {
> > > sp = list_first_entry(_boot_list,
> > > - struct srcu_struct, srcu_boot_entry);
> > > - list_del_init(>srcu_boot_entry);
> > > + struct srcu_struct, srcu_work.entry);
> > > + list_del_init(>srcu_work.entry);
> > > schedule_work(>srcu_work);
> > > }
> > > }
> > > diff --git
Re: [PATCH tip/core/rcu 3/3] srcu: Make early-boot call_srcu() reuse workqueue lists
On Wed, 29 Aug 2018 19:07:01 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 29, 2018 at 09:56:16PM -0400, Steven Rostedt wrote:
> > On Wed, 29 Aug 2018 14:23:13 -0700
> > "Paul E. McKenney" wrote:
> >
> > > Allocating a list_head structure that is almost never used, and, when
> > > used, is used only during early boot (rcu_init() and earlier), is a bit
> > > wasteful. This commit therefore eliminates that list_head in favor of
> > > the one in the work_struct structure. This is safe because the
> > > work_struct
> > > structure cannot be used until after rcu_init() returns.
> > >
> > > Reported-by: Steven Rostedt
> > > Signed-off-by: Paul E. McKenney
> > > Cc: Tejun Heo
> > > Cc: Lai Jiangshan
> > > ---
> > > include/linux/srcutiny.h | 2 --
> > > include/linux/srcutree.h | 3 +--
> > > kernel/rcu/srcutiny.c| 10 +-
> > > kernel/rcu/srcutree.c| 11 +--
> > > 4 files changed, 11 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> > > index 2b5c0822e683..f41d2fb09f87 100644
> > > --- a/include/linux/srcutiny.h
> > > +++ b/include/linux/srcutiny.h
> > > @@ -36,7 +36,6 @@ struct srcu_struct {
> > > struct rcu_head *srcu_cb_head; /* Pending callbacks: Head. */
> > > struct rcu_head **srcu_cb_tail; /* Pending callbacks: Tail. */
> > > struct work_struct srcu_work; /* For driving grace periods. */
> > > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > struct lockdep_map dep_map;
> > > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > > @@ -49,7 +48,6 @@ void srcu_drive_gp(struct work_struct *wp);
> > > .srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),\
> > > .srcu_cb_tail = _cb_head, \
> > > .srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp), \
> > > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> > > __SRCU_DEP_MAP_INIT(name) \
> > > }
> > >
> > > diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> > > index 9cfa4610113a..0ae91b3a7406 100644
> > > --- a/include/linux/srcutree.h
> > > +++ b/include/linux/srcutree.h
> > > @@ -94,7 +94,6 @@ struct srcu_struct {
> > > /* callback for the barrier */
> > > /* operation. */
> > > struct delayed_work work;
> > > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > > struct lockdep_map dep_map;
> > > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > > @@ -110,7 +109,7 @@ struct srcu_struct {
> > > .sda = _name, \
> > > .lock = __SPIN_LOCK_UNLOCKED(name.lock),\
> > > .srcu_gp_seq_needed = -1UL, \
> > > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> > > + .work = __DELAYED_WORK_INITIALIZER(name.work, NULL, 0), \
> >
> > Thanks!
>
> Glad you like it! Does it actually work for you? ;-)
Oh, you want me to actually test it too? ;-)
I'll try to add that in my todo list tomorrow.
-- Steve
>
> Thanx, Paul
>
> > -- Steve
> >
> > > __SRCU_DEP_MAP_INIT(name) \
> > > }
> > >
> > > diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> > > index d233f0c63f6f..b46e6683f8c9 100644
> > > --- a/kernel/rcu/srcutiny.c
> > > +++ b/kernel/rcu/srcutiny.c
> > > @@ -48,7 +48,7 @@ static int init_srcu_struct_fields(struct srcu_struct
> > > *sp)
> > > sp->srcu_gp_waiting = false;
> > > sp->srcu_idx = 0;
> > > INIT_WORK(>srcu_work, srcu_drive_gp);
> > > - INIT_LIST_HEAD(>srcu_boot_entry);
> > > + INIT_LIST_HEAD(>srcu_work.entry);
> > > return 0;
> > > }
> > >
> > > @@ -185,8 +185,8 @@ void call_srcu(struct srcu_struct *sp, struct
> > > rcu_head *rhp,
> > > if (!READ_ONCE(sp->srcu_gp_running)) {
> > > if (likely(srcu_init_done))
> > > schedule_work(>srcu_work);
> > > - else if (list_empty(>srcu_boot_entry))
> > > - list_add(>srcu_boot_entry, _boot_list);
> > > + else if (list_empty(>srcu_work.entry))
> > > + list_add(>srcu_work.entry, _boot_list);
> > > }
> > > }
> > > EXPORT_SYMBOL_GPL(call_srcu);
> > > @@ -224,8 +224,8 @@ void __init srcu_init(void)
> > > srcu_init_done = true;
> > > while (!list_empty(_boot_list)) {
> > > sp = list_first_entry(_boot_list,
> > > - struct srcu_struct, srcu_boot_entry);
> > > - list_del_init(>srcu_boot_entry);
> > > + struct srcu_struct, srcu_work.entry);
> > > + list_del_init(>srcu_work.entry);
> > > schedule_work(>srcu_work);
> > > }
> > > }
> > > diff --git
[BUG] [Resend] Possible sleep-in-atomic-context bugs involving regmap_lock_mutex()
Hello,
My static tool DSAC reports many sleep-in-atomic-context bugs involving
regmap_lock_mutex(), so I wonder whether this function is possible to be
executed in atomic context.
Here are some example bugs and their call paths in Linux-4.16 (from
bottom to top, and [FUNC_PTR] means that there is a function pointer call):
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2503:
[FUNC_PTR]regmap_lock_mutex in regmap_read
drivers/clk/clk-aspeed.c, 215:
regmap_read in aspeed_clk_is_enabled
drivers/clk/clk-aspeed.c, 230:
aspeed_clk_is_enabled in aspeed_clk_enable
drivers/clk/clk-aspeed.c, 228:
_raw_spin_lock_irqsave in aspeed_clk_enable
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2821:
[FUNC_PTR]regmap_lock_mutex in regmap_update_bits_base
drivers/clk/clk-aspeed.c, 270:
regmap_update_bits_base in aspeed_clk_disable
drivers/clk/clk-aspeed.c, 267:
_raw_spin_lock_irqsave in aspeed_clk_disable
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2503:
[FUNC_PTR]regmap_lock_mutex in regmap_read
drivers/char/ipmi/bt-bmc.c, 385:
regmap_read in bt_bmc_irq
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2821:
[FUNC_PTR]regmap_lock_mutex in regmap_update_bits_base
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, 213:
regmap_update_bits_base in hdmi_modb
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, 429:
hdmi_modb in hdmi_set_cts_n
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, 527:
hdmi_set_cts_n in hdmi_set_clk_regenerator
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, 524:
spin_lock_irq in hdmi_set_clk_regenerator
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2503:
[FUNC_PTR]regmap_lock_mutex in regmap_read
drivers/media/platform/atmel/atmel-isc.c, 1603:
regmap_read in isc_interrupt (interrupt handler)
I find the code about the assignment of regmap_lock_mutex():
if ((bus && bus->fast_io) ||
config->fast_io) {
spin_lock_init(>spinlock);
map->lock = regmap_lock_spinlock;
map->unlock = regmap_unlock_spinlock;
lockdep_set_class_and_name(>spinlock,
lock_key, lock_name);
} else {
mutex_init(>mutex);
map->lock = regmap_lock_mutex;
map->unlock = regmap_unlock_mutex;
lockdep_set_class_and_name(>mutex,
lock_key, lock_name);
}
But after reading the code, I cannot find the relationship between the
if condition and atomic context.
I think assigning regmap_lock_mutex() to map->lock may be not proper.
I also find some similar previously reported problems about
regmap_lock_mutex():
https://lists.launchpad.net/kernel-packages/msg187700.html
https://community.nxp.com/thread/432071
I am not sure whether my analysis and results are right.
Could someone please give me explanation?
Thanks in advance :)
Best wishes,
Jia-Ju Bai
[BUG] [Resend] Possible sleep-in-atomic-context bugs involving regmap_lock_mutex()
Hello,
My static tool DSAC reports many sleep-in-atomic-context bugs involving
regmap_lock_mutex(), so I wonder whether this function is possible to be
executed in atomic context.
Here are some example bugs and their call paths in Linux-4.16 (from
bottom to top, and [FUNC_PTR] means that there is a function pointer call):
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2503:
[FUNC_PTR]regmap_lock_mutex in regmap_read
drivers/clk/clk-aspeed.c, 215:
regmap_read in aspeed_clk_is_enabled
drivers/clk/clk-aspeed.c, 230:
aspeed_clk_is_enabled in aspeed_clk_enable
drivers/clk/clk-aspeed.c, 228:
_raw_spin_lock_irqsave in aspeed_clk_enable
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2821:
[FUNC_PTR]regmap_lock_mutex in regmap_update_bits_base
drivers/clk/clk-aspeed.c, 270:
regmap_update_bits_base in aspeed_clk_disable
drivers/clk/clk-aspeed.c, 267:
_raw_spin_lock_irqsave in aspeed_clk_disable
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2503:
[FUNC_PTR]regmap_lock_mutex in regmap_read
drivers/char/ipmi/bt-bmc.c, 385:
regmap_read in bt_bmc_irq
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2821:
[FUNC_PTR]regmap_lock_mutex in regmap_update_bits_base
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, 213:
regmap_update_bits_base in hdmi_modb
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, 429:
hdmi_modb in hdmi_set_cts_n
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, 527:
hdmi_set_cts_n in hdmi_set_clk_regenerator
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, 524:
spin_lock_irq in hdmi_set_clk_regenerator
[FUNC] mutex_lock_nested
drivers/base/regmap/regmap.c, 468:
mutex_lock_nested in regmap_lock_mutex
drivers/base/regmap/regmap.c, 2503:
[FUNC_PTR]regmap_lock_mutex in regmap_read
drivers/media/platform/atmel/atmel-isc.c, 1603:
regmap_read in isc_interrupt (interrupt handler)
I find the code about the assignment of regmap_lock_mutex():
if ((bus && bus->fast_io) ||
config->fast_io) {
spin_lock_init(>spinlock);
map->lock = regmap_lock_spinlock;
map->unlock = regmap_unlock_spinlock;
lockdep_set_class_and_name(>spinlock,
lock_key, lock_name);
} else {
mutex_init(>mutex);
map->lock = regmap_lock_mutex;
map->unlock = regmap_unlock_mutex;
lockdep_set_class_and_name(>mutex,
lock_key, lock_name);
}
But after reading the code, I cannot find the relationship between the
if condition and atomic context.
I think assigning regmap_lock_mutex() to map->lock may be not proper.
I also find some similar previously reported problems about
regmap_lock_mutex():
https://lists.launchpad.net/kernel-packages/msg187700.html
https://community.nxp.com/thread/432071
I am not sure whether my analysis and results are right.
Could someone please give me explanation?
Thanks in advance :)
Best wishes,
Jia-Ju Bai
Re: [RFC PATCH 1/6] x86/alternative: assert text_mutex is taken
On Wed, 29 Aug 2018 14:00:06 -0700
Sean Christopherson wrote:
> On Wed, Aug 29, 2018 at 08:44:47PM +, Nadav Amit wrote:
> > at 1:13 PM, Sean Christopherson wrote:
> >
> > > On Wed, Aug 29, 2018 at 07:36:22PM +, Nadav Amit wrote:
> > >> at 10:11 AM, Nadav Amit wrote:
> > >>
> > >>> at 1:59 AM, Masami Hiramatsu wrote:
> > >>>
> > On Wed, 29 Aug 2018 01:11:42 -0700
> > Nadav Amit wrote:
> >
> > > Use lockdep to ensure that text_mutex is taken when text_poke() is
> > > called.
> > >
> > > Actually it is not always taken, specifically when it is called by
> > > kgdb,
> > > so take the lock in these cases.
> >
> > Can we really take a mutex in kgdb context?
> >
> > kgdb_arch_remove_breakpoint
> > <- dbg_deactivate_sw_breakpoints
> > <- kgdb_reenter_check
> > <- kgdb_handle_exception
> > <- __kgdb_notify
> > <- kgdb_ll_trap
> > <- do_int3
> > <- kgdb_notify
> > <- die notifier
> >
> > kgdb_arch_set_breakpoint
> > <- dbg_activate_sw_breakpoints
> > <- kgdb_reenter_check
> > <- kgdb_handle_exception
> > ...
> >
> > Both seems called in exception context, so we can not take a mutex
> > lock.
> > I think kgdb needs a special path.
> > >>>
> > >>> You are correct, but I don’t want a special path. Presumably text_mutex
> > >>> is
> > >>> guaranteed not to be taken according to the code.
> > >>>
> > >>> So I guess the only concern is lockdep. Do you see any problem if I
> > >>> change
> > >>> mutex_lock() into mutex_trylock()? It should always succeed, and I can
> > >>> add a
> > >>> warning and a failure path if it fails for some reason.
> > >>
> > >> Err.. This will not work. I think I will drop this patch, since I cannot
> > >> find a proper yet simple assertion. Creating special path just for the
> > >> assertion seems wrong.
> > >
> > > It's probably worth expanding the comment for text_poke() to call out
> > > the kgdb case and reference kgdb_arch_{set,remove}_breakpoint(), whose
> > > code and comments make it explicitly clear why its safe for them to
> > > call text_poke() without acquiring the lock. Might prevent someone
> > > from going down this path again in the future.
> >
> > I thought that the whole point of the patch was to avoid comments, and
> > instead enforce the right behavior. I don’t understand well enough kgdb
> > code, so I cannot attest it does the right thing. What happens if
> > kgdb_do_roundup==0?
>
> As is, the comment is wrong because there are obviously cases where
> text_poke() is called without text_mutex being held. I can't attest
> to the kgdb code either. My thought was to document the exception so
> that if someone does want to try and enforce the right behavior they
> can dive right into the problem instead of having to learn of the kgdb
> gotcha the hard way. Maybe a FIXME is the right approach?
No, kgdb ensures that the text_mutex has not been held right before
calling text_poke. So they also take care the text_mutex. I guess
kgdb_arch_{set,remove}_breakpoint() is supposed to be run under
a special circumstance, like stopping all other threads/cores.
In that case, we can just check the text_mutex is not locked.
Anyway, kgdb is a very rare courner case. I think if CONFIG_KGDB is
enabled, lockdep and any assertion should be disabled, since kgdb
can tweak anything in the kernel with unexpected ways...
Thank you,
--
Masami Hiramatsu
Re: [RFC PATCH 1/6] x86/alternative: assert text_mutex is taken
On Wed, 29 Aug 2018 14:00:06 -0700
Sean Christopherson wrote:
> On Wed, Aug 29, 2018 at 08:44:47PM +, Nadav Amit wrote:
> > at 1:13 PM, Sean Christopherson wrote:
> >
> > > On Wed, Aug 29, 2018 at 07:36:22PM +, Nadav Amit wrote:
> > >> at 10:11 AM, Nadav Amit wrote:
> > >>
> > >>> at 1:59 AM, Masami Hiramatsu wrote:
> > >>>
> > On Wed, 29 Aug 2018 01:11:42 -0700
> > Nadav Amit wrote:
> >
> > > Use lockdep to ensure that text_mutex is taken when text_poke() is
> > > called.
> > >
> > > Actually it is not always taken, specifically when it is called by
> > > kgdb,
> > > so take the lock in these cases.
> >
> > Can we really take a mutex in kgdb context?
> >
> > kgdb_arch_remove_breakpoint
> > <- dbg_deactivate_sw_breakpoints
> > <- kgdb_reenter_check
> > <- kgdb_handle_exception
> > <- __kgdb_notify
> > <- kgdb_ll_trap
> > <- do_int3
> > <- kgdb_notify
> > <- die notifier
> >
> > kgdb_arch_set_breakpoint
> > <- dbg_activate_sw_breakpoints
> > <- kgdb_reenter_check
> > <- kgdb_handle_exception
> > ...
> >
> > Both seems called in exception context, so we can not take a mutex
> > lock.
> > I think kgdb needs a special path.
> > >>>
> > >>> You are correct, but I don’t want a special path. Presumably text_mutex
> > >>> is
> > >>> guaranteed not to be taken according to the code.
> > >>>
> > >>> So I guess the only concern is lockdep. Do you see any problem if I
> > >>> change
> > >>> mutex_lock() into mutex_trylock()? It should always succeed, and I can
> > >>> add a
> > >>> warning and a failure path if it fails for some reason.
> > >>
> > >> Err.. This will not work. I think I will drop this patch, since I cannot
> > >> find a proper yet simple assertion. Creating special path just for the
> > >> assertion seems wrong.
> > >
> > > It's probably worth expanding the comment for text_poke() to call out
> > > the kgdb case and reference kgdb_arch_{set,remove}_breakpoint(), whose
> > > code and comments make it explicitly clear why its safe for them to
> > > call text_poke() without acquiring the lock. Might prevent someone
> > > from going down this path again in the future.
> >
> > I thought that the whole point of the patch was to avoid comments, and
> > instead enforce the right behavior. I don’t understand well enough kgdb
> > code, so I cannot attest it does the right thing. What happens if
> > kgdb_do_roundup==0?
>
> As is, the comment is wrong because there are obviously cases where
> text_poke() is called without text_mutex being held. I can't attest
> to the kgdb code either. My thought was to document the exception so
> that if someone does want to try and enforce the right behavior they
> can dive right into the problem instead of having to learn of the kgdb
> gotcha the hard way. Maybe a FIXME is the right approach?
No, kgdb ensures that the text_mutex has not been held right before
calling text_poke. So they also take care the text_mutex. I guess
kgdb_arch_{set,remove}_breakpoint() is supposed to be run under
a special circumstance, like stopping all other threads/cores.
In that case, we can just check the text_mutex is not locked.
Anyway, kgdb is a very rare courner case. I think if CONFIG_KGDB is
enabled, lockdep and any assertion should be disabled, since kgdb
can tweak anything in the kernel with unexpected ways...
Thank you,
--
Masami Hiramatsu
Re: WARNING in apparmor_secid_to_secctx
On Wed, Aug 29, 2018 at 7:17 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support' > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1536d29640 > kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 > dashboard link: https://syzkaller.appspot.com/bug?extid=21016130b0580a9de3b5 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+21016130b0580a9de...@syzkaller.appspotmail.com Hi John, Tyler, I've switched syzbot from selinux to apparmor as we discussed on lss: https://github.com/google/syzkaller/commit/2c6cb254ae6c06f61e3aba21bb89ffb05b5db946 As expedited fix for this as possible would be nice to get, because we are currently getting 1 machine crash/minute on this bug: https://syzkaller.appspot.com/bug?extid=ab1882df6ecbb06d59be > [ cut here ] > AppArmor WARN apparmor_secid_to_secctx: ((!secdata)): > WARNING: CPU: 0 PID: 14826 at security/apparmor/secid.c:82 > apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 0 PID: 14826 Comm: syz-executor1 Not tainted 4.19.0-rc1+ #193 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 > panic+0x238/0x4e7 kernel/panic.c:184 > __warn.cold.8+0x163/0x1ba kernel/panic.c:536 > report_bug+0x252/0x2d0 lib/bug.c:186 > fixup_bug arch/x86/kernel/traps.c:178 [inline] > do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 > invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 > RIP: 0010:apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 > Code: c7 c7 40 66 58 87 e8 6a 6d 0f fe 0f 0b e9 6c fe ff ff e8 3e aa 44 fe > 48 c7 c6 80 67 58 87 48 c7 c7 a0 65 58 87 e8 4b 6d 0f fe <0f> 0b e9 3f fe ff > ff 48 89 df e8 fc a7 83 fe e9 ed fe ff ff bb f4 > RSP: 0018:8801ba1bed10 EFLAGS: 00010286 > RAX: RBX: 8801ba1beed0 RCX: c9000227e000 > RDX: 00018482 RSI: 8163ac01 RDI: 0001 > RBP: 8801ba1bed30 R08: 8801b80ec080 R09: ed003b603eca > R10: ed003b603eca R11: 8801db01f657 R12: 0001 > R13: R14: R15: 8801ba1beed0 > security_secid_to_secctx+0x63/0xc0 security/security.c:1314 > ctnetlink_secctx_size net/netfilter/nf_conntrack_netlink.c:621 [inline] > ctnetlink_nlmsg_size net/netfilter/nf_conntrack_netlink.c:659 [inline] > ctnetlink_conntrack_event+0x303/0x1470 > net/netfilter/nf_conntrack_netlink.c:706 > nf_conntrack_eventmask_report+0x55f/0x930 > net/netfilter/nf_conntrack_ecache.c:151 > nf_conntrack_event_report include/net/netfilter/nf_conntrack_ecache.h:112 > [inline] > nf_ct_delete+0x33c/0x5d0 net/netfilter/nf_conntrack_core.c:601 > nf_ct_iterate_cleanup+0x48c/0x5e0 net/netfilter/nf_conntrack_core.c:1892 > nf_ct_iterate_cleanup_net+0x23c/0x2d0 > net/netfilter/nf_conntrack_core.c:1974 > ctnetlink_flush_conntrack net/netfilter/nf_conntrack_netlink.c:1226 > [inline] > ctnetlink_del_conntrack+0x66c/0x850 > net/netfilter/nf_conntrack_netlink.c:1258 > nfnetlink_rcv_msg+0xd88/0x1070 net/netfilter/nfnetlink.c:228 > netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454 > nfnetlink_rcv+0x1c0/0x4d0 net/netfilter/nfnetlink.c:560 > netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] > netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 > netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908 > sock_sendmsg_nosec net/socket.c:621 [inline] > sock_sendmsg+0xd5/0x120 net/socket.c:631 > ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 > __sys_sendmsg+0x11d/0x290 net/socket.c:2152 > __do_sys_sendmsg net/socket.c:2161 [inline] > __se_sys_sendmsg net/socket.c:2159 [inline] > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x457089 > Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff > 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7f7bc6e03c78 EFLAGS: 0246 ORIG_RAX: 002e > RAX: ffda RBX: 7f7bc6e046d4 RCX: 00457089 > RDX: RSI: 20d65000 RDI: 0003 > RBP: 009300a0 R08: R09: > R10: R11: 0246 R12: > R13: 004d4588 R14: 004c8d5c R15: > Dumping ftrace buffer: >(ftrace buffer empty) > Kernel Offset:
Re: WARNING in apparmor_secid_to_secctx
On Wed, Aug 29, 2018 at 7:17 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support' > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1536d29640 > kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 > dashboard link: https://syzkaller.appspot.com/bug?extid=21016130b0580a9de3b5 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+21016130b0580a9de...@syzkaller.appspotmail.com Hi John, Tyler, I've switched syzbot from selinux to apparmor as we discussed on lss: https://github.com/google/syzkaller/commit/2c6cb254ae6c06f61e3aba21bb89ffb05b5db946 As expedited fix for this as possible would be nice to get, because we are currently getting 1 machine crash/minute on this bug: https://syzkaller.appspot.com/bug?extid=ab1882df6ecbb06d59be > [ cut here ] > AppArmor WARN apparmor_secid_to_secctx: ((!secdata)): > WARNING: CPU: 0 PID: 14826 at security/apparmor/secid.c:82 > apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 0 PID: 14826 Comm: syz-executor1 Not tainted 4.19.0-rc1+ #193 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 > panic+0x238/0x4e7 kernel/panic.c:184 > __warn.cold.8+0x163/0x1ba kernel/panic.c:536 > report_bug+0x252/0x2d0 lib/bug.c:186 > fixup_bug arch/x86/kernel/traps.c:178 [inline] > do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 > invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 > RIP: 0010:apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 > Code: c7 c7 40 66 58 87 e8 6a 6d 0f fe 0f 0b e9 6c fe ff ff e8 3e aa 44 fe > 48 c7 c6 80 67 58 87 48 c7 c7 a0 65 58 87 e8 4b 6d 0f fe <0f> 0b e9 3f fe ff > ff 48 89 df e8 fc a7 83 fe e9 ed fe ff ff bb f4 > RSP: 0018:8801ba1bed10 EFLAGS: 00010286 > RAX: RBX: 8801ba1beed0 RCX: c9000227e000 > RDX: 00018482 RSI: 8163ac01 RDI: 0001 > RBP: 8801ba1bed30 R08: 8801b80ec080 R09: ed003b603eca > R10: ed003b603eca R11: 8801db01f657 R12: 0001 > R13: R14: R15: 8801ba1beed0 > security_secid_to_secctx+0x63/0xc0 security/security.c:1314 > ctnetlink_secctx_size net/netfilter/nf_conntrack_netlink.c:621 [inline] > ctnetlink_nlmsg_size net/netfilter/nf_conntrack_netlink.c:659 [inline] > ctnetlink_conntrack_event+0x303/0x1470 > net/netfilter/nf_conntrack_netlink.c:706 > nf_conntrack_eventmask_report+0x55f/0x930 > net/netfilter/nf_conntrack_ecache.c:151 > nf_conntrack_event_report include/net/netfilter/nf_conntrack_ecache.h:112 > [inline] > nf_ct_delete+0x33c/0x5d0 net/netfilter/nf_conntrack_core.c:601 > nf_ct_iterate_cleanup+0x48c/0x5e0 net/netfilter/nf_conntrack_core.c:1892 > nf_ct_iterate_cleanup_net+0x23c/0x2d0 > net/netfilter/nf_conntrack_core.c:1974 > ctnetlink_flush_conntrack net/netfilter/nf_conntrack_netlink.c:1226 > [inline] > ctnetlink_del_conntrack+0x66c/0x850 > net/netfilter/nf_conntrack_netlink.c:1258 > nfnetlink_rcv_msg+0xd88/0x1070 net/netfilter/nfnetlink.c:228 > netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454 > nfnetlink_rcv+0x1c0/0x4d0 net/netfilter/nfnetlink.c:560 > netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] > netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 > netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908 > sock_sendmsg_nosec net/socket.c:621 [inline] > sock_sendmsg+0xd5/0x120 net/socket.c:631 > ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 > __sys_sendmsg+0x11d/0x290 net/socket.c:2152 > __do_sys_sendmsg net/socket.c:2161 [inline] > __se_sys_sendmsg net/socket.c:2159 [inline] > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x457089 > Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff > 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7f7bc6e03c78 EFLAGS: 0246 ORIG_RAX: 002e > RAX: ffda RBX: 7f7bc6e046d4 RCX: 00457089 > RDX: RSI: 20d65000 RDI: 0003 > RBP: 009300a0 R08: R09: > R10: R11: 0246 R12: > R13: 004d4588 R14: 004c8d5c R15: > Dumping ftrace buffer: >(ftrace buffer empty) > Kernel Offset:
[PATCH] perf event-parse: Use fixed size string for comms
From: Chris Phlipot
Some implementations of libc do not support the 'm' width modifier
as part of the scanf string format specifier. This can cause the
parsing to fail. Since the parser never checks if the scanf
parsing was successesful, this can result in a crash.
Change the comm string to be allocated as a fixed size instead of
dynamically using 'm' scanf width modifier. This can be safely done
since comm size is limited to 16 bytes by TASK_COMM_LEN within the
kernel.
This change prevents perf from crashing when linked against bionic
as well as reduces the total number of heap allocations and frees
invoked while accomplishing the same task.
Signed-off-by: Chris Phlipot
---
tools/perf/util/trace-event-parse.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/trace-event-parse.c
b/tools/perf/util/trace-event-parse.c
index 920b1d58a068..e76214f8d596 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -164,16 +164,15 @@ void parse_ftrace_printk(struct tep_handle *pevent,
void parse_saved_cmdline(struct tep_handle *pevent,
char *file, unsigned int size __maybe_unused)
{
- char *comm;
+ char comm[17]; /* Max comm length in the kernel is 16. */
char *line;
char *next = NULL;
int pid;
line = strtok_r(file, "\n", );
while (line) {
- sscanf(line, "%d %ms", , );
- tep_register_comm(pevent, comm, pid);
- free(comm);
+ if (sscanf(line, "%d %16s", , comm) == 2)
+ tep_register_comm(pevent, comm, pid);
line = strtok_r(NULL, "\n", );
}
}
--
2.17.1
[PATCH] perf event-parse: Use fixed size string for comms
From: Chris Phlipot
Some implementations of libc do not support the 'm' width modifier
as part of the scanf string format specifier. This can cause the
parsing to fail. Since the parser never checks if the scanf
parsing was successesful, this can result in a crash.
Change the comm string to be allocated as a fixed size instead of
dynamically using 'm' scanf width modifier. This can be safely done
since comm size is limited to 16 bytes by TASK_COMM_LEN within the
kernel.
This change prevents perf from crashing when linked against bionic
as well as reduces the total number of heap allocations and frees
invoked while accomplishing the same task.
Signed-off-by: Chris Phlipot
---
tools/perf/util/trace-event-parse.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/trace-event-parse.c
b/tools/perf/util/trace-event-parse.c
index 920b1d58a068..e76214f8d596 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -164,16 +164,15 @@ void parse_ftrace_printk(struct tep_handle *pevent,
void parse_saved_cmdline(struct tep_handle *pevent,
char *file, unsigned int size __maybe_unused)
{
- char *comm;
+ char comm[17]; /* Max comm length in the kernel is 16. */
char *line;
char *next = NULL;
int pid;
line = strtok_r(file, "\n", );
while (line) {
- sscanf(line, "%d %ms", , );
- tep_register_comm(pevent, comm, pid);
- free(comm);
+ if (sscanf(line, "%d %16s", , comm) == 2)
+ tep_register_comm(pevent, comm, pid);
line = strtok_r(NULL, "\n", );
}
}
--
2.17.1
[PATCH] thermal: qoriq: add i.mx8mq support
Add i.mx8mq specific compatible string.
Signed-off-by: Anson Huang
---
Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 6 +++---
drivers/thermal/qoriq_thermal.c | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
index 20ca4ef..04cbb90 100644
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
@@ -1,9 +1,9 @@
* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
Required properties:
-- compatible : Must include "fsl,qoriq-tmu". The version of the device is
- determined by the TMU IP Block Revision Register (IPBRR0) at
- offset 0x0BF8.
+- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
+ version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
Table of correspondences between IPBRR0 values and example chips:
Value Device
-- -
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index c866cc1..e0e7356 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -305,6 +305,7 @@ static SIMPLE_DEV_PM_OPS(qoriq_tmu_pm_ops,
static const struct of_device_id qoriq_tmu_match[] = {
{ .compatible = "fsl,qoriq-tmu", },
+ { .compatible = "fsl,imx8mq-tmu", },
{},
};
MODULE_DEVICE_TABLE(of, qoriq_tmu_match);
--
2.7.4
[PATCH] thermal: qoriq: add i.mx8mq support
Add i.mx8mq specific compatible string.
Signed-off-by: Anson Huang
---
Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 6 +++---
drivers/thermal/qoriq_thermal.c | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
index 20ca4ef..04cbb90 100644
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
@@ -1,9 +1,9 @@
* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
Required properties:
-- compatible : Must include "fsl,qoriq-tmu". The version of the device is
- determined by the TMU IP Block Revision Register (IPBRR0) at
- offset 0x0BF8.
+- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
+ version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
Table of correspondences between IPBRR0 values and example chips:
Value Device
-- -
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index c866cc1..e0e7356 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -305,6 +305,7 @@ static SIMPLE_DEV_PM_OPS(qoriq_tmu_pm_ops,
static const struct of_device_id qoriq_tmu_match[] = {
{ .compatible = "fsl,qoriq-tmu", },
+ { .compatible = "fsl,imx8mq-tmu", },
{},
};
MODULE_DEVICE_TABLE(of, qoriq_tmu_match);
--
2.7.4
WARNING in apparmor_secid_to_secctx
Hello, syzbot found the following crash on: HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support' git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1536d29640 kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 dashboard link: https://syzkaller.appspot.com/bug?extid=21016130b0580a9de3b5 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+21016130b0580a9de...@syzkaller.appspotmail.com [ cut here ] AppArmor WARN apparmor_secid_to_secctx: ((!secdata)): WARNING: CPU: 0 PID: 14826 at security/apparmor/secid.c:82 apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 14826 Comm: syz-executor1 Not tainted 4.19.0-rc1+ #193 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Code: c7 c7 40 66 58 87 e8 6a 6d 0f fe 0f 0b e9 6c fe ff ff e8 3e aa 44 fe 48 c7 c6 80 67 58 87 48 c7 c7 a0 65 58 87 e8 4b 6d 0f fe <0f> 0b e9 3f fe ff ff 48 89 df e8 fc a7 83 fe e9 ed fe ff ff bb f4 RSP: 0018:8801ba1bed10 EFLAGS: 00010286 RAX: RBX: 8801ba1beed0 RCX: c9000227e000 RDX: 00018482 RSI: 8163ac01 RDI: 0001 RBP: 8801ba1bed30 R08: 8801b80ec080 R09: ed003b603eca R10: ed003b603eca R11: 8801db01f657 R12: 0001 R13: R14: R15: 8801ba1beed0 security_secid_to_secctx+0x63/0xc0 security/security.c:1314 ctnetlink_secctx_size net/netfilter/nf_conntrack_netlink.c:621 [inline] ctnetlink_nlmsg_size net/netfilter/nf_conntrack_netlink.c:659 [inline] ctnetlink_conntrack_event+0x303/0x1470 net/netfilter/nf_conntrack_netlink.c:706 nf_conntrack_eventmask_report+0x55f/0x930 net/netfilter/nf_conntrack_ecache.c:151 nf_conntrack_event_report include/net/netfilter/nf_conntrack_ecache.h:112 [inline] nf_ct_delete+0x33c/0x5d0 net/netfilter/nf_conntrack_core.c:601 nf_ct_iterate_cleanup+0x48c/0x5e0 net/netfilter/nf_conntrack_core.c:1892 nf_ct_iterate_cleanup_net+0x23c/0x2d0 net/netfilter/nf_conntrack_core.c:1974 ctnetlink_flush_conntrack net/netfilter/nf_conntrack_netlink.c:1226 [inline] ctnetlink_del_conntrack+0x66c/0x850 net/netfilter/nf_conntrack_netlink.c:1258 nfnetlink_rcv_msg+0xd88/0x1070 net/netfilter/nfnetlink.c:228 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454 nfnetlink_rcv+0x1c0/0x4d0 net/netfilter/nfnetlink.c:560 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x290 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f7bc6e03c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 7f7bc6e046d4 RCX: 00457089 RDX: RSI: 20d65000 RDI: 0003 RBP: 009300a0 R08: R09: R10: R11: 0246 R12: R13: 004d4588 R14: 004c8d5c R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
WARNING in apparmor_secid_to_secctx
Hello, syzbot found the following crash on: HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support' git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1536d29640 kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 dashboard link: https://syzkaller.appspot.com/bug?extid=21016130b0580a9de3b5 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+21016130b0580a9de...@syzkaller.appspotmail.com [ cut here ] AppArmor WARN apparmor_secid_to_secctx: ((!secdata)): WARNING: CPU: 0 PID: 14826 at security/apparmor/secid.c:82 apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 14826 Comm: syz-executor1 Not tainted 4.19.0-rc1+ #193 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:apparmor_secid_to_secctx+0x2b5/0x2f0 security/apparmor/secid.c:82 Code: c7 c7 40 66 58 87 e8 6a 6d 0f fe 0f 0b e9 6c fe ff ff e8 3e aa 44 fe 48 c7 c6 80 67 58 87 48 c7 c7 a0 65 58 87 e8 4b 6d 0f fe <0f> 0b e9 3f fe ff ff 48 89 df e8 fc a7 83 fe e9 ed fe ff ff bb f4 RSP: 0018:8801ba1bed10 EFLAGS: 00010286 RAX: RBX: 8801ba1beed0 RCX: c9000227e000 RDX: 00018482 RSI: 8163ac01 RDI: 0001 RBP: 8801ba1bed30 R08: 8801b80ec080 R09: ed003b603eca R10: ed003b603eca R11: 8801db01f657 R12: 0001 R13: R14: R15: 8801ba1beed0 security_secid_to_secctx+0x63/0xc0 security/security.c:1314 ctnetlink_secctx_size net/netfilter/nf_conntrack_netlink.c:621 [inline] ctnetlink_nlmsg_size net/netfilter/nf_conntrack_netlink.c:659 [inline] ctnetlink_conntrack_event+0x303/0x1470 net/netfilter/nf_conntrack_netlink.c:706 nf_conntrack_eventmask_report+0x55f/0x930 net/netfilter/nf_conntrack_ecache.c:151 nf_conntrack_event_report include/net/netfilter/nf_conntrack_ecache.h:112 [inline] nf_ct_delete+0x33c/0x5d0 net/netfilter/nf_conntrack_core.c:601 nf_ct_iterate_cleanup+0x48c/0x5e0 net/netfilter/nf_conntrack_core.c:1892 nf_ct_iterate_cleanup_net+0x23c/0x2d0 net/netfilter/nf_conntrack_core.c:1974 ctnetlink_flush_conntrack net/netfilter/nf_conntrack_netlink.c:1226 [inline] ctnetlink_del_conntrack+0x66c/0x850 net/netfilter/nf_conntrack_netlink.c:1258 nfnetlink_rcv_msg+0xd88/0x1070 net/netfilter/nfnetlink.c:228 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454 nfnetlink_rcv+0x1c0/0x4d0 net/netfilter/nfnetlink.c:560 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x290 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f7bc6e03c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 7f7bc6e046d4 RCX: 00457089 RDX: RSI: 20d65000 RDI: 0003 RBP: 009300a0 R08: R09: R10: R11: 0246 R12: R13: 004d4588 R14: 004c8d5c R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
Re: [PATCH] KVM: LAPIC: Fix pv ipis out-of-bounds access
On Wed, 29 Aug 2018 at 23:42, Radim Krcmar wrote: > > 2018-08-29 13:29+0300, Dan Carpenter: > > On Wed, Aug 29, 2018 at 06:23:08PM +0800, Wanpeng Li wrote: > > > On Wed, 29 Aug 2018 at 18:18, Dan Carpenter > > > wrote: > > > > > > > > On Wed, Aug 29, 2018 at 01:12:05PM +0300, Dan Carpenter wrote: > > > > > On Wed, Aug 29, 2018 at 12:05:06PM +0300, Liran Alon wrote: > > > > > > > arch/x86/kvm/lapic.c | 17 + > > > > > > > 1 file changed, 13 insertions(+), 4 deletions(-) > > > > > > > > > > > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > > > > > > index 0cefba2..86e933c 100644 > > > > > > > --- a/arch/x86/kvm/lapic.c > > > > > > > +++ b/arch/x86/kvm/lapic.c > > > > > > > @@ -571,18 +571,27 @@ int kvm_pv_send_ipi(struct kvm *kvm, > > > > > > > unsigned long ipi_bitmap_low, > > > > > > > rcu_read_lock(); > > > > > > > map = rcu_dereference(kvm->arch.apic_map); > > > > > > > > > > > > > > + if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_low)) < > > > > > > > min)) > > > > > > > + goto out; > > > > > > > > > > > > I personally think “if ((min + __fls(ipi_bitmap_low)) > > > > > > > map->max_apic_id)” is more readable. > > > > > > But that’s just a matter of taste :) > > > > > > > > > > That's an integer overflow. > > > > > > > > > > But I do prefer to put the variable on the left. The truth is that > > > > > some > > > > > Smatch checks just ignore code which is backwards written because > > > > > otherwise you have to write duplicate code and the most code is > > > > > written > > > > > with the variable on the left. > > > > > > > > > > if (min > (s32)(map->max_apic_id - __fls(ipi_bitmap_low)) > > > > > > > > Wait, the (s32) cast doesn't make sense. We want negative min values to > > > > be treated as invalid. > > > > > > In v2, how about: > > > > > > if (unlikely(min > map->max_apic_id || (min + __fls(ipi_bitmap_low)) > > > > map->max_apic_id)) > > > goto out; > > > > That works, too. It still has the off by one and we should set > > "count = -KVM_EINVAL;". > > I'd prefer to ignore destinations that are not present and deliver the > rest, possibly nothing, instead of returning an error. > (It's closer to how the real hardware behaves and we already return the > number of notified VCPUs, so the caller can tell whether something went > wrong.) > > Either in the form that I have posted earlier, or as: > > if (min > map->max_apic_id) > goto out; > > for_each_set_bit(i, _bitmap_low, MIN(BITS_PER_LONG, > map->max_apic_id - min + 1)) Do it in v2. Regards, Wanpeng Li
Re: [PATCH] KVM: LAPIC: Fix pv ipis out-of-bounds access
On Wed, 29 Aug 2018 at 23:42, Radim Krcmar wrote: > > 2018-08-29 13:29+0300, Dan Carpenter: > > On Wed, Aug 29, 2018 at 06:23:08PM +0800, Wanpeng Li wrote: > > > On Wed, 29 Aug 2018 at 18:18, Dan Carpenter > > > wrote: > > > > > > > > On Wed, Aug 29, 2018 at 01:12:05PM +0300, Dan Carpenter wrote: > > > > > On Wed, Aug 29, 2018 at 12:05:06PM +0300, Liran Alon wrote: > > > > > > > arch/x86/kvm/lapic.c | 17 + > > > > > > > 1 file changed, 13 insertions(+), 4 deletions(-) > > > > > > > > > > > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > > > > > > index 0cefba2..86e933c 100644 > > > > > > > --- a/arch/x86/kvm/lapic.c > > > > > > > +++ b/arch/x86/kvm/lapic.c > > > > > > > @@ -571,18 +571,27 @@ int kvm_pv_send_ipi(struct kvm *kvm, > > > > > > > unsigned long ipi_bitmap_low, > > > > > > > rcu_read_lock(); > > > > > > > map = rcu_dereference(kvm->arch.apic_map); > > > > > > > > > > > > > > + if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_low)) < > > > > > > > min)) > > > > > > > + goto out; > > > > > > > > > > > > I personally think “if ((min + __fls(ipi_bitmap_low)) > > > > > > > map->max_apic_id)” is more readable. > > > > > > But that’s just a matter of taste :) > > > > > > > > > > That's an integer overflow. > > > > > > > > > > But I do prefer to put the variable on the left. The truth is that > > > > > some > > > > > Smatch checks just ignore code which is backwards written because > > > > > otherwise you have to write duplicate code and the most code is > > > > > written > > > > > with the variable on the left. > > > > > > > > > > if (min > (s32)(map->max_apic_id - __fls(ipi_bitmap_low)) > > > > > > > > Wait, the (s32) cast doesn't make sense. We want negative min values to > > > > be treated as invalid. > > > > > > In v2, how about: > > > > > > if (unlikely(min > map->max_apic_id || (min + __fls(ipi_bitmap_low)) > > > > map->max_apic_id)) > > > goto out; > > > > That works, too. It still has the off by one and we should set > > "count = -KVM_EINVAL;". > > I'd prefer to ignore destinations that are not present and deliver the > rest, possibly nothing, instead of returning an error. > (It's closer to how the real hardware behaves and we already return the > number of notified VCPUs, so the caller can tell whether something went > wrong.) > > Either in the form that I have posted earlier, or as: > > if (min > map->max_apic_id) > goto out; > > for_each_set_bit(i, _bitmap_low, MIN(BITS_PER_LONG, > map->max_apic_id - min + 1)) Do it in v2. Regards, Wanpeng Li
Re: [PATCH tip/core/rcu 3/3] srcu: Make early-boot call_srcu() reuse workqueue lists
On Wed, Aug 29, 2018 at 09:56:16PM -0400, Steven Rostedt wrote:
> On Wed, 29 Aug 2018 14:23:13 -0700
> "Paul E. McKenney" wrote:
>
> > Allocating a list_head structure that is almost never used, and, when
> > used, is used only during early boot (rcu_init() and earlier), is a bit
> > wasteful. This commit therefore eliminates that list_head in favor of
> > the one in the work_struct structure. This is safe because the work_struct
> > structure cannot be used until after rcu_init() returns.
> >
> > Reported-by: Steven Rostedt
> > Signed-off-by: Paul E. McKenney
> > Cc: Tejun Heo
> > Cc: Lai Jiangshan
> > ---
> > include/linux/srcutiny.h | 2 --
> > include/linux/srcutree.h | 3 +--
> > kernel/rcu/srcutiny.c| 10 +-
> > kernel/rcu/srcutree.c| 11 +--
> > 4 files changed, 11 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> > index 2b5c0822e683..f41d2fb09f87 100644
> > --- a/include/linux/srcutiny.h
> > +++ b/include/linux/srcutiny.h
> > @@ -36,7 +36,6 @@ struct srcu_struct {
> > struct rcu_head *srcu_cb_head; /* Pending callbacks: Head. */
> > struct rcu_head **srcu_cb_tail; /* Pending callbacks: Tail. */
> > struct work_struct srcu_work; /* For driving grace periods. */
> > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > struct lockdep_map dep_map;
> > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > @@ -49,7 +48,6 @@ void srcu_drive_gp(struct work_struct *wp);
> > .srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),\
> > .srcu_cb_tail = _cb_head, \
> > .srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp), \
> > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> > __SRCU_DEP_MAP_INIT(name) \
> > }
> >
> > diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> > index 9cfa4610113a..0ae91b3a7406 100644
> > --- a/include/linux/srcutree.h
> > +++ b/include/linux/srcutree.h
> > @@ -94,7 +94,6 @@ struct srcu_struct {
> > /* callback for the barrier */
> > /* operation. */
> > struct delayed_work work;
> > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > struct lockdep_map dep_map;
> > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > @@ -110,7 +109,7 @@ struct srcu_struct {
> > .sda = _name, \
> > .lock = __SPIN_LOCK_UNLOCKED(name.lock),\
> > .srcu_gp_seq_needed = -1UL, \
> > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> > + .work = __DELAYED_WORK_INITIALIZER(name.work, NULL, 0), \
>
> Thanks!
Glad you like it! Does it actually work for you? ;-)
Thanx, Paul
> -- Steve
>
> > __SRCU_DEP_MAP_INIT(name) \
> > }
> >
> > diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> > index d233f0c63f6f..b46e6683f8c9 100644
> > --- a/kernel/rcu/srcutiny.c
> > +++ b/kernel/rcu/srcutiny.c
> > @@ -48,7 +48,7 @@ static int init_srcu_struct_fields(struct srcu_struct *sp)
> > sp->srcu_gp_waiting = false;
> > sp->srcu_idx = 0;
> > INIT_WORK(>srcu_work, srcu_drive_gp);
> > - INIT_LIST_HEAD(>srcu_boot_entry);
> > + INIT_LIST_HEAD(>srcu_work.entry);
> > return 0;
> > }
> >
> > @@ -185,8 +185,8 @@ void call_srcu(struct srcu_struct *sp, struct rcu_head
> > *rhp,
> > if (!READ_ONCE(sp->srcu_gp_running)) {
> > if (likely(srcu_init_done))
> > schedule_work(>srcu_work);
> > - else if (list_empty(>srcu_boot_entry))
> > - list_add(>srcu_boot_entry, _boot_list);
> > + else if (list_empty(>srcu_work.entry))
> > + list_add(>srcu_work.entry, _boot_list);
> > }
> > }
> > EXPORT_SYMBOL_GPL(call_srcu);
> > @@ -224,8 +224,8 @@ void __init srcu_init(void)
> > srcu_init_done = true;
> > while (!list_empty(_boot_list)) {
> > sp = list_first_entry(_boot_list,
> > - struct srcu_struct, srcu_boot_entry);
> > - list_del_init(>srcu_boot_entry);
> > + struct srcu_struct, srcu_work.entry);
> > + list_del_init(>srcu_work.entry);
> > schedule_work(>srcu_work);
> > }
> > }
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index e79c1929328f..36a2857c84e0 100644
> > --- a/kernel/rcu/srcutree.c
> > +++ b/kernel/rcu/srcutree.c
> > @@ -186,7 +186,6 @@ static int init_srcu_struct_fields(struct srcu_struct
> > *sp, bool is_static)
> > mutex_init(>srcu_barrier_mutex);
> >
Re: [PATCH tip/core/rcu 3/3] srcu: Make early-boot call_srcu() reuse workqueue lists
On Wed, Aug 29, 2018 at 09:56:16PM -0400, Steven Rostedt wrote:
> On Wed, 29 Aug 2018 14:23:13 -0700
> "Paul E. McKenney" wrote:
>
> > Allocating a list_head structure that is almost never used, and, when
> > used, is used only during early boot (rcu_init() and earlier), is a bit
> > wasteful. This commit therefore eliminates that list_head in favor of
> > the one in the work_struct structure. This is safe because the work_struct
> > structure cannot be used until after rcu_init() returns.
> >
> > Reported-by: Steven Rostedt
> > Signed-off-by: Paul E. McKenney
> > Cc: Tejun Heo
> > Cc: Lai Jiangshan
> > ---
> > include/linux/srcutiny.h | 2 --
> > include/linux/srcutree.h | 3 +--
> > kernel/rcu/srcutiny.c| 10 +-
> > kernel/rcu/srcutree.c| 11 +--
> > 4 files changed, 11 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> > index 2b5c0822e683..f41d2fb09f87 100644
> > --- a/include/linux/srcutiny.h
> > +++ b/include/linux/srcutiny.h
> > @@ -36,7 +36,6 @@ struct srcu_struct {
> > struct rcu_head *srcu_cb_head; /* Pending callbacks: Head. */
> > struct rcu_head **srcu_cb_tail; /* Pending callbacks: Tail. */
> > struct work_struct srcu_work; /* For driving grace periods. */
> > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > struct lockdep_map dep_map;
> > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > @@ -49,7 +48,6 @@ void srcu_drive_gp(struct work_struct *wp);
> > .srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),\
> > .srcu_cb_tail = _cb_head, \
> > .srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp), \
> > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> > __SRCU_DEP_MAP_INIT(name) \
> > }
> >
> > diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> > index 9cfa4610113a..0ae91b3a7406 100644
> > --- a/include/linux/srcutree.h
> > +++ b/include/linux/srcutree.h
> > @@ -94,7 +94,6 @@ struct srcu_struct {
> > /* callback for the barrier */
> > /* operation. */
> > struct delayed_work work;
> > - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > struct lockdep_map dep_map;
> > #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > @@ -110,7 +109,7 @@ struct srcu_struct {
> > .sda = _name, \
> > .lock = __SPIN_LOCK_UNLOCKED(name.lock),\
> > .srcu_gp_seq_needed = -1UL, \
> > - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> > + .work = __DELAYED_WORK_INITIALIZER(name.work, NULL, 0), \
>
> Thanks!
Glad you like it! Does it actually work for you? ;-)
Thanx, Paul
> -- Steve
>
> > __SRCU_DEP_MAP_INIT(name) \
> > }
> >
> > diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> > index d233f0c63f6f..b46e6683f8c9 100644
> > --- a/kernel/rcu/srcutiny.c
> > +++ b/kernel/rcu/srcutiny.c
> > @@ -48,7 +48,7 @@ static int init_srcu_struct_fields(struct srcu_struct *sp)
> > sp->srcu_gp_waiting = false;
> > sp->srcu_idx = 0;
> > INIT_WORK(>srcu_work, srcu_drive_gp);
> > - INIT_LIST_HEAD(>srcu_boot_entry);
> > + INIT_LIST_HEAD(>srcu_work.entry);
> > return 0;
> > }
> >
> > @@ -185,8 +185,8 @@ void call_srcu(struct srcu_struct *sp, struct rcu_head
> > *rhp,
> > if (!READ_ONCE(sp->srcu_gp_running)) {
> > if (likely(srcu_init_done))
> > schedule_work(>srcu_work);
> > - else if (list_empty(>srcu_boot_entry))
> > - list_add(>srcu_boot_entry, _boot_list);
> > + else if (list_empty(>srcu_work.entry))
> > + list_add(>srcu_work.entry, _boot_list);
> > }
> > }
> > EXPORT_SYMBOL_GPL(call_srcu);
> > @@ -224,8 +224,8 @@ void __init srcu_init(void)
> > srcu_init_done = true;
> > while (!list_empty(_boot_list)) {
> > sp = list_first_entry(_boot_list,
> > - struct srcu_struct, srcu_boot_entry);
> > - list_del_init(>srcu_boot_entry);
> > + struct srcu_struct, srcu_work.entry);
> > + list_del_init(>srcu_work.entry);
> > schedule_work(>srcu_work);
> > }
> > }
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index e79c1929328f..36a2857c84e0 100644
> > --- a/kernel/rcu/srcutree.c
> > +++ b/kernel/rcu/srcutree.c
> > @@ -186,7 +186,6 @@ static int init_srcu_struct_fields(struct srcu_struct
> > *sp, bool is_static)
> > mutex_init(>srcu_barrier_mutex);
> >
[PATCH v2] KVM: LAPIC: Fix pv ipis out-of-bounds access
From: Wanpeng Li
Dan Carpenter reported that the untrusted data returns from kvm_register_read()
results in the following static checker warning:
arch/x86/kvm/lapic.c:576 kvm_pv_send_ipi()
error: buffer underflow 'map->phys_map' 's32min-s32max'
KVM guest can easily trigger this by executing the following assembly sequence
in Ring0:
mov $10, %rax
mov $0x, %rbx
mov $0x, %rdx
mov $0, %rsi
vmcall
As this will cause KVM to execute the following code-path:
vmx_handle_exit() -> handle_vmcall() -> kvm_emulate_hypercall() ->
kvm_pv_send_ipi()
which will reach out-of-bounds access.
This patch fixes it by adding a check to kvm_pv_send_ipi() against
map->max_apic_id,
ignoring destinations that are not present and delivering the rest. We also
check
whether or not map->phys_map[min + i] is NULL since the max_apic_id is set to
the
max apic id, some phys_map maybe NULL when apic id is sparse, especially kvm
unconditionally set max_apic_id to 255 to reserve enough space for any xAPIC ID.
Reported-by: Dan Carpenter
Reviewed-by: Liran Alon
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Liran Alon
Cc: Dan Carpenter
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* add min > map->max_apic_id check
* change min to u32
* add min((u32)BITS_PER_LONG, (map->max_apic_id - min + 1))
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/lapic.c| 23 ---
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 00ddb0c..e6534b3 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1463,7 +1463,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool
init_event);
void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu);
int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
- unsigned long ipi_bitmap_high, int min,
+ unsigned long ipi_bitmap_high, u32 min,
unsigned long icr, int op_64_bit);
u64 kvm_get_arch_capabilities(void);
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0cefba2..7de605c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -548,7 +548,7 @@ int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct
kvm_lapic_irq *irq,
}
int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
- unsigned long ipi_bitmap_high, int min,
+ unsigned long ipi_bitmap_high, u32 min,
unsigned long icr, int op_64_bit)
{
int i;
@@ -571,18 +571,27 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long
ipi_bitmap_low,
rcu_read_lock();
map = rcu_dereference(kvm->arch.apic_map);
+ if (min > map->max_apic_id)
+ goto out;
/* Bits above cluster_size are masked in the caller. */
- for_each_set_bit(i, _bitmap_low, BITS_PER_LONG) {
- vcpu = map->phys_map[min + i]->vcpu;
- count += kvm_apic_set_irq(vcpu, , NULL);
+ for_each_set_bit(i, _bitmap_low,
+ min((u32)BITS_PER_LONG, (map->max_apic_id - min + 1))) {
+ if (map->phys_map[min + i]) {
+ vcpu = map->phys_map[min + i]->vcpu;
+ count += kvm_apic_set_irq(vcpu, , NULL);
+ }
}
min += cluster_size;
- for_each_set_bit(i, _bitmap_high, BITS_PER_LONG) {
- vcpu = map->phys_map[min + i]->vcpu;
- count += kvm_apic_set_irq(vcpu, , NULL);
+ for_each_set_bit(i, _bitmap_high,
+ min((u32)BITS_PER_LONG, (map->max_apic_id - min + 1))) {
+ if (map->phys_map[min + i]) {
+ vcpu = map->phys_map[min + i]->vcpu;
+ count += kvm_apic_set_irq(vcpu, , NULL);
+ }
}
+out:
rcu_read_unlock();
return count;
}
--
2.7.4
[PATCH v2] KVM: LAPIC: Fix pv ipis out-of-bounds access
From: Wanpeng Li
Dan Carpenter reported that the untrusted data returns from kvm_register_read()
results in the following static checker warning:
arch/x86/kvm/lapic.c:576 kvm_pv_send_ipi()
error: buffer underflow 'map->phys_map' 's32min-s32max'
KVM guest can easily trigger this by executing the following assembly sequence
in Ring0:
mov $10, %rax
mov $0x, %rbx
mov $0x, %rdx
mov $0, %rsi
vmcall
As this will cause KVM to execute the following code-path:
vmx_handle_exit() -> handle_vmcall() -> kvm_emulate_hypercall() ->
kvm_pv_send_ipi()
which will reach out-of-bounds access.
This patch fixes it by adding a check to kvm_pv_send_ipi() against
map->max_apic_id,
ignoring destinations that are not present and delivering the rest. We also
check
whether or not map->phys_map[min + i] is NULL since the max_apic_id is set to
the
max apic id, some phys_map maybe NULL when apic id is sparse, especially kvm
unconditionally set max_apic_id to 255 to reserve enough space for any xAPIC ID.
Reported-by: Dan Carpenter
Reviewed-by: Liran Alon
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Liran Alon
Cc: Dan Carpenter
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* add min > map->max_apic_id check
* change min to u32
* add min((u32)BITS_PER_LONG, (map->max_apic_id - min + 1))
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/lapic.c| 23 ---
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 00ddb0c..e6534b3 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1463,7 +1463,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool
init_event);
void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu);
int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
- unsigned long ipi_bitmap_high, int min,
+ unsigned long ipi_bitmap_high, u32 min,
unsigned long icr, int op_64_bit);
u64 kvm_get_arch_capabilities(void);
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0cefba2..7de605c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -548,7 +548,7 @@ int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct
kvm_lapic_irq *irq,
}
int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
- unsigned long ipi_bitmap_high, int min,
+ unsigned long ipi_bitmap_high, u32 min,
unsigned long icr, int op_64_bit)
{
int i;
@@ -571,18 +571,27 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long
ipi_bitmap_low,
rcu_read_lock();
map = rcu_dereference(kvm->arch.apic_map);
+ if (min > map->max_apic_id)
+ goto out;
/* Bits above cluster_size are masked in the caller. */
- for_each_set_bit(i, _bitmap_low, BITS_PER_LONG) {
- vcpu = map->phys_map[min + i]->vcpu;
- count += kvm_apic_set_irq(vcpu, , NULL);
+ for_each_set_bit(i, _bitmap_low,
+ min((u32)BITS_PER_LONG, (map->max_apic_id - min + 1))) {
+ if (map->phys_map[min + i]) {
+ vcpu = map->phys_map[min + i]->vcpu;
+ count += kvm_apic_set_irq(vcpu, , NULL);
+ }
}
min += cluster_size;
- for_each_set_bit(i, _bitmap_high, BITS_PER_LONG) {
- vcpu = map->phys_map[min + i]->vcpu;
- count += kvm_apic_set_irq(vcpu, , NULL);
+ for_each_set_bit(i, _bitmap_high,
+ min((u32)BITS_PER_LONG, (map->max_apic_id - min + 1))) {
+ if (map->phys_map[min + i]) {
+ vcpu = map->phys_map[min + i]->vcpu;
+ count += kvm_apic_set_irq(vcpu, , NULL);
+ }
}
+out:
rcu_read_unlock();
return count;
}
--
2.7.4
Re: [PATCH tip/core/rcu 0/52] Remove rcu_state pointers for v4.20/v5.0
On Wed, 29 Aug 2018 15:38:30 -0700 "Paul E. McKenney" wrote: > Hello! > > This commit does RCU-consolidation cleanups that get rid of pointers to > the sole remaining rcu_state structure: > > 1-40: Remove the "rsp" parameter from numerous functions, given that > the corresponding argument will always be _state. Hmm, couldn't 1-40 have been made into a single patch? -- Steve > > 41. Remove rcu_data structure's ->rsp field, now that it always > contains a pointer to rcu_state. > > 42. Remove non-flavor-traversal rsp local variable from tree_plugin.h. > > 43. Remove the for_each_rcu_flavor() flavor-traversal macro, given > that there is now only ever one flavor to traverse. > > 44. Simplify rcutorture_get_gp_data() based on there now being only > one rcu_state structure. > > 45. Restructure rcu_check_gp_kthread_starvation() based on there > now being only one rcu_state structure. > > 46. Restructure RCU CPU stall warnings based on there now being only > one rcu_state structure. > > 47. Restructure grace-period management code based on there now being > only one rcu_state structure. > > 48. Restructure callback registration/invocation code based on there > now being only one rcu_state structure. > > 49. Restructure quiescent-state and grace-period-nonstart code based > on there now being only one rcu_state structure. > > 50. Restructure rcu_barrier() based on there now being only one > rcu_state structure. > > 51. Restructure initialization code based on there now being only > one rcu_state structure. > > 52. Fix typo in force_qs_rnp()'s parameter's parameter, which was > located by searching for "rsp". > > Thanx, Paul > > > > Documentation/RCU/Design/Data-Structures/Data-Structures.html | 23 > kernel/rcu/rcu.h | 28 > kernel/rcu/srcutree.c |4 > kernel/rcu/tree.c | 1261 > -- > kernel/rcu/tree.h | 29 > kernel/rcu/tree_exp.h | 209 - > kernel/rcu/tree_plugin.h | 203 - > 7 files changed, 784 insertions(+), 973 deletions(-)
Re: [PATCH tip/core/rcu 0/52] Remove rcu_state pointers for v4.20/v5.0
On Wed, 29 Aug 2018 15:38:30 -0700 "Paul E. McKenney" wrote: > Hello! > > This commit does RCU-consolidation cleanups that get rid of pointers to > the sole remaining rcu_state structure: > > 1-40: Remove the "rsp" parameter from numerous functions, given that > the corresponding argument will always be _state. Hmm, couldn't 1-40 have been made into a single patch? -- Steve > > 41. Remove rcu_data structure's ->rsp field, now that it always > contains a pointer to rcu_state. > > 42. Remove non-flavor-traversal rsp local variable from tree_plugin.h. > > 43. Remove the for_each_rcu_flavor() flavor-traversal macro, given > that there is now only ever one flavor to traverse. > > 44. Simplify rcutorture_get_gp_data() based on there now being only > one rcu_state structure. > > 45. Restructure rcu_check_gp_kthread_starvation() based on there > now being only one rcu_state structure. > > 46. Restructure RCU CPU stall warnings based on there now being only > one rcu_state structure. > > 47. Restructure grace-period management code based on there now being > only one rcu_state structure. > > 48. Restructure callback registration/invocation code based on there > now being only one rcu_state structure. > > 49. Restructure quiescent-state and grace-period-nonstart code based > on there now being only one rcu_state structure. > > 50. Restructure rcu_barrier() based on there now being only one > rcu_state structure. > > 51. Restructure initialization code based on there now being only > one rcu_state structure. > > 52. Fix typo in force_qs_rnp()'s parameter's parameter, which was > located by searching for "rsp". > > Thanx, Paul > > > > Documentation/RCU/Design/Data-Structures/Data-Structures.html | 23 > kernel/rcu/rcu.h | 28 > kernel/rcu/srcutree.c |4 > kernel/rcu/tree.c | 1261 > -- > kernel/rcu/tree.h | 29 > kernel/rcu/tree_exp.h | 209 - > kernel/rcu/tree_plugin.h | 203 - > 7 files changed, 784 insertions(+), 973 deletions(-)
Re: [RFC PATCH 2/6] x86/mm: temporary mm struct
> On Aug 29, 2018, at 6:38 PM, Masami Hiramatsu wrote:
>
> On Wed, 29 Aug 2018 08:41:00 -0700
> Andy Lutomirski wrote:
>
>>> On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu
>>> wrote:
>>> On Wed, 29 Aug 2018 01:11:43 -0700
>>> Nadav Amit wrote:
>>>
From: Andy Lutomirski
Sometimes we want to set a temporary page-table entries (PTEs) in one of
the cores, without allowing other cores to use - even speculatively -
these mappings. There are two benefits for doing so:
(1) Security: if sensitive PTEs are set, temporary mm prevents their use
in other cores. This hardens the security as it prevents exploding a
dangling pointer to overwrite sensitive data using the sensitive PTE.
(2) Avoiding TLB shootdowns: the PTEs do not need to be flushed in
remote page-tables.
To do so a temporary mm_struct can be used. Mappings which are private
for this mm can be set in the userspace part of the address-space.
During the whole time in which the temporary mm is loaded, interrupts
must be disabled.
The first use-case for temporary PTEs, which will follow, is for poking
the kernel text.
[ Commit message was written by Nadav ]
Cc: Andy Lutomirski
Cc: Masami Hiramatsu
Cc: Kees Cook
Cc: Peter Zijlstra
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/mmu_context.h | 20
1 file changed, 20 insertions(+)
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index eeeb9289c764..96afc8c0cf15 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -338,4 +338,24 @@ static inline unsigned long
__get_current_cr3_fast(void)
return cr3;
}
+typedef struct {
+ struct mm_struct *prev;
+} temporary_mm_state_t;
+
+static inline temporary_mm_state_t use_temporary_mm(struct mm_struct *mm)
+{
+ temporary_mm_state_t state;
+
+ lockdep_assert_irqs_disabled();
+ state.prev = this_cpu_read(cpu_tlbstate.loaded_mm);
+ switch_mm_irqs_off(NULL, mm, current);
+ return state;
+}
>>>
>>> Hmm, why don't we return mm_struct *prev directly?
>>
>> I did it this way to make it easier to add future debugging stuff
>> later. Also, when I first wrote this, I stashed the old CR3 instead
>> of the old mm_struct, and it seemed like callers should be insulated
>> from details like this.
>
> Hmm, I see. But in that case, we should call it "struct temporary_mm"
> and explicitly allocate (and pass) it, since we can not return the
> data structure from stack.
Why not?
> If we can combine it with new mm, it will
> be more encapsulated e.g.
>
> struct temporary_mm {
>struct mm_struct *mm;
>struct mm_struct *prev;
> };
>
> static struct temporary_mm poking_tmp_mm;
>
> poking_init()
> {
>if (init_temporary_mm(_mm, _mm))
>goto error;
>...
> }
>
> text_poke_safe()
> {
>...
>use_temporary_mm(_mm);
>...
>unuse_temporary_mm(_mm);
> }
>
> Any thought?
That seems more complicated for not very much gain.
Re: [RFC PATCH 2/6] x86/mm: temporary mm struct
> On Aug 29, 2018, at 6:38 PM, Masami Hiramatsu wrote:
>
> On Wed, 29 Aug 2018 08:41:00 -0700
> Andy Lutomirski wrote:
>
>>> On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu
>>> wrote:
>>> On Wed, 29 Aug 2018 01:11:43 -0700
>>> Nadav Amit wrote:
>>>
From: Andy Lutomirski
Sometimes we want to set a temporary page-table entries (PTEs) in one of
the cores, without allowing other cores to use - even speculatively -
these mappings. There are two benefits for doing so:
(1) Security: if sensitive PTEs are set, temporary mm prevents their use
in other cores. This hardens the security as it prevents exploding a
dangling pointer to overwrite sensitive data using the sensitive PTE.
(2) Avoiding TLB shootdowns: the PTEs do not need to be flushed in
remote page-tables.
To do so a temporary mm_struct can be used. Mappings which are private
for this mm can be set in the userspace part of the address-space.
During the whole time in which the temporary mm is loaded, interrupts
must be disabled.
The first use-case for temporary PTEs, which will follow, is for poking
the kernel text.
[ Commit message was written by Nadav ]
Cc: Andy Lutomirski
Cc: Masami Hiramatsu
Cc: Kees Cook
Cc: Peter Zijlstra
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/mmu_context.h | 20
1 file changed, 20 insertions(+)
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index eeeb9289c764..96afc8c0cf15 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -338,4 +338,24 @@ static inline unsigned long
__get_current_cr3_fast(void)
return cr3;
}
+typedef struct {
+ struct mm_struct *prev;
+} temporary_mm_state_t;
+
+static inline temporary_mm_state_t use_temporary_mm(struct mm_struct *mm)
+{
+ temporary_mm_state_t state;
+
+ lockdep_assert_irqs_disabled();
+ state.prev = this_cpu_read(cpu_tlbstate.loaded_mm);
+ switch_mm_irqs_off(NULL, mm, current);
+ return state;
+}
>>>
>>> Hmm, why don't we return mm_struct *prev directly?
>>
>> I did it this way to make it easier to add future debugging stuff
>> later. Also, when I first wrote this, I stashed the old CR3 instead
>> of the old mm_struct, and it seemed like callers should be insulated
>> from details like this.
>
> Hmm, I see. But in that case, we should call it "struct temporary_mm"
> and explicitly allocate (and pass) it, since we can not return the
> data structure from stack.
Why not?
> If we can combine it with new mm, it will
> be more encapsulated e.g.
>
> struct temporary_mm {
>struct mm_struct *mm;
>struct mm_struct *prev;
> };
>
> static struct temporary_mm poking_tmp_mm;
>
> poking_init()
> {
>if (init_temporary_mm(_mm, _mm))
>goto error;
>...
> }
>
> text_poke_safe()
> {
>...
>use_temporary_mm(_mm);
>...
>unuse_temporary_mm(_mm);
> }
>
> Any thought?
That seems more complicated for not very much gain.
Re: [4.14.66-rt40] [report][cpuhotplug] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:974
On Wed, 29 Aug 2018 16:28:50 -0500 Grygorii Strashko wrote: > On 08/29/2018 09:08 AM, Sebastian Andrzej Siewior wrote: > > On 2018-08-28 18:28:42 [-0500], Grygorii Strashko wrote: > > [...] > > >> [0.912275] [] alloc_pages_current+0xcc/0xe0 > >> [0.912287] [] its_allocate_pending_table+0x60/0xa0 > >> [0.912295] [] its_cpu_init+0x2a0/0x380 > >> [0.912303] [] gic_cpu_init.part.6+0x15c/0x170 > >> [0.912311] [] gic_starting_cpu+0x14/0x20 > > > > This is fixed by > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/irqchip-gic-v3-its-Make-its_lock-a-raw_spin_lock_t.patch?h=linux-4.18.y-rt-patches > > > [1] > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/irqchip-gic-v3-its-Move-ITS-pend_page-allocation-int.patch?h=linux-4.18.y-rt-patches > > > [2] > > > > in the v4.18 tree. The first patch was merged upstream. The second will > > be replaced by the patches Marc Zyngier proposed in > >https://lkml.kernel.org/r/3302f069-8f4e-8d97-5166-0dec01b43...@arm.com > > > > I plan to test + replace those for the next v4.18 release. > > Thank you. Are there any plans to back port them for 4.14-rt? > Patch [1] need to be reworked a bit, [2] - I was able to cherry-pick from > 4.18-rt. > Next week I plan on looking into the patches that need to be backported. There's quite a lot of them. -- Steve
Re: [4.14.66-rt40] [report][cpuhotplug] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:974
On Wed, 29 Aug 2018 16:28:50 -0500 Grygorii Strashko wrote: > On 08/29/2018 09:08 AM, Sebastian Andrzej Siewior wrote: > > On 2018-08-28 18:28:42 [-0500], Grygorii Strashko wrote: > > [...] > > >> [0.912275] [] alloc_pages_current+0xcc/0xe0 > >> [0.912287] [] its_allocate_pending_table+0x60/0xa0 > >> [0.912295] [] its_cpu_init+0x2a0/0x380 > >> [0.912303] [] gic_cpu_init.part.6+0x15c/0x170 > >> [0.912311] [] gic_starting_cpu+0x14/0x20 > > > > This is fixed by > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/irqchip-gic-v3-its-Make-its_lock-a-raw_spin_lock_t.patch?h=linux-4.18.y-rt-patches > > > [1] > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/irqchip-gic-v3-its-Move-ITS-pend_page-allocation-int.patch?h=linux-4.18.y-rt-patches > > > [2] > > > > in the v4.18 tree. The first patch was merged upstream. The second will > > be replaced by the patches Marc Zyngier proposed in > >https://lkml.kernel.org/r/3302f069-8f4e-8d97-5166-0dec01b43...@arm.com > > > > I plan to test + replace those for the next v4.18 release. > > Thank you. Are there any plans to back port them for 4.14-rt? > Patch [1] need to be reworked a bit, [2] - I was able to cherry-pick from > 4.18-rt. > Next week I plan on looking into the patches that need to be backported. There's quite a lot of them. -- Steve
Re: [PATCH tip/core/rcu 3/3] srcu: Make early-boot call_srcu() reuse workqueue lists
On Wed, 29 Aug 2018 14:23:13 -0700
"Paul E. McKenney" wrote:
> Allocating a list_head structure that is almost never used, and, when
> used, is used only during early boot (rcu_init() and earlier), is a bit
> wasteful. This commit therefore eliminates that list_head in favor of
> the one in the work_struct structure. This is safe because the work_struct
> structure cannot be used until after rcu_init() returns.
>
> Reported-by: Steven Rostedt
> Signed-off-by: Paul E. McKenney
> Cc: Tejun Heo
> Cc: Lai Jiangshan
> ---
> include/linux/srcutiny.h | 2 --
> include/linux/srcutree.h | 3 +--
> kernel/rcu/srcutiny.c| 10 +-
> kernel/rcu/srcutree.c| 11 +--
> 4 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> index 2b5c0822e683..f41d2fb09f87 100644
> --- a/include/linux/srcutiny.h
> +++ b/include/linux/srcutiny.h
> @@ -36,7 +36,6 @@ struct srcu_struct {
> struct rcu_head *srcu_cb_head; /* Pending callbacks: Head. */
> struct rcu_head **srcu_cb_tail; /* Pending callbacks: Tail. */
> struct work_struct srcu_work; /* For driving grace periods. */
> - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> struct lockdep_map dep_map;
> #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> @@ -49,7 +48,6 @@ void srcu_drive_gp(struct work_struct *wp);
> .srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),\
> .srcu_cb_tail = _cb_head, \
> .srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp), \
> - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> __SRCU_DEP_MAP_INIT(name) \
> }
>
> diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> index 9cfa4610113a..0ae91b3a7406 100644
> --- a/include/linux/srcutree.h
> +++ b/include/linux/srcutree.h
> @@ -94,7 +94,6 @@ struct srcu_struct {
> /* callback for the barrier */
> /* operation. */
> struct delayed_work work;
> - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> struct lockdep_map dep_map;
> #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> @@ -110,7 +109,7 @@ struct srcu_struct {
> .sda = _name, \
> .lock = __SPIN_LOCK_UNLOCKED(name.lock),\
> .srcu_gp_seq_needed = -1UL, \
> - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> + .work = __DELAYED_WORK_INITIALIZER(name.work, NULL, 0), \
Thanks!
-- Steve
> __SRCU_DEP_MAP_INIT(name) \
> }
>
> diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> index d233f0c63f6f..b46e6683f8c9 100644
> --- a/kernel/rcu/srcutiny.c
> +++ b/kernel/rcu/srcutiny.c
> @@ -48,7 +48,7 @@ static int init_srcu_struct_fields(struct srcu_struct *sp)
> sp->srcu_gp_waiting = false;
> sp->srcu_idx = 0;
> INIT_WORK(>srcu_work, srcu_drive_gp);
> - INIT_LIST_HEAD(>srcu_boot_entry);
> + INIT_LIST_HEAD(>srcu_work.entry);
> return 0;
> }
>
> @@ -185,8 +185,8 @@ void call_srcu(struct srcu_struct *sp, struct rcu_head
> *rhp,
> if (!READ_ONCE(sp->srcu_gp_running)) {
> if (likely(srcu_init_done))
> schedule_work(>srcu_work);
> - else if (list_empty(>srcu_boot_entry))
> - list_add(>srcu_boot_entry, _boot_list);
> + else if (list_empty(>srcu_work.entry))
> + list_add(>srcu_work.entry, _boot_list);
> }
> }
> EXPORT_SYMBOL_GPL(call_srcu);
> @@ -224,8 +224,8 @@ void __init srcu_init(void)
> srcu_init_done = true;
> while (!list_empty(_boot_list)) {
> sp = list_first_entry(_boot_list,
> - struct srcu_struct, srcu_boot_entry);
> - list_del_init(>srcu_boot_entry);
> + struct srcu_struct, srcu_work.entry);
> + list_del_init(>srcu_work.entry);
> schedule_work(>srcu_work);
> }
> }
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index e79c1929328f..36a2857c84e0 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -186,7 +186,6 @@ static int init_srcu_struct_fields(struct srcu_struct
> *sp, bool is_static)
> mutex_init(>srcu_barrier_mutex);
> atomic_set(>srcu_barrier_cpu_cnt, 0);
> INIT_DELAYED_WORK(>work, process_srcu);
> - INIT_LIST_HEAD(>srcu_boot_entry);
> if (!is_static)
> sp->sda = alloc_percpu(struct srcu_data);
> init_srcu_struct_nodes(sp, is_static);
> @@ -709,8 +708,8 @@ static void srcu_funnel_gp_start(struct
Re: [PATCH tip/core/rcu 3/3] srcu: Make early-boot call_srcu() reuse workqueue lists
On Wed, 29 Aug 2018 14:23:13 -0700
"Paul E. McKenney" wrote:
> Allocating a list_head structure that is almost never used, and, when
> used, is used only during early boot (rcu_init() and earlier), is a bit
> wasteful. This commit therefore eliminates that list_head in favor of
> the one in the work_struct structure. This is safe because the work_struct
> structure cannot be used until after rcu_init() returns.
>
> Reported-by: Steven Rostedt
> Signed-off-by: Paul E. McKenney
> Cc: Tejun Heo
> Cc: Lai Jiangshan
> ---
> include/linux/srcutiny.h | 2 --
> include/linux/srcutree.h | 3 +--
> kernel/rcu/srcutiny.c| 10 +-
> kernel/rcu/srcutree.c| 11 +--
> 4 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> index 2b5c0822e683..f41d2fb09f87 100644
> --- a/include/linux/srcutiny.h
> +++ b/include/linux/srcutiny.h
> @@ -36,7 +36,6 @@ struct srcu_struct {
> struct rcu_head *srcu_cb_head; /* Pending callbacks: Head. */
> struct rcu_head **srcu_cb_tail; /* Pending callbacks: Tail. */
> struct work_struct srcu_work; /* For driving grace periods. */
> - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> struct lockdep_map dep_map;
> #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> @@ -49,7 +48,6 @@ void srcu_drive_gp(struct work_struct *wp);
> .srcu_wq = __SWAIT_QUEUE_HEAD_INITIALIZER(name.srcu_wq),\
> .srcu_cb_tail = _cb_head, \
> .srcu_work = __WORK_INITIALIZER(name.srcu_work, srcu_drive_gp), \
> - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> __SRCU_DEP_MAP_INIT(name) \
> }
>
> diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
> index 9cfa4610113a..0ae91b3a7406 100644
> --- a/include/linux/srcutree.h
> +++ b/include/linux/srcutree.h
> @@ -94,7 +94,6 @@ struct srcu_struct {
> /* callback for the barrier */
> /* operation. */
> struct delayed_work work;
> - struct list_head srcu_boot_entry; /* Early-boot callbacks. */
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> struct lockdep_map dep_map;
> #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> @@ -110,7 +109,7 @@ struct srcu_struct {
> .sda = _name, \
> .lock = __SPIN_LOCK_UNLOCKED(name.lock),\
> .srcu_gp_seq_needed = -1UL, \
> - .srcu_boot_entry = LIST_HEAD_INIT(name.srcu_boot_entry),\
> + .work = __DELAYED_WORK_INITIALIZER(name.work, NULL, 0), \
Thanks!
-- Steve
> __SRCU_DEP_MAP_INIT(name) \
> }
>
> diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> index d233f0c63f6f..b46e6683f8c9 100644
> --- a/kernel/rcu/srcutiny.c
> +++ b/kernel/rcu/srcutiny.c
> @@ -48,7 +48,7 @@ static int init_srcu_struct_fields(struct srcu_struct *sp)
> sp->srcu_gp_waiting = false;
> sp->srcu_idx = 0;
> INIT_WORK(>srcu_work, srcu_drive_gp);
> - INIT_LIST_HEAD(>srcu_boot_entry);
> + INIT_LIST_HEAD(>srcu_work.entry);
> return 0;
> }
>
> @@ -185,8 +185,8 @@ void call_srcu(struct srcu_struct *sp, struct rcu_head
> *rhp,
> if (!READ_ONCE(sp->srcu_gp_running)) {
> if (likely(srcu_init_done))
> schedule_work(>srcu_work);
> - else if (list_empty(>srcu_boot_entry))
> - list_add(>srcu_boot_entry, _boot_list);
> + else if (list_empty(>srcu_work.entry))
> + list_add(>srcu_work.entry, _boot_list);
> }
> }
> EXPORT_SYMBOL_GPL(call_srcu);
> @@ -224,8 +224,8 @@ void __init srcu_init(void)
> srcu_init_done = true;
> while (!list_empty(_boot_list)) {
> sp = list_first_entry(_boot_list,
> - struct srcu_struct, srcu_boot_entry);
> - list_del_init(>srcu_boot_entry);
> + struct srcu_struct, srcu_work.entry);
> + list_del_init(>srcu_work.entry);
> schedule_work(>srcu_work);
> }
> }
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index e79c1929328f..36a2857c84e0 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -186,7 +186,6 @@ static int init_srcu_struct_fields(struct srcu_struct
> *sp, bool is_static)
> mutex_init(>srcu_barrier_mutex);
> atomic_set(>srcu_barrier_cpu_cnt, 0);
> INIT_DELAYED_WORK(>work, process_srcu);
> - INIT_LIST_HEAD(>srcu_boot_entry);
> if (!is_static)
> sp->sda = alloc_percpu(struct srcu_data);
> init_srcu_struct_nodes(sp, is_static);
> @@ -709,8 +708,8 @@ static void srcu_funnel_gp_start(struct
Re: [PATCH] mm/page_alloc: Clean up check_for_memory
On 8/28/18 5:01 PM, Oscar Salvador wrote:
> From: Oscar Salvador
>
> check_for_memory looks a bit confusing.
> First of all, we have this:
>
> if (N_MEMORY == N_NORMAL_MEMORY)
> return;
>
> Checking the ENUM declaration, looks like N_MEMORY canot be equal to
> N_NORMAL_MEMORY.
> I could not find where N_MEMORY is set to N_NORMAL_MEMORY, or the other
> way around either, so unless I am missing something, this condition
> will never evaluate to true.
> It makes sense to get rid of it.
>
> Moving forward, the operations whithin the loop look a bit confusing
> as well.
>
> We set N_HIGH_MEMORY unconditionally, and then we set N_NORMAL_MEMORY
> in case we have CONFIG_HIGHMEM (N_NORMAL_MEMORY != N_HIGH_MEMORY)
> and zone <= ZONE_NORMAL.
> (N_HIGH_MEMORY falls back to N_NORMAL_MEMORY on !CONFIG_HIGHMEM systems,
> and that is why we can just go ahead and set N_HIGH_MEMORY unconditionally)
>
> Although this works, it is a bit subtle.
>
> I think that this could be easier to follow:
>
> First, we should only set N_HIGH_MEMORY in case we have
> CONFIG_HIGHMEM.
> And then we should set N_NORMAL_MEMORY in case zone <= ZONE_NORMAL,
> without further checking whether we have CONFIG_HIGHMEM or not.
>
> Signed-off-by: Oscar Salvador
> ---
> mm/page_alloc.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 839e0cc17f2c..6aa947f9e614 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6819,15 +6819,12 @@ static void check_for_memory(pg_data_t *pgdat, int
> nid)
> {
> enum zone_type zone_type;
>
> - if (N_MEMORY == N_NORMAL_MEMORY)
> - return;
> -
> for (zone_type = 0; zone_type <= ZONE_MOVABLE - 1; zone_type++) {
> struct zone *zone = >node_zones[zone_type];
> if (populated_zone(zone)) {
> - node_set_state(nid, N_HIGH_MEMORY);
> - if (N_NORMAL_MEMORY != N_HIGH_MEMORY &&
> - zone_type <= ZONE_NORMAL)
> + if (IS_ENABLED(CONFIG_HIGHMEM))
> + node_set_state(nid, N_HIGH_MEMORY);
> + if (zone_type <= ZONE_NORMAL)
> node_set_state(nid, N_NORMAL_MEMORY);
> break;
> }
>
I would re-write the above function like this:
static void check_for_memory(pg_data_t *pgdat, int nid)
{
enum zone_type zone_type;
for (zone_type = 0; zone_type < ZONE_MOVABLE; zone_type++) {
if (populated_zone(>node_zones[zone_type])) {
node_set_state(nid, zone_type <= ZONE_NORMAL ?
N_NORMAL_MEMORY: N_HIGH_MEMORY);
break;
}
}
}
zone_type <= ZONE_MOVABLE - 1
is the same as:
zone_type < ZONE_MOVABLE
If zone > ZONE_NORMAL, it means that CONFIG_HIGHMEM is enabled, no need to
check for it.
Pavel
Re: [PATCH] mm/page_alloc: Clean up check_for_memory
On 8/28/18 5:01 PM, Oscar Salvador wrote:
> From: Oscar Salvador
>
> check_for_memory looks a bit confusing.
> First of all, we have this:
>
> if (N_MEMORY == N_NORMAL_MEMORY)
> return;
>
> Checking the ENUM declaration, looks like N_MEMORY canot be equal to
> N_NORMAL_MEMORY.
> I could not find where N_MEMORY is set to N_NORMAL_MEMORY, or the other
> way around either, so unless I am missing something, this condition
> will never evaluate to true.
> It makes sense to get rid of it.
>
> Moving forward, the operations whithin the loop look a bit confusing
> as well.
>
> We set N_HIGH_MEMORY unconditionally, and then we set N_NORMAL_MEMORY
> in case we have CONFIG_HIGHMEM (N_NORMAL_MEMORY != N_HIGH_MEMORY)
> and zone <= ZONE_NORMAL.
> (N_HIGH_MEMORY falls back to N_NORMAL_MEMORY on !CONFIG_HIGHMEM systems,
> and that is why we can just go ahead and set N_HIGH_MEMORY unconditionally)
>
> Although this works, it is a bit subtle.
>
> I think that this could be easier to follow:
>
> First, we should only set N_HIGH_MEMORY in case we have
> CONFIG_HIGHMEM.
> And then we should set N_NORMAL_MEMORY in case zone <= ZONE_NORMAL,
> without further checking whether we have CONFIG_HIGHMEM or not.
>
> Signed-off-by: Oscar Salvador
> ---
> mm/page_alloc.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 839e0cc17f2c..6aa947f9e614 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6819,15 +6819,12 @@ static void check_for_memory(pg_data_t *pgdat, int
> nid)
> {
> enum zone_type zone_type;
>
> - if (N_MEMORY == N_NORMAL_MEMORY)
> - return;
> -
> for (zone_type = 0; zone_type <= ZONE_MOVABLE - 1; zone_type++) {
> struct zone *zone = >node_zones[zone_type];
> if (populated_zone(zone)) {
> - node_set_state(nid, N_HIGH_MEMORY);
> - if (N_NORMAL_MEMORY != N_HIGH_MEMORY &&
> - zone_type <= ZONE_NORMAL)
> + if (IS_ENABLED(CONFIG_HIGHMEM))
> + node_set_state(nid, N_HIGH_MEMORY);
> + if (zone_type <= ZONE_NORMAL)
> node_set_state(nid, N_NORMAL_MEMORY);
> break;
> }
>
I would re-write the above function like this:
static void check_for_memory(pg_data_t *pgdat, int nid)
{
enum zone_type zone_type;
for (zone_type = 0; zone_type < ZONE_MOVABLE; zone_type++) {
if (populated_zone(>node_zones[zone_type])) {
node_set_state(nid, zone_type <= ZONE_NORMAL ?
N_NORMAL_MEMORY: N_HIGH_MEMORY);
break;
}
}
}
zone_type <= ZONE_MOVABLE - 1
is the same as:
zone_type < ZONE_MOVABLE
If zone > ZONE_NORMAL, it means that CONFIG_HIGHMEM is enabled, no need to
check for it.
Pavel
RE: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves
> > > > > Some kind of counter is required to keep track of the power cycle. > > > > > When going to sleep the sgx_pm_cnt is increased. sgx_einit() > > > > > compares the current value of the global count to the value in > > > > > the cache entry to see whether we are in a new power cycle. > > > > > > > > You mean reset to Intel default? I think we can also just reset > > > > the cached MSR values on each power cycle, which would be simpler, > IMHO? > > > > > > Refresh my brain, does hardware reset the MSRs on a transition to S3 or > lower? Sorry I missed this one. To be honest I don't know. I checked the SDM and all I can find is: "On reset, the default value is the digest of Intel's signing key." Jarkko may know. > > > > > > > I think we definitely need some code to handle S3-S5, but should > > > > be in separate patches, since I think the major impact of S3-S5 is > > > > entire EPC being destroyed. I think keeping pm_cnt is not > > > > sufficient enough to handle such case? > > > > > > > > > > This brings up one question though: how do we deal with VM host > > > > > going to > > > sleep? > > > > > VM guest would not be aware of this. > > > > > > > > IMO VM just gets "sudden loss of EPC" after suspend & resume in host. > > > > SGX driver and SDK should be able to handle "sudden loss of EPC", > > > > ie, co-working together to re-establish the missing enclaves. > > > > > > > > Actually supporting "sudden loss of EPC" is a requirement to > > > > support live migration of VM w/ SGX. Internally long time ago we > > > > had a discussion and the decision was we should support SGX live > > > > migration given > > > two facts: > > > > > > > > 1) losing platform-dependent is not important. For example, losing > > > > sealing key is not a problem, as we could get secrets provisioned > > > > again from remote. 2) Both windows & linux driver commit to > > > > support "sudden > > > loss of EPC". > > > > > > > > I don't think we have to support in very first upstream driver, > > > > but I think we need to support someday. > > > > > > Actually, we can easily support this in the driver, at least for SGX1 > > > hardware. > > > > That's my guess too. Just want to check whether we are still on the > > same page :) > > > > > SGX2 isn't difficult to handle, but we've intentionally postponed > > > those patches until SGX1 support is in mainline[1]. > > > Accesses to the EPC after it is lost will cause faults. Userspace EPC > > > accesses, > e.g. > > > ERESUME, will get a SIGSEGV that the process should interpret as an > > > "I should restart my enclave" event. The SDK already does this. In > > > the driver, we just need to be aware of this potential behavior and > > > not freak out. Specifically, SGX_INVD needs to not WARN on faults that > > > may > have been due to a the EPC being nuked. > > > I think we can even remove the sgx_encl_pm_notifier() code altogether. > > > > Possibly we still need to do some cleanup, ie, all structures of enclaves, > > upon > resume? > > Not for functional reasons. The driver will automatically do the cleanup via > SGX_INVD when it next accesses the enclave's pages and takes a fault, e.g. > during reclaim. Proactively reclaiming the EPC pages would probably affect > performance, though not necessarily in a good way. And I think it would be a > beneficial to get the driver out of the suspend/hibernate/resume paths, e.g. > zapping all enclaves could noticeably impact suspend/resume latency. Sure. Thanks, -Kai
RE: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves
> > > > > Some kind of counter is required to keep track of the power cycle. > > > > > When going to sleep the sgx_pm_cnt is increased. sgx_einit() > > > > > compares the current value of the global count to the value in > > > > > the cache entry to see whether we are in a new power cycle. > > > > > > > > You mean reset to Intel default? I think we can also just reset > > > > the cached MSR values on each power cycle, which would be simpler, > IMHO? > > > > > > Refresh my brain, does hardware reset the MSRs on a transition to S3 or > lower? Sorry I missed this one. To be honest I don't know. I checked the SDM and all I can find is: "On reset, the default value is the digest of Intel's signing key." Jarkko may know. > > > > > > > I think we definitely need some code to handle S3-S5, but should > > > > be in separate patches, since I think the major impact of S3-S5 is > > > > entire EPC being destroyed. I think keeping pm_cnt is not > > > > sufficient enough to handle such case? > > > > > > > > > > This brings up one question though: how do we deal with VM host > > > > > going to > > > sleep? > > > > > VM guest would not be aware of this. > > > > > > > > IMO VM just gets "sudden loss of EPC" after suspend & resume in host. > > > > SGX driver and SDK should be able to handle "sudden loss of EPC", > > > > ie, co-working together to re-establish the missing enclaves. > > > > > > > > Actually supporting "sudden loss of EPC" is a requirement to > > > > support live migration of VM w/ SGX. Internally long time ago we > > > > had a discussion and the decision was we should support SGX live > > > > migration given > > > two facts: > > > > > > > > 1) losing platform-dependent is not important. For example, losing > > > > sealing key is not a problem, as we could get secrets provisioned > > > > again from remote. 2) Both windows & linux driver commit to > > > > support "sudden > > > loss of EPC". > > > > > > > > I don't think we have to support in very first upstream driver, > > > > but I think we need to support someday. > > > > > > Actually, we can easily support this in the driver, at least for SGX1 > > > hardware. > > > > That's my guess too. Just want to check whether we are still on the > > same page :) > > > > > SGX2 isn't difficult to handle, but we've intentionally postponed > > > those patches until SGX1 support is in mainline[1]. > > > Accesses to the EPC after it is lost will cause faults. Userspace EPC > > > accesses, > e.g. > > > ERESUME, will get a SIGSEGV that the process should interpret as an > > > "I should restart my enclave" event. The SDK already does this. In > > > the driver, we just need to be aware of this potential behavior and > > > not freak out. Specifically, SGX_INVD needs to not WARN on faults that > > > may > have been due to a the EPC being nuked. > > > I think we can even remove the sgx_encl_pm_notifier() code altogether. > > > > Possibly we still need to do some cleanup, ie, all structures of enclaves, > > upon > resume? > > Not for functional reasons. The driver will automatically do the cleanup via > SGX_INVD when it next accesses the enclave's pages and takes a fault, e.g. > during reclaim. Proactively reclaiming the EPC pages would probably affect > performance, though not necessarily in a good way. And I think it would be a > beneficial to get the driver out of the suspend/hibernate/resume paths, e.g. > zapping all enclaves could noticeably impact suspend/resume latency. Sure. Thanks, -Kai
Re: [RFC PATCH 2/6] x86/mm: temporary mm struct
On Wed, 29 Aug 2018 08:41:00 -0700
Andy Lutomirski wrote:
> On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu wrote:
> > On Wed, 29 Aug 2018 01:11:43 -0700
> > Nadav Amit wrote:
> >
> >> From: Andy Lutomirski
> >>
> >> Sometimes we want to set a temporary page-table entries (PTEs) in one of
> >> the cores, without allowing other cores to use - even speculatively -
> >> these mappings. There are two benefits for doing so:
> >>
> >> (1) Security: if sensitive PTEs are set, temporary mm prevents their use
> >> in other cores. This hardens the security as it prevents exploding a
> >> dangling pointer to overwrite sensitive data using the sensitive PTE.
> >>
> >> (2) Avoiding TLB shootdowns: the PTEs do not need to be flushed in
> >> remote page-tables.
> >>
> >> To do so a temporary mm_struct can be used. Mappings which are private
> >> for this mm can be set in the userspace part of the address-space.
> >> During the whole time in which the temporary mm is loaded, interrupts
> >> must be disabled.
> >>
> >> The first use-case for temporary PTEs, which will follow, is for poking
> >> the kernel text.
> >>
> >> [ Commit message was written by Nadav ]
> >>
> >> Cc: Andy Lutomirski
> >> Cc: Masami Hiramatsu
> >> Cc: Kees Cook
> >> Cc: Peter Zijlstra
> >> Signed-off-by: Nadav Amit
> >> ---
> >> arch/x86/include/asm/mmu_context.h | 20
> >> 1 file changed, 20 insertions(+)
> >>
> >> diff --git a/arch/x86/include/asm/mmu_context.h
> >> b/arch/x86/include/asm/mmu_context.h
> >> index eeeb9289c764..96afc8c0cf15 100644
> >> --- a/arch/x86/include/asm/mmu_context.h
> >> +++ b/arch/x86/include/asm/mmu_context.h
> >> @@ -338,4 +338,24 @@ static inline unsigned long
> >> __get_current_cr3_fast(void)
> >> return cr3;
> >> }
> >>
> >> +typedef struct {
> >> + struct mm_struct *prev;
> >> +} temporary_mm_state_t;
> >> +
> >> +static inline temporary_mm_state_t use_temporary_mm(struct mm_struct *mm)
> >> +{
> >> + temporary_mm_state_t state;
> >> +
> >> + lockdep_assert_irqs_disabled();
> >> + state.prev = this_cpu_read(cpu_tlbstate.loaded_mm);
> >> + switch_mm_irqs_off(NULL, mm, current);
> >> + return state;
> >> +}
> >
> > Hmm, why don't we return mm_struct *prev directly?
>
> I did it this way to make it easier to add future debugging stuff
> later. Also, when I first wrote this, I stashed the old CR3 instead
> of the old mm_struct, and it seemed like callers should be insulated
> from details like this.
Hmm, I see. But in that case, we should call it "struct temporary_mm"
and explicitly allocate (and pass) it, since we can not return the
data structure from stack. If we can combine it with new mm, it will
be more encapsulated e.g.
struct temporary_mm {
struct mm_struct *mm;
struct mm_struct *prev;
};
static struct temporary_mm poking_tmp_mm;
poking_init()
{
if (init_temporary_mm(_mm, _mm))
goto error;
...
}
text_poke_safe()
{
...
use_temporary_mm(_mm);
...
unuse_temporary_mm(_mm);
}
Any thought?
Thanks,
--
Masami Hiramatsu
Re: [RFC PATCH 2/6] x86/mm: temporary mm struct
On Wed, 29 Aug 2018 08:41:00 -0700
Andy Lutomirski wrote:
> On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu wrote:
> > On Wed, 29 Aug 2018 01:11:43 -0700
> > Nadav Amit wrote:
> >
> >> From: Andy Lutomirski
> >>
> >> Sometimes we want to set a temporary page-table entries (PTEs) in one of
> >> the cores, without allowing other cores to use - even speculatively -
> >> these mappings. There are two benefits for doing so:
> >>
> >> (1) Security: if sensitive PTEs are set, temporary mm prevents their use
> >> in other cores. This hardens the security as it prevents exploding a
> >> dangling pointer to overwrite sensitive data using the sensitive PTE.
> >>
> >> (2) Avoiding TLB shootdowns: the PTEs do not need to be flushed in
> >> remote page-tables.
> >>
> >> To do so a temporary mm_struct can be used. Mappings which are private
> >> for this mm can be set in the userspace part of the address-space.
> >> During the whole time in which the temporary mm is loaded, interrupts
> >> must be disabled.
> >>
> >> The first use-case for temporary PTEs, which will follow, is for poking
> >> the kernel text.
> >>
> >> [ Commit message was written by Nadav ]
> >>
> >> Cc: Andy Lutomirski
> >> Cc: Masami Hiramatsu
> >> Cc: Kees Cook
> >> Cc: Peter Zijlstra
> >> Signed-off-by: Nadav Amit
> >> ---
> >> arch/x86/include/asm/mmu_context.h | 20
> >> 1 file changed, 20 insertions(+)
> >>
> >> diff --git a/arch/x86/include/asm/mmu_context.h
> >> b/arch/x86/include/asm/mmu_context.h
> >> index eeeb9289c764..96afc8c0cf15 100644
> >> --- a/arch/x86/include/asm/mmu_context.h
> >> +++ b/arch/x86/include/asm/mmu_context.h
> >> @@ -338,4 +338,24 @@ static inline unsigned long
> >> __get_current_cr3_fast(void)
> >> return cr3;
> >> }
> >>
> >> +typedef struct {
> >> + struct mm_struct *prev;
> >> +} temporary_mm_state_t;
> >> +
> >> +static inline temporary_mm_state_t use_temporary_mm(struct mm_struct *mm)
> >> +{
> >> + temporary_mm_state_t state;
> >> +
> >> + lockdep_assert_irqs_disabled();
> >> + state.prev = this_cpu_read(cpu_tlbstate.loaded_mm);
> >> + switch_mm_irqs_off(NULL, mm, current);
> >> + return state;
> >> +}
> >
> > Hmm, why don't we return mm_struct *prev directly?
>
> I did it this way to make it easier to add future debugging stuff
> later. Also, when I first wrote this, I stashed the old CR3 instead
> of the old mm_struct, and it seemed like callers should be insulated
> from details like this.
Hmm, I see. But in that case, we should call it "struct temporary_mm"
and explicitly allocate (and pass) it, since we can not return the
data structure from stack. If we can combine it with new mm, it will
be more encapsulated e.g.
struct temporary_mm {
struct mm_struct *mm;
struct mm_struct *prev;
};
static struct temporary_mm poking_tmp_mm;
poking_init()
{
if (init_temporary_mm(_mm, _mm))
goto error;
...
}
text_poke_safe()
{
...
use_temporary_mm(_mm);
...
unuse_temporary_mm(_mm);
}
Any thought?
Thanks,
--
Masami Hiramatsu
Re: mmotm 2018-08-23-17-26 uploaded
On 8/30/2018 7:22 AM, Andrew Morton Wrote: > On Tue, 28 Aug 2018 12:20:46 +0800 Jia He wrote: > >> Hi Andrew >> FYI,I watched a lockdep warning based on your mmotm master branch[1] > > Thanks. We'll need help from ARM peeps on this please. > >> [6.692731] [ cut here ] >> [6.696391] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled) >> [6.696404] WARNING: CPU: 3 PID: 320 at kernel/locking/lockdep.c:3845 >> check_flags.part.38+0x9c/0x16c >> [6.711082] Modules linked in: >> [6.714101] CPU: 3 PID: 320 Comm: modprobe Not tainted 4.18.0-rc4-mm1+ #56 >> [6.720956] Hardware name: WIWYNN HXT REP-1 System H001-1-0/HXT REP-1 >> CRB, BIOS 0ACJA530 03/20/2018 >> [6.730332] pstate: 60400085 (nZCv daIf +PAN -UAO) >> [6.735106] pc : check_flags.part.38+0x9c/0x16c >> [6.739619] lr : check_flags.part.38+0x9c/0x16c >> [6.744133] sp : 80178536fbf0 >> [6.747432] x29: 80178536fbf0 x28: 8017905a1b00 >> [6.752727] x27: 0002 x26: >> [6.758022] x25: 08abeb14 x24: >> [6.763317] x23: 0001 x22: 0001 >> [6.768612] x21: 0001 x20: >> [6.773908] x19: 0a041000 x18: >> [6.779202] x17: x16: >> [6.784498] x15: x14: >> [6.789793] x13: 08d6b190 x12: 752ce9eb60de3f00 >> [6.795088] x11: 80178536f7f0 x10: 80178536f7f0 >> [6.800383] x9 : ffd0 x8 : >> [6.805678] x7 : 0816fe48 x6 : 801794ba62b8 >> [6.810973] x5 : x4 : >> [6.816269] x3 : x2 : 091ed988 >> [6.821564] x1 : 752ce9eb60de3f00 x0 : 752ce9eb60de3f00 >> [6.826859] Call trace: >> [6.829290] check_flags.part.38+0x9c/0x16c >> [6.833457] lock_acquire+0x12c/0x280 >> [6.837104] down_read_trylock+0x78/0x98 >> [6.841011] do_page_fault+0x150/0x480 >> [6.844742] do_translation_fault+0x74/0x80 >> [6.848909] do_mem_abort+0x60/0x108 >> [6.852467] el0_da+0x24/0x28 >> [6.855418] irq event stamp: 250 >> [6.858633] hardirqs last enabled at (249): [] >> mem_cgroup_commit_charge+0x9c/0x13c >> [6.867833] hardirqs last disabled at (250): [] >> el0_svc_handler+0xc4/0x16c >> [6.876252] softirqs last enabled at (242): [] >> __do_softirq+0x2f8/0x554 >> [6.884501] softirqs last disabled at (229): [] >> irq_exit+0x180/0x194 >> [6.892399] ---[ end trace b45768f94a7b7d9f ]--- >> [6.896998] possible reason: unannotated irqs-on. >> [6.901685] irq event stamp: 250 >> [6.904898] hardirqs last enabled at (249): [] >> mem_cgroup_commit_charge+0x9c/0x13c >> [6.914100] hardirqs last disabled at (250): [] >> el0_svc_handler+0xc4/0x16c >> [6.922519] softirqs last enabled at (242): [] >> __do_softirq+0x2f8/0x554 >> [6.930766] softirqs last disabled at (229): [] >> irq_exit+0x180/0x194 >> [7.023827] Initialise system trusted keyrings >> [7.027414] workingset: timestamp_bits=45 max_order=25 bucket_order=0 > > Lockdep says current->hardirqs_enabled is false and that is indeed an > error. arch/arm64/kernel/entry.S:el0_da does enable_daif which might > be an attempt to enable hardirqs, but how does that get propagated into > lockdep's ->hardirqs_enabled? By calling > local_irq_enable()->trace_hardirqs_on(), but that's C, not assembler. > > And what changed to cause this? > > I dunno anything. Help! > >> I thought the root cause might be at [2] which seems not in your branch yet. >> >> [1] http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git >> [2] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=efd112 > > I agree, that doesn't look like the culprit. But something may well > have gone wrong in "the recent conversion of the syscall entry/exit > code to C". Sorry for my unclearly previously description. 1. no such lockdep warning in latest mainline kernel git tree. 2. there is a 100% producible warning based on your latest mmotm tree 3. after applying the commit efd112 based on your mmotm tree, the warning disappearred I will do some further digging to answer your question if no other experts' help -- Cheers, Jia
Re: mmotm 2018-08-23-17-26 uploaded
On 8/30/2018 7:22 AM, Andrew Morton Wrote: > On Tue, 28 Aug 2018 12:20:46 +0800 Jia He wrote: > >> Hi Andrew >> FYI,I watched a lockdep warning based on your mmotm master branch[1] > > Thanks. We'll need help from ARM peeps on this please. > >> [6.692731] [ cut here ] >> [6.696391] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled) >> [6.696404] WARNING: CPU: 3 PID: 320 at kernel/locking/lockdep.c:3845 >> check_flags.part.38+0x9c/0x16c >> [6.711082] Modules linked in: >> [6.714101] CPU: 3 PID: 320 Comm: modprobe Not tainted 4.18.0-rc4-mm1+ #56 >> [6.720956] Hardware name: WIWYNN HXT REP-1 System H001-1-0/HXT REP-1 >> CRB, BIOS 0ACJA530 03/20/2018 >> [6.730332] pstate: 60400085 (nZCv daIf +PAN -UAO) >> [6.735106] pc : check_flags.part.38+0x9c/0x16c >> [6.739619] lr : check_flags.part.38+0x9c/0x16c >> [6.744133] sp : 80178536fbf0 >> [6.747432] x29: 80178536fbf0 x28: 8017905a1b00 >> [6.752727] x27: 0002 x26: >> [6.758022] x25: 08abeb14 x24: >> [6.763317] x23: 0001 x22: 0001 >> [6.768612] x21: 0001 x20: >> [6.773908] x19: 0a041000 x18: >> [6.779202] x17: x16: >> [6.784498] x15: x14: >> [6.789793] x13: 08d6b190 x12: 752ce9eb60de3f00 >> [6.795088] x11: 80178536f7f0 x10: 80178536f7f0 >> [6.800383] x9 : ffd0 x8 : >> [6.805678] x7 : 0816fe48 x6 : 801794ba62b8 >> [6.810973] x5 : x4 : >> [6.816269] x3 : x2 : 091ed988 >> [6.821564] x1 : 752ce9eb60de3f00 x0 : 752ce9eb60de3f00 >> [6.826859] Call trace: >> [6.829290] check_flags.part.38+0x9c/0x16c >> [6.833457] lock_acquire+0x12c/0x280 >> [6.837104] down_read_trylock+0x78/0x98 >> [6.841011] do_page_fault+0x150/0x480 >> [6.844742] do_translation_fault+0x74/0x80 >> [6.848909] do_mem_abort+0x60/0x108 >> [6.852467] el0_da+0x24/0x28 >> [6.855418] irq event stamp: 250 >> [6.858633] hardirqs last enabled at (249): [] >> mem_cgroup_commit_charge+0x9c/0x13c >> [6.867833] hardirqs last disabled at (250): [] >> el0_svc_handler+0xc4/0x16c >> [6.876252] softirqs last enabled at (242): [] >> __do_softirq+0x2f8/0x554 >> [6.884501] softirqs last disabled at (229): [] >> irq_exit+0x180/0x194 >> [6.892399] ---[ end trace b45768f94a7b7d9f ]--- >> [6.896998] possible reason: unannotated irqs-on. >> [6.901685] irq event stamp: 250 >> [6.904898] hardirqs last enabled at (249): [] >> mem_cgroup_commit_charge+0x9c/0x13c >> [6.914100] hardirqs last disabled at (250): [] >> el0_svc_handler+0xc4/0x16c >> [6.922519] softirqs last enabled at (242): [] >> __do_softirq+0x2f8/0x554 >> [6.930766] softirqs last disabled at (229): [] >> irq_exit+0x180/0x194 >> [7.023827] Initialise system trusted keyrings >> [7.027414] workingset: timestamp_bits=45 max_order=25 bucket_order=0 > > Lockdep says current->hardirqs_enabled is false and that is indeed an > error. arch/arm64/kernel/entry.S:el0_da does enable_daif which might > be an attempt to enable hardirqs, but how does that get propagated into > lockdep's ->hardirqs_enabled? By calling > local_irq_enable()->trace_hardirqs_on(), but that's C, not assembler. > > And what changed to cause this? > > I dunno anything. Help! > >> I thought the root cause might be at [2] which seems not in your branch yet. >> >> [1] http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git >> [2] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=efd112 > > I agree, that doesn't look like the culprit. But something may well > have gone wrong in "the recent conversion of the syscall entry/exit > code to C". Sorry for my unclearly previously description. 1. no such lockdep warning in latest mainline kernel git tree. 2. there is a 100% producible warning based on your latest mmotm tree 3. after applying the commit efd112 based on your mmotm tree, the warning disappearred I will do some further digging to answer your question if no other experts' help -- Cheers, Jia
Re: [PATCH v6 1/2] mm: migration: fix migration of huge PMD shared pages
On 08/29/2018 02:11 PM, Jerome Glisse wrote:
> On Wed, Aug 29, 2018 at 08:39:06PM +0200, Michal Hocko wrote:
>> On Wed 29-08-18 14:14:25, Jerome Glisse wrote:
>>> On Wed, Aug 29, 2018 at 10:24:44AM -0700, Mike Kravetz wrote:
>> [...]
What would be the best mmu notifier interface to use where there are no
start/end calls?
Or, is the best solution to add the start/end calls as is done in later
versions of the code? If that is the suggestion, has there been any change
in invalidate start/end semantics that we should take into account?
>>>
>>> start/end would be the one to add, 4.4 seems broken in respect to THP
>>> and mmu notification. Another solution is to fix user of mmu notifier,
>>> they were only a handful back then. For instance properly adjust the
>>> address to match first address covered by pmd or pud and passing down
>>> correct page size to mmu_notifier_invalidate_page() would allow to fix
>>> this easily.
>>>
>>> This is ok because user of try_to_unmap_one() replace the pte/pmd/pud
>>> with an invalid one (either poison, migration or swap) inside the
>>> function. So anyone racing would synchronize on those special entry
>>> hence why it is fine to delay mmu_notifier_invalidate_page() to after
>>> dropping the page table lock.
>>>
>>> Adding start/end might the solution with less code churn as you would
>>> only need to change try_to_unmap_one().
>>
>> What about dependencies? 369ea8242c0fb sounds like it needs work for all
>> notifiers need to be updated as well.
>
> This commit remove mmu_notifier_invalidate_page() hence why everything
> need to be updated. But in 4.4 you can get away with just adding start/
> end and keep around mmu_notifier_invalidate_page() to minimize disruption.
>
> So the new semantic in 369ea8242c0fb is that all page table changes are
> bracketed with mmu notifier start/end calls and invalidate_range right
> after tlb flush. This simplify thing and make it more reliable for mmu
> notifier users like IOMMU or ODP or GPUs drivers.
Here is what I came up with by adding the start/end calls to the 4.4 version
of try_to_unmap_one. Note that this assumes/uses the new routine
adjust_range_if_pmd_sharing_possible to adjust the notifier/flush range if
huge pmd sharing is possible. I changed the mmu_notifier_invalidate_page
to a mmu_notifier_invalidate_range, but am not sure if that needs to happen
earlier in the routine (like right after tlb flush as you said above).
Does this look reasonable?
diff --git a/mm/rmap.c b/mm/rmap.c
index b577fbb98d4b..7ba8bfeddb4b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1302,11 +1302,30 @@ static int try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
pte_t pteval;
spinlock_t *ptl;
int ret = SWAP_AGAIN;
+ unsigned long start = address, end;
enum ttu_flags flags = (enum ttu_flags)arg;
/* munlock has nothing to gain from examining un-locked vmas */
if ((flags & TTU_MUNLOCK) && !(vma->vm_flags & VM_LOCKED))
- goto out;
+ return ret;
+
+ /*
+* For THP, we have to assume the worse case ie pmd for invalidation.
+* For hugetlb, it could be much worse if we need to do pud
+* invalidation in the case of pmd sharing.
+*
+* Note that the page can not be free in this function as call of
+* try_to_unmap() must hold a reference on the page.
+*/
+ end = min(vma->vm_end, start + (PAGE_SIZE << compound_order(page)));
+ if (PageHuge(page)) {
+ /*
+* If sharing is possible, start and end will be adjusted
+* accordingly.
+*/
+ adjust_range_if_pmd_sharing_possible(vma, , );
+ }
+ mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
pte = page_check_address(page, mm, address, , 0);
if (!pte)
@@ -1334,6 +1353,29 @@ static int try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
}
}
+ if (PageHuge(page) && huge_pmd_unshare(mm, , pte)) {
+ /*
+* huge_pmd_unshare unmapped an entire PMD page. There is
+* no way of knowing exactly which PMDs may be cached for
+* this mm, so flush them all. start/end were already
+* adjusted to cover this range.
+*/
+ flush_cache_range(vma, start, end);
+ flush_tlb_range(vma, start, end);
+
+ /*
+* The ref count of the PMD page was dropped which is part
+* of the way map counting is done for shared PMDs. When
+* there is no other sharing, huge_pmd_unshare returns false
+* and we will unmap the actual page and drop map count
+* to zero.
+*
+* Note that huge_pmd_unshare modified address and is likely
+* not what you would
Re: [PATCH v6 1/2] mm: migration: fix migration of huge PMD shared pages
On 08/29/2018 02:11 PM, Jerome Glisse wrote:
> On Wed, Aug 29, 2018 at 08:39:06PM +0200, Michal Hocko wrote:
>> On Wed 29-08-18 14:14:25, Jerome Glisse wrote:
>>> On Wed, Aug 29, 2018 at 10:24:44AM -0700, Mike Kravetz wrote:
>> [...]
What would be the best mmu notifier interface to use where there are no
start/end calls?
Or, is the best solution to add the start/end calls as is done in later
versions of the code? If that is the suggestion, has there been any change
in invalidate start/end semantics that we should take into account?
>>>
>>> start/end would be the one to add, 4.4 seems broken in respect to THP
>>> and mmu notification. Another solution is to fix user of mmu notifier,
>>> they were only a handful back then. For instance properly adjust the
>>> address to match first address covered by pmd or pud and passing down
>>> correct page size to mmu_notifier_invalidate_page() would allow to fix
>>> this easily.
>>>
>>> This is ok because user of try_to_unmap_one() replace the pte/pmd/pud
>>> with an invalid one (either poison, migration or swap) inside the
>>> function. So anyone racing would synchronize on those special entry
>>> hence why it is fine to delay mmu_notifier_invalidate_page() to after
>>> dropping the page table lock.
>>>
>>> Adding start/end might the solution with less code churn as you would
>>> only need to change try_to_unmap_one().
>>
>> What about dependencies? 369ea8242c0fb sounds like it needs work for all
>> notifiers need to be updated as well.
>
> This commit remove mmu_notifier_invalidate_page() hence why everything
> need to be updated. But in 4.4 you can get away with just adding start/
> end and keep around mmu_notifier_invalidate_page() to minimize disruption.
>
> So the new semantic in 369ea8242c0fb is that all page table changes are
> bracketed with mmu notifier start/end calls and invalidate_range right
> after tlb flush. This simplify thing and make it more reliable for mmu
> notifier users like IOMMU or ODP or GPUs drivers.
Here is what I came up with by adding the start/end calls to the 4.4 version
of try_to_unmap_one. Note that this assumes/uses the new routine
adjust_range_if_pmd_sharing_possible to adjust the notifier/flush range if
huge pmd sharing is possible. I changed the mmu_notifier_invalidate_page
to a mmu_notifier_invalidate_range, but am not sure if that needs to happen
earlier in the routine (like right after tlb flush as you said above).
Does this look reasonable?
diff --git a/mm/rmap.c b/mm/rmap.c
index b577fbb98d4b..7ba8bfeddb4b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1302,11 +1302,30 @@ static int try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
pte_t pteval;
spinlock_t *ptl;
int ret = SWAP_AGAIN;
+ unsigned long start = address, end;
enum ttu_flags flags = (enum ttu_flags)arg;
/* munlock has nothing to gain from examining un-locked vmas */
if ((flags & TTU_MUNLOCK) && !(vma->vm_flags & VM_LOCKED))
- goto out;
+ return ret;
+
+ /*
+* For THP, we have to assume the worse case ie pmd for invalidation.
+* For hugetlb, it could be much worse if we need to do pud
+* invalidation in the case of pmd sharing.
+*
+* Note that the page can not be free in this function as call of
+* try_to_unmap() must hold a reference on the page.
+*/
+ end = min(vma->vm_end, start + (PAGE_SIZE << compound_order(page)));
+ if (PageHuge(page)) {
+ /*
+* If sharing is possible, start and end will be adjusted
+* accordingly.
+*/
+ adjust_range_if_pmd_sharing_possible(vma, , );
+ }
+ mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
pte = page_check_address(page, mm, address, , 0);
if (!pte)
@@ -1334,6 +1353,29 @@ static int try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
}
}
+ if (PageHuge(page) && huge_pmd_unshare(mm, , pte)) {
+ /*
+* huge_pmd_unshare unmapped an entire PMD page. There is
+* no way of knowing exactly which PMDs may be cached for
+* this mm, so flush them all. start/end were already
+* adjusted to cover this range.
+*/
+ flush_cache_range(vma, start, end);
+ flush_tlb_range(vma, start, end);
+
+ /*
+* The ref count of the PMD page was dropped which is part
+* of the way map counting is done for shared PMDs. When
+* there is no other sharing, huge_pmd_unshare returns false
+* and we will unmap the actual page and drop map count
+* to zero.
+*
+* Note that huge_pmd_unshare modified address and is likely
+* not what you would
Re: [RFC] perf script: callchain handling is not useful
Hi, On Wed, Aug 29, 2018 at 08:14:12AM -0700, Stephane Eranian wrote: > On Wed, Aug 29, 2018 at 6:54 AM Arnaldo Carvalho de Melo > wrote: > > > > Em Tue, Aug 28, 2018 at 07:41:31PM -0700, Stephane Eranian escreveu: > > > Hi, > > > > > > I am doing the following simple collection with callchain and load > > > profiling: > > > > > > $ perf record -g -d -e cpu/event=0xd0,umask=0x81/pp my_test_program > > > > > > But when I type: > > > $ perf script -F ip,addr > > > 9d4821346878 > > > 9d58df25 > > > 9d58e054 > > > 9d5965bb > > > 9d640650 > > > 9d697d06 > > > 9d63ec60 > > > 9d640322 > > > 9d64070c > > > 9d455a60 > > > 7030c7 > > > > > > 9d4638ba84a0 > > > 9d5df447 > > > 9d5eaf4a > > > 9d63e165 > > > 9d63e439 > > > 9d697d98 > > > 9d63ec60 > > > 9d640322 > > > 9d64070c > > > 9d455a60 > > > 7030c7 > > > I also see the callchain and it is not clear which is the IP. Further > > > more parsing becomes more difficult because of multiple lines per > > > sample. I understand that multiline is likely because of > > > symbolization. But if I don't want symbolization, it should be > > > possible to print all in one line. > > > > Humm, to have this not break possibly existing scripts, perhaps we can > > have something like: > > > > $ perf script -F ip,-callchain,addr > > > > ? > > > > And if asked explicitely for the callchain, then it gets added in the > > same line? > > > Yeah, that should do it. > Thanks. I found this: $ perf script -h |& grep -A1 hide -G, --hide-call-graph When printing symbols do not display call chain Thanks, Namhyung
Re: [RFC] perf script: callchain handling is not useful
Hi, On Wed, Aug 29, 2018 at 08:14:12AM -0700, Stephane Eranian wrote: > On Wed, Aug 29, 2018 at 6:54 AM Arnaldo Carvalho de Melo > wrote: > > > > Em Tue, Aug 28, 2018 at 07:41:31PM -0700, Stephane Eranian escreveu: > > > Hi, > > > > > > I am doing the following simple collection with callchain and load > > > profiling: > > > > > > $ perf record -g -d -e cpu/event=0xd0,umask=0x81/pp my_test_program > > > > > > But when I type: > > > $ perf script -F ip,addr > > > 9d4821346878 > > > 9d58df25 > > > 9d58e054 > > > 9d5965bb > > > 9d640650 > > > 9d697d06 > > > 9d63ec60 > > > 9d640322 > > > 9d64070c > > > 9d455a60 > > > 7030c7 > > > > > > 9d4638ba84a0 > > > 9d5df447 > > > 9d5eaf4a > > > 9d63e165 > > > 9d63e439 > > > 9d697d98 > > > 9d63ec60 > > > 9d640322 > > > 9d64070c > > > 9d455a60 > > > 7030c7 > > > I also see the callchain and it is not clear which is the IP. Further > > > more parsing becomes more difficult because of multiple lines per > > > sample. I understand that multiline is likely because of > > > symbolization. But if I don't want symbolization, it should be > > > possible to print all in one line. > > > > Humm, to have this not break possibly existing scripts, perhaps we can > > have something like: > > > > $ perf script -F ip,-callchain,addr > > > > ? > > > > And if asked explicitely for the callchain, then it gets added in the > > same line? > > > Yeah, that should do it. > Thanks. I found this: $ perf script -h |& grep -A1 hide -G, --hide-call-graph When printing symbols do not display call chain Thanks, Namhyung
[GIT PULL] RISC-V Fixes and Cleanups for 4.19-rc2
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git tags/riscv-for-linus-4.19-rc2 for you to fetch changes up to 47d80a68f10d3290204a12f7836a9a8190dfc327: RISC-V: Use a less ugly workaround for unused variable warnings (2018-08-28 12:58:36 -0700) RISC-V Fixes and Cleanups for 4.19-rc2 This tag contains a handful of patches that filtered their way in during the merge window but just didn't make the deadline. It includes: * Additional documentation in the riscv,cpu-intc device tree binding that resulted from some feedback I missed in the original patch set. * A build fix that provides the definition of tlb_flush() before including tlb.h, which fixes a RISC-V build regression introduced during this merge window. * A cosmetic cleanup to sys_riscv_flush_icache(). Palmer Dabbelt (2): dt-bindings: riscv,cpu-intc: Cleanups from a missed review RISC-V: Use a less ugly workaround for unused variable warnings Will Deacon (1): riscv: tlb: Provide definition of tlb_flush() before including tlb.h .../bindings/interrupt-controller/riscv,cpu-intc.txt | 14 +++--- arch/riscv/include/asm/tlb.h | 4 arch/riscv/kernel/sys_riscv.c | 15 +-- 3 files changed, 16 insertions(+), 17 deletions(-)
[GIT PULL] RISC-V Fixes and Cleanups for 4.19-rc2
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git tags/riscv-for-linus-4.19-rc2 for you to fetch changes up to 47d80a68f10d3290204a12f7836a9a8190dfc327: RISC-V: Use a less ugly workaround for unused variable warnings (2018-08-28 12:58:36 -0700) RISC-V Fixes and Cleanups for 4.19-rc2 This tag contains a handful of patches that filtered their way in during the merge window but just didn't make the deadline. It includes: * Additional documentation in the riscv,cpu-intc device tree binding that resulted from some feedback I missed in the original patch set. * A build fix that provides the definition of tlb_flush() before including tlb.h, which fixes a RISC-V build regression introduced during this merge window. * A cosmetic cleanup to sys_riscv_flush_icache(). Palmer Dabbelt (2): dt-bindings: riscv,cpu-intc: Cleanups from a missed review RISC-V: Use a less ugly workaround for unused variable warnings Will Deacon (1): riscv: tlb: Provide definition of tlb_flush() before including tlb.h .../bindings/interrupt-controller/riscv,cpu-intc.txt | 14 +++--- arch/riscv/include/asm/tlb.h | 4 arch/riscv/kernel/sys_riscv.c | 15 +-- 3 files changed, 16 insertions(+), 17 deletions(-)
Re: [PATCH V3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP
On Wed, Aug 29, 2018 at 6:19 AM wrote: > > On 2018-08-29 05:55, Rob Herring wrote: > > On Fri, Aug 24, 2018 at 04:12:15PM +0530, Dilip Kota wrote: > >> From: Girish Mahadevan > >> > >> This driver supports GENI based SPI Controller in the Qualcomm SOCs. > >> The > >> Qualcomm Generic Interface (GENI) is a programmable module supporting > >> a > >> wide range of serial interfaces including SPI. This driver supports > >> SPI > >> operations using FIFO mode of transfer. > >> > >> Signed-off-by: Girish Mahadevan > >> Signed-off-by: Dilip Kota > >> --- > >> Addressing all the reviewer commets given in Patchset1. > >> Summerizing all the comments below: > >> > >> MAKEFILE: Arrange SPI-GENI driver in alphabetical order > >> Kconfig: Mark SPI_GENI driver dependent on QCOM_GENI_SE > >> Enable SPI core auto runtime pm, and remove runtime pm calls. > >> Remove spi_geni_unprepare_message(), > >> spi_geni_unprepare_transfer_hardware() > >> Remove likely/unlikely keywords. > >> Remove get_spi_master() and use dev_get_drvdata() > >> Move request_irq to probe() > >> Mark bus number assignment to -1 as SPI core framework will assign > >> dynamically > >> Use devm_spi_register_master() > >> Include platform_device.h instead of of_platform.h > >> Removing macros which are used only once: > >> #define SPI_NUM_CHIPSELECT 4 > >> #define SPI_XFER_TIMEOUT_MS250 > >> Place Register field definitions next to respective Register > >> definitions. > >> Replace int and u32 declerations to unsigned int. > >> Remove Hex numbers in debug prints. > >> Declare mode as u16 in spi_setup_word_len() > >> Remove the labels: setup_fifo_params_exit: > >> exit_prepare_transfer_hardware: > >> Declaring struct spi_master as spi everywhere in the file. > >> Calling spi_finalize_current_transfer() for end of transfer. > >> Hard code the SPI controller max frequency instead of reading from > >> DTSI node. > >> Spinlock not required, removed it. > >> Removed unrequired error prints. > >> Fix KASAN error in geni_spi_isr(). > >> Remove spi-geni-qcom.h > >> Remove inter words delay and CS to Clock toggle delay logic in the > >> driver, as of now no clients are using it. > >> Will submit this logic in the next patchset. > >> Use major, minor and step macros to read from hardware version > >> register. > >> > >> .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 2 - > > > > Please split to a separate patch and explain why you are removing > > spi-max-frequency? > > Hi Rob Herring, > > In this patch, added changes for Driver not to read the SPI controller > Maximum frequency from the device tree. Accordingly I removed it in the > device tree documentation file. As both the files need to updated so did > in the same patch. Just because the Linux driver doesn't use it isn't a reason. What if there is another OS driver for it? The binding is the h/w description, not what the driver uses currently. > Could you please let me know the reason for making a separate patch. - Step 1 of Documentation/devicetree/bindings/submitting-patches.txt says so - I only review the binding generally, so my ack or reviewed by only applies to it. - It makes the commit history of the DT only tree[1] more logical. Rob [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
Re: [PATCH V3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP
On Wed, Aug 29, 2018 at 6:19 AM wrote: > > On 2018-08-29 05:55, Rob Herring wrote: > > On Fri, Aug 24, 2018 at 04:12:15PM +0530, Dilip Kota wrote: > >> From: Girish Mahadevan > >> > >> This driver supports GENI based SPI Controller in the Qualcomm SOCs. > >> The > >> Qualcomm Generic Interface (GENI) is a programmable module supporting > >> a > >> wide range of serial interfaces including SPI. This driver supports > >> SPI > >> operations using FIFO mode of transfer. > >> > >> Signed-off-by: Girish Mahadevan > >> Signed-off-by: Dilip Kota > >> --- > >> Addressing all the reviewer commets given in Patchset1. > >> Summerizing all the comments below: > >> > >> MAKEFILE: Arrange SPI-GENI driver in alphabetical order > >> Kconfig: Mark SPI_GENI driver dependent on QCOM_GENI_SE > >> Enable SPI core auto runtime pm, and remove runtime pm calls. > >> Remove spi_geni_unprepare_message(), > >> spi_geni_unprepare_transfer_hardware() > >> Remove likely/unlikely keywords. > >> Remove get_spi_master() and use dev_get_drvdata() > >> Move request_irq to probe() > >> Mark bus number assignment to -1 as SPI core framework will assign > >> dynamically > >> Use devm_spi_register_master() > >> Include platform_device.h instead of of_platform.h > >> Removing macros which are used only once: > >> #define SPI_NUM_CHIPSELECT 4 > >> #define SPI_XFER_TIMEOUT_MS250 > >> Place Register field definitions next to respective Register > >> definitions. > >> Replace int and u32 declerations to unsigned int. > >> Remove Hex numbers in debug prints. > >> Declare mode as u16 in spi_setup_word_len() > >> Remove the labels: setup_fifo_params_exit: > >> exit_prepare_transfer_hardware: > >> Declaring struct spi_master as spi everywhere in the file. > >> Calling spi_finalize_current_transfer() for end of transfer. > >> Hard code the SPI controller max frequency instead of reading from > >> DTSI node. > >> Spinlock not required, removed it. > >> Removed unrequired error prints. > >> Fix KASAN error in geni_spi_isr(). > >> Remove spi-geni-qcom.h > >> Remove inter words delay and CS to Clock toggle delay logic in the > >> driver, as of now no clients are using it. > >> Will submit this logic in the next patchset. > >> Use major, minor and step macros to read from hardware version > >> register. > >> > >> .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 2 - > > > > Please split to a separate patch and explain why you are removing > > spi-max-frequency? > > Hi Rob Herring, > > In this patch, added changes for Driver not to read the SPI controller > Maximum frequency from the device tree. Accordingly I removed it in the > device tree documentation file. As both the files need to updated so did > in the same patch. Just because the Linux driver doesn't use it isn't a reason. What if there is another OS driver for it? The binding is the h/w description, not what the driver uses currently. > Could you please let me know the reason for making a separate patch. - Step 1 of Documentation/devicetree/bindings/submitting-patches.txt says so - I only review the binding generally, so my ack or reviewed by only applies to it. - It makes the commit history of the DT only tree[1] more logical. Rob [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
Re: [PATCH 3/4] mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE
On 08/27/2018 04:00 AM, Peter Zijlstra wrote:
>
> The one obvious thing SH and ARM want is a sensible default for
> tlb_start_vma(). (also: https://lkml.org/lkml/2004/1/15/6 )
>
> The below make tlb_start_vma() default to flush_cache_range(), which
> should be right and sufficient. The only exceptions that I found where
> (oddly):
>
> - m68k-mmu
> - sparc64
> - unicore
>
> Those architectures appear to have a non-NOP flush_cache_range(), but
> their current tlb_start_vma() does not call it.
So indeed we follow the DaveM's insight from 2004 about tlb_{start,end}_vma()
and
those are No-ops for ARC for the general case. For the historic VIPT aliasing
dcache they are what they should be per 2004 link above - I presume that is all
hunky dory with you ?
> Furthermore, I think tlb_flush() is broken on arc and parisc; in
> particular they don't appear to have any TLB invalidate for the
> shift_arg_pages() case, where we do not call tlb_*_vma() and fullmm=0.
Care to explain this issue a bit more ?
And that is independent of the current discussion.
> Possibly shift_arg_pages() should be fixed instead.
>
> Some archs (nds32,sparc32) avoid this by having an unconditional
> flush_tlb_mm() in tlb_flush(), which seems somewhat suboptimal if you
> have flush_tlb_range(). TLB_FLUSH_VMA() might be an option, however
> hideous it is.
>
> ---
>
> diff --git a/arch/arc/include/asm/tlb.h b/arch/arc/include/asm/tlb.h
> index a9db5f62aaf3..7af2b373ebe7 100644
> --- a/arch/arc/include/asm/tlb.h
> +++ b/arch/arc/include/asm/tlb.h
> @@ -23,15 +23,6 @@ do { \
> *
> * Note, read http://lkml.org/lkml/2004/1/15/6
> */
> -#ifndef CONFIG_ARC_CACHE_VIPT_ALIASING
> -#define tlb_start_vma(tlb, vma)
> -#else
> -#define tlb_start_vma(tlb, vma)
> \
> -do { \
> - if (!tlb->fullmm) \
> - flush_cache_range(vma, vma->vm_start, vma->vm_end); \
> -} while(0)
> -#endif
>
> #define tlb_end_vma(tlb, vma)
> \
> do { \
[snip..]
> \
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index e811ef7b8350..1d037fd5bb7a 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -181,19 +181,21 @@ static inline void
> tlb_remove_check_page_size_change(struct mmu_gather *tlb,
> * the vmas are adjusted to only cover the region to be torn down.
> */
> #ifndef tlb_start_vma
> -#define tlb_start_vma(tlb, vma) do { } while (0)
> +#define tlb_start_vma(tlb, vma)
> \
> +do { \
> + if (!tlb->fullmm) \
> + flush_cache_range(vma, vma->vm_start, vma->vm_end); \
> +} while (0)
> #endif
So for non aliasing arches to be not affected, this relies on
flush_cache_range()
to be no-op ?
> -#define __tlb_end_vma(tlb, vma) \
> - do {\
> - if (!tlb->fullmm && tlb->end) { \
> - tlb_flush(tlb); \
> - __tlb_reset_range(tlb); \
> - } \
> - } while (0)
> -
> #ifndef tlb_end_vma
> -#define tlb_end_vma __tlb_end_vma
> +#define tlb_end_vma(tlb, vma)
> \
> + do {\
> + if (!tlb->fullmm && tlb->end) { \
> + tlb_flush(tlb); \
> + __tlb_reset_range(tlb); \
> + } \
> + } while (0)
> #endif
>
> #ifndef __tlb_remove_tlb_entry
And this one is for shift_arg_pages() but will also cause extraneous flushes for
other cases - not happening currently !
-Vineet
Re: [PATCH 3/4] mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE
On 08/27/2018 04:00 AM, Peter Zijlstra wrote:
>
> The one obvious thing SH and ARM want is a sensible default for
> tlb_start_vma(). (also: https://lkml.org/lkml/2004/1/15/6 )
>
> The below make tlb_start_vma() default to flush_cache_range(), which
> should be right and sufficient. The only exceptions that I found where
> (oddly):
>
> - m68k-mmu
> - sparc64
> - unicore
>
> Those architectures appear to have a non-NOP flush_cache_range(), but
> their current tlb_start_vma() does not call it.
So indeed we follow the DaveM's insight from 2004 about tlb_{start,end}_vma()
and
those are No-ops for ARC for the general case. For the historic VIPT aliasing
dcache they are what they should be per 2004 link above - I presume that is all
hunky dory with you ?
> Furthermore, I think tlb_flush() is broken on arc and parisc; in
> particular they don't appear to have any TLB invalidate for the
> shift_arg_pages() case, where we do not call tlb_*_vma() and fullmm=0.
Care to explain this issue a bit more ?
And that is independent of the current discussion.
> Possibly shift_arg_pages() should be fixed instead.
>
> Some archs (nds32,sparc32) avoid this by having an unconditional
> flush_tlb_mm() in tlb_flush(), which seems somewhat suboptimal if you
> have flush_tlb_range(). TLB_FLUSH_VMA() might be an option, however
> hideous it is.
>
> ---
>
> diff --git a/arch/arc/include/asm/tlb.h b/arch/arc/include/asm/tlb.h
> index a9db5f62aaf3..7af2b373ebe7 100644
> --- a/arch/arc/include/asm/tlb.h
> +++ b/arch/arc/include/asm/tlb.h
> @@ -23,15 +23,6 @@ do { \
> *
> * Note, read http://lkml.org/lkml/2004/1/15/6
> */
> -#ifndef CONFIG_ARC_CACHE_VIPT_ALIASING
> -#define tlb_start_vma(tlb, vma)
> -#else
> -#define tlb_start_vma(tlb, vma)
> \
> -do { \
> - if (!tlb->fullmm) \
> - flush_cache_range(vma, vma->vm_start, vma->vm_end); \
> -} while(0)
> -#endif
>
> #define tlb_end_vma(tlb, vma)
> \
> do { \
[snip..]
> \
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index e811ef7b8350..1d037fd5bb7a 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -181,19 +181,21 @@ static inline void
> tlb_remove_check_page_size_change(struct mmu_gather *tlb,
> * the vmas are adjusted to only cover the region to be torn down.
> */
> #ifndef tlb_start_vma
> -#define tlb_start_vma(tlb, vma) do { } while (0)
> +#define tlb_start_vma(tlb, vma)
> \
> +do { \
> + if (!tlb->fullmm) \
> + flush_cache_range(vma, vma->vm_start, vma->vm_end); \
> +} while (0)
> #endif
So for non aliasing arches to be not affected, this relies on
flush_cache_range()
to be no-op ?
> -#define __tlb_end_vma(tlb, vma) \
> - do {\
> - if (!tlb->fullmm && tlb->end) { \
> - tlb_flush(tlb); \
> - __tlb_reset_range(tlb); \
> - } \
> - } while (0)
> -
> #ifndef tlb_end_vma
> -#define tlb_end_vma __tlb_end_vma
> +#define tlb_end_vma(tlb, vma)
> \
> + do {\
> + if (!tlb->fullmm && tlb->end) { \
> + tlb_flush(tlb); \
> + __tlb_reset_range(tlb); \
> + } \
> + } while (0)
> #endif
>
> #ifndef __tlb_remove_tlb_entry
And this one is for shift_arg_pages() but will also cause extraneous flushes for
other cases - not happening currently !
-Vineet
Re: [PATCH 1/2] ASoC: Add driver for PROTO Audio CODEC (with a WM8731)
Hi Codrin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on at91/at91-next]
[also build test ERROR on v4.19-rc1 next-20180829]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Codrin-Ciubotariu/ASoC-Add-driver-for-PROTO-Audio-CODEC-with-a-WM8731/20180830-060610
base: https://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git
at91-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
sound/soc/atmel/mikroe-proto.c: In function 'snd_proto_init':
>> sound/soc/atmel/mikroe-proto.c:49:35: error: 'struct snd_soc_pcm_runtime'
>> has no member named 'codec'
struct snd_soc_codec *codec = rtd->codec;
^~
>> sound/soc/atmel/mikroe-proto.c:56:16: error: dereferencing pointer to
>> incomplete type 'struct snd_soc_codec'
dev_err(codec->dev, "Failed to set WM8731 SYSCLK: %d\n", ret);
^~
vim +49 sound/soc/atmel/mikroe-proto.c
46
47 static int snd_proto_init(struct snd_soc_pcm_runtime *rtd)
48 {
> 49 struct snd_soc_codec *codec = rtd->codec;
50 struct snd_soc_dai *codec_dai = rtd->codec_dai;
51
52 /* Set proto sysclk */
53 int ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
54 XTAL_RATE, SND_SOC_CLOCK_IN);
55 if (ret < 0) {
> 56 dev_err(codec->dev, "Failed to set WM8731 SYSCLK:
%d\n", ret);
57 return ret;
58 }
59
60 return 0;
61 }
62
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 1/2] ASoC: Add driver for PROTO Audio CODEC (with a WM8731)
Hi Codrin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on at91/at91-next]
[also build test ERROR on v4.19-rc1 next-20180829]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Codrin-Ciubotariu/ASoC-Add-driver-for-PROTO-Audio-CODEC-with-a-WM8731/20180830-060610
base: https://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git
at91-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
sound/soc/atmel/mikroe-proto.c: In function 'snd_proto_init':
>> sound/soc/atmel/mikroe-proto.c:49:35: error: 'struct snd_soc_pcm_runtime'
>> has no member named 'codec'
struct snd_soc_codec *codec = rtd->codec;
^~
>> sound/soc/atmel/mikroe-proto.c:56:16: error: dereferencing pointer to
>> incomplete type 'struct snd_soc_codec'
dev_err(codec->dev, "Failed to set WM8731 SYSCLK: %d\n", ret);
^~
vim +49 sound/soc/atmel/mikroe-proto.c
46
47 static int snd_proto_init(struct snd_soc_pcm_runtime *rtd)
48 {
> 49 struct snd_soc_codec *codec = rtd->codec;
50 struct snd_soc_dai *codec_dai = rtd->codec_dai;
51
52 /* Set proto sysclk */
53 int ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
54 XTAL_RATE, SND_SOC_CLOCK_IN);
55 if (ret < 0) {
> 56 dev_err(codec->dev, "Failed to set WM8731 SYSCLK:
%d\n", ret);
57 return ret;
58 }
59
60 return 0;
61 }
62
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 11/13] proc: readdir /proc/*/task
On Tue, 28 Aug 2018 22:35:02 +0300 Alexey Dobriyan wrote: > > Are we really in a super hot path to justify all that? > > /proc is very slow, try profiling just about anything involving /proc. So how much does this patchset help? Some timing measurements would really help things along, if they show goodness.
Re: [PATCH 11/13] proc: readdir /proc/*/task
On Tue, 28 Aug 2018 22:35:02 +0300 Alexey Dobriyan wrote: > > Are we really in a super hot path to justify all that? > > /proc is very slow, try profiling just about anything involving /proc. So how much does this patchset help? Some timing measurements would really help things along, if they show goodness.
Re: mmotm 2018-08-23-17-26 uploaded
On Tue, 28 Aug 2018 12:20:46 +0800 Jia He wrote: > Hi Andrew > FYI,I watched a lockdep warning based on your mmotm master branch[1] Thanks. We'll need help from ARM peeps on this please. > [6.692731] [ cut here ] > [6.696391] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled) > [6.696404] WARNING: CPU: 3 PID: 320 at kernel/locking/lockdep.c:3845 > check_flags.part.38+0x9c/0x16c > [6.711082] Modules linked in: > [6.714101] CPU: 3 PID: 320 Comm: modprobe Not tainted 4.18.0-rc4-mm1+ #56 > [6.720956] Hardware name: WIWYNN HXT REP-1 System H001-1-0/HXT REP-1 > CRB, BIOS 0ACJA530 03/20/2018 > [6.730332] pstate: 60400085 (nZCv daIf +PAN -UAO) > [6.735106] pc : check_flags.part.38+0x9c/0x16c > [6.739619] lr : check_flags.part.38+0x9c/0x16c > [6.744133] sp : 80178536fbf0 > [6.747432] x29: 80178536fbf0 x28: 8017905a1b00 > [6.752727] x27: 0002 x26: > [6.758022] x25: 08abeb14 x24: > [6.763317] x23: 0001 x22: 0001 > [6.768612] x21: 0001 x20: > [6.773908] x19: 0a041000 x18: > [6.779202] x17: x16: > [6.784498] x15: x14: > [6.789793] x13: 08d6b190 x12: 752ce9eb60de3f00 > [6.795088] x11: 80178536f7f0 x10: 80178536f7f0 > [6.800383] x9 : ffd0 x8 : > [6.805678] x7 : 0816fe48 x6 : 801794ba62b8 > [6.810973] x5 : x4 : > [6.816269] x3 : x2 : 091ed988 > [6.821564] x1 : 752ce9eb60de3f00 x0 : 752ce9eb60de3f00 > [6.826859] Call trace: > [6.829290] check_flags.part.38+0x9c/0x16c > [6.833457] lock_acquire+0x12c/0x280 > [6.837104] down_read_trylock+0x78/0x98 > [6.841011] do_page_fault+0x150/0x480 > [6.844742] do_translation_fault+0x74/0x80 > [6.848909] do_mem_abort+0x60/0x108 > [6.852467] el0_da+0x24/0x28 > [6.855418] irq event stamp: 250 > [6.858633] hardirqs last enabled at (249): [] > mem_cgroup_commit_charge+0x9c/0x13c > [6.867833] hardirqs last disabled at (250): [] > el0_svc_handler+0xc4/0x16c > [6.876252] softirqs last enabled at (242): [] > __do_softirq+0x2f8/0x554 > [6.884501] softirqs last disabled at (229): [] > irq_exit+0x180/0x194 > [6.892399] ---[ end trace b45768f94a7b7d9f ]--- > [6.896998] possible reason: unannotated irqs-on. > [6.901685] irq event stamp: 250 > [6.904898] hardirqs last enabled at (249): [] > mem_cgroup_commit_charge+0x9c/0x13c > [6.914100] hardirqs last disabled at (250): [] > el0_svc_handler+0xc4/0x16c > [6.922519] softirqs last enabled at (242): [] > __do_softirq+0x2f8/0x554 > [6.930766] softirqs last disabled at (229): [] > irq_exit+0x180/0x194 > [7.023827] Initialise system trusted keyrings > [7.027414] workingset: timestamp_bits=45 max_order=25 bucket_order=0 Lockdep says current->hardirqs_enabled is false and that is indeed an error. arch/arm64/kernel/entry.S:el0_da does enable_daif which might be an attempt to enable hardirqs, but how does that get propagated into lockdep's ->hardirqs_enabled? By calling local_irq_enable()->trace_hardirqs_on(), but that's C, not assembler. And what changed to cause this? I dunno anything. Help! > I thought the root cause might be at [2] which seems not in your branch yet. > > [1] http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=efd112 I agree, that doesn't look like the culprit. But something may well have gone wrong in "the recent conversion of the syscall entry/exit code to C". > > ... >
Re: mmotm 2018-08-23-17-26 uploaded
On Tue, 28 Aug 2018 12:20:46 +0800 Jia He wrote: > Hi Andrew > FYI,I watched a lockdep warning based on your mmotm master branch[1] Thanks. We'll need help from ARM peeps on this please. > [6.692731] [ cut here ] > [6.696391] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled) > [6.696404] WARNING: CPU: 3 PID: 320 at kernel/locking/lockdep.c:3845 > check_flags.part.38+0x9c/0x16c > [6.711082] Modules linked in: > [6.714101] CPU: 3 PID: 320 Comm: modprobe Not tainted 4.18.0-rc4-mm1+ #56 > [6.720956] Hardware name: WIWYNN HXT REP-1 System H001-1-0/HXT REP-1 > CRB, BIOS 0ACJA530 03/20/2018 > [6.730332] pstate: 60400085 (nZCv daIf +PAN -UAO) > [6.735106] pc : check_flags.part.38+0x9c/0x16c > [6.739619] lr : check_flags.part.38+0x9c/0x16c > [6.744133] sp : 80178536fbf0 > [6.747432] x29: 80178536fbf0 x28: 8017905a1b00 > [6.752727] x27: 0002 x26: > [6.758022] x25: 08abeb14 x24: > [6.763317] x23: 0001 x22: 0001 > [6.768612] x21: 0001 x20: > [6.773908] x19: 0a041000 x18: > [6.779202] x17: x16: > [6.784498] x15: x14: > [6.789793] x13: 08d6b190 x12: 752ce9eb60de3f00 > [6.795088] x11: 80178536f7f0 x10: 80178536f7f0 > [6.800383] x9 : ffd0 x8 : > [6.805678] x7 : 0816fe48 x6 : 801794ba62b8 > [6.810973] x5 : x4 : > [6.816269] x3 : x2 : 091ed988 > [6.821564] x1 : 752ce9eb60de3f00 x0 : 752ce9eb60de3f00 > [6.826859] Call trace: > [6.829290] check_flags.part.38+0x9c/0x16c > [6.833457] lock_acquire+0x12c/0x280 > [6.837104] down_read_trylock+0x78/0x98 > [6.841011] do_page_fault+0x150/0x480 > [6.844742] do_translation_fault+0x74/0x80 > [6.848909] do_mem_abort+0x60/0x108 > [6.852467] el0_da+0x24/0x28 > [6.855418] irq event stamp: 250 > [6.858633] hardirqs last enabled at (249): [] > mem_cgroup_commit_charge+0x9c/0x13c > [6.867833] hardirqs last disabled at (250): [] > el0_svc_handler+0xc4/0x16c > [6.876252] softirqs last enabled at (242): [] > __do_softirq+0x2f8/0x554 > [6.884501] softirqs last disabled at (229): [] > irq_exit+0x180/0x194 > [6.892399] ---[ end trace b45768f94a7b7d9f ]--- > [6.896998] possible reason: unannotated irqs-on. > [6.901685] irq event stamp: 250 > [6.904898] hardirqs last enabled at (249): [] > mem_cgroup_commit_charge+0x9c/0x13c > [6.914100] hardirqs last disabled at (250): [] > el0_svc_handler+0xc4/0x16c > [6.922519] softirqs last enabled at (242): [] > __do_softirq+0x2f8/0x554 > [6.930766] softirqs last disabled at (229): [] > irq_exit+0x180/0x194 > [7.023827] Initialise system trusted keyrings > [7.027414] workingset: timestamp_bits=45 max_order=25 bucket_order=0 Lockdep says current->hardirqs_enabled is false and that is indeed an error. arch/arm64/kernel/entry.S:el0_da does enable_daif which might be an attempt to enable hardirqs, but how does that get propagated into lockdep's ->hardirqs_enabled? By calling local_irq_enable()->trace_hardirqs_on(), but that's C, not assembler. And what changed to cause this? I dunno anything. Help! > I thought the root cause might be at [2] which seems not in your branch yet. > > [1] http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=efd112 I agree, that doesn't look like the culprit. But something may well have gone wrong in "the recent conversion of the syscall entry/exit code to C". > > ... >
[PATCH 2/3] firmware: qcom: scm: Refactor clock handling
At one point in time all "future" platforms required three clocks, so
the binding and driver was written to treat this as the default case.
But new platforms has no clock requirements, which currently makes them
all a special case, causing the need for a patch in the binding and
driver for each new platform added.
This patch reworks the driver logic so that it will attempt to acquire
all three clocks and fail based on the given compatible. This allow us
to drop the clock requirement from "qcom,scm", in a way that will remain
backwards compatible with existing DT files.
Specific compatibles are added for apq8084, msm8916 and msm8974 to match
the updated binding and although equivalent to qcom,scm both ipq4019 and
msm8996 are kept as these have been used without fallback to qcom,scm.
The result of this patch is that new platforms, that require no clocks,
can be use the fallback compatible of "qcom,scm".
Signed-off-by: Bjorn Andersson
---
drivers/firmware/qcom_scm.c | 74 +
1 file changed, 42 insertions(+), 32 deletions(-)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index e778af766fae..af4eee86919d 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -525,34 +525,44 @@ static int qcom_scm_probe(struct platform_device *pdev)
return ret;
clks = (unsigned long)of_device_get_match_data(>dev);
- if (clks & SCM_HAS_CORE_CLK) {
- scm->core_clk = devm_clk_get(>dev, "core");
- if (IS_ERR(scm->core_clk)) {
- if (PTR_ERR(scm->core_clk) != -EPROBE_DEFER)
- dev_err(>dev,
- "failed to acquire core clk\n");
+
+ scm->core_clk = devm_clk_get(>dev, "core");
+ if (IS_ERR(scm->core_clk)) {
+ if (PTR_ERR(scm->core_clk) == -EPROBE_DEFER)
+ return PTR_ERR(scm->core_clk);
+
+ if (clks & SCM_HAS_CORE_CLK) {
+ dev_err(>dev, "failed to acquire core clk\n");
return PTR_ERR(scm->core_clk);
}
+
+ scm->core_clk = NULL;
}
- if (clks & SCM_HAS_IFACE_CLK) {
- scm->iface_clk = devm_clk_get(>dev, "iface");
- if (IS_ERR(scm->iface_clk)) {
- if (PTR_ERR(scm->iface_clk) != -EPROBE_DEFER)
- dev_err(>dev,
- "failed to acquire iface clk\n");
+ scm->iface_clk = devm_clk_get(>dev, "iface");
+ if (IS_ERR(scm->iface_clk)) {
+ if (PTR_ERR(scm->iface_clk) == -EPROBE_DEFER)
+ return PTR_ERR(scm->iface_clk);
+
+ if (clks & SCM_HAS_IFACE_CLK) {
+ dev_err(>dev, "failed to acquire iface clk\n");
return PTR_ERR(scm->iface_clk);
}
+
+ scm->iface_clk = NULL;
}
- if (clks & SCM_HAS_BUS_CLK) {
- scm->bus_clk = devm_clk_get(>dev, "bus");
- if (IS_ERR(scm->bus_clk)) {
- if (PTR_ERR(scm->bus_clk) != -EPROBE_DEFER)
- dev_err(>dev,
- "failed to acquire bus clk\n");
+ scm->bus_clk = devm_clk_get(>dev, "bus");
+ if (IS_ERR(scm->bus_clk)) {
+ if (PTR_ERR(scm->bus_clk) == -EPROBE_DEFER)
+ return PTR_ERR(scm->bus_clk);
+
+ if (clks & SCM_HAS_BUS_CLK) {
+ dev_err(>dev, "failed to acquire bus clk\n");
return PTR_ERR(scm->bus_clk);
}
+
+ scm->bus_clk = NULL;
}
scm->reset.ops = _scm_pas_reset_ops;
@@ -594,23 +604,23 @@ static const struct of_device_id qcom_scm_dt_match[] = {
{ .compatible = "qcom,scm-apq8064",
/* FIXME: This should have .data = (void *) SCM_HAS_CORE_CLK */
},
- { .compatible = "qcom,scm-msm8660",
- .data = (void *) SCM_HAS_CORE_CLK,
- },
- { .compatible = "qcom,scm-msm8960",
- .data = (void *) SCM_HAS_CORE_CLK,
- },
- { .compatible = "qcom,scm-msm8996",
- .data = NULL, /* no clocks */
+ { .compatible = "qcom,scm-apq8084", .data = (void *)(SCM_HAS_CORE_CLK |
+SCM_HAS_IFACE_CLK |
+SCM_HAS_BUS_CLK)
},
- { .compatible = "qcom,scm-ipq4019",
- .data = NULL, /* no clocks */
+ { .compatible = "qcom,scm-ipq4019" },
+ { .compatible = "qcom,scm-msm8660", .data = (void *) SCM_HAS_CORE_CLK },
+ { .compatible = "qcom,scm-msm8960", .data = (void *) SCM_HAS_CORE_CLK },
+ { .compatible = "qcom,scm-msm8916", .data = (void *)(SCM_HAS_CORE_CLK |
+
[PATCH 1/3] dt-bindings: firmware: scm: Refactor compatibles and clocks
When the binding was written all "future" platforms required three
clocks, so the default compatible (qcom,scm) was defined to require
this. But as history shows all "future" platforms actually lack required
clocks. Given how the binding is written these compatibles have to be
added as an exception to the default.
Refactor the description of compatible to define that a platform
compatible should be given, followed by the fallback of qcom,scm. Also
refactor the description of the clocks in a way that this does not need
to be updated as new platform specific compatibles are added.
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/firmware/qcom,scm.txt | 31 ---
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index fcf6979c0b6d..1c8e24530f7c 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -7,16 +7,21 @@ assorted actions.
Required properties:
- compatible: must contain one of the following:
- * "qcom,scm-apq8064" for APQ8064 platforms
- * "qcom,scm-msm8660" for MSM8660 platforms
- * "qcom,scm-msm8690" for MSM8690 platforms
- * "qcom,scm-msm8996" for MSM8996 platforms
- * "qcom,scm-ipq4019" for IPQ4019 platforms
- * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
-- clocks: One to three clocks may be required based on compatible.
- * No clock required for "qcom,scm-msm8996", "qcom,scm-ipq4019"
- * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and
"qcom,scm-msm8960"
- * Core, iface, and bus clocks required for "qcom,scm"
+ * "qcom,scm-apq8064"
+ * "qcom,scm-apq8084"
+ * "qcom,scm-msm8660"
+ * "qcom,scm-msm8916"
+ * "qcom,scm-msm8960"
+ * "qcom,scm-msm8974"
+ * "qcom,scm-msm8996"
+ * "qcom,scm-ipq4019"
+ and:
+ * "qcom,scm"
+- clocks: Specifies clocks needed by the SCM interface, if any:
+ * core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660" and
+ "qcom,scm-msm8960"
+ * core, iface and bus clocks required for "qcom,scm-apq8084",
+ "qcom,scm-msm8916" and "qcom,scm-msm8974"
- clock-names: Must contain "core" for the core clock, "iface" for the
interface
clock and "bus" for the bus clock per the requirements of the compatible.
- qcom,dload-mode: phandle to the TCSR hardware block and offset of the
@@ -26,8 +31,10 @@ Example for MSM8916:
firmware {
scm {
- compatible = "qcom,scm";
- clocks = < GCC_CRYPTO_CLK> , <
GCC_CRYPTO_AXI_CLK>, < GCC_CRYPTO_AHB_CLK>;
+ compatible = "qcom,msm8916", "qcom,scm";
+ clocks = < GCC_CRYPTO_CLK> ,
+< GCC_CRYPTO_AXI_CLK>,
+< GCC_CRYPTO_AHB_CLK>;
clock-names = "core", "bus", "iface";
};
};
--
2.18.0
