lkml.org 
[lkml]   [2008]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectWritable packet CD-RW mounting broken in 2.6.26 by your commit 68154e90c9d1492d570671ae181d9a8f8530da55
From
Date
On 8 Aug 2008, Alexey Dobriyan told this:

> On Fri, Aug 08, 2008 at 07:14:37AM +0400, Alexey Dobriyan wrote:
>> On Wed, Aug 06, 2008 at 08:12:49PM +0100, Nix wrote:
>> > It seems to be impossible to mount packet-written CD-RWs writably in
>> > 2.6.26.x, even as root. Things worked in 2.6.25.x.

Bisected. The bug starts here:

commit 68154e90c9d1492d570671ae181d9a8f8530da55
Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Fri Apr 25 12:47:50 2008 +0200

block: add dma alignment and padding support to blk_rq_map_kern

This patch adds bio_copy_kern similar to
bio_copy_user. blk_rq_map_kern uses bio_copy_kern instead of
bio_map_kern if necessary.

bio_copy_kern uses temporary pages and the bi_end_io callback frees
these pages. bio_copy_kern saves the original kernel buffer at
bio->bi_private it doesn't use something like struct bio_map_data to
store the information about the caller.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

With this patch from Alexey applied for diagnostics:

--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -1934,6 +1934,7 @@ static int pkt_writable_track(struct pktcdvd_device *pd, track_information *ti)
*/
static int pkt_writable_disc(struct pktcdvd_device *pd, disc_information *di)
{
+ printk("%s: pd = %p, ->mmc3_profile = %u\n", __func__, pd, pd->mmc3_profile);
switch (pd->mmc3_profile) {
case 0x0a: /* CD-RW */
case 0xffff: /* MMC3 not supported */
@@ -1986,7 +1987,16 @@ static noinline_for_stack int pkt_probe_settings(struct pktcdvd_device *pd)
cgc.cmd[0] = GPCMD_GET_CONFIGURATION;
cgc.cmd[8] = 8;
ret = pkt_generic_packet(pd, &cgc);
+ {
+ int i;
+
+ printk("%s:", __func__);
+ for (i = 0; i < 12; i++)
+ printk(" %02x", buf[i]);
+ printk("\n");
+ }
pd->mmc3_profile = ret ? 0xffff : buf[6] << 8 | buf[7];
+ printk("%s: pd = %p, ->mmc3_profile = %u\n", __func__, pd, pd->mmc3_profile);

memset(&di, 0, sizeof(disc_information));
memset(&ti, 0, sizeof(track_information));
We see output upon packet-written CD-RW mount going from the expected:

Aug 23 22:15:24 hades warning: kernel: pkt_probe_settings: 00 00 00 ac 00 00 00 0a 00 00 00 00
Aug 23 22:15:24 hades warning: kernel: pkt_probe_settings: pd = efce7ec0, ->mmc3_profile = 10
Aug 23 22:15:24 hades warning: kernel: pkt_writable_disc: pd = efce7ec0, ->mmc3_profile = 10

(i.e. `this is a CD-RW'), to the incorrect-by-one-byte

Aug 23 22:06:41 hades warning: kernel: pkt_probe_settings: 00 00 00 ac 00 00 00 00 00 00 00 00
^^
Aug 23 22:06:41 hades warning: kernel: pkt_probe_settings: pd = efc97dc0, ->mmc3_profile = 0
Aug 23 22:06:41 hades warning: kernel: pkt_writable_disc: pd = efc97dc0, ->mmc3_profile = 0

i.e., not a CD-RW, writable mounts impossible.

So something in this patch seems to be corrupting the results of at
least some ATAPI sg requests going to or from the block layer: and
indeed blk_rq_map_kern(), called by pkt_generic_packet(), is changed by
this patch.

Tomonori, Jens, can you see any immediate cause of this? It seems to me
that the alignment check in blk_rq_map_kern() *must* be going wrong,
somehow: this can't be an unaligned buffer or the code wouldn't have
worked before the patch, yet if the buffer was aligned, we should be
calling bio_map_kern(), which this patch hasn't changed. Perhaps the
buffer length of 12 is leading it to believe that it should go via a
bounce buffer and is calling the new code (and tripping some bug in it,
since presumably even the new code isn't expected to corrupt the data in
flight ;) )

Further investigations soon but I've had enough of rebooting my desktop
for tonight.

--
`Not even vi uses vi key bindings for its command line.' --- PdS


\
 
 \ /
  Last update: 2008-08-23 23:51    [W:0.128 / U:1.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site