[v6.1] kernel BUG in ext4_writepages

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 1cc3fcf63192 Linux 6.1.18
git tree: linux-6.1.y
console output: https://syzkaller.appspot.com/x/log.txt?x=1659afb2c80000
kernel config: https://syzkaller.appspot.com/x/.config?x=ac04a15f4a80e9d0
dashboard link: https://syzkaller.appspot.com/bug?extid=a8068dd81edde0186829
compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/9dee98921f5a/disk-1cc3fcf6.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/713a648558bd/vmlinux-1cc3fcf6.xz
kernel image: https://storage.googleapis.com/syzbot-assets/6b9e84fcf1df/bzImage-1cc3fcf6.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a8068d...@syzkaller.appspotmail.com

------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2746!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 15790 Comm: kworker/u4:1 Not tainted 6.1.18-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
Workqueue: writeback wb_workfn (flush-7:4)
RIP: 0010:ext4_writepages+0x3fa9/0x3fb0 fs/ext4/inode.c:2745
Code: c7 10 73 0b 8d 4c 89 f2 e8 e4 42 2c 02 e9 b9 fb ff ff e8 ca 18 51 ff 0f 0b e8 c3 18 51 ff 0f 0b e8 9c 65 50 08 e8 b7 18 51 ff <0f> 0b 0f 1f 44 00 00 41 57 41 56 41 55 41 54 53 49 89 f7 49 89 fe
RSP: 0018:ffffc90004416f60 EFLAGS: 00010293
RAX: ffffffff82394869 RBX: 0000008000000000 RCX: ffff888019630000
RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000
RBP: ffffc90004417350 R08: ffffffff82390f50 R09: ffffed1016a8d50f
R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000001
R13: ffffc90004417710 R14: 0000008410000000 R15: ffffc90004417220
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30c29000 CR3: 000000002d533000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000006
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
do_writepages+0x3a2/0x670 mm/page-writeback.c:2469
__writeback_single_inode+0x1c4/0x15d0 fs/fs-writeback.c:1587
writeback_sb_inodes+0xbe3/0x1b10 fs/fs-writeback.c:1878
wb_writeback+0x504/0x1070 fs/fs-writeback.c:2052
wb_do_writeback fs/fs-writeback.c:2195 [inline]
wb_workfn+0x487/0x10f0 fs/fs-writeback.c:2235
process_one_work+0x909/0x1380 kernel/workqueue.c:2289
worker_thread+0xa5f/0x1210 kernel/workqueue.c:2436
kthread+0x268/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_writepages+0x3fa9/0x3fb0 fs/ext4/inode.c:2745
Code: c7 10 73 0b 8d 4c 89 f2 e8 e4 42 2c 02 e9 b9 fb ff ff e8 ca 18 51 ff 0f 0b e8 c3 18 51 ff 0f 0b e8 9c 65 50 08 e8 b7 18 51 ff <0f> 0b 0f 1f 44 00 00 41 57 41 56 41 55 41 54 53 49 89 f7 49 89 fe
RSP: 0018:ffffc90004416f60 EFLAGS: 00010293
RAX: ffffffff82394869 RBX: 0000008000000000 RCX: ffff888019630000
RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000
RBP: ffffc90004417350 R08: ffffffff82390f50 R09: ffffed1016a8d50f
R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000001
R13: ffffc90004417710 R14: 0000008410000000 R15: ffffc90004417220
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c019139000 CR3: 0000000029247000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000006
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400


---
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]

Hello,

syzbot found the following issue on:

HEAD commit: bbf9f29bac04 Linux 5.15.101
git tree: linux-5.15.y
console output: https://syzkaller.appspot.com/x/log.txt?x=164b0bcac80000
kernel config: https://syzkaller.appspot.com/x/.config?x=353a11a1dbfe7820
dashboard link: https://syzkaller.appspot.com/bug?extid=84277fde3a1f96f51f90

compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2

userspace arch: arm64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1438e0a4c80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17bb9724c80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/741458b6f24d/disk-bbf9f29b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/46cdc0f15ae5/vmlinux-bbf9f29b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/15bf795c52fa/Image-bbf9f29b.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/0c018a860327/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:

