* Re: [PATCH v2 1/2] powerpc/rtas: Restrict RTAS requests from userspace
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev; +Cc: nathanl, leobras.c, stable, dja
In-Reply-To: <20200820044512.7543-1-ajd@linux.ibm.com>
On Thu, 20 Aug 2020 14:45:12 +1000, Andrew Donnellan wrote:
> A number of userspace utilities depend on making calls to RTAS to retrieve
> information and update various things.
>
> The existing API through which we expose RTAS to userspace exposes more
> RTAS functionality than we actually need, through the sys_rtas syscall,
> which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
> want with arbitrary arguments.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/rtas: Restrict RTAS requests from userspace
https://git.kernel.org/powerpc/c/bd59380c5ba4147dcbaad3e582b55ccfd120b764
[2/2] selftests/powerpc: Add a rtas_filter selftest
https://git.kernel.org/powerpc/c/dc9af82ea0614bb138705d1f5230d53b3b1dfb83
cheers
^ permalink raw reply
* Re: [PATCH V2] powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: maddy, linuxppc-dev
In-Reply-To: <1600672204-1610-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Mon, 21 Sep 2020 03:10:04 -0400, Athira Rajeev wrote:
> PMU counter support functions enforces event constraints for group of
> events to check if all events in a group can be monitored. Incase of
> event codes using PMC5 and PMC6 ( 500fa and 600f4 respectively ),
> not all constraints are applicable, say the threshold or sample bits.
> But current code includes pmc5 and pmc6 in some group constraints (like
> IC_DC Qualifier bits) which is actually not applicable and hence results
> in those events not getting counted when scheduled along with group of
> other events. Patch fixes this by excluding PMC5/6 from constraints
> which are not relevant for it.
Applied to powerpc/next.
[1/1] powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints
https://git.kernel.org/powerpc/c/3b6c3adbb2fa42749c3d38cfc4d4d0b7e096bb7b
cheers
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the powerpc tree
From: Michael Ellerman @ 2020-10-07 2:39 UTC (permalink / raw)
To: Stephen Rothwell, PowerPC
Cc: Linux Next Mailing List, Athira Rajeev, Linux Kernel Mailing List
In-Reply-To: <20201007000544.48aabc91@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> In commit
>
> 3b6c3adbb2fa ("powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints")
>
> Fixes tag
>
> Fixes: 7ffd948 ("powerpc/perf: factor out power8 pmu functions")
>
> has these problem(s):
>
> - SHA1 should be at least 12 digits long
> Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
> or later) just making sure it is not set (or set to "auto").
>
> Since Michael doesn't generally rebase his tree, this is more to be
> remebered for next time.
Yeah, if it was the wrong SHA I would rebase, but not just for a short
SHA.
You can avoid this in future by doing:
$ git config --add core.abbrev 12
$ git config --add pretty.fixes 'Fixes: %h ("%s")'
$ git config --add alias.showfix 'log -1 --format=fixes'
Then you can do:
$ git showfix 7ffd948
Fixes: 7ffd948fae4c ("powerpc/perf: factor out power8 pmu functions")
cheers
^ permalink raw reply
* [powerpc:next] BUILD REGRESSION 72cdd117c449896c707fc6cfe5b90978160697d0
From: kernel test robot @ 2020-10-07 2:18 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 72cdd117c449896c707fc6cfe5b90978160697d0 pseries/hotplug-memory: hot-add: skip redundant LMB lookup
Error/Warning in current branch:
arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: junk at end of line: `@local'
arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
arch/powerpc/kernel/vdso32/gettimeofday.S:68: Error: operand out of range (3 is not between 0 and 1)
Error/Warning ids grouped by kconfigs:
clang_recent_errors
`-- powerpc-randconfig-r033-20201005
|-- arch-powerpc-kernel-vdso32-gettimeofday.S:Error:junk-at-end-of-line:local
|-- arch-powerpc-kernel-vdso32-gettimeofday.S:Error:operand-out-of-range-(-is-not-between-and-)
`-- arch-powerpc-kernel-vdso32-gettimeofday.S:Error:syntax-error-found-expected
elapsed time: 814m
configs tested: 207
configs skipped: 3
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
mips cavium_octeon_defconfig
arm hackkit_defconfig
arm socfpga_defconfig
sh r7780mp_defconfig
sh migor_defconfig
riscv allmodconfig
sh se7724_defconfig
mips pic32mzda_defconfig
m68k m5275evb_defconfig
powerpc rainier_defconfig
arm ixp4xx_defconfig
mips bcm63xx_defconfig
sh apsh4ad0a_defconfig
mips ip28_defconfig
mips omega2p_defconfig
mips pistachio_defconfig
sh se7721_defconfig
sh defconfig
arm mxs_defconfig
mips malta_defconfig
arm assabet_defconfig
arm collie_defconfig
mips ci20_defconfig
arm aspeed_g4_defconfig
powerpc ep88xc_defconfig
xtensa xip_kc705_defconfig
powerpc arches_defconfig
arm palmz72_defconfig
powerpc mpc5200_defconfig
arm zeus_defconfig
powerpc mpc834x_itx_defconfig
powerpc obs600_defconfig
powerpc mpc8313_rdb_defconfig
sh sh7710voipgw_defconfig
mips bigsur_defconfig
arm stm32_defconfig
arm iop32x_defconfig
arm tango4_defconfig
powerpc mpc7448_hpc2_defconfig
mips nlm_xlp_defconfig
sh sh7724_generic_defconfig
arm64 alldefconfig
powerpc g5_defconfig
arm sunxi_defconfig
powerpc mpc8272_ads_defconfig
arm magician_defconfig
arm lpc32xx_defconfig
mips pnx8335_stb225_defconfig
arm s3c6400_defconfig
sh se7619_defconfig
mips decstation_r4k_defconfig
mips fuloong2e_defconfig
sh microdev_defconfig
arm versatile_defconfig
powerpc skiroot_defconfig
powerpc sam440ep_defconfig
sh kfr2r09_defconfig
m68k mac_defconfig
sh se7343_defconfig
arm spear3xx_defconfig
arm imx_v6_v7_defconfig
arm mvebu_v5_defconfig
powerpc tqm8555_defconfig
mips e55_defconfig
nds32 defconfig
mips vocore2_defconfig
c6x evmc6474_defconfig
openrisc or1ksim_defconfig
sh lboxre2_defconfig
arm lpc18xx_defconfig
arm exynos_defconfig
powerpc ppa8548_defconfig
m68k q40_defconfig
sparc64 defconfig
h8300 edosk2674_defconfig
parisc generic-64bit_defconfig
sh secureedge5410_defconfig
mips ip32_defconfig
sh apsh4a3a_defconfig
arc hsdk_defconfig
arm multi_v5_defconfig
xtensa alldefconfig
mips ath79_defconfig
h8300 h8s-sim_defconfig
powerpc ge_imp3a_defconfig
mips malta_kvm_defconfig
csky alldefconfig
parisc generic-32bit_defconfig
sh se7705_defconfig
sh alldefconfig
arm footbridge_defconfig
c6x evmc6472_defconfig
sh ecovec24_defconfig
arm efm32_defconfig
mips ip27_defconfig
powerpc lite5200b_defconfig
arm omap1_defconfig
m68k hp300_defconfig
arm mv78xx0_defconfig
sh edosk7705_defconfig
nios2 alldefconfig
m68k m5208evb_defconfig
powerpc eiger_defconfig
mips tb0226_defconfig
mips nlm_xlr_defconfig
sh se7722_defconfig
m68k m5272c3_defconfig
m68k defconfig
powerpc mpc85xx_cds_defconfig
powerpc redwood_defconfig
sh rsk7269_defconfig
arm alldefconfig
arm vt8500_v6_v7_defconfig
sh espt_defconfig
m68k bvme6000_defconfig
powerpc mpc836x_mds_defconfig
powerpc mpc837x_rdb_defconfig
arc axs101_defconfig
sh landisk_defconfig
arm sama5_defconfig
sh sh7785lcr_defconfig
powerpc iss476-smp_defconfig
mips maltaup_xpa_defconfig
mips loongson3_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20201006
x86_64 randconfig-a002-20201006
x86_64 randconfig-a001-20201006
x86_64 randconfig-a005-20201006
x86_64 randconfig-a003-20201006
x86_64 randconfig-a006-20201006
i386 randconfig-a006-20201005
i386 randconfig-a005-20201005
i386 randconfig-a001-20201005
i386 randconfig-a004-20201005
i386 randconfig-a003-20201005
i386 randconfig-a002-20201005
x86_64 randconfig-a012-20201005
x86_64 randconfig-a015-20201005
x86_64 randconfig-a014-20201005
x86_64 randconfig-a013-20201005
x86_64 randconfig-a011-20201005
x86_64 randconfig-a016-20201005
i386 randconfig-a014-20201005
i386 randconfig-a015-20201005
i386 randconfig-a013-20201005
i386 randconfig-a016-20201005
i386 randconfig-a011-20201005
i386 randconfig-a012-20201005
i386 randconfig-a014-20201007
i386 randconfig-a013-20201007
i386 randconfig-a015-20201007
i386 randconfig-a016-20201007
i386 randconfig-a011-20201007
i386 randconfig-a012-20201007
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20201005
x86_64 randconfig-a002-20201005
x86_64 randconfig-a001-20201005
x86_64 randconfig-a003-20201005
x86_64 randconfig-a005-20201005
x86_64 randconfig-a006-20201005
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS d1def5df359f3f1882cc29d8baa5cd2a4861a6c6
From: kernel test robot @ 2020-10-07 2:12 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: d1def5df359f3f1882cc29d8baa5cd2a4861a6c6 Automatic merge of 'master' into merge (2020-10-05 14:10)
elapsed time: 2819m
configs tested: 196
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
mips cavium_octeon_defconfig
sh se7724_defconfig
mips pic32mzda_defconfig
m68k m5275evb_defconfig
powerpc rainier_defconfig
sh apsh4ad0a_defconfig
arm ixp4xx_defconfig
mips bcm63xx_defconfig
m68k mvme16x_defconfig
ia64 generic_defconfig
powerpc acadia_defconfig
mips bmips_be_defconfig
mips ip28_defconfig
mips omega2p_defconfig
mips pistachio_defconfig
sh se7721_defconfig
mips malta_qemu_32r6_defconfig
powerpc katmai_defconfig
mips ath79_defconfig
powerpc skiroot_defconfig
powerpc mpc5200_defconfig
arm zeus_defconfig
powerpc mpc834x_itx_defconfig
powerpc obs600_defconfig
powerpc mpc8313_rdb_defconfig
sh sh7710voipgw_defconfig
powerpc tqm8541_defconfig
arm axm55xx_defconfig
arm moxart_defconfig
mips xway_defconfig
sh ul2_defconfig
riscv rv32_defconfig
sh sh7724_generic_defconfig
arm64 alldefconfig
powerpc g5_defconfig
arm sunxi_defconfig
powerpc mpc8272_ads_defconfig
arm magician_defconfig
arm lpc32xx_defconfig
arm clps711x_defconfig
arm hisi_defconfig
powerpc stx_gp3_defconfig
powerpc ksi8560_defconfig
arm imx_v6_v7_defconfig
arm mvebu_v5_defconfig
powerpc tqm8555_defconfig
mips e55_defconfig
sh espt_defconfig
powerpc tqm8548_defconfig
powerpc makalu_defconfig
arm lpc18xx_defconfig
arm exynos_defconfig
powerpc ppa8548_defconfig
h8300 edosk2674_defconfig
parisc generic-64bit_defconfig
sh secureedge5410_defconfig
mips ip32_defconfig
sh apsh4a3a_defconfig
arc hsdk_defconfig
arm multi_v5_defconfig
xtensa alldefconfig
h8300 h8s-sim_defconfig
powerpc ge_imp3a_defconfig
mips malta_kvm_defconfig
csky alldefconfig
parisc generic-32bit_defconfig
sh se7705_defconfig
sh alldefconfig
arm footbridge_defconfig
c6x evmc6472_defconfig
sh ecovec24_defconfig
powerpc socrates_defconfig
powerpc walnut_defconfig
sh ecovec24-romimage_defconfig
sh r7785rp_defconfig
arm pxa168_defconfig
nios2 alldefconfig
m68k m5208evb_defconfig
powerpc eiger_defconfig
mips tb0226_defconfig
mips nlm_xlr_defconfig
sh se7722_defconfig
m68k m5272c3_defconfig
powerpc mpc85xx_cds_defconfig
powerpc ep88xc_defconfig
powerpc redwood_defconfig
sh rsk7269_defconfig
arm alldefconfig
powerpc mpc885_ads_defconfig
powerpc akebono_defconfig
powerpc mvme5100_defconfig
sh edosk7705_defconfig
arm vt8500_v6_v7_defconfig
sh urquell_defconfig
riscv nommu_virt_defconfig
mips mpc30x_defconfig
arm spear3xx_defconfig
m68k bvme6000_defconfig
arm palmz72_defconfig
powerpc mpc836x_mds_defconfig
powerpc mpc837x_rdb_defconfig
arc axs101_defconfig
sh landisk_defconfig
arm sama5_defconfig
sh sh7785lcr_defconfig
powerpc iss476-smp_defconfig
mips maltasmvp_eva_defconfig
powerpc mpc834x_itxgp_defconfig
s390 alldefconfig
arm h5000_defconfig
arm integrator_defconfig
arm orion5x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20201006
x86_64 randconfig-a002-20201006
x86_64 randconfig-a001-20201006
x86_64 randconfig-a005-20201006
x86_64 randconfig-a003-20201006
x86_64 randconfig-a006-20201006
i386 randconfig-a006-20201005
i386 randconfig-a005-20201005
i386 randconfig-a001-20201005
i386 randconfig-a004-20201005
i386 randconfig-a003-20201005
i386 randconfig-a002-20201005
x86_64 randconfig-a012-20201005
x86_64 randconfig-a015-20201005
x86_64 randconfig-a014-20201005
x86_64 randconfig-a013-20201005
x86_64 randconfig-a011-20201005
x86_64 randconfig-a016-20201005
i386 randconfig-a014-20201005
i386 randconfig-a015-20201005
i386 randconfig-a013-20201005
i386 randconfig-a016-20201005
i386 randconfig-a011-20201005
i386 randconfig-a012-20201005
i386 randconfig-a014-20201007
i386 randconfig-a013-20201007
i386 randconfig-a015-20201007
i386 randconfig-a016-20201007
i386 randconfig-a011-20201007
i386 randconfig-a012-20201007
riscv nommu_k210_defconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20201005
x86_64 randconfig-a002-20201005
x86_64 randconfig-a001-20201005
x86_64 randconfig-a003-20201005
x86_64 randconfig-a005-20201005
x86_64 randconfig-a006-20201005
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test 76/183] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
From: kernel test robot @ 2020-10-06 20:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: clang-built-linux, kbuild-all, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 15939 bytes --]
Hi Michael,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: 72cdd117c449896c707fc6cfe5b90978160697d0
commit: 231b232df8f67e7d37af01259c21f2a131c3911e [76/183] powerpc/64: Make VDSO32 track COMPAT on 64-bit
config: powerpc-randconfig-r033-20201005 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 1127662c6dc2a276839c75a42238b11a3ad00f32)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=231b232df8f67e7d37af01259c21f2a131c3911e
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 231b232df8f67e7d37af01259c21f2a131c3911e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages:
>> arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
>> arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: junk at end of line: `@local'
arch/powerpc/kernel/vdso32/gettimeofday.S:68: Warning: invalid register expression
>> arch/powerpc/kernel/vdso32/gettimeofday.S:68: Error: operand out of range (3 is not between 0 and 1)
arch/powerpc/kernel/vdso32/gettimeofday.S:68: Error: missing operand
arch/powerpc/kernel/vdso32/gettimeofday.S:69: Warning: invalid register expression
arch/powerpc/kernel/vdso32/gettimeofday.S:69: Error: operand out of range (3 is not between 0 and 1)
arch/powerpc/kernel/vdso32/gettimeofday.S:69: Error: missing operand
arch/powerpc/kernel/vdso32/gettimeofday.S:72: Warning: invalid register expression
arch/powerpc/kernel/vdso32/gettimeofday.S:72: Error: operand out of range (3 is not between 0 and 1)
arch/powerpc/kernel/vdso32/gettimeofday.S:72: Error: missing operand
arch/powerpc/kernel/vdso32/gettimeofday.S:73: Warning: invalid register expression
arch/powerpc/kernel/vdso32/gettimeofday.S:73: Error: operand out of range (3 is not between 0 and 1)
arch/powerpc/kernel/vdso32/gettimeofday.S:73: Error: missing operand
arch/powerpc/kernel/vdso32/gettimeofday.S:86: Error: syntax error; found `@', expected `,'
arch/powerpc/kernel/vdso32/gettimeofday.S:86: Error: junk at end of line: `@local'
arch/powerpc/kernel/vdso32/gettimeofday.S:110: Warning: invalid register expression
arch/powerpc/kernel/vdso32/gettimeofday.S:110: Error: operand out of range (8 is not between 0 and 1)
arch/powerpc/kernel/vdso32/gettimeofday.S:110: Error: missing operand
arch/powerpc/kernel/vdso32/gettimeofday.S:144: Warning: invalid register expression
arch/powerpc/kernel/vdso32/gettimeofday.S:144: Error: missing operand
arch/powerpc/kernel/vdso32/gettimeofday.S:213: Warning: invalid register expression
arch/powerpc/kernel/vdso32/gettimeofday.S:213: Error: operand out of range (4 is not between 0 and 1)
arch/powerpc/kernel/vdso32/gettimeofday.S:213: Error: missing operand
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
vim +40 arch/powerpc/kernel/vdso32/gettimeofday.S
597bc5c00b666fe Paul Mackerras 2008-10-27 22
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 23 .text
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 24 /*
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 25 * Exact prototype of gettimeofday
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 26 *
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 27 * int __kernel_gettimeofday(struct timeval *tv, struct timezone *tz);
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 28 *
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 29 */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 30 V_FUNCTION_BEGIN(__kernel_gettimeofday)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 31 .cfi_startproc
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 32 mflr r12
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 33 .cfi_register lr,r12
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 34
bfc2eae0ad72a43 Christophe Leroy 2019-12-02 35 mr. r10,r3 /* r10 saves tv */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 36 mr r11,r4 /* r11 saves tz */
ec0895f08f99515 Christophe Leroy 2019-12-02 37 get_datapage r9, r0
74609f4536f2b8f Tony Breeds 2007-06-26 38 beq 3f
6e2f9e9cfd560f5 Christophe Leroy 2019-12-02 39 LOAD_REG_IMMEDIATE(r7, 1000000) /* load up USEC_PER_SEC */
8fd63a9ea752846 Paul Mackerras 2010-06-20 @40 bl __do_get_tspec@local /* get sec/usec from tb & kernel */
8fd63a9ea752846 Paul Mackerras 2010-06-20 41 stw r3,TVAL32_TV_SEC(r10)
8fd63a9ea752846 Paul Mackerras 2010-06-20 42 stw r4,TVAL32_TV_USEC(r10)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 43
74609f4536f2b8f Tony Breeds 2007-06-26 44 3: cmplwi r11,0 /* check if tz is NULL */
bfc2eae0ad72a43 Christophe Leroy 2019-12-02 45 mtlr r12
bfc2eae0ad72a43 Christophe Leroy 2019-12-02 46 crclr cr0*4+so
bfc2eae0ad72a43 Christophe Leroy 2019-12-02 47 li r3,0
bfc2eae0ad72a43 Christophe Leroy 2019-12-02 48 beqlr
bfc2eae0ad72a43 Christophe Leroy 2019-12-02 49
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 50 lwz r4,CFG_TZ_MINUTEWEST(r9)/* fill tz */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 51 lwz r5,CFG_TZ_DSTTIME(r9)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 52 stw r4,TZONE_TZ_MINWEST(r11)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 53 stw r5,TZONE_TZ_DSTTIME(r11)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 54
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 55 blr
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 56 .cfi_endproc
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 57 V_FUNCTION_END(__kernel_gettimeofday)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 58
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 59 /*
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 60 * Exact prototype of clock_gettime()
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 61 *
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 62 * int __kernel_clock_gettime(clockid_t clock_id, struct timespec *tp);
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 63 *
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 64 */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 65 V_FUNCTION_BEGIN(__kernel_clock_gettime)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 66 .cfi_startproc
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 67 /* Check for supported clock IDs */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 @68 cmpli cr0,r3,CLOCK_REALTIME
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 69 cmpli cr1,r3,CLOCK_MONOTONIC
0c37ec2aa88bd8a Benjamin Herrenschmidt 2005-11-14 70 cror cr0*4+eq,cr0*4+eq,cr1*4+eq
654abc69ef2e697 Christophe Leroy 2019-12-02 71
654abc69ef2e697 Christophe Leroy 2019-12-02 72 cmpli cr5,r3,CLOCK_REALTIME_COARSE
654abc69ef2e697 Christophe Leroy 2019-12-02 73 cmpli cr6,r3,CLOCK_MONOTONIC_COARSE
654abc69ef2e697 Christophe Leroy 2019-12-02 74 cror cr5*4+eq,cr5*4+eq,cr6*4+eq
654abc69ef2e697 Christophe Leroy 2019-12-02 75
654abc69ef2e697 Christophe Leroy 2019-12-02 76 cror cr0*4+eq,cr0*4+eq,cr5*4+eq
654abc69ef2e697 Christophe Leroy 2019-12-02 77 bne cr0, .Lgettime_fallback
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 78
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 79 mflr r12 /* r12 saves lr */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 80 .cfi_register lr,r12
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 81 mr r11,r4 /* r11 saves tp */
ec0895f08f99515 Christophe Leroy 2019-12-02 82 get_datapage r9, r0
6e2f9e9cfd560f5 Christophe Leroy 2019-12-02 83 LOAD_REG_IMMEDIATE(r7, NSEC_PER_SEC) /* load up NSEC_PER_SEC */
654abc69ef2e697 Christophe Leroy 2019-12-02 84 beq cr5, .Lcoarse_clocks
654abc69ef2e697 Christophe Leroy 2019-12-02 85 .Lprecise_clocks:
654abc69ef2e697 Christophe Leroy 2019-12-02 86 bl __do_get_tspec@local /* get sec/nsec from tb & kernel */
654abc69ef2e697 Christophe Leroy 2019-12-02 87 bne cr1, .Lfinish /* not monotonic -> all done */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 88
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 89 /*
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 90 * CLOCK_MONOTONIC
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 91 */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 92
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 93 /* now we must fixup using wall to monotonic. We need to snapshot
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 94 * that value and do the counter trick again. Fortunately, we still
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 95 * have the counter value in r8 that was returned by __do_get_xsec.
597bc5c00b666fe Paul Mackerras 2008-10-27 96 * At this point, r3,r4 contain our sec/nsec values, r5 and r6
597bc5c00b666fe Paul Mackerras 2008-10-27 97 * can be used, r7 contains NSEC_PER_SEC.
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 98 */
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 99
dd9a994fc68d196 Christophe Leroy 2019-04-04 100 lwz r5,(WTOM_CLOCK_SEC+LOPART)(r9)
597bc5c00b666fe Paul Mackerras 2008-10-27 101 lwz r6,WTOM_CLOCK_NSEC(r9)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 102
597bc5c00b666fe Paul Mackerras 2008-10-27 103 /* We now have our offset in r5,r6. We create a fake dependency
597bc5c00b666fe Paul Mackerras 2008-10-27 104 * on that value and re-check the counter
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 105 */
597bc5c00b666fe Paul Mackerras 2008-10-27 106 or r0,r6,r5
597bc5c00b666fe Paul Mackerras 2008-10-27 107 xor r0,r0,r0
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 108 add r9,r9,r0
597bc5c00b666fe Paul Mackerras 2008-10-27 109 lwz r0,(CFG_TB_UPDATE_COUNT+LOPART)(r9)
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 110 cmpl cr0,r8,r0 /* check if updated */
654abc69ef2e697 Christophe Leroy 2019-12-02 111 bne- .Lprecise_clocks
654abc69ef2e697 Christophe Leroy 2019-12-02 112 b .Lfinish_monotonic
654abc69ef2e697 Christophe Leroy 2019-12-02 113
654abc69ef2e697 Christophe Leroy 2019-12-02 114 /*
654abc69ef2e697 Christophe Leroy 2019-12-02 115 * For coarse clocks we get data directly from the vdso data page, so
654abc69ef2e697 Christophe Leroy 2019-12-02 116 * we don't need to call __do_get_tspec, but we still need to do the
654abc69ef2e697 Christophe Leroy 2019-12-02 117 * counter trick.
654abc69ef2e697 Christophe Leroy 2019-12-02 118 */
654abc69ef2e697 Christophe Leroy 2019-12-02 119 .Lcoarse_clocks:
654abc69ef2e697 Christophe Leroy 2019-12-02 120 lwz r8,(CFG_TB_UPDATE_COUNT+LOPART)(r9)
654abc69ef2e697 Christophe Leroy 2019-12-02 121 andi. r0,r8,1 /* pending update ? loop */
654abc69ef2e697 Christophe Leroy 2019-12-02 122 bne- .Lcoarse_clocks
654abc69ef2e697 Christophe Leroy 2019-12-02 123 add r9,r9,r0 /* r0 is already 0 */
654abc69ef2e697 Christophe Leroy 2019-12-02 124
654abc69ef2e697 Christophe Leroy 2019-12-02 125 /*
654abc69ef2e697 Christophe Leroy 2019-12-02 126 * CLOCK_REALTIME_COARSE, below values are needed for MONOTONIC_COARSE
654abc69ef2e697 Christophe Leroy 2019-12-02 127 * too
654abc69ef2e697 Christophe Leroy 2019-12-02 128 */
654abc69ef2e697 Christophe Leroy 2019-12-02 129 lwz r3,STAMP_XTIME_SEC+LOPART(r9)
654abc69ef2e697 Christophe Leroy 2019-12-02 130 lwz r4,STAMP_XTIME_NSEC+LOPART(r9)
654abc69ef2e697 Christophe Leroy 2019-12-02 131 bne cr6,1f
654abc69ef2e697 Christophe Leroy 2019-12-02 132
654abc69ef2e697 Christophe Leroy 2019-12-02 133 /* CLOCK_MONOTONIC_COARSE */
654abc69ef2e697 Christophe Leroy 2019-12-02 134 lwz r5,(WTOM_CLOCK_SEC+LOPART)(r9)
654abc69ef2e697 Christophe Leroy 2019-12-02 135 lwz r6,WTOM_CLOCK_NSEC(r9)
654abc69ef2e697 Christophe Leroy 2019-12-02 136
654abc69ef2e697 Christophe Leroy 2019-12-02 137 /* check if counter has updated */
654abc69ef2e697 Christophe Leroy 2019-12-02 138 or r0,r6,r5
654abc69ef2e697 Christophe Leroy 2019-12-02 139 1: or r0,r0,r3
654abc69ef2e697 Christophe Leroy 2019-12-02 140 or r0,r0,r4
654abc69ef2e697 Christophe Leroy 2019-12-02 141 xor r0,r0,r0
654abc69ef2e697 Christophe Leroy 2019-12-02 142 add r3,r3,r0
654abc69ef2e697 Christophe Leroy 2019-12-02 143 lwz r0,CFG_TB_UPDATE_COUNT+LOPART(r9)
654abc69ef2e697 Christophe Leroy 2019-12-02 144 cmpl cr0,r0,r8 /* check if updated */
654abc69ef2e697 Christophe Leroy 2019-12-02 145 bne- .Lcoarse_clocks
654abc69ef2e697 Christophe Leroy 2019-12-02 146
654abc69ef2e697 Christophe Leroy 2019-12-02 147 /* Counter has not updated, so continue calculating proper values for
654abc69ef2e697 Christophe Leroy 2019-12-02 148 * sec and nsec if monotonic coarse, or just return with the proper
654abc69ef2e697 Christophe Leroy 2019-12-02 149 * values for realtime.
654abc69ef2e697 Christophe Leroy 2019-12-02 150 */
654abc69ef2e697 Christophe Leroy 2019-12-02 151 bne cr6, .Lfinish
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 152
597bc5c00b666fe Paul Mackerras 2008-10-27 153 /* Calculate and store result. Note that this mimics the C code,
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 154 * which may cause funny results if nsec goes negative... is that
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 155 * possible at all ?
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 156 */
654abc69ef2e697 Christophe Leroy 2019-12-02 157 .Lfinish_monotonic:
597bc5c00b666fe Paul Mackerras 2008-10-27 158 add r3,r3,r5
597bc5c00b666fe Paul Mackerras 2008-10-27 159 add r4,r4,r6
597bc5c00b666fe Paul Mackerras 2008-10-27 160 cmpw cr0,r4,r7
597bc5c00b666fe Paul Mackerras 2008-10-27 161 cmpwi cr1,r4,0
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 162 blt 1f
597bc5c00b666fe Paul Mackerras 2008-10-27 163 subf r4,r7,r4
a7f290dad32ee34 Benjamin Herrenschmidt 2005-11-11 164 addi r3,r3,1
654abc69ef2e697 Christophe Leroy 2019-12-02 165 1: bge cr1, .Lfinish
0c37ec2aa88bd8a Benjamin Herrenschmidt 2005-11-14 166 addi r3,r3,-1
597bc5c00b666fe Paul Mackerras 2008-10-27 167 add r4,r4,r7
597bc5c00b666fe Paul Mackerras 2008-10-27 168
:::::: The code at line 40 was first introduced by commit
:::::: 8fd63a9ea7528463211a6c88d500c51851d960c8 powerpc: Rework VDSO gettimeofday to prevent time going backwards
:::::: TO: Paul Mackerras <paulus@samba.org>
:::::: CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29000 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] ASoC: dt-bindings: fsl_xcvr: Add document for XCVR
From: Rob Herring @ 2020-10-06 18:34 UTC (permalink / raw)
To: Viorel Suman (OSS)
Cc: devicetree, alsa-devel, Matthias Schiffer, Viorel Suman,
Timur Tabi, Xiubo Li, Shengjiu Wang, linuxppc-dev, Takashi Iwai,
Liam Girdwood, Nicolin Chen, Mark Brown, NXP Linux Team,
Philipp Zabel, Viorel Suman, Cosmin-Gabriel Samoila,
Jaroslav Kysela, Fabio Estevam, linux-kernel
In-Reply-To: <1601371167-32239-3-git-send-email-viorel.suman@oss.nxp.com>
On Tue, Sep 29, 2020 at 12:19:27PM +0300, Viorel Suman (OSS) wrote:
> From: Viorel Suman <viorel.suman@nxp.com>
>
> XCVR (Audio Transceiver) is a new IP module found on i.MX8MP.
>
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> ---
> .../devicetree/bindings/sound/fsl,xcvr.yaml | 103 +++++++++++++++++++++
> 1 file changed, 103 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
> new file mode 100644
> index 00000000..8abab2d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/fsl,xcvr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP Audio Transceiver (XCVR) Controller
> +
> +maintainers:
> + - Viorel Suman <viorel.suman@nxp.com>
> +
> +properties:
> + $nodename:
> + pattern: "^xcvr@.*"
> +
> + compatible:
> + const: fsl,imx8mp-xcvr
> +
> + reg:
> + items:
> + - description: 20K RAM for code and data
> + - description: registers space
> + - description: RX FIFO address
> + - description: TX FIFO address
> +
> + reg-names:
> + items:
> + - const: ram
> + - const: regs
> + - const: rxfifo
> + - const: txfifo
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: Peripheral clock
> + - description: PHY clock
> + - description: SPBA clock
> + - description: PLL clock
> +
> + clock-names:
> + items:
> + - const: ipg
> + - const: phy
> + - const: spba
> + - const: pll_ipg
> +
> + dmas:
> + maxItems: 2
> +
> + dma-names:
> + items:
> + - const: rx
> + - const: tx
> +
> + firmware-name:
> + $ref: /schemas/types.yaml#/definitions/string
> + const: imx/xcvr/xcvr-imx8mp.bin
> + description: |
> + Should contain the name of the default firmware image
> + file located on the firmware search path
We generally only have this if the name/path can't be fixed (per
compatible) in the driver. Given you only have 1 possible value, that
doesn't seem to be the case here.
> +
> + resets:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - clocks
> + - clock-names
> + - dmas
> + - dma-names
> + - firmware-name
> + - resets
additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/imx8mp-clock.h>
> + #include <dt-bindings/reset/imx8mp-reset.h>
> +
> + xcvr: xcvr@30cc0000 {
> + compatible = "fsl,imx8mp-xcvr";
> + reg = <0x30cc0000 0x800>,
> + <0x30cc0800 0x400>,
> + <0x30cc0c00 0x080>,
> + <0x30cc0e00 0x080>;
> + reg-names = "ram", "regs", "rxfifo", "txfifo";
> + interrupts = <0x0 128 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_IPG>,
> + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_PHY>,
> + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SPBA2_ROOT>,
> + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;
> + clock-names = "ipg", "phy", "spba", "pll_ipg";
> + dmas = <&sdma2 30 2 0>, <&sdma2 31 2 0>;
> + dma-names = "rx", "tx";
> + firmware-name = "imx/xcvr/xcvr-imx8mp.bin";
> + resets = <&audiomix_reset 0>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* linux-next: Fixes tag needs some work in the powerpc tree
From: Stephen Rothwell @ 2020-10-06 13:05 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Athira Rajeev, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
Hi all,
In commit
3b6c3adbb2fa ("powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints")
Fixes tag
Fixes: 7ffd948 ("powerpc/perf: factor out power8 pmu functions")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
Since Michael doesn't generally rebase his tree, this is more to be
remebered for next time.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v5] powerpc/powernv/elog: Fix race while processing OPAL error log event.
From: Michael Ellerman @ 2020-10-06 12:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: aneesh.kumar, oohall, hegdevasant
From: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Every error log reported by OPAL is exported to userspace through a
sysfs interface and notified using kobject_uevent(). The userspace
daemon (opal_errd) then reads the error log and acknowledges the error
log is saved safely to disk. Once acknowledged the kernel removes the
respective sysfs file entry causing respective resources to be
released including kobject.
However it's possible the userspace daemon may already be scanning
elog entries when a new sysfs elog entry is created by the kernel.
User daemon may read this new entry and ack it even before kernel can
notify userspace about it through kobject_uevent() call. If that
happens then we have a potential race between
elog_ack_store->kobject_put() and kobject_uevent which can lead to
use-after-free of a kernfs object resulting in a kernel crash. eg:
BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb
Faulting instruction address: 0xc0000000008ff2a0
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty #363
...
NIP kobject_uevent_env+0xa0/0x910
LR elog_event+0x1f4/0x2d0
Call Trace:
0x5deadbeef0000122 (unreliable)
elog_event+0x1f4/0x2d0
irq_thread_fn+0x4c/0xc0
irq_thread+0x1c0/0x2b0
kthread+0x1c4/0x1d0
ret_from_kernel_thread+0x5c/0x6c
This patch fixes this race by protecting the sysfs file
creation/notification by holding a reference count on kobject until we
safely send kobject_uevent().
The function create_elog_obj() returns the elog object which if used
by caller function will end up in use-after-free problem again.
However, the return value of create_elog_obj() function isn't being
used today and there is no need as well. Hence change it to return
void to make this fix complete.
Fixes: 774fea1a38c6 ("powerpc/powernv: Read OPAL error log and export it through sysfs")
Cc: stable@vger.kernel.org # v3.15+
Reported-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[mpe: Rework the logic to use a single return, reword comments, add oops]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/powernv/opal-elog.c | 33 +++++++++++++++++-----
1 file changed, 26 insertions(+), 7 deletions(-)
v5: mpe: Rework the logic to use a single return, ie. move the kobject_uevent()
into the success case of the if.
Reword comments.
Add example oops to change log.
Change in v4:
- Re-worded comments. No code change.
Change in v3:
- Change create_elog_obj function signature to return void.
Change in v2:
- Instead of mutex and use extra reference count on kobject to avoid the race.
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 62ef7ad995da..5e33b1fc67c2 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -179,14 +179,14 @@ static ssize_t raw_attr_read(struct file *filep, struct kobject *kobj,
return count;
}
-static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
+static void create_elog_obj(uint64_t id, size_t size, uint64_t type)
{
struct elog_obj *elog;
int rc;
elog = kzalloc(sizeof(*elog), GFP_KERNEL);
if (!elog)
- return NULL;
+ return;
elog->kobj.kset = elog_kset;
@@ -219,18 +219,37 @@ static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
rc = kobject_add(&elog->kobj, NULL, "0x%llx", id);
if (rc) {
kobject_put(&elog->kobj);
- return NULL;
+ return;
}
+ /*
+ * As soon as the sysfs file for this elog is created/activated there is
+ * a chance the opal_errd daemon (or any userspace) might read and
+ * acknowledge the elog before kobject_uevent() is called. If that
+ * happens then there is a potential race between
+ * elog_ack_store->kobject_put() and kobject_uevent() which leads to a
+ * use-after-free of a kernfs object resulting in a kernel crash.
+ *
+ * To avoid that, we need to take a reference on behalf of the bin file,
+ * so that our reference remains valid while we call kobject_uevent().
+ * We then drop our reference before exiting the function, leaving the
+ * bin file to drop the last reference (if it hasn't already).
+ */
+
+ /* Take a reference for the bin file */
+ kobject_get(&elog->kobj);
rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr);
- if (rc) {
+ if (rc == 0) {
+ kobject_uevent(&elog->kobj, KOBJ_ADD);
+ } else {
+ /* Drop the reference taken for the bin file */
kobject_put(&elog->kobj);
- return NULL;
}
- kobject_uevent(&elog->kobj, KOBJ_ADD);
+ /* Drop our reference */
+ kobject_put(&elog->kobj);
- return elog;
+ return;
}
static irqreturn_t elog_event(int irq, void *data)
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/32s: Rename head_32.S to head_book3s_32.S
From: Christophe Leroy @ 2020-10-06 9:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Unlike PPC64 which had a single head_64.S, PPC32 are multiple ones.
There is the head_32.S, selected by default based on the value of BITS
and overridden based on some CONFIG_ values. This leads to thinking
that it may be selected by different types of PPC32 platform but
indeed it ends up being selected by book3s/32 only.
Make that explicit by:
- Not doing any default selection based on BITS.
- Renaming head_32.S to head_book3s_32.S.
- Get head_book3s_32.S selected only by CONFIG_PPC_BOOK3S_32.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/Makefile | 3 ++-
arch/powerpc/kernel/{head_32.S => head_book3s_32.S} | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
rename arch/powerpc/kernel/{head_32.S => head_book3s_32.S} (99%)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index a5550c2b24c4..bf0bf1b900d2 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -95,7 +95,8 @@ obj-$(CONFIG_PPC_FSL_BOOK3E) += cpu_setup_fsl_booke.o
obj-$(CONFIG_PPC_DOORBELL) += dbell.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o
-extra-y := head_$(BITS).o
+extra-$(CONFIG_PPC64) := head_64.o
+extra-$(CONFIG_PPC_BOOK3S_32) := head_book3s_32.o
extra-$(CONFIG_40x) := head_40x.o
extra-$(CONFIG_44x) := head_44x.o
extra-$(CONFIG_FSL_BOOKE) := head_fsl_booke.o
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_book3s_32.S
similarity index 99%
rename from arch/powerpc/kernel/head_32.S
rename to arch/powerpc/kernel/head_book3s_32.S
index 35627693c2a4..e07a2c07ffe4 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -61,7 +61,7 @@
__HEAD
.stabs "arch/powerpc/kernel/",N_SO,0,0,0f
- .stabs "head_32.S",N_SO,0,0,0f
+ .stabs "head_book3s_32.S",N_SO,0,0,0f
0:
_ENTRY(_stext);
--
2.25.0
^ permalink raw reply related
* [PATCH 2/2] powerpc/32s: Remove #ifdef CONFIG_PPC_BOOK3S_32 in head_book3s_32.S
From: Christophe Leroy @ 2020-10-06 9:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <319d379f696412681c66a987cc75e6abf8f958d2.1601975100.git.christophe.leroy@csgroup.eu>
head_book3s_32.S is only built when CONFIG_PPC_BOOK3S_32 is selected.
Remove all conditions based on CONFIG_PPC_BOOK3S_32 in the file.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/head_book3s_32.S | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/arch/powerpc/kernel/head_book3s_32.S b/arch/powerpc/kernel/head_book3s_32.S
index e07a2c07ffe4..f659378adaf3 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -183,10 +183,8 @@ __after_mmu_off:
bl reloc_offset
li r24,0 /* cpu# */
bl call_setup_cpu /* Call setup_cpu for this CPU */
-#ifdef CONFIG_PPC_BOOK3S_32
bl reloc_offset
bl init_idle_6xx
-#endif /* CONFIG_PPC_BOOK3S_32 */
/*
@@ -892,10 +890,8 @@ __secondary_start:
lis r3,-KERNELBASE@h
mr r4,r24
bl call_setup_cpu /* Call setup_cpu for this CPU */
-#ifdef CONFIG_PPC_BOOK3S_32
lis r3,-KERNELBASE@h
bl init_idle_6xx
-#endif /* CONFIG_PPC_BOOK3S_32 */
/* get current's stack and current */
lis r2,secondary_current@ha
@@ -936,17 +932,6 @@ __secondary_start:
#include "../kvm/book3s_rmhandlers.S"
#endif
-/*
- * Those generic dummy functions are kept for CPUs not
- * included in CONFIG_PPC_BOOK3S_32
- */
-#if !defined(CONFIG_PPC_BOOK3S_32)
-_ENTRY(__save_cpu_setup)
- blr
-_ENTRY(__restore_cpu_setup)
- blr
-#endif /* !defined(CONFIG_PPC_BOOK3S_32) */
-
/*
* Load stuff into the MMU. Intended to be called with
* IR=0 and DR=0.
--
2.25.0
^ permalink raw reply related
* Re: linux-next: manual merge of the char-misc tree with the powerpc tree
From: Greg KH @ 2020-10-06 8:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Arnd Bergmann, Necip Fazil Yildiran, Linux Kernel Mailing List,
Linux Next Mailing List, Frederic Barrat, PowerPC
In-Reply-To: <20201006183506.186a3562@canb.auug.org.au>
On Tue, Oct 06, 2020 at 06:35:06PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/misc/ocxl/Kconfig
>
> between commit:
>
> dde6f18a8779 ("ocxl: Don't return trigger page when allocating an interrupt")
>
> from the powerpc tree and commit:
>
> 4b53a3c72116 ("ocxl: fix kconfig dependency warning for OCXL")
>
> from the char-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/misc/ocxl/Kconfig
> index 0d815b2a40b3,947294f6d7f4..000000000000
> --- a/drivers/misc/ocxl/Kconfig
> +++ b/drivers/misc/ocxl/Kconfig
> @@@ -9,9 -9,8 +9,9 @@@ config OCXL_BAS
>
> config OCXL
> tristate "OpenCAPI coherent accelerator support"
> - depends on PPC_POWERNV && PCI && EEH && HOTPLUG_PCI_POWERNV
> + depends on PPC_POWERNV && PCI && EEH && PPC_XIVE_NATIVE
> ++ depends on HOTPLUG_PCI_POWERNV
> select OCXL_BASE
> - select HOTPLUG_PCI_POWERNV
> default m
> help
> Select this option to enable the ocxl driver for Open
Looks good, thanks!
greg k-h
^ permalink raw reply
* [RFC PATCH] powerpc/mm: Support tlbiel set value of 1 on POWER10
From: Aneesh Kumar K.V @ 2020-10-06 8:16 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Aneesh Kumar K.V, npiggin
With POWER10, tlbiel invalidates all the congruence class of TLB
and hence we need to issue only one tlbiel with SET=0. Update
POWER10_TLB_SETS to 1 and use that in the rest of the code.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 +
arch/powerpc/kvm/book3s_hv.c | 4 +++-
arch/powerpc/kvm/book3s_hv_builtin.c | 8 +++++++-
arch/powerpc/mm/book3s64/hash_native.c | 4 +++-
arch/powerpc/mm/book3s64/radix_tlb.c | 13 ++++++++++---
5 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
index 683a9c7d1b03..755ae1ea910a 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
@@ -129,6 +129,7 @@
#define POWER8_TLB_SETS 512 /* # sets in POWER8 TLB */
#define POWER9_TLB_SETS_HASH 256 /* # sets in POWER9 TLB Hash mode */
#define POWER9_TLB_SETS_RADIX 128 /* # sets in POWER9 TLB Radix mode */
+#define POWER10_TLB_SETS 1 /* # sets in POWER10 TLB */
#ifndef __ASSEMBLY__
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 3bd3118c7633..12553cb55ede 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4939,7 +4939,9 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
* Work out how many sets the TLB has, for the use of
* the TLB invalidation loop in book3s_hv_rmhandlers.S.
*/
- if (radix_enabled())
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ kvm->arch.tlb_sets = POWER10_TLB_SETS; /* 1 */
+ else if (radix_enabled())
kvm->arch.tlb_sets = POWER9_TLB_SETS_RADIX; /* 128 */
else if (cpu_has_feature(CPU_FTR_ARCH_300))
kvm->arch.tlb_sets = POWER9_TLB_SETS_HASH; /* 256 */
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c
index 073617ce83e0..7dfe38771f3c 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -702,6 +702,7 @@ static void wait_for_sync(struct kvm_split_mode *sip, int phase)
void kvmhv_p9_set_lpcr(struct kvm_split_mode *sip)
{
+ int num_sets;
unsigned long rb, set;
/* wait for every other thread to get to real mode */
@@ -712,11 +713,16 @@ void kvmhv_p9_set_lpcr(struct kvm_split_mode *sip)
mtspr(SPRN_LPID, sip->lpidr_req);
isync();
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ num_sets = POWER10_TLB_SETS;
+ else
+ num_sets = POWER9_TLB_SETS_RADIX;
+
/* Invalidate the TLB on thread 0 */
if (local_paca->kvm_hstate.tid == 0) {
sip->do_set = 0;
asm volatile("ptesync" : : : "memory");
- for (set = 0; set < POWER9_TLB_SETS_RADIX; ++set) {
+ for (set = 0; set < num_sets; ++set) {
rb = TLBIEL_INVAL_SET_LPID +
(set << TLBIEL_INVAL_SET_SHIFT);
asm volatile(PPC_TLBIEL(%0, %1, 0, 0, 0) : :
diff --git a/arch/powerpc/mm/book3s64/hash_native.c b/arch/powerpc/mm/book3s64/hash_native.c
index cf20e5229ce1..abea64c804b2 100644
--- a/arch/powerpc/mm/book3s64/hash_native.c
+++ b/arch/powerpc/mm/book3s64/hash_native.c
@@ -130,7 +130,9 @@ void hash__tlbiel_all(unsigned int action)
BUG();
}
- if (early_cpu_has_feature(CPU_FTR_ARCH_300))
+ if (early_cpu_has_feature(CPU_FTR_ARCH_31))
+ tlbiel_all_isa300(POWER10_TLB_SETS, is);
+ else if (early_cpu_has_feature(CPU_FTR_ARCH_300))
tlbiel_all_isa300(POWER9_TLB_SETS_HASH, is);
else if (early_cpu_has_feature(CPU_FTR_ARCH_207S))
tlbiel_all_isa206(POWER8_TLB_SETS, is);
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
index 143b4fd396f0..47db637755c4 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -83,7 +83,9 @@ void radix__tlbiel_all(unsigned int action)
BUG();
}
- if (early_cpu_has_feature(CPU_FTR_ARCH_300))
+ if (early_cpu_has_feature(CPU_FTR_ARCH_31))
+ tlbiel_all_isa300(POWER10_TLB_SETS, is);
+ else if (early_cpu_has_feature(CPU_FTR_ARCH_300))
tlbiel_all_isa300(POWER9_TLB_SETS_RADIX, is);
else
WARN(1, "%s called on pre-POWER9 CPU\n", __func__);
@@ -284,7 +286,7 @@ static inline void fixup_tlbie_lpid(unsigned long lpid)
*/
static __always_inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
{
- int set;
+ int set, num_sets;
asm volatile("ptesync": : :"memory");
@@ -300,8 +302,13 @@ static __always_inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
return;
}
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ num_sets = POWER10_TLB_SETS;
+ else
+ num_sets = POWER9_TLB_SETS_RADIX;
+
/* For the remaining sets, just flush the TLB */
- for (set = 1; set < POWER9_TLB_SETS_RADIX ; set++)
+ for (set = 1; set < num_sets; set++)
__tlbiel_pid(pid, set, RIC_FLUSH_TLB);
asm volatile("ptesync": : :"memory");
--
2.26.2
^ permalink raw reply related
* linux-next: manual merge of the char-misc tree with the powerpc tree
From: Stephen Rothwell @ 2020-10-06 7:35 UTC (permalink / raw)
To: Greg KH, Arnd Bergmann, Michael Ellerman, PowerPC
Cc: Frederic Barrat, Necip Fazil Yildiran, Linux Next Mailing List,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/misc/ocxl/Kconfig
between commit:
dde6f18a8779 ("ocxl: Don't return trigger page when allocating an interrupt")
from the powerpc tree and commit:
4b53a3c72116 ("ocxl: fix kconfig dependency warning for OCXL")
from the char-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/misc/ocxl/Kconfig
index 0d815b2a40b3,947294f6d7f4..000000000000
--- a/drivers/misc/ocxl/Kconfig
+++ b/drivers/misc/ocxl/Kconfig
@@@ -9,9 -9,8 +9,9 @@@ config OCXL_BAS
config OCXL
tristate "OpenCAPI coherent accelerator support"
- depends on PPC_POWERNV && PCI && EEH && HOTPLUG_PCI_POWERNV
+ depends on PPC_POWERNV && PCI && EEH && PPC_XIVE_NATIVE
++ depends on HOTPLUG_PCI_POWERNV
select OCXL_BASE
- select HOTPLUG_PCI_POWERNV
default m
help
Select this option to enable the ocxl driver for Open
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v4] powernv/elog: Fix the race while processing OPAL error log event.
From: Mahesh Salgaonkar @ 2020-10-06 7:32 UTC (permalink / raw)
To: linuxppc-dev
Cc: Aneesh Kumar K.V, Oliver O'Halloran, stable, Vasant Hegde
Every error log reported by OPAL is exported to userspace through a sysfs
interface and notified using kobject_uevent(). The userspace daemon
(opal_errd) then reads the error log and acknowledges it error log is saved
safely to disk. Once acknowledged the kernel removes the respective sysfs
file entry causing respective resources getting released including kobject.
However there are chances where user daemon may already be scanning elog
entries while new sysfs elog entry is being created by kernel. User daemon
may read this new entry and ack it even before kernel can notify userspace
about it through kobject_uevent() call. If that happens then we have a
potential race between elog_ack_store->kobject_put() and kobject_uevent
which can lead to use-after-free issue of a kernfs object resulting into a
kernel crash. This patch fixes this race by protecting a sysfs file
creation/notification by holding a reference count on kobject until we
safely send kobject_uevent().
The function create_elog_obj() returns the elog object which if used by
caller function will end up in use-after-free problem again. However, the
return value of create_elog_obj() function isn't being used today and there
is need as well. Hence change it to return void to make this fix complete.
Fixes: 774fea1a38c6 ("powerpc/powernv: Read OPAL error log and export it through sysfs")
Cc: <stable@vger.kernel.org> # v3.15+
Reported-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
Chnage in v4:
- Re-worded comments. No code change.
Change in v3:
- Change create_elog_obj function signature to return void.
Change in v2:
- Instead of mutex and use extra reference count on kobject to avoid the
race.
---
arch/powerpc/platforms/powernv/opal-elog.c | 34 ++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 62ef7ad995da..adf4ff8d0bea 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -179,14 +179,14 @@ static ssize_t raw_attr_read(struct file *filep, struct kobject *kobj,
return count;
}
-static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
+static void create_elog_obj(uint64_t id, size_t size, uint64_t type)
{
struct elog_obj *elog;
int rc;
elog = kzalloc(sizeof(*elog), GFP_KERNEL);
if (!elog)
- return NULL;
+ return;
elog->kobj.kset = elog_kset;
@@ -219,18 +219,42 @@ static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
rc = kobject_add(&elog->kobj, NULL, "0x%llx", id);
if (rc) {
kobject_put(&elog->kobj);
- return NULL;
+ return;
}
+ /*
+ * As soon as sysfs file for this elog is created/activated there is
+ * chance opal_errd daemon might read and acknowledge this elog before
+ * kobject_uevent() is called. If that happens then we have a potential
+ * race between elog_ack_store->kobject_put() and kobject_uevent which
+ * leads to use-after-free issue of a kernfs object resulting into
+ * kernel crash.
+ *
+ * We already have one reference count on kobject and is been used for
+ * sysfs_create_bin_file() function. This initial one reference count
+ * is valid until it is dropped by elog_ack_store() function.
+ *
+ * However if userspace acknowledges the elog before this code reaches
+ * to kobject_uevent(), the reference count on kobject drops to zero
+ * and no longer stay valid for kobject_uevent() invocation. To avoid
+ * this race take reference count on kobject for bin file creation and
+ * drop it after kobject_uevent() is sent.
+ */
+
+ kobject_get(&elog->kobj); /* take a reference for the bin file. */
rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr);
if (rc) {
kobject_put(&elog->kobj);
- return NULL;
+ /* Drop reference count taken for bin file. */
+ kobject_put(&elog->kobj);
+ return;
}
kobject_uevent(&elog->kobj, KOBJ_ADD);
+ /* Drop reference count taken for bin file. */
+ kobject_put(&elog->kobj);
- return elog;
+ return;
}
static irqreturn_t elog_event(int irq, void *data)
^ permalink raw reply related
* Re: [PATCH v2] powernv/elog: Fix the race while processing OPAL error log event.
From: Michael Ellerman @ 2020-10-06 5:40 UTC (permalink / raw)
To: Mahesh Salgaonkar, linuxppc-dev
Cc: Aneesh Kumar K.V, Oliver O'Halloran, Vasant Hegde
In-Reply-To: <160187115555.1589942.2124270585910076829.stgit@jupiter>
Mahesh Salgaonkar <mahesh@linux.ibm.com> writes:
> Every error log reported by OPAL is exported to userspace through a sysfs
> interface and notified using kobject_uevent(). The userspace daemon
> (opal_errd) then reads the error log and acknowledges it error log is saved
> safely to disk. Once acknowledged the kernel removes the respective sysfs
> file entry causing respective resources getting released including kobject.
>
> However there are chances where user daemon may already be scanning elog
> entries while new sysfs elog entry is being created by kernel. User daemon
> may read this new entry and ack it even before kernel can notify userspace
> about it through kobject_uevent() call. If that happens then we have a
> potential race between elog_ack_store->kobject_put() and kobject_uevent
> which can lead to use-after-free issue of a kernfs object resulting into a
> kernel crash. This patch fixes this race by protecting a sysfs file
> creation/notification by holding an additional reference count on kobject
> until we safely send kobject_uevent().
>
> Reported-by: Oliver O'Halloran <oohall@gmail.com>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> Change in v2:
> - Instead of mutex and use extra reference count on kobject to avoid the
> race.
> ---
> arch/powerpc/platforms/powernv/opal-elog.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
> index 62ef7ad995da..230f102e87c0 100644
> --- a/arch/powerpc/platforms/powernv/opal-elog.c
> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
> @@ -222,13 +222,28 @@ static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
> return NULL;
> }
>
> + /*
> + * As soon as sysfs file for this elog is created/activated there is
> + * chance opal_errd daemon might read and acknowledge this elog before
> + * kobject_uevent() is called. If that happens then we have a potential
> + * race between elog_ack_store->kobject_put() and kobject_uevent which
> + * leads to use-after-free issue of a kernfs object resulting into
> + * kernel crash. To avoid this race take an additional reference count
> + * on kobject until we safely send kobject_uevent().
> + */
> +
> + kobject_get(&elog->kobj); /* extra reference count */
It's not really an "extra" reference.
The way the code is currently written there's one reference and it's
given to (moved into) sysfs_create_bin_file(). (Because elog_ack_store()
drops that reference).
So after that call this function no longer has a valid reference to
kobj.
If this function wants to continue to use kobj (which it does) it needs
its own reference.
Or the other way to think about it is that this code owns the initial
reference, and it needs to take a reference on behalf of the bin file
before creating the bin file.
So the patch is not wrong, but I think the comments are a bit
misleading.
> rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr);
> if (rc) {
> + kobject_put(&elog->kobj);
> + /* Drop the extra reference count */
> kobject_put(&elog->kobj);
> return NULL;
> }
>
> kobject_uevent(&elog->kobj, KOBJ_ADD);
> + /* Drop the extra reference count */
> + kobject_put(&elog->kobj);
>
> return elog;
And it is bogus that we return elog here, because we no longer have a
valid reference to it, so it may already be freed.
> }
So please send a v3 with updated comments and the return dropped.
cheers
^ permalink raw reply
* [PATCH v3] powernv/elog: Fix the race while processing OPAL error log event.
From: Mahesh Salgaonkar @ 2020-10-06 5:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K.V, Oliver O'Halloran, Vasant Hegde
Every error log reported by OPAL is exported to userspace through a sysfs
interface and notified using kobject_uevent(). The userspace daemon
(opal_errd) then reads the error log and acknowledges it error log is saved
safely to disk. Once acknowledged the kernel removes the respective sysfs
file entry causing respective resources getting released including kobject.
However there are chances where user daemon may already be scanning elog
entries while new sysfs elog entry is being created by kernel. User daemon
may read this new entry and ack it even before kernel can notify userspace
about it through kobject_uevent() call. If that happens then we have a
potential race between elog_ack_store->kobject_put() and kobject_uevent
which can lead to use-after-free issue of a kernfs object resulting into a
kernel crash. This patch fixes this race by protecting a sysfs file
creation/notification by holding an additional reference count on kobject
until we safely send kobject_uevent().
The function create_elog_obj() returns the elog object which if used by
caller function will end up in use-after-free problem again. However, the
return value of create_elog_obj() function isn't being used today and there
is need as well. Hence change it to return void to make this fix complete.
Fixes: 774fea1a38c6 ("powerpc/powernv: Read OPAL error log and export it through sysfs")
Cc: <stable@vger.kernel.org> # v3.15+
Reported-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
Change in v3:
- Change create_elog_obj function signature to return void.
Change in v2:
- Instead of mutex and use extra reference count on kobject to avoid the
race.
---
arch/powerpc/platforms/powernv/opal-elog.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 62ef7ad995da..e61cbf08e17e 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -179,14 +179,14 @@ static ssize_t raw_attr_read(struct file *filep, struct kobject *kobj,
return count;
}
-static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
+static void create_elog_obj(uint64_t id, size_t size, uint64_t type)
{
struct elog_obj *elog;
int rc;
elog = kzalloc(sizeof(*elog), GFP_KERNEL);
if (!elog)
- return NULL;
+ return;
elog->kobj.kset = elog_kset;
@@ -219,18 +219,33 @@ static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
rc = kobject_add(&elog->kobj, NULL, "0x%llx", id);
if (rc) {
kobject_put(&elog->kobj);
- return NULL;
+ return;
}
+ /*
+ * As soon as sysfs file for this elog is created/activated there is
+ * chance opal_errd daemon might read and acknowledge this elog before
+ * kobject_uevent() is called. If that happens then we have a potential
+ * race between elog_ack_store->kobject_put() and kobject_uevent which
+ * leads to use-after-free issue of a kernfs object resulting into
+ * kernel crash. To avoid this race take an additional reference count
+ * on kobject until we safely send kobject_uevent().
+ */
+
+ kobject_get(&elog->kobj); /* extra reference count */
rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr);
if (rc) {
kobject_put(&elog->kobj);
- return NULL;
+ /* Drop the extra reference count */
+ kobject_put(&elog->kobj);
+ return;
}
kobject_uevent(&elog->kobj, KOBJ_ADD);
+ /* Drop the extra reference count */
+ kobject_put(&elog->kobj);
- return elog;
+ return;
}
static irqreturn_t elog_event(int irq, void *data)
^ permalink raw reply related
* Re: [PATCH v2] powernv/elog: Fix the race while processing OPAL error log event.
From: Mahesh Jagannath Salgaonkar @ 2020-10-06 5:11 UTC (permalink / raw)
To: ananth, linuxppc-dev
In-Reply-To: <df7cebd0-bec3-d716-5514-61c4043a6d30@linux.ibm.com>
On 10/5/20 4:17 PM, Ananth N Mavinakayanahalli wrote:
> On 10/5/20 9:42 AM, Mahesh Salgaonkar wrote:
>> Every error log reported by OPAL is exported to userspace through a sysfs
>> interface and notified using kobject_uevent(). The userspace daemon
>> (opal_errd) then reads the error log and acknowledges it error log is
>> saved
>> safely to disk. Once acknowledged the kernel removes the respective sysfs
>> file entry causing respective resources getting released including
>> kobject.
>>
>> However there are chances where user daemon may already be scanning elog
>> entries while new sysfs elog entry is being created by kernel. User
>> daemon
>> may read this new entry and ack it even before kernel can notify
>> userspace
>> about it through kobject_uevent() call. If that happens then we have a
>> potential race between elog_ack_store->kobject_put() and kobject_uevent
>> which can lead to use-after-free issue of a kernfs object resulting
>> into a
>> kernel crash. This patch fixes this race by protecting a sysfs file
>> creation/notification by holding an additional reference count on kobject
>> until we safely send kobject_uevent().
>>
>> Reported-by: Oliver O'Halloran <oohall@gmail.com>
>> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>
> cc stable?
>
Will add it in v3.
Thanks,
-Mahesh.
^ permalink raw reply
* Re: [PATCH v2] powernv/elog: Fix the race while processing OPAL error log event.
From: Mahesh Jagannath Salgaonkar @ 2020-10-06 4:48 UTC (permalink / raw)
To: Oliver O'Halloran; +Cc: linuxppc-dev, Vasant Hegde, Aneesh Kumar K.V
In-Reply-To: <CAOSf1CEx_vSrMNYCRrL7q168hXr+iEAG4jxhrjkXzqEMH5CkQA@mail.gmail.com>
On 10/6/20 5:55 AM, Oliver O'Halloran wrote:
> On Mon, Oct 5, 2020 at 3:12 PM Mahesh Salgaonkar <mahesh@linux.ibm.com> wrote:
>>
>> Every error log reported by OPAL is exported to userspace through a sysfs
>> interface and notified using kobject_uevent(). The userspace daemon
>> (opal_errd) then reads the error log and acknowledges it error log is saved
>> safely to disk. Once acknowledged the kernel removes the respective sysfs
>> file entry causing respective resources getting released including kobject.
>>
>> However there are chances where user daemon may already be scanning elog
>> entries while new sysfs elog entry is being created by kernel. User daemon
>> may read this new entry and ack it even before kernel can notify userspace
>> about it through kobject_uevent() call. If that happens then we have a
>> potential race between elog_ack_store->kobject_put() and kobject_uevent
>> which can lead to use-after-free issue of a kernfs object resulting into a
>> kernel crash. This patch fixes this race by protecting a sysfs file
>> creation/notification by holding an additional reference count on kobject
>> until we safely send kobject_uevent().
>>
>> Reported-by: Oliver O'Halloran <oohall@gmail.com>
>> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> Change in v2:
>> - Instead of mutex and use extra reference count on kobject to avoid the
>> race.
>> ---
>> arch/powerpc/platforms/powernv/opal-elog.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
>> index 62ef7ad995da..230f102e87c0 100644
>> --- a/arch/powerpc/platforms/powernv/opal-elog.c
>> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
>> @@ -222,13 +222,28 @@ static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
>> return NULL;
>> }
>>
>> + /*
>> + * As soon as sysfs file for this elog is created/activated there is
>> + * chance opal_errd daemon might read and acknowledge this elog before
>> + * kobject_uevent() is called. If that happens then we have a potential
>> + * race between elog_ack_store->kobject_put() and kobject_uevent which
>> + * leads to use-after-free issue of a kernfs object resulting into
>> + * kernel crash. To avoid this race take an additional reference count
>> + * on kobject until we safely send kobject_uevent().
>> + */
>> +
>> + kobject_get(&elog->kobj); /* extra reference count */
>> rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr);
>> if (rc) {
>> + kobject_put(&elog->kobj);
>> + /* Drop the extra reference count */
>> kobject_put(&elog->kobj);
>> return NULL;
>> }
>>
>> kobject_uevent(&elog->kobj, KOBJ_ADD);
>> + /* Drop the extra reference count */
>> + kobject_put(&elog->kobj);
>
> Makes sense,
>
> Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
>
>>
>> return elog;
>
> Does the returned value actually get used anywhere? We'd have a
> similar use-after-free problem if it does. This should probably return
> an error code rather than the object itself.
>
Nope. It isn't being used. I can make it function as void and send v3.
Thanks,
-Mahesh.
^ permalink raw reply
* Re: [RFC PATCH next-20200930] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Joe Perches @ 2020-10-06 3:22 UTC (permalink / raw)
To: Joel Stanley, Michael Ellerman
Cc: Kees Cook, Paul E . McKenney, Clang-Built-Linux ML,
Nick Desaulniers, Lai Jiangshan, Josh Triplett, Steven Rostedt,
rcu, Miguel Ojeda, Mathieu Desnoyers, Sedat Dilek, Paul Mackerras,
linuxppc-dev, LKML
In-Reply-To: <CACPK8XdwX=1T8WrsVYurL+JedEsb1ZTyrWtJXDLXycu-qu4UTg@mail.gmail.com>
On Tue, 2020-10-06 at 00:34 +0000, Joel Stanley wrote:
> arch/powerpc/boot is the powerpc wrapper, and it's not built with the
> same includes or flags as the rest of the kernel. It doesn't include
> any of the headers in the top level include/ directory for hysterical
> raisins.
>
> The straightforward fix would be to exclude this directory from your script.
I agree and that's why I submitted another script
that does just that.
https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/
^ permalink raw reply
* Re: [PATCH v2] powernv/elog: Fix the race while processing OPAL error log event.
From: Vasant Hegde @ 2020-10-06 2:26 UTC (permalink / raw)
To: Oliver O'Halloran, Mahesh Salgaonkar
Cc: linuxppc-dev, Vasant Hegde, Aneesh Kumar K.V
In-Reply-To: <CAOSf1CEx_vSrMNYCRrL7q168hXr+iEAG4jxhrjkXzqEMH5CkQA@mail.gmail.com>
On 10/6/20 5:55 AM, Oliver O'Halloran wrote:
> On Mon, Oct 5, 2020 at 3:12 PM Mahesh Salgaonkar <mahesh@linux.ibm.com> wrote:
>>
>> Every error log reported by OPAL is exported to userspace through a sysfs
>> interface and notified using kobject_uevent(). The userspace daemon
>> (opal_errd) then reads the error log and acknowledges it error log is saved
>> safely to disk. Once acknowledged the kernel removes the respective sysfs
>> file entry causing respective resources getting released including kobject.
>>
>> However there are chances where user daemon may already be scanning elog
>> entries while new sysfs elog entry is being created by kernel. User daemon
>> may read this new entry and ack it even before kernel can notify userspace
>> about it through kobject_uevent() call. If that happens then we have a
>> potential race between elog_ack_store->kobject_put() and kobject_uevent
>> which can lead to use-after-free issue of a kernfs object resulting into a
>> kernel crash. This patch fixes this race by protecting a sysfs file
>> creation/notification by holding an additional reference count on kobject
>> until we safely send kobject_uevent().
>>
>> Reported-by: Oliver O'Halloran <oohall@gmail.com>
>> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> Change in v2:
>> - Instead of mutex and use extra reference count on kobject to avoid the
>> race.
>> ---
>> arch/powerpc/platforms/powernv/opal-elog.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
>> index 62ef7ad995da..230f102e87c0 100644
>> --- a/arch/powerpc/platforms/powernv/opal-elog.c
>> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
>> @@ -222,13 +222,28 @@ static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
>> return NULL;
>> }
>>
>> + /*
>> + * As soon as sysfs file for this elog is created/activated there is
>> + * chance opal_errd daemon might read and acknowledge this elog before
>> + * kobject_uevent() is called. If that happens then we have a potential
>> + * race between elog_ack_store->kobject_put() and kobject_uevent which
>> + * leads to use-after-free issue of a kernfs object resulting into
>> + * kernel crash. To avoid this race take an additional reference count
>> + * on kobject until we safely send kobject_uevent().
>> + */
>> +
>> + kobject_get(&elog->kobj); /* extra reference count */
>> rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr);
>> if (rc) {
>> + kobject_put(&elog->kobj);
>> + /* Drop the extra reference count */
>> kobject_put(&elog->kobj);
>> return NULL;
>> }
>>
>> kobject_uevent(&elog->kobj, KOBJ_ADD);
>> + /* Drop the extra reference count */
>> + kobject_put(&elog->kobj);
>
> Makes sense,
>
> Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
>
>>
>> return elog;
>
> Does the returned value actually get used anywhere? We'd have a
> similar use-after-free problem if it does. This should probably return
> an error code rather than the object itself.
No one is using it today. May be we should just make it void function.
-Vasant
^ permalink raw reply
* Re: [RFC PATCH next-20200930] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Joel Stanley @ 2020-10-06 0:34 UTC (permalink / raw)
To: Joe Perches, Michael Ellerman
Cc: Kees Cook, Paul E . McKenney, Clang-Built-Linux ML,
Nick Desaulniers, Lai Jiangshan, Josh Triplett, Steven Rostedt,
rcu, Miguel Ojeda, Mathieu Desnoyers, Sedat Dilek, Paul Mackerras,
linuxppc-dev, LKML
In-Reply-To: <61445711991c2d6eb7c8fb05bed2814458e2593b.camel@perches.com>
On Thu, 1 Oct 2020 at 20:19, Joe Perches <joe@perches.com> wrote:
>
> On Thu, 2020-10-01 at 14:39 -0500, Segher Boessenkool wrch/ote:
> > Hi!
> >
> > On Thu, Oct 01, 2020 at 12:15:39PM +0200, Miguel Ojeda wrote:
> > > > So it looks like the best option is to exclude these
> > > > 2 files from conversion.
> > >
> > > Agreed. Nevertheless, is there any reason arch/powerpc/* should not be
> > > compiling cleanly with compiler.h? (CC'ing the rest of the PowerPC
> > > reviewers and ML).
> >
> > You need to #include compiler_types.h to get this #define?
>
> Actually no, you need to add
>
> #include <linux/compiler_attributes.h>
>
> to both files and then it builds properly.
>
> Ideally though nothing should include this file directly.
arch/powerpc/boot is the powerpc wrapper, and it's not built with the
same includes or flags as the rest of the kernel. It doesn't include
any of the headers in the top level include/ directory for hysterical
raisins.
The straightforward fix would be to exclude this directory from your script.
Cheers,
Joel
^ permalink raw reply
* Re: [PATCH v2] powernv/elog: Fix the race while processing OPAL error log event.
From: Oliver O'Halloran @ 2020-10-06 0:25 UTC (permalink / raw)
To: Mahesh Salgaonkar; +Cc: linuxppc-dev, Vasant Hegde, Aneesh Kumar K.V
In-Reply-To: <160187115555.1589942.2124270585910076829.stgit@jupiter>
On Mon, Oct 5, 2020 at 3:12 PM Mahesh Salgaonkar <mahesh@linux.ibm.com> wrote:
>
> Every error log reported by OPAL is exported to userspace through a sysfs
> interface and notified using kobject_uevent(). The userspace daemon
> (opal_errd) then reads the error log and acknowledges it error log is saved
> safely to disk. Once acknowledged the kernel removes the respective sysfs
> file entry causing respective resources getting released including kobject.
>
> However there are chances where user daemon may already be scanning elog
> entries while new sysfs elog entry is being created by kernel. User daemon
> may read this new entry and ack it even before kernel can notify userspace
> about it through kobject_uevent() call. If that happens then we have a
> potential race between elog_ack_store->kobject_put() and kobject_uevent
> which can lead to use-after-free issue of a kernfs object resulting into a
> kernel crash. This patch fixes this race by protecting a sysfs file
> creation/notification by holding an additional reference count on kobject
> until we safely send kobject_uevent().
>
> Reported-by: Oliver O'Halloran <oohall@gmail.com>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> Change in v2:
> - Instead of mutex and use extra reference count on kobject to avoid the
> race.
> ---
> arch/powerpc/platforms/powernv/opal-elog.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
> index 62ef7ad995da..230f102e87c0 100644
> --- a/arch/powerpc/platforms/powernv/opal-elog.c
> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
> @@ -222,13 +222,28 @@ static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
> return NULL;
> }
>
> + /*
> + * As soon as sysfs file for this elog is created/activated there is
> + * chance opal_errd daemon might read and acknowledge this elog before
> + * kobject_uevent() is called. If that happens then we have a potential
> + * race between elog_ack_store->kobject_put() and kobject_uevent which
> + * leads to use-after-free issue of a kernfs object resulting into
> + * kernel crash. To avoid this race take an additional reference count
> + * on kobject until we safely send kobject_uevent().
> + */
> +
> + kobject_get(&elog->kobj); /* extra reference count */
> rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr);
> if (rc) {
> + kobject_put(&elog->kobj);
> + /* Drop the extra reference count */
> kobject_put(&elog->kobj);
> return NULL;
> }
>
> kobject_uevent(&elog->kobj, KOBJ_ADD);
> + /* Drop the extra reference count */
> + kobject_put(&elog->kobj);
Makes sense,
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
>
> return elog;
Does the returned value actually get used anywhere? We'd have a
similar use-after-free problem if it does. This should probably return
an error code rather than the object itself.
^ permalink raw reply
* Re: [PATCH v2] powernv/elog: Fix the race while processing OPAL error log event.
From: Oliver O'Halloran @ 2020-10-06 0:22 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli; +Cc: linuxppc-dev
In-Reply-To: <df7cebd0-bec3-d716-5514-61c4043a6d30@linux.ibm.com>
On Mon, Oct 5, 2020 at 11:07 PM Ananth N Mavinakayanahalli
<ananth@linux.ibm.com> wrote:
>
> On 10/5/20 9:42 AM, Mahesh Salgaonkar wrote:
> > Every error log reported by OPAL is exported to userspace through a sysfs
> > interface and notified using kobject_uevent(). The userspace daemon
> > (opal_errd) then reads the error log and acknowledges it error log is saved
> > safely to disk. Once acknowledged the kernel removes the respective sysfs
> > file entry causing respective resources getting released including kobject.
> >
> > However there are chances where user daemon may already be scanning elog
> > entries while new sysfs elog entry is being created by kernel. User daemon
> > may read this new entry and ack it even before kernel can notify userspace
> > about it through kobject_uevent() call. If that happens then we have a
> > potential race between elog_ack_store->kobject_put() and kobject_uevent
> > which can lead to use-after-free issue of a kernfs object resulting into a
> > kernel crash. This patch fixes this race by protecting a sysfs file
> > creation/notification by holding an additional reference count on kobject
> > until we safely send kobject_uevent().
> >
> > Reported-by: Oliver O'Halloran <oohall@gmail.com>
> > Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>
> cc stable?
+1
^ permalink raw reply
* Re: [RFC PATCH next-20200930] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Joe Perches @ 2020-10-05 18:46 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Kees Cook, Paul E . McKenney, Clang-Built-Linux ML, LKML,
Lai Jiangshan, Josh Triplett, Steven Rostedt, rcu, Miguel Ojeda,
Mathieu Desnoyers, Sedat Dilek, Paul Mackerras, linuxppc-dev
In-Reply-To: <CAKwvOdmW4ZSo0yz9ZUjFhjzzDkNAghKYk_hxn9tvrKLBgCXx-A@mail.gmail.com>
On Mon, 2020-10-05 at 11:36 -0700, Nick Desaulniers wrote:
> I don't think there's anything wrong with manually including it and adding `-I
> <path>` (capital i) if needed.
All of this is secondary to the actual change to use
quoted __section("foo") rather than __section(foo)
I'd rather get that done first and then figure out if
additional changes could be done later.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox