[PATCH 0/6] PCI: leak fixes, removable generic PCI host, assorted stuff

This primarily enables to unbind the generic PCI host controller without leaving lots of memory leaks behind. A previous proposal patch 5 was rejected because of those issues [1]. The fixes have been validated in the Jailhouse setup, where we add and remove a virtual PCI host controller on

[PATCH 0/6] PCI: leak fixes, removable generic PCI host, assorted stuff

This primarily enables to unbind the generic PCI host controller without leaving lots of memory leaks behind. A previous proposal patch 5 was rejected because of those issues [1]. The fixes have been validated in the Jailhouse setup, where we add and remove a virtual PCI host controller on

Re: [REVIEW][PATCH 14/22] signal/riscv: Use force_sig_fault where appropriate

Palmer Dabbelt writes: > On Fri, 20 Apr 2018 07:38:03 PDT (-0700), ebied...@xmission.com wrote: >> Filling in struct siginfo before calling force_sig_info a tedious and >> error prone process, where once in a great while the wrong fields >> are filled out, and siginfo has been

Re: [REVIEW][PATCH 14/22] signal/riscv: Use force_sig_fault where appropriate

Palmer Dabbelt writes: > On Fri, 20 Apr 2018 07:38:03 PDT (-0700), ebied...@xmission.com wrote: >> Filling in struct siginfo before calling force_sig_info a tedious and >> error prone process, where once in a great while the wrong fields >> are filled out, and siginfo has been inconsistently

Re: [PATCH 7/9] Pmalloc Rare Write: modify selected pools

On 24/04/18 19:03, lazytyped wrote: On 4/24/18 4:44 PM, Matthew Wilcox wrote: On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote: On 4/24/18 1:50 PM, Matthew Wilcox wrote: struct modifiable_data { struct immutable_data *d; ... }; Then allocate a new pool, change d

Re: [PATCH 7/9] Pmalloc Rare Write: modify selected pools

On 24/04/18 19:03, lazytyped wrote: On 4/24/18 4:44 PM, Matthew Wilcox wrote: On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote: On 4/24/18 1:50 PM, Matthew Wilcox wrote: struct modifiable_data { struct immutable_data *d; ... }; Then allocate a new pool, change d

[PATCH 5/6] PCI: Add support for unbinding the generic PCI host controller

From: Jan Kiszka Particularly useful when working in virtual environments where the controller may come and go, but possibly not only there. CC: Will Deacon CC: Lorenzo Pieralisi Signed-off-by: Jan Kiszka

[PATCH 5/6] PCI: Add support for unbinding the generic PCI host controller

From: Jan Kiszka Particularly useful when working in virtual environments where the controller may come and go, but possibly not only there. CC: Will Deacon CC: Lorenzo Pieralisi Signed-off-by: Jan Kiszka --- drivers/pci/host/pci-host-common.c | 13 +

Re: [RFC 09/13] arm64: dts: allwinner: a64: Add HDMI support

Hi, Dne torek, 24. april 2018 ob 15:34:21 CEST je Jagan Teki napisal(a): > HDMI on Allwinner A64 has similar behavior like H3/H5, so > reuse the same dts node details for A64. > > Signed-off-by: Jagan Teki > --- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 >

Re: [RFC 09/13] arm64: dts: allwinner: a64: Add HDMI support

Hi, Dne torek, 24. april 2018 ob 15:34:21 CEST je Jagan Teki napisal(a): > HDMI on Allwinner A64 has similar behavior like H3/H5, so > reuse the same dts node details for A64. > > Signed-off-by: Jagan Teki > --- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 > +++

[PATCH 3/6] PCI: Introduce devm_of_pci_get_host_bridge_resources

From: Jan Kiszka of_pci_get_host_bridge_resources allocates the resource structures it fills dynamically, but none of its callers care to release them so far. Rather than requiring everyone to do this explicitly, introduce a managed version of that service. This differs

[PATCH 3/6] PCI: Introduce devm_of_pci_get_host_bridge_resources

From: Jan Kiszka of_pci_get_host_bridge_resources allocates the resource structures it fills dynamically, but none of its callers care to release them so far. Rather than requiring everyone to do this explicitly, introduce a managed version of that service. This differs API-wise only in taking a

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