Reported-by: syzbot+84277f...@syzkaller.appspotmail.com

------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2732!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 136 Comm: kworker/u4:1 Not tainted 5.15.101-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023

Workqueue: writeback wb_workfn (flush-7:0)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ext4_writepages+0x3590/0x3594 fs/ext4/inode.c:2731
lr : ext4_writepages+0x3590/0x3594 fs/ext4/inode.c:2731
sp : ffff800019fe6d60
x29: ffff800019fe7140 x28: ffff800019fe7040 x27: 1ffff000033fceb2
x26: ffff0000dc8a6038 x25: 0000000000000001 x24: dfff800000000000
x23: ffff0000cfad0000 x22: ffff800019fe6f60 x21: ffff800019fe7590
x20: ffff0000dc8a5a08 x19: 0000008410000000 x18: ffff800019fe6a40
x17: ff8080000abc1a7c x16: ffff8000082ed0d4 x15: 000000000000f261
x14: 00000000ffffffff x13: ffffffffffffffff x12: 0000000000000000
x11: ff80800008da1638 x10: 0000000000000000 x9 : ffff800008da1638
x8 : ffff0000c23a0000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000080 x4 : 0000000000000000 x3 : 0000000000000001
x2 : 0000000000000000 x1 : 0000008000000000 x0 : 0000000000000000
Call trace:
ext4_writepages+0x3590/0x3594 fs/ext4/inode.c:2731
do_writepages+0x39c/0x5ec mm/page-writeback.c:2364
__writeback_single_inode+0x204/0x1afc fs/fs-writeback.c:1622
writeback_sb_inodes+0x9a0/0x17b0 fs/fs-writeback.c:1905
wb_writeback+0x4c4/0x1400 fs/fs-writeback.c:2079
wb_do_writeback fs/fs-writeback.c:2222 [inline]
wb_workfn+0x454/0x11ac fs/fs-writeback.c:2263
process_one_work+0x84c/0x14b8 kernel/workqueue.c:2306
worker_thread+0x910/0x1034 kernel/workqueue.c:2453
kthread+0x37c/0x45c kernel/kthread.c:319
ret_from_fork+0x10/0x20 <unknown>:870
Code: d4210000 97dc954c d4210000 97dc954a (d4210000)
---[ end trace 2fc6a849c01b632a ]---

---
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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: 1cc3fcf63192 Linux 6.1.18
git tree: linux-6.1.y

console output: https://syzkaller.appspot.com/x/log.txt?x=10d4b342c80000
kernel config: https://syzkaller.appspot.com/x/.config?x=157296d36f92ea19

dashboard link: https://syzkaller.appspot.com/bug?extid=a8068dd81edde0186829
compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2

userspace arch: arm64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13512ec6c80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15ca0ff4c80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0e4c0d43698b/disk-1cc3fcf6.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a4de39d735de/vmlinux-1cc3fcf6.xz
kernel image: https://storage.googleapis.com/syzbot-assets/82bab928f6e3/Image-1cc3fcf6.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/bf2e21b96210/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a8068d...@syzkaller.appspotmail.com

------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2746!

Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 11 Comm: kworker/u4:1 Not tainted 6.1.18-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023

Workqueue: writeback wb_workfn (flush-7:0)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)

pc : ext4_writepages+0x35f4/0x35f8 fs/ext4/inode.c:2745
lr : ext4_writepages+0x35f4/0x35f8 fs/ext4/inode.c:2745
sp : ffff800019d16d40
x29: ffff800019d17120 x28: ffff800008e691e4 x27: dfff800000000000
x26: ffff0000de1f3ee0 x25: ffff800019d17590 x24: ffff800019d17020
x23: ffff0000dd616000 x22: ffff800019d16f40 x21: ffff0000de1f4108
x20: 0000008410000000 x19: 0000000000000001 x18: ffff800019d16a20
x17: ffff80001572d000 x16: ffff8000083099b4 x15: 000000000000ba31
x14: 00000000ffffffff x13: dfff800000000000 x12: 0000000000000001
x11: ff80800008e6c7d8 x10: 0000000000000000 x9 : ffff800008e6c7d8
x8 : ffff0000c099b680 x7 : 0000000000000000 x6 : 0000000000000000

