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 D7559C021B8 for ; Tue, 4 Mar 2025 18:08:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 468DF6B0082; Tue, 4 Mar 2025 13:08:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4198B6B0083; Tue, 4 Mar 2025 13:08:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E2276B0085; Tue, 4 Mar 2025 13:08:26 -0500 (EST) 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 102336B0082 for ; Tue, 4 Mar 2025 13:08:26 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 797A71204A0 for ; Tue, 4 Mar 2025 18:08:25 +0000 (UTC) X-FDA: 83184653370.07.2025FEF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id A4F9D2001C for ; Tue, 4 Mar 2025 18:08:23 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=lFoQptTx; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741111703; a=rsa-sha256; cv=none; b=bJpdXgjOqLJVtr7XSHkqC2kxzR6LExQGETl22tZn3R6hdnXQ6cpkxkoXa7Vmu8tpW7usM1 79WMFlG7SZGRo/qnbdvRUE7LbnJ4EBE5Jbrv2Q6SHaqx15ixIb7i/uSZXOx331XqTzF39X DVkCcFP+tTmRTZnoxSEtm1x/AOOaE44= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=lFoQptTx; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741111703; 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=0oDWL9MqCLrBHhvluseel4yAvZkVftMTuSIpYrKtT5U=; b=dLTAlsYXDtUjb/VrI//3TwQOLtIEl+TNn/PdnusSM+m2bS8L7mbC9dajEVGiR7dmVkbFt8 vq1Cu+74lnbMm7HWE77MuVGca0DLGo3ZGnKenTWa9dopLMr80TuvNK3AcK87i746UKAc5o +8krMJipTWm4pRwNfz7LJxaGKbNLFy4= 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=0oDWL9MqCLrBHhvluseel4yAvZkVftMTuSIpYrKtT5U=; b=lFoQptTxFgvn2eDMe9RbVEMjHy bVVWUfCw27Rz8+6Vz9Pfs5Qms1vQk2tYgDHqnjK26Wj+5L+vcRKbLEqg8Er6WzIBfh81P7jRO1I1C S5amhajrZ2oT5+vUYjI2Zt+UJB45R7DD0cGnhtNujyBXgLM2rJpYmxVfAv1BUnHwBVEd3NG014M9V +WEbi3C00dMo3EwKzxqFH3F6vYB64aX382NuxQeD/au7NsDFJm42CPTl1hGqdVMIn9sh7EXtjKOd9 hqLXRwfcddIr7ZnpduODpJ00ZKAdNPJ8DGCmUjnyxYe1BfhQwdXTt+ACr3t2zHqx8bobuxqwbTB+j oc+BD3dQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tpWeA-00000002cln-3T7m; Tue, 04 Mar 2025 18:05:43 +0000 Date: Tue, 4 Mar 2025 18:05:38 +0000 From: Matthew Wilcox To: Hannes Reinecke Cc: Vlastimil Babka , Boris Pismenny , John Fastabend , Jakub Kicinski , Sagi Grimberg , "linux-nvme@lists.infradead.org" , "linux-block@vger.kernel.org" , linux-mm@kvack.org, Harry Yoo , "netdev@vger.kernel.org" Subject: Re: Kernel oops with 6.14 when enabling TLS Message-ID: References: <95b0b93b-3b27-4482-8965-01963cc8beb8@suse.cz> <6877dfb1-9f44-4023-bb6d-e7530d03e33c@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A4F9D2001C X-Stat-Signature: qp1ysrreme7dtqnjer5ojrkenb6b86c5 X-HE-Tag: 1741111703-129707 X-HE-Meta: U2FsdGVkX1+iksacu3A7Y+RqCatteDiw1kG/m1/g50/OgJAK7Jo3DOXMNF5PZImULx18JmUkI5pcq+PbhLYOcely667F7tuqXAp6v5HGzwFXC31Qgocilx73ovjFA9ydiRI2NAlEdBLbU35P86v4GDEMFDWPVlGuwNGfb9qu0QOP8EMi+xZ4FdU+X/r2omgXiJmhA91RVi6TqSPDWO+9rAucceLvyH4VoQlnOodnTINalLwO1OkrY0yCG/mejpRzxW3eTl+mHkCn4Y9Aa/KTFLILh/zhExD7zYJCRJWtoxrgOM16Ea4bSCahL8m5V4d63LI6sWTdZRfam/iIBNQrv/WyfSpbNayL/3XX7hgQRtNEseh/k8VsFis+pDtsYXkCu50etpPDiZTYbBwWRNbFIc0PZdNEAcAnRh0LaQLqr7BMylihNxGU3/WGj9q8crVCSXomcT3tJaXyYXpJlm2eeQ9TmbwBC/uw313WW45NJQu/PuRghMfUqwLoTMk9yONQeLVZgyZ3JqSg0wlVoFzY8vZybYrJTlTDaQAmEKi7mEQrSl8BaY467acK6MatP+r3pINwtf7iMxYc59kLu6j1XNIA7dbu0qNpNeuuqGtP24NxxUlPVhWtcuH62EVedFBy8Wf4RPibFoDG8b+A+4QgeWht59aa9a8A8Zq/KLKYu7E2vhdequjB91+1b0cRPQ61XvSWoRER1R4iSsGlLX+UNzKkgDHwxSiviDc7oQ+Q3/VjN1OV0YLCaQ9UPBblPnSvFqo/mS3Vt2NdEXEdjLUm2Qoktya+lN/kdE70yJ6q2KHo1wq37ObJx58a/X2kBEmJM7qbcoBIOoYqx9r5W4CZf6pbFQhFBpHbt+9nNwqWdrgP8OdimJrftgun4bJVa+S386bSc8Lp5uY0M2RogLehEM9OPKGYCaLFXy2IIzJHZenvNZYuuyXJu982eDIVn95MNSmoX67Pq117cFJajI1 X52F/25P m+uqP4qiFsgf8Uya3tdStszwfC1TTbAjTEQENWAPcrgsPXTR4IP06Xs2Umy1XcDkAkJBik4AnAcJEhlIlTioBM94gLfbSsX3BcEfwtyrLU5l8U0ds7B37CiXlJlC8jBmlCPcukB23tsV0jDjJGdGkZuHdTkEPNc3fkoozaLaWBtj71/a+C8HtOKSyNvu6CzFxahyFA9NeccCODzdsFf7O216rtzBmNQVYs6IN3bhXGVii/IGVu52mEyyTHODJiTxb0Zkw1ExGBmbGBJ6by4+dJ9Ytj2jMo8rv0aeagz/Td8qF8Nig4csbDqRSpi7RrZADOdrPksuIPPwcnxf0E2s3rAXexg== 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: List-Subscribe: List-Unsubscribe: On Tue, Mar 04, 2025 at 04:53:09PM +0000, Matthew Wilcox wrote: > Right, that's what happened in the block layer. We mark the bio with > BIO_PAGE_PINNED if the pincount needs to be dropped. As a transitional > period, we had BIO_PAGE_REFFED which indicated that the page refcount > needed to be dropped. Perhaps there's something similar that network > could be doing. Until that time ... how does this look as a quick hack to avoid reverting the slab change? diff --git a/include/linux/mm.h b/include/linux/mm.h index d6fed25243c3..ca08a923ac6d 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1520,7 +1520,10 @@ static inline void folio_get(struct folio *folio) static inline void get_page(struct page *page) { - folio_get(page_folio(page)); + struct folio *folio = page_folio(page); + if (WARN_ON_ONCE(folio_test_slab(folio))) + return; + folio_get(folio); } static inline __must_check bool try_get_page(struct page *page) @@ -1614,6 +1617,8 @@ static inline void put_page(struct page *page) { struct folio *folio = page_folio(page); + if (folio_test_slab(folio)) + return; folio_put(folio); } diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 65f550cb5081..8c7fdb7d8c8f 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -1190,8 +1190,12 @@ static ssize_t __iov_iter_get_pages_alloc(struct iov_iter *i, if (!n) return -ENOMEM; p = *pages; - for (int k = 0; k < n; k++) - get_page(p[k] = page + k); + for (int k = 0; k < n; k++) { + struct folio *folio = page_folio(page); + p[k] = page + k; + if (!folio_test_slab(folio)) + folio_get(folio); + } maxsize = min_t(size_t, maxsize, n * PAGE_SIZE - *start); i->count -= maxsize; i->iov_offset += maxsize;