From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-cys01nam02on0092.outbound.protection.outlook.com ([104.47.37.92]:4224 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726114AbeIGEyU (ORCPT ); Fri, 7 Sep 2018 00:54:20 -0400 From: Sasha Levin To: David Sterba CC: "stable@vger.kernel.org" , Nikolay Borisov Subject: Re: [PATCH AUTOSEL 4.18 107/113] btrfs: Rewrite retry logic in do_chunk_alloc Date: Fri, 7 Sep 2018 00:16:17 +0000 Message-ID: <20180907001616.GY16300@sasha-vm> References: <20180830180714.36167-1-alexander.levin@microsoft.com> <20180830180714.36167-41-alexander.levin@microsoft.com> <20180905092232.GU24025@suse.cz> In-Reply-To: <20180905092232.GU24025@suse.cz> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <9884650BE4B5E946878A5D266C69517C@namprd21.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org List-ID: On Wed, Sep 05, 2018 at 11:22:32AM +0200, David Sterba wrote: >On Thu, Aug 30, 2018 at 06:08:33PM +0000, Sasha Levin wrote: >> From: Nikolay Borisov >> >> [ Upstream commit 2556fbb0bead7929ddf67f8b4184f434cee4e7d7 ] >> >> do_chunk_alloc implements logic to detect whether there is currently >> pending chunk allocation (by means of space_info->chunk_alloc being >> set) and if so it loops around to the 'again' label. Additionally, >> based on the state of the space_info (e.g. whether it's full or not) >> and the return value of should_alloc_chunk() it decides whether this >> is a "hard" error (ENOSPC) or we can just return 0. >> >> This patch refactors all of this: >> >> 1. Put order to the scattered ifs handling the various cases in an >> easy-to-read if {} else if{} branches. This makes clear the various >> cases we are interested in handling. >> >> 2. Call should_alloc_chunk only once and use the result in the >> if/else if constructs. All of this is done under space_info->lock, so >> even before multiple calls of should_alloc_chunk were unnecessary. >> >> 3. Rewrite the "do {} while()" loop currently implemented via label >> into an explicit loop construct. >> >> 4. Move the mutex locking for the case where the caller is the one doing >> the allocation. For the case where the caller needs to wait a concurrent >> allocation, introduce a pair of mutex_lock/mutex_unlock to act as a >> barrier and reword the comment. >> >> 5. Switch local vars to bool type where pertinent. >> >> All in all this shouldn't introduce any functional changes. > >Unless there are other followup patches "No functional changes" is a >hint for autosel not to pick the patch. Out it goes, thanks!=