x5 : 0000000000000080 x4 : 0000000000000000 x3 : 0000000000000001
x2 : 0000000000000000 x1 : 0000008000000000 x0 : 0000000000000000
Call trace:

ext4_writepages+0x35f4/0x35f8 fs/ext4/inode.c:2745
do_writepages+0x2e8/0x56c mm/page-writeback.c:2469
__writeback_single_inode+0x228/0x1ec8 fs/fs-writeback.c:1587
writeback_sb_inodes+0x9c0/0x1844 fs/fs-writeback.c:1878
wb_writeback+0x4f8/0x1580 fs/fs-writeback.c:2052
wb_do_writeback fs/fs-writeback.c:2195 [inline]
wb_workfn+0x460/0x11b8 fs/fs-writeback.c:2235
process_one_work+0x868/0x16f4 kernel/workqueue.c:2289
worker_thread+0x8e4/0xfec kernel/workqueue.c:2436
kthread+0x24c/0x2d4 kernel/kthread.c:376
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
Code: d4210000 97da5cfa d4210000 97da5cf8 (d4210000)

[Muhammad Usama Anjum]

Hi,

Syzbot has reporting hitting this bug on 6.1.18 and 5.15.101 LTS kernels
and provided reproducer as well.

BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));

I've copied the same config and reproduced the bug on 6.1.18, 6.1.44 and
next-20230809.

This part of code hasn't been changed from the time it was introduced
4e7ea81db53465 ("ext4: restructure writeback path"). I'm not sure why the
inlined data is being destroyed before copying it somewhere else.

Please consider this a report.

Regards,
Muhammad Usama Anjum

On 3/13/23 11:34 AM, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: 1cc3fcf63192 Linux 6.1.18
> git tree: linux-6.1.y
> console output: https://syzkaller.appspot.com/x/log.txt?x=10d4b342c80000
> kernel config: https://syzkaller.appspot.com/x/.config?x=157296d36f92ea19

^ Kernel config

> dashboard link: https://syzkaller.appspot.com/bug?extid=a8068dd81edde0186829
> compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
> userspace arch: arm64
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13512ec6c80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15ca0ff4c80000

^ reproducers. C reproducer reproduces the bug easily.

--
BR,
Muhammad Usama Anjum

[Baokun Li]

Hello!

On 2023/8/10 18:49, Muhammad Usama Anjum wrote:
> Hi,
>
> Syzbot has reporting hitting this bug on 6.1.18 and 5.15.101 LTS kernels
> and provided reproducer as well.
>
> BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));
>
> I've copied the same config and reproduced the bug on 6.1.18, 6.1.44 and
> next-20230809.
>
> This part of code hasn't been changed from the time it was introduced
> 4e7ea81db53465 ("ext4: restructure writeback path"). I'm not sure why the
> inlined data is being destroyed before copying it somewhere else.
>
> Please consider this a report.
>
> Regards,
> Muhammad Usama Anjum

We've already noticed this problem, which is caused by the fact that

ext4_convert_inline_data() in ext4_page_mkwrite() is not protected by

an inode_lock, so it can modify the state of the inode while someone

else is holding the lock.

Unfortunately we don't have a good solution for this at the moment,

as adding inode_lock here could easily form an ABBA deadlock with

mmap_lock. For a more detailed discussion see:

     https://lkml.org/lkml/2023/5/30/894

With Best Regards,
Baokun Li
.

[Muhammad Usama Anjum]

