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 CF76AC433EF for ; Wed, 23 Mar 2022 08:28:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C9576B0072; Wed, 23 Mar 2022 04:28:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 478FE6B0073; Wed, 23 Mar 2022 04:28:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 341716B0074; Wed, 23 Mar 2022 04:28:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 266396B0072 for ; Wed, 23 Mar 2022 04:28:42 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CBCEDA4DB6 for ; Wed, 23 Mar 2022 08:28:41 +0000 (UTC) X-FDA: 79274974842.18.31B6FCA Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf23.hostedemail.com (Postfix) with ESMTP id 2DDF314002C for ; Wed, 23 Mar 2022 08:28:41 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id DE5C3210E9; Wed, 23 Mar 2022 08:28:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1648024117; 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=CW3R+Yiroys6he2hHa/SHBZUim+4itSeZjujNKPJOmQ=; b=tB448LMyefBx5twawDjt8knurabMyegikQW37yhYusJrNOEXKgv24DS1/jaejnVIzzL2kC TRwSrtJYxTnLlLapwzTrdxKmv0M0c2o7gdzOXvw4NQNzFLUKjENKzApLxv6UR+TN3zYYdM lWYYH57ssNh0s5XojNY4nxboJ1uCwzw= 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 8E09FA3BA1; Wed, 23 Mar 2022 08:28:37 +0000 (UTC) Date: Wed, 23 Mar 2022 09:28:37 +0100 From: Michal Hocko To: linux-kernel@vger.kernel.org Cc: Andrew Morton , vbabka@suse.cz, surenb@google.com, stable@vger.kernel.org, sfr@canb.auug.org.au, rientjes@google.com, nadav.amit@gmail.com, quic_charante@quicinc.com, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org Subject: Re: [patch 163/227] mm: madvise: skip unmapped vma holes passed to process_madvise Message-ID: References: <20220322143803.04a5e59a07e48284f196a2f9@linux-foundation.org> <20220322214648.AB7A1C340EC@smtp.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2DDF314002C X-Stat-Signature: wkw337xashs334qko9nm7898d7z7sg8x Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=tB448LMy; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf23.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspam-User: X-HE-Tag: 1648024121-214660 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 17:24:58, Minchan Kim wrote: > On Tue, Mar 22, 2022 at 02:46:48PM -0700, Andrew Morton wrote: > > From: Charan Teja Kalla > > Subject: mm: madvise: skip unmapped vma holes passed to process_madvise > > > > The process_madvise() system call is expected to skip holes in vma passed > > through 'struct iovec' vector list. But do_madvise, which > > process_madvise() calls for each vma, returns ENOMEM in case of unmapped > > holes, despite the VMA is processed. > > > > Thus process_madvise() should treat ENOMEM as expected and consider the > > VMA passed to as processed and continue processing other vma's in the > > vector list. Returning -ENOMEM to user, despite the VMA is processed, > > will be unable to figure out where to start the next madvise. > > > > Link: https://lkml.kernel.org/r/4f091776142f2ebf7b94018146de72318474e686.1647008754.git.quic_charante@quicinc.com > > I thought it was still under discussion and Charan will post next > version along with previous patch > "mm: madvise: return correct bytes advised with process_madvise" > > https://lore.kernel.org/linux-mm/7207b2f5-6b3e-aea4-aa1b-9c6d849abe34@quicinc.com/ Yes, I am not even sure the new semantic is sensible[1]. We should discuss that and see all the consequences. Changing the semantic of an existing syscall is always tricky going back and forth is even worse. -- Michal Hocko SUSE Labs