linux-kernel - Re: OMAPFB: CMA allocation failures

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: <525CF09A.1080808@ti.com>
Date:	Tue, 15 Oct 2013 10:36:58 +0300
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Ивайло Димитров 
	<freemangordon@....bg>
CC:	<pali.rohar@...il.com>, <pc+n900@...f.org>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>
Subject: Re: OMAPFB: CMA allocation failures

On 15/10/13 09:49, Ивайло Димитров wrote:

> I am using my n900 as a daily/only device since the beginning of 2010, never seen such an 
> issue with video playback. And as a maintainer of one of the community supported kernels for
> n900 (kernel-power) I've never had such an issue reported. On stock kernel and derivatives of
> course. It seems VRAM allocator is virtually impossible to fail, while with CMA OMAPFB fails on
> the first video after boot-up.

Yes, I think with normal fb use it's quite difficult to fragment VRAM
allocator too much.

> When saying you've not seen such an issue - did you actually test video playback, on what
> device and using which distro? Did you use DSP accelerated decoding?

No, I don't have a rootfs with DSP, and quite rarely test video
playback. But the VRAM allocator was removed a year ago, and this is the
first time I've seen anyone have issues with the CMA.

> I was able to track down the failures to:
> http://lxr.free-electrons.com/source/mm/migrate.c#L320
> 
> So it seems the problem is not that CMA gets fragmented, rather some pages cannot be migrated.
> Unfortunately, my knowledge stops here. Someone from the mm guys should be involved in the
> issue as well? I am starting to think there is some serious issue with CMA and/or mm I am
> hitting on n900. As it is not the lack of free RAM that is the problem - 
> "echo 3>/proc/sys/vm/drop_caches" results in more that 45MB of free RAM according to free.

I think we should somehow find out what the pages are that cannot be
migrated, and where they come from.

So there are "anonymous pages without mapping" with page_count(page) !=
1. I have to say I don't know what that means =). I need to find some
time to study the mm.

> dma_declare_contiguous() won't help IMO, it just reserves CMA area that is private to the
> driver, so it is used instead of the global CMA area, but I don't see how that would help in my
> case.

If the issue is not about fragmentation, then I think you're right,
dma_declare_contiguous won't help.

> Anyway, what about reverting VRAM allocator removal and migrating it to DMA API, the same way
> DMA coherent pool is allocated and managed? Or simply revering VRAM allocator removal :) ?

Well, as I said, you're the first one to report any errors, after the
change being in use for a year. Maybe people just haven't used recent
enough kernels, and the issue is only now starting to emerge, but I
wouldn't draw any conclusions yet.

If the CMA would have big generic issues, I think we would've seen
issues earlier. So I'm guessing it's some driver or app in your setup
that's causing the issues. Maybe the driver/app is broken, or maybe that
specific behavior is not handled well by CMA. In both case I think we
need to identify what that driver/app is.

I wonder how I could try to reproduce this with a generic omap3 board...

 Tomi

Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)