Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp906317pxb; Wed, 6 Apr 2022 03:55:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzc8bHdS+5mBYGs4UKLS9oamDGa50bMJnxRSJsh2j1SrcTn31fsSsqQYlHyyu8ahqXCaA/g X-Received: by 2002:a17:90a:f40b:b0:1ca:9d42:cb72 with SMTP id ch11-20020a17090af40b00b001ca9d42cb72mr8936345pjb.187.1649242537750; Wed, 06 Apr 2022 03:55:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649242537; cv=none; d=google.com; s=arc-20160816; b=LC7Ypnx/yD6lud3C6Fx2frc0LF6C/xGBZ4gav+IDNxustGJyIVQ/XDhkAra78Vp8Zj DR6c4929vP45wKDlYr8r1lxenBforoVCGHY17cdOj/Ot9YmZq4f0rNaiq6gZWAT0W18A vQ8Hd1YKb5YDi1BhBIJMJP975zqHKOTEUCKyBPUp4618O6PtDCouIfpEHItB5Sn1QP79 qRjIGsrnNVvunqe53lEDQDRfj5krM+RHpVfV867ySKyOFhlSYDBLQMoX3a+TU3Jf5rad e5DdfRn4oVNBuAJG3CIRys+uvs2p/uh/LZz8zGHHl+XQkS6bKlL/R7UuUFYZO8wrgWu8 AH9Q== 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=zsA+WIKy8GsN9nH9Y0z/90ay9fNNuqApGCZT+uQQ/zY=; b=nCXq+LXYiNl7PW7oQvNXhoXG5CcA6CMUBweiuk2tpCLYIaE8epI1wiWMhhw2yyU6Gy SPbN3o5eIaCDBQi/R1FFFWY5bEeBcsW14KW4d1tAL7/uUpRR2MAdovM8frcnrU07HUza YY0F9zSLTUufNK8DTcjFdXReIdS38NR1fwYe33p7pK+NxF54M/KKWXtPxz841duHvLpD 9CIGFK3cOO+GgZglBLBWALwmCbqN4+Cgxlj3U73zI/nRG42SCMrCtMlTNNfRvoEou2hd JKcUXiFPl2yztEfubASWh9oK8Qlyz+TcUP79OBlZapgfYfqYLR54vY6MVJxyxvs3fnV8 +1Hg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ZYMfOARH; 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 n12-20020a170902d2cc00b00153b2d16490si15658333plc.152.2022.04.06.03.55.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 03:55:37 -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=ZYMfOARH; 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EA36D59F7FB; Wed, 6 Apr 2022 02:13:53 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1450549AbiDEXXU (ORCPT + 99 others); Tue, 5 Apr 2022 19:23:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356093AbiDEKW4 (ORCPT ); Tue, 5 Apr 2022 06:22:56 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B95F6B2474; Tue, 5 Apr 2022 03:06:05 -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 ams.source.kernel.org (Postfix) with ESMTPS id 434A4B81C83; Tue, 5 Apr 2022 10:06:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 801EFC385A2; Tue, 5 Apr 2022 10:06:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649153163; bh=AXf40jmtpW45Xp9Oodq8bYKgJRTHlXh5sFHwX9zHIQY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZYMfOARH3FgULwHAcHbvUPtgmznSK8mNYvKgPYIaHqAs1pZJ6ZgVwhvJFvU59Korq q1oy69j/QQ2Um2pA+VZ9NgPba3buJa02k/RXmOk0wts/1DxpD0CqPdwYRdr/oeBHWD IGeCodM0oJ3eOUHYaVh7o6ciMNSXS4RtAtsObhic= 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.10 075/599] mm: madvise: return correct bytes advised with process_madvise Date: Tue, 5 Apr 2022 09:26:09 +0200 Message-Id: <20220405070301.057867860@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070258.802373272@linuxfoundation.org> References: <20220405070258.802373272@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 @@ -1236,8 +1236,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);