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

15.1 screen too bright. #21

Open
francogp opened this issue May 22, 2018 · 0 comments
Open

15.1 screen too bright. #21

francogp opened this issue May 22, 2018 · 0 comments

Comments

@francogp
Copy link

Automatic screen bright set the bright to max with a simple indoor light. Even setting a preference to 15% is at max!. The bright only start to change if the scroll bar is on the 15% on the lower end. That problem.is consuming all my battery because of too much bright. My only temporal fix is to set bright to manual and change it to almost the minimum.
xtrymind pushed a commit to xtrymind/android_kernel_xiaomi_msm8953 that referenced this issue May 30, 2018
@maurizio-lombardi @gregkh
cdrom: do not call check_disk_change() inside cdrom_open()
0fdfc3f 
[ Upstream commit 2bbea6e ]

when mounting an ISO filesystem sometimes (very rarely)
the system hangs because of a race condition between two tasks.

PID: 6766   TASK: ffff88007b2a6dd0  CPU: 0   COMMAND: "mount"
 #0 [ffff880078447ae0] __schedule at ffffffff8168d605
 TheScarastic#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49
 TheScarastic#2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995
 TheScarastic#3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef
 TheScarastic#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod]
 TheScarastic#5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50
 TheScarastic#6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3
 TheScarastic#7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs]
 #8 [ffff880078447da8] mount_bdev at ffffffff81202570
 TheScarastic#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs]
TheScarastic#10 [ffff880078447e28] mount_fs at ffffffff81202d09
TheScarastic#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f
TheScarastic#12 [ffff880078447ea8] do_mount at ffffffff81220fee
TheScarastic#13 [ffff880078447f28] sys_mount at ffffffff812218d6
TheScarastic#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49
    RIP: 00007fd9ea914e9a  RSP: 00007ffd5d9bf648  RFLAGS: 00010246
    RAX: 00000000000000a5  RBX: ffffffff81698c49  RCX: 0000000000000010
    RDX: 00007fd9ec2bc210  RSI: 00007fd9ec2bc290  RDI: 00007fd9ec2bcf30
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000010
    R10: 00000000c0ed0001  R11: 0000000000000206  R12: 00007fd9ec2bc040
    R13: 00007fd9eb6b2380  R14: 00007fd9ec2bc210  R15: 00007fd9ec2bcf30
    ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b

This task was trying to mount the cdrom.  It allocated and configured a
super_block struct and owned the write-lock for the super_block->s_umount
rwsem. While exclusively owning the s_umount lock, it called
sr_block_ioctl and waited to acquire the global sr_mutex lock.

PID: 6785   TASK: ffff880078720fb0  CPU: 0   COMMAND: "systemd-udevd"
 #0 [ffff880078417898] __schedule at ffffffff8168d605
 TheScarastic#1 [ffff880078417900] schedule at ffffffff8168dc59
 TheScarastic#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605
 TheScarastic#3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838
 TheScarastic#4 [ffff8800784179d0] down_read at ffffffff8168cde0
 TheScarastic#5 [ffff8800784179e8] get_super at ffffffff81201cc7
 TheScarastic#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de
 TheScarastic#7 [ffff880078417a40] flush_disk at ffffffff8123a94b
 #8 [ffff880078417a88] check_disk_change at ffffffff8123ab50
 TheScarastic#9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom]
TheScarastic#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod]
TheScarastic#11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86
TheScarastic#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65
TheScarastic#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b
TheScarastic#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7
TheScarastic#15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf
TheScarastic#16 [ffff880078417d00] do_last at ffffffff8120d53d
TheScarastic#17 [ffff880078417db0] path_openat at ffffffff8120e6b2
TheScarastic#18 [ffff880078417e48] do_filp_open at ffffffff8121082b
TheScarastic#19 [ffff880078417f18] do_sys_open at ffffffff811fdd33
TheScarastic#20 [ffff880078417f70] sys_open at ffffffff811fde4e
TheScarastic#21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49
    RIP: 00007f29438b0c20  RSP: 00007ffc76624b78  RFLAGS: 00010246
    RAX: 0000000000000002  RBX: ffffffff81698c49  RCX: 0000000000000000
    RDX: 00007f2944a5fa70  RSI: 00000000000a0800  RDI: 00007f2944a5fa70
    RBP: 00007f2944a5f540   R8: 0000000000000000   R9: 0000000000000020
    R10: 00007f2943614c40  R11: 0000000000000246  R12: ffffffff811fde4e
    R13: ffff880078417f78  R14: 000000000000000c  R15: 00007f2944a4b010
    ORIG_RAX: 0000000000000002  CS: 0033  SS: 002b

