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 6E837C71153 for ; Mon, 4 Sep 2023 18:48:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C6B38E0012; Mon, 4 Sep 2023 14:48:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 076AA8E0009; Mon, 4 Sep 2023 14:48:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E81108E0012; Mon, 4 Sep 2023 14:48:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D772B8E0009 for ; Mon, 4 Sep 2023 14:48:58 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A47C21406DC for ; Mon, 4 Sep 2023 18:48:58 +0000 (UTC) X-FDA: 81199801956.19.64D29E2 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf25.hostedemail.com (Postfix) with ESMTP id D062FA0020 for ; Mon, 4 Sep 2023 18:48:56 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=HDD5lZZh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693853336; 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=kHkLed3ShSa5G4ls8XODIWF8XE/UOVeInJKV4+j5nGY=; b=rRdTcIpLYG0OLCw3L6UIq2Mq2GVEyvDEU56RcGh/qjtyP3pGY6phMzjcm8znAnlVNy0qdX hK49RwF/mOVJaJHYYzVmkqJrHbsytnDfWnZl+rq8awOBwer9HOQ4wwZFtzRWILsc7pWsmm 70fPBCc7Fr1/CX6flOLTWeF4A+pm4U0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=HDD5lZZh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693853336; a=rsa-sha256; cv=none; b=t7YHlPcFz9ql+heYRfInR0eq0KuauNm+/o7nMlaXaHoiFAlXg1AuF5ku/OQXcT0ckgLl0I 2KOTctA4mw3+0carPRBYHDRSzH4WH/Ya2/qzt5r4kLvT4+7YHslDIuDyoWDAExPqguvHOo 12p/OEgOkiVfNtMvKGe29xBqhyuVjwY= Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-2685bcd046eso782930a91.3 for ; Mon, 04 Sep 2023 11:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693853335; x=1694458135; 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=kHkLed3ShSa5G4ls8XODIWF8XE/UOVeInJKV4+j5nGY=; b=HDD5lZZhHpSn07mWMtQnj/f6mw3N0kV2E5prhNaN2ps4iINwk2DKm6BVZ90b6Kzzh+ 6AM/dsN38YyQnM2/Ga4dcChcxj2x8M6isQSejsNKCGO+vkNu1he3YUclUuAE9s3njTi4 RQqu/qOIaS9BQaI4OpNtIklWEoe6s5enyv7SpSOpaC/tgBQTTKjX2xR1obfjtSxGvY5Y q75ZXv6BkbG87Rsx5klWjl4p1f5BjRQCcBypg8fRJG/9lcpHeJiyqE5Bf1vb3sAOx+JQ XiPB30mqaf6l5lPQgXsBsP1N/M5TFDu+4UTRPBw0p+/k0/mAmq+rH4+v3kITqRgJBngb z4FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693853336; x=1694458136; 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=kHkLed3ShSa5G4ls8XODIWF8XE/UOVeInJKV4+j5nGY=; b=X/r+eG1mJCf2RnejKsgIxcHvFd7DB8P7lN2A6v0Bt+kO9Y6sjiZdqbfvZGccspBHcW 7CjmuXH3MDxDtqQbyHi4FYPod/0iG3Kact7VSjpbnB9hKpqGgDTZ6sV97MJ8UPHx0hyI iGS9yOSneR4wbUqPfBkNlTQV1ShNIAMZGCrWGi1NN37TWAdjtkbgl52x2QSFc2p1NQ+n 8YXGhRvZXHtLPLl78XFDH+QgSuR6G/rt2abt7jGA4Pt8SeJvujeDxpN6McLQt1fNfLs1 XoN172U/9TOnvpfbbKHvav6xQSo0faUWRIwkz0SGca9G2k01uebtMDsqD0eeMuVOu/sC 3TYw== X-Gm-Message-State: AOJu0Yy9V9QtmY6AHH0rvX5r3JgPJWu7+H+WpPpZAG0i919mMn9oaG73 7BemFafmpSigsvNtqBaZdxLNIc2pLvEkDYKO+8E= X-Google-Smtp-Source: AGHT+IGF0ruB4y6Ivcx06qnSn544y5TwQFt/dfCx2tcf9FwoOKXDL8nDuD3aAdIGwqkV4zdkaYHt3EfH0WvizHMBs0w= X-Received: by 2002:a17:90a:f00b:b0:26f:d6f4:9646 with SMTP id bt11-20020a17090af00b00b0026fd6f49646mr7159222pjb.40.1693853335614; Mon, 04 Sep 2023 11:48:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Mon, 4 Sep 2023 20:48:44 +0200 Message-ID: Subject: Re: [PATCH 15/15] kasan: use stack_depot_evict for tag-based modes To: Marco Elver 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: D062FA0020 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ipuu7cdcssad36jxrbz8r5p4kt8icm6y X-HE-Tag: 1693853336-484383 X-HE-Meta: U2FsdGVkX1/6jn19CfX6ZeVHsYaADpIMQKTWWzbUloByIoiuyZ1JsEFIBw70ZdrDBhv0PdD2lNSDqX/sbGBxEVIgPEhQ6CSz/yz+nt6yMHE5EyyQAENUFFLgjj0tzrurqsltimfPHZTfNyo+engY9alUFukCV/mvAAE5lgx7ghA9uP/mdtTeYVrSmBDHOCVKHYw6rQThOLcbcqfXqiyv2nyaW06ynVVBWeh44IQXhCldrZ1Mu+biAgIEr7GTrRCwkKeDNy8/t07c2HKwDpE4KC9jhS+XUc/i0u0DfG/9gm6No8oqYfbkmz4inIorMGd/2eud8RGmWJ0qEf5/DNTLxaa6f7YWj9Lp6nPNDWyXgz1x0KKO+CColbDJygJ9rFELhsEboenYnu5iFJwu0UgCQEgf5VHBftBQmN9eBjwxB64y3DEEgeycYQ0AYNQFuUz7msjgrR90Y14iRaKOwbKI0F/YLC8haU5hq+BrSwBrAfbHGU01UT6iWgHOasspq5FcLxm3TRVBMQfec5QSJid8v5xv6urJI2ZhnBk/+jjz/+8I43c5Y3nMF94BzvE/GHevtQV9kJi/ucwn3Evz4PY31EXiYknaWqtQNL1KE3MZ72EnzcXHJgjBoHWCcIl04Yh9HwPT4MQxyulwsOC/6bK5ztSf5r9ZpGq3IQdDfstjMcxrYuFInQLXSj9LT5yCXDNJ2p3foCzMvCNh6W9wqPTwy5cfd1vF3L291FqYzYhikrWk0PhapbIs8HvqDDBQCD7OTOpCUsfT5+e7+FY0teJ6NGS5VYR8FAwZK9aZWdOEG9Gq8uXyRM+auBOipDSGurIzTOIvmouh4bXyVy2PerBki5dAEwU1PGUlgrxJg2d/ioqd86oHiALF12xp21TubKLOKLIAzhp5ZWUhWxyqUtOqpbhZ4laCZ+13M1TN5JLvHXfawy/BYY564t2k1jo1KaRIS6VeIeEKwtkBh3APsNy BG/c204g w5fIO5aGXWtqso32hcqZzjBQ27S4VxE7pdg3lgmTRIaWyGRRLDohJTYgYS19zmBa+hIZO6kmtl8waXFHMhWui2vX0uSrUGuUW3mLYrv7x/Sx8dHWi3vhlVYBsndTjAggE0BEm12hG/TWhwAw+G8ofK2NpH2cK9X/GIEPdYpqEo/L4D3wuK5BxzEYDt+hDxCTPs3X6Z8CgkPOhF2orHa1yeFLnzmAmninr2T4ISIhoE/lKj2pmIuE7Ez+3j69v6AJDGEk6TWGowiZehj4qcJzwgFJOQilnbnAyJax1cOdBod8rIMwjuLNw1s75K9V2q/0lGa2GWY1GuLNqi2rLr06WnSd4P4aYASyrEA04KyvKeA4daryg/v+U1ZDesKzXfoxBtTw67mLDclTNXd9MaZFRJ/fScaKig6VT8jZYOT88xHSnrv0= 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 Wed, Aug 30, 2023 at 11:38=E2=80=AFAM Marco Elver wro= te: > > > --- a/mm/kasan/tags.c > > +++ b/mm/kasan/tags.c > > @@ -96,7 +96,7 @@ static void save_stack_info(struct kmem_cache *cache,= 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 *cach= e, 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 the > slot has been "locked" with STACK_RING_BUSY_PTR? > > If there is no concurrency, it would be clearer to leave it unmarked and > 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? Thanks!