Stephen Smalley wrote: > Neither fsopen() nor fscontext_fs_write() appear to perform any kind of > up-front permission checking (DAC or MAC), although some security hooks may > be ultimately called to allocate structures, parse security options, etc. > Is there a reason not

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

Stephen Smalley wrote: > Neither fsopen() nor fscontext_fs_write() appear to perform any kind of > up-front permission checking (DAC or MAC), although some security hooks may > be ultimately called to allocate structures, parse security options, etc. > Is there a reason not apply a may_mount()

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote: > > $ objdump -S clang-eflag.o > > Does this now look good? Looks fine to me. The instruction choice is still pretty odd: 1a: f6 c3 fftest $0xff,%bl 1d: 74 02 je 21

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote: > > $ objdump -S clang-eflag.o > > Does this now look good? Looks fine to me. The instruction choice is still pretty odd: 1a: f6 c3 fftest $0xff,%bl 1d: 74 02 je 21 that "test $0xff,%bl" is a

[PATCH 2/6] PCI: Fix memory leak of devm_pci_alloc_host_bridge

From: Jan Kiszka devm_pci_release_host_bridge_dev failed to release the resource list. Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface") Signed-off-by: Jan Kiszka --- drivers/pci/probe.c | 4 +++- 1 file changed, 3

[PATCH 2/6] PCI: Fix memory leak of devm_pci_alloc_host_bridge

From: Jan Kiszka devm_pci_release_host_bridge_dev failed to release the resource list. Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface") Signed-off-by: Jan Kiszka --- drivers/pci/probe.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

Re: simplify procfs code for seq_file instances

On Tue, 24 Apr 2018 16:23:04 +0200 Christoph Hellwig wrote: > On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote: > > > git://git.infradead.org/users/hch/misc.git proc_create > > > > > > I want to ask if it is time to start using poorman function overloading > >

Re: simplify procfs code for seq_file instances

On Tue, 24 Apr 2018 16:23:04 +0200 Christoph Hellwig wrote: > On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote: > > > git://git.infradead.org/users/hch/misc.git proc_create > > > > > > I want to ask if it is time to start using poorman function overloading > > with _b_c_e().

Re: [PATCH] arm64/kernel: rename module_emit_adrp_veneer->module_emit_veneer_for_adrp

On 24 April 2018 at 17:13, Kim Phillips wrote: > Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around > Cortex-A53 erratum #843419") introduced a function whose name ends with > "_veneer". > > This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore

Re: [PATCH] arm64/kernel: rename module_emit_adrp_veneer->module_emit_veneer_for_adrp

On 24 April 2018 at 17:13, Kim Phillips wrote: > Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around > Cortex-A53 erratum #843419") introduced a function whose name ends with > "_veneer". > > This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore veneers > emitted by the

[BUG] igb: reconnecting of cable not always detected

Hi all, I'm on kernel 4.16.4 and have an issue with eth0, driver is igb. When I remove the ethernet cable, this is always detected: [2.772360] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k [2.772363] igb: Copyright (c) 2007-2014 Intel Corporation. [3.023707] igb

[BUG] igb: reconnecting of cable not always detected

Hi all, I'm on kernel 4.16.4 and have an issue with eth0, driver is igb. When I remove the ethernet cable, this is always detected: [2.772360] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k [2.772363] igb: Copyright (c) 2007-2014 Intel Corporation. [3.023707] igb

Re: [PATCH] arm64: dts: stratix10: Change pad skew values for EMAC0 PHY driver

On 04/23/2018 10:01 PM, Ooi, Joyce wrote: > The HPS EMAC0 drive strength is changed to 4mA because the initial 8mA > drive strength has caused CE test to fail. This requires changes on the > pad skew for EMAC0 PHY driver. Based on several measurements done, Tx > clock does not require the extra

Re: [PATCH] arm64: dts: stratix10: Change pad skew values for EMAC0 PHY driver

