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] [day] [month] [year] [list]
Message-ID: <20170501192202.GE8921@htj.duckdns.org>
Date:   Mon, 1 May 2017 15:22:02 -0400
From:   Tejun Heo <tj@...nel.org>
To:     André Przywara <andre.przywara@....com>
Cc:     Adam Borowski <kilobyte@...band.pl>,
        Icenowy Zheng <icenowy@...c.xyz>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349

Hello,

On Sun, Apr 30, 2017 at 12:34:40AM +0100, André Przywara wrote:
> >> If this is a valid use case, we can change devm to repeat till empty
> >> but it's a weird thing to do to allocate from a release function.
> >>
> >> So, something like this.  Only compile tested.
> 
> I was wondering if using devm_*alloc in a _release_ function is valid at
> all, given that it is called as part of the DEFER clean-up routine.
> Looking at pinmux_generic_free_functions() it looks like we could
> replace it with a (non-devm_) kmalloc version and it would still work
> (given we add a kfree at the end).
> Either that or we bail out early if pctldev->num_functions is zero.

I was just throwing the idea but the more I think about it, the less
sense it makes to me.  So, I really think this should be fixed by
dropping dev_kzalloc() call from the release function.  It makes no
sense.

Thanks.

-- 
tejun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