linux-kernel - Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm

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: <Pine.GSO.4.64.1304020809300.5951@umail>
Date:	Tue, 2 Apr 2013 08:31:18 -0500 (CDT)
From:	Ilija Hadzic <ihadzic@...earch.bell-labs.com>
To:	Marco Munderloh <munderl@....uni-hannover.de>
cc:	Ilija Hadzic <ilijahadzic@...il.com>,
	Michal Hocko <mhocko@...e.cz>,
	Thomas Hellstrom <thellstrom@...are.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] drm: fix i_mapping and f_mapping initialization in
 drm_open in error path


Marco,

What makes you think that the crash after second modprobe is related to 
the mappings pointers in DRM module? Can you actually establish the 
correlation between these patches and the crash or you are just suspecting 
because your other bug had something to do with module removal/insertion?

If it's the latter, then you may want to open another bug report here 
https://bugs.freedesktop.org/ (use DRI for product and pick DRM/radeon for 
component) and have this issue tracked and addressed separately.

The divide error that your log shows apparently happens at this line
inside r6xx_remap_render_backend:

pipe_rb_ratio = rendering_pipe_num / req_rb_num;

I would suspect that req_rb_num somehow evaluates to zero at the second 
modprobe. That variable seems to be the derived of the last three 
arguments to r6xx_remap_render_backend. If I look at the caller 
(evergreen_gpu_init) the arguments that have the play here are all derived 
from the GPU's hardware registers (or are the constant for a given GPU 
device). So I suspect that the GPU driver leaves some state in GPU at 
module removal that later bites you.

-- Ilija

On Tue, 2 Apr 2013, Marco Munderloh wrote:

> Hi Ilija,
>
>> Thanks for testing. Other issues are probably unrelated, so I'll send the 
>> last version of the patch to Dave.
>
> I came across another problem which seems related. rmmod radeon works, 
> however, modprobe radeon afterwards results in a crash (divide error), see 
> attachment.
>
> Best, Marco
>
> On 02.04.2013 13:23, Ilija Hadzic wrote:
>> 
>> -- Ilija
>> 
>> On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh 
>> <munderl@....uni-hannover.de <mailto:munderl@....uni-hannover.de>> wrote:
>>
>>         Attached is a v2 of the patch, for reference. I would appreciate if 
>> the original reporter or you tested it in lieu of your proposed patch and 
>> let me know if it
>>         fixes your
>>         issue.
>> 
>>
>>     The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as 
>> rmmod radeon do not end up in a crash anymore. However, I have still no 
>> clue why one of these makes
>>     drm_open to fail. On rmmod radeon I get the following log messages. If 
>> don't know if the 'unpin not necessary' has anything to do with it.
>>
>>     [drm] radeon: finishing device.
>>     radeon 0000:01:00.0: ffff88024e526c00 unpin not necessary
>>     radeon 0000:01:00.0: ffff88024f2f6000 unpin not necessary
>>     radeon 0000:01:00.0: ffff88024f2f6000 unpin not necessary
>>     [TTM] Finalizing pool allocator
>>     [TTM] Finalizing DMA pool allocator
>>     [TTM] Zone  kernel: Used memory at exit: 0 kiB
>>     [TTM] Zone   dma32: Used memory at exit: 0 kiB
>>     [drm] radeon: ttm finalized
>>     vga_switcheroo: disabled
>>     [drm] Module unloaded
>>
>>     By the way, sometimes my r8169 ethernet controller does not survive 
>> suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't 
>> know if this is related.
>> 
>> 
>
> -- 
> Dipl.-Ing. Marco Munderloh             Mail: munderl@....uni-hannover.de
> Institut für Informationsverarbeitung (TNT)     Phone: +49 511 762-19587
> Leibniz Universitaet Hannover, Appelstr. 9a       Fax: +49 511 762- 5333
> 30167 Hannover, Germany     Web: http://www.tnt.uni-hannover.de/~munderl
>