29 Sep, 2011

1 commit

  • Doing it just before starting to call into cpu_idle() made a sick kind
    of sense only because the original bug we fixed (see commit
    288d5abec831: "Boot up with usermodehelper disabled") was about problems
    with some scheduler data structures not being initialized, and they had
    better be initialized at that point.

    But it really didn't make any other conceptual sense, and doing it after
    the initial "schedule()" call for the idle thread actually opened up a
    race: what if the main initialization thread did everything without
    needing to sleep, and got all the way into user land too? Without
    actually having scheduled back to the idle thread?

    Now, in normal circumstances that doesn't ever happen, but it looks like
    Richard Cochran triggered exactly that on his ARM IXP4xx machines:

    "I have some ARM IXP4xx based machines that use the two on chip MAC
    ports (aka NPEs). The NPE needs a firmware in order to function.
    Ever since the following commit [that 288d5abec831 one], it is no
    longer possible to bring up the interfaces during the init scripts."

    with a call trace showing an ioctl coming from user space. Richard says:

    "The init is busybox, and the startup script does mount, syslogd, and
    then ifup, so that all can go by quickly."

    The fix is to move the usermodehelper_enable() into the main 'init'
    thread, and just put it after we've done all our initcalls. By then,
    everything really should be up, but we've obviously not actually started
    the user-mode portion of init yet.

    Reported-and-tested-by: Richard Cochran
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

28 Sep, 2011

20 commits


27 Sep, 2011

