From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) (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 5B01C18B0F for ; Sat, 24 Jan 2026 10:47:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769251650; cv=none; b=Wg1j/rA+AfuRsq6Xqls8xa1C5nS1QjkGRqhga4uy8MudyUgU3LqxHdxpPae25NDNwVSbBOTZbHtXyC7tZAYW6qBB/vGNVtAXMqswZN13gJdFrMnXxUyGCRDdfotVmDIa8VrI1BqzkbRdEb0FgOBLGFtAXw351lV6SHZs/GlNF1c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769251650; c=relaxed/simple; bh=4Mjk+fF40ceI4R/t2q+AJEgfmjjYtKHo0c/kooa25vI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CfmaoE544Id60ktLkjn8vkNWBEnNp/dYbeqyLk5HiFoVIcar8BIrNeYls9qKuBISWADDVj4sUNvH2RaXmlYzoUKNTtlvABLZu2ifSWh9IHC54Olm0xeU3QrMZaXwLj53lqH1BnzOnDK9vvIy15byU0SiYEGi56YtqvCFDrgo4JY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=FvuM82jL; arc=none smtp.client-ip=209.85.221.67 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="FvuM82jL" Received: by mail-wr1-f67.google.com with SMTP id ffacd0b85a97d-4359a316d89so2326926f8f.0 for ; Sat, 24 Jan 2026 02:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1769251648; x=1769856448; 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=PDUcuGLtSATdOwWmJYbA7S8LzZRTPKGXoW+hiKHosIk=; b=FvuM82jLjmKeL4riRNGE1lH1pAGbka2uEynczkk/S/2glH3NkDNuT77D3lYZFKKXae rnN415PJQFxWPa/ehgMkUWArJ6CJZUxMIKROuKnNf7cIM5jkaObUtQkWY/FIotchkyCO gXXxjNdEnOmHl16LbcMdYKIXuS86GqiI4naJ8XKVkUQKxVjdfpfz7E1K1pSX8Z0tUuLi NaVqtU9ZLLCAF0C2cWXv9YQdHkCrgx5oC+5lA3ZTPdCjhCGC4YMvc5NBuf7aQab3WFf4 AhW40x8ADwIYibHPk2G9YhP4pErAk8Rp1ucBrTp8PcSMgNy2y/5NssLmQ2Hm6lETNb8J oJCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769251648; x=1769856448; 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=PDUcuGLtSATdOwWmJYbA7S8LzZRTPKGXoW+hiKHosIk=; b=EyhnqqWmbWw8CKkFz8heotj6q6oDZ2ZapKUkNlA+iPUlJVfs8hupGBa19BoNNU/SYW EYqKpM2OiHsIksjAuTjGeml3uBlLfbfL2HfUQSqCg+7oOtMunN+cVjql0nXzd1jX/h6z VNwAiWSq3oThHoMxjL3H8hB7S5FYrtkTjsDam9Z4v2iA+LW22RSfycais/t5WySeKvzV DpTLW45cooRSLslKDkT5KVPvT3QYMEULqRIbbtfA77VRZtndECb5F+hN4leRGPhBBJcb +qTuv6F4KJMQIm3JVzKCR9+c9p/lmjF0uvaDTtFZ7KWVSpwcBH1gHhn872ZnkeufCiiD NSJw== X-Forwarded-Encrypted: i=1; AJvYcCVoiIJEfSytjEfTfz8GmcB2YtusS44TQd6xKd6BB5ojxew9IqQTwvFH6nBfVSlxOb7GUKL7gsoPX7EesPs=@vger.kernel.org X-Gm-Message-State: AOJu0YwrXymBvIZAU3uTB8Bq/0gntbXSYn+Z8eLh6zELpRfB+mLsaDCA NVDzqC9pGBjDPBbg+hR6a3SQdjsHuN2dt5E2PT3gQyIHm6g1PfHQ2ZmLVvUMJW41ZuE= X-Gm-Gg: AZuq6aIcTHLQXyCJR3nvMtsi9CViUm7eWM2VYxbJLhTnfRq/3yP3kqpRIYptgIY8ogM 1hyVlCsfUs1nU8xefMmk/8ChBu5kCBCr6yjR4PmAio7wfoNCTZkwztiDzYQukdczHi2iyLdJbmG P7b56gp9E+qy+k+ed8PnOLMdvsDZYOoZN2O9LlnPBXwCqUelBnLEVexSevxdGJax00J3SLZDdPL cMBrJXCEwbRjerUB62OqqnYi4YXw3bA964h/x4MrTB2bVO0DVxwLyp2fLDIH6FsvdHuuDmBikA8 WEwUbDggDlqiFOrmAT2wxqRzl7xuv3gKPUblSpcCPEPIy0lWGnPTX6o4VMc7BwXYeUyOsFasS2T Lv4En+O3S34oLXhvRLXNTFbWP74DAw8/9ZQ0rsKqJjXhMZMXyHmTLN28utKhqy63RpD4T+kI3Nr LklwKd9P+qAtTVMs3NrUFEkstDvP8= X-Received: by 2002:a05:6000:40dd:b0:435:a2f8:1515 with SMTP id ffacd0b85a97d-435b1587983mr9884751f8f.10.1769251647634; Sat, 24 Jan 2026 02:47:27 -0800 (PST) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1e7156dsm13469488f8f.20.2026.01.24.02.47.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Jan 2026 02:47:27 -0800 (PST) Date: Sat, 24 Jan 2026 13:47:24 +0300 From: Dan Carpenter To: Haoxiang Li Cc: ioana.ciornei@nxp.com, stuart.yoder@freescale.com, agraf@suse.de, German.Rivera@freescale.com, gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Su Hui , Christophe Leroy Subject: Re: [PATCH v3] bus: fsl-mc: fix an error handling in fsl_mc_device_add() Message-ID: References: <20260124102054.1613093-1-lihaoxiang@isrc.iscas.ac.cn> 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: <20260124102054.1613093-1-lihaoxiang@isrc.iscas.ac.cn> On Sat, Jan 24, 2026 at 06:20:54PM +0800, Haoxiang Li wrote: > In fsl_mc_device_add(), device_initialize() is called first. > put_device() should be called to drop the reference if error > occurs. And other resources would be released via put_device > -> fsl_mc_device_release. So remove redundant kfree() in > error handling path. > It is true that we shouldn't free things directly after calling device_initialize(). I don't know the impact of this bug in real life. Is it a leak? > Fixes: bbf9d17d9875 ("staging: fsl-mc: Freescale Management Complex (fsl-mc) bus driver") > Cc: stable@vger.kernel.org > Reported-by: Dan Carpenter > Closes: https://lore.kernel.org/all/b767348e-d89c-416e-acea-1ebbff3bea20@stanley.mountain/ Heh. What was I even talking about when I wrote this??? In my head I remember the code as looking like this: https://lore.kernel.org/all/20251222074958.992911-1-lihaoxiang@isrc.iscas.ac.cn/ But that's not the version of the code that I copy and pasted into my email. The release function looks like this: drivers/bus/fsl-mc/fsl-mc-bus.c 757 static void fsl_mc_device_release(struct device *dev) 758 { 759 struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev); 760 761 kfree(mc_dev->regions); 762 763 if (is_fsl_mc_bus_dprc(mc_dev)) 764 kfree(to_fsl_mc_bus(mc_dev)); 765 else 766 kfree(mc_dev); 767 } The problem is that if this function call fails: mc_dev->dev.type = fsl_mc_get_device_type(obj_desc->type); Then the is_fsl_mc_bus_dprc() check might not work. In the current code the to_fsl_mc_bus() pointer math is a no-op because mc_dev is the first struct member of mc_bus. So it works for now, but it feels wrong. The fsl_mc_get_device_type() function can't really fail in real life. regards, dan carpenter