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 92489EB64DA for ; Fri, 30 Jun 2023 19:28:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 026FA8E0047; Fri, 30 Jun 2023 15:28:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F197A8E000F; Fri, 30 Jun 2023 15:28:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE0AD8E0047; Fri, 30 Jun 2023 15:28:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CFD9B8E000F for ; Fri, 30 Jun 2023 15:28:31 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 936DE1201C0 for ; Fri, 30 Jun 2023 19:28:31 +0000 (UTC) X-FDA: 80960400822.12.366DE23 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id C31C180014 for ; Fri, 30 Jun 2023 19:28:29 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ryup1iNS; spf=pass (imf30.hostedemail.com: domain of nathan@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=nathan@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688153309; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cSiCW/KaiQdJa3PcW0Gh5S6jFmVUK5U5vgrkY1SeBVY=; b=QDWr2P8Ts0pFQnIgAFArtwhZYLKyJ0yX3oQrsAK53uHKxjbLzOqoR53Ib1axEPWf/P8/tU w2Z6sgK/+oJ+F1dmURG8Bvnmy3oNyccpLxEQUkH3suL2rbOAFGErvJDEcefROhnvueCyFY NiCJl1ZVd5N7Je9kWWm2Tt93Agp3Z2s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688153309; a=rsa-sha256; cv=none; b=5SxT04czbYpljsD/IO53anup/PrLvJreA2gyHvmP9PfVcx3G2+zGq4mIufh4r6eSeKbhop ugn8NOGroc3gXV6mIJ9LOooCV99QqzlGKX5hXy2XUmp11LSKAxAcDYy7NW5fUCrB04aQwg ES94IbEGdmUXU/WexhnkfD0UcufXcGY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ryup1iNS; spf=pass (imf30.hostedemail.com: domain of nathan@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=nathan@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9BC2F617F4; Fri, 30 Jun 2023 19:28:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE726C433C0; Fri, 30 Jun 2023 19:28:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688153308; bh=zX7DtgKaXqa8tSnrkMuQTXY6UheSPHRSG4DhhcbKq+g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ryup1iNS7cnCw2wiYI3YEs2N7PeCMaMxWV1gkQER97KVMF9lUTjIK9fzk3DQSkk6q M+MqgMxaw01mt5CQJkyVoO9FEbADys+v/GY8cYOOAo8cGz0mR5z1t2Z2jbWiWBHe3a 2SUPqi1E9SO46ZJpEI6KSX8OMAPW2qgfncFFfHniX5QNV9jHuH2YBR0CH4Oe9KVhoC Mi4/QItY+2LBUukkmIeMd8s+nPBYMevX7Wwbj1GsdziHcoAtWeZDF/tFvAn8Ar88eI RjrS0eVk052IzxtszvnH8y3/MNlfF+v+hiJeG9qiwYwudNCWMxPTjEBAgyj6rmJdq9 JLEUuTBhVG9vA== Date: Fri, 30 Jun 2023 12:28:25 -0700 From: Nathan Chancellor To: Jakub Kicinski Cc: David Howells , Aurelien Aptel , netdev@vger.kernel.org, Alexander Duyck , "David S. Miller" , Eric Dumazet , Paolo Abeni , Willem de Bruijn , David Ahern , Matthew Wilcox , Jens Axboe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sagi Grimberg , Willem de Bruijn , Keith Busch , Jens Axboe , Christoph Hellwig , Chaitanya Kulkarni , linux-nvme@lists.infradead.org, llvm@lists.linux.dev Subject: Re: [PATCH net-next v3 10/18] nvme/host: Use sendmsg(MSG_SPLICE_PAGES) rather then sendpage Message-ID: <20230630192825.GA2745548@dev-arch.thelio-3990X> References: <253mt0il43o.fsf@mtr-vdi-124.i-did-not-set--mail-host-address--so-tickle-me> <20230620145338.1300897-1-dhowells@redhat.com> <20230620145338.1300897-11-dhowells@redhat.com> <58466.1688074499@warthog.procyon.org.uk> <20230629164318.44f45caf@kernel.org> <20230630161043.GA2902645@dev-arch.thelio-3990X> <20230630091442.172ec67f@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230630091442.172ec67f@kernel.org> X-Rspamd-Queue-Id: C31C180014 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: de9qc6ai9fnezgm9pgmpo3mayd5pboqs X-HE-Tag: 1688153309-364931 X-HE-Meta: U2FsdGVkX1+qwjGz2cVpH90NB7KIb+XvxBtpWbwV/Rx66phxFKjTBgL1HyJ9k0vnKJ0EkIxTz/giaOgI2IBF/WfuR5j79Da4u0Tvt8jLRRLiorY608uF6dAwcjW28+o8TazKdmw42NztsJOSw0HIzumpWyBx6/dxN9FlAcBWGN0zDgsuY4urkidJLIdLBYei1+fIGvcyzxql+rGSfCAhQ6NXCOK/lXIcrqgmEwRS/h+dnpgUDiR3SW0wlPSoR8PEuowLHcgxJ660bJXDfi/4ehvxOct2L+IBM//lKggeLWDdAeMOhQWYTyL0RwvN/Px+/d62d3Fgfmj0IXSokMbEpmy3l8GIhoE83sGpiuq9LMYbgT4HgwxPoX7aNRzkEZBdxjav13G0QB3HExnCAaKitqgj8e6vf7QWl/Er2+22L1pohIvxQ4KQmxgXk0u9piT/+qEAptL4YDJLN30uI4cuH3WHrNxGA8YbgOdScacApgnfjmHB/t9EE8Zc9LkQXk+wJizmLi4T7d4ENvqVMYHkaHjPwkplPYWdetgrfv8yeCyUyqGOWml31hCm//9QzPKdVMphgGc9G447VLQaGZZ+G5HK69eDRUUJbx6p7FjXjB3vifWOnzm3Jw5RAOpq2J00xhNNzGqa9cKIxP0T2VErOzUwz9gtaYeo36TPEA/1qLHiKRuoO7F9aRXSvgT7g5eX5Fz3BW74hDlnMCA0VEsJnehO2ORzVqtkn32U/DJDAdOO3KFnBB5jUFOfG6FnRILJy7FgoBWpk2SB+tpPdaPy2gdHDrmuikPLBTpdbNB0BoUKI0G+SUwJvOFQ+DVK8KpESMLTdeZPSoCPw1dgtLDRlw1QZo96MNKyZF2IoS4kgOQts8cCrVQaNyCMWLVJCeCNuxvzxbhYw2qhqeILO7VpX54QJQcDUOU1C0XSz2SXu37GHv+PypzB53UWShi6Hjv3+6+F7hrdZP0UkqzRC1h /1PgVDNw 0QU6VYyUKMDO/2GKyuk3DiVlr9wglFiyoyCMtBg4SKzhDn0zLuYQKKdx6ZHgJrsKklpZbd4n5B6Nlx4elIRgbKdf2EKBpztDOuiYbNw/a7i4T4P9jS8W61+Ql4qcgTAxvztnz5bx7ZjaRGJLcY42lnNYOfH6yVquaLo9TASpGvsm8W4XRO1nJBH+EkgRzHtAL4amjCOmkjAdIfhuoZup8bxrSfsD/0LutXF6nztd5vNW+IwnbZIhJH5WgQKVtsWo85znGU48AbcOWK+itNFP5OCQP+DksO4TsF/D1uCJ36uquaXB28YlNl6vlBfw2fckdViovffy2RbWqJMjciUwB3nFMnrKEPB0FWk0XPCTRYNr+x9/igaj3GaioynGNdpXjlIIpBYL40x4lZMisRZtJ1R5I2gPjth0GiV4s6CLDD0YXsjq2xxXVknUTf3LpEyJQdXxZqb8CK8tz70XT/KihCJHS6m1OQ6QTfZpZgts6f+wJXW4= 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 Fri, Jun 30, 2023 at 09:14:42AM -0700, Jakub Kicinski wrote: > On Fri, 30 Jun 2023 09:10:43 -0700 Nathan Chancellor wrote: > > > Let me CC llvm@ in case someone's there is willing to make > > > the compiler warn about this. > > > > Turns out clang already has a warning for this, -Wcomma: > > > > drivers/nvme/host/tcp.c:1017:38: error: possible misuse of comma operator here [-Werror,-Wcomma] > > 1017 | msg.msg_flags &= ~MSG_SPLICE_PAGES, > > | ^ > > drivers/nvme/host/tcp.c:1017:4: note: cast expression to void to silence warning > > 1017 | msg.msg_flags &= ~MSG_SPLICE_PAGES, > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > | (void)( ) > > 1 error generated. > > > > Let me do some wider build testing to see if it is viable to turn this > > on for the whole kernel because it seems worth it, at least in this > > case. There are a lot of cases where a warning won't be emitted (see the > > original upstream review for a list: https://reviews.llvm.org/D3976) but > > something is better than nothing, right? :) Well, that was a pipe dream :/ In ARCH=arm multi_v7_defconfig alone, there are 289 unique instances of the warning (although a good number have multiple instances per line, so it is not quite as bad as it seems, but still bad): $ rg -- -Wcomma arm-multi_v7_defconfig.log | sort | uniq -c | wc -l 289 https://gist.github.com/nathanchance/907867e0a7adffc877fd39fd08853801 Probably not a good sign of the signal to noise ratio, I looked through a good handful and all the cases I saw were not interesting... Perhaps the warning could be tuned further to become useful for the kernel but in its current form, it is definitely a no-go :/ > Ah, neat. Misleading indentation is another possible angle, I reckon, > but not sure if that's enabled/possible to enable for the entire kernel Yeah, I was surprised there was no warning for misleading indentation... it is a part of -Wall for both clang and GCC, so it is on for the kernel, it just appears not to trigger in this case. > either :( We test-build with W=1 in networking, FWIW, so W=1 would be > enough for us. Unfortunately, even in its current form, it is way too noisy for W=1, as the qualifier for W=1 is "do not occur too often". Probably could be placed under W=2 but it still has the problem of wading through every instance and it is basically a no-op because nobody tests with W=2. Cheers, Nathan