Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp584670pxb; Tue, 5 Apr 2022 14:58:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzg5amgR1JYIaYB9eylB9HPQrsY7gLRlly31zGPe2KwajoS6AksI4QxtNSPE94o/nmDHtBW X-Received: by 2002:a17:902:768c:b0:155:e4a2:1f09 with SMTP id m12-20020a170902768c00b00155e4a21f09mr5298138pll.43.1649195914712; Tue, 05 Apr 2022 14:58:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649195914; cv=none; d=google.com; s=arc-20160816; b=lhxgwy5L3rfrjR7RLcbBmkJAz5xyfuzoggFEKpTXZnywudDlNq9mEa1fd+PyeInBNG ilxxohgyli6TVG4/Uu16if8Ti+KTL8xQDE3QM692UJLSSTpQvMl240oni6FCh6H00vxo 0bqNUXkTbdxUG3C1lc1tTm+NNXNShAfWiAVLtfyRPH08m9Yz8WoW4aCwFThjDOY3HtJw 7NZ8YAeSeLGjNw+6nxvGDJgX95m7Xv9PLXzEqwZgWLket5FgpZ2yvu5Kvm7Zxb4jpp8N TBh9QvYhiUvtOEq2cKSSqr4MaimfugjjOlDXXT9K+2xsLoO0g5R2Z/cxxbk/en891uBy 5kMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Tr5ACCXpqncaqIW/Dyl6rERuN00oaKv3N0q9wJ3aHyY=; b=m7LbWUJUJQ9C1Xtr6KfM5lSh0orPV8ZctoNx+WT3/hWdVKUdSo5fWpdJTp8HvvS7nU MfNX09xiIeDEEBv5vOq8o+e0ucNNwUTzuHsp4sCPv71iboeNRuqQGTKTYhJ7/Vjk7px8 1Bi4QAlqOeHQHYDpS0vKZMBg8uvPIkql4wmoBpoVT+HgcEDxj+OhmAhgHa6q+X+RVi/+ hYhJJbDHUKHkkQmAnPNR5w2kxhCRZKZKnHbzidarupRbD2x7MaCYFOTbkwrQuq6iP8gz nJ6GNplEXXg0yZre6wMmzmwEfxotk9y9HWODzyMxGfKRUVnpEq5QF8yDDW7sYtyn4mrv ss4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=U+U+CMcx; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id bt24-20020a17090af01800b001c651f909easi2806197pjb.137.2022.04.05.14.58.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 14:58:34 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=U+U+CMcx; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 94193123414; Tue, 5 Apr 2022 14:44:53 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238400AbiDEOUe (ORCPT + 99 others); Tue, 5 Apr 2022 10:20:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239725AbiDEJeA (ORCPT ); Tue, 5 Apr 2022 05:34:00 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0574A7DA8C; Tue, 5 Apr 2022 02:23:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id F3B93CE1C78; Tue, 5 Apr 2022 09:23:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D068DC385A0; Tue, 5 Apr 2022 09:23:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649150588; bh=Cx5L+u3zeAs8deNWRcmU5/WrIwgYWoTaZ/7o2gEtJ7Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U+U+CMcxQN5NTDoHd10LhqhUYdx6BlKFD04nSjU1bkXP+rWvxuJHgDCKDaGT6N1R3 UUHqG5RprphpiP0i+AlfqtZf6h3ry5vCWL2/24w4xJ+BLN6nw54ru/F2yLBKwLoLfW fTg9SU7SXEwFfhoTB7Mavz2QZEppiYaSrRaA5gvo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Charan Teja Kalla , Suren Baghdasaryan , Vlastimil Babka , David Rientjes , Stephen Rothwell , Minchan Kim , Nadav Amit , Michal Hocko , Andrew Morton , Linus Torvalds Subject: [PATCH 5.15 108/913] mm: madvise: return correct bytes advised with process_madvise Date: Tue, 5 Apr 2022 09:19:30 +0200 Message-Id: <20220405070343.064309939@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070339.801210740@linuxfoundation.org> References: <20220405070339.801210740@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org From: Charan Teja Kalla commit 5bd009c7c9a9e888077c07535dc0c70aeab242c3 upstream. Patch series "mm: madvise: return correct bytes processed with process_madvise", v2. With the process_madvise(), always choose to return non zero processed bytes over an error. This can help the user to know on which VMA, passed in the 'struct iovec' vector list, is failed to advise thus can take the decission of retrying/skipping on that VMA. This patch (of 2): The process_madvise() system call returns error even after processing some VMA's passed in the 'struct iovec' vector list which leaves the user confused to know where to restart the advise next. It is also against this syscall man page[1] documentation where it mentions that "return value may be less than the total number of requested bytes, if an error occurred after some iovec elements were already processed.". Consider a user passed 10 VMA's in the 'struct iovec' vector list of which 9 are processed but one. Then it just returns the error caused on that failed VMA despite the first 9 VMA's processed, leaving the user confused about on which VMA it is failed. Returning the number of bytes processed here can help the user to know which VMA it is failed on and thus can retry/skip the advise on that VMA. [1]https://man7.org/linux/man-pages/man2/process_madvise.2.html. Link: https://lkml.kernel.org/r/cover.1647008754.git.quic_charante@quicinc.com Link: https://lkml.kernel.org/r/125b61a0edcee5c2db8658aed9d06a43a19ccafc.1647008754.git.quic_charante@quicinc.com Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API") Signed-off-by: Charan Teja Kalla Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: David Rientjes Cc: Stephen Rothwell Cc: Minchan Kim Cc: Nadav Amit Cc: Michal Hocko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/madvise.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/mm/madvise.c +++ b/mm/madvise.c @@ -1301,8 +1301,7 @@ SYSCALL_DEFINE5(process_madvise, int, pi iov_iter_advance(&iter, iovec.iov_len); } - if (ret == 0) - ret = total_len - iov_iter_count(&iter); + ret = (total_len - iov_iter_count(&iter)) ? : ret; release_mm: mmput(mm);