<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/uapi, branch v6.6.40</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.40</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.40'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-07-11T10:49:20+00:00</updated>
<entry>
<title>connector: Fix invalid conversion in cn_proc.h</title>
<updated>2024-07-11T10:49:20+00:00</updated>
<author>
<name>Matt Jan</name>
<email>zoo868e@gmail.com</email>
</author>
<published>2024-05-14T04:10:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9258d795978f398ecf2d222a8388cff81d37d34d'/>
<id>urn:sha1:9258d795978f398ecf2d222a8388cff81d37d34d</id>
<content type='text'>
[ Upstream commit 06e785aeb9ea8a43d0a3967c1ba6e69d758e82d4 ]

The implicit conversion from unsigned int to enum
proc_cn_event is invalid, so explicitly cast it
for compilation in a C++ compiler.
/usr/include/linux/cn_proc.h: In function 'proc_cn_event valid_event(proc_cn_event)':
/usr/include/linux/cn_proc.h:72:17: error: invalid conversion from 'unsigned int' to 'proc_cn_event' [-fpermissive]
   72 |         ev_type &amp;= PROC_EVENT_ALL;
      |                 ^
      |                 |
      |                 unsigned int

Signed-off-by: Matt Jan &lt;zoo868e@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>syscalls: fix compat_sys_io_pgetevents_time64 usage</title>
<updated>2024-07-05T07:34:04+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-06-20T12:16:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e04886b50c3e27464a6fe81c7717687a85d3e8fa'/>
<id>urn:sha1:e04886b50c3e27464a6fe81c7717687a85d3e8fa</id>
<content type='text'>
commit d3882564a77c21eb746ba5364f3fa89b88de3d61 upstream.

Using sys_io_pgetevents() as the entry point for compat mode tasks
works almost correctly, but misses the sign extension for the min_nr
and nr arguments.