On 04/23/2018 10:01 PM, Ooi, Joyce wrote: > The HPS EMAC0 drive strength is changed to 4mA because the initial 8mA > drive strength has caused CE test to fail. This requires changes on the > pad skew for EMAC0 PHY driver. Based on several measurements done, Tx > clock does not require the extra

[PATCH] arm64/kernel: rename module_emit_adrp_veneer->module_emit_veneer_for_adrp

Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419") introduced a function whose name ends with "_veneer". This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore veneers emitted by the ARM linker"), which removes symbols ending in "_veneer" from

[PATCH] arm64/kernel: rename module_emit_adrp_veneer->module_emit_veneer_for_adrp

Commit a257e02579e ("arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419") introduced a function whose name ends with "_veneer". This clashes with commit bd8b22d2888e ("Kbuild: kallsyms: ignore veneers emitted by the ARM linker"), which removes symbols ending in "_veneer" from

Re: [PATCH] drm/i915: fix intel_dvo_dev_ops::mode_valid's return type

On Tue, 24 Apr 2018, Luc Van Oostenryck wrote: > All implementations of the method intel_dvo_dev_ops::mode_valid(), as > well as the underlying struct drm_connector_helper_funcs::mode_valid() > use 'enum drm_mode_status' for the method's return type but the >

Re: [PATCH] drm/i915: fix intel_dvo_dev_ops::mode_valid's return type

On Tue, 24 Apr 2018, Luc Van Oostenryck wrote: > All implementations of the method intel_dvo_dev_ops::mode_valid(), as > well as the underlying struct drm_connector_helper_funcs::mode_valid() > use 'enum drm_mode_status' for the method's return type but the > declaration of

Re: [RESEND PATCH] ARM: dts: consistently use 'atmel' as at24 manufacturer in cyclone5

On 04/17/2018 04:45 AM, Bartosz Golaszewski wrote: > Using 'at' or 'at24' as the part of the compatible > string is now deprecated. Use a correct value: 'atmel,'. > > Signed-off-by: Bartosz Golaszewski > --- > arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 6 +++--- > 1

Re: [RESEND PATCH] ARM: dts: consistently use 'atmel' as at24 manufacturer in cyclone5

On 04/17/2018 04:45 AM, Bartosz Golaszewski wrote: > Using 'at' or 'at24' as the part of the compatible > string is now deprecated. Use a correct value: 'atmel,'. > > Signed-off-by: Bartosz Golaszewski > --- > arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 6 +++--- > 1 file changed, 3

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

Hi, On 23-04-18 23:11, Luis R. Rodriguez wrote: Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID and security for this type of request so IMA can reject it if the policy is configured for it. Hmm, interesting, actually it seems like the whole existence of

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

Hi, On 23-04-18 23:11, Luis R. Rodriguez wrote: Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID and security for this type of request so IMA can reject it if the policy is configured for it. Hmm, interesting, actually it seems like the whole existence of

Re: [PATCH] l2tp: fix l2tp_eth_dev_xmit()'s return type

On Tue, Apr 24, 2018 at 03:18:53PM +0200, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too.

Re: [PATCH] l2tp: fix l2tp_eth_dev_xmit()'s return type

On Tue, Apr 24, 2018 at 03:18:53PM +0200, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too.

Re: [PATCH] ftrace/x86: Fix arch_syscall_match_sym_name for x86_64

On Tue, Apr 24, 2018 at 10:33:58AM -0400, Steven Rostedt wrote: > On Tue, 24 Apr 2018 12:17:38 +0200 > Jiri Olsa wrote: > > > Recent commit changed the name prefix of syscalls > > for x86_64 (check the 'Fixes:' for commit number). > > > > The names switch from "sys_" prefix to

Re: [PATCH] ftrace/x86: Fix arch_syscall_match_sym_name for x86_64

On Tue, Apr 24, 2018 at 10:33:58AM -0400, Steven Rostedt wrote: > On Tue, 24 Apr 2018 12:17:38 +0200 > Jiri Olsa wrote: > > > Recent commit changed the name prefix of syscalls > > for x86_64 (check the 'Fixes:' for commit number). > > > > The names switch from "sys_" prefix to ""__x64_sys_", >

Re: [PATCH] trace: fix missing tab for hwlat_detector

