linux-kernel - Re: New boot time message: detected capacity change

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]

Date:	Thu, 19 May 2011 09:25:32 +0200
From:	Jens Axboe <jaxboe@...ionio.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Tony Luck <tony.luck@...il.com>, Tejun Heo <tj@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: New boot time message: detected capacity change

On 2011-05-18 22:50, Linus Torvalds wrote:
> On Wed, May 18, 2011 at 1:32 PM, Tony Luck <tony.luck@...il.com> wrote:
>> Today's pull from Linus' tree (HEAD = 258-ga2b9c1f) gave me some new
>> messages during boot:
>>
>> sda: detected capacity change from 0 to 146815737856
>> sdb: detected capacity change from 0 to 146815737856
>>
>> They weren't there yesterday (HEAD = 211-gc1d10d1) ... nor do they
>> show up in any of my saved boot time dmesg files for the last few
>> months.
>>
>> Harmless?  Or something to worry about in the last few commits
>> before 2.6.39 goes final?
> 
> I htink it's 02e352287a40 ("block: rescan partitions on invalidated
> devices on -ENOMEDIA too"), which was reported to fix a bugzilla
> entry.
> 
> However, now that I look closer, that bugzilla entry was two years old
> and reported for 2.6.29.
> 
> So it wasn't a regression fix like the changelog made me think (with a
> stable pointer for 38)
> 
> Jens, Tejun - stop this messing around! The block layer has been one
> of the problem children in the last releases, the *LAST* thing we need
> is things like this happening this late in the -rc series!

This release has not been great, mostly early in the cycle. I will take
complete blame for pushing this change so late, that's why I asked Tejun
about the three patches queues up yesterday. We've had more churn in
this cycle due to both the plugging and media event notification
changes, both have caused way more commits and later in the cycle that
I'm usually comfortable with. I do _always_ try to push the big stuff
before -rc1, so I don't think it's completely fair to quote earlier
releases as problematic.

> Seriously. I'm really upset. I need to be able to trust you, and you
> are not being trust-worthy. F*&^ you, in other words. This was *NOT* a
> regression.
> 
> I don't care if it fixes a long-standing bug, you do not send fixes
> like that to me. It should have gone into the merge window for 40, and
> at *that* point it might be marked for stable.
> 
> As it was, I feel that those commit descriptions were actively
> misleading me into thinking this was a regression.
> 
> Maybe it won't cause any problems, but -rc7 is not the time to make
> these kinds of experiments!

I agree. And not that it's an excuse, but it has been well tested here
on my test and primary machines. Arguably this particular patch should
just have waited for 2.6.40 and with a stable backport instead.

Will not happen again.

-- 
Jens Axboe

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