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 85128C636CC for ; Wed, 1 Feb 2023 02:29:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E15AF6B0072; Tue, 31 Jan 2023 21:29:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DC38D6B0074; Tue, 31 Jan 2023 21:29:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB2A16B0075; Tue, 31 Jan 2023 21:29:08 -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 BACF86B0072 for ; Tue, 31 Jan 2023 21:29:08 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 79EEC140CA6 for ; Wed, 1 Feb 2023 02:29:08 +0000 (UTC) X-FDA: 80417140776.10.69AD52F Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 92F2180008 for ; Wed, 1 Feb 2023 02:29:06 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="HCp/m4br"; spf=pass (imf02.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.175 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675218546; 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=HfkJm0FYJosG42FnOanLfmkwIK+BW+AiL4ENGRclS8I=; b=DvAjDFCXVvNs01BuAQp3BL6XprsYhFy/PCgJIko5XaOg9D1NlbA3/ZBIERMLT/iwW1z4jF LHG0mJXDHmcYak8rqVpa61hNG9d3RPqCh4Ux1TRFlynaOksajjjDcLk0GeyEwVCsuMaiqh p+MduMk9O52qVeQIJxAPY0nXco/czK4= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="HCp/m4br"; spf=pass (imf02.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.175 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675218546; a=rsa-sha256; cv=none; b=pMawy2vjkah5LtjoHbKrOL56UJe+R/peKA8jZZR7/fGG8ufRTR6LpEHe17WU6FJ185xhzN Yu6eQZp16QFpL5ZIi19VdrHeb8m2PAdB0HgkdDCUFcfUpI9Q5IBR3j7p5mq6hFUOXmWWKW MF3tqu1eYTrkXkaY11a7h5pJG9IEoak= Received: by mail-qk1-f175.google.com with SMTP id r187so5159027qkf.10 for ; Tue, 31 Jan 2023 18:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HfkJm0FYJosG42FnOanLfmkwIK+BW+AiL4ENGRclS8I=; b=HCp/m4brSjwYXq5U4avqlXNv90V/dRcJ5rb1WqZvLtVTaxEVDRtDooQpv03rZIN3F9 HflgMs0paNw/2l88CwLWd4h8/PzMNvlNxR7xSgfx+7JRzeFQZbrHaW1GnUWRuDjnaK/r 6pCit8maqsaIPxrkQ4AExY1plKRIeVq/FqUAXQycT1TL+7lE8OrZxmQIZ3u+oZHzGe7J rcGwMjnu3HzBxS4x714/h+TRfwob06HC/6MDxqRrAl2Tq+y6q0gdJCB6J52ZZBRbIQG9 7z9gbZ+kU3g0Yx99WRy/CYtZ0wPFTnbZ2wW6siMRRbBSA4hgk4JOVZOvvoAi/c7ZJV98 3isw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HfkJm0FYJosG42FnOanLfmkwIK+BW+AiL4ENGRclS8I=; b=sJEArj9Usccqil/QebZypDW4j0l3RntlvhxS/6iSIgZrX/0wiwSFM/lECIFdg5IBzy kwnZQlZI9IgTpCNP+o3AopWFHYywUfbrDbIq0nCGLmaztnBBtfbNkXtt/TlnVxkB8dP/ Xick5OhcJFKk4h5Gb30Boh29MVdQtw84kMQBxAGM2TLqzvVJEXZM3TD/Oxr1V+t5aeYX j7mGljJEJbUvfEXxjOl4P/cAa/25UBO2Qc1xbrCXjFFk7pYQMEQh0GUCbUfxslAN1zJI Z7F8C6BbKFToao7scGXvG+M0Z0yVMXg5o4KLKDoi06hvvmlV3SjD6+MZJvBFADEKtaHC z7Lg== X-Gm-Message-State: AO0yUKX1EhAUA3Y3eNWkdv28GJtBKPyX4hamqjhtMbcDjja+C0fUgA6R hEk/BsJofGe49df5R/Cn85WqHaT5EzyKgM47eII= X-Google-Smtp-Source: AK7set84QFYUpiuU6AhyzUU0UwGy6qg3XrCuPyrUuSpvs+esE8nb6FO799RgT1Oduu9QynrGXsqJRRrMvXqGMkAbenU= X-Received: by 2002:a05:620a:a95:b0:725:1245:9cea with SMTP id v21-20020a05620a0a9500b0072512459ceamr80955qkg.233.1675218545522; Tue, 31 Jan 2023 18:29:05 -0800 (PST) MIME-Version: 1.0 References: <20230110231701.326724-1-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Tue, 31 Jan 2023 18:28:54 -0800 Message-ID: Subject: Re: [PATCH] zsmalloc: fix a race with deferred_handles storing To: Sergey Senozhatsky Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, minchan@kernel.org, ngupta@vflare.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, kernel-team@meta.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 92F2180008 X-Stat-Signature: zn6gjokdaw3pkhi54og5hj3ysbhgd3b9 X-Rspam-User: X-HE-Tag: 1675218546-694984 X-HE-Meta: U2FsdGVkX18fOVBSOgYEjNS3tVMLBUib8kKBOB8AXIV5bgksgvrlTnrE48RFNQ13ZqkBIsIcWsiwlMYLgZxM5cq6ZTsowqPM5YJSFTBGos6qUrPXQx5cGZMjxJEeeZUqy5WUh3QQG+Oo4BCcrCEO1qPaRMIUhOT4jp44Z5xgwNeiVTegnYpwoJA5iNMTS2UWPqUJbDshIcGi4Rw93vwqZQQSO4HGw5K31CEjCXLKo5HIlkTVajZVcSufQ27nO/IR9MQBD47nErLmCoW9QpjUWZ6+PElxllsiDoP40Tlqv9IdI8hXRpLBuwr6qx3WzOtq+IuNHr+ZShmmIk1WKJsl/z9NXE9lLcMeDSFSYuyE8J8Z6d3uCFW/UFjl7IZCYqDKvA7x4E8h09uFUxMPB9eh0FGwU9m6EZ8QS4NSOon4YOyTrYnjJ4HJ6Bm4WjQ/OgyYYLV7vgWXXzSKLZgn4Sx+yuU+UPNAUxEoBgBRyMGODA95t8glxw3kj/RjckUSSb1eOzM4gphCPGyaAr/fgEiqh57MNiyJla1ViUgRHMnQWOujWsjmM7ToY1cJTW2U/QMJb0fOZAkzlbXLOPgfSjU8C+TobTZ8venB4/GTzLhRirfsx0/eQ7YX9vjJ/ij/5gnjbTVAyy0KZqcg78SGsFSvIrMMg//7Rnb3lOTswIEUDD2N5p6NeNDk6bdNtvINobjso9g2PTnC1s/op6eX8dS8Wy1h8lGMlOFJKSBCrynZVsMpKk47cmFSU+qZJ8swrNsL+u2BARa7klnvl+5p1EuMFHFsedr2FnRmetWHKaLGAKmOdRqFyD/N5J6rWdBAnb+EKXdU9h4iKfc8JNng7EoU4kSC/jDSiJBAJmJDHBA8nMrJ2Hn32WlpsxXuUNPtO4znQuXwzBSkHSUUiPLjwwjmtB+xCtGM9+PoNbVj6NtNvzT4m0Vi242UdPdYtpGkneucYxaLuRXt//lsw/ATz69 Fgl8IFQM TYDXplspI+lV16JodSE6L4lruRO0LMW3riTgsXQezSSFpgx/2bpZzMHQqzTPZbQvFh3tCCgO5nohTyIxmzZn8P6M0QzGwU6tVjunLOHUSoqUyYapMV7o+Ur9a4CfPEc53T5wu4qQ/iGyYP4tbaKyJR6Ln7mUYM5o38DLPVrefdtwktm2icTyWQf4xlaiFpAi2y1EMIymYOCOG3nnXeBj3lil3XGd6yYXHqONi1SkIFQVyMCIGyY50X+lxiuME+94IpdFTZ+UWx8ENYEbh5Z0O/EmUR60vnQq1682d9mQ1uFSdURGMSWufnxuJNOSeeWREkMX+yVlJt7nv6MOQt78DUGgcD/wP4xEF4xqXeD3Z7KQJ6l7qjIcqSevTWCaknoV8PyuURuqF/DOOMJmHOtj8kyubD32bAqW+fGn8I8WB/4zITjJZsO1T3JUqPwlbsj1s7uHR0o1xqFS1BJbUstddnEMdxsE5/mC7mwGRb2Q3GqEsaSIJc1wm4DBPMQ== 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, Jan 31, 2023 at 5:41 PM Sergey Senozhatsky wrote: > > On (23/01/10 15:17), Nhat Pham wrote: > [..] > > #ifdef CONFIG_ZPOOL > > +static void restore_freelist(struct zs_pool *pool, struct size_class *class, > > + struct zspage *zspage) > > +{ > > + unsigned int obj_idx = 0; > > + unsigned long handle, off = 0; /* off is within-page offset */ > > + struct page *page = get_first_page(zspage); > > + struct link_free *prev_free = NULL; > > + void *prev_page_vaddr = NULL; > > + > > + /* in case no free object found */ > > + set_freeobj(zspage, (unsigned int)(-1UL)); > > I'm not following this. I see how -1UL works for link_free, but this > cast of -1UL to 4 bytes looks suspicious. (resending this since I forgot to forward this to other recipients) It is a bit convoluted indeed. But the idea is that for the last object, the last link is given by: link->next = -1UL << OBJ_TAG_BITS And at malloc time, we update freeobj as follows set_freeobj(zspage, link->next >> OBJ_TAG_BITS); Which means the freeobj value would be set to something like this: (-1UL << OBJ_TAG_BITS) >> OBJ_TAG_BITS I want to emulate this here (i.e in the case we have no free object). As for the casting, I believe set_freeobj requires an unsigned int for the second field. Alternatively, to be 100% safe, we can do something like this: (unsigned int)((-1UL << OBJ_TAG_BITS) >> OBJ_TAG_BITS) But I think I got the same result as just (unsigned int)(-1UL) when I printed out these two values - feel free to fact check me on this of course. Let me know what you think about this, or if you have a cleaner/safer way to handle this edge case :) > > > + while (page) { > > + void *vaddr = kmap_atomic(page); > > + struct page *next_page; > > + > > + while (off < PAGE_SIZE) { > > + void *obj_addr = vaddr + off; > > + > > + /* skip allocated object */ > > + if (obj_allocated(page, obj_addr, &handle)) { > > + obj_idx++; > > + off += class->size; > > + continue; > > + } > > + > > + /* free deferred handle from reclaim attempt */ > > + if (obj_stores_deferred_handle(page, obj_addr, &handle)) > > + cache_free_handle(pool, handle); > > + > > + if (prev_free) > > + prev_free->next = obj_idx << OBJ_TAG_BITS; > > + else /* first free object found */ > > + set_freeobj(zspage, obj_idx); > > + > > + prev_free = (struct link_free *)vaddr + off / sizeof(*prev_free); > > + /* if last free object in a previous page, need to unmap */ > > + if (prev_page_vaddr) { > > + kunmap_atomic(prev_page_vaddr); > > + prev_page_vaddr = NULL; > > + } > > + > > + obj_idx++; > > + off += class->size; > > + } > > + > > + /* > > + * Handle the last (full or partial) object on this page. > > + */ > > + next_page = get_next_page(page); > > + if (next_page) { > > + if (!prev_free || prev_page_vaddr) { > > + /* > > + * There is no free object in this page, so we can safely > > + * unmap it. > > + */ > > + kunmap_atomic(vaddr); > > + } else { > > + /* update prev_page_vaddr since prev_free is on this page */ > > + prev_page_vaddr = vaddr; > > + } > > A polite and gentle nit: I'd appreciate it if we honored kernel coding > styles in zsmalloc a little bit more. Comments, function declarations, etc. > I'm personally very happy with https://github.com/vivien/vim-linux-coding-style