linux-kernel - Re: kernel BUG at lib/radix-tree.c:473!

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: <871w0r5gw8.fsf@skyscraper.fehenstaub.lan>
Date:	Fri, 15 Aug 2008 01:13:59 +0200
From:	Johannes Weiner <hannes@...urebad.de>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Hugh Dickins <hugh@...itas.com>, Ian Campbell <ijc@...lion.org.uk>,
	linux-kernel@...r.kernel.org, Kel Modderman <kel@...ku42.de>,
	Markus Armbruster <armbru@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: kernel BUG at lib/radix-tree.c:473!

Hi,

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> Hugh Dickins wrote:
>> As you can see, I'm still groping towards the right answer.
>> The driver probably needs to provide its own backing_dev_info
>> (or point to a suitable default), and its own address_space_ops,
>> and perhaps more (there should be examples elsewhere).  But whether
>> it is actually wrong, or whether I was wrong to mess it up, I've
>> not yet decided.
>>   
>
> My understanding is that the driver is doing something a bit clever:
> it uses the page dirty flags to determine which parts of the
> framebuffer have been written to, and uses that information to
> minimize the amount of stuff that needs to be copied out.  The writes
> to the pages are not expected to generate actual page faults.
>
> But I haven't really looked at it closely, and I'm not at all familiar
> with the vm at this layer.  I'm not sure how it actually allocates the
> framebuffer memory for example (vmalloc?  incrementally on faults?).
> I'm hoping Markus will leap in, since wrote this stuff.  Or, gasp,
> I'll read the code myself.
>
>> An additional useful input would be: what happens if you replace
>> that /dev/fb0 by a symlink /dev/fb0 pointing to an fb0 device node in
>> one of your disk filesystems?  I rather expect that to cause the same
>> trouble, which would argue that the driver is wrong and shmem right.
>>   
>
> I don't follow. Do you mean make /dev/fb0 a plain file on a
> filesystem?  Or make it a disk device node?  Something else?

Creating a device node on a different filesystem to see if the driver
only worked with the safe shmem set_page_dirty and now breaks due to
exposure to the generic version.  Or if the driver works with the
generic version through other mappings and the shmem code screws it up
somewhere else.

	Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/