Re: BUG: corrupted list in __dentry_kill

On Sat, Mar 31, 2018 at 04:01:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on bpf-next commit > 7828f20e3779e4e85e55371e0e43f5006a15fb41 (Sat Mar 31 00:17:57 2018 +) > Merge branch 'bpf-cgroup-bind-connect' > syzbot dashboard link: >

Re: BUG: corrupted list in __dentry_kill

On Sat, Mar 31, 2018 at 04:01:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on bpf-next commit > 7828f20e3779e4e85e55371e0e43f5006a15fb41 (Sat Mar 31 00:17:57 2018 +) > Merge branch 'bpf-cgroup-bind-connect' > syzbot dashboard link: >

Re: [PATCH v5 4/4] zram: introduce zram memory tracking

On (04/20/18 11:09), Minchan Kim wrote: [..] > > hm, OK, can we get this info into the changelog? > > No problem. I will add as follows, > > "I used the feature a few years ago to find memory hoggers in userspace > to notice them what memory they have wasted without touch for a long time. >

Re: [PATCH v5 4/4] zram: introduce zram memory tracking

On (04/20/18 11:09), Minchan Kim wrote: [..] > > hm, OK, can we get this info into the changelog? > > No problem. I will add as follows, > > "I used the feature a few years ago to find memory hoggers in userspace > to notice them what memory they have wasted without touch for a long time. >

Re: [PATCH] iommu/vt-d: fix usage of force parameter in intel_ir_reconfigure_irte()

> On Apr 4, 2018, at 2:06 PM, Jag Raman wrote: > > > > On 3/6/2018 5:39 PM, Jagannathan Raman wrote: >> It was noticed that the IRTE configured for guest OS kernel >> was over-written while the guest was running. As a result, >> vt-d Posted Interrupts configured for the

Re: [PATCH] iommu/vt-d: fix usage of force parameter in intel_ir_reconfigure_irte()

> On Apr 4, 2018, at 2:06 PM, Jag Raman wrote: > > > > On 3/6/2018 5:39 PM, Jagannathan Raman wrote: >> It was noticed that the IRTE configured for guest OS kernel >> was over-written while the guest was running. As a result, >> vt-d Posted Interrupts configured for the guest are not being

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

On (04/19/18 14:53), Petr Mladek wrote: > > > > > > > > Besides 100 lines is absolutely not enough for any real lockdep splat. > > > > My call would be - up to 1000 lines in a 1 minute interval. > > But this would break the intention of this patch. You picked an arbitrary value and now you are

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

On (04/19/18 14:53), Petr Mladek wrote: > > > > > > > > Besides 100 lines is absolutely not enough for any real lockdep splat. > > > > My call would be - up to 1000 lines in a 1 minute interval. > > But this would break the intention of this patch. You picked an arbitrary value and now you are

Re: [PATCH net-next] net-next/hinic: add arm64 support

On 2018/4/20 1:34, David Miller wrote: > From: Zhao Chen > Date: Wed, 18 Apr 2018 06:07:39 -0400 > >> This patch enables arm64 platform support for the HINIC driver. >> >> Signed-off-by: Zhao Chen > > Applied, thank you. > > . > Thanks, David.

Re: [PATCH net-next] net-next/hinic: add arm64 support

On 2018/4/20 1:34, David Miller wrote: > From: Zhao Chen > Date: Wed, 18 Apr 2018 06:07:39 -0400 > >> This patch enables arm64 platform support for the HINIC driver. >> >> Signed-off-by: Zhao Chen > > Applied, thank you. > > . > Thanks, David.

Re: [PATCH v5 4/4] zram: introduce zram memory tracking

On Wed, Apr 18, 2018 at 02:07:15PM -0700, Andrew Morton wrote: > On Wed, 18 Apr 2018 10:26:36 +0900 Minchan Kim wrote: > > > Hi Andrew, > > > > On Tue, Apr 17, 2018 at 02:59:21PM -0700, Andrew Morton wrote: > > > On Mon, 16 Apr 2018 18:09:46 +0900 Minchan Kim

Re: [PATCH v5 4/4] zram: introduce zram memory tracking

