Increment netdev rx counters even for XDP_DROP verdict. Report even
tx bytes for xdp buffers (TYPE_NETSEC_XDP_TX or TYPE_NETSEC_XDP_NDO).
Moreover account pending buffer length in netsec_xdp_queue_one as it is
done for skb counterpart
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
We were checking for the full fsync flag in the inode before locking the
inode, which is racy, since at that that time it might not be set but
after we acquire the inode lock some other task set it. One case where
this can happen is on a system low on memory and some concurrent task
failed to allocate an extent map and therefore set the full sync flag on
the inode, to force the next fsync to work in full mode.
A consequence of missing the full fsync flag set is hitting the problems
fixed by commit 0c713cbab6 ("Btrfs: fix race between ranged fsync and
writeback of adjacent ranges"), BUG_ON() when dropping extents from a log
tree, hitting assertion failures at tree-log.c:copy_items() or all sorts
of weird inconsistencies after replaying a log due to file extents items
representing ranges that overlap.
So just move the check such that it's done after locking the inode and
before starting writeback again.
Fixes: 0c713cbab6 ("Btrfs: fix race between ranged fsync and writeback of adjacent ranges")
CC: stable@vger.kernel.org # 5.2+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
variable ret is not used after jumping to "unlock" label, so
the assignment is redundant.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull input fixes from Dmitry Torokhov:
"The main change is that we are reverting blanket enablement of SMBus
mode for devices with Elan touchpads that report BIOS release date as
2018+ because there are older boxes with updated BIOSes that still do
not work well in SMbus mode.
We will have to establish whitelist for SMBus mode it looks like"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Revert "Input: elantech - enable SMBus on new (2018+) systems"
Input: synaptics-rmi4 - avoid processing unknown IRQs
Input: soc_button_array - partial revert of support for newer surface devices
Input: goodix - add support for 9-bytes reports
Input: da9063 - fix capability and drop KEY_SLEEP
If we fail to reserve metadata for delalloc operations we end up releasing
the previously reserved qgroup amount twice, once explicitly under the
'out_qgroup' label by calling btrfs_qgroup_free_meta_prealloc() and once
again, under label 'out_fail', by calling btrfs_inode_rsv_release() with a
value of 'true' for its 'qgroup_free' argument, which results in
btrfs_qgroup_free_meta_prealloc() being called again, so we end up having
a double free.
Also if we fail to reserve the necessary qgroup amount, we jump to the
label 'out_fail', which calls btrfs_inode_rsv_release() and that in turns
calls btrfs_qgroup_free_meta_prealloc(), even though we weren't able to
reserve any qgroup amount. So we freed some amount we never reserved.
So fix this by removing the call to btrfs_inode_rsv_release() in the
failure path, since it's not necessary at all as we haven't changed the
inode's block reserve in any way at this point.
Fixes: c8eaeac7b7 ("btrfs: reserve delalloc metadata differently")
CC: stable@vger.kernel.org # 5.2+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The SHIFT_PERCPU_PTR() returns a pointer used by a number
of functions that expect the pointer to be __percpu annotated
(sparse address space 3). Adding __percpu to this makes the
following sparse warnings go away.
Note, this then creates the problem the __percup is marked
as noderef, which may need removing for some of the internal
functions, or to remove other warnings.
mm/vmstat.c:385:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:385:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:385:13: got signed char *
mm/vmstat.c:385:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:385:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:385:13: got signed char *
mm/vmstat.c:385:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:385:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:385:13: got signed char *
mm/vmstat.c:385:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:385:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:385:13: got signed char *
mm/vmstat.c:401:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:401:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:401:13: got signed char *
mm/vmstat.c:401:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:401:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:401:13: got signed char *
mm/vmstat.c:401:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:401:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:401:13: got signed char *
mm/vmstat.c:401:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:401:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:401:13: got signed char *
mm/vmstat.c:429:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:429:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:429:13: got signed char *
mm/vmstat.c:429:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:429:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:429:13: got signed char *
mm/vmstat.c:429:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:429:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:429:13: got signed char *
mm/vmstat.c:429:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:429:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:429:13: got signed char *
mm/vmstat.c:445:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:445:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:445:13: got signed char *
mm/vmstat.c:445:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:445:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:445:13: got signed char *
mm/vmstat.c:445:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:445:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:445:13: got signed char *
mm/vmstat.c:445:13: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:445:13: expected signed char [noderef] [usertype] <asn:3> *__p
mm/vmstat.c:445:13: got signed char *
mm/vmstat.c:763:29: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:763:29: expected signed char [noderef] <asn:3> *__p
mm/vmstat.c:763:29: got signed char *
mm/vmstat.c:763:29: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:763:29: expected signed char [noderef] <asn:3> *__p
mm/vmstat.c:763:29: got signed char *
mm/vmstat.c:763:29: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:763:29: expected signed char [noderef] <asn:3> *__p
mm/vmstat.c:763:29: got signed char *
mm/vmstat.c:763:29: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:763:29: expected signed char [noderef] <asn:3> *__p
mm/vmstat.c:763:29: got signed char *
mm/vmstat.c:825:29: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:825:29: expected signed char [noderef] <asn:3> *__p
mm/vmstat.c:825:29: got signed char *
mm/vmstat.c:825:29: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:825:29: expected signed char [noderef] <asn:3> *__p
mm/vmstat.c:825:29: got signed char *
mm/vmstat.c:825:29: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:825:29: expected signed char [noderef] <asn:3> *__p
mm/vmstat.c:825:29: got signed char *
mm/vmstat.c:825:29: warning: incorrect type in initializer (different address spaces)
mm/vmstat.c:825:29: expected signed char [noderef] <asn:3> *__p
mm/vmstat.c:825:29: got signed char *
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Dennis Zhou <dennis@kernel.org>
Better explain the usage of the microcontroller and what i915 is
responsible of. While at it, fix the documentation for the auth
function, which doesn't do any pinning anymore.
v2: add a comment on HuC being optional and descrive how HuC accesses
memory (Martin)
v3: add extra newline for better text organization (Martin)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Acked-by: Anna Karas <anna.karas@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191014183602.3643-3-daniele.ceraolospurio@intel.com
Add a short description of what we expect from GuC and some minor
improvements to existing documentation. Also remove a comment about a
difference between GuC and HuC that is not true anymore.
v2: add that the GuC is not mandatory (Martin)
v3: add extra newline for better text organization (Martin)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Acked-by: Anna Karas <anna.karas@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191014183602.3643-2-daniele.ceraolospurio@intel.com
To better organize the information, add a microcontrollers section and
move/link the GuC, HuC and DMC documentation under it. Also add a small
intro.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Acked-by: Anna Karas <anna.karas@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191014183602.3643-1-daniele.ceraolospurio@intel.com
Add the rc-vega-s9x keymap to the existing IR node in the device tree.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add an IR node to the Vega S96 dts to include the rc-vega-s9x keymap.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add missing #colling-cells field for G12B SoC
Add cooling-map for passive and hot trip point
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add missing #colling-cells field for G12A SoC
Add cooling-map for passive and hot trip point
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add minimal thermal zone for two temperature sensor
One is located close to the DDR and the other one is
located close to the PLLs (between the CPU and GPU)
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add cpu and ddr temperature sensors for G12 Socs
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add and enable the audio devices on the sei610.
The new FRDDR/TODDR D of the SM1 have been left out on purpose. The
plaftorm has 2 possible playback interfaces and 3 possible capture
interfaces. 3 pcm interfaces for each direction is enough.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add the audio devices found on the SM1 SoC family. Only the spdif output
and input are missing. These are not supported yet since no platform is
available to them.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
While it is useful for new drivers to use devm_platform_ioremap_resource,
this script is currently used to spam maintainers, often updating very
old drivers. The net benefit is the removal of 2 lines of code in the
driver but the review load for the maintainers is huge. As of now, more
that 560 patches have been sent, some of them obviously broken, as in:
https://lore.kernel.org/lkml/9bbcce19c777583815c92ce3c2ff2586@www.loen.fr/
Remove the script to reduce the spam.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The help text of NR_CPUS says that the maximum number of CPUs supported
without CPUMASK_OFFSTACK is 512. However, NR_CPUS_RANGE_END allows this
limit to be bypassed by MAXSMP even if CPUMASK_OFFSTACK is not set.
This scenario can currently only happen in the RT tree, since it has
"select CPUMASK_OFFSTACK if !PREEMPT_RT_FULL" in MAXSMP. However,
even if we ignore the RT tree, checking for MAXSMP in addition to
CPUMASK_OFFSTACK is redundant.
Signed-off-by: Scott Wood <swood@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Mike Travis <mike.travis@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191012070054.28657-1-swood@redhat.com
Przemysław Kopa reports that since commit b516ea586d ("PCI: Enable
NVIDIA HDA controllers"), the discrete GPU Nvidia GeForce GT 540M on his
2011 Samsung laptop refuses to runtime suspend, resulting in a power
regression and excessive heat.
Rivera Valdez witnesses the same issue with a GeForce GT 525M (GF108M)
of the same era, as does another Arch Linux user named "R0AR" with a
more recent GeForce GTX 1050 Ti (GP107M).
The commit exposes the discrete GPU's HDA controller and all four codecs
on the controller do not set the CLKSTOP and EPSS bits in the Supported
Power States Response. They also do not set the PS-ClkStopOk bit in the
Get Power State Response. hda_codec_runtime_suspend() therefore does
not call snd_hdac_codec_link_down(), which prevents each codec and the
PCI device from runtime suspending.
The same issue is present on some AMD discrete GPUs and we addressed it
by forcing runtime PM despite the bits not being set, see commit
57cb54e53b ("ALSA: hda - Force to link down at runtime suspend on
ATI/AMD HDMI").
Do the same for Nvidia HDMI codecs.
Fixes: b516ea586d ("PCI: Enable NVIDIA HDA controllers")
Link: https://bbs.archlinux.org/viewtopic.php?pid=1865512
Link: https://bugs.freedesktop.org/show_bug.cgi?id=75985#c81
Reported-by: Przemysław Kopa <prymoo@gmail.com>
Reported-by: Rivera Valdez <riveravaldez@ysinembargo.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Daniel Drake <dan@reactivated.net>
Cc: stable@vger.kernel.org # v5.3+
Link: https://lore.kernel.org/r/3086bc75135c1e3567c5bc4f3cc4ff5cbf7a56c2.1571324194.git.lukas@wunner.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Do not need to maintain our own shmem memory management
code as drm_gem_shmem_helpers provides it. And we can
also benifit from the work of others with shared code.
This is also a preparation for implementing buffer madv.
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010140152.17747-2-yuq825@gmail.com
Users of Intel P-Unit IPC driver might be surprised by harmless warning.
Thus, switch to API which doesn't issue a warning at all.
I²C multi-instantiate driver continues to add slave devices even when IRQ
resource is not found. For devices in the market IRQ resource is mandatory,
so, fail the ->probe() of the parent driver to avoid slaves being probed.
Avoid compiler warning due to unused variable in Classmate laptop driver.
The following is an automated git shortlog grouped by driver:
classmate-laptop:
- remove unused variable
i2c-multi-instantiate:
- Fail the probe if no IRQ provided
intel_punit_ipc:
- Avoid error message when retrieving IRQ
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAl2oJjgACgkQb7wzTHR8
rCiqIhAAwS3WO6HJultOU75VE4IvHGyaXItnq7wm/tiJm5kEWUgVLid9+p/nwax2
nLQjY1OlP50p7rdZWoIOLB9oZfJmOjzOSr7chxQjKVN1Nvwq1y7cBhNgZX/3d1fk
THZcA8RbXMnVpmUNbuAK7IW5H6mh82J4jD7JT9kI75JQCs9+42uoTJBYbRnE2H6j
3V6WSV8y5r0mIxumnd7JyEgpSkDF31OG5r1jJvOG9oHxszPxEOmLzOFw2sBQLcLz
oVJwAOI3ChSA1bOKFveAiDUtZo1Ndvy1c0c1ce0SWrdCecDudKmp8mdvExl/R9OW
OJOTmTfDuTvdO2TJ9LEJxwOvdox1LNQNQk2hlSktExePR9xptIfOcV7PWqcl33sR
qfIF3P0XR80Nwy5DVhZYZCoIa2TYrkP4sYBck9mvorB68D4tGxDeohFmupSp/2T8
InK6OGym7u3VMeAdOyJoOais7uvjWqNgRBZcV9zi5BZmOdMwflNOFrLx7JWQmk4B
Sw6Av7z0RvKamOaPJJr+wzIfqs+Hc3WTO1haU3kk8BMHnf5jdPQ9v1misF1ZdoKh
0/jnPSYYT0zAS60k5dXW+LNt77KY+bN5Jai2WnTUnI85jqeeWiiS5cusuIMcvG9M
n0Qxd20KBB2hgo662/fWe+U/KhmqdDVPmOuOfp/xBBYWJt/lWT0=
=dfns
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v5.4-3' of git://git.infradead.org/linux-platform-drivers-x86
Pull x86 platform driver fixes from Andy Shevchenko:
- Users of Intel P-Unit IPC driver might be surprised by harmless
warning. Thus, switch to API which doesn't issue a warning at all.
- I²C multi-instantiate driver continues to add slave devices even when
IRQ resource is not found. For devices in the market IRQ resource is
mandatory, so, fail the ->probe() of the parent driver to avoid
slaves being probed.
- Avoid compiler warning due to unused variable in Classmate laptop
driver.
* tag 'platform-drivers-x86-v5.4-3' of git://git.infradead.org/linux-platform-drivers-x86:
platform/x86: i2c-multi-instantiate: Fail the probe if no IRQ provided
platform/x86: intel_punit_ipc: Avoid error message when retrieving IRQ
platform/x86: classmate-laptop: remove unused variable
GFP_NOWAIT allocation can fail anytime - it doesn't wait for memory being
available and it fails if the mempool is exhausted and there is not enough
memory.
If we go down this path:
map_bio -> mg_start -> alloc_migration -> mempool_alloc(GFP_NOWAIT)
we can see that map_bio() doesn't check the return value of mg_start(),
and the bio is leaked.
If we go down this path:
map_bio -> mg_start -> mg_lock_writes -> alloc_prison_cell ->
dm_bio_prison_alloc_cell_v2 -> mempool_alloc(GFP_NOWAIT) ->
mg_lock_writes -> mg_complete
the bio is ended with an error - it is unacceptable because it could
cause filesystem corruption if the machine ran out of memory
temporarily.
Change GFP_NOWAIT to GFP_NOIO, so that the mempool code will properly
wait until memory becomes available. mempool_alloc with GFP_NOIO can't
fail, so remove the code paths that deal with allocation failure.
Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
The fixes pertain to a problem with initializing the Intel GPIO
irqchips when adding gpiochips, Andy fixed it up elegantly by
adding a hardware initialization callback to the struct
gpio_irq_chip so let's use this. Tested and verified on the
target hardware.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl2oFDQACgkQQRCzN7AZ
XXMqcxAAoFftmi61CZL5EH9oZNMD5ebg8ovBizNbP5KmQ6oAxv7RkX7TJpdAysAF
FpzmKIeR/hSiZ6t046xS2M1zBUHya9sb/X7Nlt7n/ZDbEC/aCvbRKaxADEdR7flQ
qzB2u/ZZ25yknTuCxu17Yvo1Bg1T1qEXr+36UJhw8tWDAt60UUi893o6qbnixpJ5
qaQc2IBrSsTStxnT4Tfom1nJ86gvCRgN1lKTCua0rlKVOtSO2MXf7ZlKz0eJBGpa
CNML7esE+/+4Qe6QM5KY6Rw9V0jO916N7xPoX2lVnF+HWjCc7uNmB7cWHMk55iuZ
NmkLfrkEgRwWjWTRXinlqIWTeFNWfrIsDjRbS+dCxZKxRZutPnUgNq8nrA51tD8P
qVdc29gk5myGKYCjc9onbDeJT6dgbf4ck/lYmumxp/EVlHIWFL5gCi1OwV0Nn80C
5KFyLvRf2dyKynaZSebTbdqnds4LHK3c49psnmye2eMKv5e7jCPeSzKgsYeCqT/i
SAa0gFhIGUd5e8BxiLwYf6rjCjoa6jXDz6fkCmSGDPU6iycp+wh2V4fSuXn6zBD/
wAm67n2QwcKsLWxvSTnCpcbSUt0eykPXHunswAflV+HDMOgmTz40+9F9Ymvcu+B/
H34k89WBDKWPjePDMrFw2su2EeZFo2o6HFJV8JuJzXn7xGHEpA8=
=tDS5
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"The fixes pertain to a problem with initializing the Intel GPIO
irqchips when adding gpiochips.
Andy fixed it up elegantly by adding a hardware initialization
callback to the struct gpio_irq_chip so let's use this. Tested and
verified on the target hardware"
* tag 'gpio-v5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: lynxpoint: set default handler to be handle_bad_irq()
gpio: merrifield: Move hardware initialization to callback
gpio: lynxpoint: Move hardware initialization to callback
gpio: intel-mid: Move hardware initialization to callback
gpiolib: Initialize the hardware with a callback
gpio: merrifield: Restore use of irq_base
Alexei Starovoitov says:
====================
v2->v3:
- while trying to adopt btf-based tracing in production service realized
that disabling bpf_probe_read() was premature. The real tracing program
needs to see much more than this type safe tracking can provide.
With these patches the verifier will be able to see that skb->data
is a pointer to 'u8 *', but it cannot possibly know how many bytes
of it is readable. Hence bpf_probe_read() is necessary to do basic
packet reading from tracing program. Some helper can be introduced to
solve this particular problem, but there are other similar structures.
Another issue is bitfield reading. The support for bitfields
is coming to llvm. libbpf will be supporting it eventually as well,
but there will be corner cases where bpf_probe_read() is necessary.
The long term goal is still the same: get rid of probe_read eventually.
- fixed build issue with clang reported by Nathan Chancellor.
- addressed a ton of comments from Andrii.
bitfields and arrays are explicitly unsupported in btf-based tracking.
This will be improved in the future.
Right now the verifier is more strict than necessary.
In some cases it can fall back to 'scalar' instead of rejecting
the program, but rejection today allows to make better decisions
in the future.
- adjusted testcase to demo bitfield and skb->data reading.
v1->v2:
- addressed feedback from Andrii and Eric. Thanks a lot for review!
- added missing check at raw_tp attach time.
- Andrii noticed that expected_attach_type cannot be reused.
Had to introduce new field to bpf_attr.
- cleaned up logging nicely by introducing bpf_log() helper.
- rebased.
Revolutionize bpf tracing and bpf C programming.
C language allows any pointer to be typecasted to any other pointer
or convert integer to a pointer.
Though bpf verifier is operating at assembly level it has strict type
checking for fixed number of types.
Known types are defined in 'enum bpf_reg_type'.
For example:
PTR_TO_FLOW_KEYS is a pointer to 'struct bpf_flow_keys'
PTR_TO_SOCKET is a pointer to 'struct bpf_sock',
and so on.
When it comes to bpf tracing there are no types to track.
bpf+kprobe receives 'struct pt_regs' as input.
bpf+raw_tracepoint receives raw kernel arguments as an array of u64 values.
It was up to bpf program to interpret these integers.
Typical tracing program looks like:
int bpf_prog(struct pt_regs *ctx)
{
struct net_device *dev;
struct sk_buff *skb;
int ifindex;
skb = (struct sk_buff *) ctx->di;
bpf_probe_read(&dev, sizeof(dev), &skb->dev);
bpf_probe_read(&ifindex, sizeof(ifindex), &dev->ifindex);
}
Addressing mistakes will not be caught by C compiler or by the verifier.
The program above could have typecasted ctx->si to skb and page faulted
on every bpf_probe_read().
bpf_probe_read() allows reading any address and suppresses page faults.
Typical program has hundreds of bpf_probe_read() calls to walk
kernel data structures.
Not only tracing program would be slow, but there was always a risk
that bpf_probe_read() would read mmio region of memory and cause
unpredictable hw behavior.
With introduction of Compile Once Run Everywhere technology in libbpf
and in LLVM and BPF Type Format (BTF) the verifier is finally ready
for the next step in program verification.
Now it can use in-kernel BTF to type check bpf assembly code.
Equivalent program will look like:
struct trace_kfree_skb {
struct sk_buff *skb;
void *location;
};
SEC("raw_tracepoint/kfree_skb")
int trace_kfree_skb(struct trace_kfree_skb* ctx)
{
struct sk_buff *skb = ctx->skb;
struct net_device *dev;
int ifindex;
__builtin_preserve_access_index(({
dev = skb->dev;
ifindex = dev->ifindex;
}));
}
These patches teach bpf verifier to recognize kfree_skb's first argument
as 'struct sk_buff *' because this is what kernel C code is doing.
The bpf program cannot 'cheat' and say that the first argument
to kfree_skb raw_tracepoint is some other type.
The verifier will catch such type mismatch between bpf program
assumption of kernel code and the actual type in the kernel.
Furthermore skb->dev access is type tracked as well.
The verifier can see which field of skb is being read
in bpf assembly. It will match offset to type.
If bpf program has code:
struct net_device *dev = (void *)skb->len;
C compiler will not complain and generate bpf assembly code,
but the verifier will recognize that integer 'len' field
is being accessed at offsetof(struct sk_buff, len) and will reject
further dereference of 'dev' variable because it contains
integer value instead of a pointer.
Such sophisticated type tracking allows calling networking
bpf helpers from tracing programs.
This patchset allows calling bpf_skb_event_output() that dumps
skb data into perf ring buffer.
It greatly improves observability.
Now users can not only see packet lenth of the skb
about to be freed in kfree_skb() kernel function, but can
dump it to user space via perf ring buffer using bpf helper
that was previously available only to TC and socket filters.
See patch 10 for full example.
The end result is safer and faster bpf tracing.
Safer - because type safe direct load can be used most of the time
instead of bpf_probe_read().
Faster - because direct loads are used to walk kernel data structures
instead of bpf_probe_read() calls.
Note that such loads can page fault and are supported by
hidden bpf_probe_read() in interpreter and via exception table
if program is JITed.
====================
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Load basic cls_bpf program.
Load raw_tracepoint program and attach to kfree_skb raw tracepoint.
Trigger cls_bpf via prog_test_run.
At the end of test_run kernel will call kfree_skb
which will trigger trace_kfree_skb tracepoint.
Which will call our raw_tracepoint program.
Which will take that skb and will dump it into perf ring buffer.
Check that user space received correct packet.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-12-ast@kernel.org
Introduce new helper that reuses existing skb perf_event output
implementation, but can be called from raw_tracepoint programs
that receive 'struct sk_buff *' as tracepoint argument or
can walk other kernel data structures to skb pointer.
In order to do that teach verifier to resolve true C types
of bpf helpers into in-kernel BTF ids.
The type of kernel pointer passed by raw tracepoint into bpf
program will be tracked by the verifier all the way until
it's passed into helper function.
For example:
kfree_skb() kernel function calls trace_kfree_skb(skb, loc);
bpf programs receives that skb pointer and may eventually
pass it into bpf_skb_output() bpf helper which in-kernel is
implemented via bpf_skb_event_output() kernel function.
Its first argument in the kernel is 'struct sk_buff *'.
The verifier makes sure that types match all the way.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-11-ast@kernel.org
Pointer to BTF object is a pointer to kernel object or NULL.
Such pointers can only be used by BPF_LDX instructions.
The verifier changed their opcode from LDX|MEM|size
to LDX|PROBE_MEM|size to make JITing easier.
The number of entries in extable is the number of BPF_LDX insns
that access kernel memory via "pointer to BTF type".
Only these load instructions can fault.
Since x86 extable is relative it has to be allocated in the same
memory region as JITed code.
Allocate it prior to last pass of JITing and let the last pass populate it.
Pointer to extable in bpf_prog_aux is necessary to make page fault
handling fast.
Page fault handling is done in two steps:
1. bpf_prog_kallsyms_find() finds BPF program that page faulted.
It's done by walking rb tree.
2. then extable for given bpf program is binary searched.
This process is similar to how page faulting is done for kernel modules.
The exception handler skips over faulting x86 instruction and
initializes destination register with zero. This mimics exact
behavior of bpf_probe_read (when probe_kernel_read faults dest is zeroed).
JITs for other architectures can add support in similar way.
Until then they will reject unknown opcode and fallback to interpreter.
Since extable should be aligned and placed near JITed code
make bpf_jit_binary_alloc() return 4 byte aligned image offset,
so that extable aligning formula in bpf_int_jit_compile() doesn't need
to rely on internal implementation of bpf_jit_binary_alloc().
On x86 gcc defaults to 16-byte alignment for regular kernel functions
due to better performance. JITed code may be aligned to 16 in the future,
but it will use 4 in the meantime.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-10-ast@kernel.org
Pointer to BTF object is a pointer to kernel object or NULL.
The memory access in the interpreter has to be done via probe_kernel_read
to avoid page faults.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-9-ast@kernel.org
BTF type id specified at program load time has all
necessary information to attach that program to raw tracepoint.
Use kernel type name to find raw tracepoint.
Add missing CHECK_ATTR() condition.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-8-ast@kernel.org
libbpf analyzes bpf C program, searches in-kernel BTF for given type name
and stores it into expected_attach_type.
The kernel verifier expects this btf_id to point to something like:
typedef void (*btf_trace_kfree_skb)(void *, struct sk_buff *skb, void *loc);
which represents signature of raw_tracepoint "kfree_skb".
Then btf_ctx_access() matches ctx+0 access in bpf program with 'skb'
and 'ctx+8' access with 'loc' arguments of "kfree_skb" tracepoint.
In first case it passes btf_id of 'struct sk_buff *' back to the verifier core
and 'void *' in second case.
Then the verifier tracks PTR_TO_BTF_ID as any other pointer type.
Like PTR_TO_SOCKET points to 'struct bpf_sock',
PTR_TO_TCP_SOCK points to 'struct bpf_tcp_sock', and so on.
PTR_TO_BTF_ID points to in-kernel structs.
If 1234 is btf_id of 'struct sk_buff' in vmlinux's BTF
then PTR_TO_BTF_ID#1234 points to one of in kernel skbs.
When PTR_TO_BTF_ID#1234 is dereferenced (like r2 = *(u64 *)r1 + 32)
the btf_struct_access() checks which field of 'struct sk_buff' is
at offset 32. Checks that size of access matches type definition
of the field and continues to track the dereferenced type.
If that field was a pointer to 'struct net_device' the r2's type
will be PTR_TO_BTF_ID#456. Where 456 is btf_id of 'struct net_device'
in vmlinux's BTF.
Such verifier analysis prevents "cheating" in BPF C program.
The program cannot cast arbitrary pointer to 'struct sk_buff *'
and access it. C compiler would allow type cast, of course,
but the verifier will notice type mismatch based on BPF assembly
and in-kernel BTF.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-7-ast@kernel.org
It's a responsiblity of bpf program author to annotate the program
with SEC("tp_btf/name") where "name" is a valid raw tracepoint.
The libbpf will try to find "name" in vmlinux BTF and error out
in case vmlinux BTF is not available or "name" is not found.
If "name" is indeed a valid raw tracepoint then in-kernel BTF
will have "btf_trace_##name" typedef that points to function
prototype of that raw tracepoint. BTF description captures
exact argument the kernel C code is passing into raw tracepoint.
The kernel verifier will check the types while loading bpf program.
libbpf keeps BTF type id in expected_attach_type, but since
kernel ignores this attribute for tracing programs copy it
into attach_btf_id attribute before loading.
Later the kernel will use prog->attach_btf_id to select raw tracepoint
during bpf_raw_tracepoint_open syscall command.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-6-ast@kernel.org
Add attach_btf_id attribute to prog_load command.
It's similar to existing expected_attach_type attribute which is
used in several cgroup based program types.
Unfortunately expected_attach_type is ignored for
tracing programs and cannot be reused for new purpose.
Hence introduce attach_btf_id to verify bpf programs against
given in-kernel BTF type id at load time.
It is strictly checked to be valid for raw_tp programs only.
In a later patches it will become:
btf_id == 0 semantics of existing raw_tp progs.
btd_id > 0 raw_tp with BTF and additional type safety.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-5-ast@kernel.org
If in-kernel BTF exists parse it and prepare 'struct btf *btf_vmlinux'
for further use by the verifier.
In-kernel BTF is trusted just like kallsyms and other build artifacts
embedded into vmlinux.
Yet run this BTF image through BTF verifier to make sure
that it is valid and it wasn't mangled during the build.
If in-kernel BTF is incorrect it means either gcc or pahole or kernel
are buggy. In such case disallow loading BPF programs.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-4-ast@kernel.org
When pahole converts dwarf to btf it emits only used types.
Wrap existing bpf helper functions into typedef and use it in
typecast to make gcc emits this type into dwarf.
Then pahole will convert it to btf.
The "btf_#name_of_helper" types will be used to figure out
types of arguments of bpf helpers.
The generated code before and after is the same.
Only dwarf and btf sections are different.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-3-ast@kernel.org
When pahole converts dwarf to btf it emits only used types.
Wrap existing __bpf_trace_##template() function into
btf_trace_##template typedef and use it in type cast to
make gcc emits this type into dwarf. Then pahole will convert it to btf.
The "btf_trace_" prefix will be used to identify BTF enabled raw tracepoints.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191016032505.2089704-2-ast@kernel.org
Add PHY driver for the USB2 PHY found on Marvell MMP3 SoC.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Let's move cputype.h away from mach-mmp/ so that the drivers outside that
directory are able to tell the precise silicon revision. The MMP3 USB OTG
PHY driver needs this.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Similar to MMP2, which this patch is based on. Known differencies from MMP2
are:
* Two PJ4B cores instead of one PJ4
* Tauros 3 L2 cache controller instead of Tauros 2
* A GIC interrupt controller optionally used instead of the MMP one
* A TWD local timer
* Different USB2 PHY
* A USB3 SS controller
* More interrupt muxes
Hard to tell what else is different, because documentation is not
available.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
The MMP2 and later includes a system control unit in this area. We'll need
that to initialize the secondary core on MMP3.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
MMP3 has a PJ4B with a Tauros 3 cache controller that uses CACHE_L2X0
instead, while CACHE_TAUROS2 is present on PJ4 and PJ1 (Mohawk) based
platforms only.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
