On Tue, Sep 08, 2020 at 12:50:44PM -0400, Qian Cai wrote:
> > No, you're talking nonsense. We must not free @mm when
> > 'current->active_mm == mm', never.
>
> Yes, you are right. It still trigger this below on powerpc with today's
> linux-next by fuzzing for a while (saw a few times on recent
On Wed, Jul 22, 2020 at 03:44:06PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 22, 2020 at 09:19:00AM -0400, Qian Cai wrote:
> > On Wed, Jul 22, 2020 at 12:06:37PM +0200, pet...@infradead.org wrote:
> > > On Thu, Jun 04, 2020 at 11:03:44AM -0400, Qian Cai wrote:
> > > > The linux-next commit
On Wed, Jul 22, 2020 at 09:19:00AM -0400, Qian Cai wrote:
> On Wed, Jul 22, 2020 at 12:06:37PM +0200, pet...@infradead.org wrote:
> > On Thu, Jun 04, 2020 at 11:03:44AM -0400, Qian Cai wrote:
> > > The linux-next commit bf2c59fce407 ("sched/core: Fix illegal RCU from
> > > offline CPUs") delayed,
On Wed, Jul 22, 2020 at 12:06:37PM +0200, pet...@infradead.org wrote:
> On Thu, Jun 04, 2020 at 11:03:44AM -0400, Qian Cai wrote:
> > The linux-next commit bf2c59fce407 ("sched/core: Fix illegal RCU from
> > offline CPUs") delayed,
> >
> > idle->active_mm = _mm;
> >
> > into finish_cpu() instead
On Thu, Jun 04, 2020 at 11:03:44AM -0400, Qian Cai wrote:
> The linux-next commit bf2c59fce407 ("sched/core: Fix illegal RCU from
> offline CPUs") delayed,
>
> idle->active_mm = _mm;
>
> into finish_cpu() instead of idle_task_exit() which results in a false
> positive warning that was originally
On Thu, Jun 04, 2020 at 11:03:44AM -0400, Qian Cai wrote:
> The linux-next commit bf2c59fce407 ("sched/core: Fix illegal RCU from
> offline CPUs") delayed,
>
> idle->active_mm = _mm;
>
> into finish_cpu() instead of idle_task_exit() which results in a false
> positive warning that was originally
The linux-next commit bf2c59fce407 ("sched/core: Fix illegal RCU from
offline CPUs") delayed,
idle->active_mm = _mm;
into finish_cpu() instead of idle_task_exit() which results in a false
positive warning that was originally designed in the commit 3eda69c92d47
("kernel/fork.c: detect early free
On Wed, Jul 31, 2019 at 04:49:32PM +0800, Jason Wang wrote:
> Yes, looking at the synchronization implemented by other MMU notifiers.
> Vhost is even the simplest.
I think that is only because it calls gup under a spinlock, which is,
IMHO, not great.
Jason
On 2019/7/30 下午11:08, Michael S. Tsirkin wrote:
On Tue, Jul 30, 2019 at 03:44:47PM +0800, Jason Wang wrote:
On 2019/7/29 下午10:44, Michael S. Tsirkin wrote:
On Mon, Jul 29, 2019 at 10:24:43PM +0800, Jason Wang wrote:
On 2019/7/29 下午4:59, Michael S. Tsirkin wrote:
On Mon, Jul 29, 2019 at
On Tue, Jul 30, 2019 at 03:44:47PM +0800, Jason Wang wrote:
>
> On 2019/7/29 下午10:44, Michael S. Tsirkin wrote:
> > On Mon, Jul 29, 2019 at 10:24:43PM +0800, Jason Wang wrote:
> > > On 2019/7/29 下午4:59, Michael S. Tsirkin wrote:
> > > > On Mon, Jul 29, 2019 at 01:54:49PM +0800, Jason Wang wrote:
On 2019/7/30 下午3:44, Jason Wang wrote:
}
Looks good but I'd like to think of a strategy/existing lock that let us
block properly as opposed to spinning, that would be more friendly to
e.g. the realtime patch.
Does it make sense to disable preemption in the critical section? Then
we don't
On 2019/7/29 下午10:44, Michael S. Tsirkin wrote:
On Mon, Jul 29, 2019 at 10:24:43PM +0800, Jason Wang wrote:
On 2019/7/29 下午4:59, Michael S. Tsirkin wrote:
On Mon, Jul 29, 2019 at 01:54:49PM +0800, Jason Wang wrote:
On 2019/7/26 下午9:49, Michael S. Tsirkin wrote:
Ok, let me retry if
On Mon, Jul 29, 2019 at 10:24:43PM +0800, Jason Wang wrote:
>
> On 2019/7/29 下午4:59, Michael S. Tsirkin wrote:
> > On Mon, Jul 29, 2019 at 01:54:49PM +0800, Jason Wang wrote:
> > > On 2019/7/26 下午9:49, Michael S. Tsirkin wrote:
> > > > > > Ok, let me retry if necessary (but I do remember I end up
On 2019/7/29 下午4:59, Michael S. Tsirkin wrote:
On Mon, Jul 29, 2019 at 01:54:49PM +0800, Jason Wang wrote:
On 2019/7/26 下午9:49, Michael S. Tsirkin wrote:
Ok, let me retry if necessary (but I do remember I end up with deadlocks
last try).
Ok, I play a little with this. And it works so far.
On Mon, Jul 29, 2019 at 01:54:49PM +0800, Jason Wang wrote:
>
> On 2019/7/26 下午9:49, Michael S. Tsirkin wrote:
> > > > Ok, let me retry if necessary (but I do remember I end up with deadlocks
> > > > last try).
> > > Ok, I play a little with this. And it works so far. Will do more testing
> > >
On 2019/7/26 下午11:03, Jason Gunthorpe wrote:
On Fri, Jul 26, 2019 at 10:00:20PM +0800, Jason Wang wrote:
The question is, MMU notifier are allowed to be blocked on
invalidate_range_start() which could be much slower than synchronize_rcu()
to finish.
Looking at
On 2019/7/26 下午9:49, Michael S. Tsirkin wrote:
Ok, let me retry if necessary (but I do remember I end up with deadlocks
last try).
Ok, I play a little with this. And it works so far. Will do more testing
tomorrow.
One reason could be I switch to use get_user_pages_fast() to
On Fri, Jul 26, 2019 at 10:00:20PM +0800, Jason Wang wrote:
> The question is, MMU notifier are allowed to be blocked on
> invalidate_range_start() which could be much slower than synchronize_rcu()
> to finish.
>
> Looking at amdgpu_mn_invalidate_range_start_gfx() which calls
>
On Fri, Jul 26, 2019 at 10:00:20PM +0800, Jason Wang wrote:
>
> On 2019/7/26 下午9:47, Michael S. Tsirkin wrote:
> > On Fri, Jul 26, 2019 at 08:53:18PM +0800, Jason Wang wrote:
> > > On 2019/7/26 下午8:38, Michael S. Tsirkin wrote:
> > > > On Fri, Jul 26, 2019 at 08:00:58PM +0800, Jason Wang wrote:
>
On 2019/7/26 下午9:47, Michael S. Tsirkin wrote:
On Fri, Jul 26, 2019 at 08:53:18PM +0800, Jason Wang wrote:
On 2019/7/26 下午8:38, Michael S. Tsirkin wrote:
On Fri, Jul 26, 2019 at 08:00:58PM +0800, Jason Wang wrote:
On 2019/7/26 下午7:49, Michael S. Tsirkin wrote:
On Thu, Jul 25, 2019 at
On Fri, Jul 26, 2019 at 09:36:18PM +0800, Jason Wang wrote:
>
> On 2019/7/26 下午8:53, Jason Wang wrote:
> >
> > On 2019/7/26 下午8:38, Michael S. Tsirkin wrote:
> > > On Fri, Jul 26, 2019 at 08:00:58PM +0800, Jason Wang wrote:
> > > > On 2019/7/26 下午7:49, Michael S. Tsirkin wrote:
> > > > > On Thu,
On Fri, Jul 26, 2019 at 08:53:18PM +0800, Jason Wang wrote:
>
> On 2019/7/26 下午8:38, Michael S. Tsirkin wrote:
> > On Fri, Jul 26, 2019 at 08:00:58PM +0800, Jason Wang wrote:
> > > On 2019/7/26 下午7:49, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 25, 2019 at 10:25:25PM +0800, Jason Wang wrote:
>
On 2019/7/26 下午8:53, Jason Wang wrote:
On 2019/7/26 下午8:38, Michael S. Tsirkin wrote:
On Fri, Jul 26, 2019 at 08:00:58PM +0800, Jason Wang wrote:
On 2019/7/26 下午7:49, Michael S. Tsirkin wrote:
On Thu, Jul 25, 2019 at 10:25:25PM +0800, Jason Wang wrote:
On 2019/7/25 下午9:26, Michael S.
On 2019/7/26 下午8:38, Michael S. Tsirkin wrote:
On Fri, Jul 26, 2019 at 08:00:58PM +0800, Jason Wang wrote:
On 2019/7/26 下午7:49, Michael S. Tsirkin wrote:
On Thu, Jul 25, 2019 at 10:25:25PM +0800, Jason Wang wrote:
On 2019/7/25 下午9:26, Michael S. Tsirkin wrote:
Exactly, and that's the
On Fri, Jul 26, 2019 at 08:00:58PM +0800, Jason Wang wrote:
>
> On 2019/7/26 下午7:49, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2019 at 10:25:25PM +0800, Jason Wang wrote:
> > > On 2019/7/25 下午9:26, Michael S. Tsirkin wrote:
> > > > > Exactly, and that's the reason actually I use
On 2019/7/26 下午7:49, Michael S. Tsirkin wrote:
On Thu, Jul 25, 2019 at 10:25:25PM +0800, Jason Wang wrote:
On 2019/7/25 下午9:26, Michael S. Tsirkin wrote:
Exactly, and that's the reason actually I use synchronize_rcu() there.
So the concern is still the possible synchronize_expedited()?
I
On Thu, Jul 25, 2019 at 10:25:25PM +0800, Jason Wang wrote:
>
> On 2019/7/25 下午9:26, Michael S. Tsirkin wrote:
> > > Exactly, and that's the reason actually I use synchronize_rcu() there.
> > >
> > > So the concern is still the possible synchronize_expedited()?
> > I think
On 2019/7/25 下午9:26, Michael S. Tsirkin wrote:
Exactly, and that's the reason actually I use synchronize_rcu() there.
So the concern is still the possible synchronize_expedited()?
I think synchronize_srcu_expedited.
synchronize_expedited sends lots of IPI and is bad for realtime VMs.
Can
On Thu, Jul 25, 2019 at 09:21:22PM +0800, Jason Wang wrote:
>
> On 2019/7/25 下午4:28, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2019 at 03:43:41PM +0800, Jason Wang wrote:
> > > On 2019/7/25 下午1:52, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 23, 2019 at 09:31:35PM +0800, Jason Wang wrote:
>
On 2019/7/25 下午4:28, Michael S. Tsirkin wrote:
On Thu, Jul 25, 2019 at 03:43:41PM +0800, Jason Wang wrote:
On 2019/7/25 下午1:52, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 09:31:35PM +0800, Jason Wang wrote:
On 2019/7/23 下午5:26, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at
On Thu, Jul 25, 2019 at 03:43:41PM +0800, Jason Wang wrote:
>
> On 2019/7/25 下午1:52, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 09:31:35PM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午5:26, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 23, 2019 at 04:49:01PM +0800, Jason Wang wrote:
>
On 2019/7/25 下午2:02, Michael S. Tsirkin wrote:
On Mon, Jul 22, 2019 at 11:11:52AM -0300, Jason Gunthorpe 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
On 2019/7/25 下午1:52, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 09:31:35PM +0800, Jason Wang wrote:
On 2019/7/23 下午5:26, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 04:49:01PM +0800, Jason Wang wrote:
On 2019/7/23 下午4:10, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at
On Mon, Jul 22, 2019 at 11:11:52AM -0300, Jason Gunthorpe 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
> >
On Tue, Jul 23, 2019 at 09:31:35PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午5:26, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 04:49:01PM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午4:10, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 23, 2019 at 03:53:06PM +0800, Jason Wang wrote:
>
On Thu, Jul 25, 2019 at 11:44:27AM +0800, Jason Wang wrote:
>
> On 2019/7/25 上午2:25, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 06:08:05PM +0800, Jason Wang wrote:
> > > On 2019/7/24 下午4:05, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 24, 2019 at 10:17:14AM +0800, Jason Wang wrote:
>
On 2019/7/25 上午2:25, Michael S. Tsirkin wrote:
On Wed, Jul 24, 2019 at 06:08:05PM +0800, Jason Wang wrote:
On 2019/7/24 下午4:05, Michael S. Tsirkin wrote:
On Wed, Jul 24, 2019 at 10:17:14AM +0800, Jason Wang wrote:
On 2019/7/23 下午11:02, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at
On Wed, Jul 24, 2019 at 06:08:05PM +0800, Jason Wang wrote:
>
> On 2019/7/24 下午4:05, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 10:17:14AM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午11:02, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 23, 2019 at 09:34:29PM +0800, Jason Wang wrote:
On Wed, Jul 24, 2019 at 01:53:17PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 24, 2019 at 04:05:17AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 10:17:14AM +0800, Jason Wang wrote:
> > > So even PTE is read speculatively before reading invalidate_count (only in
> > > the case of
On Wed, Jul 24, 2019 at 04:05:17AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 10:17:14AM +0800, Jason Wang wrote:
> > So even PTE is read speculatively before reading invalidate_count (only in
> > the case of invalidate_count is zero). The spinlock has guaranteed that we
> > won't
On 2019/7/24 下午4:05, Michael S. Tsirkin wrote:
On Wed, Jul 24, 2019 at 10:17:14AM +0800, Jason Wang wrote:
On 2019/7/23 下午11:02, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 09:34:29PM +0800, Jason Wang wrote:
On 2019/7/23 下午6:27, Michael S. Tsirkin wrote:
Yes, since there could be
On Wed, Jul 24, 2019 at 10:17:14AM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午11:02, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 09:34:29PM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午6:27, Michael S. Tsirkin wrote:
> > > > > Yes, since there could be multiple co-current invalidation
On 2019/7/23 下午11:02, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 09:34:29PM +0800, Jason Wang wrote:
On 2019/7/23 下午6:27, Michael S. Tsirkin wrote:
Yes, since there could be multiple co-current invalidation requests. We need
count them to make sure we don't pin wrong pages.
I also
On Tue, Jul 23, 2019 at 09:34:29PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午6:27, Michael S. Tsirkin wrote:
> > > Yes, since there could be multiple co-current invalidation requests. We
> > > need
> > > count them to make sure we don't pin wrong pages.
> > >
> > >
> > > > I also wonder
On 2019/7/23 下午6:42, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 04:42:19PM +0800, Jason Wang wrote:
So how about this: do exactly what you propose but as a 2 patch series:
start with the slow safe patch, and add then return uaddr optimizations
on top. We can then more easily reason
On 2019/7/23 下午6:27, Michael S. Tsirkin wrote:
Yes, since there could be multiple co-current invalidation requests. We need
count them to make sure we don't pin wrong pages.
I also wonder about ordering. kvm has this:
/*
* Used to check for invalidations in progress, of
On 2019/7/23 下午5:26, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 04:49:01PM +0800, Jason Wang wrote:
On 2019/7/23 下午4:10, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 03:53:06PM +0800, Jason Wang wrote:
On 2019/7/23 下午3:23, Michael S. Tsirkin wrote:
Really let's just use
On Tue, Jul 23, 2019 at 04:42:19PM +0800, Jason Wang wrote:
> > So how about this: do exactly what you propose but as a 2 patch series:
> > start with the slow safe patch, and add then return uaddr optimizations
> > on top. We can then more easily reason about whether they are safe.
>
>
> If you
On Tue, Jul 23, 2019 at 04:42:19PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午3:56, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 01:48:52PM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午1:02, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 23, 2019 at 11:55:28AM +0800, Jason Wang wrote:
>
On Tue, Jul 23, 2019 at 04:49:01PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午4:10, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 03:53:06PM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午3:23, Michael S. Tsirkin wrote:
> > > > > > Really let's just use kfree_rcu. It's way cleaner: fire
On 2019/7/23 下午4:10, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 03:53:06PM +0800, Jason Wang wrote:
On 2019/7/23 下午3:23, Michael S. Tsirkin wrote:
Really let's just use kfree_rcu. It's way cleaner: fire and forget.
Looks not, you need rate limit the fire as you've figured out?
See
On 2019/7/23 下午3:56, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 01:48:52PM +0800, Jason Wang wrote:
On 2019/7/23 下午1:02, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 11:55:28AM +0800, Jason Wang wrote:
On 2019/7/22 下午4:02, Michael S. Tsirkin wrote:
On Mon, Jul 22, 2019 at
On Tue, Jul 23, 2019 at 03:53:06PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午3:23, Michael S. Tsirkin wrote:
> > > > Really let's just use kfree_rcu. It's way cleaner: fire and forget.
> > > Looks not, you need rate limit the fire as you've figured out?
> > See the discussion that followed.
On Tue, Jul 23, 2019 at 01:48:52PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午1:02, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 11:55:28AM +0800, Jason Wang wrote:
> > > On 2019/7/22 下午4:02, Michael S. Tsirkin wrote:
> > > > On Mon, Jul 22, 2019 at 01:21:59PM +0800, Jason Wang wrote:
>
On 2019/7/23 下午3:25, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 01:48:52PM +0800, Jason Wang wrote:
On 2019/7/23 下午1:02, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 11:55:28AM +0800, Jason Wang wrote:
On 2019/7/22 下午4:02, Michael S. Tsirkin wrote:
On Mon, Jul 22, 2019 at
On 2019/7/23 下午3:23, Michael S. Tsirkin wrote:
Really let's just use kfree_rcu. It's way cleaner: fire and forget.
Looks not, you need rate limit the fire as you've figured out?
See the discussion that followed. Basically no, it's good enough
already and is only going to be better.
And in
On Tue, Jul 23, 2019 at 01:48:52PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午1:02, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 11:55:28AM +0800, Jason Wang wrote:
> > > On 2019/7/22 下午4:02, Michael S. Tsirkin wrote:
> > > > On Mon, Jul 22, 2019 at 01:21:59PM +0800, Jason Wang wrote:
>
On Tue, Jul 23, 2019 at 01:47:04PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午1:01, Michael S. Tsirkin wrote:
> > 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/23 下午1:02, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 11:55:28AM +0800, Jason Wang wrote:
On 2019/7/22 下午4:02, Michael S. Tsirkin wrote:
On Mon, Jul 22, 2019 at 01:21:59PM +0800, Jason Wang wrote:
On 2019/7/21 下午6:02, Michael S. Tsirkin wrote:
On Sat, Jul 20, 2019 at
On 2019/7/23 下午1:01, Michael S. Tsirkin wrote:
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
On Tue, Jul 23, 2019 at 11:55:28AM +0800, Jason Wang wrote:
>
> On 2019/7/22 下午4:02, Michael S. Tsirkin wrote:
> > On Mon, Jul 22, 2019 at 01:21:59PM +0800, Jason Wang wrote:
> > > On 2019/7/21 下午6:02, Michael S. Tsirkin wrote:
> > > > On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote:
> > >
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
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
On 2019/7/22 下午4:02, Michael S. Tsirkin wrote:
On Mon, Jul 22, 2019 at 01:21:59PM +0800, Jason Wang wrote:
On 2019/7/21 下午6:02, Michael S. Tsirkin wrote:
On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote:
syzbot has bisected this bug to:
commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
On Mon, Jul 22, 2019 at 12:32:17PM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 22, 2019 at 09:25:51AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 22, 2019 at 12:13:40PM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> > > > On Mon,
On Mon, Jul 22, 2019 at 09:25:51AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 22, 2019 at 12:13:40PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > > > On Mon,
On Mon, Jul 22, 2019 at 12:13:40PM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > > > [snip]
> > >
On Mon, Jul 22, 2019 at 01:04:48PM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> > So why then is there a problem?
>
> I'm not sure there is a real problem, I thought Michael was just
> asking how to design with RCU in the case where the user
On Mon, Jul 22, 2019 at 01:04:48PM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> > So why then is there a problem?
>
> I'm not sure there is a real problem, I thought Michael was just
> asking how to design with RCU in the case where the user
On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > > [snip]
> > > > > Would it make sense to have call_rcu() check to see if there are many
>
On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> So why then is there a problem?
I'm not sure there is a real problem, I thought Michael was just
asking how to design with RCU in the case where the user controls the
kfree_rcu??
Sounds like the answer is "don't worry about it"
On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > [snip]
> > > > Would it make sense to have call_rcu() check to see if there are many
> > > > outstanding requests on this CPU and if so process them before
> >
On Mon, Jul 22, 2019 at 10:41:52AM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 04:51:49AM -0700, Paul E. McKenney wrote:
>
> > > > > Would it make sense to have call_rcu() check to see if there are many
> > > > > outstanding requests on this CPU and if so process them before
> > > >
On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> [snip]
> > > Would it make sense to have call_rcu() check to see if there are many
> > > outstanding requests on this CPU and if so process them before returning?
> > > That would ensure that frequent callers usually ended up doing
[snip]
> > Would it make sense to have call_rcu() check to see if there are many
> > outstanding requests on this CPU and if so process them before returning?
> > That would ensure that frequent callers usually ended up doing their
> > own processing.
Other than what Paul already mentioned about
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
> > Date: Fri May 24 08:12:18 2019 +
> >
> >
On Mon, Jul 22, 2019 at 04:51:49AM -0700, Paul E. McKenney wrote:
> > > > Would it make sense to have call_rcu() check to see if there are many
> > > > outstanding requests on this CPU and if so process them before
> > > > returning?
> > > > That would ensure that frequent callers usually ended
On Mon, Jul 22, 2019 at 03:56:22AM -0400, Michael S. Tsirkin wrote:
> On Sun, Jul 21, 2019 at 12:28:41PM -0700, Paul E. McKenney wrote:
> > On Sun, Jul 21, 2019 at 01:53:23PM -0400, Michael S. Tsirkin wrote:
> > > On Sun, Jul 21, 2019 at 06:17:25AM -0700, Paul E. McKenney wrote:
> > > > On Sun,
On Mon, Jul 22, 2019 at 03:52:05AM -0400, Michael S. Tsirkin wrote:
> On Sun, Jul 21, 2019 at 04:31:13PM -0700, Paul E. McKenney wrote:
> > On Sun, Jul 21, 2019 at 02:08:37PM -0700, Matthew Wilcox wrote:
> > > On Sun, Jul 21, 2019 at 06:17:25AM -0700, Paul E. McKenney wrote:
> > > > Also, the
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:
> > > >
>
On Mon, Jul 22, 2019 at 01:21:59PM +0800, Jason Wang wrote:
>
> On 2019/7/21 下午6:02, 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
On Sun, Jul 21, 2019 at 12:28:41PM -0700, Paul E. McKenney wrote:
> On Sun, Jul 21, 2019 at 01:53:23PM -0400, Michael S. Tsirkin wrote:
> > On Sun, Jul 21, 2019 at 06:17:25AM -0700, Paul E. McKenney wrote:
> > > On Sun, Jul 21, 2019 at 08:28:05AM -0400, Michael S. Tsirkin wrote:
> > > > Hi Paul,
On Sun, Jul 21, 2019 at 04:31:13PM -0700, Paul E. McKenney wrote:
> On Sun, Jul 21, 2019 at 02:08:37PM -0700, Matthew Wilcox wrote:
> > On Sun, Jul 21, 2019 at 06:17:25AM -0700, Paul E. McKenney wrote:
> > > Also, the overhead is important. For example, as far as I know,
> > > current RCU
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
Date: Fri May 24
On 2019/7/21 下午6:02, 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
Date: Fri May 24 08:12:18 2019 +
vhost: access vq metadata through kernel
On Sun, Jul 21, 2019 at 02:08:37PM -0700, Matthew Wilcox wrote:
> On Sun, Jul 21, 2019 at 06:17:25AM -0700, Paul E. McKenney wrote:
> > Also, the overhead is important. For example, as far as I know,
> > current RCU gracefully handles close(open(...)) in a tight userspace
> > loop. But there
On Sun, Jul 21, 2019 at 06:17:25AM -0700, Paul E. McKenney wrote:
> Also, the overhead is important. For example, as far as I know,
> current RCU gracefully handles close(open(...)) in a tight userspace
> loop. But there might be trouble due to tight userspace loops around
> lighter-weight
On Sun, Jul 21, 2019 at 01:53:23PM -0400, Michael S. Tsirkin wrote:
> On Sun, Jul 21, 2019 at 06:17:25AM -0700, Paul E. McKenney wrote:
> > On Sun, Jul 21, 2019 at 08:28:05AM -0400, Michael S. Tsirkin wrote:
> > > Hi Paul, others,
> > >
> > > So it seems that vhost needs to call kfree_rcu from an
On Sun, Jul 21, 2019 at 06:17:25AM -0700, Paul E. McKenney wrote:
> On Sun, Jul 21, 2019 at 08:28:05AM -0400, Michael S. Tsirkin wrote:
> > Hi Paul, others,
> >
> > So it seems that vhost needs to call kfree_rcu from an ioctl. My worry
> > is what happens if userspace starts cycling through lots
On Sun, Jul 21, 2019 at 08:28:05AM -0400, Michael S. Tsirkin wrote:
> Hi Paul, others,
>
> So it seems that vhost needs to call kfree_rcu from an ioctl. My worry
> is what happens if userspace starts cycling through lots of these
> ioctls. Given we actually use rcu as an optimization, we could
Hi Paul, others,
So it seems that vhost needs to call kfree_rcu from an ioctl. My worry
is what happens if userspace starts cycling through lots of these
ioctls. Given we actually use rcu as an optimization, we could just
disable the optimization temporarily - but the question would be how to
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
> > Date: Fri May 24 08:12:18 2019 +
> >
> >
On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
> Author: Jason Wang
> Date: Fri May 24 08:12:18 2019 +
>
> vhost: access vq metadata through kernel virtual address
>
> bisection log:
syzbot has bisected this bug to:
commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
Author: Jason Wang
Date: Fri May 24 08:12:18 2019 +
vhost: access vq metadata through kernel virtual address
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=149a8a2060
start commit:
Hello,
syzbot found the following crash on:
HEAD commit:6d21a41b Add linux-next specific files for 20190718
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=134920f060
kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
95 matches
Mail list logo
