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 E0487C021B8 for ; Tue, 4 Mar 2025 19:39:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4ECA6B0085; Tue, 4 Mar 2025 14:39:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DFBF66B0083; Tue, 4 Mar 2025 14:39:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF5BF6B0085; Tue, 4 Mar 2025 14:39:55 -0500 (EST) 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 B4CD46B0082 for ; Tue, 4 Mar 2025 14:39:55 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 736331203B4 for ; Tue, 4 Mar 2025 19:39:55 +0000 (UTC) X-FDA: 83184883950.12.EB9F778 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf20.hostedemail.com (Postfix) with ESMTP id 236F71C0007 for ; Tue, 4 Mar 2025 19:39:52 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=anqvoSfE; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="1n2KVnn/"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=anqvoSfE; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="1n2KVnn/"; spf=pass (imf20.hostedemail.com: domain of hare@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=hare@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741117193; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6iIFedqhWb3N9WUw+rahWwqAHHg+Q/R9dVRr6Mkc640=; b=Vj5TbtLxouxt7PkBLHdlawvGnWngz908a94UlbfCyW2aDqy4GZ+BwnfFtagU1JIw/hyHPN 36J3reDBIBKA6d0TDVzmnHMQvVQ/wo+0tMyjw7WEV1TZqVHM4mvOQCd93MhuLsk85bBtZB +onjrjcykUfcqock5eDjyyCH+ri+6r8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741117193; a=rsa-sha256; cv=none; b=qzjh84UToElSKLLW85CcjDYqe37NKsCYVT8WgCxTsls0/wfJnj8ClB4JCqsPD5tCq3SwU2 pIHpSNG9dKurjSDZAjd110F9HapQ3dL46mlbA1VNd71JYlq4YGVDfXt3TLgB84N8p90wOc w1ZmdVUOIfFnAcqA7eV04Afzodf0kFk= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=anqvoSfE; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="1n2KVnn/"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=anqvoSfE; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="1n2KVnn/"; spf=pass (imf20.hostedemail.com: domain of hare@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=hare@suse.de; dmarc=pass (policy=none) header.from=suse.de Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 62357211A0; Tue, 4 Mar 2025 19:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1741117191; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6iIFedqhWb3N9WUw+rahWwqAHHg+Q/R9dVRr6Mkc640=; b=anqvoSfEOnhz0IPcWTGSRgdqJIPeXdhfg9TnG3YDma3lIYyfUwj+9kbSwphyLo0wokxO2W 44BapP+OKcrPnYG5WMwrnbfXCRrCsAGwH6dTzAAEo/LhVYUv9vfk12KvLS72Ke9+xQzrI/ 38r33aZD1jqZ4zWMcEUlbkBECsdsLJU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1741117191; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6iIFedqhWb3N9WUw+rahWwqAHHg+Q/R9dVRr6Mkc640=; b=1n2KVnn/CFICXg6pLnHAAW61irz5COL/8/knYOnEvhO2iEPqeDULGN3X3MyCIHu3ACYBy6 s+mldAt+ufwI+NAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1741117191; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6iIFedqhWb3N9WUw+rahWwqAHHg+Q/R9dVRr6Mkc640=; b=anqvoSfEOnhz0IPcWTGSRgdqJIPeXdhfg9TnG3YDma3lIYyfUwj+9kbSwphyLo0wokxO2W 44BapP+OKcrPnYG5WMwrnbfXCRrCsAGwH6dTzAAEo/LhVYUv9vfk12KvLS72Ke9+xQzrI/ 38r33aZD1jqZ4zWMcEUlbkBECsdsLJU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1741117191; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6iIFedqhWb3N9WUw+rahWwqAHHg+Q/R9dVRr6Mkc640=; b=1n2KVnn/CFICXg6pLnHAAW61irz5COL/8/knYOnEvhO2iEPqeDULGN3X3MyCIHu3ACYBy6 s+mldAt+ufwI+NAw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id F08E313967; Tue, 4 Mar 2025 19:39:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id VWpROAZXx2cgEgAAD6G6ig (envelope-from ); Tue, 04 Mar 2025 19:39:50 +0000 Message-ID: Date: Tue, 4 Mar 2025 20:39:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Kernel oops with 6.14 when enabling TLS To: Matthew Wilcox , 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" References: <95b0b93b-3b27-4482-8965-01963cc8beb8@suse.cz> <6877dfb1-9f44-4023-bb6d-e7530d03e33c@suse.com> Content-Language: en-US From: Hannes Reinecke In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Rspamd-Server: rspam02 X-Stat-Signature: qcrbewrqjtpk9knwas95988axphc4ci6 X-Rspamd-Queue-Id: 236F71C0007 X-Rspam-User: X-HE-Tag: 1741117192-530622 X-HE-Meta: U2FsdGVkX19ZCa1lSfGJmfcxuLdkeKDsmR9Owzwz7LXLhz39dzbOqdIZXFcnoFIESXNBZCq/62UW7AQ/myMJnd04FAGWPEoTBN/e3dMLSOyvAdi8WGNrJUfjdasAD0aO4MVygmnnseUh1F4EqJIVmsOTG4F0bFb0R6CNnxDRqrFPQu1/MQQ6p02wLgsx8hTfQtsOlInJcESs9Z+40BaSmyGGUZv+fka/KqaHccGUSi3AIqSpk7XrGrHNs6+UOtBWVRmRPfO6itRfk4BPj3Wr3GiuI07q6fQfk6X9Gl0qPKpjxINjUF1N0W32yNbPKgrCop/kBy/LxoYxfaT/V88HjajZwPLqSI++DhSgVszw2zmPMpiiaWfQ5YI4VIrbcaifql6iCgXkyDJBQI3dNYJUgsw19glzQ4eUfU7qYxODCkhFouQ9N05YJ6l9T8dKda7avR+PogB2KQYLR+/ESNRst5gjrzim9g2daRR6mRrdE6+9XdTbqn/MysItTSNYNZpYLeGi7SmhjseYIXQ6hpOOnadCzk0wwCeYITt14vLLC5NnmXh8rdY4wyqm24ZjoLqYPhZgjiQ/fhdzT/EAG9AXVOsSlipiajxzlYd6Mj17gpgm99iJUNB3vrdUmkG0yzbRk0aqj8gJDqGt6734/JYYub6SP3F6eJYqPTqtF80gvcIip7d6sjQhOq75h94eDqK+psHLMC3PWGa+YuKbBWxs6sK/IaeSSddeQcUt0pVMYb0bjFoYWPj1ykJSk+hSCOlv6SMDHA+8cB+A3AqrtHjc86kor+9X/gjRUUy4fF6eQosmMpWwz3ZQqdNtrazVMCYlpkRurQhS1jZhSVkVB3wZ3Auuc/mT9eowV10IT609ikTmvkpGc8aMl21Mwiq0lEupDoE5hVl697CCcVZP4M+3MxDgLuRbWnbXPENts8kvCPB+GfZD0nZHsWdmnyfhSh73OjeD/hnchE8IRiOsZ/z lqlRx36p ZnFTbF5PqTmpkTEcorhjbXe9iPiF7QGoJr5Um4JZyvjIP8UwsZJsfj7VqAv1J4MIAHu8O/AexvZLw8MpPmC30hb2FfEdbWv5m86lrYS1VqjCjZAMvJFgWVotWTX8+FOg84MXiPC9WwzRVqix4aDi6SCbt/RF3HawAInUe4dZZ+LeYGk/v/FZgmRLJn3/RHkbFzqTW035kLgy7UTuvM7W01iwTmx4sTtnci8Nw4Zbuhk28bqi4be9NzTndOJW4rROMBiY9Ulq6faeDgjZG6MOehFKjAbF1yme6x+3V37BIIpGvU5ZLUDFN6Nz+fd3ffJwrgphLFT/mfUbaxCceDQdu9CKZunlG2bARsd0BE8X+jyC4q2+RnFfZI7ikFA3g2UlZXz+kVbRIlcBGwmh5w3Di+zTRzqPQmso5wQu7ffnPK8wW1IVbj/zdXZMrh2gAcWeW5vxQ 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 3/4/25 19:05, Matthew Wilcox wrote: > 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; > Good news and bad news ... Good news: TLS works again! Bad news: no errors. Question to the wise: this is not the only place in iov_iter.c where we do a 'get_page()'. Do we leave them and wait for others to report regressions, knowing fully well that the current code _has_ issues? Or shouldn't we rather clean them up? I guess the real fix would be to fiddle with the 'bio_add_page()' logic; we are always adding a 'page' reference to the bio, completely ignoring whether this page is a slab page or a normal one. Discussion at LSF, maybe? Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich