Fixes: 376c7311bdb6 ("net: add a temporary sanity check in skb_orphan()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Aniket Alshi <aniket.alshi@oracle.com>
(cherry picked from commit 8b74d439e1697110c5e5c600643e823eb1dd0762) Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Paolo Abeni [Tue, 21 Feb 2017 08:33:18 +0000 (09:33 +0100)]
ip: fix IP_CHECKSUM handling
The skbs processed by ip_cmsg_recv() are not guaranteed to
be linear e.g. when sending UDP packets over loopback with
MSGMORE.
Using csum_partial() on [potentially] the whole skb len
is dangerous; instead be on the safe side and use skb_checksum().
Thanks to syzkaller team to detect the issue and provide the
reproducer.
v1 -> v2:
- move the variable declaration in a tighter scope
Fixes: ad6f939ab193 ("ip: Add offset parameter to ip_cmsg_recv") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit ca4ef4574f1ee5252e2cd365f8f5d5bafd048f32)
Eric Dumazet [Mon, 24 Oct 2016 01:03:06 +0000 (18:03 -0700)]
udp: fix IP_CHECKSUM handling
First bug was added in commit ad6f939ab193 ("ip: Add offset parameter to
ip_cmsg_recv") : Tom missed that ipv4 udp messages could be received on
AF_INET6 socket. ip_cmsg_recv(msg, skb) should have been replaced by
ip_cmsg_recv_offset(msg, skb, sizeof(struct udphdr));
Then commit e6afc8ace6dd ("udp: remove headers from UDP packets before
queueing") forgot to adjust the offsets now UDP headers are pulled
before skb are put in receive queue.
Fixes: ad6f939ab193 ("ip: Add offset parameter to ip_cmsg_recv") Fixes: e6afc8ace6dd ("udp: remove headers from UDP packets before queueing") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Sam Kumar <samanthakumar@google.com> Cc: Willem de Bruijn <willemb@google.com> Tested-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 10df8e6152c6c400a563a673e9956320bfce1871)
Willem de Bruijn [Thu, 7 Apr 2016 22:12:59 +0000 (18:12 -0400)]
udp: do not expect udp headers in recv cmsg IP_CMSG_CHECKSUM
On udp sockets, recv cmsg IP_CMSG_CHECKSUM returns a checksum over
the packet payload. Since commit e6afc8ace6dd pulled the headers,
taking skb->data as the start of transport header is incorrect. Use
the transport header pointer.
Also, when peeking at an offset from the start of the packet, only
return a checksum from the start of the peeked data. Note that the
cmsg does not subtract a tail checkum when reading truncated data.
Fixes: e6afc8ace6dd ("udp: remove headers from UDP packets before queueing") Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 31c2e4926fe912f88388bcaa8450fcaa8f2ece47)
Alexander Popov reported that an application may trigger a BUG_ON in
sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
waiting on it to queue more data and meanwhile another thread peels off
the association being used by the first thread.
This patch replaces the BUG_ON call with a proper error handling. It
will return -EPIPE to the original sendmsg call, similarly to what would
have been done if the association wasn't found in the first place.
Acked-by: Alexander Popov <alex.popov@linux.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 2dcab598484185dea7ec22219c76dcdd59e3cb90)
Darrick J. Wong [Sat, 17 Oct 2015 20:16:02 +0000 (16:16 -0400)]
ext4: store checksum seed in superblock
Allow the filesystem to store the metadata checksum seed in the
superblock and add an incompat feature to say that we're using it.
This enables tune2fs to change the UUID on a mounted metadata_csum
FS without having to (racy!) rewrite all disk metadata.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 8c81bd8f586c46eaf114758a78d82895a2b081c2)
Eryu Guan [Thu, 1 Dec 2016 20:08:37 +0000 (15:08 -0500)]
ext4: validate s_first_meta_bg at mount time
Ralf Spenneberg reported that he hit a kernel crash when mounting a
modified ext4 image. And it turns out that kernel crashed when
calculating fs overhead (ext4_calculate_overhead()), this is because
the image has very large s_first_meta_bg (debug code shows it's 842150400), and ext4 overruns the memory in count_overhead() when
setting bitmap buffer, which is PAGE_SIZE.
Darrick J. Wong [Sat, 17 Oct 2015 20:18:43 +0000 (16:18 -0400)]
ext4: clean up feature test macros with predicate functions
Create separate predicate functions to test/set/clear feature flags,
thereby replacing the wordy old macros. Furthermore, clean out the
places where we open-coded feature tests.
Paolo Bonzini [Thu, 12 Jan 2017 14:02:32 +0000 (15:02 +0100)]
KVM: x86: fix emulation of "MOV SS, null selector"
This is CVE-2017-2583. On Intel this causes a failed vmentry because
SS's type is neither 3 nor 7 (even though the manual says this check is
only done for usable SS, and the dmesg splat says that SS is unusable!).
On AMD it's worse: svm.c is confused and sets CPL to 0 in the vmcb.
The fix fabricates a data segment descriptor when SS is set to a null
selector, so that CPL and SS.DPL are set correctly in the VMCS/vmcb.
Furthermore, only allow setting SS to a NULL selector if SS.RPL < 3;
this in turn ensures CPL < 3 because RPL must be equal to CPL.
Thanks to Andy Lutomirski and Willy Tarreau for help in analyzing
the bug and deciphering the manuals.
Thomas Tai [Wed, 22 Mar 2017 17:52:11 +0000 (10:52 -0700)]
gfs2: fix slab corruption during mounting and umounting gfs file system
During mounting and unmounting GFS2 file system, kernel panic happens
due to slab memory corruption. The slab allocator suggests that it is
likely a double free memory corrruption. The issue is traced back to
v3.9-rc6 where a patch is submitted to use kzalloc() for storing a
bitmap instead of using a local variable. The intention is to allocate
memory during mounting and to free memory during unmounting. The original
patch misses a code path which has already freed the memory and caused
memory corruption. This patch sets the memory pointer to NULL after
the memory is freed, so that double free memory corruption will not
be happened.
gdlm_mount()
'-- set_recover_size() which use kzalloc()
'-- if dlm does not support ops callbacks then
'--- free_recover_size() which use kfree()
gldm_unmount()
'-- free_recover_size() which use kfree()
previous patch which introduce the double free issue is
commit 57c7310b8eb9 ("GFS2: use kmalloc for lvb bitmap")
Abhi Das [Tue, 5 May 2015 16:26:04 +0000 (11:26 -0500)]
gfs2: handle NULL rgd in set_rgrp_preferences
The function set_rgrp_preferences() does not handle the (rarely
returned) NULL value from gfs2_rgrpd_get_next() and this patch
fixes that.
The fs image in question is only 150MB in size which allows for
only 1 rgrp to be created. The in-memory rb tree has only 1 node
and when gfs2_rgrpd_get_next() is called on this sole rgrp, it
returns NULL. (Default behavior is to wrap around the rb tree and
return the first node to give the illusion of a circular linked
list. In the case of only 1 rgrp, we can't have
gfs2_rgrpd_get_next() return the same rgrp (first, last, next all
point to the same rgrp)... that would cause unintended consequences
and infinite loops.)
Signed-off-by: Abhi Das <adas@redhat.com> Signed-off-by: Bob Peterson <rpeterso@redhat.com>
(cherry picked from upstream commit 959b6717175713259664950f3bba2418b038f69a) Signed-off-by: Thomas Tai <thomas.tai@oracle.com>
Peter Zijlstra [Tue, 1 Dec 2015 13:04:04 +0000 (14:04 +0100)]
sched/wait: Fix signal handling in bit wait helpers
Vladimir reported getting RCU stall warnings and bisected it back to
commit:
743162013d40 ("sched: Remove proliferation of wait_on_bit() action functions")
That commit inadvertently reversed the calls to schedule() and signal_pending(),
thereby not handling the case where the signal receives while we sleep.
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: mark.rutland@arm.com Cc: neilb@suse.de Cc: oleg@redhat.com Fixes: 743162013d40 ("sched: Remove proliferation of wait_on_bit() action functions") Fixes: cbbce8220949 ("SCHED: add some "wait..on_bit...timeout()" interfaces.") Link: http://lkml.kernel.org/r/20151201130404.GL3816@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 68985633bccb6066bf1803e316fbc6c1f5b796d6)
Konrad Rzeszutek Wilk [Sat, 11 Mar 2017 01:24:34 +0000 (20:24 -0500)]
xen-pcifront/hvm: Slurp up "pxm" entry and set NUMA node on PCIe device. (V5)
If the XenBus contains the "pci" (which by default
it does for both PV and HVM guests), then iterate over
all the entries there and see if there are any with "pxm-X"
key. If so those values are used to modify the NUMA locality
information for the PCIe devices that match.
Also support PCIe hotplug - in case this done during runtime.
This patch also depends on the Xen to expose via XenBus the
"pxm-%d" entries.
A bit of background:
_PXM in ACPI is used to tie all kind of ACPI devices to the SRAT
table.
The SRAT table is simple N CPU array that lists APIC IDs and the NUMA nodes
and their distance from each other. There are two types - processor
affinity and memory affinity. For example one can have on a 4 CPU
machine this processor affinity:
APIC_ID | NUMA id (nid)
--------+--------------
0 | 0
2 | 0
4 | 1
6 | 1
The _PXM tie in the NUMA (nid), so for this guest there can only be
two - 0 or 1.
The _PXM can be slapped on most anything in the DSDT, the Processors
(kind of redundant as it is in SRAT), but most importantly for us the
PCIe devices. Except that ACPI does not enumerate all kind of PCIe devices.
Device (PCI0)
{
Name (_HID, EisaId ("PNP0A08") /* PCI Express Bus */) // _HID: Hardware ID
..
Name (_PXM, Zero) // _PXM: Device Proximity
}
Device (PCI1)
{
Name (_HID, EisaId ("PNP0A08") /* PCI Express Bus */) // _HID: Hardware ID
Name (_CID, EisaId ("PNP0A03") /* PCI Bus */) // _CID: Compatible ID
Name (_PXM, 0x01) // _PXM: Device Proximity
}
And this nicely helps with the Linux OS (and Windows) enumerating the
PCIe bridges (the two above) _ONCE_ during bootup. Then when a device
is hotplugged under the bridges it is very clear to which NUMA domain
it belongs.
To recap, on normal hardware Linux scans _ONCE_ the DSDT during
bootup and _only_ evaluates the _PXM on bridges "PNP0A03".
ONCE.
On the QEMU guests that Xen provides we have exactly _one_ bridge.
And the PCIe are hotplugged as 'slots' under it.
The SR-IOV VFs we hot-plug in the guest are done during runtime (not
during bootup, that would be too easy).
This means to make this work we would need to implement in QEMU:
1) Expand piix4 emulation to have bridges, PCIe bridges at bootup.
And bridges also expose the "window" of what the size of the MMIO
region is behind it (and the PCIe devices would fit in there).
2). Create up to NUMA node of these PCI bridges with the _PXM
information.
3). Then during PCI hotplug would decide which bridge based on the
NUMA locality.
That is hard. The 1) is especially difficult as we have no idea
how big MMIO bar the device plugged in will be!
Fortunatly Intel resolved this with the Intel VT-D. It has a hotplug
capability so you can insert a brand new PCIe bridge at any point.
This is how ThunderBolt works in essence.
This would mean that in QEMU we would need to:
4). Emulate in QEMU an IOMMU VT-d with PCI hotplug support.
Recognizing that 1-4 may take some time, and would need to be
done upstream first I decided to take a bit of shortcut.
Mainly that:
1) This only needs to work for ExaData which uses our kernel (UEK)
2) We already expose some of this information on XenBus.
3) Once upstream is done this can be easily 'dropped'.
The 'vdevfn' is the slot:function value. 28 is 00:05.0 and 30
is 00:06:0 and that corresponds to (inside of the guest):
-bash-4.1# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:05.0 USB Controller: NEC Corporation Device 0194 (rev 03)
00:06.0 USB Controller: NEC Corporation Device 0194 (rev 04)
This 'vdevfn' is created by QEMU when the device is hotplugged
(or at bootup time).
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Håkon Bugge <haakon.bugge@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
v1: Fixed all the checkpatch.pl issues
Made it respect the node_online() in case the backend provided
a larger value than there are NUMA nodes.
v2: Fixed per Boris's reviews.
v3: Added a mechanism to prune the list when devices are removed.
v4: s/l/len
Added space after 'len' in decleration.
Fixed comments
Added Reviewed-by.
v5: Added Boris's Reviewed-by
There were some problem in the fmr_pool code that either was missing lock
protection or was using wrong lock when allocating/freeing/looking up resource
in the FMR pool.
Covering all above issues, the code turns out that every where we need lock
protection we need both the pool_lock and used_pool_lock. So this patch also
removes the used_pool_lock and keeps the pool lock and make the later sync
all the accesses.
Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com> Reviewed-by: Avinash Repaka <avinash.repaka@oracle.com>
Prior to commit c0371da6047a ("put iov_iter into msghdr") in v3.19, there
was no check that the iovec contained enough bytes for an ICMP header,
and the read loop would walk across neighboring stack contents. Since the
iov_iter conversion, bad arguments are noticed, but the returned error is
EFAULT. Returning EINVAL is a clearer error and also solves the problem
prior to v3.19.
Reported-by: Qidan He <i@flanker017.me> Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 0eab121ef8750a5c8637d51534d5e9143fb0633f) Signed-off-by: Brian Maly <brian.maly@oracle.com>
The user can control the size of the next command passed along, but the
value passed to the ioctl isn't checked against the usable max command
size.
Cc: <stable@vger.kernel.org> Signed-off-by: Peter Chang <dpf@google.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Brian Maly <brian.maly@oracle.com>
The commit 90c311b0eeea ("xen-netfront: Fix Rx stall during network
stress and OOM") caused the refill timer to be triggerred almost on
all invocations of xennet_alloc_rx_buffers for certain workloads.
This reworks the fix by reverting to the old behaviour and taking into
consideration the skb allocation failure. Refill timer is now triggered
on insufficient requests or skb allocation failure.
Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com> Fixes: 90c311b0eeea (xen-netfront: Fix Rx stall during network stress and OOM) Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Backport from upstream 538d92912d3190a1dd809233a0d57277459f37b2
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Acked-By: Joe Jin <joe.jin@oracle.com>
During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.
The issue is with the retry logic which schedules the timer if the
created slots are less than NET_RX_SLOTS_MIN. The count of new request
slots to be pushed are calculated as a difference between new req_prod
and rsp_cons which could be more than the actual slots, if there are
unconsumed responses.
The fix is to calculate the count of newly created slots as the
difference between new req_prod and old req_prod.
Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Backport from upstream 90c311b0eeead647b708a723dbdde1eda3dcad05
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Acked-By: Joe Jin <joe.jin@oracle.com>
The problem is that shmat() calls do_mmap_pgoff() with MAP_FIXED, and
the address rounded down to 0. For the regular mmap case, the
protection mentioned above is that the kernel gets to generate the
address -- arch_get_unmapped_area() will always check for MAP_FIXED and
return that address. So by the time we do security_mmap_addr(0) things
get funky for shmat().
The testcase itself shows that while a regular user crashes, root will
not have a problem attaching a nil-page. There are two possible fixes
to this. The first, and which this patch does, is to simply allow root
to crash as well -- this is also regular mmap behavior, ie when hacking
up the testcase and adding mmap(... |MAP_FIXED). While this approach
is the safer option, the second alternative is to ignore SHM_RND if the
rounded address is 0, thus only having MAP_SHARED flags. This makes the
behavior of shmat() identical to the mmap() case. The downside of this
is obviously user visible, but does make sense in that it maintains
semantics after the round-down wrt 0 address and mmap.
Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those. Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.
Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit 128394eff343fc6d2f32172f03e24829539c5835) Signed-off-by: Brian Maly <brian.maly@oracle.com>
Fixes: 5f74f82ea34c ("net:Add sysctl_max_skb_frags") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Hans Westgaard Ry <hans.westgaard.ry@oracle.com> Cc: Håkon Bugge <haakon.bugge@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit ac9e70b17ecd7c6e933ff2eaf7ab37429e71bf4d)
This problem can occur in the following situation:
open()
- pread()
- .seq_start()
- iter = kmalloc() // succeeds
- seqf->private = iter
- .seq_stop()
- kfree(seqf->private)
- pread()
- .seq_start()
- iter = kmalloc() // fails
- .seq_stop()
- class_dev_iter_exit(seqf->private) // boom! old pointer
As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.
An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.
Cc: stable@vger.kernel.org Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@fb.com>
(cherry picked from commit 77da160530dd1dc94f6ae15a981f24e5f0021e84) Signed-off-by: Brian Maly <brian.maly@oracle.com>
Currently XFS calls file_remove_privs() without holding i_mutex. This is
wrong because that function can end up messing with file permissions and
file capabilities stored in xattrs for which we need i_mutex held.
Fix the problem by grabbing iolock exclusively when we will need to
change anything in permissions / xattrs.
Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Orabug: 24803533 Signed-off-by: darrick.wong@oracle.com
Comment in include/linux/security.h says that ->inode_killpriv() should
be called when setuid bit is being removed and that similar security
labels (in fact this applies only to file capabilities) should be
removed at this time as well. However we don't call ->inode_killpriv()
when we remove suid bit on truncate.
We fix the problem by calling ->inode_need_killpriv() and subsequently
->inode_killpriv() on truncate the same way as we do it on file write.
After this patch there's only one user of should_remove_suid() - ocfs2 -
and indeed it's buggy because it doesn't call ->inode_killpriv() on
write. However fixing it is difficult because of special locking
constraints.
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Orabug: 24803533 Signed-off-by: darrick.wong@oracle.com
Provide function telling whether file_remove_privs() will do anything.
Currently we only have should_remove_suid() and that does something
slightly different.
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Orabug: 24803533 Signed-off-by: darrick.wong@oracle.com
file_remove_suid() is a misnomer since it removes also file capabilities
stored in xattrs and sets S_NOSEC flag. Also should_remove_suid() tells
something else than whether file_remove_suid() call is necessary which
leads to bugs.
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Orabug: 24803533 Signed-off-by: darrick.wong@oracle.com
IB/ipoib: Expose acl_enable sysfs file as read only
This file can be used to determine if ipoib supports IB-ACL.
In debug mode all sysfs files are exposed in full mode.
In non-debug mode only acl_enable is exposed but in real only mode.
Chuck Anderson [Sun, 28 May 2017 02:56:21 +0000 (19:56 -0700)]
Merge branch 'topic/uek-4.1/dtrace' up to bug 26137220 into uek/uek-next
* topic/uek-4.1/dtrace:
ctf: prevent modules on the dedup blacklist from sharing any types at all
ctf: emit bitfields in in-memory order
ctf: bitfield support
ctf: emit file-scope static variables
ctf: speed up the dwarf2ctf duplicate detector some more
ctf: strdup() -> xstrdup()
ctf: speed up the dwarf2ctf duplicate detector
ctf: add module parameter to simple_dwfl_new() and adjust both callers
ctf: fix the size of int and avoid duplicating it
ctf: allow overriding of DIE attributes: use it for parent bias
DTrace tcp/udp provider probes
dtrace: define DTRACE_PROBE_ENABLED to 0 when !CONFIG_DTRACE
dtrace: ensure limit is enforced even when pcs is NULL
dtrace: make x86_64 FBT return probe detection less restrictive
dtrace: support passing offset as arg0 to FBT return probes
dtrace: make FBT entry probe detection less restrictive on x86_64
dtrace: adjust FBT entry probe dection for OL7
Pablo Neira Ayuso [Wed, 9 Dec 2015 21:06:59 +0000 (22:06 +0100)]
netfilter: nf_dup: add missing dependencies with NF_CONNTRACK
CONFIG_NF_CONNTRACK=m
CONFIG_NF_DUP_IPV4=y
results in:
net/built-in.o: In function `nf_dup_ipv4':
>> (.text+0xd434f): undefined reference to `nf_conntrack_untracked'
Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit d3340b79ec8222d20453b1e7f261b017d1d09dc9)
Pablo Neira Ayuso [Sun, 31 May 2015 16:04:11 +0000 (18:04 +0200)]
netfilter: nf_tables: add nft_dup expression
This new expression uses the nf_dup engine to clone packets to a given gateway.
Unlike xt_TEE, we use an index to indicate output interface which should be
fine at this stage.
Moreover, change to the preemtion-safe this_cpu_read(nf_skb_duplicated) from
nf_dup_ipv{4,6} to silence a lockdep splat.
Based on the original tee expression from Arturo Borrero Gonzalez, although
this patch has diverted quite a bit from this initial effort due to the
change to support maps.
Pablo Neira Ayuso [Sun, 31 May 2015 15:54:44 +0000 (17:54 +0200)]
netfilter: factor out packet duplication for IPv4/IPv6
Extracted from the xtables TEE target. This creates two new modules for IPv4
and IPv6 that are shared between the TEE target and the new nf_tables dup
expressions.
This prepares for a TEE like expression in nftables.
We want to ensure only one duplicate is sent, so both will
use the same percpu variable to detect duplication.
The other use case is detection of recursive call to xtables, but since
we don't want dependency from nft to xtables core its put into core.c
instead of the x_tables core.
Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit e7c8899f3e6f2830136cf6e115c4a55ce7a3920a)
Martin KaFai Lau [Sat, 23 May 2015 03:56:02 +0000 (20:56 -0700)]
ipv6: Set FLOWI_FLAG_KNOWN_NH at flowi6_flags
The neighbor look-up used to depend on the rt6i_gateway (if
there is a gateway) or the rt6i_dst (if it is a RTF_CACHE clone)
as the nexthop address. Note that rt6i_dst is set to fl6->daddr
for the RTF_CACHE clone where fl6->daddr is the one used to do
the route look-up.
Now, we only create RTF_CACHE clone after encountering exception.
When doing the neighbor look-up with a route that is neither a gateway
nor a RTF_CACHE clone, the daddr in skb will be used as the nexthop.
In some cases, the daddr in skb is not the one used to do
the route look-up. One example is in ip_vs_dr_xmit_v6() where the
real nexthop server address is different from the one in the skb.
This patch is going to follow the IPv4 approach and ask the
ip6_pol_route() callers to set the FLOWI_FLAG_KNOWN_NH properly.
In the next patch, ip6_pol_route() will honor the FLOWI_FLAG_KNOWN_NH
and create a RTF_CACHE clone.
Signed-off-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Julian Anastasov <ja@ssi.bg> Tested-by: Julian Anastasov <ja@ssi.bg> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 48e8aa6e3137692d38f20e8bfff100e408c6bc53)
Jan Kara [Sun, 28 Feb 2016 21:36:38 +0000 (08:36 +1100)]
ext4: Fix data exposure after failed AIO DIO
When AIO DIO fails e.g. due to IO error, we must not convert unwritten
extents as that will expose uninitialized data. Handle this case
by clearing unwritten flag from io_end in case of error and thus
preventing extent conversion.
Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry-picked commit from 74c66bcb7eda551f3b8588659c58fe29184af903)
Christoph Hellwig [Mon, 8 Feb 2016 03:40:51 +0000 (14:40 +1100)]
xfs: fold xfs_vm_do_dio into xfs_vm_direct_IO
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry-picked commit from c19b104a67b3bb1ac48275a8a1c9df666e676c25)
Christoph Hellwig [Mon, 8 Feb 2016 03:40:51 +0000 (14:40 +1100)]
xfs: don't use ioends for direct write completions
We only need to communicate two bits of information to the direct I/O
completion handler:
(1) do we need to convert any unwritten extents in the range
(2) do we need to check if we need to update the inode size based
on the range passed to the completion handler
We can use the private data passed to the get_block handler and the
completion handler as a simple bitmask to communicate this information
instead of the current complicated infrastructure reusing the ioends
from the buffer I/O path, and thus avoiding a memory allocation and
a context switch for any non-trivial direct write. As a nice side
effect we also decouple the direct I/O path implementation from that
of the buffered I/O path.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Brian Foster <bfoster@redhat.com>
(cherry-picked commit from 273dda76f757108bc2b29d30a9595b6dd3bdf3a1)
Orabug: 24393811
Conflicts:
Fixed a merge conflict in xfs_trace.h arised due to absence of
xfs_zero_eof in UEK4.
Signed-off-by: Ashok Vairavan <ashok.vairavan@oracle.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Christoph Hellwig [Fri, 28 Apr 2017 01:27:09 +0000 (18:27 -0700)]
direct-io: always call ->end_io if non-NULL
This way we can pass back errors to the file system, and allow for
cleanup required for all direct I/O invocations.
Also allow the ->end_io handlers to return errors on their own, so that
I/O completion errors can be passed on to the callers.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry-picked commit from 187372a3b9faff68ed61c291d0135e6739e0dbdf)
Orabug: 24393811
Conflicts:
The change in the return type of the function dio_iodone_t
broke the KABI. Hence, the original function return type is wrapped
around under the flag __GENKSYMS__
Signed-off-by: Ashok Vairavan <ashok.vairavan@oracle.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Under certain situations, an incremental send operation can fail due to a
premature attempt to create a new top level inode (a direct child of the
subvolume/snapshot root) whose name collides with another inode that was
removed from the send snapshot.
Consider the following example scenario.
Parent snapshot:
. (ino 256, gen 8)
|---- a1/ (ino 257, gen 9)
|---- a2/ (ino 258, gen 9)
Send snapshot:
. (ino 256, gen 3)
|---- a2/ (ino 257, gen 7)
In this scenario, when receiving the incremental send stream, the btrfs
receive command fails like this (ran in verbose mode, -vv argument):
rmdir a1
mkfile o257-7-0
rename o257-7-0 -> a2
ERROR: rename o257-7-0 -> a2 failed: Is a directory
What happens when computing the incremental send stream is:
1) An operation to remove the directory with inode number 257 and
generation 9 is issued.
2) An operation to create the inode with number 257 and generation 7 is
issued. This creates the inode with an orphanized name of "o257-7-0".
3) An operation rename the new inode 257 to its final name, "a2", is
issued. This is incorrect because inode 258, which has the same name
and it's a child of the same parent (root inode 256), was not yet
processed and therefore no rmdir operation for it was yet issued.
The rename operation is issued because we fail to detect that the
name of the new inode 257 collides with inode 258, because their
parent, a subvolume/snapshot root (inode 256) has a different
generation in both snapshots.
So fix this by ignoring the generation value of a parent directory that
matches a root inode (number 256) when we are checking if the name of the
inode currently being processed collides with the name of some other
inode that was not yet processed.
We can achieve this scenario of different inodes with the same number but
different generation values either by mounting a filesystem with the inode
cache option (-o inode_cache) or by creating and sending snapshots across
different filesystems, like in the following example:
$ mkfs.btrfs -f /dev/sdc
$ mount /dev/sdc /mnt
$ touch /mnt/a2
$ btrfs subvolume snapshot -r /mnt /mnt/snap2
$ btrfs receive /mnt -f /tmp/1.snap
# Take note that once the filesystem is created, its current
# generation has value 7 so the inode from the second snapshot has
# a generation value of 7. And after receiving the first snapshot
# the filesystem is at a generation value of 10, because the call to
# create the second snapshot bumps the generation to 8 (the snapshot
# creation ioctl does a transaction commit), the receive command calls
# the snapshot creation ioctl to create the first snapshot, which bumps
# the filesystem's generation to 9, and finally when the receive
# operation finishes it calls an ioctl to transition the first snapshot
# (snap1) from RW mode to RO mode, which does another transaction commit
# and bumps the filesystem's generation to 10.
$ rm -f /tmp/1.snap
$ btrfs send /mnt/snap1 -f /tmp/1.snap
$ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/2.snap
$ umount /mnt
$ mkfs.btrfs -f /dev/sdd
$ mount /dev/sdd /mnt
$ btrfs receive /mnt /tmp/1.snap
# Receive of snapshot snap2 used to fail.
$ btrfs receive /mnt /tmp/2.snap
Signed-off-by: Robbie Ko <robbieko@synology.com> Reviewed-by: Filipe Manana <fdmanana@suse.com>
[Rewrote changelog to be more precise and clear] Signed-off-by: Filipe Manana <fdmanana@suse.com>
(cherry picked from commit 4dd9920d991745c4a16f53a8f615f706fbe4b3f7) Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com> Signed-off-by: Shan Hai <shan.hai@oracle.com>
All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mmio under pref mmio.
According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.
Mark if the entire path from the host to the adapter is over PCI Express.
Set pref compatible bit for claim/sizing/assign for 64bit mem resource
on that pcie device.
-v2: set pref for mmio 64 when whole path is PCI Express, according to David Miller.
-v3: don't set pref directly, change to UNDER_PREF, and set PREF before
sizing and assign resource, and cleart PREF afterwards. requested by BenH.
-v4: use on_all_pcie_path device flag instead.
-v6: update after pci_find_bus_resource() change
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 44e098ad7113adb109fa2d95a29fe2ba9a846efd) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 174fdc115fe527cdcf6b4b99f1e8e6ca4f8062ce) Signed-off-by: Allen Pais <allen.pais@oracle.com>
It turns out that pci_resource_compatible()/pci_up_path_over_pref_mem64()
just check resource with bridge pref mmio register idx 15, and we have put
resource to use mmio register idx 14 during of_scan_pci_bridge()
as the bridge does not have mmio resource.
We already fix pci_up_path_over_pref_mem64() to check all bus resources.
And at the same time, this patch make resource to have consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.
Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.
Signed-off-by: Yinghai Lu <yinghai@kernel.org> Tested-by: Khalid Aziz <khalid.aziz@oracle.com> Cc: sparclinux@vger.kernel.org
Orabug: 22855133
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 71c1871c22891102da6303d09b46184361d5f853) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 47b22604dceb59dfc1018ebd0b8def065daa27db) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Yinghai Lu [Sat, 18 Jun 2016 02:24:51 +0000 (19:24 -0700)]
sparc/PCI: Reserve legacy mmio after PCI mmio
On one system found bunch of claim resource fail from pci device.
pci_sun4v f02b894c: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x2007e00000000-0x2007e0fffffff] (bus address [0x0000-0xfffffff])
pci_bus 0000:00: root bus resource [mem 0x2000000000000-0x200007effffff] (bus address [0x00000000-0x7effffff])
pci_bus 0000:00: root bus resource [mem 0x2000100000000-0x20007ffffffff] (bus address [0x100000000-0x7ffffffff])
...
PCI: Claiming 0000:00:02.0: Resource 14: 0002000000000000..00020000004fffff [200]
pci 0000:00:02.0: can't claim BAR 14 [mem 0x2000000000000-0x20000004fffff]: address conflict with Video RAM area [??? 0x20000000a0000-0x20000000bffff flags 0x80000000]
pci 0000:02:00.0: can't claim BAR 0 [mem 0x2000000000000-0x20000000fffff]: no compatible bridge window
PCI: Claiming 0000:02:00.0: Resource 3: 0002000000100000..0002000000103fff [200]
pci 0000:02:00.0: can't claim BAR 3 [mem 0x2000000100000-0x2000000103fff]: no compatible bridge window
PCI: Claiming 0000:02:00.1: Resource 0: 0002000000200000..00020000002fffff [200]
pci 0000:02:00.1: can't claim BAR 0 [mem 0x2000000200000-0x20000002fffff]: no compatible bridge window
PCI: Claiming 0000:02:00.1: Resource 3: 0002000000104000..0002000000107fff [200]
pci 0000:02:00.1: can't claim BAR 3 [mem 0x2000000104000-0x2000000107fff]: no compatible bridge window
PCI: Claiming 0000:02:00.2: Resource 0: 0002000000300000..00020000003fffff [200]
pci 0000:02:00.2: can't claim BAR 0 [mem 0x2000000300000-0x20000003fffff]: no compatible bridge window
PCI: Claiming 0000:02:00.2: Resource 3: 0002000000108000..000200000010bfff [200]
pci 0000:02:00.2: can't claim BAR 3 [mem 0x2000000108000-0x200000010bfff]: no compatible bridge window
PCI: Claiming 0000:02:00.3: Resource 0: 0002000000400000..00020000004fffff [200]
pci 0000:02:00.3: can't claim BAR 0 [mem 0x2000000400000-0x20000004fffff]: no compatible bridge window
PCI: Claiming 0000:02:00.3: Resource 3: 000200000010c000..000200000010ffff [200]
pci 0000:02:00.3: can't claim BAR 3 [mem 0x200000010c000-0x200000010ffff]: no compatible bridge window
The bridge 00:02.0 resource does not get reserved as Video RAM take the position early,
and following children resources reservation all fail.
Move down Video RAM area reservation after pci mmio get reserved,
so we leave pci driver to use those regions.
-v5: merge simplify one and use pcibios_bus_to_resource()
-v6: use pci_find_bus_resource()
Signed-off-by: Yinghai Lu <yinghai@kernel.org> Tested-by: Khalid Aziz <khalid.aziz@oracle.com> Cc: sparclinux@vger.kernel.org
Orabug: 22855133
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit bb2c8f32be84cbeec0dd585481c637657e73b05e) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Yinghai Lu [Sat, 18 Jun 2016 02:24:50 +0000 (19:24 -0700)]
PCI: Add pci_find_bus_resource()
Add pci_find_bus_resource() to return bus resource for input resource.
In some case, we may only have bus instead of dev.
It is same as pci_find_parent_resource, but take bus as input.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Orabug: 22855133
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 7f93fc77f440039967ee5a057d49644526a7879f) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Yinghai Lu [Sat, 18 Jun 2016 02:24:49 +0000 (19:24 -0700)]
sparc/PCI: Use correct offset for bus address to resource
After we added 64bit mmio parsing, we got some "no compatible bridge window"
warning on anther new model that support 64bit resource.
It turns out that we can not use mem_space.start as 64bit mem space
offset, aka there is mem_space.start != offset.
Use child_phys_addr to calculate exact offset and record offset in
pbm.
After patch we get correct offset.
/pci@305: PCI IO [io 0x2007e00000000-0x2007e0fffffff] offset 2007e00000000
/pci@305: PCI MEM [mem 0x2000000100000-0x200007effffff] offset 2000000000000
/pci@305: PCI MEM64 [mem 0x2000100000000-0x2000dffffffff] offset 2000000000000
...
pci_sun4v f02ae7f8: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x2007e00000000-0x2007e0fffffff] (bus address [0x0000-0xfffffff])
pci_bus 0000:00: root bus resource [mem 0x2000000100000-0x200007effffff] (bus address [0x00100000-0x7effffff])
pci_bus 0000:00: root bus resource [mem 0x2000100000000-0x2000dffffffff] (bus address [0x100000000-0xdffffffff])
-v3: put back mem64_offset, as we found T4 has mem_offset != mem64_offset
check overlapping between mem64_space and mem_space.
-v7: after new pci_mmap_page_range patches.
-v8: remove change in pci_resource_to_user()
Signed-off-by: Yinghai Lu <yinghai@kernel.org> Tested-by: Khalid Aziz <khalid.aziz@oracle.com> Cc: sparclinux@vger.kernel.org
Orabug: 22855133
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit f296714da83b75783997f8dcfe2a9021ef8fedde) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit c34a8c61ea58d516fb20c6ec4fdf338f96fcfeef) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Yinghai Lu [Mon, 25 Jul 2016 22:07:59 +0000 (16:07 -0600)]
PCI: Let pci_mmap_page_range() take resource address
Original pci_mmap_page_range() is taking PCI BAR value aka usr_address.
Bjorn found out that it would be much simple to pass resource address
directly and avoid extra those __pci_mmap_make_offset.
In this patch:
1. in proc path: proc_bus_pci_mmap, try convert back to resource
before calling pci_mmap_page_range
2. in sysfs path: pci_mmap_resource will just offset with resource start.
3. all pci_mmap_page_range will have vma->vm_pgoff with in resource
range instead of BAR value.
4. skip calling __pci_mmap_make_offset, as the checking is done
in pci_mmap_fits().
-v2: add pci_user_to_resource and remove __pci_mmap_make_offset
-v3: pass resource pointer with pci_mmap_page_range()
-v4: put __pci_mmap_make_offset() removing to following patch
seperate /sys io access alignment checking to another patch
updated after Bjorn's pci_resource_to_user() changes.
-v5: update after fix for pci_mmap with proc path accoring to
Bjorn.
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit d6ccd78899c966eec1bac726f96f6cbed5b9960e) Signed-off-by: Allen Pais <allen.pais@oracle.com>
vma->vm_pgoff is above code segment is user/BAR value >> PAGE_SHIFT.
pci_start is resource->start >> PAGE_SHIFT.
For sparc, resource start is different from BAR start aka pci bus address.
pci bus address need to add offset to be the resource start.
So that commit breaks all arch that exposed value is BAR/user value,
and need to be offseted to resource address.
test code using: ./test_mmap_proc /proc/bus/pci/0000:00/04.0 0x2000000
test code segment:
fd = open(argv[1], O_RDONLY);
...
sscanf(argv[2], "0x%lx", &offset);
left = offset & (PAGE_SIZE - 1);
offset &= PAGE_MASK;
ioctl(fd, PCIIOC_MMAP_IS_MEM);
addr = mmap(NULL, PAGE_SIZE, PROT_READ, MAP_SHARED, fd, offset);
for (i = 0; i < 8; i++)
printf("%x ", addr[i + left]);
munmap(addr, PAGE_SIZE);
close(fd);
Fixes: 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files") Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Orabug: 22855133
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 7bd8ad7855e6ecdac36c6dc7946f5b6beff13ae2) Signed-off-by: Allen Pais <allen.pais@oracle.com>
PCI: Supply CPU physical address (not bus address) to iomem_is_exclusive()
iomem_is_exclusive() requires a CPU physical address, but on some arches we
supplied a PCI bus address instead.
On most arches, pci_resource_to_user(res) returns "res->start", which is a
CPU physical address. But on microblaze, mips, powerpc, and sparc, it
returns the PCI bus address corresponding to "res->start".
The result is that pci_mmap_resource() may fail when it shouldn't (if the
bus address happens to match an existing resource), or it may succeed when
it should fail (if the resource is exclusive but the bus address doesn't
match it).
Call iomem_is_exclusive() with "res->start", which is always a CPU physical
address, not the result of pci_resource_to_user().
Fixes: e8de1481fd71 ("resource: allow MMIO exclusivity for device drivers") Suggested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Arjan van de Ven <arjan@linux.intel.com>
Orabug: 22855133
(cherry picked from commit ca620723d4ff9ea7ed484eab46264c3af871b9ae) Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit aee594b88bfcb58f51e0070de06d3879b3ea4609) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 2dc2632b0b252f8f50c276efa9cc4f00c8e067b5) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 934fffe0fdf1bf81c90be604827f19c4ede839fb) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 59860a19cf9b2acd24a7eaec6d539dbc984a90b9) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit b2fd930d3e95db05979aefc42291be1f6ba2c625) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 09dd990a13d7ea2a257f5be189f109fa80259599) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit de113e58a8cc67f7daa128c33ac49a33935dc767) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit c0691adf4a28993c77371969ff7800901ff1a67b) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit bb9160790d346bcbfc0b5ca701e7e6f6d5d56f87) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 2998a347e93c41d8677e73510a139aa54339c88f) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 4e49b00da550d255a9470d4ffcffb6dea2227570) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 0c060ada1d50dd5f423eed0e2ba4f3e15c4579b0) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 5b6a6cf1e2785b6bf9153c726e09435c05921040) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 7d551cd315fb544b9b815566737de6e146fd0cd8) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Babu Moger [Mon, 15 Feb 2016 08:42:02 +0000 (09:42 +0100)]
PCI: Prevent VPD access for buggy devices
On some devices, reading or writing VPD causes a system panic.
This can be easily reproduced by running "lspci -vvv" or
"cat /sys/bus/devices/XX../vpd".
Blacklist these devices so we don't access VPD data at all.
[bhelgaas: changelog, comment, drop pci/access.c changes] Link: https://bugzilla.kernel.org/show_bug.cgi?id=110681 Tested-by: Shane Seymour <shane.seymour@hpe.com> Tested-by: Babu Moger <babu.moger@oracle.com> Signed-off-by: Babu Moger <babu.moger@oracle.com> Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Alexander Duyck <alexander.duyck@gmail.com>
(cherry picked from commit 7c20078a8197389eead62399419fdc4f8ac4a8a3)
Provide a common sets of dev_attrib attributes for all devices using the
generic SPC/SBC parsers, and a second one with the minimal required read-only
attributes for passthrough devices. The later is only used by pscsi for now,
but will be wired up for the full-passthrough TCMU use case as well.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
(cherry picked from commit 5873c4d157400ade4052e9d7b6259fa592e1ddbf) Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com> Signed-off-by: Shan Hai <shan.hai@oracle.com>
Rewrite the backend driver registration based on what we did to the fabric
drivers: introduce a read-only struct target_bakckend_ops that the driver
registers, which is then instanciate as a struct target_backend by the
core. This allows the ops vector to be smaller and allows us to mark it
const. At the same time the registration function can set up the
configfs attributes, avoiding the need to add additional boilerplate code
for that to the drivers.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
(cherry picked from commit 0a06d4309dc168dfa70cec3cf0cd9eb7fc15a2fd) Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com> Signed-off-by: Shan Hai <shan.hai@oracle.com>
Adrian Hunter [Fri, 16 Oct 2015 13:24:05 +0000 (16:24 +0300)]
perf/x86: Fix time_shift in perf_event_mmap_page
Commit:
b20112edeadf ("perf/x86: Improve accuracy of perf/sched clock")
allowed the time_shift value in perf_event_mmap_page to be as much
as 32. Unfortunately the documented algorithms for using time_shift
have it shifting an integer, whereas to work correctly with the value
32, the type must be u64.
In the case of perf tools, Intel PT decodes correctly but the timestamps
that are output (for example by perf script) have lost 32-bits of
granularity so they look like they are not changing at all.
Fix by limiting the shift to 31 and adjusting the multiplier accordingly.
Also update the documentation of perf_event_mmap_page so that new code
based on it will be more future-proof.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Fixes: b20112edeadf ("perf/x86: Improve accuracy of perf/sched clock") Link: http://lkml.kernel.org/r/1445001845-13688-2-git-send-email-adrian.hunter@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit b9511cd761faafca7a1acc059e792c1399f9d7c6)
Adrian Hunter [Fri, 21 Aug 2015 09:05:18 +0000 (12:05 +0300)]
perf/x86: Improve accuracy of perf/sched clock
When TSC is stable perf/sched clock is based on it.
However the conversion from cycles to nanoseconds
is not as accurate as it could be. Because
CYC2NS_SCALE_FACTOR is 10, the accuracy is +/- 1/2048
The change is to calculate the maximum shift that
results in a multiplier that is still a 32-bit number.
For example all frequencies over 1 GHz will have
a shift of 32, making the accuracy of the conversion
+/- 1/(2^33). That is achieved by using the
'clocks_calc_mult_shift()' function.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/1440147918-22250-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit b20112edeadf0b8a1416de061caa4beb11539902)
Keith Busch [Wed, 27 Apr 2016 20:22:32 +0000 (14:22 -0600)]
x86/apic: Handle zero vector gracefully in clear_vector_irq()
If x86_vector_alloc_irq() fails x86_vector_free_irqs() is invoked to cleanup
the already allocated vectors. This subsequently calls clear_vector_irq().
The failed irq has no vector assigned, which triggers the BUG_ON(!vector) in
clear_vector_irq().
We cannot suppress the call to x86_vector_free_irqs() for the failed
interrupt, because the other data related to this irq must be cleaned up as
well. So calling clear_vector_irq() with vector == 0 is legitimate.
Remove the BUG_ON and return if vector is zero,
[ tglx: Massaged changelog ]
Fixes: b5dc8e6c21e7 "x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors" Signed-off-by: Keith Busch <keith.busch@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 1bdb8970392a68489b469c3a330a1adb5ef61beb)
Signed-off-by: Nicolas Droux <nicolas.droux@oracle.com> Acked-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Shan Hai <shan.hai@oracle.com>
Signed-off-by: Tomas Jedlicka <tomas.jedlicka@oracle.com> Acked-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Nick Alcock [Wed, 24 May 2017 16:57:05 +0000 (17:57 +0100)]
ctf: prevent modules on the dedup blacklist from sharing any types at all
The deduplication blacklist exists to deal with a few modules, mostly
old ISA sound drivers, which consist of a #define and a #include of
another module, which then uses #ifdef profusely, sometimes on structure
members. This leads to DWARF which has differently shaped structures
in the same source location, which conflicts with the purpose of the
deduplicator, which is to use the source location to identify identical
structures and merge them.
Before now, the blacklist worked by preventing the appearance of a
structure in a module on the blacklist from making a structure shared:
it could still be shared if other modules defined it. This fails to
work for two reasons.
Firstly, if it is used by only *one* other module, we'll hit an
assertion failure in the emission phase which checks that any type it
emits is either defined in the module being emitted or in the shared
type repo.
We could remove that assertion, but we'd still be in the wrong, because
you could easily have a type in some header used by many modules that
said
struct trouble {
#ifdef MODULE_FOO
/* one definition */
#else
/* a different definition */
#endif
}
and a module that says
#define MODULE_FOO 1
#include <other_module.c>
Even if we blacklisted this module (and we would), this would still
fail, because 'struct trouble' would end up in the shared type
repository, and the existing code would fail to emit a new definition of
it in module blah, even though it should because its definition is
different.
This shows that if a module is pulling tricks like this we cannot trust
its use of shared types at all, since we have no visibility into
preprocessor definitions: regardless of the space cost (about 40KiB per
module), we cannot let it share any types whatsoever with the rest of
the kernel. Rather than piling heaps of blacklist checks in all over
dwarf2ctf to implement this, we do it by exploiting the fact that the
deduplicator works entirely on the basis of type IDs. We add a
'blacklist type prefix' that type_id() can add to the start of its IDs
(with some extra decoration, because the start of type IDs is a file
path, so we want this to be an impossible path). If we set this prefix
to the module name if and only if the module is blacklisted, and do not
add one otherwise, then every blacklisted module will have a unique set
of IDs for all its types, which can be shared within the module but not
outside it, so every type in the module will be unique and none of them
will end up in the shared type repository.
While we're at it, add yet another ancient ISA sound driver that plays
the same games to the blacklist.
This fix makes blacklisting modules much more space-expensive: each such
module expands the current size of the kernel module package by about
40KiB. (But there is only one blacklisted module built in current UEK,
so this is a tolerable cost.)
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: vincent.lim@oracle.com
Orabug: 26137220
[ 437f] structure_type
name (strp) "IO_APIC_route_entry"
byte_size (data1) 8
[ 438b] member
name (strp) "vector"
byte_size (data1) 4
bit_size (data1) 8
bit_offset (data1) 24
data_member_location (data1) 0
[ 439a] member
name (strp) "delivery_mode"
byte_size (data1) 4
bit_size (data1) 3
bit_offset (data1) 21
data_member_location (data1) 0
[ 43a9] member
name (strp) "dest_mode"
byte_size (data1) 4
bit_size (data1) 1
bit_offset (data1) 20
data_member_location (data1) 0
[ 43b8] member
name (strp) "delivery_status"
byte_size (data1) 4
bit_size (data1) 1
bit_offset (data1) 19
data_member_location (data1) 0
But CTF on little-endian requires the opposite: it has special handling
for the first member of a structure which assumes that it is closest to
the start of memory: in effect, it wants structure member addresses to
always ascend, even within bitfields, regardless of endianness (which
makes some sense intellectually as well).
dwarf2ctf's emission code generally emits sequentially, so except where
deduplication has eliminated items or dependent type insertion has added
them it emits things in the CTF in the same order as in the DWARF. We
can avoid this for short runs, as in this case, by switching from
iteration to recursion in such cases, spotting a run at identical
data_member_location, recursing until we hit the end of the run, then
unwinding and emitting as we unwind until the recursion is over.
Orabug: 25815129 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: tomas.jedlicka@oracle.com
Nick Alcock [Thu, 2 Feb 2017 00:22:05 +0000 (00:22 +0000)]
ctf: bitfield support
Support for bitfields in dwarf2ctf was embryonic and largely untested
before now due to bugs in libdtrace-ctf: with a fix for those in hand,
we can fix bitfields here too.
Bitfields in DWARF and CTF have annoyingly different representations.
In DWARF, a bitfield is represented something like this:
[ 16561] member
name (string) "ihl"
decl_file (data1) 225
decl_line (data1) 87
type (ref4) [ 38]
byte_size (data1) 1
bit_size (data1) 4
bit_offset (data1) 4
data_member_location (sdata) 0
[...]
[ 38] typedef
name (strp) "__u8"
decl_file (data1) 36
decl_line (data1) 20
type (ref4) [ 43]
i.e. the padding, size, and starting location are all represented in the
member, where you would conceptually expect it to be.
In CTF, the starting location of the conceptual containing type of a
bitfield is encoded in the member: but the size and starting location of
the bitfield itself is represented in the dependent type, which is added
as a "non-root" type (which cannot be looked up by name) so that it can
have the same name as the un-bitfielded base type without causing a name
clash.
We use the new DIE attribute override mechanism added in commit 8935199962
to override DW_AT_bit_size and DW_AT_bit_offset for such members (fixing
a pre-existing bug in the process: we were looking for the DW_AT_bit_size
on the structure as a whole!), and in the base-type emission function
checking for the existence of a DW_AT_bit_size/offset and responding to
them by overriding the size and offset derived from DW_AT_byte_size and
noting that this is a non-root type. (The override needed, annoyingly,
is endian-dependent, because CTF consumers assume that on little-endian
systems the offset relates to the least-significant edge of the bitfield,
counting from the LSB, while DWARF assumes the opposite).
But this is not enough: unless more is done, this type will appear
to have the same type ID as its non-bitfield equivalent, leading to
confusion about which CTF file it should appear in and quite possibly
leading to it ending up in a CTF file that the structure containing the
bitfield cannot even see. So augment type_id()'s representation of
base types from e.g. 'int' to something like 'int:4' if and only if
a DW_AT_bit_size or an override of it is present and that override is
a different size from the native bitness of the type itself (the
DW_AT_byte_size). We encode the bit_offset only if there is also a
bit_size, as something like int:4:2. (That's unambiguous because
these attributes always arrive in pairs in bitfields and never appear
in anything else in C-generated DWARF.)
Finally, this breaks an optimization in the deduplicator, which was that
all structure members reference some top-level type, so when marking a
type as seen, structure members could just be skipped. Now, they have
to be chased iff they are bitfields using the same override trickery as
above to change the DW_AT_bit_size/offset in the member's type DIE, and
that bitfield override needs to be passed down to type_id() when finally
marking duplicated types as shared too. (Avoid code duplication by
factoring out some related code from a horrible conditional in
detect_duplicates() into a new type_needs_sharing() function.)
Orabug: 25815129 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: tomas.jedlicka@oracle.com
Nick Alcock [Thu, 27 Apr 2017 17:39:53 +0000 (18:39 +0100)]
ctf: emit file-scope static variables
For as long as dwarf2ctf has emitted variables into the CTF, it has
emitted only extern variables. This is for two reasons: firstly, a
misconception that global variables with static linkage did not appear
in /proc/kallmodsyms (they do), and secondly, an ambiguity problem.
We cannot usefully distinguish two variables with the same name in the
same module: they differ only by address, so if both are static
variables in different translation units, we can't tell which is which.
(Also, we cannot emit more than one variable with a given name into a
given module CTF file in any case). CTF's modular rather than
translation-unit-based variable/type scope bites us here.
I sought to avoid this bug by emitting only non-static variables, but
this does not save us, because there might be another static variable
with the same name in the same module, whereupon the ambiguity problem
arises all over again. We must identify such ambiguous cases and strip
them out (not emitting CTF for this variable at all): then we can emit
static file-scope variables into the CTF without worry.
We do this by introducing a new, module-scope vars_seen hashtable into
the deduplicator state, which gains an entry for every variable name
seen in this module, and indicates whether it is static or not. This
lets us tell if we have seen a variable with a given name more than
once, and if we have, whether any of the instances was static. Then
we can consult this blacklist at variable-emission time, and skip any
variable if it is in the blacklist.
Unfortunately, computing the name for the variable's entry in the
blacklist is fairly expensive, and has to be done for every variable:
worse yet, this increases the number of variables emitted drastically
(in vmlinux and the shared typo repo alone, we go from 2247 to 10409
variables), and emitting that much CTF is not free: so the runtime goes
up by about 5%. We will reclaim this lost speed soon (and then some).
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: tomas.jedlicka@oracle.com
Orabug: 25962387
Nick Alcock [Thu, 9 Mar 2017 14:31:33 +0000 (14:31 +0000)]
ctf: speed up the dwarf2ctf duplicate detector some more
The duplicate detector's alias detection pass is still doing unnecessary
work. When a non-opaque structure is marked shared, it is sometimes
necessary to do another deduplication scan, because the marking may have
marked types used within the structure as shared, which may require yet
more types (e.g. opaque uses of of that type in other modules) to be
marked shared as well. So while we know this pass can only affect
structures/ unions/enums that have names, and their interior types, it
would seem that we must keep scanning them to see if they need
deduplication until none remain.
However, there is one exception: if a non-opaque type and its
corresponding opaque type are both already marked shared, or if we have
just processed them and marked them accordingly, we know that we will
never need to re-mark those particular types again, since they can't be
more shared than they already are: so we can remove them from
consideration in future passes. Because we are only opening DWARF files
in this pass as needed now, this hugely cuts down the number of files we
process in subsequent passes: we still see the same number of passes,
but passes after the first (which marks tens of thousands of opaque
types as shared) only open a few files, mark a few hundred types, and
flash past in under a second.
In my tests, the alias fixup pass now takes under 10s, which can be
more or less ignored: all other passes other than initialization
and writeout are much more expensive. (Before this series, it took
over a minute on the fastest machine I have access to, and over three
minutes on SPARC.)
Orabug: 25815306 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: tomas.jedlicka@oracle.com
Nick Alcock [Tue, 7 Mar 2017 20:31:12 +0000 (20:31 +0000)]
ctf: speed up the dwarf2ctf duplicate detector
dwarf2ctf is very slow. By far its most expensive pass is the duplicate
detector. Of necessity this has to scan every object file in the kernel
to identify shared types, which is pretty expensive even when the cache
is hot, but it's not doing this particularly efficiently and can be sped
up quite a lot.
As of commit f0d0ebd0b4, the duplicate detector's job was cut in two:
the first pass identifies all non-structure types and non-opaque
structures used by more than one module, and the second "alias fixup"
pass repeatedly unifies opaque and non-opaque structures with the same
name in different translation units, sharing their definitions. Both of
these passes generate or modify type IDs, so both need access to the
DWARF DIE of the types in question, since the type ID is derived
recursively from the DIE: but the second pass need not look at the DWARF
of any translation units that do not contain structures that might be
unified. However, the two are currently written in the same way, using
process_file() to traverse all the kernel's DWARF, even though the alias
fixup pass does almost nothing with that DWARF, and has less and less to
do on each iteration.
The sheer amount of wasted time here is remarkable. We traverse the
DWARF once for primary duplicate detection, once for CTF emission, but
often four or five or even seven or eight times for the alias fixup pass
(the precise count depends upon the relationships between types and the
order in which the DWARF files are traversed).
So improve things by tracking all types that the alias fixup pass is
interested in (structure types that are not anonymous inner structures
nor opaque nor used only as the types of array indices) and stash them
away during the first duplicate detection pass in a new temporary
singly-linked list, detect_duplicates_state.named_structs. We remember
the filename and DWARF DIE offset (so we can look the type up again) and
the type ID (because we just worked it out, so recomputing it would be a
waste of time). Then, rather than doing a process_file() for the alias
fixup pass, traverse the linked list, opening DWARF files as needed to
mark things as shared (but no more often than that: marking non-opaque
types needs the DIE so we can traverse into all its subtypes and mark
them shared too, but marking opaque types needs no DIE at all).
This has a significant effect on dwarf2ctf speed, slashing 25% off its
runtime in my tests, reducing the duplicate detector's share of the
runtime from about 80s to about 24s.
The dominant time consumer is now CTF emission rather than the
duplicate detector.
Orabug: 25815306 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: tomas.jedlicka@oracle.com
Nick Alcock [Thu, 2 Feb 2017 00:23:16 +0000 (00:23 +0000)]
ctf: fix the size of int and avoid duplicating it
An upcoming bitfield-capable release of libdtrace-ctf adds extra
consistency checking which identified embarrassing but heretofore
harmless bugs in dwarf2ctf's representation of basic types.
dwarf2ctf has to emit a few basic types "by hand", since these are used
in the representation of types one of CTF or DWARF does not bother to
encode more complex forms for (function pointers, always encoded as
'int (*)()' in CTF, and 'void'). Embarrassingly, we were getting the
size of 'int' wrong: it should be in bits but we were emitting a count
of bytes instead, leading to a CTF representation of a 4-bit int.
This is always overridden by an accurate representation built into
DTrace in real use, but libdtrace-ctf finds the inconsistency anyway.
Worse is that it emits a representation of 'int' twice, once by hand in
init_ctf_table() and then again when it comes across the real 'int' type
DIE in the debuginfo. This is because we forgot to intern the types we
add by hand in the id_to_module and id_to_type hashes we use to detect
duplicate types, because we can only intern types we have a DWARF DIE
for, and these types either have no DIE at all or we just don't know
about it because we haven't even begun to traverse the debuginfo to look
up DIEs yet.
Fix this by adding a mark_shared_by_name() function which can be used to
intern basic types by name in these hashes. It has hardwired knowledge
of the type ID notation, but no more such knowledge than is already
present in detect_duplicates_alias_fixup() and friends (no more than
that types with no associated filename or line number are preceded by
"////".)
Orabug: 25815129 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: tomas.jedlicka@oracle.com
Nick Alcock [Wed, 1 Feb 2017 23:51:21 +0000 (23:51 +0000)]
ctf: allow overriding of DIE attributes: use it for parent bias
Currently, dwarf2ctf's CTF type emission machinery emits any given CTF
type based purely on the data in the corresponding DWARF DIE, with
possible adjustments based on the DIE's structural parent (useful for
structure members, if not so much for top-level types). But from time
to time we need to adjust a CTF type depending on some property not of
its structural parent but of a type that depends on it: i.e., for
structures, we might want to adjust the offset of the members to cater
for the fact that this structure is being structurally merged with a
shorter assignment-compatible structure with identical name which
appeared in some translation unit that was processed earlier.
Currently, we handle this case, and only this case, by passing down a
'parent_bias' to all the CTF assembly functions. Replace this with a
more generic mechanism whereby an array of 'overrides' can be passed
down to construct_ctf_id(), die_to_ctf(), and all subordinate assembly
functions: these overrides consist of an array of die_override_t's,
where each element can either override or add to the value of one DWARF
attribute: this kicks in for specific DWARF tags only. (Only numerical
attributes are supported, obviously.)
(We also pass the overrides down to type_id() so that overrides can
affect the ID of types and thus cause a single DWARF type to generate
multiple CTF types, though we do not use this facility in this commit.)
To process the attributes, we introduce a new private_find_override() to
search the override list, and private_dwarf_udata() to fetch a udata and
handle it. (We do not override dwarf_hasattr(): anything that wants to
override an attribute that may not exist has to call
private_find_override() itself. If this happens a lot, we can introduce
an override for dwarf_hasattr() too.)
Currently we use this in exactly one place: in assemble_ctf_su_member(),
to replace the use of parent_bias. Further uses will come in the next
commit: thanks to this commit, none of them will require adding new
parameters to all the CTF construction functions :)
Also rename the 'override' parameter on the CTF construction functions,
which was used by array assembly to indicate that CTF types should
replace their parent type, with a much less confusingly-named 'replace'
parameter. (It was badly named before, but now that we have a parameter
named 'overrides' it is devastatingly badly named.)
Orabug: 25815129 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: tomas.jedlicka@oracle.com
Alan Maguire [Wed, 12 Apr 2017 21:34:56 +0000 (22:34 +0100)]
DTrace tcp/udp provider probes
This patch adds DTrace SDT probes for the TCP and UDP protocols. For tcp
the following probes are added:
tcp:::send Fires when a tcp segment is transmitted
tcp:::receive Fires when a tcp segment is received
tcp:::state-change Fires when a tcp connection changes state
tcp:::connect-request Fires when a SYN segment is sent
tcp:::connect-refused Fires when a RST is received for connection attempt
tcp:::connect-established
Fires when three-way handshake completes for
initiator
tcp:::accept-refused Fires when a RST is sent refusing connection attempt
tcp:::accept-established
Fires when three-way handshake succeeds for acceptor
Arguments for all of these probes are:
arg0 struct sk_buff *; to be translated into pktinfo_t * containing
implementation-independent packet data
arg1 struct sock *; to be translated into csinfo_t * containing
implementation-independent connection data
arg2 __dtrace_tcp_void_ip_t *; to be translated into ipinfo_t * containing
implementation-independent IP information. Custom type is used as
this gives DTrace a hint that we can source IP information from other
arguments if the IP header is not available.
arg3 struct tcp_sock *; to be translated into tcpsinfo_t * containing
implementation-independent TCP connection data
arg4 struct tcphdr *; to be translated into a tcpinfo_t * containing
implementation-independent TCP header data
arg5 int representing previous state; to be translated into a
tcplsinfo_t * which contains the previous state. Differs from
current state (arg6) for state-change probes only.
arg6 int representing current state. Cannot be sourced from struct
tcp_sock as we sometimes need to probe before state change is
reflected there
arg7 int representing direction of traffic for probe; values are
DTRACE_NET_PROBE_INBOUND for receipt of data and
DTRACE_NET_PROBE_OUTBOUND for transmission.
For udp the following probes are added:
udp:::send Fires when a udp datagram is sent
udp:::receive Fires when a udp datagram is received
Arguments for these probes are:
arg0 struct sk_buff *; to be translated into pktinfo_t * containing
implementation-independent packet data
arg1 struct sock *; to be translated into csinfo_t * containing
implementation-independent connection data
arg2 void_ip_t *; to be translated into ipinfo_t * containing
implementation-independent IP information.
arg3 struct udp_sock *; to be translated into a udpsinfo_t * containing
implementation-independent UDP connection data
arg4 struct udphdr *; to be translated into a udpinfo_t * containing
implementation-independent UDP header information.
Kris Van Hees [Wed, 24 May 2017 03:34:53 +0000 (23:34 -0400)]
dtrace: ensure limit is enforced even when pcs is NULL
The dtrace_user_stacktrace() functions for x86_64 and sparc64 were
not handling the specified limit (st->limit correctly if the buffer
for PC values (st->pcs) was NULL. This commit ensures that we
decrement the limit whenever we encounter a PC, whether it gets
stored or not.
Orabug: 25949692 Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Acked-by: Nick Alcock <nick.alcock@oracle.com>
Kris Van Hees [Tue, 16 May 2017 03:29:16 +0000 (23:29 -0400)]
dtrace: make x86_64 FBT return probe detection less restrictive
The FBT return probe detection mechanism on x86_64 was requiring that
the "ret" instruction be followed by a "push %rbp" or "nop", which is
much too restrictive. The new code allows probing of all "ret"
instructions that occur in a function regardless of what instructions
follows.
In order to make this possible, the functions to set and clear FBT
probes on x86_64 (dtrace_invop_add() and dtrace_invop_remove()) have
been modified to accept a 2nd argument that indicates the instruction
to patch the probe location with. This is needed because FBT return
probes need a different instruction on x86_64 (LOCK prefix to force
an invalid opcode trap isn't safe because we do not know what
instruction may follow the "ret").
This commit also fixes the declaration of the dtrace_bad_address()
function that was missing its return type.
Orabug: 25949048 Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Acked-by: Nick Alcock <nick.alcock@oracle.com>
Kris Van Hees [Tue, 16 May 2017 03:25:09 +0000 (23:25 -0400)]
dtrace: support passing offset as arg0 to FBT return probes
FBT return probes pass the offset from the function start (in bytes)
as arg0. To make that possible, we pass the offset value in the call
to fbt_add_probe. For FBT entry probes we pass 0 (which is ignored).
Orabug: 25949086 Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Acked-by: Nick Alcock <nick.alcock@oracle.com>
Kris Van Hees [Tue, 16 May 2017 03:05:41 +0000 (23:05 -0400)]
dtrace: make FBT entry probe detection less restrictive on x86_64
The logic on x86_64 to determine whether we can probe a function is
too restrictive. By placing the probe on the "push %rbp" instruction
we can cover more functions, in case the "mov %rsp,%rbp" instruction
does not follow it immediately.
Orabug: 25949030 Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Reviewed-by: Tomas Jedlicka <tomas.jedlicka@oracle.com>
projects / users / jedix / linux-maple.git / log