On 8/10/23 4:30 PM, Baokun Li wrote:
> Hello!
>
> On 2023/8/10 18:49, Muhammad Usama Anjum wrote:
>> Hi,
>>
>> Syzbot has reporting hitting this bug on 6.1.18 and 5.15.101 LTS kernels
>> and provided reproducer as well.
>>
>>     BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));
>>
>> I've copied the same config and reproduced the bug on 6.1.18, 6.1.44 and
>> next-20230809.
>>
>> This part of code hasn't been changed from the time it was introduced
>> 4e7ea81db53465 ("ext4: restructure writeback path"). I'm not sure why the
>> inlined data is being destroyed before copying it somewhere else.
>>
>> Please consider this a report.
>>
>> Regards,
>> Muhammad Usama Anjum
>
> We've already noticed this problem, which is caused by the fact that
>
> ext4_convert_inline_data() in ext4_page_mkwrite() is not protected by
>
> an inode_lock, so it can modify the state of the inode while someone
>
> else is holding the lock.
>
> Unfortunately we don't have a good solution for this at the moment,
>
> as adding inode_lock here could easily form an ABBA deadlock with
>
> mmap_lock. For a more detailed discussion see:
>
>      https://lkml.org/lkml/2023/5/30/894

Thank you so much for replying, explaining and this reference.

BR,
Muhammad Usama Anjum

[Muhammad Usama Anjum]

The last refactoring was done by 4e7ea81db53465 on this code in 2013. The
code segment in question is present from even before that. It means that
this bug is present for several years. 4.14 is the most old kernel being
maintained today. So it affects all current LTS and mainline kernels. I'll
report 4e7ea81db53465 with regzbot for proper tracking. Thus probably the
bug report will get associated with all LTS kernels as well.

#regzbot title: Race condition between buffer write and page_mkwrite

#regzbot introduced: 4e7ea81db53465

#regzbot monitor:
https://lore.kernel.org/all/20230530134405.3...@huawei.com

[Muhammad Usama Anjum]

#regzbot title: ext4: Race condition between buffer write and page_mkwrite

