[PATCH 2/8] fs/aio: Use RCU accessors for kioctx_table->table[]

it and access may race. Mark kioctx_table->table[] with __rcu and use the approriate RCU accessors when using the field. Signed-off-by: Tejun Heo Reported-by: Jann Horn Fixes: db446a08c23d ("aio: convert the ioctx list to table lookup v3") Cc: Benjamin LaHaise Cc: Linus Torvalds

[PATCH 1/8] fs/aio: Add explicit RCU grace period when freeing kioctx

This can lead to kioctx being freed while RCU read protected dereferences are still in progress. Fix it by updating free_ioctx() to go through call_rcu() explicitly. v2: Comment added to explain double bouncing. Signed-off-by: Tejun Heo <t...@kernel.org> Reported-by: Jann Horn <ja..

[PATCH 1/8] fs/aio: Add explicit RCU grace period when freeing kioctx

This can lead to kioctx being freed while RCU read protected dereferences are still in progress. Fix it by updating free_ioctx() to go through call_rcu() explicitly. v2: Comment added to explain double bouncing. Signed-off-by: Tejun Heo Reported-by: Jann Horn Fixes: e34ecee2ae79 ("aio: Fix

[PATCHSET v2] percpu_ref, RCU: Audit RCU usages in percpu_ref users

Hello, Linus, if you want to pick up the first three fix patches, please pull from the following branch. git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git percpu_ref-rcu-audit-fixes Changes from v1[L] are * blk_queue_enter() patch dropped. Needs further investigation. *

[PATCHSET v2] percpu_ref, RCU: Audit RCU usages in percpu_ref users

Hello, Linus, if you want to pick up the first three fix patches, please pull from the following branch. git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git percpu_ref-rcu-audit-fixes Changes from v1[L] are * blk_queue_enter() patch dropped. Needs further investigation. *

Re: [PATCH 26/47] ata: remove bf54x driver

On Wed, Mar 14, 2018 at 04:35:39PM +0100, Arnd Bergmann wrote: > The blackfin architecture is getting removed, so this driver > is obsolete as well. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Tejun Heo <t...@kernel.org> Please feel free to route wit

Re: [PATCH 26/47] ata: remove bf54x driver

On Wed, Mar 14, 2018 at 04:35:39PM +0100, Arnd Bergmann wrote: > The blackfin architecture is getting removed, so this driver > is obsolete as well. > > Signed-off-by: Arnd Bergmann Acked-by: Tejun Heo Please feel free to route with the rest of the series. Thanks. -- tejun

Re: blk_mq_freeze_queue hang and possible race in percpu-refcount

Hello, David. On Tue, Mar 13, 2018 at 03:50:47PM -0700, David Chen wrote: > > CPU A CPU B > - - > percpu_ref_kill() percpu_ref_tryget_live() > { > if (__ref_is_percpu()) > set

Re: blk_mq_freeze_queue hang and possible race in percpu-refcount

Hello, David. On Tue, Mar 13, 2018 at 03:50:47PM -0700, David Chen wrote: > > CPU A CPU B > - - > percpu_ref_kill() percpu_ref_tryget_live() > { > if (__ref_is_percpu()) > set

Re: [PATCH] percpu: Allow to kill tasks doing pcpu_alloc() and waiting for pcpu_balance_workfn()

On Wed, Mar 14, 2018 at 02:51:48PM +0300, Kirill Tkhai wrote: > In case of memory deficit and low percpu memory pages, > pcpu_balance_workfn() takes pcpu_alloc_mutex for a long > time (as it makes memory allocations itself and waits > for memory reclaim). If tasks doing pcpu_alloc() are > choosen

Re: [PATCH] percpu: Allow to kill tasks doing pcpu_alloc() and waiting for pcpu_balance_workfn()

On Wed, Mar 14, 2018 at 02:51:48PM +0300, Kirill Tkhai wrote: > In case of memory deficit and low percpu memory pages, > pcpu_balance_workfn() takes pcpu_alloc_mutex for a long > time (as it makes memory allocations itself and waits > for memory reclaim). If tasks doing pcpu_alloc() are > choosen

Re: [PATCH] libata: add refcounting to ata_host

hat ata_host lives long enough. > > Bug report: https://lkml.org/lkml/2017/11/1/945 > Fixes: 9a6d6a2ddabb ("ata: make ata port as parent device of scsi host") > Cc: Tejun Heo <t...@kernel.org> > Cc: Lin Ming <min...@gmail.com> > Cc: linux-...@vger.kernel

Re: [PATCH] libata: add refcounting to ata_host

hat ata_host lives long enough. > > Bug report: https://lkml.org/lkml/2017/11/1/945 > Fixes: 9a6d6a2ddabb ("ata: make ata port as parent device of scsi host") > Cc: Tejun Heo > Cc: Lin Ming > Cc: linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Taras Kondratiuk Applied to libata/for-4.17. Thanks. -- tejun

Re: [PATCH v2] workqueue: use put_device() instead of kfree()

On Tue, Mar 06, 2018 at 03:35:43PM +0530, Arvind Yadav wrote: > Never directly free @dev after calling device_register(), even > if it returned an error! Always use put_device() to give up the > reference initialized in this function instead. > > Signed-off-by: Arvind Yadav

Re: [PATCH v2] workqueue: use put_device() instead of kfree()

On Tue, Mar 06, 2018 at 03:35:43PM +0530, Arvind Yadav wrote: > Never directly free @dev after calling device_register(), even > if it returned an error! Always use put_device() to give up the > reference initialized in this function instead. > > Signed-off-by: Arvind Yadav Applied to

Re: [PATCH 7/7] RCU, workqueue: Implement rcu_work

Hello, On Thu, Mar 08, 2018 at 08:29:53AM +0800, Lai Jiangshan wrote: > I mentioned a subtle use case that user would think it is supported > since the comment doesn't disallow it. > > It is clear that the user expects >the work must be called at least once after the API returns >the

Re: [PATCH 7/7] RCU, workqueue: Implement rcu_work

Hello, On Thu, Mar 08, 2018 at 08:29:53AM +0800, Lai Jiangshan wrote: > I mentioned a subtle use case that user would think it is supported > since the comment doesn't disallow it. > > It is clear that the user expects >the work must be called at least once after the API returns >the

Re: [PATCH 7/7] RCU, workqueue: Implement rcu_work

Hello, Linus. On Tue, Mar 06, 2018 at 10:30:29AM -0800, Linus Torvalds wrote: > - can we split this patch up, so that if somebody bisects a problem > to it, we'll see if it's cgroup or aio that triggers it? Will do. > So I'd like to either just make the thing always just use >

Re: [PATCH 7/7] RCU, workqueue: Implement rcu_work

Hello, Linus. On Tue, Mar 06, 2018 at 10:30:29AM -0800, Linus Torvalds wrote: > - can we split this patch up, so that if somebody bisects a problem > to it, we'll see if it's cgroup or aio that triggers it? Will do. > So I'd like to either just make the thing always just use >

[PATCH 7/7] RCU, workqueue: Implement rcu_work

period, and converts the open coded bouncing in fs/aio and kernel/cgroup. v2: Use rcu_barrier() instead of synchronize_rcu() to wait for completion of previously queued rcu callback as per Paul. Signed-off-by: Tejun Heo <t...@kernel.org> Cc: "Paul E. McKenney" <paul...@lin

[PATCH 7/7] RCU, workqueue: Implement rcu_work

period, and converts the open coded bouncing in fs/aio and kernel/cgroup. v2: Use rcu_barrier() instead of synchronize_rcu() to wait for completion of previously queued rcu callback as per Paul. Signed-off-by: Tejun Heo Cc: "Paul E. McKenney" Cc: Linus Torvalds ---

[PATCH 6/7] percpu_ref: Update doc to dissuade users from depending on internal RCU grace periods

ear that the grace periods are percpu_ref's internal implementation detail and can't be depended upon by the users. Signed-off-by: Tejun Heo <t...@kernel.org> Cc: Kent Overstreet <kent.overstr...@gmail.com> Cc: Linus Torvalds <torva...@linux-foundation.org> --- include/linux/p

[PATCH 6/7] percpu_ref: Update doc to dissuade users from depending on internal RCU grace periods

ear that the grace periods are percpu_ref's internal implementation detail and can't be depended upon by the users. Signed-off-by: Tejun Heo Cc: Kent Overstreet Cc: Linus Torvalds --- include/linux/percpu-refcount.h | 18 -- lib/percpu-refcount.c | 2 ++ 2 files changed,

[PATCH 5/7] block: Remove superflous rcu_read_[un]lock_sched() in blk_queue_enter()

obviously has to guarantee that @q can be dereferenced, and inside the RCU-sched protected area, there's nothing which needs further protection. Let's remove the superflous rcu_read_[un]lock_sched(). Signed-off-by: Tejun Heo <t...@kernel.org> Cc: Bart Van Assche <bart.vanass...@wdc.com&

[PATCH 5/7] block: Remove superflous rcu_read_[un]lock_sched() in blk_queue_enter()

obviously has to guarantee that @q can be dereferenced, and inside the RCU-sched protected area, there's nothing which needs further protection. Let's remove the superflous rcu_read_[un]lock_sched(). Signed-off-by: Tejun Heo Cc: Bart Van Assche Cc: Jens Axboe Cc: Linus Torvalds --- H

[PATCH 4/7] HMM: Remove superflous RCU protection around radix tree lookup

to confusion. Remove the RCU protection and open-code the radix tree lookup. If this needs to become more sophisticated in the future, let's add them back when necessary. Signed-off-by: Tejun Heo <t...@kernel.org> Cc: Jérôme Glisse <jgli...@redhat.com> Cc: linux...@kvack.org Cc: Linus Tor

[PATCH 4/7] HMM: Remove superflous RCU protection around radix tree lookup

to confusion. Remove the RCU protection and open-code the radix tree lookup. If this needs to become more sophisticated in the future, let's add them back when necessary. Signed-off-by: Tejun Heo Cc: Jérôme Glisse Cc: linux...@kvack.org Cc: Linus Torvalds --- Hello, Jérôme. This came up while auditing

[PATCH 3/7] RDMAVT: Fix synchronization around percpu_ref

ess the above issues, this patch removes the the fast exit and adds an explicit synchronize_rcu(). Signed-off-by: Tejun Heo <t...@kernel.org> Cc: Dennis Dalessandro <dennis.dalessan...@intel.com> Cc: Mike Marciniszyn <mike.marcinis...@intel.com> Cc: linux-r...@vger.kernel.org Cc:

[PATCH 3/7] RDMAVT: Fix synchronization around percpu_ref

ess the above issues, this patch removes the the fast exit and adds an explicit synchronize_rcu(). Signed-off-by: Tejun Heo Cc: Dennis Dalessandro Cc: Mike Marciniszyn Cc: linux-r...@vger.kernel.org Cc: Linus Torvalds --- Hello, Dennis, Mike. I don't know RDMA at all and this patch is only compile tes

[PATCH 2/7] fs/aio: Use RCU accessors for kioctx_table->table[]

it and access may race. Mark kioctx_table->table[] with __rcu and use the approriate RCU accessors when using the field. Signed-off-by: Tejun Heo <t...@kernel.org> Reported-by: Jann Horn <ja...@google.com> Fixes: db446a08c23d ("aio: convert the ioctx list to table lookup v3"

[PATCH 2/7] fs/aio: Use RCU accessors for kioctx_table->table[]

it and access may race. Mark kioctx_table->table[] with __rcu and use the approriate RCU accessors when using the field. Signed-off-by: Tejun Heo Reported-by: Jann Horn Fixes: db446a08c23d ("aio: convert the ioctx list to table lookup v3") Cc: Benjamin LaHaise Cc: Linus Torvalds

[PATCH 1/7] fs/aio: Add explicit RCU grace period when freeing kioctx

This can lead to kioctx being freed while RCU read protected dereferences are still in progress. Fix it by updating free_ioctx() to go through call_rcu() explicitly. v2: Comment added to explain double bouncing. Signed-off-by: Tejun Heo <t...@kernel.org> Reported-by: Jann Horn <ja..

[PATCH 1/7] fs/aio: Add explicit RCU grace period when freeing kioctx

This can lead to kioctx being freed while RCU read protected dereferences are still in progress. Fix it by updating free_ioctx() to go through call_rcu() explicitly. v2: Comment added to explain double bouncing. Signed-off-by: Tejun Heo Reported-by: Jann Horn Fixes: e34ecee2ae79 ("aio: Fix

[PATCHSET] percpu_ref, RCU: Audit RCU usages in percpu_ref users

Hello, Jann Horn found that aio was depending on the internal RCU grace periods of percpu-ref and that it's broken because aio uses regular RCU while percpu_ref uses sched-RCU. Depending on percpu_ref's internal grace periods isn't a good idea because * The RCU type might not match. *

[PATCHSET] percpu_ref, RCU: Audit RCU usages in percpu_ref users

Hello, Jann Horn found that aio was depending on the internal RCU grace periods of percpu-ref and that it's broken because aio uses regular RCU while percpu_ref uses sched-RCU. Depending on percpu_ref's internal grace periods isn't a good idea because * The RCU type might not match. *

Re: [PATCH 0/2] ahci/pci-quirks: Add PCI-id for the Highpoint Rocketraid 644L card

On Fri, Mar 02, 2018 at 01:29:07PM -0600, Bjorn Helgaas wrote: > On Fri, Mar 02, 2018 at 11:36:31AM +0100, Hans de Goede wrote: > > Hi All, > > > > Here are 2 patches adding support for Highpoint Rocketraid 644L cards, > > they can be merged independently from each-other into their resp. subsys,

Re: [PATCH 0/2] ahci/pci-quirks: Add PCI-id for the Highpoint Rocketraid 644L card

On Fri, Mar 02, 2018 at 01:29:07PM -0600, Bjorn Helgaas wrote: > On Fri, Mar 02, 2018 at 11:36:31AM +0100, Hans de Goede wrote: > > Hi All, > > > > Here are 2 patches adding support for Highpoint Rocketraid 644L cards, > > they can be merged independently from each-other into their resp. subsys,

Re: [PATCH] pata_bk3710: clarify license version and use SPDX header

On Thu, Mar 01, 2018 at 12:16:00PM +0100, Bartlomiej Zolnierkiewicz wrote: > - clarify license version (it should be GPL 2.0) > - use SPDX header > > Cc: Sekhar Nori > Signed-off-by: Bartlomiej Zolnierkiewicz Applied to libata/for-4.17. Thanks. --

Re: [PATCH] pata_bk3710: clarify license version and use SPDX header

On Thu, Mar 01, 2018 at 12:16:00PM +0100, Bartlomiej Zolnierkiewicz wrote: > - clarify license version (it should be GPL 2.0) > - use SPDX header > > Cc: Sekhar Nori > Signed-off-by: Bartlomiej Zolnierkiewicz Applied to libata/for-4.17. Thanks. -- tejun

Re: [PATCH] pata_falcon: clarify license version and use SPDX header

On Thu, Mar 01, 2018 at 12:13:35PM +0100, Bartlomiej Zolnierkiewicz wrote: > - clarify license version (it should be GPL 2.0) > - use SPDX header > > Cc: Michael Schmitz > Cc: Geert Uytterhoeven > Signed-off-by: Bartlomiej Zolnierkiewicz

Re: [PATCH] pata_falcon: clarify license version and use SPDX header

On Thu, Mar 01, 2018 at 12:13:35PM +0100, Bartlomiej Zolnierkiewicz wrote: > - clarify license version (it should be GPL 2.0) > - use SPDX header > > Cc: Michael Schmitz > Cc: Geert Uytterhoeven > Signed-off-by: Bartlomiej Zolnierkiewicz Applied to libata/for-4.17. Thanks. -- tejun

Re: [PATCH] percpu: add a schedule point in pcpu_balance_workfn()

On Fri, Feb 23, 2018 at 08:12:42AM -0800, Eric Dumazet wrote: > From: Eric Dumazet > > When a large BPF percpu map is destroyed, I have seen > pcpu_balance_workfn() holding cpu for hundreds of milliseconds. > > On KASAN config and 112 hyperthreads, average time to destroy a

Re: [PATCH] percpu: add a schedule point in pcpu_balance_workfn()

On Fri, Feb 23, 2018 at 08:12:42AM -0800, Eric Dumazet wrote: > From: Eric Dumazet > > When a large BPF percpu map is destroyed, I have seen > pcpu_balance_workfn() holding cpu for hundreds of milliseconds. > > On KASAN config and 112 hyperthreads, average time to destroy a chunk > is ~4 ms. >

[PATCH cgroup/for-4.16-fixes] cgroup: fix rule checking for threaded mode switching

>From d1897c9538edafd4ae6bbd03cc075962ddde2c21 Mon Sep 17 00:00:00 2001 From: Tejun Heo <t...@kernel.org> Date: Wed, 21 Feb 2018 11:39:22 -0800 A domain cgroup isn't allowed to be turned threaded if its subtree is populated or domain controllers are enabled. cgroup_enable_threaded()

[PATCH cgroup/for-4.16-fixes] cgroup: fix rule checking for threaded mode switching

>From d1897c9538edafd4ae6bbd03cc075962ddde2c21 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Wed, 21 Feb 2018 11:39:22 -0800 A domain cgroup isn't allowed to be turned threaded if its subtree is populated or domain controllers are enabled. cgroup_enable_threaded() depen

Re: A "domain invalid" cgroup *can* sometimes have member tasks

On Tue, Feb 20, 2018 at 11:35:47AM -0800, Tejun Heo wrote: > Hmm... nr_populated_domain_children check should have caught that > condition and rejected it. Will look into what's going on. Ah, okay, I was special-casing the first level children case too early. If you nest the test case

Re: A "domain invalid" cgroup *can* sometimes have member tasks

On Tue, Feb 20, 2018 at 11:35:47AM -0800, Tejun Heo wrote: > Hmm... nr_populated_domain_children check should have caught that > condition and rejected it. Will look into what's going on. Ah, okay, I was special-casing the first level children case too early. If you nest the test case

Re: [PATCH v2] libata: disable LPM for Crucial BX100 SSD 500GB drive

On Sun, Feb 18, 2018 at 10:17:09PM +0800, Kai-Heng Feng wrote: > After Laptop Mode Tools starts to use min_power for LPM, a user found > out Crucial BX100 SSD can't get mounted. > > Crucial BX100 SSD 500GB drive don't work well with min_power. This also > happens to med_power_with_dipm. > > So

Re: [PATCH v2] libata: disable LPM for Crucial BX100 SSD 500GB drive

On Sun, Feb 18, 2018 at 10:17:09PM +0800, Kai-Heng Feng wrote: > After Laptop Mode Tools starts to use min_power for LPM, a user found > out Crucial BX100 SSD can't get mounted. > > Crucial BX100 SSD 500GB drive don't work well with min_power. This also > happens to med_power_with_dipm. > > So

Re: A "domain invalid" cgroup *can* sometimes have member tasks

On Tue, Feb 20, 2018 at 08:26:59PM +0100, Michael Kerrisk (man-pages) wrote: > Hello Tejun > > According to Documentation/cgroup-v2.txt, a "domain invalid" cgroup > can't have member tasks. And indeed this is generally not permitted. > > However, someone recently showed me a scenario where a

Re: A "domain invalid" cgroup *can* sometimes have member tasks

On Tue, Feb 20, 2018 at 08:26:59PM +0100, Michael Kerrisk (man-pages) wrote: > Hello Tejun > > According to Documentation/cgroup-v2.txt, a "domain invalid" cgroup > can't have member tasks. And indeed this is generally not permitted. > > However, someone recently showed me a scenario where a

Re: [PATCH v2 3/3] percpu: allow select gfp to be passed to underlying allocators

On Fri, Feb 16, 2018 at 12:09:58PM -0600, Dennis Zhou wrote: > The prior patch added support for passing gfp flags through to the > underlying allocators. This patch allows users to pass along gfp flags > (currently only __GFP_NORETRY and __GFP_NOWARN) to the underlying > allocators. This should

Re: [PATCH v2 3/3] percpu: allow select gfp to be passed to underlying allocators

On Fri, Feb 16, 2018 at 12:09:58PM -0600, Dennis Zhou wrote: > The prior patch added support for passing gfp flags through to the > underlying allocators. This patch allows users to pass along gfp flags > (currently only __GFP_NORETRY and __GFP_NOWARN) to the underlying > allocators. This should

Re: [PATCH] libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs

On Fri, Feb 16, 2018 at 10:48:20AM +0100, Hans de Goede wrote: > Various people have reported the Crucial MX100 512GB model not working > with LPM set to min_power. I've now received a report that it also does > not work with the new med_power_with_dipm level. > > It does work with medium_power,

Re: [PATCH] libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs

On Fri, Feb 16, 2018 at 10:48:20AM +0100, Hans de Goede wrote: > Various people have reported the Crucial MX100 512GB model not working > with LPM set to min_power. I've now received a report that it also does > not work with the new med_power_with_dipm level. > > It does work with medium_power,

Re: [PATCH 1/2] pata_it821x: Delete an error message for a failed memory allocation in it821x_firmware_command()

On Fri, Feb 16, 2018 at 03:22:18PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 14:04:49 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle

Re: [PATCH 1/2] pata_it821x: Delete an error message for a failed memory allocation in it821x_firmware_command()

On Fri, Feb 16, 2018 at 03:22:18PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 14:04:49 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus

Re: [PATCH 1/3] pata_macio: Delete an error message for a failed memory allocation in two functions

On Fri, Feb 16, 2018 at 01:38:20PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 13:01:45 +0100 > > Omit an extra message for a memory allocation failure in these functions. > > This issue was detected by using the Coccinelle

Re: [PATCH 1/3] pata_macio: Delete an error message for a failed memory allocation in two functions

On Fri, Feb 16, 2018 at 01:38:20PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 13:01:45 +0100 > > Omit an extra message for a memory allocation failure in these functions. > > This issue was detected by using the Coccinelle software. > > Signed-off-by:

Re: [PATCH] pata_mpc52xx: Delete an error message for a failed memory allocation in mpc52xx_ata_probe()

On Fri, Feb 16, 2018 at 11:44:13AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 11:34:53 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle

Re: [PATCH] pata_mpc52xx: Delete an error message for a failed memory allocation in mpc52xx_ata_probe()

On Fri, Feb 16, 2018 at 11:44:13AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 11:34:53 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus

Re: [PATCH] sata_dwc_460ex: Delete an error message for a failed memory allocation in sata_dwc_port_start()

On Fri, Feb 16, 2018 at 11:39:13AM +0200, Andy Shevchenko wrote: > On Thu, 2018-02-15 at 22:22 +0100, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Thu, 15 Feb 2018 22:15:25 +0100 > > > > Omit an extra message for a memory allocation failure in this >

Re: [PATCH] sata_dwc_460ex: Delete an error message for a failed memory allocation in sata_dwc_port_start()

On Fri, Feb 16, 2018 at 11:39:13AM +0200, Andy Shevchenko wrote: > On Thu, 2018-02-15 at 22:22 +0100, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Thu, 15 Feb 2018 22:15:25 +0100 > > > > Omit an extra message for a memory allocation failure in this > > function. > > > > This

Re: [PATCH] pata_samsung_cf: Delete an error message for a failed memory allocation in pata_s3c_probe()

On Fri, Feb 16, 2018 at 11:08:18AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 10:55:51 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle

Re: [PATCH] pata_samsung_cf: Delete an error message for a failed memory allocation in pata_s3c_probe()

On Fri, Feb 16, 2018 at 11:08:18AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 10:55:51 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus

Re: [PATCH 3/3] pata_arasan_cf: Move two variable assignments in arasan_cf_probe()

On Fri, Feb 16, 2018 at 05:00:11PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 16:42:26 +0100 > > Move assignments for the local variables "irq_handler" and "pdata" > so that their setting will only be performed after a call > of

Re: [PATCH 3/3] pata_arasan_cf: Move two variable assignments in arasan_cf_probe()

On Fri, Feb 16, 2018 at 05:00:11PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 16:42:26 +0100 > > Move assignments for the local variables "irq_handler" and "pdata" > so that their setting will only be performed after a call > of the function "devm_kzalloc"

Re: [PATCH 2/3] pata_arasan_cf: Delete an unnecessary variable initialisation in arasan_cf_probe()

On Fri, Feb 16, 2018 at 04:59:01PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 16:28:23 +0100 > > The local variable "ret" will eventually be set to an appropriate value > a bit later. Thus omit the explicit initialisation at the

Re: [PATCH 2/3] pata_arasan_cf: Delete an unnecessary variable initialisation in arasan_cf_probe()

On Fri, Feb 16, 2018 at 04:59:01PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 16:28:23 +0100 > > The local variable "ret" will eventually be set to an appropriate value > a bit later. Thus omit the explicit initialisation at the beginning. > > Signed-off-by:

Re: [PATCH] libata-scsi: Delete an unnecessary variable in ata_scsi_slave_config()

On Fri, Feb 16, 2018 at 06:26:30PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 18:19:13 +0100 > > * Return a result code without storing it in an intermediate variable. > > * Reduce the needed source code. > > Signed-off-by:

Re: [PATCH] libata-scsi: Delete an unnecessary variable in ata_scsi_slave_config()

On Fri, Feb 16, 2018 at 06:26:30PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 16 Feb 2018 18:19:13 +0100 > > * Return a result code without storing it in an intermediate variable. > > * Reduce the needed source code. > > Signed-off-by: Markus Elfring > --- >

Re: [PATCH 3/3] percpu: allow select gfp to be passed to underlying allocators

Hello, On Thu, Feb 15, 2018 at 10:08:16AM -0600, Dennis Zhou wrote: > +/* the whitelisted flags that can be passed to the backing allocators */ > +#define gfp_percpu_mask(gfp) (((gfp) & (__GFP_NORETRY | __GFP_NOWARN)) | \ > + GFP_KERNEL) Isn't there just one place where

Re: [PATCH 3/3] percpu: allow select gfp to be passed to underlying allocators

Hello, On Thu, Feb 15, 2018 at 10:08:16AM -0600, Dennis Zhou wrote: > +/* the whitelisted flags that can be passed to the backing allocators */ > +#define gfp_percpu_mask(gfp) (((gfp) & (__GFP_NORETRY | __GFP_NOWARN)) | \ > + GFP_KERNEL) Isn't there just one place where

Re: [PATCH 2/3] percpu: add __GFP_NORETRY semantics to the percpu balancing path

Hello, On Thu, Feb 15, 2018 at 10:08:15AM -0600, Dennis Zhou wrote: > -static struct pcpu_chunk *pcpu_create_chunk(void) > +static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp) > { > const int nr_pages = pcpu_group_sizes[0] >> PAGE_SHIFT; > struct pcpu_chunk *chunk; > struct

Re: [PATCH 2/3] percpu: add __GFP_NORETRY semantics to the percpu balancing path

Hello, On Thu, Feb 15, 2018 at 10:08:15AM -0600, Dennis Zhou wrote: > -static struct pcpu_chunk *pcpu_create_chunk(void) > +static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp) > { > const int nr_pages = pcpu_group_sizes[0] >> PAGE_SHIFT; > struct pcpu_chunk *chunk; > struct

Re: [PATCH 3/3] percpu: Remove inert tracepoint in __init code

On Wed, Feb 14, 2018 at 10:40:43AM -0600, Josh Poimboeuf wrote: > The jump_label code doesn't patch init code, so this tracepoint can > never be enabled. Remove it. > > Cc: Tejun Heo <t...@kernel.org> > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Applied

Re: [PATCH 3/3] percpu: Remove inert tracepoint in __init code

On Wed, Feb 14, 2018 at 10:40:43AM -0600, Josh Poimboeuf wrote: > The jump_label code doesn't patch init code, so this tracepoint can > never be enabled. Remove it. > > Cc: Tejun Heo > Signed-off-by: Josh Poimboeuf Applied to percpu/for-4.17. Thanks. -- tejun

Re: x86/stack protector: X86_32_LAZY_GS=n hangs kernel on old processors

Hello, (cc'ing lkml as requested) On Tue, Feb 13, 2018 at 11:40:17AM -0500, tedheadster wrote: > in your patch "x86: make lazy %gs optional on x86_32" were you able > to test it on really old processors? In 4.16.0-rc1, X86_32_LAZY_GS got > toggled from 'y' to 'n' in my default config because

Re: x86/stack protector: X86_32_LAZY_GS=n hangs kernel on old processors

Hello, (cc'ing lkml as requested) On Tue, Feb 13, 2018 at 11:40:17AM -0500, tedheadster wrote: > in your patch "x86: make lazy %gs optional on x86_32" were you able > to test it on really old processors? In 4.16.0-rc1, X86_32_LAZY_GS got > toggled from 'y' to 'n' in my default config because

[PATCH] tty: make n_tty_read() always abort if hangup is in progress

printf("Child reading tty\n"); while (1) { char buf[1024]; if (read(fd, buf, sizeof(buf)) < 0) { perror("read"); return 1; } } return 0; } Signed-off-by: Tejun Heo <

[PATCH] tty: make n_tty_read() always abort if hangup is in progress

printf("Child reading tty\n"); while (1) { char buf[1024]; if (read(fd, buf, sizeof(buf)) < 0) { perror("read"); return 1; } } return 0; } Signed-off-by: Tejun Heo

Re: linux-next: build warning after merge of the libata tree

On Tue, Feb 13, 2018 at 02:04:49PM +1100, Stephen Rothwell wrote: > Hi Tejun, > > After merging the libata tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > drivers/ata/sata_rcar.c: In function 'sata_rcar_init_controller': > drivers/ata/sata_rcar.c:821:16:

Re: linux-next: build warning after merge of the libata tree

On Tue, Feb 13, 2018 at 02:04:49PM +1100, Stephen Rothwell wrote: > Hi Tejun, > > After merging the libata tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > drivers/ata/sata_rcar.c: In function 'sata_rcar_init_controller': > drivers/ata/sata_rcar.c:821:16:

Re: [PATCH] libata: update documentation for sysfs interfaces

On Tue, Feb 13, 2018 at 01:48:16PM +0530, Aishwarya Pant wrote: > Dcoumentation has been added by parsing through git commit history and > reading code. This might be useful for scripting and tracking changes in > the ABI. > > I do not have complete descriptions for the following 3 attributes;

Re: [PATCH] libata: update documentation for sysfs interfaces

On Tue, Feb 13, 2018 at 01:48:16PM +0530, Aishwarya Pant wrote: > Dcoumentation has been added by parsing through git commit history and > reading code. This might be useful for scripting and tracking changes in > the ABI. > > I do not have complete descriptions for the following 3 attributes;

Re: [PATCH] libata: transport: cleanup documentation of sysfs interface

On Tue, Feb 13, 2018 at 04:51:59PM +0530, Aishwarya Pant wrote: > Clean-up the documentation of sysfs interfaces to be in the same format > as described in Documentation/ABI/README. This will be useful for > tracking changes in the ABI. Attributes are grouped by function (device, > link or port)

Re: [PATCH] libata: transport: cleanup documentation of sysfs interface

On Tue, Feb 13, 2018 at 04:51:59PM +0530, Aishwarya Pant wrote: > Clean-up the documentation of sysfs interfaces to be in the same format > as described in Documentation/ABI/README. This will be useful for > tracking changes in the ABI. Attributes are grouped by function (device, > link or port)

[PATCH for-4.17] percpu: add Dennis Zhou as a percpu co-maintainer

Dennis rewrote the percpu area allocator some months ago, understands most of the code base and has been responsive with the bug reports and questions. Let's add him as a co-maintainer. Signed-off-by: Tejun Heo <t...@kernel.org> --- Imma apply this to percpu/for-4.17. If there's any obj

[PATCH for-4.17] percpu: add Dennis Zhou as a percpu co-maintainer

Dennis rewrote the percpu area allocator some months ago, understands most of the code base and has been responsive with the bug reports and questions. Let's add him as a co-maintainer. Signed-off-by: Tejun Heo --- Imma apply this to percpu/for-4.17. If there's any objection, please let me

Re: lost connection to test machine (4)

On Mon, Feb 12, 2018 at 09:03:25AM -0800, Tejun Heo wrote: > Hello, Daniel. > > On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote: > > [ +Dennis, +Tejun ] > > > > Looks like we're stuck in percpu allocator with key/value size of 4 bytes > >

Re: lost connection to test machine (4)

On Mon, Feb 12, 2018 at 09:03:25AM -0800, Tejun Heo wrote: > Hello, Daniel. > > On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote: > > [ +Dennis, +Tejun ] > > > > Looks like we're stuck in percpu allocator with key/value size of 4 bytes > >

Re: [PATCH v4.15-rc9] sched, cgroup: Don't reject lower cpu.max on ancestors

On Mon, Jan 22, 2018 at 11:26:18AM -0800, Tejun Heo wrote: > While adding cgroup2 interface for the cpu controller, 0d5936344f30 > ("sched: Implement interface for cgroup unified hierarchy") forgot to > update input validation and left it to reject cpu.max config if any &

Re: [PATCH v4.15-rc9] sched, cgroup: Don't reject lower cpu.max on ancestors

On Mon, Jan 22, 2018 at 11:26:18AM -0800, Tejun Heo wrote: > While adding cgroup2 interface for the cpu controller, 0d5936344f30 > ("sched: Implement interface for cgroup unified hierarchy") forgot to > update input validation and left it to reject cpu.max config if any &

Re: [PATCH] libata: fix length validation of ATAPI-relayed SCSI commands

On Sat, Feb 03, 2018 at 08:30:56PM -0800, Eric Biggers wrote: > From: Eric Biggers > > syzkaller reported a crash in ata_bmdma_fill_sg() when writing to > /dev/sg1. The immediate cause was that the ATA command's scatterlist > was not DMA-mapped, which causes 'pi - 1' to

Re: [PATCH] libata: fix length validation of ATAPI-relayed SCSI commands

On Sat, Feb 03, 2018 at 08:30:56PM -0800, Eric Biggers wrote: > From: Eric Biggers > > syzkaller reported a crash in ata_bmdma_fill_sg() when writing to > /dev/sg1. The immediate cause was that the ATA command's scatterlist > was not DMA-mapped, which causes 'pi - 1' to underflow, resulting in

Re: [PATCH 1/5] workqueue: Allow retrieval of current task's work struct

context of the worker. > > Cc: Tejun Heo <t...@kernel.org> > Cc: Lai Jiangshan <jiangshan...@gmail.com> > Cc: Dave Airlie <airl...@redhat.com> > Cc: Ben Skeggs <bske...@redhat.com> > Cc: Alex Deucher <alexander.deuc...@amd.com> > Signed

Re: [PATCH 1/5] workqueue: Allow retrieval of current task's work struct

context of the worker. > > Cc: Tejun Heo > Cc: Lai Jiangshan > Cc: Dave Airlie > Cc: Ben Skeggs > Cc: Alex Deucher > Signed-off-by: Lukas Wunner I wonder whether it's too generic a name but there are other functions named in a similar fashion and AFAICS current_work isn't u

Re: lost connection to test machine (4)

Hello, Daniel. On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote: > [ +Dennis, +Tejun ] > > Looks like we're stuck in percpu allocator with key/value size of 4 bytes > each and large number of entries (max_entries) in the reproducer in above > link. > > Could we have some

Re: lost connection to test machine (4)

Hello, Daniel. On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote: > [ +Dennis, +Tejun ] > > Looks like we're stuck in percpu allocator with key/value size of 4 bytes > each and large number of entries (max_entries) in the reproducer in above > link. > > Could we have some

Re: [PATCH] Fix compile warning with ATA_DEBUG enabled

On Fri, Jan 26, 2018 at 11:21:49AM +0800, dongbo (E) wrote: > From: Dong Bo > > This fixs the following comile warnings with ATA_DEBUG enabled, > which detected by Linaro GCC 5.2-2015.11: > > In file included from ./include/linux/printk.h:7:0, > from

<    6   7   8   9   10   11   12   13   14   15   >