1. 26 Nov, 2019 2 commits
  2. 22 Nov, 2019 2 commits
  3. 11 Nov, 2019 1 commit
    • Jan Stancek's avatar
      iomap: fix return value of iomap_dio_bio_actor on 32bit systems · e9f930ac
      Jan Stancek authored
      Naresh reported LTP diotest4 failing for 32bit x86 and arm -next
      kernels on ext4. Same problem exists in 5.4-rc7 on xfs.
      
      The failure comes down to:
        openat(AT_FDCWD, "testdata-4.5918", O_RDWR|O_DIRECT) = 4
        mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f7b000
        read(4, 0xb7f7b000, 4096)              = 0 // expects -EFAULT
      
      Problem is conversion at iomap_dio_bio_actor() return. Ternary
      operator has a return type and an attempt is made to convert each
      of operands to the type of the other. In this case "ret" (int)
      is converted to type of "copied" (unsigned long). Both have size
      of 4 bytes:
          size_t copied = 0;
          int ret = -14;
          long long actor_ret = copied ? copied : ret;
      
          On x86_64: actor_ret == -14;
          On x86   : actor_ret == 4294967282
      
      Replace ternary operator with 2 return statements to avoid this
      unwanted conversion.
      
      Fixes: 4721a601 ("iomap: dio data corruption and spurious errors when pipes fill")
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: default avatarJan Stancek <jstancek@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      e9f930ac
  4. 08 Nov, 2019 1 commit
  5. 07 Nov, 2019 1 commit
  6. 29 Oct, 2019 1 commit
  7. 21 Oct, 2019 22 commits
  8. 17 Oct, 2019 1 commit
    • Dave Chinner's avatar
      iomap: iomap that extends beyond EOF should be marked dirty · 7684e2c4
      Dave Chinner authored
      When doing a direct IO that spans the current EOF, and there are
      written blocks beyond EOF that extend beyond the current write, the
      only metadata update that needs to be done is a file size extension.
      
      However, we don't mark such iomaps as IOMAP_F_DIRTY to indicate that
      there is IO completion metadata updates required, and hence we may
      fail to correctly sync file size extensions made in IO completion
      when O_DSYNC writes are being used and the hardware supports FUA.
      
      Hence when setting IOMAP_F_DIRTY, we need to also take into account
      whether the iomap spans the current EOF. If it does, then we need to
      mark it dirty so that IO completion will call generic_write_sync()
      to flush the inode size update to stable storage correctly.
      
      Fixes: 3460cac1 ("iomap: Use FUA for pure data O_DSYNC DIO writes")
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      [darrick: removed the ext4 part; they'll handle it separately]
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      7684e2c4
  9. 15 Oct, 2019 2 commits
  10. 13 Oct, 2019 7 commits
    • Linus Torvalds's avatar
      Linux 5.4-rc3 · 4f5cafb5
      Linus Torvalds authored
      4f5cafb5
    • Linus Torvalds's avatar
      Merge tag 'trace-v5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · d4615e5a
      Linus Torvalds authored
      Pull tracing fixes from Steven Rostedt:
       "A few tracing fixes:
      
         - Remove lockdown from tracefs itself and moved it to the trace
           directory. Have the open functions there do the lockdown checks.
      
         - Fix a few races with opening an instance file and the instance
           being deleted (Discovered during the lockdown updates). Kept
           separate from the clean up code such that they can be backported to
           stable easier.
      
         - Clean up and consolidated the checks done when opening a trace
           file, as there were multiple checks that need to be done, and it
           did not make sense having them done in each open instance.
      
         - Fix a regression in the record mcount code.
      
         - Small hw_lat detector tracer fixes.
      
         - A trace_pipe read fix due to not initializing trace_seq"
      
      * tag 'trace-v5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Initialize iter->seq after zeroing in tracing_read_pipe()
        tracing/hwlat: Don't ignore outer-loop duration when calculating max_latency
        tracing/hwlat: Report total time spent in all NMIs during the sample
        recordmcount: Fix nop_mcount() function
        tracing: Do not create tracefs files if tracefs lockdown is in effect
        tracing: Add locked_down checks to the open calls of files created for tracefs
        tracing: Add tracing_check_open_get_tr()
        tracing: Have trace events system open call tracing_open_generic_tr()
        tracing: Get trace_array reference for available_tracers files
        ftrace: Get a reference counter for the trace_array on filter files
        tracefs: Revert ccbd54ff ("tracefs: Restrict tracefs when the kernel is locked down")
      d4615e5a
    • Linus Torvalds's avatar
      Merge tag 'hwmon-for-v5.4-rc3' of... · 2581efa9
      Linus Torvalds authored
      Merge tag 'hwmon-for-v5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
      
      Pull hwmon fixes from Guenter Roeck:
      
       - Update/fix inspur-ipsps1 and k10temp Documentation
      
       - Fix nct7904 driver
      
       - Fix HWMON_P_MIN_ALARM mask in hwmon core
      
      * tag 'hwmon-for-v5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
        hwmon: docs: Extend inspur-ipsps1 title underline
        hwmon: (nct7904) Add array fan_alarm and vsen_alarm to store the alarms in nct7904_data struct.
        docs: hwmon: Include 'inspur-ipsps1.rst' into docs
        hwmon: Fix HWMON_P_MIN_ALARM mask
        hwmon: (k10temp) Update documentation and add temp2_input info
        hwmon: (nct7904) Fix the incorrect value of vsen_mask in nct7904_data struct
      2581efa9
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux · 71b1b553
      Linus Torvalds authored
      Pull MTD fixes from Richard Weinberger:
       "Two fixes for MTD:
      
         - spi-nor: Fix for a regression in write_sr()
      
         - rawnand: Regression fix for the au1550nd driver"
      
      * tag 'fixes-for-5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
        mtd: rawnand: au1550nd: Fix au_read_buf16() prototype
        mtd: spi-nor: Fix direction of the write_sr() transfer
      71b1b553
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20191012' of git://git.kernel.dk/linux-block · b27528b0
      Linus Torvalds authored
      Pull io_uring fix from Jens Axboe:
       "Single small fix for a regression in the sequence logic for linked
        commands"
      
      * tag 'for-linus-20191012' of git://git.kernel.dk/linux-block:
        io_uring: fix sequence logic for timeout requests
      b27528b0
    • Petr Mladek's avatar
      tracing: Initialize iter->seq after zeroing in tracing_read_pipe() · d303de1f
      Petr Mladek authored
      A customer reported the following softlockup:
      
      [899688.160002] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [test.sh:16464]
      [899688.160002] CPU: 0 PID: 16464 Comm: test.sh Not tainted 4.12.14-6.23-azure #1 SLE12-SP4
      [899688.160002] RIP: 0010:up_write+0x1a/0x30
      [899688.160002] Kernel panic - not syncing: softlockup: hung tasks
      [899688.160002] RIP: 0010:up_write+0x1a/0x30
      [899688.160002] RSP: 0018:ffffa86784d4fde8 EFLAGS: 00000257 ORIG_RAX: ffffffffffffff12
      [899688.160002] RAX: ffffffff970fea00 RBX: 0000000000000001 RCX: 0000000000000000
      [899688.160002] RDX: ffffffff00000001 RSI: 0000000000000080 RDI: ffffffff970fea00
      [899688.160002] RBP: ffffffffffffffff R08: ffffffffffffffff R09: 0000000000000000
      [899688.160002] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8b59014720d8
      [899688.160002] R13: ffff8b59014720c0 R14: ffff8b5901471090 R15: ffff8b5901470000
      [899688.160002]  tracing_read_pipe+0x336/0x3c0
      [899688.160002]  __vfs_read+0x26/0x140
      [899688.160002]  vfs_read+0x87/0x130
      [899688.160002]  SyS_read+0x42/0x90
      [899688.160002]  do_syscall_64+0x74/0x160
      
      It caught the process in the middle of trace_access_unlock(). There is
      no loop. So, it must be looping in the caller tracing_read_pipe()
      via the "waitagain" label.
      
      Crashdump analyze uncovered that iter->seq was completely zeroed
      at this point, including iter->seq.seq.size. It means that
      print_trace_line() was never able to print anything and
      there was no forward progress.
      
      The culprit seems to be in the code:
      
      	/* reset all but tr, trace, and overruns */
      	memset(&iter->seq, 0,
      	       sizeof(struct trace_iterator) -
      	       offsetof(struct trace_iterator, seq));
      
      It was added by the commit 53d0aa77 ("ftrace:
      add logic to record overruns"). It was v2.6.27-rc1.
      It was the time when iter->seq looked like:
      
           struct trace_seq {
      	unsigned char		buffer[PAGE_SIZE];
      	unsigned int		len;
           };
      
      There was no "size" variable and zeroing was perfectly fine.
      
      The solution is to reinitialize the structure after or without
      zeroing.
      
      Link: http://lkml.kernel.org/r/20191011142134.11997-1-pmladek@suse.comSigned-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      d303de1f
    • Srivatsa S. Bhat (VMware)'s avatar
      tracing/hwlat: Don't ignore outer-loop duration when calculating max_latency · fc64e4ad
      Srivatsa S. Bhat (VMware) authored
      max_latency is intended to record the maximum ever observed hardware
      latency, which may occur in either part of the loop (inner/outer). So
      we need to also consider the outer-loop sample when updating
      max_latency.
      
      Link: http://lkml.kernel.org/r/157073345463.17189.18124025522664682811.stgit@srivatsa-ubuntu
      
      Fixes: e7c15cd8 ("tracing: Added hardware latency tracer")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSrivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      fc64e4ad