Re: [PATCH] GenWQE: Fix bad page access during abort of resource allocation

From: Frank Haverkamp
Date: Wed Oct 19 2016 - 11:00:43 EST


Hi Greg,

> On 19 Oct 2016, at 13:44, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Oct 19, 2016 at 12:29:41PM +0200, Frank Haverkamp wrote:
>> From: Gerald Schaefer <gerald.schaefer@xxxxxxxxxx>
>>
>> When interrupting an application which was allocating DMAable
>> memory, it was possible, that the DMA memory was deallocated
>> twice, leading to the error symptoms below.
>>
>> Thanks to Gerald, who analyzed the problem and provided this
>> patch.
>>
>> I agree with his analysis of the problem: ddcb_cmd_fixups() ->
>> genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL
>> and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() ->
>> genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and
>> f/lpage maybe also != NULL)
>>
>> In this scenario we would have exactly the kind of double free that
>> would explain the WARNING / Bad page state, and as expected it is
>> caused by broken error handling (cleanup).
>>
>> Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce
>> the "Bad page state" issue, and with the patch on top he could not reproduce
>> it any more.
>>
>> ------------[ cut here ]------------
>> WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141
>> Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod
>> CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu
>> task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000
>> Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8)
>> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
>> Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400
>> 0000000000000400 0000000000001fff 0000000000000400 0000000116853000
>> 07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001
>> 0000000000001000 0000000116854000 0000000000156402 00000000324e7a38
>> Krnl Code: 000000000015633a: 95001000 cli 0(%r1),0
>> 000000000015633e: a774ffc3 brc 7,1562c4
>> #0000000000156342: a7f40001 brc 15,156344
>>> 0000000000156346: 92011000 mvi 0(%r1),1
>> 000000000015634a: a7f4ffbd brc 15,1562c4
>> 000000000015634e: 0707 bcr 0,%r7
>> 0000000000156350: c00400000000 brcl 0,156350
>> 0000000000156356: eb7ff0500024 stmg %r7,%r15,80(%r15)
>> Call Trace:
>> ([<00000000001563e0>] dma_update_trans+0x90/0x228)
>> [<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160
>> [<00000000001567c2>] s390_dma_free+0x62/0x98
>> [<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card]
>> [<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card]
>> [<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card]
>> [<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card]
>> [<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card]
>> [<000000000032513a>] do_vfs_ioctl+0x3b2/0x518
>> [<0000000000325344>] SyS_ioctl+0xa4/0xb8
>> [<00000000007b86c6>] system_call+0xd6/0x264
>> [<000003ff9e8e520a>] 0x3ff9e8e520a
>> Last Breaking-Event-Address:
>> [<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8
>> ---[ end trace 35996336235145c8 ]---
>> BUG: Bad page state in process jbd2/dasdb1-8 pfn:3215b
>> page:000003d100c856c0 count:-1 mapcount:0 mapping: (null) index:0x0
>> flags: 0x3fffc0000000000()
>> page dumped because: nonzero _count
>>

Cc: <stable@xxxxxxxxxxxxxxx> # 4.x+

>> Signed-off-by: Gerald Schaefer <gerald.schaefer@xxxxxxxxxx>
>> Signed-off-by: Frank Haverkamp <haver@xxxxxxxxxxxxxxxxxx>
>
> As you say this goes back to at least 4.4, shouldn't we mark it for
> stable releases? And if so, any idea how far back it goes?
>
I think I introduced the problem with the fix for our multithreading problems:
718f762efc454796d02f172a929d051f2d6ec01a GenWQE: Fix multithreading problems

That was 30.3.2014. kernel 3.15, I think. Putting it in stable is a good idea, thanks for
pointing this out. I think 4.x+ is ok for me.

Do I need to resend the patch with the Cc: line, or will you route the change to the appropriate
places?

> thanks,
>
> greg k-h

Thanks

Frank