1. 20 3月, 2012 1 次提交
  2. 04 1月, 2012 1 次提交
  3. 12 9月, 2011 1 次提交
  4. 27 5月, 2011 5 次提交
    • N
      brd: export module parameters · 8892cbaf
      Namhyung Kim 提交于
      Export 'rd_nr', 'rd_size' and 'max_part' parameters to sysfs so user can
      know that how many devices are allowed, how big each device is and how
      many partitions are supported. If 'max_part' is 0, it means simply the
      device doesn't support partitioning.
      
      Also note that 'max_part' can be adjusted to power of 2 minus 1 form if
      needed. User should check this value after the module loading if he/she
      want to use that number correctly (i.e. fdisk, mknod, etc.).
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      8892cbaf
    • N
      brd: fix comment on initial device creation · 13868b76
      Namhyung Kim 提交于
      If 'rd_nr' param was not specified, 16 (can be adjusted via
      CONFIG_BLK_DEV_RAM_COUNT) devices would be created by default
      but comment said 1. Fix it.
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      13868b76
    • N
      brd: handle on-demand devices correctly · af465668
      Namhyung Kim 提交于
      When finding or allocating a ram disk device, brd_probe() did not take
      partition numbers into account so that it can result to a different
      device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4
      for simplicity) :
      
      $ sudo modprobe brd max_part=15
      $ ls -l /dev/ram*
      brw-rw---- 1 root disk 1,  0 2011-05-25 15:41 /dev/ram0
      brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
      brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
      brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
      $ sudo mknod /dev/ram4 b 1 64
      $ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256
      256+0 records in
      256+0 records out
      1048576 bytes (1.0 MB) copied, 0.00215578 s, 486 MB/s
      namhyung@leonhard:linux$ ls -l /dev/ram*
      brw-rw---- 1 root disk 1,    0 2011-05-25 15:41 /dev/ram0
      brw-rw---- 1 root disk 1,   16 2011-05-25 15:41 /dev/ram1
      brw-rw---- 1 root disk 1,   32 2011-05-25 15:41 /dev/ram2
      brw-rw---- 1 root disk 1,   48 2011-05-25 15:41 /dev/ram3
      brw-r--r-- 1 root root 1,   64 2011-05-25 15:45 /dev/ram4
      brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64
      
      After this patch, /dev/ram4 - instead of /dev/ram64 - was
      accessed correctly.
      
      In addition, 'range' passed to blk_register_region() should
      include all range of dev_t that RAMDISK_MAJOR can address.
      It does not need to be limited by partition numbers unless
      'rd_nr' param was specified.
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      af465668
    • N
      brd: limit 'max_part' module param to DISK_MAX_PARTS · 315980c8
      Namhyung Kim 提交于
      The 'max_part' parameter controls the number of maximum partition
      a brd device can have. However if a user specifies very large
      value it would exceed the limitation of device minor number and
      can cause a kernel panic (or, at least, produce invalid device
      nodes in some cases).
      
      On my desktop system, following command kills the kernel. On qemu,
      it triggers similar oops but the kernel was alive:
      
      $ sudo modprobe brd max_part=100000
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
       IP: [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
       PGD 7af1067 PUD 7b19067 PMD 0
       Oops: 0000 [#1] SMP
       last sysfs file:
       CPU 0
       Modules linked in: brd(+)
      
       Pid: 44, comm: insmod Tainted: G        W   2.6.39-qemu+ #158 Bochs Bochs
       RIP: 0010:[<ffffffff81110a9a>]  [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
       RSP: 0018:ffff880007b15d78  EFLAGS: 00000286
       RAX: ffff880007b05478 RBX: ffff880007a52760 RCX: ffff880007b15dc8
       RDX: ffff880007a4f900 RSI: ffff880007b15e48 RDI: ffff880007a52760
       RBP: ffff880007b15da8 R08: 0000000000000002 R09: 0000000000000000
       R10: ffff880007b15e48 R11: ffff880007b05478 R12: 0000000000000000
       R13: ffff880007b05478 R14: 0000000000400920 R15: 0000000000000063
       FS:  0000000002160880(0063) GS:ffff880007c00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000058 CR3: 0000000007b1c000 CR4: 00000000000006b0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
       Process insmod (pid: 44, threadinfo ffff880007b14000, task ffff880007acb980)
       Stack:
        ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe
        ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a
        0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000
       Call Trace:
        [<ffffffff81143c0a>] kobject_add_internal+0xdf/0x1a0
        [<ffffffff81143da1>] kobject_add_varg+0x41/0x50
        [<ffffffff81143e6b>] kobject_add+0x64/0x66
        [<ffffffff8113bbe7>] blk_register_queue+0x5f/0xb8
        [<ffffffff81140f72>] add_disk+0xdf/0x289
        [<ffffffffa00040df>] brd_init+0xdf/0x1aa [brd]
        [<ffffffffa0004000>] ? 0xffffffffa0003fff
        [<ffffffffa0004000>] ? 0xffffffffa0003fff
        [<ffffffff8100020a>] do_one_initcall+0x7a/0x12e
        [<ffffffff8108516c>] sys_init_module+0x9c/0x1dc
        [<ffffffff812ff4bb>] system_call_fastpath+0x16/0x1b
       Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30
        8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89
       RIP  [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
        RSP <ffff880007b15d78>
       CR2: 0000000000000058
       ---[ end trace aebb1175ce1f6739 ]---
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      315980c8
    • N
      brd: get rid of unused members from struct brd_device · a2cba291
      Namhyung Kim 提交于
      brd_refcnt, brd_offset, brd_sizelimit and brd_blocksize in struct
      brd_device seem to be copied from struct loop_device but they're
      not used anywhere. Let get rid of them.
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      a2cba291
  5. 05 10月, 2010 1 次提交
    • A
      block: autoconvert trivial BKL users to private mutex · 2a48fc0a
      Arnd Bergmann 提交于
      The block device drivers have all gained new lock_kernel
      calls from a recent pushdown, and some of the drivers
      were already using the BKL before.
      
      This turns the BKL into a set of per-driver mutexes.
      Still need to check whether this is safe to do.
      
      file=$1
      name=$2
      if grep -q lock_kernel ${file} ; then
          if grep -q 'include.*linux.mutex.h' ${file} ; then
                  sed -i '/include.*<linux\/smp_lock.h>/d' ${file}
          else
                  sed -i 's/include.*<linux\/smp_lock.h>.*$/include <linux\/mutex.h>/g' ${file}
          fi
          sed -i ${file} \
              -e "/^#include.*linux.mutex.h/,$ {
                      1,/^\(static\|int\|long\)/ {
                           /^\(static\|int\|long\)/istatic DEFINE_MUTEX(${name}_mutex);
      
      } }"  \
          -e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
          -e '/[      ]*cycle_kernel_lock();/d'
      else
          sed -i -e '/include.*\<smp_lock.h\>/d' ${file}  \
                      -e '/cycle_kernel_lock()/d'
      fi
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2a48fc0a
  6. 10 9月, 2010 2 次提交
    • T
      block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush() · 4913efe4
      Tejun Heo 提交于
      Barrier is deemed too heavy and will soon be replaced by FLUSH/FUA
      requests.  Deprecate barrier.  All REQ_HARDBARRIERs are failed with
      -EOPNOTSUPP and blk_queue_ordered() is replaced with simpler
      blk_queue_flush().
      
      blk_queue_flush() takes combinations of REQ_FLUSH and FUA.  If a
      device has write cache and can flush it, it should set REQ_FLUSH.  If
      the device can handle FUA writes, it should also set REQ_FUA.
      
      All blk_queue_ordered() users are converted.
      
      * ORDERED_DRAIN is mapped to 0 which is the default value.
      * ORDERED_DRAIN_FLUSH is mapped to REQ_FLUSH.
      * ORDERED_DRAIN_FLUSH_FUA is mapped to REQ_FLUSH | REQ_FUA.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NBoaz Harrosh <bharrosh@panasas.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Alasdair G Kergon <agk@redhat.com>
      Cc: Pierre Ossman <drzeus@drzeus.cx>
      Cc: Stefan Weinhuber <wein@de.ibm.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      4913efe4
    • T
      block: kill QUEUE_ORDERED_BY_TAG · 6958f145
      Tejun Heo 提交于
      Nobody is making meaningful use of ORDERED_BY_TAG now and queue
      draining for barrier requests will be removed soon which will render
      the advantage of tag ordering moot.  Kill ORDERED_BY_TAG.  The
      following users are affected.
      
      * brd: converted to ORDERED_DRAIN.
      * virtio_blk: ORDERED_TAG path was already marked deprecated.  Removed.
      * xen-blkfront: ORDERED_TAG case dropped.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      6958f145
  7. 08 8月, 2010 3 次提交
  8. 01 6月, 2010 1 次提交
  9. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  10. 26 2月, 2010 1 次提交
  11. 22 9月, 2009 1 次提交
  12. 11 6月, 2009 1 次提交
  13. 15 4月, 2009 2 次提交
  14. 21 10月, 2008 2 次提交
    • A
      [PATCH] switch brd · 2b9ecd03
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      2b9ecd03
    • 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
  15. 21 8月, 2008 1 次提交
  16. 06 6月, 2008 1 次提交
  17. 25 5月, 2008 1 次提交
    • M
      brd: don't show ramdisks in /proc/partitions · 53978d0a
      Marcin Krol 提交于
      In 2.6.25, ramdisk devices show up in /proc/partitions, which is a
      behaviour change from the old rd.c.  Add GENHD_FL_SUPPRESS_PARTITION_INFO,
      which was present in rd.c.
      
      All kernels prior to 2.6.25 weren't displaying ramdisks in
      /proc/partitions.  Since there are many userspace tools using information
      from /proc/partitions some of them may now behave incorrectly (I didn't
      tested any though).  For example before 2.6.25 /proc/partitions was empty
      if no block devices like hard disks and such were detected by kernel.  Now
      all 16 ramdisks are always visible there.  Some software may rely on such
      information (I mean, on empty /proc/partitions).
      
      There was quite similar situation back in 2004, and ramdisks were excluded
      back from displaying.  Thats why I called this a regression (maybe a bit
      unfortunate).  See this patch for info:
      http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/broken-out/nbd-proc-partitions-fix.patch
      
      I also think that someone somewhere (long time ago) excluded ramdisks from
      /proc/partitions for good reasons.  It is possible that now such new
      "feature" is harmless, but I think there are more chances that someone
      will say "hey, /proc/partitions has changed, now my software doesn't work"
      then "hey where did my new 2.6.25 feature go".  nbd devices are also
      excluded, maybe for very same (unknown to me) reasons.
      Signed-off-by: NMarcin Krol <hawk@pld-linux.org>
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      53978d0a
  18. 30 4月, 2008 1 次提交
    • L
      brd: modify ramdisk device to be able to manage partitions · d7853d1f
      Laurent Vivier 提交于
      This patch adds partition management for Block RAM Device (BRD).
      
      This patch is done to keep in sync BRD and loop device drivers.
      
      This patch adds a parameter to the module, max_part, to specify
      the maximum number of partitions per RAM device.
      
      Example:
      
      # modprobe brd max_part=63
      # ls -l /dev/ram*
      brw-rw---- 1 root disk 1,   0 2008-04-03 13:39 /dev/ram0
      brw-rw---- 1 root disk 1,  64 2008-04-03 13:39 /dev/ram1
      brw-rw---- 1 root disk 1, 640 2008-04-03 13:39 /dev/ram10
      brw-rw---- 1 root disk 1, 704 2008-04-03 13:39 /dev/ram11
      brw-rw---- 1 root disk 1, 768 2008-04-03 13:39 /dev/ram12
      brw-rw---- 1 root disk 1, 832 2008-04-03 13:39 /dev/ram13
      brw-rw---- 1 root disk 1, 896 2008-04-03 13:39 /dev/ram14
      brw-rw---- 1 root disk 1, 960 2008-04-03 13:39 /dev/ram15
      brw-rw---- 1 root disk 1, 128 2008-04-03 13:39 /dev/ram2
      brw-rw---- 1 root disk 1, 192 2008-04-03 13:39 /dev/ram3
      brw-rw---- 1 root disk 1, 256 2008-04-03 13:39 /dev/ram4
      brw-rw---- 1 root disk 1, 320 2008-04-03 13:39 /dev/ram5
      brw-rw---- 1 root disk 1, 384 2008-04-03 13:39 /dev/ram6
      brw-rw---- 1 root disk 1, 448 2008-04-03 13:39 /dev/ram7
      brw-rw---- 1 root disk 1, 512 2008-04-03 13:39 /dev/ram8
      brw-rw---- 1 root disk 1, 576 2008-04-03 13:39 /dev/ram9
      # fdisk /dev/ram0
      Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
      Building a new DOS disklabel. Changes will remain in memory only,
      until you decide to write them. After that, of course, the previous
      content won't be recoverable.
      
      Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
      
      Command (m for help): o
      Building a new DOS disklabel. Changes will remain in memory only,
      until you decide to write them. After that, of course, the previous
      content won't be recoverable.
      
      Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
      
      Command (m for help): n
      Command action
         e   extended
         p   primary partition (1-4)
      p
      Partition number (1-4): 1
      First cylinder (1-2, default 1): 1
      Last cylinder or +size or +sizeM or +sizeK (1-2, default 2): 2
      
      Command (m for help): w
      The partition table has been altered!
      
      Calling ioctl() to re-read partition table.
      Syncing disks.
      # ls -l /dev/ram0*
      brw-rw---- 1 root disk 1, 0 2008-04-03 13:40 /dev/ram0
      brw-rw---- 1 root disk 1, 1 2008-04-03 13:40 /dev/ram0p1
      # mkfs /dev/ram0p1
      mke2fs 1.40-WIP (14-Nov-2006)
      Filesystem label=
      OS type: Linux
      Block size=1024 (log=0)
      Fragment size=1024 (log=0)
      4016 inodes, 16032 blocks
      801 blocks (5.00%) reserved for the super user
      First data block=1
      Maximum filesystem blocks=16515072
      2 block groups
      8192 blocks per group, 8192 fragments per group
      2008 inodes per group
      Superblock backups stored on blocks:
      	8193
      
      Writing inode tables: done
      Writing superblocks and filesystem accounting information: done
      
      This filesystem will be automatically checked every 26 mounts or
      180 days, whichever comes first.  Use tune2fs -c or -i to override.
      # mount /dev/ram0p1 /mnt
      df /mnt
      Filesystem           1K-blocks      Used Available Use% Mounted on
      /dev/ram0p1              15521       138     14582   1% /mnt
      # ls -l /mnt
      total 12
      drwx------ 2 root root 12288 2008-04-03 13:41 lost+found
      # umount /mnt
      # rmmod brd
      Signed-off-by: NLaurent Vivier <Laurent.Vivier@bull.net>
      Acked-by: NNick Piggin <nickpiggin@yahoo.com.au>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d7853d1f
  19. 28 4月, 2008 1 次提交
    • J
      return pfn from direct_access, for XIP · 30afcb4b
      Jared Hulbert 提交于
      Alter the block device ->direct_access() API to work with the new
      get_xip_mem() API (that requires both kaddr and pfn are returned).
      
      Some architectures will not do the right thing in their virt_to_page() for use
      by XIP (to translate from the kernel virtual address returned by
      direct_access(), to a user mappable pfn in XIP's page fault handler.
      
      However, we can't switch it to just return the pfn and not the kaddr, because
      we have no good way to get a kva from a pfn, and XIP requires the kva for its
      read(2) and write(2) handlers.  So we have to return both.
      Signed-off-by: NJared Hulbert <jaredeh@gmail.com>
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux-mm@kvack.org
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      30afcb4b
  20. 23 4月, 2008 1 次提交
  21. 09 2月, 2008 2 次提交
    • N
      rd: support XIP · 75acb9cd
      Nick Piggin 提交于
      Support direct_access XIP method with brd.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      75acb9cd
    • N
      rewrite rd · 9db5579b
      Nick Piggin 提交于
      This is a rewrite of the ramdisk block device driver.
      
      The old one is really difficult because it effectively implements a block
      device which serves data out of its own buffer cache.  It relies on the dirty
      bit being set, to pin its backing store in cache, however there are non
      trivial paths which can clear the dirty bit (eg.  try_to_free_buffers()),
      which had recently lead to data corruption.  And in general it is completely
      wrong for a block device driver to do this.
      
      The new one is more like a regular block device driver.  It has no idea about
      vm/vfs stuff.  It's backing store is similar to the buffer cache (a simple
      radix-tree of pages), but it doesn't know anything about page cache (the pages
      in the radix tree are not pagecache pages).
      
      There is one slight downside -- direct block device access and filesystem
      metadata access goes through an extra copy and gets stored in RAM twice.
      However, this downside is only slight, because the real buffercache of the
      device is now reclaimable (because we're not playing crazy games with it), so
      under memory intensive situations, footprint should effectively be the same --
      maybe even a slight advantage to the new driver because it can also reclaim
      buffer heads.
      
      The fact that it now goes through all the regular vm/fs paths makes it
      much more useful for testing, too.
      
         text    data     bss     dec     hex filename
         2837     849     384    4070     fe6 drivers/block/rd.o
         3528     371      12    3911     f47 drivers/block/brd.o
      
      Text is larger, but data and bss are smaller, making total size smaller.
      
      A few other nice things about it:
      - Similar structure and layout to the new loop device handlinag.
      - Dynamic ramdisk creation.
      - Runtime flexible buffer head size (because it is no longer part of the
        ramdisk code).
      - Boot / load time flexible ramdisk size, which could easily be extended
        to a per-ramdisk runtime changeable size (eg. with an ioctl).
      - Can use highmem for the backing store.
      
      [akpm@linux-foundation.org: fix build]
      [byron.bbradley@gmail.com: make rd_size non-static]
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NByron Bradley <byron.bbradley@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9db5579b