1
0
Fork 0
Commit Graph

533801 Commits (b179b037e568a27ab3e8f5bedea1f4455aba7378)

Author SHA1 Message Date
Yuval Shaia c42687784b IB/ipoib: Scatter-Gather support in connected mode
By default, IPoIB-CM driver uses 64k MTU. Larger MTU gives better
performance.
This MTU plus overhead puts the memory allocation for IP based packets at
32 4k pages (order 5), which have to be contiguous.
When the system memory under pressure, it was observed that allocating 128k
contiguous physical memory is difficult and causes serious errors (such as
system becomes unusable).

This enhancement resolve the issue by removing the physically contiguous
memory requirement using Scatter/Gather feature that exists in Linux stack.

With this fix Scatter-Gather will be supported also in connected mode.

This change reverts some of the change made in commit e112373fd6
("IPoIB/cm: Reduce connected mode TX object size").

The ability to use SG in IPoIB CM is possible because the coupling
between NETIF_F_SG and NETIF_F_CSUM was removed in commit
ec5f061564 ("net: Kill link between CSUM and SG features.")

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Acked-by: Christian Marie <christian@ponies.io>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:13 -04:00
Carol L Soto 59d40dd92c IB/ucm: Fix bitmap wrap when devnum > IB_UCM_MAX_DEVICES
ib_ucm_release_dev clears the wrong bit if devnum is greater
than IB_UCM_MAX_DEVICES.

Signed-off-by: Carol L Soto <clsoto@linux.vnet.ibm.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:12 -04:00
Haggai Eran 8b7cce0dae IB/ipoib: Prevent lockdep warning in __ipoib_ib_dev_flush
__ipoib_ib_dev_flush calls itself recursively on child devices, and lockdep
complains about locking vlan_rwsem twice (see below). Use down_read_nested
instead of down_read to prevent the warning.

 =============================================
 [ INFO: possible recursive locking detected ]
 4.1.0-rc4+ #36 Tainted: G           O
 ---------------------------------------------
 kworker/u20:2/261 is trying to acquire lock:
  (&priv->vlan_rwsem){.+.+..}, at: [<ffffffffa0791e2a>] __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib]

 but task is already holding lock:
  (&priv->vlan_rwsem){.+.+..}, at: [<ffffffffa0791e2a>] __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib]

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&priv->vlan_rwsem);
   lock(&priv->vlan_rwsem);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 3 locks held by kworker/u20:2/261:
  #0:  ("%s""ipoib_flush"){.+.+..}, at: [<ffffffff810827cc>] process_one_work+0x15c/0x760
  #1:  ((&priv->flush_heavy)){+.+...}, at: [<ffffffff810827cc>] process_one_work+0x15c/0x760
  #2:  (&priv->vlan_rwsem){.+.+..}, at: [<ffffffffa0791e2a>] __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib]

 stack backtrace:
 CPU: 3 PID: 261 Comm: kworker/u20:2 Tainted: G           O    4.1.0-rc4+ #36
 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
 Workqueue: ipoib_flush ipoib_ib_dev_flush_heavy [ib_ipoib]
  ffff8801c6c54790 ffff8801c9927af8 ffffffff81665238 0000000000000001
  ffffffff825b5b30 ffff8801c9927bd8 ffffffff810bba51 ffff880100000000
  ffffffff00000001 ffff880100000001 ffff8801c6c55428 ffff8801c6c54790
 Call Trace:
  [<ffffffff81665238>] dump_stack+0x4f/0x6f
  [<ffffffff810bba51>] __lock_acquire+0x741/0x1820
  [<ffffffff810bcbf8>] lock_acquire+0xc8/0x240
  [<ffffffffa0791e2a>] ? __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib]
  [<ffffffff81669d2c>] down_read+0x4c/0x70
  [<ffffffffa0791e2a>] ? __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib]
  [<ffffffffa0791e2a>] __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib]
  [<ffffffffa0791e4a>] __ipoib_ib_dev_flush+0x5a/0x2b0 [ib_ipoib]
  [<ffffffffa07920ba>] ipoib_ib_dev_flush_heavy+0x1a/0x20 [ib_ipoib]
  [<ffffffff81082871>] process_one_work+0x201/0x760
  [<ffffffff810827cc>] ? process_one_work+0x15c/0x760
  [<ffffffff81082ef0>] worker_thread+0x120/0x4d0
  [<ffffffff81082dd0>] ? process_one_work+0x760/0x760
  [<ffffffff81082dd0>] ? process_one_work+0x760/0x760
  [<ffffffff81088b7e>] kthread+0xfe/0x120
  [<ffffffff81088a80>] ? __init_kthread_worker+0x70/0x70
  [<ffffffff8166c6e2>] ret_from_fork+0x42/0x70
  [<ffffffff81088a80>] ? __init_kthread_worker+0x70/0x70

Signed-off-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:12 -04:00
Haggai Eran 31b57b87fd IB/ucma: Fix lockdep warning in ucma_lock_files
The ucma_lock_files() locks the mut mutex on two files, e.g. for migrating
an ID. Use mutex_lock_nested() to prevent the warning below.

 =============================================
 [ INFO: possible recursive locking detected ]
 4.1.0-rc6-hmm+ #40 Tainted: G           O
 ---------------------------------------------
 pingpong_rpc_se/10260 is trying to acquire lock:
  (&file->mut){+.+.+.}, at: [<ffffffffa047ac55>] ucma_migrate_id+0xc5/0x248 [rdma_ucm]

 but task is already holding lock:
  (&file->mut){+.+.+.}, at: [<ffffffffa047ac4b>] ucma_migrate_id+0xbb/0x248 [rdma_ucm]

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&file->mut);
   lock(&file->mut);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 1 lock held by pingpong_rpc_se/10260:
  #0:  (&file->mut){+.+.+.}, at: [<ffffffffa047ac4b>] ucma_migrate_id+0xbb/0x248 [rdma_ucm]

 stack backtrace:
 CPU: 0 PID: 10260 Comm: pingpong_rpc_se Tainted: G           O    4.1.0-rc6-hmm+ #40
 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
  ffff8801f85b63d0 ffff880195677b58 ffffffff81668f49 0000000000000001
  ffffffff825cbbe0 ffff880195677c38 ffffffff810bb991 ffff880100000000
  ffff880100000000 ffff880100000001 ffff8801f85b7010 ffffffff8121bee9
 Call Trace:
  [<ffffffff81668f49>] dump_stack+0x4f/0x6e
  [<ffffffff810bb991>] __lock_acquire+0x741/0x1820
  [<ffffffff8121bee9>] ? dput+0x29/0x320
  [<ffffffff810bcb38>] lock_acquire+0xc8/0x240
  [<ffffffffa047ac55>] ? ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffff8166b901>] ? mutex_lock_nested+0x291/0x3e0
  [<ffffffff8166b6d5>] mutex_lock_nested+0x65/0x3e0
  [<ffffffffa047ac55>] ? ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffff810baeed>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff8166b66e>] ? mutex_unlock+0xe/0x10
  [<ffffffffa047ac55>] ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffffa0478474>] ucma_write+0xa4/0xb0 [rdma_ucm]
  [<ffffffff81200674>] __vfs_write+0x34/0x100
  [<ffffffff8112427c>] ? __audit_syscall_entry+0xac/0x110
  [<ffffffff810ec055>] ? current_kernel_time+0xc5/0xe0
  [<ffffffff812aa4d3>] ? security_file_permission+0x23/0x90
  [<ffffffff8120088d>] ? rw_verify_area+0x5d/0xe0
  [<ffffffff812009bb>] vfs_write+0xab/0x120
  [<ffffffff81201519>] SyS_write+0x59/0xd0
  [<ffffffff8112427c>] ? __audit_syscall_entry+0xac/0x110
  [<ffffffff8166ffee>] system_call_fastpath+0x12/0x76

