Age | Commit message (Collapse) | Author | Files | Lines |
|
Commit 5620a0d1aacd ("firmware: delete in-kernel firmware") deleted
in-kernel firmware support, including "make firmware_install".
Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
the error:
make[2]: *** No rule to make target `firmware_install'. Stop.
Commit df85b2d767aa ("firmware: Restore support for built-in firmware")
restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
is out of the scope of "make firmware_install". So, the right thing to
do is to kill the use of "make firmware_install".
Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
|
|
Cancel active scans and deactivate firmware scan watchdog timer
when wireless interface configuration is changed. The usecases
include wireless interface mode change, interface down,
AP stop, virtual interface removal.
Signed-off-by: Sergey Matyukevich <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
Fix tx path regression. Lock should be held when queuing packets
to h/w fifos in order to properly handle configurations with
multiple enabled interfaces.
Signed-off-by: Sergey Matyukevich <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
gcc-8 points out two comparisons that are clearly bogus
and almost certainly not what the author intended to write:
drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed':
drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
USB_PORT_STAT_ENABLE) == 1 &&
^~
drivers/usb/gadget/udc/dummy_hcd.c:381:25: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
USB_SS_PORT_LS_U0) == 1 &&
^~
I looked at the code for a bit and came up with a change that makes
it look like what the author probably meant here. This makes it
look reasonable to me and to gcc, shutting up the warning.
It does of course change behavior as the two conditions are actually
evaluated rather than being hardcoded to false, and I have made no
attempt at verifying that the changed logic makes sense in the context
of a USB HCD, so that part needs to be reviewed carefully.
Fixes: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support")
Cc: Tatyana Brokhman <[email protected]>
Cc: Felipe Balbi <[email protected]>
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Fix build errors that happen when CONFIG_EXTCON=m and
CONFIG_USB_SNP_UDC_PLAT=y by preventing that combination in Kconfig.
CONFIG_EXTCON can still be disabled or enabled for this driver since
<linux/extcon.h> has stubs for the disabled case, but if CONFIG_EXTCON=m,
USB_SNP_UDC_PLAT is restricted to m or n (cannot be builtin).
drivers/built-in.o: In function `udc_plat_remove':
snps_udc_plat.c:(.text+0x2c4060): undefined reference to `extcon_unregister_notifier'
drivers/built-in.o: In function `udc_plat_probe':
snps_udc_plat.c:(.text+0x2c438c): undefined reference to `extcon_get_edev_by_phandle'
snps_udc_plat.c:(.text+0x2c43f2): undefined reference to `extcon_register_notifier'
snps_udc_plat.c:(.text+0x2c4416): undefined reference to `extcon_get_state'
snps_udc_plat.c:(.text+0x2c44f7): undefined reference to `extcon_unregister_notifier'
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
If usb_gadget_giveback_request() is called in usb_ep_queue(),
this printer_write() is possible to cause spinlock recursion. So,
this patch adds spin_unlock() before calls usb_ep_queue() to avoid it.
Signed-off-by: Yoshihiro Shimoda <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Consider the following case: udc controller supports SuperSpeed. If we
first load a HighSpeed gadget followed by a SuperSpeed gadget, the
SuperSpeed gadget will be limited to HighSpeed as UDC core driver
doesn't call ->udc_set_speed() in the second case.
Call ->udc_set_speed() unconditionally to fix this issue.
This will also fix the case for dwc3 controller driver when SuperSpeed
gadget is loaded first and works in HighSpeed only as udc_set_speed()
was never being called.
Fixes: 6099eca796ae ("usb: gadget: core: introduce ->udc_set_speed() method")
Cc: <[email protected]> [v4.13+]
Signed-off-by: Roger Quadros <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Add a new sysctl file /proc/sys/s390/topology which displays if
topology is on (1) or off (0) as specified by the "topology=" kernel
parameter.
This allows to change topology information during runtime and
configuring it via /etc/sysctl.conf instead of using the kernel line
parameter.
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
If running on machines that do not provide topology information we
currently generate a "fake" topology which defines the maximum
distance between each cpu: each cpu will be put into an own drawer.
Historically this used to be the best option for (virtual) machines in
overcommited hypervisors.
For some workloads however it is better to generate a different
topology where all cpus are siblings within a package (all cpus are
core siblings). This shows performance improvements of up to 10%,
depending on the workload.
In order to keep the current behaviour, but also allow to switch to
the different core sibling topology use the existing "topology="
kernel parameter:
Specifying "topology=on" on machines without topology information will
generate the core siblings (fake) topology information, instead of the
default topology information where all cpus have the maximum distance.
On machines which provide topology information specifying
"topology=on" does not have any effect.
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Optprobes depended on an updated regs->nip from analyse_instr() to
identify the location to branch back from the optprobes trampoline.
However, since commit 3cdfcbfd32b9d ("powerpc: Change analyse_instr so
it doesn't modify *regs"), analyse_instr() doesn't update the registers
anymore. Due to this, we end up branching back from the optprobes
trampoline to the same branch into the trampoline resulting in a loop.
Fix this by calling out to emulate_update_regs() before using the nip.
Additionally, explicitly compare the return value from analyse_instr()
to 1, rather than just checking for !0 so as to guard against any
future changes to analyse_instr() that may result in -1 being returned
in more scenarios.
Fixes: 3cdfcbfd32b9d ("powerpc: Change analyse_instr so it doesn't modify *regs")
Signed-off-by: Naveen N. Rao <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux into fixes
Merge one commit from Scott which I missed while away.
|
|
On recent Intel platforms (Haswell, Broadwell, Skylake, ApolloLake,
KabyLake, ...), the IEC Coding Type (ICT) bitfield in the Digital
Converter Control #3 needs to be set explicitly for HDMI/DisplayPort
High Bit Rate (HBR) audio playback to work. This was not required in
earlier platforms when HBR was first introduced. The ICT bits are
defined in Section 7.3.3.9 of the HDaudio 1.0a specification.
Since the ICT bitfield was not specified for HDAudio 1.0 devices
(before 2009), we only program it on machines more recent than
Haswell.
We tested that this fix is not needed on Baytrail-I (MinnowBoard
Turbot) and believe by extension it also does not apply to Braswell.
[ Moved AC_VERB_SET_DIGI_CONVERT_3 definition to the right place
by tiwai ]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98797
Signed-off-by: Sriram Periyasamy <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Subhransu S. Prusty <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
When two adjacent TX SGL are processed and parts of both TX SGLs
are pulled into the per-request TX SGL, the wrong per-request
TX SGL entries were updated.
This fixes a NULL pointer dereference when a cipher implementation walks
the TX SGL where some of the SGL entries were NULL.
Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory...")
Signed-off-by: Stephan Mueller <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When built using multi_v7_defconfig, driver does not work on LS1021A:
[...]
caam 1700000.crypto: can't identify CAAM ipg clk: -2
caam: probe of 1700000.crypto failed with error -2
[...]
It turns out we have to detect at runtime whether driver is running
on an i.MX platform or not.
Cc: <[email protected]>
Fixes: 6c3af9559352 ("crypto: caam - add support for LS1021A")
Signed-off-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
All older compiler versions up to gcc-4.9 produce these
harmless warnings:
drivers/crypto/inside-secure/safexcel_cipher.c:389:9: warning: missing braces around initializer [-Wmissing-braces]
drivers/crypto/inside-secure/safexcel_cipher.c:389:9: warning: (near initialization for ‘result.completion’) [-Wmissing-braces]
drivers/crypto/inside-secure/safexcel_hash.c:422:9: warning: missing braces around initializer [-Wmissing-braces]
drivers/crypto/inside-secure/safexcel_hash.c:422:9: warning: (near initialization for ‘result.completion’) [-Wmissing-braces]
This changes the syntax to something that works on all versions
without warnings.
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Antoine Tenart <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Today, md5sum fails with error -ENOKEY because a setkey
function is set for non hmac hashing algs, see strace output below:
mmap(NULL, 378880, PROT_READ, MAP_SHARED, 6, 0) = 0x77f50000
accept(3, 0, NULL) = 7
vmsplice(5, [{"bin/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 378880}], 1, SPLICE_F_MORE|SPLICE_F_GIFT) = 262144
splice(4, NULL, 7, NULL, 262144, SPLICE_F_MORE) = -1 ENOKEY (Required key not available)
write(2, "Generation of hash for file kcap"..., 50) = 50
munmap(0x77f50000, 378880) = 0
This patch ensures that setkey() function is set only
for hmac hashing.
Cc: <[email protected]>
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
md5sum on some files gives wrong result
Exemple:
With the md5sum from libkcapi:
c15115c05bad51113f81bdaee735dd09 test
With the original md5sum:
bbdf41d80ba7e8b2b7be3a0772be76cb test
This patch fixes this issue
Cc: <[email protected]>
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Kernel crypto tests report the following error at startup
[ 2.752626] alg: hash: Test 4 failed for sha224-talitos
[ 2.757907] 00000000: 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0
00000010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22
This patch fixes it
Cc: <[email protected]>
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R13 instead of RBP. Both are callee-saved registers, so the
substitution is straightforward.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Mix things up a little bit to get rid of the RBP usage, without hurting
performance too much. Use RDI instead of RBP for the TBL pointer. That
will clobber CTX, so spill CTX onto the stack and use R12 to read it in
the outer loop. R12 is used as a non-persistent temporary variable
elsewhere, so it's safe to use.
Also remove the unused y4 variable.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Swap the usages of R12 and RBP. Use R12 for the TBL register, and use
RBP to store the pre-aligned stack pointer.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
There's no need to use RBP as a temporary register for the TBL value,
because it always stores the same value: the address of the K256 table.
Instead just reference the address of K256 directly.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Swap the usages of R12 and RBP. Use R12 for the TBL register, and use
RBP to store the pre-aligned stack pointer.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Swap the usages of R12 and RBP. Use R12 for the REG_D register, and use
RBP to store the pre-aligned stack pointer.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R11 instead of RBP. Since R11 isn't a callee-saved register, it
doesn't need to be saved and restored on the stack.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use RSI instead of RBP for RT1. Since RSI is also used as a the 'dst'
function argument, it needs to be saved on the stack until the argument
is needed.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R15 instead of RBP. R15 can't be used as the RID1 register because
of x86 instruction encoding limitations. So use R15 for CTX and RDI for
CTX. This means that CTX is no longer an implicit function argument.
Instead it needs to be explicitly copied from RDI.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R15 instead of RBP. R15 can't be used as the RID1 register because
of x86 instruction encoding limitations. So use R15 for CTX and RDI for
CTX. This means that CTX is no longer an implicit function argument.
Instead it needs to be explicitly copied from RDI.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R12 instead of RBP. Both are callee-saved registers, so the
substitution is straightforward.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R12 instead of RBP. R12 can't be used as the RT0 register because
of x86 instruction encoding limitations. So use R12 for CTX and RDI for
CTX. This means that CTX is no longer an implicit function argument.
Instead it needs to be explicitly copied from RDI.
Reported-by: Eric Biggers <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Eric Biggers <[email protected]>
Acked-by: Eric Biggers <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
During the change to use aligned buffers, the deallocation code path was
not updated correctly. The current code tries to free the aligned buffer
pointer and not the original buffer pointer as it is supposed to.
Thus, the code is updated to free the original buffer pointer and set
the aligned buffer pointer that is used throughout the code to NULL.
Fixes: 3cfc3b9721123 ("crypto: drbg - use aligned buffers")
CC: <[email protected]>
CC: Herbert Xu <[email protected]>
Signed-off-by: Stephan Mueller <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Commit c311c797998c ("cpumask: make "nr_cpumask_bits" unsigned")
modified mipspmu_event_init() to cast the struct perf_event cpu field to
an unsigned integer before it is compared with nr_cpumask_bits (and
*ahem* did so without copying the linux-mips mailing list or any MIPS
developers...). This is broken because the cpu field may be -1 for
events which follow a process rather than being affine to a particular
CPU. When this is the case the cast to an unsigned int results in a
value equal to ULONG_MAX, which is always greater than nr_cpumask_bits
so we always fail mipspmu_event_init() and return -ENODEV.
The check against nr_cpumask_bits seems nonsensical anyway, so this
patch simply removes it. The cpu field is going to either be -1 or a
valid CPU number. Comparing it with nr_cpumask_bits is effectively
checking that it's a valid cpu number, but it seems safe to rely on the
core perf events code to ensure that's the case.
The end result is that this fixes use of perf on MIPS when not
constraining events to a particular CPU, and fixes the "perf list hw"
command which fails to list any events without this.
Signed-off-by: Paul Burton <[email protected]>
Fixes: c311c797998c ("cpumask: make "nr_cpumask_bits" unsigned")
Cc: Alexey Dobriyan <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Cc: stable <[email protected]> # v4.12+
Patchwork: https://patchwork.linux-mips.org/patch/17323/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Add aliases for serial and ethernet nodes. Serial
aliases help keep order of tty nodes fixed and
ethernet alias is used by bootloader to setup mac
address correctly.
Reported-by: Adam Ford <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Fixes: dd7deaf218bf ("ARM: davinci: da850: add DT node for ethernet")
Signed-off-by: Sekhar Nori <[email protected]>
|
|
Signed-off-by: Ronnie Sahlberg <[email protected]>
Signed-off-by: Steve French <[email protected]>
|
|
It can be confusing if user ends up authenticated as guest but they
requested signing (server will return error validating signed packets)
so add log message for this.
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Ronnie Sahlberg <[email protected]>
CC: Stable <[email protected]>
|
|
Multi-dialect negotiate patch had a minor endian error.
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Ronnie Sahlberg <[email protected]>
CC: Stable <[email protected]> # 4.13+
|
|
The driver was not properly configuring firmware with regard to the
type of scan. It always performed an active scan even when user-space
was requesting for passive scan, ie. the scan request was done without
any SSIDs specified.
Cc: [email protected] # v4.0.x
Reported-by: Huang, Jiangyang <[email protected]>
Reviewed-by: Hante Meuleman <[email protected]>
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Franky Lin <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
Upon handling the firmware notification for scans the length was
checked properly and may result in corrupting kernel heap memory
due to buffer overruns. This fix addresses CVE-2017-0786.
Cc: [email protected] # v4.0.x
Cc: Kevin Cernekee <[email protected]>
Reviewed-by: Hante Meuleman <[email protected]>
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Franky Lin <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
Commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via
stop-api only on Hotplug") clears the PECE1 bit of the LPCR via
stop-api during CPU-Hotplug to prevent wakeup due to a decrementer on
an offlined CPU which is in a deep stop state.
In the case where the stop-api support is found to be lacking, the
commit 785a12afdb4a ("powerpc/powernv/idle: Disable LOSE_FULL_CONTEXT
states when stop-api fails") disables deep states that lose hypervisor
context. Thus in this case, the offlined CPU will be put to some
shallow idle state.
However, we currently unconditionally clear the PECE1 in LPCR via
stop-api during CPU-Hotplug even when deep states are disabled due to
stop-api failure.
Fix this by clearing PECE1 of LPCR via stop-api during CPU-Hotplug
*only* when the offlined CPU will be put to a deep state that loses
hypervisor context.
Fixes: 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via stop-api only on Hotplug")
Reported-by: Pavithra Prakash <[email protected]>
Signed-off-by: Gautham R. Shenoy <[email protected]>
Reviewed-by: Nicholas Piggin <[email protected]>
Tested-by: Pavithra Prakash <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
mullw should do a 32 bit signed multiply and create a 64 bit signed
result. It currently truncates the result to 32 bits.
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
mcrf broke when we changed analyse_instr() to not modify the register
state. The instruction writes to the CR, so we need to store the result
in op->ccval, not op->val.
Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs")
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
set_cr0() broke when we changed analyse_instr() to not modify the
register state. Instead of looking at regs->gpr[x] which has not
been updated yet, we need to look at op->val.
Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs")
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Commit cd63f3c ("powerpc/tm: Fix saving of TM SPRs in core dump")
added code to access TM SPRs in flush_tmregs_to_thread(). However
flush_tmregs_to_thread() does not check if TM feature is available on
CPU before trying to access TM SPRs in order to copy live state to
thread structures. flush_tmregs_to_thread() is indeed guarded by
CONFIG_PPC_TRANSACTIONAL_MEM but it might be the case that kernel
was compiled with CONFIG_PPC_TRANSACTIONAL_MEM enabled and ran on
a CPU without TM feature available, thus rendering the execution
of TM instructions that are treated by the CPU as illegal instructions.
The fix is just to add proper checking in flush_tmregs_to_thread()
if CPU has the TM feature before accessing any TM-specific resource,
returning immediately if TM is no available on the CPU. Adding
that checking in flush_tmregs_to_thread() instead of in places
where it is called, like in vsr_get() and vsr_set(), is better because
avoids the same problem cropping up elsewhere.
Cc: [email protected] # v4.13+
Fixes: cd63f3c ("powerpc/tm: Fix saving of TM SPRs in core dump")
Signed-off-by: Gustavo Romero <[email protected]>
Reviewed-by: Cyril Bur <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Kernel crashes if power pmu is not registered and user tries to dump
regs with 'echo p > /proc/sysrq-trigger'. Sample log:
Unable to handle kernel paging request for data at address 0x00000008
Faulting instruction address: 0xc0000000000d52f0
NIP [c0000000000d52f0] perf_event_print_debug+0x10/0x230
LR [c00000000058a938] sysrq_handle_showregs+0x38/0x50
Call Trace:
printk+0x38/0x4c (unreliable)
__handle_sysrq+0xe4/0x270
write_sysrq_trigger+0x64/0x80
proc_reg_write+0x80/0xd0
__vfs_write+0x40/0x200
vfs_write+0xc8/0x240
SyS_write+0x60/0x110
system_call+0x58/0x6c
Fixes: 5f6d0380c640 ("powerpc/perf: Define perf_event_print_debug() to print PMU register values")
Signed-off-by: Ravi Bangoria <[email protected]>
Reviewed-by: Kamalesh Babulal <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Commit eb3b705aaed9 ("ALSA: Make CONFIG_SND_OSSEMUL user-selectable")
means we need to set CONFIG_SND_OSSEMUL in our configs, otherwise we
lose some of the SND symbols.
And commit 0181307abc1d ("ALSA: seq: Reorganize kconfig and build")
reorganised things, which causes the churn.
Signed-off-by: Michael Ellerman <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is a set of five small fixes: one is a null deref fix which is
pretty critical for the fc transport class and one fixes a potential
security issue of sg leaking kernel information"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE
scsi: sg: factor out sg_fill_request_table()
scsi: sd: Remove unnecessary condition in sd_read_block_limits()
scsi: acornscsi: fix build error
scsi: scsi_transport_fc: fix NULL pointer dereference in fc_bsg_job_timeout
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
Pull si_code fix from Eric Biederman:
"When sorting out the si_code ambiguity fcntl I accidentally overshot
and included SIGPOLL as well. Ooops! This is my trivial fix for that.
Vince Weaver caught this when it landed in your tree with his
perf_event_tests many of which started failing because the si_code
changed"
Quoth Vince Weaver:
"I've tested with this patch applied and can confirm all of my tests
now pass again"
Fixes: d08477aa975e ("fcntl: Don't use ambiguous SIG_POLL si_codes")
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
fcntl: Don't set si_code to SI_SIGIO when sig == SIGPOLL
|
|
Pull KVM fixes from Radim Krčmář:
- fix build without CONFIG_HAVE_KVM_IRQ_ROUTING
- fix NULL access in x86 CR access
- fix race with VMX posted interrups
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: VMX: remove WARN_ON_ONCE in kvm_vcpu_trigger_posted_interrupt
KVM: VMX: do not change SN bit in vmx_update_pi_irte()
KVM: x86: Fix the NULL pointer parameter in check_cr_write()
Revert "KVM: Don't accept obviously wrong gsi values via KVM_IRQFD"
|
|
Function hdmi_mode_fixup() used bare list_for_each entry, which was
unsafe and caused memory corruption detected by kasan.
It now uses drm_for_each_connector_iter macro, which is now recommended
by the documentation and safe.
Signed-off-by: Maciej Purski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Samba rejects SMB3.1.1 dialect (vers=3.1.1) negotiate requests from
the kernel client due to the two byte pad at the end of the negotiate
contexts.
CC: Stable <[email protected]>
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Ronnie Sahlberg <[email protected]>
|