Jens Axboe wrote:
> On Tue, Jan 20 2009, Boaz Harrosh wrote:
>> If a bidi command was issued to a request_queue not mark as
>> QUEUE_FLAG_BIDI. Issue an error report. This is a misconfiguration
>> an administrator would like to know about, which is otherwise
>> hard to detect.
>>
>> Signed-off-by: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
>> ---
>> block/bsg.c | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/block/bsg.c b/block/bsg.c
>> index 44a2a0f..1da14fe 100644
>> --- a/block/bsg.c
>> +++ b/block/bsg.c
>> @@ -270,6 +270,11 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr, fmode_t has_write_perm,
>>
>> if (rw == WRITE && hdr->din_xfer_len) {
>> if (!test_bit(QUEUE_FLAG_BIDI, &q->queue_flags)) {
>> + if (printk_ratelimit()) {
>> + printk(KERN_ERR
>> + "bsg: Attempt to send a bidi command "
>> + "to a none bidi device\n");
>> + }
>> ret = -EOPNOTSUPP;
>> goto out;
>> }
>> --
>> 1.6.0.1
>
> Thanks, that works. But why isn't the -EOPNOTSUPP error return (which the
> app can see and print info about) enough? Do we really need to put this
> in the kernel log?
>
This is your call, I'm not very experienced with this things but ...
What I was thinking is in situations when things used to work fine, and
then later could stop working because of seemingly unrelated changes.
For example: The same iscsi target behind a new accelerated-iscsi-card like
cxgb3i, qla4xxx or iSER would stop working, since bidi is not enabled for
them.
But let me check I had problems with the return value. I'll try to detect
this condition from the application and report in the proper manner. Just
that I thought of the poor Admin that needs to fix that after the fact...
(me ;))
Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
