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 007ECC433F5 for ; Mon, 3 Oct 2022 15:01:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CAC18E0001; Mon, 3 Oct 2022 11:01:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57A276B0073; Mon, 3 Oct 2022 11:01:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F3A28E0001; Mon, 3 Oct 2022 11:01:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2A4136B0071 for ; Mon, 3 Oct 2022 11:01:42 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DAE4A1A0CAE for ; Mon, 3 Oct 2022 15:01:41 +0000 (UTC) X-FDA: 79979952402.08.D519447 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf15.hostedemail.com (Postfix) with ESMTP id 595F2A002C for ; Mon, 3 Oct 2022 15:01:39 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id u26so8372566lfk.8 for ; Mon, 03 Oct 2022 08:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date; bh=9rAQZSDFLx6oyudqXJUAKh8EPFf5CZriEW2Q/puz7cw=; b=R8sv2LFCszyDp3XyJnq6sBvDNnGkSMQYnrP0Lc3g+w4Yp8MnStv2rONOs0pMHKHcfd b1HwUh/xsuxD6nwHgRLiKUWcF23LKLGO3t3trUjyZC1CnwmHORgYdieP+o8PO5wklJjZ gvvs6uXlyJ2PsOJYOa/Xi3YiaNhGR2lFYaOqLZ6MZ1/sHkr/mKvS76+s1GvLAKF6leys CryJL6jxaaUc1b8uatBJ/TDxAMK7CvHL5sBQYWQWhzPYNOEcuOeosg+tj3FWXixEaYbK 6feHOwigK9z4PuRHCKdXAFlm5jhOu7kw/YrGgQumu4diYCXnfDawjwmf7Yv730voEpEL znWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date; bh=9rAQZSDFLx6oyudqXJUAKh8EPFf5CZriEW2Q/puz7cw=; b=XzMc6svqZlqrtOxy7FHWMRAcjmWsyLNC75TeYC1yA2lhN/8x0ar2QIp1f4El5q5bsu NdBTVOxXnI7ZZKC/7mUV5a4FEqcTXLiosCwT85uhP2VqrDG0p9sgyE4q4IrLPsV9RZlx KzpNLyXKZyW5jqbt42F9+pH7D4LIJ7Zv/ptMvVo5xap3e3eVd/au87/dPFdMGtf2gLrG iSlwtciukdm1EyWrePZy9oiekQYw99UK8Dpj6uyb01/+O8/TVtfBmaPlZkeJlWMXjqDo qXKxf9atK0v7DTdIJRdP3oWwDXm9X3qZLJQmSLsUB1ZUynVbaz8ewZGy3+wqeTtERYhl VQew== X-Gm-Message-State: ACrzQf1D6QnVq5FZHgM54mB4urPAAN4uaKPcArcywpHUHbdPW18Hdkjw y5EMskMlU0B5vOHNJ+g5CDI= X-Google-Smtp-Source: AMsMyM7sHpygU+KbInUJWX2tRggNVSc8JmSzUbVltsBYyqZ+reOPbJxrmcMdzi49gQ2Qb8oMaPYUNA== X-Received: by 2002:a19:f713:0:b0:4a2:2eda:dbc7 with SMTP id z19-20020a19f713000000b004a22edadbc7mr2913849lfe.511.1664809298701; Mon, 03 Oct 2022 08:01:38 -0700 (PDT) Received: from ?IPV6:2a02:2168:a11:244b::1? ([2a02:2168:a11:244b::1]) by smtp.gmail.com with ESMTPSA id x7-20020a2e9c87000000b0026dcfe9c7dasm509453lji.14.2022.10.03.08.01.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Oct 2022 08:01:38 -0700 (PDT) Message-ID: <2f9bdffd-062e-a364-90c4-da7f09c95619@gmail.com> Date: Mon, 3 Oct 2022 18:01:35 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: Possible race in obj_stock_flush_required() vs drain_obj_stock() To: Michal Hocko Cc: Roman Gushchin , Johannes Weiner , Shakeel Butt , Vladimir Davydov , Muchun Song , Sebastian Andrzej Siewior , cgroups@vger.kernel.org, linux-mm@kvack.org References: <1664546131660.1777662787.1655319815@gmail.com> <821923d8-17c3-f1c2-4d6a-5653c88db3e8@gmail.com> From: Alexander Fedorov In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664809300; a=rsa-sha256; cv=none; b=79SzCo4nYh+JsMyoAldcCRpAPlqQw56TZHvuLRsyQ4xAtanlBtcWax6j/NRy/iv9DfkrNA JDRyzkhkI6urk+qsBdFz97UXXRN7ihePE6RhTgddqyiqbhmN6dphLARPxpGBn4YQ5CKOG8 ABc3ZEf9GKSpAd9l/jhny7CplRJedGw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=R8sv2LFC; spf=pass (imf15.hostedemail.com: domain of halcien@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=halcien@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664809300; 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=9rAQZSDFLx6oyudqXJUAKh8EPFf5CZriEW2Q/puz7cw=; b=6FQG4jzD8EMm1vMWdzQTCdTinSziAYV2djmytGGp2wrdc9aRL122oIJOnB5qc719THoA9N BB6noisFTnyY64NlK0SzKhUeFlSMvWD89co3yVo1qBsU0BMto7lDrvA/G2mBNZSsF1Y878 PyNSrCUFyEzWXExhaOygzPtR1g3Ml0U= X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 595F2A002C X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=R8sv2LFC; spf=pass (imf15.hostedemail.com: domain of halcien@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=halcien@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: 4nysx14qr5mq5trr4sm1eheecyq8pquk X-HE-Tag: 1664809299-100279 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 03.10.2022 17:27, Michal Hocko wrote: > On Mon 03-10-22 17:09:15, Alexander Fedorov wrote: >> On 03.10.2022 16:32, Michal Hocko wrote: >>> On Mon 03-10-22 15:47:10, Alexander Fedorov wrote: >>>> @@ -3197,17 +3197,30 @@ static void drain_obj_stock(struct memcg_stock_pcp *stock) >>>> stock->nr_bytes = 0; >>>> } >>>> >>>> - obj_cgroup_put(old); >>>> + /* >>>> + * Clear pointer before freeing memory so that >>>> + * drain_all_stock() -> obj_stock_flush_required() >>>> + * does not see a freed pointer. >>>> + */ >>>> stock->cached_objcg = NULL; >>>> + obj_cgroup_put(old); >>> >>> Do we need barrier() or something else to ensure there is no reordering? >>> I am not reallyu sure what kind of barriers are implied by the pcp ref >>> counting. >> >> obj_cgroup_put() -> kfree_rcu() -> synchronize_rcu() should take care >> of this: > > This is a very subtle guarantee. Also it would only apply if this is the > last reference, right? Hmm, yes, for the last reference only, also not sure about pcp ref counter ordering rules for previous references. > Is there any reason to not use > WRITE_ONCE(stock->cached_objcg, NULL); > obj_cgroup_put(old); > > IIRC this should prevent any reordering. Now that I think about it we actually must use WRITE_ONCE everywhere when writing cached_objcg because otherwise compiler might split the pointer-sized store into several smaller-sized ones (store tearing), and obj_stock_flush_required() would read garbage instead of pointer. And thinking about memory barriers, maybe we need them too alongside WRITE_ONCE when setting pointer to non-null value? Otherwise drain_all_stock() -> obj_stock_flush_required() might read old data. Since that's exactly what rcu_assign_pointer() does, it seems that we are going back to using rcu_*() primitives everywhere?