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 picard.linux.it (picard.linux.it [213.254.12.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 41C7BC2BD09 for ; Tue, 9 Jul 2024 06:46:10 +0000 (UTC) Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id AF2333D393A for ; Tue, 9 Jul 2024 08:46:08 +0200 (CEST) Received: from in-5.smtp.seeweb.it (in-5.smtp.seeweb.it [IPv6:2001:4b78:1:20::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1)) (No client certificate requested) by picard.linux.it (Postfix) with ESMTPS id 6DFC33C0625 for ; Tue, 9 Jul 2024 08:45:53 +0200 (CEST) Authentication-Results: in-5.smtp.seeweb.it; spf=pass (sender SPF authorized) smtp.mailfrom=suse.cz (client-ip=195.135.223.131; helo=smtp-out2.suse.de; envelope-from=chrubis@suse.cz; receiver=lists.linux.it) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by in-5.smtp.seeweb.it (Postfix) with ESMTPS id E2797600793 for ; Tue, 9 Jul 2024 08:45:52 +0200 (CEST) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 049B21F79B; Tue, 9 Jul 2024 06:45:52 +0000 (UTC) Authentication-Results: smtp-out2.suse.de; none Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E06FB1369A; Tue, 9 Jul 2024 06:45:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id gJDzNZ/cjGZzCAAAD6G6ig (envelope-from ); Tue, 09 Jul 2024 06:45:51 +0000 Date: Tue, 9 Jul 2024 08:48:32 +0200 From: Cyril Hrubis To: Chuck Lever III Message-ID: References: <2fc3a3fd-7433-45ba-b281-578355dca64c@oracle.com> <296EA0E6-0E72-4EA1-8B31-B025EB531F9B@oracle.com> <2024070638-shale-avalanche-1b51@gregkh> <2024070814-very-vitamins-7021@gregkh> <64D2D29F-BCC0-4A44-BB75-D85B80B75959@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <64D2D29F-BCC0-4A44-BB75-D85B80B75959@oracle.com> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 049B21F79B X-Rspamd-Action: no action X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Virus-Scanned: clamav-milter 1.0.3 at in-5.smtp.seeweb.it X-Virus-Status: Clean Subject: Re: [LTP] [PATCH 1/1] nfsstat01: Update client RPC calls for kernel 6.9 X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux NFS Mailing List , Neil Brown , Greg KH , Jeff Layton , Sherry Yang , linux-stable , Josef Bacik , Anna Schumaker , Trond Myklebust , Calum Mackay , "kernel-team@fb.com" , "ltp@lists.linux.it" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ltp-bounces+ltp=archiver.kernel.org@lists.linux.it Sender: "ltp" Hi! > There is a change in behavior in the upstream code, but Josef's > patches fix an information leak and make the statistics more > sensible in container environments. I'm not certain that > should be considered a regression, but confess I don't know > the regression rules to this fine a degree of detail. > > If it is indeed a regression, how can we go about retaining > both behaviors (selectable by Kconfig or perhaps administrative > UI)? That is IMHO the worst solution, every userspace tool would have to be able to work with both formats for an undefinite amount of time and the only added value of this approach would be a Kconfig option to enable information leak... -- Cyril Hrubis chrubis@suse.cz -- Mailing list info: https://lists.linux.it/listinfo/ltp