Skip to content
Snippets Groups Projects
Select Git revision
  • rock5b-plus
  • rockchip-next-20250321
  • rockchip-next-20250311
  • cristicc/hdptx-phy-for-rock5b-plus
  • rockchip-devel
  • rockchip-v6.13 default
  • rk3576-vop2-support
  • rk3588
  • rk3588-test
  • rk3576-pcie-support
  • rk3588-hantro-av1dec-nv15
  • rk3588-hdmi-bridge-v6.14-rc1
  • rk3588-test-npu
  • rk3576-thermal-adc-2
  • rk3588-hdmi-audio
  • add-rkvdec2-driver-iommu
  • rk3588-test-dsi
  • zero3w
  • rk3588-v6.12
  • add-rkvdec2-driver
  • v6.13
  • v6.12
  • v6.8-rc1
  • v6.7-rc1
  • v6.6
  • v6.6-rc1
  • v6.5
  • v6.5-rc1
  • v6.4
  • v6.4-rc1
  • v6.3
  • v6.3-rc1
  • v6.2-rc1
  • v6.0-rc1
  • v5.19-rc3
  • v5.19-rc2
  • v5.19-rc1
  • v5.18
  • v5.18-rc7
  • v5.18-rc6
40 results
Search by author
  • Any Author
  • Benjamin Gaignard benjamin.gaignard
  • Boris Brezillon bbrezillon
  • Christopher Obbard Christopher Obbard obbardc
  • Cristian Ciocaltea Cristian Ciocaltea cristicc
  • Daniel Stone Daniel Stone daniels
  • Detlev Casanova detlev
  • Eugen Hristev Eugen Hristev ehristev
  • Gustavo Padovan Gustavo Padovan padovan
  • Nicolas Dufresne Nicolas Dufresne nicolas
  • Nicolas Frattaroli Nicolas Frattaroli fratti
  • Sebastian Reichel Sebastian Reichel sre
  • Shreeya Patel shreeya
  • Sjoerd Simons Sjoerd Simons sjoerd
13 authors
  1. Jul 26, 2024
    • Sebastian Reichel's avatar
      clk: divider: Fix divisor masking on 64 bit platforms · 567abd23
      Sebastian Reichel authored and Sebastian Reichel's avatar Sebastian Reichel committed 
      
The clock framework handles clock rates as "unsigned long", so u32 on
32-bit architectures and u64 on 64-bit architectures.

The current code casts the dividend to u64 on 32-bit to avoid a
potential overflow. For example DIV_ROUND_UP(3000000000, 1500000000)
= (3.0G + 1.5G - 1) / 1.5G = = OVERFLOW / 1.5G, which has been
introduced in commit 9556f9da ("clk: divider: handle integer overflow
when dividing large clock rates").

On 64 bit platforms this masks the divisor, so that only the lower
32 bit are used. Thus requesting a frequency >= 4.3GHz results
in incorrect values. For example requesting 4300000000 (4.3 GHz) will
effectively request ca. 5 MHz. Requesting clk_round_rate(clk, ULONG_MAX)
is a bit of a special case, since that still returns correct values as
long as the parent clock is below 8.5 GHz.

Fix this by switching to DIV_ROUND_UP_NO_OVERFLOW, which cannot
overflow. This avoids any requirements on the arguments (except
that divisor should not be 0 obviously).

Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      567abd23
  3. Jul 25, 2024
  5. Jul 24, 2024
    • Joel Granados's avatar
      sysctl: treewide: constify the ctl_table argument of proc_handlers · 78eb4ea2
      Joel Granados authored 
      
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.

This patch has been generated by the following coccinelle script:

```
  virtual patch

  @r1@
  identifier ctl, write, buffer, lenp, ppos;
  identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
  @@

  int func(
  - struct ctl_table *ctl
  + const struct ctl_table *ctl
    ,int write, void *buffer, size_t *lenp, loff_t *ppos);

  @r2@
  identifier func, ctl, write, buffer, lenp, ppos;
  @@

  int func(
  - struct ctl_table *ctl
  + const struct ctl_table *ctl
    ,int write, void *buffer, size_t *lenp, loff_t *ppos)
  { ... }

  @r3@
  identifier func;
  @@

  int func(
  - struct ctl_table *
  + const struct ctl_table *
    ,int , void *, size_t *, loff_t *);

  @r4@
  identifier func, ctl;
  @@

  int func(
  - struct ctl_table *ctl
  + const struct ctl_table *ctl
    ,int , void *, size_t *, loff_t *);

  @r5@
  identifier func, write, buffer, lenp, ppos;
  @@

  int func(
  - struct ctl_table *
  + const struct ctl_table *
    ,int write, void *buffer, size_t *lenp, loff_t *ppos);

```

* Code formatting was adjusted in xfs_sysctl.c to comply with code
  conventions. The xfs_stats_clear_proc_handler,
  xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
  adjusted.

* The ctl_table argument in proc_watchdog_common was const qualified.
  This is called from a proc_handler itself and is calling back into
  another proc_handler, making it necessary to change it as part of the
  proc_handler migration.

Co-developed-by: default avatarThomas Weißschuh <linux@weissschuh.net>
Signed-off-by: default avatarThomas Weißschuh <linux@weissschuh.net>
Co-developed-by: default avatarJoel Granados <j.granados@samsung.com>
Signed-off-by: default avatarJoel Granados <j.granados@samsung.com>
      78eb4ea2
    • Simon Horman's avatar
      net: stmmac: Correct byte order of perfect_match · e9dbebae
      Simon Horman authored 
      
The perfect_match parameter of the update_vlan_hash operation is __le16,
and is correctly converted from host byte-order in the lone caller,
stmmac_vlan_update().

However, the implementations of this caller, dwxgmac2_update_vlan_hash()
and dwxgmac2_update_vlan_hash(), both treat this parameter as host byte
order, using the following pattern:

	u32 value = ...
	...
	writel(value | perfect_match, ...);

This is not correct because both:
1) value is host byte order; and
2) writel expects a host byte order value as it's first argument

