[lkml]   [2018]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] mm/hugetlb: make hugetlb_lock irq safe
On Wed, Sep 05, 2018 at 04:53:41PM +0530, Aneesh Kumar K.V wrote:
> inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.

How do you go from "can be taken in softirq context" problem report to
"must disable hard interrupts" solution? Please explain why spin_lock_bh()
is not a sufficient fix.

> swapper/68/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> 0000000052a030a7 (hugetlb_lock){+.?.}, at: free_huge_page+0x9c/0x340
> {SOFTIRQ-ON-W} state was registered at:
> lock_acquire+0xd4/0x230
> _raw_spin_lock+0x44/0x70
> set_max_huge_pages+0x4c/0x360
> hugetlb_sysctl_handler_common+0x108/0x160
> proc_sys_call_handler+0x134/0x190
> __vfs_write+0x3c/0x1f0
> vfs_write+0xd8/0x220

Also, this only seems to trigger here. Is it possible we _already_
have softirqs disabled through every other code path, and it's just this
one sysctl handler that needs to disable softirqs? Rather than every
lock access?

I'm not seeing any analysis in this patch description, just a kneejerk
"lockdep complained, must disable interrupts".

 \ /
  Last update: 2018-09-05 15:05    [W:0.071 / U:8.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site