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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B7EDFC4332D for ; Wed, 18 Mar 2020 21:02:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5C2A220409 for ; Wed, 18 Mar 2020 21:02:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C2A220409 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=SDF.ORG Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7F3236B0095; Wed, 18 Mar 2020 17:02:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A1DE6B0096; Wed, 18 Mar 2020 17:02:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DE906B0098; Wed, 18 Mar 2020 17:02:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 56DFB6B0095 for ; Wed, 18 Mar 2020 17:02:42 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 10EED2473 for ; Wed, 18 Mar 2020 21:02:42 +0000 (UTC) X-FDA: 76609706964.07.sky69_349f7c1cf031c X-HE-Tag: sky69_349f7c1cf031c X-Filterd-Recvd-Size: 2983 Received: from mx.sdf.org (mx.sdf.org [205.166.94.20]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Mar 2020 21:02:41 +0000 (UTC) Received: from sdf.org (IDENT:lkml@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 02IL2WZ4029376 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 18 Mar 2020 21:02:33 GMT Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02IL2WgS005029; Wed, 18 Mar 2020 21:02:32 GMT Date: Wed, 18 Mar 2020 21:02:32 +0000 From: George Spelvin To: Dan Williams Cc: Kees Cook , Linux MM , Andrew Morton , lkml@sdf.org Subject: Re: [PATCH v2] mm/shuffle.c: Fix races in add_to_free_area_random() Message-ID: <20200318210232.GB16083@SDF.ORG> References: <20200317135035.GA19442@SDF.ORG> <202003171435.41F7F0DF9@keescook> <20200317230612.GB19442@SDF.ORG> <202003171619.23210A7E0@keescook> <20200318014410.GA2281@SDF.ORG> <20200318082035.GB2281@SDF.ORG> <20200318192934.GD2281@SDF.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Mar 18, 2020 at 12:40:33PM -0700, Dan Williams wrote: > Yes, editorializing on unlikely(). Specifically I would normally ask > for perf numbers to show that the hint is worth it, but I talked > myself out of asking for that in this case. Ah, now I understand! Yes, it's just gilding the lily, but as long as I was messing about in the area it seemed worth adding. You're saying that if the code were a hotter code path, you'd want benchmarks, but given its actual infrequent usage, you're satisfied with the argument that it's probably right; it's not like we've crippled the kernel even if wrong. > I'm referring to this: > > if (is_shuffle_order(order)) > add_to_free_area_random(page, &zone->free_area[order], > > Where shuffle order is MAX_ORDER-1. I.e. this code is only triggered > when we might be releasing a 4MB buddy-page. Ding! Okay, now it makes sense. I didn't look that far up the call stack. I was auditing each and every call to a get_random function in the kernel, when I came across this call site, struggled to understand what it was doing, and rewrote it to be less wrong. I only vaguely understand where it fits into the larger mm/ system so I never noticed that condition on its use. Yes, given that infrequent use, I'm even happier that I focused on code size rather than performance. Thank you for taking the time to explain.