On Mon, Oct 30, 2017 at 07:09:21PM +0900, Byungchul Park wrote: > On Mon, Oct 30, 2017 at 09:22:03AM +0100, Michal Hocko wrote: > > [Cc Byungchul. The original full report is > > http://lkml.kernel.org/r/089e0825eec8955c1f055c83d476@xxxxxxxxxx] > > > > Could you have a look please? This smells like a false positive to me. > > +cc peterz@xxxxxxxxxxxxx > > Hello, > > IMHO, the false positive was caused by the lockdep_map of 'cpuhp_state' > which couldn't distinguish between cpu-up and cpu-down. > > And it was solved with the following commit by Peter and Thomas: > > 5f4b55e10645b7371322c800a5ec745cab487a6c > smp/hotplug: Differentiate the AP-work lockdep class between up and down > > Therefore, we can avoid the false positive on later than the commit. > > Peter and Thomas, could you confirm it? I can indeed confirm it's running old code; cpuhp_state is no more. However, that splat translates like: __cpuhp_setup_state() #0 cpus_read_lock() __cpuhp_setup_state_cpuslocked() #1 mutex_lock(&cpuhp_state_mutex) __cpuhp_state_add_instance() #2 mutex_lock(&cpuhp_state_mutex) cpuhp_issue_call() cpuhp_invoke_ap_callback() #3 wait_for_completion() msr_device_create() ... #4 filename_create() #3 complete() do_splice() #4 file_start_write() do_splice_from() iter_file_splice_write() #5 pipe_lock() vfs_iter_write() ... #6 inode_lock() sys_fcntl() do_fcntl() shmem_fcntl() #5 inode_lock() shmem_wait_for_pins() if (!scan) lru_add_drain_all() #0 cpus_read_lock() Which is an actual real deadlock, there is no mixing of up and down. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
