From: Martin Sebor
> Sent: 22 March 2021 22:08
...
> In GCC 11, all access warnings expect objects to be either declared
> or allocated. Pointers with constant values are taken to point to
> nothing valid (as Arnd mentioned above, this is to detect invalid
> accesses to members of structs at addre
From: David Laight
> Sent: 24 March 2021 09:12
>
> From: Martin Sebor
> > Sent: 22 March 2021 22:08
> ...
> > In GCC 11, all access warnings expect objects to be either declared
> > or allocated. Pointers with constant values are taken to point to
> > nothing
>
> On Thu, Jan 21, 2021 at 11:00:20AM +0100, Christophe Leroy wrote:
> > > +bool module_loaded(const char *name);
> >
> > Maybe module_is_loaded() would be a better name.
>
> Fine with me.
It does look like both callers aren't 'unsafe'.
But it is a bit strange returning a stale value.
It did m
From: Christian König
> Sent: 15 February 2021 12:05
...
> Snooping the CPU caches introduces some extra latency, so what can
> happen is that the response to the PCIe read comes to late for the
> scanout. The result is an underflow and flickering whenever something is
> in the cache which needs to
From: David Laight
> Sent: 20 November 2020 15:39
>
> From: Thomas Zimmermann
> > Sent: 20 November 2020 13:42
> ...
> > I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> > Some candidates are
> >
> >8e3784dfef8a ("d
From: Greg KH
> Sent: 02 November 2020 20:11
>
> On Mon, Nov 02, 2020 at 02:43:45PM -0500, Alex Deucher wrote:
> > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote:
> > >
> > > Initializing global variable to 0 or NULL is not necessary and should
> > > be avoided. Issue reported by checkpatch
From: Linus Torvalds
> Sent: 18 November 2020 18:11
>
> On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote:
> >
> > I've got the 'splat' below during boot.
> > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics.
> > User space is Ubun
From: Thomas Zimmermann
> Sent: 18 November 2020 19:37
>
> Hi
>
> Am 18.11.20 um 19:10 schrieb Linus Torvalds:
> > On Wed, Nov 18, 2020 at 4:12 AM David Laight
> > wrote:
> >>
> >> I've got the 'splat' below during boot.
> >
From: Dave Airlie
> Sent: 19 November 2020 01:16
>
> On Thu, 19 Nov 2020 at 08:25, Dave Airlie wrote:
> >
> > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter wrote:
> > >
> > > On Wed, Nov 18, 2020 at 11:01 PM David Laight
> > > wrote:
> >
From: Thomas Zimmermann
> Sent: 20 November 2020 12:30
>
> Am 20.11.20 um 12:45 schrieb David Laight:
> > From: Thomas Zimmermann
> >> Sent: 20 November 2020 11:27
> > ...
> >>>> You can use drm-tip for testing, where many of the DRM patches
> Hi David
>
> Am 18.11.20 um 23:01 schrieb David Laight:
...
> Did you try Daniel's suggestion of testing with the direct parent commit?
(I was on holiday yesterday and didn't want to spend a sunny
afternoon doing bisects.)
I've just done that and it is bad.
Is ther
From: Thomas Zimmermann
> Sent: 20 November 2020 11:27
...
> >> You can use drm-tip for testing, where many of the DRM patches go through.
> >>
> >> https://cgit.freedesktop.org/drm/drm-tip/
> >>
> >> It's fairly up-to-date.
> >
> > Any idea of tags either side of the 5.10 merge?
>
> The final
From: Thomas Zimmermann
> Sent: 20 November 2020 10:14
...
> > Is there any way to bisect through the parts of the
> > drm merge patch into v5.10-rc1 ?
> >
> > That ought to be quicker (and less error prone) than
> > the bisect builds I was doing.
> >
> > Note that the stack 'splat' is due to a lat
From: Thomas Zimmermann
> Sent: 20 November 2020 13:42
...
> I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> Some candidates are
>
>8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
> plane's color format")
Ok, that one fixes the screen colours (etc).
So
From: T.J. Mercier
> Sent: 14 March 2022 23:45
>
> On Thu, Mar 10, 2022 at 11:33 AM Todd Kjos wrote:
> >
> > On Wed, Mar 9, 2022 at 8:52 AM T.J. Mercier wrote:
> > >
> > > The kernel interface should use types that the kernel defines instead of
> > > pid_t and uid_t, whose definiton is owned by
From: t...@redhat.com
> Sent: 26 February 2022 15:59
>
> From: Tom Rix
>
> Clang static analysis reports this error
> amdgpu_debugfs.c:1690:9: warning: 1st function call
> argument is an uninitialized value
> tmp = krealloc_array(tmp, i + 1,
> ^~~
>
> realloc
From: Linus Torvalds
> Sent: 28 February 2022 19:56
> On Mon, Feb 28, 2022 at 4:19 AM Christian König
> wrote:
> >
> > I don't think that using the extra variable makes the code in any way
> > more reliable or easier to read.
>
> So I think the next step is to do the attached patch (which require
From: Matthew Wilcox
> Sent: 28 February 2022 20:16
>
> On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_ 'pos' t
From: Abhinav Kumar
> Sent: 28 February 2022 21:38
...
> We also did some profiling around how much increasing the block size
> helps and here is the data:
>
> Block sizecost
>
> 4KB 229s
> 8KB86s
You must have an O(n^2) operation in there - find it.
David
-
R
From: Linus Torvalds
> Sent: 01 March 2022 19:07
> On Mon, Feb 28, 2022 at 2:29 PM James Bottomley
> wrote:
> >
> > However, if the desire is really to poison the loop variable then we
> > can do
> >
> > #define list_for_each_entry(pos, head, member) \
> > for (pos
From: Linus Torvalds
> Sent: 01 March 2022 23:03
>
> On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote:
> >
> > Can it be resolved by making:
> > #define list_entry_is_head(pos, head, member) ((pos) == NULL)
> > and double-checking that it isn't used anywhe
From: Xiaomeng Tong
> Sent: 02 March 2022 09:31
>
> On Mon, 28 Feb 2022 16:41:04 -0800, Linus Torvalds
> wrote:
> >
> > But basically to _me_, the important part is that the end result is
> > maintainable longer-term.
>
> I couldn't agree more. And because of that, I stick with the following
> a
From: Xiaomeng Tong
> Sent: 03 March 2022 02:27
>
> On Wed, 2 Mar 2022 14:04:06 +0000, David Laight
> wrote:
> > I think that it would be better to make any alternate loop macro
> > just set the variable to NULL on the loop exit.
> > That is easier to code for and t
From: Xiaomeng Tong
> Sent: 03 March 2022 07:27
>
> On Thu, 3 Mar 2022 04:58:23 +0000, David Laight wrote:
> > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > The problem is the mis-use of iterator outside the loop on exit, and
> > > the iterator will b
From: Jarkko Sakkinen
> Sent: 06 March 2022 05:32
>
> For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing. Allow
> to use that for initializing the device memory by providing a new callback
> f_ops->populate() for the purpose.
>
> SGX patches are provided to show the callback in c
From: Dan Carpenter
> Sent: 07 March 2022 15:01
>
> Updating this API is risky because some places rely on the old behavior
> and not all of them have been updated. Here are some additional places
> you might want to change.
I really can't help thinking that trying to merge this patch is
actuall
From: Christoph Hellwig
> Sent: 07 March 2022 15:57
>
> On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote:
> > So what would you suggest to sort out the issue? I'm happy to go with
> > ioctl if nothing else is acceptable.
>
> PLenty of drivers treat all mmaps as if MAP_POPULATE was
> > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
return "yes\0no" + v * 4;
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
> > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
> return "yes\0no" + v * 4;
>
> :-)
except '"no\0\0yes" + v * 4' works a bit better.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
> > except '"no\0\0yes" + v * 4' works a bit better.
>
> Is it a C code obfuscation contest?
That would be:
return &(v * 3)["no\0yes"];
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
...
> Yeah, and I am sorry for bikeshedding. Honestly, I do not know what is
> better. This is why I do not want to block this series when others
> like this.
>
> My main motivation is to point out that:
>
> enabledisable(enable)
>
> might be, for some people, more eye bleeding than
>
>
From: Yizhuo Zhai
> Sent: 01 February 2022 02:36
>
> In function do_fb_ioctl(), the "arg" is the type of unsigned long,
> and in "case FBIOBLANK:" this argument is casted into an int before
> passig to fb_blank(). In fb_blank(), the comparision
> if (blank > FB_BLANK_POWERDOWN) would be bypass if
From: Thomas Gleixner
> Sent: 11 December 2020 12:58
..
> > After my failed hasty sketch from last night I had a different one which
> > was kind of heuristics based (re-reading the upper dword and retrying if
> > it changed on 32-bit).
>
> The problem is that there will be two seperate modificati
From: Thomas Gleixner
> Sent: 11 December 2020 21:11
>
> On Fri, Dec 11 2020 at 14:19, David Laight wrote:
> > From: Thomas Gleixner
> >> You can't catch that. If this really becomes an issue you need a
> >> sequence counter around it.
> >
> > Or
From: Alastair D'Silva
> Sent: 08 May 2019 08:02
> To: alast...@d-silva.org
...
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -480,13 +480,13 @@ enum {
> DUMP_PREFIX_OFFSET
> };
>
> -extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
> -
From: Alastair D'Silva
> Sent: 10 April 2019 04:17
> With the wider display format, it can become hard to identify how many
> bytes into the line you are looking at.
>
> The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
> print vertical lines to separate every N groups of by
From: Alastair D'Silva
> Sent: 15 April 2019 11:07
...
> In the above example the author only wants the hex output, while in other
> situations, both hex & ASCII output is desirable. If you just want ASCII
> output, the caller should just use a printk or one of it's wrappers.
Hexdump will 'sanitis
From: Alastair D'Silva
> Sent: 15 April 2019 11:29
...
> I do, and I believe the choice of the output length should be in the hands
> of the caller.
>
> On further thought, it would make more sense to remove the hardcoded list of
> sizes and just enforce a power of 2. The function shouldn't dictat
From: Alastair D'Silva
> Sent: 15 April 2019 11:45
...
> > Although I think you'd want a 'no hex' flag to suppress the hex.
> >
> > Probably more useful flags are ones to suppress the address column.
>
> This is already supported by the prefix_type parameter - are you proposing
> that we eliminat
From: Christoph Hellwig
> Sent: 14 June 2019 14:47
>
> Many architectures (e.g. arm, m68 and sh) have always used exact
> allocation in their dma coherent allocator, which avoids a lot of
> memory waste especially for larger allocations. Lift this behavior
> into the generic allocator so that dma
From: 'Christoph Hellwig'
> Sent: 14 June 2019 15:50
> To: David Laight
> On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
> > Does this still guarantee that requests for 16k will not cross a 16k
> > boundary?
> > It looks like you are losing the
From: Robin Murphy
> Sent: 14 June 2019 16:06
...
> Well, apart from the bit in DMA-API-HOWTO which has said this since
> forever (well, before Git history, at least):
>
> "The CPU virtual address and the DMA address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is gr
From: Mauro Carvalho Chehab
> Sent: 30 April 2022 14:38
>
> Em Sat, 30 Apr 2022 14:04:59 +0200
> Greg KH escreveu:
>
> > On Sat, Apr 30, 2022 at 11:30:58AM +0100, Mauro Carvalho Chehab wrote:
>
> > Did you run checkpatch on this? Please do :)
> >
> > > +
> > > + if (mod == this)
> > > +
...
> * NOTE:
> * This file is gcc-parsable HW gospel, coming straight from HW engineers.
I never trust hardware engineers to write code :-)
(Although at the moment they trust me to write VHDL...)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
From: Arnd Bergmann
> Sent: 05 August 2022 20:32
...
> One thing to try would be to condense a function call like
>
> dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport(
>
...
> /* more arguments */);
>
> into calling conventions that take a po
From: Hamza Mahfooz
> Sent: 18 August 2022 17:49
>
> Addresses the following warning:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3596:6:
> error: stack frame
> size (2092) exceeds limit (2048) in
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-
>
From: Kalesh Singh
> Sent: 31 May 2022 23:30
...
> > File paths can contain fun characters like newlines or colons, which
> > could make parsing out filenames in this text file... fun. How would your
> > userspace parsing logic handle "/home/stephen/filename\nsize:\t4096"? The
> > readlink(2) API m
From: Mauro Carvalho Chehab
> Sent: 18 July 2022 15:54
>
> On Mon, 18 Jul 2022 14:16:10 +0100
> Tvrtko Ursulin wrote:
>
> > On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
> > > From: Chris Wilson
> > >
> > > Check if the device is powered down prior to any engine activity,
> > > as, on such
From: Tvrtko Ursulin
> Sent: 19 July 2022 08:25
...
> > It's not only the TLB flushes that cause grief.
> >
> > There is a loop that forces a write-back of all the frame buffer pages.
> > With a large display and some cpu (like my Ivy bridge one) that
> > takes long enough with pre-emption disabled
From: Christophe Leroy
> Sent: 08 January 2020 08:49
...
> And as pointed by Arnd, the volatile is really only necessary for the
> dereference itself, should the arch use dereferencing.
I've had trouble with some versions of gcc and reading of 'volatile unsigned
char *'.
It tended to follow the m
I've been looking at why some RT processes don't get scheduled promptly.
In my test the RT process's affinity ties it to a single cpu (this may not be
such
a good idea as it seems).
What I've found is that the Intel i915 graphics driver uses the 'events_unbound'
kernel worker thread to periodical
From: David Laight
> Sent: 13 January 2020 14:35
>
> I've been looking at why some RT processes don't get scheduled promptly.
> In my test the RT process's affinity ties it to a single cpu (this may not be
> such
> a good idea as it seems).
>
> What I&#
From: David Laight
> Sent: 16 January 2020 14:41
> > I'll do some measurements later this afternoon.
>
> This is an Ivy bridge cpu, so clflush (not clflushopt).
> With a cond_resched for every page I get:
> (Note these calls are every 10 seconds)
For comparison
From: Chris Wilson
> Sent: 16 January 2020 12:29
>
> Quoting David Laight (2020-01-16 12:26:45)
> > However there is a call from __i915_gem_objet_set_pages() that
> > is preceded by a lockdep_assert_held() check - so mustn't sleep.
>
> That is a mutex; it
> I'll do some measurements later this afternoon.
This is an Ivy bridge cpu, so clflush (not clflushopt).
With a cond_resched for every page I get:
(Note these calls are every 10 seconds)
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | |
flushing large objects takes a demonstrable amount to time
> > > to flush all the cachelines, clflush is still preferred over a
> > > system-wide wbinvd as the latter has unpredictable latencies affecting
> > > the whole system not just the local task.
> > >
re between 800MHz and 4GHz
depending on the whim of the hardware (probable at the low end).
Considerably faster, and enough that calling cond_resched() every 4k
is probably noticable.
So every 128 pages is probably a reasonable compromise.
David
> Reported-by: David Laight
> Sign
From: Sasha Levin
> Sent: 06 August 2019 22:33
>
> From: Colin Ian King
>
> [ Upstream commit 1bbbab097a05276e312dd2462791d32b21ceb1ee ]
>
> Currently the retry counter is not being decremented, leading to a
> potential infinite spin if the scalar_reads don't change state.
>
> Addresses-Coveri
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: 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
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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 <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: 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: 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: 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: 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: Logan Gunthorpe
> Sent: 13 April 2017 23:05
> Straightforward conversion to the new helper, except due to
> the lack of error path, we have to warn if unmapable memory
> is ever present in the sgl.
>
> Signed-off-by: Logan Gunthorpe
> ---
> drivers/block/xen-blkfront.c | 33 +++
From: Peilin Ye
> Sent: 28 July 2020 12:52
> Currently `struct drm_buf_desc` is defined as follows:
>
> struct drm_buf_desc {
> int count;
> int size;
> int low_mark;
> int high_mark;
> enum {
> _DRM_PAGE_ALIGN = 0x01,
> _DRM_AGP_BUFFER = 0
From: Sebastian Andrzej Siewior
> Sent: 01 May 2020 11:42
> On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for ma
From: Christoph Hellwig
> Sent: 04 May 2020 17:03
>
> On Sun, May 03, 2020 at 09:20:19PM +0100, Chris Wilson wrote:
> > > Err, why does i915 implements its own uncached memcpy instead of relying
> > > on core functionality to start with?
> >
> > What is this core functionality that provides movntq
From: Charan Teja Kalla
> Sent: 17 June 2020 07:29
...
> >> If name is freed you will copy garbage, but the only way
> >> for that to happen is that _set_name or _release have to be called
> >> at just the right time.
> >>
> >> And the above would probably only be an issue if the set_name
> >> was
From: Melissa Wen
> Sent: 21 March 2020 20:37
> The previous memset operation was not correctly setting zero on the
> alpha channel to compute the crc, and as a result, the
> pipe-A-cursor-alpha-transparent subtest of the IGT test kms_cursor_crc
> was crashing. To avoid errors of misinterpretation
From: Christian König
> Sent: 15 April 2020 08:57
> Am 15.04.20 um 09:41 schrieb Jani Nikula:
> > On Tue, 14 Apr 2020, Alex Deucher wrote:
> >> On Tue, Apr 14, 2020 at 9:05 AM Bernard Zhao wrote:
> >>> On some processors, the / operate will call the compiler`s div lib,
> >>> which is low efficien
> On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > Hi all,
> >
> > syzbot has reported [1] a global out-of-bounds read issue in
> > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> > value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
> >
From: Behalf Of Ken Helias
> All other add functions for lists have the new item as first argument and the
> position where it is added as second argument. This was changed for no good
> reason in this function and makes using it unnecessary confusing.
>
> Also the naming of the arguments in hlist
From: Bin Meng
> Sent: 08 October 2018 13:34
> Hi David,
>
> On Mon, Oct 8, 2018 at 6:06 PM David Laight wrote:
> >
> > From: Bin Meng
> > > Sent: 08 October 2018 10:44
> > ...
> > > Correct, disable the shared interrupt line keeps all devices usin
From: Bin Meng
> Sent: 08 October 2018 10:44
...
> Correct, disable the shared interrupt line keeps all devices using
> that line from working, which is current kernel's behavior w/o this
> quirk handling: it disables the (shared) interrupt line after 100.000+
> generated interrupts. But the side e
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
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
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
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
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
#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
-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
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
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, 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
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
1 - 100 of 178 matches
Mail list logo
