From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BDD738F for ; Thu, 11 Jan 2024 00:39:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="N+IF8RrF" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1d3eb299e2eso29915025ad.2 for ; Wed, 10 Jan 2024 16:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1704933563; x=1705538363; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2tzVam0hFnVO15kFt069Z14hbEubNMkoHdOSTm/yrjg=; b=N+IF8RrFbG8TDazBj+H0IBGAaIyLPOMCtAR5xyiFOEAnOSUEiXMCngtgOlTvg4+PcD EIEUoPQ5hOGxrq/ZoUBGMTKFzvlCKmB7skeoH6eZH/VNCKBJrZLo4N+qIK7WtiahZEpm 0URGVuh7RRDe8k1BepQPuchj3XSGfxBtLN8PM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704933563; x=1705538363; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2tzVam0hFnVO15kFt069Z14hbEubNMkoHdOSTm/yrjg=; b=UBOqnfyAcujyiteYt6hTz6hgxPUnrPKpIRHD19m1XzH7wQcJfawq+i8Uju0BTQIG9H LiR3/L1jBU4cFhKKBnDknWWOb0m+krNM+KSDG19jjvaPLKGhv6yrl+WFatv1LaDUdhHc 6BgcviPfJLZ9pXGSSdFduSR376Dcy4GHshxY93Q/jc5M9UP0AI4aXDcx+odIIoNZCOnJ kCi4eXN6qoiD+KxwK5I3mSzmfgOV8leXn3uBvzAexdlUI7E0slPyrfFam4dOvRRPYLh3 MuImIzNYzYRRlpwdebxBV/IZEHGVIZq51xrMAuUf9VZlcDSc1riBkN4pF5oIg9YeJozR D++A== X-Gm-Message-State: AOJu0YyM5PFcdabTuLY/VFpJyuqna67yMPpoC9cVd3/wyfuzK8rnJ1iV 9IqQi/cbb67Xu5iHfJLglrXnpR633z/MsZY+BJGMLoZROS8Q X-Google-Smtp-Source: AGHT+IECP2Bnyo5GM1JeB3lzEBvXWpVakVzi6DxHRYvR9KdZ0qjFnMRCoI+Gv8jwwvmVX7sWsHD30Q== X-Received: by 2002:a17:902:da84:b0:1d4:60b1:27af with SMTP id j4-20020a170902da8400b001d460b127afmr396174plx.97.1704933563663; Wed, 10 Jan 2024 16:39:23 -0800 (PST) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id v3-20020a1709029a0300b001d4c316e3a4sm4210089plp.189.2024.01.10.16.39.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 16:39:23 -0800 (PST) Date: Wed, 10 Jan 2024 16:39:22 -0800 From: Kees Cook To: Kent Overstreet Cc: Linus Torvalds , linux-bcachefs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [GIT PULL] bcachefs updates for 6.8 Message-ID: <202401101625.3664EA5B@keescook> References: <202401101525.112E8234@keescook> <6pbl6vnzkwdznjqimowfssedtpawsz2j722dgiufi432aldjg4@6vn573zspwy3> Precedence: bulk X-Mailing-List: linux-bcachefs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6pbl6vnzkwdznjqimowfssedtpawsz2j722dgiufi432aldjg4@6vn573zspwy3> On Wed, Jan 10, 2024 at 07:04:47PM -0500, Kent Overstreet wrote: > On Wed, Jan 10, 2024 at 03:48:43PM -0800, Kees Cook wrote: > > On Wed, Jan 10, 2024 at 02:36:30PM -0500, Kent Overstreet wrote: > > > [...] > > > bcachefs: %pg is banished > > > > Hi! > > > > Not a PR blocker, but this patch re-introduces users of strlcpy() which > > has been otherwise removed this cycle. I'll send a patch to replace > > these new uses, but process-wise, I'd like check on how bcachefs patches > > are reviewed. > > I'm happy to fix it. Perhaps the declaration could get a depracated > warning, though? That's one of checkpatch.pl's purposes, seeing as how deprecation warnings are ... deprecated. :P https://docs.kernel.org/process/deprecated.html#id1 This has made treewide changes like this more difficult, but these are the Rules From Linus. ;) > > Normally I'd go find the original email that posted the patch and reply > > there, but I couldn't find a development list where this patch was > > posted. Where is this happening? (Being posted somewhere is supposed > > to be a prerequisite for living in -next. E.g. quoting from the -next > > inclusion boiler-plate: "* posted to the relevant mailing list,") It > > looks like it was authored 5 days ago, which is cutting it awfully close > > to the merge window opening: > > > > AuthorDate: Fri Jan 5 11:58:50 2024 -0500 > > I'm confident in my testing; if it was a patch that needed more soak > time it would have waited. > > > Actually, it looks like you rebased onto v6.7-rc7? This is normally > > strongly discouraged. The common merge base is -rc2. > > Is there something special about rc2? It's what sfr suggested as it's when many subsystem maintainers merge to when opening their trees for development. Usually it's a good tree state: after stabilization fixes from any rc1 rough edges. > I reorder patches fairly often just in the normal course of backporting > fixes, and if I have to rebase everything for a backport I'll often > rebase onto a newer kernel so that the people who are running my tree > are testing something more stable - it does come up. Okay, gotcha. I personally don't care how maintainers handle rebasing; I was just confused about the timing and why I couldn't find the original patch on any lists. :) And to potentially warn about Linus possibly not liking the rebase too. > > > It also seems it didn't get a run through scripts/checkpatch.pl, which > > shows 4 warnings, 2 or which point out the strlcpy deprecation: > > > > WARNING: Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89 > > #123: FILE: fs/bcachefs/super.c:1389: > > + strlcpy(c->name, name.buf, sizeof(c->name)); > > > > WARNING: Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89 > > #124: FILE: fs/bcachefs/super.c:1390: > > + strlcpy(ca->name, name.buf, sizeof(ca->name)); > > > > Please make sure you're running checkpatch.pl -- it'll make integration, > > technical debt reduction, and coding style adjustments much easier. :) > > Well, we do have rather a lot of linters these days. > > That's actually something I've been meaning to raise - perhaps we could > start thinking about some pluggable way of running linters so that > they're all run as part of a normal kernel build (and something that > would be easy to drop new linters in to; I'd like to write some bcachefs > specific ones). With no central CI, the best we've got is everyone running the same "minimum set" of checks. I'm most familiar with netdev's CI which has such things (and checkpatch.pl is included). For example see: https://patchwork.kernel.org/project/netdevbpf/patch/20240110110451.5473-3-ptikhomirov@virtuozzo.com/ > The current model of "I have to remember to run these 5 things, and then > I'm going to get email nags for 3 more that I can't run" is not terribly > scalable :) Oh, I hear you. It's positively agonizing for those of us doing treewide changes. I've got at least 4 CIs I check (in addition to my own) just to check everyone's various coverage tools. At the very least, checkpatch.pl is the common denominator: https://docs.kernel.org/process/submitting-patches.html#style-check-your-changes -Kees -- Kees Cook