Commit Graph

534528 Commits

Author SHA1 Message Date
Guenter Roeck
0d6aaffc3a hwmon: (nct7904) Rename pwm attributes to match hwmon ABI
pwm attributes have well defined names, which should be used.

Cc: Vadim V. Vlasov <vvlasov@dev.rtsoft.ru>
Cc: stable@vger.kernel.org #v4.1+
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-07-29 20:06:46 -07:00
Dave Airlie
bdce3e7c72 Merge branch 'msm-fixes-4.2' of git://people.freedesktop.org/~robclark/linux into drm-fixes
Fix for nasty crash on mdp4 in disable path, fix for dma-buf export,
smb leak on mdp5 which could result in intermittent modeset fails, and
don't let interrupted system call disturb atomic commit once we are
past the point of no return.

* 'msm-fixes-4.2' of git://people.freedesktop.org/~robclark/linux:
  drm/msm/mdp5: release SMB (shared memory blocks) in various cases
  drm/msm: change to uninterruptible wait in atomic commit
  drm/msm: mdp4: Fix drm_framebuffer dereference crash
  drm/msm: fix msm_gem_prime_get_sg_table()
2015-07-30 12:41:44 +10:00
Dave Airlie
d698291cd4 Merge branch 'drm-fixes-4.2' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Radeon and amdgpu fixes for 4.2.  The audio fix ended up being more
invasive than I would have liked, but this should finally fix up the
last of the regressions since DP audio support was added.

* 'drm-fixes-4.2' of git://people.freedesktop.org/~agd5f/linux:
  drm/amdgpu: add new parameter to seperate map and unmap
  drm/amdgpu: hdp_flush is not needed for inside IB
  drm/amdgpu: different emit_ib for gfx and compute
  drm/amdgpu: information leak in amdgpu_info_ioctl()
  drm/amdgpu: clean up init sequence for failures
  drm/radeon/combios: add some validation of lvds values
  drm/radeon: rework audio modeset to handle non-audio hdmi features
  drm/radeon: rework audio detect (v4)
  drm/amdgpu: Drop drm/ prefix for including drm.h in amdgpu_drm.h
  drm/radeon: Drop drm/ prefix for including drm.h in radeon_drm.h
2015-07-30 12:40:27 +10:00
David S. Miller
b2428f94f4 Merge branch 'netcp-fixes'
Murali Karicheri says:

====================
net: netcp: bug fixes for dynamic module support

This series fixes few bugs to allow keystone netcp modules to be
dynamically loaded and removed. Currently it allows following
sequence multiple times

 insmod cpsw_ale.ko
 insmod davinci_mdio.ko
 insmod keystone_netcp.ko
 insmod keystone_netcp_ethss.ko
 ifup eth0
 ifup eth1
 ping <hosts on eth0>
 ping <hosts on eth1>
 ifdown eth1
 ifdown eth0
 rmmod keystone_netcp_ethss.ko
 rmmod keystone_netcp.ko
 rmmod davinci_mdio.ko
 rmmod cpsw_ale.ko
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 18:37:41 -07:00
Karicheri, Muralidharan
31a184b7ac net: netcp: ethss: cleanup gbe_probe() and gbe_remove() functions
This patch clean up error handle code to use goto label properly. In some
cases, the code unnecessarily use goto instead of just returning the error
code.  Code also make explicit calls to devm_* APIs on error which is
not necessary. In the gbe_remove() also it makes similar calls which is
also unnecessary.

Also fix few checkpatch warnings

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 18:37:41 -07:00
Karicheri, Muralidharan
c20afae75c net: netcp: ethss: fix up incorrect use of list api
The code seems to assume a null is returned when the list is empty
from first_sec_slave() to break the loop which is incorrect. Fix the
code by using list_empty().

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 18:37:40 -07:00
Karicheri, Muralidharan
01a030996e net: netcp: fix cleanup interface list in netcp_remove()
Currently if user do rmmod keystone_netcp.ko following warning is
seen :-

[   59.035891] ------------[ cut here ]------------
[   59.040535] WARNING: CPU: 2 PID: 1619 at drivers/net/ethernet/ti/
netcp_core.c:2127 netcp_remove)

This is because the interface list is not cleaned up in netcp_remove.
This patch fixes this. Also fix some checkpatch related warnings.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 18:37:40 -07:00
Linus Torvalds
d41a83ba4b Power management and ACPI fixes for v4.2-rc5
- Fix a recently introduced issue in the cpufreq core causing
    it to attempt to create duplicate symbolic links to the policy
    directory in sysfs for CPUs that are offline when the cpufreq
    driver is being registered (Rafael J Wysocki).
 
  - Fix a recently introduced problem in the ACPI device power
    management core code causing it to store an incorrect value
    in the device object's power.state field in some cases which
    in turn leads to attempts to turn power resources off while
    they should still be on going forward (Mika Westerberg).
 
  - Fix an intel_pstate driver issue introduced during the 4.1 cycle
    which leads to kernel panics on boot on Knights Landing chips due
    to incomplete support for them in that driver (Lukasz Anaczkowski).
 
 /
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABCAAGBQJVuUbwAAoJEILEb/54YlRxb64P/jtDaEmhvMDLnOAP/8/+v+Hq
 kRLF2T+zcX7yu1wEjqWsO94ir+IYX51rbIkMp0rt8+m/CqhTF8QyqvQgaxW2fMAj
 KA6++qT/c+8yeTdSSoxDSV4ux3Ax+d22Q560NOqIFFKK0b+IRSTVirzjyhcMrBJS
 iiaTS8R6o19BttjZrJw4SRnNBXoAeEHeVlMXOqk3S6lq/b89XGIqG93mzaXsFUdz
 xXmkkqudP6z5+jymmiTGp0X+sIpDlR7UruZnk0hZZbEEdmEodlkVFOtYQEV1cro1
 +e3lhMcvG1uO5Sxb5nabKtq8J8rG/buKP+vvsBifKrkxNZMSdnjVvHKxqooVkKVt
 MwGUrjnZhE1dvgL9QvnDNlafitRmrPtolohZ1v7YEXjhsvbbZafr8kkXgo+OmwUs
 wPYmzRg5H2+Di9jhms6hV1z89GtyzsVVOigf3cQZd7hBye4ZsPdWVx0QMyU+0+nC
 GXRRl/8zKyCWCRdnnBwokWs3wiMUAGJ998WPtgo9LhhCXV/JxKIzTXDq+vYxUJ7g
 Z5tbtg7Sgg4VH6WqVQC07x24FFwXKLVtrKd60x0/gbGXYCf7TPwO2dQKjaiF4cHb
 4XSdc2RDEUd2uV7r22j8MaHkPEC33V/Z76nVL49wu8TE4/n0KF6O0+RXMB9Mvsmr
 iZ/CV3rgDFfhf3trOC9v
 =tXB4
 -----END PGP SIGNATURE-----

