<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/uapi/linux, branch v4.19.310</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.310</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.310'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-03-15T14:48:17+00:00</updated>
<entry>
<title>y2038: rusage: use __kernel_old_timeval</title>
<updated>2024-03-15T14:48:17+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2019-10-25T20:46:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d5e38d6b84d6d21a4f8a4f555a0908b6d9ffe224'/>
<id>urn:sha1:d5e38d6b84d6d21a4f8a4f555a0908b6d9ffe224</id>
<content type='text'>
[ Upstream commit bdd565f817a74b9e30edec108f7cb1dbc762b8a6 ]

There are two 'struct timeval' fields in 'struct rusage'.

Unfortunately the definition of timeval is now ambiguous when used in
user space with a libc that has a 64-bit time_t, and this also changes
the 'rusage' definition in user space in a way that is incompatible with
the system call interface.

While there is no good solution to avoid all ambiguity here, change
the definition in the kernel headers to be compatible with the kernel
ABI, using __kernel_old_timeval as an unambiguous base type.

In previous discussions, there was also a plan to add a replacement
for rusage based on 64-bit timestamps and nanosecond resolution,
i.e. 'struct __kernel_timespec'. I have patches for that as well,
if anyone thinks we should do that.

Reviewed-by: Cyrill Gorcunov &lt;gorcunov@gmail.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Stable-dep-of: daa694e41375 ("getrusage: move thread_group_cputime_adjusted() outside of lock_task_sighand()")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>netfilter: nft_compat: reject unused compat flag</title>
<updated>2024-02-23T07:12:54+00:00</updated>
<author>
<name>Pablo Neira Ayuso</name>
<email>pablo@netfilter.org</email>
</author>
<published>2024-02-01T22:33:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=56fb2bf4ab8c91a2e078553497b6c5b2f1dac699'/>
<id>urn:sha1:56fb2bf4ab8c91a2e078553497b6c5b2f1dac699</id>
<content type='text'>
[ Upstream commit 292781c3c5485ce33bd22b2ef1b2bed709b4d672 ]

Flag (1 &lt;&lt; 0) is ignored is set, never used, reject it it with EINVAL
instead.

Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>btrfs: defrag: reject unknown flags of btrfs_ioctl_defrag_range_args</title>
<updated>2024-02-23T07:12:42+00:00</updated>
<author>
<name>Qu Wenruo</name>
<email>wqu@suse.com</email>
</author>
<published>2024-01-09T22:28:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f084057282bc5f45e5f50a4b226244a30666422d'/>
<id>urn:sha1:f084057282bc5f45e5f50a4b226244a30666422d</id>
<content type='text'>
commit 173431b274a9a54fc10b273b46e67f46bcf62d2e upstream.

Add extra sanity check for btrfs_ioctl_defrag_range_args::flags.

This is not really to enhance fuzzing tests, but as a preparation for
future expansion on btrfs_ioctl_defrag_range_args.

In the future we're going to add new members, allowing more fine tuning
for btrfs defrag.  Without the -ENONOTSUPP error, there would be no way
to detect if the kernel supports those new defrag features.

CC: stable@vger.kernel.org # 4.14+
Reviewed-by: Filipe Manana &lt;fdmanana@suse.com&gt;
Signed-off-by: Qu Wenruo &lt;wqu@suse.com&gt;
Reviewed-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>perf/core: Add a new read format to get a number of lost samples</title>
<updated>2023-12-13T16:42:19+00:00</updated>
<author>
<name>Namhyung Kim</name>
<email>namhyung@kernel.org</email>
</author>
<published>2022-06-16T18:06:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ece0857258cbaf20b9828157035999f46ca060c8'/>
<id>urn:sha1:ece0857258cbaf20b9828157035999f46ca060c8</id>
<content type='text'>
[ Upstream commit 119a784c81270eb88e573174ed2209225d646656 ]

Sometimes we want to know an accurate number of samples even if it's
lost.  Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
might be shared with other events.  So it's hard to know per-event
lost count.

Add event-&gt;lost_samples field and PERF_FORMAT_LOST to retrieve it from
userspace.

Original-patch-by: Jiri Olsa &lt;jolsa@redhat.com&gt;
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://lkml.kernel.org/r/20220616180623.1358843-1-namhyung@kernel.org
Stable-dep-of: 382c27f4ed28 ("perf: Fix perf_event_validate_size()")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>netfilter: xt_owner: Add supplementary groups option</title>
<updated>2023-12-13T16:42:17+00:00</updated>
<author>
<name>Lukasz Pawelczyk</name>
<email>l.pawelczyk@samsung.com</email>
</author>
<published>2019-05-10T11:46:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=22566a81f62b96400fbe75f3f67de3c5b83fe453'/>
<id>urn:sha1:22566a81f62b96400fbe75f3f67de3c5b83fe453</id>
<content type='text'>
[ Upstream commit ea6cc2fd8a2b89ab6dcd096ba6dbc1ecbdf26564 ]

The XT_OWNER_SUPPL_GROUPS flag causes GIDs specified with XT_OWNER_GID
to be also checked in the supplementary groups of a process.

