Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

linux/rockchip/dvfs.h is missing #148

Open
Llerr opened this issue Mar 21, 2019 · 1 comment
Open

linux/rockchip/dvfs.h is missing #148

Llerr opened this issue Mar 21, 2019 · 1 comment

Comments

@Llerr
Copy link

Llerr commented Mar 21, 2019

I try compile kernel for PX5 board, and add driver for PowerVR Rogue M.
In compilation time I have error

drivers/gpu/rogue_m/system/rk3368/rk_init.c:15:10: fatal error: linux/rockchip/dvfs.h: No such file or directory
#include <linux/rockchip/dvfs.h>
@Caesar-github
Copy link
Member

I didn't think this kernel support the PX50 board.

0lvin pushed a commit to free-z4u/roc-rk3328-cc-official that referenced this issue Oct 6, 2019
@kiran-modukuri @dhowells
fscache: Fix reference overput in fscache_attach_object() error handling
f29507c 
When a cookie is allocated that causes fscache_object structs to be
allocated, those objects are initialised with the cookie pointer, but
aren't blessed with a ref on that cookie unless the attachment is
successfully completed in fscache_attach_object().

If attachment fails because the parent object was dying or there was a
collision, fscache_attach_object() returns without incrementing the cookie
counter - but upon failure of this function, the object is released which
then puts the cookie, whether or not a ref was taken on the cookie.

Fix this by taking a ref on the cookie when it is assigned in
fscache_object_init(), even when we're creating a root object.


Analysis from Kiran Kumar:

This bug has been seen in 4.4.0-124-generic rockchip-linux#148-Ubuntu kernel

BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776277

fscache cookie ref count updated incorrectly during fscache object
allocation resulting in following Oops.

kernel BUG at /build/linux-Y09MKI/linux-4.4.0/fs/fscache/internal.h:321!
kernel BUG at /build/linux-Y09MKI/linux-4.4.0/fs/fscache/cookie.c:639!

[Cause]
Two threads are trying to do operate on a cookie and two objects.

(1) One thread tries to unmount the filesystem and in process goes over a
    huge list of objects marking them dead and deleting the objects.
    cookie->usage is also decremented in following path:

      nfs_fscache_release_super_cookie
       -> __fscache_relinquish_cookie
        ->__fscache_cookie_put
        ->BUG_ON(atomic_read(&cookie->usage) <= 0);

(2) A second thread tries to lookup an object for reading data in following
    path:

    fscache_alloc_object
    1) cachefiles_alloc_object
        -> fscache_object_init
           -> assign cookie, but usage not bumped.
    2) fscache_attach_object -> fails in cant_attach_object because the
         cookie's backing object or cookie's->parent object are going away
    3) fscache_put_object
        -> cachefiles_put_object
          ->fscache_object_destroy
            ->fscache_cookie_put
               ->BUG_ON(atomic_read(&cookie->usage) <= 0);

[NOTE from dhowells] It's unclear as to the circumstances in which (2) can
take place, given that thread (1) is in nfs_kill_super(), however a
conflicting NFS mount with slightly different parameters that creates a
different superblock would do it.  A backtrace from Kiran seems to show
that this is a possibility:

    kernel BUG at/build/linux-Y09MKI/linux-4.4.0/fs/fscache/cookie.c:639!
    ...
    RIP: __fscache_cookie_put+0x3a/0x40 [fscache]
    Call Trace:
     __fscache_relinquish_cookie+0x87/0x120 [fscache]
     nfs_fscache_release_super_cookie+0x2d/0xb0 [nfs]
     nfs_kill_super+0x29/0x40 [nfs]
     deactivate_locked_super+0x48/0x80
     deactivate_super+0x5c/0x60
     cleanup_mnt+0x3f/0x90
     __cleanup_mnt+0x12/0x20
     task_work_run+0x86/0xb0
     exit_to_usermode_loop+0xc2/0xd0
     syscall_return_slowpath+0x4e/0x60
     int_ret_from_sys_call+0x25/0x9f

[Fix] Bump up the cookie usage in fscache_object_init, when it is first
being assigned a cookie atomically such that the cookie is added and bumped
up if its refcount is not zero.  Remove the assignment in
fscache_attach_object().

[Testcase]
I have run ~100 hours of NFS stress tests and not seen this bug recur.

[Regression Potential]
 - Limited to fscache/cachefiles.

Fixes: ccc4fc3 ("FS-Cache: Implement the cookie management part of the netfs API")
Signed-off-by: Kiran Kumar Modukuri <kiran.modukuri@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Joern-P pushed a commit to Joern-P/kernel that referenced this issue Sep 6, 2020
@ayufan
ayufan: defconfig: add a bunch of kernel modules
98debd5 
Change-Id: I9f2c1b0d8d56a8d3da1774f51a4701212ac6ffff