Merge tag 'pm+acpi-4.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management and ACPI fixes from Rafael Wysocki:
 "These fix three regressions, two recent ones (cpufreq core and ACPI
  device power management) and one introduced during the 4.1 cycle
  (intel_pstate).

  Specifics:

   - Fix a recently introduced issue in the cpufreq core causing it to
     attempt to create duplicate symbolic links to the policy directory
     in sysfs for CPUs that are offline when the cpufreq driver is being
     registered (Rafael J Wysocki)

   - Fix a recently introduced problem in the ACPI device power
     management core code causing it to store an incorrect value in the
     device object's power.state field in some cases which in turn leads
     to attempts to turn power resources off while they should still be
     on going forward (Mika Westerberg)

   - Fix an intel_pstate driver issue introduced during the 4.1 cycle
     which leads to kernel panics on boot on Knights Landing chips due
     to incomplete support for them in that driver (Lukasz Anaczkowski)"

* tag 'pm+acpi-4.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpufreq: Avoid attempts to create duplicate symbolic links
  ACPI / PM: Use target_state to set the device power state
  intel_pstate: Add get_scaling cpu_defaults param to Knights Landing
2015-07-29 18:14:48 -07:00
Linus Torvalds
d0db3a397d - Fix DM thinp to consistently return -ENOSPC when out of data space
- Fix a logic bug in the DM cache smq policy's creation error path
 
 - Revert a DM cache 4.2-rc3 change that reduced writeback efficiency
 
 - Fix a hang on DM cache device destruction due to improper
   prealloc_used accounting introduced in 4.2-rc3
 
 - Update URL for dm-crypt wiki page
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJVuWg1AAoJEMUj8QotnQNaTyUH/2csU3My+lgTW85BlEnm3LOa
 zeuI+aeTSJ7hTO5x4GYZwK6UTXRts8iR2Np3yZozXv94EioAWwhl6yrJU+hOfwOC
 Kse1/xR6wTE2BPMD0rRfscGnXvydilYpcOZCyKQ7OR28Afr6O1HCbDa/Qqnuqmox
 yb8vzJp0pYrLC6CjuTep/ofuMkIehCib5XEzwoM/7GsgiLZQgikSEuKmz+Q5hgas
 ggsb6weQ5KbHnlBQGQfSkpART9aKbo4BNZJLJ+G3koZFEwo21YuQInIPfAFi7w+d
 AUi0UNkVwlqNcXQFSegDCUbw59/JklUdP4hrm6CocWPAnk7XtoNomlJwQNBFUEs=
 =YeBR
 -----END PGP SIGNATURE-----

Merge tag 'dm-4.2-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

Pull device mapper fixes from Mike Snitzer:

 - fix DM thinp to consistently return -ENOSPC when out of data space

 - fix a logic bug in the DM cache smq policy's creation error path

 - revert a DM cache 4.2-rc3 change that reduced writeback efficiency

 - fix a hang on DM cache device destruction due to improper
   prealloc_used accounting introduced in 4.2-rc3

 - update URL for dm-crypt wiki page

* tag 'dm-4.2-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm cache: fix device destroy hang due to improper prealloc_used accounting
  Revert "dm cache: do not wake_worker() in free_migration()"
  dm crypt: update wiki page URL
  dm cache policy smq: fix alloc_bitset check that always evaluates as false
  dm thin: return -ENOSPC when erroring retry list due to out of data space
