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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2ED68CCA47E for ; Wed, 8 Jun 2022 10:14:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236300AbiFHKOx (ORCPT ); Wed, 8 Jun 2022 06:14:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236397AbiFHKNM (ORCPT ); Wed, 8 Jun 2022 06:13:12 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 382A521D4B2 for ; Wed, 8 Jun 2022 02:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654682376; h=from:from: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; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=HTgr1iTc2yNBJ1TMG1abAXJSSpfxGYB6q8DDg6rnb5L77rqSUjLmyMcw5MKS9W8Bqf+0lQ ibC36RSLfFLbCsI4FDLUl0aYLyQa6T26wEi9aO21DVIT3Gz7UrtMwowP+cKEuztqrX1UQe 1eaWq5xsDk+ZtqJ0xrl8XsuNvnaiHOY= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-34-YKyQ962ENRK2K0vH4fKpfw-1; Wed, 08 Jun 2022 05:59:35 -0400 X-MC-Unique: YKyQ962ENRK2K0vH4fKpfw-1 Received: by mail-wm1-f71.google.com with SMTP id u12-20020a05600c19cc00b0038ec265155fso14184579wmq.6 for ; Wed, 08 Jun 2022 02:59:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=S0zWnzEl6yA/0J9m9alj2uTjOT/QRoAFMdJ78DZUtuUfl9vCnnjdDpyAmPdxSdNmEs r+0E2WK7TrzSb8wE0ZCN36yMkNrHoUnf9tRCEc3QBrXmE/XfDZo19+vVCvvlF7pTsxsO 8TWWUQMb1ZGk8GwgbUBoe8rbJ7YngABr3tmuNh6rLud29HMBynoFCdCzQTlwp0TakXwp XzxgzcIlerPwcttGgEwVRp+pJuorX+C9Lnm91dMUGxbYaOArhHPHaWqe754vn4rODGq3 LFzyvrEv/yxDvGITi2wmuBFdUMYYx6cVuLCS4FFhIDz2UkNXKIyxBwclpL4qTq5bM035 hBHw== X-Gm-Message-State: AOAM533mSwfpP7tphjnNd9YAN+uhcL2xn4oGN4Me20EiH4ZtCE80TnRY nJ8JGylBWSYL3cBcBrWE3BsX5Tgi195O0/RrWP6nCfqzZBS23h3ZyE/HXmVSqSMZxJeyQ7EZbuT SPd5HKLFiReQriejS4HauN9M= X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665188wmg.102.1654682374066; Wed, 08 Jun 2022 02:59:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4BCTXIM51kCwL6Z6H/hpvqsMvzu1fv9X/GhiUOzp5r00CIAo0BKvmPAyhZ/PubqP5kGP1SQ== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665171wmg.102.1654682373804; Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:ad00:db2:4c6:8f3a:2ec4? (p200300cbc705ad000db204c68f3a2ec4.dip0.t-ipconnect.de. [2003:cb:c705:ad00:db2:4c6:8f3a:2ec4]) by smtp.gmail.com with ESMTPSA id p19-20020a05600c1d9300b003942a244f39sm2898272wms.18.2022.06.08.02.59.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Message-ID: <36cc5e2b-b768-ce1c-fa30-72a932587289@redhat.com> Date: Wed, 8 Jun 2022 11:59:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-aio@kvack.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org, virtualization@lists.linux-foundation.org, Minchan Kim , Rafael Aquini References: <20220606204050.2625949-1-willy@infradead.org> <20220606204050.2625949-16-willy@infradead.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 15/20] balloon: Convert to migrate_folio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 07.06.22 21:21, Matthew Wilcox wrote: > On Tue, Jun 07, 2022 at 03:24:15PM +0100, Matthew Wilcox wrote: >> On Tue, Jun 07, 2022 at 09:36:21AM +0200, David Hildenbrand wrote: >>> On 06.06.22 22:40, Matthew Wilcox (Oracle) wrote: >>>> const struct address_space_operations balloon_aops = { >>>> - .migratepage = balloon_page_migrate, >>>> + .migrate_folio = balloon_migrate_folio, >>>> .isolate_page = balloon_page_isolate, >>>> .putback_page = balloon_page_putback, >>>> }; >>> >>> I assume you're working on conversion of the other callbacks as well, >>> because otherwise, this ends up looking a bit inconsistent and confusing :) >> >> My intention was to finish converting aops for the next merge window. >> >> However, it seems to me that we goofed back in 2016 by merging >> commit bda807d44454. isolate_page() and putback_page() should >> never have been part of address_space_operations. >> >> I'm about to embark on creating a new migrate_operations struct >> for drivers to use that contains only isolate/putback/migrate. >> No filesystem uses isolate/putback, so those can just be deleted. >> Both migrate_operations & address_space_operations will contain a >> migrate callback. That makes sense to me. I wonder if there was a design decision/discussion behind that. CCing Rafael. @Rafael, full mail at https://lkml.kernel.org/r/Yp+lU55H4igaV3pB@casper.infradead.org > > Well, that went more smoothly than I thought it would. > > I can't see a nice way to split this patch up (other than making secretmem > its own patch). We just don't have enough bits in struct page to support > both ways of handling PageMovable at the same time, so we can't convert > one driver at a time. The diffstat is pretty compelling. Yes, splitting rather overcomplicates stuff. > > The patch is on top of this patch series; I think it probably makes > sense to shuffle it to be first, to avoid changing these drivers to > folios, then changing them back. Absolutely. > > Questions: > > Is what I've done with zsmalloc acceptable? The locking in that > file is rather complex. > > Can we now eliminate balloon_mnt / balloon_fs from cmm.c? I haven't even > compiled thatfile , but it seems like the filesystem serves no use now. > > Similar question for vmw_balloon.c, although I have compiled that. IIRC, virtio-balloon, cmm and vmw_balloon all have the mnt/fs just for page migration purposes. So if one can get rid of them, all should be able to get rid of them. Essentially everything that uses the balloon compaction framework. That should go into separate patches then. > > --- > > I just spotted a bug with zs_unregister_migration(); it won't compile > without CONFIG_MIGRATION. I'll fix that up if the general approach is > acceptable. > > arch/powerpc/platforms/pseries/cmm.c | 13 -------- > drivers/misc/vmw_balloon.c | 10 ------ > include/linux/balloon_compaction.h | 6 +--- > include/linux/fs.h | 2 - > include/linux/migrate.h | 27 ++++++++++++++---- > include/linux/page-flags.h | 2 - > mm/balloon_compaction.c | 18 ++++++------ > mm/compaction.c | 29 ++++++++----------- > mm/migrate.c | 23 ++++++++------- > mm/secretmem.c | 6 ---- > mm/util.c | 4 +- > mm/z3fold.c | 45 ++++++------------------------ > mm/zsmalloc.c | 52 +++++++++-------------------------- > 13 files changed, 83 insertions(+), 154 deletions(-) > > diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c > index 15ed8206c463..2ecbab3db723 100644 > --- a/arch/powerpc/platforms/pseries/cmm.c > +++ b/arch/powerpc/platforms/pseries/cmm.c > @@ -578,23 +578,10 @@ static int cmm_balloon_compaction_init(void) > return rc; > } > > - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb); > - if (IS_ERR(b_dev_info.inode)) { > - rc = PTR_ERR(b_dev_info.inode); > - b_dev_info.inode = NULL; > - kern_unmount(balloon_mnt); > - balloon_mnt = NULL; > - return rc; > - } > - > - b_dev_info.inode->i_mapping->a_ops = &balloon_aops; Are you missing similar updates to drivers/virtio/virtio_balloon.c ? At least, there we're also using balloon_aops, so this patch shouldn't compile. Skimming over it, nothing else jumped at me. -- Thanks, David / dhildenb 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 smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 63AC2C43334 for ; Wed, 8 Jun 2022 09:59:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 059FF40103; Wed, 8 Jun 2022 09:59:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDfUGNFZ7Q60; Wed, 8 Jun 2022 09:59:42 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8598840025; Wed, 8 Jun 2022 09:59:41 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5812AC0032; Wed, 8 Jun 2022 09:59:41 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9D30DC002D for ; Wed, 8 Jun 2022 09:59:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 8B075400F3 for ; Wed, 8 Jun 2022 09:59:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQmoxHh3yeOL for ; Wed, 8 Jun 2022 09:59:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by smtp2.osuosl.org (Postfix) with ESMTPS id 7404840025 for ; Wed, 8 Jun 2022 09:59:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654682378; h=from:from: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; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=VaxoQa74af1KpBUfmYVcmRpHxUBU73u40BqwdLOciO6zi09uLfV8SFOJIzsZvUiWmGRBte pVScgcOnTr2fbdx/xfEe21XK+wko0i7sUburY16pt3SZOBspJIA2BVV/L+TL0Nvi6EFJXK TnmxPLhFRPltOknj5hWKKjUVs+44CuI= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-618-Lt-JhEvEPtCbhL4XFso1SQ-1; Wed, 08 Jun 2022 05:59:35 -0400 X-MC-Unique: Lt-JhEvEPtCbhL4XFso1SQ-1 Received: by mail-wm1-f72.google.com with SMTP id z13-20020a7bc7cd000000b0039c4a238eadso2482226wmk.9 for ; Wed, 08 Jun 2022 02:59:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=NcJNPk521hS+Cn+WXPSTMqMIlE7MjgSmaJgPoLTQEQcVSvv8avdVK9+wgZqBsAfBu7 jIJHxssscYa8UNWhykY4jjZIunsxYL+1txViSCQ7jbPoi8Xs+h1BKTQTccpjD9fjV7n/ HeX3h851mhm0COW5hxx8DVRIFWK8LbI3grCLWmpXkPzIgIYCp3ilXRBo630XoNd9Mh+f 5IfSenXaeB/5MNi0ZnrtVVnaMpuwuOIPHkaP4p30Zd8fQzjbMrJY+tqTOSFnwxZFSBt7 0eeTrb3fUlB61Ei2IGkFPzulN2i2eE2ohBA5MCc7pLRztvmezy78/unj4DsJRGBg6uAA c2ew== X-Gm-Message-State: AOAM533PT++oJ6i6VfdrjwRDSdS88fDTBhmkvd3YJHVQ8PXko3iFC75d 0Z+bkL/MFQlplYubx0gNTti3PBbFlJAm1ckEWSc+/Y9b9gi3mayFi0HMaytWhjCgV9iwJyIMAir aYOTyDfE+33nbcUBz0zTNPNRZAJzfAdICe78vbnJ8cA== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665201wmg.102.1654682374082; Wed, 08 Jun 2022 02:59:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4BCTXIM51kCwL6Z6H/hpvqsMvzu1fv9X/GhiUOzp5r00CIAo0BKvmPAyhZ/PubqP5kGP1SQ== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665171wmg.102.1654682373804; Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:ad00:db2:4c6:8f3a:2ec4? (p200300cbc705ad000db204c68f3a2ec4.dip0.t-ipconnect.de. [2003:cb:c705:ad00:db2:4c6:8f3a:2ec4]) by smtp.gmail.com with ESMTPSA id p19-20020a05600c1d9300b003942a244f39sm2898272wms.18.2022.06.08.02.59.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Message-ID: <36cc5e2b-b768-ce1c-fa30-72a932587289@redhat.com> Date: Wed, 8 Jun 2022 11:59:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: Matthew Wilcox References: <20220606204050.2625949-1-willy@infradead.org> <20220606204050.2625949-16-willy@infradead.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 15/20] balloon: Convert to migrate_folio In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Cc: linux-aio@kvack.org, linux-nfs@vger.kernel.org, cluster-devel@redhat.com, Rafael Aquini , Minchan Kim , linux-ntfs-dev@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-block@vger.kernel.org, linux-mm@kvack.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On 07.06.22 21:21, Matthew Wilcox wrote: > On Tue, Jun 07, 2022 at 03:24:15PM +0100, Matthew Wilcox wrote: >> On Tue, Jun 07, 2022 at 09:36:21AM +0200, David Hildenbrand wrote: >>> On 06.06.22 22:40, Matthew Wilcox (Oracle) wrote: >>>> const struct address_space_operations balloon_aops = { >>>> - .migratepage = balloon_page_migrate, >>>> + .migrate_folio = balloon_migrate_folio, >>>> .isolate_page = balloon_page_isolate, >>>> .putback_page = balloon_page_putback, >>>> }; >>> >>> I assume you're working on conversion of the other callbacks as well, >>> because otherwise, this ends up looking a bit inconsistent and confusing :) >> >> My intention was to finish converting aops for the next merge window. >> >> However, it seems to me that we goofed back in 2016 by merging >> commit bda807d44454. isolate_page() and putback_page() should >> never have been part of address_space_operations. >> >> I'm about to embark on creating a new migrate_operations struct >> for drivers to use that contains only isolate/putback/migrate. >> No filesystem uses isolate/putback, so those can just be deleted. >> Both migrate_operations & address_space_operations will contain a >> migrate callback. That makes sense to me. I wonder if there was a design decision/discussion behind that. CCing Rafael. @Rafael, full mail at https://lkml.kernel.org/r/Yp+lU55H4igaV3pB@casper.infradead.org > > Well, that went more smoothly than I thought it would. > > I can't see a nice way to split this patch up (other than making secretmem > its own patch). We just don't have enough bits in struct page to support > both ways of handling PageMovable at the same time, so we can't convert > one driver at a time. The diffstat is pretty compelling. Yes, splitting rather overcomplicates stuff. > > The patch is on top of this patch series; I think it probably makes > sense to shuffle it to be first, to avoid changing these drivers to > folios, then changing them back. Absolutely. > > Questions: > > Is what I've done with zsmalloc acceptable? The locking in that > file is rather complex. > > Can we now eliminate balloon_mnt / balloon_fs from cmm.c? I haven't even > compiled thatfile , but it seems like the filesystem serves no use now. > > Similar question for vmw_balloon.c, although I have compiled that. IIRC, virtio-balloon, cmm and vmw_balloon all have the mnt/fs just for page migration purposes. So if one can get rid of them, all should be able to get rid of them. Essentially everything that uses the balloon compaction framework. That should go into separate patches then. > > --- > > I just spotted a bug with zs_unregister_migration(); it won't compile > without CONFIG_MIGRATION. I'll fix that up if the general approach is > acceptable. > > arch/powerpc/platforms/pseries/cmm.c | 13 -------- > drivers/misc/vmw_balloon.c | 10 ------ > include/linux/balloon_compaction.h | 6 +--- > include/linux/fs.h | 2 - > include/linux/migrate.h | 27 ++++++++++++++---- > include/linux/page-flags.h | 2 - > mm/balloon_compaction.c | 18 ++++++------ > mm/compaction.c | 29 ++++++++----------- > mm/migrate.c | 23 ++++++++------- > mm/secretmem.c | 6 ---- > mm/util.c | 4 +- > mm/z3fold.c | 45 ++++++------------------------ > mm/zsmalloc.c | 52 +++++++++-------------------------- > 13 files changed, 83 insertions(+), 154 deletions(-) > > diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c > index 15ed8206c463..2ecbab3db723 100644 > --- a/arch/powerpc/platforms/pseries/cmm.c > +++ b/arch/powerpc/platforms/pseries/cmm.c > @@ -578,23 +578,10 @@ static int cmm_balloon_compaction_init(void) > return rc; > } > > - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb); > - if (IS_ERR(b_dev_info.inode)) { > - rc = PTR_ERR(b_dev_info.inode); > - b_dev_info.inode = NULL; > - kern_unmount(balloon_mnt); > - balloon_mnt = NULL; > - return rc; > - } > - > - b_dev_info.inode->i_mapping->a_ops = &balloon_aops; Are you missing similar updates to drivers/virtio/virtio_balloon.c ? At least, there we're also using balloon_aops, so this patch shouldn't compile. Skimming over it, nothing else jumped at me. -- Thanks, David / dhildenb _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization 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 aib29ajc245.phx1.oracleemaildelivery.com (aib29ajc245.phx1.oracleemaildelivery.com [192.29.103.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8E19ECCA486 for ; Wed, 8 Jun 2022 09:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=oss-phx-1109; d=oss.oracle.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=PJSB8c5mgdmbLMeAgTCzIl0TNLjzqaHpJ7qmD+OSiSc=; b=Gv2Qy8y3zb6GZY2s4LEKLPkJBWx3lQUQYMVIDPh0cWmNd8BBgc4ehoP+Dt8A6oZQ4PV3OEqOEvpJ YiJ+V66/9yox+ozQyliI4j1eKRnoBM3Q2yNA30NU5fggY1dLzVdrovcjf5/eHSq7s7217hMK7xTt cOSQJmXLgXrq1laSKitNDyoFh4Uqth7knGjgG7urYdslkCGZ7TlYHlhmE3kqhDiADRNXxMdFwQQD kXdBczbg8Aqk5uYvNr94LrVp0Y0zz4ZY0sbJJnT/8lJlgDsToekdO3d4kGQwOilSA1PIGkXJweg4 KxfI/HDI9anJFqytAuL3MSbs7rV0/MHtdWtnUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=prod-phx-20191217; d=phx1.rp.oracleemaildelivery.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=PJSB8c5mgdmbLMeAgTCzIl0TNLjzqaHpJ7qmD+OSiSc=; b=TAZhG6D0utOiILodN1hvvFsayDQgmr3WyvjroGJwjI+TJBI/VzfymYLupa7R/FHeOMzcPA0/6mWy KCyKv/740usY7/NTtWP/og8V7siUFX65N5+bOs08FYHTIRXymtayhUgRK98Jq3z3eZMmFkGXWODj 6hsIG4RtsgPH/lmnB1XUtYsm+Nvxbctb13GS/ArRUKAh0wgZ8G86ctuAwEADdNUWdE+0nmdhvUzX f7dMQkJ8SJ4R9qEuEEVlm52ZcXeG3YEsG4U9Iya4ThZEb/bX0u5B0OoQb7bF0sH9I3V+nO584xqB hVmBhd7kPRCFjGjK2O0n9kewZr7eQSr/tRTzqw== Received: by omta-ad1-fd1-102-us-phoenix-1.omtaad1.vcndpphx.oraclevcn.com (Oracle Communications Messaging Server 8.1.0.1.20220517 64bit (built May 17 2022)) with ESMTPS id <0RD500BEWL3XMCC0@omta-ad1-fd1-102-us-phoenix-1.omtaad1.vcndpphx.oraclevcn.com> for ocfs2-devel@archiver.kernel.org; Wed, 08 Jun 2022 09:59:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654682378; h=from:from: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; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=VaxoQa74af1KpBUfmYVcmRpHxUBU73u40BqwdLOciO6zi09uLfV8SFOJIzsZvUiWmGRBte pVScgcOnTr2fbdx/xfEe21XK+wko0i7sUburY16pt3SZOBspJIA2BVV/L+TL0Nvi6EFJXK TnmxPLhFRPltOknj5hWKKjUVs+44CuI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=zHi8w15SE9HuNxlPhrVYBQ2h8UMGoM92P5Y3XKpvk4LhKnjZgTzpPi0rY4xXW0cHLC AEnFu2rLdFXRuhdJghy/vb3+/3wXQ6AzypClqd3v4vacs1age7uahkxaC+JXe8O2sXGQ DaaOj0z6A/lauO36mRUdfWZ6eoxPR72BLqryW/MdhKJ+/OuvF/g13lBW19KbfxB9VCaF qKanqxcc691zCTE6jMIfmmGfqYWGLIDRuxFny1JTebsZEl2HR6491UhO1RNzK11+l2Tr 6ZqcXbyMlLdVLNK2tyJ6I9etUCpuxeVxc0iWBOqHncf8kITb5JzGr9xZIQomPeSKevDd s5gw== X-Gm-Message-State: AOAM530H81XMi5TEGg2/GO7vBBlqqLO/6HMO6QNXCz4QyncppgUGVz7k 62I6Fr39kyV38vHSzBizvO7myrpdycOF+8ZVmQl69SZOiP6dUkHzp0zxHybqKBSL285umrZKntw qQWoSHH7Im3uCqfKeoZ0aEw== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665196wmg.102.1654682374071; Wed, 08 Jun 2022 02:59:34 -0700 (PDT) X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665171wmg.102.1654682373804; Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Message-id: <36cc5e2b-b768-ce1c-fa30-72a932587289@redhat.com> Date: Wed, 8 Jun 2022 11:59:31 +0200 MIME-version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: Matthew Wilcox References: <20220606204050.2625949-1-willy@infradead.org> <20220606204050.2625949-16-willy@infradead.org> Organization: Red Hat In-reply-to: Authentication-results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com Content-language: en-US X-Source-IP: 170.10.129.124 X-Proofpoint-Virus-Version: vendor=nai engine=6400 definitions=10371 signatures=594849 Cc: linux-aio@kvack.org, linux-nfs@vger.kernel.org, cluster-devel@redhat.com, Rafael Aquini , Minchan Kim , linux-ntfs-dev@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-block@vger.kernel.org, linux-mm@kvack.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org Subject: Re: [Ocfs2-devel] [PATCH 15/20] balloon: Convert to migrate_folio X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: David Hildenbrand via Ocfs2-devel Reply-to: David Hildenbrand Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Errors-to: ocfs2-devel-bounces@oss.oracle.com X-MC-Unique: CBFm46LWO6eSJeK3nKdkFQ-1 X-Google-Smtp-Source: ABdhPJw4BCTXIM51kCwL6Z6H/hpvqsMvzu1fv9X/GhiUOzp5r00CIAo0BKvmPAyhZ/PubqP5kGP1SQ== X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 ip4:103.23.64.2 ip4:103.23.65.2 ip4:103.23.66.26 ip4:103.23.67.26 ip4:107.21.15.141 ip4:108.177.8.0/21 ip4:128.17.0.0/20 ip4:128.17.128.0/20 ip4:128.17.192.0/20 ip4:128.17.64.0/20 ip4:128.245.0.0/20 ip4:128.245.64.0/20 ip4:13.110.208.0/21 ip4:13.110.216.0/22 ip4:13.110.224.0/20 ip4:13.111.0.0/16 ip4:136.147.128.0/20 include:spf1.redhat.com -all X-Proofpoint-SPF-VenPass: Allowed X-ServerName: us-smtp-delivery-124.mimecast.com X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 ip4:103.23.64.2 ip4:103.23.65.2 ip4:103.23.66.26 ip4:103.23.67.26 ip4:107.21.15.141 ip4:108.177.8.0/21 ip4:128.17.0.0/20 ip4:128.17.128.0/20 ip4:128.17.192.0/20 ip4:128.17.64.0/20 ip4:128.245.0.0/20 ip4:128.245.64.0/20 ip4:13.110.208.0/21 ip4:13.110.216.0/22 ip4:13.110.224.0/20 ip4:13.111.0.0/16 ip4:136.147.128.0/20 include:spf1.redhat.com -all X-Proofpoint-Spam-Reason: safe X-Spam: OrgSafeList X-SpamRule: orgsafelist X-Proofpoint-ORIG-GUID: Oqs8vmjxDdk-ZkOJwJczZaavKhagvhPT X-Proofpoint-GUID: Oqs8vmjxDdk-ZkOJwJczZaavKhagvhPT Reporting-Meta: AAGnx2XvP9kfm53J79sZUgZo9mEsahRKKgMZ/PZL5jCaXE+wQXiPlIDmsIJFTl+V sVffy4Qw5Oe4rft3XFmzYjnSMScOhMyzmVmtTGxhygWw/cuvJP5ko6o7Qj2xNC24 C/mQOeMckU1rzELZkfh95pJQ4yaROnJKLUvz1IIG/+ZuKiVVkdl+5dzLc7D5Fnji n34rCofIpZOSMFS71WvzjnpGV1UuwHJzQSPj4naKClLGFQgEbUdrs35cRsmrkiQw dkdbe1EBN5IypsJA9RNv2tbIvWSk03U4/NHZr7Aw068Ra3uwVXXq2I/fHdnIveZu cBS6rbABrXccZhYmVqQWqIMJV15vennBJAiEzleyzSExc1x5zRU3gV63KcMTsWmn kBCuPbx/0+/ngaYDU7dTa+cMZsbOxGCvUtxEk4pJEy+6vt10W+J3o90zHFXfgG8w ewe618EbRDveOGNZ1HJRecvbi1ppjY+/nVtVHX487D2mgeozuynsyt+d41bJEmF1 wY1SZmX29kr+OR0pf8DYCwXI9OovfYgZx3NWDkVXBQ9K On 07.06.22 21:21, Matthew Wilcox wrote: > On Tue, Jun 07, 2022 at 03:24:15PM +0100, Matthew Wilcox wrote: >> On Tue, Jun 07, 2022 at 09:36:21AM +0200, David Hildenbrand wrote: >>> On 06.06.22 22:40, Matthew Wilcox (Oracle) wrote: >>>> const struct address_space_operations balloon_aops = { >>>> - .migratepage = balloon_page_migrate, >>>> + .migrate_folio = balloon_migrate_folio, >>>> .isolate_page = balloon_page_isolate, >>>> .putback_page = balloon_page_putback, >>>> }; >>> >>> I assume you're working on conversion of the other callbacks as well, >>> because otherwise, this ends up looking a bit inconsistent and confusing :) >> >> My intention was to finish converting aops for the next merge window. >> >> However, it seems to me that we goofed back in 2016 by merging >> commit bda807d44454. isolate_page() and putback_page() should >> never have been part of address_space_operations. >> >> I'm about to embark on creating a new migrate_operations struct >> for drivers to use that contains only isolate/putback/migrate. >> No filesystem uses isolate/putback, so those can just be deleted. >> Both migrate_operations & address_space_operations will contain a >> migrate callback. That makes sense to me. I wonder if there was a design decision/discussion behind that. CCing Rafael. @Rafael, full mail at https://lkml.kernel.org/r/Yp+lU55H4igaV3pB@casper.infradead.org > > Well, that went more smoothly than I thought it would. > > I can't see a nice way to split this patch up (other than making secretmem > its own patch). We just don't have enough bits in struct page to support > both ways of handling PageMovable at the same time, so we can't convert > one driver at a time. The diffstat is pretty compelling. Yes, splitting rather overcomplicates stuff. > > The patch is on top of this patch series; I think it probably makes > sense to shuffle it to be first, to avoid changing these drivers to > folios, then changing them back. Absolutely. > > Questions: > > Is what I've done with zsmalloc acceptable? The locking in that > file is rather complex. > > Can we now eliminate balloon_mnt / balloon_fs from cmm.c? I haven't even > compiled thatfile , but it seems like the filesystem serves no use now. > > Similar question for vmw_balloon.c, although I have compiled that. IIRC, virtio-balloon, cmm and vmw_balloon all have the mnt/fs just for page migration purposes. So if one can get rid of them, all should be able to get rid of them. Essentially everything that uses the balloon compaction framework. That should go into separate patches then. > > --- > > I just spotted a bug with zs_unregister_migration(); it won't compile > without CONFIG_MIGRATION. I'll fix that up if the general approach is > acceptable. > > arch/powerpc/platforms/pseries/cmm.c | 13 -------- > drivers/misc/vmw_balloon.c | 10 ------ > include/linux/balloon_compaction.h | 6 +--- > include/linux/fs.h | 2 - > include/linux/migrate.h | 27 ++++++++++++++---- > include/linux/page-flags.h | 2 - > mm/balloon_compaction.c | 18 ++++++------ > mm/compaction.c | 29 ++++++++----------- > mm/migrate.c | 23 ++++++++------- > mm/secretmem.c | 6 ---- > mm/util.c | 4 +- > mm/z3fold.c | 45 ++++++------------------------ > mm/zsmalloc.c | 52 +++++++++-------------------------- > 13 files changed, 83 insertions(+), 154 deletions(-) > > diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c > index 15ed8206c463..2ecbab3db723 100644 > --- a/arch/powerpc/platforms/pseries/cmm.c > +++ b/arch/powerpc/platforms/pseries/cmm.c > @@ -578,23 +578,10 @@ static int cmm_balloon_compaction_init(void) > return rc; > } > > - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb); > - if (IS_ERR(b_dev_info.inode)) { > - rc = PTR_ERR(b_dev_info.inode); > - b_dev_info.inode = NULL; > - kern_unmount(balloon_mnt); > - balloon_mnt = NULL; > - return rc; > - } > - > - b_dev_info.inode->i_mapping->a_ops = &balloon_aops; Are you missing similar updates to drivers/virtio/virtio_balloon.c ? At least, there we're also using balloon_aops, so this patch shouldn't compile. Skimming over it, nothing else jumped at me. -- Thanks, David / dhildenb _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B817C433EF for ; Wed, 8 Jun 2022 09:59:49 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nysTc-0002vd-NK; Wed, 08 Jun 2022 09:59:47 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nysTc-0002vX-9g for linux-f2fs-devel@lists.sourceforge.net; Wed, 08 Jun 2022 09:59:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: Subject:From:References:Cc:To:MIME-Version:Date:Message-ID:Sender:Reply-To: 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=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=iLscq6hoEeK5F3ePm2bifjjvKP Scspl/JMd54uU674jjujbffc6wF4lQojfO6D77BCYPm4dzp7NoMEElM+GY/1NrPZYYEhW7IStZ2jI 0Ye1hUnKwnnvKddnbh/syNwZDw70W5kczuSZwh9ntFMR/wtrH/ww3DYX1YAhyD2/zCQ0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From: References:Cc:To:MIME-Version:Date:Message-ID:Sender:Reply-To: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=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=bcnfhBmvE3R0zJqcVlTUdOPGIp 9G20almmulqLdcy2wNJQ7DvYWc49QDGxxFHF8KsWzecCAbrnf1XNlm98/Ca5nWEAl2OdVvXtafoks iwAV2tVQSaWMAs2o2ixRuHPvkTSCwa63FIfBrxhBzYzCld4FI/YKEIOmX58F/1IeZaTs=; Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.94.2) id 1nysTY-009hPJ-1i for linux-f2fs-devel@lists.sourceforge.net; Wed, 08 Jun 2022 09:59:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654682378; h=from:from: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; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=VaxoQa74af1KpBUfmYVcmRpHxUBU73u40BqwdLOciO6zi09uLfV8SFOJIzsZvUiWmGRBte pVScgcOnTr2fbdx/xfEe21XK+wko0i7sUburY16pt3SZOBspJIA2BVV/L+TL0Nvi6EFJXK TnmxPLhFRPltOknj5hWKKjUVs+44CuI= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-34-kEDmoXl7PtmCHuHKfhr3gw-1; Wed, 08 Jun 2022 05:59:35 -0400 X-MC-Unique: kEDmoXl7PtmCHuHKfhr3gw-1 Received: by mail-wm1-f69.google.com with SMTP id i67-20020a1c3b46000000b0039c65f0e4ccso78908wma.2 for ; Wed, 08 Jun 2022 02:59:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=hYHWahTPuIxHmXCm/k9LaMYnTiROT3oqMzk41gtcXRrFNN3cBWBJ5ALagiUD+i7Hrt ++MWZenCWNfgQkwjGOadFPCjOdoOBiaoQNW/j2ecKjSmKt7QW2CYxDE93sXaix0NO9Jh qHYA74ZNXHQm2sfHCLg4xX5t9rlLNIuUZls7fTc32pAMxFBkI/8MpDquUpMT55/eFgiD WBVI61TT5nbBfpdJHEJpOJHWHbmmkJbG/h19zj/BYD8NgwYiutzPt8cTq/iBZoUQsL98 K84Zk0Ca5oEViKqRIcg/6JAIZ6TCzql3vS12t47aIgbdoPxG3wI4jsjBNUhUAhiULFI5 IZJg== X-Gm-Message-State: AOAM53211jrPgWkL+oMYJBk1IUi4K6LhB9GzsKM6f6AdBEn/OucNH9wQ jM41R84DEUAyiWhQuefKP45xham4jvWwfEsJifLRfOWwJElPScY6K51ChMhXpUM2IW2kF3xo61E Bq/cz0MQv4lV0QRLJWVNvrRWQ4woVKKn2oik9yw== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665189wmg.102.1654682374067; Wed, 08 Jun 2022 02:59:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4BCTXIM51kCwL6Z6H/hpvqsMvzu1fv9X/GhiUOzp5r00CIAo0BKvmPAyhZ/PubqP5kGP1SQ== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665171wmg.102.1654682373804; Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:ad00:db2:4c6:8f3a:2ec4? (p200300cbc705ad000db204c68f3a2ec4.dip0.t-ipconnect.de. [2003:cb:c705:ad00:db2:4c6:8f3a:2ec4]) by smtp.gmail.com with ESMTPSA id p19-20020a05600c1d9300b003942a244f39sm2898272wms.18.2022.06.08.02.59.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Message-ID: <36cc5e2b-b768-ce1c-fa30-72a932587289@redhat.com> Date: Wed, 8 Jun 2022 11:59:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: Matthew Wilcox References: <20220606204050.2625949-1-willy@infradead.org> <20220606204050.2625949-16-willy@infradead.org> From: David Hildenbrand Organization: Red Hat In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-Headers-End: 1nysTY-009hPJ-1i Subject: Re: [f2fs-dev] [PATCH 15/20] balloon: Convert to migrate_folio X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-aio@kvack.org, linux-nfs@vger.kernel.org, cluster-devel@redhat.com, Rafael Aquini , Minchan Kim , linux-ntfs-dev@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-block@vger.kernel.org, linux-mm@kvack.org, linux-mtd@lists.infradead.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On 07.06.22 21:21, Matthew Wilcox wrote: > On Tue, Jun 07, 2022 at 03:24:15PM +0100, Matthew Wilcox wrote: >> On Tue, Jun 07, 2022 at 09:36:21AM +0200, David Hildenbrand wrote: >>> On 06.06.22 22:40, Matthew Wilcox (Oracle) wrote: >>>> const struct address_space_operations balloon_aops = { >>>> - .migratepage = balloon_page_migrate, >>>> + .migrate_folio = balloon_migrate_folio, >>>> .isolate_page = balloon_page_isolate, >>>> .putback_page = balloon_page_putback, >>>> }; >>> >>> I assume you're working on conversion of the other callbacks as well, >>> because otherwise, this ends up looking a bit inconsistent and confusing :) >> >> My intention was to finish converting aops for the next merge window. >> >> However, it seems to me that we goofed back in 2016 by merging >> commit bda807d44454. isolate_page() and putback_page() should >> never have been part of address_space_operations. >> >> I'm about to embark on creating a new migrate_operations struct >> for drivers to use that contains only isolate/putback/migrate. >> No filesystem uses isolate/putback, so those can just be deleted. >> Both migrate_operations & address_space_operations will contain a >> migrate callback. That makes sense to me. I wonder if there was a design decision/discussion behind that. CCing Rafael. @Rafael, full mail at https://lkml.kernel.org/r/Yp+lU55H4igaV3pB@casper.infradead.org > > Well, that went more smoothly than I thought it would. > > I can't see a nice way to split this patch up (other than making secretmem > its own patch). We just don't have enough bits in struct page to support > both ways of handling PageMovable at the same time, so we can't convert > one driver at a time. The diffstat is pretty compelling. Yes, splitting rather overcomplicates stuff. > > The patch is on top of this patch series; I think it probably makes > sense to shuffle it to be first, to avoid changing these drivers to > folios, then changing them back. Absolutely. > > Questions: > > Is what I've done with zsmalloc acceptable? The locking in that > file is rather complex. > > Can we now eliminate balloon_mnt / balloon_fs from cmm.c? I haven't even > compiled thatfile , but it seems like the filesystem serves no use now. > > Similar question for vmw_balloon.c, although I have compiled that. IIRC, virtio-balloon, cmm and vmw_balloon all have the mnt/fs just for page migration purposes. So if one can get rid of them, all should be able to get rid of them. Essentially everything that uses the balloon compaction framework. That should go into separate patches then. > > --- > > I just spotted a bug with zs_unregister_migration(); it won't compile > without CONFIG_MIGRATION. I'll fix that up if the general approach is > acceptable. > > arch/powerpc/platforms/pseries/cmm.c | 13 -------- > drivers/misc/vmw_balloon.c | 10 ------ > include/linux/balloon_compaction.h | 6 +--- > include/linux/fs.h | 2 - > include/linux/migrate.h | 27 ++++++++++++++---- > include/linux/page-flags.h | 2 - > mm/balloon_compaction.c | 18 ++++++------ > mm/compaction.c | 29 ++++++++----------- > mm/migrate.c | 23 ++++++++------- > mm/secretmem.c | 6 ---- > mm/util.c | 4 +- > mm/z3fold.c | 45 ++++++------------------------ > mm/zsmalloc.c | 52 +++++++++-------------------------- > 13 files changed, 83 insertions(+), 154 deletions(-) > > diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c > index 15ed8206c463..2ecbab3db723 100644 > --- a/arch/powerpc/platforms/pseries/cmm.c > +++ b/arch/powerpc/platforms/pseries/cmm.c > @@ -578,23 +578,10 @@ static int cmm_balloon_compaction_init(void) > return rc; > } > > - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb); > - if (IS_ERR(b_dev_info.inode)) { > - rc = PTR_ERR(b_dev_info.inode); > - b_dev_info.inode = NULL; > - kern_unmount(balloon_mnt); > - balloon_mnt = NULL; > - return rc; > - } > - > - b_dev_info.inode->i_mapping->a_ops = &balloon_aops; Are you missing similar updates to drivers/virtio/virtio_balloon.c ? At least, there we're also using balloon_aops, so this patch shouldn't compile. Skimming over it, nothing else jumped at me. -- Thanks, David / dhildenb _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 70168C433EF for ; Wed, 8 Jun 2022 10:00:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Subject:From:References:Cc: To:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=uu+78puxDOX+32Tv3s0cqoCCZhvXygNlw+JGZd6nJhQ=; b=ymqS5ItBfXSi2W SUT6atPinQNGDIVOXLQ3fG8HtGpvZ7sbFtnmOtQhQhckr5SeYyWkzh8U0wOL80keBF3H+QnQ5ThiA r5iVJ+VhP3lCyxkQsM3HsFWuqgb+qtH0yNqOUF45dwoF3bLiBfEZJx0qKu0l5i7PsoGbAjBq0fsxb wxQcNfaIHDINvMdk+yV+Qhc77GOnkcs/OaWLDdptVV7WWxAPQIJHS0bqyxcUva0MuFRtiYFlEYV4R 3qdhwZrGuD6qbmga6eM98NGBtOx5CmabkkVkY5HNgkNFlW3lNlQMk0ccLoegWFbExCxwC7IzICzAb dKTMziXaPw0XWxQgacyA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nysTo-00CYGq-As; Wed, 08 Jun 2022 10:00:00 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nysTS-00CY5l-Hu for linux-mtd@lists.infradead.org; Wed, 08 Jun 2022 09:59:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654682376; h=from:from: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; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=HTgr1iTc2yNBJ1TMG1abAXJSSpfxGYB6q8DDg6rnb5L77rqSUjLmyMcw5MKS9W8Bqf+0lQ ibC36RSLfFLbCsI4FDLUl0aYLyQa6T26wEi9aO21DVIT3Gz7UrtMwowP+cKEuztqrX1UQe 1eaWq5xsDk+ZtqJ0xrl8XsuNvnaiHOY= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-27-tqDdN3z4MjKxnl-dj1YMhw-1; Wed, 08 Jun 2022 05:59:35 -0400 X-MC-Unique: tqDdN3z4MjKxnl-dj1YMhw-1 Received: by mail-wm1-f69.google.com with SMTP id bg7-20020a05600c3c8700b0039468585269so6808995wmb.3 for ; Wed, 08 Jun 2022 02:59:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=5EmfKMSqHsJEQbwbYbyNpOoNGS+aBwVbzGMbbCjfqdOT2ZEhU+vzgnQzPjqU+UcOvg NvJX8LJOjJG9Y3mTDP8lVHRb+IeiqznbhRhQWWaSTHdmVKcas3KHdLHHUNw6XIRgcP6/ 0v8thdrrkH5Pg2hg593/heWjXpf9GaUv85abFuYRxJUXFKG0dFtK2cFhcGN7muBvP8eg YO7sdB1SogYzsJ30g6mZx3i+0SqQn048jiXPMVz9vaFnnvqI8CAbB67RfRZxx/03Vn0e IVMJR/Zgk2BVkq2a68sa20GHQdRrdiztI8RKM/0M1FBk3LUWmrDKt7kVKqLAyEf6JN1l FA8Q== X-Gm-Message-State: AOAM530v2qI3/KNBrxkMcaHtUJFTNd8teBr0jKaU945/ZCP9obVNrMEz VFvPsozmEwIX359lu2WW2VNyjUt6G6MHnhAHyy6HPX0T2o9Jh5piDHdp/oj+UP0awgRWeL4IxPg UUVxfPoocQhFP74P/B4lg4tURCA== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665198wmg.102.1654682374071; Wed, 08 Jun 2022 02:59:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4BCTXIM51kCwL6Z6H/hpvqsMvzu1fv9X/GhiUOzp5r00CIAo0BKvmPAyhZ/PubqP5kGP1SQ== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665171wmg.102.1654682373804; Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:ad00:db2:4c6:8f3a:2ec4? (p200300cbc705ad000db204c68f3a2ec4.dip0.t-ipconnect.de. [2003:cb:c705:ad00:db2:4c6:8f3a:2ec4]) by smtp.gmail.com with ESMTPSA id p19-20020a05600c1d9300b003942a244f39sm2898272wms.18.2022.06.08.02.59.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Message-ID: <36cc5e2b-b768-ce1c-fa30-72a932587289@redhat.com> Date: Wed, 8 Jun 2022 11:59:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-aio@kvack.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org, virtualization@lists.linux-foundation.org, Minchan Kim , Rafael Aquini References: <20220606204050.2625949-1-willy@infradead.org> <20220606204050.2625949-16-willy@infradead.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 15/20] balloon: Convert to migrate_folio In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220608_025938_759516_9E81542D X-CRM114-Status: GOOD ( 37.13 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On 07.06.22 21:21, Matthew Wilcox wrote: > On Tue, Jun 07, 2022 at 03:24:15PM +0100, Matthew Wilcox wrote: >> On Tue, Jun 07, 2022 at 09:36:21AM +0200, David Hildenbrand wrote: >>> On 06.06.22 22:40, Matthew Wilcox (Oracle) wrote: >>>> const struct address_space_operations balloon_aops = { >>>> - .migratepage = balloon_page_migrate, >>>> + .migrate_folio = balloon_migrate_folio, >>>> .isolate_page = balloon_page_isolate, >>>> .putback_page = balloon_page_putback, >>>> }; >>> >>> I assume you're working on conversion of the other callbacks as well, >>> because otherwise, this ends up looking a bit inconsistent and confusing :) >> >> My intention was to finish converting aops for the next merge window. >> >> However, it seems to me that we goofed back in 2016 by merging >> commit bda807d44454. isolate_page() and putback_page() should >> never have been part of address_space_operations. >> >> I'm about to embark on creating a new migrate_operations struct >> for drivers to use that contains only isolate/putback/migrate. >> No filesystem uses isolate/putback, so those can just be deleted. >> Both migrate_operations & address_space_operations will contain a >> migrate callback. That makes sense to me. I wonder if there was a design decision/discussion behind that. CCing Rafael. @Rafael, full mail at https://lkml.kernel.org/r/Yp+lU55H4igaV3pB@casper.infradead.org > > Well, that went more smoothly than I thought it would. > > I can't see a nice way to split this patch up (other than making secretmem > its own patch). We just don't have enough bits in struct page to support > both ways of handling PageMovable at the same time, so we can't convert > one driver at a time. The diffstat is pretty compelling. Yes, splitting rather overcomplicates stuff. > > The patch is on top of this patch series; I think it probably makes > sense to shuffle it to be first, to avoid changing these drivers to > folios, then changing them back. Absolutely. > > Questions: > > Is what I've done with zsmalloc acceptable? The locking in that > file is rather complex. > > Can we now eliminate balloon_mnt / balloon_fs from cmm.c? I haven't even > compiled thatfile , but it seems like the filesystem serves no use now. > > Similar question for vmw_balloon.c, although I have compiled that. IIRC, virtio-balloon, cmm and vmw_balloon all have the mnt/fs just for page migration purposes. So if one can get rid of them, all should be able to get rid of them. Essentially everything that uses the balloon compaction framework. That should go into separate patches then. > > --- > > I just spotted a bug with zs_unregister_migration(); it won't compile > without CONFIG_MIGRATION. I'll fix that up if the general approach is > acceptable. > > arch/powerpc/platforms/pseries/cmm.c | 13 -------- > drivers/misc/vmw_balloon.c | 10 ------ > include/linux/balloon_compaction.h | 6 +--- > include/linux/fs.h | 2 - > include/linux/migrate.h | 27 ++++++++++++++---- > include/linux/page-flags.h | 2 - > mm/balloon_compaction.c | 18 ++++++------ > mm/compaction.c | 29 ++++++++----------- > mm/migrate.c | 23 ++++++++------- > mm/secretmem.c | 6 ---- > mm/util.c | 4 +- > mm/z3fold.c | 45 ++++++------------------------ > mm/zsmalloc.c | 52 +++++++++-------------------------- > 13 files changed, 83 insertions(+), 154 deletions(-) > > diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c > index 15ed8206c463..2ecbab3db723 100644 > --- a/arch/powerpc/platforms/pseries/cmm.c > +++ b/arch/powerpc/platforms/pseries/cmm.c > @@ -578,23 +578,10 @@ static int cmm_balloon_compaction_init(void) > return rc; > } > > - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb); > - if (IS_ERR(b_dev_info.inode)) { > - rc = PTR_ERR(b_dev_info.inode); > - b_dev_info.inode = NULL; > - kern_unmount(balloon_mnt); > - balloon_mnt = NULL; > - return rc; > - } > - > - b_dev_info.inode->i_mapping->a_ops = &balloon_aops; Are you missing similar updates to drivers/virtio/virtio_balloon.c ? At least, there we're also using balloon_aops, so this patch shouldn't compile. Skimming over it, nothing else jumped at me. -- Thanks, David / dhildenb ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Date: Wed, 8 Jun 2022 11:59:31 +0200 Subject: [Cluster-devel] [PATCH 15/20] balloon: Convert to migrate_folio In-Reply-To: References: <20220606204050.2625949-1-willy@infradead.org> <20220606204050.2625949-16-willy@infradead.org> Message-ID: <36cc5e2b-b768-ce1c-fa30-72a932587289@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 07.06.22 21:21, Matthew Wilcox wrote: > On Tue, Jun 07, 2022 at 03:24:15PM +0100, Matthew Wilcox wrote: >> On Tue, Jun 07, 2022 at 09:36:21AM +0200, David Hildenbrand wrote: >>> On 06.06.22 22:40, Matthew Wilcox (Oracle) wrote: >>>> const struct address_space_operations balloon_aops = { >>>> - .migratepage = balloon_page_migrate, >>>> + .migrate_folio = balloon_migrate_folio, >>>> .isolate_page = balloon_page_isolate, >>>> .putback_page = balloon_page_putback, >>>> }; >>> >>> I assume you're working on conversion of the other callbacks as well, >>> because otherwise, this ends up looking a bit inconsistent and confusing :) >> >> My intention was to finish converting aops for the next merge window. >> >> However, it seems to me that we goofed back in 2016 by merging >> commit bda807d44454. isolate_page() and putback_page() should >> never have been part of address_space_operations. >> >> I'm about to embark on creating a new migrate_operations struct >> for drivers to use that contains only isolate/putback/migrate. >> No filesystem uses isolate/putback, so those can just be deleted. >> Both migrate_operations & address_space_operations will contain a >> migrate callback. That makes sense to me. I wonder if there was a design decision/discussion behind that. CCing Rafael. @Rafael, full mail at https://lkml.kernel.org/r/Yp+lU55H4igaV3pB at casper.infradead.org > > Well, that went more smoothly than I thought it would. > > I can't see a nice way to split this patch up (other than making secretmem > its own patch). We just don't have enough bits in struct page to support > both ways of handling PageMovable at the same time, so we can't convert > one driver at a time. The diffstat is pretty compelling. Yes, splitting rather overcomplicates stuff. > > The patch is on top of this patch series; I think it probably makes > sense to shuffle it to be first, to avoid changing these drivers to > folios, then changing them back. Absolutely. > > Questions: > > Is what I've done with zsmalloc acceptable? The locking in that > file is rather complex. > > Can we now eliminate balloon_mnt / balloon_fs from cmm.c? I haven't even > compiled thatfile , but it seems like the filesystem serves no use now. > > Similar question for vmw_balloon.c, although I have compiled that. IIRC, virtio-balloon, cmm and vmw_balloon all have the mnt/fs just for page migration purposes. So if one can get rid of them, all should be able to get rid of them. Essentially everything that uses the balloon compaction framework. That should go into separate patches then. > > --- > > I just spotted a bug with zs_unregister_migration(); it won't compile > without CONFIG_MIGRATION. I'll fix that up if the general approach is > acceptable. > > arch/powerpc/platforms/pseries/cmm.c | 13 -------- > drivers/misc/vmw_balloon.c | 10 ------ > include/linux/balloon_compaction.h | 6 +--- > include/linux/fs.h | 2 - > include/linux/migrate.h | 27 ++++++++++++++---- > include/linux/page-flags.h | 2 - > mm/balloon_compaction.c | 18 ++++++------ > mm/compaction.c | 29 ++++++++----------- > mm/migrate.c | 23 ++++++++------- > mm/secretmem.c | 6 ---- > mm/util.c | 4 +- > mm/z3fold.c | 45 ++++++------------------------ > mm/zsmalloc.c | 52 +++++++++-------------------------- > 13 files changed, 83 insertions(+), 154 deletions(-) > > diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c > index 15ed8206c463..2ecbab3db723 100644 > --- a/arch/powerpc/platforms/pseries/cmm.c > +++ b/arch/powerpc/platforms/pseries/cmm.c > @@ -578,23 +578,10 @@ static int cmm_balloon_compaction_init(void) > return rc; > } > > - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb); > - if (IS_ERR(b_dev_info.inode)) { > - rc = PTR_ERR(b_dev_info.inode); > - b_dev_info.inode = NULL; > - kern_unmount(balloon_mnt); > - balloon_mnt = NULL; > - return rc; > - } > - > - b_dev_info.inode->i_mapping->a_ops = &balloon_aops; Are you missing similar updates to drivers/virtio/virtio_balloon.c ? At least, there we're also using balloon_aops, so this patch shouldn't compile. Skimming over it, nothing else jumped at me. -- Thanks, David / dhildenb