linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Stefan /*St0fF*/ Hübner" <stefan.huebner@stud.tu-ilmenau.de>
To: Tejun Heo <tj@kernel.org>, linux-ide@vger.kernel.org, jgarzik@pobox.com
Subject: Re: Maybe a bug in libata-core
Date: Tue, 24 Aug 2010 00:41:45 +0200	[thread overview]
Message-ID: <4C72F929.6090401@stud.tu-ilmenau.de> (raw)
In-Reply-To: <4C723C65.6080303@kernel.org>

Am 23.08.2010 11:16, schrieb Tejun Heo:
> On 08/23/2010 02:52 AM, Stefan /*St0fF*/ Hübner wrote:
>> Hi Jeff and list,
>>
>> maybe this mail was wrong on the linux-scsi list.  So here we go again:
>>
>> -------- Original-Nachricht --------
>> Betreff: Maybe a bug in libata-core
>> Datum: Fri, 20 Aug 2010 23:48:09 +0200
>> Von: Stefan Hübner  <stefan.huebner@stud.tu-ilmenau.de>
>> Antwort an: stefan.huebner@stud.tu-ilmenau.de
>> Organisation: TU-Ilmenau
>> An: linux-scsi@vger.kernel.org
>>
>>  Hi List!
>>
>> After sending a WRITE_DMA_FUA_EXT ATA-command via SG_IO Passthru to a
>> harddisk (here: /dev/sdd), my kernel panics.  The is what I find in syslog:
> 
> You're sending down data command w/o data.  Panicking probably isn't
> the best response here.  Maybe the BUG_ON() should be changed to
> WARN_ON_ONCE() + goto sg_err.
> 
> Thanks.
> 

As far as I know my code I thought I did send enough data.  Maybe I'm
misunderstanding something: I valloc'ated block_count*logical_block_size
bytes, filled them with data and presented this buffer to the
sg_io_hdr_t structure by setting dxfer_len to the length of the buffer,
setting dxferp to a pointer to the buffer and setting the
dxfer_direction to SG_DXFER_TO_DEV.

The only thing coming to my mind would be overflow of dxfer_len, but as
this is a unsigned int - wouldn't it be 32 bits wide? (and by that
accepting f.e. 64k*512 bytes = 33 554 432 bytes (32M, needing 25 bits))

Any other suggestions, or do I have to present the code?

Thanks,
Stefan

  parent reply	other threads:[~2010-08-23 22:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-23  0:52 Fwd: Maybe a bug in libata-core Stefan /*St0fF*/ Hübner
2010-08-23  9:16 ` Tejun Heo
2010-08-23  9:27   ` [PATCH #upstream-fixes] libata: be less of a drama queen on empty data commands Tejun Heo
2010-08-23  9:44   ` Maybe a bug in libata-core Alan Cox
2010-08-23  9:27     ` Tejun Heo
2010-08-23 22:41   ` Stefan /*St0fF*/ Hübner [this message]
2010-08-24  7:27     ` Tejun Heo
2010-09-09  5:42       ` Stefan /*St0fF*/ Hübner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C72F929.6090401@stud.tu-ilmenau.de \
    --to=stefan.huebner@stud.tu-ilmenau.de \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).