[RFC] trace_events: Fix kernel crash while using empty filter with perf

Kernel is crashing when user tries to record 'ftrace:function' event with empty filter: # perf record -e ftrace:function --filter="" ls # dmesg BUG: unable to handle kernel NULL pointer dereference at 0008 Oops: [#1] SMP PTI ... RIP:

[RFC] trace_events: Fix kernel crash while using empty filter with perf

Kernel is crashing when user tries to record 'ftrace:function' event with empty filter: # perf record -e ftrace:function --filter="" ls # dmesg BUG: unable to handle kernel NULL pointer dereference at 0008 Oops: [#1] SMP PTI ... RIP:

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek wrote: > On Sun 2018-04-15 11:00:06, Kees Cook wrote: >> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote: >> > Hi! >> > >> >> Thanks. >> >> >> >> Ok, let me try to bisect it. Compile-problem should be easy... >> >>

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek wrote: > On Sun 2018-04-15 11:00:06, Kees Cook wrote: >> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote: >> > Hi! >> > >> >> Thanks. >> >> >> >> Ok, let me try to bisect it. Compile-problem should be easy... >> >> >> >> Hmm. And as it is

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On Fri, 20 Apr 2018 09:00:49 -0500 Bjorn Helgaas wrote: > [+cc Rajat, Alex because of their interest in the reset/hotplug issue] > > For context, Sinan's patch is this: > > > diff --git a/drivers/infiniband/hw/hfi1/pcie.c > > b/drivers/infiniband/hw/hfi1/pcie.c > > index

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On Fri, 20 Apr 2018 09:00:49 -0500 Bjorn Helgaas wrote: > [+cc Rajat, Alex because of their interest in the reset/hotplug issue] > > For context, Sinan's patch is this: > > > diff --git a/drivers/infiniband/hw/hfi1/pcie.c > > b/drivers/infiniband/hw/hfi1/pcie.c > > index 83d66e8..75f49e3

Re: Clang arm64 build is broken

On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote: >> The issue is that >> clang doesn't know about the "S" asm constraint. I reported this to >> clang [2], and hopefully this will get fixed. In the meantime, would >> it possible to work around using the "S" constraint in

Re: Clang arm64 build is broken

On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote: >> The issue is that >> clang doesn't know about the "S" asm constraint. I reported this to >> clang [2], and hopefully this will get fixed. In the meantime, would >> it possible to work around using the "S" constraint in the kernel? > > I

Re: [PATCH v2 1/4] tpm: Add explicit endianness cast

On Thu, Apr 19, 2018 at 01:09:12PM +, Thiebaud Weksteen wrote: > On Tue, Apr 17, 2018 at 4:00 PM Jason Gunthorpe wrote: > > > On Tue, Apr 17, 2018 at 08:32:33AM +, Thiebaud Weksteen wrote: > > > On Tue, Apr 17, 2018 at 5:02 AM Jason Gunthorpe wrote: > > > >

Re: [PATCH v2 1/4] tpm: Add explicit endianness cast

On Thu, Apr 19, 2018 at 01:09:12PM +, Thiebaud Weksteen wrote: > On Tue, Apr 17, 2018 at 4:00 PM Jason Gunthorpe wrote: > > > On Tue, Apr 17, 2018 at 08:32:33AM +, Thiebaud Weksteen wrote: > > > On Tue, Apr 17, 2018 at 5:02 AM Jason Gunthorpe wrote: > > > > > > > On Thu, Apr 12, 2018 at

Re: [PATCH] printk: Ratelimit messages printed by console drivers

On Fri 2018-04-20 10:17:51, Steven Rostedt wrote: > On Fri, 20 Apr 2018 16:01:57 +0200 > Petr Mladek wrote: > > On Fri 2018-04-20 08:04:28, Steven Rostedt wrote: > > > The problem is the way rate limit works. If you print 100 lines (or > > > 1000) in 5 seconds, then you just

Re: [PATCH] printk: Ratelimit messages printed by console drivers