This was addressed on parisc by switching to
compat_sys_io_pgetevents_time64() in commit 6431e92fc827 ("parisc:
io_pgetevents_time64() needs compat syscall in 32-bit compat mode"),
as well as by using more sophisticated system call wrappers on x86 and
s390. However, arm64, mips, powerpc, sparc and riscv still have the
same bug.

Change all of them over to use compat_sys_io_pgetevents_time64()
like parisc already does. This was clearly the intention when the
function was originally added, but it got hooked up incorrectly in
the tables.

Cc: stable@vger.kernel.org
Fixes: 48166e6ea47d ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")
Acked-by: Heiko Carstens &lt;hca@linux.ibm.com&gt; # s390
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations</title>
<updated>2024-06-12T09:12:45+00:00</updated>
<author>
<name>Mohamed Ahmed</name>
<email>mohamedahmedegypt2001@gmail.com</email>
</author>
<published>2024-05-09T20:43:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3652ac87c993d79b1640d7b8d2f8fea49b28d1e6'/>
<id>urn:sha1:3652ac87c993d79b1640d7b8d2f8fea49b28d1e6</id>
<content type='text'>
[ Upstream commit aed9a1a4f7106ff99a882ad06318cebfa71016a2 ]

Allow PTE kind and tile mode on BO create with VM_BIND, and add a
GETPARAM to indicate this change. This is needed to support modifiers in
NVK and ensure correctness when dealing with the nouveau GL driver.

The userspace modifiers implementation this is for can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795

Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Signed-off-by: Mohamed Ahmed &lt;mohamedahmedegypt2001@gmail.com&gt;
Reviewed-by: Faith Ekstrand &lt;faith.ekstrand@collabora.com&gt;
Signed-off-by: Danilo Krummrich &lt;dakr@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240509204352.7597-1-mohamedahmedegypt2001@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nouveau: add an ioctl to report vram usage</title>
<updated>2024-06-12T09:12:45+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2024-01-24T04:24:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6446c1ca2dd2ee5485cd27b1ee4b5fb70f83aacb'/>
<id>urn:sha1:6446c1ca2dd2ee5485cd27b1ee4b5fb70f83aacb</id>
<content type='text'>
[ Upstream commit 72fa02fdf83306c52bc1eede28359e3fa32a151a ]

This reports the currently used vram allocations.

userspace using this has been proposed for nvk, but
it's a rather trivial uapi addition.

Reviewed-by: Faith Ekstrand &lt;faith.ekstrand@collabora.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Stable-dep-of: aed9a1a4f710 ("drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nouveau: add an ioctl to return vram bar size.</title>
<updated>2024-06-12T09:12:45+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2024-01-24T03:50:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=929eaf32dde42857cae6cd0e42eb789d15dfe003'/>
<id>urn:sha1:929eaf32dde42857cae6cd0e42eb789d15dfe003</id>
<content type='text'>
[ Upstream commit 3f4d8aac6e768c2215ce68275256971c2f54f0c8 ]

This returns the BAR resources size so userspace can make
decisions based on rebar support.

userspace using this has been proposed for nvk, but
it's a rather trivial uapi addition.

Reviewed-by: Faith Ekstrand &lt;faith.ekstrand@collabora.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Stable-dep-of: aed9a1a4f710 ("drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tracing/user_events: Allow events to persist for perfmon_capable users</title>
<updated>2024-06-12T09:12:11+00:00</updated>
<author>
<name>Beau Belgrave</name>
<email>beaub@linux.microsoft.com</email>
</author>
<published>2023-09-12T18:07:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2fc3d0ac097b7f3a1b70866d2b5d44ed9da53f8f'/>
<id>urn:sha1:2fc3d0ac097b7f3a1b70866d2b5d44ed9da53f8f</id>
<content type='text'>
[ Upstream commit 5dbd04eddb2c0841d1b3930e0a9944a2343c9cac ]

There are several scenarios that have come up where having a user_event
persist even if the process that registered it exits. The main one is
having a daemon create events on bootup that shouldn't get deleted if
the daemon has to exit or reload. Another is within OpenTelemetry
exporters, they wish to potentially check if a user_event exists on the
system to determine if exporting the data out should occur. The
user_event in this case must exist even in the absence of the owning
process running (such as the above daemon case).

Expose the previously internal flag USER_EVENT_REG_PERSIST to user
processes. Upon register or delete of events with this flag, ensure the
user is perfmon_capable to prevent random user processes with access to
tracefs from creating events that persist after exit.

Link: https://lkml.kernel.org/r/20230912180704.1284-2-beaub@linux.microsoft.com

Signed-off-by: Beau Belgrave &lt;beaub@linux.microsoft.com&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Stable-dep-of: bd125a084091 ("tracing/user_events: Fix non-spaced field matching")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/bnxt_re: Adds MSN table capability for Gen P7 adapters</title>
<updated>2024-06-12T09:12:10+00:00</updated>
<author>
<name>Selvin Xavier</name>
<email>selvin.xavier@broadcom.com</email>
</author>
<published>2023-12-07T10:47:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29feea56dedfb0a56e38ffc9c0b3ad5b6f66cd99'/>
<id>urn:sha1:29feea56dedfb0a56e38ffc9c0b3ad5b6f66cd99</id>
<content type='text'>
[ Upstream commit 07f830ae4913d0b986c8c0ff88a7d597948b9bd8 ]

GenP7 HW expects an MSN table instead of PSN table. Check
for the HW retransmission capability and populate the MSN
table if HW retansmission is supported.

Signed-off-by: Damodharam Ammepalli &lt;damodharam.ammepalli@broadcom.com&gt;
Signed-off-by: Selvin Xavier &lt;selvin.xavier@broadcom.com&gt;
Link: https://lore.kernel.org/r/1701946060-13931-7-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Stable-dep-of: 78cfd17142ef ("bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/bnxt_re: Remove roundup_pow_of_two depth for all hardware queue resources</title>
<updated>2024-06-12T09:12:10+00:00</updated>
<author>
<name>Chandramohan Akula</name>
<email>chandramohan.akula@broadcom.com</email>
</author>
<published>2023-10-23T14:03:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e300b1b95c9352d78c0192d34122f9cca4b004d4'/>
<id>urn:sha1:e300b1b95c9352d78c0192d34122f9cca4b004d4</id>
<content type='text'>
[ Upstream commit 48f996d4adf15a0a0af8b8184d3ec6042a684ea4 ]

Rounding up the queue depth to power of two is not a hardware requirement.
In order to optimize the per connection memory usage, removing drivers
implementation which round up to the queue depths to the power of 2.

Implements a mask to maintain backward compatibility with older
library.

Signed-off-by: Chandramohan Akula &lt;chandramohan.akula@broadcom.com&gt;
Signed-off-by: Selvin Xavier &lt;selvin.xavier@broadcom.com&gt;
Link: https://lore.kernel.org/r/1698069803-1787-3-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Stable-dep-of: 78cfd17142ef ("bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: HCI: Remove HCI_AMP support</title>
<updated>2024-06-12T09:11:55+00:00</updated>
<author>
<name>Luiz Augusto von Dentz</name>
<email>luiz.von.dentz@intel.com</email>
</author>
<published>2024-05-06T22:33:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5af2e235b0d5b797e9531a00c50058319130e156'/>
<id>urn:sha1:5af2e235b0d5b797e9531a00c50058319130e156</id>
<content type='text'>
[ Upstream commit 84a4bb6548a29326564f0e659fb8064503ecc1c7 ]

Since BT_HS has been remove HCI_AMP controllers no longer has any use so
remove it along with the capability of creating AMP controllers.

Since we no longer need to differentiate between AMP and Primary
controllers, as only HCI_PRIMARY is left, this also remove
hdev-&gt;dev_type altogether.

Fixes: e7b02296fb40 ("Bluetooth: Remove BT_HS")
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpf: Pack struct bpf_fib_lookup</title>
<updated>2024-06-12T09:11:38+00:00</updated>
<author>
<name>Anton Protopopov</name>
<email>aspsk@isovalent.com</email>
</author>
<published>2024-04-03T12:33:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7a7d4237e338061616ad6cdb3a3f08ad391ca904'/>
<id>urn:sha1:7a7d4237e338061616ad6cdb3a3f08ad391ca904</id>
<content type='text'>
[ Upstream commit f91717007217d975aa975ddabd91ae1a107b9bff ]

The struct bpf_fib_lookup is supposed to be of size 64. A recent commit
59b418c7063d ("bpf: Add a check for struct bpf_fib_lookup size") added
a static assertion to check this property so that future changes to the
structure will not accidentally break this assumption.

As it immediately turned out, on some 32-bit arm systems, when AEABI=n,
the total size of the structure was equal to 68, see [1]. This happened
because the bpf_fib_lookup structure contains a union of two 16-bit
fields:

    union {
            __u16 tot_len;
            __u16 mtu_result;
    };

which was supposed to compile to a 16-bit-aligned 16-bit field. On the
aforementioned setups it was instead both aligned and padded to 32-bits.

Declare this inner union as __attribute__((packed, aligned(2))) such
that it always is of size 2 and is aligned to 16 bits.

  [1] https://lore.kernel.org/all/CA+G9fYtsoP51f-oP_Sp5MOq-Ffv8La2RztNpwvE6+R1VtFiLrw@mail.gmail.com/#t

Reported-by: Naresh Kamboju &lt;naresh.kamboju@linaro.org&gt;
Fixes: e1850ea9bd9e ("bpf: bpf_fib_lookup return MTU value as output when looked up")
Signed-off-by: Anton Protopopov &lt;aspsk@isovalent.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Reviewed-by: Alexander Lobakin &lt;aleksander.lobakin@intel.com&gt;
Acked-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/20240403123303.1452184-1-aspsk@isovalent.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