This task tried to open the cdrom device, the sr_block_open function
acquired the global sr_mutex lock. The call to check_disk_change()
then saw an event flag indicating a possible media change and tried
to flush any cached data for the device.
As part of the flush, it tried to acquire the super_block->s_umount
lock associated with the cdrom device.
This was the same super_block as created and locked by the previous task.

The first task acquires the s_umount lock and then the sr_mutex_lock;
the second task acquires the sr_mutex_lock and then the s_umount lock.

This patch fixes the issue by moving check_disk_change() out of
cdrom_open() and let the caller take care of it.

Signed-off-by: Maurizio Lombardi <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
RahifM pushed a commit to RahifM/android_kernel_xiaomi_msm8953 that referenced this issue Aug 12, 2022
@chaseyu @TheScarastic
f2fs: fix to set superblock dirty correctly
eb0d2ab 
tests/generic/251 of fstest suit complains us with below message:

------------[ cut here ]------------
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 7698 Comm: fstrim Tainted: G           O    4.7.0+ TheScarastic#21
task: e9f4e000 task.stack: e7262000
EIP: 0060:[<f89fcefe>] EFLAGS: 00010202 CPU: 2
EIP is at write_checkpoint+0xfde/0x1020 [f2fs]
EAX: f33eb300 EBX: eecac310 ECX: 00000001 EDX: ffff0001
ESI: eecac000 EDI: eecac5f0 EBP: e7263dec ESP: e7263d18
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 80050033 CR2: b76ab01c CR3: 2eb89de0 CR4: 000406f0
Stack:
 00000001 a220fb7b e9f4e000 00000002 419ff2d3 b3a05151 00000002 e9f4e5d8
 e9f4e000 419ff2d3 b3a05151 eecac310 c10b8154 b3a05151 419ff2d3 c10b78bd
 e9f4e000 e9f4e000 e9f4e5d8 00000001 e9f4e000 ec409000 eecac2cc eecac288
Call Trace:
 [<c10b8154>] ? __lock_acquire+0x3c4/0x760
 [<c10b78bd>] ? mark_held_locks+0x5d/0x80
 [<f8a10632>] f2fs_trim_fs+0x1c2/0x2e0 [f2fs]
 [<f89e9f56>] f2fs_ioctl+0x6b6/0x10b0 [f2fs]
 [<c13d51df>] ? __this_cpu_preempt_check+0xf/0x20
 [<c10b4281>] ? trace_hardirqs_off_caller+0x91/0x120
 [<f89e98a0>] ? __exchange_data_block+0xd30/0xd30 [f2fs]
 [<c120b2e1>] do_vfs_ioctl+0x81/0x7f0
 [<c11d57c5>] ? kmem_cache_free+0x245/0x2e0
 [<c1217840>] ? get_unused_fd_flags+0x40/0x40
 [<c1206eec>] ? putname+0x4c/0x50
 [<c11f631e>] ? do_sys_open+0x16e/0x1d0
 [<c1001990>] ? do_fast_syscall_32+0x30/0x1c0
 [<c13d51df>] ? __this_cpu_preempt_check+0xf/0x20
 [<c120baa8>] SyS_ioctl+0x58/0x80
 [<c1001a01>] do_fast_syscall_32+0xa1/0x1c0
 [<c178cc54>] sysenter_past_esp+0x45/0x74
EIP: [<f89fcefe>] write_checkpoint+0xfde/0x1020 [f2fs] SS:ESP 0068:e7263d18
---[ end trace 4de95d7e6b3aa7c6 ]---

The reason is: with below call stack, we will encounter BUG_ON during
doing fstrim.

Thread A				Thread B
- write_checkpoint
 - do_checkpoint
					- f2fs_write_inode
					 - update_inode_page
					  - update_inode
					   - set_page_dirty
					    - f2fs_set_node_page_dirty
					     - inc_page_count
					      - percpu_counter_inc
					      - set_sbi_flag(SBI_IS_DIRTY)
  - clear_sbi_flag(SBI_IS_DIRTY)

Thread C				Thread D
- f2fs_write_node_page
 - set_node_addr
  - __set_nat_cache_dirty
   - nm_i->dirty_nat_cnt++
					- do_vfs_ioctl
					 - f2fs_ioctl
					  - f2fs_trim_fs
					   - write_checkpoint
					    - f2fs_bug_on(nm_i->dirty_nat_cnt)

Fix it by setting superblock dirty correctly in do_checkpoint and
f2fs_write_node_page.

Signed-off-by: Chao Yu <[email protected]>
Signed-off-by: Jaegeuk Kim <[email protected]>
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
1 participant
@francogp