On Wed, Apr 18, 2018 at 02:07:15PM -0700, Andrew Morton wrote: > On Wed, 18 Apr 2018 10:26:36 +0900 Minchan Kim wrote: > > > Hi Andrew, > > > > On Tue, Apr 17, 2018 at 02:59:21PM -0700, Andrew Morton wrote: > > > On Mon, 16 Apr 2018 18:09:46 +0900 Minchan Kim wrote: > > > > > > > zRam as swap

RE: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

> --- a/drivers/usb/chipidea/Kconfig > +++ b/drivers/usb/chipidea/Kconfig > @@ -3,6 +3,8 @@ config USB_CHIPIDEA > depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD > && !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA > select EXTCON > select RESET_CONTROLLER

RE: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

> --- a/drivers/usb/chipidea/Kconfig > +++ b/drivers/usb/chipidea/Kconfig > @@ -3,6 +3,8 @@ config USB_CHIPIDEA > depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD > && !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA > select EXTCON > select RESET_CONTROLLER

[PATCH] f2fs: sepearte hot/cold in free nid

As most indirect node, dindirect node, and xattr node won't be updated after they are created, but inode node and other direct node will change more frequently, so store their nat entries mixedly in whole nat table will suffer: - fragment nat table soon due to different update rate - more nat

[PATCH] f2fs: sepearte hot/cold in free nid

As most indirect node, dindirect node, and xattr node won't be updated after they are created, but inode node and other direct node will change more frequently, so store their nat entries mixedly in whole nat table will suffer: - fragment nat table soon due to different update rate - more nat

Re: [PATCHv2] printk: wake up klogd in vprintk_emit

On (04/19/18 12:02), Petr Mladek wrote: > On Thu 2018-04-19 10:42:50, Sergey Senozhatsky wrote: > > We wake up klogd very late - only when current console_sem owner > > is done pushing pending kernel messages to the serial/net consoles. > > In some cases this results in lost syslog messages,

Re: [PATCHv2] printk: wake up klogd in vprintk_emit

On (04/19/18 12:02), Petr Mladek wrote: > On Thu 2018-04-19 10:42:50, Sergey Senozhatsky wrote: > > We wake up klogd very late - only when current console_sem owner > > is done pushing pending kernel messages to the serial/net consoles. > > In some cases this results in lost syslog messages,

Re: [PATCH] time: tick-sched: use bool for tick_stopped

On 2018-04-11 07:20 AM, yuank...@codeaurora.org wrote: ++ On 2018-04-11 07:09 AM, yuank...@codeaurora.org wrote: ++ On 2018-04-10 10:49 PM, yuank...@codeaurora.org wrote: Typo... On 2018-04-10 10:08 PM, yuank...@codeaurora.org wrote: On 2018-04-10 07:06 PM, Thomas Gleixner wrote: On Tue,

Re: [PATCH] time: tick-sched: use bool for tick_stopped

On 2018-04-11 07:20 AM, yuank...@codeaurora.org wrote: ++ On 2018-04-11 07:09 AM, yuank...@codeaurora.org wrote: ++ On 2018-04-10 10:49 PM, yuank...@codeaurora.org wrote: Typo... On 2018-04-10 10:08 PM, yuank...@codeaurora.org wrote: On 2018-04-10 07:06 PM, Thomas Gleixner wrote: On Tue,

Re: [PATCH v5 11/23] ASoC: qdsp6: q6adm: Add q6adm driver

Hi Srinivas, I love your patch! Yet something to improve: [auto build test ERROR on asoc/for-next] [also build test ERROR on v4.17-rc1 next-20180419] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v5 11/23] ASoC: qdsp6: q6adm: Add q6adm driver

Hi Srinivas, I love your patch! Yet something to improve: [auto build test ERROR on asoc/for-next] [also build test ERROR on v4.17-rc1 next-20180419] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

Hi Paul, Philipp, On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel wrote: > Hi Paul, > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote: > > This adds a device-tree binding document that specifies the properties > > used by the Sunxi-Cedurs VPU driver, as well as

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

Hi Paul, Philipp, On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel wrote: > Hi Paul, > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote: > > This adds a device-tree binding document that specifies the properties > > used by the Sunxi-Cedurs VPU driver, as well as examples. > > > >

