Re: [PATCH v2] selftests: warn if failure is due to lack of executable bit

On Thu, Aug 03, 2017 at 01:24:36PM -0700, Luis R. Rodriguez wrote: > Executing selftests is fragile as if someone forgot to set a secript > as executable the test will fail, and you won't know for sure if the > failure was caused by the lack of proper permissions or something else. > > Setting

Re: [PATCH v2] selftests: warn if failure is due to lack of executable bit

On Thu, Aug 03, 2017 at 01:24:36PM -0700, Luis R. Rodriguez wrote: > Executing selftests is fragile as if someone forgot to set a secript > as executable the test will fail, and you won't know for sure if the > failure was caused by the lack of proper permissions or something else. > > Setting

Re: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer

Hello, On Mon, Aug 07, 2017 at 01:38:39PM +0200, Michal Hocko wrote: > From: Michal Hocko > > Wenwei Tao has noticed that our current assumption that the oom victim > is dying and never doing any visible changes after it dies, and so the > oom_reaper can tear it down, is not

Re: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer

Hello, On Mon, Aug 07, 2017 at 01:38:39PM +0200, Michal Hocko wrote: > From: Michal Hocko > > Wenwei Tao has noticed that our current assumption that the oom victim > is dying and never doing any visible changes after it dies, and so the > oom_reaper can tear it down, is not entirely true. > >

Re: linux-next: manual merge of the userns tree with the mips tree

Ralf Baechle writes: > On Tue, Aug 08, 2017 at 03:10:04PM +1000, Stephen Rothwell wrote: > > (Maciej added to cc.) > >> Hi Eric, >> >> Today's linux-next merge of the userns tree got a conflict in: >> >> arch/mips/kernel/traps.c >> >> between commit: >> >>

Re: linux-next: manual merge of the userns tree with the mips tree

Ralf Baechle writes: > On Tue, Aug 08, 2017 at 03:10:04PM +1000, Stephen Rothwell wrote: > > (Maciej added to cc.) > >> Hi Eric, >> >> Today's linux-next merge of the userns tree got a conflict in: >> >> arch/mips/kernel/traps.c >> >> between commit: >> >> 260a789828aa ("MIPS: signal:

[PATCH][V2] IB/hns: fix memory leak on ah on error return path

From: Colin Ian King When dmac is NULL, ah is not being freed on the error return path. Fix this by kfree'ing it. Detected by CoverityScan, CID#1452636 ("Resource Leak") Fixes: d8966fcd4c25 ("IB/core: Use rdma_ah_attr accessor functions") Signed-off-by: Colin Ian King

[PATCH][V2] IB/hns: fix memory leak on ah on error return path

From: Colin Ian King When dmac is NULL, ah is not being freed on the error return path. Fix this by kfree'ing it. Detected by CoverityScan, CID#1452636 ("Resource Leak") Fixes: d8966fcd4c25 ("IB/core: Use rdma_ah_attr accessor functions") Signed-off-by: Colin Ian King ---

Re: kernel panic on null pointer on page->mem_cgroup

On Tue, Aug 08, 2017 at 09:56:01AM -0700, Jaegeuk Kim wrote: > On 08/08, Johannes Weiner wrote: > > Hi Jaegeuk and Bradley, > > > > On Mon, Aug 07, 2017 at 09:01:50PM -0400, Bradley Bolen wrote: > > > I am getting a very similar error on v4.11 with an arm64 board. > > > > > > I, too, also see

Re: kernel panic on null pointer on page->mem_cgroup

On Tue, Aug 08, 2017 at 09:56:01AM -0700, Jaegeuk Kim wrote: > On 08/08, Johannes Weiner wrote: > > Hi Jaegeuk and Bradley, > > > > On Mon, Aug 07, 2017 at 09:01:50PM -0400, Bradley Bolen wrote: > > > I am getting a very similar error on v4.11 with an arm64 board. > > > > > > I, too, also see

Re: [PATCH 3/3] ANDROID: binder: fix proc->tsk check.

