1. 18 12月, 2013 4 次提交
    • J
      serial: amba-pl011: use port lock to guard control register access · fe433907
      Jon Medhurst 提交于
      When the pl011 is being used for a console, pl011_console_write forces
      the control register (CR) to enable the UART for transmission and then
      restores this to the original value afterwards. It does this while
      holding the port lock.
      
      Unfortunately, when the uart is started or shutdown - say in response to
      userland using the serial device for a terminal - then this updates the
      control register without any locking.
      
      This means we can have
      
        pl011_console_write   Save CR
        pl011_startup         Initialise CR, e.g. enable receive
        pl011_console_write   Restore old CR with receive not enabled
      
      this result is a serial port which doesn't respond to any input.
      
      A similar race in reverse could happen when the device is shutdown.
      
      We can fix these problems by taking the port lock when updating CR.
      Signed-off-by: NJon Medhurst <tixy@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe433907
    • G
      Revert "serial: pl011: use DMA RX polling by default" · 8f898bfd
      Greg Kroah-Hartman 提交于
      This reverts commit 17438217 on request
      of Linus Walleij:
      	Greg can you please drop or revert
      	commit 17438217
      	"serial: pl011: use DMA RX polling by default"
      	from the TTY tree until this has been sorted out?
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f898bfd
    • P
      n_tty: Fix buffer overruns with larger-than-4k pastes · 4d0ed182
      Peter Hurley 提交于
      readline() inadvertently triggers an error recovery path when
      pastes larger than 4k overrun the line discipline buffer. The
      error recovery path discards input when the line discipline buffer
      is full and operating in canonical mode and no newline has been
      received. Because readline() changes the termios to non-canonical
      mode to read the line char-by-char, the line discipline buffer
      can become full, and then when readline() restores termios back
      to canonical mode for the caller, the now-full line discipline
      buffer triggers the error recovery.
      
      When changing termios from non-canon to canon mode and the read
      buffer contains data, simulate an EOF push _without_ the
      DISABLED_CHAR in the read buffer.
      
      Importantly for the readline() problem, the termios can be
      changed back to non-canonical mode without changes to the read
      buffer occurring; ie., as if the previous termios change had not
      happened (as long as no intervening read took place).
      
      Preserve existing userspace behavior which allows '\0's already
      received in non-canon mode to be read as '\0's in canon mode
      (rather than trigger add'l EOF pushes or an actual EOF).
      
      Patch based on original proposal and discussion here
      https://bugzilla.kernel.org/show_bug.cgi?id=55991
      by Stas Sergeev <stsp@users.sourceforge.net>
      Reported-by: NMargarita Manterola <margamanterola@gmail.com>
      Cc: Maximiliano Curia <maxy@gnuservers.com.ar>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
      Acked-by: NStas Sergeev <stsp@users.sourceforge.net>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d0ed182
    • A
      serial: clps711x: Driver refactor · bc000245
      Alexander Shiyan 提交于
      This is a complex patch for refactoring CLPS711X serial driver.
      Major changes:
      - Eliminate <mach/hardware.h> usage.
      - Devicetree support.
      Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc000245
  2. 16 12月, 2013 2 次提交
    • M
      null_blk: mem garbage on NUMA systems during init · 57053d8c
      Matias Bjorling 提交于
      For NUMA systems, initializing the blk-mq layer and using per node hctx.
      We initialize submit queues to 1, while blk-mq nr_hw_queues is
      initialized to the number of NUMA nodes.
      
      This makes the null_init_hctx function overwrite memory outside of what
      it allocated.  In my case it lead to writing garbage into struct
      request_queue's mq_map.
      Signed-off-by: NMatias Bjorling <m@bjorling.me>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      57053d8c
    • S
      radeon_pm: fix oops in hwmon_attributes_visible() and radeon_hwmon_show_temp_thresh() · e4158f1b
      Sergey Senozhatsky 提交于
      Since commit ec39f64b ("drm/radeon/dpm: Convert to use
      devm_hwmon_register_with_groups") radeon_hwmon_init() is using
      hwmon_device_register_with_groups(), which sets `rdev' as a device
      private driver_data, while hwmon_attributes_visible() and
      radeon_hwmon_show_temp_thresh() are still waiting for `drm_device'.
      
      Fix them by using dev_get_drvdata(), in order to avoid this oops:
      
        BUG: unable to handle kernel paging request at 0000000000001e28
        IP: [<ffffffffa02ae8b4>] hwmon_attributes_visible+0x18/0x3d [radeon]
        PGD 15057e067 PUD 151a8e067 PMD 0
        Oops: 0000 [#1] PREEMPT SMP
        Call Trace:
          internal_create_group+0x114/0x1d9
          sysfs_create_group+0xe/0x10
          sysfs_create_groups+0x22/0x5f
          device_add+0x34f/0x501
          device_register+0x15/0x18
          hwmon_device_register_with_groups+0xb5/0xed
          radeon_hwmon_init+0x56/0x7c [radeon]
          radeon_pm_init+0x134/0x7e5 [radeon]
          radeon_modeset_init+0x75f/0x8ed [radeon]
          radeon_driver_load_kms+0xc6/0x187 [radeon]
          drm_dev_register+0xf9/0x1b4 [drm]
          drm_get_pci_dev+0x98/0x129 [drm]
          radeon_pci_probe+0xa3/0xac [radeon]
          pci_device_probe+0x6e/0xcf
          driver_probe_device+0x98/0x1c4
          __driver_attach+0x5c/0x7e
          bus_for_each_dev+0x7b/0x85
          driver_attach+0x19/0x1b
          bus_add_driver+0x104/0x1ce
          driver_register+0x89/0xc5
          __pci_register_driver+0x58/0x5b
          drm_pci_init+0x86/0xea [drm]
          radeon_init+0x97/0x1000 [radeon]
          do_one_initcall+0x7f/0x117
          load_module+0x1583/0x1bb4
          SyS_init_module+0xa0/0xaf
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Alexander Deucher <Alexander.Deucher@amd.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e4158f1b
  3. 15 12月, 2013 2 次提交
  4. 14 12月, 2013 2 次提交
    • J
      dm array: fix a reference counting bug in shadow_ablock · ed9571f0
      Joe Thornber 提交于
      An old array block could have its reference count decremented below
      zero when it is being replaced in the btree by a new array block.
      
      The fix is to increment the old ablock's reference count just before
      inserting a new ablock into the btree.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 3.9+
      ed9571f0
    • J
      dm space map: disallow decrementing a reference count below zero · 5b564d80
      Joe Thornber 提交于
      The old behaviour, returning -EINVAL if a ref_count of 0 would be
      decremented, was removed in commit f722063e ("dm space map: optimise
      sm_ll_dec and sm_ll_inc").  To fix this regression we return an error
      code from the mutator function pointer passed to sm_ll_mutate() and have
      dec_ref_count() return -EINVAL if the old ref_count is 0.
      
      Add a DMERR to reflect the potential seriousness of this error.
      
      Also, add missing dm_tm_unlock() to sm_ll_mutate()'s error path.
      
      With this fix the following dmts regression test now passes:
       dmtest run --suite cache -n /metadata_use_kernel/
      
      The next patch fixes the higher-level dm-array code that exposed this
      regression.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 3.12+
      5b564d80
  5. 13 12月, 2013 14 次提交
  6. 12 12月, 2013 13 次提交
  7. 11 12月, 2013 3 次提交