Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d1535f25-b252-ee38-8eb8-94af9367d5f1@nvidia.com>
Date:   Tue, 6 Sep 2022 00:58:59 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.0
Subject: Re: [PATCH v2 4/7] iov_iter: new iov_iter_pin_pages*() routines
Content-Language: en-US
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Jens Axboe <axboe@kernel.dk>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Miklos Szeredi <miklos@szeredi.hu>,
        "Darrick J . Wong" <djwong@kernel.org>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>, Jan Kara <jack@suse.cz>,
        David Hildenbrand <david@redhat.com>,
        Logan Gunthorpe <logang@deltatee.com>,
        linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org,
        linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
References: <20220831041843.973026-1-jhubbard@nvidia.com>
 <20220831041843.973026-5-jhubbard@nvidia.com>
 <YxbtF1O8+kXhTNaj@infradead.org>
 <103fe662-3dc8-35cb-1a68-dda8af95c518@nvidia.com>
 <Yxb7YQWgjHkZet4u@infradead.org>
From:   John Hubbard <jhubbard@nvidia.com>
In-Reply-To: <Yxb7YQWgjHkZet4u@infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bXFCM1FZSnpYWUNkbk5ybi82ZTlRUkNBOFBqeHY4VWZpcEpXVGNrVEFlaDFZ?=
 =?utf-8?B?R1pISzBqM3hRdEZFWU9uclpZNCtCYWVkZzQzY0RRRzc2bmJhWGVRdkFZVjVN?=
 =?utf-8?B?UmpCZmNtT3NEN2R0bTRtbUtUSmUxU0RMa0xFcFY5bFRaTVhvczFtL0JjeWxN?=
 =?utf-8?B?VWk2QTQ4Mi8vNkl1azRRekVicjVsUysxMTB5aVFtRXlLL084bUQyZ0dvVzA2?=
 =?utf-8?B?MlBTT0NreU8zOWZJS21DeGhnY2QwZjYveW1XalMvenludmsxTG1aODRyTFJq?=
 =?utf-8?B?a2liMG9vSzlnVUNob3J1c1prK0FZaWh2aXhyOVh2NFpDYUdUajlvaW1NSm11?=
 =?utf-8?B?VmtpUkt3NExKblovOVFVU09XTmdRRHdKNVJvQ2h5TSswc3ZDMGhsOEFSLzMw?=
 =?utf-8?B?cE1hSUNWRXRtd0VvSzZwU3NlVVVpTUYyVjU0WGtORnVZVERxTkZ6dXMrLzJa?=
 =?utf-8?B?dDl3d283bUtUazVsM1NYTG9GdnNXbHdUaER5U3A0S29TOFg5Nm82enkyZGha?=
 =?utf-8?B?SkFPZXVnSTZ2SVhNdEROVXBIK2czQjg3UnJCb2hXYWRRTXljSjhlKytEKzFV?=
 =?utf-8?B?c2pGVkhpL0VycHRtRFcwWE4vM1dTcDlEbkpRSStlTGNjeHBFdlBqeUNQUmNH?=
 =?utf-8?B?dXo1ckkvV3RxVlV0TDBQVzMyNFFIazJpTmZ4alNmMk5zNmxFQ0FFOW1mVGpN?=
 =?utf-8?B?UjZQRzhmMHQ3UnU1Uldka044NEpBWlFNYWIzT2phQy8yeHNreGYvcjZ2eWVX?=
 =?utf-8?B?UVpucG1WeWU1a09OeGNsbFQ2QnAwdXZId1o3V3pVa000STkrZGtkV3JvYVZR?=
 =?utf-8?B?RFYveWY0K0pqNVVGZzdtUzVtL1ZwNWxaWTBvVWtSMzVOb0NlQzRoRzFvVXFp?=
 =?utf-8?B?ZjBmVXhTTWJ2YUNGNnRQMWE0NHZvUXJmNnZRb2w4cGdPK3VOa0JieWxGQmNC?=
 =?utf-8?B?QVJzaDFGNkFreWdRdTQrZTE4Y0dRdXpPdEpzdDJTNnBDaytGejZ4bk5CWFBO?=
 =?utf-8?B?dmhIaFRpaG5DU2dPZUFwYVoveWJOOTRwd0RMZGRQVlRKRk5Zdk5ZeHpVU1Bv?=
 =?utf-8?B?c3NWOXJhb0tERkpUV1BwSXZ3YkM1bkV2Y0ZEZUliMkE3NlEzMWY0OEE3TnQ4?=
 =?utf-8?B?UUhPMVdHWnZvWUdjNHlwK01WRFhFWjlqVFhVbUNyR2hVeUVOQkczS0VVdUdq?=
 =?utf-8?B?ZnhOQ2tGQnJqa2NORThCdElUT2NzNSt4NlptWWE4Um1ZSzA5cldRZlFMVW9I?=
 =?utf-8?B?TXpuK29GbklTVWYzTmV3NXovTUl2Q0dkMjE4dXJkVU9XbHNkWTFjSjZmK0xC?=
 =?utf-8?B?dXR4bzF1a3Y3NnBtbUlUb0pVRFZlOUJMc01vbnBVV0VVMTBSaVJVbHo1K2dq?=
 =?utf-8?B?cXZINHJFcGtjY3lLUE1vaG9WUldkOVFiQzJWOU0yYUJGc3hqTlNWc2lsYmFK?=
 =?utf-8?B?eXd3dkNRdlJwc2M3QXRaQ3ZJaGR1NlJGN1BMM29CWHA3RzRWM0N4U2dQcHVo?=
 =?utf-8?B?SloxTTFmYmtFa2ZrZVM1WHljaFV5d2NKZm1VTTB4MWxHWGlXc095YStzZVl0?=
 =?utf-8?B?ancrV0x6a1kzOU05Qkd1M21tSjZOMXBxK0h1NTJtN094SmxKWG5KcjRaREph?=
 =?utf-8?B?SmJkLzJmYlNYQktMRXc2WXlFZUY0bW9COEg4MFltdkZrVG5GN2ZaZmVmRlcr?=
 =?utf-8?B?a01vS21jelk3dXZYa09TSnB0aFg5bjJHTDZpZmhzc3l6UG05aEYxd0J6bkw4?=
 =?utf-8?B?cVdndzZOeEF6ekx1YzduTW93Vm1JbDlnbldyaG10RG1OUmx5UVRwS21od1Yw?=
 =?utf-8?B?R3Y1aGFSbTNQLzZaN25laDYzZ2FXNkpyeU5HZHhCdStGTE8yaVp5TWNuME9N?=
 =?utf-8?B?WEZBMCtOZ0VIL2lsazlqc2s0WUduVDdBbml3MEJJSTErRm4yTWg2VkdNalVI?=
 =?utf-8?B?MmllYUkwZUdsN2FhbHlNU2U0TDlQZjhaaG01aEZYTUxUc3BOUGtPSnZYV0xE?=
 =?utf-8?B?RHFNeVA5RXVPdVpoWDArNVVhY2JzZzRCSGQ0SExITXREdEI2MUlNTEpaaGhK?=
 =?utf-8?B?VE8yMFRhZC92bFJweFUwSDlQOVJkYTgrVURveEVINTFLUFpXY1MwUjNqdmhv?=
 =?utf-8?Q?LkvOAWaVg/d6BhQJAuKv1k1BJ?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 854f191e-6af1-4505-9918-08da8fddad86
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB4140.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Sep 2022 07:59:09.0201
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 2T6Isx3z1j2v+FzSuBMhCL66JGYL55tiirQ7tm1RRQLq8fPEKt8e5FroKRm9UMmEwJPkZRuM7NA2j+efPviR9g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB5609
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        NICE_REPLY_A,SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