14 commits

  • That flag no longer makes sense, since we don't look up automount points
    as eagerly any more. Additionally, it turns out that the NO_AUTOMOUNT
    handling was buggy to begin with: it would avoid automounting even for
    cases where we really *needed* to do the automount handling, and could
    return ENOENT for autofs entries that hadn't been instantiated yet.

    With our new non-eager automount semantics, one discussion has been
    about adding a AT_AUTOMOUNT flag to vfs_fstatat (and thus the
    newfstatat() and fstatat64() system calls), but it's probably not worth
    it: you can always force at least directory automounting by simply
    adding the final '/' to the filename, which works for *all* of the stat
    family system calls, old and new.

    So AT_NO_AUTOMOUNT (and thus LOOKUP_NO_AUTOMOUNT) really were just a
    result of our bad default behavior.

    Acked-by: Ian Kent
    Acked-by: Trond Myklebust
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • Currently the the internal oscillator is powered down when entering BIAS_OFF
    state, but not re-enabled when going back to BIAS_STANDBY. As a result the
    CODEC will stop working after suspend if the internal oscillator is used to
    generate the sysclock signal. This patch fixes it by clearing the appropriate
    bit in the power down register when the CODEC is re-enabled.

    Signed-off-by: Lars-Peter Clausen
    Signed-off-by: Mark Brown
    Cc: stable@kernel.org

    Lars-Peter Clausen
     
  • The concensus seems to be that system calls such as stat() etc should
    not trigger an automount. Neither should the l* versions.

    This patch therefore adds a LOOKUP_AUTOMOUNT flag to tag those lookups
    that _should_ trigger an automount on the last path element.

    Signed-off-by: Trond Myklebust
    [ Edited to leave out the cases that are already covered by LOOKUP_OPEN,
    LOOKUP_DIRECTORY and LOOKUP_CREATE - all of which also fundamentally
    force automounting for their own reasons - Linus ]
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     
  • Since we've now turned around and made LOOKUP_FOLLOW *not* force an
    automount, we want to add the ability to force an automount event on
    lookup even if we don't happen to have one of the other flags that force
    it implicitly (LOOKUP_OPEN, LOOKUP_DIRECTORY, LOOKUP_PARENT..)

    Most cases will never want to use this, since you'd normally want to
    delay automounting as long as possible, which usually implies
    LOOKUP_OPEN (when we open a file or directory, we really cannot avoid
    the automount any more).

    But Trond argued sufficiently forcefully that at a minimum bind mounting
    a file and quotactl will want to force the automount lookup. Some other
    cases (like nfs_follow_remote_path()) could use it too, although
    LOOKUP_DIRECTORY would work there as well.

    This commit just adds the flag and logic, no users yet, though. It also
    doesn't actually touch the LOOKUP_NO_AUTOMOUNT flag that is related, and
    was made irrelevant by the same change that made us not follow on
    LOOKUP_FOLLOW.

    Cc: Trond Myklebust
    Cc: Ian Kent
    Cc: Jeff Layton
    Cc: Miklos Szeredi
    Cc: David Howells
    Cc: Al Viro
    Cc: Greg KH
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • * 'samsung-fixes-3' of git://github.com/kgene/linux-samsung:
    ARM: EXYNOS4: Rename sclk_cam clocks for FIMC driver
    ARM: S5PV210: Rename sclk_cam clocks for FIMC media driver
    ARM: S5P: fix incorrect loop iterator usage on gpio-interrupt
    ARM: S3C2443: Fix bit-reset in setrate of clk_armdiv

    Linus Torvalds
     
  • The sclk_cam clocks are now controlled by the top level FIMC media
    device driver bound to "s5p-fimc-md" platform device.
    Rename sclk_cam clocks so they accessible by the corresponding
    driver.

    Signed-off-by: Sylwester Nawrocki
    Signed-off-by: Kyungmin Park
    Signed-off-by: Kukjin Kim

    Sylwester Nawrocki
     
  • The sclk_cam clocks are now controlled by the top level FIMC media
    device driver bound to "s5p-fimc-md" platform device.
    Rename sclk_cam clocks so they accessible by the corresponding
    driver.

    Signed-off-by: Sylwester Nawrocki
    Signed-off-by: Kyungmin Park
    Signed-off-by: Kukjin Kim

    Sylwester Nawrocki
     
  • * 'hwmon-for-linus' of git://github.com/groeck/linux:
    hwmon: (coretemp) remove struct platform_data * parameter from create_core_data()
    hwmon: (coretemp) constify static data
    hwmon: (coretemp) don't use kernel assigned CPU number as platform device ID
    hwmon: (ds620) Fix handling of negative temperatures
    hwmon: (w83791d) rename prototype parameter from 'register' to 'reg'
    hwmon: (coretemp) Don't use threshold registers for tempX_max
    hwmon: (coretemp) Let the user force TjMax
    hwmon: (coretemp) Drop duplicate function get_pkg_tjmax

    Linus Torvalds
     
  • * 'kvm-updates/3.1' of git://github.com/avikivity/kvm:
    KVM: x86 emulator: fix Src2CL decode
    KVM: MMU: fix incorrect return of spte

    Linus Torvalds
     
  • * 'fixes' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm:
    ARM: 7099/1: futex: preserve oldval in SMP __futex_atomic_op
    ARM: dma-mapping: free allocated page if unable to map
    ARM: fix vmlinux.lds.S discarding sections
    ARM: nommu: fix warning with checksyscalls.sh
    ARM: 7091/1: errata: D-cache line maintenance operation by MVA may not succeed

    Linus Torvalds
     
  • proper dma_unmapping and freeing of skb's has to be done in the rx
    cleanup for EDMA chipsets when the device is unloaded and this also
    seems to address the following warning which shows up occasionally when
    the device is unloaded

    Call Trace:
    [] warn_slowpath_common+0x72/0xa0
    [] ? dma_debug_device_change+0x19c/0x200
    [] ? dma_debug_device_change+0x19c/0x200
    [] warn_slowpath_fmt+0x33/0x40
    [] dma_debug_device_change+0x19c/0x200
    [] notifier_call_chain+0x82/0xb0
    [] __blocking_notifier_call_chain+0x60/0x90
    [] blocking_notifier_call_chain+0x1f/0x30
    [] __device_release_driver+0xa4/0xc0
    [] driver_detach+0x97/0xa0
    [] bus_remove_driver+0x6c/0xe0
    [] ? sysfs_addrm_finish+0x4b/0x60
    [] driver_unregister+0x49/0x80
    [] ? sysfs_remove_file+0x14/0x20
    [] pci_unregister_driver+0x32/0x80
    [] ath_pci_exit+0x12/0x20 [ath9k]
    [] ath9k_exit+0x17/0x36 [ath9k]
    [] ? mutex_unlock+0xd/0x10
    [] sys_delete_module+0x13f/0x200
    [] ? sys_munmap+0x4b/0x60
    [] ? restore_all+0xf/0xf
    [] ? spurious_fault+0xe0/0xe0
    [] ? trace_hardirqs_on_caller+0xf4/0x180
    [] sysenter_do_call+0x12/0x38
    ---[ end trace 16e1c1521c06bcf9 ]---
    Mapped at:
    [] debug_dma_map_page+0x48/0x120
    [] ath_rx_init+0x3f8/0x4b0 [ath9k]
    [] ath9k_init_device+0x4c4/0x7b0 [ath9k]
    [] ath_pci_probe+0x263/0x330 [ath9k]

    Signed-off-by: Mohammed Shafi Shajakhan
    Signed-off-by: John W. Linville

    Mohammed Shafi Shajakhan
     
  • Driver rtl8192cu assigns a new struct rtl_tcb_desc object, but fails to
    clear it.

    Signed-off-by: Larry Finger
    Cc: Stable [2.6.39+]
    Signed-off-by: John W. Linville

    Larry Finger
     
  • If iwl_scan_initiate() fails for any reason,
    priv->scan_request and priv->scan_vif are left
    dangling. This can lead to a crash later when
    iwl_bg_scan_completed() tries to run a pending
    scan request.

    In practice, this seems to be very rare due to
    the STATUS_SCANNING check earlier. That check,
    however, is wrong -- it should allow a scan to
    be queued when a reset/roc scan is going on.
    When a normal scan is already going on, a new
    one can't be issued by mac80211, so that code
    can be removed completely. I introduced this
    bug when adding off-channel support in commit
    266af4c745952e9bebf687dd68af58df553cb59d.

    Cc: stable@kernel.org [3.0]
    Reported-by: Peng Yan
    Signed-off-by: Johannes Berg
    Signed-off-by: Wey-Yi Guy
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • Commit b7ab83e (PM: Use spinlock instead of mutex in clock
    management functions) introduced a regression causing clocks_mutex
    to be acquired under a spinlock. This happens because
    pm_clk_suspend() and pm_clk_resume() call pm_clk_acquire() under
    pcd->lock, but pm_clk_acquire() executes clk_get() which causes
    clocks_mutex to be acquired. Similarly, __pm_clk_remove(),
    executed under pcd->lock, calls clk_put(), which also causes
    clocks_mutex to be acquired.

    To fix those problems make pm_clk_add() call pm_clk_acquire(), so
    that pm_clk_suspend() and pm_clk_resume() don't have to do that.
    Change pm_clk_remove() and pm_clk_destroy() to separate
    modifications of the pcd->clock_list list from the actual removal of
    PM clock entry objects done by __pm_clk_remove().

    Reported-and-tested-by: Guennadi Liakhovetski
    Signed-off-by: Rafael J. Wysocki
    Acked-by: Russell King

    Rafael J. Wysocki
     