On Fri, Jul 28, 2017 at 4:56 AM, Martijn Coenen wrote: > Commit c4ea41ba195d ("binder: use group leader instead of open thread")' > was incomplete and didn't update a check in binder_mmap(), causing all > mmap() calls into the binder driver to fail. > > Signed-off-by: Martijn

Re: [PATCH 3/3] ANDROID: binder: fix proc->tsk check.

On Fri, Jul 28, 2017 at 4:56 AM, Martijn Coenen wrote: > Commit c4ea41ba195d ("binder: use group leader instead of open thread")' > was incomplete and didn't update a check in binder_mmap(), causing all > mmap() calls into the binder driver to fail. > > Signed-off-by: Martijn Coenen > --- >

Re: Switching to MQ by default may generate some bug reports

> Il giorno 08 ago 2017, alle ore 10:06, Paolo Valente > ha scritto: > >> >> Il giorno 07 ago 2017, alle ore 20:42, Paolo Valente >> ha scritto: >> >>> >>> Il giorno 07 ago 2017, alle ore 19:32, Paolo Valente >>>

Re: Switching to MQ by default may generate some bug reports

> Il giorno 08 ago 2017, alle ore 10:06, Paolo Valente > ha scritto: > >> >> Il giorno 07 ago 2017, alle ore 20:42, Paolo Valente >> ha scritto: >> >>> >>> Il giorno 07 ago 2017, alle ore 19:32, Paolo Valente >>> ha scritto: >>> Il giorno 05 ago 2017, alle ore 00:05, Paolo

Re: [PATCH] NTB: Rename NTB messaging API methods

On 08/08/17 04:10 AM, Serge Semin wrote: > There is a common methods signature form used over all the NTB API > like functions naming scheme, arguments names and order, etc. > Recently added NTB messaging API IO callbacks were named a bit > different so should be renamed to be in compliance with

Re: [PATCH] NTB: Rename NTB messaging API methods

On 08/08/17 04:10 AM, Serge Semin wrote: > There is a common methods signature form used over all the NTB API > like functions naming scheme, arguments names and order, etc. > Recently added NTB messaging API IO callbacks were named a bit > different so should be renamed to be in compliance with

Re: [PATCH 2/2] sched/debug: intruduce task_state_to_char helper function

Hi Xie, [auto build test ERROR on tip/sched/core] [also build test ERROR on v4.13-rc4 next-20170808] [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/commits/Xie-XiuQi/sched-debug-show-task-state-on-proc

Re: [PATCH 2/2] sched/debug: intruduce task_state_to_char helper function

Hi Xie, [auto build test ERROR on tip/sched/core] [also build test ERROR on v4.13-rc4 next-20170808] [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/commits/Xie-XiuQi/sched-debug-show-task-state-on-proc

Re: [v2 01/12] IB/ocrdma: Use kcalloc() in ocrdma_mbx_alloc_pd_range()

Hello, How will the clarification be continued for the shown change possibilities? Regards, Markus

Re: [v2 01/12] IB/ocrdma: Use kcalloc() in ocrdma_mbx_alloc_pd_range()

Hello, How will the clarification be continued for the shown change possibilities? Regards, Markus

[PATCH 2/3] staging: rtl8188eu: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +- 1 file

[PATCH 0/3] constify staging usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Arvind Yadav (3): [PATCH 1/3] staging: most: usb: constify usb_device_id [PATCH 2/3] staging: rtl8188eu: constify

[PATCH 2/3] staging: rtl8188eu: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 0/3] constify staging usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Arvind Yadav (3): [PATCH 1/3] staging: most: usb: constify usb_device_id [PATCH 2/3] staging: rtl8188eu: constify

[PATCH 1/3] staging: most: usb: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/staging/most/hdm-usb/hdm_usb.c | 2 +- 1 file

[PATCH 3/3] staging: rtl8712: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8712/usb_intf.c | 2 +- 1 file changed,

[PATCH 1/3] staging: most: usb: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/staging/most/hdm-usb/hdm_usb.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 3/3] staging: rtl8712: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8712/usb_intf.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set

