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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 939E2C433EF for ; Fri, 1 Oct 2021 13:29:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0AA7461A08 for ; Fri, 1 Oct 2021 13:29:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0AA7461A08 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 93D9294010A; Fri, 1 Oct 2021 09:29:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8ECA59400E4; Fri, 1 Oct 2021 09:29:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7DC1294010A; Fri, 1 Oct 2021 09:29:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 6AE8C9400E4 for ; Fri, 1 Oct 2021 09:29:41 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 18A6A30C80 for ; Fri, 1 Oct 2021 13:29:41 +0000 (UTC) X-FDA: 78647950962.32.615B492 Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) by imf21.hostedemail.com (Postfix) with ESMTP id D3CD1D035D70 for ; Fri, 1 Oct 2021 13:29:40 +0000 (UTC) Received: by mail-il1-f170.google.com with SMTP id b6so10582332ilv.0 for ; Fri, 01 Oct 2021 06:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xMs0fSTF4k4sXUPE70Z2JKEpyq5JyqRAgQ76CwZyzaE=; b=pEDuSEGRh114uLI8QahRXH4hbVfIyGez8/8TDuXmXKhVYCzFsfbNyX1pEWIh+Z9srr 5Ya/tRV/avnZmnS9dxocomaXcqETM2p5tIUJpxsD948EKPb0Aj/AYGl02HYndGsZlhO6 n8LB3T/5HNkTf1tSLvuZtbMQSQQm+c/uVGIpGGJMyNS54HCub+kVakwcD8bvFwvz3vE4 dEzTAPdwPAs8AsJ9EYFq22AF1Lg8STOzUNuDV6seYY4pMY97U2gV+0CfJzHHKzLMM5d5 Ph4fIdwheMPuNZmdKAkw6NivHi38ClKzpIi6KZbXHaHtJ8gECoDsG97ybn0o/jBmiK8w NLeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xMs0fSTF4k4sXUPE70Z2JKEpyq5JyqRAgQ76CwZyzaE=; b=gIc7M2p8BpITH0mknceMKhW8OtN2NwtkOnJfIvGGhxsTKsni2jL9bqUm8sJfDzjyI+ 14ivMsLijaVJUtO8trDsNgCsGlDWKE5PkPOpRwsYcwpY1rzOFT9VIBgAO2r3Kv49K3ml +VwMGwVe74knFfZB+98ys+ahCBFzWUP9PHALyJGrsbJdC5gESXouFt/N+PYXJ9taaiND V/+ITTzyDs1KqSZz1JnwjmHguSiAsLapzJw8t2NBvuHAJcHFpFo6T18cc0iJHS00eHdQ zGoJBQWoHD8i+LRDxQ6VPp/qsUtkxSQfAcvURSy3u7SftUx/ZumkGo1r/agKdMQwK/Oi aBMg== X-Gm-Message-State: AOAM533EigihxFyzO8ZhMaEFj8rNY+yAIrZZ/hB7WrpyAkdADVrBx1Yz tTpeBaSiZJ5QkbwQWa3vbk+T+sAhLJWzoLUIR98= X-Google-Smtp-Source: ABdhPJzyOQrletc0/m0k7GQ9bnodD8aaSBhFEOXrQH7OYrsRBayS0WJ1GyqZPL2boYHXz9vvlKEbGHBQOXh1oFPecng= X-Received: by 2002:a05:6e02:1a63:: with SMTP id w3mr9162209ilv.235.1633094979971; Fri, 01 Oct 2021 06:29:39 -0700 (PDT) MIME-Version: 1.0 References: <20211001024105.3217339-1-willy@infradead.org> In-Reply-To: <20211001024105.3217339-1-willy@infradead.org> From: Andrey Konovalov Date: Fri, 1 Oct 2021 15:29:29 +0200 Message-ID: Subject: Re: [PATCH] kasan: Fix tag for large allocations when using CONFIG_SLAB To: "Matthew Wilcox (Oracle)" Cc: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Andrew Morton , kasan-dev , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: D3CD1D035D70 X-Stat-Signature: 6wuun96ccdwmqki6a31umu7r6t8ucwnk Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=pEDuSEGR; spf=pass (imf21.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.166.170 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam06 X-HE-Tag: 1633094980-87139 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 Fri, Oct 1, 2021 at 4:42 AM Matthew Wilcox (Oracle) wrote: > > If an object is allocated on a tail page of a multi-page slab, kasan > will get the wrong tagbecause page->s_mem is NULL for tail pages. Interesting. Is this a known property of tail pages? Why does this happen? I failed to find this exception in the code. The tag value won't really be "wrong", just unexpected. But if s_mem is indeed NULL for tail pages, your fix makes sense. > I'm not quite sure what the user-visible effect of this might be. Everything should work, as long as tag values are assigned consistently based on the object address. > > Fixes: 7f94ffbc4c6a ("kasan: add hooks implementation for tag-based mode") > Signed-off-by: Matthew Wilcox (Oracle) > --- > mm/kasan/common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c > index 2baf121fb8c5..41779ad109cd 100644 > --- a/mm/kasan/common.c > +++ b/mm/kasan/common.c > @@ -298,7 +298,7 @@ static inline u8 assign_tag(struct kmem_cache *cache, > /* For caches that either have a constructor or SLAB_TYPESAFE_BY_RCU: */ > #ifdef CONFIG_SLAB > /* For SLAB assign tags based on the object index in the freelist. */ > - return (u8)obj_to_index(cache, virt_to_page(object), (void *)object); > + return (u8)obj_to_index(cache, virt_to_head_page(object), (void *)object); > #else > /* > * For SLUB assign a random tag during slab creation, otherwise reuse > -- > 2.32.0 >