On Thu, 13 Mar 2025 14:09:24 -0700
Jacob Keller wrote:
> On 3/13/2025 9:36 AM, H. Peter Anvin wrote:
> > On March 13, 2025 9:24:38 AM PDT, Yury Norov wrote:
> >> On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote:
> >>> On March 12, 2025 4:56:31 PM PDT, Jacob Keller
> >>> wrote
On Sun, 9 Mar 2025 01:58:53 +
David Laight wrote:
> On Fri, 7 Mar 2025 18:58:08 +0900
> Vincent Mailhol wrote:
>
> > On 07/03/2025 at 04:23, David Laight wrote:
> > > On Thu, 06 Mar 2025 20:29:52 +0900
> > > Vincent Mailhol via B4 Relay
> > &g
On Fri, 7 Mar 2025 18:58:08 +0900
Vincent Mailhol wrote:
> On 07/03/2025 at 04:23, David Laight wrote:
> > On Thu, 06 Mar 2025 20:29:52 +0900
> > Vincent Mailhol via B4 Relay
> > wrote:
> >
> >> From: Vincent Mailhol
> >>
> >>
On Fri, 07 Mar 2025 11:30:35 -0800
"H. Peter Anvin" wrote:
> On March 7, 2025 10:49:56 AM PST, Andrew Cooper
> wrote:
> >> (int)true most definitely is guaranteed to be 1.
> >
> >That's not technically correct any more.
> >
> >GCC has introduced hardened bools that intentionally have bit patt
On Fri, 7 Mar 2025 12:42:41 +0100
Jiri Slaby wrote:
> On 07. 03. 25, 12:38, Ingo Molnar wrote:
> >
> > * Jiri Slaby wrote:
> >
> >> On 06. 03. 25, 17:25, Kuan-Wei Chiu wrote:
> >>> Change return type to bool for better clarity. Update the kernel doc
> >>> comment accordingly, including fix
On Fri, 7 Mar 2025 18:58:08 +0900
Vincent Mailhol wrote:
> On 07/03/2025 at 04:23, David Laight wrote:
> > On Thu, 06 Mar 2025 20:29:52 +0900
> > Vincent Mailhol via B4 Relay
> > wrote:
> >
> >> From: Vincent Mailhol
> >>
> >>
On Fri, 7 Mar 2025 00:25:26 +0800
Kuan-Wei Chiu wrote:
> Change return type to bool for better clarity. Update the kernel doc
> comment accordingly, including fixing "@value" to "@val" and adjusting
> examples. Also mark the function with __attribute_const__ to allow
> potential compiler optimiz
On Thu, 06 Mar 2025 20:29:52 +0900
Vincent Mailhol via B4 Relay
wrote:
> From: Vincent Mailhol
>
> In an upcoming change, GENMASK() and its friends will indirectly
> depend on sizeof() which is not available in asm.
>
> Instead of adding further complexity to __GENMASK() to make it work
> for
On Wed, 5 Mar 2025 21:56:22 +0200
Andy Shevchenko wrote:
> On Thu, Mar 06, 2025 at 02:17:18AM +0900, Vincent Mailhol wrote:
> > On 06/03/2025 at 00:48, Andy Shevchenko wrote:
> > > On Wed, Mar 05, 2025 at 11:48:10PM +0900, Vincent Mailhol wrote:
> > >> On 05/03/2025 at 23:33, Andy Shevchenko
On Wed, 5 Mar 2025 17:30:28 +0300
Dan Carpenter wrote:
> On Wed, Mar 05, 2025 at 02:17:32PM +0000, David Laight wrote:
...
> > And the 'fun' starts because NULL isn't required to use the all-zero
> > bit pattern.
> > Regardless of the bit-pattern, things lik
On Wed, 5 Mar 2025 17:48:05 +0200
Andy Shevchenko wrote:
> On Wed, Mar 05, 2025 at 11:48:10PM +0900, Vincent Mailhol wrote:
> > On 05/03/2025 at 23:33, Andy Shevchenko wrote:
> > > On Wed, Mar 05, 2025 at 10:00:16PM +0900, Vincent Mailhol via B4 Relay
> > > wrote:
>
> ...
>
> > >> +#define
On Wed, 5 Mar 2025 11:51:59 +0300
Dan Carpenter wrote:
> On Wed, Mar 05, 2025 at 09:40:43AM +0100, Markus Elfring wrote:
> > >>> The address of a data structure member was determined before
> > >>> a corresponding null pointer check in the implementation of
> > >>> the functions “dpu_hw_pp_enable
On Mon, 3 Mar 2025 10:15:41 -0500
Yury Norov wrote:
> On Mon, Mar 03, 2025 at 01:29:19AM +0800, Kuan-Wei Chiu wrote:
> > Hi Yury,
> >
> > On Sun, Mar 02, 2025 at 11:02:12AM -0500, Yury Norov wrote:
> > > On Sun, Mar 02, 2025 at 04:20:02PM +0800, Kuan-Wei Chiu wrote:
> > > > Hi Yury,
> > > >
On Mon, 3 Mar 2025 10:47:20 +0800
Kuan-Wei Chiu wrote:
> On Sun, Mar 02, 2025 at 07:09:54PM +0000, David Laight wrote:
> > On Mon, 3 Mar 2025 01:29:19 +0800
> > Kuan-Wei Chiu wrote:
> >
> > > Hi Yury,
>
On Mon, 3 Mar 2025 01:29:19 +0800
Kuan-Wei Chiu wrote:
> Hi Yury,
>
> On Sun, Mar 02, 2025 at 11:02:12AM -0500, Yury Norov wrote:
> > On Sun, Mar 02, 2025 at 04:20:02PM +0800, Kuan-Wei Chiu wrote:
> > > Hi Yury,
> > >
> > > On Sat, Mar 01, 2025 at 10:10:20PM -0500, Yury Norov wrote:
> > > >
On Thu, 27 Feb 2025 13:05:29 -0500
Yury Norov wrote:
> On Wed, Feb 26, 2025 at 10:29:11PM +0000, David Laight wrote:
> > On Mon, 24 Feb 2025 14:27:03 -0500
> > Yury Norov wrote:
> >
>
On Mon, 24 Feb 2025 14:27:03 -0500
Yury Norov wrote:
> +#define parity(val) \
> +({ \
> + u64 __v = (val);\
> + int __ret; \
> +
On Mon, 24 Feb 2025 13:55:28 -0800
"H. Peter Anvin" wrote:
> On 2/24/25 07:24, Uros Bizjak wrote:
> >
> >
> > On 23. 02. 25 17:42, Kuan-Wei Chiu wrote:
> >> Refactor parity calculations to use the standard parity8() helper. This
> >> change eliminates redundant implementations and improves co
On Mon, 24 Feb 2025 08:09:43 +0100
Jiri Slaby wrote:
> On 23. 02. 25, 17:42, Kuan-Wei Chiu wrote:
> > Several parts of the kernel open-code parity calculations using
> > different methods. Add a generic parity64() helper implemented with the
> > same efficient approach as parity8().
> >
> > Co-d
On Fri, 14 Feb 2025 20:02:01 -0500
Alex Lanzano wrote:
> On Fri, Feb 14, 2025 at 01:29:10PM +0000, David Laight wrote:
> > On Thu, 13 Feb 2025 20:54:59 -0500
> > Alex Lanzano wrote:
> >
> > > On Thu, Jan 16, 2025 at 05:48:01AM -0800, Nikita Zhandarovich wrote:
On Thu, 13 Feb 2025 20:54:59 -0500
Alex Lanzano wrote:
> On Thu, Jan 16, 2025 at 05:48:01AM -0800, Nikita Zhandarovich wrote:
> > There are conditions, albeit somewhat unlikely, under which right hand
> > expressions, calculating the end of time period in functions like
> > repaper_frame_fixed_re
On Tue, 21 Jan 2025 15:15:09 -0800
Linus Torvalds wrote:
> On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
> >
> > I'm pushing this soon to drm-intel-next, unless Linus want to take
> > this one directly to his tree
>
> Let's just go through the proper channels and go through the drm tree.
On Wed, 1 Jan 2025 17:39:20 +0200
Alexander Usyskin wrote:
> GSC NVM controller HW errors on quad access overlapping 1K border.
> Align 64bit read and write to avoid readq/writeq over 1K border.
>
> Acked-by: Miquel Raynal
> Signed-off-by: Alexander Usyskin
> ---
> drivers/mtd/devices/mtd-in
On Wed, 1 Jan 2025 16:41:19 +
David Laight wrote:
> On Wed, 1 Jan 2025 17:39:20 +0200
> Alexander Usyskin wrote:
>
> > GSC NVM controller HW errors on quad access overlapping 1K border.
> > Align 64bit read and write to avoid readq/writeq over 1K border.
> >
From: Martin Uecker
> Sent: 08 December 2024 12:38
>
> Am Sonntag, dem 08.12.2024 um 11:26 + schrieb David Laight:
> > From: Martin Uecker
> > > Sent: 07 December 2024 23:52
> > ...
> > > While the compiler can not automatically prove every use
> &g
From: Martin Uecker
> Sent: 07 December 2024 23:52
...
> While the compiler can not automatically prove every use
> of VLA bounded, it can reliably diagnose the cases where it
> can *not* see that it is bounded. Consider this example:
>
> void oob(int n, char p[n]);
> void f(unsigned int n)
> {
>
From: Martin Uecker
> Sent: 07 December 2024 21:06
>
> Am Samstag, dem 07.12.2024 um 21:00 + schrieb David Laight:
> > From: Martin Uecker
> > > Sent: 07 December 2024 19:52
> ...
>
> >
> > > There exist proposals along those lines for C2Y.
From: Martin Uecker
> Sent: 07 December 2024 19:52
...
> > Of course, often the compiler *does* have helper builtins, but we
> > can't use them, because they aren't *quite* the right thing. Like that
> > "__builtin_constant_p()" not actually working for some situations
> > where we absolutely need
From: Linus Torvalds
> Sent: 07 December 2024 20:31
...
> We're currently still accepting gcc-5.1 as a compiler, although it's
> time to look at that and probably (judging by what stable distros use)
> upgrade to something like gcc-8.1 as the minimum supported compiler
> version.
That's going to a
From: Vincent Mailhol
> Sent: 07 December 2024 13:51
...
> > > It seems to me that the long term solution to this problem are the
> > > constexpr functions.
> >
> > How would constexpr functions help here? (I am a bit sceptical about
> > constexpr functions.)
>
> I was thinking of some of the "si
From: Vincent Mailhol
> Sent: 07 December 2024 07:43
...
> > So maybe the slightly long lines:
> > #define const_true(x) _Generic(0 ? (void *)((x) + 0 ? 0L : 1L) : (char *)0,
> > char *: 1, void *: 0)
> > #define const_expr(x) _Generic(0 ? (void *)((x) + 0 ? 0L : 0L) : (char *)0,
> > char *: 1, v
From: Martin Uecker
> Sent: 07 December 2024 08:40
...
> I find it amazing how much time the Linux kernel community spends
> revising code to make it work perfectly.
>
> Still, I am wondering whether some of this time and effort should not
> be targeted at C compilers and language work to make the
...
> > > #define const_NULL(x) _Generic(0 ? (x) : (char *)0, char *: 1, void *: 0)
> > > #define const_true(x) const_NULL((x) ? NULL : (void *)1L))
> > > #define const_expr(x) const_NULL((x) ? NULL : NULL))
> > > I send this morning.
> > > Needs 's/char/struct kjkjkjkjui/' applied.
> >
> > Oh Chri
From: Willy Tarreau
> Sent: 06 December 2024 19:39
> On Fri, Dec 06, 2024 at 11:15:20AM -0800, Linus Torvalds wrote:
> > On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
> > >
> > > I'm missing the compiler version and options to generate the error.
>
From: Linus Torvalds
> Sent: 06 December 2024 19:15
> On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
> >
> > I'm missing the compiler version and options to generate the error.
>
> Just -Wall with most recent gcc versions seems to do it. At least I
> can repro
From: Linus Torvalds
> Sent: 06 December 2024 18:53
>
> On Fri, 6 Dec 2024 at 10:31, Vincent Mailhol
> wrote:
> >
> > > causes issues when 'x' is not an integer expression (think
> > > "is_const(NULL)" or "is_const(1 == 2)".
> >
> > But 1 == 2 already has an integer type as proven by:
>
> Yeah,
From: David Laight
> Sent: 06 December 2024 02:26
(now it is no longer 2am...)
Linus suggested this a while back:
> in
> https://lore.kernel.org/all/CAHk-=wiq=gunwjwwh1craychw73umoaskacovlatfdkevez...@mail.gmail.com/
>
>/*
> * iff 'x' is a non-zero
From: Vincent Mailhol
> Sent: 05 December 2024 15:26
>
> On Thu. 5 Dec 2024 at 03:30, David Laight wrote:
> > From: Vincent Mailhol
> > > Sent: 02 December 2024 17:33
> > >
> > > From: Vincent Mailhol
> > >
> > > For c
From: Vincent Mailhol
> Sent: 05 December 2024 15:31
>
> -CC: Martin Uecker
> +CC: Martin Uecker
> (seems that Martin changed his address)
>
> On Thu. 5 Dec. 2024 at 03:39, David Laight wrote:
> > > Sent: 02 December 2024 17:33
> > >
> > > F
From: Vincent Mailhol
> Sent: 02 December 2024 17:34
>
> Most of the use of __is_const_expr() in i915_reg_defs.h are just to
> test whether an expression is known to be true. Because those checks
> are all done in a BUILD_BUG_ON_ZERO(), replace those with
> is_const_true().
Another place that cou
From: Christian Brauner
> Sent: 10 May 2024 11:55
>
> > For the uapi issue you describe below my take would be that we should just
> > try, and hope that everyone's been dutifully using O_CLOEXEC. But maybe
> > I'm biased from the gpu world, where we've been hammering it in that
> > "O_CLOEXEC or
From: Christian König
> Sent: 07 May 2024 15:05
...
> I actually have been telling people to (ab)use the epoll behavior to
> check if two file descriptors point to the same underlying file when
> KCMP isn't available.
In what way?
You can add both fd to the same epoll fd.
Relying on the implicit E
From: Linus Torvalds
> Sent: 06 May 2024 19:18
...
> Which is why I applied the minimal patch for just "refcount over
> vfs_poll()", and am just mentioning my suggestion in the hope that
> some eager beaver would like to see how painful it would do to make
> the bigger surgery...
I wonder if I can
From: Christian Brauner
> Sent: 06 May 2024 09:45
>
> > The fact is, it's not dma-buf that is violating any rules. It's epoll.
>
> I agree that epoll() not taking a reference on the file is at least
> unexpected and contradicts the usual code patterns for the sake of
> performance and that it ver
From: Linus Torvalds
> Sent: 05 May 2024 18:56
>
> epoll can call out to vfs_poll() with a file pointer that may race with
> the last 'fput()'. That would make f_count go down to zero, and while
> the ep->mtx locking means that the resulting file pointer tear-down will
> be blocked until the poll
From: Maxime Ripard
> Sent: 04 March 2024 11:46
>
> On Mon, Mar 04, 2024 at 12:11:36PM +0100, Arnd Bergmann wrote:
> > On Mon, Mar 4, 2024, at 09:07, Naresh Kamboju wrote:
> > > The arm defconfig builds failed on today's Linux next tag next-20240304.
> > >
> > > Build log:
> > > -
> > > ER
27;--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/David-Laight/minmax-Put-all-the-clamp-
> definitions-together/20240226-005902
> base: git://anongit.free
From: kernel test robot
> Sent: 26 February 2024 09:42
> If you fix the issue in a separate patch/commit (i.e. not just a new version
> of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202402261720
From: Jani Nikula
> Sent: 26 February 2024 09:28
>
> On Sun, 25 Feb 2024, David Laight wrote:
> > The wrapper just adds two more lines of error output when the test fails.
>
> There are only a handful of places in kernel code that use
> _Static_assert() directly.
...
> Yes, yes, that may end up requiring getting rid of some current users of
>
> #define MIN(a,b) ((a)<(b) ? (a):(b))
>
> but dammit, we don't actually have _that_ many of them, and why should
> we have random drivers doing that anyway?
They look like they could be changed to min().
It is ev
From: Linus Torvalds
> Sent: 25 February 2024 17:14
>
> On Sun, 25 Feb 2024 at 08:53, David Laight wrote:
> >
> > The expansions of min() and max() contain statement expressions so are
> > not valid for static intialisers.
> > min_const() and max_const() are expr
d max(bool, bool).
Fixup the initial block comment to match current reality.
Signed-off-by: David Laight
---
include/linux/minmax.h | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Changes for v2:
- Typographical and spelling corrections to the commit messages.
max() does unless a '+ 0' is added.
It is a shame the compiler generates this warning for code that will
be optimised away.
Change so that the extra '+ 0' can be removed.
Signed-off-by: David Laight
---
block/blk-settings.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
that the
casts added by max_t() are no longer needed.
Signed-off-by: David Laight
---
drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 2 +-
drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
drivers/input/touchscreen/cyttsp4_core.c | 2 +-
drivers/net/can/usb/etas_es58x/es58x_devlink.
values.
Using these to size on-stack arrays lets min/max be simplified.
Zero is added before the compare to convert enum values to integers
avoinding the need for casts when enums have been used for constants.
Signed-off-by: David Laight
---
include/linux/minmax.h | 15 +++
1 file
min3() and max3() were added to optimise nested min(x, min(y, z))
sequences, but only moved where the expansion was requiested.
Add a separate implementation for 3 argument calls.
These are never required to generate constant expressions to
remove that logic.
Signed-off-by: David Laight
Nothing requires that clamp() return a constant expression.
The logic to do so significantly increases the .i file.
Remove the check and directly expand __clamp_once() from clamp_t()
since the type check can't fail.
Signed-off-by: David Laight
---
include/linux/minmax.h | 14 +++-
There is no need to do the signedness/type check when the arguments
are being cast to a fixed type.
So move the check out of __xxx_once() into __careful_xxx().
Signed-off-by: David Laight
---
include/linux/minmax.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Changes
-extension logic.
Signed-off-by: David Laight
---
include/linux/minmax.h | 48 +-
1 file changed, 24 insertions(+), 24 deletions(-)
Changes for v2:
- Typographical and spelling corrections to the commit messages.
Patches unchanged.
diff --git a/include/linux
#x27;bool' to 'int'
and avoid a compiler warning because max() gets used for 'bool'
in one place (a very expensive 'or').
(The code is optimised away by two earlier checks - but the compiler
still bleats.)
Signed-off-by: David Laight
---
include/linux/minmax.h
The wrapper just adds two more lines of error output when the test fails.
Signed-off-by: David Laight
---
include/linux/minmax.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Changes for v2:
- Typographical and spelling corrections to the commit messages.
Patches unchanged
The defines for clamp() have got separated, move togther for readability.
Update description of signedness check.
Signed-off-by: David Laight
---
include/linux/minmax.h | 120 +++--
1 file changed, 56 insertions(+), 64 deletions(-)
Changes for v2
and 10.
Changes for v2:
- Typographical and spelling corrections to the commit messages.
Patches unchanged.
David Laight (11):
[1] minmax: Put all the clamp() definitions together
[2] minmax: Use _Static_assert() instead of static_assert()
[3] minmax: Simplify signedness check
[4] minm
...
> >> +#define BIT_U8(b) ((u8)(BIT_INPUT_CHECK(u8, b) + BIT(b)))
> >> +#define BIT_U16(b)((u16)(BIT_INPUT_CHECK(u16, b) +
> >> BIT(b)))
> >> +#define BIT_U32(b)((u32)(BIT_INPUT_CHECK(u32, b) +
> >> BIT(b)))
> >> +#define BIT_U64(b)((u64)(
From: Jani Nikula
> Sent: 29 January 2024 09:08
>
> On Sun, 28 Jan 2024, David Laight wrote:
> > blk_stack_limits() contains:
> > t->zoned = max(t->zoned, b->zoned);
> > These are bool, so it is just a bitwise or.
>
> Should be a logical or, reall
From: Linus Torvalds
> Sent: 28 January 2024 19:59
>
> On Sun, 28 Jan 2024 at 11:36, David Laight wrote:
> >
> > However it generates:
> > error: comparison of constant ‘0’ with boolean expression is always
> > true [-Werror=bool-compare]
> > insi
d max(bool, bool).
Fixup the initial block comment to match current reality.
Signed-off-by: David Laight
---
include/linux/minmax.h | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/linux/minmax.h b/include/linux/minmax.h
index c08916588425..5e
ss a '+ 0' is added.
It is a shame the compiler generates this warning for code that will
be optimised away.
Change so that the extra '+ 0' can be removed.
Signed-off-by: David Laight
---
block/blk-settings.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
that the
casts added by max_t() are no longer needed.
Signed-off-by: David Laight
---
drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 2 +-
drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
drivers/input/touchscreen/cyttsp4_core.c | 2 +-
drivers/net/can/usb/etas_es58x/es58x_devlink.
values.
Using these to size on-stack arrays lets min/max be simplified.
Zero is added before the compare to convert enum values to integers
avoinding the need for casts when enums have been used for constants.
Signed-off-by: David Laight
---
include/linux/minmax.h | 15 +++
1 file
The wrapper just adds two more lines of error output when the test fails.
Signed-off-by: David Laight
---
include/linux/minmax.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/minmax.h b/include/linux/minmax.h
index 63c45865b48a..900eec7a28e5 100644
The defines for clamp() have got separated, move togther for readability.
Update description of signedness check.
Signed-off-by: David Laight
---
include/linux/minmax.h | 120 +++--
1 file changed, 56 insertions(+), 64 deletions(-)
diff --git a/include/linux
few cases seems 'suboptimal'.
Instead I've added min_const() and max_const() for VLA and static
initialisers, these check the arguments are constant to avoid misuse.
Patch [9] is dependent on the earlier patches.
Patch [10] isn't dependant on them.
Patch [11] depends on both 9 a
Nothing requires that clamp() return a constant expression.
The logic to do so significantly increases the .i file.
Remove the check and directly expand __clamp_once() from clamp_t()
since the type check can't fail.
Signed-off-by: David Laight
---
include/linux/minmax.h | 14 +++-
min3() and max3() were added to optimise nested min(x, min(y, z))
sequences, bit only moved where the expansion was requiested.
Add a separate implementation for 3 argument calls.
These are never required to generate constant expressiions to
remove that logic.
Signed-off-by: David Laight
-extension logic.
Signed-off-by: David Laight
---
include/linux/minmax.h | 48 +-
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/include/linux/minmax.h b/include/linux/minmax.h
index c32b4b40ce01..8ee003d8abaf 100644
--- a/include/linux/minmax.h
There is no need to do the signedness/type check when the arguments
are being cast to a fixed type.
So move the check out of __xxx_once() into __careful_xxx().
Signed-off-by: David Laight
---
include/linux/minmax.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
#x27;bool' to 'int'
and avoid a compiler warning because max() gets used for 'bool'
in one place (a very expensive 'or').
(The code is optimised away by two earlier checks - but the compiler
still bleats.)
Signed-off-by: David Laight
---
include/linux/minmax.h |
From: Arnd Bergmann
> Sent: 20 December 2023 08:37
>
> On Tue, Dec 19, 2023, at 22:03, Sam Ravnborg via B4 Relay wrote:
> > TODO before this can be applied:
> > - Ack from davem - as he is the principal sparc maintainer
> > - Tested-by: preferably on a target or QEMU (see above)
> > I expect bug
From: Mina Almasry
> Sent: 06 November 2023 02:44
>
> For device memory TCP, we expect the skb headers to be available in host
> memory for access, and we expect the skb frags to be in device memory
> and unaccessible to the host. We expect there to be no mixing and
> matching of device memory fra
From: Mina Almasry
> Sent: 10 August 2023 02:58
...
> * TL;DR:
>
> Device memory TCP (devmem TCP) is a proposal for transferring data to and/or
> from device memory efficiently, without bouncing the data to a host memory
> buffer.
Doesn't that really require peer-to-peer PCIe transfers?
IIRC thes
From: Andrew Morton
> Sent: 03 August 2023 18:25
>
> On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko
> wrote:
>
> > abs_diff() belongs to math.h. Move it there.
> > This will allow others to use it.
> >
> > ...
> >
> > --- a/include/linux/math.h
> > +++ b/include/linux/math.h
> > @@ -155,6 +
From: Jason-JH Lin
> Sent: 14 July 2023 07:46
>
> Hi CK,
>
> Thanks for the reviews.
>
> On Fri, 2023-07-14 at 05:45 +, CK Hu (胡俊光) wrote:
> > Hi, Jason:
> >
> > On Wed, 2023-06-21 at 18:22 +0800, Jason-JH.Lin wrote:
> > > 1. Add casting before assign to avoid the unintentional integer
> > >
From: Kasireddy, Vivek
> Sent: 13 June 2023 09:26
...
> > Is my understanding correct, that we can effectively long-term pin
> > (worse than mlock) 64 MiB per UDMABUF_CREATE, allowing eventually !root
> > users
>
> The 64 MiB limit is the theoretical upper bound that we have not seen hit in
> prac
From: 15330273...@189.cn <15330273...@189.cn>
> Sent: 23 May 2023 05:27
>
> On 2023/5/22 19:29, Jani Nikula wrote:
> > In general, do not use unsigned types in arithmethic to avoid negative
> > values, because most people will be tripped over by integer promotion
> > rules, and you'll get negative
From: 15330273...@189.cn <15330273...@189.cn>
> Sent: 22 May 2023 12:56
...
> > I'll bet most people will be surprised to see what this prints:
> >
> > #include
> > #include
> >
> > int main(void)
> > {
> > uint16_t x = 0x;
> > uint16_t y = 0x;
> > uint64_t z = x * y;
> >
> >
From: 15330273...@189.cn
> Sent: 16 May 2023 18:30
>
> From: Sui Jingfeng
>
> Both mode->crtc_htotal and mode->crtc_vtotal are u16 type,
> mode->crtc_htotal * mode->crtc_vtotal will results a unsigned type.
Nope, u16 gets promoted to 'signed int' and the result of the
multiply is also signed.
From: Thomas Zimmermann
> Sent: 12 May 2023 11:25
>
> Cast I/O offsets to pointers to use them with I/O functions. The I/O
> functions expect pointers of type 'volatile void __iomem *', but the
> offsets are plain integers. Build warnings are
>
> ../drivers/video/fbdev/hitfb.c: In function 'hit
From: Andrew Morton
> Sent: 30 March 2023 23:19
>
> On Thu, 30 Mar 2023 21:53:03 +0000 David Laight
> wrote:
>
> > > But wouldn't all these issues be addressed by simply doing
> > >
> > > #define is_power_of_2(n) (n != 0 && ((n & (n -
From: Andrew Morton
> Sent: 30 March 2023 20:51
>
> On Thu, 30 Mar 2023 13:42:39 +0300 Jani Nikula wrote:
>
> > is_power_of_2() only works for types <= sizeof(unsigned long) and it's
> > also not a constant expression. There are a number of places in kernel
> > where is_power_of_2() is called on
From: Javier Martinez Canillas
> Sent: 21 January 2023 19:10
>
> The sparse tool complains with the following warning:
>
> $ make M=drivers/gpu/drm/solomon/ C=2
> CC [M] drivers/gpu/drm/solomon/ssd130x.o
> CHECK drivers/gpu/drm/solomon/ssd130x.c
> drivers/gpu/drm/solomon/ssd130x.c:363:21:
From: Daniel Vetter
> Sent: 05 January 2023 14:13
...
> > > So here we are, with Andrzej looking to add the common helper. And the
> > > same concerns crop up. What should it be called to make it clear that
> > > it's not atomic? Is that possible?
> >
> > old_value = read_write(variable, new_value)
From: Jani Nikula
> Sent: 05 January 2023 13:28
>
> On Thu, 05 Jan 2023, Daniel Vetter wrote:
> > On Mon, Dec 12, 2022 at 09:38:12AM +0000, David Laight wrote:
> >> From: Andrzej Hajda
> >> > Sent: 09 December 2022 15:49
> >> >
> >> >
From: Andrzej Hajda
> Sent: 09 December 2022 15:49
>
> The pattern of setting variable with new value and returning old
> one is very common in kernel. Usually atomicity of the operation
> is not required, so xchg seems to be suboptimal and confusing in
> such cases. Since name xchg is already in
From: Jason A. Donenfeld
> Sent: 24 October 2022 17:29
> To: linux-ker...@vger.kernel.org
>
> With char becoming unsigned by default, and with `char` alone being
> ambiguous and based on architecture, signed chars need to be marked
> explicitly as such. This fixes warnings like:
>
...
> ---
> dr
From: Joe Perches
> Sent: 12 October 2022 20:17
>
> On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> > The prandom_u32() function has been a deprecated inline wrapper around
> > get_random_u32() for several releases now, and compiles down to the
> > exact same code. Replace the depre
From: Jason A. Donenfeld
> Sent: 07 October 2022 19:01
>
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function. The s
From: Jason A. Donenfeld
> Sent: 07 October 2022 19:01
>
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions.
>
...
> --- a/lib/cmdline_kun
From: Jason A. Donenfeld
> Sent: 07 October 2022 18:56
...
> > Given these kinds of less mechanical changes, it may make sense to split
> > these from the "trivial" conversions in a treewide patch. The chance of
> > needing a revert from the simple 1:1 conversions is much lower than the
> > need to
From: Christophe Leroy
> Sent: 06 October 2022 18:43
...
> But taking into account that sp must remain 16 bytes aligned, would it
> be better to do something like ?
>
> sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
That makes me think...
If prandom_u32_max() is passed a (constant) power of 2
1 - 100 of 176 matches
Mail list logo
