It looks like the kernel code change that made this problem visible
occurred in 2.6.10. I've attached part of a diff between "sg.c" of
Linux 2.6.9 versus 2.6.10.
Interestingly, it appears that the diagnostic message is the only thing
that was added. You can see that the code does not alter any variables,
etc.
So the question remains: is this printk erroneous... or does it
correctly identify a bug in cdparanoia?
-- graham
$ diff kernel-source-2.6.9/drivers/scsi/sg.c
kernel-source-2.6.10/drivers/scsi/sg.c
565a566,579
> /*
> * SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV,
> * but is is possible that the app intended SG_DXFER_TO_DEV, because
> there
> * is a non-zero input_size, so emit a warning.
> */
> if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV)
> if (printk_ratelimit())
> printk(KERN_WARNING
> "sg_write: data in/out %d/%d bytes for SCSI
> command 0x%x--"
> "guessing data in;\n" KERN_WARNING " "
> "program %s not setting count and/or reply_len
> properly\n",
> old_hdr.reply_len - (int)SZ_SG_HEADER,
> input_size, (unsigned int) cmnd[0],
> current->comm);