From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9A243B6362 for ; Tue, 12 May 2026 09:12:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778577145; cv=none; b=Kbn6gY4con2+H+fqglUJWCqoo27JFYi+Z4bl0U/0LUXo0oE7D/6mX+WsxN2qg0ZVf+WuoaWtyMSr5YG0DUS+ZHpJifLTeRxouj5aa5pCFr1/2mT4+Wam8kIAsI/dlPNWPtK83w7bczusZXNUPk14vON2vYLDA4s+IIwcbLjkxJo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778577145; c=relaxed/simple; bh=IrktwSreI4nd5+Fs73VimoFCZbSPT0Gmqe29WLI9ydA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L4xc8mX8EN0MBf7G/+aFf7Da++EWRT/HzhFHy2tsdFmZmGZbBjZg15y2Byw1a8ia++GNFc3N16WWWadI9RVJrWHe8FFR4//QmHspiCcocgsFccghU4Dkzz1JgQ5FJ87zbajkg0NzDvB8Os4rtF6XBjk1QraNmcQujTlfCeExirE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=A44CAG5a; arc=none smtp.client-ip=91.218.175.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="A44CAG5a" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1778577141; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IrktwSreI4nd5+Fs73VimoFCZbSPT0Gmqe29WLI9ydA=; b=A44CAG5aQY2MJ6w7emAua2oqA8MthDecl72KpoJkvlBOeWNU8Nl9YlcpvYihgUuQQVznxZ OITPLmAYlKBMB7PBVNjH4QCUHx69Ri3vjVL7mbdqM1L70HFEaVMOvKHvtY2AWj8hCvRm1N 1A0JPha0Mhyb0YxjHGVHmNTtKE+O7FI= Date: Tue, 12 May 2026 17:12:15 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v1] mm/shrinker: simplify shrinker_memcg_alloc() using guard() To: wangxuewen <18810879172@163.com>, akpm@linux-foundation.org, david@fromorbit.com, roman.gushchin@linux.dev, muchun.song@linux.dev Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, wangxuewen References: <20260512085546.368911-1-18810879172@163.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Qi Zheng In-Reply-To: <20260512085546.368911-1-18810879172@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 5/12/26 4:55 PM, wangxuewen wrote: > Use guard(mutex) to automatically handle shrinker_mutex locking and > unlocking in shrinker_memcg_alloc(). This removes the explicit > mutex_unlock() call, the goto-based error path, and the redundant > ret variable, resulting in cleaner and more concise code. I'm inclined to use guard() only for newly added code. If we were to convert existing code, there would be countless places across the kernel that need updating.