Signed-off-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:12 -04:00
Wengang Wang 4fabb59449 rds: rds_ib_device.refcount overflow
Fixes: 3e0249f9c0 ("RDS/IB: add refcount tracking to struct rds_ib_device")

There lacks a dropping on rds_ib_device.refcount in case rds_ib_alloc_fmr
failed(mr pool running out). this lead to the refcount overflow.

A complain in line 117(see following) is seen. From vmcore:
s_ib_rdma_mr_pool_depleted is 2147485544 and rds_ibdev->refcount is -2147475448.
That is the evidence the mr pool is used up. so rds_ib_alloc_fmr is very likely
to return ERR_PTR(-EAGAIN).

115 void rds_ib_dev_put(struct rds_ib_device *rds_ibdev)
116 {
117         BUG_ON(atomic_read(&rds_ibdev->refcount) <= 0);
118         if (atomic_dec_and_test(&rds_ibdev->refcount))
119                 queue_work(rds_wq, &rds_ibdev->free_work);
120 }

fix is to drop refcount when rds_ib_alloc_fmr failed.

Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
Reviewed-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:11 -04:00
Tatyana Nikolova 0a69127250 RDMA/nes: Fix for incorrect recording of the MAC address
Fix for incorrect recording of the MAC address

Signed-off-by: Tatyana Nikolova <Tatyana.E.Nikolova@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:11 -04:00
Tatyana Nikolova 165d682289 RDMA/nes: Fix for resolving the neigh
Neighbor resolution doesn't work without this fix

Signed-off-by: Tatyana Nikolova <Tatyana.E.Nikolova@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:11 -04:00
Tatyana Nikolova a7f2f24cd7 RDMA/core: Fixes for port mapper client registration
Fixes to allow clients to make remove mapping requests, after
they have provided the user space service with the mapping
information, they are using when the service is restarted.

1) Adding IWPM_REG_VALID, IWPM_REG_INCOMPL and IWPM_REG_UNDEF
   registration types for the port mapper clients and functions
   to set/check the registration type.
2) If the port mapper user space service is not available to register
   the client, then its registration stays IWPM_REG_UNDEF and the
   registration isn't checked until the service becomes available
   (no mappings are possible, if the user space service isn't running).
3) After the service is restarted, the user space port mapper pid is set
   to valid and the client registration is set to IWPM_REG_INCOMPL
   to allow the client to make remove mapping requests.

Signed-off-by: Tatyana Nikolova <Tatyana.E.Nikolova@intel.com>
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
Tested-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:10 -04:00
Amir Vadai 58e9cc90cd IB/IPoIB: Fix bad error flow in ipoib_add_port()
Error values of ib_query_port() and ib_query_device() weren't propagated
correctly. Because of that, ipoib_add_port() could return NULL value,
which escaped the IS_ERR() check in ipoib_add_one() and we crashed.

Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:10 -04:00
Matan Barak 8a7ff14dcb IB/mlx4: Do not attemp to report HCA clock offset on VFs
mlx4 VFs can provide CQE raw time-stamping services, but they
don't have the hca core clock mapped to their PCI bars.

As such, we should not attempt to query and report the clock offset
to user space for VFs. Doing so causes query_device over VFs to fail
with -ENOSUPP.

Fixes: 4b664c4355 ('IB/mlx4: Add support for CQ time-stamping')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:10 -04:00
Erez Shitrit be4b499323 IB/cm: Do not queue work to a device that's going away
Whenever ib_cm gets remove_one call, like when there is a hot-unplug
event, the driver should mark itself as going_down and confirm that no
new works are going to be queued for that device.
so, the order of the actions are:
1. mark the going_down bit.
2. flush the wq.
3. [make sure no new works for that device.]
4. unregister mad agent.

otherwise, works that are already queued can be scheduled after the mad
agent was freed.

Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:09 -04:00
Sagi Grimberg 3fdf70acec IB/srp: Avoid using uninitialized variable
We might return res which is not initialized. Also
reduce code duplication by exporting srp_parse_tmo so
srp_tmo_set can reuse it.

Detected by Coverity.

Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Jenny Falkovich <jennyf@mellanox.com>
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:09 -04:00
Vaishali Thakkar b356c1c1f9 IB/srpt: Convert use of __constant_cpu_to_beXX to cpu_to_beXX
In little endian cases, the macro cpu_to_be{16,32,64} unfolds to
__swab{16,32,64} which provides special case for constants. In
big endian cases, __constant_cpu_to_be{16,32,64} and
cpu_to_be{16,32,64} expand directly to the same expression. So,
replace __constant_cpu_to_be{16,32,64} with cpu_to_be{16,32,64}
with the goal of getting rid of the definitions of
__constant_cpu_to_be{16,32,64} completely.

The Coccinelle semantic patch that performs this transformation
is as follows:

@@expression x;@@

(
- __constant_cpu_to_be16(x)
+ cpu_to_be16(x)
|
- __constant_cpu_to_be32(x)
+ cpu_to_be32(x)
|
- __constant_cpu_to_be64(x)
+ cpu_to_be64(x)
)

Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com>
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:09 -04:00
Ira Weiny 3b8ab700af IB/mad: Remove improper use of BUG_ON
We recently added BUG_ON's which were inappropriate for a condition which
should never happen. Change these to be WARN_ON_ONCE as a debugging aid.

Fixes: 4cd7c9479a ('IB/mad: Add support for additional MAD info to/from drivers')

Signed-off-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:08 -04:00
Ira Weiny cd4cd565e0 IB/mad: Fix compare between big endian and cpu endian
The define OPA_LID_PERMISSIVE is big endian and was compared to the
cpu endian variable opa_drslid.

Problem caught by 0-day build infrastructure.

Fixes: 8e4349d13f (IB/mad: Add final OPA MAD processing)
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Reviewed-by: John, Jubin <jubin.john@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:08 -04:00
Hal Rosenstock 4139032b48 IB: Add rdma_cap_ib_switch helper and use where appropriate
Persuant to Liran's comments on node_type on linux-rdma
mailing list:

In an effort to reform the RDMA core and ULPs to minimize use of
node_type in struct ib_device, an additional bit is added to
struct ib_device for is_switch (IB switch). This is needed
to be initialized by any IB switch device driver. This is a
NEW requirement on such device drivers which are all
"out of tree".

In addition, an ib_switch helper was added to ib_verbs.h
based on the is_switch device bit rather than node_type
(although those should be consistent).

The RDMA core (MAD, SMI, agent, sa_query, multicast, sysfs)
as well as (IPoIB and SRP) ULPs are updated where
appropriate to use this new helper. In some cases,
the helper is now used under the covers of using
rdma_[start end]_port rather than the open coding
previously used.

