Re: Regression in 028abd92 for Sun UltraSPARC T1
On 24.03.21 09:28, Christoph Hellwig wrote:
On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote:
028abd9222df0cf5855dab5014a5ebaf06f90565
...is broken on my T1000.
As I don't know how big attachments can be on this list, I put the logs
on pastebin.
A log for 028abd9222df is here:
https://pastebin.com/ApPYsMcu
Just do confirm: in this tree line 304 in mm/slub.c is this BUG_ON:
BUG_ON(object == fp); /* naive detection of double free or corruption */
which would mean we have a double free. In that case it would be
interesting which call to kfree this is, which could be done by
calling gdb on vmlinux and then typing;
l *(sys_mount+0x114/0x1e0)
Not that a double free caused by this conversion makes any sense to me..
Finally - a T1 thread is so slow (for untaring) that I untared the
tarball from my X4270 cross-compile host to the T1000's root FS in the end:
```
root@t1000:~/mnt/torvalds-linux# git describe
v5.9-rc1-3-g028abd9222df
root@t1000:~/mnt/torvalds-linux# gdb -q vmlinux
Reading symbols from vmlinux...
(gdb) l *(sys_mount+0x114/0x1e0)
0x6c6380 is in __se_sys_mount (fs/namespace.c:3390).
3385 /* ... and return the root of (sub)tree on it */
3386 return path.dentry;
3387 }
3388 EXPORT_SYMBOL(mount_subtree);
3389
3390 SYSCALL_DEFINE5(mount, char __user *, dev_name, char __user *,
dir_name,
3391 char __user *, type, unsigned long, flags, void __user *, data)
3392 {
3393 int ret;
3394 char *kernel_type;
(gdb)
```
...not sure if that adds anything to what Anatoly already provided apart
from the "correct" line numbers for the actually used kernel.
Cheers,
Frank
Reply to: