Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1075160ybx; Wed, 30 Oct 2019 09:28:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqy5J3PY7r2P5g8ghYguogqY8w5ZAu4ow3hwFktWC0e2J74u/pUOGO4TQuuNAxHEPnls6Srz X-Received: by 2002:a17:906:3903:: with SMTP id f3mr340420eje.241.1572452885705; Wed, 30 Oct 2019 09:28:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572452885; cv=none; d=google.com; s=arc-20160816; b=gKXwBADawX9fziL8xxZONXqE3EmJWIY/oK+HWS0V163FGVvFsUYI0RBcYZm6bUnP3Q idt0gzokPJHP8csm479GDUiFP7dJzzaUOaK3Hj6mpTJae8PAV55SOP2bADCB2w3ngvz+ UZ5VKxXugUauXxX1hkX+Qt9nlyBHs5wF3G/Ce3f6OpVIHzVyRrMwitjCxPk7/z/sI5BZ gR9Fw9fffMRXty2/nb22MeG36Wgf87GpB21xtCwbfpS6TVe+GrOgcHWuL2rgToV8pe3Y ylU/ct5jpeXx6DJ/tgDG9rEeLegA33UWbN71P/1h8dSAcqriTzQJZZahmBjrPN3ZqHmO RGaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=4/Rv70w/+7EI+JMSXW7d1wcKcps9xuE+Taa/vCwFknY=; b=ZRxdyVXpMTacXKSUwLROEUkxulkikESh1Y3FdbE7LB5roY4rooF+wwZXFFbI+qyIO9 orrynhrnL4wYX88dBYJbFP0qMyau4Z41CwO+3jel5NG9Elh/mZhh1XpTCtbZTwfVQUkQ 1z6Zv492hH1JwPThQQ8FMHZqwhfAnXoFcy10ruoEOwTKm9TJfVb7TiapHlA91DmzteVd Swn1nSrPetL2f98Y2mJPAa4D+Bq96mWX82tAESMyYb1EIwNlY8FFMsO/i00b5/7uVDOA hiLoGMtUw8VQxh+XpS6u0elUGtXe/y33JCm9J54MqWYCanB3Gci0KAdAYQLZzaeYmxCc BwHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k23si1477004ejc.433.2019.10.30.09.27.19; Wed, 30 Oct 2019 09:28:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727481AbfJ3QXJ (ORCPT + 99 others); Wed, 30 Oct 2019 12:23:09 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:41030 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726665AbfJ3QXJ (ORCPT ); Wed, 30 Oct 2019 12:23:09 -0400 Received: from callcc.thunk.org (guestnat-104-133-0-98.corp.google.com [104.133.0.98] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9UGMhhq017904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 12:22:44 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 2C3B8420456; Wed, 30 Oct 2019 12:22:43 -0400 (EDT) Date: Wed, 30 Oct 2019 12:22:43 -0400 From: "Theodore Y. Ts'o" To: Gao Xiang Cc: Gao Xiang , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Jaegeuk Kim Subject: Re: [f2fs-dev] [PATCH] f2fs: bio_alloc should never fail Message-ID: <20191030162243.GA18729@mit.edu> References: <20191030035518.65477-1-gaoxiang25@huawei.com> <20aa40bd-280d-d223-9f73-d9ed7dbe4f29@huawei.com> <20191030091542.GA24976@architecture4> <19a417e6-8f0e-564e-bc36-59bfc883ec16@huawei.com> <20191030104345.GB170703@architecture4> <20191030151444.GC16197@mit.edu> <20191030155020.GA3953@hsiangkao-HP-ZHAN-66-Pro-G1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191030155020.GA3953@hsiangkao-HP-ZHAN-66-Pro-G1> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 30, 2019 at 11:50:37PM +0800, Gao Xiang wrote: > > So I'm curious about the original issue in commit 740432f83560 > ("f2fs: handle failed bio allocation"). Since f2fs manages multiple write > bios with its internal fio but it seems the commit is not helpful to > resolve potential mempool deadlock (I'm confused since no calltrace, > maybe I'm wrong)... Two possibilities come to mind. (a) It may be that on older kernels (when f2fs is backported to older Board Support Package kernels from the SOC vendors) didn't have the bio_alloc() guarantee, so it was necessary on older kernels, but not on upstream, or (b) it wasn't *actually* possible for bio_alloc() to fail and someone added the error handling in 740432f83560 out of paranoia. (Hence my suggestion that in the ext4 version of the patch, we add a code comment justifying why there was no error checking, to make it clear that this was a deliberate choice. :-) - Ted