1. 30 11月, 2016 3 次提交
    • C
      xprtrdma: Support for SG_GAP devices · 5e9fc6a0
      Chuck Lever 提交于
      Some devices (such as the Mellanox CX-4) can register, under a
      single R_key, a set of memory regions that are not contiguous. When
      this is done, all the segments in a Reply list, say, can then be
      invalidated in a single LocalInv Work Request (or via Remote
      Invalidation, which can invalidate exactly one R_key when completing
      a Receive).
      
      This means a single FastReg WR is used to register, and one or zero
      LocalInv WRs can invalidate, the memory involved with RDMA transfers
      on behalf of an RPC.
      
      In addition, xprtrdma constructs some Reply chunks from three or
      more segments. By registering them with SG_GAP, only one segment
      is needed for the Reply chunk, allowing the whole chunk to be
      invalidated remotely.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      5e9fc6a0
    • C
      xprtrdma: Make FRWR send queue entry accounting more accurate · 8d38de65
      Chuck Lever 提交于
      Verbs providers may perform house-keeping on the Send Queue during
      each signaled send completion. It is necessary therefore for a verbs
      consumer (like xprtrdma) to occasionally force a signaled send
      completion if it runs unsignaled most of the time.
      
      xprtrdma does not require signaled completions for Send or FastReg
      Work Requests, but does signal some LocalInv Work Requests. To
      ensure that Send Queue house-keeping can run before the Send Queue
      is more than half-consumed, xprtrdma forces a signaled completion
      on occasion by counting the number of Send Queue Entries it
      consumes. It currently does this by counting each ib_post_send as
      one Entry.
      
      Commit c9918ff5 ("xprtrdma: Add ro_unmap_sync method for FRWR")
      introduced the ability for frwr_op_unmap_sync to post more than one
      Work Request with a single post_send. Thus the underlying assumption
      of one Send Queue Entry per ib_post_send is no longer true.
      
      Also, FastReg Work Requests are currently never signaled. They
      should be signaled once in a while, just as Send is, to keep the
      accounting of consumed SQEs accurate.
      
      While we're here, convert the CQCOUNT macros to the currently
      preferred kernel coding style, which is inline functions.
      
      Fixes: c9918ff5 ("xprtrdma: Add ro_unmap_sync method for FRWR")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      8d38de65
    • C
      xprtrdma: Cap size of callback buffer resources · 62aee0e3
      Chuck Lever 提交于
      When the inline threshold size is set to large values (say, 32KB)
      any NFSv4.1 CB request from the server gets a reply with status
      NFS4ERR_RESOURCE.
      
      Looks like there are some upper layer assumptions about the maximum
      size of a reply (for example, in process_op). Cap the size of the
      NFSv4 client's reply resources at a page.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      62aee0e3
  2. 28 11月, 2016 3 次提交
  3. 27 11月, 2016 8 次提交
  4. 26 11月, 2016 22 次提交
  5. 25 11月, 2016 4 次提交
    • J
      parisc: Also flush data TLB in flush_icache_page_asm · 5035b230
      John David Anglin 提交于
      This is the second issue I noticed in reviewing the parisc TLB code.
      
      The fic instruction may use either the instruction or data TLB in
      flushing the instruction cache.  Thus, on machines with a split TLB, we
      should also flush the data TLB after setting up the temporary alias
      registers.
      
      Although this has no functional impact, I changed the pdtlb and pitlb
      instructions to consistently use the index register %r0.  These
      instructions do not support integer displacements.
      
      Tested on rp3440 and c8000.
      Signed-off-by: NJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      5035b230
    • J
      parisc: Fix race in pci-dma.c · c0452fb9
      John David Anglin 提交于
      We are still troubled by occasional random segmentation faults and
      memory memory corruption on SMP machines.  The causes quite a few
      package builds to fail on the Debian buildd machines for parisc.  When
      gcc-6 failed to build three times in a row, I looked again at the TLB
      related code.  I found a couple of issues.  This is the first.
      
      In general, we need to ensure page table updates and corresponding TLB
      purges are atomic.  The attached patch fixes an instance in pci-dma.c
      where the page table update was not guarded by the TLB lock.
      
      Tested on rp3440 and c8000.  So far, no further random segmentation
      faults have been observed.
      Signed-off-by: NJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      c0452fb9
    • H
      parisc: Switch to generic sched_clock implementation · 43b1f6ab
      Helge Deller 提交于
      Drop the open-coded sched_clock() function and replace it by the provided
      GENERIC_SCHED_CLOCK implementation.  We have seen quite some hung tasks in the
      past, which seem to be fixed by this patch.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      43b1f6ab
    • J
      parisc: Fix races in parisc_setup_cache_timing() · 741dc7bf
      John David Anglin 提交于
      Helge reported to me the following startup crash:
      
      [    0.000000] Linux version 4.8.0-1-parisc64-smp (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161019 (GCC) ) #1 SMP Debian 4.8.7-1 (2016-11-13)
      [    0.000000] The 64-bit Kernel has started...
      [    0.000000] Kernel default page size is 4 KB. Huge pages enabled with 1 MB physical and 2 MB virtual size.
      [    0.000000] Determining PDC firmware type: System Map.
      [    0.000000] model 9000/785/J5000
      [    0.000000] Total Memory: 2048 MB
      [    0.000000] Memory: 2018528K/2097152K available (9272K kernel code, 3053K rwdata, 1319K rodata, 1024K init, 840K bss, 78624K reserved, 0K cma-reserved)
      [    0.000000] virtual kernel memory layout:
      [    0.000000]     vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
      [    0.000000]     memory  : 0x0000000040000000 - 0x00000000c0000000   (2048 MB)
      [    0.000000]       .init : 0x0000000040100000 - 0x0000000040200000   (1024 kB)
      [    0.000000]       .data : 0x0000000040b0e000 - 0x0000000040f533e0   (4372 kB)
      [    0.000000]       .text : 0x0000000040200000 - 0x0000000040b0e000   (9272 kB)
      [    0.768910] Brought up 1 CPUs
      [    0.992465] NET: Registered protocol family 16
      [    2.429981] Releasing cpu 1 now, hpa=fffffffffffa2000
      [    2.635751] CPU(s): 2 out of 2 PA8500 (PCX-W) at 440.000000 MHz online
      [    2.726692] Setting cache flush threshold to 1024 kB
      [    2.729932] Not-handled unaligned insn 0x43ffff80
      [    2.798114] Setting TLB flush threshold to 140 kB
      [    2.928039] Unaligned handler failed, ret = -1
      [    3.000419]       _______________________________
      [    3.000419]      < Your System ate a SPARC! Gah! >
      [    3.000419]       -------------------------------
      [    3.000419]              \   ^__^
      [    3.000419]                  (__)\       )\/\
      [    3.000419]                   U  ||----w |
      [    3.000419]                      ||     ||
      [    9.340055] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-1-parisc64-smp #1 Debian 4.8.7-1
      [    9.448082] task: 00000000bfd48060 task.stack: 00000000bfd50000
      [    9.528040]
      [   10.760029] IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004025d154 000000004025d158
      [   10.868052]  IIR: 43ffff80    ISR: 0000000000340000  IOR: 000001ff54150960
      [   10.960029]  CPU:        1   CR30: 00000000bfd50000 CR31: 0000000011111111
      [   11.052057]  ORIG_R28: 000000004021e3b4
      [   11.100045]  IAOQ[0]: irq_exit+0x94/0x120
      [   11.152062]  IAOQ[1]: irq_exit+0x98/0x120
      [   11.208031]  RP(r2): irq_exit+0xb8/0x120
      [   11.256074] Backtrace:
      [   11.288067]  [<00000000402cd944>] cpu_startup_entry+0x1e4/0x598
      [   11.368058]  [<0000000040109528>] smp_callin+0x2c0/0x2f0
      [   11.436308]  [<00000000402b53fc>] update_curr+0x18c/0x2d0
      [   11.508055]  [<00000000402b73b8>] dequeue_entity+0x2c0/0x1030
      [   11.584040]  [<00000000402b3cc0>] set_next_entity+0x80/0xd30
      [   11.660069]  [<00000000402c1594>] pick_next_task_fair+0x614/0x720
      [   11.740085]  [<000000004020dd34>] __schedule+0x394/0xa60
      [   11.808054]  [<000000004020e488>] schedule+0x88/0x118
      [   11.876039]  [<0000000040283d3c>] rescuer_thread+0x4d4/0x5b0
      [   11.948090]  [<000000004028fc4c>] kthread+0x1ec/0x248
      [   12.016053]  [<0000000040205020>] end_fault_vector+0x20/0xc0
      [   12.092239]  [<00000000402050c0>] _switch_to_ret+0x0/0xf40
      [   12.164044]
      [   12.184036] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-1-parisc64-smp #1 Debian 4.8.7-1
      [   12.244040] Backtrace:
      [   12.244040]  [<000000004021c480>] show_stack+0x68/0x80
      [   12.244040]  [<00000000406f332c>] dump_stack+0xec/0x168
      [   12.244040]  [<000000004021c74c>] die_if_kernel+0x25c/0x430
      [   12.244040]  [<000000004022d320>] handle_unaligned+0xb48/0xb50
      [   12.244040]
      [   12.632066] ---[ end trace 9ca05a7215c7bbb2 ]---
      [   12.692036] Kernel panic - not syncing: Attempted to kill the idle task!
      
      We have the insn 0x43ffff80 in IIR but from IAOQ we should have:
         4025d150:   0f f3 20 df     ldd,s r19(r31),r31
         4025d154:   0f 9f 00 9c     ldw r31(ret0),ret0
         4025d158:   bf 80 20 58     cmpb,*<> r0,ret0,4025d18c <irq_exit+0xcc>
      
      Cpu0 has just completed running parisc_setup_cache_timing:
      
      [    2.429981] Releasing cpu 1 now, hpa=fffffffffffa2000
      [    2.635751] CPU(s): 2 out of 2 PA8500 (PCX-W) at 440.000000 MHz online
      [    2.726692] Setting cache flush threshold to 1024 kB
      [    2.729932] Not-handled unaligned insn 0x43ffff80
      [    2.798114] Setting TLB flush threshold to 140 kB
      [    2.928039] Unaligned handler failed, ret = -1
      
      From the backtrace, cpu1 is in smp_callin:
      
      void __init smp_callin(void)
      {
             int slave_id = cpu_now_booting;
      
             smp_cpu_init(slave_id);
             preempt_disable();
      
             flush_cache_all_local(); /* start with known state */
             flush_tlb_all_local(NULL);
      
             local_irq_enable();  /* Interrupts have been off until now */
      
             cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
      
      So, it has just flushed its caches and the TLB. It would seem either the
      flushes in parisc_setup_cache_timing or smp_callin have corrupted kernel
      memory.
      
      The attached patch reworks parisc_setup_cache_timing to remove the races
      in setting the cache and TLB flush thresholds. It also corrects the
      number of bytes flushed in the TLB calculation.
      
      The patch flushes the cache and TLB on cpu0 before starting the
      secondary processors so that they are started from a known state.
      
      Tested with a few reboots on c8000.
      Signed-off-by: NJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.18+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      741dc7bf