On 11/18/2013 01:21 AM, Meelis Roos wrote:
This patch seems to switch ldata with its read_buf and echo_buf from kmalloc/kfree to vmalloc/vfree (the bufs are now inlined in ldata, not separately allocated). More fields in ldata are now explicitly initialized to zero instead of kzalloc doing it before. However, I do not see the initialization of some of the fields - maybe they are done later in the code? I noticed process_char_map, raw, real_raw, icanon, read_buf, echo_buf that were zeroed before but I did not find explicit zeroing of them after the patch. However, just adding a memset to zero ldata after vmalloc does not change anything. Openpromfs does not seem to be changed after 3.11 and it does not seem to use any tty layer functions. I still have no idea how it would interact.I turned off most imaginable debug options - pagealloc, kobject, lockdep and kmemcheck among others. Lockdep got one on still working kernel, with the state just at the bad commit, on shutdown: ====================================================== [ INFO: possible circular locking dependency detected ] 3.11.0-rc2-00058-g20bafb3-dirty #121 Tainted: G W ------------------------------------------------------- bash/2383 is trying to acquire lock: (&tty->termios_rwsem){++++.+}, at: [<0000000000633648>] n_tty_read+0x368/0x620 but task is already holding lock: (&ldata->atomic_read_lock){+.+.+.}, at: [<000000000063343c>] n_tty_read+0x15c/0x620 which lock already depends on the new lock.
This is a false positive lockdep report that was fixed with commit aefceaf453024ef4cf8a0f93c4b1edf6c6f748bf, 'n_tty: Fix termios_rwsem lockdep false positive', which was added in 3.12-rc3.
[00000000004060b4] linux_sparc_syscall32+0x34/0x40 This is UP machine so the race probably did not happen?
Even on SMP there is no race (and thus no deadlock) because the CPU holding the termios_rwsem has a read lock and thus cannot prevent the other CPU from also acquiring a read lock while holding the atomic_read_lock. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
