1. 02 Jun, 2020 4 commits
    • Vivek Goyal's avatar
      ovl: initialize OVL_UPPERDATA in ovl_lookup() · 28166ab3
      Vivek Goyal authored
      Currently ovl_get_inode() initializes OVL_UPPERDATA flag and for that it
      has to call ovl_check_metacopy_xattr() and check if metacopy xattr is
      present or not.
      
      yangerkun reported sometimes underlying filesystem might return -EIO and in
      that case error handling path does not cleanup properly leading to various
      warnings.
      
      Run generic/461 with ext4 upper/lower layer sometimes may trigger the bug
      as below(linux 4.19):
      
      [  551.001349] overlayfs: failed to get metacopy (-5)
      [  551.003464] overlayfs: failed to get inode (-5)
      [  551.004243] overlayfs: cleanup of 'd44/fd51' failed (-5)
      [  551.004941] overlayfs: failed to get origin (-5)
      [  551.005199] ------------[ cut here ]------------
      [  551.006697] WARNING: CPU: 3 PID: 24674 at fs/inode.c:1528 iput+0x33b/0x400
      ...
      [  551.027219] Call Trace:
      [  551.027623]  ovl_create_object+0x13f/0x170
      [  551.028268]  ovl_create+0x27/0x30
      [  551.028799]  path_openat+0x1a35/0x1ea0
      [  551.029377]  do_filp_open+0xad/0x160
      [  551.029944]  ? vfs_writev+0xe9/0x170
      [  551.030499]  ? page_counter_try_charge+0x77/0x120
      [  551.031245]  ? __alloc_fd+0x160/0x2a0
      [  551.031832]  ? do_sys_open+0x189/0x340
      [  551.032417]  ? get_unused_fd_flags+0x34/0x40
      [  551.033081]  do_sys_open+0x189/0x340
      [  551.033632]  __x64_sys_creat+0x24/0x30
      [  551.034219]  do_syscall_64+0xd5/0x430
      [  551.034800]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      One solution is to improve error handling and call iget_failed() if error
      is encountered.  Amir thinks that this path is little intricate and there
      is not real need to check and initialize OVL_UPPERDATA in ovl_get_inode().
      Instead caller of ovl_get_inode() can initialize this state.  And this will
      avoid double checking of metacopy xattr lookup in ovl_lookup() and
      ovl_get_inode().
      
      OVL_UPPERDATA is inode flag.  So I was little concerned that initializing
      it outside ovl_get_inode() might have some races.  But this is one way
      transition.  That is once a file has been fully copied up, it can't go back
      to metacopy file again.  And that seems to help avoid races.  So as of now
      I can't see any races w.r.t OVL_UPPERDATA being set wrongly.  So move
      settingof OVL_UPPERDATA inside the callers of ovl_get_inode().
      ovl_obtain_alias() already does it.  So only two callers now left are
      ovl_lookup() and ovl_instantiate().
      Reported-by: default avataryangerkun <yangerkun@huawei.com>
      Suggested-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      28166ab3
    • Vivek Goyal's avatar
      ovl: use only uppermetacopy state in ovl_lookup() · 6815f479
      Vivek Goyal authored
      Currently we use a variable "metacopy" which signifies that dentry could be
      either uppermetacopy or lowermetacopy.  Amir suggested that we can move
      code around and use d.metacopy in such a way that we don't need
      lowermetacopy and just can do away with uppermetacopy.
      
      So this patch replaces "metacopy" with "uppermetacopy".
      
      It also moves some code little higher to keep reading little simpler.
      Suggested-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      6815f479
    • Vivek Goyal's avatar
      ovl: simplify setting of origin for index lookup · 59fb2013
      Vivek Goyal authored
      overlayfs can keep index of copied up files and directories and it seems to
      serve two primary puroposes.  For regular files, it avoids breaking lower
      hardlinks over copy up.  For directories it seems to be used for various
      error checks.
      
      During ovl_lookup(), we lookup for index using lower dentry in many a
      cases.  That lower dentry is called "origin" and following is a summary of
      current logic.
      
      If there is no upperdentry, always lookup for index using lower dentry.
      For regular files it helps avoiding breaking hard links over copyup and for
      directories it seems to be just error checks.
      
      If there is an upperdentry, then there are 3 possible cases.
      
       - For directories, lower dentry is found using two ways.  One is regular
        path based lookup in lower layers and second is using ORIGIN xattr on
        upper dentry.  First verify that path based lookup lower dentry matches
        the one pointed by upper ORIGIN xattr.  If yes, use this verified origin
        for index lookup.
      
       - For regular files (non-metacopy), there is no path based lookup in lower
        layers as lookup stops once we find upper dentry.  So there is no origin
        verification.  If there is ORIGIN xattr present on upper, use that to
        lookup index otherwise don't.
      
       - For regular metacopy files, again lower dentry is found using path based
        lookup as well as ORIGIN xattr on upper.  Path based lookup is continued
        in this case to find lower data dentry for metacopy upper.  So like
        directories we only use verified origin.  If ORIGIN xattr is not present
        (Either because lower did not support file handles or because this is
        hardlink copied up with index=off), then don't use path lookup based
        lower dentry as origin.  This is same as regular non-metacopy file case.
      Suggested-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      59fb2013
    • Amir Goldstein's avatar
      ovl: fix out of bounds access warning in ovl_check_fb_len() · 522f6e6c
      Amir Goldstein authored
      syzbot reported out of bounds memory access from open_by_handle_at()
      with a crafted file handle that looks like this:
      
        { .handle_bytes = 2, .handle_type = OVL_FILEID_V1 }
      
      handle_bytes gets rounded down to 0 and we end up calling:
        ovl_check_fh_len(fh, 0) => ovl_check_fb_len(fh + 3, -3)
      
      But fh buffer is only 2 bytes long, so accessing struct ovl_fb at
      fh + 3 is illegal.
      
      Fixes: cbe7fba8 ("ovl: make sure that real fid is 32bit aligned in memory")
      Reported-and-tested-by: syzbot+61958888b1c60361a791@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org> # v5.5
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      522f6e6c
  2. 13 May, 2020 10 commits
  3. 30 Apr, 2020 2 commits
    • Vivek Goyal's avatar
      ovl: clear ATTR_OPEN from attr->ia_valid · 15fd2ea9
      Vivek Goyal authored
      As of now during open(), we don't pass bunch of flags to underlying
      filesystem. O_TRUNC is one of these. Normally this is not a problem as VFS
      calls ->setattr() with zero size and underlying filesystem sets file size
      to 0.
      
      But when overlayfs is running on top of virtiofs, it has an optimization
      where it does not send setattr request to server if dectects that
      truncation is part of open(O_TRUNC). It assumes that server already zeroed
      file size as part of open(O_TRUNC).
      
      fuse_do_setattr() {
              if (attr->ia_valid & ATTR_OPEN) {
                      /*
                       * No need to send request to userspace, since actual
                       * truncation has already been done by OPEN.  But still
                       * need to truncate page cache.
                       */
              }
      }
      
      IOW, fuse expects O_TRUNC to be passed to it as part of open flags.
      
      But currently overlayfs does not pass O_TRUNC to underlying filesystem
      hence fuse/virtiofs breaks. Setup overlayfs on top of virtiofs and
      following does not zero the file size of a file is either upper only or has
      already been copied up.
      
      fd = open(foo.txt, O_TRUNC | O_WRONLY);
      
      There are two ways to fix this. Either pass O_TRUNC to underlying
      filesystem or clear ATTR_OPEN from attr->ia_valid so that fuse ends up
      sending a SETATTR request to server. Miklos is concerned that O_TRUNC might
      have side affects so it is better to clear ATTR_OPEN for now. Hence this
      patch clears ATTR_OPEN from attr->ia_valid.
      
      I found this problem while running unionmount-testsuite. With this patch,
      unionmount-testsuite passes with overlayfs on top of virtiofs.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Fixes: bccece1e ("ovl: allow remote upper")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      15fd2ea9
    • Vivek Goyal's avatar
      ovl: clear ATTR_FILE from attr->ia_valid · e67f0216
      Vivek Goyal authored
      ovl_setattr() can be passed an attr which has ATTR_FILE set and
      attr->ia_file is a file pointer to overlay file. This is done in
      open(O_TRUNC) path.
      
      We should either replace with attr->ia_file with underlying file object or
      clear ATTR_FILE so that underlying filesystem does not end up using
      overlayfs file object pointer.
      
      There are no good use cases yet so for now clear ATTR_FILE. fuse seems to
      be one user which can use this. But it can work even without this.  So it
      is not mandatory to pass ATTR_FILE to fuse.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Fixes: bccece1e ("ovl: allow remote upper")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      e67f0216
  4. 19 Apr, 2020 12 commits
    • Linus Torvalds's avatar
      Linux 5.7-rc2 · ae83d0b4
      Linus Torvalds authored
      ae83d0b4
    • Brian Geffon's avatar
      mm: Fix MREMAP_DONTUNMAP accounting on VMA merge · dadbd85f
      Brian Geffon authored
      When remapping a mapping where a portion of a VMA is remapped
      into another portion of the VMA it can cause the VMA to become
      split. During the copy_vma operation the VMA can actually
      be remerged if it's an anonymous VMA whose pages have not yet
      been faulted. This isn't normally a problem because at the end
      of the remap the original portion is unmapped causing it to
      become split again.
      
      However, MREMAP_DONTUNMAP leaves that original portion in place which
      means that the VMA which was split and then remerged is not actually
      split at the end of the mremap. This patch fixes a bug where
      we don't detect that the VMAs got remerged and we end up
      putting back VM_ACCOUNT on the next mapping which is completely
      unreleated. When that next mapping is unmapped it results in
      incorrectly unaccounting for the memory which was never accounted,
      and eventually we will underflow on the memory comittment.
      
      There is also another issue which is similar, we're currently
      accouting for the number of pages in the new_vma but that's wrong.
      We need to account for the length of the remap operation as that's
      all that is being added. If there was a mapping already at that
      location its comittment would have been adjusted as part of
      the munmap at the start of the mremap.
      
      A really simple repro can be seen in:
      https://gist.github.com/bgaff/e101ce99da7d9a8c60acc641d07f312c
      
      Fixes: e346b381 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarBrian Geffon <bgeffon@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dadbd85f
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 86cc3398
      Linus Torvalds authored
      Pull clk fixes from Stephen Boyd:
       "Two build fixes for a couple clk drivers and a fix for the Unisoc
        serial clk where we want to keep it on for earlycon"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: sprd: don't gate uart console clock
        clk: mmp2: fix link error without mmp2
        clk: asm9260: fix __clk_hw_register_fixed_rate_with_accuracy typo
      86cc3398
    • Linus Torvalds's avatar
      Merge tag 'x86-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 0fe5f9ca
      Linus Torvalds authored
      Pull x86 and objtool fixes from Thomas Gleixner:
       "A set of fixes for x86 and objtool:
      
        objtool:
      
         - Ignore the double UD2 which is emitted in BUG() when
           CONFIG_UBSAN_TRAP is enabled.
      
         - Support clang non-section symbols in objtool ORC dump
      
         - Fix switch table detection in .text.unlikely
      
         - Make the BP scratch register warning more robust.
      
        x86:
      
         - Increase microcode maximum patch size for AMD to cope with new CPUs
           which have a larger patch size.
      
         - Fix a crash in the resource control filesystem when the removal of
           the default resource group is attempted.
      
         - Preserve Code and Data Prioritization enabled state accross CPU
           hotplug.
      
         - Update split lock cpu matching to use the new X86_MATCH macros.
      
         - Change the split lock enumeration as Intel finaly decided that the
           IA32_CORE_CAPABILITIES bits are not architectural contrary to what
           the SDM claims. !@#%$^!
      
         - Add Tremont CPU models to the split lock detection cpu match.
      
         - Add a missing static attribute to make sparse happy"
      
      * tag 'x86-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/split_lock: Add Tremont family CPU models
        x86/split_lock: Bits in IA32_CORE_CAPABILITIES are not architectural
        x86/resctrl: Preserve CDP enable over CPU hotplug
        x86/resctrl: Fix invalid attempt at removing the default resource group
        x86/split_lock: Update to use X86_MATCH_INTEL_FAM6_MODEL()
        x86/umip: Make umip_insns static
        x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE
        objtool: Make BP scratch register warning more robust
        objtool: Fix switch table detection in .text.unlikely
        objtool: Support Clang non-section symbols in ORC generation
        objtool: Support Clang non-section symbols in ORC dump
        objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings
      0fe5f9ca
    • Linus Torvalds's avatar
      Merge tag 'timers-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 3e0dea57
      Linus Torvalds authored
      Pull time namespace fix from Thomas Gleixner:
       "An update for the proc interface of time namespaces: Use symbolic
        names instead of clockid numbers. The usability nuisance of numbers
        was noticed by Michael when polishing the man page"
      
      * tag 'timers-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        proc, time/namespace: Show clock symbolic names in /proc/pid/timens_offsets
      3e0dea57
    • Linus Torvalds's avatar
      Merge tag 'perf-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · b7374586
      Linus Torvalds authored
      Pull perf tooling fixes and updates from Thomas Gleixner:
      
       - Fix the header line of perf stat output for '--metric-only --per-socket'
      
       - Fix the python build with clang
      
       - The usual tools UAPI header synchronization
      
      * tag 'perf-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        tools headers: Synchronize linux/bits.h with the kernel sources
        tools headers: Adopt verbatim copy of compiletime_assert() from kernel sources
        tools headers: Update x86's syscall_64.tbl with the kernel sources
        tools headers UAPI: Sync drm/i915_drm.h with the kernel sources
        tools headers UAPI: Update tools's copy of drm.h headers
        tools headers kvm: Sync linux/kvm.h with the kernel sources
        tools headers UAPI: Sync linux/fscrypt.h with the kernel sources
        tools include UAPI: Sync linux/vhost.h with the kernel sources
        tools arch x86: Sync asm/cpufeatures.h with the kernel sources
        tools headers UAPI: Sync linux/mman.h with the kernel
        tools headers UAPI: Sync sched.h with the kernel
        tools headers: Update linux/vdso.h and grab a copy of vdso/const.h
        perf stat: Fix no metric header if --per-socket and --metric-only set
        perf python: Check if clang supports -fno-semantic-interposition
        tools arch x86: Sync the msr-index.h copy with the kernel sources
      b7374586
    • Linus Torvalds's avatar
      Merge tag 'irq-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 80ade29e
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "A set of fixes/updates for the interrupt subsystem:
      
         - Remove setup_irq() and remove_irq(). All users have been converted
           so remove them before new users surface.
      
         - A set of bugfixes for various interrupt chip drivers
      
         - Add a few missing static attributes to address sparse warnings"
      
      * tag 'irq-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() static
        irqchip/irq-mvebu-icu: Make legacy_bindings static
        irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock order
        irqchip/sifive-plic: Fix maximum priority threshold value
        irqchip/ti-sci-inta: Fix processing of masked irqs
        irqchip/mbigen: Free msi_desc on device teardown
        irqchip/gic-v4.1: Update effective affinity of virtual SGIs
        irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling
        genirq: Remove setup_irq() and remove_irq()
      80ade29e
    • Linus Torvalds's avatar
      Merge tag 'sched-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 08dd3872
      Linus Torvalds authored
      Pull scheduler fixes from Thomas Gleixner:
       "Two fixes for the scheduler:
      
         - Work around an uninitialized variable warning where GCC can't
           figure it out.
      
         - Allow 'isolcpus=' to skip unknown subparameters so that older
           kernels work with the commandline of a newer kernel. Improve the
           error output while at it"
      
      * tag 'sched-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/vtime: Work around an unitialized variable warning
        sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters
      08dd3872
    • Linus Torvalds's avatar
      Merge tag 'core-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 5e7de581
      Linus Torvalds authored
      Pull RCU fix from Thomas Gleixner:
       "A single bugfix for RCU to prevent taking a lock in NMI context"
      
      * tag 'core-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        rcu: Don't acquire lock in NMI handler in rcu_nmi_enter_common()
      5e7de581
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 439f1da9
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Miscellaneous bug fixes and cleanups for ext4, including a fix for
        generic/388 in data=journal mode, removing some BUG_ON's, and cleaning
        up some compiler warnings"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: convert BUG_ON's to WARN_ON's in mballoc.c
        ext4: increase wait time needed before reuse of deleted inode numbers
        ext4: remove set but not used variable 'es' in ext4_jbd2.c
        ext4: remove set but not used variable 'es'
        ext4: do not zeroout extents beyond i_disksize
        ext4: fix return-value types in several function comments
        ext4: use non-movable memory for superblock readahead
        ext4: use matching invalidatepage in ext4_writepage
      439f1da9
    • Linus Torvalds's avatar
      Merge tag '5.7-rc-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6 · aee0314b
      Linus Torvalds authored
      Pull cifs fixes from Steve French:
       "Three small smb3 fixes: two debug related (helping network tracing for
        SMB2 mounts, and the other removing an unintended debug line on
        signing failures), and one fixing a performance problem with 64K
        pages"
      
      * tag '5.7-rc-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
        smb3: remove overly noisy debug line in signing errors
        cifs: improve read performance for page size 64KB & cache=strict & vers=2.1+
        cifs: dump the session id and keys also for SMB2 sessions
      aee0314b
    • Linus Torvalds's avatar
      Merge tag 'flexible-array-member-5.7-rc2' of... · 13402837
      Linus Torvalds authored
      Merge tag 'flexible-array-member-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux
      
      Pull flexible-array member conversion from Gustavo Silva:
       "The current codebase makes use of the zero-length array language
        extension to the C90 standard, but the preferred mechanism to declare
        variable-length types such as these ones is a flexible array
        member[1][2], introduced in C99:
      
          struct foo {
              int stuff;
              struct boo array[];
          };
      
        By making use of the mechanism above, we will get a compiler warning
        in case the flexible array does not occur last in the structure, which
        will help us prevent some kind of undefined behavior bugs from being
        inadvertently introduced[3] to the codebase from now on.
      
        Also, notice that, dynamic memory allocations won't be affected by
        this change:
      
         "Flexible array members have incomplete type, and so the sizeof
          operator may not be applied. As a quirk of the original
          implementation of zero-length arrays, sizeof evaluates to zero."[1]
      
        sizeof(flexible-array-member) triggers a warning because flexible
        array members have incomplete type[1]. There are some instances of
        code in which the sizeof operator is being incorrectly/erroneously
        applied to zero-length arrays and the result is zero. Such instances
        may be hiding some bugs. So, this work (flexible-array member
        convertions) will also help to get completely rid of those sorts of
        issues.
      
        Notice that all of these patches have been baking in linux-next for
        quite a while now and, 238 more of these patches have already been
        merged into 5.7-rc1.
      
        There are a couple hundred more of these issues waiting to be
        addressed in the whole codebase"
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      
      * tag 'flexible-array-member-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: (28 commits)
        xattr.h: Replace zero-length array with flexible-array member
        uapi: linux: fiemap.h: Replace zero-length array with flexible-array member
        uapi: linux: dlm_device.h: Replace zero-length array with flexible-array member
        tpm_eventlog.h: Replace zero-length array with flexible-array member
        ti_wilink_st.h: Replace zero-length array with flexible-array member
        swap.h: Replace zero-length array with flexible-array member
        skbuff.h: Replace zero-length array with flexible-array member
        sched: topology.h: Replace zero-length array with flexible-array member
        rslib.h: Replace zero-length array with flexible-array member
        rio.h: Replace zero-length array with flexible-array member
        posix_acl.h: Replace zero-length array with flexible-array member
        platform_data: wilco-ec.h: Replace zero-length array with flexible-array member
        memcontrol.h: Replace zero-length array with flexible-array member
        list_lru.h: Replace zero-length array with flexible-array member
        lib: cpu_rmap: Replace zero-length array with flexible-array member
        irq.h: Replace zero-length array with flexible-array member
        ihex.h: Replace zero-length array with flexible-array member
        igmp.h: Replace zero-length array with flexible-array member
        genalloc.h: Replace zero-length array with flexible-array member
        ethtool.h: Replace zero-length array with flexible-array member
        ...
      13402837
  5. 18 Apr, 2020 12 commits
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 50cc09c1
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Seven fixes: three in target, one on a sg error leg, two in qla2xxx
        fixing warnings introduced in the last merge window and updating
        MAINTAINERS and one in hisi_sas fixing a problem introduced by libata"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: sg: add sg_remove_request in sg_common_write
        scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKEN
        scsi: target: fix PR IN / READ FULL STATUS for FC
        scsi: target: Write NULL to *port_nexus_ptr if no ISID
        scsi: MAINTAINERS: Update qla2xxx FC-SCSI driver maintainer
        scsi: qla2xxx: Fix regression warnings
        scsi: hisi_sas: Fix build error without SATA_HOST
      50cc09c1
    • Gustavo A. R. Silva's avatar
      xattr.h: Replace zero-length array with flexible-array member · 43951585
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      43951585
    • Gustavo A. R. Silva's avatar
      uapi: linux: fiemap.h: Replace zero-length array with flexible-array member · 6e88abb8
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      6e88abb8
    • Gustavo A. R. Silva's avatar
      uapi: linux: dlm_device.h: Replace zero-length array with flexible-array member · d6cdad87
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      d6cdad87
    • Gustavo A. R. Silva's avatar
      tpm_eventlog.h: Replace zero-length array with flexible-array member · 06ccf63d
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      06ccf63d
    • Gustavo A. R. Silva's avatar
      ti_wilink_st.h: Replace zero-length array with flexible-array member · 4ea19ecf
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      4ea19ecf
    • Gustavo A. R. Silva's avatar
      swap.h: Replace zero-length array with flexible-array member · 16c3380f
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      16c3380f
    • Gustavo A. R. Silva's avatar
      skbuff.h: Replace zero-length array with flexible-array member · 5c91aa1d
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      5c91aa1d
    • Gustavo A. R. Silva's avatar
      sched: topology.h: Replace zero-length array with flexible-array member · fe946db6
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      fe946db6
    • Gustavo A. R. Silva's avatar
      rslib.h: Replace zero-length array with flexible-array member · 9dd8bb5f
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      9dd8bb5f
    • Gustavo A. R. Silva's avatar
      rio.h: Replace zero-length array with flexible-array member · a1c4b924
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      a1c4b924
    • Gustavo A. R. Silva's avatar
      posix_acl.h: Replace zero-length array with flexible-array member · 70f1451e
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      70f1451e