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 A8A2EC48BF6 for ; Mon, 26 Feb 2024 09:22:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 108076B018C; Mon, 26 Feb 2024 04:22:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B86A6B018D; Mon, 26 Feb 2024 04:22:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC2986B018E; Mon, 26 Feb 2024 04:22:47 -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 DD2C66B018C for ; Mon, 26 Feb 2024 04:22:47 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B70A4120707 for ; Mon, 26 Feb 2024 09:22:47 +0000 (UTC) X-FDA: 81833415174.21.69CBC39 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf29.hostedemail.com (Postfix) with ESMTP id CC56B120009 for ; Mon, 26 Feb 2024 09:22:45 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uUS9p0ru; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of elver@google.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708939365; 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=8QfBmNQlREY1mFL6Qy4q05yfZGbpdHZnd4065oOqFl0=; b=ppMd4Tfq+6DZioVdo+YzNU+cs+rqpfVPEmFCY9bG6tDj/sxyXvh7zIqrc0bz7iw76nuwue 5ATx8DX5V7d8DSe/z7z2FizGjP18XFOdSRGKl1nNSckqnPHk2p0Qbe2Ikw9zTK9eNs10L1 DMhymaMmygOtfLU3di26boM/gpmReII= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uUS9p0ru; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of elver@google.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708939365; a=rsa-sha256; cv=none; b=Xjp0rAdwTyVofJeO5L4E5FUCTnZUyGotTqz0woa/h/pmn6NTx0+GGMAKzbAZiIYI/QbZjg LLW/W0YQYf//VYYTiT19pgRrNDMk/JNc2watyLD5A6rZsn7XA6QHyi+X0SlPF3HJbtaNU5 +0gLzvtPG1RLsNEKQ8aIMQKDvnh97sY= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-412a7db191cso1830265e9.2 for ; Mon, 26 Feb 2024 01:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708939364; x=1709544164; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=8QfBmNQlREY1mFL6Qy4q05yfZGbpdHZnd4065oOqFl0=; b=uUS9p0rudv0oooQ1wkxbSi/sl61g0JNFrhAF0BR00/qHoK8ISq6ttRGhPWhj/bXysa gsSrhl9Fd0DeZhdwxruDQT03T41sMnDfWWnLGXTAKzgabc8q0KwewrqiJTQ02jHC6tE+ EeWhaThbaTOhA1YYLHoFe9diLdCe0Y9QZQ2nYB0MqCr12E2p6R8X7+AYcUpn/+MjbTaV FrDyKTNKp48fKtFGBkYq5WXLssOJT+jJ+kd1oFT2305ClOH/KE9WTpp+1TyjzVFBeQUD R1JeLMj0o878yAoDoGLIloveCgzOPuzsC3zfqzW0hia/9HkuN9M63tTHxy1vlnQMIGwW y8/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708939364; x=1709544164; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8QfBmNQlREY1mFL6Qy4q05yfZGbpdHZnd4065oOqFl0=; b=Q8gmT4n9ez6SlLo+N5pz5IEABMa3zo/dFqcLsq7aYmLUdW+g7ffwhmUXd1AoFrXsmj Ij2lIiFiqaIODNssZGSv9Ktkv6H7R0/56mcQ3xs/Qdpun9dJPCwph/HR2AiRvyEBi9Q2 6kwwuFAM8eQkXvLdOsDP4vDun5uEqZ54caHimoNsoSu9BEDed2w0Lopccu4yUCuTofBw aqaPS+6sLMDXL5ufWt/FCF+wXLLfG4Ciq5l7axIBPCE7m38DGlARey/B1Bv9WuQcaX7V kG8CUGHbD8Efu2MJZoghY8QQNoigXNPMu/TgV7yncFxlzdExHRGy2MIVmz2mW37+WAYe qkeg== X-Forwarded-Encrypted: i=1; AJvYcCWC/kuse+VvUwdOVT/AUZs0QMTrSgdhf2DJ5qgzOYiE3iWZ3ISj6i5dBKbpfVaHGxImPxbKiesJXGBi922pguBAvhw= X-Gm-Message-State: AOJu0Yz7oUeggaDc0f7yJc4FkD5MLD03yrQjuLmB/BQPr3pj8h0bMKfB IWZOiljWP45RIEAYxRpaUcVS4WPKlzKh0YR812ORM+5k3rE4TXGgl6b0/ZGytw== X-Google-Smtp-Source: AGHT+IEzYPyOySk525CCJZt3qsdauA8ALlZmo88S6gjzSE+qUyX/zZ24wPNv6whKTUB5puYa+0pWAg== X-Received: by 2002:a05:600c:4f95:b0:412:954c:801d with SMTP id n21-20020a05600c4f9500b00412954c801dmr5459772wmq.12.1708939364176; Mon, 26 Feb 2024 01:22:44 -0800 (PST) Received: from elver.google.com ([2a00:79e0:9c:201:2bc0:f3a5:93e2:b2c2]) by smtp.gmail.com with ESMTPSA id az8-20020adfe188000000b0033d7dd27d97sm7607221wrb.45.2024.02.26.01.22.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 01:22:43 -0800 (PST) Date: Mon, 26 Feb 2024 10:22:37 +0100 From: Marco Elver To: Tetsuo Handa Cc: Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , linux-mm@kvack.org, kasan-dev@googlegroups.com, Andi Kleen , Andrew Morton Subject: Re: [PATCH 2/2] stackdepot: make fast paths lock-less again Message-ID: References: <20240118110216.2539519-1-elver@google.com> <20240118110216.2539519-2-elver@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) X-Rspam-User: X-Stat-Signature: a7q1keudhzptitz349hhj6fmn93wo3gf X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: CC56B120009 X-HE-Tag: 1708939365-641765 X-HE-Meta: U2FsdGVkX18eeJLkumucSj0TnyoivBScf2ruxl8wSqMBJ7tp6jd7Jl1yeNgK+goEjxAvWTbmCSnZb/gA9lBX8A3sdWhGDyY3RrXNc70S/RLNdjXsrE3c551e5H4Htn1hDP3+KSoRV3YU0c0LJojO+SbRCwxP2EpvHfmdz+PAh/c4rKOtOREQ4zjfnvattVxDOAbu5g4lpzAXNmKzLp3CLyxBsIVavazLGV9HaWFrNhkgOHTOXH5lTZDe9PbPdU/ESvqor1M9rxwJgkHysCvj3x6ohHh4r8rOrt1u8v6roWaYMuKboRSKR9302of2u3Bq5t7K+nhUVP2fzUiWagnB0ZSD4YCVXQG6pnVetMWBsu+nb200VqNkYvCGuy9nSA4tGbSI6h5rd6/47rJFIkbPL+9tB5YoeocuEwYPLejNnC+8oa1XQg/HTGjpC5NdCMehpJ87wrdFd0bsoL0Er5EVOMuY9sJRzgtumtzlIjcBSS0rhHmeYa8M4/2Yhq2XXpW3OeP14js0Tsq3nqWxx9S9eKBopmm3QM9McVjrofGV+ny22Cpq8LyVRrPQWjsGZ/Ed50UlMNv1jDxZiFI4k/v+fudyPM3U8SdAaAcPTNcZJX6PFr1em+KtHZYWn5bVwWI4cFFQJIgLB0LHC1QwLse87LJnsPUiM3pEJ0CvYCIciaS+iqJg0y+7xEdT8gfeiHPQ1eP8upIcrxkyJpVbLUaRN2OzvlqE5qXwxqKAYcVDD5mIpzfoqmaUXkloo9s0GaNm84yyEdq9YOhw9hA1YTc2dW+s291EHruEw15PtvIlqBWJvExteX+67q6nlQA/jekM5y3nv4EotwYcP0CX5zEKWSJoTZSnANsMEXF2WZnsG5IUbJsMC3Cd/eTgR5sp2SaZgY3jk+wKB9ci0aBv8JPHDDwzizG88HKRHdOburY1dytdfEcn+w/6Yh/GIi20P8Xgoa/lUNqrB4Pa1+FGZK3 nGb0OYKn h/kd2Hyc4/yaMRd+HORKCkpVPUwacsdt/sNx4qU88n/CA56VmM/rCEFwAoQ743PLokbqVSP1n6DJXMin4tjpuAU+KJx+Wi1q3Zj/wybXMQ2KWqhKcbhPdFVSMQVxNXeX1q6DUi9EFTi5DAEpP8BN/yTv9L9TY7Y5z01I5sA2Ix+schqlc0cwTDnd9c/gcPky9fhFR5HUXhglxEopuFzpim3Na8+fBWQgTCnlV5DGsAyFbnZKT2WTlKMm2XNxU8UKyFtzh+eN8/M0kW6yhxyYWq06sRsZyaHVQ5CILnVJVbvEy19UD6OdtIXlrW8zi8RZiNMMh85flkHyL/5lxcYB8MjaIqyhQW27P+Dgn0w06Xq///bIcApJG35KcaUjducJ3cteMVt3ZMoDn3B+ptatAQKaN7SEeJwbU6symPI1V08AqJ7WizyixfvSGwF+RuwYgVD+L5ZRVmw1sUf4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 Sat, Feb 24, 2024 at 07:03PM +0100, Marco Elver wrote: [...] > > stackdepot users who do not use STACK_DEPOT_FLAG_GET must never call > stack_depot_put() on such entries. > > Violation of this contract will lead to UAF errors. > > From the report I see this is a KMSAN error. There is a high chance > this is a false positive. Have you tried it with this patch: > https://lore.kernel.org/all/20240124173134.1165747-1-glider@google.com/T/#u ^ [2] I see what's going on now. The series [1] (+ the kmsan fix above [2]) that's in -next that brings back variable-sized records fixes it. [1] https://lore.kernel.org/all/20240129100708.39460-1-elver@google.com/ The reason [2] alone on top of mainline doesn't fix it is because stackdepot in mainline still pre-populates the freelist, and then does depot_pop_free(), which in turn calls list_del() to remove from the freelist. However, the stackdepot "pool" is never unpoisoned by KMSAN before depot_pop_free() (remember that KMSAN uses stackdepot itself, so we have to be careful when to unpoison stackdepot memory), and we see the KMSAN false positive report. Only after the entry has already been removed from the freelist is kmsan_unpoison_memory(stack, ...) called to unpoison the entry (which is too late). Therefore, the bug you've observed is a KMSAN false positive. This diff confirms the issue: diff --git a/lib/stackdepot.c b/lib/stackdepot.c index 5caa1f566553..3c18aad3f833 100644 --- a/lib/stackdepot.c +++ b/lib/stackdepot.c @@ -423,6 +423,7 @@ static struct stack_record *depot_pop_free(void) if (stack->size && !poll_state_synchronize_rcu(stack->rcu_state)) return NULL; + kmsan_unpoison_memory(stack, DEPOT_STACK_RECORD_SIZE); list_del(&stack->free_list); counters[DEPOT_COUNTER_FREELIST_SIZE]--; @@ -467,7 +468,7 @@ depot_alloc_stack(unsigned long *entries, int size, u32 hash, void **prealloc) * Let KMSAN know the stored stack record is initialized. This shall * prevent false positive reports if instrumented code accesses it. */ - kmsan_unpoison_memory(stack, DEPOT_STACK_RECORD_SIZE); + //kmsan_unpoison_memory(stack, DEPOT_STACK_RECORD_SIZE); counters[DEPOT_COUNTER_ALLOCS]++; counters[DEPOT_COUNTER_INUSE]++; But that's not a good fix. Besides reducing KMSAN memory usage back to v6.7 levels, the series [1] completely removes pre-populating the freelist and entries are only ever inserted into the freelist when they are actually "evicted", i.e. after kmsan_unpoison_memory() has been called in depot_alloc_stack, and any subsequent list_del() actually operates on unpoisoned memory. If we want this fixed in mainline, I propose that [1] + [2] are sent for 6.8-rc inclusion. Thanks, -- Marco