[PATCH 0/2] Fatal signal handing within uaccess faults

Hi, Arch maintainer tl;dr: most arch fault code doesn't handle fatal signals correctly, allowing unprivileged users to create an unkillable task which can lock up the system. Please check whether your arch is affected. AFAICT, most arches don't correctly handle a fatal signal interrupting a

[PATCH 0/2] Fatal signal handing within uaccess faults

Hi, Arch maintainer tl;dr: most arch fault code doesn't handle fatal signals correctly, allowing unprivileged users to create an unkillable task which can lock up the system. Please check whether your arch is affected. AFAICT, most arches don't correctly handle a fatal signal interrupting a

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

On 07/11/2017 08:15 AM, Peter Zijlstra wrote: > On Mon, Jul 10, 2017 at 05:01:19PM -0400, Waiman Long wrote: >> On 07/10/2017 04:32 AM, Peter Zijlstra wrote: >>> On Fri, Jun 30, 2017 at 09:23:24AM -0400, Tejun Heo wrote: On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote: > On

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

On 07/11/2017 08:15 AM, Peter Zijlstra wrote: > On Mon, Jul 10, 2017 at 05:01:19PM -0400, Waiman Long wrote: >> On 07/10/2017 04:32 AM, Peter Zijlstra wrote: >>> On Fri, Jun 30, 2017 at 09:23:24AM -0400, Tejun Heo wrote: On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote: > On

Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient

Hi Viresh, On Tue, Jul 11, 2017 at 3:14 AM, Viresh Kumar wrote: > On 09-07-17, 10:08, Joel Fernandes wrote: >> diff --git a/kernel/sched/cpufreq_schedutil.c >> b/kernel/sched/cpufreq_schedutil.c >> index 622eed1b7658..4d9e8b96bed1 100644 >> ---

Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient

Hi Viresh, On Tue, Jul 11, 2017 at 3:14 AM, Viresh Kumar wrote: > On 09-07-17, 10:08, Joel Fernandes wrote: >> diff --git a/kernel/sched/cpufreq_schedutil.c >> b/kernel/sched/cpufreq_schedutil.c >> index 622eed1b7658..4d9e8b96bed1 100644 >> --- a/kernel/sched/cpufreq_schedutil.c >> +++

[PATCH] scsi: scsi_dh_alua: fix boolreturn.cocci warnings

drivers/scsi/device_handler/scsi_dh_alua.c:594:9-10: WARNING: return of 0/1 in function 'alua_rtpg_print_check' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: scripts/coccinelle/misc/boolreturn.cocci Fixes: cb809ba2fcbf

Re: [PATCH v2 3/4] scsi: scsi_dh_alua: do not print RTPG state if it remains unavailable/standby

