linux-ext4 - Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD

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]

Date:	Fri, 08 Mar 2013 10:18:14 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Lukáš Czerner <lczerner@...hat.com>
CC:	Theodore Ts'o <tytso@....edu>, Chris Ball <cjb@...top.org>,
	linux-ext4@...r.kernel.org, Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD

On 03/08/2013 12:23 AM, Lukáš Czerner wrote:
> On Thu, 7 Mar 2013, Stephen Warren wrote:
> 
>> Date: Thu, 07 Mar 2013 12:47:09 -0700
>> From: Stephen Warren <swarren@...dotorg.org>
>> To: Lukáš Czerner <lczerner@...hat.com>
>> Cc: Theodore Ts'o <tytso@....edu>, Chris Ball <cjb@...top.org>,
>>     linux-ext4@...r.kernel.org, Stephen Warren <swarren@...dia.com>
>> Subject: Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD
>>
>> On 03/06/2013 12:13 AM, Lukáš Czerner wrote:
>>> On Tue, 5 Mar 2013, Stephen Warren wrote:
>>>
>>>> Date: Tue,  5 Mar 2013 13:25:18 -0700
>>>> From: Stephen Warren <swarren@...dotorg.org>
>>>> To: Theodore Ts'o <tytso@....edu>
>>>> Cc: Chris Ball <cjb@...top.org>, linux-ext4@...r.kernel.org,
>>>>     Stephen Warren <swarren@...dia.com>
>>>> Subject: [PATCH] mke2fs: restore verbose message for BLKDISCARD
>>>>
>>>> From: Stephen Warren <swarren@...dia.com>
>>>>
>>>> mke2fs on a large slow eMMC device may appear to hang while executing
>>>> ioctl(BLKDISCARD). CTRL-C and CTRL-\ don't appear to respond, or respond
>>>> extremely slowly. -v doesn't give any hints what's happening. Only strace
>>>> is a clue. Make -v print some clues to make it easier to track down the
>>>> apparent hang.
>>>>
>>>> This change re-uses the original messages that were implemented as part
>>>> of 5827d24 "mke2fs support for BLKDISCARD" in order to easily re-use the
>>>> translations of that message. Note that this patch prints the first
>>>> message before executing the IOCTL, so the user is told what's going on
>>>> before the long wait.
>>>>
>>>> Signed-off-by: Stephen Warren <swarren@...dia.com>
>>>
>>> Note that you've added the message only around the first 4k discard
>>> which is only used to test whether the device actually support the
>>> discard... which is not very useful and it can not even know whether
>>> the whole device discard will succeed/fail so it is misleading.
>>
>> Oops. I certainly should looked at the code better.
>>
>>> Moreover there actually is a message saying that we're "Discarding
>>> device blocks" and it even shows the progress. The step in which
>>> we're doing the discard (and update the progress) is given by
>>> DISCARD_STEP_MB = 2048MB. And all that in non verbose mode as well.
>>
>> That said, it's that very first call to io_channel_discard() that is
>> hanging then; I don't see the existing message at all. With my change, I
>> do see the new message that I added. (So, no stdio flushing issue here).
> 
> It's just one fs block discard, are you sure about that ?

Yes:

root@...alhost:~# strace -e ioctl ./e2fsprogs/misc/mke2fs -v /dev/mmcblk1p1
mke2fs 1.43-WIP (21-Jan-2013)
ioctl(3, BLKGETSIZE64, 0xbe940110)      = 0
fs_types for mke2fs.conf resolution: 'ext2'
ioctl(3, BLKSSZGET, 0xbe940360)         = 0
ioctl(3, BLKPBSZGET, 0xbe940364)        = 0
ioctl(3, BLKDISCARDZEROES, 0xbe940324)  = 0
ioctl(3, BLKROGET, 0xbe940324)          = 0
Calling BLKDISCARD from 0 to 4096 ioctl(3, BLKDISCARD

>> I will go investigate why this API is hanging. Sorry for the noise.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html