1. 03 Jul, 2013 17 commits
  2. 01 Jul, 2013 5 commits
  3. 30 Jun, 2013 6 commits
    • Linus Torvalds's avatar
      Linux 3.10 · 8bb495e3
      Linus Torvalds authored
      8bb495e3
    • Linus Torvalds's avatar
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · f0277dce
      Linus Torvalds authored
      Pull another powerpc fix from Benjamin Herrenschmidt:
       "I mentioned that while we had fixed the kernel crashes, EEH error
        recovery didn't always recover...  It appears that I had a fix for
        that already in powerpc-next (with a stable CC).
      
        I cherry-picked it today and did a few tests and it seems that things
        now work quite well.  The patch is also pretty simple, so I see no
        reason to wait before merging it."
      
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
        powerpc/eeh: Fix fetching bus for single-dev-PE
      f0277dce
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 4b483802
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This is a set of seven bug fixes.  Several fcoe fixes for locking
        problems, initiator issues and a VLAN API change, all of which could
        eventually lead to data corruption, one fix for a qla2xxx locking
        problem which could lead to multiple completions of the same request
        (and subsequent data corruption) and a use after free in the ipr
        driver.  Plus one minor MAINTAINERS file update"
      
      (only six bugfixes in this pull, since I had already pulled the fcoe API
      fix directly from Robert Love)
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        [SCSI] ipr: Avoid target_destroy accessing memory after it was freed
        [SCSI] qla2xxx: Fix for locking issue between driver ISR and mailbox routines
        MAINTAINERS: Fix fcoe mailing list
        libfc: extend ex_lock to protect all of fc_seq_send
        libfc: Correct check for initiator role
        libfcoe: Fix Conflicting FCFs issue in the fabric
      4b483802
    • Gavin Shan's avatar
      powerpc/eeh: Fix fetching bus for single-dev-PE · ea461abf
      Gavin Shan authored
      While running Linux as guest on top of phyp, we possiblly have
      PE that includes single PCI device. However, we didn't return
      its PCI bus correctly and it leads to failure on recovery from
      EEH errors for single-dev-PE. The patch fixes the issue.
      
      Cc: <stable@vger.kernel.org> # v3.7+
      Cc: Steve Best <sbest@us.ibm.com>
      Signed-off-by: default avatarGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ea461abf
    • Linus Torvalds's avatar
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · 6c355bea
      Linus Torvalds authored
      Pull powerpc fixes from Ben Herrenschmidt:
       "We discovered some breakage in our "EEH" (PCI Error Handling) code
        while doing error injection, due to a couple of regressions.  One of
        them is due to a patch (37f02195 "powerpc/pci: fix PCI-e devices
        rescan issue on powerpc platform") that, in hindsight, I shouldn't
        have merged considering that it caused more problems than it solved.
      
        Please pull those two fixes.  One for a simple EEH address cache
        initialization issue.  The other one is a patch from Guenter that I
        had originally planned to put in 3.11 but which happens to also fix
        that other regression (a kernel oops during EEH error handling and
        possibly hotplug).
      
        With those two, the couple of test machines I've hammered with error
        injection are remaining up now.  EEH appears to still fail to recover
        on some devices, so there is another problem that Gavin is looking
        into but at least it's no longer crashing the kernel."
      
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
        powerpc/pci: Improve device hotplug initialization
        powerpc/eeh: Add eeh_dev to the cache during boot
      6c355bea
    • Olof Johansson's avatar
      ARM: dt: Only print warning, not WARN() on bad cpu map in device tree · 8d5bc1a6
      Olof Johansson authored
      Due to recent changes and expecations of proper cpu bindings, there are
      now cases for many of the in-tree devicetrees where a WARN() will hit
      on boot due to badly formatted /cpus nodes.
      
      Downgrade this to a pr_warn() to be less alarmist, since it's not a
      new problem.
      
      Tested on Arndale, Cubox, Seaboard and Panda ES. Panda hits the WARN
      without this, the others do not.
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8d5bc1a6
  4. 29 Jun, 2013 11 commits
  5. 28 Jun, 2013 1 commit
    • Akira Takeuchi's avatar
      mn10300: Use early_param() to parse "mem=" parameter · e3f12a53
      Akira Takeuchi authored
      This fixes the problem that "init=" options may not be passed to kernel
      correctly.
      
      parse_mem_cmdline() of mn10300 arch gets rid of "mem=" string from
      redboot_command_line. Then init_setup() parses the "init=" options from
      static_command_line, which is a copy of redboot_command_line, and keeps
      the pointer to the init options in execute_command variable.
      
      Since the commit 026cee00 upstream (params: <level>_initcall-like kernel
      parameters), static_command_line becomes overwritten by saved_command_line at
      do_initcall_level(). Notice that saved_command_line is a command line
      which includes "mem=" string.
      
      As a result, execute_command may point to weird string by the length of
      "mem=" parameter.
      I noticed this problem when using the command line like this:
      
          mem=128M console=ttyS0,115200 init=/bin/sh
      
      Here is the processing flow of command line parameters.
          start_kernel()
            setup_arch(&command_line)
               parse_mem_cmdline(cmdline_p)
                 * strcpy(boot_command_line, redboot_command_line);
                 * Remove "mem=xxx" from redboot_command_line.
                 * *cmdline_p = redboot_command_line;
            setup_command_line(command_line) <-- command_line is redboot_command_line
              * strcpy(saved_command_line, boot_command_line)
              * strcpy(static_command_line, command_line)
            parse_early_param()
              strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
              parse_early_options(tmp_cmdline);
                parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param);
            parse_args("Booting ..", static_command_line, ...);
              init_setup() <-- save the pointer in execute_command
            rest_init()
              kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
      
      At this point, execute_command points to "/bin/sh" string.
      
          kernel_init()
            kernel_init_freeable()
              do_basic_setup()
                do_initcalls()
                  do_initcall_level()
                    (*) strcpy(static_command_line, saved_command_line);
      
      Here, execute_command gets to point to "200" string !!
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      e3f12a53