On Fri 2018-04-20 10:17:51, Steven Rostedt wrote: > On Fri, 20 Apr 2018 16:01:57 +0200 > Petr Mladek wrote: > > On Fri 2018-04-20 08:04:28, Steven Rostedt wrote: > > > The problem is the way rate limit works. If you print 100 lines (or > > > 1000) in 5 seconds, then you just stopped printing from

Re: [PATCH] sh: mm: Fix unprotected access to struct device

On Fri, Apr 20, 2018 at 11:59:13AM +0200, Geert Uytterhoeven wrote: > Hi Christoph, > > On Fri, Apr 20, 2018 at 10:31 AM, Christoph Hellwig > wrote: > > On Wed, Apr 18, 2018 at 03:13:14PM +0200, jacopo mondi wrote: > >> As long as it goes for arch/sh, the only user of

Re: [PATCH] sh: mm: Fix unprotected access to struct device

On Fri, Apr 20, 2018 at 11:59:13AM +0200, Geert Uytterhoeven wrote: > Hi Christoph, > > On Fri, Apr 20, 2018 at 10:31 AM, Christoph Hellwig > wrote: > > On Wed, Apr 18, 2018 at 03:13:14PM +0200, jacopo mondi wrote: > >> As long as it goes for arch/sh, the only user of dma_alloc_coherent() > >>

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On Thu, Apr 19, 2018 at 10:11:27PM +, Deucher, Alexander wrote: > My understanding was that some platfoms only bring up the link in > gen 1 mode for compatibility reasons. TBH, I'm not that familiar > with how the links come up on different platforms. Then the platform firmware or

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On Thu, Apr 19, 2018 at 10:11:27PM +, Deucher, Alexander wrote: > My understanding was that some platfoms only bring up the link in > gen 1 mode for compatibility reasons. TBH, I'm not that familiar > with how the links come up on different platforms. Then the platform firmware or

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Thu, Apr 19, 2018 at 5:40 PM, Michael S. Tsirkin wrote: > On Tue, Apr 03, 2018 at 12:06:03PM -0700, Alexander Duyck wrote: >> On Tue, Apr 3, 2018 at 11:27 AM, Michael S. Tsirkin wrote: >> > On Tue, Apr 03, 2018 at 10:32:00AM -0700, Alexander Duyck wrote: >>

[PATCH 4/4] KVM: arm64: Add support for PUD hugepages at stage 2

KVM only supports PMD hugepages at stage 2. Extend the stage 2 fault handling to add support for PUD hugepages. Addition of pud hugepage support enables additional hugepage sizes (e.g., 1G with 4K granule) which can be useful on cores that support mapping larger block sizes in the TLB entries.

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Thu, Apr 19, 2018 at 5:40 PM, Michael S. Tsirkin wrote: > On Tue, Apr 03, 2018 at 12:06:03PM -0700, Alexander Duyck wrote: >> On Tue, Apr 3, 2018 at 11:27 AM, Michael S. Tsirkin wrote: >> > On Tue, Apr 03, 2018 at 10:32:00AM -0700, Alexander Duyck wrote: >> >> On Tue, Apr 3, 2018 at 6:12 AM,

[PATCH 4/4] KVM: arm64: Add support for PUD hugepages at stage 2

KVM only supports PMD hugepages at stage 2. Extend the stage 2 fault handling to add support for PUD hugepages. Addition of pud hugepage support enables additional hugepage sizes (e.g., 1G with 4K granule) which can be useful on cores that support mapping larger block sizes in the TLB entries.

Re: [Patch v4] cifs: Allocate validate negotiation request through kmalloc

Looks good, but I have two possibly style-related comments. On 4/19/2018 5:38 PM, Long Li wrote: From: Long Li The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect

Re: [Patch v4] cifs: Allocate validate negotiation request through kmalloc

Looks good, but I have two possibly style-related comments. On 4/19/2018 5:38 PM, Long Li wrote: From: Long Li The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect address can't be detected

Re: [REVIEW][PATCH 16/22] signal/sh: Use force_sig_fault where appropriate

On Fri, Apr 20, 2018 at 09:38:05AM -0500, Eric W. Biederman 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 cleared. > > Simplify this process

Re: [REVIEW][PATCH 16/22] signal/sh: Use force_sig_fault where appropriate

