Bugfixes.
I need to pull actual changesets for the drivers, etc properly and
verify that they build so those will be coming next week. You will be
getting them one by one.
1. Memory corruption.
The reverse case of this race (you need to msync, before you do non-mmap
fileops) is well known and textbook. This is the first and only time I
have seen this one (fsync before mmap). I have not heard it mentioned
either. It is however fairly easy to reproduce. If you run 200+ UML on a
system ~0.2-0.5% will always die at startup with a memory corruption
warning. While this does not happen every time (0.2-0.5% and only on
startup) it is very reproducible for systems running lots of UMLs.
Once this fix went in we stopped seeing that one. Observed on 3.2, 3.3
and 3.8, fix tested on 3.2, 3.3, 3.4 and 3.8.
2. SIGPIPE.
Linux actually produces SIGPIPE ane EPIPE not only on missing reader. It
will produce it under some circumstances on a stalled reader. Discovered
when running UML under expect and/or trying to use fds and other virtual
serials to do management transactions.
While I have not seen it on UML internal pipes I would not be surprised
if you can reproduce it there too (f.e. if ubd thread is too slow). So
SIGPIPE needs to be disabled. From there on, for most drivers have
correct error handling for this.
Observed on 3.2, 3.3 and 3.8, fix tested on 3.2, 3.3, 3.4 and 3.8.
A.
On 28/02/14 08:33, Richard Weinberger wrote:
> Am 28.02.2014 09:27, schrieb Anton Ivanov (antivano):
>> Hi Richard, Hi Jeff, hi list,
>>
>> On behalf of Cisco systems, I am authorized to make a offer a set bug
>> fixes as well as contribute several additional features and performance
>> improvements to UML. All of these have been used internally for a couple
>> of years and will ship as parts of product(s) in the near future. Some
>> of these improve performance by up to 8 times on use cases which are of
>> interest to us and are likely to be of interest to the community.
>>
>> As the full patchset is now in the 100k+ zone, so I am going to do only
>> the announcement now and submit the patches one by one after that over
>> the next 1-2 weeks.
>>
>> We will submit separately bug fixes for:
>>
>> 1. Critical memory corruption on startup observed on heavily loaded
>> machines (especially when multiple UMLs run simultaneously).
>> 2. Fix(es) for incorrect handling of error conditions when UML is run
>> under expect and conX=fd: is used to communicate with another process.
>> The same error may be observed on internal UML IPCs too leading to
>> immediate crash.
>>
>> I will also file bugs for both vs Debian UML package so that patches for
>> both can go in ASAP.
>>
>> In addition to the bug fixes, the new features include:
>>
>> 1. Several transports. All can do up to multi-gigabit throughput on some
>> scenarios. We are contributing their counterparts to qemu/kvm as well.
>>
>> 1.1. Direct connection of UML to overlay networks/L2 VPNs using L2TPv3.
>>
>> This has a number of advantages compared to the existing UML "multicast"
>> and qemu "socket" transports.
>>
>> * Standard compliant - RFC 3931 updated recently by RFC 5641
>> * Supported on most network equipment
>> * Allowing to move virtual switching off-host to an NPU or high
>> performance physical switch
>> * Allowing to mix virtual and physical switching (well supported on
>> modern Linuxes and other OSes)
>> * Well researched security profile as well as established
>> interactions with IPSEC allowing to extend virtual networks outside the
>> datacenter to remote physical devices and/or VMs.
>>
>> 1.2. Raw transport which allows both bi-directional communication with
>> any network device which looks like Ethernet as well as in-span
>> listening at speeds in the multi-gigabit range.
>>
>> 1.3. We intend to contribute other key overlay transports like GRE, etc
>> as well. The ones we are contributing at this point are the ones which
>> we have used most extensively and have had the most testing (~ 1.5-2 years).
>>
>> 2. New high res timer subsystem
>>
>> Adding these new network transports to UML revealed a key issue - it
>> cannot meter or shape any traffic correctly as its internal timer system
>> is way off. Personally, I consider it a bug, however there is no "easy"
>> fix here. The only way to fix it is a new timer driver. Unfortunately,
>> it does not fix uml userspace - timers there remain off. It does fix all
>> kernel timer functionality - traffic shaping (both qdisc and iptables
>> traffic limits).
>>
>> As a side effect, this provides performance improvements for tcp and
>> other protocols which rely on kernel high res timers for their state
>> machines.
>>
>> We have further scalability contributions lined up which improve network
>> and IO performance between 1.5 and 8 times (depending on use case),
>> allow hundreds of virtual interfaces per UML without performance
>> penalties, allow to run several hundreds (if not thousands) of UMLs per
>> machine, etc. All in all, it can no go where no virtualization and no
>> virtual networking has gone before.
>>
>> However, I would prefer to take it one step at a time and get through
>> these first (even these are quite a lot for one "sitting").
> Sounds awesome!
>
> Please send the patches as soon as possible.
> I'm eager to test and merge them.
>
> Thanks,
> //richard
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);
/*
diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index b314cf7..e984b2c 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -144,6 +144,7 @@ extern int os_write_file(int fd, const void *buf, int count);
extern int os_file_size(const char *file, unsigned long long *size_out);
extern int os_file_modtime(const char *file, unsigned long *modtime);
extern int os_pipe(int *fd, int stream, int close_on_exec);
+extern int os_fsync(int fd);
extern int os_set_fd_async(int fd);
extern int os_clear_fd_async(int fd);
extern int os_set_fd_block(int fd, int blocking);
diff --git a/arch/um/kernel/physmem.c b/arch/um/kernel/physmem.c
index f116db1..ea606ee 100644
--- a/arch/um/kernel/physmem.c
+++ b/arch/um/kernel/physmem.c
@@ -87,6 +87,14 @@ void __init setup_physmem(unsigned long start, unsigned long reserve_end,
physmem_fd = create_mem_file(len + highmem);
+ /*
+ * Special kludge - This page will be mapped in to userspace processes
+ * from physmem_fd, so it needs to be written out there.
+ */
+ os_seek_file(physmem_fd, __pa(&__syscall_stub_start));
+ os_write_file(physmem_fd, &__syscall_stub_start, PAGE_SIZE);
+ os_fsync(physmem_fd);
+
offset = uml_reserved - uml_physmem;
err = os_map_memory((void *) uml_reserved, physmem_fd, offset,
len - offset, 1, 1, 1);
@@ -97,12 +105,6 @@ void __init setup_physmem(unsigned long start, unsigned long reserve_end,
exit(1);
}
- /*
- * Special kludge - This page will be mapped in to userspace processes
- * from physmem_fd, so it needs to be written out there.
- */
- os_seek_file(physmem_fd, __pa(&__syscall_stub_start));
- os_write_file(physmem_fd, &__syscall_stub_start, PAGE_SIZE);
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..d4985be99 100644
--- a/arch/um/os-Linux/file.c
+++ b/arch/um/os-Linux/file.c
@@ -33,6 +33,10 @@ static void copy_stat(struct uml_stat *dst, const struct stat64 *src)
});
}
+int os_fsync(int fd) {
+ fsync(fd);
+}
+
int os_stat_fd(const int fd, struct uml_stat *ubuf)
{
struct stat64 sbuf;
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&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
