Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 11 5月, 2009 2 次提交
    • T
      block: implement blk_rq_pos/[cur_]sectors() and convert obvious ones · 5b93629b
      由 Tejun Heo 提交于 
      Implement accessors - blk_rq_pos(), blk_rq_sectors() and
blk_rq_cur_sectors() which return rq->hard_sector, rq->hard_nr_sectors
and rq->hard_cur_sectors respectively and convert direct references of
the said fields to the accessors.

This is in preparation of request data length handling cleanup.

Geert	: suggested adding const to struct request * parameter to accessors
Sergei	: spotted error in patch description

[ Impact: cleanup ]
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Acked-by: NStephen Rothwell <sfr@canb.auug.org.au>
Tested-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Ackec-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Borislav Petkov <petkovbb@googlemail.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      5b93629b
    • T
      block: add rq->resid_len · c3a4d78c
      由 Tejun Heo 提交于 
      rq->data_len served two purposes - the length of data buffer on issue
and the residual count on completion.  This duality creates some
headaches.

First of all, block layer and low level drivers can't really determine
what rq->data_len contains while a request is executing.  It could be
the total request length or it coulde be anything else one of the
lower layers is using to keep track of residual count.  This
complicates things because blk_rq_bytes() and thus
[__]blk_end_request_all() relies on rq->data_len for PC commands.
Drivers which want to report residual count should first cache the
total request length, update rq->data_len and then complete the
request with the cached data length.

Secondly, it makes requests default to reporting full residual count,
ie. reporting that no data transfer occurred.  The residual count is
an exception not the norm; however, the driver should clear
rq->data_len to zero to signify the normal cases while leaving it
alone means no data transfer occurred at all.  This reverse default
behavior complicates code unnecessarily and renders block PC on some
drivers (ide-tape/floppy) unuseable.

This patch adds rq->resid_len which is used only for residual count.

While at it, remove now unnecessasry blk_rq_bytes() caching in
ide_pc_intr() as rq->data_len is not changed anymore.

Boaz	: spotted missing conversion in osd
Sergei	: spotted too early conversion to blk_rq_bytes() in ide-tape

[ Impact: cleanup residual count handling, report 0 resid by default ]
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Borislav Petkov <petkovbb@googlemail.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Mike Miller <mike.miller@hp.com>
Cc: Eric Moore <Eric.Moore@lsi.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Doug Gilbert <dgilbert@interlog.com>
Cc: Mike Miller <mike.miller@hp.com>
Cc: Eric Moore <Eric.Moore@lsi.com>
Cc: Darrick J. Wong <djwong@us.ibm.com>
Cc: Pete Zaitcev <zaitcev@redhat.com>
Cc: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      c3a4d78c
  3. 28 4月, 2009 4 次提交
    • T
      ide-cd,atapi: use bio for internal commands · 02e7cf8f
      由 Tejun Heo 提交于 
      Impact: unify request data buffer handling

rq->data is used mostly to pass kernel buffer through request queue
without using bio.  There are only a couple of places which still do
this in kernel and converting to bio isn't difficult.

This patch converts ide-cd and atapi to use bio instead of rq->data
for request sense and internal pc commands.  With previous change to
unify sense request handling, this is relatively easily achieved by
adding blk_rq_map_kern() during sense_rq prep and PC issue.

If blk_rq_map_kern() fails for sense, the error is deferred till sense
issue and aborts the failed command which triggered the sense.  Note
that this is a slim possibility as sense prep is done on each command
issue, so for the above condition to actually trigger, all preps since
the last sense issue till the issue of the request which would require
a sense should fail.

* do_request functions might sleep now.  This should be okay as ide
  request_fn - do_ide_request() - is invoked only from make_request
  and plug work.  Make sure this is the case by adding might_sleep()
  to do_ide_request().

* Functions which access the read sense data before the sense request
  is complete now should access bio_data(sense_rq->bio) as the sense
  buffer might have been copied during blk_rq_map_kern().

* ide-tape updated to map sg.

* cdrom_do_block_pc() now doesn't have to deal with REQ_TYPE_ATA_PC
  special case.  Simplified.

* tp_ops->output/input_data path dropped from ide_pc_intr().
Signed-off-by: NTejun Heo <tj@kernel.org>
      02e7cf8f
    • B
      ide-cd: convert to using generic sense request · c457ce87
      由 Borislav Petkov 提交于 
      Preallocate a sense request in the ->do_request method and reinitialize
it only on demand, in case it's been consumed in the IRQ handler path.
The reason for this is that we don't want to be mapping rq to bio in
the IRQ path and introduce all kinds of unnecessary hacks to the block
layer.

tj: * Both user and kernel PC requests expect sense data to be stored
      in separate storage other than drive->sense_data.  Copy sense
      data to rq->sense on completion if rq->sense is not NULL.  This
      fixes bogus sense data on PC requests.

As a result, remove cdrom_queue_request_sense.

CC: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NBorislav Petkov <petkovbb@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
      c457ce87
    • T
      ide-cd: don't abuse rq->buffer · 1f181d2b
      由 Tejun Heo 提交于 
      Impact: rq->buffer usage cleanup

ide-cd uses rq->buffer to carry pointer to the original request when
issuing REQUEST_SENSE.  Use rq->special instead.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
      1f181d2b
    • T
      ide-cd: clear sense buffer before issuing request sense · 59a4f6f3
      由 Tejun Heo 提交于 
      Impact: code simplification

ide_cd_request_sense_fixup() clears the tail of the sense buffer if
the device didn't completely fill it.  This patch makes
cdrom_queue_request_sense() clear the sense buffer before issuing the
command instead of clearing it afterwards.  This simplifies code and
eases future changes.
Signed-off-by: NTejun Heo <tj@kernel.org>
      59a4f6f3
  5. 23 4月, 2009 1 次提交
    • H
      ide-cd: fix kernel crash on hppa regression · a1f9a89c
      由 Helge Deller 提交于 
      With 2.6.30-rc2 I face a kernel crash on the 32bit hppa architecture 
due to ide-cd when udev creates the device nodes at startup:

Kernel Fault: Code=26 regs=8ed34c40 (Addr=00000024)
IASQ: 00000000 00000000 IAOQ: 1034b5ac 1034b5b0
 IIR: 4ab30048    ISR: 00000000  IOR: 00000024
 CPU:        0   CR30: 8ed34000 CR31: ffff55ff
 ORIG_R28: 00000000
 IAOQ[0]: ide_complete_rq+0x2c/0x70
 IAOQ[1]: ide_complete_rq+0x30/0x70
 RP(r2): cdrom_newpc_intr+0x178/0x46c
Backtrace:
 [<1035c608>] cdrom_newpc_intr+0x178/0x46c
 [<1034c494>] ide_intr+0x1b0/0x214
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<102f7864>] superio_interrupt+0x88/0xbc
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<10112efc>] do_cpu_irq_mask+0x9c/0xd0
 [<10116068>] intr_return+0x0/0x4

This crash seems to happen due to an uninitialized variable "rc".
The compiler even warns about that:
  CC      drivers/ide/ide-cd.o                                                         
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c: In function `cdrom_newpc_intr':
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c:612: warning: `rc' might be used uninitialized in this function

After applying the trivial patch below, which just initializes 
the variable to zero, the kernel doesn't crash any longer:

Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
done.
Signed-off-by: NHelge Deller <deller@gmx.de>
Acked-by: NBorislav Petkov <petkovbb@gmail.com>
Cc: Linus <torvalds@linux-foundation.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      a1f9a89c
  7. 08 4月, 2009 8 次提交
  9. 01 4月, 2009 22 次提交
  11. 27 3月, 2009 3 次提交