RE: [PATCH resend] usb: chipidea: Don't select EXTCON

> drivers/usb/chipidea/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index > 785f0ed037f7..97509172d536 100644 > --- a/drivers/usb/chipidea/Kconfig > +++ b/drivers/usb/chipidea/Kconfig > @@ -1,7 +1,6 @@ > config

RE: [PATCH resend] usb: chipidea: Don't select EXTCON

> drivers/usb/chipidea/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index > 785f0ed037f7..97509172d536 100644 > --- a/drivers/usb/chipidea/Kconfig > +++ b/drivers/usb/chipidea/Kconfig > @@ -1,7 +1,6 @@ > config

Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions

On 2018-04-19 06:42 PM, yuank...@codeaurora.org wrote: On 2018-04-19 02:48 PM, yuank...@codeaurora.org wrote: On 2018-04-19 01:16 PM, Julia Lawall wrote: On Wed, 18 Apr 2018, Joe Perches wrote: On Thu, 2018-04-19 at 06:40 +0200, Julia Lawall wrote: > > On Wed, 18 Apr 2018, Joe Perches wrote:

Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions

On 2018-04-19 06:42 PM, yuank...@codeaurora.org wrote: On 2018-04-19 02:48 PM, yuank...@codeaurora.org wrote: On 2018-04-19 01:16 PM, Julia Lawall wrote: On Wed, 18 Apr 2018, Joe Perches wrote: On Thu, 2018-04-19 at 06:40 +0200, Julia Lawall wrote: > > On Wed, 18 Apr 2018, Joe Perches wrote:

Re: [RFC PATCH ghak32 V2 06/13] audit: add support for non-syscall auxiliary records

On 2018-04-18 20:39, Paul Moore wrote: > On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: > > Standalone audit records have the timestamp and serial number generated > > on the fly and as such are unique, making them standalone. This new > > function

Re: [RFC PATCH ghak32 V2 06/13] audit: add support for non-syscall auxiliary records

On 2018-04-18 20:39, Paul Moore wrote: > On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: > > Standalone audit records have the timestamp and serial number generated > > on the fly and as such are unique, making them standalone. This new > > function audit_alloc_local() generates a

[PATCH] arm64: dts: msm8996: Add modem remoteproc

Add the modem remoteproc node and the child smd-edge in order to be able to boot the modem Hexagon found in MSM8996 based devices. Also extend the tcsr mutex node size, to cover the registers at the end of the block, used for halting the modem subsystem. Signed-off-by: Bjorn Andersson

[PATCH] arm64: dts: msm8996: Add modem remoteproc

Add the modem remoteproc node and the child smd-edge in order to be able to boot the modem Hexagon found in MSM8996 based devices. Also extend the tcsr mutex node size, to cover the registers at the end of the block, used for halting the modem subsystem. Signed-off-by: Bjorn Andersson --- This

[PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework

Attempt to acquire the APCS IPC through the mailbox framework and fall back to the old syscon based approach, to allow us to move away from using the syscon. Reviewed-by: Arun Kumar Neelakantam Signed-off-by: Bjorn Andersson --- Changes since

[PATCH v3] rpmsg: qcom_smd: Access APCS through mailbox framework

Attempt to acquire the APCS IPC through the mailbox framework and fall back to the old syscon based approach, to allow us to move away from using the syscon. Reviewed-by: Arun Kumar Neelakantam Signed-off-by: Bjorn Andersson --- Changes since v2: - Added comment about mbox_send_message()

[GIT] Networking

1) Unbalanced refcounting in TIPC, from Jon Maloy. 2) Only allow TCP_MD5SIG to be set on sockets in close or listen state. Once the connection is established it makes no sense to change this. From Eric Dumazet. 3) Missing attribute validation in neigh_dump_table(), also from Eric

[GIT] Networking

1) Unbalanced refcounting in TIPC, from Jon Maloy. 2) Only allow TCP_MD5SIG to be set on sockets in close or listen state. Once the connection is established it makes no sense to change this. From Eric Dumazet. 3) Missing attribute validation in neigh_dump_table(), also from Eric

[PATCH] serial: imx: enable IMX21_UCR3_RXDMUXSEL for non-dte-mode

