Skip to content

L
linux
Switch branch/tag
  1. 24 Nov, 2022 1 commit
    • Heiko Carstens's avatar
      s390/crashdump: fix TOD programmable field size · f44e07a8
      Heiko Carstens authored 
      The size of the TOD programmable field was incorrectly increased from
four to eight bytes with commit 1a2c5840 ("s390/dump: cleanup CPU
save area handling").
This leads to an elf notes section NT_S390_TODPREG which has a size of
eight instead of four bytes in case of kdump, however even worse is
that the contents is incorrect: it is supposed to contain only the
contents of the TOD programmable field, but in fact contains a mix of
the TOD programmable field (32 bit upper bits) and parts of the CPU
timer register (lower 32 bits).

Fix this by simply changing the size of the todpreg field within the
save area structure. This will implicitly also fix the size of the
corresponding elf notes sections.

This also gets rid of this compile time warning:

in function ‘fortify_memcpy_chk’,
    inlined from ‘save_area_add_regs’ at arch/s390/kernel/crash_dump.c:99:2:
./include/linux/fortify-string.h:413:25: error: call to ‘__read_overflow2_field’
   declared with attribute warning: detected read beyond size of field
   (2nd parameter); maybe use struct_group()? [-Werror=attribute-warning]
  413 |                         __read_overflow2_field(q_size_field, size);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fixes: 1a2c5840 ("s390/dump: cleanup CPU save area handling")
Reviewed-by: default avatarChristian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      f44e07a8
  3. 23 Nov, 2022 1 commit
  5. 16 Nov, 2022 2 commits
    • Vasily Gorbik's avatar
      s390: avoid using global register for current_stack_pointer · e3c11025
      Vasily Gorbik authored 
      Commit 30de14b1 ("s390: current_stack_pointer shouldn't be a
function") made current_stack_pointer a global register variable like
on many other architectures. Unfortunately on s390 it uncovers old
gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87
("S/390: Fix PR89775. Stackpointer save/restore instructions removed")]
and backported to gcc-8.4 and later. Due to this bug gcc versions prior
to 8.4 generate broken code which leads to stack corruptions.

Current minimal gcc version required to build the kernel is declared
as 5.1. It is not possible to fix all old gcc versions, so work
around this problem by avoiding using global register variable for
current_stack_pointer.

Fixes: 30de14b1 ("s390: current_stack_pointer shouldn't be a function")
Reviewed-by: default avatarHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
Signed-off-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      e3c11025
    • Gerald Schaefer's avatar
      s390/dcssblk: fix deadlock when adding a DCSS · a41a11b4
      Gerald Schaefer authored 
      After the rework from commit 1ebe2e5f ("block: remove
GENHD_FL_EXT_DEVT"), when calling device_add_disk(), dcssblk will end up
in disk_scan_partitions(), and not break out early w/o GENHD_FL_NO_PART.
This will trigger implicit open/release via blkdev_get/put_whole()
later. dcssblk_release() will then deadlock on dcssblk_devices_sem
semaphore, which is already held from dcssblk_add_store() when calling
device_add_disk().

dcssblk does not support partitions (DCSSBLK_MINORS_PER_DISK == 1), and
never scanned partitions before. Therefore restore the previous
behavior, and explicitly disallow partition scanning by setting the
GENHD_FL_NO_PART flag. This will also prevent this deadlock scenario.

Fixes: 1ebe2e5f ("block: remove GENHD_FL_EXT_DEVT")
Cc: <stable@vger.kernel.org> # 5.17+
Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@linux.ibm.com>
Acked-by: default avatarHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      a41a11b4
  7. 09 Nov, 2022 1 commit
  9. 08 Nov, 2022 3 commits
  11. 02 Nov, 2022 2 commits
  13. 26 Oct, 2022 8 commits
  15. 23 Oct, 2022 9 commits
  17. 22 Oct, 2022 13 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7