On Thu, 15 Mar 2018 14:06:39 +0800 Peter Xu wrote: > It's been missing for a while but no one is touching that up. Fix it. I just noticed this patch. I added it, thanks! -- Steve > > CC: Steven Rostedt > CC: Ingo Molnar >

Re: [PATCH] trace: fix missing tab for hwlat_detector

On Thu, 15 Mar 2018 14:06:39 +0800 Peter Xu wrote: > It's been missing for a while but no one is touching that up. Fix it. I just noticed this patch. I added it, thanks! -- Steve > > CC: Steven Rostedt > CC: Ingo Molnar > Signed-off-by: Peter Xu > --- > kernel/trace/trace_entries.h | 2

[PATCH v1] mfd: intel-lpss: Correct names of RESETS register bits

According to documentation the function has 2 bits for reset while iDMA 64-bit has only one. Rename it accordingly. Note, there is no functional change since we always handle them together. Signed-off-by: Andy Shevchenko --- drivers/mfd/intel-lpss.c | 4 ++--

[PATCH v1] mfd: intel-lpss: Correct names of RESETS register bits

According to documentation the function has 2 bits for reset while iDMA 64-bit has only one. Rename it accordingly. Note, there is no functional change since we always handle them together. Signed-off-by: Andy Shevchenko --- drivers/mfd/intel-lpss.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH] perf: Documentation: Support for asciidoctor

asciidoc seems behind the recent big wave of python3 conversion, and we were advised to switch to asciidoctor instead. It's almost compatible but some extensions used for perf documentation don't work with it. Here is the patch to cover them, and add the proper support for asciidoctor. Pass

[PATCH] perf: Documentation: Support for asciidoctor

asciidoc seems behind the recent big wave of python3 conversion, and we were advised to switch to asciidoctor instead. It's almost compatible but some extensions used for perf documentation don't work with it. Here is the patch to cover them, and add the proper support for asciidoctor. Pass

Re: [PATCH 7/9] Pmalloc Rare Write: modify selected pools

On 4/24/18 4:44 PM, Matthew Wilcox wrote: > On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote: >> On 4/24/18 1:50 PM, Matthew Wilcox wrote: >>> struct modifiable_data { >>> struct immutable_data *d; >>> ... >>> }; >>> >>> Then allocate a new pool, change d and destroy the old

Re: [PATCH 7/9] Pmalloc Rare Write: modify selected pools

On 4/24/18 4:44 PM, Matthew Wilcox wrote: > On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote: >> On 4/24/18 1:50 PM, Matthew Wilcox wrote: >>> struct modifiable_data { >>> struct immutable_data *d; >>> ... >>> }; >>> >>> Then allocate a new pool, change d and destroy the old

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On Tue, 24 Apr 2018 16:58:43 +0200, Oleksandr Andrushchenko wrote: > > On 04/24/2018 05:35 PM, Takashi Iwai wrote: > > On Tue, 24 Apr 2018 16:29:15 +0200, > > Oleksandr Andrushchenko wrote: > >> On 04/24/2018 05:20 PM, Takashi Iwai wrote: > >>> On Mon, 16 Apr 2018 08:24:51 +0200, > >>> Oleksandr

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On Tue, 24 Apr 2018 16:58:43 +0200, Oleksandr Andrushchenko wrote: > > On 04/24/2018 05:35 PM, Takashi Iwai wrote: > > On Tue, 24 Apr 2018 16:29:15 +0200, > > Oleksandr Andrushchenko wrote: > >> On 04/24/2018 05:20 PM, Takashi Iwai wrote: > >>> On Mon, 16 Apr 2018 08:24:51 +0200, > >>> Oleksandr

[PATCH] perf vendor events intel: Fix double words "are are" in cache.json

This patch fix double words "are are". Signed-off-by: Masanari Iida --- tools/perf/pmu-events/arch/x86/silvermont/cache.json | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/perf/pmu-events/arch/x86/silvermont/cache.json

[PATCH] perf vendor events intel: Fix double words "are are" in cache.json

This patch fix double words "are are". Signed-off-by: Masanari Iida --- tools/perf/pmu-events/arch/x86/silvermont/cache.json | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/perf/pmu-events/arch/x86/silvermont/cache.json