Fix a problem introduced with commit e61c38d85b73 ("serial: imx: setup DCEDTE early and ensure DCD and RI irqs to be off") result in non dte-mode imx-uart fail receive data. By add back IMX21_UCR3_RXDMUXSEL the serial port works as expected. Signed-off-by: Chris Ruehl

[PATCH] serial: imx: enable IMX21_UCR3_RXDMUXSEL for non-dte-mode

Fix a problem introduced with commit e61c38d85b73 ("serial: imx: setup DCEDTE early and ensure DCD and RI irqs to be off") result in non dte-mode imx-uart fail receive data. By add back IMX21_UCR3_RXDMUXSEL the serial port works as expected. Signed-off-by: Chris Ruehl ---

[REVIEW][PATCH 16/17] signal/alpha: Replace TRAP_FIXME with TRAP_UNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing to do, and causes problems in interesting ways. For it really is not clear to me if using TRAP_UNK bugcheck or the default case of gentrap is really the best way to handle things. There is certainly enough information

[REVIEW][PATCH 16/17] signal/alpha: Replace TRAP_FIXME with TRAP_UNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing to do, and causes problems in interesting ways. For it really is not clear to me if using TRAP_UNK bugcheck or the default case of gentrap is really the best way to handle things. There is certainly enough information

[REVIEW][PATCH 14/17] signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe

The si_code of 0 (aka SI_USER) has fields si_pid and si_uid not si_addr so it so only by luck would the appropriate fields by copied to userspace by copy_siginfo_to_user. This is just broken and wrong. Make it obvious what is happening by moving the si_code from a parameter of the one call to

[REVIEW][PATCH 14/17] signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe

The si_code of 0 (aka SI_USER) has fields si_pid and si_uid not si_addr so it so only by luck would the appropriate fields by copied to userspace by copy_siginfo_to_user. This is just broken and wrong. Make it obvious what is happening by moving the si_code from a parameter of the one call to

[REVIEW][PATCH 17/17] signal/powerpc: Replace TRAP_FIXME with TRAP_UNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. For use in unknown_exception the recently defined TRAP_UNK semantically is a perfect fit. For use in RunModeException it looks like something more specific than TRAP_UNK

[REVIEW][PATCH 17/17] signal/powerpc: Replace TRAP_FIXME with TRAP_UNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. For use in unknown_exception the recently defined TRAP_UNK semantically is a perfect fit. For use in RunModeException it looks like something more specific than TRAP_UNK

[REVIEW][PATCH 13/17] signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. The newly defined FPE_FLTUNK semantically appears to fit the bill so use it instead. Cc: Paul Mackerras Cc: Kumar Gala Cc:

[REVIEW][PATCH 13/17] signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. The newly defined FPE_FLTUNK semantically appears to fit the bill so use it instead. Cc: Paul Mackerras Cc: Kumar Gala Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc:

[REVIEW][PATCH 11/17] signal/alpha: Replace FPE_FIXME with FPE_FLTUNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. The newly defined FPE_FLTUNK semantically appears to fit the bill so use it instead. Given recent experience in this area odds are it will not break anything. Fixing it

[REVIEW][PATCH 15/17] signal: Add TRAP_UNK si_code for undiagnosted trap exceptions

Both powerpc and alpha have cases where they wronly set si_code to 0 in combination with SIGTRAP and don't mean SI_USER. About half the time this is because the architecture can not report accurately what kind of trap exception triggered the trap exception. The other half the time it looks like

[REVIEW][PATCH 11/17] signal/alpha: Replace FPE_FIXME with FPE_FLTUNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. The newly defined FPE_FLTUNK semantically appears to fit the bill so use it instead. Given recent experience in this area odds are it will not break anything. Fixing it

[REVIEW][PATCH 15/17] signal: Add TRAP_UNK si_code for undiagnosted trap exceptions

Both powerpc and alpha have cases where they wronly set si_code to 0 in combination with SIGTRAP and don't mean SI_USER. About half the time this is because the architecture can not report accurately what kind of trap exception triggered the trap exception. The other half the time it looks like