On Fri, Apr 20, 2018 at 09:38:05AM -0500, Eric W. Biederman 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 cleared. > > Simplify this process

[PATCH 2/4] KVM: arm/arm64: Introduce helpers to manupulate page table entries

Introduce helpers to abstract architectural handling of the conversion of pfn to page table entries and marking a PMD page table entry as a block entry. The helpers are introduced in preparation for supporting PUD hugepages at stage 2 - which are supported on arm64 but do not exist on arm.

[PATCH 1/4] KVM: arm/arm64: Share common code in user_mem_abort()

The code for operations such as marking the pfn as dirty, and dcache/icache maintenance during stage 2 fault handling is duplicated between normal pages and PMD hugepages. Instead of creating another copy of the operations when we introduce PUD hugepages, let's share them across the different

[PATCH 2/4] KVM: arm/arm64: Introduce helpers to manupulate page table entries

Introduce helpers to abstract architectural handling of the conversion of pfn to page table entries and marking a PMD page table entry as a block entry. The helpers are introduced in preparation for supporting PUD hugepages at stage 2 - which are supported on arm64 but do not exist on arm.

[PATCH 1/4] KVM: arm/arm64: Share common code in user_mem_abort()

The code for operations such as marking the pfn as dirty, and dcache/icache maintenance during stage 2 fault handling is duplicated between normal pages and PMD hugepages. Instead of creating another copy of the operations when we introduce PUD hugepages, let's share them across the different

[PATCH 3/4] KVM: arm64: Support dirty page tracking for PUD hugepages

In preparation for creating PUD hugepages at stage 2, add support for write protecting PUD hugepages when they are encountered. Write protecting guest tables is used to track dirty pages when migrating VMs. Also, provide trivial implementations of required kvm_s2pud_* helpers to allow sharing of

[PATCH 3/4] KVM: arm64: Support dirty page tracking for PUD hugepages

In preparation for creating PUD hugepages at stage 2, add support for write protecting PUD hugepages when they are encountered. Write protecting guest tables is used to track dirty pages when migrating VMs. Also, provide trivial implementations of required kvm_s2pud_* helpers to allow sharing of

[PATCH 0/4] KVM: Support PUD hugepages at stage 2

Hi, This patchset adds support for PUD hugepages at stage 2. This feature is useful on cores that have support for large sized TLB mappings (e.g., 1GB for 4K granule). Previous posting[0]. Support is added to code that is shared between arm and arm64. Dummy helpers for arm are provided as the

[PATCH 0/4] KVM: Support PUD hugepages at stage 2

Hi, This patchset adds support for PUD hugepages at stage 2. This feature is useful on cores that have support for large sized TLB mappings (e.g., 1GB for 4K granule). Previous posting[0]. Support is added to code that is shared between arm and arm64. Dummy helpers for arm are provided as the

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On Thu, Apr 19, 2018 at 04:47:23PM -0500, Bjorn Helgaas wrote: > I *thought* the hardware was supposed to automatically negotiate to > the highest rate supported by both sides without any help at all from > software. But since several drivers have code to do it themselves, I > wonder if I'm

