linux-kernel - Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5798D299.4090904@linux.intel.com>
Date:	Wed, 27 Jul 2016 08:26:17 -0700
From:	Dave Hansen <dave.hansen@...ux.intel.com>
To:	hejianet <hejianet@...il.com>, linux-mm@...ck.org
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Mike Kravetz <mike.kravetz@...cle.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Michal Hocko <mhocko@...e.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>
Subject: Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

On 07/26/2016 06:39 PM, hejianet wrote:
>>>
>> and you choose to patch both of the alloc_*() functions.  Why not just
>> fix it at the common call site?  Seems like that
>> spin_lock(&hugetlb_lock) could be a cond_resched_lock() which would fix
>> both cases.
> I agree to move the cond_resched() to a common site in 
> set_max_huge_pages(). But do you mean the spin_lock in this while
> loop can be replaced by cond_resched_lock? IIUC, cond_resched_lock =
> spin_unlock+cond_resched+spin_lock. So could you please explain more
> details about it? Thanks.

Ahh, good point.  A plain cond_resched() outside the lock is probably
sufficient here.