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 CA797C531DC for ; Fri, 16 Aug 2024 16:10:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 695198D008D; Fri, 16 Aug 2024 12:10:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6477E8D007E; Fri, 16 Aug 2024 12:10:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 499668D008D; Fri, 16 Aug 2024 12:10:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 288968D007E for ; Fri, 16 Aug 2024 12:10:48 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D5644C0113 for ; Fri, 16 Aug 2024 16:10:47 +0000 (UTC) X-FDA: 82458596934.30.639F411 Received: from mout.web.de (mout.web.de [212.227.17.12]) by imf07.hostedemail.com (Postfix) with ESMTP id BEBF140024 for ; Fri, 16 Aug 2024 16:10:45 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=web.de header.s=s29768273 header.b=TEPYnjX1; spf=pass (imf07.hostedemail.com: domain of spasswolf@web.de designates 212.227.17.12 as permitted sender) smtp.mailfrom=spasswolf@web.de; dmarc=pass (policy=quarantine) header.from=web.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723824632; 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=XHeSc4EmQEyvh1Xp4MeSDRuGugN27ZqCYg6lFm5zXkw=; b=ei0xIO4ByaOjF61NSg+MHeLSu2JfhyTykyj69PGw/I735EhdNmf89NzwRm0m36Hz3lkorh XMlVMmhhxQst8CLf5m3ouSyc5swEcEGER3B7IRu+DggzPXeEuJCSVc3gALZuQyaRPOfrbm bL2JfuDSj8ewihIU6ui1lbX89+wUM78= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=web.de header.s=s29768273 header.b=TEPYnjX1; spf=pass (imf07.hostedemail.com: domain of spasswolf@web.de designates 212.227.17.12 as permitted sender) smtp.mailfrom=spasswolf@web.de; dmarc=pass (policy=quarantine) header.from=web.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723824632; a=rsa-sha256; cv=none; b=8PlrDfXYAzXGLkvGpu86JCdaFN7LnsKFJjRM+qifCXd1GwNSyr01WqC8KXyb0VM5Y4KAIH 3boiD3AIIRatJ/TDeRmZWnjybecKesEMJII5GqeFE/+5bN14QKg2WLOI1oES8CuXpybyrh Mg43PuJBWSda7jxoy++jCMcMzp3Okh0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=web.de; s=s29768273; t=1723824644; x=1724429444; i=spasswolf@web.de; bh=XHeSc4EmQEyvh1Xp4MeSDRuGugN27ZqCYg6lFm5zXkw=; h=X-UI-Sender-Class:Message-ID:Subject:From:To:Cc:In-Reply-To: References:Content-Type:MIME-Version:Date: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=TEPYnjX1mbsCUnunMTrszooQJtAa50thEBVJeeEzp91TyCHG7jk5Qb+uBdTux1AA NoU3/hZkZcO1y+aijbNGmNY9USLzLDxGnLEvpBHXy3opNZweoJVhgSlLr8um3/jyC Au1gQuK+rJnipVSTjYks4IXKu5Q92fTDQ+9aPRWiVAoY2Up3jZreLIqkGAO4abWrO LzDGuQJhVKvVtGH6XNLEyPtNsTjjfjkRqReFHGf9OdOcr0Mtqp3Sc5jjlYiAm5dRT L6eJWW2/xVVkU1A5zg1NpVxDVxgYJjQFXrRrYclUujpBbVHQQjhe1vPWsoD0eTUVx eWrF+u5bSzJLHUIWxQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from [192.168.0.101] ([84.119.92.193]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MkElP-1rucF31YwT-00eAAr; Fri, 16 Aug 2024 18:10:44 +0200 Message-ID: <0d377467c50cf60a4d008d7986d4402eecb8c94a.camel@web.de> Subject: Re: [PATCH v5.1 00/19] Rebase v5 patchset to next-20240816 From: Bert Karwatzki To: Lorenzo Stoakes Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org In-Reply-To: <5fa31825-e7dc-4d58-b218-d54ed6d86507@lucifer.local> References: <20240816111405.11793-1-spasswolf@web.de> <5fa31825-e7dc-4d58-b218-d54ed6d86507@lucifer.local> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 16 Aug 2024 13:55:33 +0200 User-Agent: Evolution 3.53.2-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:KJ/tHxtS9QD8WiaE74h81FWnlfsSwU9ypMpgMZY1ephZteF4pGY rJ5ELc/PbkVlq09aa9bWLTgdYa/Me94S6qLDo/0P4AkQRDhNfxkoXY52uxRAjv91hkOMpsw IpNWjlpZpDn4U+cJDu3Xu/01Fx638E8HofpnxYV0tOzZmuCOTo3u/PmAIbpF8rNHlmvk3v+ NPcIM68wM5x5QdzfrMiAA== UI-OutboundReport: notjunk:1;M01:P0:VAXjOzJTUWs=;vAmCcuA/HBBM31mr+nugY7mx3zR EEXQbBHQj4CI2WtP8grSMQCOP+IbJrXsRg14HAjwAJ8/NY2ZWZ5zFQdDBdZfFAjR2yZJqsNht Vs625ib95qMeBYKtGrDvKnpSOSERUZFYOniZRiEupX2uayPfVEVOi7hsntbqXQqh9FSF8XPbF agGv3skdZadGcW4MQKG3BgHF8fto6YAV3vUxnU5fAhIDX0S8WYz3sxNuIqobDm9+7IjJ6AUED cVn4HFgqMB0LYxkanvAWWodMrw8o84yFJxFRr3jQyiSEPaFx4uHqp2s26yjT/dhS1ZaPgKe5h cau/hoTgVYcm1yEj1rcfPMVCPnC13C5jq/0eruwoUD64v7vjLITO7gwiFxJnowz+wZZLhaAZ1 nVn39A2+VVjhYSVVBIpGmEUlA9oBX6CPc2A1Y1kjTDQFtgjO0egQN+cJ1eDSLVovg1PGKNrd1 kC2awslXfqS1Kq/40eayQKeho4tUcRzUVCTsQ5LFICM3w8V5sw8pP0fUkJlOjBMzYgZW21CoY U3tqBpOY/eEcohPHgqQYb5BiHSHCBr4W2rdMalJQb7s6bwD/TfBN4QJ8oK3o5kn86yHyEnpWu +/FmY57pP6tp9SNGSucgqrNLCBfoLrooMZQbDsAdXMgVcsdEbnAYpDXPUaL34Vg13xsOF+Dej jCBUoALvjszMA11ZLghiMPecKiNaVaJQQzs/Qchv0vf1//fAXIReNgnDWNvl8sPHiarWHMnMP vX9QTIWHX4tX8iu5a4aDvww5f5OjAmwmYdjdrkYixPXXckhX45g2Tn+pGhkP3qVtfx+s753EG ecAWWGvifJj5lzIm2xiVxHjg== X-Rspam-User: X-Stat-Signature: 3rtnna4i3a3bkuauoku8r874t84awatu X-Rspamd-Queue-Id: BEBF140024 X-Rspamd-Server: rspam11 X-HE-Tag: 1723824645-73071 X-HE-Meta: U2FsdGVkX1+sLvdFPiU5RKVVemMrK7BCRFqBEsNDl2MfF4zgKKCHmiDgY1r1I5vf5cRFVSqdFbcVqaEQ0Ynax/ZaA2Os8vYGUueuTYyxIB2Oz08pife8DKVxFJHwClpY6bikn7t8i/h8/sBzlgFBzL7GNi/uyKy6DOJnsRVnTY/XBOrLh3D2Xshd/mxdUA8GcrXXXioojYT5/Kz9U63O6mxGrwX/hKEjefWiR27zhF7/GkFH/0QsR42b5r7ZbzrhDRH4BdtmBAft2q4KJE1FBNXMHIAQ+1bSbE1v2vVW1RjiLWtcENTaME0hT3RgLP2+cYyEbtqiwvIKgPDaMRmd4+H0p3/QEJWmB1Vzp5lV5qsLGK4DTNDC7GTa9F3++LltOZBHwGvSXa76tLaZcvji39qFOlqpwsa7x8UHVQcgO74aoXY/bD5X4xIPqbz4RWQ/wtkY22GTTafo2wjrmBDk6otulxLGGCKatZMzZ2ZP4h8HDX1c5XZbHy0A4eqK2RwqsacolOg8NfyXM4PZhUTMQ6GdbQPL278EUR/3s9k6BU+4ZxP/ssKNaWeYMg/X4dtFFC/0KXbSPflqi0A6xSZ6NSVcTSkGkU8lRWY56BP9xg1s0EQbtaHOrN4FvXfwKdzl84n+7hXmaK//v60zF4Zd6TKZlyB6oRU75vRXPDaqoQ+lRH4krktG8W6RnM+bl/+hNsX7UuAAn03mPJls+PgupvyAqHCfmFet2exvxQMV7bvOoX3n5B6hklMgNCIZRoUrmX9I217DsaWPGwpH8mLxBfpwp9OzTcNHy1hVjPfmijLdi6h3qSUE77QMg9/GOyz7d128XU8xDraiVmn4YQ4n/p9aedCXiKeUJUtQiMaw9j0QC2F7Nj4wZk0q2o8fsWnEh35gRC7ji77bpatUO65dzjtQ80lfUfUJeS7y6oC2hNiC1P+p7KpWOe+GmgE291qbtbV2CDcMR65XDXdiycG dS8L9jqu RvMfTjs4qAb+NSDapHB1ecgQv0SrOEgJNrCUJLVQHrxZuW2rG/2K1+PZ6h6SDMBW21nNA4CImG4z65rW3QE5nL7mWWV+eJ1oZjGOBBqrYhoP4s7F7TPyxITJmDFL1HzYtsjylQPF0TJg1om5vzFUcDxSNh2MorGA3Z6tpXnR5TM/Wvhw5dw4IMbI1yflSyVyVxXtJqwHIdCqlYhVCXgsoezy6LvMhTRKfMKalFc7nRJ2QjhGYQdsVhjvqtrmxGsR8L61GeOzSJIETAhmV6gEV3FXCBzp3VBjld0OEuVrqnkpaRFA1nLzRcg2wHTZcxsw6s5/syAdpfc7c48HgnW/8VKybOFzXnqo/i92P2LTbhyAer+o= 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: List-Subscribe: List-Unsubscribe: Am Freitag, dem 16.08.2024 um 12:33 +0100 schrieb Lorenzo Stoakes: > On Fri, Aug 16, 2024 at 01:13:41PM GMT, Bert Karwatzki wrote: > > Since the v5 patchset some changes have taken place in the linux-next = tree > > which make it impossible to cleanly apply that patchset. The most impo= rtant > > of these changes is the splitting of the mm/mmap.c into mm/mmap.c and = mm/vma.c > > and the splitting of mm/internal.h into mm/internal.h and mm/vma.h. Al= so > > arch_unmap() has already been removed from mm/mmap.c in next-20240816 = so > > there's no need to take care of that. > > > > When testing this with `stress-ng --vm-segv 1` dmesg show errors like > > > > [ T3753] coredump: 3753(stress-ng-vm-se): over coredump resource li= mit, skipping core dump > > [ T3753] coredump: 3753(stress-ng-vm-se): coredump has not been cre= ated, error -7 > > [ T3754] coredump: 3754(stress-ng-vm-se): over coredump resource li= mit, skipping core dump > > [ T3754] coredump: 3754(stress-ng-vm-se): coredump has not been cre= ated, error -7 > > [...] > > > > this is most likely not a problem of the patchset but instead caused b= y > > a more verbose coredump introduced in the following patch: > > https://lore.kernel.org/all/20240718182743.1959160-3-romank@linux.micr= osoft.com/ > > > > Changes since v4: > > - rebase on next-20240816 > > - some functions which were static in the original v5 patchset > > are now non-static as they're used in both mmap.c and vma.c > > (an alternative approach to this would have been to leave > > them as "static inline" and put them into vma.h (at least if > > they're only used in mmap.c and vma.c)) > > > > Bert Karwatzki > > > > Liam R. Howlett (19): > > mm/mmap: Correctly position vma_iterator in __split_vma() > > mm/mmap: Introduce abort_munmap_vmas() > > mm/mmap: Introduce vmi_complete_munmap_vmas() > > mm/mmap: Extract the gathering of vmas from do_vmi_align_munmap() > > mm/mmap: Introduce vma_munmap_struct for use in munmap operations > > mm/mmap: Change munmap to use vma_munmap_struct() for accounting and > > surrounding vmas > > mm/mmap: Extract validate_mm() from vma_complete() > > mm/mmap: Inline munmap operation in mmap_region() > > mm/mmap: Expand mmap_region() munmap call > > mm/mmap: Support vma =3D=3D NULL in init_vma_munmap() > > mm/mmap: Reposition vma iterator in mmap_region() > > mm/mmap: Track start and end of munmap in vma_munmap_struct > > mm/mmap: Clean up unmap_region() argument list > > mm/mmap: Avoid zeroing vma tree in mmap_region() > > mm/mmap: Use PHYS_PFN in mmap_region() > > mm/mmap: Use vms accounted pages in mmap_region() > > mm/mmap: Move can_modify_mm() check down the stack > > ipc/shm, mm: Drop do_vma_munmap() > > mm/mmap: Move may_expand_vm() check in mmap_region() > > > > include/linux/mm.h | 6 +- > > ipc/shm.c | 8 +- > > mm/mmap.c | 146 ++++++++--------- > > mm/vma.c | 397 +++++++++++++++++++++++++++++++-------------= - > > mm/vma.h | 61 ++++++- > > 5 files changed, 403 insertions(+), 215 deletions(-) > > > > -- > > 2.45.2 > > > > I appreciate the effort taken in rebasing, but this is quite confusing, > it's like you've re-sent the series (with tags...) as if you were > submitting it, which I'm sure isn't your intent. > > You've also cc'd Andrew as if it were a submission and everybody else on > thread... > > It's probably worth marking the series to make it totally clear you're j= ust > doing this as a favour or for testing purposes (I know you at least chan= ged > the title of the series accordingly). At the very least RFC it... > > Also you should mark that this is based on -next, as mm work is based on > mm-unstable (for this series, likely the same). > > Liam is working on a rebase/rework of the series in parallel also so we > should definitely be careful to avoid any confusion here. > > (Oh and as a side note - please do not send email to my personal address= , > all kernel mail should go to my Oracle one please). > > To avoid any confusion: > > NAK this whole series in this form (+ wait for Liam's next version...) > > Nacked-by: Lorenzo Stoakes Yes, this done for testing purposes (linux-next had several NULL pointer e= rrors (unrelated to the patchset) and as these are resolved since next-20240814,= I wanted to try the patches again, which I last tried on linux-next-20240730= ). I should have taken more care in marking this as unofficial testing. (and = not CC everyone) > (Oh and as a side note - please do not send email to my personal address= , > all kernel mail should go to my Oracle one please). Ok, I just copied it from the Cc of Che old patches (like the other addres= ses.) Also patches 16 to 19 of the set are currently stuck as smtp.web.de curren= tly refuses to send them. Bert Karwatzki