<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v6.9.2</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.9.2</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.9.2'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-05-25T14:30:56Z</updated>
<entry>
<title>Linux 6.9.2</title>
<updated>2024-05-25T14:30:56Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2024-05-25T14:30:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c8eef176690851911d8b70d798152e7314b0f7dc'/>
<id>urn:sha1:c8eef176690851911d8b70d798152e7314b0f7dc</id>
<content type='text'>
Link: https://lore.kernel.org/r/20240523130330.386580714@linuxfoundation.org
Tested-by: Mark Brown &lt;broonie@kernel.org&gt;
Tested-by: SeongJae Park &lt;sj@kernel.org&gt;
Tested-by: Ronald Warsow &lt;rwarsow@gmx.de&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Tested-by: Ron Economos &lt;re@w6rz.net&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;
Tested-by: Pascal Ernster &lt;git@hardfalcon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>block: add a partscan sysfs attribute for disks</title>
<updated>2024-05-25T14:30:56Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2024-05-02T13:00:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9ee1c10611b4fc9efd65e8edc97f5c5730ce889d'/>
<id>urn:sha1:9ee1c10611b4fc9efd65e8edc97f5c5730ce889d</id>
<content type='text'>
commit a4217c6740dc64a3eb6815868a9260825e8c68c6 upstream.

Userspace had been unknowingly relying on a non-stable interface of
kernel internals to determine if partition scanning is enabled for a
given disk. Provide a stable interface for this purpose instead.

Cc: stable@vger.kernel.org # 6.3+
Depends-on: 140ce28dd3be ("block: add a disk_has_partscan helper")
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Link: https://lore.kernel.org/linux-block/ZhQJf8mzq_wipkBH@gardel-login/
Link: https://lore.kernel.org/r/20240502130033.1958492-3-hch@lst.de
[axboe: add links and commit message from Keith]
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>block: add a disk_has_partscan helper</title>
<updated>2024-05-25T14:30:56Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2024-05-02T13:00:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=59e0727d444a93a3e6382f63a2c45346c151e27a'/>
<id>urn:sha1:59e0727d444a93a3e6382f63a2c45346c151e27a</id>
<content type='text'>
commit 140ce28dd3bee8e53acc27f123ae474d69ef66f0 upstream.

Add a helper to check if partition scanning is enabled instead of
open coding the check in a few places.  This now always checks for
the hidden flag even if all but one of the callers are never reachable
for hidden gendisks.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Link: https://lore.kernel.org/r/20240502130033.1958492-2-hch@lst.de
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Docs/admin-guide/mm/damon/usage: fix wrong schemes effective quota update command</title>
<updated>2024-05-25T14:30:56Z</updated>
<author>
<name>SeongJae Park</name>
<email>sj@kernel.org</email>
</author>
<published>2024-05-03T18:03:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=50ef147264b708f8ab87ef07715ff7a07d5947a8'/>
<id>urn:sha1:50ef147264b708f8ab87ef07715ff7a07d5947a8</id>
<content type='text'>
commit 14e70e4660d6ecaf503c461f072949ef8758e4a1 upstream.

To update effective size quota of DAMOS schemes on DAMON sysfs file
interface, user should write 'update_schemes_effective_quotas' to the
kdamond 'state' file.  But the document is mistakenly saying the input
string as 'update_schemes_effective_bytes'.  Fix it (s/bytes/quotas/).

Link: https://lkml.kernel.org/r/20240503180318.72798-8-sj@kernel.org
Fixes: a6068d6dfa2f ("Docs/admin-guide/mm/damon/usage: document effective_bytes file")
Signed-off-by: SeongJae Park &lt;sj@kernel.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;	[6.9.x]
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Docs/admin-guide/mm/damon/usage: fix wrong example of DAMOS filter matching sysfs file</title>
<updated>2024-05-25T14:30:56Z</updated>
<author>
<name>SeongJae Park</name>
<email>sj@kernel.org</email>
</author>
<published>2024-05-03T18:03:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=883c84b2b3e61e82e0bb2de70f747f628b007be4'/>
<id>urn:sha1:883c84b2b3e61e82e0bb2de70f747f628b007be4</id>
<content type='text'>
commit da2a061888883e067e8e649d086df35c92c760a7 upstream.

