Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Aug 9, 2012
  1. @gregkh

    Linux 3.4.8

    gregkh authored
  2. @dvhart @gregkh

    futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()

    dvhart authored gregkh committed
    commit 6f7b0a2 upstream.
    
    If uaddr == uaddr2, then we have broken the rule of only requeueing
    from a non-pi futex to a pi futex with this call. If we attempt this,
    as the trinity test suite manages to do, we miss early wakeups as
    q.key is equal to key2 (because they are the same uaddr). We will then
    attempt to dereference the pi_mutex (which would exist had the futex_q
    been properly requeued to a pi futex) and trigger a NULL pointer
    dereference.
    
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Dave Jones <davej@redhat.com>
    Link: http://lkml.kernel.org/r/ad82bfe7f7d130247fbe2b5b4275654807774227.1342809673.git.dvhart@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. @dvhart @gregkh

    futex: Fix bug in WARN_ON for NULL q.pi_state

    dvhart authored gregkh committed
    commit f27071c upstream.
    
    The WARN_ON in futex_wait_requeue_pi() for a NULL q.pi_state was testing
    the address (&q.pi_state) of the pointer instead of the value
    (q.pi_state) of the pointer. Correct it accordingly.
    
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Dave Jones <davej@redhat.com>
    Link: http://lkml.kernel.org/r/1c85d97f6e5f79ec389a4ead3e367363c74bd09a.1342809673.git.dvhart@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. @dvhart @gregkh

    futex: Test for pi_mutex on fault in futex_wait_requeue_pi()

    dvhart authored gregkh committed
    commit b6070a8 upstream.
    
    If fixup_pi_state_owner() faults, pi_mutex may be NULL. Test
    for pi_mutex != NULL before testing the owner against current
    and possibly unlocking it.
    
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Link: http://lkml.kernel.org/r/dc59890338fc413606f04e5c5b131530734dae3d.1342809673.git.dvhart@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. @gregkh

    m68k: Correct the Atari ALLOWINT definition

    Mikael Pettersson authored gregkh committed
    commit c663600 upstream.
    
    Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the
    `nfeth' ethernet device triggers a WARN_ONCE() in generic irq
    handling code on the first irq for that device:
    
    WARNING: at kernel/irq/handle.c:146 handle_irq_event_percpu+0x134/0x142()
    irq 3 handler nfeth_interrupt+0x0/0x194 enabled interrupts
    Modules linked in:
    Call Trace: [<000299b2>] warn_slowpath_common+0x48/0x6a
     [<000299c0>] warn_slowpath_common+0x56/0x6a
     [<00029a4c>] warn_slowpath_fmt+0x2a/0x32
     [<0005b34c>] handle_irq_event_percpu+0x134/0x142
     [<0005b34c>] handle_irq_event_percpu+0x134/0x142
     [<0000a584>] nfeth_interrupt+0x0/0x194
     [<001ba0a8>] schedule_preempt_disabled+0x0/0xc
     [<0005b37a>] handle_irq_event+0x20/0x2c
     [<0005add4>] generic_handle_irq+0x2c/0x3a
     [<00002ab6>] do_IRQ+0x20/0x32
     [<0000289e>] auto_irqhandler_fixup+0x4/0x6
     [<00003144>] cpu_idle+0x22/0x2e
     [<001b8a78>] printk+0x0/0x18
     [<0024d112>] start_kernel+0x37a/0x386
     [<0003021d>] __do_proc_dointvec+0xb1/0x366
     [<0003021d>] __do_proc_dointvec+0xb1/0x366
     [<0024c31e>] _sinittext+0x31e/0x9c0
    
    After invoking the irq's handler the kernel sees !irqs_disabled()
    and concludes that the handler erroneously enabled interrupts.
    
    However, debugging shows that !irqs_disabled() is true even before
    the handler is invoked, which indicates a problem in the platform
    code rather than the specific driver.
    
    The warning does not occur in 3.1 or older kernels.
    
    It turns out that the ALLOWINT definition for Atari is incorrect.
    
    The Atari definition of ALLOWINT is ~0x400, the stated purpose of
    that is to avoid taking HSYNC interrupts.  irqs_disabled() returns
    true if the 3-bit ipl & 4 is non-zero.  The nfeth interrupt runs at
    ipl 3 (it's autovector 3), but 3 & 4 is zero so irqs_disabled() is
    false, and the warning above is generated.
    
    When interrupts are explicitly disabled, ipl is set to 7.  When they
    are enabled, ipl is masked with ALLOWINT.  On Atari this will result
    in ipl = 3, which blocks interrupts at ipl 3 and below.  So how come
    nfeth interrupts at ipl 3 are received at all?  That's because ipl
    is reset to 2 by Atari-specific code in default_idle(), again with
    the stated purpose of blocking HSYNC interrupts.  This discrepancy
    means that ipl 3 can remain blocked for longer than intended.
    
    Both default_idle() and falcon_hblhandler() identify HSYNC with
    ipl 2, and the "Atari ST/.../F030 Hardware Register Listing" agrees,
    but ALLOWINT is defined as if HSYNC was ipl 3.
    
    [As an experiment I modified default_idle() to reset ipl to 3, and
    as expected that resulted in all nfeth interrupts being blocked.]
    
    The fix is simple: define ALLOWINT as ~0x500 instead.  This makes
    arch_local_irq_enable() consistent with default_idle(), and prevents
    the !irqs_disabled() problems for ipl 3 interrupts.
    
    Tested on Atari running in an Aranym VM.
    
    Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
    Tested-by: Michael Schmitz <schmitzmic@googlemail.com>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. @andreas-schwab @gregkh

    m68k: Make sys_atomic_cmpxchg_32 work on classic m68k

    andreas-schwab authored gregkh committed
    commit 9e2760d upstream.
    
    User space access must always go through uaccess accessors, since on
    classic m68k user space and kernel space are completely separate.
    
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Tested-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. @broonie @gregkh

    ASoC: wm8994: Ensure there are enough BCLKs for four channels

    broonie authored gregkh committed
    commit b8edf3e upstream.
    
    Otherwise if someone tries to use all four channels on AIF1 with the
    device in master mode we won't be able to clock out all the data.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. @broonie @gregkh

    ASoC: wm8962: Allow VMID time to fully ramp

    broonie authored gregkh committed
    commit 9d40e55 upstream.
    
    Required for reliable power up from cold.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. @tiwai @gregkh

    ALSA: hda - Support dock on Lenovo Thinkpad T530 with ALC269VC

    tiwai authored gregkh committed
    commit 707fba3 upstream.
    
    Lenovo Thinkpad T530 with ALC269VC codec has a dock port but BIOS
    doesn't set up the pins properly.  Enable the pins as well as on
    Thinkpad X230 Tablet.
    
    Reported-and-tested-by: Mario <anyc@hadiko.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. @tiwai @gregkh

    ALSA: hda - Fix mute-LED GPIO initialization for IDT codecs

    tiwai authored gregkh committed
    commit 1f43f6c upstream.
    
    The IDT codecs initializes the GPIO setup for mute LEDs via
    snd_hda_sync_vmaster_hook().  This works in most cases except for the
    very first call, which is called before PCM and control creations.
    Thus before Master switch is set manually via alsactl, the mute LED
    may show the wrong state, depending on the polarity.
    
    Now it's fixed by calling the LED-status update function manually when
    no vmaster is set yet.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. @tiwai @gregkh

    ALSA: hda - Fix polarity of mute LED on HP Mini 210

    tiwai authored gregkh committed
    commit ff8a1e2 upstream.
    
    The commit a3e1997 made the LED working again on HP Mini 210 but
    with a wrong polarity.  This patch fixes the polarity for this
    machine, and also introduce a new model string "hp-inv-led".
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=772923
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. @tiwai @gregkh

    ALSA: hda - Fix mute-LED GPIO setup for HP Mini 210

    tiwai authored gregkh committed
    commit a3e1997 upstream.
    
    BIOS on HP Mini 210 doesn't provide the proper "HP_Mute_LED" DMI
    string, thus the driver doesn't initialize the GPIO, too.  In the
    earlier kernel, the driver falls back to GPIO1, but since 3.3 we've
    stopped this due to other wrongly advertised machines.
    
    For fixing this particular case, add a new model type to specify the
    default polarity explicitly so that the fallback to GPIO1 is handled.
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=772923
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. @tiwai @gregkh

    ALSA: hda - Fix invalid D3 of headphone DAC on VT202x codecs

    tiwai authored gregkh committed
    commit 6162552 upstream.
    
    We've got a bug report about the silent output from the headphone on a
    mobo with VT2021, and spotted out that this was because of the wrong
    D3 state on the DAC for the headphone output.  The bug is triggered by
    the incomplete check for this DAC in set_widgets_power_state_vt1718S().
    It checks only the connectivity of the primary output (0x27) but
    doesn't consider the path from the headphone pin (0x28).
    
    Now this patch fixes the problem by checking both pins for DAC 0x0b.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. @tiwai @gregkh

    ALSA: mpu401: Fix missing initialization of irq field

    tiwai authored gregkh committed
    commit bc733d4 upstream.
    
    The irq field of struct snd_mpu401 is supposed to be initialized to -1.
    Since it's set to zero as of now, a probing error before the irq
    installation results in a kernel warning "Trying to free already-free
    IRQ 0".
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44821
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. @zonque @gregkh

    ALSA: snd-usb: fix clock source validity index

    zonque authored gregkh committed
    commit aff252a upstream.
    
    uac_clock_source_is_valid() uses the control selector value to access
    the bmControls bitmap of the clock source unit. This is wrong, as
    control selector values start from 1, while the bitmap uses all
    available bits.
    
    In other words, "Clock Validity Control" is stored in D3..2, not D5..4
    of the clock selector unit's bmControls.
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Reported-by: Andreas Koch <andreas@akdesigninc.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. @gregkh

    USB: echi-dbgp: increase the controller wait time to come out of halt.

    Colin Ian King authored gregkh committed
    commit f96a421 upstream.
    
    The default 10 microsecond delay for the controller to come out of
    halt in dbgp_ehci_startup is too short, so increase it to 1 millisecond.
    
    This is based on emperical testing on various USB debug ports on
    modern machines such as a Lenovo X220i and an Ivybridge development
    platform that needed to wait ~450-950 microseconds.
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. @minipli @gregkh

    net/tun: fix ioctl() based info leaks

    minipli authored gregkh committed
    [ Upstream commits a117dac
      and 8bbb181 ]
    
    The tun module leaks up to 36 bytes of memory by not fully initializing
    a structure located on the stack that gets copied to user memory by the
    TUNGETIFF and SIOCGIFHWADDR ioctl()s.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. @gregkh

    tcp: perform DMA to userspace only if there is a task waiting for it

    Jiri Kosina authored gregkh committed
    [ Upstream commit 59ea33a ]
    
    Back in 2006, commit 1a2449a ("[I/OAT]: TCP recv offload to I/OAT")
    added support for receive offloading to IOAT dma engine if available.
    
    The code in tcp_rcv_established() tries to perform early DMA copy if
    applicable. It however does so without checking whether the userspace
    task is actually expecting the data in the buffer.
    
    This is not a problem under normal circumstances, but there is a corner
    case where this doesn't work -- and that's when MSG_TRUNC flag to
    recvmsg() is used.
    
    If the IOAT dma engine is not used, the code properly checks whether
    there is a valid ucopy.task and the socket is owned by userspace, but
    misses the check in the dmaengine case.
    
    This problem can be observed in real trivially -- for example 'tbench' is a
    good reproducer, as it makes a heavy use of MSG_TRUNC. On systems utilizing
    IOAT, you will soon find tbench waiting indefinitely in sk_wait_data(), as they
    have been already early-copied in tcp_rcv_established() using dma engine.
    
    This patch introduces the same check we are performing in the simple
    iovec copy case to the IOAT case as well. It fixes the indefinite
    recvmsg(MSG_TRUNC) hangs.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. @gregkh

    net: fix rtnetlink IFF_PROMISC and IFF_ALLMULTI handling

    Jiri Benc authored gregkh committed
    [ Upstream commit b1beb68 ]
    
    When device flags are set using rtnetlink, IFF_PROMISC and IFF_ALLMULTI
    flags are handled specially. Function dev_change_flags sets IFF_PROMISC and
    IFF_ALLMULTI bits in dev->gflags according to the passed value but
    do_setlink passes a result of rtnl_dev_combine_flags which takes those bits
    from dev->flags.
    
    This can be easily trigerred by doing:
    
    tcpdump -i eth0 &
    ip l s up eth0
    
    ip sets IFF_UP flag in ifi_flags and ifi_change, which is combined with
    IFF_PROMISC by rtnl_dev_combine_flags, causing __dev_change_flags to set
    IFF_PROMISC in gflags.
    
    Reported-by: Max Matveev <makc@redhat.com>
    Signed-off-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  20. @gregkh

    USB: kaweth.c: use GFP_ATOMIC under spin_lock

    Dan Carpenter authored gregkh committed
    [ Upstream commit e4c7f25 ]
    
    The problem is that we call this with a spin lock held.  The call tree
    is:
    	kaweth_start_xmit() holds kaweth->device_lock.
    	-> kaweth_async_set_rx_mode()
    	   -> kaweth_control()
    	      -> kaweth_internal_control_msg()
    
    The kaweth_internal_control_msg() function is only called from
    kaweth_control() which used GFP_ATOMIC for its allocations.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  21. @liuhangbin @gregkh

    tcp: Add TCP_USER_TIMEOUT negative value check

    liuhangbin authored gregkh committed
    [ Upstream commit 4249357 ]
    
    TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int. But
    patch "tcp: Add TCP_USER_TIMEOUT socket option"(dca43c7) didn't check the negative
    values. If a user assign -1 to it, the socket will set successfully and wait
    for 4294967295 miliseconds. This patch add a negative value check to avoid
    this issue.
    
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  22. @gregkh

    wanmain: comparing array with NULL

    Alan Cox authored gregkh committed
    [ Upstream commit 8b72ff6 ]
    
    gcc really should warn about these !
    
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  23. @gregkh

    caif: fix NULL pointer check

    Alan Cox authored gregkh committed
    [ Upstream commit c66b9b7 ]
    
    Reported-by: <rucsoftsec@gmail.com>
    Resolves-bug: http://bugzilla.kernel.org/show_bug?44441
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  24. @gregkh

    r8169: revert "add byte queue limit support".

    Francois Romieu authored gregkh committed
    [ Upstream commit 17bcb68 ]
    
    This reverts commit 036dafa.
    
    First it appears in bisection, then reverting it solves the usual
    netdev watchdog problem for different people. I don't have a proper
    fix yet so get rid of it.
    
    Bisected-and-reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
    Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Cc: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  25. @jjuhl @gregkh

    net: Fix references to out-of-scope variables in put_cmsg_compat()

    jjuhl authored gregkh committed
    [ Upstream commit 8188104 ]
    
    In net/compat.c::put_cmsg_compat() we may assign 'data' the address of
    either the 'ctv' or 'cts' local variables inside the 'if
    (!COMPAT_USE_64BIT_TIME)' branch.
    
    Those variables go out of scope at the end of the 'if' statement, so
    when we use 'data' further down in 'copy_to_user(CMSG_COMPAT_DATA(cm),
    data, cmlen - sizeof(struct compat_cmsghdr))' there's no telling what
    it may be refering to - not good.
    
    Fix the problem by simply giving 'ctv' and 'cts' function scope.
    
    Signed-off-by: Jesper Juhl <jj@chaosbits.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  26. @pcmoore @gregkh

    cipso: don't follow a NULL pointer when setsockopt() is called

    pcmoore authored gregkh committed
    [ Upstream commit 89d7ae3 ]
    
    As reported by Alan Cox, and verified by Lin Ming, when a user
    attempts to add a CIPSO option to a socket using the CIPSO_V4_TAG_LOCAL
    tag the kernel dies a terrible death when it attempts to follow a NULL
    pointer (the skb argument to cipso_v4_validate() is NULL when called via
    the setsockopt() syscall).
    
    This patch fixes this by first checking to ensure that the skb is
    non-NULL before using it to find the incoming network interface.  In
    the unlikely case where the skb is NULL and the user attempts to add
    a CIPSO option with the _TAG_LOCAL tag we return an error as this is
    not something we want to allow.
    
    A simple reproducer, kindly supplied by Lin Ming, although you must
    have the CIPSO DOI #3 configure on the system first or you will be
    caught early in cipso_v4_validate():
    
    	#include <sys/types.h>
    	#include <sys/socket.h>
    	#include <linux/ip.h>
    	#include <linux/in.h>
    	#include <string.h>
    
    	struct local_tag {
    		char type;
    		char length;
    		char info[4];
    	};
    
    	struct cipso {
    		char type;
    		char length;
    		char doi[4];
    		struct local_tag local;
    	};
    
    	int main(int argc, char **argv)
    	{
    		int sockfd;
    		struct cipso cipso = {
    			.type = IPOPT_CIPSO,
    			.length = sizeof(struct cipso),
    			.local = {
    				.type = 128,
    				.length = sizeof(struct local_tag),
    			},
    		};
    
    		memset(cipso.doi, 0, 4);
    		cipso.doi[3] = 3;
    
    		sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    		#define SOL_IP 0
    		setsockopt(sockfd, SOL_IP, IP_OPTIONS,
    			&cipso, sizeof(struct cipso));
    
    		return 0;
    	}
    
    CC: Lin Ming <mlin@ss.pku.edu.cn>
    Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  27. @gregkh

    caif: Fix access to freed pernet memory

    Sjur Brændeland authored gregkh committed
    [ Upstream commit 96f80d1 ]
    
    unregister_netdevice_notifier() must be called before
    unregister_pernet_subsys() to avoid accessing already freed
    pernet memory. This fixes the following oops when doing rmmod:
    
    Call Trace:
     [<ffffffffa0f802bd>] caif_device_notify+0x4d/0x5a0 [caif]
     [<ffffffff81552ba9>] unregister_netdevice_notifier+0xb9/0x100
     [<ffffffffa0f86dcc>] caif_device_exit+0x1c/0x250 [caif]
     [<ffffffff810e7734>] sys_delete_module+0x1a4/0x300
     [<ffffffff810da82d>] ? trace_hardirqs_on_caller+0x15d/0x1e0
     [<ffffffff813517de>] ? trace_hardirqs_on_thunk+0x3a/0x3
     [<ffffffff81696bad>] system_call_fastpath+0x1a/0x1f
    
    RIP
     [<ffffffffa0f7f561>] caif_get+0x51/0xb0 [caif]
    
    Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
    Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  28. @gregkh

    sctp: Fix list corruption resulting from freeing an association on a …

    Neil Horman authored gregkh committed
    …list
    
    [ Upstream commit 2eebc1e ]
    
    A few days ago Dave Jones reported this oops:
    
    [22766.294255] general protection fault: 0000 [#1] PREEMPT SMP
    [22766.295376] CPU 0
    [22766.295384] Modules linked in:
    [22766.387137]  ffffffffa169f292 6b6b6b6b6b6b6b6b ffff880147c03a90
    ffff880147c03a74
    [22766.387135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000
    [22766.387136] Process trinity-watchdo (pid: 10896, threadinfo ffff88013e7d2000,
    [22766.387137] Stack:
    [22766.387140]  ffff880147c03a10
    [22766.387140]  ffffffffa169f2b6
    [22766.387140]  ffff88013ed95728
    [22766.387143]  0000000000000002
    [22766.387143]  0000000000000000
    [22766.387143]  ffff880003fad062
    [22766.387144]  ffff88013c120000
    [22766.387144]
    [22766.387145] Call Trace:
    [22766.387145]  <IRQ>
    [22766.387150]  [<ffffffffa169f292>] ? __sctp_lookup_association+0x62/0xd0
    [sctp]
    [22766.387154]  [<ffffffffa169f2b6>] __sctp_lookup_association+0x86/0xd0 [sctp]
    [22766.387157]  [<ffffffffa169f597>] sctp_rcv+0x207/0xbb0 [sctp]
    [22766.387161]  [<ffffffff810d4da8>] ? trace_hardirqs_off_caller+0x28/0xd0
    [22766.387163]  [<ffffffff815827e3>] ? nf_hook_slow+0x133/0x210
    [22766.387166]  [<ffffffff815902fc>] ? ip_local_deliver_finish+0x4c/0x4c0
    [22766.387168]  [<ffffffff8159043d>] ip_local_deliver_finish+0x18d/0x4c0
    [22766.387169]  [<ffffffff815902fc>] ? ip_local_deliver_finish+0x4c/0x4c0
    [22766.387171]  [<ffffffff81590a07>] ip_local_deliver+0x47/0x80
    [22766.387172]  [<ffffffff8158fd80>] ip_rcv_finish+0x150/0x680
    [22766.387174]  [<ffffffff81590c54>] ip_rcv+0x214/0x320
    [22766.387176]  [<ffffffff81558c07>] __netif_receive_skb+0x7b7/0x910
    [22766.387178]  [<ffffffff8155856c>] ? __netif_receive_skb+0x11c/0x910
    [22766.387180]  [<ffffffff810d423e>] ? put_lock_stats.isra.25+0xe/0x40
    [22766.387182]  [<ffffffff81558f83>] netif_receive_skb+0x23/0x1f0
    [22766.387183]  [<ffffffff815596a9>] ? dev_gro_receive+0x139/0x440
    [22766.387185]  [<ffffffff81559280>] napi_skb_finish+0x70/0xa0
    [22766.387187]  [<ffffffff81559cb5>] napi_gro_receive+0xf5/0x130
    [22766.387218]  [<ffffffffa01c4679>] e1000_receive_skb+0x59/0x70 [e1000e]
    [22766.387242]  [<ffffffffa01c5aab>] e1000_clean_rx_irq+0x28b/0x460 [e1000e]
    [22766.387266]  [<ffffffffa01c9c18>] e1000e_poll+0x78/0x430 [e1000e]
    [22766.387268]  [<ffffffff81559fea>] net_rx_action+0x1aa/0x3d0
    [22766.387270]  [<ffffffff810a495f>] ? account_system_vtime+0x10f/0x130
    [22766.387273]  [<ffffffff810734d0>] __do_softirq+0xe0/0x420
    [22766.387275]  [<ffffffff8169826c>] call_softirq+0x1c/0x30
    [22766.387278]  [<ffffffff8101db15>] do_softirq+0xd5/0x110
    [22766.387279]  [<ffffffff81073bc5>] irq_exit+0xd5/0xe0
    [22766.387281]  [<ffffffff81698b03>] do_IRQ+0x63/0xd0
    [22766.387283]  [<ffffffff8168ee2f>] common_interrupt+0x6f/0x6f
    [22766.387283]  <EOI>
    [22766.387284]
    [22766.387285]  [<ffffffff8168eed9>] ? retint_swapgs+0x13/0x1b
    [22766.387285] Code: c0 90 5d c3 66 0f 1f 44 00 00 4c 89 c8 5d c3 0f 1f 00 55 48
    89 e5 48 83
    ec 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 <0f> b7 87 98 00 00 00
    48 89 fb
    49 89 f5 66 c1 c0 08 66 39 46 02
    [22766.387307]
    [22766.387307] RIP
    [22766.387311]  [<ffffffffa168a2c9>] sctp_assoc_is_match+0x19/0x90 [sctp]
    [22766.387311]  RSP <ffff880147c039b0>
    [22766.387142]  ffffffffa16ab120
    [22766.599537] ---[ end trace 3f6dae82e37b17f5 ]---
    [22766.601221] Kernel panic - not syncing: Fatal exception in interrupt
    
    It appears from his analysis and some staring at the code that this is likely
    occuring because an association is getting freed while still on the
    sctp_assoc_hashtable.  As a result, we get a gpf when traversing the hashtable
    while a freed node corrupts part of the list.
    
    Nominally I would think that an mibalanced refcount was responsible for this,
    but I can't seem to find any obvious imbalance.  What I did note however was
    that the two places where we create an association using
    sctp_primitive_ASSOCIATE (__sctp_connect and sctp_sendmsg), have failure paths
    which free a newly created association after calling sctp_primitive_ASSOCIATE.
    sctp_primitive_ASSOCIATE brings us into the sctp_sf_do_prm_asoc path, which
    issues a SCTP_CMD_NEW_ASOC side effect, which in turn adds a new association to
    the aforementioned hash table.  the sctp command interpreter that process side
    effects has not way to unwind previously processed commands, so freeing the
    association from the __sctp_connect or sctp_sendmsg error path would lead to a
    freed association remaining on this hash table.
    
    I've fixed this but modifying sctp_[un]hash_established to use hlist_del_init,
    which allows us to proerly use hlist_unhashed to check if the node is on a
    hashlist safely during a delete.  That in turn alows us to safely call
    sctp_unhash_established in the __sctp_connect and sctp_sendmsg error paths
    before freeing them, regardles of what the associations state is on the hash
    list.
    
    I noted, while I was doing this, that the __sctp_unhash_endpoint was using
    hlist_unhsashed in a simmilar fashion, but never nullified any removed nodes
    pointers to make that function work properly, so I fixed that up in a simmilar
    fashion.
    
    I attempted to test this using a virtual guest running the SCTP_RR test from
    netperf in a loop while running the trinity fuzzer, both in a loop.  I wasn't
    able to recreate the problem prior to this fix, nor was I able to trigger the
    failure after (neither of which I suppose is suprising).  Given the trace above
    however, I think its likely that this is what we hit.
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: davej@redhat.com
    CC: davej@redhat.com
    CC: "David S. Miller" <davem@davemloft.net>
    CC: Vlad Yasevich <vyasevich@gmail.com>
    CC: Sridhar Samudrala <sri@us.ibm.com>
    CC: linux-sctp@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  29. @gregkh

    sch_sfb: Fix missing NULL check

    Alan Cox authored gregkh committed
    [ Upstream commit 7ac2908 ]
    
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44461
    
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  30. @gregkh

    bnx2: Fix bug in bnx2_free_tx_skbs().

    Michael Chan authored gregkh committed
    [ Upstream commit c1f5163 ]
    
    In rare cases, bnx2x_free_tx_skbs() can unmap the wrong DMA address
    when it gets to the last entry of the tx ring.  We were not using
    the proper macro to skip the last entry when advancing the tx index.
    
    Reported-by: Zongyun Lai <zlai@vmware.com>
    Reviewed-by: Jeffrey Huang <huangjw@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  31. @gregkh

    net: Fix memory leak - vlan_info struct

    Amir Hanania authored gregkh committed
    [ Upstream commit efc73f4 ]
    
    In driver reload test there is a memory leak.
    The structure vlan_info was not freed when the driver was removed.
    It was not released since the nr_vids var is one after last vlan was removed.
    The nr_vids is one, since vlan zero is added to the interface when the interface
    is being set, but the vlan zero is not deleted at unregister.
    Fix - delete vlan zero when we unregister the device.
    
    Signed-off-by: Amir Hanania <amir.hanania@intel.com>
    Acked-by: John Fastabend <john.r.fastabend@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  32. @gregkh

    gianfar: fix potential sk_wmem_alloc imbalance

    Eric Dumazet authored gregkh committed
    [ Upstream commit 313b037 ]
    
    commit db83d13 (gianfar: Fix missing sock reference when
    processing TX time stamps) added a potential sk_wmem_alloc imbalance
    
    If the new skb has a different truesize than old one, we can get a
    negative sk_wmem_alloc once new skb is orphaned at TX completion.
    
    Now we no longer early orphan skbs in dev_hard_start_xmit(), this
    probably can lead to fatal bugs.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Manfred Rudigier <manfred.rudigier@omicron.at>
    Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
    Cc: Jiajun Wu <b06378@freescale.com>
    Cc: Andy Fleming <afleming@freescale.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  33. @gregkh

    netem: add limitation to reordered packets

    Eric Dumazet authored gregkh committed
    [ Upstream commit 960fb66 ]
    
    Fix two netem bugs :
    
    1) When a frame was dropped by tfifo_enqueue(), drop counter
       was incremented twice.
    
    2) When reordering is triggered, we enqueue a packet without
       checking queue limit. This can OOM pretty fast when this
       is repeated enough, since skbs are orphaned, no socket limit
       can help in this situation.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Mark Gordon <msg@google.com>
    Cc: Andreas Terzis <aterzis@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Hagen Paul Pfeifer <hagen@jauu.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  34. @gregkh

    atl1c: fix issue of transmit queue 0 timed out

    Cloud Ren authored gregkh committed
    [ Upstream commit b94e52f ]
    
    some people report atl1c could cause system hang with following
    kernel trace info:
    ---------------------------------------
    WARNING: at.../net/sched/sch_generic.c:258 dev_watchdog+0x1db/0x1d0()
    ...
    NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
    ...
    ---------------------------------------
    This is caused by netif_stop_queue calling when cable Link is down.
    So remove netif_stop_queue, because link_watch will take it over.
    
    Signed-off-by: xiong <xiong@qca.qualcomm.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Cloud Ren <cjren@qca.qualcomm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  35. @tytso @gregkh

    ext4: undo ext4_calc_metadata_amount if we fail to claim space

    tytso authored gregkh committed
    commit 03179fe upstream.
    
    The function ext4_calc_metadata_amount() has side effects, although
    it's not obvious from its function name.  So if we fail to claim
    space, regardless of whether we retry to claim the space again, or
    return an error, we need to undo these side effects.
    
    Otherwise we can end up incorrectly calculating the number of metadata
    blocks needed for the operation, which was responsible for an xfstests
    failure for test #271 when using an ext2 file system with delalloc
    enabled.
    
    Reported-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Something went wrong with that request. Please try again.