If rcu_kick_kthreads is set, and gp is in progress, check_cpu_stall() does checks to figure out whether jiffies is past rsp->jiffies_stall, doing ordered accesses to avoid any false positives for new grace period initialization after a sufficiently large idle period. This extra processing can be

[PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set

If rcu_kick_kthreads is set, and gp is in progress, check_cpu_stall() does checks to figure out whether jiffies is past rsp->jiffies_stall, doing ordered accesses to avoid any false positives for new grace period initialization after a sufficiently large idle period. This extra processing can be

Re: Switching to MQ by default may generate some bug reports

> Il giorno 08 ago 2017, alle ore 12:30, Mel Gorman > ha scritto: > > On Mon, Aug 07, 2017 at 07:32:41PM +0200, Paolo Valente wrote: global-dhp__io-dbench4-fsync-ext4 was a universal loss across any machine tested. This is global-dhp__io-dbench4-fsync

Re: Switching to MQ by default may generate some bug reports

> Il giorno 08 ago 2017, alle ore 12:30, Mel Gorman > ha scritto: > > On Mon, Aug 07, 2017 at 07:32:41PM +0200, Paolo Valente wrote: global-dhp__io-dbench4-fsync-ext4 was a universal loss across any machine tested. This is global-dhp__io-dbench4-fsync from mmtests using ext4 as

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-08-08 12:44 GMT+03:00 Will Deacon : > On Tue, Aug 08, 2017 at 12:29:50PM +0300, Dmitry Safonov wrote: >> 2017-08-02 19:04 GMT+03:00 Will Deacon : >> > On Fri, Jul 28, 2017 at 10:06:20PM +0300, Dmitry Safonov wrote: >> >> 2017-07-28 19:48 GMT+03:00

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-08-08 12:44 GMT+03:00 Will Deacon : > On Tue, Aug 08, 2017 at 12:29:50PM +0300, Dmitry Safonov wrote: >> 2017-08-02 19:04 GMT+03:00 Will Deacon : >> > On Fri, Jul 28, 2017 at 10:06:20PM +0300, Dmitry Safonov wrote: >> >> 2017-07-28 19:48 GMT+03:00 Will Deacon : >> >> > On Wed, Jul 26, 2017 at

Re: kernel BUG at kernel/futex.c:679 on v4.13-rc3-ish on arm64

On Tue, Aug 08, 2017 at 05:44:22PM +0100, Mel Gorman wrote: > On Tue, Aug 08, 2017 at 09:06:48AM -0700, Linus Torvalds wrote: > > On Tue, Aug 8, 2017 at 8:41 AM, Mark Rutland wrote: > > > > > > With my __BUG_FLAGS() issue corrected, the WARN_ON_ONCE() fires once, > > > and

Re: kernel BUG at kernel/futex.c:679 on v4.13-rc3-ish on arm64

On Tue, Aug 08, 2017 at 05:44:22PM +0100, Mel Gorman wrote: > On Tue, Aug 08, 2017 at 09:06:48AM -0700, Linus Torvalds wrote: > > On Tue, Aug 8, 2017 at 8:41 AM, Mark Rutland wrote: > > > > > > With my __BUG_FLAGS() issue corrected, the WARN_ON_ONCE() fires once, > > > and everything else seems

Re: [PATCH V3 net-next 03/21] net-next/hinic: Initialize api cmd resources

From: Aviad Krawczyk Date: Tue, 8 Aug 2017 19:23:32 +0300 > Is it a new rule? It's at least 10 years old. > We can fix it, but I can look over the Linux Kernel source and there are > a lot of examples that have the same problem. Stop right there. Just because there

Re: [PATCH V3 net-next 03/21] net-next/hinic: Initialize api cmd resources

From: Aviad Krawczyk Date: Tue, 8 Aug 2017 19:23:32 +0300 > Is it a new rule? It's at least 10 years old. > We can fix it, but I can look over the Linux Kernel source and there are > a lot of examples that have the same problem. Stop right there. Just because there is code in the kernel with

Re: kernel panic on null pointer on page->mem_cgroup

On 08/08, Johannes Weiner wrote: > Hi Jaegeuk and Bradley, > > On Mon, Aug 07, 2017 at 09:01:50PM -0400, Bradley Bolen wrote: > > I am getting a very similar error on v4.11 with an arm64 board. > > > > I, too, also see page->mem_cgroup checked to make sure that it is not > > NULL and then

Re: kernel panic on null pointer on page->mem_cgroup

On 08/08, Johannes Weiner wrote: > Hi Jaegeuk and Bradley, > > On Mon, Aug 07, 2017 at 09:01:50PM -0400, Bradley Bolen wrote: > > I am getting a very similar error on v4.11 with an arm64 board. > > > > I, too, also see page->mem_cgroup checked to make sure that it is not > > NULL and then

[PATCH] Input: ati_remote2: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/input/misc/ati_remote2.c | 2 +- 1 file changed, 1

[PATCH] Input: ati_remote2: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/input/misc/ati_remote2.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > If the use case is fairly specific, then perhaps it makes sense to > > make MADV_WIPEONFORK not applicable (EINVAL) for mappings where the > > result is 'questionable'. > >

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > If the use case is fairly specific, then perhaps it makes sense to > > make MADV_WIPEONFORK not applicable (EINVAL) for mappings where the > > result is 'questionable'. > >

Re: blk-mq breaks suspend even with runtime PM patch

On Tue, 2017-08-08 at 09:44 -0700, Greg KH wrote: > > Should these go back farther than 4.12? Looks like they apply cleanly > to 4.9, didn't look older than that... I met prerequisites at 4.11, but I wasn't patching anything remotely resembling virgin source. -Mike

Re: blk-mq breaks suspend even with runtime PM patch

On Tue, 2017-08-08 at 09:44 -0700, Greg KH wrote: > > Should these go back farther than 4.12? Looks like they apply cleanly > to 4.9, didn't look older than that... I met prerequisites at 4.11, but I wasn't patching anything remotely resembling virgin source. -Mike

[PATCH] isdn: hisax: hfc_usb: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/isdn/hisax/hfc_usb.c | 2 +- 1 file changed, 1

[PATCH] isdn: hisax: hfc_usb: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/isdn/hisax/hfc_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] isdn: hfcsusb: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/isdn/hardware/mISDN/hfcsusb.h | 2 +- 1 file

