<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v5.12.19</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.12.19</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.12.19'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2021-07-20T14:02:29Z</updated>
<entry>
<title>Linux 5.12.19</title>
<updated>2021-07-20T14:02:29Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2021-07-20T14:02:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0e6f651912bdd027a6d730b68d6d1c3f4427c0ae'/>
<id>urn:sha1:0e6f651912bdd027a6d730b68d6d1c3f4427c0ae</id>
<content type='text'>
Link: https://lore.kernel.org/r/20210719144942.514164272@linuxfoundation.org
Link: https://lore.kernel.org/r/20210719183557.768945788@linuxfoundation.org
Tested-by: Fox Chen &lt;foxhlchen@gmail.com&gt;
Tested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>seq_file: disallow extremely large seq buffer allocations</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Eric Sandeen</name>
<email>sandeen@redhat.com</email>
</author>
<published>2021-07-13T15:49:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=514b6531b1cbb64199db63bfdb80953d71998cca'/>
<id>urn:sha1:514b6531b1cbb64199db63bfdb80953d71998cca</id>
<content type='text'>
commit 8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b upstream.

There is no reasonable need for a buffer larger than this, and it avoids
int overflow pitfalls.

Fixes: 058504edd026 ("fs/seq_file: fallback to vmalloc allocation")
Suggested-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Reported-by: Qualys Security Advisory &lt;qsa@qualys.com&gt;
Signed-off-by: Eric Sandeen &lt;sandeen@redhat.com&gt;
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: alcor_pci: fix inverted branch condition</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Tong Zhang</name>
<email>ztong0001@gmail.com</email>
</author>
<published>2021-05-22T04:37:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=eeae4230dbf181f318a6604a74106765e0c66248'/>
<id>urn:sha1:eeae4230dbf181f318a6604a74106765e0c66248</id>
<content type='text'>
commit 281e468446994a7672733af2bf941f4110d4a895 upstream.

This patch fixes a trivial mistake that I made in the previous attempt
in fixing the null bridge issue. The branch condition is inverted and we
should call alcor_pci_find_cap_offset() only if bridge is not null.

Reported-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Fixes: 3ce3e45cc333 ("misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge")
Signed-off-by: Tong Zhang &lt;ztong0001@gmail.com&gt;
Link: https://lore.kernel.org/r/20210522043725.602179-1-ztong0001@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2021-06-03T12:33:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8898558843d3311c9225c1216bee8017e1215adb'/>
<id>urn:sha1:8898558843d3311c9225c1216bee8017e1215adb</id>
<content type='text'>
commit 80927822e8b6be46f488524cd7d5fe683de97fc4 upstream.

The "retval" variable needs to be signed for the error handling to work.

Link: https://lore.kernel.org/r/YLjMEAFNxOas1mIp@mwanda
Fixes: 7e26e3ea0287 ("scsi: scsi_dh_alua: Check for negative result value")
Reviewed-by: Martin Wilck &lt;mwilck@suse.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>certs: add 'x509_revocation_list' to gitignore</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-04-26T17:48:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ccc413fa14a9e9fbc8de2c6dbec68e1e20dfae95'/>
<id>urn:sha1:ccc413fa14a9e9fbc8de2c6dbec68e1e20dfae95</id>
<content type='text'>
commit 81f202315856edb75a371f3376aa3a47543c16f0 upstream.

Commit d1f044103dad ("certs: Add ability to preload revocation certs")
created a new generated file for revocation certs, but didn't tell git
to ignore it.  Thus causing unnecessary "git status" noise after a
kernel build with CONFIG_SYSTEM_REVOCATION_LIST enabled.

Add the proper gitignore magic.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2021-06-18T08:01:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b775383355755885b19d2acef977f1ca132e80a3'/>
<id>urn:sha1:b775383355755885b19d2acef977f1ca132e80a3</id>
<content type='text'>
[ Upstream commit fe2535a44904a77615a3af8e8fd7dafb98fb0e1b ]

It's a classic example of memleak, we allocate something, we fail and
never free the resources.

Make sure we free all resources on policy -&gt;init() failures.

Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list")
Tested-by: Vincent Guittot &lt;vincent.guittot@linaro.org&gt;
Reviewed-by: Ionela Voinescu &lt;ionela.voinescu@arm.com&gt;
Tested-by: Qian Cai &lt;quic_qiancai@quicinc.com&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>MIPS: vdso: Invalid GIC access through VDSO</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Martin Fäcknitz</name>
<email>faecknitz@hotsplots.de</email>
</author>
<published>2021-07-05T00:03:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=29cb4c6229201f22f6ce16d6a9fd15f76c001dc0'/>
<id>urn:sha1:29cb4c6229201f22f6ce16d6a9fd15f76c001dc0</id>
<content type='text'>
[ Upstream commit 47ce8527fbba145a7723685bc9a27d9855e06491 ]

