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 982E4C4332F for ; Mon, 30 Oct 2023 07:37:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A2926B0186; Mon, 30 Oct 2023 03:37:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1523D6B018A; Mon, 30 Oct 2023 03:37:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01B8C6B018C; Mon, 30 Oct 2023 03:37:48 -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 E1CE36B0186 for ; Mon, 30 Oct 2023 03:37:48 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8B175140454 for ; Mon, 30 Oct 2023 07:37:48 +0000 (UTC) X-FDA: 81401323416.24.DD9C9BE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 9FF7E40012 for ; Mon, 30 Oct 2023 07:37:46 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CyIK0Trx; spf=pass (imf11.hostedemail.com: domain of mpatocka@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698651466; a=rsa-sha256; cv=none; b=470DoXgrUPlx10x8+6K1skTwZF1SEcJzka2knaY3OpKPTcoB68CNdVSIu/PICM9eQuVlhn wtjqpy+o46xt+Mv5dng8UcqhiLbkDRxzhp0DePUiNer/r+XBtOG/ADqq6lT67/byR1uxAA 3GAfROkqBEbhwgsOhRWg2rY0DTAiiKo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CyIK0Trx; spf=pass (imf11.hostedemail.com: domain of mpatocka@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698651466; 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=9x1xINqPKW24VJSZvIxrqGM94OrSE3vzkj8Ji7WoEIE=; b=jGPao7IOhcL/Tf1QiV7PDQF8/8y2TfVVpT6AqIfjfH7v5Oow6hp4n8KBa/kZtVSsWVDY0/ TQZM/XNQux0sXHEIJDzDaHga9Tg4wv20j/BG7+nQ0fULaGMYhW9j39GJtbLZZcO3RtcimU itQ0UPNZFZT79uKDbL3TBMd+RxqXvgk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698651465; h=from:from:reply-to:subject:subject: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=9x1xINqPKW24VJSZvIxrqGM94OrSE3vzkj8Ji7WoEIE=; b=CyIK0Trxher03PJJYkHxfj/1ilSO/8yqF3mSEtBGWcyoQZ89kE/mEjI9neOD8FE/c6NQ+g 0TJw/h18W+Tb1EUvGTLdG56uJPnWYtmD5dYamb8JUYTXYJiFRCZE1QhsU0xDMNrJXZwnv4 We8gWEJUHS8AWScUASfZl8u68P87YAA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-81-HtQO4g_9OzSL8hAv1k6QaQ-1; Mon, 30 Oct 2023 03:37:41 -0400 X-MC-Unique: HtQO4g_9OzSL8hAv1k6QaQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F2D2F857D07; Mon, 30 Oct 2023 07:37:40 +0000 (UTC) Received: from file1-rdu.file-001.prod.rdu2.dc.redhat.com (unknown [10.11.5.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1E2CCC1596C; Mon, 30 Oct 2023 07:37:40 +0000 (UTC) Received: by file1-rdu.file-001.prod.rdu2.dc.redhat.com (Postfix, from userid 12668) id 088A230C72A4; Mon, 30 Oct 2023 07:37:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by file1-rdu.file-001.prod.rdu2.dc.redhat.com (Postfix) with ESMTP id 0381D3D99F; Mon, 30 Oct 2023 08:37:40 +0100 (CET) Date: Mon, 30 Oct 2023 08:37:39 +0100 (CET) From: Mikulas Patocka To: Vlastimil Babka cc: =?ISO-8859-15?Q?Marek_Marczykowski-G=F3recki?= , Andrew Morton , Matthew Wilcox , Michal Hocko , stable@vger.kernel.org, regressions@lists.linux.dev, Alasdair Kergon , Mike Snitzer , dm-devel@lists.linux.dev, linux-mm@kvack.org Subject: Re: Intermittent storage (dm-crypt?) freeze - regression 6.4->6.5 In-Reply-To: <89320668-67a2-2a41-e577-a2f561e3dfdd@suse.cz> Message-ID: <818a23f2-c242-1c51-232d-d479c3bcbb6@redhat.com> References: <89320668-67a2-2a41-e577-a2f561e3dfdd@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9FF7E40012 X-Stat-Signature: wh3e1h3f3nac8qiiu15hystixtnd9jmg X-Rspam-User: X-HE-Tag: 1698651466-132332 X-HE-Meta: U2FsdGVkX1+VJtr7NYUb8sCVo1aRL6Hc7rb979D0u60U0oN0KY8SfTCWzb9DmduNFJzlxrA0nKIjF6TXjxr6QIksR/QM2YwN/Kli2det7p4d5iAVnZYTaKdCkiuSysa2aCYitzvbfZKds7/J6fuYhBUAJdaPyCD0W9h5bmTKKzRDhhRxAeOT/XY2MSQgUjBBKdA8yiUleibNLzR82K9YSPMeFaGZSXbt+CRLsZBwMTP0TOj814HBg163bWQhzweXkO08OeebGmsUprNF9Pqz2BMuQ7qCg7uUyjVtoa//K3TBk1KScRU0hdhPSxPvsd8V6G08oO/lCDSkPDfA297/9rFFcuDS7bmXiUaWdzUH2dNZPaQxRjGPQSHcfQawP7mlVBs3/KRkBcWF4mWTq5Tv9O3H+DdBMODZwUikZAAOn7o5/jJSuMyVeDGifjM3NfMM9bJEbyxm1g4A9K6fT8hTdMUU6+1URpKCtwxUjCpik2pB47ZNZdM7kbbj/DB+qYtshlwJy77hslbBs7vlttfN42ZtzW5Kf+EybCP5tI0l6ZTDXLYTxYBFINYHLfGZWktj//+DA55q9pGtbk526WQOohTfg9ElmsMRblx+qM9c4N9Wm9Bg3hZEKd7SY0EjTgM9bb8GGPAKkt0M2ChFrQ/xxjQMMKGzIEjb1V2MU/kvslML1/GDUGbftY6fg72T5Kv5bv8dkmpiClS5vtPT3BpdyfW0PUOFgVFVld0T1DxBbs947bWgp9ue1BlgQq+shqM3Dkr6iBCxFcGmFkGS0JEY4tSFfNthNUYIxupJMhJG/GsGKJdQsHfJ58eSZVsnx2hTEQaXuMPQMvKWn+851i4RXkq6ph/G15DZTphu+Sy/nT45i7SohL2GCC/Isa0m75oEG+N6J8OU+MFLFW+Pg+QGbtiJmzY6xH3Cg4Mv+xybvTFY8JYZhNWckV813U2O8npefLYkA4h6JB2nSYvEB0l i2IYTbAl OPEO2VyHP4Ij3xBMAzxQuH3eMgpEzgrTxH2R8l6A3ZOd55MI/+OIUvUbfQ4bmp6heYnXJhlkTTm7rn0JIzbNuzK7iNiIUJXhhXq7t3pX3q440ViO+2yC1Yvnk7EP8Dq+e7MkwizMcDLzG2Q9lY0FOGObiW1bpp1lgn/eP0iOFh7DgRKEjKRWn/a7A6qpXWD3C3KihmQvhUNLAEw4= 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 Sun, 29 Oct 2023, Vlastimil Babka wrote: > Haven't found any. However I'd like to point out some things I noticed in > crypt_alloc_buffer(), although they are probably not related. > > > static struct bio *crypt_alloc_buffer(struct dm_crypt_io *io, unsigned int size) > > { > > struct crypt_config *cc = io->cc; > > struct bio *clone; > > unsigned int nr_iovecs = (size + PAGE_SIZE - 1) >> PAGE_SHIFT; > > gfp_t gfp_mask = GFP_NOWAIT | __GFP_HIGHMEM; > > unsigned int remaining_size; > > unsigned int order = MAX_ORDER - 1; > > > > retry: > > if (unlikely(gfp_mask & __GFP_DIRECT_RECLAIM)) > > mutex_lock(&cc->bio_alloc_lock); > > What if we end up in "goto retry" more than once? I don't see a matching It is impossible. Before we jump to the retry label, we set __GFP_DIRECT_RECLAIM. mempool_alloc can't ever fail if __GFP_DIRECT_RECLAIM is present (it will just wait until some other task frees some objects into the mempool). > unlock. Yeah, very unlikely to happen that order-0 in page allocator which > includes __GFP_DIRECT_RECLAIM would fail, but not impossible, and also I see > crypt_page_alloc() for the mempool can fail for another reason, due to a > counter being too high. Looks dangerous. If crypt_page_alloc fails, mempool falls back to allocating from a pre-allocated list. But now I see that there is a bug that the compound pages don't contribute to the "cc->n_allocated_pages" counter. I'll have to fix it. > > > > clone = bio_alloc_bioset(cc->dev->bdev, nr_iovecs, io->base_bio->bi_opf, > > GFP_NOIO, &cc->bs); > > clone->bi_private = io; > > clone->bi_end_io = crypt_endio; > > > > remaining_size = size; > > > > while (remaining_size) { > > struct page *pages; > > unsigned size_to_add; > > unsigned remaining_order = __fls((remaining_size + PAGE_SIZE - 1) >> PAGE_SHIFT); > > Tip: you can use get_order(remaining_size) here. get_order rounds the size up and we need to round it down here (rounding it up would waste memory). > > order = min(order, remaining_order); > > > > while (order > 0) { > > Is this intentionally > 0 and not >= 0? We could still succeed avoiding > mempool with order-0... Yes, it is intentional. mempool alloc will try to allocate the page using alloc_page, so there is no need to go to the "pages = alloc_pages" branch before it. > > pages = alloc_pages(gfp_mask > > | __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_NOWARN | __GFP_COMP, > > order); > > if (likely(pages != NULL)) > > goto have_pages; > > order--; > > } > > > > pages = mempool_alloc(&cc->page_pool, gfp_mask); > > if (!pages) { > > crypt_free_buffer_pages(cc, clone); > > bio_put(clone); > > gfp_mask |= __GFP_DIRECT_RECLAIM; > > order = 0; > > goto retry; > > } > > > > have_pages: > > size_to_add = min((unsigned)PAGE_SIZE << order, remaining_size); > > __bio_add_page(clone, pages, size_to_add, 0); > > remaining_size -= size_to_add; > > } > > > > /* Allocate space for integrity tags */ > > if (dm_crypt_integrity_io_alloc(io, clone)) { > > crypt_free_buffer_pages(cc, clone); > > bio_put(clone); > > clone = NULL; > > } > > > > if (unlikely(gfp_mask & __GFP_DIRECT_RECLAIM)) > > mutex_unlock(&cc->bio_alloc_lock); > > > > return clone; > > } Mikulas