[PATCH] isdn: hfcsusb: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/isdn/hardware/mISDN/hfcsusb.h | 2 +- 1 file changed, 1 insertion(+), 1

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

From: Daniel Borkmann Date: Tue, 08 Aug 2017 10:46:52 +0200 > On 08/08/2017 12:25 AM, James Hogan wrote: >> In bpf_trace_printk(), the elements in mod[] are left uninitialised, >> but >> they are then incremented to track the width of the formats. Zero >> initialise the

Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk

From: Daniel Borkmann Date: Tue, 08 Aug 2017 10:46:52 +0200 > On 08/08/2017 12:25 AM, James Hogan wrote: >> In bpf_trace_printk(), the elements in mod[] are left uninitialised, >> but >> they are then incremented to track the width of the formats. Zero >> initialise the array just in case the

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, Aug 8, 2017 at 5:46 PM, Rik van Riel wrote: >> If the use case is fairly specific, then perhaps it makes sense to >> make MADV_WIPEONFORK not applicable (EINVAL) for mappings where the >> result is 'questionable'. > > That would be a question for Florian and Colm. > > If

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, Aug 8, 2017 at 5:46 PM, Rik van Riel wrote: >> If the use case is fairly specific, then perhaps it makes sense to >> make MADV_WIPEONFORK not applicable (EINVAL) for mappings where the >> result is 'questionable'. > > That would be a question for Florian and Colm. > > If they are OK with

