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 929D3E77173 for ; Fri, 6 Dec 2024 14:52:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1084D6B028C; Fri, 6 Dec 2024 09:52:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B8F46B028D; Fri, 6 Dec 2024 09:52:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE8F16B028E; Fri, 6 Dec 2024 09:52:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D19F66B028C for ; Fri, 6 Dec 2024 09:52:23 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 65AC7407AC for ; Fri, 6 Dec 2024 14:52:23 +0000 (UTC) X-FDA: 82864823748.17.45787B5 Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by imf25.hostedemail.com (Postfix) with ESMTP id 313E7A000C for ; Fri, 6 Dec 2024 14:52:08 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=morinfr.org header.s=20170427 header.b=PxFerdCI; spf=pass (imf25.hostedemail.com: domain of guillaume@morinfr.org designates 212.27.42.2 as permitted sender) smtp.mailfrom=guillaume@morinfr.org; dmarc=pass (policy=quarantine) header.from=morinfr.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733496734; 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=Z0V41C+el6ZxU+5bWs0t+oix5z85dABjQe8DaTTtBhM=; b=ptuhVX5WKI3QoGldf6gcr7UMrICGVIUBGiC8OKqZ0rzQ7gn8tHFYBjiVZZuZ+1BxE1r1E6 G0UOMXSITvJ6TKtMCsXaHiZD6QwBll4YIG9bqXpYFb6+Gw0fejXQqaVN0llIw+JFXlXvT9 6vMPz1dAz7gl9svwAmG/pjBcvzTjdvs= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=morinfr.org header.s=20170427 header.b=PxFerdCI; spf=pass (imf25.hostedemail.com: domain of guillaume@morinfr.org designates 212.27.42.2 as permitted sender) smtp.mailfrom=guillaume@morinfr.org; dmarc=pass (policy=quarantine) header.from=morinfr.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733496734; a=rsa-sha256; cv=none; b=Nv0UTW2FfmcoS6cvXOChvjJ4tkjl/3jxpHDvtMWK7iZW0Oy3qBpAWRBlRNYexi6WGG/DNj Mcksw+zza9DZArW8XctVPiEuYbZsXUap45pzc1QDBfuNk8HOPtHUOdqjABfFboU3awgnxz yOGMERzSLybLCq4sasKdwpOLWwB2XE4= Received: from bender.morinfr.org (unknown [82.66.66.112]) by smtp2-g21.free.fr (Postfix) with ESMTPS id 64F5B2003CA; Fri, 6 Dec 2024 15:52:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=morinfr.org ; s=20170427; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Z0V41C+el6ZxU+5bWs0t+oix5z85dABjQe8DaTTtBhM=; b=PxFerdCIiCaY8kBwiLnLtlVvpK hUKVkQWTVJ8G8cruN1Y9qYkReotnK48NHn0Kyfrr2LSNaq4Bca4cMHMSOb5PcwP5Yew5H+1+HbOwa OWVcvvwSaM6fKsny5CFzJojc9T0RiEW5aTHr2mo8uflPzIpQVESFbFqv1Q1XB7wLZHKY=; Received: from guillaum by bender.morinfr.org with local (Exim 4.96) (envelope-from ) id 1tJZgc-002J1j-1t; Fri, 06 Dec 2024 15:52:06 +0100 Date: Fri, 6 Dec 2024 15:52:06 +0100 From: Guillaume Morin To: David Hildenbrand Cc: Heiko Carstens , Guillaume Morin , Nathan Chancellor , Vasily Gorbik , Alexander Gordeev , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Muchun Song , Andrew Morton , Peter Xu , Eric Hagberg , linux-s390@vger.kernel.org Subject: Re: [PATCH v3] mm/hugetlb: support FOLL_FORCE|FOLL_WRITE Message-ID: References: <20241206045019.GA2215843@thelio-3990X> <20241206092453.9026-A-hca@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 313E7A000C X-Stat-Signature: enfx19c1ymcc91mjg39a6mcaymipodyr X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1733496728-166853 X-HE-Meta: U2FsdGVkX1/9gYE2oQvTx14uv0jZr9HgNPCEpUvfHUsbkKujqOLi9jxw4ed6NFoGQi7RM6CfSZvoSlT8r78tfusbGBr8/cL1qe9846C+9k3/tPtWm/ms56E1ycKT+/DsKfiGuJYJoswihvvjuco63A1M7Pbav5bijhyN9DVFwoA3w/7UAaxDlJCg6VgYhn6cTHam/hNb8ueZESL+h04A4aNk9pyCJbWYMuyR89zRZzsfOsm8LQHV11i3ytLk16KfYoQr5/dI1Hu0wDIPI6i5fhQIDmb5Y01gyItIhswWYGqojaYsSVcfPUCOLTjkXeoB+uDcxOxkmCEveW822E7rABjV74DDLu6xRvIr5X5HJNMHeH62nkQSAIUGCSFeOXj177b8/kIiB0sb8ge5k/6WuoRbAyaqWUOUmJCH+QDU6NQYdEy588XFsOqMLJQx/AzZmcNfqytgUH2/IrpH/l5V9jVX0JXYF80vxqONGfXJyD3m5Z/TvgXy3vd+C/Um28WkNC5IIPe6INpjw81Lk2ELrvBafqx+j8nh/zXZCF7NO4eTq+XUCYh/YS1HkK6eRh15D5jAhKIqOTUAf+Gm2WoJPmlJ64COAD1IjJEUQq+99xNnDGnwK9vi8yuX0W9CEKDU8pjKCmmk60ljY71EmmEdYqvOSl3ORoeifQnySva6VlAlz7+3AIl9V3uxPbZdEgZCUmkd+1LxcuyzrAFuXSz/veHzfjgtV7Hc5ZzjNuvCkz4LSB2AOKtzykGmI1dyc2rxK5J23g6pKYrRVIV7YeFpKgbTtiB95OUby+uvKJBMnNlPhMTevyBIPAOzvt4ns4f7+bq8uw8YgGn1I7fJUfONqxtIjYKxdH2VKM6GhowytFYANfrW0lWrjERbVaRrAeuDRkyhU0hn/Hu8TLk5HvlqlFFK/D2Mhq6Qdam6Cpv/m4xDmNiZa3k1UP6vap5v2b9zqlQ80oso8EmPwjWoa+d PqzovoN9 HdPuVbHFiLJJwvHKnMwSdC8y/2P+UEnrMkuHv3ee/QecjwYKvzzoQuocFVOt0I8LQ40biebvTQPX5wp5cq0uQKERY7DYrnC+CS5b8X02+aJxTUZ0Pi+XpTIjJYgs400kHbvHQT5TQ2WEMcre+898WHk/A+bZIy3R+SxE2uCDLXHrpQZ05ql0GCEXWxsZutQF0EIq0jZDMQdBeTAMgvd8/FdFuVafyrgv8Wo9SGjrqBH/MewgJhUYCSq9nkMzWuoK4/csw8BqkkTxFoNNpjD5rZU6bUWJq3vSFhkw1zr6Lld8vkxK7K2uRAuA9PtFSBvMut5hsAogKDrSS8rEx5UiFxXeoWf9ghKcs0exX X-Bogosity: Ham, tests=bogofilter, spamicity=0.000901, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 06 Dec 10:29, David Hildenbrand wrote: > > On 06.12.24 10:24, Heiko Carstens wrote: > > On Fri, Dec 06, 2024 at 06:27:09AM +0100, Guillaume Morin wrote: > > > On 05 Dec 21:50, Nathan Chancellor wrote: > > > > This looks to be one of the first uses of pud_soft_dirty() in a generic > > > > part of the tree from what I can tell, which shows that s390 is lacking > > > > it despite setting CONFIG_HAVE_ARCH_SOFT_DIRTY: > > > > > > > > $ make -skj"$(nproc)" ARCH=s390 CROSS_COMPILE=s390-linux- mrproper defconfig mm/gup.o > > > > mm/gup.c: In function 'can_follow_write_pud': > > > > mm/gup.c:665:48: error: implicit declaration of function 'pud_soft_dirty'; did you mean 'pmd_soft_dirty'? [-Wimplicit-function-declaration] > > > > 665 | return !vma_soft_dirty_enabled(vma) || pud_soft_dirty(pud); > > > > | ^~~~~~~~~~~~~~ > > > > | pmd_soft_dirty > > > > > > > > Is this expected? > > > > > > Yikes! It does look like an oversight in the s390 code since as you said > > > it has CONFIG_HAVE_ARCH_SOFT_DIRTY and pud_mkdirty seems to be setting > > > _REGION3_ENTRY_SOFT_DIRTY. But I'll let the s390 folks opine. > > > > > > I don't mind dropping the pud part of the change (even if that's a bit > > > of a shame) if it's causing too many issues. > > > > It would be quite easy to add pud_soft_dirty() etc. helper functions > > for s390, but I think that would be the wrong answer to this problem. > > > > s390 implements pud_mkdirty(), but it is only used in the context of > > HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD, which s390 doesn't support. So > > this function should probably be removed from s390's pgtable.h. > > > > Similar the pud_soft_dirty() and friends helper functions should only > > be implemented if common code support for soft dirty would exist, > > which is currently not the case. Otherwise similar fallbacks like for > > pmd_soft_dirty() (-> include/linux/pgtable.h) would also need to be > > implemented. > > > > So IMHO the right fix (at this time) seems to be to remove the above > > pud part of your patch, and in addition we should probably also drop > > the partially implemented pud level soft dirty bits in s390 code, > > since that is dead code and might cause even more confusion in future. > > > > Does that make sense? > > As hugetlb does not support softdirty, and PUDs are currently only possible > (weird DAX thing put aside) with hugetlb, it makes sense to drop the pud > softdirty thingy. Thanks all. I dropped the check and the dummy definition I had to add for i386 in v4 [1] [1] https://lore.kernel.org/linux-mm/Z1MO5slZh8uWl8LH@bender.morinfr.org/T/#u -- Guillaume Morin