Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote: > Hello, Atish, Peter, all. > > I have a question about if a task's nr_cpus_allowed is 1. > In that scenario we do not call select_task_rq. Therefore > even thought a task "p" is placed on idle CPU that CPU > will not be marked as claimed

qemu x86 CPUID leafs override

Hi guys, I'm using the hack below to do some quick kernel testing by setting arbitrary feature bits and then make it execute the code for that feature. For example, boot with: -cpu EPYC,cpuid-leaf=0x8007,ebx=0xf to set some RAS feature bits and test newer RAS code. Would something like

Re: [PATCH 3.16 100/133] bcache: correct cache_dirty_target in __update_writeback_rate()

On Tue, 2017-11-21 at 19:41 -0800, Joe Perches wrote: > On Wed, 2017-11-22 at 01:58 +, Ben Hutchings wrote: > > 3.16.51-rc1 review patch. If anyone has any objections, please let me know. > > [] > > --- a/drivers/md/bcache/writeback.h > > +++ b/drivers/md/bcache/writeback.h > > @@ -14,6

Re: [PATCH 3.16 100/133] bcache: correct cache_dirty_target in __update_writeback_rate()

On Tue, 2017-11-21 at 19:41 -0800, Joe Perches wrote: > On Wed, 2017-11-22 at 01:58 +, Ben Hutchings wrote: > > 3.16.51-rc1 review patch. If anyone has any objections, please let me know. > > [] > > --- a/drivers/md/bcache/writeback.h > > +++ b/drivers/md/bcache/writeback.h > > @@ -14,6

Re: [f2fs-dev] [PATCH RESEND v3] f2fs: fix concurrent problem for updating free bitmap

On 2017/11/22 16:07, LiFan wrote: > alloc_nid_failed and scan_nat_page can be called at the same time, > and we haven't protected add_free_nid and update_free_nid_bitmap > with the same nid_list_lock. That could lead to > > Thread A Thread B > - __build_free_nids > -

Re: [f2fs-dev] [PATCH RESEND v3] f2fs: fix concurrent problem for updating free bitmap

On 2017/11/22 16:07, LiFan wrote: > alloc_nid_failed and scan_nat_page can be called at the same time, > and we haven't protected add_free_nid and update_free_nid_bitmap > with the same nid_list_lock. That could lead to > > Thread A Thread B > - __build_free_nids > -

Re: [PATCH v3 RESEND] f2fs: add bug_on when f2fs_gc even fails to get one victim

On 2017/11/22 11:50, Yunlong Song wrote: > ping again... > > On 2017/11/17 9:09, Yunlong Song wrote: >> This can help to find potential bugs on some corner case. Could you test this patch with fstest suit? if there are any testcases can trigger this bug_on, it will be better to fix them all

Re: [PATCH v3 RESEND] f2fs: add bug_on when f2fs_gc even fails to get one victim

On 2017/11/22 11:50, Yunlong Song wrote: > ping again... > > On 2017/11/17 9:09, Yunlong Song wrote: >> This can help to find potential bugs on some corner case. Could you test this patch with fstest suit? if there are any testcases can trigger this bug_on, it will be better to fix them all

Re: [PATCH 3.16 105/133] mm/vmstat.c: fix wrong comment

On Wed, 2017-11-22 at 08:41 +0100, Vlastimil Babka wrote: > On 11/22/2017 02:58 AM, Ben Hutchings wrote: > > 3.16.51-rc1 review patch. If anyone has any objections, please let me know. > > I don't really care much in the end, but is "fix wrong comment" really a > stable patch material these

Re: [PATCH 3.16 105/133] mm/vmstat.c: fix wrong comment

On Wed, 2017-11-22 at 08:41 +0100, Vlastimil Babka wrote: > On 11/22/2017 02:58 AM, Ben Hutchings wrote: > > 3.16.51-rc1 review patch. If anyone has any objections, please let me know. > > I don't really care much in the end, but is "fix wrong comment" really a > stable patch material these

Re: [PATCH] PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent

