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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB0F6C2D0DB for ; Thu, 30 Jan 2020 18:28:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6E53820661 for ; Thu, 30 Jan 2020 18:28:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E53820661 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 006A06B0378; Thu, 30 Jan 2020 13:28:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ED1C16B0379; Thu, 30 Jan 2020 13:28:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE8126B037A; Thu, 30 Jan 2020 13:28:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id C337E6B0378 for ; Thu, 30 Jan 2020 13:28:16 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6833C45AA for ; Thu, 30 Jan 2020 18:28:16 +0000 (UTC) X-FDA: 76435135392.21.base76_82669d6926920 X-HE-Tag: base76_82669d6926920 X-Filterd-Recvd-Size: 1848 Received: from gentwo.org (gentwo.org [3.19.106.255]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Jan 2020 18:28:15 +0000 (UTC) Received: by gentwo.org (Postfix, from userid 1002) id 708B53EA08; Thu, 30 Jan 2020 18:28:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 6F9A13E94E; Thu, 30 Jan 2020 18:28:15 +0000 (UTC) Date: Thu, 30 Jan 2020 18:28:15 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Vijayanand Jitta cc: penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.or, vinmenon@codeaurora.org, kernel-team@android.com Subject: Re: [PATCH] mm: slub: reinitialize random sequence cache on slab object update In-Reply-To: <1580379523-32272-1-git-send-email-vjitta@codeaurora.org> Message-ID: References: <1580379523-32272-1-git-send-email-vjitta@codeaurora.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Thu, 30 Jan 2020, vjitta@codeaurora.org wrote: > Random sequence cache is precomputed during slab object creation > based up on the object size and no of objects per slab. These could > be changed when flags like SLAB_STORE_USER, SLAB_POISON are updated > from sysfs. So when shuffle_freelist is called during slab_alloc it Sorry no. That cannot happen. Changing the size of the slab is only possible if no slab pages are allocated. Any sysfs changes that affect the object size must fail if object and slab pages are already allocated. If you were able to change the object size then we need to prevent that from happening.