[REVIEW][PATCH 12/17] signal/ia64: Replace FPE_FIXME with FPE_FLTUNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. The newly defined FPE_FLTUNK semantically appears to fit the bill so use it instead. Given recent experience in this area odds are it will not break anything. Fixing it

[REVIEW][PATCH 12/17] signal/ia64: Replace FPE_FIXME with FPE_FLTUNK

Using an si_code of 0 that aliases with SI_USER is clearly the wrong thing todo, and causes problems in interesting ways. The newly defined FPE_FLTUNK semantically appears to fit the bill so use it instead. Given recent experience in this area odds are it will not break anything. Fixing it

Re: [PATCH v2 net 0/3] virtio: ctrl buffer fixes

From: "Michael S. Tsirkin" Date: Fri, 20 Apr 2018 03:49:19 +0300 > On Thu, Apr 19, 2018 at 04:34:22PM -0400, David Miller wrote: >> From: "Michael S. Tsirkin" >> Date: Thu, 19 Apr 2018 08:30:47 +0300 >> >> > Here are a couple of fixes related to the virtio

Re: [PATCH v2 net 0/3] virtio: ctrl buffer fixes

From: "Michael S. Tsirkin" Date: Fri, 20 Apr 2018 03:49:19 +0300 > On Thu, Apr 19, 2018 at 04:34:22PM -0400, David Miller wrote: >> From: "Michael S. Tsirkin" >> Date: Thu, 19 Apr 2018 08:30:47 +0300 >> >> > Here are a couple of fixes related to the virtio control buffer. >> > Lightly tested

[REVIEW][PATCH 02/17] sparc: fix compat siginfo ABI regression

From: "Dmitry V. Levin" Starting with commit v4.14-rc1~60^2^2~1, a SIGFPE signal sent via kill results to wrong values in si_pid and si_uid fields of compat siginfo_t. This happens due to FPE_FIXME being defined to 0 for sparc, and at the same time siginfo_layout() introduced

[REVIEW][PATCH 02/17] sparc: fix compat siginfo ABI regression

From: "Dmitry V. Levin" Starting with commit v4.14-rc1~60^2^2~1, a SIGFPE signal sent via kill results to wrong values in si_pid and si_uid fields of compat siginfo_t. This happens due to FPE_FIXME being defined to 0 for sparc, and at the same time siginfo_layout() introduced by the same commit

[REVIEW][PATCH 05/17] signal/nds32: Use force_sig(SIGILL) in do_revisn