[PATCH v3 2/2] media: Add a driver for the ov7251 camera sensor

The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image Sensor from Omnivision. The driver supports the following modes: - 640x480 30fps - 640x480 60fps - 640x480 90fps Output format is 10bit B RAW - MEDIA_BUS_FMT_Y10_1X10. The driver supports configuration via user controls for: -

[PATCH v3 2/2] media: Add a driver for the ov7251 camera sensor

The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image Sensor from Omnivision. The driver supports the following modes: - 640x480 30fps - 640x480 60fps - 640x480 90fps Output format is 10bit B RAW - MEDIA_BUS_FMT_Y10_1X10. The driver supports configuration via user controls for: -

[PATCH v3 0/2] Add support for ov7251 camera sensor

The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image Sensor from Omnivision. -- Version 3: - DT binding: added that there shall be a single endpoint node in the port node; - added a comment for regulator

[PATCH v3 0/2] Add support for ov7251 camera sensor

The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image Sensor from Omnivision. -- Version 3: - DT binding: added that there shall be a single endpoint node in the port node; - added a comment for regulator

[PATCH v3 1/2] dt-bindings: media: Binding document for OV7251 camera sensor

Add the document for ov7251 device tree binding. CC: Rob Herring CC: Mark Rutland CC: devicet...@vger.kernel.org Signed-off-by: Todor Tomov Reviewed-by: Rob Herring ---

[PATCH v3 1/2] dt-bindings: media: Binding document for OV7251 camera sensor

Add the document for ov7251 device tree binding. CC: Rob Herring CC: Mark Rutland CC: devicet...@vger.kernel.org Signed-off-by: Todor Tomov Reviewed-by: Rob Herring --- .../devicetree/bindings/media/i2c/ov7251.txt | 52 ++ 1 file changed, 52 insertions(+) create

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

