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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02267C43460 for ; Tue, 18 May 2021 11:31:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F4F1601FC for ; Tue, 18 May 2021 11:31:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F4F1601FC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EAF5B6B00D3; Tue, 18 May 2021 07:31:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5FF36B00D5; Tue, 18 May 2021 07:31:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D27F16B00D6; Tue, 18 May 2021 07:31:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id 9F6FF6B00D3 for ; Tue, 18 May 2021 07:31:43 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4C63C824999B for ; Tue, 18 May 2021 11:31:43 +0000 (UTC) X-FDA: 78154136886.18.F451ED9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 8B8E6A0003A9 for ; Tue, 18 May 2021 11:31:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=bcVit+6mgvFx6heftajsrfaGxDkJsK5oc1JEKMXcvbk=; b=t8b781qfNVrmqOk36u2HkQAnOx 3W8zk/6U2ayPe7nlMCdyQKDq5sK6zToIkich1QZsLvVi4Ef40iM1NQf/c3DO2Bw5VrEd12V5SzHb+ 1cOUCYljpa9RqEfXAJRGJSCEloeSVRUtjxY3I5Zy4v61LDPhLryztZfyIO+zqSUOkZNQTZaUnvKos h1HVt1hJZP9IapTE2fnBHe/L/qbbxFtY7Ms4cork7z+pdoSjGbQGNRW1dMn5uMqcasMHRm/GyMKti vUYpR/zArMKUU2BLUwaJiCEz1z3/DGSEA+G7R31dwlBynnjx2qNl9FJxQY+ISkqeBIX+63q9u4h+B geD92rLw==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lixvF-00DvfV-Dm; Tue, 18 May 2021 11:30:53 +0000 Date: Tue, 18 May 2021 12:30:01 +0100 From: Matthew Wilcox To: Vlastimil Babka Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Jeff Layton Subject: Re: [PATCH v10 18/33] mm/filemap: Add folio_unlock Message-ID: References: <20210511214735.1836149-1-willy@infradead.org> <20210511214735.1836149-19-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=t8b781qf; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: w153s9hw5t7zampxiryc1nhjzfqnguos X-Rspamd-Queue-Id: 8B8E6A0003A9 X-Rspamd-Server: rspam02 X-HE-Tag: 1621337500-351314 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, May 18, 2021 at 12:06:42PM +0200, Vlastimil Babka wrote: > > /** > > - * unlock_page - unlock a locked page > > - * @page: the page > > + * folio_unlock - Unlock a locked folio. > > + * @folio: The folio. > > * > > - * Unlocks the page and wakes up sleepers in wait_on_page_locked(). > > - * Also wakes sleepers in wait_on_page_writeback() because the wakeup > > - * mechanism between PageLocked pages and PageWriteback pages is shared. > > - * But that's OK - sleepers in wait_on_page_writeback() just go back to sleep. > > + * Unlocks the folio and wakes up any thread sleeping on the page lock. > > * > > - * Note that this depends on PG_waiters being the sign bit in the byte > > - * that contains PG_locked - thus the BUILD_BUG_ON(). That allows us to > > - * clear the PG_locked bit and test PG_waiters at the same time fairly > > - * portably (architectures that do LL/SC can test any bit, while x86 can > > - * test the sign bit). > > Was it necessary to remove the comments about wait_on_page_writeback() and > PG_waiters etc? I think so. This kernel-doc is for the person who wants to understand how to use the function, not for the person who wants to understand why the function is written the way it is. For that person, we have git log messages and other comments dotted throughout, eg the comment on clear_bit_unlock_is_negative_byte() in mm/filemap.c and the comment on PG_waiters in include/linux/page-flags.h. > > + * Context: May be called from interrupt or process context. May not be > > + * called from NMI context. > > Where did the NMI part come from? If you're in NMI context and call unlock_page() and the page has a waiter on it, we call folio_wake_bit(), which calls spin_lock_irqsave() on the wait_queue_head_t lock, which I believe cannot be done safely from NMI context (as the NMI may have interrupted us while holding that lock).