RE: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

2021-03-24 Thread David Laight
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

RE: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

2021-03-24 Thread David Laight
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

RE: [PATCH 02/13] module: add a module_loaded helper

2021-01-22 Thread David Laight
> > 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

RE: DMA-buf and uncached system memory

2021-02-15 Thread David Laight
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

RE: Linux 5.10-rc4; graphics alignment

2020-11-25 Thread David Laight
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

RE: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL

2020-11-03 Thread David Laight
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

RE: Linux 5.10-rc4

2020-11-19 Thread David Laight
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

RE: Linux 5.10-rc4

2020-11-19 Thread David Laight
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. > >

RE: Linux 5.10-rc4

2020-11-19 Thread David Laight
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: > >

RE: Linux 5.10-rc4; graphics alignment

2020-11-21 Thread David Laight
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

RE: Linux 5.10-rc4; graphics alignment

2020-11-21 Thread David Laight
> 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

RE: Linux 5.10-rc4; graphics alignment

2020-11-21 Thread David Laight
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

RE: Linux 5.10-rc4; graphics alignment

2020-11-21 Thread David Laight
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

RE: Linux 5.10-rc4; graphics alignment

2020-11-21 Thread David Laight
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

RE: [RFC v3 7/8] binder: use __kernel_pid_t and __kernel_uid_t for userspace

2022-03-15 Thread David Laight
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

RE: [PATCH] drm/amdgpu: Fix realloc of ptr

2022-02-26 Thread David Laight
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

RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread David Laight
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

RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread David Laight
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

RE: [PATCH] devcoredump: increase the device delete timeout to 10 mins

2022-02-28 Thread David Laight
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

RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-01 Thread David Laight
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

RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-01 Thread David Laight
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

RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-02 Thread David Laight
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

RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-02 Thread David Laight
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

RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread David Laight
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

RE: [PATCH RFC 0/3] MAP_POPULATE for device memory

2022-03-06 Thread David Laight
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

RE: [PATCH 0/6] Remove usage of list iterator past the loop body

2022-03-07 Thread David Laight
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

RE: [PATCH RFC 0/3] MAP_POPULATE for device memory

2022-03-07 Thread David Laight
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

RE: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation

2022-01-19 Thread David Laight
> > > +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)

RE: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation

2022-01-19 Thread David Laight
> > > > +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)

RE: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation

2022-01-19 Thread David Laight
> > 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)

RE: [PATCH 0/3] lib/string_helpers: Add a few string helpers

2022-01-20 Thread David Laight
... > 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 > >

RE: [PATCH v2] fbdev: fbmem: Fix the implicit type casting

2022-02-02 Thread David Laight
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