On Tue, 24 Apr 2018, Genki Sky wrote: > Sorry to have been the bearer of bad news :(. No problem. We're not shooting the messengers > Again, I just have my user hat on here. It does seem like this unifying > would have been nice to have. And even, more compliant with the POSIX > definition of

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

On Tue, 24 Apr 2018, Genki Sky wrote: > Sorry to have been the bearer of bad news :(. No problem. We're not shooting the messengers > Again, I just have my user hat on here. It does seem like this unifying > would have been nice to have. And even, more compliant with the POSIX > definition of

[PATCH v1] mfd: intel-lpss: Program REMAP register in PIO mode

According to documentation REMAP register has to be programmed in either DMA or PIO mode of the slice. Move the DMA capability check below to let REMAP register be programmed in PIO mode. Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Cc: Mika Westerberg

[PATCH v1] mfd: intel-lpss: Program REMAP register in PIO mode

According to documentation REMAP register has to be programmed in either DMA or PIO mode of the slice. Move the DMA capability check below to let REMAP register be programmed in PIO mode. Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Cc: Mika Westerberg

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On 04/24/2018 05:35 PM, Takashi Iwai wrote: On Tue, 24 Apr 2018 16:29:15 +0200, Oleksandr Andrushchenko wrote: On 04/24/2018 05:20 PM, Takashi Iwai wrote: On Mon, 16 Apr 2018 08:24:51 +0200, Oleksandr Andrushchenko wrote: +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) +{ +

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On 04/24/2018 05:35 PM, Takashi Iwai wrote: On Tue, 24 Apr 2018 16:29:15 +0200, Oleksandr Andrushchenko wrote: On 04/24/2018 05:20 PM, Takashi Iwai wrote: On Mon, 16 Apr 2018 08:24:51 +0200, Oleksandr Andrushchenko wrote: +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) +{ +

RE: hrtimer (rdmavt RNR timer) was lost

On Mon, 23 Apr 2018, Thomas Gleixner wrote: > On Mon, 23 Apr 2018, Wan, Kaike wrote: > > > Can you apply the following debug patch and enable the hrtimer_start trace > > > point and send me the full trace or upload it somewhere? > > > > The original trace was about 29GB and I filtered it with > >

RE: hrtimer (rdmavt RNR timer) was lost

On Mon, 23 Apr 2018, Thomas Gleixner wrote: > On Mon, 23 Apr 2018, Wan, Kaike wrote: > > > Can you apply the following debug patch and enable the hrtimer_start trace > > > point and send me the full trace or upload it somewhere? > > > > The original trace was about 29GB and I filtered it with > >

Re: [PATCH 1/3] big key: get rid of stack array allocation

On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: > Tycho Andersen wrote: > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != > > > > GCM_AES_IV_SIZE)) { > > > > + WARN(1, "big key algorithm changed?"); > > Please avoid using WARN() WARN_ON() etc. > syzbot

Re: [PATCH 1/3] big key: get rid of stack array allocation

On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: > Tycho Andersen wrote: > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != > > > > GCM_AES_IV_SIZE)) { > > > > + WARN(1, "big key algorithm changed?"); > > Please avoid using WARN() WARN_ON() etc. > syzbot

Re: [RFC][PATCH] printk: do not call console drivers from printk_safe context

On Tue, 24 Apr 2018 11:28:02 +0900 Sergey Senozhatsky wrote: > Calling console drivers from printk_safe() context does not really > make call_console_drivers() any safer, because printk_safe() has > nothing to do with console drivers or the underlying code. At

Re: [PATCH] powerpc/signal32: Use fault_in_pages_readable() to prefault user context

On Tue, Apr 24, 2018 at 4:45 PM, Mathieu Malaterre wrote: > On Tue, Apr 24, 2018 at 4:17 PM, Christophe Leroy > wrote: >> Use fault_in_pages_readable() to prefault user context >> instead of open coding >> >> Signed-off-by: Christophe Leroy

Re: [RFC][PATCH] printk: do not call console drivers from printk_safe context

On Tue, 24 Apr 2018 11:28:02 +0900 Sergey Senozhatsky wrote: > Calling console drivers from printk_safe() context does not really > make call_console_drivers() any safer, because printk_safe() has > nothing to do with console drivers or the underlying code. At the > same time printk()-s from

Re: [PATCH] powerpc/signal32: Use fault_in_pages_readable() to prefault user context

On Tue, Apr 24, 2018 at 4:45 PM, Mathieu Malaterre wrote: > On Tue, Apr 24, 2018 at 4:17 PM, Christophe Leroy > wrote: >> Use fault_in_pages_readable() to prefault user context >> instead of open coding >> >> Signed-off-by: Christophe Leroy >> --- >> arch/powerpc/kernel/signal_32.c | 13

Re: [PATCH 2/2] tracing/events: block: dev_t via driver core for plug and unplug events

On 04/19/2018 10:56 PM, Bart Van Assche wrote: > On Thu, 2018-04-19 at 12:24 -0700, Omar Sandoval wrote: >> We quiesce and freeze the queue before tearing it down, so it won't be >> NULL while we're still doing I/O. Cc'ing Bart in case I'm lying to you, >> though ;) > > blk_cleanup_queue() waits

Re: [PATCH 2/2] tracing/events: block: dev_t via driver core for plug and unplug events

On 04/19/2018 10:56 PM, Bart Van Assche wrote: > On Thu, 2018-04-19 at 12:24 -0700, Omar Sandoval wrote: >> We quiesce and freeze the queue before tearing it down, so it won't be >> NULL while we're still doing I/O. Cc'ing Bart in case I'm lying to you, >> though ;) > > blk_cleanup_queue() waits

Re: [PATCH] locking/rwsem: Synchronize task state & waiter->task of readers