f_cred-&gt;group_info cannot be modified during its lifetime and f_cred
holds a reference to it so it's safe to use.

Signed-off-by: Lukasz Pawelczyk &lt;l.pawelczyk@samsung.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Stable-dep-of: 7ae836a3d630 ("netfilter: xt_owner: Fix for unsafe access of sk-&gt;sk_socket")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpf: Clarify error expectations from bpf_clone_redirect</title>
<updated>2023-10-10T19:44:58+00:00</updated>
<author>
<name>Stanislav Fomichev</name>
<email>sdf@google.com</email>
</author>
<published>2023-09-11T19:47:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4f8c4e167ad88387de51da02a1d2d5c366025470'/>
<id>urn:sha1:4f8c4e167ad88387de51da02a1d2d5c366025470</id>
<content type='text'>
[ Upstream commit 7cb779a6867fea00b4209bcf6de2f178a743247d ]

Commit 151e887d8ff9 ("veth: Fixing transmit return status for dropped
packets") exposed the fact that bpf_clone_redirect is capable of
returning raw NET_XMIT_XXX return codes.

This is in the conflict with its UAPI doc which says the following:
"0 on success, or a negative error in case of failure."

Update the UAPI to reflect the fact that bpf_clone_redirect can
return positive error numbers, but don't explicitly define
their meaning.

Reported-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Signed-off-by: Stanislav Fomichev &lt;sdf@google.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/20230911194731.286342-1-sdf@google.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dma-buf/sync_file: Fix docs syntax</title>
<updated>2023-09-23T08:48:08+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2023-07-24T14:49:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d8ff73e44d10a87d7f2edbe2f7578247debfb7b5'/>
<id>urn:sha1:d8ff73e44d10a87d7f2edbe2f7578247debfb7b5</id>
<content type='text'>
[ Upstream commit 05d56d8079d510a2994039470f65bea85f0075ee ]

Fixes the warning:

  include/uapi/linux/sync_file.h:77: warning: Function parameter or member 'num_fences' not described in 'sync_file_info'

Fixes: 2d75c88fefb2 ("staging/android: refactor SYNC IOCTLs")
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Reviewed-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Link: https://lore.kernel.org/r/20230724145000.125880-1-robdclark@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: Add #defines for Enter Compliance, Transmit Margin</title>
<updated>2023-09-23T08:48:05+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2019-11-12T17:07:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e50a0d4aefafa6fee15474cbf9a9e4d1d94d4c7a'/>
<id>urn:sha1:e50a0d4aefafa6fee15474cbf9a9e4d1d94d4c7a</id>
<content type='text'>
[ Upstream commit bbdb2f5ecdf1e66b2f09710134db3c2e5c43a958 ]

Add definitions for the Enter Compliance and Transmit Margin fields of the
PCIe Link Control 2 register.

Link: https://lore.kernel.org/r/20191112173503.176611-2-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Stable-dep-of: ce7d88110b9e ("drm/amdgpu: Use RMW accessors for changing LNKCTL")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: Decode PCIe 32 GT/s link speed</title>
<updated>2023-09-23T08:48:05+00:00</updated>
<author>
<name>Gustavo Pimentel</name>
<email>Gustavo.Pimentel@synopsys.com</email>
</author>
<published>2019-06-04T16:24:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eac3517cd33568e8e15a4b51dcb96cd059bc58e4'/>
<id>urn:sha1:eac3517cd33568e8e15a4b51dcb96cd059bc58e4</id>
<content type='text'>
[ Upstream commit de76cda215d56256ffcda7ffa538b70f9fb301a7 ]

PCIe r5.0, sec 7.5.3.18, defines a new 32.0 GT/s bit in the Supported Link
Speeds Vector of Link Capabilities 2.  Decode this new speed.  This does
not affect the speed of the link, which should be negotiated automatically
by the hardware; it only adds decoding when showing the speed to the user.

Previously, reading the speed of a link operating at this speed showed
"Unknown speed" instead of "32.0 GT/s".

Link: https://lore.kernel.org/lkml/92365e3caf0fc559f9ab14bcd053bfc92d4f661c.1559664969.git.gustavo.pimentel@synopsys.com
Signed-off-by: Gustavo Pimentel &lt;gustavo.pimentel@synopsys.com&gt;
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Stable-dep-of: ce7d88110b9e ("drm/amdgpu: Use RMW accessors for changing LNKCTL")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: Cleanup register definition width and whitespace</title>
<updated>2023-09-23T08:48:05+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2019-02-04T20:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d132ec2ccd4a47ee129eaf824a593c2da3a59c15'/>
<id>urn:sha1:d132ec2ccd4a47ee129eaf824a593c2da3a59c15</id>
<content type='text'>
[ Upstream commit 35d0a06dad2220d62042fd1a91a216d17744e724 ]

Follow the file conventions of:

  - register offsets not indented
  - fields within a register indented one space
  - field masks use same width as register
  - register field values indented an additional space

No functional change intended.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Stable-dep-of: ce7d88110b9e ("drm/amdgpu: Use RMW accessors for changing LNKCTL")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
