Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756272AbdDRKwI convert rfc822-to-8bit (ORCPT ); Tue, 18 Apr 2017 06:52:08 -0400 Received: from hermes.aosc.io ([199.195.250.187]:36345 "EHLO hermes.aosc.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164AbdDRKwG (ORCPT ); Tue, 18 Apr 2017 06:52:06 -0400 Date: Tue, 18 Apr 2017 18:51:43 +0800 In-Reply-To: <20170418072505.GE3899@wtj.duckdns.org> References: <20170315161406.smd4na25two55jjh@angband.pl> <197431489595078@web8g.yandex.ru> <20170316010615.GA23552@kroah.com> <20170317140812.GB5078@htj.duckdns.org> <785901489760914@web50g.yandex.ru> <20170317144422.GD5078@htj.duckdns.org> <3cf02066-ca0e-05f4-6a3d-ebc6d5373caf@arm.com> <20170418072505.GE3899@wtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349 To: Tejun Heo , =?ISO-8859-1?Q?Andr=E9_Przywara?= CC: Icenowy Zheng , Greg Kroah-Hartman , Adam Borowski , "linux-kernel@vger.kernel.org" From: Icenowy Zheng Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1359 Lines: 37 于 2017年4月18日 GMT+08:00 下午3:25:05, Tejun Heo 写到: >Hello, > >On Mon, Apr 03, 2017 at 12:48:16AM +0100, André Przywara wrote: >> So I see this problem easily now - on every boot - with an unpatched >> 4.11-rc3 kernel and the (arm64) defconfig on a Pine64 or BananaPi >M64. >> I enabled devres.log and see that pinctrl probes early, but >apparently >> gets deferred, pretty late actually (after 43 ADDs). >> >> Now what sticks out from the sequence (see the attached log) is that >> there are two un-matches ADDs with a devm_kmalloc of size 0: >> sun50i-a64-pinctrl 1c20800.pinctrl: DEVRES ADD ffff80007bd84200 >> devm_kzalloc_release (0 bytes) >> sun50i-a64-pinctrl 1c20800.pinctrl: DEVRES ADD ffff80007bd84100 >> devm_kzalloc_release (0 bytes) P.S. mysteriously the warn disappeared in newest -next, but still exist in 4.11-rc. >> >> While all the other ADDs have a matching REL, those two have not. I >> guess it's due to the size being 0. Does that ring a bell? > >AFAICS, 0 size allocs should be fine. > >> Or is due to the fact that these two ADDs are after the RELs have >> already started, so at a point where the driver is already cleaned >up? > >But this sounds problematic to me. So, these zero length allocations >are happening after release of the device is initiated? Where are >they coming from? > >Thanks.