<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v5.15.49</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.15.49</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.15.49'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2022-06-22T12:22:05Z</updated>
<entry>
<title>Linux 5.15.49</title>
<updated>2022-06-22T12:22:05Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2022-06-22T12:22:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ee039006371a0b1d64d825a59f0eed8627bb3c91'/>
<id>urn:sha1:ee039006371a0b1d64d825a59f0eed8627bb3c91</id>
<content type='text'>
Link: https://lore.kernel.org/r/20220620124724.380838401@linuxfoundation.org
Tested-by: Fox Chen &lt;foxhlchen@gmail.com&gt;
Tested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Tested-by: Ron Economos &lt;re@w6rz.net&gt;
Tested-by: Sudip Mukherjee &lt;sudip.mukherjee@codethink.co.uk&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>clk: imx8mp: fix usb_root_clk parent</title>
<updated>2022-06-22T12:22:05Z</updated>
<author>
<name>Peng Fan</name>
<email>peng.fan@nxp.com</email>
</author>
<published>2022-05-07T12:54:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c5559147766c6de7ded2db62b8aeaa579c66750b'/>
<id>urn:sha1:c5559147766c6de7ded2db62b8aeaa579c66750b</id>
<content type='text'>
commit cf7f3f4fa9e57b8e9f594823e77e6cbb0ce2b254 upstream.

According to reference mannual CCGR77(usb) sources from hsio_axi, fix
it.

Fixes: 9c140d9926761 ("clk: imx: Add support for i.MX8MP clock driver")
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Reviewed-by: Abel Vesa &lt;abel.vesa@nxp.com&gt;
Link: https://lore.kernel.org/r/20220507125430.793287-1-peng.fan@oss.nxp.com
Signed-off-by: Abel Vesa &lt;abel.vesa@nxp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>powerpc/book3e: get rid of #include &lt;generated/compile.h&gt;</title>
<updated>2022-06-22T12:22:05Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2022-06-04T08:50:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d807e0dfb47118dd4fd8add70b8cb071d0d3974b'/>
<id>urn:sha1:d807e0dfb47118dd4fd8add70b8cb071d0d3974b</id>
<content type='text'>
commit 7ad4bd887d27c6b6ffbef216f19c19f8fe2b8f52 upstream.

You cannot include &lt;generated/compile.h&gt; here because it is generated
in init/Makefile but there is no guarantee that it happens before
arch/powerpc/mm/nohash/kaslr_booke.c is compiled for parallel builds.

