Message-ID: <ca995ed7-e6db-4265-e528-5e29fb418594@suse.com>
Date:   Mon, 13 Mar 2023 14:27:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: [PATCH v4 1/5] mfd: Add support for Intel LJCA device
Content-Language: en-US
To:     "Ye, Xiang" <xiang.ye@intel.com>, Oliver Neukum <oneukum@suse.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Matthias Kaehlcke <mka@chromium.org>,
        Lee Jones <lee@kernel.org>, Wolfram Sang <wsa@kernel.org>,
        Tyrone Ting <kfting@nuvoton.com>,
        Mark Brown <broonie@kernel.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <brgl@bgdev.pl>, linux-usb@vger.kernel.org,
        linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-spi@vger.kernel.org, linux-gpio@vger.kernel.org,
        srinivas.pandruvada@intel.com, heikki.krogerus@linux.intel.com,
        andriy.shevchenko@linux.intel.com, sakari.ailus@linux.intel.com,
        zhifeng.wang@intel.com, wentong.wu@intel.com, lixu.zhang@intel.com
References: <20230309071100.2856899-1-xiang.ye@intel.com>
 <20230309071100.2856899-2-xiang.ye@intel.com>
 <097d1742-1aa8-fc0b-db11-3571ea49383d@suse.com>
 <ZAqukC7XfSbIa9ov@ye-NUC7i7DNHE>
