05.08.2011 02:19, Jan Kiszka wrote:
[]
Resume on error in migrate_fd_put_buffer raced with migrate_fd_cleanup
triggered via migrate_fd_put_ready called from migrate_fd_connect.
This migration code is a horrible maze. Patch below tries to move
monitor_resume a bit out of this. Please check if
On 2011-08-05 08:51, Michael Tokarev wrote:
05.08.2011 02:19, Jan Kiszka wrote:
[]
Resume on error in migrate_fd_put_buffer raced with migrate_fd_cleanup
triggered via migrate_fd_put_ready called from migrate_fd_connect.
This migration code is a horrible maze. Patch below tries to move
On Wed, 3 Aug 2011 18:51:44 +0400
Michael Tokarev m...@tls.msk.ru wrote:
If we do, it results in double monitor_resume() (second being called
from migrate_fd_cleanup() anyway) and monitor suspend count becoming
negative.
Are you hitting an specific issue or did you find this by code
04.08.2011 23:24, Luiz Capitulino пишет:
On Wed, 3 Aug 2011 18:51:44 +0400
Michael Tokarev m...@tls.msk.ru wrote:
If we do, it results in double monitor_resume() (second being called
from migrate_fd_cleanup() anyway) and monitor suspend count becoming
negative.
Are you hitting an
04.08.2011 23:52, Michael Tokarev пишет:
04.08.2011 23:24, Luiz Capitulino пишет:
On Wed, 3 Aug 2011 18:51:44 +0400
Michael Tokarev m...@tls.msk.ru wrote:
If we do, it results in double monitor_resume() (second being called
from migrate_fd_cleanup() anyway) and monitor suspend count
On 2011-08-04 22:00, Michael Tokarev wrote:
04.08.2011 23:52, Michael Tokarev пишет:
04.08.2011 23:24, Luiz Capitulino пишет:
On Wed, 3 Aug 2011 18:51:44 +0400
Michael Tokarev m...@tls.msk.ru wrote:
If we do, it results in double monitor_resume() (second being called
from
So, can we decide on this somehow? I don't see a code
path where we don't call monitor_resume at the end,
so the intermediate monitor_resume can be dropped.
This way we fix real bug. If there will be other
problem from that, it can be fixed later - this will
mean that code path is found...
On 2011-08-03 09:38, Michael Tokarev wrote:
So, can we decide on this somehow? I don't see a code
path where we don't call monitor_resume at the end,
so the intermediate monitor_resume can be dropped.
This way we fix real bug. If there will be other
problem from that, it can be fixed later
If we do, it results in double monitor_resume() (second being called
from migrate_fd_cleanup() anyway) and monitor suspend count becoming
negative.
Signed-Off-By: Michael Tokarev m...@tls.msk.ru
Reviewed-By: Jan Kiszka jan.kis...@siemens.com
---
migration.c |3 ---
1 files changed, 0
On Tue, Jul 19, 2011 at 11:48:22PM +0200, Jan Kiszka wrote:
On 2011-07-19 13:46, Michael Tokarev wrote:
If we do, it results in double monitor_resume() (second being called
from migrate_fd_cleanup() anyway) and monitor suspend count becoming
negative.
Cc'ing people from `git blame'
On 2011-07-20 18:34, Marcelo Tosatti wrote:
On Tue, Jul 19, 2011 at 11:48:22PM +0200, Jan Kiszka wrote:
On 2011-07-19 13:46, Michael Tokarev wrote:
If we do, it results in double monitor_resume() (second being called
from migrate_fd_cleanup() anyway) and monitor suspend count becoming
If we do, it results in double monitor_resume() (second being called
from migrate_fd_cleanup() anyway) and monitor suspend count becoming
negative.
Cc'ing people from `git blame' list for the lines in question: the
change fixes the problem but I'm not sure what the original intention
of this code
On 2011-07-19 13:46, Michael Tokarev wrote:
If we do, it results in double monitor_resume() (second being called
from migrate_fd_cleanup() anyway) and monitor suspend count becoming
negative.
Cc'ing people from `git blame' list for the lines in question: the
change fixes the problem but I'm
13 matches
Mail list logo
