linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	IDE/ATA development list <linux-ide@vger.kernel.org>,
	Albert Lee <albertcc@tw.ibm.com>
Subject: Re: libata passthru: support PIO multi commands
Date: Tue, 12 Jun 2007 11:18:15 -0400	[thread overview]
Message-ID: <466EB937.6050807@garzik.org> (raw)
In-Reply-To: <20070612111621.10074408@the-village.bc.nu>

Alan Cox wrote:
>>>> +		if (multi_count != dev->multi_count)
>>>> +			ata_dev_printk(dev, KERN_WARNING,
>>>> +				       "invalid multi_count %u ignored\n",
>>>> +				       multi_count);
>>>> +	}
>>> What limits log spamming here ?
>> Intelligence of the user with privs?
> 
> Not ever SG_IO call requires priviledges.

All calls relevant to this thread require CAP_SYS_RAWIO.


> Issue a multi count sized write. Acidentally collide with another program
> which mucks up the multiwrite count (for once it probably won't be HAL
> making a mess ;)) and send data. The state of the disk at the point a
> short multiwrite terminates is undefined, it may have written some of the
> sectors, it may have blanked them all (Optical media) etc. Far better
> just to error the invalid command - especially as in some cases without
> Mark's fixes for DRQ cleanup on error it may even hang in one direction.

ata_scsi_pass_thru() is not executed at ioctl submission time (block 
queue submission time), but rather immediately before it is issued to 
the drive.  At that point you know the bus is idle, all other commands 
have finished executing, and dev->multi_count is fresh not stale.  The 
code path goes from ata_scsi_pass_thru() to ata_qc_issue() without 
releasing the spinlock, even.

But the last point is true -- we should error rather than just warn 
there, AFAICS.

	Jeff



       reply	other threads:[~2007-06-12 15:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200706112200.l5BM0qFn005767@hera.kernel.org>
     [not found] ` <20070611233917.4bd8c6d7@the-village.bc.nu>
     [not found]   ` <466DE438.70108@garzik.org>
     [not found]     ` <20070612111621.10074408@the-village.bc.nu>
2007-06-12 15:18       ` Jeff Garzik [this message]
2007-06-12 16:05         ` libata passthru: support PIO multi commands Alan Cox
2007-06-13  2:57           ` Albert Lee
2007-06-13 18:40             ` Mark Lord
2007-06-13 18:55             ` Sergei Shtylyov
2007-06-13 18:55               ` Jeff Garzik

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=466EB937.6050807@garzik.org \
    --to=jeff@garzik.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=albertcc@tw.ibm.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.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).