From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756272AbdDRKwI convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        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 <rfc822;linux-kernel@vger.kernel.org>);
        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 <tj@kernel.org>,
        =?ISO-8859-1?Q?Andr=E9_Przywara?= <andre.przywara@arm.com>
CC: Icenowy Zheng <icenowy@aosc.xyz>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Adam Borowski <kilobyte@angband.pl>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
From: Icenowy Zheng <icenowy@aosc.io>
Message-ID: <FDCD703C-E0E8-4776-B0AA-CFF05565AE41@aosc.io>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



于 2017年4月18日 GMT+08:00 下午3:25:05, Tejun Heo <tj@kernel.org> 写到:
>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.