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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45001C43334 for ; Thu, 7 Jul 2022 16:52:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235367AbiGGQwe (ORCPT ); Thu, 7 Jul 2022 12:52:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236296AbiGGQwZ (ORCPT ); Thu, 7 Jul 2022 12:52:25 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD29457200 for ; Thu, 7 Jul 2022 09:52:24 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 5580621FE1; Thu, 7 Jul 2022 16:52:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1657212743; h=from:from:reply-to:reply-to: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=gTUl6c7wv6QQ0iR9NVEOKsO5XJ/lX51qMTXbK9caEro=; b=NwRblmWbdzZLeTrZfhGyv1rqNZ8mTnFJ/EAOqTFmPVZ1lBvwCHIBI6aNULeQZ78ovx8erj buSXYZ8fBLVStbPyPe2m80k+bhVGYGPSemtjEUywTAczueB2z24INdWHwMAOrnnZoOA5tQ 67sAg/h2y0E1xywQcm61visQ3g5s0EY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1657212743; h=from:from:reply-to:reply-to: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=gTUl6c7wv6QQ0iR9NVEOKsO5XJ/lX51qMTXbK9caEro=; b=NQuKu0wJEW1gAQzNrFgl9ZxcflD4HBzkOYyuZmwfpR2N+RGvMNFasZMiewp78Djyc3KUjA cqdw3kS4h2RRedCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 334FC13461; Thu, 7 Jul 2022 16:52:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id K41UC0cPx2LwbgAAMHmgww (envelope-from ); Thu, 07 Jul 2022 16:52:23 +0000 Date: Thu, 7 Jul 2022 18:47:36 +0200 From: David Sterba To: Christoph Hellwig Cc: fdmanana@kernel.org, linux-btrfs@vger.kernel.org Subject: Re: [PATCH 1/3] btrfs: return -EAGAIN for NOWAIT dio reads/writes on compressed and inline extents Message-ID: <20220707164736.GH15169@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Christoph Hellwig , fdmanana@kernel.org, linux-btrfs@vger.kernel.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, Jul 04, 2022 at 04:57:41AM -0700, Christoph Hellwig wrote: > On Mon, Jul 04, 2022 at 12:42:03PM +0100, fdmanana@kernel.org wrote: > > + * filemap_read(), we fail to fault in pages for the read buffer, > > + * in which case filemap_read() returns a short read (the number > > + * of bytes previously read is > 0, so it does not return -EFAULT). > > Two overly long lines here, which are especially annoying in block > comments as they completely break the layout. The only line that is not under 81 is the last one and what does not if is "T).". This is within the acceptable overflow and I adjust many lines in patches based on how the code looks (ie. avoiding some line breaks) and if the potentially overflown text does not obscure the meaning. Keeping the lines under 80 makes sense for me personally when resolving conflicts in the 3+1 vimdiff view, but the limit is not strict and the criteria is if the code follows the common patterns we've settled on and what people in the btrfs group are used to, either reading or writing. The kernel coding style does not cover everything and is a good starting point. The rest is at https://btrfs.wiki.kernel.org/index.php/Development_notes#Coding_style_preferences