The places where you can reliably include &lt;generated/compile.h&gt; are:

  - init/          (because init/Makefile can specify the dependency)
  - arch/*/boot/   (because it is compiled after vmlinux)

Commit f231e4333312 ("hexagon: get rid of #include &lt;generated/compile.h&gt;")
fixed the last breakage at that time, but powerpc re-added this.

&lt;generated/compile.h&gt; was unneeded because 'build_str' is almost the
same as 'linux_banner' defined in init/version.c

Let's copy the solution from MIPS.
(get_random_boot() in arch/mips/kernel/relocate.c)

Fixes: 6a38ea1d7b94 ("powerpc/fsl_booke/32: randomize the kernel image offset")
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Acked-by: Scott Wood &lt;oss@buserror.net&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220604085050.4078927-1-masahiroy@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>virtio-pci: Remove wrong address verification in vp_del_vqs()</title>
<updated>2022-06-22T12:22:05Z</updated>
<author>
<name>Murilo Opsfelder Araujo</name>
<email>muriloo@linux.ibm.com</email>
</author>
<published>2022-04-15T02:30:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=870179c053ce61760c8b1571dfb6d04efa0387dd'/>
<id>urn:sha1:870179c053ce61760c8b1571dfb6d04efa0387dd</id>
<content type='text'>
commit 7e415282b41bf0d15c6e0fe268f822d9b083f2f7 upstream.

GCC 12 enhanced -Waddress when comparing array address to null [0],
which warns:

    drivers/virtio/virtio_pci_common.c: In function ‘vp_del_vqs’:
    drivers/virtio/virtio_pci_common.c:257:29: warning: the comparison will always evaluate as ‘true’ for the pointer operand in ‘vp_dev-&gt;msix_affinity_masks + (sizetype)((long unsigned int)i * 256)’ must not be NULL [-Waddress]
      257 |                         if (vp_dev-&gt;msix_affinity_masks[i])
          |                             ^~~~~~

In fact, the verification is comparing the result of a pointer
arithmetic, the address "msix_affinity_masks + i", which will always
evaluate to true.

Under the hood, free_cpumask_var() calls kfree(), which is safe to pass
NULL, not requiring non-null verification.  So remove the verification
to make compiler happy (happy compiler, happy life).

[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103

Signed-off-by: Murilo Opsfelder Araujo &lt;muriloo@linux.ibm.com&gt;
Message-Id: &lt;20220415023002.49805-1-muriloo@linux.ibm.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Acked-by: Christophe de Dinechin &lt;dinechin@redhat.com&gt;
Cc: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for HP machine</title>
<updated>2022-06-22T12:22:05Z</updated>
<author>
<name>Andy Chi</name>
<email>andy.chi@canonical.com</email>
</author>
<published>2022-05-13T12:16:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c64dfc63c4223c83232e173beaca5f4df91e2952'/>
<id>urn:sha1:c64dfc63c4223c83232e173beaca5f4df91e2952</id>
<content type='text'>
commit 024a7ad9eb4df626ca8c77fef4f67fd0ebd559d2 upstream.

The HP EliteBook 630 is using ALC236 codec which used 0x02 to control mute LED
and 0x01 to control micmute LED. Therefore, add a quirk to make it works.

Signed-off-by: Andy Chi &lt;andy.chi@canonical.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20220513121648.28584-1-andy.chi@canonical.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
[sudip: adjust context]
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Don't read a HW interrupt pending state in user context</title>
<updated>2022-06-22T12:22:05Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-06-07T13:14:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ac0899da0ed19bd7c0c61fb7a0ed2d6155afca4c'/>
<id>urn:sha1:ac0899da0ed19bd7c0c61fb7a0ed2d6155afca4c</id>
<content type='text'>
commit 2cdea19a34c2340b3aa69508804efe4e3750fcec upstream.

Since 5bfa685e62e9 ("KVM: arm64: vgic: Read HW interrupt pending state
from the HW"), we're able to source the pending bit for an interrupt
that is stored either on the physical distributor or on a device.

However, this state is only available when the vcpu is loaded,
and is not intended to be accessed from userspace. Unfortunately,
the GICv2 emulation doesn't provide specific userspace accessors,
and we fallback with the ones that are intended for the guest,
with fatal consequences.

Add a new vgic_uaccess_read_pending() accessor for userspace
to use, build on top of the existing vgic_mmio_read_pending().

Reported-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Tested-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Fixes: 5bfa685e62e9 ("KVM: arm64: vgic: Read HW interrupt pending state from the HW")
Link: https://lore.kernel.org/r/20220607131427.1164881-2-maz@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ext4: add reserved GDT blocks check</title>
<updated>2022-06-22T12:22:05Z</updated>
<author>
<name>Zhang Yi</name>
<email>yi.zhang@huawei.com</email>
</author>
<published>2022-06-01T09:27:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=33b1bba31f4c784d33d2c2517964bdccdc9204cd'/>
<id>urn:sha1:33b1bba31f4c784d33d2c2517964bdccdc9204cd</id>
<content type='text'>
commit b55c3cd102a6f48b90e61c44f7f3dda8c290c694 upstream.

We capture a NULL pointer issue when resizing a corrupt ext4 image which
is freshly clear resize_inode feature (not run e2fsck). It could be
simply reproduced by following steps. The problem is because of the
resize_inode feature was cleared, and it will convert the filesystem to
meta_bg mode in ext4_resize_fs(), but the es-&gt;s_reserved_gdt_blocks was
not reduced to zero, so could we mistakenly call reserve_backup_gdb()
and passing an uninitialized resize_inode to it when adding new group
descriptors.

 mkfs.ext4 /dev/sda 3G
 tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
 mount /dev/sda /mnt
 resize2fs /dev/sda 8G

 ========
 BUG: kernel NULL pointer dereference, address: 0000000000000028
 CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
 ...
 RIP: 0010:ext4_flex_group_add+0xe08/0x2570
 ...
 Call Trace:
  &lt;TASK&gt;
  ext4_resize_fs+0xbec/0x1660
  __ext4_ioctl+0x1749/0x24e0
  ext4_ioctl+0x12/0x20
  __x64_sys_ioctl+0xa6/0x110
  do_syscall_64+0x3b/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7f2dd739617b
 ========

The fix is simple, add a check in ext4_resize_begin() to make sure that
the es-&gt;s_reserved_gdt_blocks is zero when the resize_inode feature is
disabled.

Cc: stable@kernel.org
Signed-off-by: Zhang Yi &lt;yi.zhang@huawei.com&gt;
Reviewed-by: Ritesh Harjani &lt;ritesh.list@gmail.com&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Link: https://lore.kernel.org/r/20220601092717.763694-1-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ext4: make variable "count" signed</title>
<updated>2022-06-22T12:22:05Z</updated>
<author>
<name>Ding Xiang</name>
<email>dingxiang@cmss.chinamobile.com</email>
</author>
<published>2022-05-30T10:00:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4fadac8c73764436a3434acf324b4d213d5bd281'/>
<id>urn:sha1:4fadac8c73764436a3434acf324b4d213d5bd281</id>
<content type='text'>
commit bc75a6eb856cb1507fa907bf6c1eda91b3fef52f upstream.

Since dx_make_map() may return -EFSCORRUPTED now, so change "count" to
be a signed integer so we can correctly check for an error code returned
by dx_make_map().

Fixes: 46c116b920eb ("ext4: verify dir block before splitting it")
Cc: stable@kernel.org
Signed-off-by: Ding Xiang &lt;dingxiang@cmss.chinamobile.com&gt;
Link: https://lore.kernel.org/r/20220530100047.537598-1-dingxiang@cmss.chinamobile.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ext4: fix bug_on ext4_mb_use_inode_pa</title>
<updated>2022-06-22T12:22:04Z</updated>
<author>
<name>Baokun Li</name>
<email>libaokun1@huawei.com</email>
</author>
<published>2022-05-28T11:00:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=90f0f9d45dff0128c0fca0d2358c4153b024afa6'/>
<id>urn:sha1:90f0f9d45dff0128c0fca0d2358c4153b024afa6</id>
<content type='text'>
commit a08f789d2ab5242c07e716baf9a835725046be89 upstream.

Hulk Robot reported a BUG_ON:
==================================================================
kernel BUG at fs/ext4/mballoc.c:3211!
[...]
RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f
[...]
Call Trace:
 ext4_mb_new_blocks+0x9df/0x5d30
 ext4_ext_map_blocks+0x1803/0x4d80
 ext4_map_blocks+0x3a4/0x1a10
 ext4_writepages+0x126d/0x2c30
 do_writepages+0x7f/0x1b0
 __filemap_fdatawrite_range+0x285/0x3b0
 file_write_and_wait_range+0xb1/0x140
 ext4_sync_file+0x1aa/0xca0
 vfs_fsync_range+0xfb/0x260
 do_fsync+0x48/0xa0
[...]
==================================================================

Above issue may happen as follows:
-------------------------------------
do_fsync
 vfs_fsync_range
  ext4_sync_file
   file_write_and_wait_range
    __filemap_fdatawrite_range
     do_writepages
      ext4_writepages
       mpage_map_and_submit_extent
        mpage_map_one_extent
         ext4_map_blocks
          ext4_mb_new_blocks
           ext4_mb_normalize_request
            &gt;&gt;&gt; start + size &lt;= ac-&gt;ac_o_ex.fe_logical
           ext4_mb_regular_allocator
            ext4_mb_simple_scan_group
             ext4_mb_use_best_found
              ext4_mb_new_preallocation
               ext4_mb_new_inode_pa
                ext4_mb_use_inode_pa
                 &gt;&gt;&gt; set ac-&gt;ac_b_ex.fe_len &lt;= 0
           ext4_mb_mark_diskspace_used
            &gt;&gt;&gt; BUG_ON(ac-&gt;ac_b_ex.fe_len &lt;= 0);

we can easily reproduce this problem with the following commands:
	`fallocate -l100M disk`
	`mkfs.ext4 -b 1024 -g 256 disk`
	`mount disk /mnt`
	`fsstress -d /mnt -l 0 -n 1000 -p 1`

The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP.
Therefore, "start + size &lt;= ac-&gt;ac_o_ex.fe_logical" may occur
when the size is truncated. So start should be the start position of
the group where ac_o_ex.fe_logical is located after alignment.
In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP
is very large, the value calculated by start_off is more accurate.

Cc: stable@kernel.org
Fixes: cd648b8a8fd5 ("ext4: trim allocation requests to group size")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Baokun Li &lt;libaokun1@huawei.com&gt;
Reviewed-by: Ritesh Harjani &lt;ritesh.list@gmail.com&gt;
Link: https://lore.kernel.org/r/20220528110017.354175-2-libaokun1@huawei.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ext4: fix super block checksum incorrect after mount</title>
<updated>2022-06-22T12:22:04Z</updated>
<author>
<name>Ye Bin</name>
<email>yebin10@huawei.com</email>
</author>
<published>2022-05-25T01:29:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=38db3b696f27afdb8c1a1a9b1e14f03606b0bb50'/>
<id>urn:sha1:38db3b696f27afdb8c1a1a9b1e14f03606b0bb50</id>
<content type='text'>
commit 9b6641dd95a0c441b277dd72ba22fed8d61f76ad upstream.

We got issue as follows:
[home]# mount  /dev/sda  test
EXT4-fs (sda): warning: mounting fs with errors, running e2fsck is recommended
[home]# dmesg
EXT4-fs (sda): warning: mounting fs with errors, running e2fsck is recommended
EXT4-fs (sda): Errors on filesystem, clearing orphan list.
EXT4-fs (sda): recovery complete
EXT4-fs (sda): mounted filesystem with ordered data mode. Quota mode: none.
[home]# debugfs /dev/sda
debugfs 1.46.5 (30-Dec-2021)
Checksum errors in superblock!  Retrying...

Reason is ext4_orphan_cleanup will reset ‘s_last_orphan’ but not update
super block checksum.

To solve above issue, defer update super block checksum after
ext4_orphan_cleanup.

Signed-off-by: Ye Bin &lt;yebin10@huawei.com&gt;
Cc: stable@kernel.org
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Ritesh Harjani &lt;ritesh.list@gmail.com&gt;
Link: https://lore.kernel.org/r/20220525012904.1604737-1-yebin10@huawei.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