Re: blk-mq breaks suspend even with runtime PM patch

Greg, this is 765e40b675a9566459ddcb8358ad16f3b8344bbe. On úterý 8. srpna 2017 18:43:33 CEST Greg KH wrote: > On Tue, Aug 08, 2017 at 06:36:01PM +0200, Oleksandr Natalenko wrote: > > Could you queue "block: disable runtime-pm for blk-mq" too please? It is > > also related to suspend-resume

Re: blk-mq breaks suspend even with runtime PM patch

Greg, this is 765e40b675a9566459ddcb8358ad16f3b8344bbe. On úterý 8. srpna 2017 18:43:33 CEST Greg KH wrote: > On Tue, Aug 08, 2017 at 06:36:01PM +0200, Oleksandr Natalenko wrote: > > Could you queue "block: disable runtime-pm for blk-mq" too please? It is > > also related to suspend-resume

Re: kernel BUG at kernel/futex.c:679 on v4.13-rc3-ish on arm64

On Tue, Aug 08, 2017 at 09:06:48AM -0700, Linus Torvalds wrote: > On Tue, Aug 8, 2017 at 8:41 AM, Mark Rutland wrote: > > > > With my __BUG_FLAGS() issue corrected, the WARN_ON_ONCE() fires once, > > and everything else seems fine. I'll have a go with additional debug > >

Re: kernel BUG at kernel/futex.c:679 on v4.13-rc3-ish on arm64

On Tue, Aug 08, 2017 at 09:06:48AM -0700, Linus Torvalds wrote: > On Tue, Aug 8, 2017 at 8:41 AM, Mark Rutland wrote: > > > > With my __BUG_FLAGS() issue corrected, the WARN_ON_ONCE() fires once, > > and everything else seems fine. I'll have a go with additional debug > > enabled just in case. >

Re: blk-mq breaks suspend even with runtime PM patch

On Tue, Aug 08, 2017 at 06:34:01PM +0200, Mike Galbraith wrote: > On Tue, 2017-08-08 at 09:22 -0700, Greg KH wrote: > > On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote: > > > Hello Mike et al. > > > > > > On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote: > > > >

Re: blk-mq breaks suspend even with runtime PM patch

On Tue, Aug 08, 2017 at 06:34:01PM +0200, Mike Galbraith wrote: > On Tue, 2017-08-08 at 09:22 -0700, Greg KH wrote: > > On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote: > > > Hello Mike et al. > > > > > > On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote: > > > >

Re: blk-mq breaks suspend even with runtime PM patch

On Tue, Aug 08, 2017 at 06:36:01PM +0200, Oleksandr Natalenko wrote: > Could you queue "block: disable runtime-pm for blk-mq" too please? It is also > related to suspend-resume freezes that were observed by multiple users. What is the git commit id of that patch? thanks, greg k-h

Re: blk-mq breaks suspend even with runtime PM patch

On Tue, Aug 08, 2017 at 06:36:01PM +0200, Oleksandr Natalenko wrote: > Could you queue "block: disable runtime-pm for blk-mq" too please? It is also > related to suspend-resume freezes that were observed by multiple users. What is the git commit id of that patch? thanks, greg k-h

Re: [PATCH net] rds: Reintroduce statistics counting

