[libvirt] [PATCH] nwfilter: serialize execution of scripts with ebtables cmds

While testing the SIGHUP handling and reloading of the nwfilter driver, I found that when the filters are rebuilt and mutlipe threads handled the individual interfaces, concurrently running multiple external bash scripts causes strange failures even though the executed ebtables commands are working on different tables for different interfaces. I cannot say for sure where the concurrency problems are caused, but introducing this lock definitely helps. Signed-off-by: Stefan Berger <stefanb@us.ibm.com> --- src/nwfilter/nwfilter_ebiptables_driver.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) Index: libvirt-acl/src/nwfilter/nwfilter_ebiptables_driver.c =================================================================== --- libvirt-acl.orig/src/nwfilter/nwfilter_ebiptables_driver.c +++ libvirt-acl/src/nwfilter/nwfilter_ebiptables_driver.c @@ -104,6 +104,7 @@ static int ebiptablesDriverInit(void); static void ebiptablesDriverShutdown(void); static int ebtablesCleanAll(const char *ifname); +static virMutex execCLIMutex; struct ushort_map { unsigned short attr; @@ -2309,8 +2310,13 @@ ebiptablesExecCLI(virBufferPtr buf, return 1; argv[0] = filename; + + virMutexLock(&execCLIMutex); + rc = virRun(argv, status); + virMutexUnlock(&execCLIMutex); + *status >>= 8; VIR_DEBUG("rc = %d, status = %d",rc, *status); @@ -3163,8 +3169,9 @@ tear_down_tmpebchains: ebiptablesExecCLI(&buf, &cli_status); virNWFilterReportError(VIR_ERR_BUILD_FIREWALL, - "%s", - _("Some rules could not be created.")); + _("Some rules could not be created for " + "interface %s."), + ifname); return 1; } @@ -3364,6 +3371,9 @@ ebiptablesDriverInit(void) virBuffer buf = VIR_BUFFER_INITIALIZER; int cli_status; + if (virMutexInit(&execCLIMutex)) + return EINVAL; + bash_cmd_path = virFindFileInPath("bash"); gawk_cmd_path = virFindFileInPath("gawk"); grep_cmd_path = virFindFileInPath("grep");

On 08/13/2010 12:35 PM, Stefan Berger wrote:
While testing the SIGHUP handling and reloading of the nwfilter driver, I found that when the filters are rebuilt and mutlipe threads handled the individual interfaces, concurrently running multiple external bash scripts causes strange failures even though the executed ebtables commands are working on different tables for different interfaces. I cannot say for sure where the concurrency problems are caused, but introducing this lock definitely helps.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
ACK. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

libvir-list-bounces@redhat.com wrote on 08/13/2010 03:08:11 PM:
[image removed]
Re: [libvirt] [PATCH] nwfilter: serialize execution of scripts with ebtables cmds
Eric Blake
to:
Stefan Berger
08/13/2010 03:17 PM
Sent by:
libvir-list-bounces@redhat.com
Cc:
libvir-list
On 08/13/2010 12:35 PM, Stefan Berger wrote:
While testing the SIGHUP handling and reloading of the nwfilter driver, I found that when the filters are rebuilt and mutlipe threads handled the individual interfaces, concurrently running multiple external bash scripts causes strange failures even though the executed ebtables commands are working on different tables for different interfaces. I cannot say for sure where the concurrency problems are caused, but introducing this lock definitely helps.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
ACK.
I'll push this shortly. For the record, here two scripts, that each execute fine but once run concurrently cause a race. script 1: #!/bin/bash dev=xyzdev while test 1; do ebtables -t nat -A PREROUTING -i ${dev} -j ACCEPT if [ $? -ne 0 ]; then echo "odd!" fi ebtables -t nat -D PREROUTING -i ${dev} -j ACCEPT if [ $? -ne 0 ]; then echo "odd!" fi script 2: #!/bin/bash dev=xyzdev2 while test 1; do ebtables -t nat -A PREROUTING -i ${dev} -j ACCEPT if [ $? -ne 0 ]; then echo "odd!" fi ebtables -t nat -D PREROUTING -i ${dev} -j ACCEPT if [ $? -ne 0 ]; then echo "odd!" fi Output when run concurrently: The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension. odd! The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension. odd! Stefan
participants (3)
-
Eric Blake
-
Stefan Berger
-
Stefan Berger