[Theodore Ts'o]

On Mon, Aug 14, 2023 at 10:35:57AM +0500, Muhammad Usama Anjum wrote:
> > The last refactoring was done by 4e7ea81db53465 on this code in 2013. The
> > code segment in question is present from even before that. It means that
> > this bug is present for several years. 4.14 is the most old kernel being
> > maintained today. So it affects all current LTS and mainline kernels. I'll
> > report 4e7ea81db53465 with regzbot for proper tracking. Thus probably the
> > bug report will get associated with all LTS kernels as well.
> >
> > #regzbot title: Race condition between buffer write and page_mkwrite
>
> #regzbot title: ext4: Race condition between buffer write and page_mkwrite

If it's a long-standing bug, then it's really not something I consider
a regression. That being said, you're assuming that the refactoring
is what has introduced the bug; that's not necessarily case.

*Especially* if it requires a maliciously fuzzed file system, since
you have to be root to mount a file system. That's the other thing;
the different reports at the console have different reproducers, and
at least one of them has a very badly corrupted file system --- and
since you need to have root to mount the a maliciously fuzzed file
system, these are treated with a much lower priority as far as I'm
concerned.

(If you think it should be higher priority, and your company is
willing to fund such work, patches are greatfully appreciated. :-)

I tried to reproduce this using one of the reproducers on a modern
kernel, and it doesn't reproduce there. That being said, it's not
entirely what the reproducer is doing, since (a) passing -1 to the
in_fd and out_fd to sendfile *should* just cause sendfile to to return
an EBADF error, and (b) when I ran it, it just segfaulted on an mmap()
before it executed anything interesting.

Please let me know (a) if you can replicate this on the latest
upstream kernel, and (b) if the reproducer doesn't require a
maliciously fuzzed kernel, or where the reproducer is scribbling on
the file system image while it is mounted.

Cheers,

- Ted

[Muhammad Usama Anjum]

Thank you for looking at the email.

On 8/15/23 3:05 AM, Theodore Ts'o wrote:
> On Mon, Aug 14, 2023 at 10:35:57AM +0500, Muhammad Usama Anjum wrote:
>>> The last refactoring was done by 4e7ea81db53465 on this code in 2013. The
>>> code segment in question is present from even before that. It means that
>>> this bug is present for several years. 4.14 is the most old kernel being
>>> maintained today. So it affects all current LTS and mainline kernels. I'll
>>> report 4e7ea81db53465 with regzbot for proper tracking. Thus probably the
>>> bug report will get associated with all LTS kernels as well.
>>>
>>> #regzbot title: Race condition between buffer write and page_mkwrite
>>
>> #regzbot title: ext4: Race condition between buffer write and page_mkwrite
>
> If it's a long-standing bug, then it's really not something I consider
> a regression. That being said, you're assuming that the refactoring
> is what has introduced the bug; that's not necessarily case.

The bug was introduced by the following patch:
9c3569b50f12 ("ext4: add delalloc support for inline data")

https://lore.kernel.org/all/1351047338-4963-7...@tao.ma/
The bug is in the inline data feature addition patches itself.

Should I remove this regression from regzbot marking it as not regression
and only a long-standing bug?

>
> *Especially* if it requires a maliciously fuzzed file system, since
> you have to be root to mount a file system. That's the other thing;
> the different reports at the console have different reproducers, and
> at least one of them has a very badly corrupted file system --- and
> since you need to have root to mount the a maliciously fuzzed file
> system, these are treated with a much lower priority as far as I'm
> concerned.
>
> (If you think it should be higher priority, and your company is
> willing to fund such work, patches are greatfully appreciated. :-)
>
> I tried to reproduce this using one of the reproducers on a modern
> kernel, and it doesn't reproduce there. That being said, it's not
> entirely what the reproducer is doing, since (a) passing -1 to the
> in_fd and out_fd to sendfile *should* just cause sendfile to to return
> an EBADF error, and (b) when I ran it, it just segfaulted on an mmap()
> before it executed anything interesting.
>
> Please let me know (a) if you can replicate this on the latest
> upstream kernel, and (b) if the reproducer doesn't require a
> maliciously fuzzed kernel, or where the reproducer is scribbling on
> the file system image while it is mounted.

I can replicate the bug on next-20230809 with the attached config and
reproducer application. Root permissions are required for the bug to get
reproduced though.

>
> Cheers,
>
> - Ted

[Linux regression tracking (Thorsten Leemhuis)]

On 15.08.23 18:31, Muhammad Usama Anjum wrote:
> Thank you for looking at the email.
>
> On 8/15/23 3:05 AM, Theodore Ts'o wrote:
>> On Mon, Aug 14, 2023 at 10:35:57AM +0500, Muhammad Usama Anjum wrote:
>>>> The last refactoring was done by 4e7ea81db53465 on this code in 2013. The
>>>> code segment in question is present from even before that. It means that
>>>> this bug is present for several years. 4.14 is the most old kernel being
>>>> maintained today. So it affects all current LTS and mainline kernels. I'll
>>>> report 4e7ea81db53465 with regzbot for proper tracking. Thus probably the
>>>> bug report will get associated with all LTS kernels as well.
>>>>
>>>> #regzbot title: Race condition between buffer write and page_mkwrite
>>>
>>> #regzbot title: ext4: Race condition between buffer write and page_mkwrite
>>
>> If it's a long-standing bug, then it's really not something I consider
>> a regression. That being said, you're assuming that the refactoring
>> is what has introduced the bug; that's not necessarily case.
> The bug was introduced by the following patch:
> 9c3569b50f12 ("ext4: add delalloc support for inline data")

Which was v3.8-rc1 afaics.

> https://lore.kernel.org/all/1351047338-4963-7...@tao.ma/
> The bug is in the inline data feature addition patches itself.
>
> Should I remove this regression from regzbot marking it as not regression
> and only a long-standing bug?

Let me do that:

#regzbot inconclusive: regression from the 3.8 days, tracking doesn't
really gain us anything

To explain: not sure how Linus sees it, but if the culprit was merged
that long ago there is not much worth in tracking it, as there is no
easy way to fix it with a revert or something anyway. Sure, the issue
nevertheless should not remain unfixed, but lets trust Ted here that
he'll sooner or later take care of it when he sees fit.

Ciao, Thorsten