linux-kernel - Re: regression: CD burning (k3b) went broke

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:	Thu, 28 Feb 2008 16:43:26 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Mike Galbraith <efault@....de>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-ide@...r.kernel.org,
	linux-scsi@...r.kernel.org, Jeff Garzik <jgarzik@...ox.com>
Subject: Re: regression: CD burning (k3b) went broke

Hello, all.

Sorry about the delay.  Was buried under other stuff.  Mike, thanks a
lot for reporting and analyzing the problem; however, the patch is
slightly incorrect.  rq->data_len is rq->data_len + extra stuff for
alignment and padding, so the correct thing to do is...

  req->raw_data_len -= req->data_len - scsi_get_resid(cmd);
  req->data_len = scsi_get_resid(cmd);

which is ugly and error-prone.  In addition, this isn't the only place
where resid is set.  Other block drivers do this too.  This definitely
should be done in block layer.

With rq->data_len and rq->raw_data_len, it's impossible to translate
resid of rq->data_len to resid of rq->raw_data_len as block layer
doesn't know how much was extra data after rq->data_len is modified.
The attached patch substitutes rq->raw_data_len w/ rq->extra_len and
adds blk_rq_raw_data_len().  Things look cleaner this way and the resid
problem should be solved with this.

Can you please verify the attached patch fixes the problem?

Thanks.

-- 
tejun

View attachment "patch" of type "text/plain" (4609 bytes)