From:   Oliver Neukum <oneukum@suse.com>
In-Reply-To: <ZAqukC7XfSbIa9ov@ye-NUC7i7DNHE>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YTBXVWFXN2x0cDBrenM5NE5MaCs2WTJ2RjNnZ3VXY3dyWUNDa3BreUsvNzBO?=
 =?utf-8?B?cGJQRTRpaTE0V3hDTkhuNElZUWZnbTVSRU53aFd0ZnlZQm9mNUpaUWtkR0NM?=
 =?utf-8?B?RGhCb0c4YnMwNy9GbHZhdmxndmQ2ckdDaU1VM0wrdWt1SmJZU05scFNlU0Jw?=
 =?utf-8?B?N1NweXJRUysxaFZYZXhLcy82b1JtejQ4ZGg5WG5QN0Z2dUQwaytaRG9OT2ds?=
 =?utf-8?B?SmdjOTROa3dlRGtrRVN1bEs1TXIrdEQ0ZGxqN01pWGlYQ3hOTjJrY2Q2bndi?=
 =?utf-8?B?dkpnWU1NZU1QUXlPR0Z0eGRBN1hiRzNRaDZuZk9qb3JId3NPaHhEZFpQdmNX?=
 =?utf-8?B?bXhXUDllTEFQN2wvMUxTelVBQUZZWHBjZk1rSEYrWkVqVFVZVmlMbWxOTVVP?=
 =?utf-8?B?WGV5U0FhZkpIWWxqUE1Ja1dlVm1lVFdUblFtQzlXMFBYcDJnQVRIdmZvd3pm?=
 =?utf-8?B?N0JJOVBHbGpub21ybmtRTmc0ejdaQU5LRnRrbWRrSE9ZdlNjQkRST1lQVklm?=
 =?utf-8?B?RmdXTjRpcXZxd2loYVdldERzKzF0cWZCMVAvc1NCR1BNQk5EUk5STlZiWDZp?=
 =?utf-8?B?cnpiU3N0MzBJakNvUlhkVC8vVDhxNkhYWDZpQTdlaUZPM0FkSGVrWmpZYlhr?=
 =?utf-8?B?L2tuZWhwTCt4azk0NWM2NUZpRmdHWnFBYTZ2Q1JBQVIxMGp6c0hZblVyUVEy?=
 =?utf-8?B?Z0tVSTBTWXJaSDFFViszY1Z6bkE0VUFaOGZoMXVVemFwMzA0c2tjVnptWEIx?=
 =?utf-8?B?dGs2MXFiLzBOSUJxQTR2SVRkcFdDeUQ1MzJzaGYwc0xPNWdRWGZLUzJ1eFlj?=
 =?utf-8?B?dkJXVmRwd1k3KzhBYmpxenFUdStBYTI2SFdJaWhuZHFMaWhNb3pFTGJ1aUxm?=
 =?utf-8?B?eWVzdnQ1M21FL0REaXMxZ3RmdHJJemJldTMxUzFMa1JHeEcrWTNPMmhhRDJP?=
 =?utf-8?B?Z2M3ZnduMmU2ZlYyY1VKSFMxd2txWmphNG12T1JjOFhDMGlyR0h6T2ZIOHBL?=
 =?utf-8?B?bXdtVC9vYmZ3SDRXT0xhVDlFQmtIKzRoMEt2VG9qUjE5dWlDMnFudFFyODRE?=
 =?utf-8?B?N0l2MktyMDR0dS9MdmE4VjVhcGxFV1VSRVVlOE92YlZMcnprVUg5NXBmWG8w?=
 =?utf-8?B?eDEyS3ZFK0hDRFZQRzMwYVk5WHpmbHpBUlNEdTlrcFdCRHJIN3JMdGRYdEpO?=
 =?utf-8?B?S1JDelFRdDNLVUtaZGNyU0l1K25Ja2syclM2QmhyL1RRN2dsZEEwdWJLYnJk?=
 =?utf-8?B?dWx3N0pieE9CYXdVakx2elVGRHM3eDdTNVJwL1ltcCttK1FaRXN6KzF5Vmpo?=
 =?utf-8?B?b01mQXZXc3lmQTZ0VDhwS0xxaHZDYXN6blRoRU5naWdRa1MvNWFjM0NkSEFE?=
 =?utf-8?B?OXcrTjc1bm5GcVpJUm5jU2M3MXNMZ0h6RkRHVzZxaUdhaUk3UlhYK2xpY3hV?=
 =?utf-8?B?dCs4RWxUYTBsSTE3ZVczUVh4UkR3Q0thRXFqZEtaRkVSOGRyQTdUUzB6TzZM?=
 =?utf-8?B?MUorVVJVMGNXdWUzQVp4MkZsTG1sWFpQSjJSVVlMazloMDgyRDBpbEZhMjgy?=
 =?utf-8?B?NlI2aUpyclkzTWllbjZOTGJPUVRrOENpZVpiZm9MSmhwUnlXVjJqemM2THZN?=
 =?utf-8?B?K0M0Yk5zTVBjVTNWYmRDZXVXRXFuOC9RVElnWFNYMElYTUZQQk5NS3g1QXBl?=
 =?utf-8?B?bG56cXJhY0NUNThMcU1UYm96a0lPckcxVks0Y1hGVjFEdGlLRlRtWTluSWIx?=
 =?utf-8?B?a05WMXJ6OE55V0NzQWpQakZIbmE3SmxFVHp4Sy8yb2hSbU1xR2oyTjVBM2dW?=
 =?utf-8?B?R3RmNDBBOUFnci9Kekk3VC9SVkFUK2ZodElrZEpDMzF0MHBaSk1LZURPTmk3?=
 =?utf-8?B?ODFZUHcxZHlDZk9yK0tqSnYveE5kdXMzMHc0b1BUcitUaUhqdWR3UDU3N3NW?=
 =?utf-8?B?OXB5bkU4cjRrakZYOERWNmRCTXdTQWZhKzJNcnl5SEEzYzk3cThsNmJ4aWdJ?=
 =?utf-8?B?ZVR4cHFWMkhUOVZNd1dWV1NDTE5mNlI2NVBhNS9jcWMraFpBTGhWMU12a3o4?=
 =?utf-8?B?azRqMWlNdVFJZjVFOWxUWWtLUmtPVFFob1M5TVIxUUpDaHN0VHlvUXNyKzB1?=
 =?utf-8?B?SkhTMEdFWmtFcVJ5aE1hS3dIT3M1K0tMNzRvRGdINDBkem1lcEw1WnU5VTA2?=
 =?utf-8?Q?c/Y8WkMNt5h8N9hGKOVT3Mx6mTINvLSP7jkTb2eyKS1h?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 232e894a-30cf-4d92-6d0c-08db23c6c02a
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB7104.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2023 13:27:53.9903
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bhdzMBWmu0uZS0GPci6S8Aaj982UF+ZWlgkZVOJbN964sIx4mT/qUmO2xfFaCs1LiGN1r41j7lMYRXOJleJENg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR04MB7552
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10.03.23 05:14, Ye, Xiang wrote:
> Hi Oliver,

Hi,

