1. 30 Apr, 2020 1 commit
  2. 28 Apr, 2020 3 commits
    • Trond Myklebust's avatar
      Merge tag 'nfs-rdma-for-5.7-2' of git://git.linux-nfs.org/projects/anna/linux-nfs · 8e2912c7
      Trond Myklebust authored
      NFSoRDMA Client Fixes for Linux 5.7
      
      Bugfixes:
      - Restore wake-up-all to rpcrdma_cm_event_handler()
        - Otherwise the client won't respond to server disconnect requests
      - Fix tracepoint use-after-free race
      - Fix usage of xdr_stream_encode_item_{present, absent}
        - These functions return a size on success, and not 0
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      8e2912c7
    • Olga Kornievskaia's avatar
      NFSv4.1: fix handling of backchannel binding in BIND_CONN_TO_SESSION · dff58530
      Olga Kornievskaia authored
      Currently, if the client sends BIND_CONN_TO_SESSION with
      NFS4_CDFC4_FORE_OR_BOTH but only gets NFS4_CDFS4_FORE back it ignores
      that it wasn't able to enable a backchannel.
      
      To make sure, the client sends BIND_CONN_TO_SESSION as the first
      operation on the connections (ie., no other session compounds haven't
      been sent before), and if the client's request to bind the backchannel
      is not satisfied, then reset the connection and retry.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      dff58530
    • NeilBrown's avatar
      SUNRPC: defer slow parts of rpc_free_client() to a workqueue. · 7c4310ff
      NeilBrown authored
      The rpciod workqueue is on the write-out path for freeing dirty memory,
      so it is important that it never block waiting for memory to be
      allocated - this can lead to a deadlock.
      
      rpc_execute() - which is often called by an rpciod work item - calls
      rcp_task_release_client() which can lead to rpc_free_client().
      
      rpc_free_client() makes two calls which could potentially block wating
      for memory allocation.
      
      rpc_clnt_debugfs_unregister() calls into debugfs and will block while
      any of the debugfs files are being accessed.  In particular it can block
      while any of the 'open' methods are being called and all of these use
      malloc for one thing or another.  So this can deadlock if the memory
      allocation waits for NFS to complete some writes via rpciod.
      
      rpc_clnt_remove_pipedir() can take the inode_lock() and while it isn't
      obvious that memory allocations can happen while the lock it held, it is
      safer to assume they might and to not let rpciod call
      rpc_clnt_remove_pipedir().
      
      So this patch moves these two calls (together with the final kfree() and
      rpciod_down()) into a work-item to be run from the system work-queue.
      rpciod can continue its important work, and the final stages of the free
      can happen whenever they happen.
      
      I have seen this deadlock on a 4.12 based kernel where debugfs used
      synchronize_srcu() when removing objects.  synchronize_srcu() requires a
      workqueue and there were no free workther threads and none could be
      allocated.  While debugsfs no longer uses SRCU, I believe the deadlock
      is still possible.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      7c4310ff
  3. 25 Apr, 2020 1 commit
  4. 21 Apr, 2020 1 commit
  5. 20 Apr, 2020 5 commits
  6. 19 Apr, 2020 13 commits
    • Trond Myklebust's avatar
      NFS/pnfs: Ensure that _pnfs_return_layout() waits for layoutreturn completion · 7bcc1058
      Trond Myklebust authored
      We require that any outstanding layout return completes before we can
      free up the inode so that the layout itself can be freed.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      7bcc1058
    • 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
  7. 18 Apr, 2020 16 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
    • Gustavo A. R. Silva's avatar
      platform_data: wilco-ec.h: Replace zero-length array with flexible-array member · 1223f3db
      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>
      1223f3db
    • Gustavo A. R. Silva's avatar
      memcontrol.h: Replace zero-length array with flexible-array member · 307ed94c
      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>
      307ed94c
    • Gustavo A. R. Silva's avatar
      list_lru.h: Replace zero-length array with flexible-array member · 859b4941
      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>
      859b4941
    • Gustavo A. R. Silva's avatar
      lib: cpu_rmap: Replace zero-length array with flexible-array member · 31232272
      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>
      31232272