linux-kernel - Re: [BUG sparc64] 2.6.16-git6 broke X11 on Ultra5 with ATI Mach64

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-next>] [day] [month] [year] [list]

Message-Id: <20060727.181356.71087770.davem@davemloft.net>
Date:	Thu, 27 Jul 2006 18:13:56 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mikpe@...uu.se
Cc:	linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [BUG sparc64] 2.6.16-git6 broke X11 on Ultra5 with ATI Mach64

From: David Miller <davem@...emloft.net>
Date: Fri, 07 Jul 2006 00:05:24 -0700 (PDT)

> I'll have to figure out how the writeable bits get lost
> in the call chain.

Actually, I digged further, things seem correct.

Initially we only set the SW-writable bit, and this is the right thing
to do for a MAP_SHARED writable mapping.

If the process actually tries to write to the mapping, the page fault
path will set the two bits that actually enable writes, namely the
HW-writable bit and the SW-dirty bit.

This occurs when pte_mkdirty() is called on the PTE during the
execution of mm/memory.c:handle_pte_fault(), right here:

	if (write_access) {
		if (!pte_write(entry))
			return do_wp_page(mm, vma, address,
					pte, pmd, ptl, entry);
		entry = pte_mkdirty(entry);
	}

pte_write() will return true, since the SW-writable bit is set.  So we
don't should not invoke do_wp_page(), and we'll just set the dirty bit
on the existing PTE.

For some reason that isn't happening properly, or something keeps
clearing the HW-writable bit on us.  Another possibility is that
one of these operations sets the cacheable bits, or clears the
side-effect bit, either of which would cause corruption or other
problems when accessing the ATI card through such a mapping.

I wonder why.... I'll try to run some experiments on my system to try
and get to the bottom of this.
-
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/