Hi Mauricio, [auto build test WARNING on bvanassche/for-next] [also build test WARNING on v4.12 next-20170711] [cannot apply to mkp-scsi/for-next scsi/for-next] [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

[PATCH] scsi: scsi_dh_alua: fix boolreturn.cocci warnings

drivers/scsi/device_handler/scsi_dh_alua.c:594:9-10: WARNING: return of 0/1 in function 'alua_rtpg_print_check' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: scripts/coccinelle/misc/boolreturn.cocci Fixes: cb809ba2fcbf

Re: [PATCH v2 3/4] scsi: scsi_dh_alua: do not print RTPG state if it remains unavailable/standby

Hi Mauricio, [auto build test WARNING on bvanassche/for-next] [also build test WARNING on v4.12 next-20170711] [cannot apply to mkp-scsi/for-next scsi/for-next] [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

[PATCH] ARM: dts: uniphier: use SPDX-License-Identifier (2nd)

Commit fa53757bca33 ("ARM: dts: uniphier: use SPDX-License-Identifier") missed to touch these two. Now updating. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-pinctrl.dtsi | 38 +

[PATCH] ARM: dts: uniphier: use SPDX-License-Identifier (2nd)

Commit fa53757bca33 ("ARM: dts: uniphier: use SPDX-License-Identifier") missed to touch these two. Now updating. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-pinctrl.dtsi | 38 + arch/arm/boot/dts/uniphier-pro5.dtsi| 38

[PATCH] ASoC: hdmi-codec: make const array hdmi_codec_eld_spk_alloc_bits static

From: Colin Ian King Don't populate array hdmi_codec_eld_spk_alloc_bits on the stack but make it static. Makes the object code smaller by over 260 bytes: Before: textdata bss dec hex filename 108823384 64 1433037fa

[PATCH] ASoC: hdmi-codec: make const array hdmi_codec_eld_spk_alloc_bits static

From: Colin Ian King Don't populate array hdmi_codec_eld_spk_alloc_bits on the stack but make it static. Makes the object code smaller by over 260 bytes: Before: textdata bss dec hex filename 108823384 64 1433037fa sound/soc/codecs/hdmi-codec.o After:

[PATCH] power: supply: ltc2941-battery-gauge: Add LTC2944 support

The only difference between the already supported LTC2943 and LTC2944 is the operating range (3.6V - 20V compared to 3.6V - 60V). Signed-off-by: Dragos Bogdan --- Documentation/devicetree/bindings/power/supply/ltc2941.txt | 10 +-

[PATCH] power: supply: ltc2941-battery-gauge: Add LTC2944 support

The only difference between the already supported LTC2943 and LTC2944 is the operating range (3.6V - 20V compared to 3.6V - 60V). Signed-off-by: Dragos Bogdan --- Documentation/devicetree/bindings/power/supply/ltc2941.txt | 10 +- drivers/power/supply/ltc2941-battery-gauge.c

Re: [PATCH/RFC] dma-mapping: Provide dummy set_dma_ops() for NO_DMA=y

On Mon, Jul 10, 2017 at 04:31:54PM +0100, Robin Murphy wrote: > On 10/07/17 15:56, Christoph Hellwig wrote: > > This looks reasonable to me, I'd be happy to pick it up. Can you send > > it as a series with the reverts? > > The fact remains that the FSL driver is still doing the wrong thing >

Re: [PATCH/RFC] dma-mapping: Provide dummy set_dma_ops() for NO_DMA=y

On Mon, Jul 10, 2017 at 04:31:54PM +0100, Robin Murphy wrote: > On 10/07/17 15:56, Christoph Hellwig wrote: > > This looks reasonable to me, I'd be happy to pick it up. Can you send > > it as a series with the reverts? > > The fact remains that the FSL driver is still doing the wrong thing >

Re: [PATCH 16/17] RISC-V: User-facing API

Hi Christoph, On Tue, Jul 11, 2017 at 06:39:48AM -0700, Christoph Hellwig wrote: > > +#ifdef CONFIG_64BIT > > +SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len, > > + unsigned long, prot, unsigned long, flags, > > + unsigned long, fd, off_t, offset) > > +{ > > + if

Re: [PATCH 16/17] RISC-V: User-facing API

Hi Christoph, On Tue, Jul 11, 2017 at 06:39:48AM -0700, Christoph Hellwig wrote: > > +#ifdef CONFIG_64BIT > > +SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len, > > + unsigned long, prot, unsigned long, flags, > > + unsigned long, fd, off_t, offset) > > +{ > > + if

Re: [PATCH v8 05/10] mm: thp: enable thp migration in generic path

On 11 Jul 2017, at 2:47, Naoya Horiguchi wrote: > On Sat, Jul 01, 2017 at 09:40:03AM -0400, Zi Yan wrote: >> From: Zi Yan >> >> This patch adds thp migration's core code, including conversions >> between a PMD entry and a swap entry, setting PMD migration entry, >>

Re: [PATCH v8 05/10] mm: thp: enable thp migration in generic path

On 11 Jul 2017, at 2:47, Naoya Horiguchi wrote: > On Sat, Jul 01, 2017 at 09:40:03AM -0400, Zi Yan wrote: >> From: Zi Yan >> >> This patch adds thp migration's core code, including conversions >> between a PMD entry and a swap entry, setting PMD migration entry, >> removing PMD migration entry,

Re: [PATCH 00/16] omap_hsmmc: Add ADMA support and UHS/HS200/DDR support

Hi Ulf, On Tuesday 11 July 2017 06:40 PM, Ulf Hansson wrote: > On 16 June 2017 at 14:45, Kishon Vijay Abraham I wrote: >> This is the final part of the series originally sent as >> part of [2]. >> >> This series adds UHS, HS200, DDR mode and ADMA support to >> omap_hsmmc driver

Re: [PATCH 00/16] omap_hsmmc: Add ADMA support and UHS/HS200/DDR support

Hi Ulf, On Tuesday 11 July 2017 06:40 PM, Ulf Hansson wrote: > On 16 June 2017 at 14:45, Kishon Vijay Abraham I wrote: >> This is the final part of the series originally sent as >> part of [2]. >> >> This series adds UHS, HS200, DDR mode and ADMA support to >> omap_hsmmc driver used to improve

Re: [PATCH 8/9] RISC-V: User-facing API

On Tue, Jul 11, 2017 at 02:22:15PM +0100, Will Deacon wrote: > The problem is that by supporting these hypothetical designs that can't do > atomics, you hurt sensible designs that *can* do the atomics because you > force them to take an additional indirection that could otherwise be > avoided.

Re: [PATCH 8/9] RISC-V: User-facing API

On Tue, Jul 11, 2017 at 02:22:15PM +0100, Will Deacon wrote: > The problem is that by supporting these hypothetical designs that can't do > atomics, you hurt sensible designs that *can* do the atomics because you > force them to take an additional indirection that could otherwise be > avoided.

Re: [PATCH 2/2] mmc: sdhci-of-at91: set clocks and presets after resume from deepest PM

On 11 July 2017 at 15:33, Ludovic Desroches wrote: > On Tue, Jul 11, 2017 at 02:42:44PM +0200, Ulf Hansson wrote: >> On 16 June 2017 at 09:29, Quentin Schulz >> wrote: >> > This adds deepest (Backup+Self-Refresh) PM support to

Re: [PATCH 2/2] mmc: sdhci-of-at91: set clocks and presets after resume from deepest PM

On 11 July 2017 at 15:33, Ludovic Desroches wrote: > On Tue, Jul 11, 2017 at 02:42:44PM +0200, Ulf Hansson wrote: >> On 16 June 2017 at 09:29, Quentin Schulz >> wrote: >> > This adds deepest (Backup+Self-Refresh) PM support to the ATMEL SAMA5D2 >> > SoC's SDHCI controller. >> > >> > When

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

[David did a great review, so I'll just point out things I noticed.] 2017-07-11 09:51+0200, David Hildenbrand: > On 10.07.2017 22:49, Bandan Das wrote: > > When L2 uses vmfunc, L0 utilizes the associated vmexit to > > emulate a switching of the ept pointer by reloading the > > guest MMU. > > > >

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

[David did a great review, so I'll just point out things I noticed.] 2017-07-11 09:51+0200, David Hildenbrand: > On 10.07.2017 22:49, Bandan Das wrote: > > When L2 uses vmfunc, L0 utilizes the associated vmexit to > > emulate a switching of the ept pointer by reloading the > > guest MMU. > > > >

Re: [GIT pull] irq updates for 4.13

* Thomas Gleixner [170711 02:48]: > On Tue, 11 Jul 2017, Thomas Gleixner wrote: > > So Tony actually provided the part of dmesg which shows the initial > failure, which subsequently leads to the splat Sebastian reported. > > Unhandled fault: external abort on non-linefetch

Re: [GIT pull] irq updates for 4.13

* Thomas Gleixner [170711 02:48]: > On Tue, 11 Jul 2017, Thomas Gleixner wrote: > > So Tony actually provided the part of dmesg which shows the initial > failure, which subsequently leads to the splat Sebastian reported. > > Unhandled fault: external abort on non-linefetch (0x1028) at

Re: [GIT pull] irq updates for 4.13

On 11/07/17 12:21, Sebastian Reichel wrote: > Hi, > > On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote: >> On Tue, 11 Jul 2017, Thomas Gleixner wrote: >>> On Tue, 11 Jul 2017, Sebastian Reichel wrote: >>> So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to >>>

Re: [GIT pull] irq updates for 4.13

On 11/07/17 12:21, Sebastian Reichel wrote: > Hi, > > On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote: >> On Tue, 11 Jul 2017, Thomas Gleixner wrote: >>> On Tue, 11 Jul 2017, Sebastian Reichel wrote: >>> So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to >>>

Re: [RFC PATCH 1/2] mmc: sdhci: add quirk SDHCI_QUIRK2_BROKEN_SDMA_BOUNDARY_BUFFER

On 28 June 2017 at 15:35, wrote: > From: Srinivas Kandagatla > > This patch adds quirk to sdhci controllers which are broken when > HOST SDMA Buffer Boundary is programmed in Block Size Register (0x04) > when using ADMA. Qualcomm

Re: [RFC PATCH 1/2] mmc: sdhci: add quirk SDHCI_QUIRK2_BROKEN_SDMA_BOUNDARY_BUFFER

On 28 June 2017 at 15:35, wrote: > From: Srinivas Kandagatla > > This patch adds quirk to sdhci controllers which are broken when > HOST SDMA Buffer Boundary is programmed in Block Size Register (0x04) > when using ADMA. Qualcomm sdhci controller is one of such type, writing > to this bits is

Re: [PATCH 1/2] staging: ccree: remove unnecessary cast on kmalloc

On Sun, Jul 9, 2017 at 8:43 AM, Gustavo A. R. Silva wrote: > The assignment operator implicitly converts a void pointer to the type of the > pointer it is assigned to. > > This issue was detected using Coccinelle and the following semantic patch: > > @@ > expression * e;

Re: [PATCH 1/2] staging: ccree: remove unnecessary cast on kmalloc

On Sun, Jul 9, 2017 at 8:43 AM, Gustavo A. R. Silva wrote: > The assignment operator implicitly converts a void pointer to the type of the > pointer it is assigned to. > > This issue was detected using Coccinelle and the following semantic patch: > > @@ > expression * e; > expression arg1, arg2;

[PATCH v4 1/1] ARM: dts: imx53: Add GE Healthcare PPD

From: Fabien Lahoudere PPD is a product from GE Healthcare to monitor vital biometric signals. Signed-off-by: Fabien Lahoudere Signed-off-by: Sebastian Reichel Signed-off-by: Martyn Welch

[PATCH v4 1/1] ARM: dts: imx53: Add GE Healthcare PPD

From: Fabien Lahoudere PPD is a product from GE Healthcare to monitor vital biometric signals. Signed-off-by: Fabien Lahoudere Signed-off-by: Sebastian Reichel Signed-off-by: Martyn Welch --- Changes since PATCHv3: https://patchwork.kernel.org/patch/9819017/ - licensing modified -

[PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap

From: Michal Hocko vmemmap_populate uses huge pages if the CPU supports them which is good and usually what we want. vmemmap_alloc_block will use the bootmem allocator in the early initialization so the allocation will most likely succeed. This is not the case for the memory

[PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap

From: Michal Hocko vmemmap_populate uses huge pages if the CPU supports them which is good and usually what we want. vmemmap_alloc_block will use the bootmem allocator in the early initialization so the allocation will most likely succeed. This is not the case for the memory hotplug though. Such

Re: [PATCH 16/17] RISC-V: User-facing API

> +++ b/arch/riscv/kernel/sys_riscv.c > @@ -0,0 +1,43 @@ > +/* > + * Copyright (C) 2012 Regents of the University of California > + * Copyright (C) 2014 Darius Rad > + * Copyright (C) 2017 SiFive > + * > + * This program is free software; you can redistribute it and/or > +

Re: [PATCH 16/17] RISC-V: User-facing API

> +++ b/arch/riscv/kernel/sys_riscv.c > @@ -0,0 +1,43 @@ > +/* > + * Copyright (C) 2012 Regents of the University of California > + * Copyright (C) 2014 Darius Rad > + * Copyright (C) 2017 SiFive > + * > + * This program is free software; you can redistribute it and/or > + * modify it under

Re: [RFC PATCH 2/4] pmbus: Add fan configuration support

On 07/10/2017 06:56 AM, Andrew Jeffery wrote: Augment PMBus support to include control of fans via the FAN_COMMAND_[1-4] registers, both in RPM and PWM modes. The behaviour of FAN_CONFIG_{1_2,3_4} and FAN_COMMAND_[1-4] are tightly coupled, and their interactions do not fit the existing use of

Re: [RFC PATCH 2/4] pmbus: Add fan configuration support

On 07/10/2017 06:56 AM, Andrew Jeffery wrote: Augment PMBus support to include control of fans via the FAN_COMMAND_[1-4] registers, both in RPM and PWM modes. The behaviour of FAN_CONFIG_{1_2,3_4} and FAN_COMMAND_[1-4] are tightly coupled, and their interactions do not fit the existing use of

Re: [PATCH v2] staging: ccree: Use __func__ instead of function name

Hello Karthik , Thank you for the patch. On Thu, Jun 29, 2017 at 8:08 PM, wrote: > From: Karthik Tummala > > Fixed following checkpatch.pl warning: > WARNING: Prefer using '"%s...", __func__' to using > the function's name, in a string > >

Re: [PATCH v2] staging: ccree: Use __func__ instead of function name

Hello Karthik , Thank you for the patch. On Thu, Jun 29, 2017 at 8:08 PM, wrote: > From: Karthik Tummala > > Fixed following checkpatch.pl warning: > WARNING: Prefer using '"%s...", __func__' to using > the function's name, in a string > > It is prefered to use '%s & __func__' instead

[RESEND PATCH 13/13] vfs: Delete struct fdtable

Completing the conversion of the file descriptor allocation code to use the IDR. This patch includes below changes: - Move max_fds from struct fdtable to files_struct. - Added fill_max_fds() routine to calculate the new value of max_fds to matches the old behaviour of alloc_fdtable() code

[RESEND PATCH 13/13] vfs: Delete struct fdtable

Completing the conversion of the file descriptor allocation code to use the IDR. This patch includes below changes: - Move max_fds from struct fdtable to files_struct. - Added fill_max_fds() routine to calculate the new value of max_fds to matches the old behaviour of alloc_fdtable() code

[RESEND PATCH 12/13] vfs: Convert select to use idr_get_tag_batch()

Convert select to use idr_get_tag_batch(). Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox --- fs/select.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/fs/select.c b/fs/select.c index

[RESEND PATCH 12/13] vfs: Convert select to use idr_get_tag_batch()

Convert select to use idr_get_tag_batch(). Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox --- fs/select.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/fs/select.c b/fs/select.c index e211227..5d20a14 100644 --- a/fs/select.c +++ b/fs/select.c

[RESEND PATCH 11/13] vfs: Add init_task.h include

Removes a sparse warning about init_files() not being declared. Signed-off-by: Matthew Wilcox --- fs/file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/file.c b/fs/file.c index 56c5731..23f198b 100644 --- a/fs/file.c +++ b/fs/file.c @@ -19,6 +19,7 @@ #include

[RESEND PATCH 11/13] vfs: Add init_task.h include

Removes a sparse warning about init_files() not being declared. Signed-off-by: Matthew Wilcox --- fs/file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/file.c b/fs/file.c index 56c5731..23f198b 100644 --- a/fs/file.c +++ b/fs/file.c @@ -19,6 +19,7 @@ #include #include #include

Re: [PATCH 2/2] mmc: sdhci-of-at91: set clocks and presets after resume from deepest PM

On Tue, Jul 11, 2017 at 02:42:44PM +0200, Ulf Hansson wrote: > On 16 June 2017 at 09:29, Quentin Schulz > wrote: > > This adds deepest (Backup+Self-Refresh) PM support to the ATMEL SAMA5D2 > > SoC's SDHCI controller. > > > > When resuming from deepest state, it

Re: [PATCH 2/2] mmc: sdhci-of-at91: set clocks and presets after resume from deepest PM

On Tue, Jul 11, 2017 at 02:42:44PM +0200, Ulf Hansson wrote: > On 16 June 2017 at 09:29, Quentin Schulz > wrote: > > This adds deepest (Backup+Self-Refresh) PM support to the ATMEL SAMA5D2 > > SoC's SDHCI controller. > > > > When resuming from deepest state, it is required to restore preset > >

Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

On Tue, Jul 11, 2017 at 02:13:31PM +0200, Sebastian Reichel wrote: > How is having a subnode without a compatible property different? You don't *need* to have the subnode, I was only mentioning that if for some reason it was super useful for organizing the properties. signature.asc

Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

On Tue, Jul 11, 2017 at 02:13:31PM +0200, Sebastian Reichel wrote: > How is having a subnode without a compatible property different? You don't *need* to have the subnode, I was only mentioning that if for some reason it was super useful for organizing the properties. signature.asc

[RESEND PATCH 10/13] vfs: Replace close_on_exec bitmap with an IDR tag

Replace close_on_exec with idr_(get,set,clear)_tag(). Through this patch, added new IDR tag FD_TAG_CLOEXEC which is passing to idr_(get,set,clear)_tag() to achieve close_on_exec functionality. Also removed get_close_on_exec() and using close_on_exec() instead of that. Signed-off-by: Sandhya

[RESEND PATCH 10/13] vfs: Replace close_on_exec bitmap with an IDR tag

Replace close_on_exec with idr_(get,set,clear)_tag(). Through this patch, added new IDR tag FD_TAG_CLOEXEC which is passing to idr_(get,set,clear)_tag() to achieve close_on_exec functionality. Also removed get_close_on_exec() and using close_on_exec() instead of that. Signed-off-by: Sandhya

Re: [RFC PATCH 3/4] pmbus: Allow dynamic fan coefficient values

On 07/10/2017 06:56 AM, Andrew Jeffery wrote: Some PMBus chips, such as the MAX31785, use different coefficients for FAN_COMMAND_[1-4] depending on whether the fan is in PWM (percent duty) or RPM mode. Add a callback to allow the driver to provide the applicable coefficients to avoid imposing on

Re: [RFC PATCH 3/4] pmbus: Allow dynamic fan coefficient values

On 07/10/2017 06:56 AM, Andrew Jeffery wrote: Some PMBus chips, such as the MAX31785, use different coefficients for FAN_COMMAND_[1-4] depending on whether the fan is in PWM (percent duty) or RPM mode. Add a callback to allow the driver to provide the applicable coefficients to avoid imposing on

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

At 07/11/2017 09:26 PM, Dou Liyang wrote: Hi, Rafael Recently, I worked for unify the interrupt delivery mode and do its setup earlier[1]. And I met a bug about ACPI[2]. When I investigated it, I got your commit c4e1acbb35e4 (ACPI / init: Run acpi_early_init() before timekeeping_init()).

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

At 07/11/2017 09:26 PM, Dou Liyang wrote: Hi, Rafael Recently, I worked for unify the interrupt delivery mode and do its setup earlier[1]. And I met a bug about ACPI[2]. When I investigated it, I got your commit c4e1acbb35e4 (ACPI / init: Run acpi_early_init() before timekeeping_init()).

[RESEND PATCH 09/13] vfs: Rewrite close_files()

Use the IDR iteration functionality instead of the open_fds bitmap to call filp_close() for each open file. Also make close_files() return void, because it no longer uses the fdtable. Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox

[RESEND PATCH 09/13] vfs: Rewrite close_files()

Use the IDR iteration functionality instead of the open_fds bitmap to call filp_close() for each open file. Also make close_files() return void, because it no longer uses the fdtable. Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox --- fs/file.c | 37

[RESEND PATCH 08/13] vfs: Use idr_tag_get() in fd_is_open().

Use idr_tag_get() in fd_is_open() to know whether a given fd is allocated. Also move fd_is_open() to file.c and make it static as it is only called from one place. Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox --- fs/file.c

[RESEND PATCH 08/13] vfs: Use idr_tag_get() in fd_is_open().

Use idr_tag_get() in fd_is_open() to know whether a given fd is allocated. Also move fd_is_open() to file.c and make it static as it is only called from one place. Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox --- fs/file.c | 7 ++- include/linux/fdtable.h | 5

Re: [GIT pull] irq updates for 4.13

On Tue, 11 Jul 2017, Sebastian Reichel wrote: > On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote: > > On Tue, 11 Jul 2017, Thomas Gleixner wrote: > > > On Tue, 11 Jul 2017, Sebastian Reichel wrote: > > > So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to > > >

Re: [GIT pull] irq updates for 4.13

On Tue, 11 Jul 2017, Sebastian Reichel wrote: > On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote: > > On Tue, 11 Jul 2017, Thomas Gleixner wrote: > > > On Tue, 11 Jul 2017, Sebastian Reichel wrote: > > > So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to > > >

A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

Hi, Rafael Recently, I worked for unify the interrupt delivery mode and do its setup earlier[1]. And I met a bug about ACPI[2]. When I investigated it, I got your commit c4e1acbb35e4 (ACPI / init: Run acpi_early_init() before timekeeping_init()). And I reproduced the problem you said.

A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

Hi, Rafael Recently, I worked for unify the interrupt delivery mode and do its setup earlier[1]. And I met a bug about ACPI[2]. When I investigated it, I got your commit c4e1acbb35e4 (ACPI / init: Run acpi_early_init() before timekeeping_init()). And I reproduced the problem you said.

[RESEND PATCH 07/13] vfs: Remove full_fds_bits from fd allocation code path.

The IDR has removed the need to have full_fds_bits hence removing it. Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox --- fs/file.c | 18 +- include/linux/fdtable.h | 2 -- 2 files changed, 1

[RESEND PATCH 07/13] vfs: Remove full_fds_bits from fd allocation code path.

The IDR has removed the need to have full_fds_bits hence removing it. Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox --- fs/file.c | 18 +- include/linux/fdtable.h | 2 -- 2 files changed, 1 insertion(+), 19 deletions(-) diff --git a/fs/file.c

Re: [PATCH] [media] staging/imx: remove confusing IS_ERR_OR_NULL usage

On Thu, Jun 29, 2017 at 11:13 AM, Philipp Zabel wrote: >> @@ -134,23 +134,26 @@ static void csi_idmac_put_ipu_resources(struct >> csi_priv *priv) >> static int csi_idmac_get_ipu_resources(struct csi_priv *priv) >> { >> int ch_num, ret; >> + struct ipu_smfc

Re: [PATCH] [media] staging/imx: remove confusing IS_ERR_OR_NULL usage

On Thu, Jun 29, 2017 at 11:13 AM, Philipp Zabel wrote: >> @@ -134,23 +134,26 @@ static void csi_idmac_put_ipu_resources(struct >> csi_priv *priv) >> static int csi_idmac_get_ipu_resources(struct csi_priv *priv) >> { >> int ch_num, ret; >> + struct ipu_smfc *smfc, *idmac_ch; > > This

[RESEND PATCH 06/13] vfs: Remove next_fd from fd alloc code path.

The IDR is used in file descriptor allocation code to allocate new file descriptor so, no need of next_fd to track next file descriptor. Hence removing it from file descriptor allocation code path. Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox

[RESEND PATCH 06/13] vfs: Remove next_fd from fd alloc code path.

The IDR is used in file descriptor allocation code to allocate new file descriptor so, no need of next_fd to track next file descriptor. Hence removing it from file descriptor allocation code path. Signed-off-by: Sandhya Bankar Signed-off-by: Matthew Wilcox --- fs/file.c | 6

Re: [PATCH 8/9] RISC-V: User-facing API

On Mon, Jul 10, 2017 at 01:00:29PM -0700, Palmer Dabbelt wrote: > On Thu, 06 Jul 2017 08:45:13 PDT (-0700), will.dea...@arm.com wrote: > > On Thu, Jul 06, 2017 at 08:34:27AM -0700, Christoph Hellwig wrote: > >> On Thu, Jul 06, 2017 at 09:55:03AM +0100, Will Deacon wrote: > >> > Agreed on the

Re: [PATCH 8/9] RISC-V: User-facing API

On Mon, Jul 10, 2017 at 01:00:29PM -0700, Palmer Dabbelt wrote: > On Thu, 06 Jul 2017 08:45:13 PDT (-0700), will.dea...@arm.com wrote: > > On Thu, Jul 06, 2017 at 08:34:27AM -0700, Christoph Hellwig wrote: > >> On Thu, Jul 06, 2017 at 09:55:03AM +0100, Will Deacon wrote: > >> > Agreed on the

[RESEND PATCH 05/13] vfs: Replace array of file pointers with an IDR

Instead of storing all the file pointers in a single array, use an IDR. It is RCU-safe, and does not need to be reallocated when the fd array grows. It also handles allocation of new file descriptors. Signed-off-by: Sandhya Bankar [mawil...@microsoft.com: fixes]

[RESEND PATCH 05/13] vfs: Replace array of file pointers with an IDR

Instead of storing all the file pointers in a single array, use an IDR. It is RCU-safe, and does not need to be reallocated when the fd array grows. It also handles allocation of new file descriptors. Signed-off-by: Sandhya Bankar [mawil...@microsoft.com: fixes] Signed-off-by: Matthew Wilcox

[PATCH v2] [media] staging/imx: remove confusing IS_ERR_OR_NULL usage

While looking at a compiler warning, I noticed the use of IS_ERR_OR_NULL, which is generally a sign of a bad API design and should be avoided. In this driver, this is fairly easy, we can simply stop storing error pointers in persistent structures, and change the two functions that might return

[PATCH v2] [media] staging/imx: remove confusing IS_ERR_OR_NULL usage

While looking at a compiler warning, I noticed the use of IS_ERR_OR_NULL, which is generally a sign of a bad API design and should be avoided. In this driver, this is fairly easy, we can simply stop storing error pointers in persistent structures, and change the two functions that might return

Re: [PATCH 00/16] omap_hsmmc: Add ADMA support and UHS/HS200/DDR support

On 16 June 2017 at 14:45, Kishon Vijay Abraham I wrote: > This is the final part of the series originally sent as > part of [2]. > > This series adds UHS, HS200, DDR mode and ADMA support to > omap_hsmmc driver used to improve the throughput of MMC/SD in dra7 > SoCs. > > Changes

Re: [PATCH 00/16] omap_hsmmc: Add ADMA support and UHS/HS200/DDR support

On 16 June 2017 at 14:45, Kishon Vijay Abraham I wrote: > This is the final part of the series originally sent as > part of [2]. > > This series adds UHS, HS200, DDR mode and ADMA support to > omap_hsmmc driver used to improve the throughput of MMC/SD in dra7 > SoCs. > > Changes from [2]: > *) No

Re: [PATCH v4 02/14] drm/atomic-helper: update lut props directly in ..._legacy_gamma_set

On 2017-07-11 10:02, Daniel Vetter wrote: > On Thu, Jul 06, 2017 at 02:20:36PM +0200, Peter Rosin wrote: >> Do not waste cycles looking up the property id when we have the >> actual property already. >> >> Signed-off-by: Peter Rosin > > With the names adjusted per my comments on

Re: [PATCH v4 02/14] drm/atomic-helper: update lut props directly in ..._legacy_gamma_set

On 2017-07-11 10:02, Daniel Vetter wrote: > On Thu, Jul 06, 2017 at 02:20:36PM +0200, Peter Rosin wrote: >> Do not waste cycles looking up the property id when we have the >> actual property already. >> >> Signed-off-by: Peter Rosin > > With the names adjusted per my comments on patch 1 this

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On 7/11/2017 5:03 PM, Ingo Molnar wrote: * Kyle Huey wrote: On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan wrote: On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: Should any of those be moved into the "should be

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On 7/11/2017 5:03 PM, Ingo Molnar wrote: * Kyle Huey wrote: On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan wrote: On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: Should any of those be moved into the "should be dropped" pile? Why not be conservative and clear every sample

[RESEND PATCH 04/13] idr, radix-tree: Implement copy_preload

In the file descriptor table duplication code (called at fork()), we need to duplicate an IDR. But we have to do it under a lock (so another thread doesn't open/close a fd in the middle), and there's no suitable preload operation for this today. Adding just idr_copy_preload() isn't enough as

[RESEND PATCH 04/13] idr, radix-tree: Implement copy_preload

In the file descriptor table duplication code (called at fork()), we need to duplicate an IDR. But we have to do it under a lock (so another thread doesn't open/close a fd in the middle), and there's no suitable preload operation for this today. Adding just idr_copy_preload() isn't enough as

[RESEND PATCH 03/13] idr, radix-tree: Add get_tag_batch function

To implement select() on top of the IDR, we need to be able to get the tags which represent the open files in bulk. For this user, it makes sense to get a batch of BITS_PER_LONG tags at a time, and until another user shows up that wants something different, let's enforce that instead of coping

[RESEND PATCH 03/13] idr, radix-tree: Add get_tag_batch function

To implement select() on top of the IDR, we need to be able to get the tags which represent the open files in bulk. For this user, it makes sense to get a batch of BITS_PER_LONG tags at a time, and until another user shows up that wants something different, let's enforce that instead of coping

[RESEND PATCH 02/13] idr: Add idr_for_each_entry_tagged()

Add the ability to iterate over tagged entries in the IDR with idr_get_next_tag() and idr_for_each_entry_tagged(). Signed-off-by: Matthew Wilcox --- include/linux/idr.h | 15 ++- lib/idr.c | 30

[RESEND PATCH 02/13] idr: Add idr_for_each_entry_tagged()

Add the ability to iterate over tagged entries in the IDR with idr_get_next_tag() and idr_for_each_entry_tagged(). Signed-off-by: Matthew Wilcox --- include/linux/idr.h | 15 ++- lib/idr.c | 30 +-

drivers/usb/typec/ucsi/ucsi.h:331:59: warning: 'struct device' declared inside parameter list

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 548aa0e3c516d906dae5edb1fc9a1ad2e490120a commit: c1b0bc2dabfa884dea49c02adaf3cd6b52b33d2f usb: typec: Add support for UCSI interface date: 2 weeks ago config: x86_64-randconfig-in0-07111558 (attached as

drivers/usb/typec/ucsi/ucsi.h:331:59: warning: 'struct device' declared inside parameter list

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 548aa0e3c516d906dae5edb1fc9a1ad2e490120a commit: c1b0bc2dabfa884dea49c02adaf3cd6b52b33d2f usb: typec: Add support for UCSI interface date: 2 weeks ago config: x86_64-randconfig-in0-07111558 (attached as

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote: > From: Aubrey Li > > The system will enter a fast idle loop if the predicted idle period > is shorter than the threshold. > --- > kernel/sched/idle.c | 9 - > 1 file changed, 8 insertions(+), 1

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote: > From: Aubrey Li > > The system will enter a fast idle loop if the predicted idle period > is shorter than the threshold. > --- > kernel/sched/idle.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git

<    6   7   8   9   10   11   12   13   14   15   >