linux-kernel - Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51FA8B16.20507@fastmail.fm>
Date:	Thu, 01 Aug 2013 18:21:42 +0200
From:	Bernd Schubert <bernd.schubert@...tmail.fm>
To:	Nix <nix@...eri.org.uk>
CC:	Douglas Gilbert <dgilbert@...erlog.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	nick.cheng@...ca.com.tw, stable@...r.kernel.org
Subject: Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup
 / early userspace transition

On 08/01/2013 06:04 PM, Nix wrote:
> On 1 Aug 2013, Bernd Schubert verbalised:
>
>> On 07/30/2013 11:20 PM, Nix wrote:
>>> On 30 Jul 2013, Bernd Schubert told this:
>>>
>>>> On 07/30/2013 02:56 AM, Nix wrote:
>>>>> On 30 Jul 2013, Douglas Gilbert outgrape:
>>>>>
>>>>>> Please supply the information that Martin Petersen asked
>>>>>> for.
>>>>>
>>>>> Did it in private IRC (the advantage of working for the same division of
>>>>> the same company!)
>>>>>
>>>>> I didn't realise the original fix was actually implemented to allow
>>>>> Bernd, with a different Areca controller, to boot... obviously, in that
>>>>> situation, reversion is wrong, since that would just replace one won't-
>>>>> boot situation with another.
>>>>
>>>> Unless there is very simple fix the commit should reverted, imho. It
>>>> would better then to remove write-same support from the md-layer.
>>>
>>> I'm not using md on that machine, just LVM. Our suspicion is that ext4
>>> is doing a WRITE SAME for some reason.
>>
>> I didn't check yet for other cases, mkfs.ext4 does WRITE SAME and with
>> lazy init it also will happen after mounting the file system, while
>> lazy init is running (inode zeroing).
>
> Well, it'll happen the first few times you mount the fs. If your fs is
> years old (as mine are) the inode tables will probably have been
> initialized by now!
>

I'm frequently doing tests with millions of files and reformating is 
ways faster than deleting the all these files.
--
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/