Accessing raw timers (currently only CLOCK_MONOTONIC_RAW) through VDSO
doesn't return the correct time when using the GIC as clock source.
The address of the GIC mapped page is in this case not calculated
correctly. The GIC mapped page is calculated from the VDSO data by
subtracting PAGE_SIZE:

  void *get_gic(const struct vdso_data *data) {
    return (void __iomem *)data - PAGE_SIZE;
  }

However, the data pointer is not page aligned for raw clock sources.
This is because the VDSO data for raw clock sources (CS_RAW = 1) is
stored after the VDSO data for coarse clock sources (CS_HRES_COARSE = 0).
Therefore, only the VDSO data for CS_HRES_COARSE is page aligned:

  +--------------------+
  |                    |
  | vd[CS_RAW]         | ---+
  | vd[CS_HRES_COARSE] |    |
  +--------------------+    | -PAGE_SIZE
  |                    |    |
  |  GIC mapped page   | &lt;--+
  |                    |
  +--------------------+

When __arch_get_hw_counter() is called with &amp;vd[CS_RAW], get_gic returns
the wrong address (somewhere inside the GIC mapped page). The GIC counter
values are not returned which results in an invalid time.

Fixes: a7f4df4e21dd ("MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()")
Signed-off-by: Martin Fäcknitz &lt;faecknitz@hotsplots.de&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/irq: remove HAVE_IRQ_EXIT_ON_IRQ_STACK</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Sven Schnelle</name>
<email>svens@linux.ibm.com</email>
</author>
<published>2021-07-06T18:24:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=503d234c8f665c4bfc8a019e360de391d94b2afc'/>
<id>urn:sha1:503d234c8f665c4bfc8a019e360de391d94b2afc</id>
<content type='text'>
[ Upstream commit 0aa4ff7688632a86bdb133fa106f2ccd514b91a7 ]

This is no longer true since we switched to generic entry. The code
switches to the IRQ stack before calling do_IRQ, but switches back
to the kernel stack before calling irq_exit().

Fixes: 56e62a737028 ("s390: convert to generic entry")
Signed-off-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Reviewed-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf script python: Fix buffer size to report iregs in perf script</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Kajol Jain</name>
<email>kjain@linux.ibm.com</email>
</author>
<published>2021-06-28T06:23:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b0626b6f00a5f7781c0311a91a08c91c8ee8253f'/>
<id>urn:sha1:b0626b6f00a5f7781c0311a91a08c91c8ee8253f</id>
<content type='text'>
[ Upstream commit dea8cfcc33695f70f56023b416cf88ae44c8a45a ]

Commit 48a1f565261d2ab1 ("perf script python: Add more PMU fields to
event handler dict") added functionality to report fields like weight,
iregs, uregs etc via perf report.  That commit predefined buffer size to
512 bytes to print those fields.

But in PowerPC, since we added extended regs support in:

  068aeea3773a6f4c ("perf powerpc: Support exposing Performance Monitor Counter SPRs as part of extended regs")
  d735599a069f6936 ("powerpc/perf: Add extended regs support for power10 platform")

Now iregs can carry more bytes of data and this predefined buffer size
can result to data loss in perf script output.

This patch resolves this issue by making the buffer size dynamic, based
on the number of registers needed to print. It also changes the
regs_map() return type from int to void, as it is not being used by the
set_regs_in_dict(), its only caller.

Fixes: 068aeea3773a6f4c ("perf powerpc: Support exposing Performance Monitor Counter SPRs as part of extended regs")
Signed-off-by: Kajol Jain &lt;kjain@linux.ibm.com&gt;
Tested-by: Nageswara R Sastry &lt;rnsastry@linux.ibm.com&gt;
Cc: Athira Jajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Madhavan Srinivasan &lt;maddy@linux.vnet.ibm.com&gt;
Cc: Paul Clarke &lt;pc@us.ibm.com&gt;
Cc: Ravi Bangoria &lt;ravi.bangoria@linux.ibm.com&gt;
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lore.kernel.org/lkml/20210628062341.155839-1-kjain@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mips: disable branch profiling in boot/decompress.o</title>
<updated>2021-07-20T14:02:28Z</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2021-07-04T23:02:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cdef787703bd7e3edfff976d21666ab8daba0690'/>
<id>urn:sha1:cdef787703bd7e3edfff976d21666ab8daba0690</id>
<content type='text'>
[ Upstream commit 97e488073cfca0eea84450169ca4cbfcc64e33e3 ]

Use DISABLE_BRANCH_PROFILING for arch/mips/boot/compressed/decompress.o
to prevent linkage errors.

mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `LZ4_decompress_fast_extDict':
decompress.c:(.text+0x8c): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0xf4): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x200): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x230): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x320): undefined reference to `ftrace_likely_update'
mips64-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0x3f4): more undefined references to `ftrace_likely_update' follow

Fixes: e76e1fdfa8f8 ("lib: add support for LZ4-compressed kernel")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Cc: linux-mips@vger.kernel.org
Cc: Kyungsik Lee &lt;kyungsik.lee@lge.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
