From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C607A23A562 for ; Sun, 3 May 2026 15:02:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777820521; cv=none; b=B8j4ATqzWAypRogZ0GhTehHZBSFO0jJ+oQnZCdEa3HOjkwXumgvBFCVghn0oa4M65TdLbQrXJ8X6cLa7UlcHSS4iY8wmCupaH2tmuV0M+1AKwQSNRcj8CHylFeJKFgcmq8Fuq/+y0BZGm/s80TwtHEfU3n8cNtCugGzqqADI2z8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777820521; c=relaxed/simple; bh=mxiuTSM74D+CaLeXfgdYtfifPRbcHdaHlRBKwbBo1qQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OU26vhDNwtQKUq0225yaKKGilsukNRWd/1w2FQWA8vE/w/B7CrFCRepI1iGkUR0loY9rhwhEcaL/b2K6XQCHyJQxDqbLTJMcARCsI9PMTHPFweoiW67QXBAPnNrIi08RI730NGIyt20mOhy5ATSJ4Rx4fcE5qW/DqnsTlLqtyZU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ezzCAw2O; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ezzCAw2O" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2ba180a022dso22555ad.1 for ; Sun, 03 May 2026 08:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777820520; x=1778425320; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=fnGRoHJD9DIK5jxS2cgW0aYU1wp8JHRLjsfyg7b6pV0=; b=ezzCAw2OfpHY9PBHeNatHTb21QbIJoSO7qETLbtH7vL4gjJT9wuFEq8UqmpWSznkQ8 m0Y4fUj5DX+NCz8zqj7g6V1/0CI9v9cmlQf7L/0eGa7vWO/dv/y8ViLJ+ddBVJZsHpuB wRVgCUjXOj6I0iZj356emwZQ6tJkzm/5LEG6iUFc6AUIqCpEHpUDQ+k4TfH/LiwK5fZv RaXs8E08Ljt0DhCAz139jbKQnDLU5Kf/bHjyxEV+jnWBKnUODfBgGGVoOQkEY5Umh7vq /CpmA33/cbvt3/ITUs2XtcKXZTaKxZjXi9MPGzp55xLsJBsTiGRFuubZ63iwjZ40tfUM 6DIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777820520; x=1778425320; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fnGRoHJD9DIK5jxS2cgW0aYU1wp8JHRLjsfyg7b6pV0=; b=Bm6BofO+OG0ETvqnuwdCTvvwYfURHxjlbGuYB8JKLeDA5vY43H1v0nQd5lNWGLcEb1 4jhgX9lM3VcPiV0GuSSz6dI0/KzXIwmbOqAAiXrFlSs3YcVqVjCbijx6HabL7Bfl42y4 67Qm2l3w/WY81lT5tNrlbWdY51ZShI21nV2Oy4/ylqD7eP8qGsXRR1aNAVCuxPdwwnq6 OkY90r5500yJg4fjxNmAXD1iOnNf5Tj+EWz5bJKFbewdUijGpJcG8n8gdxFZ79JDRjbF vPNxSNUj0825llaVsIMBcLjK8pTaIGdoZEE0AXNsRq+qlET46ICBCbRqIhailOdmvB93 A1kQ== X-Forwarded-Encrypted: i=1; AFNElJ+aye8qSJ53okEISdhDvbnVPHI1H0L5Q8np58fhtG3kLvUMdy+QXPC/CgPFxdJb53m0DsX3bu+BdETZKjA=@vger.kernel.org X-Gm-Message-State: AOJu0YxWFyGQXTEfCCoxbzZTWS8ZDBwcXgkIBYneehdKkSZMnrH09aRt BPkw6rMkiUX92VaKMGkXyiZDoZPOXE1TY7OagrratxQtBtM0niwdHbgB/4dV5yLHAA== X-Gm-Gg: AeBDieuPrD0pORiOY/jVQG50Z3oXl6LYUhfZKsR9cKf9dZaOv+L6S88/4y58ZNHgya1 tgmoWnAYt6eqGPccCRCsvBxUaIDxHxkZ5kxWfuLfuYC9n0CXH/Nd00tbZdRwJFiGGNPF1xjHcqO ISCFX5flQuIhf8dNnvLv9zmmLByMb63tVEqQE/Hz9GCiIJZKcQy+ari/niEOiwu1zds8T/Yronk aASrRcwyx+OlFAsvf+stypN+g/Qdu3ACWOfNqq+Kw7t5UYsd4lAja+Ae2p9oRSNUooULWUBh1tZ JD2FrkZD6HsjYlryNvxvNYczmRUYg7RCgg8jdf+pO6h2FPNbm0X/bYGB8nR02mmHext2915avoe Ir1/0oclrL05OuNGtRn7dBTHfhPMEG0zcHz6uD6flmnxzzAMpEhhRgPehmk0MiVNaDmEDnv7/f+ 8233vSKRpjQlNMxaeSxQrrhQ4GiK1Ub1zRLphb2w0UEoY43dxBuoJDcvOE9YlcRdnF7ulHwbnmP uu5h2WJMPTpw4Gys8qMO2nOuo8CoksiLQ7gGopxsPQRozshBHAvM5RFzYL55JOQVDW2mDFTVcJx Wg== X-Received: by 2002:a17:903:3c2e:b0:294:ecba:c8e with SMTP id d9443c01a7336-2b9f5801b67mr2523835ad.3.1777820519037; Sun, 03 May 2026 08:01:59 -0700 (PDT) Received: from google.com (112.174.16.34.bc.googleusercontent.com. [34.16.174.112]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-364f488df2fsm3665907a91.6.2026.05.03.08.01.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2026 08:01:58 -0700 (PDT) Date: Sun, 3 May 2026 15:01:53 +0000 From: Carlos Llamas To: Bart Van Assche Cc: Christoph Hellwig , Jens Axboe , "Martin K. Petersen" , Chaitanya Kulkarni , kernel-team@android.com, linux-kernel@vger.kernel.org, "open list:BLOCK LAYER" Subject: Re: [PATCH] block: restore mempool reserves for non-block Message-ID: References: <20260503001734.858296-1-cmllamas@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, May 03, 2026 at 06:26:48AM +0200, Bart Van Assche wrote: > On 5/3/26 2:17 AM, Carlos Llamas wrote: > > Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath") > > Hi Carlos, > > Please help with verifying whether this patch series is sufficient: > Christoph Hellwig, fix /dev/sg allocation failures register, April 15. > This patch series can be found by searching for "b520c4eef83d" on > lore.kernel.org. Hey Bart, I did look for fixes but I totally missed commit 7b03c93d2beb ("scsi: sg: Don't use GFP_ATOMIC in sg_start_req()") from mkp tree. Sorry, this patch definitely fixes the issue I'm facing. Thanks! I actually started with this same approach as there was no apparent reason for using GFP_ATOMIC in sg_start_req(), there is even another might-sleep call with scsi_alloc_request() a few lines above. However, it seemed odd to me that after removing the check added by Christoph the mempool allocation would succeed. So there was something else besides a failed slab request that made it work. That is how I eventually found out about the mempool reserves. My (very limited) understanding is that mempool_alloc() attempts to allocate in the following order: (1) from the slab cache, (2) mempool reserves and finally (3) sleep and wait. In this scenario, we now that (1) has failed and (3) is not an option because of no-block flags. However, mempool reserves are still a valid option. Anyway, I just wanted to point that out in case the check needs to be revisited. I'll cherry-pick the fix from Martin's tree for now. Cheers! -- Carlos Llamas