Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4645528pxj; Tue, 25 May 2021 12:50:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzv3pYw0E3gQj7J0aOTHIsw0+BqCJKHjs+UCVItDHnWcp+6FQt32Oh+Y0JAA0199LWN4RXO X-Received: by 2002:a17:907:98e6:: with SMTP id ke6mr30025494ejc.107.1621972241734; Tue, 25 May 2021 12:50:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621972241; cv=none; d=google.com; s=arc-20160816; b=YkuJ3XM7RJOgTgymWoP3ZVGimlJFlvf+K2QdZJCLF2GugPedh1H7Ef4fPerG9mCDtZ 1jItqvIyaytD8ZbSB7FDq4893Ns0EZzPS0feHLxJjC8rGZUp4+bZ7XT19ejDfyULwfQl VlCsPqhKALOmaNsYTaKO7Gcm8fPgLW/nCXQq1gIGbN8q/swh0jFJKJ7Ldyh2mvztw9nP a3WC95Mm2rji5glp86Jq56JbY/y2s22uiWAHdnDRpNexOkmHZzdVluD2AGRC+jIg6JpT a9OQGtmacdEHEVf3ZTRFmyA0DJ2mlRhG3JIAdvJ7PHmUvorrJC8O3QKhdlU2QTOOPffF fdOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=X49KMwK/wFJ5JRpDV/cPj1TnCcaYZUMIUrxY6R7DCKg=; b=VEnNhMscpo2vghqBToSyLIkc6AFLsYqVOVMxOjvoqJHUcNmEEfV3eYhUB65vV6wJNo 8BvJTJ7DIyvLM0kfH8nRtNohhfsrjPJg4MCnsRzW3GEMO8pEZcw+axSJwnizuAYiYowE v/19N663By/zTaZfGicCT1/r3HmXn1L0J5Ytf4mKhjOseM0IRn8shuMBg5r9rz0Ib88/ ZGSodlTyFVVy2Fhtk4EoXE98LY0JHHflS3t9QNU3kcP+v+I9uXiS4diTa01xBdxpnEpC ohjWp638IPWPqAdM7umGyiXcNU4nAplUMY384Qtuk53gjrmuW99Qz4CLrNUFiJH6JLQ2 ftaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="im7/D+yV"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ca28si16605627edb.453.2021.05.25.12.50.08; Tue, 25 May 2021 12:50:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="im7/D+yV"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232911AbhEYPfY (ORCPT + 99 others); Tue, 25 May 2021 11:35:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231685AbhEYPfX (ORCPT ); Tue, 25 May 2021 11:35:23 -0400 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5CC67C061574 for ; Tue, 25 May 2021 08:33:52 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id v5so38672383ljg.12 for ; Tue, 25 May 2021 08:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X49KMwK/wFJ5JRpDV/cPj1TnCcaYZUMIUrxY6R7DCKg=; b=im7/D+yVaQx6FpQ+llblSwQdRwG0A+5z3rqPbU+VMhK3kfxsYzfm9ktDfxJAPWcbak mIrqCt4KVwD1I0W+yIrbN3ZQvsLLtYbH1S+h/1a1et4secGpPSIN0HiA9Aa+hTBvyLPy 0LS6+bGEDy3CYKRIcY8G0Y2ov96/5OqC0CTNtiPWe+kPaeob9WAui/xL572OdawACfX5 qC6GoSPieg+nFJp0QocPu/DV+14vxwwH7gCf3HTIsc6SAbb/EiSZepvtgrQ/Wj5do4Oy eQaAYOPBrDSqTVbf8+ZN5jj/2S88yHdsY4x0lvMx8JSTs7nKGgDe7jobMwsi9ndtZJtT 4xaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X49KMwK/wFJ5JRpDV/cPj1TnCcaYZUMIUrxY6R7DCKg=; b=jpr6QMnGSZIJz67Zvmph5XYcusWpDCmdOaWHoWPkQAwKWfuEEMktlbhdoqVa7avO4h gyPnIRr4dnw5GvAaGDUXhyUXFQuP8V5XuTcWnaE/kSJrqAlxxP677zhI1seYoOBqNFut 9Gy9Vex8aIR0YYgs3EcLqYDe8Mo8yaINYIzUDGvuiCD2UZT7/l/mlMAwkMvxSTKf9x9e 3BUPp2gTc8aGISuX66LUK3wL3dbDa9DUgmo/Ks5iNJNKKifMV8pwNd8Ging7AAq2LXhV uE1Sh+c7LC2CWHyyiMrwDksub0oMHrKlMdP4TCFpb/9Fxj0hr7U3Qw2LOQq/J4JYZ2Pz 3sew== X-Gm-Message-State: AOAM531lFP+Ium19Aoc3JPo2lrb4SVFPTSApvJPTtZ2Io4M4Cp1mBh4n vx04j8WnbopxcB1V4EjrlC4T5Eb9ji0PpH+opYcWgA== X-Received: by 2002:a2e:b80b:: with SMTP id u11mr22068665ljo.94.1621956830209; Tue, 25 May 2021 08:33:50 -0700 (PDT) MIME-Version: 1.0 References: <20210524233946.20352-1-vbabka@suse.cz> <20210524233946.20352-26-vbabka@suse.cz> In-Reply-To: <20210524233946.20352-26-vbabka@suse.cz> From: Jann Horn Date: Tue, 25 May 2021 17:33:23 +0200 Message-ID: Subject: Re: [RFC 25/26] mm, slub: use migrate_disable() in put_cpu_partial() To: Vlastimil Babka Cc: Linux-MM , kernel list , Christoph Lameter , David Rientjes , Pekka Enberg , Joonsoo Kim , Sebastian Andrzej Siewior , Thomas Gleixner , Mel Gorman , Jesper Dangaard Brouer , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 25, 2021 at 1:40 AM Vlastimil Babka wrote: > In put_cpu_partial, we need a stable cpu, but being preempted is not an issue. > So, disable migration instead of preemption. I wouldn't say "not an issue", more like "you're not making it worse". From what I can tell, the following race can already theoretically happen: task A: put_cpu_partial() calls preempt_disable() task A: oldpage = this_cpu_read(s->cpu_slab->partial) interrupt: kfree() reaches unfreeze_partials() and discards the page task B (on another CPU): reallocates page as page cache task A: reads page->pages and page->pobjects, which are actually halves of the pointer page->lru.prev task B (on another CPU): frees page interrupt: allocates page as SLUB page and places it on the percpu partial list task A: this_cpu_cmpxchg() succeeds which would cause page->pages and page->pobjects to end up containing halves of pointers that would then influence when put_cpu_partial() happens and show up in root-only sysfs files. Maybe that's acceptable, I don't know. But there should probably at least be a comment for now to point out that we're reading union fields of a page that might be in a completely different state. (Someone should probably fix that code sometime and get rid of page->pobjects entirely, given how inaccurate it is...)