Please CC me on future revisions.
As of 6.2, the prandom namespace is *only* for predictable randomness.
There's no need to rename anything. So nack on this patch 1/5.
With regards to the remaining patches in this series, if you want to
move prandom_u32_state callers over to get_random_bytes()
Hey again,
On Wed, Nov 16, 2022 at 01:36:00AM +0100, Jason A. Donenfeld wrote:
> I'm a bit surprised that this patch was ignored. I had sort of assumed
Mystery solved: this message to you bounced from this linux.ie address I
somehow wound up with in the recipients list. Fixing now by us
this again.
The original message is reproduced in full below.
Regards,
Jason
On Sat, Nov 05, 2022 at 11:20:12PM +0100, Jason A. Donenfeld wrote:
> This reverts 26b1d3b527e7 ("drm/atomic: Take the atomic toys away from
> X"), a rootkit-like kludge that has no business being inside of
Cc: Adam Jackson
Cc: Greg Kroah-Hartman
Cc: Sean Paul
Cc: David Airlie
Cc: Rob Clark
Cc: Sultan Alsawaf
Signed-off-by: Jason A. Donenfeld
---
drivers/gpu/drm/drm_ioctl.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index
On Sat, Nov 05, 2022 at 12:36:42PM -0400, Steven Rostedt wrote:
> --8<
> @@
> identifier ptr, timer, rfield, slab;
> @@
> (
> - del_timer(>timer);
> + timer_shutdown(>timer);
> |
> - del_timer_sync(>timer);
> +
On Mon, Oct 24, 2022 at 8:29 PM Helge Deller wrote:
>
> On 10/24/22 18:29, Jason A. Donenfeld wrote:
> > 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.
dex]->ROMMODEIDX661' is unsigned
Cc: Thomas Winischhofer
Cc: Greg Kroah-Hartman
Cc: Helge Deller
Cc: linux-...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jason A. Donenfeld
---
drivers/usb/misc/sisusbvga/sisusb_struct.h | 2 +-
drivers/video/fbd
On Tue, Oct 11, 2022 at 01:18:40AM +, Elliott, Robert (Servers) wrote:
>
> > diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> ...
> > @@ -944,7 +944,7 @@ static void generate_random_bytes(u8 *buf, size_t count)
> > default:
> > /* Fully random bytes */
> > for (i
With no callers left of prandom_u32() and prandom_bytes(), as well as
get_random_int(), remove these deprecated wrappers, in favor of
get_random_u32() and get_random_bytes().
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kees Cook
Reviewed-by: Yury Norov
Signed-off-by: Jason A. Donenfeld
Kroah-Hartman
Reviewed-by: Kees Cook
Reviewed-by: Yury Norov
Reviewed-by: Christophe Leroy # powerpc
Signed-off-by: Jason A. Donenfeld
---
arch/powerpc/crypto/crc-vpmsum_test.c | 2 +-
block/blk-crypto-fallback.c | 2 +-
crypto/async_tx/raid6test.c | 2
# for thunderbolt
Acked-by: Darrick J. Wong # for xfs
Signed-off-by: Jason A. Donenfeld
---
Documentation/networking/filter.rst| 2 +-
arch/parisc/kernel/process.c | 2 +-
arch/parisc/kernel/sys_parisc.c| 4 ++--
arch/s390/mm/mmap.c
in a non-32-bit context.
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kees Cook
Reviewed-by: Yury Norov
Signed-off-by: Jason A. Donenfeld
---
arch/s390/kernel/process.c | 2 +-
drivers/mtd/nand/raw/nandsim.c | 2 +-
lib/test_vmalloc.c | 2 +-
net/rds/bind.c | 2
literal_mask.LITERAL;
position literal_mask.p;
identifier add_one.RESULT;
identifier FUNC;
@@
- (FUNC()@p & (LITERAL))
+ (RESULT() & LITERAL)
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kees Cook
Reviewed-by: Yury Norov
Acked-by: Toke Høiland-Jørgensen
-by: Greg Kroah-Hartman
Reviewed-by: Kees Cook
Reviewed-by: Yury Norov
Reviewed-by: Jan Kara # for ext2, ext4, and sbitmap
Signed-off-by: Jason A. Donenfeld
---
fs/ext2/ialloc.c | 3 +--
fs/ext4/ialloc.c | 5 ++---
lib/sbitmap.c | 2 +-
lib/test_vmalloc.c | 17 -
4
iewed-by: Christoph Böhmwalder # for drbd
Acked-by: Ulf Hansson # for mmc
Acked-by: Darrick J. Wong # for xfs
Signed-off-by: Jason A. Donenfeld
---
arch/arm/kernel/process.c | 2 +-
arch/arm64/kernel/process.c | 2 +-
arch/loongarch/kernel/pr
lists.linux.dev
Cc: net...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Jason A. Donenfeld (7):
treewide: use prandom_u32_max() when possible, part 1
treewide: use prandom_u32_max() when possible, part 2
treewide: use get_random_{u8,u16}() when possible, part 1
treewide:
On Sat, Oct 08, 2022 at 08:41:14PM -0700, Kees Cook wrote:
> On Fri, Oct 07, 2022 at 11:53:52PM -0600, Jason A. Donenfeld wrote:
> > This is a five part treewide cleanup of random integer handling. The
> > rules for random integers are:
>
> Reviewing the delta between of my
On Sat, Oct 08, 2022 at 09:53:33PM +, David Laight wrote:
> 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 tre
On Sat, Oct 8, 2022 at 4:37 PM Jason A. Donenfeld wrote:
>
> On Sat, Oct 08, 2022 at 10:18:45PM +, David Laight wrote:
> > From: Jason A. Donenfeld
> > > Sent: 07 October 2022 19:01
> > >
> > > The prandom_u32() function has been a deprecated inl
On Sat, Oct 08, 2022 at 10:18:45PM +, David Laight wrote:
> 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
On Sat, Oct 08, 2022 at 10:08:03PM +, David Laight wrote:
> 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
With no callers left of prandom_u32() and prandom_bytes(), as well as
get_random_int(), remove these deprecated wrappers, in favor of
get_random_u32() and get_random_bytes().
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 11 +--
include/linux
Reviewed-by: Christophe Leroy # powerpc
Signed-off-by: Jason A. Donenfeld
---
arch/powerpc/crypto/crc-vpmsum_test.c | 2 +-
block/blk-crypto-fallback.c | 2 +-
crypto/async_tx/raid6test.c | 2 +-
drivers/dma/dmatest.c | 2
-by: Jason A. Donenfeld
---
Documentation/networking/filter.rst| 2 +-
arch/parisc/kernel/process.c | 2 +-
arch/parisc/kernel/sys_parisc.c| 4 ++--
arch/s390/mm/mmap.c| 2 +-
arch/x86/kernel/cpu/amd.c
in a non-32-bit context.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
arch/s390/kernel/process.c | 2 +-
lib/test_vmalloc.c | 2 +-
net/ipv4/ip_output.c| 2 +-
net/netfilter/nf_nat_core.c | 4 ++--
net/rds/bind.c | 2 +-
net/sched/sch_sfb.c
e mask of %s" % (literal))
cocci.include_match(False)
// Replace the literal mask with the calculated result.
@plus_one@
expression literal_mask.LITERAL;
position literal_mask.p;
identifier add_one.RESULT;
identifier FUNC;
@@
- (FUNC()@p & (LITERAL))
+ (RESULT() & LITERAL)
-by: Kees Cook
Reviewed-by: Jan Kara # for ext2, ext4, and sbitmap
Signed-off-by: Jason A. Donenfeld
---
fs/ext2/ialloc.c | 3 +--
fs/ext4/ialloc.c | 5 ++---
lib/sbitmap.c | 2 +-
lib/test_vmalloc.c | 17 -
4 files changed, 8 insertions(+), 19 deletions(-)
diff --git
identifier VAR;
@@
{
- T VAR;
... when != VAR
}
Reviewed-by: Kees Cook
Reviewed-by: KP Singh
Reviewed-by: Jan Kara # for ext4 and sbitmap
Reviewed-by: Christoph Böhmwalder # for drbd
Acked-by: Ulf Hansson # for mmc
Acked-by: Darrick J. Wong # for xfs
Signed-off-by: J
x.dev
Cc: net...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Jason A. Donenfeld (7):
treewide: use prandom_u32_max() when possible, part 1
treewide: use prandom_u32_max() when possible, part 2
treewide: use get_random_{u8,u16}() when possible, part 1
treewide: use g
On Fri, Oct 07, 2022 at 03:47:44PM -0700, Kees Cook wrote:
> > diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
> > index 4f2f2d1bac56..56ffaa8dd3f6 100644
> > --- a/lib/test_vmalloc.c
> > +++ b/lib/test_vmalloc.c
> > @@ -151,9 +151,7 @@ static int random_size_alloc_test(void)
> > int i;
>
On Fri, Oct 07, 2022 at 03:47:44PM -0700, Kees Cook wrote:
> On Fri, Oct 07, 2022 at 12:01:03PM -0600, Jason A. Donenfeld wrote:
> > Rather than incurring a division or requesting too many random bytes for
> > the given range, use the prandom_u32_max() function, which only takes
On Fri, Oct 07, 2022 at 10:34:47PM +0200, Rolf Eike Beer wrote:
> > diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
> > index 7c37e09c92da..18c4f0e3e906 100644
> > --- a/arch/parisc/kernel/process.c
> > +++ b/arch/parisc/kernel/process.c
> > @@ -288,7 +288,7 @@
On Fri, Oct 07, 2022 at 02:17:22PM -0700, Darrick J. Wong wrote:
> On Fri, Oct 07, 2022 at 12:01:03PM -0600, Jason A. Donenfeld wrote:
> > Rather than incurring a division or requesting too many random bytes for
> > the given range, use the prandom_u32_max() function, w
With no callers left of prandom_u32() and prandom_bytes(), as well as
get_random_int(), remove these deprecated wrappers, in favor of
get_random_u32() and get_random_bytes().
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 11 +--
include/linux
Signed-off-by: Jason A. Donenfeld
---
arch/powerpc/crypto/crc-vpmsum_test.c | 2 +-
block/blk-crypto-fallback.c | 2 +-
crypto/async_tx/raid6test.c | 2 +-
drivers/dma/dmatest.c | 2 +-
drivers/mtd/nand/raw/nandsim.c | 2
around get_random_u32().
Reviewed-by: Kees Cook
Acked-by: Toke Høiland-Jørgensen # for sch_cake
Acked-by: Chuck Lever # for nfsd
Reviewed-by: Jan Kara # for ext4
Acked-by: Mika Westerberg # for thunderbolt
Signed-off-by: Jason A. Donenfeld
---
Documentation/networking/filter.rst| 2
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Reviewed-by: Kees Cook
Acked-by: Toke Høiland-Jørgensen # for sch_cake
Signed-off-by: Jason
Reviewed-by: Jan Kara # for ext2, ext4, and sbitmap
Signed-off-by: Jason A. Donenfeld
---
arch/arm64/kernel/process.c | 2 +-
arch/loongarch/kernel/process.c | 2 +-
arch/loongarch/kernel/vdso.c | 2 +-
arch/mips/kernel/process.c | 2 +-
arch/mips/kernel
-by: Kees Cook
Reviewed-by: KP Singh
Reviewed-by: Jan Kara # for ext4 and sbitmap
Acked-by: Ulf Hansson # for mmc
Signed-off-by: Jason A. Donenfeld
---
arch/arm/kernel/process.c | 2 +-
arch/s390/kernel/vdso.c | 2 +-
arch/um/kernel/process.c
ozlabs.org
Cc: loonga...@lists.linux.dev
Cc: net...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Jason A. Donenfeld (6):
treewide: use prandom_u32_max() when possible, mechanically
treewide: use prandom_u32_max() when possible
treewide: use get_random_{u8,u16}() when
On Fri, Oct 07, 2022 at 10:12:42AM -0700, Kees Cook wrote:
> On Fri, Oct 07, 2022 at 08:07:58AM -0600, Jason A. Donenfeld wrote:
> > On Fri, Oct 07, 2022 at 04:57:24AM +, Christophe Leroy wrote:
> > >
> > >
> > > Le 07/10/2022 à 01:36, Jason A. Do
On Fri, Oct 07, 2022 at 04:57:24AM +, Christophe Leroy wrote:
>
>
> Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > On 10/6/22, Christophe Leroy wrote:
> >>
> >>
> >> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
> >>>
On Thu, Oct 06, 2022 at 10:43:31AM +0200, Jan Kara wrote:
> The code here is effectively doing the
>
> parent_group = prandom_u32_max(ngroups);
>
> Similarly here we can use prandom_u32_max(ngroups) like:
>
> if (qstr) {
> ...
>
Hi Kees,
On Wed, Oct 05, 2022 at 09:16:50PM -0700, Kees Cook wrote:
> On Wed, Oct 05, 2022 at 11:48:40PM +0200, Jason A. Donenfeld wrote:
> > Rather than incurring a division or requesting too many random bytes for
> > the given range, use the prandom_u32_max() function, w
A v2 that won't murder your mail setup is now available here:
https://lore.kernel.org/lkml/20221006132510.23374-1-ja...@zx2c4.com/
Please do not (attempt to) post more replies to v1, as it kicks up a
storm of angry MTAs.
On Wed, Oct 05, 2022 at 09:38:02PM -0700, Kees Cook wrote:
> > diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
> > index 56ffaa8dd3f6..0131ed2cd1bd 100644
> > --- a/lib/test_vmalloc.c
> > +++ b/lib/test_vmalloc.c
> > @@ -80,7 +80,7 @@ static int random_size_align_alloc_test(void)
> > int
On Wed, Oct 05, 2022 at 09:55:43PM -0700, Kees Cook wrote:
> It'd be nice to capture some (all?) of the above somewhere. Perhaps just
> a massive comment in the header?
I'll include (something like) this in some "how to use" documentation
I'm working on separately.
> > I've CC'd
On Thu, Oct 6, 2022 at 7:01 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 06, 2022 at 06:33:15AM -0600, Jason A. Donenfeld wrote:
> > On Thu, Oct 06, 2022 at 10:43:31AM +0200, Jan Kara wrote:
>
> ...
>
> > > The code here is effectively doing the
> > >
> >
On Thu, Oct 6, 2022 at 6:47 AM Jason Gunthorpe wrote:
>
> On Wed, Oct 05, 2022 at 11:48:42PM +0200, Jason A. Donenfeld wrote:
>
> > index 14392c942f49..499a425a3379 100644
> > --- a/drivers/infiniband/hw/cxgb4/cm.c
> > +++ b/drivers/infiniband/hw/cxgb4/cm.c
> &g
On 10/6/22, Bagas Sanjaya wrote:
> On 10/6/22 23:53, Jason A. Donenfeld wrote:
>> The prandom_bytes() function has been a deprecated inline wrapper around
>> get_random_bytes() for several releases now, and compiles down to the
>> exact same code. Replace the deprecated wrapp
On 10/6/22, Christophe Leroy wrote:
>
>
> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
>>
>>
>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
>>> Hi Christophe,
>>>
>>> On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
>>>
Hi Christophe,
On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
wrote:
> Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> > The prandom_u32() function has been a deprecated inline wrapper around
> > get_random_u32() for several releases now, and compiles down to the
>
With no callers left of prandom_u32() and prandom_bytes(), as well as
get_random_int(), remove these deprecated wrappers, in favor of
get_random_u32() and get_random_bytes().
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 11 +--
include/linux
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
around get_random_u32().
Reviewed-by: Kees Cook
Acked-by: Toke Høiland-Jørgensen # for sch_cake
Acked-by: Chuck Lever # for nfsd
Reviewed-by: Jan Kara # for ext4
Signed-off-by: Jason A. Donenfeld
---
Documentation/networking/filter.rst| 2 +-
arch/arm64/kernel/process.c
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Reviewed-by: Kees Cook
Acked-by: Toke Høiland-Jørgensen # for sch_cake
Signed-off-by: Jason
Reviewed-by: Jan Kara # for ext2, ext4, and sbitmap
Signed-off-by: Jason A. Donenfeld
---
arch/arm/kernel/process.c | 2 +-
arch/loongarch/kernel/vdso.c | 2 +-
arch/mips/kernel/vdso.c | 2 +-
arch/parisc/kernel/vdso.c
ux-r...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-wirel...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: loonga...@lists.linux.dev
Cc: net...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
J
FYI, v3, which I'll wait a bit before posting, will also take care of
get_random_int().
On Thu, Oct 6, 2022 at 7:25 AM Jason A. Donenfeld wrote:
> This is a five part treewide cleanup of random integer handling.
> [...]
> Please take a look!
I should add that this patchset probably appears bigger than it
already is, due in part to that wall of motivational text. Kee
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
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.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
With no callers left of prandom_u32() and prandom_bytes(), remove these
deprecated wrappers.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
include/linux/prandom.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
crypto/testmgr.c
-by: Jason A. Donenfeld
---
arch/x86/mm/pat/cpa-test.c| 4 +-
crypto/testmgr.c | 86 +--
drivers/block/drbd/drbd_receiver.c| 4 +-
drivers/infiniband/core/cma.c | 2 +-
drivers/infiniband/hw/cxgb4
c: linux-n...@lists.infradead.org
Cc: linux-r...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Jason A. Donenfeld (5):
treewide: use prandom_u32_max() when possible
treewide: use get_random_{u8,u16}() when possible
treewide: use get_
With no callers left of prandom_u32() and prandom_bytes(), remove these
deprecated wrappers.
Signed-off-by: Jason A. Donenfeld
---
include/linux/prandom.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index 78db003bc290
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Signed-off-by: Jason A. Donenfeld
---
arch/powerpc/crypto/crc
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.
Signed-off-by: Jason A. Donenfeld
---
Documentation/networking
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Signed-off-by: Jason A. Donenfeld
---
crypto/testmgr.c | 8
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.
Signed-off-by: Jason A. Donenfeld
---
arch/x86/mm/pat/cpa-test.c| 4
Hi Daniel,
On Mon, Jun 27, 2022 at 11:08:32AM +0200, Daniel Vetter wrote:
> On Sat, Jun 25, 2022 at 01:01:14PM +0200, Jason A. Donenfeld wrote:
> > This is already set by anon_inode_getfile(), since dma_buf_fops has
> > non-NULL ->llseek, so we don't need to set it here too.
This is already set by anon_inode_getfile(), since dma_buf_fops has
non-NULL ->llseek, so we don't need to set it here too.
Suggested-by: Al Viro
Cc: Sumit Semwal
Cc: Christian König
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jason A. Donenfeld
---
drivers/dma-buf/dma-buf.c | 1 -
This is already on by default.
Suggested-by: Al Viro
Cc: Sumit Semwal
Cc: Christian König
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jason A. Donenfeld
---
drivers/dma-buf/dma-buf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma
Hi Jani,
On Mon, Jun 20, 2022 at 07:10:30PM +0300, Jani Nikula wrote:
> On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote:
> > Hi Jani,
> >
> > Do you plan to merge this revert?
>
> Yes, I've done that now, thanks for the bisection and the patch.
Thanks!
Hi Jani,
Do you plan to merge this revert?
Thanks,
Jason
Hi Jani,
On Mon, Jun 13, 2022 at 02:05:17PM +0300, Jani Nikula wrote:
> On Mon, 13 Jun 2022, "Jason A. Donenfeld" wrote:
> > This reverts commit 73867c8709b569cdd7fda67f01dfe02c8d055521, which, on
> > an i7-11850H iGPU with a Thinkpad X1 Extreme Gen 4, attached to a LG
&
to this commit, which makes sense given the
issues.
Fixes: 73867c8709b5 ("drm/i915/display: Remove check for low voltage sku for
max dp source rate")
Cc: Ankit Nautiyal
Cc: Imre Deak
Cc: Jani Nikula
Cc: Uma Shankar
Cc: Animesh Manna
Cc: Jani Saarinen
Signed-off-by: Jason A.
Done. https://gitlab.freedesktop.org/drm/intel/-/issues/6205
FWIW, I found that reverting the two drm merges (with `git revert -m`)
from 5.19-rc1 "fixed" the issue.
Hi,
Using the i7-11850H's iGPU, when I wake my Thinkpad X1 Extreme Gen 4
from suspend on 5.19-rc1, the display shows wild flickering with
strobing colors and more artifacts than real pixels in an utter
disaster explosion of pantone, as though bombs were dropped on the
leprechauns at the base of
Hi Daniele,
I'll give it a whirl on my laptop. Thanks.
Jason
Hey Intel PXPers,
I hit this splat on 5.16-rc1 during system suspend:
Nov 22 13:54:09 thinkpad systemd-logind[934]: Lid closed.
Nov 22 13:54:09 thinkpad systemd[1]: Reached target Sleep.
Nov 22 13:54:09 thinkpad systemd[1]: Starting System Suspend...
Nov 22 13:54:09 thinkpad
For the drivers/net/wireguard part,
Reviewed-by: Jason A. Donenfeld
rk+0x1f/0x30
CR2: 0064
This commit fixes the problem by using the mm pointer passed to the
function rather than the bogus one in current.
Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
Cc: Jason Gunthorpe
Cc: Peter Xu
Signed-off-by: Jason A. Donenfeld
---
m
Oh, this is just a copy and paste error, when the code was originally
pasted from internal_get_user_pages_fast, which assumes a current.
I'll fix this up and send a patch shortly.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
[ 1311.596896] BUG: kernel NULL pointer dereference, address: 0064
[ 1311.596898] #PF: supervisor write access in kernel mode
[ 1311.596899] #PF: error_code(0x0002) - not-present page
[ 1311.596899] PGD 0 P4D 0
[ 1311.596901]
Increasing the CC list a bit, as i915 didn't really get much churn
rc6->rc7, but mm/gup.c did, and mm has had a lot of recent changes.
On Mon, Sep 28, 2020 at 11:39 AM Jason A. Donenfeld wrote:
>
> Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
>
> [ 1311.596896] B
Alright, the failing code seems to be in mm:
if (flags & FOLL_PIN)
atomic_set(>mm->has_pinned, 1);
Apparently you can't rely on current->mm being valid in this context;
it's null here, hence the +0x64 for has_pinned's offset.
This was added by 008cfe4418b3 ("mm:
On Sun, May 3, 2020 at 2:30 PM Chris Wilson wrote:
>
> Quoting Jason A. Donenfeld (2020-04-30 23:10:16)
> > 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 t
On Fri, May 1, 2020 at 4:42 AM Sebastian Andrzej Siewior
wrote:
>Reviewed-by: Sebastian Andrzej Siewior
Thanks.
>
> May I ask how large the memcpy can be? I'm asking in case it is large
> and an explicit rescheduling point might be needed.
Yea I was worried about that too. I'm not an i915
On Fri, May 1, 2020 at 12:07 PM Christoph Hellwig wrote:
>
> On Thu, Apr 30, 2020 at 04:10:16PM -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. Usual
fixes up i915's accelerated memcpy routines to fallback
to boring memcpy if may_use_simd() is false.
Cc: sta...@vger.kernel.org
Signed-off-by: Jason A. Donenfeld
---
drivers/gpu/drm/i915/i915_memcpy.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915
On Tue, Apr 21, 2020 at 09:38:09AM -0700, Sultan Alsawaf wrote:
> Why hasn't this bug got any attention:
> https://gitlab.freedesktop.org/drm/intel/issues/1412
>
> That seems like a showstopper.
Indeed, pretty shocking. It's worth mentioning that the reporter of said
bug, after significant time
On Sat, Mar 28, 2020 at 1:59 AM Chris Wilson wrote:
>
> Quoting Jason A. Donenfeld (2020-03-28 00:04:22)
> > It's not safe to just grab the FPU willy nilly without first checking to
> > see if it's available. This patch adds the usual call to may_use_simd()
> > and fal
It's not safe to just grab the FPU willy nilly without first checking to
see if it's available. This patch adds the usual call to may_use_simd()
and falls back to boring memcpy if it's not available.
Signed-off-by: Jason A. Donenfeld
---
drivers/gpu/drm/i915/i915_memcpy.c | 12
1
Hi,
In upgrading from 5.1.1 to 5.3.6, I'm seeing the following in my dmesg
when resuming from sleep, which is accompanied by a slight hang too.
Is anybody else seeing this?
Thanks,
Jason
[ 46.618138] nouveau :01:00.0: timeout
[ 46.618183] WARNING: CPU: 4 PID: 993 at
Hi Greg,
On Thu, Dec 15, 2016 at 8:10 PM, Greg KH wrote:
> I'll take it after 4.10-rc1 is out, thanks.
Thank you!
Jason
t;2.4
Atomic Counting With Check and Release Memory Barrier", which uses
atomic_inc_not_zero.
[1] http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2167.pdf
Signed-off-by: Jason A. Donenfeld
Reviewed-by: Thomas Hellstrom
Reviewed-by: Christoph Hellwig
---
Sorry to submit this again,
t;2.4
Atomic Counting With Check and Release Memory Barrier", which uses
atomic_inc_not_zero.
[1] http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2167.pdf
Signed-off-by: Jason A. Donenfeld
Reviewed-by: Thomas Hellstrom
---
This was reviewed favorably 14 months ago but never pick
1 - 100 of 101 matches
Mail list logo
