<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v4.19.281</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.19.281</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.19.281'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-04-20T10:04:41Z</updated>
<entry>
<title>Linux 4.19.281</title>
<updated>2023-04-20T10:04:41Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-04-20T10:04:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a5b79a58cfc02977cd4d5c1e20454cd98e88f749'/>
<id>urn:sha1:a5b79a58cfc02977cd4d5c1e20454cd98e88f749</id>
<content type='text'>
Link: https://lore.kernel.org/r/20230418120258.713853188@linuxfoundation.org
Tested-by: Chris Paterson (CIP) &lt;chris.paterson2@renesas.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Hulk Robot &lt;hulkrobot@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>arm64: KVM: Fix system register enumeration</title>
<updated>2023-04-20T10:04:41Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2019-04-02T02:28:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=17992d52dd8b8dcabf1100839b6d0e45787a9381'/>
<id>urn:sha1:17992d52dd8b8dcabf1100839b6d0e45787a9381</id>
<content type='text'>
commit 5d8d4af24460d079ecdb190254b14b528add1228 upstream.

The introduction of the SVE registers to userspace started with a
refactoring of the way we expose any register via the ONE_REG
interface.

Unfortunately, this change doesn't exactly behave as expected
if the number of registers is non-zero and consider everything
to be an error. The visible result is that QEMU barfs very early
when creating vcpus.

Make sure we only exit early in case there is an actual error, rather
than a positive number of registers...

Fixes: be25bbb392fa ("KVM: arm64: Factor out core register ID enumeration")
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Takahiro Itazuri &lt;itazur@amazon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST</title>
<updated>2023-04-20T10:04:41Z</updated>
<author>
<name>Dave Martin</name>
<email>Dave.Martin@arm.com</email>
</author>
<published>2019-06-12T12:44:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6f4eb3ca9ec3168a983d352f43fb53679c9826d6'/>
<id>urn:sha1:6f4eb3ca9ec3168a983d352f43fb53679c9826d6</id>
<content type='text'>
commit df205b5c63281e4f32caac22adda18fd68795e80 upstream.

