1. 26 Mar, 2012 1 commit
  2. 23 Mar, 2012 2 commits
  3. 21 Mar, 2012 2 commits
    • Tarun Kanti DebBarma's avatar
      gpio/omap: fix redundant decoding of gpio offset · 7fcca715
      Tarun Kanti DebBarma authored
      In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
      un-necessary operation to compute gpio mask. The gpio offset passed
      to gpio_get() is sufficient to do that.
      
      Here is Russell's original comment:
      Can someone explain to me this:
      
      static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
      {
             void __iomem *reg = bank->base + bank->regs->datain;
      
             return (__raw_readl(reg) & GPIO_BIT(bank, gpio)) != 0;
      }
      
      static int gpio_get(struct gpio_chip *chip, unsigned offset)
      {
             struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
             void __iomem *reg = bank->base;
             int gpio = chip->base + offset;
             u32 mask = GPIO_BIT(bank, gpio);
      
             if (gpio_is_input(bank, mask))
                     return _get_gpio_datain(bank, gpio);
             else
                     return _get_gpio_dataout(bank, gpio);
      }
      
      Given that bank->width on OMAP is either 32 or 16, and GPIO numbers for
      any GPIO chip are always aligned to 32 or 16, why does this code bother
      adding the chips base gpio number and then modulo the width?
      
      Surely this means if - for argument sake - you registered a GPIO chip
      with 8 lines followed by one with 16 lines, GPIO0..7 would be chip 0
      bit 0..7, GPIO8..15 would be chip 1 bit 8..15, GPIO16..23 would be
      chip 1 bit 0..7.
      
      However, if you registered a GPIO chip with 16 lines first, it would
      mean GPIO0..15 would be chip 0 bit 0..15, and GPIO16..31 would be
      chip 1 bit 0..15.
      
      Surely this kind of behaviour is not intended?
      
      Is there a reason why the bitmask can't just be (1 << offset) where
      offset is passed into these functions as GPIO number - chip->base ?
      Reported-by: default avatarRussell King - ARM Linux <linux@arm.linux.org.uk>
      Signed-off-by: default avatarTarun Kanti DebBarma <tarun.kanti@ti.com>
      Reviewed-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      7fcca715
    • Tarun Kanti DebBarma's avatar
      gpio/omap: fix incorrect update to context.irqenable1 · 2a900eb7
      Tarun Kanti DebBarma authored
      In _enable_gpio_irqbank() when bank->regs->set_irqenable is TRUE,
      gpio_mask can be directly set by writing to set_irqenable register
      without overwriting current value. In order to ensure the same is
      stored in context.irqenable1, we must avoid overwriting it with
      gpio_mask at the end of the function. Instead, update irqenable1
      appropriately by OR'ing with gpio_mask.
      For the case where bank->regs->set_irqenable is FALSE, irqenable1
      can be directly overwritten with 'l' which holds correct computed
      value.
              if (bank->regs->set_irqenable) {
                      reg += bank->regs->set_irqenable;
                      l = gpio_mask;
              } else {
                      reg += bank->regs->irqenable;
                      l = __raw_readl(reg);
                      if (bank->regs->irqenable_inv)
                              l &= ~gpio_mask;
                      else
                              l |= gpio_mask;
              }
      
      Make similar change for _disable_gpio_irqbank().
      Signed-off-by: default avatarTarun Kanti DebBarma <tarun.kanti@ti.com>
      Reviewed-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      2a900eb7
  4. 20 Mar, 2012 5 commits
  5. 19 Mar, 2012 1 commit
  6. 12 Mar, 2012 10 commits
    • Sekhar Nori's avatar
      gpio/davinci: fix enabling unbanked GPIO IRQs · 81b279d8
      Sekhar Nori authored
      Unbanked GPIO IRQ handling code made a copy of just
      the irq_chip structure for GPIO IRQ lines which caused
      problems after the generic IRQ chip conversion because
      there was no valid irq_chip_type structure with the
      right "regs" populated. irq_gc_mask_set_bit() was
      therefore accessing random addresses.
      
      Fix it by making a copy of irq_chip_type structure
      instead. This will ensure sane register offsets.
      
      Cc: <stable@vger.kernel.org> # v3.0.x+
      Reported-by: default avatarJon Povey <Jon.Povey@racelogic.co.uk>
      Tested-by: default avatarJon Povey <Jon.Povey@racelogic.co.uk>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      81b279d8
    • Sekhar Nori's avatar
      gpio/davinci: fix oops on unbanked gpio irq request · ab2dde99
      Sekhar Nori authored
      Unbanked GPIO irq setup code was overwriting chip_data leading
      to the following oops on request_irq()
      
      Unable to handle kernel paging request at virtual address febfffff
      pgd = c22dc000
      [febfffff] *pgd=00000000
      Internal error: Oops: 801 [#1] PREEMPT
      Modules linked in: mcu(+) edmak irqk cmemk
      CPU: 0    Not tainted  (3.0.0-rc7+ #93)
      PC is at irq_gc_mask_set_bit+0x68/0x7c
      LR is at vprintk+0x22c/0x484
      pc : [<c0080c0c>]    lr : [<c00457e0>]    psr: 60000093
      sp : c33e3ba0  ip : c33e3af0  fp : c33e3bc4
      r10: c04555bc  r9 : c33d4340  r8 : 60000013
      r7 : 0000002d  r6 : c04555bc  r5 : fec67010  r4 : 00000000
      r3 : c04734c8  r2 : fec00000  r1 : ffffffff  r0 : 00000026
      Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 0005317f  Table: 822dc000  DAC: 00000015
      Process modprobe (pid: 526, stack limit = 0xc33e2270)
      Stack: (0xc33e3ba0 to 0xc33e4000)
      3ba0: 00000000 c007d3d4 c33e3bcc c04555bc c04555bc c33d4340 c33e3bdc c33e3bc8
      3bc0: c007f5f8 c0080bb4 00000000 c04555bc c33e3bf4 c33e3be0 c007f654 c007f5c0
      3be0: 00000000 c04555bc c33e3c24 c33e3bf8 c007e6e8 c007f618 c01f2284 c0350af8
      3c00: c0405214 bf016c98 00000001 00000000 c33dc008 0000002d c33e3c54 c33e3c28
      3c20: c007e888 c007e408 00000001 c23ef880 c33dc000 00000000 c33dc080 c25caa00
      3c40: c0487498 bf017078 c33e3c94 c33e3c58 bf016b44 c007e7d4 bf017078 c33dc008
      3c60: c25caa08 c33dc008 c33e3c84 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08
      3c80: c0496d60 bf017484 c33e3ca4 c33e3c98 c022a698 bf01692c c33e3cd4 c33e3ca8
      3ca0: c01f5d88 c022a688 00000000 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08
      3cc0: c0496d60 00000000 c33e3cec c33e3cd8 c01f5f8c c01f5d10 00000000 c33e3cf0
      3ce0: c33e3d14 c33e3cf0 c01f5210 c01f5f58 c303cb48 c25ecf94 c25caa00 c25caa00
      3d00: c25caa34 c33e3dd8 c33e3d34 c33e3d18 c01f6044 c01f51b8 c0496d3c c25caa00
      3d20: c044e918 c33e3dd8 c33e3d44 c33e3d38 c01f4ff4 c01f5fcc c33e3d94 c33e3d48
      3d40: c01f3d10 c01f4fd8 00000000 c044e918 00000000 00000000 c01f52c0 c034d570
      3d60: c33e3d84 c33e3d70 c022bf84 c25caa00 00000000 c044e918 c33e3dd8 c25c2e00
      3d80: c0496d60 bf01763c c33e3db4 c33e3d98 c022b1a0 c01f384c c25caa00 c33e3dd8
      3da0: 00000000 c33e3dd8 c33e3dd4 c33e3db8 c022b27c c022b0e8 00000000 bf01763c
      3dc0: c0451c80 c33e3dd8 c33e3e34 c33e3dd8 bf016f60 c022b210 5f75636d 746e6f63
      3de0: 006c6f72 00000000 00000000 00000000 00000000 00000000 00000000 bf0174bc
      3e00: 00000000 00989680 00000000 00000020 c0451c80 c0451c80 bf0174dc c01f5eb0
      3e20: c33f0f00 bf0174dc c33e3e44 c33e3e38 c01f72f4 bf016e2c c33e3e74 c33e3e48
      3e40: c01f5d88 c01f72e4 00000000 c0451c80 c0451cb4 bf0174dc c01f5eb0 c33f0f00
      3e60: c0473100 00000000 c33e3e94 c33e3e78 c01f5f44 c01f5d10 00000000 c33e3e98
      3e80: bf0174dc c01f5eb0 c33e3ebc c33e3e98 c01f5534 c01f5ec0 c303c038 c3061c30
      3ea0: 00003cd8 00098258 bf0174dc c0462ac8 c33e3ecc c33e3ec0 c01f5bec c01f54dc
      3ec0: c33e3efc c33e3ed0 c01f4d30 c01f5bdc bf0173a0 c33e2000 00003cd8 00098258
      3ee0: bf0174dc c33e2000 c00301a4 bf019000 c33e3f1c c33e3f00 c01f6588 c01f4c8c
      3f00: 00003cd8 00098258 00000000 c33e2000 c33e3f2c c33e3f20 c01f777c c01f6524
      3f20: c33e3f3c c33e3f30 bf019014 c01f7740 c33e3f7c c33e3f40 c002f3ec bf019010
      3f40: 00000000 00003cd8 00098258 bf017518 00000000 00003cd8 00098258 bf017518
      3f60: 00000000 c00301a4 c33e2000 00000000 c33e3fa4 c33e3f80 c007b934 c002f3c4
      3f80: c00b307c c00b2f48 00003cd8 00000000 00000003 00000080 00000000 c33e3fa8
      3fa0: c0030020 c007b8b8 00003cd8 00000000 00098288 00003cd8 00098258 00098240
      3fc0: 00003cd8 00000000 00000003 00000080 00098008 00098028 00098288 00000001
      3fe0: be892998 be892988 00013d7c 40178740 60000010 00098288 09089041 00200845
      Backtrace:
      [<c0080ba4>] (irq_gc_mask_set_bit+0x0/0x7c) from [<c007f5f8>] (irq_enable+0x48/0x58)
       r6:c33d4340 r5:c04555bc r4:c04555bc
      [<c007f5b0>] (irq_enable+0x0/0x58) from [<c007f654>] (irq_startup+0x4c/0x54)
       r5:c04555bc r4:00000000
      [<c007f608>] (irq_startup+0x0/0x54) from [<c007e6e8>] (__setup_irq+0x2f0/0x3cc)
       r5:c04555bc r4:00000000
      [<c007e3f8>] (__setup_irq+0x0/0x3cc) from [<c007e888>] (request_threaded_irq+0xc4/0x110)
       r8:0000002d r7:c33dc008 r6:00000000 r5:00000001 r4:bf016c98
      [<c007e7c4>] (request_threaded_irq+0x0/0x110) from [<bf016b44>] (mcu_spi_probe+0x228/0x37c [mcu])
      [<bf01691c>] (mcu_spi_probe+0x0/0x37c [mcu]) from [<c022a698>] (spi_drv_probe+0x20/0x24)
      [<c022a678>] (spi_drv_probe+0x0/0x24) from [<c01f5d88>] (driver_probe_device+0x88/0x1b0)
      [<c01f5d00>] (driver_probe_device+0x0/0x1b0) from [<c01f5f8c>] (__device_attach+0x44/0x48)
      [<c01f5f48>] (__device_attach+0x0/0x48) from [<c01f5210>] (bus_for_each_drv+0x68/0x94)
       r5:c33e3cf0 r4:00000000
      [<c01f51a8>] (bus_for_each_drv+0x0/0x94) from [<c01f6044>] (device_attach+0x88/0xa0)
       r7:c33e3dd8 r6:c25caa34 r5:c25caa00 r4:c25caa00
      [<c01f5fbc>] (device_attach+0x0/0xa0) from [<c01f4ff4>] (bus_probe_device+0x2c/0x4c)
       r7:c33e3dd8 r6:c044e918 r5:c25caa00 r4:c0496d3c
      [<c01f4fc8>] (bus_probe_device+0x0/0x4c) from [<c01f3d10>] (device_add+0x4d4/0x648)
      [<c01f383c>] (device_add+0x0/0x648) from [<c022b1a0>] (spi_add_device+0xc8/0x128)
      [<c022b0d8>] (spi_add_device+0x0/0x128) from [<c022b27c>] (spi_new_device+0x7c/0xb4)
       r7:c33e3dd8 r6:00000000 r5:c33e3dd8 r4:c25caa00
      [<c022b200>] (spi_new_device+0x0/0xb4) from [<bf016f60>] (mcu_probe+0x144/0x224 [mcu])
       r7:c33e3dd8 r6:c0451c80 r5:bf01763c r4:00000000
      [<bf016e1c>] (mcu_probe+0x0/0x224 [mcu]) from [<c01f72f4>] (platform_drv_probe+0x20/0x24)
      [<c01f72d4>] (platform_drv_probe+0x0/0x24) from [<c01f5d88>] (driver_probe_device+0x88/0x1b0)
      [<c01f5d00>] (driver_probe_device+0x0/0x1b0) from [<c01f5f44>] (__driver_attach+0x94/0x98)
      [<c01f5eb0>] (__driver_attach+0x0/0x98) from [<c01f5534>] (bus_for_each_dev+0x68/0x94)
       r7:c01f5eb0 r6:bf0174dc r5:c33e3e98 r4:00000000
      [<c01f54cc>] (bus_for_each_dev+0x0/0x94) from [<c01f5bec>] (driver_attach+0x20/0x28)
       r7:c0462ac8 r6:bf0174dc r5:00098258 r4:00003cd8
      [<c01f5bcc>] (driver_attach+0x0/0x28) from [<c01f4d30>] (bus_add_driver+0xb4/0x258)
      [<c01f4c7c>] (bus_add_driver+0x0/0x258) from [<c01f6588>] (driver_register+0x74/0x158)
      [<c01f6514>] (driver_register+0x0/0x158) from [<c01f777c>] (platform_driver_register+0x4c/0x60)
       r7:c33e2000 r6:00000000 r5:00098258 r4:00003cd8
      [<c01f7730>] (platform_driver_register+0x0/0x60) from [<bf019014>] (mcu_init+0x14/0x20 [mcu])
      [<bf019000>] (mcu_init+0x0/0x20 [mcu]) from [<c002f3ec>] (do_one_initcall+0x38/0x170)
      [<c002f3b4>] (do_one_initcall+0x0/0x170) from [<c007b934>] (sys_init_module+0x8c/0x1a4)
      [<c007b8a8>] (sys_init_module+0x0/0x1a4) from [<c0030020>] (ret_fast_syscall+0x0/0x2c)
       r7:00000080 r6:00000003 r5:00000000 r4:00003cd8
      Code: e1844003 e585400c e596300c e5932064 (e7814002)
      
      Fix the issue.
      
      Cc: <stable@vger.kernel.org> # v3.0.x+
      Reported-by: default avatarJon Povey <Jon.Povey@racelogic.co.uk>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      ab2dde99
    • Tony Lindgren's avatar
      gpio/omap: Fix section warning for omap_mpuio_alloc_gc() · 8805f410
      Tony Lindgren authored
      Make omap_mpuio_alloc_gc() __devinit as omap_gpio_chip_init()
      is __devinit. Otherwise we get:
      
      WARNING: vmlinux.o(.devinit.text+0xa10): Section mismatch in reference
      from the function omap_gpio_chip_init() to the function .init.text:omap_mpuio_alloc_gc()
      The function __devinit omap_gpio_chip_init() references
      a function __init omap_mpuio_alloc_gc().
      If omap_mpuio_alloc_gc is only used by omap_gpio_chip_init then
      annotate omap_mpuio_alloc_gc with a matching annotation.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      8805f410
    • Arnd Bergmann's avatar
      ARM: tegra: export tegra_gpio_{en,dis}able · 691e06c0
      Arnd Bergmann authored
      These two functions are used in drivers that can be
      modules, so they need to be exported.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAlan Ott <alan@signal11.us>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      691e06c0
    • Bhupesh Sharma's avatar
      gpio/gpio-stmpe: Fix the value returned by _get_value routine · 7535b8be
      Bhupesh Sharma authored
      The present _get_value routine returns the contents of the GPIO Monitor Pin
      Status Register(GPMR) starting from the bit whose value is requested to BIT 0
      (irrelevant bits are replace by 0).
      
      For e.g. if we request the value of GPIO 6 in the earlier implementation the
      value returned is:
      
      	BIT6 followed by 6 0's
      
      whereas it should just return BIT6.
      
      This patch addresses the same.
      Signed-off-by: default avatarBhupesh Sharma <bhupesh.sharma@st.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@st.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      7535b8be
    • Stephen Warren's avatar
      Documentation/gpio.txt: Explain expected pinctrl interaction · 0dc665d4
      Stephen Warren authored
      Update gpio.txt based on recent discussions regarding interaction with the
      pinctrl subsystem.
      
      Previously, gpio_request() was described as explicitly not performing any
      required mux setup operations etc.
      
      Now, gpio_request() is explicitly as explicitly performing any required mux
      setup operations where possible. In the case it isn't, platform code is
      required to have set up any required muxing or other configuration prior to
      gpio_request() being called, in order to maintain the same semantics.
      
      This is achieved by gpiolib drivers calling e.g. pinctrl_request_gpio() in
      their .request() operation.
      
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: linux-doc@vger.kernel.org
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      0dc665d4
    • Roland Stigge's avatar
      GPIO: LPC32xx: Add output reading to GPO P3 · 46158aad
      Roland Stigge authored
      The chip offers the function to detect the current state of output of the GPO
      P3 pins. Useful for reading GPIO output state in Linux' GPIO API, e.g. via
      sysfs.
      
      Please note that this only reads back the currently programmed output state,
      not the actual electrical level in terms of a GPI function. Finally, GPO3 is
      still just an output.
      Signed-off-by: default avatarRoland Stigge <stigge@antcom.de>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      46158aad
    • Roland Stigge's avatar
      GPIO: LPC32xx: Fix missing bit selection mask · 8e5fb37b
      Roland Stigge authored
      Add missing mask to pin bit selection in gpio-lpc32xx.c
      (#define GPIO3_PIN_IN_SEL)
      Signed-off-by: default avatarRoland Stigge <stigge@antcom.de>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      8e5fb37b
    • Kevin Hilman's avatar
      gpio/omap: fix wakeups on level-triggered GPIOs · 68942edb
      Kevin Hilman authored
      While both level- and edge-triggered GPIOs are capable of generating
      interrupts, only edge-triggered GPIOs are capable of generating a
      module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.)
      
      In order to ensure that devices using level-triggered GPIOs as
      interrupts can also cause wakeups (e.g. from idle), this patch enables
      edge-triggering for wakeup-enabled, level-triggered GPIOs when a GPIO
      bank is runtime-suspended (which also happens during idle.)
      
      This fixes a problem found in GPMC-connected network cards with GPIO
      interrupts (e.g. smsc911x on Zoom3, Overo, ...) where network booting
      with NFSroot was very slow since the GPIO IRQs used by the NIC were
      not generating PRCM wakeups, and thus not waking the system from idle.
      NOTE: until v3.3, this boot-time problem was somewhat masked because
      the UART init prevented WFI during boot until the full serial driver
      was available.  Preventing WFI allowed regular GPIO interrupts to fire
      and this problem was not seen.  After the UART runtime PM cleanups, we
      no longer avoid WFI during boot, so GPIO IRQs that were not causing
      wakeups resulted in very slow IRQ response times.
      
      Tested on platforms using level-triggered GPIOs for network IRQs using
      the SMSC911x NIC: 3530/Overo and 3630/Zoom3.
      Reported-by: default avatarTony Lindgren <tony@atomide.com>
      Tested-by: default avatarTarun Kanti DebBarma <tarun.kanti@ti.com>
      Tested-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      68942edb
    • Grant Likely's avatar
      Merge tag 'v3.3-rc7' into gpio/next · e2aa4177
      Grant Likely authored
      Linux 3.3-rc7.  Merged into the gpio branch to pick up gpio bugfixes already
      in mainline before queueing up move v3.4 patches
      e2aa4177
  7. 10 Mar, 2012 4 commits
    • Linus Torvalds's avatar
      Linux 3.3-rc7 · fde7d904
      Linus Torvalds authored
      fde7d904
    • Al Viro's avatar
      aio: fix the "too late munmap()" race · c7b28555
      Al Viro authored
      Current code has put_ioctx() called asynchronously from aio_fput_routine();
      that's done *after* we have killed the request that used to pin ioctx,
      so there's nothing to stop io_destroy() waiting in wait_for_all_aios()
      from progressing.  As the result, we can end up with async call of
      put_ioctx() being the last one and possibly happening during exit_mmap()
      or elf_core_dump(), neither of which expects stray munmap() being done
      to them...
      
      We do need to prevent _freeing_ ioctx until aio_fput_routine() is done
      with that, but that's all we care about - neither io_destroy() nor
      exit_aio() will progress past wait_for_all_aios() until aio_fput_routine()
      does really_put_req(), so the ioctx teardown won't be done until then
      and we don't care about the contents of ioctx past that point.
      
      Since actual freeing of these suckers is RCU-delayed, we don't need to
      bump ioctx refcount when request goes into list for async removal.
      All we need is rcu_read_lock held just over the ->ctx_lock-protected
      area in aio_fput_routine().
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Acked-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c7b28555
    • Al Viro's avatar
      aio: fix io_setup/io_destroy race · 86b62a2c
      Al Viro authored
      Have ioctx_alloc() return an extra reference, so that caller would drop it
      on success and not bother with re-grabbing it on failure exit.  The current
      code is obviously broken - io_destroy() from another thread that managed
      to guess the address io_setup() would've returned would free ioctx right
      under us; gets especially interesting if aio_context_t * we pass to
      io_setup() points to PROT_READ mapping, so put_user() fails and we end
      up doing io_destroy() on kioctx another thread has just got freed...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      86b62a2c
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 86e06008
      Linus Torvalds authored
      Pull btrfs updates from Chris Mason:
       "I have two additional and btrfs fixes in my for-linus branch.  One is
        a casting error that leads to memory corruption on i386 during scrub,
        and the other fixes a corner case in the backref walking code (also
        triggered by scrub)."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: fix casting error in scrub reada code
        btrfs: fix locking issues in find_parent_nodes()
      86e06008
  8. 09 Mar, 2012 14 commits
  9. 08 Mar, 2012 1 commit