1. 22 Aug, 2016 7 commits
  2. 09 Aug, 2016 1 commit
  3. 08 Aug, 2016 23 commits
  4. 03 Aug, 2016 1 commit
    • Florian Westphal's avatar
      netfilter: x_tables: speed up jump target validation · f5bba514
      Florian Westphal authored
      [ Upstream commit f4dc7771 ]
      
      The dummy ruleset I used to test the original validation change was broken,
      most rules were unreachable and were not tested by mark_source_chains().
      
      In some cases rulesets that used to load in a few seconds now require
      several minutes.
      
      sample ruleset that shows the behaviour:
      
      echo "*filter"
      for i in $(seq 0 100000);do
              printf ":chain_%06x - [0:0]\n" $i
      done
      for i in $(seq 0 100000);do
         printf -- "-A INPUT -j chain_%06x\n" $i
         printf -- "-A INPUT -j chain_%06x\n" $i
         printf -- "-A INPUT -j chain_%06x\n" $i
      done
      echo COMMIT
      
      [ pipe result into iptables-restore ]
      
      This ruleset will be about 74mbyte in size, with ~500k searches
      though all 500k[1] rule entries. iptables-restore will take forever
      (gave up after 10 minutes)
      
      Instead of always searching the entire blob for a match, fill an
      array with the start offsets of every single ipt_entry struct,
      then do a binary search to check if the jump target is present or not.
      
      After this change ruleset restore times get again close to what one
      gets when reverting 36472341 (~3 seconds on my workstation).
      
      [1] every user-defined rule gets an implicit RETURN, so we get
      300k jumps + 100k userchains + 100k returns -> 500k rule entries
      
      Fixes: 36472341 ("netfilter: x_tables: validate targets of jumps")
      Reported-by: default avatarJeff Wu <wujiafu@gmail.com>
      Tested-by: default avatarJeff Wu <wujiafu@gmail.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f5bba514
  5. 01 Aug, 2016 2 commits
  6. 30 Jul, 2016 1 commit
  7. 20 Jul, 2016 5 commits
    • Steven Rostedt's avatar
      4.1.28 Fix bad backport of 8f182270 "mm/swap.c: flush lru pvecs on compound page arrival" · 52c84a95
      Steven Rostedt authored
      When I pulled in 4.1.28 into my stable 4.1-rt tree and ran the tests,
      it crashed with a severe OOM killing everything. I then tested 4.1.28
      without -rt and it had the same issue. I did a bisect between 4.1.27
      and 4.1.28 and found that the bug started at:
      
      commit 8f182270 "mm/swap.c: flush lru pvecs on compound page
      arrival"
      
      Looking at that patch and what's in mainline, I see that there's a
      mismatch in one of the hunks:
      
      Mainline:
      
      @@ -391,9 +391,8 @@ static void __lru_cache_add(struct page *page)
              struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
      
              get_page(page);
      -       if (!pagevec_space(pvec))
      +       if (!pagevec_add(pvec, page) || PageCompound(page))
                      __pagevec_lru_add(pvec);
      -       pagevec_add(pvec, page);
              put_cpu_var(lru_add_pvec);
       }
      
      Stable 4.1.28:
      
      @@ -631,9 +631,8 @@ static void __lru_cache_add(struct page *page)
              struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
      
              page_cache_get(page);
      -       if (!pagevec_space(pvec))
      +       if (!pagevec_space(pvec) || PageCompound(page))
                      __pagevec_lru_add(pvec);
      -       pagevec_add(pvec, page);
              put_cpu_var(lru_add_pvec);
       }
      
      Where mainline replace pagevec_space() with pagevec_add, and stable did
      not.
      
      Fixing this makes the OOM go away.
      
      Note, 3.18 has the same bug.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      52c84a95
    • Michael Ellerman's avatar
      powerpc: Fix build break due to missing PPC_FEATURE2_HTM_NOSC · da3e7add
      Michael Ellerman authored
      The backport of 4705e024 ("powerpc: Update TM user feature bits in
      scan_features()") (f49eb503), missed the fact that 4.1 doesn't
      include the commit that added PPC_FEATURE2_HTM_NOSC.
      
      The correct fix is simply to omit PPC_FEATURE2_HTM_NOSC.
      
      Fixes: f49eb503 ("powerpc: Update TM user feature bits in scan_features()")
      Reported-by: default avatarChristian Zigotzky <chzigotzky@bayern-mail.de>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      da3e7add
    • Jeff Mahoney's avatar
      ecryptfs: don't allow mmap when the lower fs doesn't support it · 8c8e669b
      Jeff Mahoney authored
      [ Upstream commit f0fe970d ]
      
      There are legitimate reasons to disallow mmap on certain files, notably
      in sysfs or procfs.  We shouldn't emulate mmap support on file systems
      that don't offer support natively.
      
      CVE-2016-1583
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Cc: stable@vger.kernel.org
      [tyhicks: clean up f_op check by using ecryptfs_file_to_lower()]
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8c8e669b
    • Jan Beulich's avatar
      xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7 · 050216f6
      Jan Beulich authored
      [ Upstream commit 6f2d9d99 ]
      
      As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
      CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
      both Intel and AMD systems. Doing any kind of hardware capability
      checks in the driver as a prerequisite was wrong anyway: With the
      hypervisor being in charge, all such checking should be done by it. If
      ACPI data gets uploaded despite some missing capability, the hypervisor
      is free to ignore part or all of that data.
      
      Ditch the entire check_prereq() function, and do the only valid check
      (xen_initial_domain()) in the caller in its place.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      050216f6
    • Jan Beulich's avatar
      xenbus: don't bail early from xenbus_dev_request_and_reply() · 38cd765b
      Jan Beulich authored
      [ Upstream commit 7469be95 ]
      
      xenbus_dev_request_and_reply() needs to track whether a transaction is
      open.  For XS_TRANSACTION_START messages it calls transaction_start()
      and for XS_TRANSACTION_END messages it calls transaction_end().
      
      If sending an XS_TRANSACTION_START message fails or responds with an
      an error, the transaction is not open and transaction_end() must be
      called.
      
      If sending an XS_TRANSACTION_END message fails, the transaction is
      still open, but if an error response is returned the transaction is
      closed.
      
      Commit 027bd7e8 ("xen/xenbus: Avoid synchronous wait on XenBus
      stalling shutdown/restart") introduced a regression where failed
      XS_TRANSACTION_START messages were leaving the transaction open.  This
      can cause problems with suspend (and migration) as all transactions
      must be closed before suspending.
      
      It appears that the problematic change was added accidentally, so just
      remove it.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      38cd765b