While running stress tests on adding and deleting ftrace instances I hit
this bug:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: selinux_inode_permission+0x85/0x160
PGD 63681067 PUD 7ddbe067 PMD 0
Oops: 0000 [#1] PREEMPT
CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20
Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000
RIP: 0010:[<ffffffff812d8bc5>] [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160
RSP: 0018:ffff88007ddb1c48 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840
RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000
RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54
R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000
R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000
FS: 00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0
Call Trace:
security_inode_permission+0x1c/0x30
__inode_permission+0x41/0xa0
inode_permission+0x18/0x50
link_path_walk+0x66/0x920
path_openat+0xa6/0x6c0
do_filp_open+0x43/0xa0
do_sys_open+0x146/0x240
SyS_open+0x1e/0x20
system_call_fastpath+0x16/0x1b
Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
RIP selinux_inode_permission+0x85/0x160
CR2: 0000000000000020
Investigating, I found that the inode->i_security was NULL, and the
dereference of it caused the oops.
in selinux_inode_permission():
isec = inode->i_security;
rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd);
Note, the crash came from stressing the deletion and reading of debugfs
files. I was not able to recreate this via normal files. But I'm not
sure they are safe. It may just be that the race window is much harder
to hit.
What seems to have happened (and what I have traced), is the file is
being opened at the same time the file or directory is being deleted.
As the dentry and inode locks are not held during the path walk, nor is
the inodes ref counts being incremented, there is nothing saving these
structures from being discarded except for an rcu_read_lock().
The rcu_read_lock() protects against freeing of the inode, but it does
not protect freeing of the inode_security_struct. Now if the freeing of
the i_security happens with a call_rcu(), and the i_security field of
the inode is not changed (it gets freed as the inode gets freed) then
there will be no issue here. (Linus Torvalds suggested not setting the
field to NULL such that we do not need to check if it is NULL in the
permission check).
Note, this is a hack, but it fixes the problem at hand. A real fix is
to restructure the destroy_inode() to call all the destructor handlers
from the RCU callback. But that is a major job to do, and requires a
lot of work. For now, we just band-aid this bug with this fix (it
works), and work on a more maintainable solution in the future.
Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home
Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home
Cc: stable@vger.kernel.org
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We see General Protection Fault on RSI in copy_page_rep: that RSI is
what you get from a NULL struct page pointer.
RIP: 0010:[<ffffffff81154955>] [<ffffffff81154955>] copy_page_rep+0x5/0x10
RSP: 0000:ffff880136e15c00 EFLAGS: 00010286
RAX: ffff880000000000 RBX: ffff880136e14000 RCX: 0000000000000200
RDX: 6db6db6db6db6db7 RSI: db73880000000000 RDI: ffff880dd0c00000
RBP: ffff880136e15c18 R08: 0000000000000200 R09: 000000000005987c
R10: 000000000005987c R11: 0000000000000200 R12: 0000000000000001
R13: ffffea00305aa000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f195752f700(0000) GS:ffff880c7fc20000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000093010000 CR3: 00000001458e1000 CR4: 00000000000027e0
Call Trace:
copy_user_huge_page+0x93/0xab
do_huge_pmd_wp_page+0x710/0x815
handle_mm_fault+0x15d8/0x1d70
__do_page_fault+0x14d/0x840
do_page_fault+0x2f/0x90
page_fault+0x22/0x30
do_huge_pmd_wp_page() tests is_huge_zero_pmd(orig_pmd) four times: but
since shrink_huge_zero_page() can free the huge_zero_page, and we have
no hold of our own on it here (except where the fourth test holds
page_table_lock and has checked pmd_same), it's possible for it to
answer yes the first time, but no to the second or third test. Change
all those last three to tests for NULL page.
(Note: this is not the same issue as trinity's DEBUG_PAGEALLOC BUG
in copy_page_rep with RSI: ffff88009c422000, reported by Sasha Levin
in https://lkml.org/lkml/2013/3/29/103. I believe that one is due
to the source page being split, and a tail page freed, while copy
is in progress; and not a problem without DEBUG_PAGEALLOC, since
the pmd_same check will prevent a miscopy from being made visible.)
Fixes: 97ae17497e ("thp: implement refcounting for huge zero page")
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org # v3.10 v3.11 v3.12
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When queue_mode is NULL_Q_MQ and null_blk is being removed,
blk_cleanup_queue() isn't called to cleanup queue, so the queue
allocated won't be freed.
This patch calls blk_cleanup_queue() for MQ to drain all pending
requests first and release the reference counter of queue kobject, then
blk_mq_free_queue() will be called in queue kobject's release handler
when queue kobject's reference counter drops to zero.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Before we do an EMMS in the AMD FXSAVE information leak workaround we
need to clear any pending exceptions, otherwise we trap with a
floating-point exception inside this code.
Reported-by: halfdog <me@halfdog.net>
Tested-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/CA%2B55aFxQnY_PCG_n4=0w-VG=YLXL-yr7oMxyy0WU2gCBAf3ydg@mail.gmail.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Pull networking fixes from David Miller:
"Famouse last words: "final pull request" :-)
I'm sending this because Jason Wang's fixes are pretty important
1) Add missing per-cpu stats initialization to ip6_vti. Otherwise
lockdep spits out a call trace. From Li RongQing.
2) Fix NULL oops in wireless hwsim, from Javier Lopez
3) TIPC deferred packet queue unlink must NULL out skb->next to avoid
crashes. From Erik Hugne
4) Fix access to uninitialized buffer in nf_nat netfilter code, from
Daniel Borkmann
5) Fix lifetime of ipv6 loopback and SIT tunnel addresses, otherwise
they basically timeout immediately. From Hannes Frederic Sowa
6) Fix DMA unmapping of TSO packets in bnx2x driver, from Michal
Schmidt
7) Do not allow L2 forwarding offload via macvtap device, the way
things are now it will not end up being forwaded at all. From
Jason Wang
8) Fix transmit queue selection via ndo_dfwd_start_xmit(), fixing
things like applying NETIF_F_LLTX to the wrong device (!!) and
eliding the proper transmit watchdog handling
9) qlcnic driver was not updating tx statistics at all, from Manish
Chopra"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
qlcnic: Fix ethtool statistics length calculation
qlcnic: Fix bug in TX statistics
net: core: explicitly select a txq before doing l2 forwarding
macvlan: forbid L2 fowarding offload for macvtap
bnx2x: fix DMA unmapping of TSO split BDs
ipv6: add link-local, sit and loopback address with INFINITY_LIFE_TIME
bnx2x: prevent WARN during driver unload
tipc: correctly unlink packets from deferred packet queue
ipv6: pcpu_tstats.syncp should be initialised in ip6_vti.c
netfilter: only warn once on wrong seqadj usage
netfilter: nf_nat: fix access to uninitialized buffer in IRC NAT helper
NFC: Fix target mode p2p link establishment
iwlwifi: add new devices for 7265 series
mac80211: move "bufferable MMPDU" check to fix AP mode scan
mac80211_hwsim: Fix NULL pointer dereference
- fix off-by-one in xfs_attr3_rmt_verify
- fix missing destroy_work_on_stack() in xfs_bmapi_allocate
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJS0ECWAAoJENaLyazVq6ZOgn0QAKSC/pkP4km+QbmL0R7SqSJH
ZSSj16gIjR5lHlwI3PQzv5BgyEC9BcRDKWXN6dy+GHHuMtP4qYK8cLWFcyl7EysH
HAyDBnaJVphXt23C5iIzk+iseNfRYXA2LOpYSH6qfhZ5bxEeYzQS42zL4YhxZrXq
kzLHojcTLUx0IzJ+4oHn5AXSgPt+PXxNz3s+TU9virFnfSMlw2qYukxQtG49nbQr
kQjNHgeTIBKzeHdlnxmv5Rd2bD//397w5aWXxmaUh8fk6Z7VJi40ALAG4Pks81HF
+TEgMtF9/xTXdlwrYJDoHp++vUs6HANCX+wSAb4MdrBQvjh/USytK2WFwOeMyyR6
L/iogfPXHHizTkoYSzPwPdEmCCFhzidvBEqNX68+ojlJnDtoart7IgkOcm9LvaQI
j//u76CPRcd8tFh+1fDNaXn1ykJ6/CepSY13/yOnbpc7JoDbtqK2R8HFxdSlkDDg
UooLF2AfQ6lX280cUWwV0flqGO6iTIM3Fw1mIq3z8X4usNn+bMnlOu/DUnCbF5bB
YJCV4uT7f04w7oJqin9a7LHaHKRD56tWQun/OCEd7ZV/hJ1YRYlhhLfSdWdX7+SX
oIawXJy7NvCPQLaTwycD3h2gDlaxw17GAc9rA3AcCknxBsgNosv1ETQnEPC4iIAq
QsVal7p6oMLZ/qx6mvX7
=Xpq3
-----END PGP SIGNATURE-----
Merge tag 'xfs-for-linus-v3.13-rc8' of git://oss.sgi.com/xfs/xfs
Pull xfs bugfixes from Ben Myers:
"Here we have a bugfix for an off-by-one in the remote attribute
verifier that results in a forced shutdown which you can hit with v5
superblock by creating a 64k xattr, and a fix for a missing
destroy_work_on_stack() in the allocation worker.
It's a bit late, but they are both fairly straightforward"
* tag 'xfs-for-linus-v3.13-rc8' of git://oss.sgi.com/xfs/xfs:
xfs: Calling destroy_work_on_stack() to pair with INIT_WORK_ONSTACK()
xfs: fix off-by-one error in xfs_attr3_rmt_verify
Pull LED fix from Bryan Wu:
"Pali Rohár and Pavel Machek reported the LED of Nokia N900 doesn't
work with our latest 3.13-rc6 kernel. Milo fixed the regression here"
* 'leds-fixes-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
leds: lp5521/5523: Remove duplicate mutex
- Recent commits modifying the lists of C-states in the intel_idle
driver introduced bugs leading to crashes on some systems. Two
fixes from Jiang Liu.
- The ACPI AC driver should receive all types of notifications, but
recent change made it ignore some of them. Fix from Alexander Mezin.
- intel_pstate's validity checks for MSRs it depends on are not
sufficient to catch the lack of support in nested KVM setups, so
they are extended to cover that case. From Dirk Brandewie.
- NEC LZ750/LS has a botched up _BIX method in its ACPI tables, so our
ACPI battery driver needs a quirk for it. From Lan Tianyu.
- The tpm_ppi driver sometimes leaks memory allocated by acpi_get_name().
Fix from Jiang Liu.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJSz/qJAAoJEILEb/54YlRxraQP/Arse18aykhROgu4tFbJ5Cy0
w4T8PjmSgb7IYkld/zsY18dgOxEXRSzpXeaYREfcehgjipwv30BS4YPxXlulCMYG
79CCOFbWqjzhxRdNYpgqoKsW7H5PI1bMn6tD1Ih2DAlkqnCevqYqs9PsUnNJCXE9
Go2ldksIw/pRUlTEnhIBU0mGGcZLSau0UELVYV0ObJMbjY2DLCaqODXKHBOKoBvQ
+4cBkIF0WP73ISLwPAXv7o3C0+10b4q23zpQ+oDw5qzckuhHcCIJOmSs62mhoJjt
ZswQWZrrocmntASaMsvzDNCezu/GkV6ZF6+jFyedrpQiFJSCVjTVD+Qix098UWIn
3Fs0l9Mf51sTuQR8/RD93zgQEwPBjphrFOzBePDZkZXYAEzKA8IPXxQv8PKU/rIy
LkhmocwTVN4shNy+JF0xOxlvndba1FUm2E9TqVJzNFrSrQFt6M2AyBbyMxyTKlTm
SYcfR1jkoPTMPZ4z5tXB91HtXZVd5R9Bn3b80AwXriU6mEUb0Sf7UAdPDulvBv/W
WAeItvg6K1oiED6WHhardL/MQc7gXtrRzXSL+M+xAoxlGI/vo7MJsez3SzDafLhQ
nSggpcpo2F6h39Fi1UFUkciWsp4s2/BzbHObu960DMO0n+23/riguOxPgHz4AfiC
7ejxAG5eMpF7QiKjEUYO
=Eqc0
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.13-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
- Recent commits modifying the lists of C-states in the intel_idle
driver introduced bugs leading to crashes on some systems. Two fixes
from Jiang Liu.
- The ACPI AC driver should receive all types of notifications, but
recent change made it ignore some of them. Fix from Alexander Mezin.
- intel_pstate's validity checks for MSRs it depends on are not
sufficient to catch the lack of support in nested KVM setups, so they
are extended to cover that case. From Dirk Brandewie.
- NEC LZ750/LS has a botched up _BIX method in its ACPI tables, so our
ACPI battery driver needs a quirk for it. From Lan Tianyu.
- The tpm_ppi driver sometimes leaks memory allocated by
acpi_get_name(). Fix from Jiang Liu.
* tag 'pm+acpi-3.13-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
intel_idle: close avn_cstates array with correct marker
Revert "intel_idle: mark states tables with __initdata tag"
ACPI / Battery: Add a _BIX quirk for NEC LZ750/LS
intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.
ACPI / TPM: fix memory leak when walking ACPI namespace
ACPI / AC: change notification handler type to ACPI_ALL_NOTIFY
It only contains one fix for the rtsx_pcr driver. Without it we see a
kernel panic on some machines, when resuming from suspend to RAM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJSz7AIAAoJEIqAPN1PVmxKRSAQAJJpDZQB7zdQmcAEWK/NQPDE
h3QRfO0Fc+X8OpIPjAtmQgTXi4Naf5B5KwpDl5Mdcqe1PyWC959y94KohiHiN5WL
lcbGJF7LD+NfpdiXomIa6HmkBM8gUVAheVfU4mnYy5rbIRTVCLxysPYFt6w9cQRU
7dkHyL5qVt6+9p+/jr+XuVW//k7lbZX7nwBcs+HFInQNHu4qT97gxs99Mbvob+LZ
EdREj4hlrgteyTLAYTmHFtWkL464IeZXN9iI7ncShf+6icxwYyHIsr7QPjxO33+B
A0Wueofb3VKAbFi41g38QbstsywdWi2X5YDxbMi1VpB5LZe/TyVl6fAbAB8NAfNN
s9mOtrEdL3bBWcbWmXuZSsq4Jjvxl9IZ3aK0nwibD4cP64BRbbQG+ICcZ1e4urAR
uxhC7sT8tR+XJYr3cv+r6Br3awqku+0/hOLAXK+YKonftUBd2WvpWVya/zJW64JW
UyxnS87Zdz98Z1BK9925vC+TwhBxcp+jlEgrT+Ersgvtr+0o22ditrusxbY3vIea
F3LVeIIlD1rcOt8n2fL/0L6M/QXHNKycdA24nb2kViYQCfb5edmEEQ+OXTcoXzTy
9Gxm0aZaABY2Y+4cHnAQIi7IcVd34KcJRSn77+rStXwlyI9fIgG+5xfKUj4oFHZZ
eiBUJ6vC6Uq36jqh4SLt
=Dmc7
-----END PGP SIGNATURE-----
Merge tag 'mfd-fixes-3.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-fixes
Pull MFD fix from Samuel Ortiz:
"This is the 2nd MFD pull request for 3.13
It only contains one fix for the rtsx_pcr driver. Without it we see a
kernel panic on some machines, when resuming from suspend to RAM"
* tag 'mfd-fixes-3.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-fixes:
mfd: rtsx_pcr: Disable interrupts before cancelling delayed works
It can be a problem when a pattern is loaded via the firmware interface.
LP55xx common driver has already locked the mutex in 'lp55xx_firmware_loaded()'.
So it should be deleted.
On the other hand, locks are required in store_engine_load()
on updating program memory.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Cc: <stable@vger.kernel.org>
We were apparently relying on the defaults on BDW, which resulted in no
hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to
enable all interrupts.
v2: use preinstall instead of redundant SDIER write
References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
References: https://bugs.freedesktop.org/show_bug.cgi?id=72833
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel thought that this was an opportune moment to include which pins
and bits ended up being stuck in the WARN.
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Disabling the hotplug IRQ is a two-step process. First, inside the IRQ
handler we mark the rogue hotplug pin for disabling. Then later in the
hotplug worker, we actually disable the hotplug pin. So we should not
WARN about the rogue hotplug IRQ being sent until after we have
completed disabling the pin.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems that hardware that is broken enough to emit a hotplug IRQ even
though the pin is surposedly disable, will do so indefinitely.
Note: There's a good chance the underlying issue has been fixed with
commit 0ce99f749b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 26 11:27:49 2013 +0200
drm/i915: fix gen4 digital port hotplug definitions
References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170
Link: https://bugzilla.redhat.com/attachment.cgi?id=847786
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about the potential fix.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We specifically exclude original gen4 (i.e. i965g/gm), so update the
naming for consistency. Spotted while reviewing related code due to a
report from Jesse about byt needing again different values.
v2: g4x, not gm45 since this also applies to the desktop version.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In case CONFIG_DEBUG_OBJECTS_WORK is defined, it is needed to
call destroy_work_on_stack() which frees the debug object to pair
with INIT_WORK_ONSTACK().
Signed-off-by: Liu, Chuansheng <chuansheng.liu@intel.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
(cherry picked from commit 6f96b3063c)
With CRC check is enabled, if trying to set an attributes value just
equal to the maximum size of XATTR_SIZE_MAX would cause the v3 remote
attr write verification procedure failure, which would yield the back
trace like below:
<snip>
XFS (sda7): Internal error xfs_attr3_rmt_write_verify at line 191 of file fs/xfs/xfs_attr_remote.c
<snip>
Call Trace:
[<ffffffff816f0042>] dump_stack+0x45/0x56
[<ffffffffa0d99c8b>] xfs_error_report+0x3b/0x40 [xfs]
[<ffffffffa0d96edd>] ? _xfs_buf_ioapply+0x6d/0x390 [xfs]
[<ffffffffa0d99ce5>] xfs_corruption_error+0x55/0x80 [xfs]
[<ffffffffa0dbef6b>] xfs_attr3_rmt_write_verify+0x14b/0x1a0 [xfs]
[<ffffffffa0d96edd>] ? _xfs_buf_ioapply+0x6d/0x390 [xfs]
[<ffffffffa0d97315>] ? xfs_bdstrat_cb+0x55/0xb0 [xfs]
[<ffffffffa0d96edd>] _xfs_buf_ioapply+0x6d/0x390 [xfs]
[<ffffffff81184cda>] ? vm_map_ram+0x31a/0x460
[<ffffffff81097230>] ? wake_up_state+0x20/0x20
[<ffffffffa0d97315>] ? xfs_bdstrat_cb+0x55/0xb0 [xfs]
[<ffffffffa0d9726b>] xfs_buf_iorequest+0x6b/0xc0 [xfs]
[<ffffffffa0d97315>] xfs_bdstrat_cb+0x55/0xb0 [xfs]
[<ffffffffa0d97906>] xfs_bwrite+0x46/0x80 [xfs]
[<ffffffffa0dbfa94>] xfs_attr_rmtval_set+0x334/0x490 [xfs]
[<ffffffffa0db84aa>] xfs_attr_leaf_addname+0x24a/0x410 [xfs]
[<ffffffffa0db8893>] xfs_attr_set_int+0x223/0x470 [xfs]
[<ffffffffa0db8b76>] xfs_attr_set+0x96/0xb0 [xfs]
[<ffffffffa0db13b2>] xfs_xattr_set+0x42/0x70 [xfs]
[<ffffffff811df9b2>] generic_setxattr+0x62/0x80
[<ffffffff811e0213>] __vfs_setxattr_noperm+0x63/0x1b0
[<ffffffff81307afe>] ? evm_inode_setxattr+0xe/0x10
[<ffffffff811e0415>] vfs_setxattr+0xb5/0xc0
[<ffffffff811e054e>] setxattr+0x12e/0x1c0
[<ffffffff811c6e82>] ? final_putname+0x22/0x50
[<ffffffff811c708b>] ? putname+0x2b/0x40
[<ffffffff811cc4bf>] ? user_path_at_empty+0x5f/0x90
[<ffffffff811bdfd9>] ? __sb_start_write+0x49/0xe0
[<ffffffff81168589>] ? vm_mmap_pgoff+0x99/0xc0
[<ffffffff811e07df>] SyS_setxattr+0x8f/0xe0
[<ffffffff81700c2d>] system_call_fastpath+0x1a/0x1f
Tests:
setfattr -n user.longxattr -v `perl -e 'print "A"x65536'` testfile
This patch fix it to check the remote EA size is greater than the
XATTR_SIZE_MAX rather than more than or equal to it, because it's
valid if the specified EA value size is equal to the limitation as
per VFS setxattr interface.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
(cherry picked from commit 85dd0707f0)
o Consider number of Tx queues while calculating the length of
Tx statistics as part of ethtool stats.
o Calculate statistics lenght properly for 82xx and 83xx adapter
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
o Driver was not updating TX stats so it was not populating
statistics in `ifconfig` command output.
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
will cause several issues:
- NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
instead of lower device which misses the necessary txq synchronization for
lower device such as txq stopping or frozen required by dev watchdog or
control path.
- dev_hard_start_xmit() was called with NULL txq which bypasses the net device
watchdog.
- dev_hard_start_xmit() does not check txq everywhere which will lead a crash
when tso is disabled for lower device.
Fix this by explicitly introducing a new param for .ndo_select_queue() for just
selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
forwarding transmission.
With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
dev_queue_xmit() to do the transmission.
In the future, it was also required for macvtap l2 forwarding support since it
provides a necessary synchronization method.
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: e1000-devel@lists.sourceforge.net
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
L2 fowarding offload will bypass the rx handler of real device. This will make
the packet could not be forwarded to macvtap device. Another problem is the
dev_hard_start_xmit() called for macvtap does not have any synchronization.
Fix this by forbidding L2 forwarding for macvtap.
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John W. Linville says:
====================
For the mac80211 bits, Johannes says:
"I have a fix from Javier for mac80211_hwsim when used with wmediumd
userspace, and a fix from Felix for buffering in AP mode."
For the NFC bits, Samuel says:
"This pull request only contains one fix for a regression introduced with
commit e29a9e2ae1. Without this fix, we can not establish a p2p link
in target mode. Only initiator mode works."
For the iwlwifi bits, Emmanuel says:
"It only includes new device IDs so it's not vital. If you have a pull
request to net.git anyway, I'd happy to have this in."
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
bnx2x triggers warnings with CONFIG_DMA_API_DEBUG=y:
WARNING: CPU: 0 PID: 2253 at lib/dma-debug.c:887 check_unmap+0xf8/0x920()
bnx2x 0000:28:00.0: DMA-API: device driver frees DMA memory with
different size [device address=0x00000000da2b389e] [map size=1490 bytes]
[unmap size=66 bytes]
The reason is that bnx2x splits a TSO BD into two BDs (headers + data)
using one DMA mapping for both, but it uses only the length of the first
BD when unmapping.
This patch fixes the bug by unmapping the whole length of the two BDs.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It's an accident waiting to happen.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
INSTPM is a masked register so use the _MASKED_BIT_{ENABLE,DISABLE}
macros when enabling/disabling self-refresh on 915GM.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no LVDS port on 830M so don't go reading the LVDS control
register.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PFIT_CONTROL doesn't exist on 830M, so avoid reading it in
i9xx_get_pfit_config().
Also assume that only mobile gen2/3 chipsets have a panel fitter. This
matches the documentation, but I didn't have real hardware to verify.
Gen4 docmentation is a bit inconsistent, but experimenetation on my
LPT machine suggests that the panel fitter is available on non-mobile
gen4 platforms. At least on this machine panel fitter appears works
just fine even on VGA output.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Many of the fields from Gen6 have gone away for vlv. Strip all those
fields that are not relevent and try to update fields that we care
about. This patch give information about current RP & RC status and
individual Wells.
v2: Move Render & Media Well status to separate lines (Ville)
Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VGA detection requires the reference clock to be on, so make sure this
is the case.
This fixes VGA hotplug/manual detection where all pipes are off and so
we would normally disable all clocks.
v2:
- Instead of disabling PSR clock gating, force the reference clock on
through the DPLL_A register. (Kin Chan S <kin.s.chan@intel.com>)
v3:
- Move enabling of the clock to intel_reset_dpio() and use the DPLL_B
register instead, where we already have a similar tweak for the CRI
clock. (Ville)
Reported-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_init_dpio() isn't called during resume, so we won't set the CRI
clock enable bit during that time. Move the enabling to
intel_reset_dpio() instead.
Note that the HW reset value for this bit is 1, so probably this patch
won't make any difference. We should still make the setting explicit,
since BIOS could change things under us.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The WA is mentioned in HSW's GAMMA_MODE register documentation, but
not on on BDW's documentation, so let's assume it is not needed there.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That we can use for debugging purposes.
v2: Use designated initializers for the 'names' array (Paulo Zanoni,
Jani Nikula).
Add a check in case the array has a hole (which can now remain
unnoticed with designated initializers) (Jani Nikula)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (for v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In some cases we have more than 1 connector associated to an encoder
(e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of
these connectors. If we only allowed modesets for connected connectors
we would never need this patch, but since we do allow modeset for
disconnected connectors we may see user space trying to set modes on
the two connectors attached to the same encoder, so we need to forbid
that.
This problem can be reproduced by running the following
intel-gpu-tools test case:
./kms_setmode --run-subtest clone-exclusive-crtc
Thanks to Daniel Vetter for providing a version of this patch on
pastebin.
Credits-to: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.
Note that the max fifo value isn't actually correct for the i830M, but
since we don't frob the fifo split we don't actually need it. This is
different for some gen3 devices where we need the full fifo for self
refresh mode.
Cc: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My OCD just couldn't let this slide. Spotted while reviewing Ville's
patch to only flip planes when we have FBC.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
regressions, typically boot failures or other unsafe system
configuration that causes badness.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSz5HsAAoJEDqPOy9afJhJYCcP/RgFkHD39l28dCUlxAZK1S1b
loyQn9OhpTDkMqcRNiv71dMm7y0Z28Qvf3CHPaZmkddstd351Agdz4mPTIOpbutQ
/THb0mAU7kufYkFUXq8+fDOcgkERMsQysIWAYV/vlCBDMPd+1j6z15E3A9jNC0Ap
q1o8KgmAbxDcsqltZmdlT+He7XsJiRSuyS+YFfNvtSm6MJ1qtuqiAumf9/DSBgFg
0aj+ADWS2mWiw50LOOaVVKKjKYKaO/DPq2gYz2Tz8C49rQfstMnOmjMWqIPGRpiZ
YPCDzAiutI8H+SXBaetkgIJn/MiVS2rnNPXfMHmCgWoO3Xi0PCq9+Vg7cTuvNSRl
HeMCnEsBcU9N2DfaZkom2OVU6XQXUkOM/jLIuTBGf7IKdLALSXy+w22NknRd0WKv
VKdie6GBmV5KwAeytDETdSxSQNuxIxLUfILd5+Y5kl1cFDUCsSxBDGD+01EbqS6B
Q/FkoS3EMvQvvFeGopCEje8fv87JvTrviJ7Mkj8xpJZGCWW7FTpsgTS0mP2ifDTX
RpjTGhcho0LbD4Hu3E58Kykc7LBO5LH5vnPHpMPj7KQxC/4gFVwdWHWgRFKI2pEr
B6zSl0W5j7cSR0mADH4MWuqQh8T2zbKgP4pcNJ878V3hGhBktcxure1VGcIr/yj9
U+FKg/lBoKUvVBDUnajQ
=iLBN
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux
Pull clock fixes from Mike Turquette:
"Late fixes for clock drivers. All of these fixes are for user-visible
regressions, typically boot failures or other unsafe system
configuration that causes badness"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
clk: clk-divider: fix divisor > 255 bug
clk: exynos: File scope reg_save array should depend on PM_SLEEP
clk: samsung: exynos5250: Add CLK_IGNORE_UNUSED flag for the sysreg clock
ARM: dts: exynos5250: Fix MDMA0 clock number
clk: samsung: exynos5250: Add MDMA0 clocks
clk: samsung: exynos5250: Fix ACP gate register offset
clk: exynos5250: fix sysmmu_mfc{l,r} gate clocks
clk: samsung: exynos4: Correct SRC_MFC register
Hopefully the last set of arm-soc fixes for 3.13, or at least only a
few stray patches after this.
There are a few fixes for Renesas platforms to fixup DMA masks (this
started causing errors once the DMA API added checks for valid masks in
3.13). Two more dealing with resources for MMC and PWM setup.
There's also a few TI/OMAP/DRA fixes for smaller stuff and a fix for
compilation failures on a PXA platform.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSzmLqAAoJEIwa5zzehBx3AIMP/i/Br36+IPTft/v6EN1dON3p
RXLTSh5bAO7uS5lEd7osRKvFGAM7kk7V1xwpixJaweiDBhJYgCC08fLQsmXr2ktL
uQZsWNqPzvNOUib8qmJSeYjuu4Otr+4KOS1FNhPmLJppnnZCnF0SsCaOTT/UZiV1
dgwB3JwRZvSE+twqbeL6LDHdh3qF3Kp85IeeFMZjvRAlAtwwwK4zBc0mbAHUUYs9
+h18T1iaJ+/j/5MQDVED6sJOWH4+cNh/DIvvWKGKe1z56Ji6wuMmrAFAhSiyeVNA
sxRXgtaqeegXu/LQkxTeFI4PYOzU/LGXPuO6lDqKJ8h5/YfHoxdiAnkxA1WFrq6z
sB4mc2A6WPKu13HbjqZOeVkFSZTL6lZDlLEP4f6mTDoHW5kJ6X7WabCBJswLpi9c
d5PvAu+jYF20OXks2ctnsITHk5xcYXMK1VSNiv6z7Dff63x7Lh078bkns5E1YLqs
vhkmZRGBWSsofFvyobNFKOsVvIW4Z6CGOiwW8RkQr6nlYzzoytnMU8E4yOUeXFRJ
c4veMRPn4pgNkbRXdxvUXmRado6hs53YFcRWYXX3fuFTC5x8KTjR2hxLm6J+Ca/m
2d9EFbBZQB1oZoHT6n/ghZCRIBjgVkbaaxNrdoMozF/ryOOj9ujj0xTB5dRoiX21
0Fhq/UVUxj0i5XWLgxQA
=edy8
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A few fixes for Renesas platforms to fixup DMA masks (this started
causing errors once the DMA API added checks for valid masks in 3.13)"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: shmobile: mackerel: Fix coherent DMA mask
ARM: shmobile: kzm9g: Fix coherent DMA mask
ARM: shmobile: armadillo: Fix coherent DMA mask
Looks like 830M doesn't quite like it when you try to move a plane from
one pipe to another. It seems that the plane's old pipe has to be active
even if the plane is already disabled, otherwise the relevant register
just won't accept new values.
The following commit:
commit 1f1c2e2468
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Nov 28 17:30:01 2013 +0200
drm/i915: Swap primary planes on gen2 for FBC
caused a regression on 830M. It will attempt to swap the planes when the
driver is loaded, but at that time only pipe A might be active, so plane
A gets disabled, but plane B won't get enabled since pipe B is not
active when we try to move the plane over to pipe A.
There's no reason to swap planes on 830M since it doesn't support
FBC. Change the logic a bit to limit the plane swapping to platforms
which actually support FBC. This should avoid getting a black screen on
830M.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the pipe A force quirk is applied the code will attempt to grab
a crtc mutex during intel_modeset_setup_hw_state(). If we're already
holding all crtc mutexes this will obviously deadlock every time.
So instead of using drm_modeset_lock_all() just grab the
mode_config.mutex. This is enough to avoid the unlocked mutex warnings
from certain lower level functions.
The regression was introduced in:
commit 0274766428
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Dec 2 11:08:06 2013 +0200
drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
[danvet: Add cc: stable since the offending commit has that, too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the past the IFA_PERMANENT flag indicated, that the valid and preferred
lifetime where ignored. Since change fad8da3e08 ("ipv6 addrconf: fix
preferred lifetime state-changing behavior while valid_lft is infinity")
we honour at least the preferred lifetime on those addresses. As such
the valid lifetime gets recalculated and updated to 0.
If loopback address is added manually this problem does not occur.
Also if NetworkManager manages IPv6, those addresses will get added via
inet6_rtm_newaddr and thus will have a correct lifetime, too.
Reported-by: François-Xavier Le Bail <fx.lebail@yahoo.com>
Reported-by: Damien Wyart <damien.wyart@gmail.com>
Fixes: fad8da3e08 ("ipv6 addrconf: fix preferred lifetime state-changing behavior while valid_lft is infinity")
Cc: Yasushi Asano <yasushi.asano@jp.fujitsu.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Starting with commit 80c33dd "net: add might_sleep() call to napi_disable"
bnx2x fails the might_sleep tests causing a stack trace to appear whenever
the driver is unloaded, as local_bh_disable() is being called before
napi_disable().
This changes the locking schematics related to CONFIG_NET_RX_BUSY_POLL,
preventing the need for calling local_bh_disable() and thus eliminating
the issue.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Close avn_cstates array with correct marker to avoid overflow
in function intel_idle_cpu_init().
[rjw: The problem was introduced when commit 22e580d07f was merged
on top of eba682a5ae (intel_idle: shrink states tables).]
Fixes: 22e580d07f (intel_idle: Fixed C6 state on Avoton/Rangeley processors)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Function tracing callbacks expect to have the ftrace_ops that registered it
passed to them, not the address of the variable that holds the ftrace_ops
that registered it.
Use a mov instead of a lea to store the ftrace_ops into the parameter
of the function tracing callback.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Link: http://lkml.kernel.org/r/20131113152004.459787f9@gandalf.local.home
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.8+
Add support for adreno 330. Not too much different, just a few
differences in initial configuration plus setting OCMEM base.
Userspace support is already in upstream mesa.
Note that the existing DT code is simply using the bindings from
downstream android kernel, to simplify porting of this driver to
existing devices. These do not constitute any committed/stable
DT ABI. The addition of proper DT bindings will be a subsequent
patch, at which point (as best as possible) I will try to support
either upstream bindings or what is found in downstream android
kernel, so that existing device DT files can be used.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The HDMI block is basically the same between older SoC's with mdp4
display controller, and newer ones with mdp5.
So mostly this consists of better abstracting out the different sets of
regulators, clks, etc. In particular, for regulators and clks we can
split it up by what is needed for hot plug detect to work, and what is
needed to light up the display.
Also, 8x74 has a new phy.. a very simple one, but split out into a
different mmio space. And with mdp5, the irq is shared with mdp, so we
don't directly register our own irq handler.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Linus Torvalds