1. 07 5月, 2014 1 次提交
    • A
      genirq: Provide irq_force_affinity fallback for non-SMP · 4c88d7f9
      Arnd Bergmann 提交于
      Patch 01f8fa4f "genirq: Allow forcing cpu affinity of interrupts" added
      an irq_force_affinity() function, and 30ccf03b "clocksource: Exynos_mct:
      Use irq_force_affinity() in cpu bringup" subsequently uses it. However, the
      driver can be used with CONFIG_SMP disabled, but the function declaration
      is only available for CONFIG_SMP, leading to this build error:
      
      drivers/clocksource/exynos_mct.c:431:3: error: implicit declaration of function 'irq_force_affinity' [-Werror=implicit-function-declaration]
         irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
      
      This patch introduces a dummy helper function for the non-SMP case
      that always returns success, to get rid of the build error.
      Since the patches causing the problem are marked for stable backports,
      this one should be as well.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NKukjin Kim <kgene.kim@samsung.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/5619084.0zmrrIUZLV@wuerfelSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      4c88d7f9
  2. 28 4月, 2014 3 次提交
    • S
      ftrace/module: Hardcode ftrace_module_init() call into load_module() · a949ae56
      Steven Rostedt (Red Hat) 提交于
      A race exists between module loading and enabling of function tracer.
      
      	CPU 1				CPU 2
      	-----				-----
        load_module()
         module->state = MODULE_STATE_COMING
      
      				register_ftrace_function()
      				 mutex_lock(&ftrace_lock);
      				 ftrace_startup()
      				  update_ftrace_function();
      				   ftrace_arch_code_modify_prepare()
      				    set_all_module_text_rw();
      				   <enables-ftrace>
      				    ftrace_arch_code_modify_post_process()
      				     set_all_module_text_ro();
      
      				[ here all module text is set to RO,
      				  including the module that is
      				  loading!! ]
      
         blocking_notifier_call_chain(MODULE_STATE_COMING);
          ftrace_init_module()
      
           [ tries to modify code, but it's RO, and fails!
             ftrace_bug() is called]
      
      When this race happens, ftrace_bug() will produces a nasty warning and
      all of the function tracing features will be disabled until reboot.
      
      The simple solution is to treate module load the same way the core
      kernel is treated at boot. To hardcode the ftrace function modification
      of converting calls to mcount into nops. This is done in init/main.c
      there's no reason it could not be done in load_module(). This gives
      a better control of the changes and doesn't tie the state of the
      module to its notifiers as much. Ftrace is special, it needs to be
      treated as such.
      
      The reason this would work, is that the ftrace_module_init() would be
      called while the module is in MODULE_STATE_UNFORMED, which is ignored
      by the set_all_module_text_ro() call.
      
      Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.comReported-by: NTakao Indoh <indou.takao@jp.fujitsu.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: stable@vger.kernel.org # 2.6.38+
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      a949ae56
    • T
      genirq: x86: Ensure that dynamic irq allocation does not conflict · 62a08ae2
      Thomas Gleixner 提交于
      On x86 the allocation of irq descriptors may allocate interrupts which
      are in the range of the GSI interrupts. That's wrong as those
      interrupts are hardwired and we don't have the irq domain translation
      like PPC. So one of these interrupts can be hooked up later to one of
      the devices which are hard wired to it and the io_apic init code for
      that particular interrupt line happily reuses that descriptor with a
      completely different configuration so hell breaks lose.
      
      Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs,
      except for a few usage sites which have not yet blown up in our face
      for whatever reason. But for drivers which need an irq range, like the
      GPIO drivers, we have no limit in place and we don't want to expose
      such a detail to a driver.
      
      To cure this introduce a function which an architecture can implement
      to impose a lower bound on the dynamic interrupt allocations.
      
      Implement it for x86 and set the lower bound to nr_gsi_irqs, which is
      the end of the hardwired interrupt space, so all dynamic allocations
      happen above.
      
      That not only allows the GPIO driver to work sanely, it also protects
      the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and
      htirq code. They need to be cleaned up as well, but that's a separate
      issue.
      Reported-by: NJin Yao <yao.jin@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Krogerus Heikki <heikki.krogerus@intel.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1404241617360.28206@ionos.tec.linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      62a08ae2
    • R
      linux/interrupt.h: fix new kernel-doc warnings · def5f127
      Randy Dunlap 提交于
      Fix new kernel-doc warnings in <linux/interrupt.h>:
      
      Warning(include/linux/interrupt.h:219): No description found for parameter 'cpumask'
      Warning(include/linux/interrupt.h:219): Excess function parameter 'mask' description in 'irq_set_affinity'
      Warning(include/linux/interrupt.h:236): No description found for parameter 'cpumask'
      Warning(include/linux/interrupt.h:236): Excess function parameter 'mask' description in 'irq_force_affinity'
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Link: http://lkml.kernel.org/r/535DD2FD.7030804@infradead.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      def5f127
  3. 25 4月, 2014 3 次提交
    • M
      tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc · 6a20dbd6
      Manfred Schlaegl 提交于
      The race was introduced while development of linux-3.11 by
      e8437d7e and
      e9975fde.
      Originally it was found and reproduced on linux-3.12.15 and
      linux-3.12.15-rt25, by sending 500 byte blocks with 115kbaud to the
      target uart in a loop with 100 milliseconds delay.
      
      In short:
       1. The consumer flush_to_ldisc is on to remove the head tty_buffer.
       2. The producer adds a number of bytes, so that a new tty_buffer must
      	be allocated and added by __tty_buffer_request_room.
       3. The consumer removes the head tty_buffer element, without handling
      	newly committed data.
      
      Detailed example:
       * Initial buffer:
         * Head, Tail -> 0: used=250; commit=250; read=240; next=NULL
       * Consumer: ''flush_to_ldisc''
         * consumed 10 Byte
         * buffer:
           * Head, Tail -> 0: used=250; commit=250; read=250; next=NULL
      {{{
      		count = head->commit - head->read;	// count = 0
      		if (!count) {				// enter
      			// INTERRUPTED BY PRODUCER ->
      			if (head->next == NULL)
      				break;
      			buf->head = head->next;
      			tty_buffer_free(port, head);
      			continue;
      		}
      }}}
       * Producer: tty_insert_flip_... 10 bytes + tty_flip_buffer_push
         * buffer:
           * Head, Tail -> 0: used=250; commit=250; read=250; next=NULL
         * added 6 bytes: head-element filled to maximum.
           * buffer:
             * Head, Tail -> 0: used=256; commit=250; read=250; next=NULL
         * added 4 bytes: __tty_buffer_request_room is called
           * buffer:
             * Head -> 0: used=256; commit=256; read=250; next=1
             * Tail -> 1: used=4; commit=0; read=250 next=NULL
         * push (tty_flip_buffer_push)
           * buffer:
             * Head -> 0: used=256; commit=256; read=250; next=1
             * Tail -> 1: used=4; commit=4; read=250 next=NULL
       * Consumer
      {{{
      		count = head->commit - head->read;
      		if (!count) {
      			// INTERRUPTED BY PRODUCER <-
      			if (head->next == NULL)		// -> no break
      				break;
      			buf->head = head->next;
      			tty_buffer_free(port, head);
      			// ERROR: tty_buffer head freed -> 6 bytes lost
      			continue;
      		}
      }}}
      
      This patch reintroduces a spin_lock to protect this case. Perhaps later
      a lock-less solution could be found.
      Signed-off-by: NManfred Schlaegl <manfred.schlaegl@gmx.at>
      Cc: stable <stable@vger.kernel.org> # 3.11
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a20dbd6
    • R
      of/irq: do irq resolution in platform_get_irq · 9ec36caf
      Rob Herring 提交于
      Currently we get the following kind of errors if we try to use interrupt
      phandles to irqchips that have not yet initialized:
      
      irq: no irq domain found for /ocp/pinmux@48002030 !
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
      (show_stack+0x14/0x1c)
      (dump_stack+0x6c/0xa0)
      (warn_slowpath_common+0x64/0x84)
      (warn_slowpath_null+0x1c/0x24)
      (of_device_alloc+0x144/0x184)
      (of_platform_device_create_pdata+0x44/0x9c)
      (of_platform_bus_create+0xd0/0x170)
      (of_platform_bus_create+0x12c/0x170)
      (of_platform_populate+0x60/0x98)
      
      This is because we're wrongly trying to populate resources that are not
      yet available. It's perfectly valid to create irqchips dynamically, so
      let's fix up the issue by resolving the interrupt resources when
      platform_get_irq is called.
      
      And then we also need to accept the fact that some irqdomains do not
      exist that early on, and only get initialized later on. So we can
      make the current WARN_ON into just into a pr_debug().
      
      We still attempt to populate irq resources when we create the devices.
      This allows current drivers which don't use platform_get_irq to continue
      to function. Once all drivers are fixed, this code can be removed.
      Suggested-by: NRussell King <linux@arm.linux.org.uk>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Cc: stable@vger.kernel.org # v3.10+
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      9ec36caf
    • G
      phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY · 2b97789f
      Grygorii Strashko 提交于
      This fixes a regression on Keystone 2 platforms caused by patch
      57303488
      "usb: dwc3: adapt dwc3 core to use Generic PHY Framework" which adds
      optional support of generic phy in DWC3 core.
      
      On Keystone 2 platforms the USB is not working now because
      CONFIG_GENERIC_PHY isn't set and, as result, Generic PHY APIs stubs
      return -ENOSYS always. The log shows:
       dwc3 2690000.dwc3: failed to initialize core
       dwc3: probe of 2690000.dwc3 failed with error -38
      
      Hence, fix it by making NULL a valid phy reference in Generic PHY
      APIs stubs in the same way as it was done by the patch
      04c2faca "drivers: phy: Make NULL
      a valid phy reference".
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b97789f
  4. 24 4月, 2014 1 次提交
  5. 20 4月, 2014 1 次提交
    • H
      Input: serio - add firmware_id sysfs attribute · 0456c66f
      Hans de Goede 提交于
      serio devices exposed via platform firmware interfaces such as ACPI may
      provide additional identifying information of use to userspace.
      
      We don't associate the serio devices with the firmware device (we don't
      set it as parent), so there's no way for userspace to make use of this
      information.
      
      We cannot change the parent for serio devices instantiated though a
      firmware interface as that would break suspend / resume ordering.
      
      Therefore this patch adds a new firmware_id sysfs attribute so that
      userspace can get a string from there with any additional identifying
      information the firmware interface may provide.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      0456c66f
  6. 19 4月, 2014 3 次提交
  7. 18 4月, 2014 5 次提交
    • T
      regulator: core: Return error in get optional stub · df7926ff
      Tim Kryger 提交于
      Drivers that call regulator_get_optional are tolerant to the absence of
      that regulator.  By modifying the value returned from the stub function
      to match that seen when a regulator isn't present, callers can wrap the
      regulator logic with an IS_ERR based conditional even if they happen to
      call regulator_is_supported_voltage.  This improves efficiency as well
      as eliminates the possibility for a very subtle bug.
      Signed-off-by: NTim Kryger <tim.kryger@linaro.org>
      Reviewed-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      df7926ff
    • A
      of: add empty of_find_node_by_path() for !OF · 20cd477c
      Alexander Shiyan 提交于
      Add an empty version of of_find_node_by_path().
      This fixes following build error for asoc tree:
      sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe':
      sound/soc/fsl/fsl_ssi.c:1471:2: error: implicit declaration of function 'of_find_node_by_path' [-Werror=implicit-function-declaration]
        sprop = of_get_property(of_find_node_by_path("/"), "compatible", NULL);
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
      Signed-off-by: NRob Herring <robh@kernel.org>
      20cd477c
    • T
      genirq: Allow forcing cpu affinity of interrupts · 01f8fa4f
      Thomas Gleixner 提交于
      The current implementation of irq_set_affinity() refuses rightfully to
      route an interrupt to an offline cpu.
      
      But there is a special case, where this is actually desired. Some of
      the ARM SoCs have per cpu timers which require setting the affinity
      during cpu startup where the cpu is not yet in the online mask.
      
      If we can't do that, then the local timer interrupt for the about to
      become online cpu is routed to some random online cpu.
      
      The developers of the affected machines tried to work around that
      issue, but that results in a massive mess in that timer code.
      
      We have a yet unused argument in the set_affinity callbacks of the irq
      chips, which I added back then for a similar reason. It was never
      required so it got not used. But I'm happy that I never removed it.
      
      That allows us to implement a sane handling of the above scenario. So
      the affected SoC drivers can add the required force handling to their
      interrupt chip, switch the timer code to irq_force_affinity() and
      things just work.
      
      This does not affect any existing user of irq_set_affinity().
      
      Tagged for stable to allow a simple fix of the affected SoC clock
      event drivers.
      Reported-and-tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Tomasz Figa <t.figa@samsung.com>,
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: linux-arm-kernel@lists.infradead.org,
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      01f8fa4f
    • C
      ipmi: boolify some things · 7aefac26
      Corey Minyard 提交于
      Convert some ints to bools.
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7aefac26
    • C
      ipmi: Turn off all activity on an idle ipmi interface · 89986496
      Corey Minyard 提交于
      The IPMI driver would wake up periodically looking for events and
      watchdog pretimeouts.  If there is nothing waiting for these events,
      it's really kind of pointless to be checking for them.  So modify the
      driver so the message handler can pass down if it needs the lower layer
      to be waiting for these.  Modify the system interface lower layer to
      turn off all timer and thread activity if the upper layer doesn't need
      anything and it is not currently handling messages.  And modify the
      message handler to not restart the timer if its timer is not needed.
      
      The timers and kthread will still be enabled if:
       - the SI interface is handling a message.
       - a user has enabled watching for events.
       - the IPMI watchdog timer is in use (since it uses pretimeouts).
       - the message handler is waiting on a remote response.
       - a user has registered to receive commands.
      
      This mostly affects interfaces without interrupts.  Interfaces with
      interrupts already don't use CPU in the system interface when the
      interface is idle.
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      89986496
  8. 17 4月, 2014 5 次提交
  9. 16 4月, 2014 1 次提交
    • I
      x86: Remove the PCI reboot method from the default chain · 5be44a6f
      Ingo Molnar 提交于
      Steve reported a reboot hang and bisected it back to this commit:
      
        a4f1987e x86, reboot: Add EFI and CF9 reboot methods into the default list
      
      He heroically tested all reboot methods and found the following:
      
        reboot=t       # triple fault                  ok
        reboot=k       # keyboard ctrl                 FAIL
        reboot=b       # BIOS                          ok
        reboot=a       # ACPI                          FAIL
        reboot=e       # EFI                           FAIL   [system has no EFI]
        reboot=p       # PCI 0xcf9                     FAIL
      
      And I think it's pretty obvious that we should only try PCI 0xcf9 as a
      last resort - if at all.
      
      The other observation is that (on this box) we should never try
      the PCI reboot method, but close with either the 'triple fault'
      or the 'BIOS' (terminal!) reboot methods.
      
      Thirdly, CF9_COND is a total misnomer - it should be something like
      CF9_SAFE or CF9_CAREFUL, and 'CF9' should be 'CF9_FORCE' ...
      
      So this patch fixes the worst problems:
      
       - it orders the actual reboot logic to follow the reboot ordering
         pattern - it was in a pretty random order before for no good
         reason.
      
       - it fixes the CF9 misnomers and uses BOOT_CF9_FORCE and
         BOOT_CF9_SAFE flags to make the code more obvious.
      
       - it tries the BIOS reboot method before the PCI reboot method.
         (Since 'BIOS' is a terminal reboot method resulting in a hang
          if it does not work, this is essentially equivalent to removing
          the PCI reboot method from the default reboot chain.)
      
       - just for the miraculous possibility of terminal (resulting
         in hang) reboot methods of triple fault or BIOS returning
         without having done their job, there's an ordering between
         them as well.
      Reported-and-bisected-and-tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Li Aubrey <aubrey.li@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Link: http://lkml.kernel.org/r/20140404064120.GB11877@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5be44a6f
  10. 15 4月, 2014 1 次提交
    • D
      net: filter: seccomp: fix wrong decoding of BPF_S_ANC_SECCOMP_LD_W · 8c482cdc
      Daniel Borkmann 提交于
      While reviewing seccomp code, we found that BPF_S_ANC_SECCOMP_LD_W has
      been wrongly decoded by commit a8fc9277 ("sk-filter: Add ability to
      get socket filter program (v2)") into the opcode BPF_LD|BPF_B|BPF_ABS
      although it should have been decoded as BPF_LD|BPF_W|BPF_ABS.
      
      In practice, this should not have much side-effect though, as such
      conversion is/was being done through prctl(2) PR_SET_SECCOMP. Reverse
      operation PR_GET_SECCOMP will only return the current seccomp mode, but
      not the filter itself. Since the transition to the new BPF infrastructure,
      it's also not used anymore, so we can simply remove this as it's
      unreachable.
      
      Fixes: a8fc9277 ("sk-filter: Add ability to get socket filter program (v2)")
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c482cdc
  11. 12 4月, 2014 1 次提交
    • D
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller 提交于
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      676d2369
  12. 11 4月, 2014 7 次提交
  13. 10 4月, 2014 4 次提交
    • J
      block: fix regression with block enabled tagging · 360f92c2
      Jens Axboe 提交于
      Martin reported that his test system would not boot with
      current git, it oopsed with this:
      
      BUG: unable to handle kernel paging request at ffff88046c6c9e80
      IP: [<ffffffff812971e0>] blk_queue_start_tag+0x90/0x150
      PGD 1ddf067 PUD 1de2067 PMD 47fc7d067 PTE 800000046c6c9060
      Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
      Modules linked in: sd_mod lpfc(+) scsi_transport_fc scsi_tgt oracleasm
      rpcsec_gss_krb5 ipv6 igb dca i2c_algo_bit i2c_core hwmon
      CPU: 3 PID: 87 Comm: kworker/u17:1 Not tainted 3.14.0+ #246
      Hardware name: Supermicro X9DRX+-F/X9DRX+-F, BIOS 3.00 07/09/2013
      Workqueue: events_unbound async_run_entry_fn
      task: ffff8802743c2150 ti: ffff880273d02000 task.ti: ffff880273d02000
      RIP: 0010:[<ffffffff812971e0>]  [<ffffffff812971e0>]
      blk_queue_start_tag+0x90/0x150
      RSP: 0018:ffff880273d03a58  EFLAGS: 00010092
      RAX: ffff88046c6c9e78 RBX: ffff880077208e78 RCX: 00000000fffc8da6
      RDX: 00000000fffc186d RSI: 0000000000000009 RDI: 00000000fffc8d9d
      RBP: ffff880273d03a88 R08: 0000000000000001 R09: ffff8800021c2410
      R10: 0000000000000005 R11: 0000000000015b30 R12: ffff88046c5bb8a0
      R13: ffff88046c5c0890 R14: 000000000000001e R15: 000000000000001e
      FS:  0000000000000000(0000) GS:ffff880277b00000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffff88046c6c9e80 CR3: 00000000018f6000 CR4: 00000000000407e0
      Stack:
       ffff880273d03a98 ffff880474b18800 0000000000000000 ffff880474157000
       ffff88046c5c0890 ffff880077208e78 ffff880273d03ae8 ffffffff813b9e62
       ffff880200000010 ffff880474b18968 ffff880474b18848 ffff88046c5c0cd8
      Call Trace:
       [<ffffffff813b9e62>] scsi_request_fn+0xf2/0x510
       [<ffffffff81293167>] __blk_run_queue+0x37/0x50
       [<ffffffff8129ac43>] blk_execute_rq_nowait+0xb3/0x130
       [<ffffffff8129ad24>] blk_execute_rq+0x64/0xf0
       [<ffffffff8108d2b0>] ? bit_waitqueue+0xd0/0xd0
       [<ffffffff813bba35>] scsi_execute+0xe5/0x180
       [<ffffffff813bbe4a>] scsi_execute_req_flags+0x9a/0x110
       [<ffffffffa01b1304>] sd_spinup_disk+0x94/0x460 [sd_mod]
       [<ffffffff81160000>] ? __unmap_hugepage_range+0x200/0x2f0
       [<ffffffffa01b2b9a>] sd_revalidate_disk+0xaa/0x3f0 [sd_mod]
       [<ffffffffa01b2fb8>] sd_probe_async+0xd8/0x200 [sd_mod]
       [<ffffffff8107703f>] async_run_entry_fn+0x3f/0x140
       [<ffffffff8106a1c5>] process_one_work+0x175/0x410
       [<ffffffff8106b373>] worker_thread+0x123/0x400
       [<ffffffff8106b250>] ? manage_workers+0x160/0x160
       [<ffffffff8107104e>] kthread+0xce/0xf0
       [<ffffffff81070f80>] ? kthread_freezable_should_stop+0x70/0x70
       [<ffffffff815f0bac>] ret_from_fork+0x7c/0xb0
       [<ffffffff81070f80>] ? kthread_freezable_should_stop+0x70/0x70
      Code: 48 0f ab 11 72 db 48 81 4b 40 00 00 10 00 89 83 08 01 00 00 48 89
      df 49 8b 04 24 48 89 1c d0 e8 f7 a8 ff ff 49 8b 85 28 05 00 00 <48> 89
      58 08 48 89 03 49 8d 85 28 05 00 00 48 89 43 08 49 89 9d
      RIP  [<ffffffff812971e0>] blk_queue_start_tag+0x90/0x150
       RSP <ffff880273d03a58>
      CR2: ffff88046c6c9e80
      
      Martin bisected and found this to be the problem patch;
      
      	commit 6d113398
      	Author: Jan Kara <jack@suse.cz>
      	Date:   Mon Feb 24 16:39:54 2014 +0100
      
      	    block: Stop abusing rq->csd.list in blk-softirq
      
      and the problem was immediately apparent. The patch states that
      it is safe to reuse queuelist at completion time, since it is
      no longer used. However, that is not true if a device is using
      block enabled tagging. If that is the case, then the queuelist
      is reused to keep track of busy tags. If a device also ended
      up using softirq completions, we'd reuse ->queuelist for the
      IPI handling while block tagging was still using it. Boom.
      
      Fix this by adding a new ipi_list list head, and share the
      memory used with the request hash table. The hash table is
      never used after the request is moved to the dispatch list,
      which happens long before any potential completion of the
      request. Add a new request bit for this, so we don't have
      cases that check rq->hash while it could potentially have
      been reused for the IPI completion.
      Reported-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Tested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      360f92c2
    • M
      tracing: Fix anonymous unions in struct ftrace_event_call · abb43f69
      Mathieu Desnoyers 提交于
      gcc <= 4.5.x has significant limitations with respect to initialization
      of anonymous unions within structures. They need to be surrounded by
      brackets, _and_ they need to be initialized in the same order in which
      they appear in the structure declaration.
      
      Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
      Link: http://lkml.kernel.org/r/1397077568-3156-1-git-send-email-mathieu.desnoyers@efficios.comSigned-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      abb43f69
    • B
      x86: LLVMLinux: Fix "incomplete type const struct x86cpu_device_id" · c4586256
      Behan Webster 提交于
      Similar to the fix in 40413dcb
      
      MODULE_DEVICE_TABLE(x86cpu, ...) expects the struct to be called struct
      x86cpu_device_id, and not struct x86_cpu_id which is what is used in the rest
      of the kernel code.  Although gcc seems to ignore this error, clang fails
      without this define to fix the name.
      
      Code from drivers/thermal/x86_pkg_temp_thermal.c
      static const struct x86_cpu_id __initconst pkg_temp_thermal_ids[] = { ... };
      MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids);
      
      Error from clang:
      drivers/thermal/x86_pkg_temp_thermal.c:577:1: error: variable has
            incomplete type 'const struct x86cpu_device_id'
      MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids);
      ^
      include/linux/module.h:145:3: note: expanded from macro
            'MODULE_DEVICE_TABLE'
        MODULE_GENERIC_TABLE(type##_device, name)
        ^
      include/linux/module.h:87:32: note: expanded from macro
            'MODULE_GENERIC_TABLE'
      extern const struct gtype##_id __mod_##gtype##_table            \
                                     ^
      <scratch space>:143:1: note: expanded from here
      __mod_x86cpu_device_table
      ^
      drivers/thermal/x86_pkg_temp_thermal.c:577:1: note: forward declaration of
            'struct x86cpu_device_id'
      include/linux/module.h:145:3: note: expanded from macro
            'MODULE_DEVICE_TABLE'
        MODULE_GENERIC_TABLE(type##_device, name)
        ^
      include/linux/module.h:87:21: note: expanded from macro
            'MODULE_GENERIC_TABLE'
      extern const struct gtype##_id __mod_##gtype##_table            \
                          ^
      <scratch space>:141:1: note: expanded from here
      x86cpu_device_id
      ^
      1 error generated.
      Signed-off-by: NBehan Webster <behanw@converseincode.com>
      Signed-off-by: NJan-Simon Möller <dl9pf@gmx.de>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4586256
    • M
      LLVMLinux: Add support for clang to compiler.h and new compiler-clang.h · 565cbdc2
      Mark Charlebois 提交于
      Add a compiler-clang.h file to add specific macros needed for compiling the
      kernel with clang.
      
      Initially the only override required is the macro for silencing the
      compiler for a purposefully uninintialized variable.
      
      Author: Mark Charlebois <charlebm@gmail.com>
      Signed-off-by: NMark Charlebois <charlebm@gmail.com>
      Signed-off-by: NBehan Webster <behanw@converseincode.com>
      565cbdc2
  14. 09 4月, 2014 4 次提交