Use the of_device_get_match_data() helper instead of open coding,
postponing the matching until when it's really needed.
Note that the renesas_usb3 driver is used with DT only, so there's
always a valid match.
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Use the of_device_get_match_data() helper instead of open coding.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch adds support for generic phy as an optional. If you want
to use a generic phy (e.g. phy-rcar-gen3-usb3 driver) on this driver,
you have to do "insmod phy-rcar-gen3-usb3.ko" first for now.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch moves pm_runtime_{en,dis}able() call timing to
renesas_usb3_{probe,remove}() for supporting PM_SLEEP feature in
the future.
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
[shimoda: Revise the commit log]
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch adds support for R-Car D3. This SoC needs to release
the PLL reset by the UGCTRL register. So, since this is not the same
as other R-Car Gen3 SoCs, this patch adds a new type as
"USBHS_TYPE_RCAR_GEN3_WITH_PLL".
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch unifies the Gen2 and Gen3 pipe_config setting on
usbhs_parse_dt().
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
mxs phy has data pin contact and usb charger detector blocks which
can be controlled by software to detect charger type for SDP, CDP and
DCP.
Reviewed-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Now that all the information we need sits in struct dwc3_ep, we can
start taking only a pointer to struct dwc3_ep as an argument. This
allows us to clean the code up a bit.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
There is more possibility for sharing code if we just realise that now
__dwc3_gadget_kic_transfer() knows to break out early if there are no
TRBs left.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This will let us call __dwc3_gadget_kick_transfer()
unconditionally. No functional changes, cleanup only.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
If the clock handle is given in the DT, it means the clock is required
for proper operation of the PHY. In that case a failure to obtain the
clock must be propagated to stop the driver from probing. This fixes
working with clocks, which request probe deferral.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
A couple of structures in <linux/usb/gadget.h> have incomplete kerneldoc
comments, leading to these warnings in the docs build:
./include/linux/usb/gadget.h:230: warning: No description found for parameter 'claimed'
./include/linux/usb/gadget.h:230: warning: No description found for parameter 'enabled'
./include/linux/usb/gadget.h:412: warning: No description found for parameter 'quirk_altset_not_supp'
./include/linux/usb/gadget.h:412: warning: No description found for parameter 'quirk_stall_not_supp'
./include/linux/usb/gadget.h:412: warning: No description found for parameter 'quirk_zlp_not_supp'
Document those fields to make the warnings go away.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Here's a new metro-usb device id for another bar-code scanner.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEHszNKQClByu0A+9RQQ3kT97htJUFAlnoTmoRHGpvaGFuQGtl
cm5lbC5vcmcACgkQQQ3kT97htJWw7A/8CcZIokgucSDAvBKbmFKIB7kWDoFnLMjQ
/pVQOgR+Pkw7sDAHlc/N4KSsSQhP6VdQ+lar8NwK9GyI0lQ2Xl3kD7beEiznTV7Q
fCgIW5w059W6W0hezVuRMPmJyQr6T/8HhIJXTC1y4xUw4IEX5m13LEoVWJasOnLP
oCUsaod6RhOsNQWWcC6vfmbTji/DikmZSUwHYj0YXsaLyz9fakV7WvRJVIz4MZsi
4Ea8a4PVnc5ki7UxxIIoGPwao/zX1fcuYCZgWeLmgPQ5oU7JOlMY4A9LZd7ETqNP
JJEcG1vuW3FupUYMQqbykd5a5div1VyfGW4vBDzpF71ipA8pPt8bgxeJVSQ/KSAA
/qAT2SkAtzJc1LMVnNOl5YTNSd9H1UdJknL93CaS6QIE8h5ew1k9uJyLDlRBszLZ
lTdoD9ngojNQ4V4xZxoT5hpHslZxXrvwLM1vJjLE7vR7qXaxYJ9sAnpKQQURnYzJ
d55Ie6Lj8dalNjTCPPiGX6SbtXV+yMJMyQtwdsnmTeJe7W9Y1wQ3XFBeevNy8I84
fqXmuEgHjpfT/xMnFWVNYzVGY2YM/w/1Uu7PYOKpx8C7DQGNiEo43bqIoLSVts62
3qZDwHbt9Ie2ERrVth9d47awd2I+aiLxz2ClYbRkhqlOdN4NfFo38Nzs7Og5reya
ykBF074OfT4=
=g3Ln
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fixes for v4.14-rc6
Here's a new metro-usb device id for another bar-code scanner.
Signed-off-by: Johan Hovold <johan@kernel.org>
For CPUs which have an unknown or invalid CPU location (physical location)
assume that their cycle counters aren't syncronized across CPUs.
Signed-off-by: Helge Deller <deller@gmx.de>
Fixes: c8c3735997a3 ("parisc: Enhance detection of synchronous cr16 clocksources")
Cc: stable@vger.kernel.org # 4.13+
Signed-off-by: Helge Deller <deller@gmx.de>
__cmpxchg_u64 is built and used outside CONFIG_64BIT and thus needs to
be exported. This fixes the following build error seen when building
parisc:allmodconfig.
ERROR: "__cmpxchg_u64" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Helge Deller <deller@gmx.de>
As discussed on the debian-hppa list, double-wordcompare and exchange
operations fail on 32-bit kernels. Looking at the code, I realized that
the ",ma" completer does the wrong thing in the "ldw,ma 4(%r26), %r29"
instruction. This increments %r26 and causes the following store to
write to the wrong location.
Note by Helge Deller:
The patch applies cleanly to stable kernel series if this upstream
commit is merged in advance:
f4125cfdb300 ("parisc: Avoid trashing sr2 and sr3 in LWS code").
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Tested-by: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
Fixes: 89206491201c ("parisc: Implement new LWS CAS supporting 64 bit operations.")
Cc: stable@vger.kernel.org # 3.13+
Signed-off-by: Helge Deller <deller@gmx.de>
Fix for stable:
- Fix DDI translation tables for BDW (Chris).
Critical fix:
- Fix GPU Hang on GVT (Changbin).
Other fixes:
- Fix eviction when GGTT is idle (Chris).
- CNL PLL fixes (Rodrigo).
- Fix pwrite into shmemfs (Chris).
- Mask bits for BXT and CHV L3 Workaround
WaProgramL3SqcReg1Default (Oscar).
* tag 'drm-intel-fixes-2017-10-18-1' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915: Use a mask when applying WaProgramL3SqcReg1Default
drm/i915: Report -EFAULT before pwrite fast path into shmemfs
drm/i915/cnl: Fix PLL initialization for HDMI.
drm/i915/cnl: Fix PLL mapping.
drm/i915: Use bdw_ddi_translations_fdi for Broadwell
drm/i915: Fix eviction when the GGTT is idle but full
drm/i915/gvt: Fix GPU hang after reusing vGPU instance across different guest OS
The pointer fs_ns is assigned from inode->i_ib->s_user_ns before
a null pointer check on inode, hence if inode is actually null we
will get a null pointer dereference on this assignment. Fix this
by only dereferencing inode after the null pointer check on
inode.
Detected by CoverityScan CID#1455328 ("Dereference before null check")
Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: stable@vger.kernel.org
Acked-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
The commit 78bcac7b2ae1e ("Input: add support for the STMicroelectronics
FingerTip touchscreen) used the 'touchscreen_parse_properties()' helper
function in order to get the value of common properties.
But, commit 78bcac7b2ae1e didn't set the capability of ABS_MT_POSITION_*
before calling touchscreen_parse_properties(). In result, the max_x and
max_y of 'struct touchscreen_properties' were not set.
Fixes: 78bcac7b2ae1e ("Input: add support for the STMicroelectronics FingerTip touchscreen")
Cc: stable@vger.kernel.org
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Step config setting for 5 wire touchscreen is incorrect for Y coordinates.
It was broken while we moved to DT. If you look close at the offending
commit bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made
configurable"), the change was:
- STEPCONFIG_XNP | STEPCONFIG_YPN;
+ ts_dev->bit_xn | ts_dev->bit_yp;
while bit_xn = STEPCONFIG_XNN and bit_yp = STEPCONFIG_YNN. Not quite the
same.
Fixes: bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made configurable")
Signed-off-by: Jeff Lance <j-lance1@ti.com>
[vigneshr@ti.com: Rebase to v4.14-rc1]
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Single amdgpu regression fix.
* 'drm-fixes-4.14' of git://people.freedesktop.org/~agd5f/linux:
Revert "drm/amdgpu: discard commands of killed processes"
[AV: in addition to the fix in previous commit]
Signed-off-by: Matthew Garrett <mjg59@google.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Reviewed-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
some nouveau fixes.
* 'linux-4.14' of git://github.com/skeggsb/linux:
drm/nouveau/fbcon: fix oops without fbdev emulation
drm/nouveau/kms/nv50: fix oops during DP IRQ handling on non-MST boards
drm/nouveau/bsp/g92: disable by default
drm/nouveau/mmu: flush tlbs before deleting page tables
This is similar to an earlier commit 52dfcc5ccfbb ("drm/nouveau: fix for
disabled fbdev emulation"), but protects all occurrences of helper.fbdev
in the source.
I see oops in nouveau_fbcon_accel_save_disable() called from
nouveau_fbcon_set_suspend_work() on Linux 3.13 when
CONFIG_DRM_FBDEV_EMULATION option is disabled.
Signed-off-by: Pavel Roskin <plroskin@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
- fix some more CONFIG_XFS_RT related build problems
- fix data loss when writeback at eof races eofblocks gc and loses
- invalidate page cache after fs finishes a dio write
- remove dirty page state when invalidating pages so releasepage does
the right thing when handed a dirty page
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCgAGBQJZ5jqbAAoJEPh/dxk0SrTrtfMP/jcQ6lTDcpnQ7XEP2fg2dXjx
2+z8uI7Mjr5wo2qfIWHc8nZHZ+8KRak4U28rTlrXkeVbJ79x3Z+SzeipP76dGHXB
u9MD7uacTD6BDT7R8/bux7g7KrPATVJYJiT3PRHZ5ysUT6i9KnREdbaKpgOwhMcI
Ivd9ROZHx62CmZhsbfLzD+Ccy9/mGBR5OmT8nQlsuD8cEcFU5u1afaJ2/YlCjNLN
c16Q8dhGXed7tjduiYCzsxDiewJMzSfcGdyk6yCwXdR3zcI3RdhXUN5FRH0R9GB2
xxG1n5Q4qgtgODGgcPUl9WG8mfhVvEcuZGioxChQrxCEcaHt1Waop0fOixLy9J3Q
lUn4qjA5S+VBqa6XsKCSCkiZdDtncSedvMRQYef09q8DGAouwAtN/Z3BVM24oyWU
k5888Gt4EHZK6V3lz3qPMmGFxfuPL6GeyEvIYUezpVIYsmp0sLQTeNFUW+XC7fb/
tOBNom4ARHFmSb5da7uwJvesNZBVFSpFQtxkcx1OL0rhTqlKIfPP61dLznKhqUTL
2NhaFjnznYenSEK2CsP+V3CtQrCxywdqDNnOEgTgKJbWPpsYMX63z/Cmtm0A7Qdz
BAbGc+OSBLqelwsWNnNzTWPHk33SKxtIxGTe8gKbKbrzbR7mxyJxHKEwpZvWIqh+
8eTdgJb1wgJyqtBsTSHN
=UY00
-----END PGP SIGNATURE-----
Merge tag 'xfs-4.14-fixes-6' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fixes from Darrick Wong:
- fix some more CONFIG_XFS_RT related build problems
- fix data loss when writeback at eof races eofblocks gc and loses
- invalidate page cache after fs finishes a dio write
- remove dirty page state when invalidating pages so releasepage does
the right thing when handed a dirty page
* tag 'xfs-4.14-fixes-6' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: move two more RT specific functions into CONFIG_XFS_RT
xfs: trim writepage mapping to within eof
fs: invalidate page cache after end_io() in dio completion
xfs: cancel dirty pages on invalidation
Pull block fixes from Jens Axboe:
"Three small fixes:
- A fix for skd, it was using kfree() to free a structure allocate
with kmem_cache_alloc().
- Stable fix for nbd, fixing a regression using the normal ioctl
based tools.
- Fix for a previous fix in this series, that fixed up
inconsistencies between buffered and direct IO"
* 'for-linus' of git://git.kernel.dk/linux-block:
fs: Avoid invalidation in interrupt context in dio_complete()
nbd: don't set the device size until we're connected
skd: Use kmem_cache_free
Andrey used the syzkaller fuzzer to find an out-of-bounds memory
access in usb_get_bos_descriptor(). The code wasn't checking that the
next usb_dev_cap_header structure could fit into the remaining buffer
space.
This patch fixes the error and also reduces the bNumDeviceCaps field
in the header to match the actual number of capabilities found, in
cases where there are fewer than expected.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This causes instability in piglit. It's fixed in drm-next with:
515c6faf85970af529953ec137b4b6fcb3272e25
1650c14b459ff9c85767746f1ef795a780653128
214a91e6bfabaa6cbfa692df8732000aab050795
29d253553559dba919315be847f4f2cce29edd42
79867462634836ee5c39a2cdf624719feeb189bd
This reverts commit 6af0883ed9770cf9b0a4f224c91481484cd1b025.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Otherwise we are blasting other bits in GEN8_L3SQCREG1 that might be important
(although we probably aren't at the moment because 0 seems to be the default
for all the other bits).
v2: Extra parentheses (Michel)
Fixes: 050fc46 ("drm/i915:bxt: implement WaProgramL3SqcReg1DefaultForPerf")
Fixes: 450174f ("drm/i915/chv: Tune L3 SQC credits based on actual latencies")
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1508271945-14961-1-git-send-email-oscar.mateo@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 930a784d02339be437fec07b3bb7213bde0ed53b)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
When pwriting into shmemfs, the fast path pagecache_write does not
notice when it is writing to beyond the end of the truncated shmemfs
inode. Report -EFAULT directly when we try to use pwrite into the
!I915_MADV_WILLNEED object.
Fixes: 7c55e2c5772d ("drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl")
Testcase: igt/gem_madvise/dontneed-before-pwrite
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016202732.25459-1-chris@chris-wilson.co.uk
(cherry picked from commit a6d65e451cc4e7127698384868a4447ee7be7d16)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Borislav thinks that we don't need this knob in a released kernel.
Get rid of it.
Requested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: b956575bed91 ("x86/mm: Flush more aggressively in lazy TLB mode")
Link: http://lkml.kernel.org/r/1fa72431924e81e86c164ff7881bf9240d1f1a6c.1508000261.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Due to timezones, commit:
b956575bed91 ("x86/mm: Flush more aggressively in lazy TLB mode")
was an outdated patch that well tested and fixed the bug but didn't
address Borislav's review comments.
Tidy it up:
- The name "tlb_use_lazy_mode()" was highly confusing. Change it to
"tlb_defer_switch_to_init_mm()", which describes what it actually
means.
- Move the static_branch crap into a helper.
- Improve comments.
Actually removing the debugfs option is in the next patch.
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: b956575bed91 ("x86/mm: Flush more aggressively in lazy TLB mode")
Link: http://lkml.kernel.org/r/154ef95428d4592596b6e98b0af1d2747d6cfbf8.1508000261.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Blacklist Broadwell X model 79 for late loading due to an erratum.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Tony Luck <tony.luck@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171018111225.25635-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The previous commit (0adbfd46) fixed a memory leak but also freed a
block in the success case, causing a stale pointer to be used with
potentially fatal results. Only free the vchi_instance block in the
case that vchi_connect fails; once connected, the instance is
retained for subsequent connections.
Simplifying the code by removing a bunch of gotos and returning errors
directly.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Fixes: 0adbfd4694c2 ("staging: bcm2835-audio: fix memory leak in bcm2835_audio_open_connection()")
Cc: stable <stable@vger.kernel.org> # 4.12+
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit f1174f77b50c ("bpf/verifier: rework value tracking")
removed the crafty selection of which pointer types are
allowed to be modified. This is OK for most pointer types
since adjust_ptr_min_max_vals() will catch operations on
immutable pointers. One exception is PTR_TO_CTX which is
now allowed to be offseted freely.
The intent of aforementioned commit was to allow context
access via modified registers. The offset passed to
->is_valid_access() verifier callback has been adjusted
by the value of the variable offset.
What is missing, however, is taking the variable offset
into account when the context register is used. Or in terms
of the code adding the offset to the value passed to the
->convert_ctx_access() callback. This leads to the following
eBPF user code:
r1 += 68
r0 = *(u32 *)(r1 + 8)
exit
being translated to this in kernel space:
0: (07) r1 += 68
1: (61) r0 = *(u32 *)(r1 +180)
2: (95) exit
Offset 8 is corresponding to 180 in the kernel, but offset
76 is valid too. Verifier will "accept" access to offset
68+8=76 but then "convert" access to offset 8 as 180.
Effective access to offset 248 is beyond the kernel context.
(This is a __sk_buff example on a debug-heavy kernel -
packet mark is 8 -> 180, 76 would be data.)
Dereferencing the modified context pointer is not as easy
as dereferencing other types, because we have to translate
the access to reading a field in kernel structures which is
usually at a different offset and often of a different size.
To allow modifying the pointer we would have to make sure
that given eBPF instruction will always access the same
field or the fields accessed are "compatible" in terms of
offset and size...
Disallow dereferencing modified context pointers and add
to selftests the test case described here.
Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In debian/ubuntu, libc.so is located at a different place,
/lib/x86_64-linux-gnu/libc-2.23.so, so it outputs like this when testing:
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.040 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.040/0.040/0.040/0.000 ms
0.000 probe_libc:inet_pton:(7f0e2db741c0))
__GI___inet_pton (/lib/x86_64-linux-gnu/libc-2.23.so)
getaddrinfo (/lib/x86_64-linux-gnu/libc-2.23.so)
[0xffffa9d40f34ff4d] (/bin/ping)
Fix up the libc path to make sure this test works in more OSes.
Committer testing:
When this test fails one can use 'perf test -v', i.e. in verbose mode, where
it'll show the expected backtrace, so, after applying this test:
On Fedora 26:
# perf test -v ping
62: probe libc's inet_pton & backtrace it with ping :
--- start ---
test child forked, pid 23322
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.058 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.058/0.058/0.058/0.000 ms
0.000 probe_libc:inet_pton:(7fe344310d80))
__GI___inet_pton (/usr/lib64/libc-2.25.so)
getaddrinfo (/usr/lib64/libc-2.25.so)
_init (/usr/bin/ping)
test child finished with 0
---- end ----
probe libc's inet_pton & backtrace it with ping: Ok
#
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Kim Phillips <kim.phillips@arm.com>
Cc: Li Zhijian <lizhijian@cn.fujitsu.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Philip Li <philip.li@intel.com>
Link: http://lkml.kernel.org/r/1508315649-18836-1-git-send-email-lizhijian@cn.fujitsu.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In current xyarray code, xyarray__max_x() returns max_y, and xyarray__max_y()
returns max_x.
It's confusing and for code logic it looks not correct.
Error happens when closing evsel fd. Let's see this scenario:
1. Allocate an fd (pseudo-code)
perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int nthreads)
{
evsel->fd = xyarray__new(ncpus, nthreads, sizeof(int));
}
xyarray__new(int xlen, int ylen, size_t entry_size)
{
size_t row_size = ylen * entry_size;
struct xyarray *xy = zalloc(sizeof(*xy) + xlen * row_size);
xy->entry_size = entry_size;
xy->row_size = row_size;
xy->entries = xlen * ylen;
xy->max_x = xlen;
xy->max_y = ylen;
......
}
So max_x is ncpus, max_y is nthreads and row_size = nthreads * 4.
2. Use perf syscall and get the fd
int perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
struct thread_map *threads)
{
for (cpu = 0; cpu < cpus->nr; cpu++) {
for (thread = 0; thread < nthreads; thread++) {
int fd, group_fd;
fd = sys_perf_event_open(&evsel->attr, pid, cpus->map[cpu],
group_fd, flags);
FD(evsel, cpu, thread) = fd;
}
}
static inline void *xyarray__entry(struct xyarray *xy, int x, int y)
{
return &xy->contents[x * xy->row_size + y * xy->entry_size];
}
These codes don't have issues. The issue happens in the closing of fd.
3. Close fd.
void perf_evsel__close_fd(struct perf_evsel *evsel)
{
int cpu, thread;
for (cpu = 0; cpu < xyarray__max_x(evsel->fd); cpu++)
for (thread = 0; thread < xyarray__max_y(evsel->fd); ++thread) {
close(FD(evsel, cpu, thread));
FD(evsel, cpu, thread) = -1;
}
}
Since xyarray__max_x() returns max_y (nthreads) and xyarry__max_y()
returns max_x (ncpus), so above code is actually to be:
for (cpu = 0; cpu < nthreads; cpu++)
for (thread = 0; thread < ncpus; ++thread) {
close(FD(evsel, cpu, thread));
FD(evsel, cpu, thread) = -1;
}
It's not correct!
This change is introduced by "475fb533fb7d" ("perf evsel: Fix buffer overflow
while freeing events")
This fix is to let xyarray__max_x() return max_x (ncpus) and
let xyarry__max_y() return max_y (nthreads)
Committer note:
This was also fixed by Ravi Bangoria, who provided the same patch,
noticing the problem with 'perf record':
<quote Ravi>
I see 'perf record -p <pid>' crashes with following log:
*** Error in `./perf': free(): invalid next size (normal): 0x000000000298b340 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f7fd85c87e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f7fd85d137a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f7fd85d553c]
./perf(perf_evsel__close+0xb4)[0x4b7614]
./perf(perf_evlist__delete+0x100)[0x4ab180]
./perf(cmd_record+0x1d9)[0x43a5a9]
./perf[0x49aa2f]
./perf(main+0x631)[0x427841]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f7fd8571830]
./perf(_start+0x29)[0x427a59]
</>
Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Fixes: d74be4767367 ("perf xyarray: Save max_x, max_y")
Link: http://lkml.kernel.org/r/1508339478-26674-1-git-send-email-yao.jin@linux.intel.com
Link: http://lkml.kernel.org/r/1508327446-15302-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It seems that it's possible to toggle NETLINK_F_EXT_ACK
through setsockopt() while another thread/CPU is building
a message inside netlink_ack(), which could then trigger
the WARN_ON()s I added since if it goes from being turned
off to being turned on between allocating and filling the
message, the skb could end up being too small.
Avoid this whole situation by storing the value of this
flag in a separate variable and using that throughout the
function instead.
Fixes: 2d4bc93368f5 ("netlink: extended ACK reporting")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch correctly sets the number of additional header descriptors
that will be sent in an indirect SCRQ entry.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When an EMAD is transmitted, a timeout work item is scheduled with a
delay of 200ms, so that another EMAD will be retried until a maximum of
five retries.
In certain situations, it's possible for the function waiting on the
EMAD to be associated with a work item that is queued on the same
workqueue (`mlxsw_core`) as the timeout work item. This results in
flushing a work item on the same workqueue.
According to commit e159489baa71 ("workqueue: relax lockdep annotation
on flush_work()") the above may lead to a deadlock in case the workqueue
has only one worker active or if the system in under memory pressure and
the rescue worker is in use. The latter explains the very rare and
random nature of the lockdep splats we have been seeing:
[ 52.730240] ============================================
[ 52.736179] WARNING: possible recursive locking detected
[ 52.742119] 4.14.0-rc3jiri+ #4 Not tainted
[ 52.746697] --------------------------------------------
[ 52.752635] kworker/1:3/599 is trying to acquire lock:
[ 52.758378] (mlxsw_core_driver_name){+.+.}, at: [<ffffffff811c4fa4>] flush_work+0x3a4/0x5e0
[ 52.767837]
but task is already holding lock:
[ 52.774360] (mlxsw_core_driver_name){+.+.}, at: [<ffffffff811c65c4>] process_one_work+0x7d4/0x12f0
[ 52.784495]
other info that might help us debug this:
[ 52.791794] Possible unsafe locking scenario:
[ 52.798413] CPU0
[ 52.801144] ----
[ 52.803875] lock(mlxsw_core_driver_name);
[ 52.808556] lock(mlxsw_core_driver_name);
[ 52.813236]
*** DEADLOCK ***
[ 52.819857] May be due to missing lock nesting notation
[ 52.827450] 3 locks held by kworker/1:3/599:
[ 52.832221] #0: (mlxsw_core_driver_name){+.+.}, at: [<ffffffff811c65c4>] process_one_work+0x7d4/0x12f0
[ 52.842846] #1: ((&(&bridge->fdb_notify.dw)->work)){+.+.}, at: [<ffffffff811c65c4>] process_one_work+0x7d4/0x12f0
[ 52.854537] #2: (rtnl_mutex){+.+.}, at: [<ffffffff822ad8e7>] rtnl_lock+0x17/0x20
[ 52.863021]
stack backtrace:
[ 52.867890] CPU: 1 PID: 599 Comm: kworker/1:3 Not tainted 4.14.0-rc3jiri+ #4
[ 52.875773] Hardware name: Mellanox Technologies Ltd. "MSN2100-CB2F"/"SA001017", BIOS 5.6.5 06/07/2016
[ 52.886267] Workqueue: mlxsw_core mlxsw_sp_fdb_notify_work [mlxsw_spectrum]
[ 52.894060] Call Trace:
[ 52.909122] __lock_acquire+0xf6f/0x2a10
[ 53.025412] lock_acquire+0x158/0x440
[ 53.047557] flush_work+0x3c4/0x5e0
[ 53.087571] __cancel_work_timer+0x3ca/0x5e0
[ 53.177051] cancel_delayed_work_sync+0x13/0x20
[ 53.182142] mlxsw_reg_trans_bulk_wait+0x12d/0x7a0 [mlxsw_core]
[ 53.194571] mlxsw_core_reg_access+0x586/0x990 [mlxsw_core]
[ 53.225365] mlxsw_reg_query+0x10/0x20 [mlxsw_core]
[ 53.230882] mlxsw_sp_fdb_notify_work+0x2a3/0x9d0 [mlxsw_spectrum]
[ 53.237801] process_one_work+0x8f1/0x12f0
[ 53.321804] worker_thread+0x1fd/0x10c0
[ 53.435158] kthread+0x28e/0x370
[ 53.448703] ret_from_fork+0x2a/0x40
[ 53.453017] mlxsw_spectrum 0000:01:00.0: EMAD retries (2/5) (tid=bf4549b100000774)
[ 53.453119] mlxsw_spectrum 0000:01:00.0: EMAD retries (5/5) (tid=bf4549b100000770)
[ 53.453132] mlxsw_spectrum 0000:01:00.0: EMAD reg access failed (tid=bf4549b100000770,reg_id=200b(sfn),type=query,status=0(operation performed))
[ 53.453143] mlxsw_spectrum 0000:01:00.0: Failed to get FDB notifications
Fix this by creating another workqueue for EMAD timeouts, thereby
preventing the situation of a work item trying to flush a work item
queued on the same workqueue.
Fixes: caf7297e7ab5f ("mlxsw: core: Introduce support for asynchronous EMAD register access")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here's a pull request to add a new file to the kernel's Documentation directory.
It adds a short document describing the views of how the Linux kernel community
feels about enforcing the license of the kernel.
The patch has been reviewed by a large number of kernel developers already, as
seen by their acks on the patch, and their agreement of the statement with
their names on it. The location of the file was also agreed upon by the
Documentation maintainer, so all should be good there.
For some background information about this statement, see this article
written by some of the kernel developers involved in drafting it:
http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
and this article that answers a number of questions that came up in the
discussion of this statement with the kernel developer community:
http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
If anyone has any further questions about it, please let me, and the TAB
members, know and we will be glad to help answer them.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWeR6Sw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykG3ACeN9zl6v505gikqm84ZkfBaxuxDVYAni1dqsY7
DCsTizcpTneOYeK/Sh+1
=lbTy
-----END PGP SIGNATURE-----
Merge tag 'enforcement-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull enforcement policy update from Greg KH:
"Documentation: Add a file explaining the requested Linux kernel
license enforcement policy
Here's a new file to the kernel's Documentation directory. It adds a
short document describing the views of how the Linux kernel community
feels about enforcing the license of the kernel.
The patch has been reviewed by a large number of kernel developers
already, as seen by their acks on the patch, and their agreement of
the statement with their names on it. The location of the file was
also agreed upon by the Documentation maintainer, so all should be
good there.
For some background information about this statement, see this article
written by some of the kernel developers involved in drafting it:
http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
and this article that answers a number of questions that came up in
the discussion of this statement with the kernel developer community:
http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
If anyone has any further questions about it, please let me, and the
TAB members, know and we will be glad to help answer them"
* tag 'enforcement-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
Documentation: Add a file explaining the Linux kernel license enforcement policy
Pull s390 fixes from Martin Schwidefsky:
"Two bug fixes:
- A fix for cputime accounting vs CPU hotplug
- Add two options to zfcpdump_defconfig to make SCSI dump work again"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: fix zfcpdump-config
s390/cputime: fix guest/irq/softirq times after CPU hotplug
# modprobe trace-events-sample
# echo 1 > /sys/kernel/debug/tracing/events/sample-trace/enable
# rmmod trace-events-sample
This would cause an oops. The issue is that I added another trace
event sample that reused a reg function of another trace event to
create a thread to call the tracepoints. The problem was that the
reg function couldn't handle nested calls (reg; reg; unreg; unreg;)
and created two threads (instead of one) and only removed one
on exit.
This isn't a critical bug as the bug is only in sample code. But sample
code should be free of known bugs to prevent others from copying
it. This is why this is also marked for stable.
-----BEGIN PGP SIGNATURE-----
iQHIBAABCgAyFiEEPm6V/WuN2kyArTUe1a05Y9njSUkFAlnmcA0UHHJvc3RlZHRA
Z29vZG1pcy5vcmcACgkQ1a05Y9njSUkvqAwAhY/W7OF2JG/TV2cHNmHZqTEgQOFz
59EXWI7EsnQzcKTm14rWuR477iK+Q6r2YEzpGajHhBcOy8KjpzYM2+Oj3qzn6ovc
dyMEwr2wsaVb52B0h2X9J7fsfzZtL0KIIb6Y/wSz/H28BTHMi0xJUJLDkH4W9jrB
g/3vbKHLpbr4hg8msMPoLSExe4seZeHeB+6VQ+G3VHuIIPlCZOSCnXH05pd8AqC6
Y9cJzKqlivNPJFWUDnref0yE1aK/KuRsC+DpceJmP/K1+uiYhFMKCwlpWz/kI2eQ
z02pYugUqck007NWCSdr1xTYWJQBEx4Ke19XKFhtXs2o5a/fgnVZoLYXUagV/QiT
VoNDHnuqqnTESySMK38dQvekdj5lPU80ycy+Dsgp9RSCW804MBvaXswoMT1095OV
zxyMAIsbSof2zgUqjUQKEFU75usjxpd1ifl6CoXlfH8hmKEvvdZmqvEypUKakyxh
0D9+DcGTyOAg9MLEpMdyaW7+F0CVLqwVToBM
=xSts
-----END PGP SIGNATURE-----
Merge tag 'trace-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fix from Steven Rostedt:
"Testing a new trace event format, I triggered a bug by doing:
# modprobe trace-events-sample
# echo 1 > /sys/kernel/debug/tracing/events/sample-trace/enable
# rmmod trace-events-sample
This would cause an oops. The issue is that I added another trace
event sample that reused a reg function of another trace event to
create a thread to call the tracepoints. The problem was that the reg
function couldn't handle nested calls (reg; reg; unreg; unreg;) and
created two threads (instead of one) and only removed one on exit.
This isn't a critical bug as the bug is only in sample code. But
sample code should be free of known bugs to prevent others from
copying it. This is why this is also marked for stable"
* tag 'trace-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing/samples: Fix creation and deletion of simple_thread_fn creation
The commit 99b5c5bb9a54 ("ALSA: hda - Remove the use of set_fs()")
converted the get_kctl_0dB_offset() call for killing set_fs() usage in
HD-audio codec code. The conversion assumed that the TLV callback
used in HD-audio code is only snd_hda_mixer_amp() and applies the TLV
calculation locally.
Although this assumption is correct, and all slave kctls are actually
with that callback, the current code is still utterly buggy; it
doesn't hit this condition and falls back to the next check. It's
because the function gets called after adding slave kctls to vmaster.
By assigning a slave kctl, the slave kctl object is faked inside
vmaster code, and the whole kctl ops are overridden. Thus the
callback op points to a different value from what we've assumed.
More badly, as reported by the KERNEXEC and UDEREF features of PaX,
the code flow turns into the unexpected pitfall. The next fallback
check is SNDRV_CTL_ELEM_ACCESS_TLV_READ access bit, and this always
hits for each kctl with TLV. Then it evaluates the callback function
pointer wrongly as if it were a TLV array. Although currently its
side-effect is fairly limited, this incorrect reference may lead to an
unpleasant result.
For addressing the regression, this patch introduces a new helper to
vmaster code, snd_ctl_apply_vmaster_slaves(). This works similarly
like the existing map_slaves() in hda_codec.c: it loops over the slave
list of the given master, and applies the given function to each
slave. Then the initializer function receives the right kctl object
and we can compare the correct pointer instead of the faked one.
Also, for catching the similar breakage in future, give an error
message when the unexpected TLV callback is found and bail out
immediately.
Fixes: 99b5c5bb9a54 ("ALSA: hda - Remove the use of set_fs()")
Reported-by: PaX Team <pageexec@freemail.hu>
Cc: <stable@vger.kernel.org> # v4.13
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While converting the error messages to the standard macros in the
commit 4e76a8833fac ("ALSA: hda - Replace with standard printk"), a
superfluous '-' slipped in the code mistakenly. Its influence is
almost negligible, merely shows a dB value as negative integer instead
of positive integer (or vice versa) in the rare error message.
So let's kill this embarrassing byte to show more correct value.
Fixes: 4e76a8833fac ("ALSA: hda - Replace with standard printk")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