On 8/8/2017 2:13 AM, Håkon Bugge wrote: In commit 7e3f2952eeb1 ("rds: don't let RDS shutdown a connection while senders are present"), refilling the receive queue was removed from rds_ib_recv(), along with the increment of s_ib_rx_refill_from_thread. Commit 73ce4317bf98 ("RDS: make sure we post

Re: [PATCH net] rds: Reintroduce statistics counting

On 8/8/2017 2:13 AM, Håkon Bugge wrote: In commit 7e3f2952eeb1 ("rds: don't let RDS shutdown a connection while senders are present"), refilling the receive queue was removed from rds_ib_recv(), along with the increment of s_ib_rx_refill_from_thread. Commit 73ce4317bf98 ("RDS: make sure we post

[PATCH] lib: Add test module for CONFIG_DEBUG_VIRTUAL

Add a test module that allows testing that CONFIG_DEBUG_VIRTUAL works correctly, at least that it can catch invalid calls to virt_to_phys() against the non-linear kernel virtual address map. Signed-off-by: Florian Fainelli --- lib/Kconfig.debug| 11 +++

[PATCH] lib: Add test module for CONFIG_DEBUG_VIRTUAL

Add a test module that allows testing that CONFIG_DEBUG_VIRTUAL works correctly, at least that it can catch invalid calls to virt_to_phys() against the non-linear kernel virtual address map. Signed-off-by: Florian Fainelli --- lib/Kconfig.debug| 11 +++ lib/Makefile

Re: blk-mq breaks suspend even with runtime PM patch

Could you queue "block: disable runtime-pm for blk-mq" too please? It is also related to suspend-resume freezes that were observed by multiple users. Thanks. On úterý 8. srpna 2017 18:33:29 CEST Jens Axboe wrote: > On 08/08/2017 10:22 AM, Greg KH wrote: > > On Sun, Jul 30, 2017 at 03:50:15PM

Re: blk-mq breaks suspend even with runtime PM patch

Could you queue "block: disable runtime-pm for blk-mq" too please? It is also related to suspend-resume freezes that were observed by multiple users. Thanks. On úterý 8. srpna 2017 18:33:29 CEST Jens Axboe wrote: > On 08/08/2017 10:22 AM, Greg KH wrote: > > On Sun, Jul 30, 2017 at 03:50:15PM

Re: xfs: use kmem_free to free return value of kmem_zalloc

On Tue, Aug 08, 2017 at 08:17:57PM +0800, Pan Bian wrote: > In function xfs_test_remount_options(), kfree() is used to free memory > allocated by kmem_zalloc(). But it is better to use kmem_free(). Looks fine (for 4.14), Reviewed-by: Darrick J. Wong > Signed-off-by: Pan

Re: xfs: use kmem_free to free return value of kmem_zalloc

On Tue, Aug 08, 2017 at 08:17:57PM +0800, Pan Bian wrote: > In function xfs_test_remount_options(), kfree() is used to free memory > allocated by kmem_zalloc(). But it is better to use kmem_free(). Looks fine (for 4.14), Reviewed-by: Darrick J. Wong > Signed-off-by: Pan Bian > --- >

Re: blk-mq breaks suspend even with runtime PM patch

On Tue, 2017-08-08 at 09:22 -0700, Greg KH wrote: > On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote: > > Hello Mike et al. > > > > On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote: > > > FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if > > >

Re: blk-mq breaks suspend even with runtime PM patch

On Tue, 2017-08-08 at 09:22 -0700, Greg KH wrote: > On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote: > > Hello Mike et al. > > > > On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote: > > > FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if > > >

Re: blk-mq breaks suspend even with runtime PM patch

On 08/08/2017 10:22 AM, Greg KH wrote: > On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote: >> Hello Mike et al. >> >> On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote: >>> FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if >>> stable fixed it. >>

Re: blk-mq breaks suspend even with runtime PM patch

On 08/08/2017 10:22 AM, Greg KH wrote: > On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote: >> Hello Mike et al. >> >> On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote: >>> FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if >>> stable fixed it. >>

Re: [PATCH v3 41/49] xfs: convert to bio_for_each_segment_all_sp()

On Tue, Aug 08, 2017 at 04:45:40PM +0800, Ming Lei wrote: Sure would be nice to have a changelog explaining why we're doing this. > Cc: "Darrick J. Wong" > Cc: linux-...@vger.kernel.org > Signed-off-by: Ming Lei > --- > fs/xfs/xfs_aops.c | 3 ++- >

Re: [PATCH v3 41/49] xfs: convert to bio_for_each_segment_all_sp()

On Tue, Aug 08, 2017 at 04:45:40PM +0800, Ming Lei wrote: Sure would be nice to have a changelog explaining why we're doing this. > Cc: "Darrick J. Wong" > Cc: linux-...@vger.kernel.org > Signed-off-by: Ming Lei > --- > fs/xfs/xfs_aops.c | 3 ++- > 1 file changed, 2 insertions(+), 1

Re: [PATCH] acpi: apei: fix GHES estatus iteration

On Thu, Aug 03, 2017 at 03:32:25PM -0600, Tyler Baicar wrote: > Currently iterating through the GHES estatus blocks does not > take into account the new generic data v3 structure size. This > can result in garbage non-standard trace events to be triggered > since the loop will not properly iterate

Re: [PATCH] acpi: apei: fix GHES estatus iteration

On Thu, Aug 03, 2017 at 03:32:25PM -0600, Tyler Baicar wrote: > Currently iterating through the GHES estatus blocks does not > take into account the new generic data v3 structure size. This > can result in garbage non-standard trace events to be triggered > since the loop will not properly iterate

Re: [PATCH 4.4 17/91] drm: rcar-du: Simplify and fix probe error handling

On Mon, Aug 07, 2017 at 04:17:58PM +0100, Ben Hutchings wrote: > On Fri, 2017-08-04 at 16:15 -0700, Greg Kroah-Hartman wrote: > [...] > > @@ -291,6 +290,15 @@ static int rcar_du_probe(struct platform > > rcdu->dev = >dev; > > rcdu->info = of_match_device(rcar_du_of_table, rcdu->dev)->data;

Re: [PATCH 4.4 17/91] drm: rcar-du: Simplify and fix probe error handling

On Mon, Aug 07, 2017 at 04:17:58PM +0100, Ben Hutchings wrote: > On Fri, 2017-08-04 at 16:15 -0700, Greg Kroah-Hartman wrote: > [...] > > @@ -291,6 +290,15 @@ static int rcar_du_probe(struct platform > > rcdu->dev = >dev; > > rcdu->info = of_match_device(rcar_du_of_table, rcdu->dev)->data;

[PATCH] random: fix warning message on ia64 and parisc

Fix the warning message on the parisc and IA64 architectures to show the correct function name of the caller by using %pS instead of %pF. The message is printed with the value of _RET_IP_ which calls __builtin_return_address(0) and as such returns the IP address caller instead of pointer to a

[PATCH] random: fix warning message on ia64 and parisc

Fix the warning message on the parisc and IA64 architectures to show the correct function name of the caller by using %pS instead of %pF. The message is printed with the value of _RET_IP_ which calls __builtin_return_address(0) and as such returns the IP address caller instead of pointer to a

Re: [PATCH] KVM: arm64: add esr_el2 and far_el2 to sysreg

Hi gengdongjiu, On 07/08/17 18:43, gengdongjiu wrote: > Another question, For the SEI, I want to also use SIGBUS both for the KVM > user and non-kvm user, > if SEA and SEI Error all use the SIGBUS to notify user space(Qemu), User-space shouldn't necessarily be notified about Synchronous

Re: [PATCH] KVM: arm64: add esr_el2 and far_el2 to sysreg

Hi gengdongjiu, On 07/08/17 18:43, gengdongjiu wrote: > Another question, For the SEI, I want to also use SIGBUS both for the KVM > user and non-kvm user, > if SEA and SEI Error all use the SIGBUS to notify user space(Qemu), User-space shouldn't necessarily be notified about Synchronous

Re: firmware: vpd: use memunmap instead of iounmap

Hi Pan, On Tue, Aug 8, 2017 at 5:45 AM, Pan Bian wrote: > In functions vpd_sections_init() and vpd_section_init(), iounmap() is > used to unmap memory. However, in these cases, memunmap() is better. > > Signed-off-by: Pan Bian > --- >

Re: firmware: vpd: use memunmap instead of iounmap

Hi Pan, On Tue, Aug 8, 2017 at 5:45 AM, Pan Bian wrote: > In functions vpd_sections_init() and vpd_section_init(), iounmap() is > used to unmap memory. However, in these cases, memunmap() is better. > > Signed-off-by: Pan Bian > --- > drivers/firmware/google/vpd.c | 6 +++--- > 1 file changed,

Re: [PATCH V3 net-next 03/21] net-next/hinic: Initialize api cmd resources

Hi David, Is it a new rule? We can fix it, but I can look over the Linux Kernel source and there are a lot of examples that have the same problem. I can see even code that inserted to 4.10 with the same problem. Thanks for your time and review, Aviad On 8/4/2017 1:35 AM, David Miller wrote: >

Re: [PATCH V3 net-next 03/21] net-next/hinic: Initialize api cmd resources

Hi David, Is it a new rule? We can fix it, but I can look over the Linux Kernel source and there are a lot of examples that have the same problem. I can see even code that inserted to 4.10 with the same problem. Thanks for your time and review, Aviad On 8/4/2017 1:35 AM, David Miller wrote: >

Re: blk-mq breaks suspend even with runtime PM patch

On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote: > Hello Mike et al. > > On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote: > > FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if > > stable fixed it. > > My build already includes v4.12.4. > > >

Re: blk-mq breaks suspend even with runtime PM patch

On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote: > Hello Mike et al. > > On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote: > > FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if > > stable fixed it. > > My build already includes v4.12.4. > > >

Re: kernel panic on null pointer on page->mem_cgroup

Hi Jaegeuk and Bradley, On Mon, Aug 07, 2017 at 09:01:50PM -0400, Bradley Bolen wrote: > I am getting a very similar error on v4.11 with an arm64 board. > > I, too, also see page->mem_cgroup checked to make sure that it is not > NULL and then several instructions later it is NULL. It does

Re: kernel panic on null pointer on page->mem_cgroup

Hi Jaegeuk and Bradley, On Mon, Aug 07, 2017 at 09:01:50PM -0400, Bradley Bolen wrote: > I am getting a very similar error on v4.11 with an arm64 board. > > I, too, also see page->mem_cgroup checked to make sure that it is not > NULL and then several instructions later it is NULL. It does

Question about via-ircc.ko

Hello. While searching for races in the Linux kernel I've come across "drivers/net/irda/via-ircc.ko" module. Here are questions that I came up with while analyzing results. Lines are given using the info from Linux v4.12. Consider the following case: Thread 1:Thread 2:

Question about via-ircc.ko

Hello. While searching for races in the Linux kernel I've come across "drivers/net/irda/via-ircc.ko" module. Here are questions that I came up with while analyzing results. Lines are given using the info from Linux v4.12. Consider the following case: Thread 1:Thread 2:

Re: [PATCH v3 03/13] mpt3sas: SGL to PRP Translation for I/Os to NVMe devices

Suganath, > + /* > + ** Below code detects gaps/holes in IO data buffers. > + ** What does holes/gaps mean? > + ** Any SGE except first one in a SGL starts at non NVME page size > + ** aligned address OR Any SGE except last one in a SGL ends at > + ** non NVME page

Re: [PATCH v3 03/13] mpt3sas: SGL to PRP Translation for I/Os to NVMe devices

Suganath, > + /* > + ** Below code detects gaps/holes in IO data buffers. > + ** What does holes/gaps mean? > + ** Any SGE except first one in a SGL starts at non NVME page size > + ** aligned address OR Any SGE except last one in a SGL ends at > + ** non NVME page

[PATCH 04/35] net: irda: irda-usb: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/irda/irda-usb.c | 2 +- 1 file changed, 1

[PATCH 04/35] net: irda: irda-usb: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/irda/irda-usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 05/35] net: irda: kingsun: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/irda/kingsun-sir.c | 2 +- 1 file changed, 1

[PATCH 05/35] net: irda: kingsun: constify usb_device_id

usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by work with const usb_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/irda/kingsun-sir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

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