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 1F918C71153 for ; Mon, 4 Sep 2023 18:59:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F6408E0014; Mon, 4 Sep 2023 14:59:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A60B8E0009; Mon, 4 Sep 2023 14:59:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86D698E0014; Mon, 4 Sep 2023 14:59:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 765A18E0009 for ; Mon, 4 Sep 2023 14:59:30 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 490CC1CA097 for ; Mon, 4 Sep 2023 18:59:30 +0000 (UTC) X-FDA: 81199828500.01.03C9B59 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf21.hostedemail.com (Postfix) with ESMTP id 4DDCC1C0019 for ; Mon, 4 Sep 2023 18:59:28 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=44DjIaud; spf=pass (imf21.hostedemail.com: domain of elver@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693853968; 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=GDbiLlEqmBfltBmTsCoRx2b9yjBtdlH6iWz3M1Lt5wc=; b=we7l2M4ZxLPuPJDyilq8+EzmmZx34oTLaUoOUH328G7xkMCl+8qp19li4+z6QA92pZt1V7 PyCsrgBy4YYtj63iJQ8p1wRtZfiUDW7RQSZBRQ2QeoLr/WlVbeiFsrPNR60BDV/ARIHip0 v6nQV9AjH5jcqGUdjTVnRD6PXxILKrk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693853968; a=rsa-sha256; cv=none; b=XbS4BGkwz7vt51zud/uHAfposdQ9D+QWWJprPChsUNfenWlqoLuqeLYdCopNmfgJ/S75m0 Y2foHDpKU2D9oWMhquwyIgXNwbkBxmecFUuQjhnGrMyL/IGlDW3lHke9Kjuo9/0NQn2ABT 1MONotML4hmskG2+qKnUYLzDQ9ErDYo= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=44DjIaud; spf=pass (imf21.hostedemail.com: domain of elver@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-3ff7d73a6feso16839875e9.1 for ; Mon, 04 Sep 2023 11:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693853967; x=1694458767; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GDbiLlEqmBfltBmTsCoRx2b9yjBtdlH6iWz3M1Lt5wc=; b=44DjIaudcC6E5YpOnfXfH5YvDz4+UjpjprvZ10sSeWMNJI/jc4vPunRZL4Hmp4LXAL 3/I8WYUv7wk5QeGRIsWdol/MAXvvU2w6Zkj0RRO+1iSFGQSoDJA6AvTO2hroMqXN8vxV OFKV5y9PXKV+xlY2s5N79SLWgWBmpbLEs9CRLNEx1qOLRMVr6DcfzPk6oz9KnBEjU1M5 y7VjgR3z57kAu3FAZ0PYwnkqxFVr/2pCrjDUGiKM2CdnyShwDep8JIamiskjwdYd808U fS19ELZG9HEEsmgq/H3LhfDoIdlQcyuWbIcOl/oT+RBgk+R8Wzs8sYim+bkh9MSDfsI/ 2cvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693853967; x=1694458767; h=content-transfer-encoding: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=GDbiLlEqmBfltBmTsCoRx2b9yjBtdlH6iWz3M1Lt5wc=; b=LMJrOPxNBR3eYZfViJHFGRYs1/hqzFUuF8irWpmjqF2TXeAi+UGwieDJJoOT/r13Id 1o6ytClnh6Vy6M6AtVTIsLdjI4dQZtbVUw/DLetqhBaVke7s6zrcLORImmTcOf29klY5 z6ZL5kw1vSbWbKeciEFY+c2vFyMmBeMsBfqST92SPMBbQOFJeMqYCxOSZfeHxGaMWgzj Vnsv87tnnh3cwBJ8gM0TWY/1Lb/Nhy/xKPe56FUP0L2yzme29amwNnyLP0SRQDfPX4mt 13wMTSMduuuGk+8DLRKX1Jv9UyCPztDmb+aYfjaf+kHso9eRDrhQ+FXjr5oqSz7LC9kl r7Gg== X-Gm-Message-State: AOJu0Yy84hbxCzawiT0gZpLpV73d4y4Vo9ec6YlXoY2NDCBNW5wpcOdA qzhMFyC9CbpmanYgC4oeGxm3F9JK+r3Ap6Lx76lzjAUVZ9jmosWNp+A= X-Google-Smtp-Source: AGHT+IHOsC3Af4FNjKO9QGMexCyA+QCLKl7uog8SZuiwiBIkzWUkqdvWTyJBAuXaxokuy1BJ3nGY6bHsOOQBsnoybKI= X-Received: by 2002:a7b:ce18:0:b0:3fb:f0ef:4669 with SMTP id m24-20020a7bce18000000b003fbf0ef4669mr8247988wmc.17.1693853966862; Mon, 04 Sep 2023 11:59:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Mon, 4 Sep 2023 20:58:50 +0200 Message-ID: Subject: Re: [PATCH 15/15] kasan: use stack_depot_evict for tag-based modes To: Andrey Konovalov Cc: andrey.konovalov@linux.dev, Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4DDCC1C0019 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: nnstf5pypjrog7s4txzutfsp6t683c4r X-HE-Tag: 1693853968-302424 X-HE-Meta: U2FsdGVkX1+0efi8UP/L9n15uiZkLvSWlCpnBZgwqL57tWgoImr9jwn7sW+rxCOBLgTHYtgb3/JkFbjq/BSp8lVZf3POzhON1LnwkyusnMDJBMJSgYHxyZLw4VP6MjMK8Sicxi0/QK+8PmrtCtbKUgSSf7j8UMmU4Xd/fsJwefCpqnLLb2IT7j4hKGqUk/tIuS8hAagzNq/Y0crM4eFmGsF9KWq/SA75EtkycSpzb4AkGEL5ocOLM94g/WeV/0bmZGkxlMYxZ9rxUuPlIafHR/SEybFjCEU9RQoitI2LrlAZyOmxirlUnrKkc9CELfzxjjI+37m7nt8EFTCFE42zVxtpq7gRQ21ymKdyKls9gD3WsW96egp6prHN0pDeuXxCZGjtGeNNuVDOB6B13Qhr2vWedC7wsZ3zrSas+0aw6g5FkGxAzGFgqpmIqOuF0SKjQEkQp0Sv9vOR8SVEHsgnjlY7ESpQ2oObSyG2d3xsKDbx9KAl3esajjHrDeUgdgXuK6GkyFFx7jfdg+KjTTJN01niA0GfSrDDB22HD1vbVUV9Vk9AZmWnIoAwhJZ9luANsy55ghFUgXGK8J6BAg1JXlJvMW0jqDY+Oa1NB3UCormI2W6x9uDieTmnpt8KVrMXY/NsnAf8d67uz3t/0ZCUS2/G2TaOiYvzJiYVCrajb6hmNlXs/I4SNT1cG8MO6GntBnh/3m36ZvWOvfIu0DIDeo2Zn2vEuRc2IP21ytEx89qLlBAvinjf7P3hnx2w4hkCqyYY/YH3boIyjyTsmZYbiGASaXEUanOkfZ2/zolMVLsywvq0kfh38NlFNSbC07sWxp1ENtnt9pxss/Pdd4l9zwIpiyWf0WXPDCXXUxWZ4Oa0XKtddMOejVz/LWQWJpFpFOdlRq6s8AfH5F1z0b65IXMJ3JTOjQ+XE0SgEmyspSOzZ8UDXnlXffwr5fSbaDEtg+V0LM/8APJ7grOxNV7 hgJRSp2G S5FsIhyhqTLQMLlPoScm6I72oHNcm7XC9zNJcdY6GC9nxV9t4efVFhkTu3LJZT7puw9FguWu2nt+cRc32btJk8rDEfnn6M3URZq3r9lbqHzcaUAGFi6zIXPHbzZ7GMNCtf5eKBtp9/sYcEjs1WfHMI6Q9ae7tUvco4XQ+rU0sek/dOy4zB+MGx/KD+11+Pmiqocr6GXgdhG6g9kEv6ZnAfd++j1yZZWHs/wcsuTZD1JqlcZmQ/W+g+THFjamy9+OmhjE/XyeMZJFdMVhb2V18iahfhr6XR40WGuyExpf31+aHPoxcf4aUYkSjwvqIMgVsqo0d 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 Mon, 4 Sept 2023 at 20:48, Andrey Konovalov wrote= : > > On Wed, Aug 30, 2023 at 11:38=E2=80=AFAM Marco Elver w= rote: > > > > > --- a/mm/kasan/tags.c > > > +++ b/mm/kasan/tags.c > > > @@ -96,7 +96,7 @@ static void save_stack_info(struct kmem_cache *cach= e, void *object, > > > gfp_t gfp_flags, bool is_free) > > > { > > > unsigned long flags; > > > - depot_stack_handle_t stack; > > > + depot_stack_handle_t stack, old_stack; > > > u64 pos; > > > struct kasan_stack_ring_entry *entry; > > > void *old_ptr; > > > @@ -120,6 +120,8 @@ static void save_stack_info(struct kmem_cache *ca= che, void *object, > > > if (!try_cmpxchg(&entry->ptr, &old_ptr, STACK_RING_BUSY_PTR)) > > > goto next; /* Busy slot. */ > > > > > > + old_stack =3D READ_ONCE(entry->stack); > > > > Why READ_ONCE? Is it possible that there is a concurrent writer once th= e > > slot has been "locked" with STACK_RING_BUSY_PTR? > > > > If there is no concurrency, it would be clearer to leave it unmarked an= d > > add a comment to that effect. (I also think a comment would be good to > > say what the WRITE_ONCE below pair with, because at this point I've > > forgotten.) > > Hm, I actually suspect we don't need these READ/WRITE_ONCE to entry > fields at all. This seems to be a leftover from the initial series > when I didn't yet have the rwlock. The rwlock prevents the entries > from being read (in kasan_complete_mode_report_info) while being > written and the try_cmpxchg prevents the same entry from being > rewritten (in the unlikely case of wrapping during writing). > > Marco, do you think we can drop these READ/WRITE_ONCE? Yes, I think they can be dropped.