| 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
| ||
|
Date: Wed, 8 Jul 2015 08:45:45 +0000
From: Alexey Brodkin <Alexey.Brodkin@...opsys.com>
To: "jh80.chung@...sung.com" <jh80.chung@...sung.com>
CC: "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"tgih.jun@...sung.com" <tgih.jun@...sung.com>,
"arc-linux-dev@...opsys.com" <arc-linux-dev@...opsys.com>
Subject: Re: [PATCH] mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is
used
Hi Jaehoon,
On Wed, 2015-07-08 at 13:14 +0900, Jaehoon Chung wrote:
> Hi, Alexey.
>
> On 06/25/2015 05:25 PM, Alexey Brodkin wrote:
> > As per DW MobileStorage databook "each descriptor can transfer up to 4kB
> > of data in chained mode", moreover buffer size that is put in "des1" is
> > limited to 13 bits, i.e. for example on attempt to
> > IDMAC_SET_BUFFER1_SIZE(desc, 8192) size value that's effectively written
> > will be 0.
> >
> > On the platform with 8kB PAGE_SIZE I see dw_mmc gets data blocks in
> > SG-list of 8kB size and that leads to unpredictable behavior of the
> > SD/MMC controller.
>
> I didn't see your problem, since i didn't test with 8K PAGE_SIZE.
> But I think your patch is reasonable.
> As possible, I want to know in more detail what unpredictable behavior.
> (Just stuck behavior?)
Please find below my observations from before the fix.
I noticed that some simple operations (especially reads of large files from FAT partitions)
lead to dw_mmc being unresponsive, see below and example:
---------------------------------->8------------------------------
$ mkdir /sd1
$ mount /dev/mmcblk0p1 /sd1
FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ARCLinux]$ ls -lah /sd1
total 7252
drwxr-xr-x 8 root root 16.0K Dec 31 16:00 .
drwxrwxrwt 16 root root 380 Dec 31 16:03 ..
-rwxr-xr-x 1 root root 241 Dec 18 2014 boot.scr
-rwxr-xr-x 1 root root 44.3K Dec 18 2014 script.bin
-rwxr-xr-x 1 root root 7.0M Jan 13 2015 uImage
[ARCLinux]$ md5sum /sd1/uImage
---------------------------------->8------------------------------
At this point nothing was happening for a long time, so I pressed Ctrl-C and
run another "ls" that worked perfectly fine on the previous step (see above).
But that time "ls" didn't work, instead I saw:
---------------------------------->8------------------------------
$ mkdir /sd2
$ mount /dev/mmcblk0p2 /sd2
$ ls -lah /sd2
INFO: task ls:104 blocked for more than 10 seconds.
Not tainted 3.18.10-01062-g89ecf3c-dirty #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls D 8020e79c 0 104 84 0x00000004
Stack Trace:
__switch_to+0x0/0x98
__schedule+0x1d0/0x494
io_schedule+0x42/0x6c
bit_wait_io+0x1e/0x40
__wait_on_bit+0x86/0xac
out_of_line_wait_on_bit+0x48/0x58
ext4_bread+0x68/0x7c
__ext4_read_dirblock+0x32/0x320
htree_dirblock_to_tree+0x4a/0x174
ext4_htree_fill_tree+0x76/0x1e0
ext4_readdir+0x5e6/0x86c
iterate_dir+0x80/0xf4
SyS_getdents64+0x64/0xd4
ret_from_system_call+0x0/0x4
INFO: task ls:104 blocked for more than 10 seconds.
Not tainted 3.18.10-01062-g89ecf3c-dirty #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls D 8020e79c 0 104 84 0x00000004
Stack Trace:
__switch_to+0x0/0x98
__schedule+0x1d0/0x494
io_schedule+0x42/0x6c
bit_wait_io+0x1e/0x40
__wait_on_bit+0x86/0xac
out_of_line_wait_on_bit+0x48/0x58
ext4_bread+0x68/0x7c
__ext4_read_dirblock+0x32/0x320
htree_dirblock_to_tree+0x4a/0x174
ext4_htree_fill_tree+0x76/0x1e0
ext4_readdir+0x5e6/0x86c
iterate_dir+0x80/0xf4
SyS_getdents64+0x64/0xd4
ret_from_system_call+0x0/0x4
INFO: task ls:104 blocked for more than 10 seconds.
Not tainted 3.18.10-01062-g89ecf3c-dirty #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls D 8020e79c 0 104 84 0x00000004
Stack Trace:
__switch_to+0x0/0x98
__schedule+0x1d0/0x494
io_schedule+0x42/0x6c
bit_wait_io+0x1e/0x40
__wait_on_bit+0x86/0xac
out_of_line_wait_on_bit+0x48/0x58
ext4_bread+0x68/0x7c
__ext4_read_dirblock+0x32/0x320
htree_dirblock_to_tree+0x4a/0x174
ext4_htree_fill_tree+0x76/0x1e0
ext4_readdir+0x5e6/0x86c
iterate_dir+0x80/0xf4
SyS_getdents64+0x64/0xd4
ret_from_system_call+0x0/0x4
INFO: task ls:104 blocked for more than 10 seconds.
Not tainted 3.18.10-01062-g89ecf3c-dirty #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls D 8020e79c 0 104 84 0x00000004
Stack Trace:
__switch_to+0x0/0x98
__schedule+0x1d0/0x494
io_schedule+0x42/0x6c
bit_wait_io+0x1e/0x40
__wait_on_bit+0x86/0xac
out_of_line_wait_on_bit+0x48/0x58
ext4_bread+0x68/0x7c
__ext4_read_dirblock+0x32/0x320
htree_dirblock_to_tree+0x4a/0x174
ext4_htree_fill_tree+0x76/0x1e0
ext4_readdir+0x5e6/0x86c
iterate_dir+0x80/0xf4
SyS_getdents64+0x64/0xd4
ret_from_system_call+0x0/0x4
---------------------------------->8------------------------------
Seeing that problem I started to check what data is being sent to MMC controller
and pretty quickly found-out that sometimes value 8192 is written in the first
13 bits of DES1 that in case of IDMAC_SET_BUFFER1_SIZE macro usage effectively
writes 0. That was a clean misuse of MMC controller (it gets buffer descriptor
that points to zero-sized buffer). Once I fixed that flaw my initial problem
went away.
Let me know if that description makes sense to you.
-Alexey--
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/
Powered by blists - more mailing lists