1. 05 May, 2015 40 commits
    • John Soni Jose's avatar
      be2iscsi: Fix kernel panic when device initialization fails · 7064c67d
      John Soni Jose authored
      commit 2e7cee02 upstream.
      
      Kernel panic was happening as iscsi_host_remove() was called on
      a host which was not yet added.
      Signed-off-by: default avatarJohn Soni Jose <sony.john-n@emulex.com>
      Reviewed-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7064c67d
    • Kailang Yang's avatar
      ALSA: hda/realtek - Make more stable to get pin sense for ALC283 · 5bb67025
      Kailang Yang authored
      commit a59d7199 upstream.
      
      Pin sense will active when power pin is wake up.
      Power pin will not wake up immediately during resume state.
      Add some delay to wait for power pin activated.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5bb67025
    • Al Viro's avatar
      ioctx_alloc(): fix vma (and file) leak on failure · 9e41babe
      Al Viro authored
      commit deeb8525 upstream.
      
      If we fail past the aio_setup_ring(), we need to destroy the
      mapping.  We don't need to care about anybody having found ctx,
      or added requests to it, since the last failure exit is exactly
      the failure to make ctx visible to lookups.
      
      Reproducer (based on one by Joe Mario <jmario@redhat.com>):
      
      void count(char *p)
      {
      	char s[80];
      	printf("%s: ", p);
      	fflush(stdout);
      	sprintf(s, "/bin/cat /proc/%d/maps|/bin/fgrep -c '/[aio] (deleted)'", getpid());
      	system(s);
      }
      
      int main()
      {
      	io_context_t *ctx;
      	int created, limit, i, destroyed;
      	FILE *f;
      
      	count("before");
      	if ((f = fopen("/proc/sys/fs/aio-max-nr", "r")) == NULL)
      		perror("opening aio-max-nr");
      	else if (fscanf(f, "%d", &limit) != 1)
      		fprintf(stderr, "can't parse aio-max-nr\n");
      	else if ((ctx = calloc(limit, sizeof(io_context_t))) == NULL)
      		perror("allocating aio_context_t array");
      	else {
      		for (i = 0, created = 0; i < limit; i++) {
      			if (io_setup(1000, ctx + created) == 0)
      				created++;
      		}
      		for (i = 0, destroyed = 0; i < created; i++)
      			if (io_destroy(ctx[i]) == 0)
      				destroyed++;
      		printf("created %d, failed %d, destroyed %d\n",
      			created, limit - created, destroyed);
      		count("after");
      	}
      }
      Found-by: default avatarJoe Mario <jmario@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9e41babe
    • Thomas Schlichter's avatar
      cpuidle: ACPI: do not overwrite name and description of C0 · eadf0253
      Thomas Schlichter authored
      commit c7e8bdf5 upstream.
      
      Fix a bug that leads to showing the name and description of C-state C0
      as "<null>" in sysfs after the ACPI C-states changed (e.g. after AC->DC
      or DC->AC
      transition).
      
      The function poll_idle_init() in drivers/cpuidle/driver.c initializes the
      state 0 during cpuidle_register_driver(), so we better do not overwrite it
      again with '\0' during acpi_processor_cst_has_changed().
      Signed-off-by: default avatarThomas Schlichter <thomas.schlichter@web.de>
      Reviewed-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      eadf0253
    • Marek Szyprowski's avatar
      [media] media: s5p-mfc: fix mmap support for 64bit arch · 70ab62c4
      Marek Szyprowski authored
      commit 05b676ab upstream.
      
      TASK_SIZE is depends on the systems architecture (32 or 64 bits) and it
      should not be used for defining offset boundary for mmaping buffers for
      CAPTURE and OUTPUT queues. This patch fixes support for MMAP calls on
      the CAPTURE queue on 64bit architectures (like ARM64).
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarKamil Debski <k.debski@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      70ab62c4
    • Hans Verkuil's avatar
      [media] sh_veu: v4l2_dev wasn't set · 255a698e
      Hans Verkuil authored
      commit ab312030 upstream.
      
      The v4l2_dev field of struct video_device must be set correctly.
      This was never done for this driver, so no video nodes were created
      anymore.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      255a698e
    • Dan Carpenter's avatar
      PCI: cpcihp: Add missing curly braces in cpci_configure_slot() · 36dea02f
      Dan Carpenter authored
      commit bc3b5b47 upstream.
      
      I don't have this hardware but it looks like we weren't adding bridge
      devices as intended.  Maybe the bridge is always the last device?
      
      Fixes: 05b12500 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      36dea02f
    • Neal Cardwell's avatar
      tcp: fix FRTO undo on cumulative ACK of SACKed range · 54695743
      Neal Cardwell authored
      [ Upstream commit 666b8051 ]
      
      On processing cumulative ACKs, the FRTO code was not checking the
      SACKed bit, meaning that there could be a spurious FRTO undo on a
      cumulative ACK of a previously SACKed skb.
      
      The FRTO code should only consider a cumulative ACK to indicate that
      an original/unretransmitted skb is newly ACKed if the skb was not yet
      SACKed.
      
      The effect of the spurious FRTO undo would typically be to make the
      connection think that all previously-sent packets were in flight when
      they really weren't, leading to a stall and an RTO.
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Fixes: e33099f9 ("tcp: implement RFC5682 F-RTO")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      54695743
    • Jonathan Davies's avatar
      xen-netfront: transmit fully GSO-sized packets · ab03d1dc
      Jonathan Davies authored
      commit 0c36820e upstream.
      
      xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
      GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
      bytes each. This slight reduction in the size of packets means a slight loss in
      efficiency.
      
      Since c/s 9ecd1a75, xen-netfront sets gso_max_size to
          XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
      where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.
      
      The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
      6c09fa09) in determining when to split an skb into two is
          sk->sk_gso_max_size - 1 - MAX_TCP_HEADER.
      
      So the maximum permitted size of an skb is calculated to be
          (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.
      
      Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
      Instead, there is no need to deviate from the default gso_max_size of 65536 as
      this already accommodates the size of the header.
      
      Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
      of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
      skbs of up to 65160 bytes (45 segments of 1448 bytes each).
      
      Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as
      it relates to the size of the whole packet, including the header.
      
      Fixes: 9ecd1a75 ("xen-netfront: reduce gso_max_size to account for max TCP header")
      Signed-off-by: default avatarJonathan Davies <jonathan.davies@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ab03d1dc
    • WANG Cong's avatar
      net: use for_each_netdev_safe() in rtnl_group_changelink() · 799ed863
      WANG Cong authored
      commit d079535d upstream.
      
      In case we move the whole dev group to another netns,
      we should call for_each_netdev_safe(), otherwise we get
      a soft lockup:
      
       NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ip:798]
       irq event stamp: 255424
       hardirqs last  enabled at (255423): [<ffffffff81a2aa95>] restore_args+0x0/0x30
       hardirqs last disabled at (255424): [<ffffffff81a2ad5a>] apic_timer_interrupt+0x6a/0x80
       softirqs last  enabled at (255422): [<ffffffff81079ebc>] __do_softirq+0x2c1/0x3a9
       softirqs last disabled at (255417): [<ffffffff8107a190>] irq_exit+0x41/0x95
       CPU: 0 PID: 798 Comm: ip Not tainted 4.0.0-rc4+ #881
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       task: ffff8800d1b88000 ti: ffff880119530000 task.ti: ffff880119530000
       RIP: 0010:[<ffffffff810cad11>]  [<ffffffff810cad11>] debug_lockdep_rcu_enabled+0x28/0x30
       RSP: 0018:ffff880119533778  EFLAGS: 00000246
       RAX: ffff8800d1b88000 RBX: 0000000000000002 RCX: 0000000000000038
       RDX: 0000000000000000 RSI: ffff8800d1b888c8 RDI: ffff8800d1b888c8
       RBP: ffff880119533778 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 000000000000b5c2 R12: 0000000000000246
       R13: ffff880119533708 R14: 00000000001d5a40 R15: ffff88011a7d5a40
       FS:  00007fc01315f740(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 00007f367a120988 CR3: 000000011849c000 CR4: 00000000000007f0
       Stack:
        ffff880119533798 ffffffff811ac868 ffffffff811ac831 ffffffff811ac828
        ffff8801195337c8 ffffffff811ac8c9 ffff8801195339b0 ffff8801197633e0
        0000000000000000 ffff8801195339b0 ffff8801195337d8 ffffffff811ad2d7
       Call Trace:
        [<ffffffff811ac868>] rcu_read_lock+0x37/0x6e
        [<ffffffff811ac831>] ? rcu_read_unlock+0x5f/0x5f
        [<ffffffff811ac828>] ? rcu_read_unlock+0x56/0x5f
        [<ffffffff811ac8c9>] __fget+0x2a/0x7a
        [<ffffffff811ad2d7>] fget+0x13/0x15
        [<ffffffff811be732>] proc_ns_fget+0xe/0x38
        [<ffffffff817c7714>] get_net_ns_by_fd+0x11/0x59
        [<ffffffff817df359>] rtnl_link_get_net+0x33/0x3e
        [<ffffffff817df3d7>] do_setlink+0x73/0x87b
        [<ffffffff810b28ce>] ? trace_hardirqs_off+0xd/0xf
        [<ffffffff81a2aa95>] ? retint_restore_args+0xe/0xe
        [<ffffffff817e0301>] rtnl_newlink+0x40c/0x699
        [<ffffffff817dffe0>] ? rtnl_newlink+0xeb/0x699
        [<ffffffff81a29246>] ? _raw_spin_unlock+0x28/0x33
        [<ffffffff8143ed1e>] ? security_capable+0x18/0x1a
        [<ffffffff8107da51>] ? ns_capable+0x4d/0x65
        [<ffffffff817de5ce>] rtnetlink_rcv_msg+0x181/0x194
        [<ffffffff817de407>] ? rtnl_lock+0x17/0x19
        [<ffffffff817de407>] ? rtnl_lock+0x17/0x19
        [<ffffffff817de44d>] ? __rtnl_unlock+0x17/0x17
        [<ffffffff818327c6>] netlink_rcv_skb+0x4d/0x93
        [<ffffffff817de42f>] rtnetlink_rcv+0x26/0x2d
        [<ffffffff81830f18>] netlink_unicast+0xcb/0x150
        [<ffffffff8183198e>] netlink_sendmsg+0x501/0x523
        [<ffffffff8115cba9>] ? might_fault+0x59/0xa9
        [<ffffffff817b5398>] ? copy_from_user+0x2a/0x2c
        [<ffffffff817b7b74>] sock_sendmsg+0x34/0x3c
        [<ffffffff817b7f6d>] ___sys_sendmsg+0x1b8/0x255
        [<ffffffff8115c5eb>] ? handle_pte_fault+0xbd5/0xd4a
        [<ffffffff8100a2b0>] ? native_sched_clock+0x35/0x37
        [<ffffffff8109e94b>] ? sched_clock_local+0x12/0x72
        [<ffffffff8109eb9c>] ? sched_clock_cpu+0x9e/0xb7
        [<ffffffff810cadbf>] ? rcu_read_lock_held+0x3b/0x3d
        [<ffffffff811ac1d8>] ? __fcheck_files+0x4c/0x58
        [<ffffffff811ac946>] ? __fget_light+0x2d/0x52
        [<ffffffff817b8adc>] __sys_sendmsg+0x42/0x60
        [<ffffffff817b8b0c>] SyS_sendmsg+0x12/0x1c
        [<ffffffff81a29e32>] system_call_fastpath+0x12/0x17
      
      Fixes: e7ed828f ("netlink: support setting devgroup parameters")
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      799ed863
    • Michal Kubeček's avatar
      tcp: prevent fetching dst twice in early demux code · 5eb14979
      Michal Kubeček authored
      [ Upstream commit d0c294c5 ]
      
      On s390x, gcc 4.8 compiles this part of tcp_v6_early_demux()
      
              struct dst_entry *dst = sk->sk_rx_dst;
      
              if (dst)
                      dst = dst_check(dst, inet6_sk(sk)->rx_dst_cookie);
      
      to code reading sk->sk_rx_dst twice, once for the test and once for
      the argument of ip6_dst_check() (dst_check() is inline). This allows
      ip6_dst_check() to be called with null first argument, causing a crash.
      
      Protect sk->sk_rx_dst access by ACCESS_ONCE() both in IPv4 and IPv6
      TCP early demux code.
      
      Fixes: 41063e9d ("ipv4: Early TCP socket demux.")
      Fixes: c7109986 ("ipv6: Early TCP socket demux")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5eb14979
    • Shachar Raindel's avatar
      IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic · 5eafec14
      Shachar Raindel authored
      commit 8494057a upstream.
      
      Properly verify that the resulting page aligned end address is larger
      than both the start address and the length of the memory area requested.
      
      Both the start and length arguments for ib_umem_get are controlled by
      the user. A misbehaving user can provide values which will cause an
      integer overflow when calculating the page aligned end address.
      
      This overflow can cause also miscalculation of the number of pages
      mapped, and additional logic issues.
      
      Addresses: CVE-2014-8159
      Signed-off-by: default avatarShachar Raindel <raindel@mellanox.com>
      Signed-off-by: default avatarJack Morgenstein <jackm@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5eafec14
    • Johannes Berg's avatar
      mac80211: fix RX A-MPDU session reorder timer deletion · e4c79c12
      Johannes Berg authored
      commit 788211d8 upstream.
      
      There's an issue with the way the RX A-MPDU reorder timer is
      deleted that can cause a kernel crash like this:
      
       * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
       * station is destroyed
       * reorder timer fires before ieee80211_free_tid_rx() runs,
         accessing the station, thus potentially crashing due to
         the use-after-free
      
      The station deletion is protected by synchronize_net(), but
      that isn't enough -- ieee80211_free_tid_rx() need not have
      run when that returns (it deletes the timer.) We could use
      rcu_barrier() instead of synchronize_net(), but that's much
      more expensive.
      
      Instead, to fix this, add a field tracking that the session
      is being deleted. In this case, the only re-arming of the
      timer happens with the reorder spinlock held, so make that
      code not rearm it if the session is being deleted and also
      delete the timer after setting that field. This ensures the
      timer cannot fire after ___ieee80211_stop_rx_ba_session()
      returns, which fixes the problem.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e4c79c12
    • Stefan Lippers-Hollmann's avatar
      x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk · ff3dbaf1
      Stefan Lippers-Hollmann authored
      commit 80313b30 upstream.
      
      The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
      both BIOS and UEFI mode while rebooting unless reboot=pci is
      used. Add a quirk to reboot via the pci method.
      
      The problem is very intermittent and hard to debug, it might succeed
      rebooting just fine 40 times in a row - but fails half a dozen times
      the next day. It seems to be slightly less common in BIOS CSM mode
      than native UEFI (with the CSM disabled), but it does happen in either
      mode. Since I've started testing this patch in late january, rebooting
      has been 100% reliable.
      
      Most of the time it already hangs during POST, but occasionally it
      might even make it through the bootloader and the kernel might even
      start booting, but then hangs before the mode switch. The same symptoms
      occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
      kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
      Upgrading to the most current mainboard firmware of the ASRock
      Q1900DC-ITX, version 1.20, does not improve the situation.
      
      ( Searching the web seems to suggest that other Bay Trail-D mainboards
        might be affected as well. )
      --
      Signed-off-by: default avatarStefan Lippers-Hollmann <s.l-h@gmx.de>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mirSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ff3dbaf1
    • Peter Ujfalusi's avatar
      dmaengine: omap-dma: Fix memory leak when terminating running transfer · 11890cda
      Peter Ujfalusi authored
      commit 02d88b73 upstream.
      
      In omap_dma_start_desc the vdesc->node is removed from the virt-dma
      framework managed lists (to be precise from the desc_issued list).
      If a terminate_all comes before the transfer finishes the omap_desc will
      not be freed up because it is not in any of the lists and we stopped the
      DMA channel so the transfer will not going to complete.
      There is no special sequence for leaking memory when using cyclic (audio)
      transfer: with every start and stop of a cyclic transfer the driver leaks
      struct omap_desc worth of memory.
      
      Free up the allocated memory directly in omap_dma_terminate_all() since the
      framework will not going to do that for us.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      CC: <linux-omap@vger.kernel.org>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      11890cda
    • Petr Kulhavy's avatar
      dmaengine: edma: fix memory leak when terminating running transfers · 17a9e8d1
      Petr Kulhavy authored
      commit 5ca9e7ce upstream.
      
      If edma_terminate_all() was called while a transfer was running (i.e. after
      edma_execute() but before edma_callback()) the echan->edesc was not freed.
      
      This was due to the fact that a running transfer is on none of the
      vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
      removes it from the desc_issued list), so the vchan_dma_desc_free_list()
      called at the end of edma_terminate_all() didn't find it and didn't free it.
      
      This bug was found on an AM1808 based hardware (very similar to da850evm,
      however using the second MMC/SD controller), where intense operations on the SD
      card wasted the device 128MB RAM within a couple of days.
      
      Peter Ujfalusi:
      The issue is even more severe since it affects cyclic (audio) transfers as
      well. In this case starting/stopping audio will results memory leak.
      Signed-off-by: default avatarPetr Kulhavy <petr@barix.com>
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      CC: <linux-omap@vger.kernel.org>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      17a9e8d1
    • Darshana Padmadas's avatar
      iio: imu: Use iio_trigger_get for indio_dev->trig assignment · 040690b9
      Darshana Padmadas authored
      commit 4ce7ca89 upstream.
      
      This patch uses iio_trigger_get to increment the reference
      count of trigger device, to avoid incorrect assignment.
      Can result in a null pointer dereference during removal if the
      trigger has been changed before removal.
      
      This patch refers to a similar situation encountered through the
      following discussion:
      http://www.spinics.net/lists/linux-iio/msg13669.htmlSigned-off-by: default avatarDarshana Padmadas <darshanapadmadas@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      040690b9
    • David Miller's avatar
      radeon: Do not directly dereference pointers to BIOS area. · c3e6692b
      David Miller authored
      commit f2c9e560 upstream.
      
      Use readb() and memcpy_fromio() accessors instead.
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c3e6692b
    • Stefan Agner's avatar
      tty: serial: fsl_lpuart: clear receive flag on FIFO flush · c839086c
      Stefan Agner authored
      commit 8e4934c6 upstream.
      
      When the receiver was enabled during startup, a character could
      have been in the FIFO when the UART get initially used. The
      driver configures the (receive) watermark level, and flushes the
      FIFO. However, the receive flag (RDRF) could still be set at that
      stage (as mentioned in the register description of UARTx_RWFIFO).
      This leads to an interrupt which won't be handled properly in
      interrupt mode: The receive interrupt function lpuart_rxint checks
      the FIFO count, which is 0 at that point (due to the flush
      during initialization). The problem does not manifest when using
      DMA to receive characters.
      
      Fix this situation by explicitly read the status register, which
      leads to clearing of the RDRF flag. Due to the flush just after
      the status flag read, a explicit data read is not to required.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c839086c
    • Doug Goldstein's avatar
      USB: ftdi_sio: Use jtag quirk for SNAP Connect E10 · 20b4931d
      Doug Goldstein authored
      commit b229a0f8 upstream.
      
      This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order
      to avoid attaching a TTY to the JTAG port as this board is based on the
      CALAO Systems reference design and needs the same fix up.
      Signed-off-by: default avatarDoug Goldstein <cardoe@cardoe.com>
      [johan: clean up probe logic ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      20b4931d
    • Lu Baolu's avatar
      usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers · 77075554
      Lu Baolu authored
      commit 227a4fd8 upstream.
      
      When a device with an isochronous endpoint is plugged into the Intel
      xHCI host controller, and the driver submits multiple frames per URB,
      the xHCI driver will set the Block Event Interrupt (BEI) flag on all
      but the last TD for the URB. This causes the host controller to place
      an event on the event ring, but not send an interrupt. When the last
      TD for the URB completes, BEI is cleared, and we get an interrupt for
      the whole URB.
      
      However, under Intel xHCI host controllers, if the event ring is full
      of events from transfers with BEI set,  an "Event Ring is Full" event
      will be posted to the last entry of the event ring,  but no interrupt
      is generated. Host will cease all transfer and command executions and
      wait until software completes handling the pending events in the event
      ring.  That means xHC stops, but event of "event ring is full" is not
      notified. As the result, the xHC looks like dead to user.
      
      This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
      it should be backported to kernels as old as 3.0, that contains the
      commit 69e848c2 ("Intel xhci: Support EHCI/xHCI port switching.").
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Tested-by: default avatarAlistair Grant <akgrant0710@gmail.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      77075554
    • Lu Baolu's avatar
      usb: xhci: handle Config Error Change (CEC) in xhci driver · cc480a2f
      Lu Baolu authored
      commit 9425183d upstream.
      
      Linux xHCI driver doesn't report and handle port cofig error change.
      If Port Configure Error for root hub port occurs, CEC bit in PORTSC
      would be set by xHC and remains 1. This happends when the root port
      fails to configure its link partner, e.g. the port fails to exchange
      port capabilities information using Port Capability LMPs.
      
      Then the Port Status Change Events will be blocked until all status
      change bits(CEC is one of the change bits) are cleared('0') (refer to
      xHCI spec 4.19.2). Otherwise, the port status change event for this
      root port will not be generated anymore, then root port would look
      like dead for user and can't be recovered until a Host Controller
      Reset(HCRST).
      
      This patch is to check CEC bit in PORTSC in xhci_get_port_status()
      and set a Config Error in the return status if CEC is set. This will
      cause a ClearPortFeature request, where CEC bit is cleared in
      xhci_clear_port_change_bit().
      
      [The commit log is based on initial Marvell patch posted at
      http://marc.info/?l=linux-kernel&m=142323612321434&w=2]
      Reported-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cc480a2f
    • Andreas Werner's avatar
      can: flexcan: Deferred on Regulator return EPROBE_DEFER · 8dee2bb8
      Andreas Werner authored
      commit 555828ef upstream.
      
      Return EPROBE_DEFER if Regulator returns EPROBE_DEFER
      
      If the Flexcan driver is built into kernel and a regulator is used to
      enable the CAN transceiver, the Flexcan driver may not use the regulator.
      
      When initializing the Flexcan device with a regulator defined in the device
      tree, but not initialized, the regulator subsystem returns EPROBE_DEFER, hence
      the Flexcan init fails.
      
      The solution for this is to return EPROBE_DEFER if regulator is not initialized
      and wait until the regulator is initialized.
      Signed-off-by: default avatarAndreas Werner <kernel@andy89.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8dee2bb8
    • David Disseldorp's avatar
      cifs: fix use-after-free bug in find_writable_file · df98f851
      David Disseldorp authored
      commit e1e9bda2 upstream.
      
      Under intermittent network outages, find_writable_file() is susceptible
      to the following race condition, which results in a user-after-free in
      the cifs_writepages code-path:
      
      Thread 1                                        Thread 2
      ========                                        ========
      
      inv_file = NULL
      refind = 0
      spin_lock(&cifs_file_list_lock)
      
      // invalidHandle found on openFileList
      
      inv_file = open_file
      // inv_file->count currently 1
      
      cifsFileInfo_get(inv_file)
      // inv_file->count = 2
      
      spin_unlock(&cifs_file_list_lock);
      
      cifs_reopen_file()                            cifs_close()
      // fails (rc != 0)                            ->cifsFileInfo_put()
                                             spin_lock(&cifs_file_list_lock)
                                             // inv_file->count = 1
                                             spin_unlock(&cifs_file_list_lock)
      
      spin_lock(&cifs_file_list_lock);
      list_move_tail(&inv_file->flist,
            &cifs_inode->openFileList);
      spin_unlock(&cifs_file_list_lock);
      
      cifsFileInfo_put(inv_file);
      ->spin_lock(&cifs_file_list_lock)
      
        // inv_file->count = 0
        list_del(&cifs_file->flist);
        // cleanup!!
        kfree(cifs_file);
      
        spin_unlock(&cifs_file_list_lock);
      
      spin_lock(&cifs_file_list_lock);
      ++refind;
      // refind = 1
      goto refind_writable;
      
      At this point we loop back through with an invalid inv_file pointer
      and a refind value of 1. On second pass, inv_file is not overwritten on
      openFileList traversal, and is subsequently dereferenced.
      Signed-off-by: default avatarDavid Disseldorp <ddiss@suse.de>
      Reviewed-by: default avatarJeff Layton <jlayton@samba.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      df98f851
    • Sachin Prabhu's avatar
      cifs: smb2_clone_range() - exit on unhandled error · 24cc3584
      Sachin Prabhu authored
      commit 2477bc58 upstream.
      
      While attempting to clone a file on a samba server, we receive a
      STATUS_INVALID_DEVICE_REQUEST. This is mapped to -EOPNOTSUPP which
      isn't handled in smb2_clone_range(). We end up looping in the while loop
      making same call to the samba server over and over again.
      
      The proposed fix is to exit and return the error value when encountered
      with an unhandled error.
      Signed-off-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      24cc3584
    • Nathaniel W Filardo's avatar
      USB: keyspan_pda: add new device id · 38975ff9
      Nathaniel W Filardo authored
      commit 5e71fc86 upstream.
      
      Add USB VID/PID for Xircom PGMFHUB USB/serial component.  (The hub and SCSI
      bridge on that hardware are recognized out of the box by existing drivers.)
      Tested VID/PID using new_id and loopback connection and was met with
      success, but that's all the testing done.
      Signed-off-by: default avatarNathaniel Wesley Filardo <nwf@cs.jhu.edu>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      38975ff9
    • Emmanuel Grumbach's avatar
      iwlwifi: dvm: run INIT firmware again upon .start() · 7b1d13cf
      Emmanuel Grumbach authored
      commit 9c8928f5 upstream.
      
      The assumption before this patch was that we don't need to
      run again the INIT firmware after the system booted. The
      INIT firmware runs calibrations which impact the physical
      layer's behavior.
      Users reported that it may be helpful to run these
      calibrations again every time the interface is brought up.
      The penatly is minimal, since the calibrations run fast.
      This fixes:
      https://bugzilla.kernel.org/show_bug.cgi?id=94341Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7b1d13cf
    • Doug Goldstein's avatar
      USB: ftdi_sio: Added custom PID for Synapse Wireless product · 3a848c95
      Doug Goldstein authored
      commit 4899c054 upstream.
      
      Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their
      SNAP Stick 200 product.
      Signed-off-by: default avatarDoug Goldstein <cardoe@cardoe.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3a848c95
    • Martin Fuzzey's avatar
      iio: core: Fix double free. · e3758a0d
      Martin Fuzzey authored
      commit c1b03ab5 upstream.
      
      When an error occurred during event registration memory was freed twice
      resulting in kernel memory corruption and a crash in unrelated code.
      
      The problem was caused by
      	iio_device_unregister_eventset()
      	iio_device_unregister_sysfs()
      
      being called twice, once on the error path and then
      again via iio_dev_release().
      
      Fix this by making these two functions idempotent so they
      may be called multiple times.
      
      The problem was observed before applying
      	78b33216 iio:core: Handle error when mask type is not separate
      Signed-off-by: default avatarMartin Fuzzey <mfuzzey@parkeon.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e3758a0d
    • Viorel Suman's avatar
      iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo · 66e5781f
      Viorel Suman authored
      commit 4dac0a8e upstream.
      
      A hardware fifo reset always imply an invalidation of the
      existing timestamps, so we'll clear timestamps fifo on
      successfull hardware fifo reset.
      Signed-off-by: default avatarViorel Suman <viorel.suman@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      66e5781f
    • Octavian Purdila's avatar
      iio: fix drivers that check buffer->scan_mask · 9605bbf0
      Octavian Purdila authored
      commit 70dddeee upstream.
      
      If the in-kernel push interface is used we may have a different masks
      on the device buffer and the kernel buffer and in this case the device
      should generate data for the reunion of the buffers, which is
      available at indio_dev->active_scan_mask.
      
      Compiled tested only except for bmc150-accel which was tested at
      runtime with the hardware.
      Signed-off-by: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      [ luis: backported to 3.16: dropped changes to:
        - drivers/iio/accel/bmc150-accel.c
        - drivers/iio/accel/kxcjk-1013.c
        - drivers/iio/gyro/bmg160.c
        - drivers/iio/imu/kmx61.c
        - drivers/iio/proximity/sx9500.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9605bbf0
    • Tejun Heo's avatar
      writeback: fix possible underflow in write bandwidth calculation · 8e9be18f
      Tejun Heo authored
      commit c72efb65 upstream.
      
      From 1ebf33901ecc75d9496862dceb1ef0377980587c Mon Sep 17 00:00:00 2001
      From: Tejun Heo <tj@kernel.org>
      Date: Mon, 23 Mar 2015 00:08:19 -0400
      
      2f800fbd ("writeback: fix dirtied pages accounting on redirty")
      introduced account_page_redirty() which reverts stat updates for a
      redirtied page, making BDI_DIRTIED no longer monotonically increasing.
      
      bdi_update_write_bandwidth() uses the delta in BDI_DIRTIED as the
      basis for bandwidth calculation.  While unlikely, since the above
      patch, the newer value may be lower than the recorded past value and
      underflow the bandwidth calculation leading to a wild result.
      
      Fix it by subtracing min of the old and new values when calculating
      delta.  AFAIK, there hasn't been any report of it happening but the
      resulting erratic behavior would be non-critical and temporary, so
      it's possible that the issue is happening without being reported.  The
      risk of the fix is very low, so tagged for -stable.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Greg Thelen <gthelen@google.com>
      Fixes: 2f800fbd ("writeback: fix dirtied pages accounting on redirty")
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8e9be18f
    • Vineet Gupta's avatar
      ARC: SA_SIGINFO ucontext regs off-by-one · 218bb3b8
      Vineet Gupta authored
      commit 6914e1e3 upstream.
      
      The regfile provided to SA_SIGINFO signal handler as ucontext was off by
      one due to pt_regs gutter cleanups in 2013.
      
      Before handling signal, user pt_regs are copied onto user_regs_struct and copied
      back later. Both structs are binary compatible. This was all fine until
      commit 2fa91904 (ARC: pt_regs update #2) which removed the empty stack slot
      at top of pt_regs (corresponding to first pad) and made the corresponding
      fixup in struct user_regs_struct (the pad in there was moved out of
      @scratch - not removed altogether as it is part of ptrace ABI)
      
       struct user_regs_struct {
      +       long pad;
              struct {
      -               long pad;
                      long bta, lp_start, lp_end,....
              } scratch;
       ...
       }
      
      This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and
      signal code needs to user_regs_struct.scratch to reflect it as pt_regs,
      which is what this commit does.
      
      This problem was hidden for 2 years, because both save/restore, despite
      using wrong location, were using the same location. Only an interim
      inspection (reproducer below) exposed the issue.
      
           void handle_segv(int signo, siginfo_t *info, void *context)
           {
       	ucontext_t *uc = context;
      	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
      
      	printf("regs %x %x\n",               <=== prints 7 8 (vs. 8 9)
                     regs->scratch.r8, regs->scratch.r9);
           }
      
           int main()
           {
      	struct sigaction sa;
      
      	sa.sa_sigaction = handle_segv;
      	sa.sa_flags = SA_SIGINFO;
      	sigemptyset(&sa.sa_mask);
      	sigaction(SIGSEGV, &sa, NULL);
      
      	asm volatile(
      	"mov	r7, 7	\n"
      	"mov	r8, 8	\n"
      	"mov	r9, 9	\n"
      	"mov	r10, 10	\n"
      	:::"r7","r8","r9","r10");
      
      	*((unsigned int*)0x10) = 0;
           }
      
      Fixes: 2fa91904 "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs"
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      218bb3b8
    • Sergei Antonov's avatar
      hfsplus: fix B-tree corruption after insertion at position 0 · b5ef8af2
      Sergei Antonov authored
      commit 98cf21c6 upstream.
      
      Fix B-tree corruption when a new record is inserted at position 0 in the
      node in hfs_brec_insert().  In this case a hfs_brec_update_parent() is
      called to update the parent index node (if exists) and it is passed
      hfs_find_data with a search_key containing a newly inserted key instead
      of the key to be updated.  This results in an inconsistent index node.
      The bug reproduces on my machine after an extents overflow record for
      the catalog file (CNID=4) is inserted into the extents overflow B-tree.
      Because of a low (reserved) value of CNID=4, it has to become the first
      record in the first leaf node.
      
      The resulting first leaf node is correct:
      
        ----------------------------------------------------
        | key0.CNID=4 | key1.CNID=123 | key2.CNID=456, ... |
        ----------------------------------------------------
      
      But the parent index key0 still contains the previous key CNID=123:
      
        -----------------------
        | key0.CNID=123 | ... |
        -----------------------
      
      A change in hfs_brec_insert() makes hfs_brec_update_parent() work
      correctly by preventing it from getting fd->record=-1 value from
      __hfs_brec_find().
      
      Along the way, I removed duplicate code with unification of the if
      condition.  The resulting code is equivalent to the original code
      because node is never 0.
      
      Also hfs_brec_update_parent() will now return an error after getting a
      negative fd->record value.  However, the return value of
      hfs_brec_update_parent() is not checked anywhere in the file and I'm
      leaving it unchanged by this patch.  brec.c lacks error checking after
      some other calls too, but this issue is of less importance than the one
      being fixed by this patch.
      Signed-off-by: default avatarSergei Antonov <saproj@gmail.com>
      Cc: Joe Perches <joe@perches.com>
      Reviewed-by: default avatarVyacheslav Dubeyko <slava@dubeyko.com>
      Acked-by: default avatarHin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Anton Altaparmakov <aia21@cam.ac.uk>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b5ef8af2
    • Gu Zheng's avatar
      mm/memory hotplug: postpone the reset of obsolete pgdat · 4d751774
      Gu Zheng authored
      commit b0dc3a34 upstream.
      
      Qiu Xishi reported the following BUG when testing hot-add/hot-remove node under
      stress condition:
      
        BUG: unable to handle kernel paging request at 0000000000025f60
        IP: next_online_pgdat+0x1/0x50
        PGD 0
        Oops: 0000 [#1] SMP
        ACPI: Device does not support D3cold
        Modules linked in: fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod coretemp mperf crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 pcspkr microcode igb dca i2c_algo_bit ipv6 megaraid_sas iTCO_wdt i2c_i801 i2c_core iTCO_vendor_support tg3 sg hwmon ptp lpc_ich pps_core mfd_core acpi_pad rtc_cmos button ext3 jbd mbcache sd_mod crc_t10dif scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh ahci libahci libata scsi_mod [last unloaded: rasf]
        CPU: 23 PID: 238 Comm: kworker/23:1 Tainted: G           O 3.10.15-5885-euler0302 #1
        Hardware name: HUAWEI TECHNOLOGIES CO.,LTD. Huawei N1/Huawei N1, BIOS V100R001 03/02/2015
        Workqueue: events vmstat_update
        task: ffffa800d32c0000 ti: ffffa800d32ae000 task.ti: ffffa800d32ae000
        RIP: 0010: next_online_pgdat+0x1/0x50
        RSP: 0018:ffffa800d32afce8  EFLAGS: 00010286
        RAX: 0000000000001440 RBX: ffffffff81da53b8 RCX: 0000000000000082
        RDX: 0000000000000000 RSI: 0000000000000082 RDI: 0000000000000000
        RBP: ffffa800d32afd28 R08: ffffffff81c93bfc R09: ffffffff81cbdc96
        R10: 00000000000040ec R11: 00000000000000a0 R12: ffffa800fffb3440
        R13: ffffa800d32afd38 R14: 0000000000000017 R15: ffffa800e6616800
        FS:  0000000000000000(0000) GS:ffffa800e6600000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000025f60 CR3: 0000000001a0b000 CR4: 00000000001407e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
          refresh_cpu_vm_stats+0xd0/0x140
          vmstat_update+0x11/0x50
          process_one_work+0x194/0x3d0
          worker_thread+0x12b/0x410
          kthread+0xc6/0xd0
          ret_from_fork+0x7c/0xb0
      
      The cause is the "memset(pgdat, 0, sizeof(*pgdat))" at the end of
      try_offline_node, which will reset all the content of pgdat to 0, as the
      pgdat is accessed lock-free, so that the users still using the pgdat
      will panic, such as the vmstat_update routine.
      
      process A:				offline node XX:
      
      vmstat_updat()
         refresh_cpu_vm_stats()
           for_each_populated_zone()
             find online node XX
           cond_resched()
      					offline cpu and memory, then try_offline_node()
      					node_set_offline(nid), and memset(pgdat, 0, sizeof(*pgdat))
             zone = next_zone(zone)
               pg_data_t *pgdat = zone->zone_pgdat;  // here pgdat is NULL now
                 next_online_pgdat(pgdat)
                   next_online_node(pgdat->node_id);  // NULL pointer access
      
      So the solution here is postponing the reset of obsolete pgdat from
      try_offline_node() to hotadd_new_pgdat(), and just resetting
      pgdat->nr_zones and pgdat->classzone_idx to be 0 rather than the memset
      0 to avoid breaking pointer information in pgdat.
      Signed-off-by: default avatarGu Zheng <guz.fnst@cn.fujitsu.com>
      Reported-by: default avatarXishi Qiu <qiuxishi@huawei.com>
      Suggested-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Xie XiuQi <xiexiuqi@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      4d751774
    • Leon Yu's avatar
      mm: fix anon_vma->degree underflow in anon_vma endless growing prevention · ed3d98af
      Leon Yu authored
      commit 3fe89b3e upstream.
      
      I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after
      upgrading to 3.19 and had no luck with 4.0-rc1 neither.
      
      So, after looking into new logic introduced by commit 7a3ef208 ("mm:
      prevent endless growth of anon_vma hierarchy"), I found chances are that
      unlink_anon_vmas() is called without incrementing dst->anon_vma->degree
      in anon_vma_clone() due to allocation failure.  If dst->anon_vma is not
      NULL in error path, its degree will be incorrectly decremented in
      unlink_anon_vmas() and eventually underflow when exiting as a result of
      another call to unlink_anon_vmas().  That's how "kernel BUG at
      mm/rmap.c:399!" is triggered for me.
      
      This patch fixes the underflow by dropping dst->anon_vma when allocation
      fails.  It's safe to do so regardless of original value of dst->anon_vma
      because dst->anon_vma doesn't have valid meaning if anon_vma_clone()
      fails.  Besides, callers don't care dst->anon_vma in such case neither.
      
      Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as
      anon_vma_clone() now does the work.
      
      [akpm@linux-foundation.org: tweak comment]
      Fixes: 7a3ef208 ("mm: prevent endless growth of anon_vma hierarchy")
      Signed-off-by: default avatarLeon Yu <chianglungyu@gmail.com>
      Signed-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ed3d98af
    • Joe Perches's avatar
      selinux: fix sel_write_enforce broken return value · cf781cbc
      Joe Perches authored
      commit 6436a123 upstream.
      
      Return a negative error value like the rest of the entries in this function.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      [PM: tweaked subject line]
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cf781cbc
    • Catalin Marinas's avatar
      arm64: Use the reserved TTBR0 if context switching to the init_mm · 930792ab
      Catalin Marinas authored
      commit e53f21bc upstream.
      
      The idle_task_exit() function may call switch_mm() with next ==
      &init_mm. On arm64, init_mm.pgd cannot be used for user mappings, so
      this patch simply sets the reserved TTBR0.
      Reported-by: default avatarJon Medhurst (Tixy) <tixy@linaro.org>
      Tested-by: default avatarJon Medhurst (Tixy) <tixy@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      930792ab
    • Peter Zijlstra's avatar
      perf: Fix irq_work 'tail' recursion · 464ab131
      Peter Zijlstra authored
      commit d525211f upstream.
      
      Vince reported a watchdog lockup like:
      
      	[<ffffffff8115e114>] perf_tp_event+0xc4/0x210
      	[<ffffffff810b4f8a>] perf_trace_lock+0x12a/0x160
      	[<ffffffff810b7f10>] lock_release+0x130/0x260
      	[<ffffffff816c7474>] _raw_spin_unlock_irqrestore+0x24/0x40
      	[<ffffffff8107bb4d>] do_send_sig_info+0x5d/0x80
      	[<ffffffff811f69df>] send_sigio_to_task+0x12f/0x1a0
      	[<ffffffff811f71ce>] send_sigio+0xae/0x100
      	[<ffffffff811f72b7>] kill_fasync+0x97/0xf0
      	[<ffffffff8115d0b4>] perf_event_wakeup+0xd4/0xf0
      	[<ffffffff8115d103>] perf_pending_event+0x33/0x60
      	[<ffffffff8114e3fc>] irq_work_run_list+0x4c/0x80
      	[<ffffffff8114e448>] irq_work_run+0x18/0x40
      	[<ffffffff810196af>] smp_trace_irq_work_interrupt+0x3f/0xc0
      	[<ffffffff816c99bd>] trace_irq_work_interrupt+0x6d/0x80
      
      Which is caused by an irq_work generating new irq_work and therefore
      not allowing forward progress.
      
      This happens because processing the perf irq_work triggers another
      perf event (tracepoint stuff) which in turn generates an irq_work ad
      infinitum.
      
      Avoid this by raising the recursion counter in the irq_work -- which
      effectively disables all software events (including tracepoints) from
      actually triggering again.
      Reported-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Tested-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/20150219170311.GH21418@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      464ab131
    • Markos Chandras's avatar
      net: ethernet: pcnet32: Setup the SRAM and NOUFLO on Am79C97{3, 5} · 4235c2c4
      Markos Chandras authored
      commit 87f966d9 upstream.
      
      On a MIPS Malta board, tons of fifo underflow errors have been observed
      when using u-boot as bootloader instead of YAMON. The reason for that
      is that YAMON used to set the pcnet device to SRAM mode but u-boot does
      not. As a result, the default Tx threshold (64 bytes) is now too small to
      keep the fifo relatively used and it can result to Tx fifo underflow errors.
      As a result of which, it's best to setup the SRAM on supported controllers
      so we can always use the NOUFLO bit.
      
      Cc: <netdev@vger.kernel.org>
      Cc: <linux-kernel@vger.kernel.org>
      Cc: Don Fry <pcnet32@frontier.com>
      Signed-off-by: default avatarMarkos Chandras <markos.chandras@imgtec.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      4235c2c4