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 D5B1FE6ADCB for ; Fri, 22 Nov 2024 22:02:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D3186B0085; Fri, 22 Nov 2024 17:02:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 583B96B0088; Fri, 22 Nov 2024 17:02:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44AF96B0089; Fri, 22 Nov 2024 17:02:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 275AB6B0085 for ; Fri, 22 Nov 2024 17:02:15 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CF1C941A0F for ; Fri, 22 Nov 2024 22:02:14 +0000 (UTC) X-FDA: 82815104988.18.3D6D697 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) by imf03.hostedemail.com (Postfix) with ESMTP id 3C87D20015 for ; Fri, 22 Nov 2024 22:02:11 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=TJjYLcuE; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf03.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.182 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732312933; 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=7GPdysU3+ulwwEZym2gbb4LV2XNAsMZyaMxjoxUdvB0=; b=jAcTMT5m8NqOyTyFtaf88C1lyGzzkLbaoAYws0vTqZRsw44nD3tEAddujRj5EL+3FNiTVO gM/RjIfF2SPiNMGwH53bbwbzblJIWBj5LsV289m/QQpKXIbZnzp+buw9PB9EaefH6kY4Ko 9acLTwYXagZyl8r0JLFYFo6tx4H8NSk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=TJjYLcuE; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf03.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.182 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732312933; a=rsa-sha256; cv=none; b=R5weyv3AC1mlhzPbQx3uszCnxIhM1rXc46eUOLsIi5RHfzJRWrKHrResJF4VA96nn6d3GW 4SUZImVEn0vqC3acUd5NnwrJtS7/Swh6f3Cfpa88qEGRdEH9ezCy0Mfx7oP6MFKyvmdH3C jZKayBUeG+T4g+5APlpkwA48NqWYOMk= Date: Fri, 22 Nov 2024 17:02:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1732312927; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7GPdysU3+ulwwEZym2gbb4LV2XNAsMZyaMxjoxUdvB0=; b=TJjYLcuEehU9rXjjANl641dzAmpdwyRVnPXBAD3hi93j7iO70q+kZM0cRhqXky8BYbwpzs vNEt9DhzO6PHrmTnqLmq6uLj7B800wnZRup6/7nRZjkbm6jQV3gSwa6p8+IMuVzdg442sz uRH30CxPY04qAHyFUmghkytqv+J0G78= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Dan Williams Cc: Michal Hocko , Dave Chinner , Andrew Morton , Christoph Hellwig , Yafang Shao , jack@suse.cz, Christian Brauner , Alexander Viro , Paul Moore , James Morris , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-bcachefs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, maintainers@linux.kernel.org Subject: Re: [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Message-ID: References: <6740fc3aabec0_5eb129497@dwillia2-xfh.jf.intel.com.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6740fc3aabec0_5eb129497@dwillia2-xfh.jf.intel.com.notmuch> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3C87D20015 X-Stat-Signature: fam3qzj8xwzeq6wci4tf5h33a3tyjrfd X-HE-Tag: 1732312930-599036 X-HE-Meta: U2FsdGVkX18KX92tesOoYL0O3t7MmYShFv+vVB/5nsF0z4x+jRSE2SRYyly66RA2AOzkHgZRy0p2vu0VfAR6hpK5aHQavy3zRySBbnl0q+vZN065W44a/5za9L2XD5l1LXoBnXgAoGa2VREaJY52pr9NSdeASyFWboWq+5+TYfprUPRDf5+FW2iKQZM2qLCR70C57xHLKI6Jg6GOITdkGoVt9bDuqaMaLQpyVWOmdBjrLo6Y0gy7+e+SgsWg1GiY9Cns+iRoauGmBpy9DBU73K2lzv1xlCgJm7BNrb4m4dVFA49pqNbZDOGJu9D9EEX+Lf7kf/8KdiP68q7RrbaBkYe+ByzahcFFtAC/G82l2f5lq1B1tzXcn/zK29A+mEtCOY6sHnYAxGVBAdyt/JfaqXkaFZb5HFgUwewORrhRwbewK66er30RlFeIbUdr0ZtPVqiupYEzSMjwFkM6v/eD+69pFowPNiNLbxJwG9eDlh74dcY60UR7WYf7VsDFPVEDGxphqAnM+BLDtAHFjl/3NIAGrKT7faj46LVxHkNSI7if7vkh7a5dH/CR4jmY5Tpt70SM0oM2WgCx0ZVWSO7emcZ4TaY8CSFIgEvLZ7w4Iap1xzRhh+WcAYVA6P8QLPpAFaRs+rA4QfYoYhuaygVekLsE8788GPgW7C5wiSB/oIz45nqJJa7ME/dwLdomFP7w7qdji+KDVAaX0AkuoWOGEPlNn+evC+kVkyhs3eNZy3zIPHvB3CsXkKoZNFtpgL3xFoK3WQddFhduFmdsSzO3IwdHCILW45gXyHlldG6pz7jmtx6KUEx9fiMEM18XlrzFaCRqaAKO5jLycGMAwe0VcoQAt9jAGyoS6Bt+d51nJxnCl8fMXJDjWoqPg9VVVsERaX82jRAxxyuMtkrBZPnI7ZdiJodCRImWEJploTV58CuqytIqAxAnKwabk7c/VEgNsoJLrNbvgneiKSOnTkE TticzXBV 6Pt0/UZzBb+1p4gc+X8uSCPwc9gYI9e4hQiNPozCiEDYR/OP9WTX1aDCyy6PKlKjt8duPU/qCpUHKhoewD9SGmBSqaRAXS1Ibp0uaWmvaeg32xCN+XYbBYark1mbM1RyCILwXoGoHCE3r0moCjqxaC3eiWC3/uVkwjmlwacvHuXkiDG5nIczc4ZFA4OI81KvBA1kn6zHjyv5hqTxas3huMVRCM6m2ZFqi7xCl4lxZ1TjhTzmi9EzvY40k9iRcidgVBN8u7AJ+MqG+YUcAkVxuIDPtPRzI5dtYs/P0e8MeZr+yE+IC8XtDoWDz+dYxOx02WAmqM1ylZG9xtY2hSIm22ve1QMhi/beKwCb1V3fj7iSJsR9EOyBXVLfEOA== 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: List-Subscribe: List-Unsubscribe: On Fri, Nov 22, 2024 at 01:48:42PM -0800, Dan Williams wrote: > Kent Overstreet wrote: > > On Mon, Sep 02, 2024 at 11:39:41AM GMT, Michal Hocko wrote: > > > On Mon 02-09-24 04:52:49, Kent Overstreet wrote: > > > > On Mon, Sep 02, 2024 at 10:41:31AM GMT, Michal Hocko wrote: > > > > > On Sun 01-09-24 21:35:30, Kent Overstreet wrote: > [..] > > Kent, > > The Code of Conduct Committee received reports about your conduct in > this email discussion. > > Link to email where the violation took place: > > https://lore.kernel.org/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk > > Our community works on trust and respect and has agreed to abide by the > Code of Conduct: > > Reference: https://docs.kernel.org/process/code-of-conduct.html > > The code of Conduct Committee has determined that your written abuse > of another community member required action on your part to repair the > damage to the individual and the community. You took insufficient action > to restore the community's faith in having otherwise productive technical > discussions without the fear of personal attacks. > > Following the Code of Conduct Interpretation process the TAB has approved > has approved the following recommendation: > > -- Restrict Kent Overstreet's participation in the kernel development > process during the Linux 6.13 kernel development cycle. > > - Scope: Decline all pull requests from Kent Overstreet during > the Linux 6.13 kernel development cycle. Ok. Just to be clear on what this is about though, I'm going to post publically what I wrote Michal back in September. This is about a CoC board that on the one hand, doesn't wish to follow its own rules, and on the other - I can't even make sense of. >From kent.overstreet@linux.dev Wed Sep 4 14:22:39 2024 Date: Wed, 4 Sep 2024 14:22:39 -0400 From: Kent Overstreet To: Michal Hocko Subject: Re: [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Message-ID: <5qukfetlxkadrdjp443xlzbyjhw26l3zzgcdlmfkxgbkpkrv65@hobl73hoc5ip> References: <20240827061543.1235703-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Status: RO Content-Length: 4224 Lines: 88 On Mon, Sep 02, 2024 at 11:39:41AM GMT, Michal Hocko wrote: > On Mon 02-09-24 04:52:49, Kent Overstreet wrote: > > On Mon, Sep 02, 2024 at 10:41:31AM GMT, Michal Hocko wrote: > > > On Sun 01-09-24 21:35:30, Kent Overstreet wrote: > > > [...] > > > > But I am saying that kmalloc(__GFP_NOFAIL) _should_ fail and return NULL > > > > in the case of bugs, because that's going to be an improvement w.r.t. > > > > system robustness, in exactly the same way we don't use BUG_ON() if it's > > > > something that we can't guarantee won't happen in the wild - we WARN() > > > > and try to handle the error as best we can. > > > > > > We have discussed that in a different email thread. And I have to say > > > that I am not convinced that returning NULL makes a broken code much > > > better. Why? Because we can expect that broken NOFAIL users will not have a > > > error checking path. Even valid NOFAIL users will not have one because > > > they _know_ they do not have a different than retry for ever recovery > > > path. > > > > You mean where I asked you for a link to the discussion and rationale > > you claimed had happened? Still waiting on that > > I am not your assistent to be tasked and search through lore archives. > Find one if you need that. > > Anyway, if you read the email and even tried to understand what is > written there rather than immediately started shouting a response then > you would have noticed I have put actual arguments here. You are free to > disagree with them and lay down your arguments. You have decided to > > [...] > > > Yeah, enough of this insanity. > > so I do not think you are able to do that. Again... BTW - (after getting emails for three different people about this, heh) I do want to apologize for things getting this heated the other day, but I need to also tell you why I reacted the way I did. Firstly, it's nothing personal: I'm not axe grinding against you (although you were a major source of frustration for myself and Suren in the memory allocation profiling discussions, and I hope you can recognize that as well). But I do take correctness issues very seriously, and I will get frosty or genuinely angry if they're being ignored or brushed aside. The reality as that experience, and to be frank standards of professionalism, do vary within the kernel community, and I have had some _outrageous_ fights over things as bad as silent data corruption bugs (introduced in code I wrote by people who did not CC me, no less; it was _bad_, and yes it has happened more than once). So - I am _not_ inclined to let things slide, even if it means being the asshole at times. Thankfully, most people aren't like that. Dave, Willy, Linus - we can be shouting at each other, but we still listen, and we know how not to take it personally and focus on the technical when there's something serious going on. Usually when one of us is shouting, you'll find there's a good reason and some history behind it, even if we also recognize the need to try to tone things down and not be _too_ much of an asshole. Linus was reminding me of that yesterday... So for the record: I'm not trying to roadblock you or anyone else, I'm just trying to make sure we all have shit that _works_. And I have been noticing you stepping up in discussions more, and I'd like to encourage that, if I may. MM has been lacking in strong technical leadership for a _long_ time - Andrew's great on the process side, he makes sure things move along, but we haven't had anyone who's trying to keep everything important in their heads, who's able to point out to people where their work fits in the larger picture, and there's been some messy things that have built up over time. And a word on technical leadership - it doesn't mean being the one who's "right" all the time, although it does involve a lot of saying "no" to people. The people who seem the smartest - it's not raw IQ that they've got (although that helps!), it's the ability to listen and quickly incorporate other people's ideas without drama or attachment, and the ability to maintain perspective; notice what people are blocked on, without getting stuck on it, and think about how it fits into the wider perspective. Cheers, Kent