From: Hemant Kumar <hemantk(a)codeaurora.org>
Upon usb composition switch there is possibility of ep0 file
release happening after gadget driver bind. In case of composition
switch from adb to a non-adb composition gadget will never gets
bound again resulting into failure of usb device enumeration. Fix
this issue by checking FFS_FL_BOUND flag and avoid extra
gadget driver unbind if it is already done as part of composition
switch.
This fixes adb reconnection error reported on Android running
v4.4 and above kernel versions. Verified on Hikey running vanilla
v4.15-rc7 + few out of tree Mali patches.
Reviewed-at: https://android-review.googlesource.com/#/c/582632/
Cc: Felipe Balbi <balbi(a)kernel.org>
Cc: Greg KH <gregkh(a)linux-foundation.org>
Cc: Michal Nazarewicz <mina86(a)mina86.com>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Dmitry Shmidt <dimitrysh(a)google.com>
Cc: Badhri <badhri(a)google.com>
Cc: Android Kernel Team <kernel-team(a)android.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Hemant Kumar <hemantk(a)codeaurora.org>
[AmitP: Cherry-picked it from android-4.14 and updated the commit log]
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
---
drivers/usb/gadget/function/f_fs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index b6cf5ab5a0a1..f9bd351637cd 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3700,7 +3700,8 @@ static void ffs_closed(struct ffs_data *ffs)
ci = opts->func_inst.group.cg_item.ci_parent->ci_parent;
ffs_dev_unlock();
- unregister_gadget_item(ci);
+ if (test_bit(FFS_FL_BOUND, &ffs->flags))
+ unregister_gadget_item(ci);
return;
done:
ffs_dev_unlock();
--
2.7.4
Some distributions have turned on the reset attack mitigation feature,
which is designed to force the platform to clear the contents of RAM if
the machine is shut down uncleanly. However, in order for the platform
to be able to determine whether the shutdown was clean or not, userspace
has to be configured to clear the MemoryOverwriteRequest flag on
shutdown - otherwise the firmware will end up clearing RAM on every
reboot, which is unnecessarily time consuming. Add some additional
clarity to the kconfig text to reduce the risk of systems being
configured this way.
Signed-off-by: Matthew Garrett <mjg59(a)google.com>
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: linux-efi(a)vger.kernel.org
Cc: stable(a)vger.kernel.org
---
drivers/firmware/efi/Kconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 2b4c39fdfa91..86210f75d233 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -159,7 +159,10 @@ config RESET_ATTACK_MITIGATION
using the TCG Platform Reset Attack Mitigation specification. This
protects against an attacker forcibly rebooting the system while it
still contains secrets in RAM, booting another OS and extracting the
- secrets.
+ secrets. This should only be enabled when userland is configured to
+ clear the MemoryOverwriteRequest flag on clean shutdown after secrets
+ have been evicted, since otherwise it will trigger even on clean
+ reboots.
endmenu
--
2.16.0.rc0.223.g4a4ac83678-goog
On Mon, Jan 08, 2018 at 09:26:10PM +0100, Yves-Alexis Perez wrote:
> On Mon, 2018-01-08 at 19:26 +0100, Willy Tarreau wrote:
> > You're totally right, I discovered during my later developments that
> > indeed PCID is not exposed there. So we take the hit of a full TLB
> > flush twice per syscall.
>
> So I really think it might make sense to redo the tests with PCID, because the
> assumptions you're basing your patch series on might actually not hold.
I'll have to do it on the bare-metal server soon anyway.
Cheers,
Willy
From: Viktor Slavkovic <viktors(a)google.com>
A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a
race condition when mmap is called. After the !asma->file check, before
setting asma->size, asma->file can be set in mmap. That would result in
having different asma->size than the mapped memory size. Combined with
ASHMEM_UNPIN ioctl and shrinker invocation, this can result in memory
corruption.
Signed-off-by: Viktor Slavkovic <viktors(a)google.com>
Cc: stable(a)vger.kernel.org
---
drivers/staging/android/ashmem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 0f695df14c9d..372ce9913e6d 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -765,10 +765,12 @@ static long ashmem_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
break;
case ASHMEM_SET_SIZE:
ret = -EINVAL;
+ mutex_lock(&ashmem_mutex);
if (!asma->file) {
ret = 0;
asma->size = (size_t)arg;
}
+ mutex_unlock(&ashmem_mutex);
break;
case ASHMEM_GET_SIZE:
ret = asma->size;
--
2.16.0.rc0.223.g4a4ac83678-goog
Hi Yves-Alexis,
On Mon, Jan 08, 2018 at 06:07:54PM +0100, Yves-Alexis Perez wrote:
> On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> > - the highest performance impact on VMs comes from having PTI on the
> > guest kernel (-45%). At this point it makes no difference whether
> > the host kernel has it or not.
>
> Hi Willy,
>
> out of curiosity, is the pcid/invpcid flags exposed to and used by your guest
> CPU? It might very well that the PCID optimisations are not used by the guests
> here, and it might be worth either checking on bare metal or with the PCID
> optimisations enabled.
You're totally right, I discovered during my later developments that
indeed PCID is not exposed there. So we take the hit of a full TLB
flush twice per syscall.
Willy
On Mon, Jan 8, 2018 at 3:05 PM, kernelci.org bot <bot(a)kernelci.org> wrote:
>
> stable-rc/linux-4.4.y build: 178 builds: 7 failed, 171 passed, 8 errors (v4.4.110-23-g49278737d445)
> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.110-23-…
> Tree: stable-rc
> Branch: linux-4.4.y
> Git Describe: v4.4.110-23-g49278737d445
> Git Commit: 49278737d4458032fb523dfe5451b441c04c5b73
> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Built: 4 unique architectures
>
> Build Failures Detected:
>
> x86: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
> allnoconfig FAIL
> i386_defconfig FAIL
> tinyconfig FAIL
I missed these earlier, since the kernelci summary output doesn't
print link errors:
arch/x86/kernel/setup.o: In function `vsyscall_enabled':
setup.c:(.text+0x10): multiple definition of `vsyscall_enabled'
arch/x86/kernel/time.o:time.c:(.text+0x10): first defined here
arch/x86/kernel/rtc.o: In function `vsyscall_enabled':
rtc.c:(.text+0x0): multiple definition of `vsyscall_enabled'
arch/x86/kernel/time.o:time.c:(.text+0x10): first defined here
arch/x86/kernel/cpu/built-in.o: In function `vsyscall_enabled':
(.text+0xbc0): multiple definition of `vsyscall_enabled'
This comes from 0cbf2b590bea ("Map the vsyscall page with _PAGE_USER")
which adds a line 'bool vsyscall_enabled(void) { return false; }' that
presumably
should have been 'static inline'.
Arnd
On 01/08/2018 01:05 AM, Yves-Alexis Perez wrote:
> On Mon, 2018-01-08 at 03:25 +0000, Ben Hutchings wrote:
>> This is with the full patch set applied (and a fix for NMI handling
>> that wasn't in 3.16.53-rc1):
>> https://www.decadent.org.uk/ben/tmp/linux-image-3.16.52_3.16.52-50_amd64.deb
I booted this. It crashes in *secondary* CPU startup when it sets
CR4.PCIDE while still in 32-bit protected mode. That's illegal.
Plain 3.16 doesn't do this:
https://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-kaiser.git/tree/a…
> /* Enable PAE mode and PGE */
> movl $(X86_CR4_PAE | X86_CR4_PGE), %ecx
> movq %rcx, %cr4
So I suspect the "Enable PAE and PGE" area is wrong.
On Mon, Jan 8, 2018 at 12:25 PM, kernelci.org bot <bot(a)kernelci.org> wrote:
>
> stable-rc/linux-4.4.y build: 178 builds: 4 failed, 174 passed, 8 errors (v4.4.110-18-g5da3d9af3a4b)
> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.110-18-…
> Tree: stable-rc
> Branch: linux-4.4.y
> Git Describe: v4.4.110-18-g5da3d9af3a4b
> Git Commit: 5da3d9af3a4b90d3c5ab19f9ad1dbb7d237edcf9
> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Built: 4 unique architectures
>
> Build Failures Detected:
>
> arm: gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> cm_x300_defconfig FAIL
> mvebu_v7_defconfig FAIL
> pxa3xx_defconfig FAIL
> raumfeld_defconfig FAIL
>
> mvebu_v7_defconfig (arm) — FAIL, 2 errors, 0 warnings, 0 section mismatches
>
> Errors:
> drivers/mtd/nand/pxa3xx_nand.c:918:2: error: duplicate case value
> drivers/mtd/nand/pxa3xx_nand.c:915:2: error: previously used here
Hi Greg,
Commit fee4380f368e ("mtd: nand: pxa3xx: Fix READOOB implementation") was
apparently backported in error, it looks like it should just be
dropped here in 4.4.y.
The commit lists 'Fixes: 43bcfd2bb24a ("mtd: nand: pxa3xx: Add driver-specific
ECC BCH support")', that commit was merged into v4.14, so backporting the
fix further is probably not appropriate for 4.9 or earlier kernels either.
The duplicate case statement only happens before linux-4.6, as commit
c2cdace755b5 ("mtd: nand: pxa3xx_nand: add support for partial chunks")'
removed a previous 'case READOOB' statement in this driver, so the build
regression appears only in 4.4 but not 4.9.
Arnd