On 04/24/2018 05:15 AM, Peter Zijlstra wrote: > On Mon, Apr 23, 2018 at 10:55:14PM +0200, Andrea Parri wrote: + /* + * To avoid missed wakeup of reader, we need to make sure + * that task state and waiter->task are properly synchronized. + * + * wakeup

Re: [PATCH] locking/rwsem: Synchronize task state & waiter->task of readers

On 04/24/2018 05:15 AM, Peter Zijlstra wrote: > On Mon, Apr 23, 2018 at 10:55:14PM +0200, Andrea Parri wrote: + /* + * To avoid missed wakeup of reader, we need to make sure + * that task state and waiter->task are properly synchronized. + * + * wakeup

Re: [PATCH] net: sh-eth: fix sh_eth_start_xmit()'s return type

On Tue, Apr 24, 2018 at 3:17 PM, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t'

Re: [PATCH] net: sh-eth: fix sh_eth_start_xmit()'s return type

On Tue, Apr 24, 2018 at 3:17 PM, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too. > >

Re: [PATCH 1/3] big key: get rid of stack array allocation

Tycho Andersen wrote: > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != GCM_AES_IV_SIZE)) { > > > + WARN(1, "big key algorithm changed?"); Please avoid using WARN() WARN_ON() etc. syzbot would catch it and panic() due to panic_on_warn == 1.

Re: [PATCH 1/3] big key: get rid of stack array allocation

Tycho Andersen wrote: > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != GCM_AES_IV_SIZE)) { > > > + WARN(1, "big key algorithm changed?"); Please avoid using WARN() WARN_ON() etc. syzbot would catch it and panic() due to panic_on_warn == 1.

Re: [PATCH] powerpc/signal32: Use fault_in_pages_readable() to prefault user context

On Tue, Apr 24, 2018 at 4:17 PM, Christophe Leroy wrote: > Use fault_in_pages_readable() to prefault user context > instead of open coding > > Signed-off-by: Christophe Leroy > --- > arch/powerpc/kernel/signal_32.c | 13 + > 1 file

Re: [PATCH] powerpc/signal32: Use fault_in_pages_readable() to prefault user context

On Tue, Apr 24, 2018 at 4:17 PM, Christophe Leroy wrote: > Use fault_in_pages_readable() to prefault user context > instead of open coding > > Signed-off-by: Christophe Leroy > --- > arch/powerpc/kernel/signal_32.c | 13 + > 1 file changed, 5 insertions(+), 8 deletions(-) > > diff

Re: [PATCH 7/9] Pmalloc Rare Write: modify selected pools

On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote: > On 4/24/18 1:50 PM, Matthew Wilcox wrote: > > struct modifiable_data { > > struct immutable_data *d; > > ... > > }; > > > > Then allocate a new pool, change d and destroy the old pool. > > With the above, you have just shifted

Re: [PATCH 7/9] Pmalloc Rare Write: modify selected pools

On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote: > On 4/24/18 1:50 PM, Matthew Wilcox wrote: > > struct modifiable_data { > > struct immutable_data *d; > > ... > > }; > > > > Then allocate a new pool, change d and destroy the old pool. > > With the above, you have just shifted

Re: [PATCH] kthread/smpboot: Serialize kthread parking against wakeup

Hi , We can also fix below race by smpboot code as well: @@ -109,7 +109,6 @@ static int smpboot_thread_fn(void *data)     struct smp_hotplug_thread *ht = td->ht;     while (1) { -   set_current_state(TASK_INTERRUPTIBLE);     preempt_disable();    

Re: [PATCH] kthread/smpboot: Serialize kthread parking against wakeup

Hi , We can also fix below race by smpboot code as well: @@ -109,7 +109,6 @@ static int smpboot_thread_fn(void *data)     struct smp_hotplug_thread *ht = td->ht;     while (1) { -   set_current_state(TASK_INTERRUPTIBLE);     preempt_disable();    

Re: [PATCH] net: aquantia: fix aq_ndev_start_xmit()'s return type

Luc please don't submit such a huge number of patches all at one time. Also, please fix the indentation of the functions whose arguments span multiple lines as has been pointed out to you in patch feedback. Finally, make this a true patch series. It is so much easier for maintainers to work

Re: [PATCH] net: aquantia: fix aq_ndev_start_xmit()'s return type

Luc please don't submit such a huge number of patches all at one time. Also, please fix the indentation of the functions whose arguments span multiple lines as has been pointed out to you in patch feedback. Finally, make this a true patch series. It is so much easier for maintainers to work

Re: kernel BUG at fs/f2fs/node.c:LINE!

Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: kernel BUG at fs/f2fs/inode.c:LINE! F2FS-fs (loop5): invalid crc value F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x0) F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock

Re: kernel BUG at fs/f2fs/node.c:LINE!

Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: kernel BUG at fs/f2fs/inode.c:LINE! F2FS-fs (loop5): invalid crc value F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x0) F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock

[PATCH 1/7] genirq/debugfs: Print percpu affinity for percpu_devid interrupts

percpu_devid interrupts have their affinities stored in a different field. Let's special-case it. Signed-off-by: Marc Zyngier --- kernel/irq/debugfs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c index

[PATCH 1/7] genirq/debugfs: Print percpu affinity for percpu_devid interrupts

percpu_devid interrupts have their affinities stored in a different field. Let's special-case it. Signed-off-by: Marc Zyngier --- kernel/irq/debugfs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c index

Re: printk feature for syzbot?

On Tue, 24 Apr 2018 10:33:36 +0900 Sergey Senozhatsky wrote: > Petr, Steven, Fengguang, what do you think? Do you have any objections? > Ideas? If it can be turned off by a config option, I'm fine with it. -- Steve

Re: [PATCH v1 3/4] clk: mediatek: add g3dsys support for MT2701 and MT7623

On Wed, Apr 18, 2018 at 06:24:55PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add clock driver support for g3dsys on MT2701 and MT7623, which is > providing essential clock gate and reset controller to Mali-450. > > Signed-off-by: Sean Wang

Re: printk feature for syzbot?

On Tue, 24 Apr 2018 10:33:36 +0900 Sergey Senozhatsky wrote: > Petr, Steven, Fengguang, what do you think? Do you have any objections? > Ideas? If it can be turned off by a config option, I'm fine with it. -- Steve

Re: [PATCH v1 3/4] clk: mediatek: add g3dsys support for MT2701 and MT7623

On Wed, Apr 18, 2018 at 06:24:55PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add clock driver support for g3dsys on MT2701 and MT7623, which is > providing essential clock gate and reset controller to Mali-450. > > Signed-off-by: Sean Wang > --- > drivers/clk/mediatek/Kconfig

Re: [PATCH v7 6/9] PCI: dwc: Define maximum number of vectors

On Tuesday, April 24, 2018 9:45 AM, Gustavo Pimentel wrote: > > Adds a callback that defines the maximum number of vectors that can be use > by the Root Complex. > > Since this is a parameter associated to each SoC IP setting, makes sense > to > be configurable and easily visible to future

Re: [PATCH v7 6/9] PCI: dwc: Define maximum number of vectors

On Tuesday, April 24, 2018 9:45 AM, Gustavo Pimentel wrote: > > Adds a callback that defines the maximum number of vectors that can be use > by the Root Complex. > > Since this is a parameter associated to each SoC IP setting, makes sense > to > be configurable and easily visible to future

Re: [PATCH] ARM: tegra: fix ulpi regression on tegra20

Hi Marcel, On 24.04.2018 01:05, Marcel Ziswiler wrote: > Hi Dmitry > > On Fri, 2018-04-20 at 13:50 +0300, Dmitry Osipenko wrote: >> ... >> I managed to find CDEV clocks in TRM this time. > > And where exactly in which TRM? In all my attempts at finding anything > CDEV2 is just a pad group which

Re: [PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings

On Wed, Apr 18, 2018 at 06:24:54PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add bindings to g3dsys providing necessary clock and reset control to > Mali-450. > > Signed-off-by: Sean Wang > --- >

Re: [PATCH] ARM: tegra: fix ulpi regression on tegra20

Hi Marcel, On 24.04.2018 01:05, Marcel Ziswiler wrote: > Hi Dmitry > > On Fri, 2018-04-20 at 13:50 +0300, Dmitry Osipenko wrote: >> ... >> I managed to find CDEV clocks in TRM this time. > > And where exactly in which TRM? In all my attempts at finding anything > CDEV2 is just a pad group which

Re: [PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings

On Wed, Apr 18, 2018 at 06:24:54PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add bindings to g3dsys providing necessary clock and reset control to > Mali-450. > > Signed-off-by: Sean Wang > --- > .../bindings/arm/mediatek/mediatek,g3dsys.txt | 30 >

<    8   9   10   11   12   13   14   15   16   17   >