added IPGRE module to enable: (rockchip-linux#18)

ip tunnel add grx mode gre

Change-Id: I26bda9ece68f9f6be1277da0779076694d5d845c

ayufan: rockchip_linux_defconfig compile ZRAM as module

Change-Id: I2ee48973cb370130cc5d75008a07d5777c69208a

ayufan: rockchip_defconfig: disable CONFIG_SCHED_WALT as it makes system unstable

Change-Id: Id2a150311fcaad9f11127320558dc3caafb250e4

config: add more USB wifi chipsets (rockchip-linux#19)

* Add some more USB wifi chipsets to default config.

* Fix typo in default config.

Added openvswitch kernel module compilation (rockchip-linux#22)

ayufan: defconfig: add RK805 pinctrl

Change-Id: I9144206544db4e86e73a4d553fb8db3aa194c619

ayufan: enable additional realtek devices

Change-Id: Ie3598c47154b648540f161ad4aedd597bc33f83f

config: Add support for modules/features requested by issues rockchip-linux#24 (AUTOFS4), rockchip-linux#54 (DRBD), rockchip-linux#64 (Multiple Routing Tables), rockchip-linux#87 (RTL8188EU), rockchip-linux#107 (iSCSI), rockchip-linux#148 (1-W GPIO) (rockchip-linux#24)

ayufan: rtl8812au: add Edimax 600 USB adapter

Add requested kernel modules/features for issue rockchip-linux#153 and LIRC, PPS GPIO support, remove wifi staging drivers. (rockchip-linux#25)

Fix compile error (rockchip-linux#26)

Multiple definition error due to midgard and bifrost both selected

ayufan: defconfig: add a bunch of kernel modules

Change-Id: I77f5c4809c35b6c74a3bb668487eba93a0a15169

ayufan: rockchip_wlan: revert changes

Change-Id: I6aa0bbc24e2fdfb6da350ed167d59c4eea836c2a

ayufan: defconfig: enable CONFIG_MEMTEST

Change-Id: I82c3d1b2d35fb10172f891571ef600a692ac4e61

ayufan: defconfig: remove unusued kernel configs

Change-Id: I2a4a2e5785dd5796bb7404718898127718b86425

ayufan: defconfig: enable initrd in bzip2/lzma/lzo/lz4

Change-Id: I88ea1f8127d8fdadf90dd4428a51a1582adc2687

ayufan: defconfig: enable PWM FAN

Change-Id: I87a364e95d937c354e06eb41fead43d8d5cb0b4a

external: defconfig: Add support for f2fs and crc32 (rockchip-linux#32)

Add support for f2fs and it's dependency crc32 to rock64.

This patch may or may not need to be included as well due to this bug https://bugs.debian.org/819725    A official patch was added by Debian https://salsa.debian.org/kernel-team/linux/blob/master/debian/patches/bugfix/all/fs-add-module_softdep-declarations-for-hard-coded-cr.patch

external: defconfig: enable kernel modules for RBD and IPVS (rockchip-linux#33)

external: defconfig: Make crc, crc32, f2fs to be compiled into kernel. (rockchip-linux#35)

This changes crc, crc32, and f2fs to be compiled into the kernel instead of as module. This also fixes the issue of crc32-arm64 not being compiled due to a incorrect driver name.  CONFIG_CRYPTO_CRC32_ARM64 became CONFIG_CRYPTO_CRC32_ARM64_CE in newer kernel sources. That's why I had to change that here.

ayufan: defconfig: use CONFIG_HZ=250

Change-Id: I8009db93ee7c5af5e7804a004ab03d0ba97d20e2

CONFIG_SQUASHFS_XZ=y (rockchip-linux#41)

cyberp: defconfig: squashfs xz for snap support

defconfig: enable binfmt-misc (rockchip-linux#36)

ayufan: defconfig: organize with savedefconfig

ayufan: defconfig: support tehuti 10gbps adapter

ayufan: defconfig: enable usb gadget via configfs

ayufan: dts: compile-in audio codecs

Change-Id: I7c70870395a10a0eafff006aabc17faf1d33355e
scpcom pushed a commit to scpcom/linux that referenced this issue Mar 4, 2023
@SunHao-0 @gregkh
bpf: Skip task with pid=1 in send_signal_common()
a1c0263 
[ Upstream commit a3d81bc ]

The following kernel panic can be triggered when a task with pid=1 attaches
a prog that attempts to send killing signal to itself, also see [1] for more
details:

  Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
  CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f rockchip-linux#148
  Call Trace:
  <TASK>
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
  panic+0x2c4/0x60f kernel/panic.c:275
  do_exit.cold+0x63/0xe4 kernel/exit.c:789
  do_group_exit+0xd4/0x2a0 kernel/exit.c:950
  get_signal+0x2460/0x2600 kernel/signal.c:2858
  arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306
  exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
  exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
  __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
  syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
  do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
  entry_SYSCALL_64_after_hwframe+0x63/0xcd

So skip task with pid=1 in bpf_send_signal_common() to avoid the panic.

  [1] https://lore.kernel.org/bpf/20221222043507.33037-1-sunhao.th@gmail.com

Signed-off-by: Hao Sun <sunhao.th@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20230106084838.12690-1-sunhao.th@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
scpcom pushed a commit to scpcom/linux that referenced this issue Apr 12, 2023
@SunHao-0 @gregkh
bpf: Skip task with pid=1 in send_signal_common()
0dfef50 
[ Upstream commit a3d81bc ]

The following kernel panic can be triggered when a task with pid=1 attaches
a prog that attempts to send killing signal to itself, also see [1] for more
details:

  Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
  CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f rockchip-linux#148
  Call Trace:
  <TASK>
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
  panic+0x2c4/0x60f kernel/panic.c:275
  do_exit.cold+0x63/0xe4 kernel/exit.c:789
  do_group_exit+0xd4/0x2a0 kernel/exit.c:950
  get_signal+0x2460/0x2600 kernel/signal.c:2858
  arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306
  exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
  exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
  __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
  syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
  do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
  entry_SYSCALL_64_after_hwframe+0x63/0xcd

So skip task with pid=1 in bpf_send_signal_common() to avoid the panic.

  [1] https://lore.kernel.org/bpf/20221222043507.33037-1-sunhao.th@gmail.com

Signed-off-by: Hao Sun <sunhao.th@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20230106084838.12690-1-sunhao.th@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Caesar-github @Llerr