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 909BFECAAD8 for ; Fri, 16 Sep 2022 18:47:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D02368D0002; Fri, 16 Sep 2022 14:47:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB2238D0001; Fri, 16 Sep 2022 14:47:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B78B88D0002; Fri, 16 Sep 2022 14:47:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A4F378D0001 for ; Fri, 16 Sep 2022 14:47:40 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6FA2C8051F for ; Fri, 16 Sep 2022 18:47:40 +0000 (UTC) X-FDA: 79918832280.18.EB70FC5 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf18.hostedemail.com (Postfix) with ESMTP id 2F7401C00A1 for ; Fri, 16 Sep 2022 18:47:40 +0000 (UTC) Received: by mail-ed1-f49.google.com with SMTP id w28so8855002edi.7 for ; Fri, 16 Sep 2022 11:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date; bh=anUOjxSWuh9smzFVz+5oZi9OcnMQyhkNh4o03mr+FNY=; b=S4Md8QKgu2i4Hzly2L6/A4DLA1glocAVYiMM4a4c4x3o5YnKP3RQC3PdKc+zwYInXo 0R1FH25vj2Hh49hRP6k/rCJ1LYI0S6nNlQCf6/dpJyeuQOjBqdyNogO2j3bz23xzPBlb MCohQqakQVVY/DkeJ7DtBpt2P8Bd5/g7rKzN3PGA3+7lSsdzXk8FClwGv4waUMyCbINX AGtdrSrpBbvtwQizZ2pkjmUIm4AqJs7QygFZTFcC38XYetsqhThB0gLjByWJMwwBmGQN A/x8xfY1IBGXKQxf5iDfLm3o+pbfVaDx/QHL5ZuxOe/D/UUVVYzJzK2UpaYdLste1R+9 AH4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date; bh=anUOjxSWuh9smzFVz+5oZi9OcnMQyhkNh4o03mr+FNY=; b=0wZ/846WlU7kw+uhPYw0H8jo92TsSG/waQqQSOfxVumD/5j9QTLrY6unOuI+e4TwrB avy6V1HsoHe3/omE46ChiWoP2xOCd2JhqTxaxnzzKa4DGP6wGd+wVc8IY2lfqhtvWyhZ QwD3DBcgfMu8gUVv879vcs7wE3BiV8SPn313nsNNqHi2mhH6UBcWFXRYvW9ANDSpfgs2 tKVZoQ3U6Mn57wwZdUSO+GVvVkzyP6hVhOAhGR7lQ0oImAW7Zco58UHnT3NwqrxRV0Bq xTnRjf3CG3n6PzQS2UEEEMTFC7qI2jx+4KmV1GHr88SYJnT0vAQmZN4RxSmiFriTr+KZ ZplQ== X-Gm-Message-State: ACrzQf1ibpCnv98XWhiQUuXCOQw5V3Ex0Bht2CE6pJOGVt8X1YC1XOyT W2KULOCXzCPsxCI8oP1wqZg= X-Google-Smtp-Source: AMsMyM4fnBAs2DAaik59U06CjadPBF5E5g8ofCgo76pAWxTBCTnEJ0wVc4kIFFvJg9oZZ3OQ1B7FWg== X-Received: by 2002:a05:6402:1818:b0:44e:66db:e401 with SMTP id g24-20020a056402181800b0044e66dbe401mr5080193edy.346.1663354058739; Fri, 16 Sep 2022 11:47:38 -0700 (PDT) Received: from pc636 ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id u13-20020a170906408d00b006fe0abb00f0sm10562282ejj.209.2022.09.16.11.47.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Sep 2022 11:47:38 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 16 Sep 2022 20:47:36 +0200 To: Matthew Wilcox Cc: Kees Cook , Yu Zhao , Andrew Morton , dev@der-flo.net, Linux-MM , Uladzislau Rezki , bugzilla-daemon@kernel.org Subject: Re: [Bug 216489] New: Machine freezes due to memory lock Message-ID: References: <20220915133931.ee0a6c8a86c59a144828eb60@linux-foundation.org> <202209160230.CE9E0E51@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663354060; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=anUOjxSWuh9smzFVz+5oZi9OcnMQyhkNh4o03mr+FNY=; b=764HkEXDoHySuD9CsQbRdHVmB0aB41bXDQdPQFiK1DGVusxh+BUqR7v62tpytbuAHVCFt+ Lo9D4M2Vs0ewe2e6iv9sSFh+j60/O8Atk6WDiBomSbUKBdLKnFJG7D0kL/PVxyKz0WNH2W ZBdT+4GVFEXtRg5CAHl0bTWulXvt30w= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=S4Md8QKg; spf=pass (imf18.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663354060; a=rsa-sha256; cv=none; b=Mj+eLrQvp+GAnX7CR3JbgBCGkK+6UbtDCt4dAhcUoxmaU5v8TqpHAOsQktsbiNpJfW2Nf0 tWIqdzjDKIl9x4ufRP8NT9nLFUcQtrLmk6q9T5WZPUfWXHlnRg8rCE5KmYpwTAMT6B4436 1VKjf6X6Vya9/wpFFATRapbW07sZa2g= X-Stat-Signature: oidyjzwtup87inu357us79azmiqkjabc X-Rspamd-Queue-Id: 2F7401C00A1 X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=S4Md8QKg; spf=pass (imf18.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam06 X-HE-Tag: 1663354060-275620 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, Sep 16, 2022 at 03:15:05PM +0100, Matthew Wilcox wrote: > On Fri, Sep 16, 2022 at 02:46:39AM -0700, Kees Cook wrote: > > On Fri, Sep 16, 2022 at 09:38:33AM +0100, Matthew Wilcox wrote: > > > On Thu, Sep 15, 2022 at 05:59:56PM -0600, Yu Zhao wrote: > > > > I think this is a manifest of the lockdep warning I reported a couple > > > > of weeks ago: > > > > https://lore.kernel.org/r/CAOUHufaPshtKrTWOz7T7QFYUNVGFm0JBjvM700Nhf9qEL9b3EQ@mail.gmail.com/ > > > > > > That would certainly match the symptoms. > > > > > > Turning vmap_lock into an NMI-safe lock would be bad. I don't even know > > > if we have primitives for that (it's not like you can disable an NMI > > > ...) > > > > > > I don't quite have time to write a patch right now. Perhaps something > > > like: > > > > > > struct vmap_area *find_vmap_area_nmi(unsigned long addr) > > > { > > > struct vmap_area *va; > > > > > > if (spin_trylock(&vmap_area_lock)) > > > return NULL; > > > va = __find_vmap_area(addr, &vmap_area_root); > > > spin_unlock(&vmap_area_lock); > > > > > > return va; > > > } > > > > > > and then call find_vmap_area_nmi() in check_heap_object(). I may have > > > the polarity of the return value of spin_trylock() incorrect. > > > > I think we'll need something slightly tweaked, since this would > > return NULL under any contention (and a NULL return is fatal in > > check_heap_object()). It seems like we need to explicitly check > > for being in nmi context in check_heap_object() to deal with it? > > Like this (only build tested): > > Right, and Ulad is right about it beig callable from any context. I think > the longterm solution is to make the vmap_area_root tree walkable under > RCU protection. > > For now, let's have a distinct return code (ERR_PTR(-EAGAIN), perhaps?) to > indicate that we've hit contention. It generally won't matter if we > hit it in process context because hardening doesn't have to be 100% > reliable to be useful. > > Erm ... so what prevents this race: > > CPU 0 CPU 1 > copy_to_user() > check_heap_object() > area = find_vmap_area(addr) > __purge_vmap_area_lazy() > merge_or_add_vmap_area_augment() > __merge_or_add_vmap_area() > kmem_cache_free(vmap_area_cachep, va); > Sounds like it can happen. I think it is a good argument to switch to the RCU usage here for safe access to va after the lock is released. So i can think about it and put it as task to my todo list. Since it is not urgent so far it is OK to wait for a splat. But it might never happens :) -- Uladzislau Rezki