| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This splat reminds us:
[ 8166.045595] [ INFO: suspicious RCU usage. ]
[ 8166.168972] [<ffffffff81127837>] lockdep_rcu_suspicious+0xe7/0x120
[ 8166.175966] [<ffffffff811e0bae>] perf_callchain+0x23e/0x250
[ 8166.182280] [<ffffffff811dda3d>] perf_prepare_sample+0x27d/0x350
[ 8166.189082] [<ffffffff8100f503>] intel_pmu_drain_bts_buffer+0x133/0x200
... that as the core code does, one should hold rcu_read_lock() over that
entire BTS event-output generation sequence as well.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
There were two problems with the dynamic interrupt throttle mechanism,
both triggered by the same action.
When you (or perf_fuzzer) write a huge value into
/proc/sys/kernel/perf_event_max_sample_rate the computed
perf_sample_allowed_ns becomes 0. This effectively disables the whole
dynamic throttle.
This is fixed by ensuring update_perf_cpu_limits() never sets the
value to 0. However, we allow disabling of the dynamic throttle by
writing 100 to /proc/sys/kernel/perf_cpu_time_max_percent. This will
generate a warning in dmesg.
The second problem is that by setting the max_sample_rate to a huge
number, the adaptive process can take a few tries, since it halfs the
limit each time. Change that to directly compute a new value based on
the observed duration.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Interrupt throttling is normally only done against
sysctl_perf_event_sample_rate. This means that if that number is too
high (for whatever reason) you can lock up your machine.
We have, however, a dynamic throttling scheme too, but for that to
work, we need to add a callback to the interrupt handler, IBS did not
have this, so add it.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
While tracing the IBS bits I saw the NMI hitting between clearing
IBS_STARTING and the actual MSR writes to disable the counter.
Since IBS_STARTING was cleared, the handler assumed these were spurious
NMIs and because STOPPING wasn't set yet either, insta-triggered an
"Unknown NMI".
Cure this by clearing IBS_STARTING after disabling the hardware.
Tested-by: Borislav Petkov <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
When the IBS IRQ handler get a !0 return from perf_event_overflow;
meaning it should throttle the event, it only disables it, it doesn't
call perf_ibs_stop().
This confuses the state machine, as we'll use pmu::start() ->
perf_ibs_start() to unthrottle.
Tested-by: Borislav Petkov <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Its possible to IOC_PERIOD while the event is throttled, this would
re-start the event and the next tick would then try to unthrottle it,
and find the event wasn't actually stopped anymore.
This would tickle a WARN in the x86-pmu code which isn't expecting to
start a !stopped event.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Alexander Shishkin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Signed-off-by: Stephen Rothwell <[email protected]>
Reviewed-by: Christian König <[email protected].
Signed-off-by: Dave Airlie <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 protection key support from Ingo Molnar:
"This tree adds support for a new memory protection hardware feature
that is available in upcoming Intel CPUs: 'protection keys' (pkeys).
There's a background article at LWN.net:
https://lwn.net/Articles/643797/
The gist is that protection keys allow the encoding of
user-controllable permission masks in the pte. So instead of having a
fixed protection mask in the pte (which needs a system call to change
and works on a per page basis), the user can map a (handful of)
protection mask variants and can change the masks runtime relatively
cheaply, without having to change every single page in the affected
virtual memory range.
This allows the dynamic switching of the protection bits of large
amounts of virtual memory, via user-space instructions. It also
allows more precise control of MMU permission bits: for example the
executable bit is separate from the read bit (see more about that
below).
This tree adds the MM infrastructure and low level x86 glue needed for
that, plus it adds a high level API to make use of protection keys -
if a user-space application calls:
mmap(..., PROT_EXEC);
or
mprotect(ptr, sz, PROT_EXEC);
(note PROT_EXEC-only, without PROT_READ/WRITE), the kernel will notice
this special case, and will set a special protection key on this
memory range. It also sets the appropriate bits in the Protection
Keys User Rights (PKRU) register so that the memory becomes unreadable
and unwritable.
So using protection keys the kernel is able to implement 'true'
PROT_EXEC on x86 CPUs: without protection keys PROT_EXEC implies
PROT_READ as well. Unreadable executable mappings have security
advantages: they cannot be read via information leaks to figure out
ASLR details, nor can they be scanned for ROP gadgets - and they
cannot be used by exploits for data purposes either.
We know about no user-space code that relies on pure PROT_EXEC
mappings today, but binary loaders could start making use of this new
feature to map binaries and libraries in a more secure fashion.
There is other pending pkeys work that offers more high level system
call APIs to manage protection keys - but those are not part of this
pull request.
Right now there's a Kconfig that controls this feature
(CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS) that is default enabled
(like most x86 CPU feature enablement code that has no runtime
overhead), but it's not user-configurable at the moment. If there's
any serious problem with this then we can make it configurable and/or
flip the default"
* 'mm-pkeys-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (38 commits)
x86/mm/pkeys: Fix mismerge of protection keys CPUID bits
mm/pkeys: Fix siginfo ABI breakage caused by new u64 field
x86/mm/pkeys: Fix access_error() denial of writes to write-only VMA
mm/core, x86/mm/pkeys: Add execute-only protection keys support
x86/mm/pkeys: Create an x86 arch_calc_vm_prot_bits() for VMA flags
x86/mm/pkeys: Allow kernel to modify user pkey rights register
x86/fpu: Allow setting of XSAVE state
x86/mm: Factor out LDT init from context init
mm/core, x86/mm/pkeys: Add arch_validate_pkey()
mm/core, arch, powerpc: Pass a protection key in to calc_vm_flag_bits()
x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU
x86/mm/pkeys: Add Kconfig prompt to existing config option
x86/mm/pkeys: Dump pkey from VMA in /proc/pid/smaps
x86/mm/pkeys: Dump PKRU with other kernel registers
mm/core, x86/mm/pkeys: Differentiate instruction fetches
x86/mm/pkeys: Optimize fault handling in access_error()
mm/core: Do not enforce PKEY permissions on remote mm access
um, pkeys: Add UML arch_*_access_permitted() methods
mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys
x86/mm/gup: Simplify get_user_pages() PTE bit handling
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull EFI updates from Ingo Molnar:
"The main changes are:
- Use separate EFI page tables when executing EFI firmware code.
This isolates the EFI context from the rest of the kernel, which
has security and general robustness advantages. (Matt Fleming)
- Run regular UEFI firmware with interrupts enabled. This is already
the status quo under other OSs. (Ard Biesheuvel)
- Various x86 EFI enhancements, such as the use of non-executable
attributes for EFI memory mappings. (Sai Praneeth Prakhya)
- Various arm64 UEFI enhancements. (Ard Biesheuvel)
- ... various fixes and cleanups.
The separate EFI page tables feature got delayed twice already,
because it's an intrusive change and we didn't feel confident about
it - third time's the charm we hope!"
* 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (37 commits)
x86/mm/pat: Fix boot crash when 1GB pages are not supported by the CPU
x86/efi: Only map kernel text for EFI mixed mode
x86/efi: Map EFI_MEMORY_{XP,RO} memory region bits to EFI page tables
x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd()
efi/arm*: Perform hardware compatibility check
efi/arm64: Check for h/w support before booting a >4 KB granular kernel
efi/arm: Check for LPAE support before booting a LPAE kernel
efi/arm-init: Use read-only early mappings
efi/efistub: Prevent __init annotations from being used
arm64/vmlinux.lds.S: Handle .init.rodata.xxx and .init.bss sections
efi/arm64: Drop __init annotation from handle_kernel_image()
x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings
efi/runtime-wrappers: Run UEFI Runtime Services with interrupts enabled
efi: Reformat GUID tables to follow the format in UEFI spec
efi: Add Persistent Memory type name
efi: Add NV memory attribute
x86/efi: Show actual ending addresses in efi_print_memmap
x86/efi/bgrt: Don't ignore the BGRT if the 'valid' bit is 0
efivars: Use to_efivar_entry
efi: Runtime-wrapper: Get rid of the rtc_lock spinlock
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull 'objtool' stack frame validation from Ingo Molnar:
"This tree adds a new kernel build-time object file validation feature
(ONFIG_STACK_VALIDATION=y): kernel stack frame correctness validation.
It was written by and is maintained by Josh Poimboeuf.
The motivation: there's a category of hard to find kernel bugs, most
of them in assembly code (but also occasionally in C code), that
degrades the quality of kernel stack dumps/backtraces. These bugs are
hard to detect at the source code level. Such bugs result in
incorrect/incomplete backtraces most of time - but can also in some
rare cases result in crashes or other undefined behavior.
The build time correctness checking is done via the new 'objtool'
user-space utility that was written for this purpose and which is
hosted in the kernel repository in tools/objtool/. The tool's (very
simple) UI and source code design is shaped after Git and perf and
shares quite a bit of infrastructure with tools/perf (which tooling
infrastructure sharing effort got merged via perf and is already
upstream). Objtool follows the well-known kernel coding style.
Objtool does not try to check .c or .S files, it instead analyzes the
resulting .o generated machine code from first principles: it decodes
the instruction stream and interprets it. (Right now objtool supports
the x86-64 architecture.)
From tools/objtool/Documentation/stack-validation.txt:
"The kernel CONFIG_STACK_VALIDATION option enables a host tool named
objtool which runs at compile time. It has a "check" subcommand
which analyzes every .o file and ensures the validity of its stack
metadata. It enforces a set of rules on asm code and C inline
assembly code so that stack traces can be reliable.
Currently it only checks frame pointer usage, but there are plans to
add CFI validation for C files and CFI generation for asm files.
For each function, it recursively follows all possible code paths
and validates the correct frame pointer state at each instruction.
It also follows code paths involving special sections, like
.altinstructions, __jump_table, and __ex_table, which can add
alternative execution paths to a given instruction (or set of
instructions). Similarly, it knows how to follow switch statements,
for which gcc sometimes uses jump tables."
When this new kernel option is enabled (it's disabled by default), the
tool, if it finds any suspicious assembly code pattern, outputs
warnings in compiler warning format:
warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch
warning: objtool: cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup
warning: objtool:__schedule()+0x3c0: duplicate frame pointer save
warning: objtool:__schedule()+0x3fd: sibling call from callable instruction with changed frame pointer
... so that scripts that pick up compiler warnings will notice them.
All known warnings triggered by the tool are fixed by the tree, most
of the commits in fact prepare the kernel to be warning-free. Most of
them are bugfixes or cleanups that stand on their own, but there are
also some annotations of 'special' stack frames for justified cases
such entries to JIT-ed code (BPF) or really special boot time code.
There are two other long-term motivations behind this tool as well:
- To improve the quality and reliability of kernel stack frames, so
that they can be used for optimized live patching.
- To create independent infrastructure to check the correctness of
CFI stack frames at build time. CFI debuginfo is notoriously
unreliable and we cannot use it in the kernel as-is without extra
checking done both on the kernel side and on the build side.
The quality of kernel stack frames matters to debuggability as well,
so IMO we can merge this without having to consider the live patching
or CFI debuginfo angle"
* 'core-objtool-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (52 commits)
objtool: Only print one warning per function
objtool: Add several performance improvements
tools: Copy hashtable.h into tools directory
objtool: Fix false positive warnings for functions with multiple switch statements
objtool: Rename some variables and functions
objtool: Remove superflous INIT_LIST_HEAD
objtool: Add helper macros for traversing instructions
objtool: Fix false positive warnings related to sibling calls
objtool: Compile with debugging symbols
objtool: Detect infinite recursion
objtool: Prevent infinite recursion in noreturn detection
objtool: Detect and warn if libelf is missing and don't break the build
tools: Support relative directory path for 'O='
objtool: Support CROSS_COMPILE
x86/asm/decoder: Use explicitly signed chars
objtool: Enable stack metadata validation on 64-bit x86
objtool: Add CONFIG_STACK_VALIDATION option
objtool: Add tool to perform compile-time stack metadata validation
x86/kprobes: Mark kretprobe_trampoline() stack frame as non-standard
sched: Always inline context_switch()
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver updates from Arnd Bergmann:
"Driver updates for ARM SoCs, these contain various things that touch
the drivers/ directory but got merged through arm-soc for practical
reasons:
- Rockchip rk3368 gains power domain support
- Small updates for the ARM spmi driver
- The Atmel PMC driver saw a larger rework, touching both
arch/arm/mach-at91 and drivers/clk/at91
- All reset controller driver changes alway get merged through
arm-soc, though this time the largest change is the addition of a
MIPS pistachio reset driver
- One bugfix for the NXP (formerly Freescale) i.MX weim bus driver"
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (43 commits)
bus: imx-weim: Take the 'status' property value into account
clk: at91: remove useless includes
clk: at91: pmc: remove useless capacities handling
clk: at91: pmc: drop at91_pmc_base
usb: gadget: atmel: access the PMC using regmap
ARM: at91: remove useless includes and function prototypes
ARM: at91: pm: move idle functions to pm.c
ARM: at91: pm: find and remap the pmc
ARM: at91: pm: simply call at91_pm_init
clk: at91: pmc: move pmc structures to C file
clk: at91: pmc: merge at91_pmc_init in atmel_pmc_probe
clk: at91: remove IRQ handling and use polling
clk: at91: make use of syscon/regmap internally
clk: at91: make use of syscon to share PMC registers in several drivers
hwmon: (scpi) add energy meter support
firmware: arm_scpi: add support for 64-bit sensor values
firmware: arm_scpi: decrease Tx timeout to 20ms
firmware: arm_scpi: fix send_message and sensor_get_value for big-endian
reset: sti: Make reset_control_ops const
reset: zynq: Make reset_control_ops const
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC defconfig updates from Arnd Bergmann:
"As usual, a bunch of commits, mostly adding drivers and other options
to defconfigs.
The realview_smp_defconfig and realview_defconfig got merged into one,
so we are now down to 110 files.
For stm32, we have now added a Kconfig fragment, the first such file
on arch/arm. The purpose here is to have a shared defconfig file that
works for all boards, while the DRAM offset has to be hardwired on
NOMMU machines at compile time.
The Exynos defconfig changes depend on changes in the RTC tree, so
this is pulled in here, but has already been merged into 4.6 now"
* tag 'armsoc-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (45 commits)
ARM: imx_v4_v5_defconfig: Enable initramfs support
ARM: imx_v4_v5_defconfig: Cleanup imx_v4_v5_defconfig
ARM: multi_v7_defconfig: Enable LP872x regulator support
ARM: omap2plus_defconfig: Enable LP872x regulator support
ARM: mxs_defconfig: Enable initramfs support
ARM: mxs_defconfig: Cleanup mxs_defconfig
ARM: multi_v5_defconfig: Enable initramfs support
ARM: multi_v5_defconfig: Cleanup multi_v5_defconfig
ARM: multi_v7_defconfig: enable useful configurations for Vybrid
ARM: multi_v7_defconfig: add MACH_ARTPEC6
ARM: omap2plus_defconfig: Enable AT24 eeprom
ARM: omap2plus_defconfig: Enable TI TVP5150 video decoder support
ARM: omap2plus_defconfig: Enable ISP support and dependencies
ARM: omap2plus_defconfig: Enable OMAP IOMMU support
ARM: socfpga_defconfig: enable support for initramfs/initrd support
ARM: at91/defconfig: add sama5d2 adc support in sama5_defconfig
ARM: multi_v7_defconfig: Enable BCM283x
ARM: bcm2835_defconfig: Enable RPi power domain driver
ARM: bcm2835_defconfig: Enable RPi firmware driver
ARM: bcm2835_defconfig: enable ARMv7 support
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM 64-bit DT updates from Arnd Bergmann:
"The arm64 device tree changes make up an increasing portion of the
overall changes, so they are kept separate from the 32-bit devicetree
changes and from the other arm64 updates.
Newly added SoCs and boards are:
- 96Boards Husky board
- AMD Overdrive board
- Amlogic S905 SoC and related Tronsmart boxes
- Annapurna Labs Alpine family and development board
- Broadcom Vulcan servers
- Broadcom Northstar 2 SoC
- Marvell Armada 3700 family and development board
- Qualcomm MSM8996 SoC
Additional devices are enabled for existing platforms from Applied
Micro, Hisilicon, Mediatek, Qualcomm, and Renesas and there are a
couple of other updates for Rockchip, Xilinx and NXP/Freescale"
* tag 'armsoc-dt64' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (102 commits)
ARM64: dts: amlogic: Add Tronsmart Vega S95 configs
Documentation: devicetree: amlogic: Document Tronsmart Vega S95 boards
ARM64: dts: Prepare configs for Amlogic Meson GXBaby
Documentation: devicetree: amlogic: Document Meson GXBaby
devicetree: bindings: Add vendor prefix for Tronsmart
arm64: dts: qcom: Fix MPP's function used for LED control
arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi
arm64: dts: add the Alpine v2 EVP
arm64: dts: marvell: re-order Device Tree nodes for Armada AP806
arm64: dts: marvell: update Armada AP806 clock description
arm64: dts: marvell: add Device Tree files for Armada 7K/8K
arm64: dts: apm: Add DT node for X-Gene v2 SLIMpro Mailbox I2C Driver
arm64: dts: apm: Mailbox device tree node for APM X-Gene v2 platform.
arm64: dts: apm: Add DT node for X-Gene v1 SLIMpro Mailbox I2C Driver
arm64: dts: apm: mailbox device tree node for APM X-Gene platform.
arm64: dts: apm: Update GPIO to control power-off on X-Gene v2 platforms
arm64: dts: apm: Update GPIO standby controller DT node for X-Gene v2 platforms
arm64: dts: apm: Update GPIO to control power-off on X-Gene v1 platforms
arm64: dts: salvator-x: enable USB 2.0 Host of channel 1 and 2
arm64: dts: salvator-x: enable usb2_phy of channel 1 and 2
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM DT updates from Arnd Bergmann:
"These are all the updates to device tree files for 32-bit platforms,
plus a couple of related 64-bit updates:
New SoC support:
- Allwinner A83T
- Axis Artpec-6 SoC
- Mediatek MT7623 SoC
- TI Keystone K2G SoC
- ST Microelectronics stm32f469
New board or machine support:
- ARM Juno R2
- Buffalo Linkstation LS-QVL and LS-GL
- Cubietruck plus
- D-Link DIR-885L
- DT support for ARM RealView PB1176 and PB11MPCore
- Google Nexus 7
- Homlet v2
- Itead Ibox
- Lamobo R1
- LG Optimus Black
- Logicpd dm3730
- Raspberry Pi Model A
Other changes include
- Lots of updates for Qualcomm APQ8064, MSM8974 and others
- Improved support for Nokia N900 and other OMAP machines
- Common clk support for lpc32xx
- HDLCD display on ARM
- Improved stm32f429 support
- Improved Renesas device support, r8a779x and others
- Lots of Rockchip updates
- Samsung cleanups
- ADC support for Atmel SAMA5D2
- BCM2835 (Raspberry Pi) improvements
- Broadcom Northstar Plus enhancements
- OMAP GPMC rework
- Several improvements for Atmel SAMA5D2 / Xplained
- Global change to remove inofficial "arm,amba-bus" compatible
string"
* tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (350 commits)
ARM, ARM64: dts: drop "arm,amba-bus" in favor of "simple-bus"
ARM: dts: artpec: dual-license on artpec6.dtsi
ARM: dts: ux500: add synaptics RMI4 for Ux500 TVK DT
arm64: dts: juno/vexpress: fix node name unit-address presence warnings
arm64: dts: foundation-v8: add SBSA Generic Watchdog device node
ARM: dts: at91: sama5d2 Xplained: add leds node
ARM: dts: at91: sama5d2 Xplained: add user push button
ARM: dts: at91: sama5d2 Xplained: set pin muxing for usb gadget and usb host
ARM: dts: stm32f429: Enable Ethernet on Eval board
ARM: dts: omap3-sniper: TWL4030 keypad support
Revert "ARM: dts: DRA7: Add dt nodes for PWMSS"
ARM: dts: dm814x: dra62x: Disable wait pin monitoring for NAND
ARM: dts: dm814x: dra62x: Fix NAND device nodes
ARM: dts: stm32f429: Add Ethernet support
ARM: dts: stm32f429: Add system config bank node
ARM: dts: at91: sama5d2: add nand0 and nfc0 nodes
ARM: dts: at91: sama5d2: add dma properties to UART nodes
ARM: dts: at91: sama5d2 Xplained: Correct the macb irq pinctrl node
ARM: dts: exynos: Don't overheat the Odroid XU3-Lite on high load
ARM: dts: exynos: Add cooling levels for Exynos5422/5800 CPUs
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC 64-bit changes from Arnd Bergmann:
"Here's our branch of ARM64 contents for this merge window, now
containing all ARM64 changes other than device tree files.
- Various new platforms get added:
* Allwinner A64 SoC
* Annapurna Labs Alpine SoCs
* Broadcom Vulcan
* Marvell Armada 3700 SoCs
* Amlogic S905
- Various defconfig changes to enable platform specific drivers
This branch includes the clk git tree to resolve a build-time
dependency"
* tag 'armsoc-arm64' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (48 commits)
arm64: defconfig: Increase MMC_BLOCK_MINORS to 16
arm64: defconfig: Add Qualcomm sdhci and restart functionality
ARM64: Enable Amlogic Meson GXBaby platform
arm64: defconfig: Enable Samsung MFD and related configs
arm64: alpine: select the Alpine MSI controller driver
arm64: defconfig: enable the Alpine family
arm64: add Alpine SoC family
arm64: defconfig: Enable exynos thermal config
arm64: add defconfig options for Allwinner SoCs
arm64: defconfig: Enable DesignWare APB GPIO controller
arm64: defconfig: Add Renesas R-Car Gen3 USB 2.0 phy driver support
arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS
clk: samsung: Don't build ARMv8 clock drivers on ARMv7
MAINTAINERS: Add entry for Broadcom Vulcan SoC
arm64: cputype info for Broadcom Vulcan
arm64: Broadcom Vulcan support
arm64: defconfig: Add Broadcom Vulcan to defconfig
arm64: update ARCH_MVEBU for Marvell Armada 7K/8K support
Documentation: arm: add Marvell Armada 7K and 8K families
Documentation: arm: add link to Armada 38x Functional Spec
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC platform updates from Arnd Bergmann:
"Newly added support for additional SoCs:
- Axis Artpec-6 SoC family
- Allwinner A83T SoC
- Mediatek MT7623
- NXP i.MX6QP SoC
- ST Microelectronics stm32f469 microcontroller
New features:
- SMP support for Mediatek mt2701
- Big-endian support for NXP i.MX
- DaVinci now uses the new DMA engine dma_slave_map
- OMAP now uses the new DMA engine dma_slave_map
- earlyprintk support for palmchip uart on mach-tango
- delay timer support for orion
Other:
- Exynos PMU driver moved out to drivers/soc/
- Various smaller updates for Renesas, Xilinx, PXA, AT91, OMAP,
uniphier"
* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (83 commits)
ARM: uniphier: rework SMP code to support new System Bus binding
ARM: uniphier: add missing of_node_put()
ARM: at91: avoid defining CONFIG_* symbols in source code
ARM: DRA7: hwmod: Add data for eDMA tpcc, tptc0, tptc1
ARM: imx: Make reset_control_ops const
ARM: imx: Do L2 errata only if the L2 cache isn't enabled
ARM: imx: select ARM_CPU_SUSPEND only for imx6
dmaengine: pxa_dma: fix the maximum requestor line
ARM: alpine: select the Alpine MSI controller driver
ARM: pxa: add the number of DMA requestor lines
dmaengine: mmp-pdma: add number of requestors
dma: mmp_pdma: Add the #dma-requests DT property documentation
ARM: OMAP2+: Add rtc hwmod configuration for ti81xx
ARM: s3c24xx: Avoid warning for inb/outb
ARM: zynq: Move early printk virtual address to vmalloc area
ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
ARM: SAMSUNG: Remove unused register offset definition
ARM: EXYNOS: Cleanup header files inclusion
drivers: soc: samsung: Enable COMPILE_TEST
MAINTAINERS: Add maintainers entry for drivers/soc/samsung
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC cleanups from Arnd Bergmann:
"A few simple cleanups across multiple platforms, not much standing
out:
- lpc32xx removes its private implementation of the clk API, after
generic code was merged in 4.5
- all unused Makefile.boot files get removed
- a number of simplifications for shmobile
- asm/clkdev.h gets replaced with the asm-generic version after all
mach/clkdev.h implementations are gone"
* tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: shmobile: Kconfig: Get rid of old comment
ARM: shmobile: Consolidate SCU mapping code
arm: lpc32xx: remove direct control of GPIOs from shared mach file
arm: lpc32xx: remove selected HAVE_IDE
arm: lpc32xx: switch to common clock framework
ARM: Use generic clkdev.h header
ARM: plat-versatile: Remove unused clock.c file
ARM: netx: remove redundant "depends on ARCH_NETX"
ARM: integrator: remove redundant select in Kconfig
ARM: drop unused Makefile.boot of Multiplatform SoCs
ARM: mvebu: add missing of_node_put()
ARM: shmobile: r8a7779: Remove remainings of removed SCU boot setup code
ARM: shmobile: Typo s/MIPDR/MPIDR/
ARM: shmobile: Add includes providing forward declarations
ARM: shmobile: rcar-gen2: Make rcar_gen2_dma_contiguous static
ARM: mv78xx0: use "depends on" instead of "if" after prompt
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC non-urgent fixes from Arnd Bergmann:
"As usual, we queue up a few fixes that don't seem urgent enough to go
in through -rc.
- a number of randconfig warning fixes from Arnd
- various small fixes for OMAP
- one somewhat larger patch to restore the OMAP3 cpuidle tuning that
was lost in a cleanup
- a small regression fix for cns3xxx PCI"
* tag 'armsoc-fixes-nc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (26 commits)
CNS3xxx: Fix PCI cns3xxx_write_config()
MAINTAINERS: unify email addrs for Kevin Hilman
CNS3xxx: remove unused *_VIRT definitions
ARM: OMAP2+: Fix hwmod clock for l4_ls
soc: TI knav_qmss: fix dma_addr_t printing
ARM: prima2: always enable reset controller
ARM: socfpga: hide unused functions
ARM: ux500: fix ureachable iounmap()
ARM: ks8695: fix __initdata annotation
ARM: mvebu: mark mvebu_hwcc_pci_nb as __maybe_unused
ARM: mv78xx0: avoid unused function warning
ARM: orion: only select I2C_BOARDINFO when using I2C
ARM: OMAP2+: Fix out of range register access with syscon_config.max_register
ARM: OMAP3: Add cpuidle parameters table for omap3430
ARM: davinci: make I2C support optional
ARM: davinci: DA8xx+DMx combined kernels need PATCH_PHYS_VIRT
ARM: davinci: avoid unused mityomapl138_pn_info variable
ARM: davinci: limit DT support to DA850
ARM: DRA7: hwmod: Add reset data for PCIe
ARM: DRA7: hwmod: Fix OCP2SCP sysconfig
...
|
|
This reverts commit a59f8c5b048dc938fb958c91c282c865cd845705.
There are several bugs in this new code, for example:
1) Uses sleeping locks in get_stats64, which is not allowed,
as the operation can be invoked in an atomic context.
2) Uses PM fields without CONFIG_PM or similar guards.
3) Does not synchronize HW stats when the device runtime
suspends.
Therefore this is being reverted until a correct version
is implemented.
Signed-off-by: David S. Miller <[email protected]>
|
|
Commit 2213e9a66bb8 ("kallsyms: add support for relative offsets in
kallsyms address table") changed the default kallsyms symbol table
format to use relative references rather than absolute addresses.
This reduces the size of the kallsyms symbol table by 50% on 64-bit
architectures, and further reduces the size of the relocation tables
used by relocatable kernels. Since the memory footprint of the static
kernel image is always much smaller than 4 GB, these relative references
are assumed to be representable in 32 bits, even when the native word
size is 64 bits.
On 64-bit architectures, this obviously only works if the distance
between each relative reference and the chosen anchor point is
representable in 32 bits, and so the table generation code in
scripts/kallsyms.c scans the table for the lowest value that is covered
by the kernel text, and selects it as the anchor point.
However, when using the GOLD linker rather than the default BFD linker
to build the x86_64 kernel, the symbol phys_offset_64, which is the
result of arithmetic defined in the linker script, is emitted as a 'T'
rather than an 'A' type symbol, resulting in scripts/kallsyms.c to
mistake it for a suitable anchor point, even though it is far away from
the actual kernel image in the virtual address space. This results in
out-of-range warnings from scripts/kallsyms.c and a broken build.
So let's align with the BFD linker, and emit the phys_offset_[32|64]
symbols as absolute symbols explicitly. Note that the out of range
issue does not exist on 32-bit x86, but this patch changes both symbols
for symmetry.
Reported-by: Markus Trippelsdorf <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Commit 22e0f8b9322c ("net: sched: make bstats per cpu and estimator RCU safe")
added the argument cpu_bstats to functions gen_new_estimator and
gen_replace_estimator and now the descriptions of these are missing for the
documentation. Adding them.
Signed-off-by: Luis de Bethencourt <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Function gnet_stats_copy_basic is missing the description of the cpu
argument in the documentation. Adding it.
Signed-off-by: Luis de Bethencourt <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
'struct timeval' uses 32-bit representation for seconds which will
overflow in year 2038 and beyond. mISDN/clock.c needs to compute and
store elapsed time in intervals of 125 microseconds. This patch replaces
the usage of 'struct timeval' with 64-bit ktime_t which is y2038 safe.
The patch also replaces do_gettimeofday() (wall-clock time) with
ktime_get() (monotonic time) since we only care about elapsed time here.
Signed-off-by: Tina Ruchandani <[email protected]>
Suggested-by: Arnd Bergmnann <[email protected]>
Suggested-by: David Miller <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
UBIFS does not support POSIX ACLs, so there is no need for including any
POSIX ACL hesders.
Signed-off-by: Andreas Gruenbacher <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
|
|
...to represent the status quo.
Signed-off-by: Richard Weinberger <[email protected]>
Acked-by: Artem Bityutskiy <[email protected]>
|
|
Using logging functions instead of macros can reduce overall object size.
$ size drivers/mtd/ubi/built-in.o*
text data bss dec hex filename
271620 163364 73696 508680 7c308 drivers/mtd/ubi/built-in.o.allyesconfig.new
287638 165380 73504 526522 808ba drivers/mtd/ubi/built-in.o.allyesconfig.old
87728 3780 504 92012 1676c drivers/mtd/ubi/built-in.o.defconfig.new
97084 3780 504 101368 18bf8 drivers/mtd/ubi/built-in.o.defconfig.old
Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
|
|
The existing logging macros are fairly large and converting the
macros to functions make the object code smaller.
Use %pV and __builtin_return_address(0) as appropriate.
$ size fs/ubifs/built-in.o*
text data bss dec hex filename
575831 309688 161312 1046831 ff92f fs/ubifs/built-in.o.allyesconfig.new
622457 312872 161120 1096449 10bb01 fs/ubifs/built-in.o.allyesconfig.old
223785 640 644 225069 36f2d fs/ubifs/built-in.o.defconfig.new
251873 640 644 253157 3dce5 fs/ubifs/built-in.o.defconfig.old
Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
|
|
Jesse Gross says:
====================
Tunneling fixes
This series fixes a problem that was reported where encapsulated packets
do not have their encapsulation offload markers stripped off when being
decapsulated. This causes a significant performance drop if the packets
are later retransmitted.
Fixing this revealed two other bugs which are also addressed as prerequisites:
* GRO can aggregate packets for multiple layers of encapsulation which the
stack cannot properly handle.
* IPIP packets which are combined by GRO are not marked properly with their
GSO type.
Note that this is based off the net-next tree as the current target for
bug fixes.
v2: No code changes, just additional information in commit messages and
a new cover letter.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
If a packet is either locally encapsulated or processed through GRO
it is marked with the offloads that it requires. However, when it is
decapsulated these tunnel offload indications are not removed. This
means that if we receive an encapsulated TCP packet, aggregate it with
GRO, decapsulate, and retransmit the resulting frame on a NIC that does
not support encapsulation, we won't be able to take advantage of hardware
offloads even though it is just a simple TCP packet at this point.
This fixes the problem by stripping off encapsulation offload indications
when packets are decapsulated.
The performance impacts of this bug are significant. In a test where a
Geneve encapsulated TCP stream is sent to a hypervisor, GRO'ed, decapsulated,
and bridged to a VM performance is improved by 60% (5Gbps->8Gbps) as a
result of avoiding unnecessary segmentation at the VM tap interface.
Reported-by: Ramu Ramamurthy <[email protected]>
Fixes: 68c33163 ("v4 GRE: Add TCP segmentation offload for GRE")
Signed-off-by: Jesse Gross <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When drivers express support for TSO of encapsulated packets, they
only mean that they can do it for one layer of encapsulation.
Supporting additional levels would mean updating, at a minimum,
more IP length fields and they are unaware of this.
No encapsulation device expresses support for handling offloaded
encapsulated packets, so we won't generate these types of frames
in the transmit path. However, GRO doesn't have a check for
multiple levels of encapsulation and will attempt to build them.
UDP tunnel GRO actually does prevent this situation but it only
handles multiple UDP tunnels stacked on top of each other. This
generalizes that solution to prevent any kind of tunnel stacking
that would cause problems.
Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
Signed-off-by: Jesse Gross <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
ipip encapsulated packets can be merged together by GRO but the result
does not have the proper GSO type set or even marked as being
encapsulated at all. Later retransmission of these packets will likely
fail if the device does not support ipip offloads. This is similar to
the issue resolved in IPv6 sit in feec0cb3
("ipv6: gro: support sit protocol").
Reported-by: Patrick Boutilier <[email protected]>
Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload")
Tested-by: Patrick Boutilier <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: Jesse Gross <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
If the user supply a different fragmentation point or if there is a
network header that cause it to not be aligned, force it to be aligned.
Fragmentation point at a value that is not aligned is not optimal. It
causes extra padding to be used and has just no pros.
v2:
- Make use of the new WORD_TRUNC macro
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare
MTU can sometimes return values that are not aligned, like for loopback,
which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment
will cause the last non-aligned bytes to never be used and can cause
issues with congestion control.
So it's better to just consider a lower MTU and keep congestion control
calcs saner as they are based on PMTU.
Same applies to icmp frag needed messages, which is also fixed by this
patch.
One other effect of this is the inability to send MTU-sized packet
without queueing or fragmentation and without hitting Nagle. As the
check performed at sctp_packet_can_append_data():
if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
/* Enough data queued to fill a packet */
return SCTP_XMIT_OK;
with the above example of MTU, if there are no other messages queued,
one cannot send a packet that just fits one packet (65532 bytes) and
without causing DATA chunk fragmentation or a delay.
v2:
- Added WORD_TRUNC macro
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Currently, if a chunk is scheduled to be sent through a transport that
is currently unconfirmed, it will be leaked as it is dequeued from outq
and is not re-queued nor freed.
As I'm not aware of any situation that may lead to this situation, I'm
fixing this by freeing the chunk and also logging a trace so that we can
fix the other bug if it ever happens.
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The SACK can be lost pretty much elsewhere, but if its allocation fail,
we know we are not sending it, so it is better to revert a_rwnd to its
previous value as this may give it a chance to issue a window update
later.
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Pull virtio/vhost updates from Michael Tsirkin:
"New features, performance improvements, cleanups:
- basic polling support for vhost
- rework virtio to optionally use DMA API, fixing it on Xen
- balloon stats gained a new entry
- using the new napi_alloc_skb speeds up virtio net
- virtio blk stats can now be read while another VCPU is busy
inflating or deflating the balloon
plus misc cleanups in various places"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio_net: replace netdev_alloc_skb_ip_align() with napi_alloc_skb()
vhost_net: basic polling support
vhost: introduce vhost_vq_avail_empty()
vhost: introduce vhost_has_work()
virtio_balloon: Allow to resize and update the balloon stats in parallel
virtio_balloon: Use a workqueue instead of "vballoon" kthread
virtio/s390: size of SET_IND payload
virtio/s390: use dev_to_virtio
vhost: rename vhost_init_used()
vhost: rename cross-endian helpers
virtio_blk: VIRTIO_BLK_F_WCE->VIRTIO_BLK_F_FLUSH
vring: Use the DMA API on Xen
virtio_pci: Use the DMA API if enabled
virtio_mmio: Use the DMA API if enabled
virtio: Add improved queue allocation API
virtio_ring: Support DMA APIs
vring: Introduce vring_use_dma_api()
s390/dma: Allow per device dma ops
alpha/dma: use common noop dma ops
dma: Provide simple noop dma ops
|
|
TCP protocol is still used these days, and TCP uses
clones in its transmit path. We can not optimize linux
stack assuming it is mostly used in routers, or that TCP
is dead.
Fixes: 795bb1c00d ("net: bulk free infrastructure for NAPI context, use napi_consume_skb")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Jesper Dangaard Brouer <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
zero_gid is not used, so remove this redundant array.
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.linaro.org/landing-teams/working/fujitsu/integration
Pull mailbox updates from Jassi Brar:
- mailbox bindings and drivers for
* APM X-Gene
* Hisilicon Hi6220
* Rockchip RK3368
platforms
- minor fixes to the above three drivers.
- misc cleanups of mailbox-test driver.
* 'mailbox-for-next' of git://git.linaro.org/landing-teams/working/fujitsu/integration:
mailbox: rockchip: avoid 64-bit division
mailbox: rockchip: Add Rockchip mailbox driver
dt-bindings: rockchip-mailbox: Add mailbox controller document on Rockchip SoCs
mailbox/xgene-slimpro: Checking for IS_ERR instead of NULL
mailbox: Hi6220: add mailbox driver
dt-bindings: mailbox: Document Hi6220 mailbox driver
mailbox: mailbox-test: add support for separate tx/rx buffer with single channel
mailbox: mailbox-test: use print_hex_dump_bytes to allow dynamic printk
mailbox: mailbox-test: fix the compatible string
mailbox: mailbox-test: rename driver as generic test driver
Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts documentation
mailbox: Add support for APM X-Gene platform mailbox driver
|
|
Pull Xtensa updates from Chris Zankel:
"Xtensa improvements for 4.6:
- control whether perf IRQ is treated as NMI from Kconfig
- implement ioremap for regions outside KIO segment
- fix ISS serial port behaviour when EOF is reached
- fix preemption in {clear,copy}_user_highpage
- fix endianness issues for XTFPGA devices, big-endian cores are now
fully functional
- clean up debug infrastructure and add support for hardware
breakpoints and watchpoints
- add processor configurations for Three Core HiFi-2 MX and HiFi3
cpus"
* tag 'xtensa-next-20160320' of git://github.com/czankel/xtensa-linux:
xtensa: add test_kc705_hifi variant
xtensa: add Three Core HiFi-2 MX Variant.
xtensa: support hardware breakpoints/watchpoints
xtensa: use context structure for debug exceptions
xtensa: remove remaining non-functional KGDB bits
xtensa: clear all DBREAKC registers on start
xtensa: xtfpga: fix earlycon endianness
xtensa: xtfpga: fix i2c controller register width and endianness
xtensa: xtfpga: fix ethernet controller endianness
xtensa: xtfpga: fix serial port register width and endianness
xtensa: define CONFIG_CPU_{BIG,LITTLE}_ENDIAN
xtensa: fix preemption in {clear,copy}_user_highpage
xtensa: ISS: don't hang if stdin EOF is reached
xtensa: support ioremap for memory outside KIO region
xtensa: use XTENSA_INT_LEVEL macro in asm/timex.h
xtensa: make fake NMI configurable
|
|
Current code calls irq_domain_alloc_irqs_parent() in .alloc,
so it should call irq_domain_free_irqs_parent() accordingly in .free.
Fix it by switching to use irq_domain_free_irqs_common() instead of
the open-coded private implementation.
Signed-off-by: Axel Lin <[email protected]>
Cc: Alexandre Courbot <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Stephen Warren <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Daniel Borkmann says:
====================
flowi6_tos fixes
This set is a follow-up to address Jiri's recent feedback [1] on
the flowi6_tos issue, that it is not used for IPv6 route lookups.
The three patches fix all current users of flowi6_tos and remove
the define to avoid any future confusion on this. Tested the vxlan
and geneve ones with IPv6 routing rules. For details, please see
individual patches.
[ As fixes are currently applied against net-next tree, I've rebased
it against that. ]
Thanks!
[1] http://patchwork.ozlabs.org/patch/592055/
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
flowi6_tos of struct flowi6 is unused in IPv6, therefore dumping tos on
that tracepoint will also give incorrect information wrt traffic class.
If we want to fix it, we need to extract it via ip6_tclass(flp->flowlabel).
While for the same test case I get a count of 0 non-zero tos values before
the change, they now start to show up after the change:
# ./perf record -e fib6:fib6_table_lookup -a sleep 10
# ./perf script | grep -v "tos 0" | wc -l
60
Since there's no user in the kernel tree anymore of flowi6_tos, remove the
define to avoid any future confusion on this.
Fixes: b811580d91e9 ("net: IPv6 fib lookup tracepoint")
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The struct flowi6's flowi6_tos is not used in IPv6 route lookup, the
traffic class information is handled in the flowi6's flowlabel member
instead. For example, for policy routing, fib6_rule_match() uses
ip6_tclass() that is applied on the flowlabel for matching on tclass,
which would currently not work as expected.
Fixes: 3a56f86f1be6 ("geneve: handle ipv6 priority like ipv4 tos")
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Jiri mentioned that flowi6_tos of struct flowi6 is never used/read
anywhere. In fact, rest of the kernel uses the flowi6's flowlabel,
where the traffic class _and_ the flowlabel (aka flowinfo) is encoded.
For example, for policy routing, fib6_rule_match() uses ip6_tclass()
that is applied on the flowlabel member for matching on tclass. Similar
fix is needed for geneve, where flowi6_tos is set as well. Installing
a v6 blackhole rule that f.e. matches on tos is now working with vxlan.
Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class")
Reported-by: Jiri Benc <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When cgroup writeback is in use, there can be multiple wb's
(bdi_writeback's) per bdi and an inode may switch among them
dynamically. In a couple places, the wrong wb was used leading to
performing operations on the wrong list under the wrong lock
corrupting the io lists.
* writeback_single_inode() was taking @wb parameter and used it to
remove the inode from io lists if it becomes clean after writeback.
The callers of this function were always passing in the root wb
regardless of the actual wb that the inode was associated with,
which could also change while writeback is in progress.
Fix it by dropping the @wb parameter and using
inode_to_wb_and_lock_list() to determine and lock the associated wb.
* After writeback_sb_inodes() writes out an inode, it re-locks @wb and
inode to remove it from or move it to the right io list. It assumes
that the inode is still associated with @wb; however, the inode may
have switched to another wb while writeback was in progress.
Fix it by using inode_to_wb_and_lock_list() to determine and lock
the associated wb after writeback is complete. As the function
requires the original @wb->list_lock locked for the next iteration,
in the unlikely case where the inode has changed association, switch
the locks.
Kudos to Tahsin for pinpointing these subtle breakages.
Signed-off-by: Tejun Heo <[email protected]>
Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching")
Link: http://lkml.kernel.org/g/CAAeU0aMYeM_39Y2+PaRvyB1nqAPYZSNngJ1eBRmrxn7gKAt2Mg@mail.gmail.com
Reported-and-diagnosed-by: Tahsin Erdogan <[email protected]>
Tested-by: Tahsin Erdogan <[email protected]>
Cc: [email protected] # v4.2+
Signed-off-by: Jens Axboe <[email protected]>
|
|
locked_inode_to_wb_and_lock_list() wb_get()'s the wb associated with
the target inode, unlocks inode, locks the wb's list_lock and verifies
that the inode is still associated with the wb. To prevent the wb
going away between dropping inode lock and acquiring list_lock, the wb
is pinned while inode lock is held. The wb reference is put right
after acquiring list_lock citing that the wb won't be dereferenced
anymore.
This isn't true. If the inode is still associated with the wb, the
inode has reference and it's safe to return the wb; however, if inode
has been switched, the wb still needs to be unlocked which is a
dereference and can lead to use-after-free if it it races with wb
destruction.
Fix it by putting the reference after releasing list_lock.
Signed-off-by: Tejun Heo <[email protected]>
Fixes: 87e1d789bf55 ("writeback: implement [locked_]inode_to_wb_and_lock_list()")
Cc: [email protected] # v4.2+
Tested-by: Tahsin Erdogan <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
queue_for_each_ctx() iterates over per_cpu variables under the assumption that
the possible cpu mask cannot have holes. That's wrong as all cpumasks can have
holes. In case there are holes the iteration ends up accessing uninitialized
memory and crashing as a result.
Replace the macro by a proper for_each_possible_cpu() loop and drop the unused
macro blk_ctx_sum() which references queue_for_each_ctx().
Reported-by: Xiong Zhou <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
Description of expected_size doesn't match any parameter of the function
drm_atomic_replace_property_blob. Removing it.
Signed-off-by: Luis de Bethencourt <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Ensure optional regulator is properly disabled when present.
Fixes: 63d5d525cbbc ("iio:magnetometer:ak8975: power regulator support")
Signed-off-by: Gregor Boirie <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|