Since commit d26c25a9d19b ("arm64: KVM: Tighten guest core register
access from userspace"), KVM_{GET,SET}_ONE_REG rejects register IDs
that do not correspond to a single underlying architectural register.

KVM_GET_REG_LIST was not changed to match however: instead, it
simply yields a list of 32-bit register IDs that together cover the
whole kvm_regs struct.  This means that if userspace tries to use
the resulting list of IDs directly to drive calls to KVM_*_ONE_REG,
some of those calls will now fail.

This was not the intention.  Instead, iterating KVM_*_ONE_REG over
the list of IDs returned by KVM_GET_REG_LIST should be guaranteed
to work.

This patch fixes the problem by splitting validate_core_offset()
into a backend core_reg_size_from_offset() which does all of the
work except for checking that the size field in the register ID
matches, and kvm_arm_copy_reg_indices() and num_core_regs() are
converted to use this to enumerate the valid offsets.

kvm_arm_copy_reg_indices() now also sets the register ID size field
appropriately based on the value returned, so the register ID
supplied to userspace is fully qualified for use with the register
access ioctls.

Cc: stable@vger.kernel.org
Fixes: d26c25a9d19b ("arm64: KVM: Tighten guest core register access from userspace")
Signed-off-by: Dave Martin &lt;Dave.Martin@arm.com&gt;
Reviewed-by: Andrew Jones &lt;drjones@redhat.com&gt;
Tested-by: Andrew Jones &lt;drjones@redhat.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Takahiro Itazuri &lt;itazur@amazon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Factor out core register ID enumeration</title>
<updated>2023-04-20T10:04:41Z</updated>
<author>
<name>Dave Martin</name>
<email>Dave.Martin@arm.com</email>
</author>
<published>2019-03-15T15:47:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e072604cfdc068b75f60be8b4f3fc39b1d082f65'/>
<id>urn:sha1:e072604cfdc068b75f60be8b4f3fc39b1d082f65</id>
<content type='text'>
commit be25bbb392fad3a721d6d21b78639b60612b5439 upstream.

In preparation for adding logic to filter out some KVM_REG_ARM_CORE
registers from the KVM_GET_REG_LIST output, this patch factors out
the core register enumeration into a separate function and rebuilds
num_core_regs() on top of it.

This may be a little more expensive (depending on how good a job
the compiler does of specialising the code), but KVM_GET_REG_LIST
is not a hot path.

This will make it easier to consolidate ID filtering code in one
place.

No functional change.

Signed-off-by: Dave Martin &lt;Dave.Martin@arm.com&gt;
Reviewed-by: Julien Thierry &lt;julien.thierry@arm.com&gt;
Tested-by: zhang.lei &lt;zhang.lei@jp.fujitsu.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Takahiro Itazuri &lt;itazur@amazon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: nVMX: add missing consistency checks for CR0 and CR4</title>
<updated>2023-04-20T10:04:41Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2023-03-10T16:10:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=495adb06518bb10f50e1aa1a1dbd5daa47d118f2'/>
<id>urn:sha1:495adb06518bb10f50e1aa1a1dbd5daa47d118f2</id>
<content type='text'>
commit 112e66017bff7f2837030f34c2bc19501e9212d5 upstream.

The effective values of the guest CR0 and CR4 registers may differ from
those included in the VMCS12.  In particular, disabling EPT forces
CR4.PAE=1 and disabling unrestricted guest mode forces CR0.PG=CR0.PE=1.

Therefore, checks on these bits cannot be delegated to the processor
and must be performed by KVM.

Reported-by: Reima ISHII &lt;ishiir@g.ecc.u-tokyo.ac.jp&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
[OP: drop CC() macro calls, as tracing is not implemented in 4.19]
[OP: adjust "return -EINVAL" -&gt; "return 1" to match current return logic]
Signed-off-by: Ovidiu Panait &lt;ovidiu.panait@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>coresight-etm4: Fix for() loop drvdata-&gt;nr_addr_cmp range bug</title>
<updated>2023-04-20T10:04:41Z</updated>
<author>
<name>Steve Clevenger</name>
<email>scclevenger@os.amperecomputing.com</email>
</author>
<published>2023-02-27T23:54:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=08096e5355115698b92ab74e9f2df68694011c1d'/>
<id>urn:sha1:08096e5355115698b92ab74e9f2df68694011c1d</id>
<content type='text'>
commit bf84937e882009075f57fd213836256fc65d96bc upstream.

In etm4_enable_hw, fix for() loop range to represent address comparator pairs.

Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver")
Cc: stable@vger.kernel.org
Signed-off-by: Steve Clevenger &lt;scclevenger@os.amperecomputing.com&gt;
Reviewed-by: James Clark &lt;james.clark@arm.com&gt;
Signed-off-by: Suzuki K Poulose &lt;suzuki.poulose@arm.com&gt;
Link: https://lore.kernel.org/r/4a4ee61ce8ef402615a4528b21a051de3444fb7b.1677540079.git.scclevenger@os.amperecomputing.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>watchdog: sbsa_wdog: Make sure the timeout programming is within the limits</title>
<updated>2023-04-20T10:04:41Z</updated>
<author>
<name>George Cherian</name>
<email>george.cherian@marvell.com</email>
</author>
<published>2023-02-09T02:11:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8e39a6239d3edd3232d7f1c7a994bd60539fa3fa'/>
<id>urn:sha1:8e39a6239d3edd3232d7f1c7a994bd60539fa3fa</id>
<content type='text'>
commit 000987a38b53c172f435142a4026dd71378ca464 upstream.

Make sure to honour the max_hw_heartbeat_ms while programming the timeout
value to WOR. Clamp the timeout passed to sbsa_gwdt_set_timeout() to
make sure the programmed value is within the permissible range.

Fixes: abd3ac7902fb ("watchdog: sbsa: Support architecture version 1")

Signed-off-by: George Cherian &lt;george.cherian@marvell.com&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Link: https://lore.kernel.org/r/20230209021117.1512097-1-george.cherian@marvell.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Wim Van Sebroeck &lt;wim@linux-watchdog.org&gt;
Signed-off-by: Tyler Hicks (Microsoft) &lt;code@tyhicks.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cgroup/cpuset: Wake up cpuset_attach_wq tasks in cpuset_cancel_attach()</title>
<updated>2023-04-20T10:04:40Z</updated>
<author>
<name>Waiman Long</name>
<email>longman@redhat.com</email>
</author>
<published>2023-04-11T13:35:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=30e138e23f43f566b6df87bba51e4d97930671fd'/>
<id>urn:sha1:30e138e23f43f566b6df87bba51e4d97930671fd</id>
<content type='text'>
commit ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 upstream.

After a successful cpuset_can_attach() call which increments the
attach_in_progress flag, either cpuset_cancel_attach() or cpuset_attach()
will be called later. In cpuset_attach(), tasks in cpuset_attach_wq,
if present, will be woken up at the end. That is not the case in
cpuset_cancel_attach(). So missed wakeup is possible if the attach
operation is somehow cancelled. Fix that by doing the wakeup in
cpuset_cancel_attach() as well.

Fixes: e44193d39e8d ("cpuset: let hotplug propagation work wait for task attaching")
Signed-off-by: Waiman Long &lt;longman@redhat.com&gt;
Reviewed-by: Michal Koutný &lt;mkoutny@suse.com&gt;
Cc: stable@vger.kernel.org # v3.11+
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ubi: Fix deadlock caused by recursively holding work_sem</title>
<updated>2023-04-20T10:04:40Z</updated>
<author>
<name>ZhaoLong Wang</name>
<email>wangzhaolong1@huawei.com</email>
</author>
<published>2023-03-04T01:41:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=24c01263ef8c650475e5a35f0d030bef61881164'/>
<id>urn:sha1:24c01263ef8c650475e5a35f0d030bef61881164</id>
<content type='text'>
[ Upstream commit f773f0a331d6c41733b17bebbc1b6cae12e016f5 ]

During the processing of the bgt, if the sync_erase() return -EBUSY
or some other error code in __erase_worker(),schedule_erase() called
again lead to the down_read(ubi-&gt;work_sem) hold twice and may get
block by down_write(ubi-&gt;work_sem) in ubi_update_fastmap(),
which cause deadlock.

          ubi bgt                        other task
 do_work
  down_read(&amp;ubi-&gt;work_sem)          ubi_update_fastmap
  erase_worker                         # Blocked by down_read
   __erase_worker                      down_write(&amp;ubi-&gt;work_sem)
    schedule_erase
     schedule_ubi_work
      down_read(&amp;ubi-&gt;work_sem)

Fix this by changing input parameter @nested of the schedule_erase() to
'true' to avoid recursively acquiring the down_read(&amp;ubi-&gt;work_sem).

Also, fix the incorrect comment about @nested parameter of the
schedule_erase() because when down_write(ubi-&gt;work_sem) is held, the
@nested is also need be true.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217093
Fixes: 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()")
Signed-off-by: ZhaoLong Wang &lt;wangzhaolong1@huawei.com&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mtd: ubi: wl: Fix a couple of kernel-doc issues</title>
<updated>2023-04-20T10:04:40Z</updated>
<author>
<name>Lee Jones</name>
<email>lee.jones@linaro.org</email>
</author>
<published>2020-11-09T18:21:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6aee9f324dcd763fa47c4f32182a9ec4d1e429da'/>
<id>urn:sha1:6aee9f324dcd763fa47c4f32182a9ec4d1e429da</id>
<content type='text'>
[ Upstream commit ab4e4de9fd8b469823a645f05f2c142e9270b012 ]

Fixes the following W=1 kernel build warning(s):

 drivers/mtd/ubi/wl.c:584: warning: Function parameter or member 'nested' not described in 'schedule_erase'
 drivers/mtd/ubi/wl.c:1075: warning: Excess function parameter 'shutdown' description in '__erase_worker'

Cc: Richard Weinberger &lt;richard@nod.at&gt;
Cc: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Cc: Vignesh Raghavendra &lt;vigneshr@ti.com&gt;
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-13-lee.jones@linaro.org
Stable-dep-of: f773f0a331d6 ("ubi: Fix deadlock caused by recursively holding work_sem")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