RE: [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy

2020-12-14 Thread David Laight
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

RE: [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy

2020-12-14 Thread David Laight
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

RE: [PATCH v2 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags

2019-05-09 Thread David Laight
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, > -

RE: [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be separated by lines '|'

2019-04-11 Thread David Laight
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

RE: [PATCH 3/4] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags

2019-04-16 Thread David Laight
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

RE: [PATCH 1/4] lib/hexdump.c: Allow 64 bytes per line

2019-04-16 Thread David Laight
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

RE: [PATCH 3/4] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags

2019-04-16 Thread David Laight
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

RE: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous

2019-06-14 Thread David Laight
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

RE: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous

2019-06-14 Thread David Laight
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

RE: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous

2019-06-14 Thread David Laight
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

RE: [PATCH v2 1/2] module: update dependencies at try_module_get()

2022-05-01 Thread David Laight
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) > > > +

RE: mainline build failure for x86_64 allmodconfig with clang

2022-08-05 Thread David Laight
... > * 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,

RE: mainline build failure for x86_64 allmodconfig with clang

2022-08-07 Thread David Laight
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

RE: [PATCH] drm/amd/display: fix i386 frame size warning

2022-08-24 Thread David Laight
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- >

RE: [PATCH 2/2] procfs: Add 'path' to /proc//fdinfo/

2022-06-01 Thread David Laight
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

RE: [Intel-gfx] [PATCH v2 01/21] drm/i915/gt: Ignore TLB invalidations on idle engines

2022-07-18 Thread David Laight
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

RE: [Intel-gfx] [PATCH v2 01/21] drm/i915/gt: Ignore TLB invalidations on idle engines

2022-07-19 Thread David Laight
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

RE: [RFT 00/13] iomap: Constify ioreadX() iomem argument

2020-01-09 Thread David Laight
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

drm_cflush_sg() loops for over 3ms

2020-01-14 Thread David Laight
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

RE: drm_cflush_sg() loops for over 3ms - scheduler not running tasks.

2020-01-14 Thread David Laight
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&#

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-17 Thread David Laight
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

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-17 Thread David Laight
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

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-17 Thread David Laight
> 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 # | | |

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-17 Thread David Laight
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: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-24 Thread David Laight
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

RE: [PATCH AUTOSEL 5.2 51/59] drm/exynos: fix missing decrement of retry counter

2019-08-07 Thread David Laight
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

RE: [PATCH] drm/ssd130x: Silence a `dubious: x & !y` warning

2023-01-23 Thread David Laight
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:

RE: [PATCH v3 3/5] treewide: use get_random_u32() when possible

2022-10-07 Thread David Laight
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

RE: [PATCH v3 3/5] treewide: use get_random_u32() when possible

2022-10-08 Thread David Laight
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

RE: [PATCH v4 2/6] treewide: use prandom_u32_max() when possible

2022-10-08 Thread David Laight
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

RE: [PATCH v4 4/6] treewide: use get_random_u32() when possible

2022-10-08 Thread David Laight
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

RE: [PATCH v1 3/5] treewide: use get_random_u32() when possible

2022-10-12 Thread David Laight
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

RE: [PATCH] video: fbdev: sis: use explicitly signed char

2022-10-25 Thread David Laight
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

RE: [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

2022-12-12 Thread David Laight
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

RE: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

2023-01-05 Thread David Laight
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 > >> > > >> >

RE: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

2023-01-05 Thread David Laight
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)

RE: [PATCH 0/4] log2: make is_power_of_2() more generic

2023-03-30 Thread David Laight
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

RE: [PATCH 0/4] log2: make is_power_of_2() more generic

2023-03-31 Thread David Laight
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 -

RE: [PATCH v7 1/7] fbdev/hitfb: Cast I/O offset to address

2023-05-12 Thread David Laight
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

RE: [PATCH] drm/drm_vblank.c: avoid unsigned int to signed int cast

2023-05-17 Thread David Laight
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.

RE: [PATCH] drm/drm_vblank.c: avoid unsigned int to signed int cast

2023-05-22 Thread David Laight
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; > > > >

RE: [PATCH] drm/drm_vblank.c: avoid unsigned int to signed int cast

2023-05-23 Thread David Laight
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

RE: [PATCH v4 1/1] drm/i915: Move abs_diff() to math.h

2023-08-04 Thread David Laight
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 +

RE: [PATCH] udmabuf: revert 'Add support for mapping hugepages (v4)'

2023-06-13 Thread David Laight
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

RE: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-15 Thread David Laight
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

RE: [PATCH v3 3/4] drm/mediatek: Add casting before assign

2023-07-17 Thread David Laight
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 > > >

RE: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

2017-04-18 Thread David Laight
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 +++

RE: [Linux-kernel-mentees] [PATCH v2] drm/bufs: Prevent kernel-infoleak in copy_one_buf()

2020-07-28 Thread David Laight
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

RE: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

2020-05-02 Thread David Laight
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

RE: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

2020-05-04 Thread David Laight
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

RE: [PATCH] dmabuf: use spinlock to access dmabuf->name

2020-06-18 Thread David Laight
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

RE: [PATCH] drm/vkms: use bitfield op to get xrgb on compute crc

2020-03-24 Thread David Laight
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

RE: [PATCH] Optimized division operation to shift operation

2020-04-16 Thread David Laight
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

RE: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers

2020-09-25 Thread David Laight
> 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 > >

[PATCH] list: Fix order of arguments for hlist_add_after(_rcu)

2014-06-06 Thread David Laight
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

RE: [PATCH] pci: Add a few new IDs for Intel GPU "spurious interrupt" quirk

2018-10-09 Thread David Laight
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

RE: [PATCH] pci: Add a few new IDs for Intel GPU "spurious interrupt" quirk

2018-10-09 Thread David Laight
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

RE: arm: ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!

2024-03-09 Thread David Laight
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

RE: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags

2023-11-08 Thread David Laight
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

[PATCH next v2 00/11] minmax: Optimise to reduce .i line length

2024-02-25 Thread David Laight
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

[PATCH next v2 01/11] minmax: Put all the clamp() definitions together

2024-02-25 Thread David Laight
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

[PATCH next v2 02/11] minmax: Use _Static_assert() instead of static_assert()

2024-02-25 Thread David Laight
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

[PATCH next v2 03/11] minmax: Simplify signedness check

2024-02-25 Thread David Laight
#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

[PATCH next v2 04/11] minmax: Replace multiple __UNIQUE_ID() by directly using __COUNTER__

2024-02-25 Thread David Laight
-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

[PATCH next v2 05/11] minmax: Move the signedness check out of __cmp_once() and __clamp_once()

2024-02-25 Thread David Laight
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

[PATCH next v2 06/11] minmax: Remove 'constexpr' check from __careful_clamp()

2024-02-25 Thread 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 +++-

[PATCH next v2 07/11] minmax: minmax: Add __types_ok3() and optimise defines with 3 arguments

2024-02-25 Thread David Laight
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

[PATCH next v2 08/11] minmax: Add min_const() and max_const()

2024-02-25 Thread 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   2   >