Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 6月, 2005 4 次提交
  3. 17 6月, 2005 1 次提交
    • K
      When cfq I/O scheduler is selected, get_request() in __make_request() calls · db3b5848
      由 Kiyoshi Ueda 提交于 
      __cfq_get_queue().  __cfq_get_queue() finds an existing queue (struct
cfq_queue) of the current process for the device and returns it.  If it's not
found, __cfq_get_queue() creates and returns a new one if __cfq_get_queue() is
called with __GFP_WAIT flag, or __cfq_get_queue() returns NULL (this means that
get_request() fails) if no __GFP_WAIT flag.

On the other hand, in __make_request(), get_request() is called without
__GFP_WAIT flag at the first time.  Thus, the get_request() fails when there is
no existing queue, typically when it's called for the first I/O request of the
process to the device.

Though it will be followed by get_request_wait() for general case,
__make_request() will just end the I/O with an error (EWOULDBLOCK) when the
request was for read-ahead.
Signed-off-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NKiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      db3b5848
  5. 16 6月, 2005 2 次提交
  7. 12 6月, 2005 1 次提交
  9. 09 6月, 2005 1 次提交
  11. 03 6月, 2005 1 次提交
  13. 21 5月, 2005 3 次提交
  15. 17 5月, 2005 3 次提交
    • P
      [PATCH] CDRW/DVD packet writing data corruption fix · 7baeb6a5
      由 Peter Osterlund 提交于 
      I found a bug in the packet writing driver that could cause data
corruption.  The problem arised if the driver got a write request for a
sector in a "zone" it was already working on.  In that case it was supposed
to queue the write request until it was done processing earlier requests
for the same zone, and instead work on some other zone in the mean time.
However, if there was no other zone to work on, the driver would initiate
two packet_data objects for the same zone, causing unpredictable things to
happen.
Signed-off-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7baeb6a5
    • P
      [PATCH] Fix root hole in pktcdvd · 118326e9
      由 Peter Osterlund 提交于 
      ioctl_by_bdev may only be used INSIDE the kernel.  If the "arg" argument
refers to memory that is accessed by put_user/get_user in the ioctl
function, the memory needs to be in the kernel address space (that's the
set_fs(KERNEL_DS) doing in the ioctl_by_bdev).  This works on i386 because
even with set_fs(KERNEL_DS) the user space memory is still accessible with
put_user/get_user.  That is not true for s390.  In short the ioctl
implementation of the pktcdvd device driver is horribly broken.
Signed-off-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      118326e9
    • S
      [PATCH] Fix root hole in raw device · 68f66feb
      由 Stephen Tweedie 提交于 
      [Patch] Fix raw device ioctl pass-through

Raw character devices are supposed to pass ioctls through to the block
devices they are bound to.  Unfortunately, they are using the wrong
function for this: ioctl_by_bdev(), instead of blkdev_ioctl().

ioctl_by_bdev() performs a set_fs(KERNEL_DS) before calling the ioctl,
redirecting the user-space buffer access to the kernel address space.
This is, needless to say, a bad thing.

This was noticed first on s390, where raw IO was non-functioning.  The
s390 driver config does not actually allow raw IO to be enabled, which
was the first part of the problem.  Secondly, the s390 kernel address
space is distinct from user, causing legal raw ioctls to fail.  I've
reproduced this on a kernel built with 4G:4G split on x86, which fails
in the same way (-EFAULT if the address does not exist kernel-side;
returns success without actually populating the user buffer if it does.)

The patch below fixes both the config and address-space problems.  It's
based closely on a patch by Jan Glauber <jang@de.ibm.com>, which has
been tested on s390 at IBM.  I've tested it on x86 4G:4G (split address
space) and x86_64 (common address space).

Kernel-address-space access has been assigned CAN-2005-1264.
Signed-off-by: NStephen Tweedie <sct@redhat.com>
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      68f66feb
  17. 07 5月, 2005 1 次提交
  19. 06 5月, 2005 3 次提交
  21. 04 5月, 2005 5 次提交
  23. 01 5月, 2005 2 次提交
  25. 25 4月, 2005 1 次提交
  27. 19 4月, 2005 8 次提交
  29. 17 4月, 2005 4 次提交