2015-07-29 18:08:48 -07:00
Daniel Borkmann
2482abb93e ebpf, x86: fix general protection fault when tail call is invoked
With eBPF JIT compiler enabled on x86_64, I was able to reliably trigger
the following general protection fault out of an eBPF program with a simple
tail call, f.e. tracex5 (or a stripped down version of it):

  [  927.097918] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
  [...]
  [  927.100870] task: ffff8801f228b780 ti: ffff880016a64000 task.ti: ffff880016a64000
  [  927.102096] RIP: 0010:[<ffffffffa002440d>]  [<ffffffffa002440d>] 0xffffffffa002440d
  [  927.103390] RSP: 0018:ffff880016a67a68  EFLAGS: 00010006
  [  927.104683] RAX: 5a5a5a5a5a5a5a5a RBX: 0000000000000000 RCX: 0000000000000001
  [  927.105921] RDX: 0000000000000000 RSI: ffff88014e438000 RDI: ffff880016a67e00
  [  927.107137] RBP: ffff880016a67c90 R08: 0000000000000000 R09: 0000000000000001
  [  927.108351] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880016a67e00
  [  927.109567] R13: 0000000000000000 R14: ffff88026500e460 R15: ffff880220a81520
  [  927.110787] FS:  00007fe7d5c1f740(0000) GS:ffff880265000000(0000) knlGS:0000000000000000
  [  927.112021] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [  927.113255] CR2: 0000003e7bbb91a0 CR3: 000000006e04b000 CR4: 00000000001407e0
  [  927.114500] Stack:
  [  927.115737]  ffffc90008cdb000 ffff880016a67e00 ffff88026500e460 ffff880220a81520
  [  927.117005]  0000000100000000 000000000000001b ffff880016a67aa8 ffffffff8106c548
  [  927.118276]  00007ffcdaf22e58 0000000000000000 0000000000000000 ffff880016a67ff0
  [  927.119543] Call Trace:
  [  927.120797]  [<ffffffff8106c548>] ? lookup_address+0x28/0x30
  [  927.122058]  [<ffffffff8113d176>] ? __module_text_address+0x16/0x70
  [  927.123314]  [<ffffffff8117bf0e>] ? is_ftrace_trampoline+0x3e/0x70
  [  927.124562]  [<ffffffff810c1a0f>] ? __kernel_text_address+0x5f/0x80
  [  927.125806]  [<ffffffff8102086f>] ? print_context_stack+0x7f/0xf0
  [  927.127033]  [<ffffffff810f7852>] ? __lock_acquire+0x572/0x2050
  [  927.128254]  [<ffffffff810f7852>] ? __lock_acquire+0x572/0x2050
  [  927.129461]  [<ffffffff8119edfa>] ? trace_call_bpf+0x3a/0x140
  [  927.130654]  [<ffffffff8119ee4a>] trace_call_bpf+0x8a/0x140
  [  927.131837]  [<ffffffff8119edfa>] ? trace_call_bpf+0x3a/0x140
  [  927.133015]  [<ffffffff8119f008>] kprobe_perf_func+0x28/0x220
  [  927.134195]  [<ffffffff811a1668>] kprobe_dispatcher+0x38/0x60
  [  927.135367]  [<ffffffff81174b91>] ? seccomp_phase1+0x1/0x230
  [  927.136523]  [<ffffffff81061400>] kprobe_ftrace_handler+0xf0/0x150
  [  927.137666]  [<ffffffff81174b95>] ? seccomp_phase1+0x5/0x230
  [  927.138802]  [<ffffffff8117950c>] ftrace_ops_recurs_func+0x5c/0xb0
  [  927.139934]  [<ffffffffa022b0d5>] 0xffffffffa022b0d5
  [  927.141066]  [<ffffffff81174b91>] ? seccomp_phase1+0x1/0x230
  [  927.142199]  [<ffffffff81174b95>] seccomp_phase1+0x5/0x230
  [  927.143323]  [<ffffffff8102c0a4>] syscall_trace_enter_phase1+0xc4/0x150
  [  927.144450]  [<ffffffff81174b95>] ? seccomp_phase1+0x5/0x230
  [  927.145572]  [<ffffffff8102c0a4>] ? syscall_trace_enter_phase1+0xc4/0x150
  [  927.146666]  [<ffffffff817f9a9f>] tracesys+0xd/0x44
  [  927.147723] Code: 48 8b 46 10 48 39 d0 76 2c 8b 85 fc fd ff ff 83 f8 20 77 21 83
                       c0 01 89 85 fc fd ff ff 48 8d 44 d6 80 48 8b 00 48 83 f8 00 74
                       0a <48> 8b 40 20 48 83 c0 33 ff e0 48 89 d8 48 8b 9d d8 fd ff
                       ff 4c
  [  927.150046] RIP  [<ffffffffa002440d>] 0xffffffffa002440d

The code section with the instructions that traps points into the eBPF JIT
image of the root program (the one invoking the tail call instruction).

Using bpf_jit_disasm -o on the eBPF root program image:

  [...]
  4e:   mov    -0x204(%rbp),%eax
        8b 85 fc fd ff ff
  54:   cmp    $0x20,%eax               <--- if (tail_call_cnt > MAX_TAIL_CALL_CNT)
        83 f8 20
  57:   ja     0x000000000000007a
        77 21
  59:   add    $0x1,%eax                <--- tail_call_cnt++
        83 c0 01
  5c:   mov    %eax,-0x204(%rbp)
        89 85 fc fd ff ff
  62:   lea    -0x80(%rsi,%rdx,8),%rax  <--- prog = array->prog[index]
        48 8d 44 d6 80
  67:   mov    (%rax),%rax
        48 8b 00
  6a:   cmp    $0x0,%rax                <--- check for NULL
        48 83 f8 00
  6e:   je     0x000000000000007a
        74 0a
  70:   mov    0x20(%rax),%rax          <--- GPF triggered here! fetch of bpf_func
        48 8b 40 20                              [ matches <48> 8b 40 20 ... from above ]
  74:   add    $0x33,%rax               <--- prologue skip of new prog
        48 83 c0 33
  78:   jmpq   *%rax                    <--- jump to new prog insns
        ff e0
  [...]

The problem is that rax has 5a5a5a5a5a5a5a5a, which suggests a tail call
jump to map slot 0 is pointing to a poisoned page. The issue is the following:

lea instruction has a wrong offset, i.e. it should be ...

  lea    0x80(%rsi,%rdx,8),%rax

... but it actually seems to be ...

  lea   -0x80(%rsi,%rdx,8),%rax

... where 0x80 is offsetof(struct bpf_array, prog), thus the offset needs
to be positive instead of negative. Disassembling the interpreter, we btw
similarly do:

  [...]
  c88:  lea     0x80(%rax,%rdx,8),%rax  <--- prog = array->prog[index]
        48 8d 84 d0 80 00 00 00
  c90:  add     $0x1,%r13d
        41 83 c5 01
  c94:  mov     (%rax),%rax
        48 8b 00
  [...]

Now the other interesting fact is that this panic triggers only when things
like CONFIG_LOCKDEP are being used. In that case offsetof(struct bpf_array,
prog) starts at offset 0x80 and in non-CONFIG_LOCKDEP case at offset 0x50.
Reason is that the work_struct inside struct bpf_map grows by 48 bytes in my
case due to the lockdep_map member (which also has CONFIG_LOCK_STAT enabled
members).

Changing the emitter to always use the 4 byte displacement in the lea
instruction fixes the panic on my side. It increases the tail call instruction
emission by 3 more byte, but it should cover us from various combinations
(and perhaps other future increases on related structures).

After patch, disassembly:

  [...]
  9e:   lea    0x80(%rsi,%rdx,8),%rax   <--- CONFIG_LOCKDEP/CONFIG_LOCK_STAT
        48 8d 84 d6 80 00 00 00
  a6:   mov    (%rax),%rax
        48 8b 00
  [...]

  [...]
  9e:   lea    0x50(%rsi,%rdx,8),%rax   <--- No CONFIG_LOCKDEP
        48 8d 84 d6 50 00 00 00
  a6:   mov    (%rax),%rax
        48 8b 00
  [...]

