1. 18 2月, 2011 8 次提交
  2. 17 2月, 2011 1 次提交
  3. 30 1月, 2011 1 次提交
  4. 17 1月, 2011 2 次提交
    • A
      mtd: mtdpart: disallow reading OOB past the end of the partition · 154bf89f
      Artem Bityutskiy 提交于
      This patch fixes the mtdpart bug which allows users reading OOB past the
      end of the partition. This happens because 'part_read_oob()' allows reading
      multiple OOB areas in one go, and mtdparts does not validate the OOB
      length in the request.
      
      Although there is such check in 'nand_do_read_oob()' in nand_base.c, but
      it checks that we do not read past the flash chip, not the partition,
      because in nand_base.c we work with the whole chip (e.g., mtd->size
      in nand_base.c is the size of the whole chip). So this check cannot
      be done correctly in nand_base.c and should be instead done in mtdparts.c.
      
      This problem was reported by Jason Liu <r64343@freescale.com> and reproduced
      with nandsim:
      
      $ modprobe nandsim first_id_byte=0x20 second_id_byte=0xaa third_id_byte=0x00 \
                         fourth_id_byte=0x15 parts=0x400,0x400
      $ modprobe nandsim mtd_oobtest.ko dev=0
      $ dmesg
      = snip =
      mtd_oobtest: attempting to read past end of device
      mtd_oobtest: an error is expected...
      mtd_oobtest: error: read past end of device
      = snip =
      mtd_oobtest: finished with 2 errors
      Reported-by: NJason Liu <liu.h.jason@gmail.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      154bf89f
    • A
      sanitize vfsmount refcounting changes · f03c6599
      Al Viro 提交于
      Instead of splitting refcount between (per-cpu) mnt_count
      and (SMP-only) mnt_longrefs, make all references contribute
      to mnt_count again and keep track of how many are longterm
      ones.
      
      Accounting rules for longterm count:
      	* 1 for each fs_struct.root.mnt
      	* 1 for each fs_struct.pwd.mnt
      	* 1 for having non-NULL ->mnt_ns
      	* decrement to 0 happens only under vfsmount lock exclusive
      
      That allows nice common case for mntput() - since we can't drop the
      final reference until after mnt_longterm has reached 0 due to the rules
      above, mntput() can grab vfsmount lock shared and check mnt_longterm.
      If it turns out to be non-zero (which is the common case), we know
      that this is not the final mntput() and can just blindly decrement
      percpu mnt_count.  Otherwise we grab vfsmount lock exclusive and
      do usual decrement-and-check of percpu mnt_count.
      
      For fs_struct.c we have mnt_make_longterm() and mnt_make_shortterm();
      namespace.c uses the latter in places where we don't already hold
      vfsmount lock exclusive and opencodes a few remaining spots where
      we need to manipulate mnt_longterm.
      
      Note that we mostly revert the code outside of fs/namespace.c back
      to what we used to have; in particular, normal code doesn't need
      to care about two kinds of references, etc.  And we get to keep
      the optimization Nick's variant had bought us...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      f03c6599
  5. 14 1月, 2011 1 次提交
    • S
      kmsg_dump: constrain mtdoops and ramoops to perform their actions only for KMSG_DUMP_PANIC · fc2d557c
      Seiji Aguchi 提交于
      This series aims to develop logging facility for enterprise use.
      
      It is important to save kernel messages reliably on enterprise system
      because they are helpful for diagnosing system.
      
      This series add kmsg_dump() to the paths loosing kernel messages.  The use
      case is the following.
      
      [Use case of reboot/poweroff/halt/emergency_restart]
      
       My company has often experienced the followings in our support service.
       - Customer's system suddenly reboots.
       - Customers ask us to investigate the reason of the reboot.
      
      We recognize the fact itself because boot messages remain in
      /var/log/messages.  However, we can't investigate the reason why the
      system rebooted, because the last messages don't remain.  And off course
      we can't explain the reason.
      
      We can solve above problem with this patch as follows.
      
       Case1: reboot with command
         - We can see "Restarting system with command:" or ""Restarting system.".
      
       Case2: halt with command
         - We can see "System halted.".
      
       Case3: poweroff with command
         - We can see " Power down.".
      
       Case4: emergency_restart with sysrq.
         - We can see "Sysrq:" outputted in __handle_sysrq().
      
       Case5: emergency_restart with softdog.
         - We can see "Initiating system reboot" in watchdog_fire().
      
      So, we can distinguish the reason of reboot, poweroff, halt and emergency_restart.
      
      If customer executed reboot command, you may think the customer should
      know the fact.  However, they often claim they don't execute the command
      when they rebooted system by mistake.
      
      No message remains on the current Linux kernel, so we can't show the proof
      to the customer.  This patch improves this situation.
      
      This patch:
      
      Alters mtdoops and ramoops to perform their actions only for
      KMSG_DUMP_PANIC, KMSG_DUMP_OOPS and KMSG_DUMP_KEXEC because they would
      like to log crashes only.
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marco Stornelli <marco.stornelli@gmail.com>
      Reviewed-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fc2d557c
  6. 13 1月, 2011 1 次提交
  7. 07 1月, 2011 1 次提交
    • N
      fs: scale mntget/mntput · b3e19d92
      Nick Piggin 提交于
      The problem that this patch aims to fix is vfsmount refcounting scalability.
      We need to take a reference on the vfsmount for every successful path lookup,
      which often go to the same mount point.
      
      The fundamental difficulty is that a "simple" reference count can never be made
      scalable, because any time a reference is dropped, we must check whether that
      was the last reference. To do that requires communication with all other CPUs
      that may have taken a reference count.
      
      We can make refcounts more scalable in a couple of ways, involving keeping
      distributed counters, and checking for the global-zero condition less
      frequently.
      
      - check the global sum once every interval (this will delay zero detection
        for some interval, so it's probably a showstopper for vfsmounts).
      
      - keep a local count and only taking the global sum when local reaches 0 (this
        is difficult for vfsmounts, because we can't hold preempt off for the life of
        a reference, so a counter would need to be per-thread or tied strongly to a
        particular CPU which requires more locking).
      
      - keep a local difference of increments and decrements, which allows us to sum
        the total difference and hence find the refcount when summing all CPUs. Then,
        keep a single integer "long" refcount for slow and long lasting references,
        and only take the global sum of local counters when the long refcount is 0.
      
      This last scheme is what I implemented here. Attached mounts and process root
      and working directory references are "long" references, and everything else is
      a short reference.
      
      This allows scalable vfsmount references during path walking over mounted
      subtrees and unattached (lazy umounted) mounts with processes still running
      in them.
      
      This results in one fewer atomic op in the fastpath: mntget is now just a
      per-CPU inc, rather than an atomic inc; and mntput just requires a spinlock
      and non-atomic decrement in the common case. However code is otherwise bigger
      and heavier, so single threaded performance is basically a wash.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      b3e19d92
  8. 06 1月, 2011 23 次提交
  9. 04 1月, 2011 1 次提交
  10. 22 12月, 2010 1 次提交