Skip to content
GitLab
  1. Sep 19, 2018
    • Boqun Feng's avatar
      rcu: Make expedited GPs handle CPU 0 being offline · dfeb52bf
      Boqun Feng authored 
      

Currently, the parallelized initialization of expedited grace periods uses
the workqueue associated with each rcu_node structure's ->grplo field.
This works fine unless that CPU is offline.  This commit therefore uses
the CPU corresponding to the lowest-numbered online CPU, or just queues
the work on WORK_CPU_UNBOUND if there are no online CPUs corresponding
to this rcu_node structure.

Note that this patch uses cpu_is_offline() instead of the usual approach
of checking bits in the rcu_node structure's ->qsmaskinitnext field.  This
is safe because preemption is disabled across both the cpu_is_offline()
check and the call to queue_work_on().

Signed-off-by: default avatarBoqun Feng <boqun.feng@gmail.com>
[ paulmck: Disable preemption to close offline race window. ]
Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
[ paulmck: Apply Peter Zijlstra feedback on CPU selection. ]
Tested-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      dfeb52bf
  3. Aug 28, 2018
    • Palmer Dabbelt's avatar
      RISC-V: Fix sys_riscv_flush_icache · 9f6192e5
      Palmer Dabbelt authored 
      This contains a pair of patches that together fix sys_riscv_flush_icache
on all systems:

* The first enables sys_riscv_flush_icache() for non-SMP systems.
* The second fixes a bug in our syscall header that caused
  sys_riscv_flush_icache to never get generated.
      9f6192e5
    • Palmer Dabbelt's avatar
      RISC-V: Don't use a global include guard for uapi/asm/syscalls.h · 73d15ed8
      Palmer Dabbelt authored 
      

This file is expected to be included multiple times in the same file in
order to allow the __SYSCALL macro to generate system call tables.  With
a global include guard we end up missing __NR_riscv_flush_icache in the
syscall table, which results in icache flushes that escape the vDSO call
to not actually do anything.

The fix is to move to per-#define include guards, which allows the
system call tables to actually be populated.  Thanks to Macrus Comstedt
for finding and fixing the bug!

Cc: Marcus Comstedt <marcus@mc.pp.se>
Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      73d15ed8
    • Palmer Dabbelt's avatar
      RISC-V: Define sys_riscv_flush_icache when SMP=n · eb1cb15e
      Palmer Dabbelt authored 
      

This would be necessary to make non-SMP builds work, but there is
another error in the implementation of our syscall linkage that actually
just causes sys_riscv_flush_icache to never build.  I've build tested
this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
normal.

CC: Christoph Hellwig <hch@infradead.org>
CC: Guenter Roeck <linux@roeck-us.net>
In-Reply-To: <20180809055830.GA17533@infradead.org>
In-Reply-To: <20180809132612.GA31058@roeck-us.net>
Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      eb1cb15e
    • Deepa Dinamani's avatar
      riscv: Delete asm/compat.h · 7bc738f1
      Deepa Dinamani authored 
      

riscv does not enable CONFIG_COMPAT in default configurations:
defconfig, allmodconfig and allnoconfig.
Remove the asm/compat.h as it does not seem to add any value to
the architecture without CONFIG_COMPAT.

Now that time compat syscalls are being reused in non CONFIG_COMPAT
modes, asm-generic/compat.h provides definitions for riscv 32 bit
mode.

Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
Cc: palmer@sifive.com
Cc: linux-riscv@lists.infradead.org
Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      7bc738f1
  5. Aug 21, 2018
    • Christoph Hellwig's avatar
      PCI/xilinx: Depend on OF instead of the ARCH · 76103a26
      Christoph Hellwig authored 
      

There isn't a hard dependency of the Xilinx AXI-PCIe host bridge on any
architecture.  For example: at SiFive we map RISC-V cores to Xilinx FPGAs
and connect the Xilinx IP via a TileLink adapter, so the RISC-V Linux
port will need to be able to enable PCIE_XILINX in order to have PCIe
support.

This patch decouples the PCIE_XILINX support from ARCH.  Instead it just
depends on OF, which is the only true dependency.

Signed-off-by: default avatarPalmer Dabbelt <palmer@dabbelt.com>
[hch: switch to OF instead of OF_PCI now that the latter is gone]
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
[lorenzo.pieralisi@arm.com: trimmed the commit log]
Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      76103a26
    • Wesley W. Terpstra's avatar
      base: fix order of OF initialization · 5ca42fb9
      Wesley W. Terpstra authored 
      

This fixes: [    0.010000] cpu cpu0: Error -2 creating of_node link
... which you get for every CPU on all architectures that use
CONFIG_GENERIC_CPU_DEVICES.

In that case, driver_init() calls cpu_dev_init() before calling
of_core_init(). Then we get the callchain:

  cpu_dev_init()
    -> cpu_dev_register_generic()
    -> register_cpu(cpu, i)
    -> device_register(&cpu->dev)
    -> device_add(dev)
    -> device_add_class_symlinks(dev)

... in device_add_class_symlinks, we we dev->of_node, and call
sysfs_create_link(), which fails because we haven't called
of_core_init() to register the sysfs devicetree directory yet.