4 platform using the pci-epf-test.c driver and the pcitest userspace program. My tests were done with both linux-next (next-20171123) and the next branch of the pci tree. commit 723288836628bc1c08 ("of: restrict DMA configuration") has already been merged in linux-next but not in pci-ne

Re: [PATCH] PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent

erspace program. My tests were done with both linux-next (next-20171123) and the next branch of the pci tree. commit 723288836628bc1c08 ("of: restrict DMA configuration") has already been merged in linux-next but not in pci-next yet. Hence without Kishon's patch dma_alloc_coherent()

Re: [PATCH] Add slowpath enter/exit trace events

On 11/23/2017 01:47 PM, Michal Hocko wrote: > > This might be true but the other POV is that the trace point with the > additional information is just too disruptive to the rest of the code > and it exposes too many implementation details. >From who do you want to hide details? Is this a security

[PATCH 5/5] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.

All recent emtrion modules based on i.mx6 make use of the DA0963. Therefore enable it with the following defaults: - CONFIG_MFD_DA9063=y - CONFIG_REGULATOR_DA9063=y - CONFIG_DA9063_WATCHDOG=m - CONFIG_RTC_DRV_DA9063=m MFD and REGULATOR are built-in to have it at

Re: [PATCH] Add slowpath enter/exit trace events

On 11/23/2017 01:47 PM, Michal Hocko wrote: > > This might be true but the other POV is that the trace point with the > additional information is just too disruptive to the rest of the code > and it exposes too many implementation details. >From who do you want to hide details? Is this a security

[PATCH 5/5] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.

All recent emtrion modules based on i.mx6 make use of the DA0963. Therefore enable it with the following defaults: - CONFIG_MFD_DA9063=y - CONFIG_REGULATOR_DA9063=y - CONFIG_DA9063_WATCHDOG=m - CONFIG_RTC_DRV_DA9063=m MFD and REGULATOR are built-in to have it at

[PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

emtrion is a system integrator and manufacturer of embedded systems. Website: https://www.emtrion.de Signed-off-by: Jan Tuerk --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

emtrion is a system integrator and manufacturer of embedded systems. Website: https://www.emtrion.de Signed-off-by: Jan Tuerk --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt

[PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6

The Emerging Display Technology ETM0700G0BDH6 is exactly the same display as the ETM0700G0DH6, exept the pixelclock polarity. Therefore re-use the ETM0700G0DH6 modes. It is used by default on emtrion Avari based development kits. Signed-off-by: Jan Tuerk ---

[PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6

The Emerging Display Technology ETM0700G0BDH6 is exactly the same display as the ETM0700G0DH6, exept the pixelclock polarity. Therefore re-use the ETM0700G0DH6 modes. It is used by default on emtrion Avari based development kits. Signed-off-by: Jan Tuerk ---

[PATCH 0/5] Add basic support for emtrion emCON-MX6 modules

The following patch-series adds support for emtrion's emCON-MX6 modules with all their dependencies. The focus is based on the emtion standard developer-kit configuration. It includes a new vendor-prefix, an new simple-panel type, a small modification of the imx6dl.dtsi, as well as modifications

[PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

Adding the label cpu0 allows the adjustment of cpu-parameters by reference in overlaying dtsi files in the same way as it is possible for imx6q devices. Signed-off-by: Jan Tuerk --- arch/arm/boot/dts/imx6dl.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

This patch adds support for the emtrion GmbH emCON-MX6 modules. They are available with imx.6 Solo, Dual-Lite, Dual and Quad equipped with Memory from 512MB to 2GB (configured by U-Boot). Our default developer-Kit ships with the Avari baseboard and the EDT ETM0700G0BDH6 Display

[PATCH 0/5] Add basic support for emtrion emCON-MX6 modules

The following patch-series adds support for emtrion's emCON-MX6 modules with all their dependencies. The focus is based on the emtion standard developer-kit configuration. It includes a new vendor-prefix, an new simple-panel type, a small modification of the imx6dl.dtsi, as well as modifications

[PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

Adding the label cpu0 allows the adjustment of cpu-parameters by reference in overlaying dtsi files in the same way as it is possible for imx6q devices. Signed-off-by: Jan Tuerk --- arch/arm/boot/dts/imx6dl.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

This patch adds support for the emtrion GmbH emCON-MX6 modules. They are available with imx.6 Solo, Dual-Lite, Dual and Quad equipped with Memory from 512MB to 2GB (configured by U-Boot). Our default developer-Kit ships with the Avari baseboard and the EDT ETM0700G0BDH6 Display

Re: [PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

Am 23.11.2017 um 13:55 schrieb Jan Tuerk: > Adding the label cpu0 allows the adjustment of cpu-parameters > by reference in overlaying dtsi files in the same way as it > is possible for imx6q devices. > > Signed-off-by: Jan Tuerk > --- > arch/arm/boot/dts/imx6dl.dtsi | 2

Re: [PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

Am 23.11.2017 um 13:55 schrieb Jan Tuerk: > Adding the label cpu0 allows the adjustment of cpu-parameters > by reference in overlaying dtsi files in the same way as it > is possible for imx6q devices. > > Signed-off-by: Jan Tuerk > --- > arch/arm/boot/dts/imx6dl.dtsi | 2 +- > 1 file changed, 1

Re: [PATCH] Add slowpath enter/exit trace events

On 2017/11/23 19:43, peter.enderb...@sony.com wrote: > The warning of slow allocation has been removed, this is > a other way to fetch that information. But you need > to enable the trace. The exit function also returns > information about the number of retries, how long > it was stalled and

Re: [PATCH] Add slowpath enter/exit trace events

On 2017/11/23 19:43, peter.enderb...@sony.com wrote: > The warning of slow allocation has been removed, this is > a other way to fetch that information. But you need > to enable the trace. The exit function also returns > information about the number of retries, how long > it was stalled and

Re: [PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

Am 23.11.2017 um 13:55 schrieb Jan Tuerk: > emtrion is a system integrator and manufacturer of embedded systems. > > Website: https://www.emtrion.de > > Signed-off-by: Jan Tuerk > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1

Re: [PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

Am 23.11.2017 um 13:55 schrieb Jan Tuerk: > emtrion is a system integrator and manufacturer of embedded systems. > > Website: https://www.emtrion.de > > Signed-off-by: Jan Tuerk > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Reviewed-by:

Re: [PATCH v2] arm: detect buggy binutils when in thumb2 mode

On Thu, 23 Nov 2017, Jason A. Donenfeld wrote: On older versions of binutils, \sym points to an aligned address. On newer versions of binutils, \sym sometimes points to the unaligned thumb address in certain circumstances. In order to homogenize this behavior, rather than adding 1, we could

Re: [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps during boot

On Wed 2017-11-15 19:15:38, Thomas Gleixner wrote: > For demonstration purposes only. > > Add a disgusting hack to work around the fact that high resolution clock > MONOTONIC accessors are not available during early boot and return stale > time stamps accross suspend/resume when the current

Re: [PATCH v2] arm: detect buggy binutils when in thumb2 mode

On Thu, 23 Nov 2017, Jason A. Donenfeld wrote: On older versions of binutils, \sym points to an aligned address. On newer versions of binutils, \sym sometimes points to the unaligned thumb address in certain circumstances. In order to homogenize this behavior, rather than adding 1, we could

Re: [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps during boot

On Wed 2017-11-15 19:15:38, Thomas Gleixner wrote: > For demonstration purposes only. > > Add a disgusting hack to work around the fact that high resolution clock > MONOTONIC accessors are not available during early boot and return stale > time stamps accross suspend/resume when the current

Re: [PATCH 0/3] scsi: arcmsr: add driver module parameter - msi_enable, msix_enable

On Thu, Nov 23, 2017 at 09:22:03AM +0800, Ching Huang wrote: > From: Ching Huang > > Hi all, > > The following patches apply to Martin's 4.16/scsi-queue. > > Patch 1: Add module parameter msi_enable to has a chance to disable msi > interrupt if it does not work

Re: [PATCH 0/3] scsi: arcmsr: add driver module parameter - msi_enable, msix_enable

On Thu, Nov 23, 2017 at 09:22:03AM +0800, Ching Huang wrote: > From: Ching Huang > > Hi all, > > The following patches apply to Martin's 4.16/scsi-queue. > > Patch 1: Add module parameter msi_enable to has a chance to disable msi > interrupt if it does not work properly. > > Patch 2: Add

Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 13:53:45, Michal Hocko wrote: > On Thu 23-11-17 13:45:41, Michal Hocko wrote: > [...] > > What about the following? > > Dohh, a rebase artifact sneaked in. So let me try again. Sorry about > spamming :/ > --- > From 467be16ca5165613daf292a68592e3b5bc7252c5 Mon Sep 17 00:00:00 2001

Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 13:53:45, Michal Hocko wrote: > On Thu 23-11-17 13:45:41, Michal Hocko wrote: > [...] > > What about the following? > > Dohh, a rebase artifact sneaked in. So let me try again. Sorry about > spamming :/ > --- > From 467be16ca5165613daf292a68592e3b5bc7252c5 Mon Sep 17 00:00:00 2001

Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 13:45:41, Michal Hocko wrote: [...] > What about the following? Dohh, a rebase artifact sneaked in. So let me try again. Sorry about spamming :/ --- >From 467be16ca5165613daf292a68592e3b5bc7252c5 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Thu, 23 Nov 2017

Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 13:45:41, Michal Hocko wrote: [...] > What about the following? Dohh, a rebase artifact sneaked in. So let me try again. Sorry about spamming :/ --- >From 467be16ca5165613daf292a68592e3b5bc7252c5 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Thu, 23 Nov 2017 12:28:35 +0100

Re: [PATCH v1] mm: relax deferred struct page requirements

Pavel Tatashin writes: > There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT, > as all the page initialization code is in common code. > > Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code > does not really use hotplug memory

Re: [PATCH v1] mm: relax deferred struct page requirements

Pavel Tatashin writes: > There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT, > as all the page initialization code is in common code. > > Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code > does not really use hotplug memory functionality. So, we can remove

Re: [PATCH] Add slowpath enter/exit trace events

On Thu 23-11-17 13:35:15, peter enderborg wrote: > Monitoring both enter/exit for all allocations and track down the one > that are slow will be a very big load on mobile devices or embedded > device consuming a lot of battery and cpu. With this we can do useful > monitoring on devices on our

Re: [PATCH] Add slowpath enter/exit trace events

On Thu 23-11-17 13:35:15, peter enderborg wrote: > Monitoring both enter/exit for all allocations and track down the one > that are slow will be a very big load on mobile devices or embedded > device consuming a lot of battery and cpu. With this we can do useful > monitoring on devices on our

Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume

On Thu, Nov 23, 2017 at 08:24:05PM +0800, Chris Chiu wrote: > Thanks for your confirmation. I've pushed this back to ASUS. They told me > there's a new official BIOS released, of course they don't know > whether if it helps > or not. I then upgraded it and the problem is gone. So it's truly a >

Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume

On Thu, Nov 23, 2017 at 08:24:05PM +0800, Chris Chiu wrote: > Thanks for your confirmation. I've pushed this back to ASUS. They told me > there's a new official BIOS released, of course they don't know > whether if it helps > or not. I then upgraded it and the problem is gone. So it's truly a >

Re: [RFC patch 5/7] crash: Add VMCOREINFO_FIELD_AND_OFFSET()

On Wed 2017-11-15 19:15:36, Thomas Gleixner wrote: > Changing the time stamp storage in the printk ringbuffer entries would > break existing tools which rely on the availability of the 'ts_nsec' field > in vmcore info. > > Provide a new macro which allows to store the offset of a member of struct

Re: [RFC patch 5/7] crash: Add VMCOREINFO_FIELD_AND_OFFSET()

On Wed 2017-11-15 19:15:36, Thomas Gleixner wrote: > Changing the time stamp storage in the printk ringbuffer entries would > break existing tools which rely on the availability of the 'ts_nsec' field > in vmcore info. > > Provide a new macro which allows to store the offset of a member of struct

Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 13:26:16, Jan Kara wrote: > On Thu 23-11-17 12:52:47, Michal Hocko wrote: [...] > > @@ -489,6 +489,7 @@ struct super_block *sget_userns(struct file_system_type > > *type, > > continue; > > if (user_ns != old->s_user_ns) { > >

Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 13:26:16, Jan Kara wrote: > On Thu 23-11-17 12:52:47, Michal Hocko wrote: [...] > > @@ -489,6 +489,7 @@ struct super_block *sget_userns(struct file_system_type > > *type, > > continue; > > if (user_ns != old->s_user_ns) { > >

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of hyp emulated mmio instructions

On Thu, Nov 23, 2017 at 12:11:34PM +, Alex Bennée wrote: > There is a fast-path of MMIO emulation inside hyp mode. The handling > of single-step is broadly the same as kvm_arm_handle_step_debug() > except we just setup ESR/HSR so handle_exit() does the correct thing > as we exit. > > For the

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of hyp emulated mmio instructions

On Thu, Nov 23, 2017 at 12:11:34PM +, Alex Bennée wrote: > There is a fast-path of MMIO emulation inside hyp mode. The handling > of single-step is broadly the same as kvm_arm_handle_step_debug() > except we just setup ESR/HSR so handle_exit() does the correct thing > as we exit. > > For the

Re: [PATCH] Add slowpath enter/exit trace events

Monitoring both enter/exit for all allocations and track down the one that are slow will be a very big load on mobile devices or embedded device consuming a lot of battery and cpu. With this we can do useful monitoring on devices on our field tests with real usage. On 11/23/2017 01:25 PM,

Re: [PATCH] Add slowpath enter/exit trace events

Monitoring both enter/exit for all allocations and track down the one that are slow will be a very big load on mobile devices or embedded device consuming a lot of battery and cpu. With this we can do useful monitoring on devices on our field tests with real usage. On 11/23/2017 01:25 PM,

Re: [PATCH v1 1/2] kvm: arm64: handle single-step during SError exceptions

On Thu, Nov 23, 2017 at 12:11:33PM +, Alex Bennée wrote: > When an SError arrives during single-step it may be delivered before > the step completes. nit: this is not entirely accurate wording comparing with the ARM ARM, which says that the step would be completed, but you'll now have both a

Re: [PATCH v1 1/2] kvm: arm64: handle single-step during SError exceptions

On Thu, Nov 23, 2017 at 12:11:33PM +, Alex Bennée wrote: > When an SError arrives during single-step it may be delivered before > the step completes. nit: this is not entirely accurate wording comparing with the ARM ARM, which says that the step would be completed, but you'll now have both a

[PATCH v2] kmemleak: add scheduling point to kmemleak_scan

kmemleak_scan will scan struct page for each node and it can be really large and resulting in a soft lockup. We have seen a soft lockup when do scan while compile kernel: [ 220.561051] watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287] [...] [ 220.753837] Call Trace: [

[PATCH v2] kmemleak: add scheduling point to kmemleak_scan

kmemleak_scan will scan struct page for each node and it can be really large and resulting in a soft lockup. We have seen a soft lockup when do scan while compile kernel: [ 220.561051] watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287] [...] [ 220.753837] Call Trace: [

Re: [PATCH 3/3] trace-cmd: Making stat to report when the stack tracer is ON

On Wed, 2017-11-22 at 14:50 -0500, Steven Rostedt wrote: > > I applied the first two. Small comments about this one. Thanks, Steven. > > > > > > +/* Stack tracer public functions */ > > +int is_stack_tracer_enabled(void); > > As this is now in the trace-cmd.h header, please rename it to: >

Re: [PATCH 3/3] trace-cmd: Making stat to report when the stack tracer is ON

On Wed, 2017-11-22 at 14:50 -0500, Steven Rostedt wrote: > > I applied the first two. Small comments about this one. Thanks, Steven. > > > > > > +/* Stack tracer public functions */ > > +int is_stack_tracer_enabled(void); > > As this is now in the trace-cmd.h header, please rename it to: >

Re: [RFC v8 3/7] platform/x86: intel_pmc_ipc: Use regmap calls for GCR updates

On Sun, Oct 29, 2017 at 02:49:56AM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > This patch adds support for regmap based implementation for GCR > read/write/update APIs. > > Signed-off-by: Kuppuswamy

Re: [RFC v8 3/7] platform/x86: intel_pmc_ipc: Use regmap calls for GCR updates

On Sun, Oct 29, 2017 at 02:49:56AM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > This patch adds support for regmap based implementation for GCR > read/write/update APIs. > > Signed-off-by: Kuppuswamy Sathyanarayanan > > --- >

Re: [PATCH 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S, U}20_4

On 23.11.2017 08:40, Takashi Sakamoto wrote: > On Nov 23 2017 08:44, Maciej S. Szmigiero wrote: >> On 23.11.2017 00:27, Takashi Sakamoto wrote: >>> On Nov 23 2017 04:17, Maciej S. Szmigiero wrote: >> (..) --- a/include/uapi/sound/asound.h +++ b/include/uapi/sound/asound.h @@ -236,7

Re: [PATCH 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S, U}20_4

On 23.11.2017 08:40, Takashi Sakamoto wrote: > On Nov 23 2017 08:44, Maciej S. Szmigiero wrote: >> On 23.11.2017 00:27, Takashi Sakamoto wrote: >>> On Nov 23 2017 04:17, Maciej S. Szmigiero wrote: >> (..) --- a/include/uapi/sound/asound.h +++ b/include/uapi/sound/asound.h @@ -236,7

Re: [PATCH 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S,U}20_4

On 23.11.2017 09:08, Takashi Iwai wrote: > On Wed, 22 Nov 2017 20:17:34 +0100, > Maciej S. Szmigiero wrote: >> >> This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep >> 20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not >> allow 3-byte accesses (including

Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 12:52:47, Michal Hocko wrote: > From: Michal Hocko > > Syzbot has reported NULL ptr dereference during mntput because of > sb shrinker being NULL > CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82 > Hardware name: Google Google Compute

Re: [PATCH 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S,U}20_4

On 23.11.2017 09:08, Takashi Iwai wrote: > On Wed, 22 Nov 2017 20:17:34 +0100, > Maciej S. Szmigiero wrote: >> >> This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep >> 20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not >> allow 3-byte accesses (including

Re: [PATCH] fs: handle shrinker registration failure in sget_userns

On Thu 23-11-17 12:52:47, Michal Hocko wrote: > From: Michal Hocko > > Syzbot has reported NULL ptr dereference during mntput because of > sb shrinker being NULL > CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82 > Hardware name: Google Google Compute Engine/Google Compute

Re: [PATCH] Add slowpath enter/exit trace events

On Thu 23-11-17 11:43:36, peter.enderb...@sony.com wrote: > From: Peter Enderborg > > The warning of slow allocation has been removed, this is > a other way to fetch that information. But you need > to enable the trace. The exit function also returns > information about

Re: [PATCH] Add slowpath enter/exit trace events

On Thu 23-11-17 11:43:36, peter.enderb...@sony.com wrote: > From: Peter Enderborg > > The warning of slow allocation has been removed, this is > a other way to fetch that information. But you need > to enable the trace. The exit function also returns > information about the number of retries,

Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume

On Tue, Nov 21, 2017 at 8:04 PM, Mika Westerberg wrote: > On Tue, Nov 21, 2017 at 07:54:26PM +0800, Chris Chiu wrote: >> Yup, I checked the value of the corresponded pin. It shows following before >> suspend >> pin 18 (GPIO_18) GPIO 0x40800102 0x00024075 >> >>

Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume

On Tue, Nov 21, 2017 at 8:04 PM, Mika Westerberg wrote: > On Tue, Nov 21, 2017 at 07:54:26PM +0800, Chris Chiu wrote: >> Yup, I checked the value of the corresponded pin. It shows following before >> suspend >> pin 18 (GPIO_18) GPIO 0x40800102 0x00024075 >> >> Then after resume >> pin 18

Re: [PATCH 1/4] staging: lustre: fixed signedness of some socklnd params

On Wed, Nov 22, 2017 at 08:38:28PM +0100, Stefano Manni wrote: > diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c > b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c > index 5663a4c..2ad89ca 100644 > ---

Re: [PATCH 1/4] staging: lustre: fixed signedness of some socklnd params

On Wed, Nov 22, 2017 at 08:38:28PM +0100, Stefano Manni wrote: > diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c > b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c > index 5663a4c..2ad89ca 100644 > ---

[PATCH v2] f2fs: obsolete free nid list approach

Previously, we use free nid list to manage free nid entry, so during nid allocation, we can just pick up one entry from list header, which has quite low overhead. But sadly, during initialization of free nid list, we should do lookup combining with lots of different inner caches, including NAT

[PATCH v2] f2fs: obsolete free nid list approach

Previously, we use free nid list to manage free nid entry, so during nid allocation, we can just pick up one entry from list header, which has quite low overhead. But sadly, during initialization of free nid list, we should do lookup combining with lots of different inner caches, including NAT

[PATCH v1 1/2] kvm: arm64: handle single-step during SError exceptions

When an SError arrives during single-step it may be delivered before the step completes. In that case the DBG_SPSR_SS bit will have flipped as the instruction executed. After handling the abort in handle_exit() we test to see if the bit is clear and we were single-stepping before deciding if we

[PATCH v1 1/2] kvm: arm64: handle single-step during SError exceptions

When an SError arrives during single-step it may be delivered before the step completes. In that case the DBG_SPSR_SS bit will have flipped as the instruction executed. After handling the abort in handle_exit() we test to see if the bit is clear and we were single-stepping before deciding if we

Re: [PATCH V2 24/29] backlight: deprecate pci_get_bus_and_slot()

On 22/11/17 22:49, Sinan Kaya wrote: pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of

Re: [PATCH V2 24/29] backlight: deprecate pci_get_bus_and_slot()

On 22/11/17 22:49, Sinan Kaya wrote: pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of

[PATCH v1 2/2] kvm: arm64: handle single-step of hyp emulated mmio instructions

There is a fast-path of MMIO emulation inside hyp mode. The handling of single-step is broadly the same as kvm_arm_handle_step_debug() except we just setup ESR/HSR so handle_exit() does the correct thing as we exit. For the case of an emulated illegal access causing an SError we will exit via the

[PATCH v1 2/2] kvm: arm64: handle single-step of hyp emulated mmio instructions

There is a fast-path of MMIO emulation inside hyp mode. The handling of single-step is broadly the same as kvm_arm_handle_step_debug() except we just setup ESR/HSR so handle_exit() does the correct thing as we exit. For the case of an emulated illegal access causing an SError we will exit via the

[PATCH] xfs: handle register_shrinker error

From: Michal Hocko xfs_alloc_buftarg doesn't handle register_shrinker error path. While it is unlikely to trigger it is not impossible especially with large NUMAs. Let's handle the failure to make the code more robust. Signed-off-by: Michal Hocko --- Hi, this

[PATCH] xfs: handle register_shrinker error

From: Michal Hocko xfs_alloc_buftarg doesn't handle register_shrinker error path. While it is unlikely to trigger it is not impossible especially with large NUMAs. Let's handle the failure to make the code more robust. Signed-off-by: Michal Hocko --- Hi, this is not tested but it looks quite

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

Christophe LEROY writes: > Le 22/11/2017 à 12:48, Michael Ellerman a écrit : >> Christophe LEROY writes: >>> Le 22/11/2017 à 00:07, Balbir Singh a écrit : On Wed, Nov 22, 2017 at 1:28 AM, Christophe Leroy

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

Christophe LEROY writes: > Le 22/11/2017 à 12:48, Michael Ellerman a écrit : >> Christophe LEROY writes: >>> Le 22/11/2017 à 00:07, Balbir Singh a écrit : On Wed, Nov 22, 2017 at 1:28 AM, Christophe Leroy wrote: > On powerpc32, patch_instruction() is called by

Re: [PATCH v2 09/18] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

On Tue, Nov 21, 2017 at 08:44:04PM -0800, Andy Lutomirski wrote: > I want SYSENTER_stack to have reliable overflow detection, which > means that it needs to be at the bottom of a page, not the top. Passive-impersonal tone pls. > Move it to the beginning of struct tss_struct and page-align it. >

Re: [PATCH v2 09/18] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

On Tue, Nov 21, 2017 at 08:44:04PM -0800, Andy Lutomirski wrote: > I want SYSENTER_stack to have reliable overflow detection, which > means that it needs to be at the bottom of a page, not the top. Passive-impersonal tone pls. > Move it to the beginning of struct tss_struct and page-align it. >

Re: [RFC PATCH v2] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Wed, 2017-11-22 at 19:58 +0100, Luis R. Rodriguez wrote: > I've frankly have grown tired of pushing firmware signing just for the sake of > the fact that I needed it for cfg80211, but now that its out of the way and > we open coded it, its no longer a requirement on my part. As the keys

Re: [RFC PATCH v2] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Wed, 2017-11-22 at 19:58 +0100, Luis R. Rodriguez wrote: > I've frankly have grown tired of pushing firmware signing just for the sake of > the fact that I needed it for cfg80211, but now that its out of the way and > we open coded it, its no longer a requirement on my part. As the keys

[PATCH] fs: handle shrinker registration failure in sget_userns

From: Michal Hocko Syzbot has reported NULL ptr dereference during mntput because of sb shrinker being NULL CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 task:

[PATCH] fs: handle shrinker registration failure in sget_userns

From: Michal Hocko Syzbot has reported NULL ptr dereference during mntput because of sb shrinker being NULL CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 task: 8801d1dbe5c0

Re: [PATCH 0/4] staging: lustre: fixed some signedness warns from sparse

On Thu, Nov 23, 2017 at 03:59:26PM +1100, Tobin C. Harding wrote: > On Wed, Nov 22, 2017 at 08:38:27PM +0100, Stefano Manni wrote: > > Fixed some signedness warnings from sparse on lustre. > > > > Stefano Manni (4): > > staging: lustre: fixed signedness of some socklnd params > > staging:

Re: [PATCH 0/4] staging: lustre: fixed some signedness warns from sparse

On Thu, Nov 23, 2017 at 03:59:26PM +1100, Tobin C. Harding wrote: > On Wed, Nov 22, 2017 at 08:38:27PM +0100, Stefano Manni wrote: > > Fixed some signedness warnings from sparse on lustre. > > > > Stefano Manni (4): > > staging: lustre: fixed signedness of some socklnd params > > staging:

[PATCH v2] arm: detect buggy binutils when in thumb2 mode

On older versions of binutils, \sym points to an aligned address. On newer versions of binutils, \sym sometimes points to the unaligned thumb address in certain circumstances. In order to homogenize this behavior, rather than adding 1, we could simply OR in 1, so that already unaligned

[PATCH v2] arm: detect buggy binutils when in thumb2 mode

On older versions of binutils, \sym points to an aligned address. On newer versions of binutils, \sym sometimes points to the unaligned thumb address in certain circumstances. In order to homogenize this behavior, rather than adding 1, we could simply OR in 1, so that already unaligned

Re: [RFC v8 2/7] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

Hi, On Sun, Oct 29, 2017 at 02:49:55AM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Currently, we have lot of repetitive code in dependent device resource > allocation and device creation handling

Re: [RFC v8 2/7] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

Hi, On Sun, Oct 29, 2017 at 02:49:55AM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Currently, we have lot of repetitive code in dependent device resource > allocation and device creation handling code. This logic can be improved if > we use

<    5   6   7   8   9   10   11   12   13   >