I believe that this will break on big endian systems. And I expect it
has gone unnoticed by only being exercised on little endian systems.

The approach taken by this patch is to update the callback, and it's
caller to simply use a host byte order value.

Flagged by Sparse.
Compile tested only.

Fixes: c7ab0b80 ("net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available")
Signed-off-by: default avatarSimon Horman <horms@kernel.org>
Reviewed-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9dbebae
  7. Jul 23, 2024
  9. Jul 20, 2024
  11. Jul 19, 2024
    • Jason A. Donenfeld's avatar
      random: introduce generic vDSO getrandom() implementation · 4ad10a5f
      Jason A. Donenfeld authored 
      
Provide a generic C vDSO getrandom() implementation, which operates on
an opaque state returned by vgetrandom_alloc() and produces random bytes
the same way as getrandom(). This has the following API signature:

  ssize_t vgetrandom(void *buffer, size_t len, unsigned int flags,
                     void *opaque_state, size_t opaque_len);

The return value and the first three arguments are the same as ordinary
getrandom(), while the last two arguments are a pointer to the opaque
allocated state and its size. Were all five arguments passed to the
getrandom() syscall, nothing different would happen, and the functions
would have the exact same behavior.

The actual vDSO RNG algorithm implemented is the same one implemented by
drivers/char/random.c, using the same fast-erasure techniques as that.
Should the in-kernel implementation change, so too will the vDSO one.

It requires an implementation of ChaCha20 that does not use any stack,
in order to maintain forward secrecy if a multi-threaded program forks
(though this does not account for a similar issue with SA_SIGINFO
copying registers to the stack), so this is left as an
architecture-specific fill-in. Stack-less ChaCha20 is an easy algorithm
to implement on a variety of architectures, so this shouldn't be too
onerous.

Initially, the state is keyless, and so the first call makes a
getrandom() syscall to generate that key, and then uses it for
subsequent calls. By keeping track of a generation counter, it knows
when its key is invalidated and it should fetch a new one using the
syscall. Later, more than just a generation counter might be used.

Since MADV_WIPEONFORK is set on the opaque state, the key and related
state is wiped during a fork(), so secrets don't roll over into new
processes, and the same state doesn't accidentally generate the same
random stream. The generation counter, as well, is always >0, so that
the 0 counter is a useful indication of a fork() or otherwise
uninitialized state.

If the kernel RNG is not yet initialized, then the vDSO always calls the
syscall, because that behavior cannot be emulated in userspace, but
fortunately that state is short lived and only during early boot. If it
has been initialized, then there is no need to inspect the `flags`
argument, because the behavior does not change post-initialization
regardless of the `flags` value.

Since the opaque state passed to it is mutated, vDSO getrandom() is not
reentrant, when used with the same opaque state, which libc should be
mindful of.

The function works over an opaque per-thread state of a particular size,
which must be marked VM_WIPEONFORK, VM_DONTDUMP, VM_NORESERVE, and
VM_DROPPABLE for proper operation. Over time, the nuances of these
allocations may change or grow or even differ based on architectural
features.