Fixes: b52f00e6a7 ("x86: bpf_jit: implement bpf_tail_call() helper")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 17:02:19 -07:00
Nikolay Aleksandrov
7ae90a4f96 bridge: mdb: fix delmdb state in the notification
Since mdb states were introduced when deleting an entry the state was
left as it was set in the delete request from the user which leads to
the following output when doing a monitor (for example):
$ bridge mdb add dev br0 port eth3 grp 239.0.0.1 permanent
(monitor) dev br0 port eth3 grp 239.0.0.1 permanent
$ bridge mdb del dev br0 port eth3 grp 239.0.0.1 permanent
(monitor) dev br0 port eth3 grp 239.0.0.1 temp
^^^
Note the "temp" state in the delete notification which is wrong since
the entry was permanent, the state in a delete is always reported as
"temp" regardless of the real state of the entry.

After this patch:
$ bridge mdb add dev br0 port eth3 grp 239.0.0.1 permanent
(monitor) dev br0 port eth3 grp 239.0.0.1 permanent
$ bridge mdb del dev br0 port eth3 grp 239.0.0.1 permanent
(monitor) dev br0 port eth3 grp 239.0.0.1 permanent

There's one important note to make here that the state is actually not
matched when doing a delete, so one can delete a permanent entry by
stating "temp" in the end of the command, I've chosen this fix in order
not to break user-space tools which rely on this (incorrect) behaviour.

So to give an example after this patch and using the wrong state:
$ bridge mdb add dev br0 port eth3 grp 239.0.0.1 permanent
(monitor) dev br0 port eth3 grp 239.0.0.1 permanent
$ bridge mdb del dev br0 port eth3 grp 239.0.0.1 temp
(monitor) dev br0 port eth3 grp 239.0.0.1 permanent

Note the state of the entry that got deleted is correct in the
notification.

Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Fixes: ccb1c31a7a ("bridge: add flags to distinguish permanent mdb entires")
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 15:02:30 -07:00
Satish Ashok
544586f742 bridge: mcast: give fast leave precedence over multicast router and querier
When fast leave is configured on a bridge port and an IGMP leave is
received for a group, the group is not deleted immediately if there is
a router detected or if multicast querier is configured.
Ideally the group should be deleted immediately when fast leave is
configured.

Signed-off-by: Satish Ashok <sashok@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 14:57:05 -07:00
Wentao Xu
b4cba04f05 drm/msm/mdp5: release SMB (shared memory blocks) in various cases
Release all blocks after the pipe is disabled, even when vsync
didn't happen in some error cases. Allow requesting SMB multiple
times before configuring to hardware, by releasing blocks not
programmed to hardware yet for shrinking case.

This fixes a potential leak of shared memory pool blocks.

Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
Tested-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-07-29 16:38:24 -04:00
Wentao Xu
99fc1bc48f drm/msm: change to uninterruptible wait in atomic commit
The atomic commit cannot easily undo and return an error once the
state is swapped. Change to uninterruptible wait, and ignore the
timeout error.

Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-07-29 16:38:24 -04:00
Archit Taneja
a1c3e3e01e drm/msm: mdp4: Fix drm_framebuffer dereference crash
mdp4_get_frame_format() can dereference a drm_framebuffer when it's NULL.
Call it in mdp4_plane_mode_set only when we know fb is non-NULL.

Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-07-29 16:38:24 -04:00
Rob Clark
ac45146733 drm/msm: fix msm_gem_prime_get_sg_table()
We need to return a new sgt, since the caller takes ownership of it.

Reported-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-07-29 16:38:24 -04:00
monk.liu
194a33643b drm/amdgpu: add new parameter to seperate map and unmap
Signed-off-by: monk.liu <monk.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2015-07-29 16:06:45 -04:00
monk.liu
e722b71a54 drm/amdgpu: hdp_flush is not needed for inside IB
hdp flush is not needed for IBs that dispatched from kernel inside
because there is no video memory host access

Signed-off-by: monk.liu <monk.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2015-07-29 16:06:17 -04:00
monk.liu
93323131d6 drm/amdgpu: different emit_ib for gfx and compute
compute ring didn't use const engine byfar, so ignore CE things in
compute routine

Signed-off-by: monk.liu <monk.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2015-07-29 16:05:57 -04:00
Dan Carpenter
c193fa91b9 drm/amdgpu: information leak in amdgpu_info_ioctl()
We recently changed the drm_amdgpu_info_device struct so now there is
a 4 byte hole at the end.  We need to initialize it so we don't disclose
secret information from the stack.

Fixes: fa92754e9c ('drm/amdgpu: add VCE harvesting instance query')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-07-29 15:50:37 -04:00
Alex Deucher
8faf0e08d5 drm/amdgpu: clean up init sequence for failures
If we fail during device init, record what state each
block is in so that we can tear down clearly.

Fixes various problems on device init failure.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-07-29 15:50:36 -04:00
Alex Deucher
0a90a0cff9 drm/radeon/combios: add some validation of lvds values
Fixes a broken hsync start value uncovered by:
abc0b1447d
(drm: Perform basic sanity checks on probed modes)

The driver handled the bad hsync start elsewhere, but
the above commit prevented it from getting added.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91401

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2015-07-29 15:50:36 -04:00
Alex Deucher
7726e72b3d drm/radeon: rework audio modeset to handle non-audio hdmi features
Need to setup the deep color and avi packets regardless of
audio setup.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-07-29 15:50:28 -04:00
Alex Deucher
d0ea397e22 drm/radeon: rework audio detect (v4)
1. Always assign audio function pointers even if the display does
not support audio.  We need to properly disable the audio stream
when when using a non-audio capable monitor.  Fixes purple line
on some hdmi monitors.

2. Check if a pin is in use by another encoder before disabling
it.

v2: make sure we've fetched the edid before checking audio and
    look up the encoder before calling audio_detect since
    connector->encoder may not be assigned yet.  Separate
    pin and afmt.  They are allocated at different times and
    have no dependency on eachother.
