[uml-devel] [PATCH 1/3] BUG: Missing pipe handling

[uml-devel] [PATCH 1/3] BUG: Missing pipe handling

[anton.ivanov]

From: Anton Ivanov <antivano@cisco.com>

UML does not handle sigpipe. As a result when running it under
expect or redirecting the IO from the console to an external program
it will crash if the program stops or exits.

Signed-off-by: Anton Ivanov <antivano@cisco.com>
---
 arch/um/os-Linux/main.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/um/os-Linux/main.c b/arch/um/os-Linux/main.c
index 7a86dd5..048166d 100644
--- a/arch/um/os-Linux/main.c
+++ b/arch/um/os-Linux/main.c
@@ -149,6 +149,7 @@ int __init main(int argc, char **argv, char **envp)
 #endif
 
 	do_uml_initcalls();
+	change_sig(SIGPIPE, 0);
 	ret = linux_main(argc, argv);
 
 	/*
-- 
1.7.10.4


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH 2/3] BUG: Memory corruption on startup

[anton.ivanov]

From: Anton Ivanov <antivano@cisco.com>

The reverse case of this race (you must msync before read) is
well known. This is the not so common one.

It can be triggered only on systems which do a lot of task
switching and only at UML startup. If you are starting 200+ UMLs
~ 0.5% will always die without this fix.

Signed-off-by: Anton Ivanov <antivano@cisco.com>
---
 arch/um/include/shared/os.h |    1 +
 arch/um/kernel/physmem.c    |    1 +
 arch/um/os-Linux/file.c     |    6 ++++++
 3 files changed, 8 insertions(+)

diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index 89b686c1..3c9738d 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -136,6 +136,7 @@ extern int os_ioctl_generic(int fd, unsigned int cmd, unsigned long arg);
 extern int os_get_ifname(int fd, char *namebuf);
 extern int os_set_slip(int fd);
 extern int os_mode_fd(int fd, int mode);
+extern int os_fsync_file(int fd);
 
 extern int os_seek_file(int fd, unsigned long long offset);
 extern int os_open_file(const char *file, struct openflags flags, int mode);
diff --git a/arch/um/kernel/physmem.c b/arch/um/kernel/physmem.c
index f116db1..30fdd5d0 100644
--- a/arch/um/kernel/physmem.c
+++ b/arch/um/kernel/physmem.c
@@ -103,6 +103,7 @@ void __init setup_physmem(unsigned long start, unsigned long reserve_end,
 	 */
 	os_seek_file(physmem_fd, __pa(&__syscall_stub_start));
 	os_write_file(physmem_fd, &__syscall_stub_start, PAGE_SIZE);
