1. 30 Jun, 2020 5 commits
    • Tobias Klauser's avatar
      padata: Remove unused but set variables · 2a211849
      Tobias Klauser authored
      BugLink: https://bugs.launchpad.net/bugs/1883916
      
      commit 119a0798 upstream.
      
      Remove the unused but set variable pinst in padata_parallel_worker to
      fix the following warning when building with 'W=1':
      
        kernel/padata.c: In function ‘padata_parallel_worker’:
        kernel/padata.c:68:26: warning: variable ‘pinst’ set but not used [-Wunused-but-set-variable]
      
      Also remove the now unused variable pd which is only used to set pinst.
      Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
      Acked-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      2a211849
    • Cao jin's avatar
      igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr · a06d2fa4
      Cao jin authored
      BugLink: https://bugs.launchpad.net/bugs/1883916
      
      commit 629823b8 upstream.
      
      When running as guest, under certain condition, it will oops as following.
      writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
      is NULL. While other register access won't oops kernel because they use
      wr32/rd32 which have a defense against NULL pointer.
      
          [  141.225449] pcieport 0000:00:1c.0: AER: Multiple Uncorrected (Fatal)
          error received: id=0101
          [  141.225523] igb 0000:01:00.1: PCIe Bus Error:
          severity=Uncorrected (Fatal), type=Unaccessible,
          id=0101(Unregistered Agent ID)
          [  141.299442] igb 0000:01:00.1: broadcast error_detected message
          [  141.300539] igb 0000:01:00.0 enp1s0f0: PCIe link lost, device now
          detached
          [  141.351019] igb 0000:01:00.1 enp1s0f1: PCIe link lost, device now
          detached
          [  143.465904] pcieport 0000:00:1c.0: Root Port link has been reset
          [  143.465994] igb 0000:01:00.1: broadcast slot_reset message
          [  143.466039] igb 0000:01:00.0: enabling device (0000 -> 0002)
          [  144.389078] igb 0000:01:00.1: enabling device (0000 -> 0002)
          [  145.312078] igb 0000:01:00.1: broadcast resume message
          [  145.322211] BUG: unable to handle kernel paging request at
          0000000000003818
          [  145.361275] IP: [<ffffffffa02fd38d>]
          igb_configure_tx_ring+0x14d/0x280 [igb]
          [  145.400048] PGD 0
          [  145.438007] Oops: 0002 [#1] SMP
      
      A similar issue & solution could be found at:
          http://patchwork.ozlabs.org/patch/689592/Signed-off-by: default avatarCao jin <caoj.fnst@cn.fujitsu.com>
      Acked-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      a06d2fa4
    • Alison Schofield's avatar
      x86, sched: Allow topologies where NUMA nodes share an LLC · 86a0090a
      Alison Schofield authored
      BugLink: https://bugs.launchpad.net/bugs/1882478
      
      Intel's Skylake Server CPUs have a different LLC topology than previous
      generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided
      into two "slices", each containing half the cores, half the LLC, and one
      memory controller and each slice is enumerated to Linux as a NUMA
      node. This is similar to how the cores and LLC were arranged for the
      Cluster-On-Die (CoD) feature.
      
      CoD allowed the same cache line to be present in each half of the LLC.
      But, with SNC, each line is only ever present in *one* slice. This means
      that the portion of the LLC *available* to a CPU depends on the data being
      accessed:
      
          Remote socket: entire package LLC is shared
          Local socket->local slice: data goes into local slice LLC
          Local socket->remote slice: data goes into remote-slice LLC. Slightly
                          		higher latency than local slice LLC.
      
      The biggest implication from this is that a process accessing all
      NUMA-local memory only sees half the LLC capacity.
      
      The CPU describes its cache hierarchy with the CPUID instruction. One of
      the CPUID leaves enumerates the "logical processors sharing this
      cache". This information is used for scheduling decisions so that tasks
      move more freely between CPUs sharing the cache.
      
      But, the CPUID for the SNC configuration discussed above enumerates the LLC
      as being shared by the entire package. This is not 100% precise because the
      entire cache is not usable by all accesses. But, it *is* the way the
      hardware enumerates itself, and this is not likely to change.
      
      The userspace visible impact of all the above is that the sysfs info
      reports the entire LLC as being available to the entire package. As noted
      above, this is not true for local socket accesses. This patch does not
      correct the sysfs info. It is the same, pre and post patch.
      
      The current code emits the following warning:
      
       sched: CPU #3's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
      
      The warning is coming from the topology_sane() check in smpboot.c because
      the topology is not matching the expectations of the model for obvious
      reasons.
      
      To fix this, add a vendor and model specific check to never call
      topology_sane() for these systems. Also, just like "Cluster-on-Die" disable
      the "coregroup" sched_domain_topology_level and use NUMA information from
      the SRAT alone.
      
      This is OK at least on the hardware we are immediately concerned about
      because the LLC sharing happens at both the slice and at the package level,
      which are also NUMA boundaries.
      Signed-off-by: default avatarAlison Schofield <alison.schofield@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: brice.goglin@gmail.com
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@linux.intel.com>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Link: https://lkml.kernel.org/r/20180407002130.GA18984@alison-desk.jf.intel.com
      (backported from commit 1340ccfa)
      [mruffell: re-arrange #includes to match upstream, remove comment hunk]
      Signed-off-by: default avatarMatthew Ruffell <matthew.ruffell@canonical.com>
      Acked-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Acked-by: default avatarSultan Alsawaf <sultan.alsawaf@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      86a0090a
    • J. R. Okajima's avatar
      UBUNTU: SAUCE: aufs: bugfix, IMA i_readcount · 332c268d
      J. R. Okajima authored
      By the recent commit
      	21913077f9918 2020-06-17 aufs: do not call i_readcount_inc()
      a very old bug was fixed, which is inblance counter.
      But still aufs needs to call i_readcount_inc() when the branch
      permission is chaned from RW to RO.  Otherwise the counter reaches 0
      and BUG() in i_readcount_dec() will be activated.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      (cherry picked from commit f10aea57d39d6cd311312e9e7746804f7059b5c8 aufs4-linux.git)
      CVE-2020-11935
      Signed-off-by: default avatarMauricio Faria de Oliveira <mfo@canonical.com>
      Acked-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Acked-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      332c268d
    • Mauricio Faria de Oliveira's avatar
      UBUNTU: SAUCE: aufs: do not call i_readcount_inc() · f500cf60
      Mauricio Faria de Oliveira authored
      The 'struct inode.i_readcount' field is maintained at the VFS, and
      should not be modified by filesystems.  But aufs does in one place,
      which causes it to be unbalanced.
      
      This started with Linux v2.6.39 commit 890275b5 ("IMA: maintain
      i_readcount in the VFS layer"), which moved the i_readcount updates
      from IMA into the VFS (at the same places IMA was called previously)
      and introduced 'mutex_lock(i_mutex)' in the ima_file_check() path.
      
      The former change is functionally equivalent, thus no changes are
      needed in response to it.
      
      The latter change, on the other hand, is _not_; and is reported to
      cause a deadlock in aufs (see below), thus it dropped the call to
      ima_file_check().
      
      However, when dropping the ima_file_check() call, aufs introduced
      the i_readcount_inc() call as well, which according to the commit
      changes is not necessary.
      
      This can be observed in aufs2-standalone.git commit 1dbd1c864e455
      ("aufs2.1 standalone version for linux-2.6."), announced to the
      aufs-users mailing list on 2011-04-04 [1].
      
          diff --git a/ChangeLog b/ChangeLog
          ...
          +commit 17eac367b03334e57a93e8051eb712add24d2534
          +Author: J. R. Okajima <hooanon05@yahoo.co.jp>
          +Date:   Fri Apr 1 16:31:22 2011 +0900
          +
          +    aufs: for 2.6.39, limit the support for IMA
          +
          +    Since it acquires i_mutex and causes a deadlock, replace a
          +    ima_file_check() call by i_readcount_inc().
          +
          +    Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
          ...
          diff --git a/fs/aufs/vfsub.c b/fs/aufs/vfsub.c
          ...
          struct file *vfsub_dentry_open(struct path *path, int flags)
          ...
          +       if (!IS_ERR_OR_NULL(file)
          +           && (file->f_mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ)
          +               i_readcount_inc(path->dentry->d_inode);
      
          -       err = ima_file_check(file, au_conv_oflags(flags));
          ...
      
      Apparently, this might have been a misunderstanding of one hunk in
      the 2.6.39 commit, that deletes the lines to increment i_readcount,
      and adds the lines to acquire i_mutex.
      
      It reuses code from the removed function ima_counts_get() to create
      ima_rdwr_violation_check(), and another hunk calls the new function
      from ima_file_check().  But note that the i_readcount increment was
      _not_ called from ima_file_check() previously, via ima_counts_get():
      
          -void ima_counts_get(struct file *file)
          +static void ima_rdwr_violation_check(struct file *file)
           {
          ...
          +       mutex_lock(&inode->i_mutex);    /* file metadata: permissions, xattr */
          ...
          -               atomic_inc(&inode->i_readcount);
      
          #@@ -318,6 +308,7 @@ int ima_file_check(struct file *file, int mask)
          ...
          +       ima_rdwr_violation_check(file);
      
      So, in order to avoid the unbalance caused to i_readcount, drop the
      i_readcount_inc() call.
      
      Note the issue is not the lack of a corresponding i_readcount_dec()
      call; it's the mere usage of these functions outside of VFS layer,
      where i_readcount is maintained.
      
      Links:
      
      [1] https://sourceforge.net/p/aufs/mailman/message/27304125/
          snippet:
      
          """
          aufs2 Monday GIT release
          From: <sfjro@us...> - 2011-04-04 04:59:18
      
          o news
          - begin supporting linux-2.6.39-rcN.
          ...
          - aufs2-2.6.git#aufs2.1 branch
          ...
                aufs: for 2.6.39, limit the support for IMA
          ...
          """
      Signed-off-by: default avatarMauricio Faria de Oliveira <mfo@canonical.com>
      (cherry picked from commit 515a586eeef31e0717d5dea21e2c11a965340b3c aufs4-linux.git)
      CVE-2020-11935
      Signed-off-by: default avatarMauricio Faria de Oliveira <mfo@canonical.com>
      Acked-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Acked-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarKhalid Elmously <khalid.elmously@canonical.com>
      f500cf60
  2. 22 Jun, 2020 1 commit
  3. 08 Jun, 2020 34 commits