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 2622FC761A6 for ; Tue, 4 Apr 2023 11:05:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8CD16B0072; Tue, 4 Apr 2023 07:05:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3BF26B0075; Tue, 4 Apr 2023 07:05:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 904126B0078; Tue, 4 Apr 2023 07:05:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 811466B0072 for ; Tue, 4 Apr 2023 07:05:41 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 55E811206B0 for ; Tue, 4 Apr 2023 11:05:41 +0000 (UTC) X-FDA: 80643428082.04.57CB792 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf07.hostedemail.com (Postfix) with ESMTP id 6DECA40026 for ; Tue, 4 Apr 2023 11:05:38 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=e2rAQnjg; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680606338; 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=7BKNvkvvgni9fd/8FqhhKUBmOLok5HbMpNRQFk5Ac9I=; b=vS9xgRQ34VE4845hj+EBukS+THzk+huaog0UyAka9elwwrqK6rUZNPVxOttitJu+A25sIj /ypGEDCdC4I/AExPMsapcalYeVPPG4FoyKetQyvhLjwo1+7afaU1uHL2RtMPamw9s3vlBb ViSz70FvOs9uB7RA/5MHiv25cMDeJcA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=e2rAQnjg; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680606338; a=rsa-sha256; cv=none; b=63P5gwn+i6gElTW5AZeDLBqU5Cu5R98W91eeOjFacyRX9yykyeMmIOWmfASIVYxJU5A3sY MY6qvB/L9vQ3C4hqzQUyGbBO8uGECLFvfCAw+oG2ln/DO9ONZEmrvTEnhOUGY9Z0Ukyey+ KDPF7vO58AD+pKcceiMrhO31TuMhfGQ= 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-out2.suse.de (Postfix) with ESMTPS id C4DB420546; Tue, 4 Apr 2023 11:05:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1680606336; 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=7BKNvkvvgni9fd/8FqhhKUBmOLok5HbMpNRQFk5Ac9I=; b=e2rAQnjgOvdBks8OXobQEHoU/pNdTm96uY+INeKoLKRwkkFQghkRHMZi4VNWbCO+eVTP8l R9t51lMyaUvTPnr+rJUXWybNnjpTBW839Yw8Yy1VJtlj65POOL5vJbl9DuIIOM9MqnIRhB t+EoyrgTFNj1XTQAGHac9hmDZyG/y2Q= 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 B414C13920; Tue, 4 Apr 2023 11:05:36 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id LFyIK4AELGQGcQAAMHmgww (envelope-from ); Tue, 04 Apr 2023 11:05:36 +0000 Date: Tue, 4 Apr 2023 13:05:36 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Petr Mladek , Patrick Daly , Mel Gorman , David Hildenbrand , Andrew Morton , Sergey Senozhatsky , Steven Rostedt , John Ogness , syzkaller-bugs@googlegroups.com, Ilpo =?iso-8859-1?Q?J=E4rvinen?= , syzbot , linux-mm Subject: Re: [PATCH] mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock Message-ID: References: <78ff6e70-e986-1fcb-eafb-3edd5f2bceae@I-love.SAKURA.ne.jp> <6266b161-e4c3-7d65-6590-da6cc04d93ec@I-love.SAKURA.ne.jp> <0585ddb9-5de8-8cdd-202e-53887bbb6b5f@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0585ddb9-5de8-8cdd-202e-53887bbb6b5f@I-love.SAKURA.ne.jp> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6DECA40026 X-Stat-Signature: n3gps86f6swsifc3cdwobftjuo8zk1pt X-Rspam-User: X-HE-Tag: 1680606338-742506 X-HE-Meta: U2FsdGVkX196vpF96tgK8DNQtBGc42QnO6/0R8NBweU5CcIKW4SNPO7xvPEu3EqNDzgjs7l/w/5P3BuLlIEQw4e7sZ0xH8F3kobWvq0moO6uv1icIr/rXsVXiRNv5OFHbFyLN4vOsXgdWJszWONr+1XF8D8CI7qIZoz0GZvye4/+EaUSXKUgZu/pr9yUmvY11yh5fur5wfNFd9GKnQha/Vi0fl9vjOQ/6WiL9rKKz4AxpUgHpRHY4VlTx8Mc57BlXmpq//0eCsuTQNb4q3tC4j2uRN9R7ockMWr/SZj8pyAHPEjv1Rb9HXtAkysmucZDpeS6AQxIMCxNGITsWW+LN3YOz85/YUXY5IZcuBh6oht4iGFA09/KmxJI8BFICwUMpLJJ0PQSxaZOz3uBKT/ytgKJmSBuUDZXmVhNsGdEUOO3bgqft0UGTJKakpo7VO//grYH0XyTsVQg8EVTHTL5PkBVCp0lQ1KEyhdUnuPweuFODP0IlfSRmdl2ia+CjiNs08AGa7Sf3oq/rki7xZQLJcQEo9bIHobHlSVEEQiXo5b+xJ/6KkqScIhf+yYZ3x7sFFYnZvCXKnEEfdaehfXcdQIwqQZyMLeb7Q6ya/qjZpf8maul9w0/t9xHF+nBe3g29GBCGq1mYV9p9gNDobNt9qMWPwXWUFlp1y60U3bze/Kb3ktocLcTT/+UQOUcAvx1Dc8JlDQHnHr9ZQgxXaXvWviTWFDdV2/uhXN1TC2PIh6glNwZc27/VcoFYTnXc9f422jUZNF3Lr/mSr68toJdaANHxUYHQMjZiWcyX+xdlOsjpN3O75kEsa7sKX8B5XIg1WFZe9qGKH9+KZnU5cSkM0DA4VhbC516yAM8qzjSScOaWYB18FUxJ5xREioMUvFbv2cI3LhAAcao/v/vsmlLjBI84HdUp3xCQ0W+C5/Ns6XQlccPLhn3nWxJQREO4JjvbVDuMlvahDumSweR2ve DTvpgxSh NrtKcrVqLZBZHB1ynNZMrqvQn4y3YhrQvsL6SWll0/RAigvPX3DRIPlaSCWdWtS7d63HWy6QsML2BU1QrQ9fW9BicCBFpW6SX1kI2EuVppf0df5tOkXE3VWeQzBwunpsjzJd5K0nJi2j31u7SL6h5DvlaxdzAiGi9qCBq64BKX64RsQnRqDPfZeqGp2Ib0yY8h6gcCnWZxsdIJe/DsugORYfrSHIRh+I0nEFf+7ZPmC+lMFLPl3FmZLwdS17amB5ZcTmi2DdNqApjknerY08NjB5RUGeOiMuz6ayeFLHZGss1FuGTgGYmaJhxyg== 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 Tue 04-04-23 17:20:02, Tetsuo Handa wrote: > On 2023/04/04 16:54, Michal Hocko wrote: > >> + /* > >> + * Since __alloc_pages_slowpath() spins if zonelist_update_seq.seqcount > >> + * is odd, any memory allocation while zonelist_update_seq.seqcount is > >> + * odd have to be avoided. > >> + * > >> + * Explicitly disable local irqs in order to avoid calling > >> + * kmalloc(GFP_ATOMIC) from e.g. timer interrupt handler. > >> + * Also, explicitly prevent printk() from synchronously waiting for > >> + * port->lock because tty_insert_flip_string_and_push_buffer() might > >> + * call kmalloc(GFP_ATOMIC | __GFP_NOWARN) while holding port->lock. > > > > This explanation of local_irq_save just doesn't make any sense. You do > > not prevent any other cpu from entering the IRQ and doing the same > > thing. > > There is no need to prevent other CPUs from doing the same thing. > The intent of local_irq_save() here is to avoid below sequence. > > CPU0 > ---- > __build_all_zonelists() { > write_seqlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount odd > // e.g. timer interrupt handler runs at this moment > some_timer_func() { > kmalloc(GFP_ATOMIC) { > __alloc_pages_slowpath() { > read_seqbegin(&zonelist_update_seq) { > // forever spins because zonelist_update_seq.seqcount is odd > } > } > } > } > // e.g. timer interrupt handler finishes > write_sequnlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount even > } OK, now we are on the same page. Your previous bc630622-8b24-e4ca-2685-64880b5a7647@I-love.SAKURA.ne.jp explanation had an intermediary lock in the dependency (port->lock). I haven't realized that the actual scenario could be simpler than that. But you are right that GFP_ATOMIC allocations from IRQ context are quite common so this is a more general situation that doesn't really need to involve TTY and some locking oddities there. This all is quite subtle and easy to miss so please make sure to describe both scenarios in the changelog. For the comment above I would rephrase as follows: /* * Explicitly disable interrupts before taking seqlock to prevent * any IRQ handler from calling into the page allocator * (e.g. GFP_ATOMIC) that could hit zonelist_iter_begin and live * lock. */ Thanks! -- Michal Hocko SUSE Labs