+	os_fsync_file(physmem_fd);
 
 	bootmap_size = init_bootmem(pfn, pfn + delta);
 	free_bootmem(__pa(reserve_end) + bootmap_size,
diff --git a/arch/um/os-Linux/file.c b/arch/um/os-Linux/file.c
index b049a63..c879b12 100644
--- a/arch/um/os-Linux/file.c
+++ b/arch/um/os-Linux/file.c
@@ -237,6 +237,12 @@ void os_close_file(int fd)
 {
 	close(fd);
 }
+int os_fsync_file(int fd)
+{
+	if (fsync(fd) < 0) 
+	    return -errno
+	return 0;
+}
 
 int os_seek_file(int fd, unsigned long long offset)
 {
-- 
1.7.10.4


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH 3/3] BUG: Inapprorpiate choice of IPC

[anton.ivanov]

From: Anton Ivanov <antivano@cisco.com>

PIPE is the wrong IPC for this type of inter-thread communication.

For more details see:

http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k

The observations on that thread have been confirmed by us for UML's
UBD driver. If you load UML with network IO and do disk IO at the same
time the UBD IO helper thread fails to process requests fast enough.

In most cases this will lead to a slowdown in disk IO as well as
inability to execute new processes until the network load goes away.
In some cases however it will not recover. Example - with our new high
performance 1G+ network drivers a wget of 1G file from the network
is a nearly guaranteed crash if it writes out to UBD.

The crashes and the slowdowns are not observed with this patch -
it switches the IPC to socket which does not have the pipe granularity
and queue size problems.

This signifies a problem with overall UBD error handling which this
patch fails to fix. The workaround should be good enough for most
cases.

Signed-off-by: Anton Ivanov <antivano@cisco.com>
---
 arch/um/drivers/ubd_kern.c |    2 +-
 arch/um/drivers/ubd_user.c |    2 +-
 arch/um/os-Linux/file.c    |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index 944453a..c9a5717 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -1291,7 +1291,7 @@ static void do_ubd_request(struct request_queue *q)
 			n = os_write_file(thread_fd, &io_req,
 					  sizeof(struct io_thread_req *));
 			if(n != sizeof(struct io_thread_req *)){
-				if(n != -EAGAIN)
+				if(!((n == -EAGAIN) || (n == -ENOBUFS)))
 					printk("write to io thread failed, "
 					       "errno = %d\n", -n);
 				else if(list_empty(&dev->restart))
diff --git a/arch/um/drivers/ubd_user.c b/arch/um/drivers/ubd_user.c
index 007b94d..f1f84a4 100644
--- a/arch/um/drivers/ubd_user.c
+++ b/arch/um/drivers/ubd_user.c
@@ -32,7 +32,7 @@ int start_io_thread(unsigned long sp, int *fd_out)
 {
 	int pid, fds[2], err;
 
-	err = os_pipe(fds, 1, 1);
+	err = socketpair(AF_UNIX, SOCK_STREAM, 0, (int *) &fds);
 	if(err < 0){
 		printk("start_io_thread - os_pipe failed, err = %d\n", -err);
 		goto out;
diff --git a/arch/um/os-Linux/file.c b/arch/um/os-Linux/file.c
index c879b12..a4f0e65 100644
--- a/arch/um/os-Linux/file.c
+++ b/arch/um/os-Linux/file.c
@@ -240,7 +240,7 @@ void os_close_file(int fd)
 int os_fsync_file(int fd)
 {
 	if (fsync(fd) < 0) 
-	    return -errno
+	    return -errno;
 	return 0;
 }
 
-- 
1.7.10.4


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 3/3] BUG: Inapprorpiate choice of IPC

[Richard Weinberger]

Am 07.03.2014 19:37, schrieb anton.ivanov@kot-begemot.co.uk:
> From: Anton Ivanov <antivano@cisco.com>
> 
> PIPE is the wrong IPC for this type of inter-thread communication.
> 
> For more details see:
> 
> http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k
> 
> The observations on that thread have been confirmed by us for UML's
> UBD driver. If you load UML with network IO and do disk IO at the same
> time the UBD IO helper thread fails to process requests fast enough.
> 
> In most cases this will lead to a slowdown in disk IO as well as
> inability to execute new processes until the network load goes away.
> In some cases however it will not recover. Example - with our new high
> performance 1G+ network drivers a wget of 1G file from the network
> is a nearly guaranteed crash if it writes out to UBD.
> 
> The crashes and the slowdowns are not observed with this patch -
> it switches the IPC to socket which does not have the pipe granularity
> and queue size problems.
> 
> This signifies a problem with overall UBD error handling which this
> patch fails to fix. The workaround should be good enough for most
> cases.
> 
> Signed-off-by: Anton Ivanov <antivano@cisco.com>
> ---
>  arch/um/drivers/ubd_kern.c |    2 +-
>  arch/um/drivers/ubd_user.c |    2 +-
>  arch/um/os-Linux/file.c    |    2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
> index 944453a..c9a5717 100644
> --- a/arch/um/drivers/ubd_kern.c
> +++ b/arch/um/drivers/ubd_kern.c
> @@ -1291,7 +1291,7 @@ static void do_ubd_request(struct request_queue *q)
>  			n = os_write_file(thread_fd, &io_req,
>  					  sizeof(struct io_thread_req *));
>  			if(n != sizeof(struct io_thread_req *)){
> -				if(n != -EAGAIN)
> +				if(!((n == -EAGAIN) || (n == -ENOBUFS)))
>  					printk("write to io thread failed, "
>  					       "errno = %d\n", -n);
>  				else if(list_empty(&dev->restart))
> diff --git a/arch/um/drivers/ubd_user.c b/arch/um/drivers/ubd_user.c
> index 007b94d..f1f84a4 100644
> --- a/arch/um/drivers/ubd_user.c
> +++ b/arch/um/drivers/ubd_user.c
> @@ -32,7 +32,7 @@ int start_io_thread(unsigned long sp, int *fd_out)
>  {
>  	int pid, fds[2], err;
>  
> -	err = os_pipe(fds, 1, 1);
> +	err = socketpair(AF_UNIX, SOCK_STREAM, 0, (int *) &fds);
>  	if(err < 0){
>  		printk("start_io_thread - os_pipe failed, err = %d\n", -err);
>  		goto out;
> diff --git a/arch/um/os-Linux/file.c b/arch/um/os-Linux/file.c
> index c879b12..a4f0e65 100644
> --- a/arch/um/os-Linux/file.c
> +++ b/arch/um/os-Linux/file.c
> @@ -240,7 +240,7 @@ void os_close_file(int fd)
>  int os_fsync_file(int fd)
>  {
>  	if (fsync(fd) < 0) 
> -	    return -errno
> +	    return -errno;

Huh?
I think this does not belong to the patch.

The other drivers look good. Thanks a lot for pushing this work upstream!
We are already at -rc5. I'll send the patches to Linus within the next merge window
and mark them for stable.

Thanks,
//richard

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 3/3] BUG: Inapprorpiate choice of IPC

[Anton Ivanov]

Yes, that is why I resent it.

My mistake when moving the commits from the main tree to a branch which
was just for submission.

The file.c frag is from patch-2 (the memory corruption one).

Please use the resent version, it has them in the right places.
Alternatively, I can resend them again off-list.

A.

On 08/03/14 23:33, Richard Weinberger wrote:
>
> Am 07.03.2014 19:37, schrieb anton.ivanov@kot-begemot.co.uk:
>> From: Anton Ivanov <antivano@cisco.com>
>>
>> PIPE is the wrong IPC for this type of inter-thread communication.
>>
>> For more details see:
>>
>> http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k
>>
>> The observations on that thread have been confirmed by us for UML's
>> UBD driver. If you load UML with network IO and do disk IO at the same
>> time the UBD IO helper thread fails to process requests fast enough.
>>
>> In most cases this will lead to a slowdown in disk IO as well as
>> inability to execute new processes until the network load goes away.
>> In some cases however it will not recover. Example - with our new high
>> performance 1G+ network drivers a wget of 1G file from the network
>> is a nearly guaranteed crash if it writes out to UBD.
>>
>> The crashes and the slowdowns are not observed with this patch -
>> it switches the IPC to socket which does not have the pipe granularity
>> and queue size problems.
>>
>> This signifies a problem with overall UBD error handling which this
>> patch fails to fix. The workaround should be good enough for most
>> cases.
>>
>> Signed-off-by: Anton Ivanov <antivano@cisco.com>
>> ---
>>  arch/um/drivers/ubd_kern.c |    2 +-
>>  arch/um/drivers/ubd_user.c |    2 +-
>>  arch/um/os-Linux/file.c    |    2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
>> index 944453a..c9a5717 100644
>> --- a/arch/um/drivers/ubd_kern.c
>> +++ b/arch/um/drivers/ubd_kern.c
>> @@ -1291,7 +1291,7 @@ static void do_ubd_request(struct request_queue *q)
>>  			n = os_write_file(thread_fd, &io_req,
>>  					  sizeof(struct io_thread_req *));
>>  			if(n != sizeof(struct io_thread_req *)){
>> -				if(n != -EAGAIN)
>> +				if(!((n == -EAGAIN) || (n == -ENOBUFS)))
>>  					printk("write to io thread failed, "
>>  					       "errno = %d\n", -n);
>>  				else if(list_empty(&dev->restart))
>> diff --git a/arch/um/drivers/ubd_user.c b/arch/um/drivers/ubd_user.c
>> index 007b94d..f1f84a4 100644
>> --- a/arch/um/drivers/ubd_user.c
>> +++ b/arch/um/drivers/ubd_user.c
>> @@ -32,7 +32,7 @@ int start_io_thread(unsigned long sp, int *fd_out)
>>  {
>>  	int pid, fds[2], err;
>>  
>> -	err = os_pipe(fds, 1, 1);
>> +	err = socketpair(AF_UNIX, SOCK_STREAM, 0, (int *) &fds);
>>  	if(err < 0){
>>  		printk("start_io_thread - os_pipe failed, err = %d\n", -err);
>>  		goto out;
>> diff --git a/arch/um/os-Linux/file.c b/arch/um/os-Linux/file.c
>> index c879b12..a4f0e65 100644
>> --- a/arch/um/os-Linux/file.c
>> +++ b/arch/um/os-Linux/file.c
>> @@ -240,7 +240,7 @@ void os_close_file(int fd)
>>  int os_fsync_file(int fd)
>>  {
>>  	if (fsync(fd) < 0) 
>> -	    return -errno
>> +	    return -errno;
> Huh?
> I think this does not belong to the patch.
>
> The other drivers look good. Thanks a lot for pushing this work upstream!
> We are already at -rc5. I'll send the patches to Linus within the next merge window
> and mark them for stable.
>
> Thanks,
> //richard
>


-- 
"If you think it's expensive to hire a professional to do the job,
    wait until you hire an amateur."
				    Paul Neal "Red" Adair 

A. R. Ivanov
E-mail:  anton.ivanov@kot-begemot.co.uk


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 3/3] BUG: Inapprorpiate choice of IPC

[Richard Weinberger]

Am 07.03.2014 19:37, schrieb anton.ivanov@kot-begemot.co.uk:
> From: Anton Ivanov <antivano@cisco.com>
> 
> PIPE is the wrong IPC for this type of inter-thread communication.
> 
> For more details see:
> 
> http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k
> 
> The observations on that thread have been confirmed by us for UML's
> UBD driver. If you load UML with network IO and do disk IO at the same
> time the UBD IO helper thread fails to process requests fast enough.
> 
> In most cases this will lead to a slowdown in disk IO as well as
> inability to execute new processes until the network load goes away.
> In some cases however it will not recover. Example - with our new high
> performance 1G+ network drivers a wget of 1G file from the network
> is a nearly guaranteed crash if it writes out to UBD.
> 
> The crashes and the slowdowns are not observed with this patch -
> it switches the IPC to socket which does not have the pipe granularity
> and queue size problems.
> 
> This signifies a problem with overall UBD error handling which this
> patch fails to fix. The workaround should be good enough for most
> cases.
> 
> Signed-off-by: Anton Ivanov <antivano@cisco.com>
> ---
>  arch/um/drivers/ubd_kern.c |    2 +-
>  arch/um/drivers/ubd_user.c |    2 +-
>  arch/um/os-Linux/file.c    |    2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
> index 944453a..c9a5717 100644
> --- a/arch/um/drivers/ubd_kern.c
> +++ b/arch/um/drivers/ubd_kern.c
> @@ -1291,7 +1291,7 @@ static void do_ubd_request(struct request_queue *q)
>  			n = os_write_file(thread_fd, &io_req,
>  					  sizeof(struct io_thread_req *));
>  			if(n != sizeof(struct io_thread_req *)){
> -				if(n != -EAGAIN)
> +				if(!((n == -EAGAIN) || (n == -ENOBUFS)))
>  					printk("write to io thread failed, "
>  					       "errno = %d\n", -n);
>  				else if(list_empty(&dev->restart))
> diff --git a/arch/um/drivers/ubd_user.c b/arch/um/drivers/ubd_user.c
> index 007b94d..f1f84a4 100644
> --- a/arch/um/drivers/ubd_user.c
> +++ b/arch/um/drivers/ubd_user.c
> @@ -32,7 +32,7 @@ int start_io_thread(unsigned long sp, int *fd_out)
>  {
>  	int pid, fds[2], err;
>  
> -	err = os_pipe(fds, 1, 1);
> +	err = socketpair(AF_UNIX, SOCK_STREAM, 0, (int *) &fds);
>  	if(err < 0){
>  		printk("start_io_thread - os_pipe failed, err = %d\n", -err);
>  		goto out;
> diff --git a/arch/um/os-Linux/file.c b/arch/um/os-Linux/file.c
> index c879b12..a4f0e65 100644
> --- a/arch/um/os-Linux/file.c
> +++ b/arch/um/os-Linux/file.c
> @@ -240,7 +240,7 @@ void os_close_file(int fd)
>  int os_fsync_file(int fd)
>  {
>  	if (fsync(fd) < 0) 
> -	    return -errno
> +	    return -errno;
>  	return 0;
>  }

FYI, I did not send this patch to Linus because it does not apply.
Please fix this. :-)

Thanks,
//richard

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 3/3] BUG: Inapprorpiate choice of IPC

[Anton Ivanov (antivano)]

OK. Cool.

It was vs 3.3.8 (openwrt) so it may not apply cleanly vs 3.15. I will
fix it and resubmit it.

A.

On 20/04/14 22:28, Richard Weinberger wrote:
> Am 07.03.2014 19:37, schrieb anton.ivanov@kot-begemot.co.uk:
>> From: Anton Ivanov <antivano@cisco.com>
>>
>> PIPE is the wrong IPC for this type of inter-thread communication.
>>
>> For more details see:
>>
>> http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k
>>
>> The observations on that thread have been confirmed by us for UML's
>> UBD driver. If you load UML with network IO and do disk IO at the same
>> time the UBD IO helper thread fails to process requests fast enough.
>>
>> In most cases this will lead to a slowdown in disk IO as well as
>> inability to execute new processes until the network load goes away.
>> In some cases however it will not recover. Example - with our new high
>> performance 1G+ network drivers a wget of 1G file from the network
>> is a nearly guaranteed crash if it writes out to UBD.
>>
>> The crashes and the slowdowns are not observed with this patch -
>> it switches the IPC to socket which does not have the pipe granularity
>> and queue size problems.
>>
>> This signifies a problem with overall UBD error handling which this
>> patch fails to fix. The workaround should be good enough for most
>> cases.
>>
>> Signed-off-by: Anton Ivanov <antivano@cisco.com>
>> ---
>>  arch/um/drivers/ubd_kern.c |    2 +-
>>  arch/um/drivers/ubd_user.c |    2 +-
>>  arch/um/os-Linux/file.c    |    2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
>> index 944453a..c9a5717 100644
>> --- a/arch/um/drivers/ubd_kern.c
>> +++ b/arch/um/drivers/ubd_kern.c
>> @@ -1291,7 +1291,7 @@ static void do_ubd_request(struct request_queue *q)
>>  			n = os_write_file(thread_fd, &io_req,
>>  					  sizeof(struct io_thread_req *));
>>  			if(n != sizeof(struct io_thread_req *)){
>> -				if(n != -EAGAIN)
>> +				if(!((n == -EAGAIN) || (n == -ENOBUFS)))
>>  					printk("write to io thread failed, "
>>  					       "errno = %d\n", -n);
>>  				else if(list_empty(&dev->restart))
>> diff --git a/arch/um/drivers/ubd_user.c b/arch/um/drivers/ubd_user.c
>> index 007b94d..f1f84a4 100644
>> --- a/arch/um/drivers/ubd_user.c
>> +++ b/arch/um/drivers/ubd_user.c
>> @@ -32,7 +32,7 @@ int start_io_thread(unsigned long sp, int *fd_out)
>>  {
>>  	int pid, fds[2], err;
>>  
>> -	err = os_pipe(fds, 1, 1);
>> +	err = socketpair(AF_UNIX, SOCK_STREAM, 0, (int *) &fds);
>>  	if(err < 0){
>>  		printk("start_io_thread - os_pipe failed, err = %d\n", -err);
>>  		goto out;
>> diff --git a/arch/um/os-Linux/file.c b/arch/um/os-Linux/file.c
>> index c879b12..a4f0e65 100644
>> --- a/arch/um/os-Linux/file.c
>> +++ b/arch/um/os-Linux/file.c
>> @@ -240,7 +240,7 @@ void os_close_file(int fd)
>>  int os_fsync_file(int fd)
>>  {
>>  	if (fsync(fd) < 0) 
>> -	    return -errno
>> +	    return -errno;
>>  	return 0;
>>  }
> FYI, I did not send this patch to Linus because it does not apply.
> Please fix this. :-)
>
> Thanks,
> //richard

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel