Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 21 10月, 2008 1 次提交
    • A
      [PATCH] beginning of methods conversion · d4430d62
      由 Al Viro 提交于 
      To keep the size of changesets sane we split the switch by drivers;
to keep the damn thing bisectable we do the following:
	1) rename the affected methods, add ones with correct
prototypes, make (few) callers handle both.  That's this changeset.
	2) for each driver convert to new methods.  *ALL* drivers
are converted in this series.
	3) kill the old (renamed) methods.

Note that it _is_ a flagday; all in-tree drivers are converted and by the
end of this series no trace of old methods remain.  The only reason why
we do that this way is to keep the damn thing bisectable and allow per-driver
debugging if anything goes wrong.

New methods:
	open(bdev, mode)
	release(disk, mode)
	ioctl(bdev, mode, cmd, arg)		/* Called without BKL */
	compat_ioctl(bdev, mode, cmd, arg)
	locked_ioctl(bdev, mode, cmd, arg)	/* Called with BKL, legacy */
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d4430d62
  3. 17 10月, 2008 1 次提交
    • A
      i2o: Fix 32/64bit DMA locking · 9d793b0b
      由 Alan Cox 提交于 
      The I2O ioctls assume 32bits.  In itself that is fine as they are old
cards and nobody uses 64bit.  However on LKML it was noted this
assumption is also made for allocated memory and is unsafe on 64bit
systems.

Fixing this is a mess.  It turns out there is tons of crap buried in a
header file that does racy 32/64bit filtering on the masks.

So we:
- Verify all callers of the racy code can sleep (i2o_dma_[re]alloc)
- Move the code into a new i2o/memory.c file
- Remove the gfp_mask argument so nobody can try and misuse the function
- Wrap a mutex around the problem area (a single mutex is easy to do and
  none of this is performance relevant)
- Switch the remaining problem kmalloc holdout to use i2o_dma_alloc

Cc: Markus Lidel <Markus.Lidel@shadowconnect.com>
Cc: Vasily Averin <vvs@sw.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9d793b0b
  5. 27 7月, 2008 2 次提交
  7. 25 7月, 2008 1 次提交
  9. 22 7月, 2008 1 次提交
  11. 12 7月, 2008 3 次提交
  13. 08 7月, 2008 1 次提交
  15. 03 7月, 2008 2 次提交
  17. 21 6月, 2008 1 次提交
  19. 05 6月, 2008 3 次提交
  21. 27 5月, 2008 1 次提交
    • M
      [SCSI] fusion mpt: fix target missing after resetting external raid · 7ba2db5f
      由 Michael Reed 提交于 
      Following a hard reset of a SAS raid, one of the raid targets is occasionally
missing.  I tracked this down to a pretty obscure little bug.

The LSI fusion drivers for SAS and Fibre Channel both use their respective
transport layers.  Those transport layers increment the target number
assigned to new targets.

The routine __scsi_scan_target uses the "this_id" element of the Scsi_Host
structure to avoid scanning the scsi host adapter.  Both fusion drivers set
"this_id" from a value returned in a firmware PortFacts response.  For my
particular test case (SAS) the firmware id assigned to the initiator was
173.  After enough raid resets to cause the raid targets to go and come a
sufficient number of times, the id assigned by the transport to a raid
target would match the id assigned by the host adapter to the "this_id"
field, resulting in that target not being scanned.

Fix by not assigning this_id and not checking it in slave_configure. 
Signed-off-by: NMichael Reed <mdr@sgi.com>
Acked-by: N"Moore, Eric" <Eric.Moore@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      7ba2db5f
  23. 29 4月, 2008 2 次提交
  25. 20 4月, 2008 1 次提交
  27. 08 4月, 2008 4 次提交
  29. 19 3月, 2008 1 次提交
  31. 06 3月, 2008 1 次提交
  33. 04 3月, 2008 2 次提交
  35. 22 2月, 2008 1 次提交
  37. 18 2月, 2008 1 次提交
  39. 12 2月, 2008 2 次提交
  41. 03 2月, 2008 2 次提交
  43. 28 1月, 2008 1 次提交
  45. 24 1月, 2008 2 次提交
  47. 12 1月, 2008 1 次提交
  49. 06 11月, 2007 1 次提交
  51. 24 10月, 2007 1 次提交