From: "Michael S. Tsirkin" <mst@redhat.com> To: Jason Wang <jasowang@redhat.com> Cc: syzbot <syzbot+e58112d71f77113ddb7b@syzkaller.appspotmail.com>, aarcange@redhat.com, akpm@linux-foundation.org, christian@brauner.io, davem@davemloft.net, ebiederm@xmission.com, elena.reshetova@intel.com, guro@fb.com, hch@infradead.org, james.bottomley@hansenpartnership.com, jglisse@redhat.com, keescook@chromium.org, ldv@altlinux.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, luto@amacapital.net, mhocko@suse.com, mingo@kernel.org, namit@vmware.com, peterz@infradead.org, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk, wad@chromium.org Subject: Re: WARNING in __mmdrop Date: Tue, 23 Jul 2019 01:01:49 -0400 [thread overview] Message-ID: <20190723010019-mutt-send-email-mst@kernel.org> (raw) In-Reply-To: <4bd2ff78-6871-55f2-44dc-0982ffef3337@redhat.com> On Tue, Jul 23, 2019 at 12:01:40PM +0800, Jason Wang wrote: > > On 2019/7/22 下午4:08, Michael S. Tsirkin wrote: > > On Mon, Jul 22, 2019 at 01:24:24PM +0800, Jason Wang wrote: > > > On 2019/7/21 下午8:18, Michael S. Tsirkin wrote: > > > > On Sun, Jul 21, 2019 at 06:02:52AM -0400, Michael S. Tsirkin wrote: > > > > > On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote: > > > > > > syzbot has bisected this bug to: > > > > > > > > > > > > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc > > > > > > Author: Jason Wang<jasowang@redhat.com> > > > > > > Date: Fri May 24 08:12:18 2019 +0000 > > > > > > > > > > > > vhost: access vq metadata through kernel virtual address > > > > > > > > > > > > bisection log:https://syzkaller.appspot.com/x/bisect.txt?x=149a8a20600000 > > > > > > start commit: 6d21a41b Add linux-next specific files for 20190718 > > > > > > git tree: linux-next > > > > > > final crash:https://syzkaller.appspot.com/x/report.txt?x=169a8a20600000 > > > > > > console output:https://syzkaller.appspot.com/x/log.txt?x=129a8a20600000 > > > > > > kernel config:https://syzkaller.appspot.com/x/.config?x=3430a151e1452331 > > > > > > dashboard link:https://syzkaller.appspot.com/bug?extid=e58112d71f77113ddb7b > > > > > > syz repro:https://syzkaller.appspot.com/x/repro.syz?x=10139e68600000 > > > > > > > > > > > > Reported-by:syzbot+e58112d71f77113ddb7b@syzkaller.appspotmail.com > > > > > > Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual > > > > > > address") > > > > > > > > > > > > For information about bisection process see:https://goo.gl/tpsmEJ#bisection > > > > > OK I poked at this for a bit, I see several things that > > > > > we need to fix, though I'm not yet sure it's the reason for > > > > > the failures: > > > > > > > > > > > > > > > 1. mmu_notifier_register shouldn't be called from vhost_vring_set_num_addr > > > > > That's just a bad hack, in particular I don't think device > > > > > mutex is taken and so poking at two VQs will corrupt > > > > > memory. > > > > > So what to do? How about a per vq notifier? > > > > > Of course we also have synchronize_rcu > > > > > in the notifier which is slow and is now going to be called twice. > > > > > I think call_rcu would be more appropriate here. > > > > > We then need rcu_barrier on module unload. > > > > > OTOH if we make pages linear with map then we are good > > > > > with kfree_rcu which is even nicer. > > > > > > > > > > 2. Doesn't map leak after vhost_map_unprefetch? > > > > > And why does it poke at contents of the map? > > > > > No one should use it right? > > > > > > > > > > 3. notifier unregister happens last in vhost_dev_cleanup, > > > > > but register happens first. This looks wrong to me. > > > > > > > > > > 4. OK so we use the invalidate count to try and detect that > > > > > some invalidate is in progress. > > > > > I am not 100% sure why do we care. > > > > > Assuming we do, uaddr can change between start and end > > > > > and then the counter can get negative, or generally > > > > > out of sync. > > > > > > > > > > So what to do about all this? > > > > > I am inclined to say let's just drop the uaddr optimization > > > > > for now. E.g. kvm invalidates unconditionally. > > > > > 3 should be fixed independently. > > > > Above implements this but is only build-tested. > > > > Jason, pls take a look. If you like the approach feel > > > > free to take it from here. > > > > > > > > One thing the below does not have is any kind of rate-limiting. > > > > Given it's so easy to restart I'm thinking it makes sense > > > > to add a generic infrastructure for this. > > > > Can be a separate patch I guess. > > > > > > I don't get why must use kfree_rcu() instead of synchronize_rcu() here. > > synchronize_rcu has very high latency on busy systems. > > It is not something that should be used on a syscall path. > > KVM had to switch to SRCU to keep it sane. > > Otherwise one guest can trivially slow down another one. > > > I think you mean the synchronize_rcu_expedited()? Rethink of the code, the > synchronize_rcu() in ioctl() could be removed, since it was serialized with > memory accessor. Really let's just use kfree_rcu. It's way cleaner: fire and forget. > > Btw, for kvm ioctl it still uses synchronize_rcu() in kvm_vcpu_ioctl(), > (just a little bit more hard to trigger): AFAIK these never run in response to guest events. So they can take very long and guests still won't crash. > > case KVM_RUN: { > ... > if (unlikely(oldpid != task_pid(current))) { > /* The thread running this VCPU changed. */ > struct pid *newpid; > > r = kvm_arch_vcpu_run_pid_change(vcpu); > if (r) > break; > > newpid = get_task_pid(current, PIDTYPE_PID); > rcu_assign_pointer(vcpu->pid, newpid); > if (oldpid) > synchronize_rcu(); > put_pid(oldpid); > } > ... > break; > > > > > > > > Signed-off-by: Michael S. Tsirkin<mst@redhat.com> > > > > > > Let me try to figure out the root cause then decide whether or not to go for > > > this way. > > > > > > Thanks > > The root cause of the crash is relevant, but we still need > > to fix issues 1-4. > > > > More issues (my patch tries to fix them too): > > > > 5. page not dirtied when mappings are torn down outside > > of invalidate callback > > > Yes. > > > > > > 6. potential cross-VM DOS by one guest keeping system busy > > and increasing synchronize_rcu latency to the point where > > another guest stars timing out and crashes > > > > > > > > This will be addressed after I remove the synchronize_rcu() from ioctl path. > > Thanks
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com> To: Jason Wang <jasowang@redhat.com> Cc: mhocko@suse.com, peterz@infradead.org, ldv@altlinux.org, james.bottomley@hansenpartnership.com, linux-mm@kvack.org, namit@vmware.com, mingo@kernel.org, elena.reshetova@intel.com, keescook@chromium.org, aarcange@redhat.com, davem@davemloft.net, hch@infradead.org, christian@brauner.io, syzbot <syzbot+e58112d71f77113ddb7b@syzkaller.appspotmail.com>, syzkaller-bugs@googlegroups.com, jglisse@redhat.com, viro@zeniv.linux.org.uk, linux-arm-kernel@lists.infradead.org, wad@chromium.org, linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org, luto@amacapital.net, ebiederm@xmission.com, akpm@linux-foundation.org, guro@fb.com Subject: Re: WARNING in __mmdrop Date: Tue, 23 Jul 2019 01:01:49 -0400 [thread overview] Message-ID: <20190723010019-mutt-send-email-mst@kernel.org> (raw) In-Reply-To: <4bd2ff78-6871-55f2-44dc-0982ffef3337@redhat.com> On Tue, Jul 23, 2019 at 12:01:40PM +0800, Jason Wang wrote: > > On 2019/7/22 下午4:08, Michael S. Tsirkin wrote: > > On Mon, Jul 22, 2019 at 01:24:24PM +0800, Jason Wang wrote: > > > On 2019/7/21 下午8:18, Michael S. Tsirkin wrote: > > > > On Sun, Jul 21, 2019 at 06:02:52AM -0400, Michael S. Tsirkin wrote: > > > > > On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote: > > > > > > syzbot has bisected this bug to: > > > > > > > > > > > > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc > > > > > > Author: Jason Wang<jasowang@redhat.com> > > > > > > Date: Fri May 24 08:12:18 2019 +0000 > > > > > > > > > > > > vhost: access vq metadata through kernel virtual address > > > > > > > > > > > > bisection log:https://syzkaller.appspot.com/x/bisect.txt?x=149a8a20600000 > > > > > > start commit: 6d21a41b Add linux-next specific files for 20190718 > > > > > > git tree: linux-next > > > > > > final crash:https://syzkaller.appspot.com/x/report.txt?x=169a8a20600000 > > > > > > console output:https://syzkaller.appspot.com/x/log.txt?x=129a8a20600000 > > > > > > kernel config:https://syzkaller.appspot.com/x/.config?x=3430a151e1452331 > > > > > > dashboard link:https://syzkaller.appspot.com/bug?extid=e58112d71f77113ddb7b > > > > > > syz repro:https://syzkaller.appspot.com/x/repro.syz?x=10139e68600000 > > > > > > > > > > > > Reported-by:syzbot+e58112d71f77113ddb7b@syzkaller.appspotmail.com > > > > > > Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual > > > > > > address") > > > > > > > > > > > > For information about bisection process see:https://goo.gl/tpsmEJ#bisection > > > > > OK I poked at this for a bit, I see several things that > > > > > we need to fix, though I'm not yet sure it's the reason for > > > > > the failures: > > > > > > > > > > > > > > > 1. mmu_notifier_register shouldn't be called from vhost_vring_set_num_addr > > > > > That's just a bad hack, in particular I don't think device > > > > > mutex is taken and so poking at two VQs will corrupt > > > > > memory. > > > > > So what to do? How about a per vq notifier? > > > > > Of course we also have synchronize_rcu > > > > > in the notifier which is slow and is now going to be called twice. > > > > > I think call_rcu would be more appropriate here. > > > > > We then need rcu_barrier on module unload. > > > > > OTOH if we make pages linear with map then we are good > > > > > with kfree_rcu which is even nicer. > > > > > > > > > > 2. Doesn't map leak after vhost_map_unprefetch? > > > > > And why does it poke at contents of the map? > > > > > No one should use it right? > > > > > > > > > > 3. notifier unregister happens last in vhost_dev_cleanup, > > > > > but register happens first. This looks wrong to me. > > > > > > > > > > 4. OK so we use the invalidate count to try and detect that > > > > > some invalidate is in progress. > > > > > I am not 100% sure why do we care. > > > > > Assuming we do, uaddr can change between start and end > > > > > and then the counter can get negative, or generally > > > > > out of sync. > > > > > > > > > > So what to do about all this? > > > > > I am inclined to say let's just drop the uaddr optimization > > > > > for now. E.g. kvm invalidates unconditionally. > > > > > 3 should be fixed independently. > > > > Above implements this but is only build-tested. > > > > Jason, pls take a look. If you like the approach feel > > > > free to take it from here. > > > > > > > > One thing the below does not have is any kind of rate-limiting. > > > > Given it's so easy to restart I'm thinking it makes sense > > > > to add a generic infrastructure for this. > > > > Can be a separate patch I guess. > > > > > > I don't get why must use kfree_rcu() instead of synchronize_rcu() here. > > synchronize_rcu has very high latency on busy systems. > > It is not something that should be used on a syscall path. > > KVM had to switch to SRCU to keep it sane. > > Otherwise one guest can trivially slow down another one. > > > I think you mean the synchronize_rcu_expedited()? Rethink of the code, the > synchronize_rcu() in ioctl() could be removed, since it was serialized with > memory accessor. Really let's just use kfree_rcu. It's way cleaner: fire and forget. > > Btw, for kvm ioctl it still uses synchronize_rcu() in kvm_vcpu_ioctl(), > (just a little bit more hard to trigger): AFAIK these never run in response to guest events. So they can take very long and guests still won't crash. > > case KVM_RUN: { > ... > if (unlikely(oldpid != task_pid(current))) { > /* The thread running this VCPU changed. */ > struct pid *newpid; > > r = kvm_arch_vcpu_run_pid_change(vcpu); > if (r) > break; > > newpid = get_task_pid(current, PIDTYPE_PID); > rcu_assign_pointer(vcpu->pid, newpid); > if (oldpid) > synchronize_rcu(); > put_pid(oldpid); > } > ... > break; > > > > > > > > Signed-off-by: Michael S. Tsirkin<mst@redhat.com> > > > > > > Let me try to figure out the root cause then decide whether or not to go for > > > this way. > > > > > > Thanks > > The root cause of the crash is relevant, but we still need > > to fix issues 1-4. > > > > More issues (my patch tries to fix them too): > > > > 5. page not dirtied when mappings are torn down outside > > of invalidate callback > > > Yes. > > > > > > 6. potential cross-VM DOS by one guest keeping system busy > > and increasing synchronize_rcu latency to the point where > > another guest stars timing out and crashes > > > > > > > > This will be addressed after I remove the synchronize_rcu() from ioctl path. > > Thanks _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-07-23 5:01 UTC|newest] Thread overview: 176+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-19 3:35 WARNING in __mmdrop syzbot 2019-07-20 10:08 ` syzbot 2019-07-20 10:08 ` syzbot 2019-07-20 10:08 ` syzbot 2019-07-21 10:02 ` Michael S. Tsirkin 2019-07-21 10:02 ` Michael S. Tsirkin 2019-07-21 12:18 ` Michael S. Tsirkin 2019-07-21 12:18 ` Michael S. Tsirkin 2019-07-22 5:24 ` Jason Wang 2019-07-22 5:24 ` Jason Wang 2019-07-22 8:08 ` Michael S. Tsirkin 2019-07-22 8:08 ` Michael S. Tsirkin 2019-07-23 4:01 ` Jason Wang 2019-07-23 4:01 ` Jason Wang 2019-07-23 5:01 ` Michael S. Tsirkin [this message] 2019-07-23 5:01 ` Michael S. Tsirkin 2019-07-23 5:47 ` Jason Wang 2019-07-23 5:47 ` Jason Wang 2019-07-23 7:23 ` Michael S. Tsirkin 2019-07-23 7:23 ` Michael S. Tsirkin 2019-07-23 7:53 ` Jason Wang 2019-07-23 7:53 ` Jason Wang 2019-07-23 8:10 ` Michael S. Tsirkin 2019-07-23 8:10 ` Michael S. Tsirkin 2019-07-23 8:49 ` Jason Wang 2019-07-23 8:49 ` Jason Wang 2019-07-23 9:26 ` Michael S. Tsirkin 2019-07-23 9:26 ` Michael S. Tsirkin 2019-07-23 13:31 ` Jason Wang 2019-07-23 13:31 ` Jason Wang 2019-07-25 5:52 ` Michael S. Tsirkin 2019-07-25 5:52 ` Michael S. Tsirkin 2019-07-25 7:43 ` Jason Wang 2019-07-25 7:43 ` Jason Wang 2019-07-25 8:28 ` Michael S. Tsirkin 2019-07-25 8:28 ` Michael S. Tsirkin 2019-07-25 13:21 ` Jason Wang 2019-07-25 13:21 ` Jason Wang 2019-07-25 13:26 ` Michael S. Tsirkin 2019-07-25 13:26 ` Michael S. Tsirkin 2019-07-25 14:25 ` Jason Wang 2019-07-25 14:25 ` Jason Wang 2019-07-26 11:49 ` Michael S. Tsirkin 2019-07-26 11:49 ` Michael S. Tsirkin 2019-07-26 12:00 ` Jason Wang 2019-07-26 12:00 ` Jason Wang 2019-07-26 12:38 ` Michael S. Tsirkin 2019-07-26 12:38 ` Michael S. Tsirkin 2019-07-26 12:53 ` Jason Wang 2019-07-26 12:53 ` Jason Wang 2019-07-26 13:36 ` Jason Wang 2019-07-26 13:36 ` Jason Wang 2019-07-26 13:49 ` Michael S. Tsirkin 2019-07-26 13:49 ` Michael S. Tsirkin 2019-07-29 5:54 ` Jason Wang 2019-07-29 5:54 ` Jason Wang 2019-07-29 8:59 ` Michael S. Tsirkin 2019-07-29 8:59 ` Michael S. Tsirkin 2019-07-29 14:24 ` Jason Wang 2019-07-29 14:24 ` Jason Wang 2019-07-29 14:44 ` Michael S. Tsirkin 2019-07-29 14:44 ` Michael S. Tsirkin 2019-07-30 7:44 ` Jason Wang 2019-07-30 7:44 ` Jason Wang 2019-07-30 8:03 ` Jason Wang 2019-07-30 8:03 ` Jason Wang 2019-07-30 15:08 ` Michael S. Tsirkin 2019-07-30 15:08 ` Michael S. Tsirkin 2019-07-31 8:49 ` Jason Wang 2019-07-31 8:49 ` Jason Wang 2019-07-31 23:00 ` Jason Gunthorpe 2019-07-31 23:00 ` Jason Gunthorpe 2019-07-26 13:47 ` Michael S. Tsirkin 2019-07-26 13:47 ` Michael S. Tsirkin 2019-07-26 14:00 ` Jason Wang 2019-07-26 14:00 ` Jason Wang 2019-07-26 14:10 ` Michael S. Tsirkin 2019-07-26 14:10 ` Michael S. Tsirkin 2019-07-26 15:03 ` Jason Gunthorpe 2019-07-26 15:03 ` Jason Gunthorpe 2019-07-29 5:56 ` Jason Wang 2019-07-29 5:56 ` Jason Wang 2019-07-21 12:28 ` RFC: call_rcu_outstanding (was Re: WARNING in __mmdrop) Michael S. Tsirkin 2019-07-21 12:28 ` Michael S. Tsirkin 2019-07-21 13:17 ` Paul E. McKenney 2019-07-21 13:17 ` Paul E. McKenney 2019-07-21 17:53 ` Michael S. Tsirkin 2019-07-21 17:53 ` Michael S. Tsirkin 2019-07-21 19:28 ` Paul E. McKenney 2019-07-21 19:28 ` Paul E. McKenney 2019-07-22 7:56 ` Michael S. Tsirkin 2019-07-22 7:56 ` Michael S. Tsirkin 2019-07-22 11:57 ` Paul E. McKenney 2019-07-22 11:57 ` Paul E. McKenney 2019-07-21 21:08 ` Matthew Wilcox 2019-07-21 21:08 ` Matthew Wilcox 2019-07-21 23:31 ` Paul E. McKenney 2019-07-21 23:31 ` Paul E. McKenney 2019-07-22 7:52 ` Michael S. Tsirkin 2019-07-22 7:52 ` Michael S. Tsirkin 2019-07-22 11:51 ` Paul E. McKenney 2019-07-22 11:51 ` Paul E. McKenney 2019-07-22 13:41 ` Jason Gunthorpe 2019-07-22 13:41 ` Jason Gunthorpe 2019-07-22 15:52 ` Paul E. McKenney 2019-07-22 15:52 ` Paul E. McKenney 2019-07-22 16:04 ` Jason Gunthorpe 2019-07-22 16:04 ` Jason Gunthorpe 2019-07-22 16:15 ` Michael S. Tsirkin 2019-07-22 16:15 ` Michael S. Tsirkin 2019-07-22 16:15 ` Paul E. McKenney 2019-07-22 16:15 ` Paul E. McKenney 2019-07-22 15:14 ` Joel Fernandes 2019-07-22 15:14 ` Joel Fernandes 2019-07-22 15:47 ` Michael S. Tsirkin 2019-07-22 15:47 ` Michael S. Tsirkin 2019-07-22 15:55 ` Paul E. McKenney 2019-07-22 15:55 ` Paul E. McKenney 2019-07-22 16:13 ` Michael S. Tsirkin 2019-07-22 16:13 ` Michael S. Tsirkin 2019-07-22 16:25 ` Paul E. McKenney 2019-07-22 16:25 ` Paul E. McKenney 2019-07-22 16:32 ` Michael S. Tsirkin 2019-07-22 16:32 ` Michael S. Tsirkin 2019-07-22 18:58 ` Paul E. McKenney 2019-07-22 18:58 ` Paul E. McKenney 2019-07-22 5:21 ` WARNING in __mmdrop Jason Wang 2019-07-22 5:21 ` Jason Wang 2019-07-22 8:02 ` Michael S. Tsirkin 2019-07-22 8:02 ` Michael S. Tsirkin 2019-07-23 3:55 ` Jason Wang 2019-07-23 3:55 ` Jason Wang 2019-07-23 5:02 ` Michael S. Tsirkin 2019-07-23 5:02 ` Michael S. Tsirkin 2019-07-23 5:48 ` Jason Wang 2019-07-23 5:48 ` Jason Wang 2019-07-23 7:25 ` Michael S. Tsirkin 2019-07-23 7:25 ` Michael S. Tsirkin 2019-07-23 7:55 ` Jason Wang 2019-07-23 7:55 ` Jason Wang 2019-07-23 7:56 ` Michael S. Tsirkin 2019-07-23 7:56 ` Michael S. Tsirkin 2019-07-23 8:42 ` Jason Wang 2019-07-23 8:42 ` Jason Wang 2019-07-23 10:27 ` Michael S. Tsirkin 2019-07-23 10:27 ` Michael S. Tsirkin 2019-07-23 13:34 ` Jason Wang 2019-07-23 13:34 ` Jason Wang 2019-07-23 15:02 ` Michael S. Tsirkin 2019-07-23 15:02 ` Michael S. Tsirkin 2019-07-24 2:17 ` Jason Wang 2019-07-24 2:17 ` Jason Wang 2019-07-24 8:05 ` Michael S. Tsirkin 2019-07-24 8:05 ` Michael S. Tsirkin 2019-07-24 10:08 ` Jason Wang 2019-07-24 10:08 ` Jason Wang 2019-07-24 18:25 ` Michael S. Tsirkin 2019-07-24 18:25 ` Michael S. Tsirkin 2019-07-25 3:44 ` Jason Wang 2019-07-25 3:44 ` Jason Wang 2019-07-25 5:09 ` Michael S. Tsirkin 2019-07-25 5:09 ` Michael S. Tsirkin 2019-07-24 16:53 ` Jason Gunthorpe 2019-07-24 16:53 ` Jason Gunthorpe 2019-07-24 18:25 ` Michael S. Tsirkin 2019-07-24 18:25 ` Michael S. Tsirkin 2019-07-23 10:42 ` Michael S. Tsirkin 2019-07-23 10:42 ` Michael S. Tsirkin 2019-07-23 13:37 ` Jason Wang 2019-07-23 13:37 ` Jason Wang 2019-07-22 14:11 ` Jason Gunthorpe 2019-07-22 14:11 ` Jason Gunthorpe 2019-07-25 6:02 ` Michael S. Tsirkin 2019-07-25 6:02 ` Michael S. Tsirkin 2019-07-25 7:44 ` Jason Wang 2019-07-25 7:44 ` Jason Wang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190723010019-mutt-send-email-mst@kernel.org \ --to=mst@redhat.com \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=christian@brauner.io \ --cc=davem@davemloft.net \ --cc=ebiederm@xmission.com \ --cc=elena.reshetova@intel.com \ --cc=guro@fb.com \ --cc=hch@infradead.org \ --cc=james.bottomley@hansenpartnership.com \ --cc=jasowang@redhat.com \ --cc=jglisse@redhat.com \ --cc=keescook@chromium.org \ --cc=ldv@altlinux.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-parisc@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mhocko@suse.com \ --cc=mingo@kernel.org \ --cc=namit@vmware.com \ --cc=peterz@infradead.org \ --cc=syzbot+e58112d71f77113ddb7b@syzkaller.appspotmail.com \ --cc=syzkaller-bugs@googlegroups.com \ --cc=viro@zeniv.linux.org.uk \ --cc=wad@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.