linux-kernel - Re: shmem + TTM oops

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: <Pine.LNX.4.64.0908062045270.944@sister.anvils>
Date:	Thu, 6 Aug 2009 21:03:03 +0100 (BST)
From:	Hugh Dickins <hugh.dickins@...cali.co.uk>
To:	Thomas Hellström <thomas@...gstengraphics.com>
cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Linux Memory Management <linux-mm@...ck.org>
Subject: Re: shmem + TTM  oops

On Thu, 6 Aug 2009, Thomas Hellström wrote:
> Hi!
> I've been debugging a strange problem for a while, and it'd be nice to have
> some more eyes on this.
> 
> When the TTM graphics memory manager decides it's using too much memory, it
> copies the contents of the buffer to shmem objects and releases the buffers.
> This is because shmem objects are pageable whereas TTM buffers are not. When
> the TTM buffers are accessed in one way or another, it copies contents back.
> Seems to work fairly nice, but not really optimal.
> 
> When the X server is VT switched, TTM optionally switches out all buffers to
> shmem objects, but when the contents are read back, some shmem objects have
> corrupted swap entry top directory. The member
> shmem_inode_info::i_indirect[0] usually contains a value 0xffffff60 or
> something similar, causing an oops in shmem_truncate_range() when the shmem
> object is freed. Before that, readback seems to work OK. The corruption is
> happening after X server VT switch when TTM is supposed to be idle. The shmem
> objects have been verified to have swap entry directories after all buffer
> objects have been swapped out.

Not a symptom I've ever come across: I agree strange.  A few questions:

What architecture? I assume x86 32-bit; if so, what happens on 64-bit?
if not x86, what is your PAGE_SIZE?

What size are these objects i.e. how many pages?

What release? I'm assuming 2.6.31-rc5 and various earlier.

What slab allocator? what if you choose another (SLUB versus SLAB)?
Please turn on all the slab/slub debugging you can.

And you say i_indirect "usually contains a value 0xffffff60 or something
similar": please give other examples of what you find there (if possible,
with a rough idea of their frequency e.g. is 0xffffff60 the most common?).

Does there appear to be corruption of any other nearby fields?

Thanks.

> 
> If anyone could shed some light over this, it would be very helpful. Relevant
> TTM code is fairly straightforward looks like this. The process that copies
> out to shmem objects may not be the same process that copies in:

I didn't notice anything wrong with your code; and it wouldn't
be easy for it to corrupt that field of shmem_inode_info.

Hugh