Regular expressions for highlights in kernel-doc are stored in a Perl
hash. These hashes are ordered differently for each Perl run. This will
prevent kernel-doc to behave deterministically when parsing “@foo()” as
in some runs it will be interpreted as a parameter and in the others it
will be interpreted as a function.
We now sort the %highlights hash to get the same behavior on every run.
Signed-off-by: Jérémy Bobbio <lunar@debian.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
If we fail to add some DSPs or fail to add the controls we should call
wm_adsp2_codec_remove for all the cores we have already added. This
patch fixes this up on the wm5102 and wm5110.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We currently set x27 in compat_sys_sigreturn_wrapper and
compat_sys_rt_sigreturn_wrapper, similarly to what we do with r8/why on
32-bit ARM, in an attempt to prevent sigreturns from being restarted.
However, on arm64 we have always used pt_regs::syscallno for syscall
restarting (for both native and compat tasks), and x27 is never
inspected again before being overwritten in kernel_exit.
This patch removes the pointless register assignments.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The filesystems proc and sysfs do not have executable files do not
have exectuable files today and portions of userspace break if we do
enforce nosuid and noexec consistency of nosuid and noexec flags
between previous mounts and new mounts of proc and sysfs.
Add the code to enforce consistency of the nosuid and noexec flags,
and use the presence of SB_I_NOEXEC to signal that there is no need to
bother.
This results in a completely userspace invisible change that makes it
clear fs_fully_visible can only skip the enforcement of noexec and
nosuid because it is known the filesystems in question do not support
executables.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Today proc and sysfs do not contain any executable files. Several
applications today mount proc or sysfs without noexec and nosuid and
then depend on there being no exectuables files on proc or sysfs.
Having any executable files show on proc or sysfs would cause
a user space visible regression, and most likely security problems.
Therefore commit to never allowing executables on proc and sysfs by
adding a new flag to mark them as filesystems without executables and
enforce that flag.
Test the flag where MNT_NOEXEC is tested today, so that the only user
visible effect will be that exectuables will be treated as if the
execute bit is cleared.
The filesystems proc and sysfs do not currently incoporate any
executable files so this does not result in any user visible effects.
This makes it unnecessary to vet changes to proc and sysfs tightly for
adding exectuable files or changes to chattr that would modify
existing files, as no matter what the individual file say they will
not be treated as exectuable files by the vfs.
Not having to vet changes to closely is important as without this we
are only one proc_create call (or another goof up in the
implementation of notify_change) from having problematic executables
on proc. Those mistakes are all too easy to make and would create
a situation where there are security issues or the assumptions of
some program having to be broken (and cause userspace regressions).
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
We have to put back the references to the master conntrack and the expectation
that we just created, otherwise we'll leak them.
Fixes: 0ef71ee1a5 ("netfilter: ctnetlink: refactor ctnetlink_create_expect")
Reported-by: Tim Wiess <Tim.Wiess@watchguard.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Loc Ho <lho@apm.com>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Link: http://lkml.kernel.org/r/1436507243-11159-1-git-send-email-k.kozlowski@samsung.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Currently guest MTRR is avoided if kvm_is_reserved_pfn returns true.
However, the guest could prefer a different page type than UC for
such pages. A good example is that pass-throughed VGA frame buffer is
not always UC as host expected.
This patch enables full use of virtual guest MTRRs.
Suggested-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Tested-by: Joerg Roedel <jroedel@suse.de> (on AMD)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When hardware supports the g_pat VMCB field, we can use it for emulating
the PAT configuration that the guest configures by writing to the
corresponding MSR.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Right now, NPT page attributes are not used, and the final page
attribute depends solely on gPAT (which however is not synced
correctly), the guest MTRRs and the guest page attributes.
However, we can do better by mimicking what is done for VMX.
In the absence of PCI passthrough, the guest PAT can be ignored
and the page attributes can be just WB. If passthrough is being
used, instead, keep respecting the guest PAT, and emulate the guest
MTRRs through the PAT field of the nested page tables.
The only snag is that WP memory cannot be emulated correctly,
because Linux's default PAT setting only includes the other types.
Tested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If there are no assigned devices, the guest PAT are not providing
any useful information and can be overridden to writeback; VMX
always does this because it has the "IPAT" bit in its extended
page table entries, but SVM does not have anything similar.
Hook into VFIO and legacy device assignment so that they
provide this information to KVM.
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Tested-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
fpu_activate is called outside of vcpu_load(), which means it should not
touch VMCS, but fpu_activate needs to. Avoid the call by moving it to a
point where we know that the guest needs eager FPU and VMCS is loaded.
This will get rid of the following trace
vmwrite error: reg 6800 value 0 (err 1)
[<ffffffff8162035b>] dump_stack+0x19/0x1b
[<ffffffffa046c701>] vmwrite_error+0x2c/0x2e [kvm_intel]
[<ffffffffa045f26f>] vmcs_writel+0x1f/0x30 [kvm_intel]
[<ffffffffa04617e5>] vmx_fpu_activate.part.61+0x45/0xb0 [kvm_intel]
[<ffffffffa0461865>] vmx_fpu_activate+0x15/0x20 [kvm_intel]
[<ffffffffa0560b91>] kvm_arch_vcpu_create+0x51/0x70 [kvm]
[<ffffffffa0548011>] kvm_vm_ioctl+0x1c1/0x760 [kvm]
[<ffffffff8118b55a>] ? handle_mm_fault+0x49a/0xec0
[<ffffffff811e47d5>] do_vfs_ioctl+0x2e5/0x4c0
[<ffffffff8127abbe>] ? file_has_perm+0xae/0xc0
[<ffffffff811e4a51>] SyS_ioctl+0xa1/0xc0
[<ffffffff81630949>] system_call_fastpath+0x16/0x1b
(Note: we also unconditionally activate FPU in vmx_vcpu_reset(), so the
removed code added nothing.)
Fixes: c447e76b4c ("kvm/fpu: Enable eager restore kvm FPU for MPX")
Cc: <stable@vger.kernel.org>
Reported-by: Vlastimil Holer <vlastimil.holer@gmail.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The call to get_mt_mask was really using kvm_is_reserved_pfn to
detect an MMIO-backed page. In this case, we want "false" to be
returned for the zero page.
Reintroduce a separate kvm_is_mmio_pfn predicate for this use
only.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
rsnd_force_write() is similar to rsnd_write(),
but rsnd_force_write() write data to register even though
it is same value.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This allows users to use _update_bits() without the write suppression,
useful for some hardware.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVn6DOAAoJECTWi3JdVIfQIb8H+wVh2/P7OJNL+GjESuzCMg24
sBbM6dqqBtb9eYvuKIioRAvSsOqKtwEZ06ntQIWI+Yyb7k0DuvOZ26iJMTabwZys
nCokCiCnA42LWortts6H0NvdDwrJNlKMB55SLh8eFJIv1ZVFvMC+fcj+HOxL02Sn
0I0jhTgphhSau8WBBzLsGokVs34UcNTnS3F5SxuOw4HDS9c/HZIDE64ykNqAliD/
+xGW0jcUlx/FCoAPFTZVOmUzfeQTbeXD2s21KmUfG+ObeMuJyyFrbdeVb6IxPlTM
vg6426H+jRXJFTq0v5Ozy0xpOS12lAxnFb+xmNzTpNJhzmJxKTcBXMVYmT//MoI=
=fNFo
-----END PGP SIGNATURE-----
Merge tag 'regmap-force' into asoc-rcar
regmap: Force write support
This allows users to use _update_bits() without the write suppression,
useful for some hardware.
regmap_fields_force_write() is similar to regmap_fields_write(),
but regmap_fields_force_write() write data to register even though
it is same value.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap_write_bits() is similar to regmap_update_bits(),
but regmap_write_bits() write data to register even though
it is same value.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Sometimes we want to write data even though it doesn't change value.
Then, force_write option on _regmap_update_bits() helps this purpose.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We provide our own implementation of asm/mcs_spinlock.h, so there's no
need to ask for the (empty) generic version.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
For PPI based PMUs, we bail out early in of_pmu_irq_cfg() without
setting the PMU's supported_cpus bitmap. This causes the
smp_call_function_any() in armv7_probe_num_events() to fail. Set
the bitmap to be all CPUs so that we properly probe PMUs that use
PPIs.
Fixes: cc88116da0 ("arm: perf: treat PMUs as CPU affine")
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
"CoreLink Level 2 Cache Controller L2C-310", p. 2-15, section 2.3.2
Shareable attribute" states:
"The default behavior of the cache controller with respect to the
shareable attribute is to transform Normal Memory Non-cacheable
transactions into:
- cacheable no allocate for reads
- write through no write allocate for writes."
Depending on the system architecture, this may cause memory corruption
in the presence of bus mastering devices (e.g. OHCI). To avoid such
corruption, the default behavior can be disabled by setting the Shared
Override bit in the Auxiliary Control register.
Currently the Shared Override bit can be set only using C code:
- by calling l2x0_init() directly, which is deprecated,
- by setting/clearing the bit in the machine_desc.l2c_aux_val/mask
fields, but using values differing from 0/~0 is also deprecated.
Hence add support for an "arm,shared-override" device tree property for
the l2c device node. By specifying this property, affected systems can
indicate that non-cacheable transactions must not be transformed.
Then, it's up to the OS to decide. The current behavior is to set the
"shared attribute override enable" bit, as there may exist kernel linear
mappings and cacheable aliases for the DMA buffers, even if CMA is
enabled.
See also commit 1a8e41cd67 ("ARM: 6395/1: VExpress: Set bit 22 in
the PL310 (cache controller) AuxCtlr register"):
"Clearing bit 22 in the PL310 Auxiliary Control register (shared
attribute override enable) has the side effect of transforming
Normal Shared Non-cacheable reads into Cacheable no-allocate reads.
Coherent DMA buffers in Linux always have a Cacheable alias via the
kernel linear mapping and the processor can speculatively load
cache lines into the PL310 controller. With bit 22 cleared,
Non-cacheable reads would unexpectedly hit such cache lines leading
to buffer corruption."
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We need to emit EV_SYN/SYN_REPORT between key press and release, otherwise
userspace is allowed to "swallow" the event.
[jkosina@suse.com: Dmitry says that he's observing this behavior with
Plantronics headset]
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
cp2112_i2c_xfer() only supports a single i2c_msg. More than
one message at a time just returns EIO. This breaks certain
important cases. For example, the at24 eeprom driver generates
paired write and read messages (for eeprom address and data).
Since the device doesn't support i2c repeated starts in general,
but does support a single write-repeated-start-read pair
(since hardware rev 1), we recognize the latter case and
implement only that.
Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Commit a7c6e76fee ("drm/imx: switch to use media bus formats") accidentally
replaced IPU_PIX_FMT_GBR24 with MEDIA_BUS_FMT_YUV8_1X24 instead of the correct
MEDIA_BUS_FMT_GBR888_1X24. This patch is needed to fix VGA output in i.MX53.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Even with the oops fixed by a previous patch, the system still fails to
kexec, due to a stuck chained interrupt locking the system. We must
disable the child interrupts prior to setting up the irq chip to ensure
we don't get stuck here.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The parallel-display driver used an undocumented, non-standard property
"fsl,panel" to optionally associate with a drm_panel device. This patch
fixes the driver to use the same OF graph bindings as the LDB driver
instead:
parallel-display {
compatible = "fsl,imx-parallel-display";
...
port@1 {
reg = <1>;
parallel_out: endpoint {
remote_endpoint = <&panel_in>;
};
};
};
panel {
...
port {
panel_in: endpoint {
remote-endpoint = <¶llel_out>;
};
};
};
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Gary Bisson <gary.bisson@boundarydevices.com>
We were using the native syscall and that results in subtle breakage.
This is the same issue as fixed in 077d0e6561
(MIPS: N32: Use compat getsockopt syscall) but that commit did fix it only
for N32.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100291
The L2 cache in the I6400 core has 16 ways, so extend the way_string
array to take such caches into account.
[ralf@linux-mips.org: Other already supported CPUs are free to support
more than 8 ways of cache as well.]
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10640/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Implement the mips_cdmm_phys_base() platform callback to provide a
default Common Device Memory Map (CDMM) physical base address for the
Pistachio SoC. This allows the CDMM in each VPE to be configured and
probed for devices, such as the Fast Debug Channel (FDC).
The physical address chosen is just below the default CPC address, which
appears to also be unallocated.
The FDC IRQ is also usable on Pistachio, and is routed through the GIC,
so implement the get_c0_fdc_int() platform callback using
gic_get_c0_fdc_int(), so the FDC driver doesn't have to fall back to
polling.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Andrew Bresticker <abrestic@chromium.org>
Cc: James Hartley <james.hartley@imgtec.com>
Cc: linux-mips@linux-mips.org
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Patchwork: http://patchwork.linux-mips.org/patch/9749/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Wider testing reveals that the Fast Debug Channel (FDC) interrupt is
routed through the GIC just fine on Pistachio SoC, even though it
contains interAptiv cores. Clearly the FDC interrupt routing problems
previously observed on interAptiv and proAptiv cores are specific to the
Malta FPGA bitstreams.
Move the workaround for interAptiv and proAptiv out of
gic_get_c0_fdc_int() in the GIC irqchip driver into Malta's
get_c0_fdc_int() platform callback, to allow the Pistachio SoC to use
the FDC interrupt.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Andrew Bresticker <abrestic@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: linux-mips@linux-mips.org
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Cc: James Hartley <james.hartley@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/9748/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MT_SMP is not the only SMP option for MT cores. The MT_SMP option
allows more than one VPE per core to appear as a secondary CPU in the
system. Because of how CM works, it propagates the address-based
cache ops to the secondary cores but not the index-based ones.
Because of that, the code does not use IPIs to flush the L1 caches on
secondary cores because the CM would have done that already. However,
the CM functionality is independent of the type of SMP kernel so even in
non-MT kernels, IPIs are not necessary. As a result of which, we change
the conditional to depend on the CM presence. Moreover, since VPEs on
the same core share the same L1 caches, there is no need to send an
IPI on all of them so we calculate a suitable cpumask with only one
VPE per core.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: <stable@vger.kernel.org> # 3.15+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10654/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Mikulas reported his K6-3 not booting. This is because the
static_key API confusion struck and bit Andy, this wants to be
static_key_false().
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Tested-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: Vince Weaver <vince@deater.net>
Cc: hillf.zj <hillf.zj@alibaba-inc.com>
Fixes: a66734297f ("perf/x86: Add /sys/devices/cpu/rdpmc=2 to allow rdpmc for all tasks")
Link: http://lkml.kernel.org/r/20150709172338.GC19282@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
These are only noticed when doing a detached tarball, i.e. when one does:
make perf-perf-tar-src-pkg
to create a perf-4.2.0-rc1.tar file and then try to build the contents of this
tarball:
- The python binding also has a MANIFEST like file where we list the files that
need to be built and linked to form the resulting python shared object module
file. And it has an entry for rbtree.c that still pointed to the one in the
kernel sources, fix it by also removing one level of indirection so that it
uses the tools/lib/rbtree.c copy. (Arnaldo Carvalho de Melo)
- For the same reasons as for rbtree.c, copy the kernel lib/hweight.c file to
tools/lib/, sanitizing it in the process to remove kernel specific stuff like
EXPORT_SYMBOL() lines and the linux/export.h include reference, as that file
doesn't exist anymore in tools/include/linux. (Arnaldo Carvalho de Melo)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVnuOBAAoJENZQFvNTUqpAgQwP/30+PqfZgFl1NQ980/cCguLW
nMIwlw+GyQerOzffbCjRpilPJSV5IyWl9EwRxb53eyUugD/vUwEw0C3lgP1Txm27
4yMudNFDLSk4Nux3FIl+z0Y6Zp2y4RnmpDNqbGpro7zv7/G6YzcvSzS/qjhyKeS6
0leGcFVFRcnezpLFRGvNjChUhVtQ8ldoZW0PR5bGXika1BnQSs15aaUfZU7HDSHr
RNf5LLO/ODh+XQZdBH42nOKbFlHJBWT6WyuuSC7+3shtM2Z2dS7jpFWILkdhdnSk
Dypm9qAkU91gxuhLunasfzhJUXf2g+nbP5R75lwiIL6Z97/D3O9WBF8BBZgmfozt
T29FDO/hPsW8SjHRfceyUysrVjUR4XP6vISj+6W+3ptAg1r7fPRrXzMsIRNJiDgB
VK7ZWloO6aAHC+C1szudR99CXIxhz0x9sOOyrKmBi7Qc3hi0UszsT0yHOKzfFqga
4JtGAGUQUijQsiL+jN6vgUuWcuGW9/huGosDH4t7FR7o8eGHBap6e3rxXX0weKer
Y8MVrm3a3v6SA2hUD6kSlw3XuBOSL0vBid8aAATiTzhQZfmMHKb48yxDt+U3eoO9
4Ygae6vNveKr0vYMlwvsy0lCcTbwxLwvtG4rRyQVOj7zwW/wdJ+30FAUFowD9r+9
MhUPsCF4B4OO1RkZtwjZ
=bQ38
-----END PGP SIGNATURE-----
Merge tag 'perf-urgent-for-mingo-2' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
- Fix 'perf top -u username', where not enough memory per thread_map
entry was being allocated nor was being initialized, causing a
segfault (Arnaldo Carvalho de Melo)
- Fix locking lockup using 32-bit compat vdso (Adrian Hunter)
- Fix shadow declaration of 'close' with older build environments (Jiri Olsa)
- Make the 'clean' target do a better job, removing some more temp files (Riku Voipio)
- The python binding also has a MANIFEST like file where we list the files that
need to be built and linked to form the resulting python shared object module
file. And it has an entry for rbtree.c that still pointed to the one in the
kernel sources, fix it by also removing one level of indirection so that it
uses the tools/lib/rbtree.c copy. (Arnaldo Carvalho de Melo)
- For the same reasons as for rbtree.c, copy the kernel lib/hweight.c file to
tools/lib/, sanitizing it in the process to remove kernel specific stuff like
EXPORT_SYMBOL() lines and the linux/export.h include reference, as that file
doesn't exist anymore in tools/include/linux. (Arnaldo Carvalho de Melo)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Small fixes for omapdrm, including:
* Fix packed 24 bit color formats
* Ensure the planes are inside the crtc
* Handle out-of-dma-memory error
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVlkYTAAoJEPo9qoy8lh710vwQAJ6UlpVR9Yo1YjywKbFw3GrM
NAhtBxpUkM13QIpWIq7dzEtSzOU90KC7rCPmlxCLSE8zDKUWDbBexja1gdpe43n4
I2HViKQI/GMtph4OkolPVWn3tiIQJp8JAqQsBpZkiJpLvRQZC/SKSm42ZkuqPwMX
4+gq3c82ZCnA86BrXeVkxIGit+J2Jzf+dqb5F/4g+sVu+XjpsHIyHv5wCXBetTkW
HiCIlej0FaROQMDqnYOE+M8InpFuA4Wc9JGPgUGRH/RQKnBocaOsdp/i98iAyBPD
rqjFJYMMt+TOE9/I6NFZ+GyAFSV3M5WT+bc7KUmj7RgCXNHBxxGBzWC3SH56Zk3o
ipDsjyLyZksLyMvrVG9dPjMCcU3rm7JOYeodQa9Y3Hc6Em3Wc7UwWXg9JoPLJXRN
0UayZYSQJsP2/mBF+1eNsiNgDNz1AyRwB4qPb7jEgwCti6kbGv4AMTiwX+BbIJpm
989UaRBze07GAbjiO0UVjydegNKf6Vp8J3B8+GnGHBQWnFIyB3a6bGmdBSeubjsg
uPcsC/r8f2RTkOpyf6Mk3pCpkyi+S8hQvUchaPqdgjl37o/xRl2tq9mo3szRASDV
HvxYh1eqnM1YIgDrDfO/FJtNqQlVULlg0HQO1Tu+wwOMOC9rAuSHSvBXDKVLN7KU
8kS017e4KRPXlGHDAL6q
=mgUq
-----END PGP SIGNATURE-----
Merge tag 'omapdrm-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-fixes
omapdrm fixes for 4.2
Small fixes for omapdrm, including:
* Fix packed 24 bit color formats
* Ensure the planes are inside the crtc
* Handle out-of-dma-memory error
* tag 'omapdrm-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
drm/omap: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN
drm/omap: fix align_pitch() for 24 bits per pixel
drm/omap: fix omap_gem_put_paddr() error handling
drm/omap: fix omap_framebuffer_unpin() error handling
drm/omap: increase DMM transaction timeout
drm/omap: check that plane is inside crtc
drm/omap: return error if dma_alloc_writecombine fails
Pile of fixes for either 4.2 issues or cc: stable. This should fix the 2nd
kind of WARNING Linus's been seeing, please ask him to scream if that's
not the case.
* tag 'drm-intel-fixes-2015-07-09' of git://anongit.freedesktop.org/drm-intel:
Revert "drm/i915: Allocate context objects from stolen"
drm/i915: Declare the swizzling unknown for L-shaped configurations
drm/i915: Use crtc_state->active in primary check_plane func
drm/i915: Check crtc->active in intel_crtc_disable_planes
drm/i915: Restore all GGTT VMAs on resume
drm/i915/chv: fix HW readout of the port PLL fractional divider
A single fix so far for 4.2:
- checking a pointer is not null before using it
* tag 'drm-amdkfd-fixes-2015-07-09' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: validate pdd where it acquired first
radeon and amdgpu fixes for 4.2. All over the place:
- fix cursor corruption on resume and re-enable no VT switch on suspend
- vblank fixes
- fix gpuvm error messages
- misc other fixes
* 'drm-fixes-4.2' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: disable vce init on cayman (v2)
drm/amdgpu: fix timeout calculation
drm/radeon: check if BO_VA is set before adding it to the invalidation list
drm/radeon: allways add the VM clear duplicate
Revert "Revert "drm/radeon: dont switch vt on suspend""
drm/radeon: Fold radeon_set_cursor() into radeon_show_cursor()
drm/radeon: unpin cursor BOs on suspend and pin them again on resume (v2)
drm/radeon: Clean up reference counting and pinning of the cursor BOs
drm/radeon: fix underflow in r600_cp_dispatch_texture()
drm/radeon: default to 2048 MB GART size on SI+
drm/radeon: fix HDP flushing
drm/radeon: use RCU query for GEM_BUSY syscall
drm/amdgpu: Handle irqs only based on irq ring, not irq status regs.
drm/radeon: Handle irqs only based on irq ring, not irq status regs.
Commit c29390c6df ("xps: must clear sender_cpu before forwarding")
fixed an issue in normal forward path, caused by sender_cpu & napi_id
skb fields being an union.
Bridge is another point where skb can be forwarded, so we need
the same cure.
Bug triggers if packet was received on a NIC using skb_mark_napi_id()
Fixes: 2bd82484bb ("xps: fix xps for stacked devices")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Bob Liu <bob.liu@oracle.com>
Tested-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After commit 900f65d361 ("tcp: move duplicate code from
tcp_v4_init_sock()/tcp_v6_init_sock()"), we no longer
need to export tcp_init_xmit_timers()
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Value returned by devm_ioremap_resource() was checked for non-NULL but
devm_ioremap_resource() returns IOMEM_ERR_PTR, not NULL. In case of
error this could lead to dereference of ERR_PTR.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Cc: <stable@vger.kernel.org>
Fixes: 46aa27df88 ("net: axienet: Use devm_* calls")
Reviewed-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fill also the port group state when sending notifications.
Signed-off-by: Satish Ashok <sashok@cumulusnetworks.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
flags local variable in __mkroute_input is not used as a variable.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support to allow non-local binds similar to how this was done for IPv4.
Non-local binds are very useful in emulating the Internet in a box, etc.
This add the ip_nonlocal_bind sysctl under ipv6.
Testing:
Set up nonlocal binding and receive routing on a host, e.g.:
ip -6 rule add from ::/0 iif eth0 lookup 200
ip -6 route add local 2001:0:0:1::/64 dev lo proto kernel scope host table 200
sysctl -w net.ipv6.ip_nonlocal_bind=1
Set up routing to 2001:0:0:1::/64 on peer to go to first host
ping6 -I 2001:0:0:1::1 peer-address -- to verify
Signed-off-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The pointer to an AFU in the adapter's list of AFUs can be null
if we're in the process of removing AFUs. The afu_list_lock
doesn't guard against this.
Say we have 2 slices, and we're in the process of removing cxl.
- We remove the AFUs in order (see cxl_remove). In cxl_remove_afu
for AFU 0, we take the lock, set adapter->afu[0] = NULL, and
release the lock.
- Then we get an slbia. In cxl_slbia we take the lock, and set
afu = adapter->afu[0], which is NULL.
- Therefore our attempt to check afu->enabled will blow up.
Therefore, check if afu is a null pointer before dereferencing it.
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Axtens <dja@axtens.net>
Acked-by: Michael Neuling <mikey@neuling.org>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Zoltan Boszormenyi reported this regression:
"There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
1565:230e) network chip on the mainboard. After the r8169 driver loaded
the IRQs in the machine went berserk. Keyboard keypressed arrived with
considerable latency and duplicated, so no real work was possible.
The machine responded to the power button but didn't actually power
down. It just stuck at the powering down message. I had to press the
power button for 4 seconds to power it down.
The computer is a POS machine with a big battery inside. Because of this,
either ACPI or the Realtek chip kept the bad state and after rebooting,
the network chip didn't even show up in lspci. Not even the PXE ROM
announced itself during boot. I had to disconnect the battery to beat
some sense back to the computer.
The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final. 3.18.16 was
good."
The regression is caused by commit 593669c2ac (x86/PCI/ACPI: Use common
ACPI resource interfaces to simplify implementation). Since commit
593669c2ac, x86 PCI ACPI host bridge driver validates ACPI resources by
first converting an ACPI resource to a 'struct resource' structure and
then applying checks against the converted resource structure. The 'start'
and 'end' fields in 'struct resource' are defined to be type of
resource_size_t, which may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT.
This may cause incorrect resource validation results with 32-bit kernels
because 64-bit ACPI resource descriptors may get truncated when converting
to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
affects PCI resource allocation subsystem and makes some PCI devices and
the system behave abnormally due to incorrect resource assignment.
So enhance the ACPI resource parsing interfaces to ignore ACPI resource
descriptors with address/offset above 4G when running in 32-bit mode.
With the fix applied, the behavior of the machine was restored to how
3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
and lspci -vvxxx shows that everything is at the same memory window as
they were with 3.18.16.
Reported-and-tested-by: Boszormenyi Zoltan <zboszor@pr.hu>
Fixes: 593669c2ac (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Users of freq table may want to access it for any CPU from
policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
list of 'clip_cpus' (equivalent to policy->related_cpus) during
registration and tries to get freq_table for the first CPU of this mask.
If the CPU, for which it tries to fetch freq_table, is offline,
cpufreq_frequency_get_table() fails. This happens because it relies on
cpufreq_cpu_get_raw() for its functioning which returns policy only for
online CPUs.
The fix is to access the policy data structure for the given CPU
directly (which also returns a valid policy for offline CPUs), but the
policy itself has to be active (meaning that at least one CPU using it
is online) for the frequency table to be returned.
Because we will be using 'cpufreq_cpu_data' now, which is internal to
the cpufreq core, move cpufreq_frequency_get_table() to cpufreq.c.
Reported-and-tested-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