The opaque state passed to vDSO getrandom() must be allocated using the
mmap_flags and mmap_prot parameters provided by the vgetrandom_opaque_params
struct, which also contains the size of each state. That struct can be
obtained with a call to vgetrandom(NULL, 0, 0, &params, ~0UL). Then,
libc can call mmap(2) and slice up the returned array into a state per
each thread, while ensuring that no single state straddles a page
boundary. Libc is expected to allocate a chunk of these on first use,
and then dole them out to threads as they're created, allocating more
when needed.

vDSO getrandom() provides the ability for userspace to generate random
bytes quickly and safely, and is intended to be integrated into libc's
thread management. As an illustrative example, the introduced code in
the vdso_test_getrandom self test later in this series might be used to
do the same outside of libc. In a libc the various pthread-isms are
expected to be elided into libc internals.

Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      4ad10a5f
    • Huacai Chen's avatar
      PCI: loongson: Enable MSI in LS7A Root Complex · a4bbcac1
      Huacai Chen authored 
      The LS7A chipset can be used as part of a PCIe Root Complex with
Loongson-3C6000 and similar CPUs.  In this case, DEV_LS7A_PCIE_PORT5 has a
PCI_CLASS_BRIDGE_HOST class code, and it is a Type 0 Function whose config
space provides access to Root Complex registers.

The DEV_LS7A_PCIE_PORT5 has an MSI Capability, and its MSI Enable bit must
be set before other devices below the Root Complex can use MSI.  This is
not the standard PCI behavior of MSI Enable, so the normal PCI MSI code
does not set it.

Set the DEV_LS7A_PCIE_PORT5 MSI Enable bit via a quirk so other devices
below the Root Complex can use MSI.

[kwilczynski: exit early to reduce indentation; commit log]
Link: https://lore.kernel.org/linux-pci/20240612065315.2048110-1-chenhuacai@loongson.cn


Signed-off-by: default avatarSheng Wu <wusheng@loongson.cn>
Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
Signed-off-by: default avatarKrzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: commit log]
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
      a4bbcac1
    • Jakub Kicinski's avatar
      eth: fbnic: don't build the driver when skb has more than 21 frags · 43598361
      Jakub Kicinski authored 
      
Similarly to commit 0e03c643 ("eth: fbnic: fix s390 build."),
the driver won't build if skb_shared_info has more than 25 frags
assuming a 64B cache line and 21 frags assuming a 128B cache line.

  (512 - 48 -  64) / 16 = 25
  (512 - 48 - 128) / 16 = 21

Fixes: 0cb4c0a1 ("eth: fbnic: Implement Rx queue alloc/start/stop/free")
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20240717161600.1291544-1-kuba@kernel.org


Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      43598361
    • Matthew Sakai's avatar
      dm vdo int-map: fix kerneldoc formatting · 513789b7
      Matthew Sakai authored 
      
Reported-by: default avatarkernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202407141607.M3E2XQ0Z-lkp@intel.com/


Signed-off-by: default avatarMatthew Sakai <msakai@redhat.com>
Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      513789b7
    • Matthew Sakai's avatar
      dm vdo repair: add missing kerneldoc fields · fa398e60
      Matthew Sakai authored 
      
Also remove trivial comment for increment_recovery_point.

Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9518


Signed-off-by: default avatarMatthew Sakai <msakai@redhat.com>
Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      fa398e60
    • Christophe JAILLET's avatar
      dm: Constify struct dm_block_validator · 0b60be16
      Christophe JAILLET authored 
      
'struct dm_block_validator' are not modified in these drivers.

Constifying this structure moves some data to a read-only section, so
increase overall security.

On a x86_64, with allmodconfig, as an example:

Before:
======
   text	   data	    bss	    dec	    hex	filename
  32047	    920	     16	  32983	   80d7	drivers/md/dm-cache-metadata.o

After:
=====
   text	   data	    bss	    dec	    hex	filename
  32075	    896	     16	  32987	   80db	drivers/md/dm-cache-metadata.o

Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      0b60be16
    • Mikulas Patocka's avatar
      dm-integrity: introduce the Inline mode · fb098768
      Mikulas Patocka authored 
      
This commit introduces a new 'I' mode for dm-integrity.

The 'I' mode may be selected if the underlying device has non-power-of-2
sector size. In this mode, dm-integrity will store integrity data
directly in device's sectors and it will not use journal.

This mode improves performance and reduces flash wear because there would
be no journal writes.

Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      fb098768
  13. Jul 18, 2024