Re: [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset

On Thu, Apr 19, 2018 at 04:47:23PM -0500, Bjorn Helgaas wrote: > I *thought* the hardware was supposed to automatically negotiate to > the highest rate supported by both sides without any help at all from > software. But since several drivers have code to do it themselves, I > wonder if I'm

Re: [PATCH] SLUB: Do not fallback to mininum order if __GFP_NORETRY is set

On Thu, 19 Apr 2018, Michal Hocko wrote: > Overriding __GFP_NORETRY is just a bad idea. It will make the semantic > of the flag just more confusing. Note there are users who use > __GFP_NORETRY as a way to suppress heavy memory pressure and/or the OOM > killer. You do not want to change the

Re: [PATCH] SLUB: Do not fallback to mininum order if __GFP_NORETRY is set

On Thu, 19 Apr 2018, Michal Hocko wrote: > Overriding __GFP_NORETRY is just a bad idea. It will make the semantic > of the flag just more confusing. Note there are users who use > __GFP_NORETRY as a way to suppress heavy memory pressure and/or the OOM > killer. You do not want to change the

Re: [PATCH 1/8] arm: shmobile: Change platform dependency to ARCH_RENESAS

On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote: > Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") > is ARCH_RENESAS a more appropriate platform dependency than the legacy "ARCH_RENESAS is", no? > ARCH_SHMOBILE, hence use the former. > > This will allow to drop

Re: [PATCH 1/8] arm: shmobile: Change platform dependency to ARCH_RENESAS

On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote: > Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") > is ARCH_RENESAS a more appropriate platform dependency than the legacy "ARCH_RENESAS is", no? > ARCH_SHMOBILE, hence use the former. > > This will allow to drop

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

On Friday, April 04/20/18, 2018 at 19:06:09 +0530, Eric W. Biederman wrote: > Rahul Lakkireddy writes: > > > On Thursday, April 04/19/18, 2018 at 20:23:37 +0530, Eric W. Biederman > > wrote: > >> Rahul Lakkireddy writes: > >> > >> >

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

On Friday, April 04/20/18, 2018 at 19:06:09 +0530, Eric W. Biederman wrote: > Rahul Lakkireddy writes: > > > On Thursday, April 04/19/18, 2018 at 20:23:37 +0530, Eric W. Biederman > > wrote: > >> Rahul Lakkireddy writes: > >> > >> > On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave

Re: [RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function

On Wednesday 18 Apr 2018 at 17:23:16 (+0800), Leo Yan wrote: > On Fri, Apr 06, 2018 at 04:36:05PM +0100, Dietmar Eggemann wrote: > > [...] > > > +/* > > + * Estimates the system level energy assuming that p wakes-up on dst_cpu. > > + * > > + * compute_energy() is safe to call only if an energy

Re: [RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function

On Wednesday 18 Apr 2018 at 17:23:16 (+0800), Leo Yan wrote: > On Fri, Apr 06, 2018 at 04:36:05PM +0100, Dietmar Eggemann wrote: > > [...] > > > +/* > > + * Estimates the system level energy assuming that p wakes-up on dst_cpu. > > + * > > + * compute_energy() is safe to call only if an energy

Re: [PATCH net-next v2 0/3] ave: fix the activation issues for some UniPhier SoCs

From: Kunihiko Hayashi Date: Thu, 19 Apr 2018 16:24:52 +0900 > This add the following stuffs to fix the activation issues and satisfy > requirements for AVE ethernet driver implemented on some UniPhier SoCs. > > - Add support for additional necessary clocks and

Re: [PATCH net-next v2 0/3] ave: fix the activation issues for some UniPhier SoCs

From: Kunihiko Hayashi Date: Thu, 19 Apr 2018 16:24:52 +0900 > This add the following stuffs to fix the activation issues and satisfy > requirements for AVE ethernet driver implemented on some UniPhier SoCs. > > - Add support for additional necessary clocks and resets, because the kernel > is

[REVIEW][PATCH 20/22] signal/um: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 13/22] signal/parisc: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 13/22] signal/parisc: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 20/22] signal/um: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 21/22] signal/xtensa: Consistenly use SIGBUS in do_unaligned_user

While working on changing this code to use force_sig_fault I discovered that do_unaliged_user is sets si_signo to SIGBUS and passes SIGSEGV to force_sig_info. Which is just b0rked. The code is reporting a SIGBUS error so replace the SIGSEGV with SIGBUS. Cc: Chris Zankel Cc:

[REVIEW][PATCH 18/22] signal/sparc: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 21/22] signal/xtensa: Consistenly use SIGBUS in do_unaligned_user

While working on changing this code to use force_sig_fault I discovered that do_unaliged_user is sets si_signo to SIGBUS and passes SIGSEGV to force_sig_info. Which is just b0rked. The code is reporting a SIGBUS error so replace the SIGSEGV with SIGBUS. Cc: Chris Zankel Cc: Max Filippov Cc:

[REVIEW][PATCH 18/22] signal/sparc: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 22/22] signal/xtensa: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 22/22] signal/xtensa: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

Re: [GIT PULL V3] Thermal SoC management updates for v4.17-rc1

Hello Bartlomiej, On Thu, Apr 19, 2018 at 12:41:42PM +0200, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, April 18, 2018 07:10:30 AM Eduardo Valentin wrote: > > Hello, > > > > On Wed, Apr 18, 2018 at 03:51:29PM +0800, Zhang Rui wrote: > > > Hi, Eduardo, > > > > > > On 六,

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

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

Re: [GIT PULL V3] Thermal SoC management updates for v4.17-rc1

Hello Bartlomiej, On Thu, Apr 19, 2018 at 12:41:42PM +0200, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, April 18, 2018 07:10:30 AM Eduardo Valentin wrote: > > Hello, > > > > On Wed, Apr 18, 2018 at 03:51:29PM +0800, Zhang Rui wrote: > > > Hi, Eduardo, > > > > > > On 六,

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

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

Re: AMD graphics performance regression in 4.15 and later

On 2018-04-11 11:37 AM, Christian König wrote: > Am 11.04.2018 um 06:00 schrieb Gabriel C: >> 2018-04-09 11:42 GMT+02:00 Christian König >> : >>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: Hi Christian, Thanks for the info. FYI, I've also

Re: AMD graphics performance regression in 4.15 and later

On 2018-04-11 11:37 AM, Christian König wrote: > Am 11.04.2018 um 06:00 schrieb Gabriel C: >> 2018-04-09 11:42 GMT+02:00 Christian König >> : >>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: Hi Christian, Thanks for the info. FYI, I've also opened a Firefox bug for that at:

[REVIEW][PATCH 17/22] signal/sparc: Use send_sig_fault where appropriate

Filling in struct siginfo before calling send_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 cleared. Simplify this process by using the helper send_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 17/22] signal/sparc: Use send_sig_fault where appropriate

Filling in struct siginfo before calling send_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 cleared. Simplify this process by using the helper send_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 15/22] signal/s390: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 15/22] signal/s390: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 16/22] signal/sh: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 16/22] signal/sh: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

Today user mode linux only works on x86 and x86_64 and this allows simplifications of relay_signal. - x86 always set si_errno to 0 in fault handlers. - x86 does not implement si_trapno. - Only si_codes between SI_USER and SI_KERNEL have a fault address. Therefore warn if si_errno is set (it

[REVIEW][PATCH 12/22] signal/parisc: Use force_sig_mceerr where appropriate

In do_page_fault where an mceerr is generated stop and call force_sig_mceerr. Keeping the mcerr handling logic out of the force_sig_info call below. This ensures that only and always in the mcerr case is lsb interesting. This ensures setting set si_lsb in the future won't accidentally stomp

[REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

Today user mode linux only works on x86 and x86_64 and this allows simplifications of relay_signal. - x86 always set si_errno to 0 in fault handlers. - x86 does not implement si_trapno. - Only si_codes between SI_USER and SI_KERNEL have a fault address. Therefore warn if si_errno is set (it

[REVIEW][PATCH 12/22] signal/parisc: Use force_sig_mceerr where appropriate

In do_page_fault where an mceerr is generated stop and call force_sig_mceerr. Keeping the mcerr handling logic out of the force_sig_info call below. This ensures that only and always in the mcerr case is lsb interesting. This ensures setting set si_lsb in the future won't accidentally stomp

Re: [PATCH] [net] ipv6: sr: fix NULL pointer dereference in seg6_do_srh_encap()- v4 pkts

On Fri, 20 Apr 2018 15:38:08 +0100 David Lebrun wrote: > On 04/20/2018 02:58 PM, Ahmed Abdelsalam wrote: > > In case of seg6 in encap mode, seg6_do_srh_encap() calls set_tun_src() > > in order to set the src addr of outer IPv6 header. > > > > The net_device is required for

Re: [PATCH] [net] ipv6: sr: fix NULL pointer dereference in seg6_do_srh_encap()- v4 pkts

On Fri, 20 Apr 2018 15:38:08 +0100 David Lebrun wrote: > On 04/20/2018 02:58 PM, Ahmed Abdelsalam wrote: > > In case of seg6 in encap mode, seg6_do_srh_encap() calls set_tun_src() > > in order to set the src addr of outer IPv6 header. > > > > The net_device is required for set_tun_src().

[REVIEW][PATCH 11/22] signal/openrisc: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 11/22] signal/openrisc: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

* Daniel Stone [180420 14:41]: > Hi Tony! > > On 20 April 2018 at 15:25, Tony Lindgren wrote: > > * Daniel Stone [180420 10:21]: > >> On 20 April 2018 at 08:09, Tomi Valkeinen wrote: > >> > It's actually not

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

* Daniel Stone [180420 14:41]: > Hi Tony! > > On 20 April 2018 at 15:25, Tony Lindgren wrote: > > * Daniel Stone [180420 10:21]: > >> On 20 April 2018 at 08:09, Tomi Valkeinen wrote: > >> > It's actually not quite clear to me how manual update displays work with > >> > DRM... > >> > > >> > As

Re: [RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function

Hi Leo, On Wednesday 18 Apr 2018 at 20:15:47 (+0800), Leo Yan wrote: > Sorry I introduce mess at here to spread my questions in several > replying, later will try to ask questions in one replying. Below are > more questions which it's good to bring up: > > The code for energy computation is

Re: [RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function

Hi Leo, On Wednesday 18 Apr 2018 at 20:15:47 (+0800), Leo Yan wrote: > Sorry I introduce mess at here to spread my questions in several > replying, later will try to ask questions in one replying. Below are > more questions which it's good to bring up: > > The code for energy computation is

[REVIEW][PATCH 04/22] signal/hexagon: Use force_sig_fault as appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 06/22] signal/microblaze: Remove the commented out force_sig_info in do_page_fault

Remove the commented out call to force_sig_info right after a call to _exception in do_page_fault. The function _exception does exactly the work the commented out code does so there is no reason for the commented out code. Cc: Michal Simek Signed-off-by: "Eric W. Biederman"

[REVIEW][PATCH 06/22] signal/microblaze: Remove the commented out force_sig_info in do_page_fault

Remove the commented out call to force_sig_info right after a call to _exception in do_page_fault. The function _exception does exactly the work the commented out code does so there is no reason for the commented out code. Cc: Michal Simek Signed-off-by: "Eric W. Biederman" ---

[REVIEW][PATCH 04/22] signal/hexagon: Use force_sig_fault as appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 03/22] signal/c6x: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 03/22] signal/c6x: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 10/22] signal/nios2: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 09/22] signal/nds32: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 07/22] signal/microblaze: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 07/22] signal/microblaze: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 10/22] signal/nios2: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 09/22] signal/nds32: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 08/22] signal/mips: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 08/22] signal/mips: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 05/22] signal/m68k: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 05/22] signal/m68k: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

Re: [PATCH] net: qrtr: Expose tunneling endpoint to user space

From: Bjorn Andersson Date: Wed, 18 Apr 2018 22:03:46 -0700 > +struct qrtr_tun { > + struct qrtr_endpoint ep; > + > + struct mutex queue_lock; > + struct sk_buff_head queue; > + wait_queue_head_t readq; > +}; The queue lock is surperfluous.

Re: [PATCH] net: qrtr: Expose tunneling endpoint to user space

From: Bjorn Andersson Date: Wed, 18 Apr 2018 22:03:46 -0700 > +struct qrtr_tun { > + struct qrtr_endpoint ep; > + > + struct mutex queue_lock; > + struct sk_buff_head queue; > + wait_queue_head_t readq; > +}; The queue lock is surperfluous. sk_buff_head and all of the helpers

[REVIEW][PATCH 02/22] signal/alpha: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 02/22] signal/alpha: Use force_sig_fault where appropriate

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 cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 01/22] signal/alpha: Use send_sig_fault where appropriate

Filling in struct siginfo before calling send_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 cleared. Simplify this process by using the helper send_sig_fault. Which takes as a parameters all of the

[REVIEW][PATCH 01/22] signal/alpha: Use send_sig_fault where appropriate

Filling in struct siginfo before calling send_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 cleared. Simplify this process by using the helper send_sig_fault. Which takes as a parameters all of the

<    4   5   6   7   8   9   10   11   12   13   >