1. 21 Sep, 2021 2 commits
  2. 10 Sep, 2021 5 commits
  3. 06 Sep, 2021 3 commits
  4. 04 Sep, 2021 3 commits
  5. 30 Aug, 2021 5 commits
  6. 24 Jul, 2021 5 commits
  7. 23 Jul, 2021 3 commits
  8. 21 Jul, 2021 1 commit
  9. 19 Jul, 2021 4 commits
  10. 05 Jul, 2021 1 commit
  11. 27 Jun, 2021 2 commits
    • Linus Torvalds's avatar
      Linux 5.13 · 62fb9874
      Linus Torvalds authored
      62fb9874
    • Linus Torvalds's avatar
      Revert "signal: Allow tasks to cache one sigqueue struct" · b4b27b9e
      Linus Torvalds authored
      This reverts commits 4bad58eb (and
      399f8dd9, which tried to fix it).
      
      I do not believe these are correct, and I'm about to release 5.13, so am
      reverting them out of an abundance of caution.
      
      The locking is odd, and appears broken.
      
      On the allocation side (in __sigqueue_alloc()), the locking is somewhat
      straightforward: it depends on sighand->siglock.  Since one caller
      doesn't hold that lock, it further then tests 'sigqueue_flags' to avoid
      the case with no locks held.
      
      On the freeing side (in sigqueue_cache_or_free()), there is no locking
      at all, and the logic instead depends on 'current' being a single
      thread, and not able to race with itself.
      
      To make things more exciting, there's also the data race between freeing
      a signal and allocating one, which is handled by using WRITE_ONCE() and
      READ_ONCE(), and being mutually exclusive wrt the initial state (ie
      freeing will only free if the old state was NULL, while allocating will
      obviously only use the value if it was non-NULL, so only one or the
      other will actually act on the value).
      
      However, while the free->alloc paths do seem mutually exclusive thanks
      to just the data value dependency, it's not clear what the memory
      ordering constraints are on it.  Could writes from the previous
      allocation possibly be delayed and seen by the new allocation later,
      causing logical inconsistencies?
      
      So it's all very exciting and unusual.
      
      And in particular, it seems that the freeing side is incorrect in
      depending on "current" being single-threaded.  Yes, 'current' is a
      single thread, but in the presense of asynchronous events even a single
      thread can have data races.
      
      And such asynchronous events can and do happen, with interrupts causing
      signals to be flushed and thus free'd (for example - sending a
      SIGCONT/SIGSTOP can happen from interrupt context, and can flush
      previously queued process control signals).
      
      So regardless of all the other questions about the memory ordering and
      locking for this new cached allocation, the sigqueue_cache_or_free()
      assumptions seem to be fundamentally incorrect.
      
      It may be that people will show me the errors of my ways, and tell me
      why this is all safe after all.  We can reinstate it if so.  But my
      current belief is that the WRITE_ONCE() that sets the cached entry needs
      to be a smp_store_release(), and the READ_ONCE() that finds a cached
      entry needs to be a smp_load_acquire() to handle memory ordering
      correctly.
      
      And the sequence in sigqueue_cache_or_free() would need to either use a
      lock or at least be interrupt-safe some way (perhaps by using something
      like the percpu 'cmpxchg': it doesn't need to be SMP-safe, but like the
      percpu operations it needs to be interrupt-safe).
      
      Fixes: 399f8dd9 ("signal: Prevent sigqueue caching after task got released")
      Fixes: 4bad58eb ("signal: Allow tasks to cache one sigqueue struct")
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Christian Brauner <christian.brauner@ubuntu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b4b27b9e
  12. 26 Jun, 2021 2 commits
  13. 25 Jun, 2021 4 commits
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · e2f527b5
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Two small fixes, both in upper layer drivers (scsi disk and cdrom).
      
        The sd one is fixing a commit changing revalidation that came from the
        block tree a while ago (5.10) and the sr one adds handling of a
        condition we didn't previously handle for manually removed media"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: sd: Call sd_revalidate_disk() for ioctl(BLKRRPART)
        scsi: sr: Return appropriate error code when disk is ejected
      e2f527b5
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 7ce32ac6
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "24 patches, based on 4a09d388.
      
        Subsystems affected by this patch series: mm (thp, vmalloc, hugetlb,
        memory-failure, and pagealloc), nilfs2, kthread, MAINTAINERS, and
        mailmap"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (24 commits)
        mailmap: add Marek's other e-mail address and identity without diacritics
        MAINTAINERS: fix Marek's identity again
        mm/page_alloc: do bulk array bounds check after checking populated elements
        mm/page_alloc: __alloc_pages_bulk(): do bounds check before accessing array
        mm/hwpoison: do not lock page again when me_huge_page() successfully recovers
        mm,hwpoison: return -EHWPOISON to denote that the page has already been poisoned
        mm/memory-failure: use a mutex to avoid memory_failure() races
        mm, futex: fix shared futex pgoff on shmem huge page
        kthread: prevent deadlock when kthread_mod_delayed_work() races with kthread_cancel_delayed_work_sync()
        kthread_worker: split code for canceling the delayed work timer
        mm/vmalloc: unbreak kasan vmalloc support
        KVM: s390: prepare for hugepage vmalloc
        mm/vmalloc: add vmalloc_no_huge
        nilfs2: fix memory leak in nilfs_sysfs_delete_device_group
        mm/thp: another PVMW_SYNC fix in page_vma_mapped_walk()
        mm/thp: fix page_vma_mapped_walk() if THP mapped by ptes
        mm: page_vma_mapped_walk(): get vma_address_end() earlier
        mm: page_vma_mapped_walk(): use goto instead of while (1)
        mm: page_vma_mapped_walk(): add a level of indentation
        mm: page_vma_mapped_walk(): crossing page table boundary
        ...
      7ce32ac6
    • Gleb Fotengauer-Malinovskiy's avatar
      userfaultfd: uapi: fix UFFDIO_CONTINUE ioctl request definition · 808e9df4
      Gleb Fotengauer-Malinovskiy authored
      This ioctl request reads from uffdio_continue structure written by
      userspace which justifies _IOC_WRITE flag.  It also writes back to that
      structure which justifies _IOC_READ flag.
      
      See NOTEs in include/uapi/asm-generic/ioctl.h for more information.
      
      Fixes: f6191471 ("userfaultfd: add UFFDIO_CONTINUE ioctl")
      Signed-off-by: default avatarGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
      Acked-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarAxel Rasmussen <axelrasmussen@google.com>
      Reviewed-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      808e9df4
    • Linus Torvalds's avatar
      Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · 55fcd449
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "Three more driver bugfixes and an annotation fix for the core"
      
      * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        i2c: robotfuzz-osif: fix control-request directions
        i2c: dev: Add __user annotation
        i2c: cp2615: check for allocation failure in cp2615_i2c_recv()
        i2c: i801: Ensure that SMBHSTSTS_INUSE_STS is cleared when leaving i801_access
      55fcd449