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 E1E8CC433EF for ; Tue, 22 Mar 2022 08:40:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60B3D6B0072; Tue, 22 Mar 2022 04:40:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 594A66B0073; Tue, 22 Mar 2022 04:40:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 434C06B0074; Tue, 22 Mar 2022 04:40:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 2E9E56B0072 for ; Tue, 22 Mar 2022 04:40:59 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id EC2251213B9 for ; Tue, 22 Mar 2022 08:40:58 +0000 (UTC) X-FDA: 79271376996.14.D416432 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf29.hostedemail.com (Postfix) with ESMTP id 5AEE9120022 for ; Tue, 22 Mar 2022 08:40:58 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 417CF210F3; Tue, 22 Mar 2022 08:40:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1647938457; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0wkneNYxu4+l2f/BwLiRAlini3J7bunPFDGOTKdmMbo=; b=aq6Tcn/s2XSpyqv94Jpi3whbz2A0f6QZQd2Mffhvu70LiPOkVlLzqRbyCxMnVLMHji6MN0 +Syv9J3Ia7u2PStho5upOeSuYxDUJ4DOK2Pv4eDq5ZByXJKn1vtZvYDNPihvve6RxrdPAo 1fLCAPZix2NZhePzVsOxCCItV6HGLaI= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id D8E3EA3B88; Tue, 22 Mar 2022 08:40:56 +0000 (UTC) Date: Tue, 22 Mar 2022 09:40:56 +0100 From: Michal Hocko To: Charan Teja Kalla Cc: akpm@linux-foundation.org, surenb@google.com, vbabka@suse.cz, rientjes@google.com, sfr@canb.auug.org.au, edgararriaga@google.com, minchan@kernel.org, nadav.amit@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "# 5 . 10+" Subject: Re: [PATCH V2,2/2] mm: madvise: skip unmapped vma holes passed to process_madvise Message-ID: References: <4f091776142f2ebf7b94018146de72318474e686.1647008754.git.quic_charante@quicinc.com> <7207b2f5-6b3e-aea4-aa1b-9c6d849abe34@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7207b2f5-6b3e-aea4-aa1b-9c6d849abe34@quicinc.com> Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="aq6Tcn/s"; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5AEE9120022 X-Stat-Signature: ujf9zg3amjtdnqcjj5o7979zq13xcxhc X-HE-Tag: 1647938458-995253 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 Tue 22-03-22 12:40:24, Charan Teja Kalla wrote: > Thanks Michal for the inputs. > > On 3/21/2022 9:04 PM, Michal Hocko wrote: > > On Fri 11-03-22 20:59:06, Charan Teja Kalla wrote: > >> The process_madvise() system call is expected to skip holes in vma > >> passed through 'struct iovec' vector list. > > Where is this assumption coming from? From the man page I can see: > > : The advice might be applied to only a part of iovec if one of its > > : elements points to an invalid memory region in the remote > > : process. No further elements will be processed beyond that > > : point. > > I assumed this while processing a single element of a iovec. In a > scenario where a range passed contains multiple VMA's + holes, on > encountering the VMA with VM_LOCKED|VM_HUGETLB|VM_PFNMAP, we are > immediately stopping further processing of that iovec element with > EINVAL return. Where as on encountering a hole, we are simply > remembering it as ENOMEM but continues processing that iovec element and > in the end returns ENOMEM. This means that complete range is processed > but still returning ENOMEM, hence the assumption of skipping holes in a > vma. > > The other problem is, in an individual iovec element, though some bytes > are processed we may still endup in returning EINVAL which is hard for > the user to take decisions i.e. he doesn't know at which address it is > exactly failed to advise. > > Anyway, both these will be addressed in the next version of this patch > with the suggestions from minchan [1] where it mentioned that: "it > should represent exact bytes it addressed with exacts ranges like > process_vm_readv/writev. Poviding valid ranges is responsiblity from the > user." I would tend to agree that the userspace should be providing sensible ranges (either subsets or full existing mappings). Whenever multiple vmas are defined by a single iovec, things get more complicated. IMO process_madvise should mimic the madvise semantic applied to each iovec. That means to bail out on an error. That applies to ENOMEM even when the last iovec has been processed completely. This would allow to learn about address space change that the caller is not aware of. That being said, your first patch should be good enough. -- Michal Hocko SUSE Labs