On 9/6/22 00:48, Christoph Hellwig wrote:
> On Tue, Sep 06, 2022 at 12:44:28AM -0700, John Hubbard wrote:
>> OK, that part is clear.
>>
>>>  - for the pin case don't use the existing bvec helper at all, but
>>>    copy the logic for the block layer for not pinning.
>>
>> I'm almost, but not quite sure I get the idea above. Overall, what
>> happens to bvec pages? Leave the get_page() pin in place for FOLL_GET
>> (or USE_FOLL_GET), I suppose, but do...what, for FOLL_PIN callers?
> 
> Do not change anyhing for FOLL_GET callers, as they are on the way out
> anyway.
> 

OK, got it.

> For FOLL_PIN callers, never pin bvec and kvec pages:  For file systems
> not acquiring a reference is obviously safe, and the other callers will
> need an audit, but I can't think of why it woul  ever be unsafe.

In order to do that, one would need to be confident that such bvec and kvec
pages do not get passed down to bio_release_pages() (or the new
bio_unpin_pages()). Also, I'm missing a key point, because today bvec pages get
a get_page() reference from __iov_iter_get_pages_alloc(). If I just skip
that, then the get/put calls are unbalanced...

I can just hear Al Viro repeating his points about splice() and vmsplice(),
heh. :)


thanks,

-- 
John Hubbard
NVIDIA