Reviewed-by: Sean Hefty <sean.hefty@intel.com>
Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Tested-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Hal Rosenstock <hal@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-07-14 13:20:08 -04:00
Filipe Manana ed95876264 Btrfs: fix file corruption after cloning inline extents
Using the clone ioctl (or extent_same ioctl, which calls the same extent
cloning function as well) we end up allowing copy an inline extent from
the source file into a non-zero offset of the destination file. This is
something not expected and that the btrfs code is not prepared to deal
with - all inline extents must be at a file offset equals to 0.

For example, the following excerpt of a test case for fstests triggers
a crash/BUG_ON() on a write operation after an inline extent is cloned
into a non-zero offset:

  _scratch_mkfs >>$seqres.full 2>&1
  _scratch_mount

  # Create our test files. File foo has the same 2K of data at offset 4K
  # as file bar has at its offset 0.
  $XFS_IO_PROG -f -s -c "pwrite -S 0xaa 0 4K" \
      -c "pwrite -S 0xbb 4k 2K" \
      -c "pwrite -S 0xcc 8K 4K" \
      $SCRATCH_MNT/foo | _filter_xfs_io

  # File bar consists of a single inline extent (2K size).
  $XFS_IO_PROG -f -s -c "pwrite -S 0xbb 0 2K" \
     $SCRATCH_MNT/bar | _filter_xfs_io

  # Now call the clone ioctl to clone the extent of file bar into file
  # foo at its offset 4K. This made file foo have an inline extent at
  # offset 4K, something which the btrfs code can not deal with in future
  # IO operations because all inline extents are supposed to start at an
  # offset of 0, resulting in all sorts of chaos.
  # So here we validate that clone ioctl returns an EOPNOTSUPP, which is
  # what it returns for other cases dealing with inlined extents.
  $CLONER_PROG -s 0 -d $((4 * 1024)) -l $((2 * 1024)) \
      $SCRATCH_MNT/bar $SCRATCH_MNT/foo

  # Because of the inline extent at offset 4K, the following write made
  # the kernel crash with a BUG_ON().
  $XFS_IO_PROG -c "pwrite -S 0xdd 6K 2K" $SCRATCH_MNT/foo | _filter_xfs_io

  status=0
  exit

The stack trace of the BUG_ON() triggered by the last write is:

  [152154.035903] ------------[ cut here ]------------
  [152154.036424] kernel BUG at mm/page-writeback.c:2286!
  [152154.036424] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  [152154.036424] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop fuse parport_pc acpi_cpu$
  [152154.036424] CPU: 2 PID: 17873 Comm: xfs_io Tainted: G        W       4.1.0-rc6-btrfs-next-11+ #2
  [152154.036424] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014
  [152154.036424] task: ffff880429f70990 ti: ffff880429efc000 task.ti: ffff880429efc000
  [152154.036424] RIP: 0010:[<ffffffff8111a9d5>]  [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
  [152154.036424] RSP: 0018:ffff880429effc68  EFLAGS: 00010246
  [152154.036424] RAX: 0200000000000806 RBX: ffffea0006a6d8f0 RCX: 0000000000000001
  [152154.036424] RDX: 0000000000000000 RSI: ffffffff81155d1b RDI: ffffea0006a6d8f0
  [152154.036424] RBP: ffff880429effc78 R08: ffff8801ce389fe0 R09: 0000000000000001
  [152154.036424] R10: 0000000000002000 R11: ffffffffffffffff R12: ffff8800200dce68
  [152154.036424] R13: 0000000000000000 R14: ffff8800200dcc88 R15: ffff8803d5736d80
  [152154.036424] FS:  00007fbf119f6700(0000) GS:ffff88043d280000(0000) knlGS:0000000000000000
  [152154.036424] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [152154.036424] CR2: 0000000001bdc000 CR3: 00000003aa555000 CR4: 00000000000006e0
  [152154.036424] Stack:
  [152154.036424]  ffff8803d5736d80 0000000000000001 ffff880429effcd8 ffffffffa04e97c1
  [152154.036424]  ffff880429effd68 ffff880429effd60 0000000000000001 ffff8800200dc9c8
  [152154.036424]  0000000000000001 ffff8800200dcc88 0000000000000000 0000000000001000
  [152154.036424] Call Trace:
  [152154.036424]  [<ffffffffa04e97c1>] lock_and_cleanup_extent_if_need+0x147/0x18d [btrfs]
  [152154.036424]  [<ffffffffa04ea82c>] __btrfs_buffered_write+0x245/0x4c8 [btrfs]
  [152154.036424]  [<ffffffffa04ed14b>] ? btrfs_file_write_iter+0x150/0x3e0 [btrfs]
  [152154.036424]  [<ffffffffa04ed15a>] ? btrfs_file_write_iter+0x15f/0x3e0 [btrfs]
  [152154.036424]  [<ffffffffa04ed2c7>] btrfs_file_write_iter+0x2cc/0x3e0 [btrfs]
  [152154.036424]  [<ffffffff81165a4a>] __vfs_write+0x7c/0xa5
  [152154.036424]  [<ffffffff81165f89>] vfs_write+0xa0/0xe4
  [152154.036424]  [<ffffffff81166855>] SyS_pwrite64+0x64/0x82
  [152154.036424]  [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
  [152154.036424] Code: 48 89 c7 e8 0f ff ff ff 5b 41 5c 5d c3 0f 1f 44 00 00 55 48 89 e5 41 54 53 48 89 fb e8 ae ef 00 00 49 89 c4 48 8b 03 a8 01 75 02 <0f> 0b 4d 85 e4 74 59 49 8b 3c 2$
  [152154.036424] RIP  [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
  [152154.036424]  RSP <ffff880429effc68>
  [152154.242621] ---[ end trace e3d3376b23a57041 ]---

Fix this by returning the error EOPNOTSUPP if an attempt to copy an
inline extent into a non-zero offset happens, just like what is done for
other scenarios that would require copying/splitting inline extents,
which were introduced by the following commits:

   00fdf13a2e ("Btrfs: fix a crash of clone with inline extents's split")
   3f9e3df8da ("btrfs: replace error code from btrfs_drop_extents")

Cc: stable@vger.kernel.org
Signed-off-by: Filipe Manana <fdmanana@suse.com>
2015-07-14 16:09:39 +01:00
Paul Burton 4e9d324d42 MIPS: Require O32 FP64 support for MIPS64 with O32 compat
MIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with
support for MIPS32r6 binaries but without support for O32 with FP64 is
therefore a problem which can lead to incorrectly executed userland.

CONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is
configured for MIPS32r6, but not when the kernel is configured for
MIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in
such configurations to prevent building kernels which execute MIPS32r6
userland incorrectly.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: <stable@vger.kernel.org> # v4.0-
Cc: linux-mips@linux-mips.org
Cc: Matthew Fortune <matthew.fortune@imgtec.com>
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10674/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-14 16:40:19 +02:00
Ralf Baechle 5f7e63107f MIPS: asm-offset.c: Patch up various comments refering to the old filename.
arch/mips/tools/offset.c was renamed to arch/mips/kernel/asm-offsets.c
for v2.6.14.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-14 16:05:49 +02:00
Takashi Iwai 4d0e677523 ALSA: line6: Fix -EBUSY error during active monitoring
When a monitor stream is active, the next PCM stream access results in
EBUSY error because of the check in line6_stream_start().  Fix this by
just skipping the submission of pending URBs when the stream is
already running instead.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101431
Cc: <stable@vger.kernel.org> # v4.0+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-07-14 15:19:37 +02:00
Maarten Lankhorst ccfb8b2ed4 drm/i915: Do not call intel_crtc_disable if the crtc is already disabled.
When resuming with dpms off, the following warn can happen:

[  118.334082] ------------[ cut here ]------------
[  118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]()
[  118.334106] WARN_ON(!crtc->state->enable)
[  118.334137] Modules linked in: i915
[  118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148
[  118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[  118.334144] Workqueue: events_unbound async_run_entry_fn
[  118.334147]  ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001
[  118.334149]  ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8
[  118.334151]  ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668
[  118.334151] Call Trace:
[  118.334155]  [<ffffffff817aa62a>] dump_stack+0x4f/0x7b
[  118.334157]  [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0
[  118.334158]  [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50
[  118.334173]  [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915]
[  118.334188]  [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915]
[  118.334191]  [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80
[  118.334205]  [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915]
[  118.334219]  [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915]
[  118.334232]  [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915]
[  118.334246]  [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915]
[  118.334248]  [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90
[  118.334255]  [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915]
[  118.334262]  [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915]
[  118.334263]  [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0
[  118.334266]  [<ffffffff81467550>] dpm_run_callback+0x70/0x420
[  118.334267]  [<ffffffff81467cbd>] device_resume+0x9d/0x1c0
[  118.334269]  [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60
[  118.334270]  [<ffffffff81467dfc>] async_resume+0x1c/0x50
[  118.334271]  [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0
[  118.334273]  [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0
[  118.334275]  [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0
[  118.334276]  [<ffffffff8109daf9>] worker_thread+0x49/0x450
[  118.334278]  [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0
[  118.334280]  [<ffffffff810a3cb9>] kthread+0xf9/0x110
[  118.334282]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
[  118.334284]  [<ffffffff817b414f>] ret_from_fork+0x3f/0x70
[  118.334286]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
[  118.334287] ---[ end trace 01f2cf6371b82d7a ]---

This warn is harmless, and can be fixed by not calling intel_crtc_disable when
the crtc is already disabled.

Reported-and-Tested-by: Jörg Otte <jrg.otte@gmail.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14 14:00:13 +02:00
Daniel Vetter d82c0ba6e3 Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations"
This reverts commit 19ee835cdb.

It breaks existing old userspace which doesn't handle UNKNOWN
swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably
still is on some other platforms, but it still pretty clearly broke
the testers machine. If we want this we need to extend the ioctl with
new paramters that only new userspace looks at.

Cc: Harald Arnesen <harald@skogtun.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Harald Arnesen <harald@skogtun.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-14 12:29:27 +02:00
Thomas Gleixner 0f44705175 tick: Move the export of tick_broadcast_oneshot_control to the proper place
tick_broadcast_oneshot_control got moved from tick-broadcast to
tick-common, but the export stayed in the old place. Fix it up.

Fixes: f32dd11705 'tick/broadcast: Make idle check independent from mode and config'
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-07-14 12:01:04 +02:00
Baruch Siach cde137aa86 MAINTAINERS: digicolor: add dts files
The 'digicolor' regexp doesn't cover the dts files. Add a glob pattern for
them.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Olof Johansson <olof@lixom.net>
2015-07-14 11:19:37 +02:00
Olof Johansson a549608f5c SoCFPGA fixes against v4.2-rc1
- Update compatible "adxl345x" compatible string
 - Alphabetize the DTS nodes for the C5 sockit board file
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJVn+cMAAoJEBmUBAuBoyj0CpAP/jAsBFLSE0FWbKn42H/MA7x3
 zGPcPlaM5B8dmYli+IEciO4XJOLrJqidrpazgYCfuNFb5x7+f0Yubh8utRvoNt35
 a/OmiQw5aXxjKohYE03ytnY9uwaoJzNU+10H2v/BdwcGS33DXb9rrxdKSJ73pBzu
 LzbC0Dzqi6AbY6zxxsVjjvn1u9HWIYA9vWECaNtbpmHaAy2azICPfmuW6Gp1E2ug
 BzvE2LNMo0NSvkGzl0udhv/KE0TyLAmbGTAU46zsydkb2zx8hxLklhmr3ea+JAGs
 GpvDTXJXZLs62uU0gDs33i/5w5FMXH8FnVP+bu/qFqZh8yYBrjo88EgCiVB9STU1
 e3I7oIlWOgef9tWEbqaZkefHPaAqGdjEYQefXD6zhNKT4jyfzn9RlZJJi3iybfeI
 K2ipNoJ49DBoGd3s6fE5h/croacFEpl+5J6ArGyXythLPDIjF2YzCh1qi3Lorhk8
 oAAK2FzLttATnirOasVG+CiVYWMrGndGaO8wbJiAAvdpsqLzoXVo4eUlZ2Hxlwfk
 kLFIWwNfwd6fu0yRIDfeMs4DjjqDy87R4xUuEGaa4QBef3+WGW/6Fj4T0f9rSGwi
 lZiMHRsirkBgj5iuhaAc1nLbdT0CMaaqQBO40GBbhQ3jMs7cWe2Csm925pOQGkLM
 ZxRjGIsjbCcEZHNIQPNM
 =bmZp
 -----END PGP SIGNATURE-----

Merge tag 'socfpga_fixes_for_v4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into fixes

Merge "SoCFPGA fixes for v4.2-rc1" from Dinh Nguyen:

SoCFPGA fixes against v4.2-rc1
- Update compatible "adxl345x" compatible string
- Alphabetize the DTS nodes for the C5 sockit board file

* tag 'socfpga_fixes_for_v4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
  ARM: socfpga: dts: Fix entries order
  ARM: socfpga: dts: Fix adxl34x formating and compatible string
2015-07-14 11:16:55 +02:00
Linus Walleij 1d8aca9df6 ARM: ux500: fix MMC/SD card regression
Ux500 is regressing due to commit
a21763a0b1
"pinctrl: nomadik: activate strict mux mode" which disallows
Nomadik GPIO 5 to be muxed in as a level shifter voltage select
pin, as it is currently described as being used for RX on UART1.

The behaviour is correct, instead the hardware config has been
incorrecly specified: UART1 is indeed unused on HREFv60plus and
Snowball and that is why HREFv60plus can use the pins it would
normally occupy as the voltage select line for the MMC/SD
levelshifter (Snowball uses it for I2C4).

The reason UART1 was anyway enabled on these platforms was
probably to secure the port enumeration to userspace. This
can be solved by using aliases (done in a separate patch) so
we can now deactivate UART1 and let MMC/SD use it properly
on HREFv60plus. We explicitly activate it only for the
older HREFprev60 board.

To complete, we set up the pin configuration for these pins
properly in the sdi0 node.

Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
2015-07-14 11:15:57 +02:00
Linus Walleij 109978dea4 ARM: ux500: define serial port aliases
This enumerates the PL011 serial ports on the Ux500. This is
necessary to do if we want to remove one of the serial ports,
since userspace depends on console to be present on ttyAMA2
and we must not break userspace.

Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
2015-07-14 11:15:42 +02:00
Tvrtko Ursulin ac7e7ab1c3 drm/i915: Forward all core DRM ioctls to core compat handling
Previously only core DRM ioctls under the DRM_COMMAND_BASE were being
forwarded, but the drm.h header suggests (and reality confirms) ones
after (and including) DRM_COMMAND_END should be forwarded as well.

We need this to correctly forward the compat ioctl for the botched-up
addfb2.1 extension.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: stable@vger.kernel.org # 4.1+
[danvet: Explain why this is suddenly needed and add cc: stable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14 10:15:41 +02:00
Suman Anna c1b5d0f624 ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes
for OMAP5 platforms. This property is required as per the generic
iommu binding.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-07-14 00:00:46 -07:00
Suman Anna 22e3bcc62e ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes
for OMAP4 platforms. This property is required as per the generic
iommu binding.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-07-14 00:00:46 -07:00
Arun Bharadwaj 693f4f4c96 ARM: dts: Fix frequency scaling on Gumstix Pepper
The device tree for Gumstix Pepper has DCDC2 and
DCDC3 correctly labelled but the upper limit values
are wrong. The confusion is due to the hardware
quirk where the DCDC2 and DCDC3 wires are flipped
in Pepper.

Signed-off-by: Arun Bharadwaj <arun@gumstix.com>
Tested-by: Ash Charles <ashcharles@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-07-14 00:00:46 -07:00
Adam YH Lee 5aed4ee7cc ARM: dts: configure regulators for Gumstix Pepper
Boot process is halting in midway because some of the necessary voltage
regulators are deemed unused and subsequently powered off, leading to
a completely unresponsive system.

Most of the device nodes had correct voltage regulator attachments.
Yet these nodes had to set stricter enforcement on them through
'regulator-boot-on' and 'regulator-always-on' to function correctly.

The consumers of the regulators this commit affect are the followings:

	DCDC1: vdd_1v8 system supply, USB-PHY, and ADC
	DCDC2: Core domain
	DCDC3: MPU core domain
	 LDO1: RTC
	 LDO2: 3v3 IO domain
	 LDO3: USB-PHY; not a boot-time requirement
	 LDO4: LCD [16:23]

All but LDO3 need to be always-on for the system to be functional.

Additionally regulator-name properties have been added for the kernel to
display the name from the schematic. This will improve diagnostics.

Signed-off-by: Adam YH Lee <adam.yh.lee@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-07-14 00:00:46 -07:00
Adam YH Lee 3c20b827b1 ARM: dts: omap3: overo: Update LCD panel names
For Gumstix Overo COMs, the u-boot bootloader typically passes an
argument specifying the default display via the omapdss.def_disp
parameter.  When a default display is specified, DSS2 tries to match
this name with either the device tree label (e.g. label=dvi) or,
failing this, the device tree alias (e.g. label=display0). Update the
panel names for the 'lcd43' and 'lcd35' displays in the device tree
such that they match the names passed by u-boot.

Signed-off-by: Ash Charles <ashcharles@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-07-13 23:59:11 -07:00
Chris Zhong b2b9dc6074 ARM: dts: cros-ec-keyboard: Add support for some Japanese keys
Add support for 4 Japanese keys

Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
2015-07-13 23:44:44 +02:00
Jarkko Sakkinen b371616b85 tpm, tpm_crb: fail when TPM2 ACPI table contents look corrupted
At least some versions of AMI BIOS have corrupted contents in the TPM2
ACPI table and namely the physical address of the control area is set to
zero.

This patch changes the driver to fail gracefully  when we observe a zero
address instead of continuing to ioremap.

Cc: <stable@vger.kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
2015-07-13 23:34:12 +02:00
Jason Gunthorpe ba0ef85479 tpm: Fix initialization of the cdev
When a cdev is contained in a dynamic structure the cdev parent kobj
should be set to the kobj that controls the lifetime of the enclosing
structure. In TPM's case this is the embedded struct device.

Also, cdev_init 0's the whole structure, so all sets must be after,
not before. This fixes module ref counting and cdev.

Cc: <stable@vger.kernel.org>
Fixes: 313d21eeab ("tpm: device class for tpm")
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
2015-07-13 23:33:57 +02:00
Thomas Gleixner 20483d04ae gpio/davinci: Fix race in installing chained irq handler
Fix a race where a pending interrupt could be received and the handler
called before the handler's data has been setup, by converting to
irq_set_chained_handler_and_data().
    
Search and conversion was done with coccinelle.
    
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
2015-07-13 23:24:48 +02:00
Greg Kroah-Hartman 8c5dfdbbeb Second set of IIO fixes for the 4.2 cycle. Note these depend (mostly) on
material in the recent merge window, hence their separation from set (a)
 as the fixes-togreg branch predated the merge window.  I am running rather
 later with these than I would have liked hence the large set.
 
 * stk3310 fixes from Hartmut's review that came in post merge
   - fix direction of proximity inline with recent documentation
     clarification.
   - fix missing REGMAP_I2C dependency
   - rework the error handling for raw readings to fix an failure to power
     down in the event of a raw reading failing.
   - fix a bug in the compensation code which was toggling an extra bit in the
     register.
 * mmc35240 - reported samplign frequencies were wrong.
 * ltr501 fixes
   - fix a case of returning the return value of a regmap_read instead of
     the value read.
   - fix missing regmap dependency
 * sx9500 - fix missing default values for ret in a couple of places to handle
   the case of no enabled channels.
 * tmp006 - check that writes to info_mask elements are actually to writable
   ones.  Otherwise, writing to any of them will change the sampling frequency.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJVpCJ3AAoJEFSFNJnE9BaIN3gP/0bAfaLmR8zdnnBlUCr3VG1I
 xiXjzpcnzg8sZR0883AeqgnGpu2W4LNAIrVumNLBWOCifvN2HVdlcmIH5iHjHR+n
 r9Mp6RM9bBYWbUCmOZuaTOKHBMifh59cc8y3UkRsGAjr/EvpT5jciX4d60EvSE4d
 nQ2Fcg/kEYmyVZQ1UjfUZvbOwUcNJP2WhHsz30HGDFSCeCYkbtrDz2lcZqaSZSDV
 P/nJ3ySQtLIJ3OzyCKz9b212WrLODWc50CDQlcIFzKxaMqYytGndE88Zsvs0a1nx
 JPcSDK7zaMItPJ75PA+I5h7L4mMTOgReTrnQlpLP3YnlAdS8/1o2gz9dLnI2Y7iC
 eBLOBFFwp/rgY6eHdcvjyiLmpGs1zl93tiZsVBvcQkJw74HG56xlemPzxN09tmLd
 gxlGztucdBhXh8/PAG9o5kSV7xcop2lftJP+jAV7rxpCbmi2use/2vejFi8qjFiE
 CekQxmEm32YakVnkNauz5iiUIgCUa5fZ++/G2nIg6F3iRlF8B6akUFdStCcwIc8b
 6vyF4jkKU+hyAu0TiWnjLHa83brlJ44L4TOPhhS3QvDbGpr8ULHdCrSBdwifZoBC
 0m6J0Tia6M/TmwQ+4Owd2MzNzX/YUbtd3b7nIje7QnEQu5UAe4F3Myio8uyWB8uR
 o/sfUmysDXQbKycJ0PEg
 =1kNg
 -----END PGP SIGNATURE-----

Merge tag 'iio-fixes-for-4.2b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

Jonathan writes:

Second set of IIO fixes for the 4.2 cycle. Note these depend (mostly) on
material in the recent merge window, hence their separation from set (a)
as the fixes-togreg branch predated the merge window.  I am running rather
later with these than I would have liked hence the large set.

* stk3310 fixes from Hartmut's review that came in post merge
  - fix direction of proximity inline with recent documentation
    clarification.
  - fix missing REGMAP_I2C dependency
  - rework the error handling for raw readings to fix an failure to power
    down in the event of a raw reading failing.
  - fix a bug in the compensation code which was toggling an extra bit in the
    register.
* mmc35240 - reported samplign frequencies were wrong.
* ltr501 fixes
  - fix a case of returning the return value of a regmap_read instead of
    the value read.
  - fix missing regmap dependency
* sx9500 - fix missing default values for ret in a couple of places to handle
  the case of no enabled channels.
* tmp006 - check that writes to info_mask elements are actually to writable
  ones.  Otherwise, writing to any of them will change the sampling frequency.
2015-07-13 14:19:22 -07:00
Greg Kroah-Hartman a732cd437b First set of IIO fixes for the 4.2 cycle.
* Fix a regression in hid sensors suspend time as a result of adding runtime
   pm.  The normal flow of waking up devices in order to go into suspend
   (given the devices are normally suspended when not reading) to a regression
   in suspend time on some laptops (reports of an additional 8 seconds).
   Fix this by checking to see if a user action resulting in the wake up, and
   make it a null operation if it didn't.  Note that for hid sensors, there is
   nothing useful to be done when moving into a full suspend from a runtime
   suspend so they might as well be left alone.
 * rochip_saradc: fix some missing MODULE_* data including the licence so that
   the driver does not taint the kernel incorrectly and can build as a module.
 * twl4030 - mark irq as oneshot as it always should have been.
 * inv-mpu - write formats for attributes not specified, leading to miss
   interpretation of the gyro scale channel when written.
 * Proximity ABI clarification.  This had snuck through as a mess.  Some
   drivers thought proximity went in one direction, some the other.  We went
   with the most common option, documented it and fixed up the drivers going
   the other way.  Fix for sx9500 included in this set.
 * ad624r - fix a wrong shift in the output data.
 * at91_adc - remove a false limit on the value of the STARTUP register
   applied by too small a type for the device tree parameter.
 * cm3323 - clear the bits when setting the integration time (otherwise
   we can only ever set more bits in the relevant field).
 * bmc150-accel - multiple triggers are registered, but on error were not being
   unwound in the opposite order leading to removal of triggers that had not
   yet successfully been registered (count down instead of up when unwinding).
 * tcs3414 - ensure right part of val / val2 pair read so that the integration
   time is not always 0.
 * cc10001_adc - bug in kconfig dependency. Use of OR when AND was intended.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJVpA2CAAoJEFSFNJnE9BaIJGEP/2uXFSqOZhmJ9sGqICSgKj4W
 OUjDtpXpKWxLC3Fypzvzg5u00R1t2likfvhXP2RsF5+/mqPb8NS6qzdcKMPCyxEl
 5tvsmYHm9yxN8o3ZZqtgYaR4mYt5tH4dFZ9qHpbFeNAXGjTRrYhGbgmLnND0v7cA
 5L1ABLls8ntoJ1aZZDsofwnmnUgclW5yqQZZ+huNkwaOpUQLke9tEL18cv+bsVgS
 zw7j/t3oJVdcUB9OTB7T/sW9J0+W7XnXogATHksHdHh2cd5N7wh/EZ1bet69QUrI
 PD2q2+0MUwyBMWDPveyWfm7XbS66lYxIRCmWZp+69Q1c/V91srhSPfh0kPcvHSQ1
 Uzpba6oSFPlFyDAtXWhaSEBzjXaHwKBIQvIVYOKiE6JdrbsnSg4GHAcF8TMhGtwT
 SDDgfb+cxOm6Vb4ws0+i15HMEiXpeK8AiJfHmLvau3OnA69/xzxHqqSg/oCO6/ES
 IzoAMqIVEk3L5gu88qgnmWzmyWp1pyTf1u+Kr+gAXNdSF/b3wgVkGn2X9hNRQ4g/
 XEFAD1PzarBnv1ce/HfWi+9/aUwv08nXHxBe4Yx3bfle2RUQKmFSbksVkCwu+ha3
 E4jPs5Cf9MrHO4gbuFaZX2+bFYlMdbcEWVRcP/3CHUuxeixGwemOsak1L+J5h6+e
 2xVEkGeywVdmDOsan1B8
 =mBqw
 -----END PGP SIGNATURE-----

Merge tag 'iio-fixes-for-4.2a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

Jonathan writes:

First set of IIO fixes for the 4.2 cycle.

* Fix a regression in hid sensors suspend time as a result of adding runtime
  pm.  The normal flow of waking up devices in order to go into suspend
  (given the devices are normally suspended when not reading) to a regression
  in suspend time on some laptops (reports of an additional 8 seconds).
  Fix this by checking to see if a user action resulting in the wake up, and
  make it a null operation if it didn't.  Note that for hid sensors, there is
  nothing useful to be done when moving into a full suspend from a runtime
  suspend so they might as well be left alone.
* rochip_saradc: fix some missing MODULE_* data including the licence so that
  the driver does not taint the kernel incorrectly and can build as a module.
* twl4030 - mark irq as oneshot as it always should have been.
* inv-mpu - write formats for attributes not specified, leading to miss
  interpretation of the gyro scale channel when written.
* Proximity ABI clarification.  This had snuck through as a mess.  Some
  drivers thought proximity went in one direction, some the other.  We went
  with the most common option, documented it and fixed up the drivers going
  the other way.  Fix for sx9500 included in this set.
* ad624r - fix a wrong shift in the output data.
* at91_adc - remove a false limit on the value of the STARTUP register
  applied by too small a type for the device tree parameter.
* cm3323 - clear the bits when setting the integration time (otherwise
  we can only ever set more bits in the relevant field).
* bmc150-accel - multiple triggers are registered, but on error were not being
  unwound in the opposite order leading to removal of triggers that had not
  yet successfully been registered (count down instead of up when unwinding).
* tcs3414 - ensure right part of val / val2 pair read so that the integration
  time is not always 0.
* cc10001_adc - bug in kconfig dependency. Use of OR when AND was intended.
2015-07-13 14:18:07 -07:00
Daniel Vetter bbf470202d drm/i915: fix oops in primary_check_plane
On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote:
> On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <jrg.otte@gmail.com> wrote:
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
> > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb
>
> Ugh. Please enable KALLSYMS to get sane symbols.
>
> But yes, "crtc_state->base.active" is at offset 9 from "crtc_state",
> so it's pretty clearly just that change frm
>
> -       if (intel_crtc->active) {
> +       if (crtc_state->base.active) {
>
> and "crtc_state" is NULL.
>
> And the code very much knows that crtc_state can be NULL, since it's
> initialized with
>
>         crtc_state = state->base.state ?
>                 intel_atomic_get_crtc_state(state->base.state,
> intel_crtc) : NULL;
>
> Tssk. Daniel? Should I just revert that commit dec4f799d0
> ("drm/i915: Use crtc_state->active in primary check_plane func") for
> now, or is there a better fix? Like just checking crtc_state for NULL?

Indeed embarrassing. I've missed that we still have 1 caller left that's
using the transitional helpers, and those don't fill out
plane_state->state backpointers to the global atomic update since there is
no global atomic update for transitional helpers. Below diff should fix
this - we need to preferentially check crts_state->active and if that's
not set intel_crtc->active should yield the right result for the one
remaining caller (it's in the crtc_disable paths).

This fixes a regression introduced in

commit dec4f799d0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jul 7 11:15:47 2015 +0200

    drm/i915: Use crtc_state->active in primary check_plane func

which was quickly reverted in

commit 01e2d0627a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jul 12 15:00:20 2015 -0700

    Revert "drm/i915: Use crtc_state->active in primary check_plane func"

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jörg Otte <jrg.otte@gmail.com>
Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-13 22:44:13 +02:00
Imre Deak 5ec5b51639 drm/i915: remove unused has_dma_mapping flag
After the previous patch this flag will check always clear, as it's
never set for shmem backed and userptr objects, so we can remove it.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Yeah this isn't really fixes but it's a nice cleanup to
clarify the code but not really worth the hassle of backmerging. So
just add to -fixes, we're still early in -rc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-13 22:42:41 +02:00
Daniel Vetter 101057fa40 drm/i915: Fix missing return warning for !CONFIG_DEBUGFS
This broken code was introduced in

commit aa7471d228
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Apr 1 11:15:21 2015 +0300

    drm/i915: add i915 specific connector debugfs file for DPCD

v2: Drop hunk that accidentally crept in.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: François Valenduc <francoisvalenduc@gmail.com>
Reported-by: François Valenduc <francoisvalenduc@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-13 22:42:40 +02:00
Imre Deak e227330223 drm/i915: avoid leaking DMA mappings
We have 3 types of DMA mappings for GEM objects:
1. physically contiguous for stolen and for objects needing contiguous
   memory
2. DMA-buf mappings imported via a DMA-buf attach operation
3. SG DMA mappings for shmem backed and userptr objects

For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the
corresponding backing pages and so in practice we create/release the
mapping in the object's get_pages/put_pages callback.

For 3. the lifetime of the mapping matches that of any existing GPU binding
of the object, so we'll create the mapping when the object is bound to
the first vma and release the mapping when the object is unbound from its
last vma.

Since the object can be bound to multiple vmas, we can end up creating a
new DMA mapping in the 3. case even if the object already had one. This
is not allowed by the DMA API and can lead to leaked mapping data and
IOMMU memory space starvation in certain cases. For example HW IOMMU
drivers (intel_iommu) allocate a new range from their memory space
whenever a mapping is created, silently overriding a pre-existing
mapping.

Fix this by moving the creation/removal of DMA mappings to the object's
get_pages/put_pages callbacks. These callbacks already check for and do
an early return in case of any nested calls. This way objects of the 3.
case also become more like the other object types.

I noticed this issue by enabling DMA debugging, which got disabled after
a while due to its internal mapping tables getting full. It also reported
errors in connection to random other drivers that did a DMA mapping for
an address that was previously mapped by i915 but was never released.
Besides these diagnostic messages and the memory space starvation
problem for IOMMUs, I'm not aware of this causing a real issue.

The fix is based on a patch from Chris.

v2:
- move the DMA mapping create/remove calls to the get_pages/put_pages
  callbacks instead of adding new callbacks for these (Chris)
v3:
- also fix the get_page cache logic on the userptr async path (Chris)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-13 22:42:40 +02:00
Tomas Elf 94f7bbe150 drm/i915: Snapshot seqno of most recently submitted request.
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect requests since
requests might be deallocated during inspection. In the past we've had kernel
panics due to this very unsynchronized access in the hang checker.

One solution to this problem is to not inspect the requests directly since
we're only interested in the seqno of the most recently submitted request - not
the request itself. Instead the seqno of the most recently submitted request is
stored separately, which the hang checker then inspects, circumventing the
issue of synchronization from the hang checker entirely.

This fixes a regression introduced in

commit 44cdd6d219
Author: John Harrison <John.C.Harrison@Intel.com>
Date:   Mon Nov 24 18:49:40 2014 +0000

    drm/i915: Convert 'ring_idle()' to use requests not seqnos

v2 (Chris Wilson):
- Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather
than compute it over again.
- Remove extra whitespace.

Issue: VIZ-5998
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regressing commit citation provided by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-13 22:42:39 +02:00
Chris Wilson 9ea4feecc3 drm/i915: Store device pointer in contexts for late tracepoint usafe
[ 1572.417121] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 1572.421010] IP: [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915]
[ 1572.424970] PGD 1766a3067 PUD 1767a2067 PMD 0
[ 1572.428892] Oops: 0000 [#1] SMP
[ 1572.432787] Modules linked in: ipv6 dm_mod iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore serio_raw pcspkr lpc_ich i2c_i801 mfd_core battery ac acpi_cpufreq i915 button video drm_kms_helper drm
[ 1572.441720] CPU: 2 PID: 18853 Comm: kworker/u8:0 Not tainted 4.0.0_kcloud_3f0360_20150429+ #588
[ 1572.446298] Workqueue: i915 i915_gem_retire_work_handler [i915]
[ 1572.450876] task: ffff880002f428f0 ti: ffff880035724000 task.ti: ffff880035724000
[ 1572.455557] RIP: 0010:[<ffffffffa00b2514>]  [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915]
[ 1572.460423] RSP: 0018:ffff880035727ce8  EFLAGS: 00010286
[ 1572.465262] RAX: ffff880073f1643c RBX: ffff880002da9058 RCX: ffff880073e5db40
[ 1572.470179] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880035727ce8
[ 1572.475107] RBP: ffff88007bb11a00 R08: 0000000000000000 R09: 0000000000000000
[ 1572.480034] R10: 0000000000362200 R11: 0000000000000008 R12: 0000000000000000
[ 1572.484952] R13: ffff880035727d78 R14: ffff880002dc1c98 R15: ffff880002dc1dc8
[ 1572.489886] FS:  0000000000000000(0000) GS:ffff88017fd00000(0000) knlGS:0000000000000000
[ 1572.494883] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1572.499859] CR2: 0000000000000000 CR3: 000000017572a000 CR4: 00000000001006e0
[ 1572.504842] Stack:
[ 1572.509834]  ffff88017b0090c0 ffff880073f16438 ffff880002da9058 ffff880073f1643c
[ 1572.514904]  0000000000000246 ffff880100000000 ffff88007bb11a00 ffff880002ddeb10
[ 1572.519985]  ffff8801759f79c0 ffffffffa0092ff0 0000000000000000 ffff88007bb11a00
[ 1572.525049] Call Trace:
[ 1572.530093]  [<ffffffffa0092ff0>] ? i915_gem_context_free+0xa8/0xc1 [i915]
[ 1572.535227]  [<ffffffffa009b969>] ? i915_gem_request_free+0x4e/0x50 [i915]
[ 1572.540347]  [<ffffffffa00b5533>] ? intel_execlists_retire_requests+0x14c/0x159 [i915]
[ 1572.545500]  [<ffffffffa009d9ea>] ? i915_gem_retire_requests+0x9d/0xeb [i915]
[ 1572.550664]  [<ffffffffa009dd8c>] ? i915_gem_retire_work_handler+0x4c/0x61 [i915]
[ 1572.555825]  [<ffffffff8104ca7f>] ? process_one_work+0x1b2/0x31d
[ 1572.560951]  [<ffffffff8104d278>] ? worker_thread+0x24d/0x339
[ 1572.566033]  [<ffffffff8104d02b>] ? cancel_delayed_work_sync+0xa/0xa
[ 1572.571140]  [<ffffffff81050b25>] ? kthread+0xce/0xd6
[ 1572.576191]  [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162
[ 1572.581228]  [<ffffffff8179b3c8>] ? ret_from_fork+0x58/0x90
[ 1572.586259]  [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162
[ 1572.591318] Code: de 48 89 e7 e8 09 4d 00 e1 48 85 c0 74 27 48 89 68 10 48 8b 55 38 48 89 e7 48 89 50 18 48 8b 55 10 48 8b 12 48 8b 12 48 8b 52 38 <8b> 12 89 50 08 e8 95 4d 00 e1 48 83 c4 30 5b 5d 41 5c c3 41 55
[ 1572.596981] RIP  [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915]
[ 1572.602464]  RSP <ffff880035727ce8>
[ 1572.607911] CR2: 0000000000000000

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112#c23
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-13 22:42:38 +02:00
Arnaldo Carvalho de Melo 9c0fa8dd3d perf hists browser: Take the --comm, --dsos, etc filters into account
At some point:

  commit 2c86c7ca76
  Author: Namhyung Kim <namhyung@kernel.org>
  Date:   Mon Mar 17 18:18:54 2014 -0300

    perf report: Merge al->filtered with hist_entry->filtered

We stopped dropping samples for things filtered via the --comms, --dsos,
--symbols, etc, i.e. things marked as filtered in the symbol resolution
routines (thread__find_addr_map(), perf_event__preprocess_sample(),
etc).

But then, in:

  commit 268397cb2a
  Author: Namhyung Kim <namhyung@kernel.org>
  Date:   Tue Apr 22 14:49:31 2014 +0900

    perf top/tui: Update nr_entries properly after a filter is applied

We don't take into account entries that were filtered in
perf_event__preprocess_sample() and friends, which leads to
inconsistency in the browser seek routines, that expects the number of
hist_entry->filtered entries to match what it thinks is the number of
unfiltered, browsable entries.

So, for instance, when we do:

  perf top --symbols ___non_existent_symbol___

the hist_browser__nr_entries() routine thinks there are no filters in
place, uses the hists->nr_entries but all entries are filtered, leading
to a segfault.

Tested with:

   perf top --symbols malloc,free --percentage=relative

Freezing, by pressing 'f', at any time and doing the math on the
percentages ends up with 100%, ditto for:

   perf top --dsos libpthread-2.20.so,libxul.so --percentage=relative

Both were segfaulting, all fixed now.

More work needed to do away with checking if filters are in place, we
should just use the nr_non_filtered_samples counter, no need to
conditionally use it or hists.nr_filter, as what the browser does is
just show unfiltered stuff. An audit of how it is being accounted is
needed, this is the minimal fix.

Reported-by: Michael Petlan <mpetlan@redhat.com>
Fixes: 268397cb2a ("perf top/tui: Update nr_entries properly after a filter is applied")
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-6w01d5q97qk0d64kuojme5in@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-07-13 16:06:09 -03:00
Linus Torvalds f760b87f8f Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Pull networking fixes from David Miller:

 1) Missing list head init in bluetooth hidp session creation, from Tedd
    Ho-Jeong An.

 2) Don't leak SKB in bridge netfilter error paths, from Florian
    Westphal.

 3) ipv6 netdevice private leak in netfilter bridging, fixed by Julien
    Grall.

 4) Fix regression in IP over hamradio bpq encapsulation, from Ralf
    Baechle.

 5) Fix race between rhashtable resize events and table walks, from Phil
    Sutter.

 6) Missing validation of IFLA_VF_INFO netlink attributes, fix from
    Daniel Borkmann.

 7) Missing security layer socket state initialization in tipc code,
    from Stephen Smalley.

 8) Fix shared IRQ handling in boomerang 3c59x interrupt handler, from
    Denys Vlasenko.

 9) Missing minor_idr destroy on module unload on macvtap driver, from
    Johannes Thumshirn.

10) Various pktgen kernel thread races, from Oleg Nesterov.

11) Fix races that can cause packets to be processed in the backlog even
    after a device attached to that SKB has been fully unregistered.
    From Julian Anastasov.

12) bcmgenet driver doesn't account packet drops vs.  errors properly,
    fix from Petri Gynther.

13) Array index validation and off by one fix in DSA layer from Florian
    Fainelli

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (66 commits)
  can: replace timestamp as unique skb attribute
  ARM: dts: dra7x-evm: Prevent glitch on DCAN1 pinmux
  can: c_can: Fix default pinmux glitch at init
  can: rcar_can: unify error messages
  can: rcar_can: print request_irq() error code
  can: rcar_can: fix typo in error message
  can: rcar_can: print signed IRQ #
  can: rcar_can: fix IRQ check
  net: dsa: Fix off-by-one in switch address parsing
  net: dsa: Test array index before use
  net: switchdev: don't abort unsupported operations
  net: bcmgenet: fix accounting of packet drops vs errors
  cdc_ncm: update specs URL
  Doc: z8530book: Fix typo in API-z8530-sync-txdma-open.html
  net: inet_diag: always export IPV6_V6ONLY sockopt for listening sockets
  bridge: mdb: allow the user to delete mdb entry if there's a querier
  net: call rcu_read_lock early in process_backlog
  net: do not process device backlog during unregistration
  bridge: fix potential crash in __netdev_pick_tx()
  net: axienet: Fix devm_ioremap_resource return value check
  ...
2015-07-13 11:18:25 -07:00
Linus Torvalds 34bef46e78 Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
 "This fixes a duplicate dma_unmap_sg call in omap-des and reentrancy
  bugs in the powerpc nx driver which may cause bogus output or worse
  memory corruption"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: nx - Fix reentrancy bugs
  crypto: omap-des - Fix unmapping of dma channels
2015-07-13 10:33:22 -07:00
Mikulas Patocka b06075a98d dm: fix use after free crash due to incorrect cleanup sequence
Linux 4.2-rc1 Commit 0f20972f7b ("dm: factor out a common
cleanup_mapped_device()") moved a common cleanup code to a separate
function.  Unfortunately, that commit incorrectly changed the order of
cleanup, so that it destroys the mapped_device's srcu structure
'io_barrier' before destroying its workqueue.

The function that is executed on the workqueue (dm_wq_work) uses the srcu
structure, thus it may use it after being freed.  That results in a
crash in the LVM test suite's mirror-vgreduce-removemissing.sh test.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Fixes: 0f20972f7b ("dm: factor out a common cleanup_mapped_device()")
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2015-07-13 09:14:11 -04:00
Arnaldo Carvalho de Melo 0bc2f2f7d0 perf symbols: Store if there is a filter in place
When setting yup the symbols library we setup several filter lists,
for dsos, comms, symbols, etc, and there is code that, if there are
filters, do certain operations, like recalculate the number of non
filtered histogram entries in the top/report TUI.

But they were considering just the "Zoom" filters, when they need to
take into account as well the above mentioned filters (perf top --comms,
--dsos, etc).

So store in symbol_conf.has_filter true if any of those filters is in
place.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-f5edfmhq69vfvs1kmikq1wep@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-07-13 08:21:57 -03:00