1. 28 9月, 2012 2 次提交
    • A
      USB: Fix race condition when removing host controllers · 0d00dc26
      Alan Stern 提交于
      This patch (as1607) fixes a race that can occur if a USB host
      controller is removed while a process is reading the
      /sys/kernel/debug/usb/devices file.
      
      The usb_device_read() routine uses the bus->root_hub pointer to
      determine whether or not the root hub is registered.  The is not a
      valid test, because the pointer is set before the root hub gets
      registered and remains set even after the root hub is unregistered and
      deallocated.  As a result, usb_device_read() or usb_device_dump() can
      access freed memory, causing an oops.
      
      The patch changes the test to use the hcd->rh_registered flag, which
      does get set and cleared at the appropriate times.  It also makes sure
      to hold the usb_bus_list_lock mutex while setting the flag, so that
      usb_device_read() will become aware of new root hubs as soon as they
      are registered.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NDon Zickus <dzickus@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d00dc26
    • J
      USB: ohci-at91: fix null pointer in ohci_hcd_at91_overcurrent_irq · 01bb6501
      Joachim Eastwood 提交于
      Fixes the following NULL pointer dereference:
      [    7.740000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
      [    7.810000] Unable to handle kernel NULL pointer dereference at virtual address 00000028
      [    7.810000] pgd = c3a38000
      [    7.810000] [00000028] *pgd=23a8c831, *pte=00000000, *ppte=00000000
      [    7.810000] Internal error: Oops: 17 [#1] PREEMPT ARM
      [    7.810000] Modules linked in: ohci_hcd(+) regmap_i2c snd_pcm usbcore snd_page_alloc at91_cf snd_timer pcmcia_rsrc snd soundcore gpio_keys regmap_spi pcmcia_core usb_common nls_base
      [    7.810000] CPU: 0    Not tainted  (3.6.0-rc6-mpa+ #264)
      [    7.810000] PC is at __gpio_to_irq+0x18/0x40
      [    7.810000] LR is at ohci_hcd_at91_overcurrent_irq+0x24/0xb4 [ohci_hcd]
      [    7.810000] pc : [<c01392d4>]    lr : [<bf08f694>]    psr: 40000093
      [    7.810000] sp : c3a11c40  ip : c3a11c50  fp : c3a11c4c
      [    7.810000] r10: 00000000  r9 : c02dcd6e  r8 : fefff400
      [    7.810000] r7 : 00000000  r6 : c02cc928  r5 : 00000030  r4 : c02dd168
      [    7.810000] r3 : c02e7350  r2 : ffffffea  r1 : c02cc928  r0 : 00000000
      [    7.810000] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [    7.810000] Control: c000717f  Table: 23a38000  DAC: 00000015
      [    7.810000] Process modprobe (pid: 285, stack limit = 0xc3a10270)
      [    7.810000] Stack: (0xc3a11c40 to 0xc3a12000)
      [    7.810000] 1c40: c3a11c6c c3a11c50 bf08f694 c01392cc c3a11c84 c2c38b00 c3806900 00000030
      [    7.810000] 1c60: c3a11ca4 c3a11c70 c0051264 bf08f680 c3a11cac c3a11c80 c003e764 c3806900
      [    7.810000] 1c80: c2c38b00 c02cb05c c02cb000 fefff400 c3806930 c3a11cf4 c3a11cbc c3a11ca8
      [    7.810000] 1ca0: c005142c c005123c c3806900 c3805a00 c3a11cd4 c3a11cc0 c0053f24 c00513e4
      [    7.810000] 1cc0: c3a11cf4 00000030 c3a11cec c3a11cd8 c005120c c0053e88 00000000 00000000
      [    7.810000] 1ce0: c3a11d1c c3a11cf0 c00124d0 c00511e0 01400000 00000001 00000012 00000000
      [    7.810000] 1d00: ffffffff c3a11d94 00000030 00000000 c3a11d34 c3a11d20 c005120c c0012438
      [    7.810000] 1d20: c001dac4 00000012 c3a11d4c c3a11d38 c0009b08 c00511e0 c00523fc 60000013
      [    7.810000] 1d40: c3a11d5c c3a11d50 c0008510 c0009ab4 c3a11ddc c3a11d60 c0008eb4 c00084f0
      [    7.810000] 1d60: 00000000 00000030 00000000 00000080 60000013 bf08f670 c3806900 c2c38b00
      [    7.810000] 1d80: 00000030 c3806930 00000000 c3a11ddc c3a11d88 c3a11da8 c0054190 c00523fc
      [    7.810000] 1da0: 60000013 ffffffff c3a11dec c3a11db8 00000000 c2c38b00 bf08f670 c3806900
      [    7.810000] 1dc0: 00000000 00000080 c02cc928 00000030 c3a11e0c c3a11de0 c0052764 c00520d8
      [    7.810000] 1de0: c3a11dfc 00000000 00000000 00000002 bf090f61 00000004 c02cc930 c02cc928
      [    7.810000] 1e00: c3a11e4c c3a11e10 bf090978 c005269c bf090f61 c02cc928 bf093000 c02dd170
      [    7.810000] 1e20: c3a11e3c c02cc930 c02cc930 bf0911d0 bf0911d0 bf093000 c3a10000 00000000
      [    7.810000] 1e40: c3a11e5c c3a11e50 c0155b7c bf090808 c3a11e7c c3a11e60 c0154690 c0155b6c
      [    7.810000] 1e60: c02cc930 c02cc964 bf0911d0 c3a11ea0 c3a11e9c c3a11e80 c015484c c01545e8
      [    7.810000] 1e80: 00000000 00000000 c01547e4 bf0911d0 c3a11ec4 c3a11ea0 c0152e58 c01547f4
      [    7.810000] 1ea0: c381b88c c384ab10 c2c10540 bf0911d0 00000000 c02d7518 c3a11ed4 c3a11ec8
      [    7.810000] 1ec0: c01544c0 c0152e0c c3a11efc c3a11ed8 c01536cc c01544b0 bf091075 c3a11ee8
      [    7.810000] 1ee0: bf049af0 bf09120c bf0911d0 00000000 c3a11f1c c3a11f00 c0154e9c c0153628
      [    7.810000] 1f00: bf049af0 bf09120c 000ae190 00000000 c3a11f2c c3a11f20 c0155f58 c0154e04
      [    7.810000] 1f20: c3a11f44 c3a11f30 bf093054 c0155f1c 00000000 00006a4f c3a11f7c c3a11f48
      [    7.810000] 1f40: c0008638 bf093010 bf09120c 000ae190 00000000 c00093c4 00006a4f bf09120c
      [    7.810000] 1f60: 000ae190 00000000 c00093c4 00000000 c3a11fa4 c3a11f80 c004fdc4 c000859c
      [    7.810000] 1f80: c3a11fa4 000ae190 00006a4f 00016eb8 000ad018 00000080 00000000 c3a11fa8
      [    7.810000] 1fa0: c0009260 c004fd58 00006a4f 00016eb8 000ae190 00006a4f 000ae100 00000000
      [    7.810000] 1fc0: 00006a4f 00016eb8 000ad018 00000080 000adba0 000ad208 00000000 000ad3d8
      [    7.810000] 1fe0: beaf7ae8 beaf7ad8 000172b8 b6e4e940 20000010 000ae190 00000000 00000000
      [    7.810000] Backtrace:
      [    7.810000] [<c01392bc>] (__gpio_to_irq+0x0/0x40) from [<bf08f694>] (ohci_hcd_at91_overcurrent_irq+0x24/0xb4 [ohci_hcd])
      [    7.810000] [<bf08f670>] (ohci_hcd_at91_overcurrent_irq+0x0/0xb4 [ohci_hcd]) from [<c0051264>] (handle_irq_event_percpu+0x38/0x1a8)
      [    7.810000]  r6:00000030 r5:c3806900 r4:c2c38b00
      [    7.810000] [<c005122c>] (handle_irq_event_percpu+0x0/0x1a8) from [<c005142c>] (handle_irq_event+0x58/0x7c)
      [    7.810000] [<c00513d4>] (handle_irq_event+0x0/0x7c) from [<c0053f24>] (handle_simple_irq+0xac/0xd8)
      [    7.810000]  r5:c3805a00 r4:c3806900
      [    7.810000] [<c0053e78>] (handle_simple_irq+0x0/0xd8) from [<c005120c>] (generic_handle_irq+0x3c/0x48)
      [    7.810000]  r4:00000030
      [    7.810000] [<c00511d0>] (generic_handle_irq+0x0/0x48) from [<c00124d0>] (gpio_irq_handler+0xa8/0xfc)
      [    7.810000]  r4:00000000
      [    7.810000] [<c0012428>] (gpio_irq_handler+0x0/0xfc) from [<c005120c>] (generic_handle_irq+0x3c/0x48)
      [    7.810000] [<c00511d0>] (generic_handle_irq+0x0/0x48) from [<c0009b08>] (handle_IRQ+0x64/0x88)
      [    7.810000]  r4:00000012
      [    7.810000] [<c0009aa4>] (handle_IRQ+0x0/0x88) from [<c0008510>] (at91_aic_handle_irq+0x30/0x38)
      [    7.810000]  r5:60000013 r4:c00523fc
      [    7.810000] [<c00084e0>] (at91_aic_handle_irq+0x0/0x38) from [<c0008eb4>] (__irq_svc+0x34/0x60)
      [    7.810000] Exception stack(0xc3a11d60 to 0xc3a11da8)
      [    7.810000] 1d60: 00000000 00000030 00000000 00000080 60000013 bf08f670 c3806900 c2c38b00
      [    7.810000] 1d80: 00000030 c3806930 00000000 c3a11ddc c3a11d88 c3a11da8 c0054190 c00523fc
      [    7.810000] 1da0: 60000013 ffffffff
      [    7.810000] [<c00520c8>] (__setup_irq+0x0/0x458) from [<c0052764>] (request_threaded_irq+0xd8/0x134)
      [    7.810000] [<c005268c>] (request_threaded_irq+0x0/0x134) from [<bf090978>] (ohci_hcd_at91_drv_probe+0x180/0x41c [ohci_hcd])
      [    7.810000] [<bf0907f8>] (ohci_hcd_at91_drv_probe+0x0/0x41c [ohci_hcd]) from [<c0155b7c>] (platform_drv_probe+0x20/0x24)
      [    7.810000] [<c0155b5c>] (platform_drv_probe+0x0/0x24) from [<c0154690>] (driver_probe_device+0xb8/0x20c)
      [    7.810000] [<c01545d8>] (driver_probe_device+0x0/0x20c) from [<c015484c>] (__driver_attach+0x68/0x88)
      [    7.810000]  r7:c3a11ea0 r6:bf0911d0 r5:c02cc964 r4:c02cc930
      [    7.810000] [<c01547e4>] (__driver_attach+0x0/0x88) from [<c0152e58>] (bus_for_each_dev+0x5c/0x9c)
      [    7.810000]  r6:bf0911d0 r5:c01547e4 r4:00000000
      [    7.810000] [<c0152dfc>] (bus_for_each_dev+0x0/0x9c) from [<c01544c0>] (driver_attach+0x20/0x28)
      [    7.810000]  r7:c02d7518 r6:00000000 r5:bf0911d0 r4:c2c10540
      [    7.810000] [<c01544a0>] (driver_attach+0x0/0x28) from [<c01536cc>] (bus_add_driver+0xb4/0x22c)
      [    7.810000] [<c0153618>] (bus_add_driver+0x0/0x22c) from [<c0154e9c>] (driver_register+0xa8/0x144)
      [    7.810000]  r7:00000000 r6:bf0911d0 r5:bf09120c r4:bf049af0
      [    7.810000] [<c0154df4>] (driver_register+0x0/0x144) from [<c0155f58>] (platform_driver_register+0x4c/0x60)
      [    7.810000]  r7:00000000 r6:000ae190 r5:bf09120c r4:bf049af0
      [    7.810000] [<c0155f0c>] (platform_driver_register+0x0/0x60) from [<bf093054>] (ohci_hcd_mod_init+0x54/0x8c [ohci_hcd])
      [    7.810000] [<bf093000>] (ohci_hcd_mod_init+0x0/0x8c [ohci_hcd]) from [<c0008638>] (do_one_initcall+0xac/0x174)
      [    7.810000]  r4:00006a4f
      [    7.810000] [<c000858c>] (do_one_initcall+0x0/0x174) from [<c004fdc4>] (sys_init_module+0x7c/0x1a0)
      [    7.810000] [<c004fd48>] (sys_init_module+0x0/0x1a0) from [<c0009260>] (ret_fast_syscall+0x0/0x2c)
      [    7.810000]  r7:00000080 r6:000ad018 r5:00016eb8 r4:00006a4f
      [    7.810000] Code: e24cb004 e59f3028 e1a02000 e7930180 (e5903028)
      [    7.810000] ---[ end trace 85aa37ed128143b5 ]---
      [    7.810000] Kernel panic - not syncing: Fatal exception in interrupt
      
      Commit 6fffb77c (USB: ohci-at91: fix PIO handling in relation with number of
      ports) started setting unused pins to EINVAL. But this exposed a bug in the
      ohci_hcd_at91_overcurrent_irq function where the gpio was used without being
      checked to see if it is valid.
      
      This patches fixed the issue by adding the gpio valid check.
      Signed-off-by: NJoachim Eastwood <joachim.eastwood@jotron.com>
      Cc: stable <stable@vger.kernel.org> # [3.4+] whereever 6fffb77c went
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01bb6501
  2. 27 9月, 2012 10 次提交
    • N
      md/raid10: fix "enough" function for detecting if array is failed. · 80b48124
      NeilBrown 提交于
      The 'enough' function is written to work with 'near' arrays only
      in that is implicitly assumes that the offset from one 'group' of
      devices to the next is the same as the number of copies.
      In reality it is the number of 'near' copies.
      
      So change it to make this number explicit.
      
      This bug makes it possible to run arrays without enough drives
      present, which is dangerous.
      It is appropriate for an -stable kernel, but will almost certainly
      need to be modified for some of them.
      
      Cc: stable@vger.kernel.org
      Reported-by: NJakub Husák <jakub@gooseman.cz>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      80b48124
    • B
      drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN · 833dd822
      Ben Skeggs 提交于
      PFIFO_INTR = 0x40000000 appears to be a normal case on nvc0/nve0 PFIFO,
      the binary driver appears to completely ignore it in its PFIFO interrupt
      handler and even masks off the bit (as we do) in PFIFO_INTR_EN at init
      time.
      
      The bits still light up in the hardware sometimes though, so lets just
      ignore any bits we haven't explicitely requested.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      833dd822
    • M
      dm verity: fix overflow check · 1d55f6bc
      Mikulas Patocka 提交于
      This patch fixes sector_t overflow checking in dm-verity.
      
      Without this patch, the code checks for overflow only if sector_t is
      smaller than long long, not if sector_t and long long have the same size.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      1d55f6bc
    • M
      dm thin: fix discard support for data devices · 0424caa1
      Mike Snitzer 提交于
      The discard limits that get established for a thin-pool or thin device
      may be incompatible with the pool's data device.  Avoid this by checking
      the discard limits of the pool's data device.  If an incompatibility is
      found then the pool's 'discard passdown' feature is disabled.
      
      Change thin_io_hints to ensure that a thin device always uses the same
      queue limits as its pool device.
      
      Introduce requested_pf to track whether or not the table line originally
      contained the no_discard_passdown flag and use this directly for table
      output.  We prepare the correct setting for discard_passdown directly in
      bind_control_target (called from pool_io_hints) and store it in
      adjusted_pf rather than waiting until we have access to pool->pf in
      pool_preresume.
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      0424caa1
    • M
      dm thin: tidy discard support · 9bc142dd
      Mike Snitzer 提交于
      A little thin discard code refactoring to make the next patch (dm thin:
      fix discard support for data devices) more readable.
      Pull out a couple of functions (and uses bools instead of unsigned for
      features).
      
      No functional changes.
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      9bc142dd
    • M
      dm: retain table limits when swapping to new table with no devices · 3ae70656
      Mike Snitzer 提交于
      Add a safety net that will re-use the DM device's existing limits in the
      event that DM device has a temporary table that doesn't have any
      component devices.  This is to reduce the chance that requests not
      respecting the hardware limits will reach the device.
      
      DM recalculates queue limits based only on devices which currently exist
      in the table.  This creates a problem in the event all devices are
      temporarily removed such as all paths being lost in multipath.  DM will
      reset the limits to the maximum permissible, which can then assemble
      requests which exceed the limits of the paths when the paths are
      restored.  The request will fail the blk_rq_check_limits() test when
      sent to a path with lower limits, and will be retried without end by
      multipath.  This became a much bigger issue after v3.6 commit fe86cdce
      ("block: do not artificially constrain max_sectors for stacking
      drivers").
      Reported-by: NDavid Jeffery <djeffery@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      3ae70656
    • M
      dm table: clear add_random unless all devices have it set · c3c4555e
      Milan Broz 提交于
      Always clear QUEUE_FLAG_ADD_RANDOM if any underlying device does not
      have it set. Otherwise devices with predictable characteristics may
      contribute entropy.
      
      QUEUE_FLAG_ADD_RANDOM specifies whether or not queue IO timings
      contribute to the random pool.
      
      For bio-based targets this flag is always 0 because such devices have no
      real queue.
      
      For request-based devices this flag was always set to 1 by default.
      
      Now set it according to the flags on underlying devices. If there is at
      least one device which should not contribute, set the flag to zero: If a
      device, such as fast SSD storage, is not suitable for supplying entropy,
      a request-based queue stacked over it will not be either.
      
      Because the checking logic is exactly same as for the rotational flag,
      share the iteration function with device_is_nonrot().
      Signed-off-by: NMilan Broz <mbroz@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      c3c4555e
    • M
      dm: handle requests beyond end of device instead of using BUG_ON · ba1cbad9
      Mike Snitzer 提交于
      The access beyond the end of device BUG_ON that was introduced to
      dm_request_fn via commit 29e4013d ("dm: implement
      REQ_FLUSH/FUA support for request-based dm") was an overly
      drastic (but simple) response to this situation.
      
      I have received a report that this BUG_ON was hit and now think
      it would be better to use dm_kill_unmapped_request() to fail the clone
      and original request with -EIO.
      
      map_request() will assign the valid target returned by
      dm_table_find_target to tio->ti.  But when the target
      isn't valid tio->ti is never assigned (because map_request isn't
      called); so add a check for tio->ti != NULL to dm_done().
      Reported-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Cc: stable@vger.kernel.org # v2.6.37+
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      ba1cbad9
    • M
      dm mpath: only retry ioctl when no paths if queue_if_no_path set · 7ba10aa6
      Mike Snitzer 提交于
      When there are no paths and multipath receives an ioctl, it waits until
      a path becomes available.  This behaviour is incorrect if the
      "queue_if_no_path" setting was not specified, as then the ioctl should
      be rejected immediately, which this patch now does.
      
      commit 35991652 ("dm mpath: allow ioctls to trigger pg init") should
      have checked if queue_if_no_path was configured before queueing IO.
      
      Checking for the queue_if_no_path feature, like is done in map_io(),
      allows the following table load to work without blocking in the
      multipath_ioctl retry loop:
      
        echo "0 1024 multipath 0 0 0 0" | dmsetup create mpath_nodevs
      
      Without this fix the multipath_ioctl will block with the following stack
      trace:
      
        blkid           D 0000000000000002     0 23936      1 0x00000000
         ffff8802b89e5cd8 0000000000000082 ffff8802b89e5fd8 0000000000012440
         ffff8802b89e4010 0000000000012440 0000000000012440 0000000000012440
         ffff8802b89e5fd8 0000000000012440 ffff88030c2aab30 ffff880325794040
        Call Trace:
         [<ffffffff814ce099>] schedule+0x29/0x70
         [<ffffffff814cc312>] schedule_timeout+0x182/0x2e0
         [<ffffffff8104dee0>] ? lock_timer_base+0x70/0x70
         [<ffffffff814cc48e>] schedule_timeout_uninterruptible+0x1e/0x20
         [<ffffffff8104f840>] msleep+0x20/0x30
         [<ffffffffa0000839>] multipath_ioctl+0x109/0x170 [dm_multipath]
         [<ffffffffa06bfb9c>] dm_blk_ioctl+0xbc/0xd0 [dm_mod]
         [<ffffffff8122a408>] __blkdev_driver_ioctl+0x28/0x30
         [<ffffffff8122a79e>] blkdev_ioctl+0xce/0x730
         [<ffffffff811970ac>] block_ioctl+0x3c/0x40
         [<ffffffff8117321c>] do_vfs_ioctl+0x8c/0x340
         [<ffffffff81166293>] ? sys_newfstat+0x33/0x40
         [<ffffffff81173571>] sys_ioctl+0xa1/0xb0
         [<ffffffff814d70a9>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 3.5+
      Acked-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      7ba10aa6
    • M
      dm thin: do not set discard_zeroes_data · 307615a2
      Mike Snitzer 提交于
      The dm thin pool target claims to support the zeroing of discarded
      data areas.  This turns out to be incorrect when processing discards
      that do not exactly cover a complete number of blocks, so the target
      must always set discard_zeroes_data_unsupported.
      
      The thin pool target will zero blocks when they are allocated if the
      skip_block_zeroing feature is not specified.  The block layer
      may send a discard that only partly covers a block.  If a thin pool
      block is partially discarded then there is no guarantee that the
      discarded data will get zeroed before it is accessed again.
      Due to this, thin devices cannot claim discards will always zero data.
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Cc: stable@vger.kernel.org # 3.4+
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      307615a2
  3. 26 9月, 2012 4 次提交
  4. 25 9月, 2012 7 次提交
    • M
      sb_edac: Avoid overflow errors at memory size calculation · deb09dda
      Mauro Carvalho Chehab 提交于
      Sandy bridge EDAC is calculating the memory size with overflow.
      Basically, the size field and the integer calculation is using 32 bits.
      More bits are needed, when the DIMM memories have high density.
      
      The net result is that memories are improperly reported there, when
      high-density DIMMs are used:
      
      EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 0, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
      EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 1, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
      
      As the number of pages value is handled at the EDAC core as unsigned
      ints, the driver shows the 16 GB memories at sysfs interface as 16760832
      MB! The fix is simple: calculate the number of pages as unsigned 64-bits
      integer.
      
      After the patch, the memory size (16 GB) is properly detected:
      
      EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 0, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
      EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 1, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
      
      Cc: stable@kernel.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      deb09dda
    • M
      i5000: Fix the memory size calculation with 2R memories · b70f8333
      Mauro Carvalho Chehab 提交于
      When 2R memories are found, the memory size should be multiplied
      by two, otherwise, it will report half of the memory size:
      
             +-----------------------------------------------+
             |                      mc0                      |
             |        branch0        |        branch1        |
             | channel0  | channel1  | channel0  | channel1  |
      -------+-----------------------------------------------+
      slot3: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
      slot2: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
      -------+-----------------------------------------------+
      slot1: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
      slot0: |  1024 MB  |  1024 MB  |  1024 MB  |  1024 MB  |
      -------+-----------------------------------------------+
      
      (the above machine have 4 x 2GB 2R memories)
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b70f8333
    • M
      i3200_edac: Fix memory rank size · 582a8996
      Mauro Carvalho Chehab 提交于
      commit a895bf8b incorrectly
      changed the logic that fills the memory bank size. Fix it.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      582a8996
    • P
      sh: pfc: Fix up GPIO mux type reconfig case. · 16d74ebe
      Paul Mundt 提交于
      Some drivers need to switch pin states between GPIO and pin function at
      runtime, which was inadvertently broken in the pinctrl driver for GPIOs
      being bound to a specific direction.
      
      This fixes up the request path to ensure that previously configured GPIOs
      don't cause us to inadvertently error out with an unsupported mux on
      reconfig, which in practice is primarily aimed at trapping pull-up/down
      users that have yet to be implemented under the new API.
      
      Fixes up regressions in the TPU PWM driver, amongst others.
      Reported-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      16d74ebe
    • R
      gpio-lpc32xx: Fix value handling of gpio_direction_output() · b1268d37
      Roland Stigge 提交于
      For GPIOs of gpio-lpc32xx, gpio_direction_output() ignores the value argument
      (initial value of output). This patch fixes this by setting the level
      accordingly.
      
      Cc: stable@kernel.org
      Signed-off-by: NRoland Stigge <stigge@antcom.de>
      Acked-by: NAlexandre Pereira da Silva <aletes.xgr@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      b1268d37
    • M
      phy/micrel: Rename KS80xx to KSZ80xx · 510d573f
      Marek Vasut 提交于
      There is no such part as KS8001, KS8041 or KS8051. There are only
      KSZ8001, KSZ8041 and KSZ8051. Rename these parts as such to match
      the Micrel naming.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: David J. Choi <david.choi@micrel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Cc: Linux ARM kernel <linux-arm-kernel@lists.infradead.org>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      510d573f
    • M
      phy/micrel: Implement support for KSZ8021 · 212ea99a
      Marek Vasut 提交于
      The KSZ8021 PHY was previously caught by KS8051, which is not correct.
      This PHY needs additional setup if it is strapped for address 0. In such
      case an reserved bit must be written in the 0x16, "Operation Mode Strap
      Override" register. According to the KS8051 datasheet, that bit means
      "PHY Address 0 in non-broadcast" and it indeed behaves as such on KSZ8021.
      The issue where the ethernet controller (Freescale FEC) did not communicate
      with network is fixed by writing this bit as 1.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: David J. Choi <david.choi@micrel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      212ea99a
  5. 24 9月, 2012 6 次提交
    • N
      md/raid5: add missing spin_lock_init. · cb13ff69
      NeilBrown 提交于
      commit b17459c0
         raid5: add a per-stripe lock
      
      added a spin_lock to the 'stripe_head' struct.
      Unfortunately there are two places where this struct is allocated
      but the spin lock was only initialised in one of them.
      
      So add the missing spin_lock_init.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      cb13ff69
    • S
      edac_mc: edac_mc_free() cannot assume mem_ctl_info is registered in sysfs. · faa2ad09
      Shaun Ruffell 提交于
      Fix potential NULL pointer dereference in edac_unregister_sysfs() on
      system boot introduced in 3.6-rc1.
      
      Since commit 7a623c03 ("edac: rewrite the sysfs code to use struct
      device") edac_mc_alloc() no longer initializes embedded kobjects in
      struct mem_ctl_info.  Therefore edac_mc_free() can no longer simply
      decrement a kobject reference count to free the allocated memory unless
      the memory controller driver module had also called edac_mc_add_mc().
      
      Now edac_mc_free() will check if the newly embedded struct device has
      been registered with sysfs before using either the standard device
      release functions or freeing the data structures itself with logic
      pulled out of the error path of edac_mc_alloc().
      
      The BUG this patch resolves for me:
      
        BUG: unable to handle kernel NULL pointer dereference at   (null)
        EIP is at __wake_up_common+0x1a/0x6a
        Process modprobe (pid: 933, ti=f3dc6000 task=f3db9520 task.ti=f3dc6000)
        Call Trace:
          complete_all+0x3f/0x50
          device_pm_remove+0x23/0xa2
          device_del+0x34/0x142
          edac_unregister_sysfs+0x3b/0x5c [edac_core]
          edac_mc_free+0x29/0x2f [edac_core]
          e7xxx_probe1+0x268/0x311 [e7xxx_edac]
          e7xxx_init_one+0x56/0x61 [e7xxx_edac]
          local_pci_probe+0x13/0x15
        ...
      
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: NShaun Ruffell <sruffell@digium.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      faa2ad09
    • F
      edac_mc: fix messy kfree calls in the error path · ef6e7816
      Fengguang Wu 提交于
      coccinelle warns about:
      
      + drivers/edac/edac_mc.c:429:9-23: ERROR: reference preceded by free on line 429
      
         421         if (mci->csrows) {
       > 422                 for (chn = 0; chn < tot_channels; chn++) {
         423                         csr = mci->csrows[chn];
         424                         if (csr) {
       > 425                                 for (chn = 0; chn < tot_channels; chn++)
         426                                          kfree(csr->channels[chn]);
         427                                  kfree(csr);
         428                          }
       > 429                          kfree(mci->csrows[i]);
         430                  }
         431                  kfree(mci->csrows);
         432          }
      
      and that code block seem to mess things up in several ways (double free, memory
      leak, out-of-bound reads etc.):
      
      L422: The iterator "chn" and bound "tot_channels" are totally wrong. Should be
            "row" and "tot_csrows" respectively. Which means either memory leak, or
            out-of-bound reads (which if does not trigger an immediate page fault
            error, will further lead to kfree() on random addresses).
      
      L425: The inner loop is reusing the same iterator "chn" as the outer loop,
            which could lead to premature end of the outer loop, and hence memory leak.
      
      L429: The array index 'i' in mci->csrows[i] is a temporary value used in
            previous loops, and won't change at all in the current loop. Which
            means either out-of-bound read and possibly kfree(random number), or the
            same mci->csrows[i] get freed once and again, and possibly double free
            for the kfree(csr) in L427.
      
      L426/L427: a kfree(csr->channels) is needed in between to avoid leaking the memory.
      
      The buggy code was introduced by commit de3910eb ("edac: change the mem
      allocation scheme to make Documentation/kobject.txt happy") in the 3.6-rc1
      merge window. Fix it by freeing up resources in this order:
      
        free csrows[i]->channels[j]
        free csrows[i]->channels
        free csrows[i]
        free csrows
      
      CC: Mauro Carvalho Chehab <mchehab@redhat.com>
      CC: Shaun Ruffell <sruffell@digium.com>
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef6e7816
    • A
      hwmon: (fam15h_power) Tweak runavg_range on resume · 5f0ecb90
      Andreas Herrmann 提交于
      The quirk introduced with commit
      00250ec9 (hwmon: fam15h_power: fix
      bogus values with current BIOSes) is not only required during driver
      load but also when system resumes from suspend. The BIOS might set the
      previously recommended (but unsuitable) initilization value for the
      running average range register during resume.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Tested-by: NAndreas Hartmann <andihartmann@01019freenet.de>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: stable@vger.kernel.org # 3.0+
      5f0ecb90
    • S
      hwmon: (coretemp) Use get_online_cpus to avoid races involving CPU hotplug · 641f1456
      Silas Boyd-Wickizer 提交于
      coretemp_init loops with for_each_online_cpu, adding platform_devices
      and sysfs interfaces, then calls register_hotcpu_notifier.  There is a
      race if a CPU is offlined or onlined after the loop, but before
      register_hotcpu_notifier.  The race might result in the absence of a
      platform_device+sysfs interface for an online CPU, or the presence of
      a platform_device+sysfs interface for an offline CPU.  A similar race
      occurs during coretemp_exit, after the module calls
      unregister_hotcpu_notifier, but before it unregisters all devices, a
      CPU might offline and a device for an offline CPU will exist for a
      short while.
      
      This fix surrounds for_each_online_cpu and register_hotcpu_notifier
      with get_online_cpus+put_online_cpus; and surrounds
      unregister_hotcpu_notifier and device unregistering with
      get_online_cpus+put_online_cpus.
      
      Build tested.
      Signed-off-by: NSilas Boyd-Wickizer <sbw@mit.edu>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      641f1456
    • S
      hwmon: (via-cputemp) Use get_online_cpus to avoid races involving CPU hotplug · 1ec3ddfd
      Silas Boyd-Wickizer 提交于
      via_cputemp_init loops with for_each_online_cpu, adding
      platform_devices, then calls register_hotcpu_notifier.  If a CPU is
      offlined between the loop and register_hotcpu_notifier, then later
      onlined, via_cputemp_device_add will attempt to add platform devices
      with the same ID.  A similar race occurs during via_cputemp_exit,
      after the module calls unregister_hotcpu_notifier, a CPU might offline
      and a device will exist for a CPU that is offline.
      
      This fix surrounds for_each_online_cpu and register_hotcpu_notifier
      with get_online_cpus+put_online_cpus; and surrounds
      unregister_hotcpu_notifier and device unregistering with
      get_online_cpus+put_online_cpus.
      
      Build tested.
      Signed-off-by: NSilas Boyd-Wickizer <sbw@mit.edu>
      Acked-by: NHarald Welte <laforge@gnumonks.org>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      1ec3ddfd
  6. 23 9月, 2012 3 次提交
  7. 22 9月, 2012 8 次提交