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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <94408FC0-D7F8-4050-936E-F350029DAB9F@aosc.io>
Date:   Fri, 18 Aug 2017 14:23:34 +0800
From:   Icenowy Zheng <icenowy@...c.io>
To:     wens@...e.org, Chen-Yu Tsai <wens@...e.org>
CC:     Rob Herring <robh+dt@...nel.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [linux-sunxi] [PATCH 2/4] drivers: soc: sunxi: fix error processing on base address when claiming



于 2017年8月18日 GMT+08:00 下午2:21:07, Chen-Yu Tsai <wens@...e.org> 写到:
>Hi,
>
>On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy@...c.io> wrote:
>> When claiming SRAM, if the base is set to an error, it means that the
>> SRAM controller has been probed, but failed to remap the controller
>> memory zone. If the base is zero, thus the SRAM controller should be
>not
>> probed at all, and it should return -EPROBE_DEFER. However, currently
>we
>> returned -EPROBE_DEFER in the former situation, and ignored the
>latter
>> situation (which will lead to the kernel to panic).
>>
>> Fix the behavior on abnormal base address processing when claiming.
>
>Could you describe how you actually ran into this? The failure seems
>unlikely for a properly written device tree.

In fact it's possible, as the probe defering used to be broken.

On the A64 situation, the SRAM is referenced by the DE2 CCU driver, which will be probed very early -- before SRAM is probed, and the problem happens.

>
>Thanks
>ChenYu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