v3: fix connector fetching in encoder functions
v4: fix missed dig->pin check in dce6_afmt_write_latency_fields

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=93701
https://bugzilla.redhat.com/show_bug.cgi?id=1236337
https://bugs.freedesktop.org/show_bug.cgi?id=91041

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2015-07-29 15:48:05 -04:00
Michel Dänzer
b3fcf36aee drm/amdgpu: Drop drm/ prefix for including drm.h in amdgpu_drm.h
This allows amdgpu_drm.h to be reused verbatim in libdrm.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
2015-07-29 15:48:05 -04:00
Michel Dänzer
e13af53e7d drm/radeon: Drop drm/ prefix for including drm.h in radeon_drm.h
This allows radeon_drm.h to be reused verbatim in libdrm.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
2015-07-29 15:48:04 -04:00
Toshiaki Makita
df356d5e81 bridge: Fix network header pointer for vlan tagged packets
There are several devices that can receive vlan tagged packets with
CHECKSUM_PARTIAL like tap, possibly veth and xennet.
When (multiple) vlan tagged packets with CHECKSUM_PARTIAL are forwarded
by bridge to a device with the IP_CSUM feature, they end up with checksum
error because before entering bridge, the network header is set to
ETH_HLEN (not including vlan header length) in __netif_receive_skb_core(),
get_rps_cpu(), or drivers' rx functions, and nobody fixes the pointer later.

