linux-kernel - Re: [PATCH] ata: sata_mv: fix sg_tbl

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: <50F73351.3050708@web.de>
Date:	Thu, 17 Jan 2013 00:10:09 +0100
From:	Soeren Moch <smoch@....de>
To:	Jason Cooper <jason@...edaemon.net>
CC:	Greg KH <gregkh@...uxfoundation.org>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Andrew Lunn <andrew@...n.ch>, Arnd Bergmann <arnd@...db.de>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...e.cz>,
	linux-mm@...ck.org, Kyungmin Park <kyungmin.park@...sung.com>,
	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	linaro-mm-sig@...ts.linaro.org,
	linux-arm-kernel@...ts.infradead.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH] ata: sata_mv: fix sg_tbl_pool alignment

On 16.01.2013 18:52, Jason Cooper wrote:
> On Wed, Jan 16, 2013 at 06:05:59PM +0100, Soeren Moch wrote:
>> On 16.01.2013 16:50, Jason Cooper wrote:
>>> On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
>>>> On 16.01.2013 04:24, Soeren Moch wrote:
>>>>> On 16.01.2013 03:40, Jason Cooper wrote:
>>>>>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>>>>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>>>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>
>>>> OK, I could trigger the error
>>>>    ERROR: 1024 KiB atomic DMA coherent pool is too small!
>>>>    Please increase it with coherent_pool= kernel parameter!
>>>> only with em28xx sticks and sata, dib0700 sticks removed.
>>>
>>> Did you test the reverse scenario?  ie dib0700 with sata_mv and no
>>> em28xx.
>>
>> Maybe I can test this next night.
>
> Please do, this will tell us if it is in the USB drivers or lower
> (something in common).
>
>>>>>> What would be most helpful is if you could do a git bisect between
>>>>>> v3.5.x (working) and the oldest version where you know it started
>>>>>> failing (v3.7.1 or earlier if you know it).
>>>>>>
>>>>> I did not bisect it, but Marek mentioned earlier that commit
>>>>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>>>>> new code for dma allocations. This is probably the root cause for the
>>>>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>>>>
>>>> I don't want to say that Mareks patch is wrong, probably it triggers a
>>>> bug somewhere else! (in em28xx?)
>>>
>>> Of the four drivers you listed, none are using dma.  sata_mv is the only
>>> one.
>>
>> usb_core is doing the actual DMA for the usb bridge drivers, I think.
>
> Yes, my mistake.  I'd like to attribute that statement to pre-coffee
> rambling. :-)
>
>>> If one is to believe the comments in sata_mv.c:~151, then the alignment
>>> is wrong for the sg_tbl_pool.
>>>
>>> Could you please try the following patch?
>>
>> OK, what should I test first, the setup from last night (em28xx, no
>> dib0700) plus your patch, or the reverse setup (dib0700, no em28xx)
>> without your patch, or my normal setting (all dvb sticks) plus your
>> patch?
>
> if testing time is limited, please do the test I outlined at the top of
> this email.  I've been digging more into the dma code and while I think
> the patch is correct, I don't see where it would fix your problem (yet).

Unfortunately test time is limited, and the test has to run about
10 hours to trigger the error.

I also think that sata is not causing the problem.
Maybe your patch even goes in the wrong direction. Perhaps the dma
memory pool is not too small, there might be enough memory available,
but it is too much fragmented to satisfy larger block allocations. With 
different drivers allocating totally different block sizes aligned to
bytes or words, perhaps we end up with lots of very small free blocks
in the dma pool after several hours of runtime?
So maybe it would help to align all allocations in the dma pool to 256B?

Regards,
Soeren

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