As originally committed do_revisn would deliver a siginfo for SIGILL with an si_code composed of random stack contents. That makes no sense and is not something userspace can depend on. So simplify the code and just use "force_sig(SIG_ILL, current)" instead. Fixes: 2923f5ea7738 ("nds32:

[REVIEW][PATCH 05/17] signal/nds32: Use force_sig(SIGILL) in do_revisn

As originally committed do_revisn would deliver a siginfo for SIGILL with an si_code composed of random stack contents. That makes no sense and is not something userspace can depend on. So simplify the code and just use "force_sig(SIG_ILL, current)" instead. Fixes: 2923f5ea7738 ("nds32:

Re: [RFC PATCH ghak32 V2 05/13] audit: add containerid support for ptrace and signals

On 2018-04-18 20:32, Paul Moore wrote: > On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: > > Add container ID support to ptrace and signals. In particular, the "op" > > field provides a way to label the auxiliary record to which it is > > associated. > > > >

Re: [RFC PATCH ghak32 V2 05/13] audit: add containerid support for ptrace and signals

On 2018-04-18 20:32, Paul Moore wrote: > On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: > > Add container ID support to ptrace and signals. In particular, the "op" > > field provides a way to label the auxiliary record to which it is > > associated. > > > > Signed-off-by: Richard Guy

Re: [PATCH v2] mmc: sdhci-cadence: fix logically and structurally dead code

2018-04-20 0:59 GMT+09:00 Gustavo A. R. Silva : > Currently, the code block inside the for loop will never execute > more than once, because the function returns inmediately after > the first iteration, hence the execution of the code at the second > iteration is

Re: [PATCH v2] mmc: sdhci-cadence: fix logically and structurally dead code

2018-04-20 0:59 GMT+09:00 Gustavo A. R. Silva : > Currently, the code block inside the for loop will never execute > more than once, because the function returns inmediately after > the first iteration, hence the execution of the code at the second > iteration is structurally dead and, code at

[REVIEW][PATCH 08/17] signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout

After more experience with the cases where no one the si_code of 0 is used both as a signal specific si_code, and as SI_USER it appears that no one cares about the signal specific si_code case and the good solution is to just fix the architectures by using a different si_code. In none of the

[REVIEW][PATCH 08/17] signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout

After more experience with the cases where no one the si_code of 0 is used both as a signal specific si_code, and as SI_USER it appears that no one cares about the signal specific si_code case and the good solution is to just fix the architectures by using a different si_code. In none of the

[REVIEW][PATCH 07/17] signal: Reduce copy_siginfo_to_user to just copy_to_user

Now that every instance of struct siginfo is now initialized it is no longer necessary to copy struct siginfo piece by piece to userspace but instead the entire structure can be copied. As well as making the code simpler and more efficient this means that copy_sinfo_to_user no longer cares which

[REVIEW][PATCH 06/17] signal: Ensure every siginfo we send has all bits initialized

Call clear_siginfo to ensure every stack allocated siginfo is properly initialized before being passed to the signal sending functions. Note: It is not safe to depend on C initializers to initialize struct siginfo on the stack because C is allowed to skip holes when initializing a structure. The

[REVIEW][PATCH 07/17] signal: Reduce copy_siginfo_to_user to just copy_to_user

Now that every instance of struct siginfo is now initialized it is no longer necessary to copy struct siginfo piece by piece to userspace but instead the entire structure can be copied. As well as making the code simpler and more efficient this means that copy_sinfo_to_user no longer cares which

[REVIEW][PATCH 06/17] signal: Ensure every siginfo we send has all bits initialized

Call clear_siginfo to ensure every stack allocated siginfo is properly initialized before being passed to the signal sending functions. Note: It is not safe to depend on C initializers to initialize struct siginfo on the stack because C is allowed to skip holes when initializing a structure. The

[REVIEW][PATCH 10/17] signal: Remove ifdefs for BUS_MCEERR_AR and BUS_MCEERR_AO

With the recent architecture cleanups these si_codes are always defined so there is no need to test for them. Signed-off-by: "Eric W. Biederman" --- fs/signalfd.c | 15 ++- kernel/signal.c | 24 2 files changed, 10 insertions(+), 29

[REVIEW][PATCH 09/17] signal: Remove SEGV_BNDERR ifdefs

After the last round of cleanups to siginfo.h SEGV_BNDERR is defined on all architectures so testing to see if it is defined is unnecessary. Signed-off-by: "Eric W. Biederman" --- kernel/signal.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/kernel/signal.c

[REVIEW][PATCH 10/17] signal: Remove ifdefs for BUS_MCEERR_AR and BUS_MCEERR_AO

With the recent architecture cleanups these si_codes are always defined so there is no need to test for them. Signed-off-by: "Eric W. Biederman" --- fs/signalfd.c | 15 ++- kernel/signal.c | 24 2 files changed, 10 insertions(+), 29 deletions(-) diff

[REVIEW][PATCH 09/17] signal: Remove SEGV_BNDERR ifdefs

After the last round of cleanups to siginfo.h SEGV_BNDERR is defined on all architectures so testing to see if it is defined is unnecessary. Signed-off-by: "Eric W. Biederman" --- kernel/signal.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/kernel/signal.c b/kernel/signal.c index

Re: [PATCH v6] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

On Thu, Apr 19, 2018 at 9:32 AM, Lukasz Majewski wrote: > This commit adds device tree description of Kieback & Peter GmbH > iMX6Q TPC board. > > Signed-off-by: Lukasz Majewski > Reviewed-by: Fabio Estevam > > --- > Changes for v6: > - Add

Re: [PATCH v6] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

On Thu, Apr 19, 2018 at 9:32 AM, Lukasz Majewski wrote: > This commit adds device tree description of Kieback & Peter GmbH > iMX6Q TPC board. > > Signed-off-by: Lukasz Majewski > Reviewed-by: Fabio Estevam > > --- > Changes for v6: > - Add space between // and SPDX > - Replace 'disp0' with

[REVIEW][PATCH 04/17] signal/nds32: Use force_sig in unhandled_interruption and unhandled_exceptions

Neither unhandled_interrupt nor unhandled_exceptions fills in any of the siginfo fields whend sending SIGKILL. Further because it is SIGKILL even if all of the fields were filled out appropriately it would be impossible for the process to read any of the siginfo fields. So simplfy things and

[REVIEW][PATCH 04/17] signal/nds32: Use force_sig in unhandled_interruption and unhandled_exceptions

Neither unhandled_interrupt nor unhandled_exceptions fills in any of the siginfo fields whend sending SIGKILL. Further because it is SIGKILL even if all of the fields were filled out appropriately it would be impossible for the process to read any of the siginfo fields. So simplfy things and

[REVIEW][PATCH 01/17] signal/alpha: Document a conflict with SI_USER for SIGFPE

Setting si_code to 0 is the same as setting si_code to SI_USER. This is the same si_code as SI_USER. Posix and common sense requires that SI_USER not be a signal specific si_code. As such this use of 0 for the si_code is a pretty horribly broken ABI. Cc: Helge Deller Cc:

[REVIEW][PATCH 01/17] signal/alpha: Document a conflict with SI_USER for SIGFPE

Setting si_code to 0 is the same as setting si_code to SI_USER. This is the same si_code as SI_USER. Posix and common sense requires that SI_USER not be a signal specific si_code. As such this use of 0 for the si_code is a pretty horribly broken ABI. Cc: Helge Deller Cc: Richard Henderson

[REVIEW][PATCH 03/17] signal/sh: Use force_sig_fault in hw_breakpoint_handler

The call chain is: breakpoint notify_die hw_breakpoint_exceptions_notify hw_breakpoint_handler So the signal number can only be SIGTRAP. In hw_breakpoint_handler rc is either NOTIFY_STOP or NOTIF_DONE both of which notifier_to_errno converts to 0. So si_errno is 0. Historically

[REVIEW][PATCH 03/17] signal/sh: Use force_sig_fault in hw_breakpoint_handler

The call chain is: breakpoint notify_die hw_breakpoint_exceptions_notify hw_breakpoint_handler So the signal number can only be SIGTRAP. In hw_breakpoint_handler rc is either NOTIFY_STOP or NOTIF_DONE both of which notifier_to_errno converts to 0. So si_errno is 0. Historically

[REVIEW][PATCH 00/17] siginfo bugfixes and cleanups

Mostly this dealing with aliases of SI_USER, that make it impossible for userspace to tell what kind of siginfo it has received. Also in this series is the change to ensure we have siginfo initialized so I can rip out the switch in copy_siginfo_to_user for better performance, and to ensure

[REVIEW][PATCH 00/17] siginfo bugfixes and cleanups

Mostly this dealing with aliases of SI_USER, that make it impossible for userspace to tell what kind of siginfo it has received. Also in this series is the change to ensure we have siginfo initialized so I can rip out the switch in copy_siginfo_to_user for better performance, and to ensure

Re: [PATCH] KVM: X86: Extend MAX_IRQ_ROUTES to 4096

2018-04-19 22:09 GMT+08:00 Cornelia Huck : > On Thu, 19 Apr 2018 13:42:55 + > Wanpeng Li wrote: > >> On Thu, 19 Apr 2018 05:30:40 -0700 >> >> Wanpeng Li wrote: >> >> > From: Wanpeng Li >> > >> > Our

Re: [PATCH] KVM: X86: Extend MAX_IRQ_ROUTES to 4096

2018-04-19 22:09 GMT+08:00 Cornelia Huck : > On Thu, 19 Apr 2018 13:42:55 + > Wanpeng Li wrote: > >> On Thu, 19 Apr 2018 05:30:40 -0700 >> >> Wanpeng Li wrote: >> >> > From: Wanpeng Li >> > >> > Our virtual machines make use of device assignment by configuring >> > 12 NVMe disks for high

Re: [alsa-devel] [PATCH v5 07/23] ASoC: qdsp6: q6afe: Add q6afe driver

Hi Srinivas, I love your patch! Yet something to improve: [auto build test ERROR on asoc/for-next] [also build test ERROR on v4.17-rc1 next-20180419] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [alsa-devel] [PATCH v5 07/23] ASoC: qdsp6: q6afe: Add q6afe driver

Hi Srinivas, I love your patch! Yet something to improve: [auto build test ERROR on asoc/for-next] [also build test ERROR on v4.17-rc1 next-20180419] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH] USB: Increment wakeup count on remote wakeup.

Hi Alan, Thanks for reviewing the change. Appreciate your time. I tried to address your comments in the V2 of the patch. On Thu, Apr 19, 2018 at 8:01 AM, Alan Stern wrote: > On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote: > >> On chromebooks we depend on wakeup

Re: [PATCH] USB: Increment wakeup count on remote wakeup.

Hi Alan, Thanks for reviewing the change. Appreciate your time. I tried to address your comments in the V2 of the patch. On Thu, Apr 19, 2018 at 8:01 AM, Alan Stern wrote: > On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote: > >> On chromebooks we depend on wakeup count to identify the wakeup

Re: [PATCH v2 net 0/3] virtio: ctrl buffer fixes

On Thu, Apr 19, 2018 at 04:34:22PM -0400, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Thu, 19 Apr 2018 08:30:47 +0300 > > > Here are a couple of fixes related to the virtio control buffer. > > Lightly tested on x86 only. > > Thanks for taking care of the control

Re: [PATCH v2 net 0/3] virtio: ctrl buffer fixes

On Thu, Apr 19, 2018 at 04:34:22PM -0400, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Thu, 19 Apr 2018 08:30:47 +0300 > > > Here are a couple of fixes related to the virtio control buffer. > > Lightly tested on x86 only. > > Thanks for taking care of the control buffer DMA'ability

Re: [RFC PATCH ghak32 V2 10/13] audit: add containerid support for seccomp and anom_abend records

On 2018-04-18 21:31, Paul Moore wrote: > On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: > > Add container ID auxiliary records to secure computing and abnormal end > > standalone records. > > > > Signed-off-by: Richard Guy Briggs > > --- > >

[PATCH v2] KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs

From: Wanpeng Li Our virtual machines make use of device assignment by configuring 12 NVMe disks for high I/O performance. Each NVMe device has 129 MSI-X Table entries: Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 offset=2000 The windows

[PATCH v2] KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs

From: Wanpeng Li Our virtual machines make use of device assignment by configuring 12 NVMe disks for high I/O performance. Each NVMe device has 129 MSI-X Table entries: Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 offset=2000 The windows virtual machines fail to

Re: [RFC PATCH ghak32 V2 10/13] audit: add containerid support for seccomp and anom_abend records

On 2018-04-18 21:31, Paul Moore wrote: > On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: > > Add container ID auxiliary records to secure computing and abnormal end > > standalone records. > > > > Signed-off-by: Richard Guy Briggs > > --- > > kernel/auditsc.c | 10 -- > > 1

Re: [pci PATCH v7 0/5] Add support for unmanaged SR-IOV

On Thu, Apr 19, 2018 at 03:54:49PM -0700, Alexander Duyck wrote: > On Thu, Mar 15, 2018 at 11:40 AM, Alexander Duyck > wrote: > > This series is meant to add support for SR-IOV on devices when the VFs are > > not managed by the kernel. Examples of recent patches

Re: [pci PATCH v7 0/5] Add support for unmanaged SR-IOV

On Thu, Apr 19, 2018 at 03:54:49PM -0700, Alexander Duyck wrote: > On Thu, Mar 15, 2018 at 11:40 AM, Alexander Duyck > wrote: > > This series is meant to add support for SR-IOV on devices when the VFs are > > not managed by the kernel. Examples of recent patches attempting to do this > > include:

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

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, Michael S. Tsirkin wrote: > >>

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

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, Michael S. Tsirkin wrote: > >> > On Fri, Mar 16, 2018 at

[PATCH V2] USB: Increment wakeup count on remote wakeup.

On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a

[PATCH V2] USB: Increment wakeup count on remote wakeup.

On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a

<    1   2   3   4   5   6   7   8   9   10   >