The example usage of DAMOS filter sysfs files, specifically the part of
'matching' file writing for memcg type filter, is wrong.  The intention is
to exclude pages of a memcg that already getting enough care from a given
scheme, but the example is setting the filter to apply the scheme to only
the pages of the memcg.  Fix it.

Link: https://lkml.kernel.org/r/20240503180318.72798-7-sj@kernel.org
Fixes: 9b7f9322a530 ("Docs/admin-guide/mm/damon/usage: document DAMOS filters of sysfs")
Closes: https://lore.kernel.org/r/20240317191358.97578-1-sj@kernel.org
Signed-off-by: SeongJae Park &lt;sj@kernel.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;	[6.3.x]
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>docs: kernel_include.py: Cope with docutils 0.21</title>
<updated>2024-05-25T14:30:56Z</updated>
<author>
<name>Akira Yokosawa</name>
<email>akiyks@gmail.com</email>
</author>
<published>2024-05-01T03:16:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=387f3d34e847eeb298f0acfc53309d1185a353de'/>
<id>urn:sha1:387f3d34e847eeb298f0acfc53309d1185a353de</id>
<content type='text'>
commit d43ddd5c91802a46354fa4c4381416ef760676e2 upstream.

Running "make htmldocs" on a newly installed Sphinx 7.3.7 ends up in
a build error:

    Sphinx parallel build error:
    AttributeError: module 'docutils.nodes' has no attribute 'reprunicode'

docutils 0.21 has removed nodes.reprunicode, quote from release note [1]:

  * Removed objects:

    docutils.nodes.reprunicode, docutils.nodes.ensure_str()
        Python 2 compatibility hacks

Sphinx 7.3.0 supports docutils 0.21 [2]:

kernel_include.py, whose origin is misc.py of docutils, uses reprunicode.

Upstream docutils removed the offending line from the corresponding file
(docutils/docutils/parsers/rst/directives/misc.py) in January 2022.
Quoting the changelog [3]:

    Deprecate `nodes.reprunicode` and `nodes.ensure_str()`.

    Drop uses of the deprecated constructs (not required with Python 3).

Do the same for kernel_include.py.

Tested against:
  - Sphinx 2.4.5 (docutils 0.17.1)
  - Sphinx 3.4.3 (docutils 0.17.1)
  - Sphinx 5.3.0 (docutils 0.18.1)
  - Sphinx 6.2.1 (docutils 0.19)
  - Sphinx 7.2.6 (docutils 0.20.1)
  - Sphinx 7.3.7 (docutils 0.21.2)

Link: http://www.docutils.org/RELEASE-NOTES.html#release-0-21-2024-04-09 [1]
Link: https://www.sphinx-doc.org/en/master/changes.html#release-7-3-0-released-apr-16-2024 [2]
Link: https://github.com/docutils/docutils/commit/c8471ce47a24 [3]
Signed-off-by: Akira Yokosawa &lt;akiyks@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
Link: https://lore.kernel.org/r/faf5fa45-2a9d-4573-9d2e-3930bdc1ed65@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET</title>
<updated>2024-05-25T14:30:55Z</updated>
<author>
<name>Thomas Weißschuh</name>
<email>linux@weissschuh.net</email>
</author>
<published>2024-04-23T10:34:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=86b808ff187473674bb91a9d5abd0ad018b77cc4'/>
<id>urn:sha1:86b808ff187473674bb91a9d5abd0ad018b77cc4</id>
<content type='text'>
commit 8af2d1ab78f2342f8c4c3740ca02d86f0ebfac5a upstream.

sched_core_share_pid() copies the cookie to userspace with
put_user(id, (u64 __user *)uaddr), expecting 64 bits of space.
The "unsigned long" datatype that is documented in core-scheduling.rst
however is only 32 bits large on 32 bit architectures.

Document "unsigned long long" as the correct data type that is always
64bits large.

This matches what the selftest cs_prctl_test.c has been doing all along.

