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 DE57EC433EF for ; Fri, 22 Apr 2022 05:40:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53C176B0072; Fri, 22 Apr 2022 01:40:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EB1A6B0073; Fri, 22 Apr 2022 01:40:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B2646B0074; Fri, 22 Apr 2022 01:40:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 2BE256B0072 for ; Fri, 22 Apr 2022 01:40:19 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DCA2F605E8 for ; Fri, 22 Apr 2022 05:40:18 +0000 (UTC) X-FDA: 79383414516.25.A6D4245 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf06.hostedemail.com (Postfix) with ESMTP id 738EB18000E for ; Fri, 22 Apr 2022 05:40:17 +0000 (UTC) Received: by mail-qk1-f170.google.com with SMTP id s4so5195122qkh.0 for ; Thu, 21 Apr 2022 22:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jAQ2pbLdTfhl30ocu6C+i1NM+Q2M0iWmeznVvUstHlo=; b=cUpqEGNJFGjvcc9JuIKeWlJ+JFHIyTAM3pTNyWHFrgX+4i24Jz04tla9xUNfTyCzl5 bVuFcQlxAE26UsTsQxAN7GpSdben9COgaKlYI/iGO40dFVZKmNe1TqyiUrdJs6ZYjbaz s4xxezv+/nxuwd708wIPqKFaoPQPqrp1Ml5ubK4d9F/HTzuaWcHHpMDKbzLDQ4salERd LjqebR9MH14fAY3T9gGWCQtIvNvP8GaV2KRJRmUGUNR13OtDCXyIMhTXzscHn6kE6p53 N08EvVn/iYw3ZG08FCdnMZRB24CoqNB2RN7zDRN4MecNix57jMnprdm7Rd1UFbtqLOD0 2EMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jAQ2pbLdTfhl30ocu6C+i1NM+Q2M0iWmeznVvUstHlo=; b=Y1gWes9o0zLMGAzn6LmxWVv4WDsQCLflNNiB0hHpdZoAX8s1SmtHXnb/1tsndeZMIK BUD7NUxJlxDYkm9veSqUmuDdVZDEdEY1Mu2JJ50PAj5RA1oANd8kGFtcQbNQQ2T7CiWl 4TrfE+joEhoqRLwdpaE2IkoCtieZckBUeVOTqrfUud02rPe3S0YZkx/dO3TVyRv0M8PW 1VcEX1/71ex3ErTti77duoTO/ZiqowNnVpyALBE/VWJWRJhsExdTt9oB6IAePQqd+rSW levyoSzgJxCRwMIVVClm+x+/yU4RVc01aiyZjwqCmKS3iwAi0IeIpFRTyeJKg4SR4ktu 4+rA== X-Gm-Message-State: AOAM531RitSfByrTsMiPs0RW7dsr6+/McTJqJo3KMs/O/U7TjpULJK/z KXj7+eITppHR2uhPxNrTJQ== X-Google-Smtp-Source: ABdhPJzeaQoIWaOjnQOFgQA3ulm2DVNPu04DBzQixKkQFqrNtoHzoLH3h5SHG6932KbYJ0RP8l+S2Q== X-Received: by 2002:a37:bc1:0:b0:69d:ea33:7f2e with SMTP id 184-20020a370bc1000000b0069dea337f2emr1638627qkl.74.1650606017616; Thu, 21 Apr 2022 22:40:17 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id b11-20020ac85bcb000000b002f35ab13e36sm229485qtb.51.2022.04.21.22.40.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 22:40:16 -0700 (PDT) Date: Fri, 22 Apr 2022 01:40:15 -0400 From: Kent Overstreet To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org, linux-input@vger.kernel.org, roman.gushchin@linux.dev, rostedt@goodmis.org Subject: Re: [PATCH v2 1/8] lib/printbuf: New data structure for heap-allocated strings Message-ID: References: <20220421234837.3629927-1-kent.overstreet@gmail.com> <20220421234837.3629927-7-kent.overstreet@gmail.com> <20220422042017.GA9946@lst.de> <20220422052208.GA10745@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220422052208.GA10745@lst.de> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 738EB18000E X-Stat-Signature: z3f8zw54az4mqxmquu7fwqa6onqq6u1j Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cUpqEGNJ; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1650606017-426612 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, Apr 22, 2022 at 07:22:08AM +0200, Christoph Hellwig wrote: > On Fri, Apr 22, 2022 at 01:14:48AM -0400, Kent Overstreet wrote: > > Christoph, you have no problem making more work for me but I can't even get you > > I think you are misunderstanding this. You are trying to create more > work for people maintainaing the kernel by creating duplicate > infrastructure. The burden is always on the submitter. > > > to look at the bugs you introuduce in your refactorings that I report to you. > > > > Still waiting on you to look at oops you introduced in bio_copy_data_iter... > > I'm not sure why I shoud care about your out of tree code making > assumptions about block layer helpers. Wasn't just bcachefs, it affected bcache too, as Coly also reported. And I wrote that code originally (and the whole fucking modern bvec iter infrastracture, mind you) so please don't lecture me on making assumptions on block layer helpers. Here's the thing, I think you and I have somewhat different approaches to engineering. Personaly, I find good engineering to be about tradeoffs, not absolutism, and not letting perfect be the enemy of good. So I'm honestly not super eager to start modifying tricky arch code that I can't test, and digging into what looked like non trivial interactions between the way the traceing code using seq_buf (naturally, given that's where it originates). I like to push out code that I have high confidence in, and the patch series I pushed out I do have confidence in, given that it's been in use for awhile and it's well tested in my tree. Now yes, I _could_ do a wholesale conversion of seq_buf to printbuf and delete that code, but doing that job right, to be confident that I'm not introducing bugs, is going to take more time than I really want to invest right now. I really don't like to play fast and loose with that stuff. And the reason getting this from you really irks me is that _practically every single time_ I trip over a something nasty when I rebase and I git bisect or blame it's something you did. I don't even bother reporting most of them to you. I don't want to be calling you out for the work you do because on the whole it's good and appreciated - I saw the patch series go by getting request_queue out of filesystem land, I'm happy that's getting done. But I've also seen the stuff you submit get _really_ churny at times for no good reason, and some really nasty, data corrupting bugs go by, so... Please chill out a bit if I'm not super in a rush to do it your way.