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]
Message-ID: <475B9270.6070902@gmail.com>
Date:	Sun, 09 Dec 2007 16:00:00 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23

Hello, (cc'ing Alan)

Andrew Morton wrote:
>> Subject		: cd/dvd inaccessible in 2.6.24-rc2
>> Submitter	: Will Trives <will@...vescon.com.au>
>> References	: http://lkml.org/lkml/2007/11/9/290
>> 		  http://bugzilla.kernel.org/show_bug.cgi?id=9346
>> Handled-By	: Len Brown <lenb@...nel.org>
>> 		  Tejun Heo <htejun@...il.com>
>> Patch		: 
>>
> 
> Nasty one.  Tejun and several diligent reporters are doing sterling
> work there and things have improved.  I don't know whether any of
> Tejun's patches have been merged yet, but we'll probably be OK on
> this one.

I'm still trying to find out what's really going on.  That drive is
quite peculiar.

> What is unclear (to me) is what actually caused those people's machines to
> break?

It's introduced by setting ATAPI transfer chunk size to actual
transfer size which is the right thing to do generally.  However, with
the change, the ATAPI HSM should be ready to drain full extra transfer
chunks which libata HSM wasn't doing.  With that part changed, most
regressions should go away.

Unfortunately, simply adding that doesn't fix the case in bug 9346 and
I'm still trying to find out why.  The good news is that the drive
works fine with proposed more extensive improvements to libata ATAPI
which will probably be included into 2.6.25, so we at least have long
term solution.

If we fail to find out the solution in time, we always have the
alternative of backing out the ATAPI transfer chunk size update.  This
will break some other cases which were fixed by the change but those
won't be regressions at least and we can add transfer chunk size
update with other changes to 2.6.25.

Thanks.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