linux-kernel - Re: sun50i-a64-pinctrl WARN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <FDCD703C-E0E8-4776-B0AA-CFF05565AE41@aosc.io>
Date:   Tue, 18 Apr 2017 18:51:43 +0800
From:   Icenowy Zheng <icenowy@...c.io>
To:     Tejun Heo <tj@...nel.org>,
        André Przywara <andre.przywara@....com>
CC:     Icenowy Zheng <icenowy@...c.xyz>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Adam Borowski <kilobyte@...band.pl>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349



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