Signed-off-by: default avatarWesley W. Terpstra <wesley@sifive.com>
[hch: updated the changelog based on review feedback]
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
Acked-by: default avatarFrank Rowand <frowand.list@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ca42fb9
    • Palmer Dabbelt's avatar
      RISC-V Updates for the 4.19 Merge Window · 33e7d009
      Palmer Dabbelt authored 
      This tag contains some major improvements to the RISC-V port, including
the necessary interrupt controller and timer support to actually make it
to userspace.  Support for three devices has been added:

* Support for the ISA-mandated timers on RISC-V systems.
* Support for the ISA-mandated first-level interrupt controller on
  RISC-V systems, which is handled as part of our core arch code because
  it's very small and tightly tied to the ISA.
* Support for SiFive's platform-level interrupt controller, which talks
  to the actual devices.

In addition to these new devices, there are a handful of cleanups all
over the RISC-V tree:

* Build fixes for various configurations
    * A fix to the vDSO build's makefile so it respects CFLAGS.
    * The addition of __lshrti3, a libgcc derived function necessary for
      some 32-bit configurations.
    * !SMP && PERF_EVENTS
* Cleanups to the arch code to remove the remnants of old versions of
  the drivers that were just properly submitted.
    * Some dead code from the timer driver, most of which wasn't ever
      even compiled.
    * Cleanups of some interrupt #defines, which are now local to the
      interrupt handling code.
* Fixes to ptrace(), which while not being sufficient to fully make GDB
  work are at least sufficient to get simple GDB tasks to work.
* Early printk support via RISC-V's architecturally mandated SBI console
  device.
* A fix to our early debug trap handler to ensure it's always aligned.

These patches have all been through a fairly extensive review process,
but as this enables a whole pile of functionality (ie, userspace) I'm
confident we'll need to submit a few more patches.  The only concrete
issues I know about are the sys_riscv_flush_icache patches, but as I
managed to screw those up on Friday I figured it'd be best to let them
bake another week.

This tag boots a Fedora root filesystem on QEMU's master branch for me,
and before this morning's rebase (from 4.18-rc8 to 4.18) it booted on
the HiFive Unleashed.

Thanks to Christoph Hellwig and the other guys at WD for getting the new
drivers in shape!
      33e7d009
  7. Aug 14, 2018
  9. Aug 13, 2018
  11. Aug 12, 2018
  13. Aug 11, 2018
  15. Aug 10, 2018
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · e91e2189
      David S. Miller authored 
      

Daniel Borkmann says:

====================
pull-request: bpf 2018-08-10

The following pull-request contains BPF updates for your *net* tree.

The main changes are:

1) Fix cpumap and devmap on teardown as they're under RCU context
   and won't have same assumption as running under NAPI protection,
   from Jesper.

2) Fix various sockmap bugs in bpf_tcp_sendmsg() code, e.g. we had
   a bug where socket error was not propagated correctly, from Daniel.

3) Fix incompatible libbpf header license for BTF code and match it
   before it gets officially released with the rest of libbpf which
   is LGPL-2.1, from Martin.
====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e91e2189
    • Al Viro's avatar
      make sure that __dentry_kill() always invalidates d_seq, unhashed or not · 4c0d7cd5
      Al Viro authored 
      

RCU pathwalk relies upon the assumption that anything that changes
->d_inode of a dentry will invalidate its ->d_seq.  That's almost
true - the one exception is that the final dput() of already unhashed
dentry does *not* touch ->d_seq at all.  Unhashing does, though,
so for anything we'd found by RCU dcache lookup we are fine.
Unfortunately, we can *start* with an unhashed dentry or jump into
it.

We could try and be careful in the (few) places where that could
happen.  Or we could just make the final dput() invalidate the damn
thing, unhashed or not.  The latter is much simpler and easier to
backport, so let's do it that way.

Reported-by: default avatar"Dae R. Jeong" <threeearcat@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      4c0d7cd5
    • Al Viro's avatar
      fix __legitimize_mnt()/mntput() race · 119e1ef8
      Al Viro authored 
      

__legitimize_mnt() has two problems - one is that in case of success
the check of mount_lock is not ordered wrt preceding increment of
refcount, making it possible to have successful __legitimize_mnt()
on one CPU just before the otherwise final mntpu() on another,
with __legitimize_mnt() not seeing mntput() taking the lock and
mntput() not seeing the increment done by __legitimize_mnt().
Solved by a pair of barriers.

Another is that failure of __legitimize_mnt() on the second
read_seqretry() leaves us with reference that'll need to be
dropped by caller; however, if that races with final mntput()
we can end up with caller dropping rcu_read_lock() and doing
mntput() to release that reference - with the first mntput()
having freed the damn thing just as rcu_read_lock() had been
dropped.  Solution: in "do mntput() yourself" failure case
grab mount_lock, check if MNT_DOOMED has been set by racing
final mntput() that has missed our increment and if it has -
undo the increment and treat that as "failure, caller doesn't
need to drop anything" case.

It's not easy to hit - the final mntput() has to come right
after the first read_seqretry() in __legitimize_mnt() *and*
manage to miss the increment done by __legitimize_mnt() before
the second read_seqretry() in there.  The things that are almost
impossible to hit on bare hardware are not impossible on SMP
KVM, though...

Reported-by: default avatarOleg Nesterov <oleg@redhat.com>
Fixes: 48a066e7

 ("RCU'd vsfmounts")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      119e1ef8