Buildresult: powerpc-next/ppc64_defconfig+NO_TM/powerpc-gcc5 built on Apr 4 2018, 23:49

kisskb

Revisions | Branches | Compilers | Configs | Build Results | Build Failures |

Status:	OK
Date/Time:	Apr 4 2018, 23:49
Duration:	0:02:42.870186
Builder:	ka2
Revision:	cxl: Fix possible deadlock when processing page faults from cxllib (`ad7b4e8022b9864c075fe71e1328b1d25cad82f6)`
Target:	powerpc-next/ppc64_defconfig+NO_TM/powerpc-gcc5
Branch:	powerpc-next
Compiler:	powerpc-gcc5 (powerpc64-linux-gcc (GCC) 5.3.0)
Config:	ppc64_defconfig+NO_TM (download)
Log:	Download original Possible warnings (1) WARNING: modpost: Found 2 section mismatch(es). Full Log # git rev-parse -q --verify ad7b4e8022b9864c075fe71e1328b1d25cad82f6^{commit} ad7b4e8022b9864c075fe71e1328b1d25cad82f6 already have revision, skipping fetch # git checkout -q -f -B kisskb ad7b4e8022b9864c075fe71e1328b1d25cad82f6 # git clean -qxdf # < git log -1 # commit ad7b4e8022b9864c075fe71e1328b1d25cad82f6 # Author: Frederic Barrat <fbarrat@linux.vnet.ibm.com> # Date: Tue Apr 3 15:54:02 2018 +0200 # # cxl: Fix possible deadlock when processing page faults from cxllib # # cxllib_handle_fault() is called by an external driver when it needs to # have the host resolve page faults for a buffer. The buffer can cover # several pages and VMAs. The function iterates over all the pages used # by the buffer, based on the page size of the VMA. # # To ensure some stability while processing the faults, the thread T1 # grabs the mm->mmap_sem semaphore with read access (R1). However, when # processing a page fault for a single page, one of the underlying # functions, copro_handle_mm_fault(), also grabs the same semaphore with # read access (R2). So the thread T1 takes the semaphore twice. # # If another thread T2 tries to access the semaphore in write mode W1 # (say, because it wants to allocate memory and calls 'brk'), then that # thread T2 will have to wait because there's a reader (R1). If the # thread T1 is processing a new page at that time, it won't get an # automatic grant at R2, because there's now a writer thread # waiting (T2). And we have a deadlock. # # The timeline is: # 1. thread T1 owns the semaphore with read access R1 # 2. thread T2 requests write access W1 and waits # 3. thread T1 requests read access R2 and waits # # The fix is for the thread T1 to release the semaphore R1 once it got # the information it needs from the current VMA. The address space/VMAs # could evolve while T1 iterates over the full buffer, but in the # unlikely case where T1 misses a page, the external driver will raise a # new page fault when retrying the memory access. # # Fixes: 3ced8d730063 ("cxl: Export library to support IBM XSL") # Cc: stable@vger.kernel.org # 4.13+ # Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> # Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> # < /opt/cross/kisskb/gcc-5.3.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc --version # < git log --format=%s --max-count=1 ad7b4e8022b9864c075fe71e1328b1d25cad82f6 # < make -s -j 48 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64_defconfig+NO_TM_powerpc-5.3 CROSS_COMPILE=/opt/cross/kisskb/gcc-5.3.0-nolibc/powerpc64-linux/bin/powerpc64-linux- ppc64_defconfig # Added to kconfig CONFIG_PPC_TRANSACTIONAL_MEM=n # yes \n \| make -s -j 48 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64_defconfig+NO_TM_powerpc-5.3 CROSS_COMPILE=/opt/cross/kisskb/gcc-5.3.0-nolibc/powerpc64-linux/bin/powerpc64-linux- oldconfig yes: standard output: Broken pipe yes: write error # make -s -j 48 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64_defconfig+NO_TM_powerpc-5.3 CROSS_COMPILE=/opt/cross/kisskb/gcc-5.3.0-nolibc/powerpc64-linux/bin/powerpc64-linux- WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' Completed OK # rm -rf /kisskb/build/powerpc-next_ppc64_defconfig+NO_TM_powerpc-5.3 # Build took: 0:02:42.870186

© Michael Ellerman 2006-2018.