Since the network header is exepected to be ETH_HLEN in flow-dissection
and hash-calculation in RPS in rx path, and since the header pointer fix
is needed only in tx path, set the appropriate network header on forwarding
packets.

Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 12:20:16 -07:00
Mike Snitzer
795e633a2d dm cache: fix device destroy hang due to improper prealloc_used accounting
Commit 665022d72f ("dm cache: avoid calls to prealloc_free_structs() if
possible") introduced a regression that caused the removal of a DM cache
device to hang in cache_postsuspend()'s call to wait_for_migrations()
with the following stack trace:

  [<ffffffff81651457>] schedule+0x37/0x80
  [<ffffffffa041e21b>] cache_postsuspend+0xbb/0x470 [dm_cache]
  [<ffffffff810ba970>] ? prepare_to_wait_event+0xf0/0xf0
  [<ffffffffa0006f77>] dm_table_postsuspend_targets+0x47/0x60 [dm_mod]
  [<ffffffffa0001eb5>] __dm_destroy+0x215/0x250 [dm_mod]
  [<ffffffffa0004113>] dm_destroy+0x13/0x20 [dm_mod]
  [<ffffffffa00098cd>] dev_remove+0x10d/0x170 [dm_mod]
  [<ffffffffa00097c0>] ? dev_suspend+0x240/0x240 [dm_mod]
  [<ffffffffa0009f85>] ctl_ioctl+0x255/0x4d0 [dm_mod]
  [<ffffffff8127ac00>] ? SYSC_semtimedop+0x280/0xe10
  [<ffffffffa000a213>] dm_ctl_ioctl+0x13/0x20 [dm_mod]
  [<ffffffff811fd432>] do_vfs_ioctl+0x2d2/0x4b0
  [<ffffffff81117d5f>] ? __audit_syscall_entry+0xaf/0x100
  [<ffffffff81022636>] ? do_audit_syscall_entry+0x66/0x70
  [<ffffffff811fd689>] SyS_ioctl+0x79/0x90
  [<ffffffff81023e58>] ? syscall_trace_leave+0xb8/0x110
  [<ffffffff81654f6e>] entry_SYSCALL_64_fastpath+0x12/0x71

Fix this by accounting for the call to prealloc_data_structs()
immediately _before_ the call as opposed to after.  This is needed
because it is possible to break out of the control loop after the call
to prealloc_data_structs() but before prealloc_used was set to true.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2015-07-29 14:32:09 -04:00
Mike Snitzer
3508e6590d Revert "dm cache: do not wake_worker() in free_migration()"
This reverts commit 386cb7cdee.

Taking the wake_worker() out of free_migration() will slow writeback
dramatically, and hence adaptability.

Say we have 10k blocks that need writing back, but are only able to
issue 5 concurrently due to the migration bandwidth: it's imperative
that we wake_worker() immediately after migration completion; waiting
for the next 1 second wake up (via do_waker) means it'll take a long
time to write that all back.

Reported-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2015-07-29 14:32:08 -04:00
U. Artie Eoff
342e844905 ALSA: hda - Fix race between PM ops and HDA init/probe
PM ops could be triggered before HDA is done initializing
and cause PM to set HDA controller to D3Hot.  This can result
in "CORB reset timeout#2, CORBRP = 65535" and "no codecs
initialized".  Additionally, PM ops can be triggered before
azx_probe_continue finishes (async probe).  This can result
in a NULL deref kernel crash.

To fix this, avoid PM ops if !chip->running.

Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-07-29 19:37:26 +02:00
Linus Torvalds
86ea07ca84 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Martin Schwidefsky:
 "Two bug fixes:

   - fix a crash on pre-z10 hardware due to cache-info

   - fix an issue with classic BPF programs in the eBPF JIT"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/cachinfo: add missing facility check to init_cache_level()
  s390/bpf: clear correct BPF accumulator register
2015-07-29 10:23:14 -07:00
Linus Torvalds
d9065f44be VFIO fixes for v4.2
- Fix a lockdep reported deadlock in device open error path (Alex Williamson)
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJVuPowAAoJECObm247sIsii7gP/0Lw9csfXBuZSBVEQzp6okYD
 1BJoL9c1bfR2f+CKFfnc5JDCgdKGIATWYdZ04M6UGDbRTIRfgd11W46kjneNZS/c
 FV6NjuabY2YGpj6ckIqi/FzJna93ZucLnaGaCGKyLYdy1Yc50thBQZp/zFvPLhZi
 fEWz7toOB0sG0/1HTqZN8Mg5qjwXR79+M6qQIOUZSmIfKJFXWcDlUffraS6Ls2Rx
 O7MlNNUthRf9FI9wX1RnYeRvotzuy1pwQpeSkUi2CPWn7/m/+ynIz4qkakOGnerX
 5QwjQd4Ww3BgrAyJ7js9JyfvhQK5He/GZVmQWRuAC0hEDu2JK4AlpOneUc63SaP9
 ap+B87pxynmomRAKrgaB5bqh5zzrMPaXooowc3eQ613a5ThVFNWRw8PaK0/yQepX
 HipvNkR0GVM6aJuXCYTiSyOrL/T8kaSlkn8NXNbMMwZZZiVQLtTlIoCU717iKqbb
 Ig5Ut9h8OJcNljeIhdeEXJGwCy24BTo5AnABuCUnpZKv9fGryruGQHa5buiirhvR
 6Rbdi8HIAvg/KzRtjTgDtHMK1p0DDbQVTh8rAAivHRewg5wkNosILKyvQwbeVc2U
 1/L3ewqyRYQuHzS1/MB8M+CYFF3HSQyJnVUzJ94dqrWNHzPjGSb3E0iQfPRhcydM
 rfwPgM7vpIehTnCMTqlx
 =e/+g
 -----END PGP SIGNATURE-----

Merge tag 'vfio-v4.2-rc5' of git://github.com/awilliam/linux-vfio

Pull VFIO fix from Alex Williamson:
 "Fix a lockdep reported deadlock in device open error path"

* tag 'vfio-v4.2-rc5' of git://github.com/awilliam/linux-vfio:
  vfio: Fix lockdep issue
2015-07-29 10:17:55 -07:00
Linus Torvalds
733db573a6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
Pull SCSI target fixes from Nicholas Bellinger:
 "This series is larger than what I'd normally be conformable with
  sending for a -rc5 PULL request..

  However, the bulk of the series is localized to qla2xxx target
  specific fixes that address a number of real-world correctness issues,
  that have been outstanding on the list for ~6 weeks now.  They where
  submitted + verified + acked by the HW LLD vendor, contributed by a
  major production customer of the code, and are marked for v3.18.y
  stable code.

  That said, I don't see a good reason to wait another month to get
  these fixes into mainline.

  Beyond the qla2xx specific fixes, this series also includes:

   - bugfix for a long standing use-after-free in iscsi-target during
     TPG shutdown + demo-mode sessions.

   - bugfix for a >= v4.0 regression OOPs in iscsi-target during a
     iscsi_start_kthreads() failure.

   - bugfix for a >= v4.0 regression hang in iscsi-target for iser
     explicit session/connection logout.

   - bugfix for a iser-target bug where a early CMA REJECTED status
     during login triggers a NULL pointer dereference OOPs.

   - bugfixes for a handful of v4.2-rc1 specific regressions related to
     the larger set of recent backend configfs attribute changes.

  A big thanks to QLogic + Pure Storage for the qla2xxx target bugfixes"

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: (28 commits)
  Documentation/target: Fix tcm_mod_builder.py build breakage
  iser-target: Fix REJECT CM event use-after-free OOPs
  iscsi-target: Fix iser explicit logout TX kthread leak
  iscsi-target: Fix iscsit_start_kthreads failure OOPs
  iscsi-target: Fix use-after-free during TPG session shutdown
  qla2xxx: terminate exchange when command is aborted by LIO
  qla2xxx: drop cmds/tmrs arrived while session is being deleted
  qla2xxx: disable scsi_transport_fc registration in target mode
  qla2xxx: added sess generations to detect RSCN update races
  qla2xxx: Abort stale cmds on qla_tgt_wq when plogi arrives
  qla2xxx: delay plogi/prli ack until existing sessions are deleted
  qla2xxx: cleanup cmd in qla workqueue before processing TMR
  qla2xxx: kill sessions/log out initiator on RSCN and port down events
  qla2xxx: fix command initialization in target mode.
  qla2xxx: Remove msleep in qlt_send_term_exchange
  qla2xxx: adjust debug flags
  qla2xxx: release request queue reservation.
  qla2xxx: Add flush after updating ATIOQ consumer index.
  qla2xxx: Enable target mode for ISP27XX
  qla2xxx: Fix hardware lock/unlock issue causing kernel panic.
  ...
2015-07-29 09:54:40 -07:00
Rafael J. Wysocki
d29809b8eb Merge branches 'pm-cpufreq' and 'acpi-pm'
* pm-cpufreq:
  cpufreq: Avoid attempts to create duplicate symbolic links
  intel_pstate: Add get_scaling cpu_defaults param to Knights Landing

* acpi-pm:
  ACPI / PM: Use target_state to set the device power state
2015-07-29 15:19:39 +02:00
Chris Wilson
ee0a227b7a drm/i915: Replace WARN inside I915_READ64_2x32 with retry loop
Since we may conceivably encounter situations where the upper part of the
64bit register changes between reads, for example when a timestamp
counter overflows, change the WARN into a retry loop.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-29 10:22:18 +02:00
Yao-Wen Mao
2d1cb7f658 ALSA: usb-audio: add dB range mapping for some devices
Add the correct dB ranges of Bose Companion 5 and Drangonfly DAC 1.2.

Signed-off-by: Yao-Wen Mao <yaowen@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-07-29 09:28:02 +02:00
Dave Airlie
520e8bfc35 Merge branch 'linux-4.2' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
Two more nouveau fixes.

* 'linux-4.2' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau/nouveau/ttm: fix tiled system memory with Maxwell
  drm/nouveau/kms/nv50-: guard against enabling cursor on disabled heads
2015-07-29 17:21:38 +10:00
Alexander Drozdov
dbd46ab412 packet: tpacket_snd(): fix signed/unsigned comparison
tpacket_fill_skb() can return a negative value (-errno) which
is stored in tp_len variable. In that case the following
condition will be (but shouldn't be) true:

tp_len > dev->mtu + dev->hard_header_len

as dev->mtu and dev->hard_header_len are both unsigned.

That may lead to just returning an incorrect EMSGSIZE errno
to the user.

Fixes: 52f1454f62 ("packet: allow to transmit +4 byte in TX_RING slot for VLAN case")
Signed-off-by: Alexander Drozdov <al.drozdov@gmail.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-29 00:09:58 -07:00
Takashi Iwai
3a05d12f46 ALSA: hda - Apply a fixup to Dell Vostro 5480
Dell Vostro 5480 (1028:069a) needs the very same quirk used for Vostro
5470 model to make bass speakers properly working.

Reported-and-tested-by: Paulo Roberto de Oliveira Castro <p.oliveira.castro@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-07-29 09:04:52 +02:00
Eric Dumazet
11c91ef98f arp: filter NOARP neighbours for SIOCGARP
When arp is off on a device, and ioctl(SIOCGARP) is queried,
a buggy answer is given with MAC address of the device, instead
of the mac address of the destination/gateway.

We filter out NUD_NOARP neighbours for /proc/net/arp,
we must do the same for SIOCGARP ioctl.

Tested:

lpaa23:~# ./arp 10.246.7.190
MAC=00:01:e8:22:cb:1d      // correct answer

lpaa23:~# ip link set dev eth0 arp off
lpaa23:~# cat /proc/net/arp   # check arp table is now 'empty'
IP address       HW type     Flags       HW address    Mask     Device
lpaa23:~# ./arp 10.246.7.190
MAC=00:1a:11:c3:0d:7f   // buggy answer before patch (this is eth0 mac)

After patch :

lpaa23:~# ip link set dev eth0 arp off
lpaa23:~# ./arp 10.246.7.190
ioctl(SIOCGARP) failed: No such device or address

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Vytautas Valancius <valas@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-28 23:41:24 -07:00
David Ward
865b804244 net/ipv4: suppress NETDEV_UP notification on address lifetime update
This notification causes the FIB to be updated, which is not needed
because the address already exists, and more importantly it may undo
intentional changes that were made to the FIB after the address was
originally added. (As a point of comparison, when an address becomes
deprecated because its preferred lifetime expired, a notification on
this chain is not generated.)

The motivation for this commit is fixing an incompatibility between
DHCP clients which set and update the address lifetime according to
the lease, and a commercial VPN client which replaces kernel routes
in a way that outbound traffic is sent only through the tunnel (and
disconnects if any further route changes are detected via netlink).

Signed-off-by: David Ward <david.ward@ll.mit.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-28 23:38:13 -07:00
Nikolay Aleksandrov
76b91c32dd bridge: stp: when using userspace stp stop kernel hello and hold timers
These should be handled only by the respective STP which is in control.
They become problematic for devices with limited resources with many
ports because the hold_timer is per port and fires each second and the
hello timer fires each 2 seconds even though it's global. While in
user-space STP mode these timers are completely unnecessary so it's better
to keep them off.
Also ensure that when the bridge is up these timers are started only when
running with kernel STP.

Signed-off-by: Satish Ashok <sashok@cumulusnetworks.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-28 23:33:20 -07:00
Dave Chinner
df150ed102 xfs: remote attributes need to be considered data
We don't log remote attribute contents, and instead write them
synchronously before we commit the block allocation and attribute
tree update transaction. As a result we are writing to the allocated
space before the allcoation has been made permanent.

As a result, we cannot consider this allocation to be a metadata
allocation. Metadata allocation can take blocks from the free list
and so reuse them before the transaction that freed the block is
committed to disk. This behaviour is perfectly fine for journalled
metadata changes as log recovery will ensure the free operation is
replayed before the overwrite, but for remote attribute writes this
is not the case.

Hence we have to consider the remote attribute blocks to contain
data and allocate accordingly. We do this by dropping the
XFS_BMAPI_METADATA flag from the block allocation. This means the
allocation will not use blocks that are on the busy list without
first ensuring that the freeing transaction has been committed to
disk and the blocks removed from the busy list. This ensures we will
never overwrite a freed block without first ensuring that it is
really free.

cc: <stable@vger.kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-07-29 11:48:02 +10:00
Dave Chinner
e3c32ee9e3 xfs: remote attribute headers contain an invalid LSN
In recent testing, a system that crashed failed log recovery on
restart with a bad symlink buffer magic number:

XFS (vda): Starting recovery (logdev: internal)
XFS (vda): Bad symlink block magic!
XFS: Assertion failed: 0, file: fs/xfs/xfs_log_recover.c, line: 2060

On examination of the log via xfs_logprint, none of the symlink
buffers in the log had a bad magic number, nor were any other types
of buffer log format headers mis-identified as symlink buffers.
Tracing was used to find the buffer the kernel was tripping over,
and xfs_db identified it's contents as:

000: 5841524d 00000000 00000346 64d82b48 8983e692 d71e4680 a5f49e2c b317576e
020: 00000000 00602038 00000000 006034ce d0020000 00000000 4d4d4d4d 4d4d4d4d
040: 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d
060: 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d
.....

This is a remote attribute buffer, which are notable in that they
are not logged but are instead written synchronously by the remote
attribute code so that they exist on disk before the attribute
transactions are committed to the journal.

The above remote attribute block has an invalid LSN in it - cycle
0xd002000, block 0 - which means when log recovery comes along to
determine if the transaction that writes to the underlying block
should be replayed, it sees a block that has a future LSN and so
does not replay the buffer data in the transaction. Instead, it
validates the buffer magic number and attaches the buffer verifier
to it.  It is this buffer magic number check that is failing in the
above assert, indicating that we skipped replay due to the LSN of
the underlying buffer.

The problem here is that the remote attribute buffers cannot have a
valid LSN placed into them, because the transaction that contains 
the attribute tree pointer changes and the block allocation that the
attribute data is being written to hasn't yet been committed. Hence
the LSN field in the attribute block is completely unwritten,
thereby leaving the underlying contents of the block in the LSN
field. It could have any value, and hence a future overwrite of the
block by log recovery may or may not work correctly.

Fix this by always writing an invalid LSN to the remote attribute
block, as any buffer in log recovery that needs to write over the
remote attribute should occur. We are protected from having old data
written over the attribute by the fact that freeing the block before
the remote attribute is written will result in the buffer being
marked stale in the log and so all changes prior to the buffer stale
transaction will be cancelled by log recovery.

Hence it is safe to ignore the LSN in the case or synchronously
written, unlogged metadata such as remote attribute blocks, and to
ensure we do that correctly, we need to write an invalid LSN to all
remote attribute blocks to trigger immediate recovery of metadata
that is written over the top.

As a further protection for filesystems that may already have remote
attribute blocks with bad LSNs on disk, change the log recovery code
to always trigger immediate recovery of metadata over remote
attribute blocks.

cc: <stable@vger.kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-07-29 11:48:01 +10:00
Dave Chinner
b2442c5a7f xfs: call dax_fault on read page faults for DAX
When modifying the patch series to handle the XFS MMAP_LOCK nesting
of page faults, I botched the conversion of the read page fault
path, and so it is only every calling through the page cache. Re-add
the necessary __dax_fault() call for such files.

Because the get_blocks callback on read faults may not set up the
mapping buffer correctly to allow unwritten extent completion to be
run, we need to allow callers of __dax_fault() to pass a null
complete_unwritten() callback. The DAX code always zeros the
unwritten page when it is read faulted so there are no stale data
exposure issues with not doing the conversion. The only downside
will be the potential for increased CPU overhead on repeated read
faults of the same page. If this proves to be a problem, then the
filesystem needs to fix it's get_block callback and provide a
convert_unwritten() callback to the read fault path.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Matthew Wilcox <willy@linux.intel.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-07-29 11:48:00 +10:00
Linus Torvalds
956325bd55 Changes for 4.2-rc
- Two minor bug fixes
 - Relicense ocrdma driver to dual license, GPL or BSD
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJVt4+aAAoJELgmozMOVy/dsiwQALBVIIscxVh+GGuRvDopAwA7
 nfsAAqK/XFO3kT3QNSO3gsj4yhIfgR8EXjLiKVrYAWNIUz4NwtlH0lDDH741pVxS
 v8dVFuH4KuKw9Hotu4G7W4M3AslszZZQAjSVGSgzrmvIBf9vS6A33S8gfCnNshnZ
 o/dccJalsAPMsf9OY4vVJE4Jpc0vhwaLxxILK8l3qBImnrJrzoV8jQc+SGWFA2V1
 IePSEMuVVcXEVLaxaOCtQEoI40UHDZHAqINw+QvNzGBpaY8FysnwAAl0p9r5a5VU
 jteYZ+jvAkbSC/GUpbM6s/MziltTookbFyC6pMIbGAPi43Hz1khA2eYofJ30bihP
 TAyNGv9yzwkPcTjq6NMxpj2O06ITyzDSCLlC6/dOcV9nrfMz/xoPZ8zaVpFuTt/Q
 bHpXgqyQcz8RWpX4A2c5iomgKwX4lwMtsDf/0fLlZTwHWBc3nGuGHeX1wTtemK/i
 ClEUNmZR14/jaQdeLJU6bvGmUo03nhCvIVvIJa8wpqL4nAzUsKDQMVTEK2A26mzz
 SD2JaFMiDACAvhU1UjkmdpUAycyFacbCgkm9FpwsuaK5lFhkzRohD1kM9oyzz0Q8
 p0HTikxjU6Ve1s6kM6c6dISD3x5beDR2cNDQuQaIcrDO8HETugQ5m+gXeVOuH8zo
 PRe/SehnsjTmHHFq6s+v
 =TYMP
 -----END PGP SIGNATURE-----

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma

Pull rdma fixes from Doug Ledford:

 - two minor bug fixes

 - relicense ocrdma driver to dual license, GPL or BSD

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  RDMA/ocrdma: update ocrdma module license string
  RDMA/ocrdma: update ocrdma license to dual-license
  IB/ipoib: Fix CONFIG_INFINIBAND_IPOIB_CM
  RDMA/cxgb3: fail get_dma_mr on 64 bit arches
2015-07-28 14:20:16 -07:00
Linus Torvalds
d4ec1f181f Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
Pull key fix from James Morris.

Fix memory leak.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  KEYS: ensure we free the assoc array edit if edit is valid
2015-07-28 14:18:10 -07:00
Linus Torvalds
d61be4b3f2 Fix buffer overflow when UTF-16 UEFI vendor string is copied from the
system table into a char array with a size of 100 bytes.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJVt8LEAAoJEGvWsS0AyF7xg4gP/iZweJzesP29V1O6l+PxqEMU
 vTJYVEUBmzso2bt8GYb8EFhL3CdPmw5azGNksgOICL2Knd+sVlGLtMmfMupN7H1M
 j+f7o546UCw3g+e0huKJvGmBuNFJkTleXAh+KRWSlFDpt7IVqzjT1njVeF+xvd0b
 JG+a3+xPYCUuOUDv4mCVdQ3zueLhLBy/Mv3QWKAGyX0JdraT4PkgHSiD1c46YeAt
 l4uymuTGXJlSMTdwQK50QDevH5Nh28c7TaksH1OkZPHNxDogWuTeAUpFRpbtWGpQ
 VrGExlb/CYT14R6SvlG5Jz80BLlW0mHVYgwXXJZ+Z/tKquOnYR0B4ZnX7R8q7YgM
 g6YKOAPNhiifgwBbasXPt46po7SeBV0/qdUuOVpjdtZXKlUo7O57bGDcdchxJ5V5
 WDuXJoA3wDcRUg99eEG8cPl0yb5DAzUhR0n+1WvQ7ON7G978QHW5YpXWQ13zEHGV
 rIDZelU+o2Yr84YIZBmuo7qip4xQU7AJaHmqs9GSxyNA1Kip8jJD2UJ/+7PW/l+F
 VsNasShQleiC+9nIkOhzkpgfy1BLb7+8PkfIgJiz6nz3i9PpTHKHsCAHOURoGjuP
 g2wHGxOsjcygkqkJQTMwlaGjhWbm7uP40d88kHmYqYfVDwLtYXdXsv/oH+zDN+zN
 UUFU9EIDgOkEocRNEMf+
 =phfS
 -----END PGP SIGNATURE-----

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

Pull arm64 fix from Catalin Marinas:
 "Fix buffer overflow when UTF-16 UEFI vendor string is copied from the
  system table into a char array with a size of 100 bytes"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64/efi: map the entire UEFI vendor string before reading it
2015-07-28 11:26:13 -07:00
Linus Torvalds
67eb890e5e Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32
Pull AVR32 fix from Hans-Christian Egtvedt.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32:
  avr32: handle NULL as a valid clock object
2015-07-28 10:29:23 -07:00
Dmitry Torokhov
3213afb8bf Revert "Input: zforce - don't overwrite the stack"
This reverts commit 7d01cd261c because
with given FRAME_MAXSIZE of 257 the check will never trigger and it
causes warnings from GCC (with -Wtype-limits). Also the check was
incorrect as it was not accounting for the already read 2 bytes of data
stored in the buffer.
2015-07-28 10:25:03 -07:00