| Age | Commit message (Collapse) | Author |
|---|
|
When enabling a range of VLANs on a bridged port we can configure
flooding for these VLANs by one register access instead of calling the
same register for each VLAN. This is accomplished by using the 'range'
field of the Switch Flooding Table Register (SFTR).
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
It is a flag anyway, so move it to existing u8 flag and don't waste mem.
Fix the flags to be in single u8 on the way.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In certain use cases it is not always desirable for the switch device to
flood traffic to CPU port. Instead, only certain packet types (e.g.
STP, LACP) should be trapped to it.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Allow devices supporting this feature to control the flooding of unknown
unicast traffic, by making switchdev infrastructure propagate this setting
to the switch driver.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Iyappan Subramanian says:
====================
drivers: xgene: Add support RGMII TX/RX delay configuration
X-Gene RGMII ethernet controller has a RGMII bridge that performs the
task of converting the RGMII signal {RX_CLK,RX_CTL, RX_DATA[3:0]} from
PHY to GMII signal {RX_DV,RX_ER,RX_DATA[7:0]} and vice versa. This
RGMII bridge has a provision to internally delay the input RX_CLK and
the output TX_CLK using configuration registers. This will help in
maintain the CLK-CTL delay relationship in various operating
conditions.
This patch adds support RGMII TX/RX delay configuration.
====================
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add RGMII TX/RX delay configuration support. RGMII standard requires 2ns
delay to help the RGMII bridge receiver to sample data correctly. If the
default value does not provide proper centering of the data sample, the
TX/RX delay parameters can be used to adjust accordingly.
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
hashtable
Problem Description:
We can add fdbs pointing to the bridge with NULL ->dst but that has a
few race conditions because br_fdb_insert() is used which first creates
the fdb and then, after the fdb has been published/linked, sets
"is_local" to 1 and in that time frame if a packet arrives for that fdb
it may see it as non-local and either do a NULL ptr dereference in
br_forward() or attach the fdb to the port where it arrived, and later
br_fdb_insert() will make it local thus getting a wrong fdb entry.
Call chain br_handle_frame_finish() -> br_forward():
But in br_handle_frame_finish() in order to call br_forward() the dst
should not be local i.e. skb != NULL, whenever the dst is
found to be local skb is set to NULL so we can't forward it,
and here comes the problem since it's running only
with RCU when forwarding packets it can see the entry before "is_local"
is set to 1 and actually try to dereference NULL.
The main issue is that if someone sends a packet to the switch while
it's adding the entry which points to the bridge device, it may
dereference NULL ptr. This is needed now after we can add fdbs
pointing to the bridge. This poses a problem for
br_fdb_update() as well, while someone's adding a bridge fdb, but
before it has is_local == 1, it might get moved to a port if it comes
as a source mac and then it may get its "is_local" set to 1
This patch changes fdb_create to take is_local and is_static as
arguments to set these values in the fdb entry before it is added to the
hash. Also adds null check for port in br_forward.
Fixes: 3741873b4f73 ("bridge: allow adding of fdb entries pointing to the bridge device")
Reported-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Other callers of udp_tunnel6_xmit_skb just pass 0 for the prio
argument. Jesse Gross <jesse@nicira.com> suggested that prio is really
the same as IPv4's tos and should be handled the same, so this is my
interpretation of that suggestion.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported-by: Jesse Gross <jesse@nicira.com>
Reviewed-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
NOTE: Link-local IPv6 addresses for remote endpoints are not supported,
since the driver currently has no capacity for binding a geneve
interface to a specific link.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Extend the pxa2xx_spi_acpi_get_pdata() so that it can create platform data
also on platforms that do not support ACPI or if CONFIG_ACPI is not set.
Now it is expected that "pxa2xx-spi" platform device is either created with
explicit platform data or has an ACPI companion device.
However there is only little in pxa2xx_spi_acpi_get_pdata() that is really
dependent on ACPI companion and it can be reworked to cover also cases
where "pxa2xx-spi" device doesn't have ACPI companion and is created
without platform data.
Do this by renaming the pxa2xx_spi_acpi_get_pdata(), moving it outside of
CONFIG_ACPI test and changing a few runtime tests there to support non-ACPI
case. Only port/bus ID setting based on ACPI _UID is dependent on ACPI and
is moved to own function inside CONFIG_ACPI.
Purpose of this to support non-ACPI case for those PCI enumerated compound
devices that integrate both LPSS SPI host controller and integrated DMA
engine under the same PCI ID and which are registered in MFD layer instead
of in spi-pxa2xx-pci.c.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
LPSS SPI in Intel Broxton is otherwise the same than in Intel Sunrisepoint
but it supports up to four chip selects per port and has different FIFO
thresholds. Patch adds support for two Broxton SoC variants.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
SPI capabilities register located in private registers space of newer
Intel LPSS SPI host controllers tell in register bits 12:9 which chip
select signals are enabled.
Use that information for detecting the number of chip selects. For
simplicity we assume chip selects are enabled one after another without
disabled chip selects between. For instance CS0 | CS1 | CS2 but not
CS0 | CS1 | CS3.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Intel LPSS SPI host controllers in upcoming Intel platforms can have up
to 4 chip selects per port. Extend chip select control in
lpss_ssp_cs_control() by adding a code that selects the active chip
select output prior to changing the state. Detection for number of
enabled chip select signals will be added by another patch.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Rename a few defines that are specific to Intel LPSS SPI private
registers with LPSS prefix. It makes easier to distinguish them from
common defines.
Suggested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Commit bfebd1cdb497a57757c83f5fbf1a29931591e2a4 ("dm: add full blk-mq
support to request-based DM") moves the initialization of the fields
backing_dev_info.congested_fn, backing_dev_info.congested_data and
queuedata from the function dm_init_md_queue (that is called when the
device is created) to dm_init_old_md_queue (that is called after the
device type is determined).
There is no locking when accessing these variables, thus it is possible
for other parts of the kernel to briefly see this data in a transient
state (e.g. queue->backing_dev_info.congested_fn initialized and
md->queue->backing_dev_info.congested_data uninitialized, resulting in
passing an incorrect parameter to the function dm_any_congested).
This queue data is left initialized for blk-mq devices even though they
that don't use it.
Fixes: bfebd1cdb497 ("dm: add full blk-mq support to request-based DM")
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # v4.1+
|
|
LS1043a and LS2080A in the Layerscape family also support DSPI, make
DSPI selectable for these hardwares.
Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
there's no need to call pm_runtime_get_sync()
followed by pm_runtime_put(). We should, instead,
just call pm_runtime_put_sync() and pm_runtime_disable().
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
Few more drm-misc stragglers for 4.4. Big thing is the generic probe for
imx/rockchip/armada (but the variant for msm/rpi/exynos is still missing).
Also the hdmi clocking fixes from Ville which was a lot of confusion about
which tree it should be applied to ;-)
* tag 'topic/drm-misc-2015-10-22' of git://anongit.freedesktop.org/drm-intel:
drm: correctly check failed allocation
vga_switcheroo: Constify vga_switcheroo_handler
drm/armada: Convert the probe function to the generic drm_of_component_probe()
drm/rockchip: Convert the probe function to the generic drm_of_component_probe()
drm/imx: Convert the probe function to the generic drm_of_component_probe()
drm: Introduce generic probe function for component based masters.
drm/edid: Round to closest when computing the CEA/HDMI alternate clock
drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings
|
|
into drm-next
More amdgpu and radeon stuff for drm-next. Stoney support is the big change.
The rest is just bug fixes and code cleanups. The Stoney stuff is pretty
low impact with respect to existing chips.
* 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: change VM size default to 64GB
drm/amdgpu: add Stoney pci ids
drm/amdgpu: update the core VI support for Stoney
drm/amdgpu: add VCE support for Stoney (v2)
drm/amdgpu: add UVD support for Stoney
drm/amdgpu: add GFX support for Stoney (v2)
drm/amdgpu: add SDMA support for Stoney (v2)
drm/amdgpu: add DCE support for Stoney
drm/amdgpu: Update SMC/DPM for Stoney
drm/amdgpu: add GMC support for Stoney
drm/amdgpu: add Stoney chip family
drm/amdgpu: fix the broken vm->mutex V2
drm/amdgpu: remove the unnecessary parameter adev for amdgpu_fence_wait_any()
drm/amdgpu: remove the exclusive lock
drm/amdgpu: remove old lockup detection infrastructure
drm: fix trivial typos
drm/amdgpu/dce: simplify suspend/resume
drm/amdgpu/gfx8: set TC_WB_ACTION_EN in RELEASE_MEM packet
drm/radeon: Use rdev->gem.mutex to protect hyperz/cmask owners
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work
from Ville in here since it's low-risk but lots of churn all over.
* tag 'drm-intel-next-fixes-2015-10-22' of git://anongit.freedesktop.org/drm-intel: (23 commits)
drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks
drm/i915: Kill the leftover RMW from ivb_sprite_disable()
drm/i915: restore ggtt double-bind avoidance
drm/i915/skl: Enable pipe gamma for sprite planes.
drm/i915/skl+: Enable pipe CSC on cursor planes. (v2)
MAINTAINERS: add link to the Intel Graphics for Linux web site
drm/i915: Move skl/bxt gt specific workarounds to ring init
drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
drm/i915: revert a few more watermark commits
drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE
drm/i915: Clean up LVDS register handling
drm/i915: Throw out some useless variables
drm/i915: Parametrize and fix SWF registers
drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.
drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function
drm/i915: Fix a few bad hex numbers in register defines
drm/i915: Protect register macro arguments
drm/i915: Include gpio_mmio_base in GMBUS reg defines
drm/i915: Parametrize HSW video DIP data registers
drm/i915: Eliminate weird parameter inversion from BXT PPS registers
...
|
|
into drm-fixes
regression fix for backlight on old laptops.
* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix dpms when driver backlight control is disabled
drm/radeon: move bl encoder assignment into bl init
|
|
David reported that a T5-8 sparc system failed to boot with:
pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff])
pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff])
pci 0000:00:01.0: can't claim BAR 15 [mem 0x100000000-0x4afffffff pref]: no compatible bridge window
Note that we don't know about a host bridge aperture that contains
BAR 15. OF does report a MEM64 aperture, but before this patch,
pci_determine_mem_io_space() ignored it.
Add support for host bridge apertures with 64-bit PCI addresses. Also
set IORESOURCE_MEM_64 for PCI device and bridge resources in PCI 64-bit
memory space.
Sparc doesn't actually print the device and bridge resources, but after
this patch, we should have the equivalent of this:
pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff])
pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff])
pci_bus 0000:00: root bus resource [mem 0x800100000000-0x8007ffffffff] (bus address [0x100000000-0x7ffffffff])
pci 0000:00:01.0: bridge window [mem 0x800100000000-0x8004afffffff 64bit pref]
[bhelgaas: changelog, URL to David's report]
Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Link: http://lkml.kernel.org/r/5514391F.2030300@oracle.com
Reported-by: David Ahern <david.ahern@oracle.com>
Tested-by: David Ahern <david.ahern@oracle.com>
Tested-by: Khalid Aziz <khalid.aziz@oracle.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
An Enhanced Allocation Capability entry with BEI 0 fills in
dev->resource[0] just like a real BAR 0 would, but non-EA experts might not
connect "EA - BEI 0" with BAR 0.
Decode the EA jargon a little bit, e.g., change this:
pci 0002:01:00.0: EA - BEI 0, Prop 0x00: [mem 0x84300000-0x84303fff]
to this:
pci 0002:01:00.0: BAR 0: [mem 0x84300000-0x84303fff] (from Enhanced Allocation, properties 0x00)
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Expand bitmask #defines completely. This puts the shift in the code
instead of in the #define, but it makes it more obvious in the header file
how fields in the register are laid out.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
SR-IOV BARs can be specified via EA entries. Extend the EA parser to
extract the SRIOV BAR resources, and modify sriov_init() to use resources
previously obtained via EA.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Sean O. Stalley <sean.stalley@intel.com>
|
|
Add support for devices using Enhanced Allocation entries instead of BARs.
This allows the kernel to parse the EA Extended Capability structure in PCI
config space and claim the BAR-equivalent resources.
See https://pcisig.com/sites/default/files/specification_documents/ECN_Enhanced_Allocation_23_Oct_2014_Final.pdf
[bhelgaas: add spec URL, s/pci_ea_set_flags/pci_ea_flags/, consolidate
declarations, print unknown property in hex to match spec]
Signed-off-by: Sean O. Stalley <sean.stalley@intel.com>
[david.daney@cavium.com: Add more support/checking for Entry Properties,
allow EA behind bridges, rewrite some error messages.]
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Add registers defined in PCI-SIG's Enhanced allocation ECN.
[bhelgaas: s/WRITEABLE/WRITABLE]
Signed-off-by: Sean O. Stalley <sean.stalley@intel.com>
[david.daney@cavium.com: Added more definitions for PCI_EA_BEI_*]
Signed-off-by: Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The new Enhanced Allocation (EA) capability support (patches to follow)
creates resources with the IORESOURCE_PCI_FIXED set. During resource
assignment in pci_bus_assign_resources(), IORESOURCE_PCI_FIXED resources
are not given a parent. This, in turn, causes pci_enable_resources() to
fail with a "not claimed" error.
So, in __pci_bus_assign_resources(), for IORESOURCE_PCI_FIXED resources,
try to request the resource from a parent bus.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Sean O. Stalley <sean.stalley@intel.com>
|
|
The new Enhanced Allocation (EA) capability support (patches to follow)
creates resources with the IORESOURCE_PCI_FIXED set. Since these resources
cannot be relocated or resized, their alignment is not really defined, and
it is therefore not specified. This causes a problem in pbus_size_mem()
where resources with unspecified alignment are disabled.
So, in pbus_size_mem() skip IORESOURCE_PCI_FIXED resources, instead of
disabling them.
[bhelgaas: folded in "flags & IORESOURCE_PCI_FIXED" fix from David]
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Sean O. Stalley <sean.stalley@intel.com>
|
|
The return value should be checked for non-zero, instead
of checking it being IS_ERR_VALUE().
Acked-by: Alan Tull <atull@opensource.altera.com>
Reviewed-by: Josh Cartwright <joshc@eso.teric.us>
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Previously, we read, validated, and cached PCI_SRIOV_VF_OFFSET and
PCI_SRIOV_VF_STRIDE in sriov_enable(). But sriov_init() now does
that via compute_max_vf_buses(), so we don't need to do it again.
Remove the PCI_SRIOV_VF_OFFSET and PCI_SRIOV_VF_STRIDE config reads from
sriov_enable(). The pci_sriov structure already contains the offset and
stride corresponding to the current NumVFs.
[bhelgaas: split to separate patch for reviewability]
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Wei Yang <weiyang@linux.vnet.ibm.com>
|
|
The enumeration path should leave NumVFs set to zero. But after
4449f079722c ("PCI: Calculate maximum number of buses required for VFs"),
we call virtfn_max_buses() in the enumeration path, which changes NumVFs.
This NumVFs change is visible via lspci and sysfs until a driver enables
SR-IOV.
Iterate from TotalVFs down to zero so NumVFs is zero when we're finished
computing the maximum number of buses. Validate offset and stride in
the loop, so we can test it at every possible NumVFs setting. Rename
virtfn_max_buses() to compute_max_vf_buses() to hint that it does have a
side effect of updating iov->max_VF_buses.
[bhelgaas: changelog, rename, allow numVF==1 && stride==0, rework loop,
reverse sense of error path]
Fixes: 4449f079722c ("PCI: Calculate maximum number of buses required for VFs")
Based-on-patch-by: Ethan Zhao <ethan.zhao@oracle.com>
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
For some SR-IOV devices, the number of available virtual functions, i.e.,
TotalVFs, increases after setting the ARI Capable Hierarchy bit in the
SR-IOV Control register. This violates the SR-IOV spec, r1.1, sec 3.3.6,
which says TotalVFs is HwInit, but we don't need TotalVFs before setting
the ARI Capable bit anyway.
Set the ARI Capable Hierarchy bit (if ARI is enabled in the upstream
bridge) before reading TotalVFs.
[bhelgaas: changelog]
Signed-off-by: Ben Shelton <benjamin.h.shelton@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Even if --symfs is used to point to the debug binaries, we send in the
non-debug filenames to libunwind, which leads to libunwind not finding
the debug frame. Fix this by preferring the file in --symfs, if it is
available.
Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rabin Vincent <rabinv@axis.com>
Link: http://lkml.kernel.org/r/1446104978-26429-1-git-send-email-rabin.vincent@axis.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Any CFLAGS or LDFLAGS set by the user need to be passed to the feature
build command. This many include for example -I or -L to point to
libraries and include files in custom paths.
In most of the test-*.bin rules in build/feature/Makefile, we use the BUILD
macro which always sends in CFLAGS and LDFLAGS. The libiberty build line
however doesn't use the BUILD macro and thus needs to send in CFLAGS and
LDFLAGS explicitly. Without this, when using custom CFLAGS/LDFLAGS, libiberty
fails to be detected and the perf link fails with something like:
LINK perf
libbfd.a(bfd.o): In function `bfd_errmsg':
bfd.c:(.text+0x168): undefined reference to `xstrerror'
bbfd.a(opncls.o): In function `_bfd_new_bfd':
opncls.c:(.text+0xe8): undefined reference to `objalloc_create'
...
Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rabin Vincent <rabinv@axis.com>
Link: http://lkml.kernel.org/r/1446104978-26429-2-git-send-email-rabin.vincent@axis.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
This is really about simplifying the double xchg patterns into
a single cmpxchg, with the same logic. Other than the immediate
cleanup, there are some subtleties this change deals with:
(i) While the load of the old bt is fully ordered wrt everything,
ie:
old_bt = xchg(&q->blk_trace, bt); [barrier]
if (old_bt)
(void) xchg(&q->blk_trace, old_bt); [barrier]
blk_trace could still be changed between the xchg and the old_bt
load. Note that this description is merely theoretical and afaict
very small, but doing everything in a single context with cmpxchg
closes this potential race.
(ii) Ordering guarantees are obviously kept with cmpxchg.
(iii) Gets rid of the hacky-by-nature (void)xchg pattern.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
eviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
This patch provides infrastructure for passing source files to --event
directly using:
# perf record --event bpf-file.c command
This patch does following works:
1) Allow passing '.c' file to '--event'. parse_events_load_bpf() is
expanded to allow caller tell it whether the passed file is source
file or object.
2) llvm__compile_bpf() is called to compile the '.c' file, the result
is saved into memory. Use bpf_object__open_buffer() to load the
in-memory object.
Introduces a bpf-script-example.c so we can manually test it:
# perf record --clang-opt "-DLINUX_VERSION_CODE=0x40200" --event ./bpf-script-example.c sleep 1
Note that '--clang-opt' must put before '--event'.
Futher patches will merge it into a testcase so can be tested automatically.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kaixu Xia <xiakaixu@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1444826502-49291-10-git-send-email-wangnan0@huawei.com
Signed-off-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Although previous patch allows setting BPF compiler related options in
perfconfig, on some ad-hoc situation it still requires passing options
through cmdline. This patch introduces 2 options to 'perf record' for
this propose: --clang-path and --clang-opt.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kaixu Xia <xiakaixu@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1444826502-49291-9-git-send-email-wangnan0@huawei.com
[ Add the new options to the 'record' man page ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
This is the final patch which makes basic BPF filter work. After
applying this patch, users are allowed to use BPF filter like:
# perf record --event ./hello_world.o ls
A bpf_fd field is appended to 'struct evsel', and setup during the
callback function add_bpf_event() for each 'probe_trace_event'.
PERF_EVENT_IOC_SET_BPF ioctl is used to attach eBPF program to a newly
created perf event. The file descriptor of the eBPF program is passed to
perf record using previous patches, and stored into evsel->bpf_fd.
It is possible that different perf event are created for one kprobe
events for different CPUs. In this case, when trying to call the ioctl,
EEXIST will be return. This patch doesn't treat it as an error.
Committer note:
The bpf proggie used so far:
__attribute__((section("fork=_do_fork"), used))
int fork(void *ctx)
{
return 0;
}
char _license[] __attribute__((section("license"), used)) = "GPL";
int _version __attribute__((section("version"), used)) = 0x40300;
failed to produce any samples, even with forks happening and it being
running in system wide mode.
That is because now the filter is being associated, and the code above
always returns zero, meaning that all forks will be probed but filtered
away ;-/
Change it to 'return 1;' instead and after that:
# trace --no-syscalls --event /tmp/foo.o
0.000 perf_bpf_probe:fork:(ffffffff8109be30))
2.333 perf_bpf_probe:fork:(ffffffff8109be30))
3.725 perf_bpf_probe:fork:(ffffffff8109be30))
4.550 perf_bpf_probe:fork:(ffffffff8109be30))
^C#
And it works with all tools, including 'perf trace'.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kaixu Xia <xiakaixu@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1444826502-49291-8-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
While doing 'make -C tools/perf build-test':
LD fixdep-in.o
LINK fixdep
/bin/sh: /home/acme/git/linux/tools/build/fixdep: Permission denied
make[6]: *** [bpf.o] Error 1
make[5]: *** [libbpf-in.o] Error 2
make[4]: *** [/home/acme/git/linux/tools/lib/bpf/libbpf.a] Error 2
make[4]: *** Waiting for unfinished jobs....
The fixdep tool needs to be built as the first binary. Libraries are
built in paralel, so each of them needs to depend on fixdep target.
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20151028204450.GA25553@krava.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
This patch improves perf script by enabling printing of the
branch stack via the 'brstack' and 'brstacksym' arguments to
the field selection option -F. The option is off by default
and operates only if the perf.data file has branch stack content.
The branches are printed in to/from pairs. The most recent branch
is printed first. The number of branch entries vary based on the
underlying hardware and filtering used.
The brstack prints FROM/TO addresses in raw hexadecimal format.
The brstacksym prints FROM/TO addresses in symbolic form wherever
possible.
$ perf script -F ip,brstack
5d3000 0x401aa0/0x5d2000/M/-/-/-/0 ...
$ perf script -F ip,brstacksym
4011e0 noploop+0x0/noploop+0x0/P/-/-/0
The notation F/T/M/X/A/C describes the attributes of the branch.
F=from, T=to, M/P=misprediction/prediction, X=TSX, A=TSX abort, C=cycles (SKL)
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yuanfang Chen <cyfmxc@gmail.com>
Link: http://lkml.kernel.org/r/1441039273-16260-5-git-send-email-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
As new_valid_dev always returns 1, so !new_valid_dev check is not
needed, remove it.
Signed-off-by: Yaowei Bai <bywxiaobai@163.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
Commit e66cf161 replaced the gl_spin spinlock in struct gfs2_glock with a
gl_lockref lockref and defined gl_spin as gl_lockref.lock (the spinlock in
gl_lockref). Remove that define to make the references to gl_lockref.lock more
obvious.
Signed-off-by: Andreas Gruenbacher <andreas.gruenbacher@gmail.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
|
|
A kernel built with DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA doesn't
have .text aligned to a page boundary, though fixup_executable works at
page-granularity thanks to its use of create_mapping. If .text is not
page-aligned, the first page it exists in may be marked non-executable,
leading to failures when an attempt is made to execute code in said
page.
This patch upgrades ALIGN_DEBUG_RO and ALIGN_DEBUG_RO_MIN to force page
alignment for DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA kernels,
ensuring that all sections with specific RWX permission requirements are
mapped with the correct permissions.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Laura Abbott <laura@labbott.name>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Fixes: da141706aea52c1a ("arm64: add better page protections to arm64")
Cc: <stable@vger.kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
Trying to build with CONFIG_ZONE_DMA=n leaves visible references
to the now-undefined ZONE_DMA, resulting in a syntax error.
Hide the references behind an #ifdef instead of using IS_ENABLED.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
For reasons not entirely apparent, but now enshrined in history, the
architectural mapping of AArch32 banked registers to AArch64 registers
actually orders SP_<mode> and LR_<mode> backwards compared to the
intuitive r13/r14 order, for all modes except FIQ.
Fix the compat_<reg>_<mode> macros accordingly, in the hope of avoiding
subtle bugs with KVM and AArch32 guests.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The current arm64 Image relocation code in the UEFI stub assumes that
the dram_base argument it receives is always a multiple of 2 MB. In
reality, it is simply the lowest start address of all RAM entries in
the UEFI memory map, which means it could be any multiple of 4 KB.
Since the arm64 kernel Image needs to reside TEXT_OFFSET bytes beyond
a 2 MB aligned base, or it will fail to boot, make sure we round dram_base
to 2 MB before using it to calculate the relocation address.
Fixes: e38457c361b30c5a ("arm64: efi: prefer AllocatePages() over efi_low_alloc() for vmlinux")
Reported-by: Timur Tabi <timur@codeaurora.org>
Tested-by: Timur Tabi <timur@codeaurora.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
No callers and no providers left, go ahead and remove it.
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
