1. 28 5月, 2014 2 次提交
  2. 04 5月, 2014 2 次提交
  3. 29 4月, 2014 3 次提交
  4. 25 4月, 2014 2 次提交
    • 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
    • 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
  5. 24 4月, 2014 2 次提交
  6. 23 4月, 2014 6 次提交
  7. 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
  8. 19 4月, 2014 3 次提交
  9. 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
  10. 17 4月, 2014 5 次提交
  11. 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
  12. 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
  13. 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
  14. 11 4月, 2014 6 次提交