From: Dmitry Vyukov via Linux-kernel-mentees <hidden> Date: 2020-10-14 07:57:30
FYI Gmail has a setting of making Replay All the default button.
On Wed, Oct 14, 2020 at 9:39 AM Fox Chen [off-list ref] wrote:
Hi,
I found this bug was caused by either uid/gid info in superblocks or
id_index_table is corrupted. The uid/gid index is larger than the size of
msblk->id_table.
Should I add a sanity check to squashfs_get_id??
The complete solution is to record the size of msblk->id_table in msblk
and check uid/gid index each time in squashfs_get_id. However, this
requires a change to msblk struct.
A simple solution is to calculate the max available room for uid/gid table
by doing msblk->xattr_table - msblk->id_table[0] and check if index is
larger than this. While this provides some sort of check, it is imperfect
because id_table can be smaller than that.
Both of them work out for this bug.
thanks,
fox
On Friday, September 25, 2020 at 10:48:18 PM UTC+8 syzbot wrote:
quoted
Hello,
syzbot found the following issue on:
HEAD commit: 171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead3900000
kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc
dashboard link:
https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172ff481900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c3e6c5900000
IMPORTANT: if you fix the issue, please add the following tag to the
commit:
Reported-by: syzbot+8e28bb...@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in squashfs_get_id+0xb9/0x1c0
fs/squashfs/id.c:38
Read of size 8 at addr ffff8880a9684b98 by task syz-executor329/6836
CPU: 1 PID: 6836 Comm: syz-executor329 Not tainted 5.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d6/0x29e lib/dump_stack.c:118
print_address_description+0x66/0x620 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report+0x132/0x1d0 mm/kasan/report.c:530
squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38
squashfs_new_inode fs/squashfs/inode.c:51 [inline]
squashfs_read_inode+0x155/0x2170 fs/squashfs/inode.c:120
squashfs_fill_super+0x1478/0x1790 fs/squashfs/super.c:310
get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342
vfs_get_tree+0x88/0x270 fs/super.c:1547
do_new_mount fs/namespace.c:2875 [inline]
path_mount+0x179d/0x29e0 fs/namespace.c:3192
do_mount fs/namespace.c:3205 [inline]
__do_sys_mount fs/namespace.c:3413 [inline]
__se_sys_mount+0x126/0x180 fs/namespace.c:3390
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d1a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e
0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0
ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:00007ffd7dd4f8b8 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffd7dd4f910 RCX: 0000000000446d1a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd7dd4f8d0
RBP: 00007ffd7dd4f8d0 R08: 00007ffd7dd4f910 R09: 00007ffd00000015
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001
R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003
Allocated by task 3913:
kasan_save_stack mm/kasan/common.c:48 [inline]
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461
kmalloc_node include/linux/slab.h:577 [inline]
__vmalloc_area_node mm/vmalloc.c:2429 [inline]
__vmalloc_node_range+0x2c7/0x870 mm/vmalloc.c:2511
module_alloc+0x7e/0x90 arch/x86/kernel/module.c:75
bpf_jit_binary_alloc+0x123/0x230 kernel/bpf/core.c:871
bpf_int_jit_compile+0x7995/0x8920 arch/x86/net/bpf_jit_comp.c:1911
bpf_prog_select_runtime+0x76d/0xa60 kernel/bpf/core.c:1807
bpf_migrate_filter net/core/filter.c:1290 [inline]
bpf_prepare_filter+0xec2/0x1140 net/core/filter.c:1338
bpf_prog_create_from_user+0x2ad/0x3e0 net/core/filter.c:1432
seccomp_prepare_filter kernel/seccomp.c:567 [inline]
seccomp_prepare_user_filter kernel/seccomp.c:604 [inline]
seccomp_set_mode_filter kernel/seccomp.c:1546 [inline]
do_seccomp+0x852/0x20b0 kernel/seccomp.c:1661
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at ffff8880a9684b80
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 24 bytes inside of
32-byte region [ffff8880a9684b80, ffff8880a9684ba0)
The buggy address belongs to the page:
page:00000000f697ca3d refcount:1 mapcount:0 mapping:0000000000000000
index:0xffff8880a9684fc1 pfn:0xa9684
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002a5d5c8 ffffea0002a98588 ffff8880aa440100
raw: ffff8880a9684fc1 ffff8880a9684000 000000010000003f 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a9684a80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff8880a9684b00: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc
quoted
ffff8880a9684b80: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc
^
ffff8880a9684c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff8880a9684c80: 00 00 01 fc fc fc fc fc fa fb fb fb fc fc fc fc
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Oh, Thank you, Dmitry!
I firstly replied to this from
https://groups.google.com/g/syzkaller-bugs/c/SPtlDDI7jmw/m/BtgjaCcDAwAJ.
I don't know why "reply all" only replies to syzkaller-bugs and I
didn't notice that.
Sorry about that.
On Wed, Oct 14, 2020 at 3:57 PM Dmitry Vyukov [off-list ref] wrote:
FYI Gmail has a setting of making Replay All the default button.
On Wed, Oct 14, 2020 at 9:39 AM Fox Chen [off-list ref] wrote:
quoted
Hi,
I found this bug was caused by either uid/gid info in superblocks or id_index_table is corrupted. The uid/gid index is larger than the size of msblk->id_table.
Should I add a sanity check to squashfs_get_id??
The complete solution is to record the size of msblk->id_table in msblk and check uid/gid index each time in squashfs_get_id. However, this requires a change to msblk struct.
A simple solution is to calculate the max available room for uid/gid table by doing msblk->xattr_table - msblk->id_table[0] and check if index is larger than this. While this provides some sort of check, it is imperfect because id_table can be smaller than that.
Both of them work out for this bug.
thanks,
fox
On Friday, September 25, 2020 at 10:48:18 PM UTC+8 syzbot wrote:
quoted
Hello,
syzbot found the following issue on:
HEAD commit: 171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead3900000
kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc
dashboard link: https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172ff481900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c3e6c5900000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8e28bb...@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38
Read of size 8 at addr ffff8880a9684b98 by task syz-executor329/6836
CPU: 1 PID: 6836 Comm: syz-executor329 Not tainted 5.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d6/0x29e lib/dump_stack.c:118
print_address_description+0x66/0x620 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report+0x132/0x1d0 mm/kasan/report.c:530
squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38
squashfs_new_inode fs/squashfs/inode.c:51 [inline]
squashfs_read_inode+0x155/0x2170 fs/squashfs/inode.c:120
squashfs_fill_super+0x1478/0x1790 fs/squashfs/super.c:310
get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342
vfs_get_tree+0x88/0x270 fs/super.c:1547
do_new_mount fs/namespace.c:2875 [inline]
path_mount+0x179d/0x29e0 fs/namespace.c:3192
do_mount fs/namespace.c:3205 [inline]
__do_sys_mount fs/namespace.c:3413 [inline]
__se_sys_mount+0x126/0x180 fs/namespace.c:3390
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d1a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:00007ffd7dd4f8b8 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffd7dd4f910 RCX: 0000000000446d1a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd7dd4f8d0
RBP: 00007ffd7dd4f8d0 R08: 00007ffd7dd4f910 R09: 00007ffd00000015
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001
R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003
Allocated by task 3913:
kasan_save_stack mm/kasan/common.c:48 [inline]
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461
kmalloc_node include/linux/slab.h:577 [inline]
__vmalloc_area_node mm/vmalloc.c:2429 [inline]
__vmalloc_node_range+0x2c7/0x870 mm/vmalloc.c:2511
module_alloc+0x7e/0x90 arch/x86/kernel/module.c:75
bpf_jit_binary_alloc+0x123/0x230 kernel/bpf/core.c:871
bpf_int_jit_compile+0x7995/0x8920 arch/x86/net/bpf_jit_comp.c:1911
bpf_prog_select_runtime+0x76d/0xa60 kernel/bpf/core.c:1807
bpf_migrate_filter net/core/filter.c:1290 [inline]
bpf_prepare_filter+0xec2/0x1140 net/core/filter.c:1338
bpf_prog_create_from_user+0x2ad/0x3e0 net/core/filter.c:1432
seccomp_prepare_filter kernel/seccomp.c:567 [inline]
seccomp_prepare_user_filter kernel/seccomp.c:604 [inline]
seccomp_set_mode_filter kernel/seccomp.c:1546 [inline]
do_seccomp+0x852/0x20b0 kernel/seccomp.c:1661
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at ffff8880a9684b80
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 24 bytes inside of
32-byte region [ffff8880a9684b80, ffff8880a9684ba0)
The buggy address belongs to the page:
page:00000000f697ca3d refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880a9684fc1 pfn:0xa9684
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002a5d5c8 ffffea0002a98588 ffff8880aa440100
raw: ffff8880a9684fc1 ffff8880a9684000 000000010000003f 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a9684a80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff8880a9684b00: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc
quoted
ffff8880a9684b80: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc
^
ffff8880a9684c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff8880a9684c80: 00 00 01 fc fc fc fc fc fa fb fb fb fc fc fc fc
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Oh, from groups. Yes, that won't work for the kernel. That also
generated an HTML email, which is generally not welcome on kernel
mailing lists.
On Wed, Oct 14, 2020 at 3:57 PM Dmitry Vyukov [off-list ref] wrote:
quoted
FYI Gmail has a setting of making Replay All the default button.
On Wed, Oct 14, 2020 at 9:39 AM Fox Chen [off-list ref] wrote:
quoted
Hi,
I found this bug was caused by either uid/gid info in superblocks or id_index_table is corrupted. The uid/gid index is larger than the size of msblk->id_table.
Should I add a sanity check to squashfs_get_id??
The complete solution is to record the size of msblk->id_table in msblk and check uid/gid index each time in squashfs_get_id. However, this requires a change to msblk struct.
A simple solution is to calculate the max available room for uid/gid table by doing msblk->xattr_table - msblk->id_table[0] and check if index is larger than this. While this provides some sort of check, it is imperfect because id_table can be smaller than that.
Both of them work out for this bug.
thanks,
fox
On Friday, September 25, 2020 at 10:48:18 PM UTC+8 syzbot wrote:
quoted
Hello,
syzbot found the following issue on:
HEAD commit: 171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead3900000
kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc
dashboard link: https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172ff481900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c3e6c5900000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8e28bb...@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38
Read of size 8 at addr ffff8880a9684b98 by task syz-executor329/6836
CPU: 1 PID: 6836 Comm: syz-executor329 Not tainted 5.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d6/0x29e lib/dump_stack.c:118
print_address_description+0x66/0x620 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report+0x132/0x1d0 mm/kasan/report.c:530
squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38
squashfs_new_inode fs/squashfs/inode.c:51 [inline]
squashfs_read_inode+0x155/0x2170 fs/squashfs/inode.c:120
squashfs_fill_super+0x1478/0x1790 fs/squashfs/super.c:310
get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342
vfs_get_tree+0x88/0x270 fs/super.c:1547
do_new_mount fs/namespace.c:2875 [inline]
path_mount+0x179d/0x29e0 fs/namespace.c:3192
do_mount fs/namespace.c:3205 [inline]
__do_sys_mount fs/namespace.c:3413 [inline]
__se_sys_mount+0x126/0x180 fs/namespace.c:3390
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d1a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:00007ffd7dd4f8b8 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffd7dd4f910 RCX: 0000000000446d1a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd7dd4f8d0
RBP: 00007ffd7dd4f8d0 R08: 00007ffd7dd4f910 R09: 00007ffd00000015
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001
R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003
Allocated by task 3913:
kasan_save_stack mm/kasan/common.c:48 [inline]
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461
kmalloc_node include/linux/slab.h:577 [inline]
__vmalloc_area_node mm/vmalloc.c:2429 [inline]
__vmalloc_node_range+0x2c7/0x870 mm/vmalloc.c:2511
module_alloc+0x7e/0x90 arch/x86/kernel/module.c:75
bpf_jit_binary_alloc+0x123/0x230 kernel/bpf/core.c:871
bpf_int_jit_compile+0x7995/0x8920 arch/x86/net/bpf_jit_comp.c:1911
bpf_prog_select_runtime+0x76d/0xa60 kernel/bpf/core.c:1807
bpf_migrate_filter net/core/filter.c:1290 [inline]
bpf_prepare_filter+0xec2/0x1140 net/core/filter.c:1338
bpf_prog_create_from_user+0x2ad/0x3e0 net/core/filter.c:1432
seccomp_prepare_filter kernel/seccomp.c:567 [inline]
seccomp_prepare_user_filter kernel/seccomp.c:604 [inline]
seccomp_set_mode_filter kernel/seccomp.c:1546 [inline]
do_seccomp+0x852/0x20b0 kernel/seccomp.c:1661
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at ffff8880a9684b80
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 24 bytes inside of
32-byte region [ffff8880a9684b80, ffff8880a9684ba0)
The buggy address belongs to the page:
page:00000000f697ca3d refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880a9684fc1 pfn:0xa9684
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002a5d5c8 ffffea0002a98588 ffff8880aa440100
raw: ffff8880a9684fc1 ffff8880a9684000 000000010000003f 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a9684a80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff8880a9684b00: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc
quoted
ffff8880a9684b80: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc
^
ffff8880a9684c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff8880a9684c80: 00 00 01 fc fc fc fc fc fa fb fb fb fc fc fc fc
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
On Wed, Oct 14, 2020 at 4:27 PM Dmitry Vyukov [off-list ref] wrote:
Oh, from groups. Yes, that won't work for the kernel. That also
generated an HTML email, which is generally not welcome on kernel
mailing lists.
Got it! thank you!
If I miss the original email, without using "groups", how can I reply
to the thread??
Apart from manually copying/pasting the content, recipients, and
setting in-reply-to, Is there any convenient way??
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
From: Dmitry Vyukov via Linux-kernel-mentees <hidden> Date: 2020-10-14 09:21:31
On Wed, Oct 14, 2020 at 11:13 AM Fox Chen [off-list ref] wrote:
quoted
Oh, from groups. Yes, that won't work for the kernel. That also
generated an HTML email, which is generally not welcome on kernel
mailing lists.
Got it! thank you!
If I miss the original email, without using "groups", how can I reply
to the thread??
Apart from manually copying/pasting the content, recipients, and
setting in-reply-to, Is there any convenient way??
No, unfortunately, no convenient way. Nature of email-based
development workflow.
I think I've seen some web archives in the past that allowed you to
forward an email to yourself, and then you can reply to it normally.
But I don't remember where it was. Maybe you can find it.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
On Wed, Oct 14, 2020 at 11:21 AM Dmitry Vyukov via
Linux-kernel-mentees [off-list ref]
wrote:
On Wed, Oct 14, 2020 at 11:13 AM Fox Chen [off-list ref] wrote:
quoted
quoted
Oh, from groups. Yes, that won't work for the kernel. That also
generated an HTML email, which is generally not welcome on kernel
mailing lists.
Got it! thank you!
If I miss the original email, without using "groups", how can I reply
to the thread??
Apart from manually copying/pasting the content, recipients, and
setting in-reply-to, Is there any convenient way??
No, unfortunately, no convenient way. Nature of email-based
development workflow.
I think I've seen some web archives in the past that allowed you to
forward an email to yourself, and then you can reply to it normally.
But I don't remember where it was. Maybe you can find it.
If the mailing list is archived on lore.kernel.org
(https://lore.kernel.org/lists.html), you can search the email there
and you will find a suitable mailto link (which might work for your
client)
Alternatively, you can download an mbox, load that with an email
client, and then respond from mutt, pine etc.
syzkaller-bugs is not archived at lore.kernel.org, but I assumed all
those emails there also go out to lkml.
If useful, we could ask to archive syzkaller-bugs on lore.kernel.org as well.
Lukas
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
If the mailing list is archived on lore.kernel.org
(https://lore.kernel.org/lists.html), you can search the email there
and you will find a suitable mailto link (which might work for your
client)
Alternatively, you can download an mbox, load that with an email
client, and then respond from mutt, pine etc.
Oh, Great!
syzkaller-bugs is not archived at lore.kernel.org, but I assumed all
those emails there also go out to lkml.
If useful, we could ask to archive syzkaller-bugs on lore.kernel.org as well.
From: Dmitry Vyukov via Linux-kernel-mentees <hidden> Date: 2020-10-14 09:36:47
On Wed, Oct 14, 2020 at 11:28 AM Lukas Bulwahn [off-list ref] wrote:
On Wed, Oct 14, 2020 at 11:21 AM Dmitry Vyukov via
Linux-kernel-mentees [off-list ref]
wrote:
quoted
On Wed, Oct 14, 2020 at 11:13 AM Fox Chen [off-list ref] wrote:
quoted
quoted
Oh, from groups. Yes, that won't work for the kernel. That also
generated an HTML email, which is generally not welcome on kernel
mailing lists.
Got it! thank you!
If I miss the original email, without using "groups", how can I reply
to the thread??
Apart from manually copying/pasting the content, recipients, and
setting in-reply-to, Is there any convenient way??
No, unfortunately, no convenient way. Nature of email-based
development workflow.
I think I've seen some web archives in the past that allowed you to
forward an email to yourself, and then you can reply to it normally.
But I don't remember where it was. Maybe you can find it.
If the mailing list is archived on lore.kernel.org
(https://lore.kernel.org/lists.html), you can search the email there
and you will find a suitable mailto link (which might work for your
client)
Alternatively, you can download an mbox, load that with an email
client, and then respond from mutt, pine etc.
syzkaller-bugs is not archived at lore.kernel.org, but I assumed all
those emails there also go out to lkml.
If useful, we could ask to archive syzkaller-bugs on lore.kernel.org as well.
On Wed, Oct 14, 2020 at 05:13:29PM +0800, Fox Chen wrote:
On Wed, Oct 14, 2020 at 4:27 PM Dmitry Vyukov [off-list ref] wrote:
quoted
Oh, from groups. Yes, that won't work for the kernel. That also
generated an HTML email, which is generally not welcome on kernel
mailing lists.
Got it! thank you!
If I miss the original email, without using "groups", how can I reply
to the thread??
If the tool lets you, just download the "raw" message, and load it in
your email client and respond to it from there.
I know lore.kernel.org has the option to save it this way, then just use
a mail client like mutt:
mutt -f message_downloaded.txt
and away you go.
If your email client does not let you do this, perhaps you need a better
email client :)
thanks,
greg k-h
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
Hi Anant, Dmitry, Greg,
Wow, mbox & raw work. lore has mailto link, just on-click, even more convenient.
And, yes, I've found the mail on linux-kernel list.
Thank you all for the help! :)
Cheers!
fox
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees