dm log userspace: fix memory leak in dm_ulog_tfr_init failure path

If cn_add_callback() fails in dm_ulog_tfr_init(), it does not
deallocate prealloced memory but calls cn_del_callback().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Reviewed-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
ecryptfs: avoid to access NULL pointer when write metadata in xattr

Christopher Head 2014-06-28 05:26:20 UTC described:
"I tried to reproduce this on 3.12.21. Instead, when I do "echo hello > foo"
in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash:

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
PGD d7840067 PUD b2c3c067 PMD 0
Oops: 0002 [#1] SMP
Modules linked in: nvidia(PO)
CPU: 3 PID: 3566 Comm: bash Tainted: P           O 3.12.21-gentoo-r1 #2
Hardware name: ASUSTek Computer Inc. G60JX/G60JX, BIOS 206 03/15/2010
task: ffff8801948944c0 ti: ffff8800bad70000 task.ti: ffff8800bad70000
RIP: 0010:[<ffffffff8110eb39>]  [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
RSP: 0018:ffff8800bad71c10  EFLAGS: 00010246
RAX: 00000000000181a4 RBX: ffff880198648480 RCX: 0000000000000000
RDX: 0000000000000004 RSI: ffff880172010450 RDI: 0000000000000000
RBP: ffff880198490e40 R08: 0000000000000000 R09: 0000000000000000
R10: ffff880172010450 R11: ffffea0002c51e80 R12: 0000000000002000
R13: 000000000000001a R14: 0000000000000000 R15: ffff880198490e40
FS:  00007ff224caa700(0000) GS:ffff88019fcc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000bb07f000 CR4: 00000000000007e0
Stack:
ffffffff811826e8 ffff8800a39d8000 0000000000000000 000000000000001a
ffff8800a01d0000 ffff8800a39d8000 ffffffff81185fd5 ffffffff81082c2c
00000001a39d8000 53d0abbc98490e40 0000000000000037 ffff8800a39d8220
Call Trace:
[<ffffffff811826e8>] ? ecryptfs_setxattr+0x40/0x52
[<ffffffff81185fd5>] ? ecryptfs_write_metadata+0x1b3/0x223
[<ffffffff81082c2c>] ? should_resched+0x5/0x23
[<ffffffff8118322b>] ? ecryptfs_initialize_file+0xaf/0xd4
[<ffffffff81183344>] ? ecryptfs_create+0xf4/0x142
[<ffffffff810f8c0d>] ? vfs_create+0x48/0x71
[<ffffffff810f9c86>] ? do_last.isra.68+0x559/0x952
[<ffffffff810f7ce7>] ? link_path_walk+0xbd/0x458
[<ffffffff810fa2a3>] ? path_openat+0x224/0x472
[<ffffffff810fa7bd>] ? do_filp_open+0x2b/0x6f
[<ffffffff81103606>] ? __alloc_fd+0xd6/0xe7
[<ffffffff810ee6ab>] ? do_sys_open+0x65/0xe9
[<ffffffff8157d022>] ? system_call_fastpath+0x16/0x1b
RIP  [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
RSP <ffff8800bad71c10>
CR2: 0000000000000000
---[ end trace df9dba5f1ddb8565 ]---"

If we create a file when we mount with ecryptfs_xattr_metadata option, we will
encounter a crash in this path:
->ecryptfs_create
  ->ecryptfs_initialize_file
    ->ecryptfs_write_metadata
      ->ecryptfs_write_metadata_to_xattr
        ->ecryptfs_setxattr
          ->fsstack_copy_attr_all
It's because our dentry->d_inode used in fsstack_copy_attr_all is NULL, and it
will be initialized when ecryptfs_initialize_file finish.

So we should skip copying attr from lower inode when the value of ->d_inode is
invalid.

Signed-off-by: Chao Yu <chao2.yu@samsung.com>
Cc: stable@vger.kernel.org # v3.2+: b59db43 eCryptfs: Prevent file create race condition
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
To remove non-ascii characters in of_selftest.txt

This patch removes the non-ascii characters in
Documentation/devicetree/of_selftest.txt

Signed-off-by: Gaurav Minocha <gaurav.minocha.os@gmail.com>
[grant.likely: Fix: s/of_fdt_unflatten_device_tree()/of_fdt_unflatten_tree()/]
Signed-off-by: Grant Likely <grant.likely@linaro.org>
x86/xen: Set EFER.NX and EFER.SCE in PVH guests

This fixes two bugs in PVH guests:

  - Not setting EFER.NX means the NX bit in page table entries is
    ignored on Intel processors and causes reserved bit page faults on
    AMD processors.

  - After the Xen commit 7645640d6ff1 ("x86/PVH: don't set EFER_SCE for
    pvh guest") PVH guests are required to set EFER.SCE to enable the
    SYSCALL instruction.

Secondary VCPUs are started with pagetables with the NX bit set so
EFER.NX must be set before using any stack or data segment.
xen_pvh_cpu_early_init() is the new secondary VCPU entry point that
sets EFER before jumping to cpu_bringup_and_idle().

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
xen/xenbus: Correct the comments for xenbus_grant_ring()

A grant reference (which is a positive number) can indicate success, so
the original comments need be improved.

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
xen/xenbus: Remove BUG_ON() when error string trucated

xenbus_va_dev_error() is for printing error, so when error string is
too long to be truncated, need not BUG_ON(), still return truncation
string is OK.

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
xen: remove DEFINE_XENBUS_DRIVER() macro

The DEFINE_XENBUS_DRIVER() macro looks a bit weird and causes sparse
errors.

Replace the uses with standard structure definitions instead.  This is
similar to pci and usb device registration.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Merge tag 'asoc-v3.17-rc4' into asoc-linus

ASoC: Fixes for v3.17

Another round of again fairly unexciting fixes - several driver fixes,
an e-mail address change and a fix for error handling with DPCM.

# gpg: Signature made Wed 10 Sep 2014 12:26:54 BST using RSA key ID 5D5487D0
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg:                 aka "Mark Brown <broonie@debian.org>"
# gpg:                 aka "Mark Brown <broonie@kernel.org>"
# gpg:                 aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg:                 aka "Mark Brown <broonie@linaro.org>"
# gpg:                 aka "Mark Brown <Mark.Brown@linaro.org>"
Merge remote-tracking branches 'asoc/fix/davinci' and 'asoc/fix/max98090' into asoc-linus
Merge remote-tracking branch 'asoc/topic/component' into asoc-next
Merge remote-tracking branch 'asoc/topic/core' into asoc-next
Merge remote-tracking branch 'asoc/topic/dapm' into asoc-next
Merge remote-tracking branch 'asoc/topic/fsl-esai' into asoc-next
Merge remote-tracking branches 'asoc/topic/ab8500', 'asoc/topic/ac97' and 'asoc/topic/cs35l32' into asoc-next
Merge remote-tracking branches 'asoc/topic/cs4265', 'asoc/topic/cs42l52', 'asoc/topic/cs42l56' and 'asoc/topic/da732x' into asoc-next
Merge remote-tracking branches 'asoc/topic/davinci', 'asoc/topic/dmic', 'asoc/topic/drivers', 'asoc/topic/es8328' and 'asoc/topic/fsl' into asoc-next
Merge remote-tracking branches 'asoc/topic/fsl-easi', 'asoc/topic/fsl-sai', 'asoc/topic/fsl-ssi' and 'asoc/topic/intel' into asoc-next
Merge remote-tracking branches 'asoc/topic/max98090', 'asoc/topic/rockchip', 'asoc/topic/rsnd' and 'asoc/topic/rt286' into asoc-next
Merge remote-tracking branches 'asoc/topic/rt5645', 'asoc/topic/rt5677', 'asoc/topic/samsung', 'asoc/topic/sgtl5000' and 'asoc/topic/sh' into asoc-next
Merge remote-tracking branches 'asoc/topic/simple', 'asoc/topic/sirf', 'asoc/topic/spdif', 'asoc/topic/ssm2602' and 'asoc/topic/ssm4567' into asoc-next