From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E197EC761A6 for ; Mon, 3 Apr 2023 13:44:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79E836B0071; Mon, 3 Apr 2023 09:44:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 727856B0072; Mon, 3 Apr 2023 09:44:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EFC26B0074; Mon, 3 Apr 2023 09:44:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4D5C66B0071 for ; Mon, 3 Apr 2023 09:44:39 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 20CFE1C5D31 for ; Mon, 3 Apr 2023 13:44:39 +0000 (UTC) X-FDA: 80640199878.04.14A6957 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf26.hostedemail.com (Postfix) with ESMTP id 20983140011 for ; Mon, 3 Apr 2023 13:44:36 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="cXRs1/Dw"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680529477; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SGErzjl8q8bEHkw+j7+9BmRrAZAhIxrCfdEddh/fnqQ=; b=ltm74AxJD0fKA3H99JKw3IeQm77InIqr8rrSs9hUm6/Fyl+9uqbrwtE3oPwD2L013cRE14 TprmVppT4i2fSKmoujsnk3rTt+BYwoTIp+BVcWnFlasxKepnXFZz7qHRD+LwGHdMVAiE72 Z4kqNcDuGXbwXq74V0tLu1e6FoaOFUI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="cXRs1/Dw"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680529477; a=rsa-sha256; cv=none; b=n1nBRJaXRnvlRyieq6PxCOQYrRbm531dHsf7RSxHM0UkBkcLvrLKLiBPVxgUJHtgFaCnGV CKjy00ULmsfpXPn17wo3iMp34NKBlPd+GWz1P7vT0TNnSNIJ0/Szs7xw1C0v2yZFXxASHb jc3B3Ry0F12yjZvj81EXbEE2/c8UsfU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id CC54321D70; Mon, 3 Apr 2023 13:44:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1680529475; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SGErzjl8q8bEHkw+j7+9BmRrAZAhIxrCfdEddh/fnqQ=; b=cXRs1/DwLag4B98azT3sb5gizoxUZwvvHSf7cv7VqoQUSBRyKaVPNmzQ8bD8gDH1NsxS0Q hF1ly9tkEuIcn2fgpGNRX0byVxYU4uykD6qu9JJ1IN7Vclvvxe48C5aDohZARfefFbLpHV suwfGacZFv71uFwWg4lqbbsQcdx5gdU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id ACA8013416; Mon, 3 Apr 2023 13:44:35 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id asXaJ0PYKmQuewAAMHmgww (envelope-from ); Mon, 03 Apr 2023 13:44:35 +0000 Date: Mon, 3 Apr 2023 15:44:34 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Petr Mladek , Sergey Senozhatsky , Steven Rostedt , John Ogness , Mel Gorman , Patrick Daly , David Hildenbrand , Andrew Morton , syzkaller-bugs@googlegroups.com, Ilpo =?iso-8859-1?Q?J=E4rvinen?= , syzbot , linux-mm Subject: Re: [PATCH] mm/page_alloc: don't check zonelist_update_seq from atomic allocations Message-ID: References: <000000000000b21f0a05e9ec310d@google.com> <78ff6e70-e986-1fcb-eafb-3edd5f2bceae@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78ff6e70-e986-1fcb-eafb-3edd5f2bceae@I-love.SAKURA.ne.jp> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 20983140011 X-Stat-Signature: ks676cteyfcg1wtf7zsm9mn3o1f4s5tx X-HE-Tag: 1680529476-718811 X-HE-Meta: U2FsdGVkX19jVdAge4J9TyEd3s6zMx12YSYZA2a1giT/KRty9gSZ26Emqjy7ngSbHwlU8GIIFfoF0zSsyJ+ZcMzmIjV9FnSfwTpy3ay3fji71tQz9zWNBrWcLmWqrKwiy++XTwHN92xfGN5B0DoVf2LKToRsrEnshdcH9cgykdEf9TYSmlu9rdUXuRQqnLe/Np1aUwj7i7u14GepfNuhGoIXkuVgfHHg5CdfCtWystNyKBoa2VJHkM8ow8BpLX6L24kiGnFvKyGegE9UYRhPqzs8mYKgP8XlSgxxoPBn38vNFEDCOBW+9pl9/jbCpSVLG9cZ7YYRL9bQwstNGaDgaUtebuIeyEYhZGUBJZi2SaaPMCU88mTn4wBzG4o3Pewrh6xLxaLAAylqpSukCvQb+LFUnrjBTMNmgXTaM1TMOdI5Gx6z/8Qrlv7ZNdY8dbFlNPm3qmQwmE05K3eAwpwndAj0VBqwb8mXpV1pYCnZ+a4x4EqZZbrfDf0h1yaf4DA/ilIAEbp7BHqkVHPbPArAfZCeZfKW3XDbGh2ztoJczQR+RdOF8Yp8Jx9dAb4rQLJGjq2eZUBFankPL/9ENeYbN+Cwt8kepn97PD978NYFYcoE2gyqi8xzsHb4aROFGb/6Xr3JX+NcmFf3ov3XqSbL/egGFB5vKF7CUUUqY6l1miQD2wc02Tp1eBPKCrsmnhCxoKOojmNY+/I733z4EK4CbB/HpGL4UJDlcU3KJe3w7ArfPB9cMIKikPKoRTqJ2ifswjjTL0xMUErNsBvJ6Be8BNmttlbsDk62mdaqoPPlEXK6yfbAhcy/652CsM6RmOkfk/H71J7781XbOkRObYMPmHHaeVUlsT7c72/2VpbUEW7ME9UNPA03TIl45LhVmc2ZFkMKxfikkCg5WgKVgJPpw2j2ASVCCCp+szi3r4LdGkxGx7em30fwNGjbgTK31U9CFD1NJRjyeqWMaHlxCk/ nI/S1fQy ZcT8j8PR03bJmDLmuLTL0A/9UC5pxAqY58xGExwqNxDBdV5FATJkETRCaJHEQ9nKkmX745FqH1+BxgCfzq1ggbuXxN3mv4q+JAax8uTk1VZj8Ea54OCvjnzEG+FPWa+YdKV/dr+aPc5ihnUYxIZ8Z2ohTfbH6Mgq1mE84FQ+KCfh44nIxtAfNPYZQD74Tn8SHwKQnDr83s2l4vfpuTmkCjeeQg4uTqtDFAsuqVr4BJJqLJzv8PHkYCc/pcTUGEZGceJmvcXGUBKiFZtsGnZeWeJEegZK6Ja4OJ8HmoNftJDDdGJquyDXJLTeAo40jKowuh2jh X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 03-04-23 21:51:29, Tetsuo Handa wrote: > On 2023/04/03 21:09, Michal Hocko wrote: > > On Mon 03-04-23 20:14:28, Tetsuo Handa wrote: > >> Well, it seems that read_mems_allowed_begin() is protected by calling > >> local_irq_save(flags) before write_seqcount_begin(¤t->mems_allowed_seq). > >> > >> Can zonelist_iter_begin() be protected as well (i.e. call local_irq_save(flags) > >> before write_seqlock(&zonelist_update_seq)) ? > >> > >> But even if write_seqlock(&zonelist_update_seq) is called with local irq disabled, > >> port_lock_key after all makes this warning again? > > Hmm, local_irq_save(flags) before write_seqlock(&zonelist_update_seq) won't help. > Synchronous printk() will try to hold port->lock from process context even if local > irq is disabled, won't it? Not limited to interrupt handler but any synchronous printk() > inside write_seqlock(&zonelist_update_seq) / write_sequnlock(&zonelist_update_seq) > section is not safe. > > > Thank you! IIUC this can only happen when there is a race with the > > memory hotplug. So pretty much a very rare event. > > Right. > > > Also I am not really > > sure this really requires any changes at the allocator level. I would > > much rather sacrifice the printk in build_zonelists or pull it out of > > the locked section. Or would printk_deferred help in this case? > > Just moving printk() out of write_seqlock(&zonelist_update_seq) / write_sequnlock(&zonelist_update_seq) > section is not sufficient. This problem will happen as long as interrupt handler tries to hold port->lock. I do not follow. How is a printk outside of zonelist_update_seq going to cause a dead/live lock? There shouldn't be any other locks (apart from hotplug) taken in that path IIRC. > Also disabling local irq will be needed. Why? > By the way, is this case qualified as a user of printk_deferred(), for printk_deferred() says > > /* > * Special printk facility for scheduler/timekeeping use only, _DO_NOT_USE_ ! > */ > __printf(1, 2) __cold int _printk_deferred(const char *fmt, ...); > > ? Dunno, question for printk maintainers. I know they want to limit the usage. Maybe this qualifies as a exception worth case as well. > Since this is a problem introduced by mm change, I think fixing this problem on the > mm side is the cleaner. Agreed. That would be one of the options I have mentioned. I do not think the printk information serves such a big role we couldn't live without it. > Can't there be a different approach? For example, can't we > replace > > cpuset_mems_cookie = read_mems_allowed_begin(); > zonelist_iter_cookie = zonelist_iter_begin(); > > and > > if (check_retry_cpuset(cpuset_mems_cookie, ac) || > check_retry_zonelist(zonelist_iter_cookie)) > > with different conditions, like recalculate cpuset/zonelist in the last second and > check immediately before giving up allocation or OOM kill whether they have changed? Dunno and honestly that is a subtle piece of code and I would rather not touch it just because we have limitations in printk usage. Especially considerenig the above. -- Michal Hocko SUSE Labs