Fixes: 0159bb020ca9 ("Documentation: Add usecases, design and interface for core scheduling")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/util-linux/df7a25a0-7923-4f8b-a527-5e6f0064074d@t-8ch.de/
Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Reviewed-by: Chris Hyser &lt;chris.hyser@oracle.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
Link: https://lore.kernel.org/r/20240423-core-scheduling-cookie-v1-1-5753a35f8dfc@weissschuh.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KEYS: trusted: Do not use WARN when encode fails</title>
<updated>2024-05-25T14:30:55Z</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko@kernel.org</email>
</author>
<published>2024-05-13T18:19:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ff91cc12faf798f573dab2abc976c1d5b1862fea'/>
<id>urn:sha1:ff91cc12faf798f573dab2abc976c1d5b1862fea</id>
<content type='text'>
commit 050bf3c793a07f96bd1e2fd62e1447f731ed733b upstream.

When asn1_encode_sequence() fails, WARN is not the correct solution.

1. asn1_encode_sequence() is not an internal function (located
   in lib/asn1_encode.c).
2. Location is known, which makes the stack trace useless.
3. Results a crash if panic_on_warn is set.

It is also noteworthy that the use of WARN is undocumented, and it
should be avoided unless there is a carefully considered rationale to
use it.

Replace WARN with pr_err, and print the return value instead, which is
only useful piece of information.

Cc: stable@vger.kernel.org # v5.13+
Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "media: v4l2-ctrls: show all owned controls in log_status"</title>
<updated>2024-05-25T14:30:55Z</updated>
<author>
<name>Hans Verkuil</name>
<email>hverkuil-cisco@xs4all.nl</email>
</author>
<published>2024-05-10T07:11:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2e0ce54a9c5c7013b1257be044d99cbe7305e9f1'/>
<id>urn:sha1:2e0ce54a9c5c7013b1257be044d99cbe7305e9f1</id>
<content type='text'>
commit eba63df7eb1f95df6bfb67722a35372b6994928d upstream.

This reverts commit 9801b5b28c6929139d6fceeee8d739cc67bb2739.

This patch introduced a potential deadlock scenario:

[Wed May  8 10:02:06 2024]  Possible unsafe locking scenario:

[Wed May  8 10:02:06 2024]        CPU0                    CPU1
[Wed May  8 10:02:06 2024]        ----                    ----
[Wed May  8 10:02:06 2024]   lock(vivid_ctrls:1620:(hdl_vid_cap)-&gt;_lock);
[Wed May  8 10:02:06 2024]                                lock(vivid_ctrls:1608:(hdl_user_vid)-&gt;_lock);
[Wed May  8 10:02:06 2024]                                lock(vivid_ctrls:1620:(hdl_vid_cap)-&gt;_lock);
[Wed May  8 10:02:06 2024]   lock(vivid_ctrls:1608:(hdl_user_vid)-&gt;_lock);

For now just revert.

Fixes: 9801b5b28c69 ("media: v4l2-ctrls: show all owned controls in log_status")
Cc: stable@vger.kernel.org
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>remoteproc: mediatek: Make sure IPI buffer fits in L2TCM</title>
<updated>2024-05-25T14:30:55Z</updated>
<author>
<name>AngeloGioacchino Del Regno</name>
<email>angelogioacchino.delregno@collabora.com</email>
</author>
<published>2024-03-21T08:46:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=36c79eb4845551e9f6d28c663b38ce0ab03b84a9'/>
<id>urn:sha1:36c79eb4845551e9f6d28c663b38ce0ab03b84a9</id>
<content type='text'>
commit 331f91d86f71d0bb89a44217cc0b2a22810bbd42 upstream.

The IPI buffer location is read from the firmware that we load to the
System Companion Processor, and it's not granted that both the SRAM
(L2TCM) size that is defined in the devicetree node is large enough
for that, and while this is especially true for multi-core SCP, it's
still useful to check on single-core variants as well.

Failing to perform this check may make this driver perform R/W
operations out of the L2TCM boundary, resulting (at best) in a
kernel panic.

To fix that, check that the IPI buffer fits, otherwise return a
failure and refuse to boot the relevant SCP core (or the SCP at
all, if this is single core).

Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
Signed-off-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240321084614.45253-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