sorry for the delayed answer.

> Thanks for your review.
> On Thu, Mar 09, 2023 at 01:53:28PM +0100, Oliver Neukum wrote:
>>
>>
>> On 09.03.23 08:10, Ye Xiang wrote:
>>
>>> +static int ljca_stub_write(struct ljca_stub *stub, u8 cmd, const void *obuf, unsigned int obuf_len,
>>> +			   void *ibuf, unsigned int *ibuf_len, bool wait_ack, unsigned long timeout)
>>
>> Why do you make ibuf_len a pointer?
> Because ibuf_len is also used as output of this function here.
> It stores the actual length of ibuf receive from LJCA device.

Yes, I understand that now, thank you for the explanation, yet
that is problematic, if we look at another issue. See further down:

>>> +		ret = -ENODEV;
>>> +		goto error_put;
>>> +	}
>>> +
>>> +	mutex_lock(&dev->mutex);
>>> +	stub->cur_cmd = cmd;
>>> +	stub->ipacket.ibuf = ibuf;
>>> +	stub->ipacket.ibuf_len = ibuf_len;

Here you store the pointer into the stub. Hence we must make sure
that the location it points to stays valid.

>>> +	stub->acked = false;
>>> +	ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, dev->out_ep), header, msg_len,
>>> +			   &actual, LJCA_USB_WRITE_TIMEOUT_MS);
>>> +	kfree(header);
>>> +	if (ret) {
>>> +		dev_err(&dev->intf->dev, "bridge write failed ret:%d\n", ret);
>>> +		goto error_unlock;
>>> +	}
>>> +
>>> +	if (actual != msg_len) {
>>> +		dev_err(&dev->intf->dev, "bridge write length mismatch (%d vs %d)\n", msg_len,
>>> +			actual);
>>> +		ret = -EINVAL;
>>> +		goto error_unlock;
>>> +	}
>>> +
>>> +	if (wait_ack) {
>>> +		ret = wait_event_timeout(dev->ack_wq, stub->acked, msecs_to_jiffies(timeout));
>>> +		if (!ret) {
>>> +			dev_err(&dev->intf->dev, "acked wait timeout\n");
>>> +			ret = -ETIMEDOUT;

The function will return an error in the timeout case.
This may be a trivial observation but it becomes important.

>> If that triggers, you may have a pending URB.

I misspoke. Pending IO would have been correct.

>> You must kill it.
> which URB? I guess what you mean is dev->in_urb?
> But the in_urb should always be up to waiting for message from firmware,
> even through this timeout happen.


Now let's look at ljca_mng_reset_handshake(). I am afraid I have to quote
its first part in full:

+static int ljca_mng_reset_handshake(struct ljca_stub *stub)
+{
+	struct ljca_mng_priv *priv;
+	__le32 reset_id;
+	__le32 reset_id_ret = 0;
+	unsigned int ilen = sizeof(__le32);

This is on the _stack_
Highly important !!!

+	int ret;
+
+	priv = ljca_priv(stub);
+	reset_id = cpu_to_le32(priv->reset_id++);
+	ret = ljca_stub_write(stub, LJCA_MNG_RESET_NOTIFY, &reset_id, sizeof(reset_id),
+			      &reset_id_ret, &ilen, true, LJCA_USB_WRITE_ACK_TIMEOUT_MS);

If we run into the timeout error case, ret will be -ETIMEDOUT.

+	if (ret)
+		return ret;

And thus here we return and free the stack _including_ "ilen", which we
still have a pointer to. That means if the operation concludes after
a timeout, we _will_ follow a rogue pointer.
A couple of functions have this race condition.


>> What happens to stub in the error case?
> ljca_add_mfd_cell only failed when krealloc_array failing. When
> ljca_add_mfd_cell fails, the related stub just be left alone here.
> 
> Maybe I should free the stub here when fails? what is your advice?

Yes, that is the cleanest solution.

>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>
>>
>>> +
>>> +static void ljca_disconnect(struct usb_interface *intf)
>>> +{
>>> +	struct ljca_dev *dev = usb_get_intfdata(intf);
>>> +
>>> +	ljca_stop(dev);
>>
>> What prevents restarting the device here?

Sorry, you are calling ljca_start() only in probe(9 and resume()
Your code is correct.

	Regards
		Oliver