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 9371AC001DE for ; Wed, 9 Aug 2023 21:07:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0538F6B0071; Wed, 9 Aug 2023 17:07:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 002F16B0074; Wed, 9 Aug 2023 17:07:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE5FE8E0001; Wed, 9 Aug 2023 17:07:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CCF846B0071 for ; Wed, 9 Aug 2023 17:07:48 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A5A091CA04E for ; Wed, 9 Aug 2023 21:07:48 +0000 (UTC) X-FDA: 81105803016.17.BA96E52 Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) by imf20.hostedemail.com (Postfix) with ESMTP id CF15E1C0012 for ; Wed, 9 Aug 2023 21:07:46 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=EUnhMb2X; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.160.49 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691615266; 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=VQhPymUQatLez9OhAXnkjteLBnvrlDrlwzKYnLXCkIU=; b=m4ryC2tGKumSSmLhu/5vT6sONDDyQOF4C4KFHbHA83BVz9eddPmmX9ALV9LvMOVMIRf/4d r5oIjCcGGcKwCchpwFiXVOZOc9YwhUN0E6FDhXSHCJsPdhYEoibn/3CM8V8PphCP5wQdXr GRyF2y/c13Q2k9zi9X+PDQr2vTuDwHY= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=EUnhMb2X; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.160.49 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691615266; a=rsa-sha256; cv=none; b=FHfHA+E6/D40YxoMM3fztpLK+es88Bxl5GJUgS+7leBj8QGtg/BGVuoRTWqwWIfikW9p4I 2Toc7ZEsUT6WbyHEtHifrkYAffAvUrLbNxBpWjuvm1tjBDEwq+Ad+V+4+XXwpQodduEXrv 5TuUQp8TDXugq6tKUxUnWHwAaViT3ZI= Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-1c034312675so181386fac.3 for ; Wed, 09 Aug 2023 14:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691615266; x=1692220066; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VQhPymUQatLez9OhAXnkjteLBnvrlDrlwzKYnLXCkIU=; b=EUnhMb2XtpgZMeivppTYpKUPHU/1tJTVNBvx8vjB6hgiPMyGsMKylvyif+u5Dy9rTO MbQnLpB9E25ZjsusJDPz5b2JQva54uSYWYx+1c4sA6X4S0vkJkRcrz01EIBvZMxr57Zl srRkBKI4gD1LySDPQnA8AFHo8eQclUdgOBu5zQe0t6UHyPNBGHga2x38AT3tJopFblRM /wolOhfa4YMk3v7GqzGSVnmS01EF8XvsSnMK4eMdDmRPLskyVcvqMA2jHa5XPkMH7CaF wrnnPYbeFBNeFTymBA7lA6EtgvuuWWPGNhHBn4V9roF47dPo0wrijxcmSVNKIse63GnY Eupw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691615266; x=1692220066; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VQhPymUQatLez9OhAXnkjteLBnvrlDrlwzKYnLXCkIU=; b=bPRCzQkJwTfy8hEIjjCILWIZqHRc3FZAWbxnHylKt9x3KcJ2C+PY4IBFow6Iu9Wt0p TP28Yadiwhz1VRZ1FpJFflZiGWrvd+Y4gvvWVXARrSJ1WzLf/Z4GvI3bZ5S6p7Z34yE/ zYONjTiHdkNzTG1BgNKinBt4QOZGNwuZAgzR9/9CAdN/JMaAuGjU1y4robGts9meDref Wv8Wt8NdatWiWzhlY4fdPlsrDy7SzT3GNCz66RuT64LQmiF+IppPQ/U6RCCfIxy/V99F MsEk764E3AMvZlg0hjRqXHSXfJHPU9reVsajbta6YjOGBWmtCjzVxXuhFs8xEpH+zeNh FzGg== X-Gm-Message-State: AOJu0Yx9TiWUmn4vi+WYLzKkByC70J7FYQAc1h0RtrVCvmMkLY3AYA7u eZzRuLEwx6UkaIGyiyWYFKoGHpMZ4OqTNDqxdnQ= X-Google-Smtp-Source: AGHT+IEfcjCJMWcdPFDkWHU7lh8NId2uR9ZSbF4zjNWL5iX3wKgvPA5uGM4+ivUnywUPI0zMEhF9Oh8mRWxuJA61RBA= X-Received: by 2002:a05:6870:88a9:b0:1b4:7411:5c0c with SMTP id m41-20020a05687088a900b001b474115c0cmr443843oam.13.1691615265775; Wed, 09 Aug 2023 14:07:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:129a:0:b0:4f0:1250:dd51 with HTTP; Wed, 9 Aug 2023 14:07:45 -0700 (PDT) In-Reply-To: References: <20230708191212.4147700-1-surenb@google.com> <20230708191212.4147700-3-surenb@google.com> <20230804214620.btgwhsszsd7rh6nf@f> From: Mateusz Guzik Date: Wed, 9 Aug 2023 23:07:45 +0200 Message-ID: Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking To: Suren Baghdasaryan Cc: Linus Torvalds , akpm@linux-foundation.org, regressions@leemhuis.info, bagasdotme@gmail.com, jacobly.alt@gmail.com, willy@infradead.org, liam.howlett@oracle.com, david@redhat.com, peterx@redhat.com, ldufour@linux.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org, regressions@lists.linux.dev, Jiri Slaby , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CF15E1C0012 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: kesrmp4dwptktppqae1p51g6hdbe4xb5 X-HE-Tag: 1691615266-311966 X-HE-Meta: U2FsdGVkX18ZMxMNmRdgBlaN1THrQvvPjA08OhGbgVscfQM2ny3EmteM3rr8oLpegB00Yy78yeErfX21e8A394mWIeNI/R5HMPuyHZtrGPeXk5LKaZ7OsfiBXhF+EO15fHLIiE1h08Q/m4IXKEJLEpj1MX05+EUxjzIz+rjXWyimu5lTI1LANw0OLVNQNGyT+vnM7ZiByKtgJbuLlKacvcIjDpbVEBlZfw5xoS0H0Ea7VNFa4Cwinr2kbA0INLtItxDM0ENFLvbk1UAXYj/3eCg6vk2RTXVFbzQWTeaRBgRDKAIuwBvS3hXH2TNYKkKSHZmtV5lgNwAlGYjak/2dReoDIy4nhYHWjyh/rz5lFVLj9QXwi4xG067s3o9cNGG5czVn+POpj0sQQsn58OtM8kIkrHgrqNI/7eQ27iHo3u3/7+jktlm/Y58t3TNtnexm6Cc8OA9NIRPvwLa1Sjyi6E84EhkeveP3i7clGL46u2i9APTvdbthHYugqauSMFPWg0N2L082jAc+sse8geh05XPFNtWk8CzGebFzYJ9V5V85fT2o1rl1r2wkYEXNzPTDnWmosy2Mmujx2r63Hb+AqH5tVIds+lkczYimf7zfa9M/0q0+6PI0DJzOVZDyOsQN+wf3RAqCSliEh1J61Z0zAiyorwj5Rpch4s0vMYIuTsTreOupggz78S8OwNNdYBhZsg0z3unAzX9rj2yRz7ATpMLZqKmlsvxfDlgVRU+udG1Ap5LdL/KH/uND29L32EqG30G6mbzvpjIw3kJre2tSV79Tpj8tptjmN98kICNuJFaKTIHl/po1ghkUxFae4LffefwARRYndqZpwk8B0IgeYFDbKwSTJCuSpwpjwqei7eW9kCM6pAcTsZQVJARHGrCipFInQB/AOZ9eBdsbR5i9IbL9YBDVCGlaxPw+0DY1V5Y77Hj4nCcBjP3W295QYtQgdGH1HQ1DYIN374vq+gG G4qiFF+b 8ouO5slDSvuoI7M+GW6RQ2bKMZWVpUfR70zJAAg6x7qEby8MTz4bqVtkdrxyB+QeaaizQxoXS511kcqOAZbe2SDboa88pwIZixg04IzFTQQ3vEDzYDUy2uXFhPjEh+ikw3ubpCWvSJSL2cYvBweF1sOABcj8hgZPiu3B1GGarKbPqY4Vtrgq5Z7dfbowh727e0JlC+wuPTVjfeBAGcGbqcPv2n5g7t0JO7BQO9DcYr8pm1mSO3zUYU753zgayjsT5DHgNusZlCKWd5+krVZx+1W4p7A72XJ7ukMX5vq7zTLVI5jhl8mfL+GAQF6c0mJq1hyJN0K0aOFv8wNtbjILNqplDvC0e4e5ruQnOM2tYRkqxKI9ZsB52lndrvcPcLmYl7ud8dfY2Wqp15DxKJjzwag2qCN9+rj8nrRkDSr9TF9Y6R2CeuCt5V5EHAy1i7n1cnIjnXV04EltNV6owukdTGdUprBf34sijFzpwxHwqJi0wKfwNSicUEaU4aNcssBkRTmFWxxtZ4r6FV3uPc5NYx19AGDltf6iHXQ4/2Yqf6lkkfxMhbhwOM21O5TaLrI3A+Q+mvy1OEQfBMccgxzrEnv+yXQ== 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 8/5/23, Suren Baghdasaryan wrote: > On Fri, Aug 4, 2023 at 6:06=E2=80=AFPM Mateusz Guzik = wrote: >> >> On 8/5/23, Linus Torvalds wrote: >> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote: >> >> >> >> I know of these guys, I think they are excluded as is -- they go >> >> through access_remote_vm, starting with: >> >> if (mmap_read_lock_killable(mm)) >> >> return 0; >> >> >> >> while dup_mmap already write locks the parent's mm. >> > >> > Oh, you're only worried about vma_start_write()? >> > >> > That's a non-issue. It doesn't take the lock normally, since it starts >> > off >> > with >> > >> > if (__is_vma_write_locked(vma, &mm_lock_seq)) >> > return; >> > >> > which catches on the lock sequence number already being set. >> > >> > So no extra locking there. >> > >> > Well, technically there's extra locking because the code stupidly >> > doesn't initialize new vma allocations to the right sequence number, >> > but that was talked about here: >> > >> > >> > https://lore.kernel.org/all/CAHk-=3DwiCrWAoEesBuoGoqqufvesicbGp3cX0LyK= gEvsFaZNpDA@mail.gmail.com/ >> > >> > and it's a separate issue. >> > >> >> I'm going to bet one beer this is the issue. >> >> The patch I'm responding to only consists of adding the call to >> vma_start_write and claims the 5% slowdown from it, while fixing >> crashes if the forking process is multithreaded. >> >> For the fix to work it has to lock something against the parent. >> >> VMA_ITERATOR(old_vmi, oldmm, 0); >> [..] >> for_each_vma(old_vmi, mpnt) { >> [..] >> vma_start_write(mpnt); >> >> the added line locks an obj in the parent's vm space. >> >> The problem you linked looks like pessimization for freshly allocated >> vmas, but that's what is being operated on here. > > Sorry, now I'm having trouble understanding the problem you are > describing. We are locking the parent's vma before copying it and the > newly created vma is locked before it's added into the vma tree. What > is the problem then? > Sorry for the late reply! Looks there has been a bunch of weird talking past one another in this thread and I don't think trying to straighten it all out is worth any time. I think at least the two of us agree that if a single-threaded process enters dup_mmap an down_writes the mmap semaphore, then no new thread can pop up in said process, thus no surprise page faults from that angle. 3rd parties are supposed to interfaces like access_remote_vm, which down_read said semaphore and are consequently also not a problem. The only worry here is that someone is messing with another process memory without the semaphore, but is very unlikely and patchable in the worst case -- but someone(tm) has to audit. With all these conditions satisfied one can elide vma_start_write for a perf win. Finally, I think we agreed you are going to do the audit ;) Cheers, --=20 Mateusz Guzik