linux-kernel - Re: 2.6.29 pat issue

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: <1233856988.4286.83.camel@localhost.localdomain>
Date:	Thu, 05 Feb 2009 10:03:08 -0800
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	Thomas Hellström <thellstrom@...are.com>
Cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
Subject: Re: 2.6.29 pat issue

On Thu, 2009-02-05 at 04:47 -0800, Thomas Hellström wrote:
> Hi!
> 
> The function in include/linux/mm.h:
> is_linear_pfn_mapping()
> 
> doesn't seem valid to me.
> 
> In particular, we have VMAs to graphics devices in which vma->vm_pgoff
> is non-zero (Points to an offset in the drm device node), and the VMA is
> sparsely populated with pfns pointing to uncached discontigous RAM pages.
> 
> This causes the X86 PAT code to hit the optimized path when it
> shouldn't, and issue a warning.

Only place where vm_pgoff is getting set for a PFNMAP vma is in
remap_pfn_range() which maps the entire range. vm_insert_pfn() which may
have sparsely populated ranges does not set vm_pgoff. What interface are
you using to map discontig pages, where you are seeing these errors?

> Also a question about the philosofy behind this strict checking that all
> PTEs have the same caching attributes: I guess this is only to catch
> bugs in kernel drivers that don't get this right. At the same time, now
> that also user-space VMAs are checked this will probably have a
> significant performance impact. Shouldn't this checking really live
> behind a debug define?

The result of not having the caching attribute right can be really bad
as to hang/crash the system. So, having this only in debug is not the
enough, IM0. Kernel has to enforce UC and WC caching types are
consistent at all times. And we also have to keep the indentity map and
other mappings that may be present for that address consistent.

Thanks,
Venki


--
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/