26 Sep, 2011

5 commits

  • Following reports on the list, it looks like the 3e-9xxx driver will leak dma
    mappings every time we get a transient queueing error back from the card.
    This is because it maps the sg list in the routine that sends the command, but
    doesn't unmap again in the transient failure path (even though the command is
    sent back to the block layer). Fix by unmapping before returning the status.

    Reported-by: Chris Boot
    Tested-by: Chris Boot
    Acked-by: Adam Radford
    Cc: stable@kernel.org
    Signed-off-by: James Bottomley

    James Bottomley
     
  • This oops was reported recently:
    d:mon> e
    cpu 0xd: Vector: 300 (Data Access) at [c0000000fd4c7120]
    pc: d00000000076f194: .t3_l2t_get+0x44/0x524 [cxgb3]
    lr: d000000000b02108: .init_act_open+0x150/0x3d4 [cxgb3i]
    sp: c0000000fd4c73a0
    msr: 8000000000009032
    dar: 0
    dsisr: 40000000
    current = 0xc0000000fd640d40
    paca = 0xc00000000054ff80
    pid = 5085, comm = iscsid
    d:mon> t
    [c0000000fd4c7450] d000000000b02108 .init_act_open+0x150/0x3d4 [cxgb3i]
    [c0000000fd4c7500] d000000000e45378 .cxgbi_ep_connect+0x784/0x8e8 [libcxgbi]
    [c0000000fd4c7650] d000000000db33f0 .iscsi_if_rx+0x71c/0xb18
    [scsi_transport_iscsi2]
    [c0000000fd4c7740] c000000000370c9c .netlink_data_ready+0x40/0xa4
    [c0000000fd4c77c0] c00000000036f010 .netlink_sendskb+0x4c/0x9c
    [c0000000fd4c7850] c000000000370c18 .netlink_sendmsg+0x358/0x39c
    [c0000000fd4c7950] c00000000033be24 .sock_sendmsg+0x114/0x1b8
    [c0000000fd4c7b50] c00000000033d208 .sys_sendmsg+0x218/0x2ac
    [c0000000fd4c7d70] c00000000033f55c .sys_socketcall+0x228/0x27c
    [c0000000fd4c7e30] c0000000000086a4 syscall_exit+0x0/0x40
    --- Exception: c01 (System Call) at 00000080da560cfc

    The root cause was an EEH error, which sent us down the offload_close path in
    the cxgb3 driver, which in turn sets cdev->l2opt to NULL, without regard for
    upper layer driver (like the cxgbi drivers) which might have execution contexts
    in the middle of its use. The result is the oops above, when t3_l2t_get attempts
    to dereference L2DATA(cdev)->nentries in arp_hash right after the EEH error handler sets it to NULL.

    The fix is to prevent the setting of the NULL pointer until after there are no
    further users of it. The t3cdev->l2opt pointer is now converted to be an rcu
    pointer and the L2DATA macro is now called under the protection of the
    rcu_read_lock(). When the EEH error path:
    t3_adapter_error->offload_close->cxgb3_offload_deactivate
    Is exectured, setting of that l2opt pointer to NULL, is now gated on an rcu
    quiescence point, preventing, allowing L2DATA callers to safely check for a NULL
    pointer without concern that the underlying data will be freeded before the
    pointer is dereferenced.

    This has been tested by the reporter and shown to fix the reproted oops

    [nhorman: fix up unitinialised variable reported by Dan Carpenter]
    Signed-off-by: Neil Horman
    Reviewed-by: Karen Xie
    Cc: stable@kernel.org
    Signed-off-by: James Bottomley

    Neil Horman
     
  • Before clearing the probing flag in the error exit path, check that the
    chip pointer is not NULL.

    Signed-off-by: Thomas Pfaff
    Cc: [2.6.39+]
    Signed-off-by: Takashi Iwai

    Thomas Pfaff
     
  • The spec->autocfg.line_out_pins[] may contain the same pins as hp_pins[]
    depending on the configuration. When they are identical, detecting the
    line_jack_present flag screws up the auto-mute because alc_line_automute()
    is called unconditionally at initialization while it won't be triggered
    by unsol events, thus the old line_jack_present flag is kept for the
    whole run.

    For fixing this buggy behavior, the driver needs to check whether the
    line-outs are really individual, and skip if same as headphone jacks.

    Reference: https://bugzilla.novell.com/show_bug.cgi?id=716104

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • The SMP implementation of __futex_atomic_op clobbers oldval with the
    status flag from the exclusive store. This causes it to always read as
    zero when performing the FUTEX_OP_CMP_* operation.

    This patch updates the ARM __futex_atomic_op implementations to take a
    tmp argument, allowing us to store the strex status flag without
    overwriting the register containing oldval.

    Cc: stable@kernel.org
    Reported-by: Minho Ban
    Reviewed-by: Nicolas Pitre
    Signed-off-by: Will Deacon
    Signed-off-by: Russell King

    Will Deacon