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 AFDB5C282D1 for ; Thu, 6 Mar 2025 09:15:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 383FB280002; Thu, 6 Mar 2025 04:15:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 332B6280001; Thu, 6 Mar 2025 04:15:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AD4C280002; Thu, 6 Mar 2025 04:15:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F1AB8280001 for ; Thu, 6 Mar 2025 04:15:15 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 257F21C8770 for ; Thu, 6 Mar 2025 09:15:17 +0000 (UTC) X-FDA: 83190567474.12.448F815 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf15.hostedemail.com (Postfix) with ESMTP id DCB59A0012 for ; Thu, 6 Mar 2025 09:15:14 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=vBwbmBBU; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=mD9aK61I; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=vBwbmBBU; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=mD9aK61I; spf=pass (imf15.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741252515; 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=RPhhRvINO8sdNrDDGrFMepQM60xk8knk9oHarU6dqAw=; b=1NMZdakMu2z5vlBgl77DoWB32M/kcLrpJRr5kKCoWoDr3+SiTHSIjbf7j/Bve1kn/9G/Yd 5Yh/HUwL6K8CjEUGUaNWk8NLf2XI6LrKMu05G0wi58FSPhKnUu/5no8p04R9v4dGMhiCgJ ox1OknIkOzomrZPrbqyTzMmBX0rKbHw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=vBwbmBBU; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=mD9aK61I; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=vBwbmBBU; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=mD9aK61I; spf=pass (imf15.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741252515; a=rsa-sha256; cv=none; b=aDfIEZhFjGxoJ/XH4DzW1VyF5TPZjmmtL+Q8DIdLRDtXdYaxR3Ce313wMekoDfkksLZiXv ACvDztkNktbfuotG12CroWfYq8arb8zz9+thGbZDaOZaFo0ILqJ1MgVkikEZjgIwbGSdoW C7JLGt9Wo0esiYWelWFrLYhptmBUn88= Received: from imap1.dmz-prg2.suse.org (unknown [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 1908A211BA; Thu, 6 Mar 2025 09:15:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1741252513; 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=RPhhRvINO8sdNrDDGrFMepQM60xk8knk9oHarU6dqAw=; b=vBwbmBBUiQw+JRmOBdvXucqI226N8EsqCTy5Oe+no3qWFLc5QmTXHJf0REGo3EvJdNV88R A4iF3rCIy4sf2BP2AFeurXxrRGQIgySCCEw3cF+kXWJUfjcLX6E+c1qzcPHdH30S77awLx ADL70xm8FrUyNLKW0RWpgkMYEKRK5S0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1741252513; 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=RPhhRvINO8sdNrDDGrFMepQM60xk8knk9oHarU6dqAw=; b=mD9aK61ISZTDqNAZvIMEfDYX4TLw8iNgnCLbNocLqk/PxZtLBjWr4amLJWTtdvAo0FiP6C qc6D6x8g0e8NpnCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1741252513; 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=RPhhRvINO8sdNrDDGrFMepQM60xk8knk9oHarU6dqAw=; b=vBwbmBBUiQw+JRmOBdvXucqI226N8EsqCTy5Oe+no3qWFLc5QmTXHJf0REGo3EvJdNV88R A4iF3rCIy4sf2BP2AFeurXxrRGQIgySCCEw3cF+kXWJUfjcLX6E+c1qzcPHdH30S77awLx ADL70xm8FrUyNLKW0RWpgkMYEKRK5S0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1741252513; 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=RPhhRvINO8sdNrDDGrFMepQM60xk8knk9oHarU6dqAw=; b=mD9aK61ISZTDqNAZvIMEfDYX4TLw8iNgnCLbNocLqk/PxZtLBjWr4amLJWTtdvAo0FiP6C qc6D6x8g0e8NpnCA== 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 EF4D413A61; Thu, 6 Mar 2025 09:15:12 +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 NcMLOqBnyWf3EgAAD6G6ig (envelope-from ); Thu, 06 Mar 2025 09:15:12 +0000 Message-ID: Date: Thu, 6 Mar 2025 10:15:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Kernel oops with 6.14 when enabling TLS Content-Language: en-US To: Hannes Reinecke , Hannes Reinecke , Matthew Wilcox Cc: 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" , David Howells References: <95b0b93b-3b27-4482-8965-01963cc8beb8@suse.cz> <6877dfb1-9f44-4023-bb6d-e7530d03e33c@suse.com> <27111897-0b36-4d8c-8be9-4f8bdbae88b7@suse.cz> <7439cb2f-6a97-494b-aa10-e9bebb218b58@suse.de> From: Vlastimil Babka In-Reply-To: <7439cb2f-6a97-494b-aa10-e9bebb218b58@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: jfthm61q5neu11scn7i815me9qyyse88 X-Rspamd-Queue-Id: DCB59A0012 X-Rspamd-Server: rspam07 X-HE-Tag: 1741252514-872969 X-HE-Meta: U2FsdGVkX1+7+/WyUYgPUGMMf/frKDEb9riyjk5EzTkExXGo8r4W8QHwyJXURXh6H/d6X69MoNjLUCIrPvVbjKbwIeACMd0DBIyjBo2NGkB7qUqh3/v3v1hu7U+CWYAVeCQ1v8UZG7t8TtwpXWil9XRmKNSzXUsrGxQ3mBEwgCxhovcybUG7cJ3uu0h3AxkRlynmvfAueedNw4/qYUfy4AfmXPD2YOvNjvNCVljj1hl9pHLJsgL/Xim8q2haapR2mVOzd5ZVfSPW3Azz+ryvQAcP7yLoGTO5TS3zUtykUJfaDRKSi+VShlgvFU5asr27HXesXNoTz4QMp946L+3aPJCHFLsBa75qsdtB2rWpicnbLnOTwmSlTFFmHag3tRbVPGuvKs1ROiiACcZpTCp4/wLVmhwZYXne1/UTDpsMr/zVMxfNyIcsf4tHTQ5DcjMhCWaKwzHHlN/GNNbCk4SC4m9WiahYfla1py6QrVAHBA1soNVQcN/KgkJxuWgfhrcqBpsB5XOouXnd0dcSPYJsurXGlMLsanwFWKoJ2Tp0Ex3ThcRZq+IhnL8xlo2aK5SRXQh7HyjBVjIR+/zKqiMC0LfCILIdyuxKUnmGN72n770+a4KofYlsv+pzu6sfSmRR+qHBCPgZFYVflo+gdzB932nOjE4Aem1fZdPU7GEwgzfdFVaUZWy9CW8/PV6uvXJIDomkyqDbb/SYFexTPGA5YQ7FmJzD57PDAUqotWS+84pEEt7CL7TlqGGtZ6aKNITfA0CM1zDYourS/FQPkD17Z4OfH/Qlt3eVvUqWXn/DMm6/WCcaDO0pjsOQZO/o9J8YJ2oAl2FiSyOzkSXKKAL2tdRB7qJxJKWeyHCzzLCk9NPKS1aVdXxCSiL81W7N+rGIX4vbOrgdvswKPBisz4VsMfZ1wbhzLu5XR4/4SKKA90VpRgj+SRRdvXOVowP4Ig5Et5XYPYLhH8qqAlcFx9x /e63lXZU yg7R6bwCd55CM3YuZ8ZTUMS5qW6qRKtjpYBUrscjcWK4SM32JgKuLNdf30QoRrFZK8ckdyJlhEDS5/GJ/CV+Igd5rBorxw2ut4Q2Rumshn8CXCre0PMfsTmwy04YB50Smt9HiEP789/lLnpQ3HBh9KmAUDFFMnlLJU/LxyiniQMeY4brEmEn6HWhJTQYM3EHJfMOgcIvIChXN34NBscr/HZFH0xvyNgxPqqkMhDdP5i1lIz3F2BTGVQKV5ud6cq8ndVDfAc90gG2bXdjgo5//4Kl5HOhQVvq10EVLiTET3Q0GHOzJsZnThI+e0mG6e8CX3oFtXU2i+lR2eK0d7VhaZflB0NDjp4nNEiphKpkS8oGakcyxBNZuWsuJIf/aaXPFBZpNyTSC8YsiUWcYF/4gQbhaBw== 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/5/25 12:43, Hannes Reinecke wrote: > On 3/5/25 09:58, Vlastimil Babka wrote: >> On 3/5/25 09:20, Hannes Reinecke wrote: >>> On 3/4/25 20:44, Vlastimil Babka wrote: >>>> On 3/4/25 20:39, Hannes Reinecke wrote: >>> [ .. ] >>>>> >>>>> Good news and bad news ... >>>>> Good news: TLS works again! >>>>> Bad news: no errors. >>>> >>>> Wait, did you add a WARN_ON_ONCE() to the put_page() as I suggested? If yes >>>> and there was no error, it would have to be leaking the page. Or the path >>>> uses folio_put() and we'd need to put the warning there. >>>> >>> That triggers: >> ... >>> Not surprisingly, though, as the original code did a get_page(), so >>> there had to be a corresponding put_page() somewhere. >> >> Is is this one? If there's no more warning afterwards, that should be it. >> >> diff --git a/net/core/skmsg.c b/net/core/skmsg.c >> index 61f3f3d4e528..b37d99cec069 100644 >> --- a/net/core/skmsg.c >> +++ b/net/core/skmsg.c >> @@ -182,9 +182,14 @@ static int sk_msg_free_elem(struct sock *sk, struct sk_msg *msg, u32 i, >> >> /* When the skb owns the memory we free it from consume_skb path. */ >> if (!msg->skb) { >> + struct folio *folio; >> + >> if (charge) >> sk_mem_uncharge(sk, len); >> - put_page(sg_page(sge)); >> + >> + folio = page_folio(sg_page(sge)); >> + if (!folio_test_slab(folio)) >> + folio_put(folio); >> } >> memset(sge, 0, sizeof(*sge)); >> return len; >> >> > Oh, sure. But what annoys me: why do we have to care? > > When doing I/O _all_ data is stuffed into bvecs via > bio_add_page(), and after that information about the > origin is lost; any iteration on the bio will be a bvec > iteration. > Previously we could just do a bvec iteration, get a reference > for each page, and start processing. AFAIU there's BIO_PAGE_PINNED that controls whether the pages are pinned, as there are usecases where it makes sense to do that (userspace pages?). And __bio_release_pages() can be removing the last pin and freeing the pages. But this is a case where the buffer is a kmalloc() allocation, so somebody has to do the corresponding kfree() when the messages are processed. A pin on the slab folio where the kmalloc() resides helps nothing and as willy says it's just unnecessary overhead of atomic allocations. > Now suddenly the caller has to check if it's a slab page and don't > get a reference for that. Not only that, he also has to remember > to _not_ drop the reference when he's done. The caller did kmalloc() and will have to do kfree(). I guess it's about telling the intermediate layers via something similar like BIO_PAGE_PINNED whether the pages should be pinned or not. > And, of course, tracing get_page() and the corresponding put_page() > calls through all the layers. > Really? > > Cheers, > > Hannes