On 07/10/2022 05:18, allen.c...@ite.com.tw wrote:
> hi
>
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Thursday, October 6, 2022 4:17 PM
> To: Allen Chen (陳柏宇)
> Cc: Jau-Chih Tseng (曾昭智) ; Kenneth Hung (洪家倫)
> ; Hermes Wu (吳佳宏) ; Pin-yen
> Lin ; Andrzej Hajda ; Neil
> Arms
Hi
Am 06.10.22 um 22:18 schrieb Javier Martinez Canillas:
Hello Thomas,
On 10/5/22 13:40, Thomas Zimmermann wrote:
In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the pl
Am 07.10.22 um 04:45 schrieb Dave Airlie:
On Fri, 7 Oct 2022 at 09:45, Linus Torvalds
wrote:
On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
[ 1234.778760] BUG: kernel NULL pointer dereference, address: 0088
[ 1234.778813] RIP: 0010:drm_sched_job_done.isra.0+0xc/0x140 [gpu_sche
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 :
>>>
>>>
>>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
Hi Christophe,
On Thu, Oct 6, 2022 at 11:21 AM Christophe Leroy
On Thu, Oct 06, 2022 at 09:55:19AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 06, 2022 at 06:45:25AM -0600, Jason A. Donenfeld wrote:
> > 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 incurri
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) {
> ...
> par
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, which only takes
> > the m
On Thu, Oct 06, 2022 at 06:45:25AM -0600, Jason A. Donenfeld wrote:
> 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
> > >
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 i
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 get_maintainers.p
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
> @@ -734,7 +734,7 @@ static int send_connect(struct c4iw_ep *ep)
> &ep->
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
> > >
> > > parent_group = prandom_u32_max(ngroups)
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
> > @@ -734,7 +734,7 @@ static int send_
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
> >
> > parent_group = prandom_u32_max(ngroups);
> >
> > Similarly here we can use prandom_u32_max(ngroups) like:
>
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 wrapper with a direct call
hi
-Original Message-
From: Krzysztof Kozlowski
Sent: Thursday, October 6, 2022 4:17 PM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智) ; Kenneth Hung (洪家倫)
; Hermes Wu (吳佳宏) ; Pin-yen Lin
; Andrzej Hajda ; Neil
Armstrong ; Robert Foss ;
Laurent Pinchart ; Jonas Karlman
; Jernej Skra
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 wrapper with a direct call to
> the real function.
>
> Reviewed-b
On Fri, 7 Oct 2022 at 12:54, Dave Airlie wrote:
>
> On Fri, 7 Oct 2022 at 12:45, Dave Airlie wrote:
> >
> > On Fri, 7 Oct 2022 at 09:45, Linus Torvalds
> > wrote:
> > >
> > > On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
> > > >
> > > >
> > > > [ 1234.778760] BUG: kernel NULL pointer derefe
Hi Linus,
This reverts the patch I found with rough bisection to instability
around fences and the oops I got from netconsole.
Christian, I tried the two patches from drm-next, but the oops still
occurred, a good reproducer for me was to run vulkan cts with
deqp-runner in parallel here.
Regards,
On Fri, 7 Oct 2022 at 12:45, Dave Airlie wrote:
>
> On Fri, 7 Oct 2022 at 09:45, Linus Torvalds
> wrote:
> >
> > On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
> > >
> > >
> > > [ 1234.778760] BUG: kernel NULL pointer dereference, address:
> > > 0088
> > > [ 1234.778813] RIP: 001
On Fri, 7 Oct 2022 at 09:45, Linus Torvalds
wrote:
>
> On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
> >
> >
> > [ 1234.778760] BUG: kernel NULL pointer dereference, address:
> > 0088
> > [ 1234.778813] RIP: 0010:drm_sched_job_done.isra.0+0xc/0x140 [gpu_sched]
>
> As far as I can
On Thu, 2022-10-06 at 10:01 +0200, Thomas Zimmermann wrote:
> Hi Zack
>
> Am 05.10.22 um 21:49 schrieb Zack Rusin:
> > Hi, Thomas.
> >
> > Because you've been the one who's been working on drm_fb_helper.c the most
> > the last
> > few years I wanted to pick your brain a bit.
> >
> > I was porti
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt.
But the caller does not notice that, it will free spt again in error path.
Fix this by spliting invalidate and free in ppgtt_invalidate_spt.
Only free spt when in good case.
Reported-by: Zh
Greg KH 于2022年10月7日周五 03:22写道：
>
> On Fri, Oct 07, 2022 at 12:58:45AM +0800, Zheng Wang wrote:
> > If intel_gvt_dma_map_guest_page failed, it will call
> > ppgtt_invalidate_spt, which will finally free the spt.
> > But the caller does not notice that, it will free spt again in error path.
> >
> >
On Thu, Oct 6, 2022 at 1:50 PM Sudip Mukherjee
wrote:
>
> > And it looks like Sudip's proposed fix for this particular code is
> > additionally fixing unsigned vs signed as well. I think -Warray-bounds
> > did its job (though, with quite a confusing index range in the report).
>
> Not my. Linus's.
On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
>
>
> [ 1234.778760] BUG: kernel NULL pointer dereference, address: 0088
> [ 1234.778813] RIP: 0010:drm_sched_job_done.isra.0+0xc/0x140 [gpu_sched]
As far as I can tell, that's the line
struct drm_gpu_scheduler *sched = s_fenc
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
>>> wrote:
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
On Tue, Oct 4, 2022 at 10:38 AM Jani Nikula wrote:
> Got any bug report with more info, or any other details to back this up?
> This is kind of thin. What's the 800 ms based on?
This issue affected several different CometLake-based Chrome OS device
designs. The details of the original report are
On Mon, 12 Sep 2022, Matthieu CHARETTE wrote:
> Hi,
>
> Sorry for late reply.
>
> How do you propose to go then?
> Can we still use a persistent platform device to load the firmware and
> cache it? But, in this case the system will still crash in case the
> user change drm.edid_firmware then, wi
We've used a temporary platform device for firmware EDID loading since
it was introduced in commit da0df92b5731 ("drm: allow loading an EDID as
firmware to override broken monitor"), but there's no explanation why.
Do we need to?
Maybe this fixes the suspend/resume issue?
(Yes, I'll rewrite the
On Fri, 7 Oct 2022 at 07:41, Dave Airlie wrote:
>
> On Fri, 7 Oct 2022 at 06:24, Dave Airlie wrote:
> >
> > On Fri, 7 Oct 2022 at 06:14, Alex Deucher wrote:
> > >
> > > On Thu, Oct 6, 2022 at 3:48 PM Linus Torvalds
> > > wrote:
> > > >
> > > > On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher
> >
On Fri, 7 Oct 2022 at 06:24, Dave Airlie wrote:
>
> On Fri, 7 Oct 2022 at 06:14, Alex Deucher wrote:
> >
> > On Thu, Oct 6, 2022 at 3:48 PM Linus Torvalds
> > wrote:
> > >
> > > On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher
> > > wrote:
> > > >
> > > > Maybe you are seeing this which is an issu
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence t
From: John Harrison
A workaround was added to the driver to allow compute workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.
However, this does not work well in
From: John Harrison
An earlier patch added support for compute engines. However, it missed
enabling the anti-pre-emption w/a for the new engine class. So move
the 'compute capable' flag earlier and use it for the pre-emption w/a
test.
Fixes: c674c5b9342e ("drm/i915/xehp: CCS should use RCS setup
From: John Harrison
Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to prevent
unwanted resets. Instead, the hang detection was left to the heartbeat
and its (longer) timeout. This is undesirable with GuC submission
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
On Wed, Oct 05, 2022 at 08:59:43AM -0700, Vinay Belgaumkar wrote:
> Read the values stored in the SLPC structures. Remove the
> fields that are no longer valid (like RPS interrupts) as
> well.
>
> v2: Move all functionality changes to this patch (Jani)
> v3: Fix compile warning and if condition (J
Hi Alex,
On Thu, 6 Oct 2022 09:56:32 -0400 Alex Deucher wrote:
>
> This looks good to me. Care to add you s-o-b?
>
> On Thu, Oct 6, 2022 at 4:12 AM Stephen Rothwell wrote:
> >
> > This works as well, and (in my opinion) is better:
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_str
On Thu, Oct 6, 2022 at 9:37 PM Kees Cook wrote:
>
> On Thu, Oct 06, 2022 at 12:39:40PM -0700, Linus Torvalds wrote:
> > What confuses me is that error message ("array subscript [0, 0] is
> > outside array bounds of 'struct dc_writeback_info[1]') which seems to
> > be aware that the value is actual
On Thu, Oct 06, 2022 at 12:39:40PM -0700, Linus Torvalds wrote:
> What confuses me is that error message ("array subscript [0, 0] is
> outside array bounds of 'struct dc_writeback_info[1]') which seems to
> be aware that the value is actually 0.
I've seen bugs in the tracker where the reporting is
On 10/5/22 13:40, Thomas Zimmermann wrote:
> Rename the atomic helper function drm_atomic_helper_check_crtc_state()
> to drm_atomic_helper_check_crtc_primary_plane() and only check for an
> attached primary plane. Adapt callers.
>
> Instead of having one big function to check for various CRTC stat
On 10/6/2022 13:16, Ceraolo Spurio, Daniele wrote:
On 10/6/2022 1:09 PM, John Harrison wrote:
On 10/6/2022 10:20, Daniele Ceraolo Spurio wrote:
We're observing sporadic HuC delayed load timeouts in CI, due to
mei_pxp
binding completing later than we expected. HuC is still still loaded
still s
On Fri, 7 Oct 2022 at 06:14, Alex Deucher wrote:
>
> On Thu, Oct 6, 2022 at 3:48 PM Linus Torvalds
> wrote:
> >
> > On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher wrote:
> > >
> > > Maybe you are seeing this which is an issue with GPU TLB flushes which
> > > is kind of sporadic:
> > > https://gitl
Hello Thomas,
On 10/5/22 13:40, Thomas Zimmermann wrote:
> In drm_atomic_helper_check_crtc_state(), do not add a new plane state
> to the global state if it does not exist already. Adding a new plane
> state will result in overhead for the plane during the atomic-commit
> step.
>
> For the test i
On 10/6/2022 1:09 PM, John Harrison wrote:
On 10/6/2022 10:20, Daniele Ceraolo Spurio wrote:
We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
binding completing later than we expected. HuC is still still loaded
still still
when the bind occurs, but in the meantime i
On Thu, Oct 6, 2022 at 3:48 PM Linus Torvalds
wrote:
>
> On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher wrote:
> >
> > Maybe you are seeing this which is an issue with GPU TLB flushes which
> > is kind of sporadic:
> > https://gitlab.freedesktop.org/drm/amd/-/issues/2113
>
> Well, that seems to be
On 10/6/2022 10:20, Daniele Ceraolo Spurio wrote:
We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
binding completing later than we expected. HuC is still still loaded
still still
when the bind occurs, but in the meantime i915 has started allowing
submission to the VCS
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 7da9fed0474b4cd46055dd92d55c42faf32c19ac Add linux-next specific
files for 20221006
Error/Warning reports:
https://lore.kernel.org/linux-doc/202210070057.npbamyxb-...@intel.com
https
On Thu, Oct 6, 2022 at 8:39 PM Linus Torvalds
wrote:
>
> On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink)
> wrote:
> >
> > This is only seen with gcc-11, gcc-12 builds are ok.
>
> Hmm. This seems to be some odd gcc issue.
>
>
> The fix *MAY* be to just add a '&& i < MAX_DWB_PIPES' to
Hello,
syzbot found the following issue on:
HEAD commit:bbed346d5a96 Merge branch 'for-next/core' into for-kernelci
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=13b7a1b888
kernel confi
Hey Linus,
On 2022-10-06 15:39, Linus Torvalds wrote:
On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink)
wrote:
This is only seen with gcc-11, gcc-12 builds are ok.
Hmm. This seems to be some odd gcc issue.
I *think* that what is going on is that the test
j = 0 ; j < MAX_
On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher wrote:
>
> Maybe you are seeing this which is an issue with GPU TLB flushes which
> is kind of sporadic:
> https://gitlab.freedesktop.org/drm/amd/-/issues/2113
Well, that seems to be 5.19, and while timing changes (or whatever
other software updates) c
On Thu, Oct 6, 2022 at 12:30 PM Dave Airlie wrote:
>
> netconsole?
I've never been really successful with that in the past, and haven't
used it for decades. I guess I could try if nothing else works.
Linus
On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink)
wrote:
>
> This is only seen with gcc-11, gcc-12 builds are ok.
Hmm. This seems to be some odd gcc issue.
I *think* that what is going on is that the test
j = 0 ; j < MAX_DWB_PIPES
makes gcc decide that "hey, j is in the range
On Fri, 7 Oct 2022 at 04:48, Linus Torvalds
wrote:
>
> On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
> >
> > Lots of stuff all over, some new AMD IP support and gang
> > submit support [..]
>
> Hmm.
>
> I have now had my main desktop lock up twice after pulling this.
> Nothing in the dmesg af
On Thu, Oct 6, 2022 at 2:48 PM Linus Torvalds
wrote:
>
> On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
> >
> > Lots of stuff all over, some new AMD IP support and gang
> > submit support [..]
>
> Hmm.
>
> I have now had my main desktop lock up twice after pulling this.
> Nothing in the dmesg
On Fri, Oct 07, 2022 at 12:58:45AM +0800, Zheng Wang wrote:
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt.
> But the caller does not notice that, it will free spt again in error path.
>
> Fix this by spliting invalidate and free in p
On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
>
> Lots of stuff all over, some new AMD IP support and gang
> submit support [..]
Hmm.
I have now had my main desktop lock up twice after pulling this.
Nothing in the dmesg after a reboot, and nothing in particular that
seems to trigger it, so I
On Thu, 6 Oct 2022 08:37:09 -0300
Jason Gunthorpe wrote:
> On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
> > We can't have a .remove callback that does nothing, this breaks
> > removing the device while it's in use. Once we have the
> > vfio_unregister_group_dev() fix below, w
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
wrote:
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
The prandom_u32() function has been a deprecated inline wrappe
Le 06/10/2022 à 19:24, Jason A. Donenfeld a écrit :
> 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 r
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
> > exact same code. Repl
On Wed, Oct 05, 2022 at 11:46:15PM -0700, Guenter Roeck wrote:
> On Tue, Sep 27, 2022 at 03:12:00PM -0400, Hamza Mahfooz wrote:
> > Address the following error:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: In function
> > ‘dc_stream_remove_writeback’:
> > drivers/gpu/drm/amd/amdg
Le 06/10/2022 à 18:53, Jason A. Donenfeld a écrit :
> 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.
>
>
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
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function. The same
We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
binding completing later than we expected. HuC is still still loaded
when the bind occurs, but in the meantime i915 has started allowing
submission to the VCS engines even if HuC is not there.
In most of the cases I've observe
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt.
But the caller does not notice that, it will free spt again in error path.
Fix this by spliting invalidate and free in ppgtt_invalidate_spt.
Only free spt when in good case.
Reported-by: Zh
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/pra
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
---
ar
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 same also applies to get_random_int(), which is
just a wrapper arou
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 A. Donenfel
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.
Reviewed-by: Kees Cook
Reviewed-by: KP Singh
Reviewed-by: Christoph Böhmwalder # for drbd
Changes v2->v3:
- Handle get_random_int() conversions too, which were overlooked before,
in the same way as the rest.
Hi folks,
This is a five part treewide cleanup of random integer handling. The
rules for random integers are:
- If you want a secure or an insecure random u64, use get_random_u
On Thu 06-10-22 07:25:08, 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 deprecated wrapper with a direct call to
> the real function.
>
> Review
On Thu 06-10-22 07:25:06, 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
> the minimum required bytes from the RNG and avoids divisions.
>
> Reviewed-by: Kees Cook
> Revie
On 2022-10-06 04:12, Stephen Rothwell wrote:
Hi all,
On Thu, 6 Oct 2022 09:28:10 +1100 Stephen Rothwell
wrote:
I have applied the following hack for today:
From: Stephen Rothwell
Date: Thu, 6 Oct 2022 09:14:26 +1100
Subject: [PATCH] fix up for drivers/gpu/drm/amd/display/dc/core/dc_stream.
> On Oct 6, 2022, at 9:25 AM, 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 deprecated wrapper with a direct call to
> the real function.
FYI, v3, which I'll wait a bit before posting, will also take care of
get_random_int().
On Wed, Oct 5, 2022 at 1:51 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 05.10.2022 17:12, Jagan Teki wrote:
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and i.MX8MM DSI devi
On Thu, Oct 06, 2022 at 11:33:14AM +0200, Simon Rettberg wrote:
> Current dual mode adaptor ("DP++") detection code assumes that all
> adaptors support i2c sub-addressing for read operations from the
> DP-HDMI adaptor ID buffer. It has been observed that multiple
> adaptors do not in fact support
Hi Robert
Thanks for the review.
On 10/4/2022 8:55 AM, Robert Foss wrote:
On Mon, 29 Aug 2022 at 20:23, Abhinav Kumar wrote:
adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.
This approach is incorrect because this method of d
On Fri, Mar 4, 2022 at 8:48 PM Dave Stevenson
wrote:
>
> Mapping to the drm_bridge flag pre_enable_upstream_first,
> add a new flag prepare_upstream_first to drm_panel to allow
> the panel driver to request that the upstream bridge should
> be pre_enabled before the panel prepare.
>
> Signed-off-b
Hi Marek,
On Thu, Oct 6, 2022 at 2:21 AM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 05.10.2022 17:12, Jagan Teki wrote:
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and i.MX8
This looks good to me. Care to add you s-o-b?
Alex
On Thu, Oct 6, 2022 at 4:12 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Thu, 6 Oct 2022 09:28:10 +1100 Stephen Rothwell
> wrote:
> >
> > I have applied the following hack for today:
> >
> > From: Stephen Rothwell
> > Date: Thu, 6 Oct 2022
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. Keep in
mind, though
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
---
ar
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
---
Docume
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
in
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
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.
Reviewed-by: Kees Cook
Reviewed-by: KP Singh
Reviewed-by: Christoph Böhmwalder
Signed-off-
[Posting v2 right away, because I CC'd too many people for v1, and email
systems worldwide exploded.]
Hi folks,
This is a five part treewide cleanup of random integer handling. The
rules for random integers are:
- If you want a secure or an insecure random u64, use get_random_u64().
- If you wa
On Thu, Oct 06, 2022 at 07:05:48AM -0600, Jason A. Donenfeld wrote:
> 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:
...
> > > - u32 isn = (prandom_u32() & ~7UL) - 1;
> > > + u32 isn = (get_random_u32() & ~7UL
On Thu, Oct 06, 2022 at 07:05:48AM -0600, Jason A. Donenfeld wrote:
> > > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > index fd9d7f2c4d64..a605cf66b83e 100644
> > > --- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> > > +++ b/drivers/infi
On Wed, Oct 5, 2022 at 9:05 PM allen wrote:
>
> From: allen chen
>
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
> ---
> .../bindings/display/bridge/ite,it6505.yaml | 12
> 1 file changed, 12 insert
On Thu, 06 Oct 2022 10:04:43 +0800, allen wrote:
> From: allen chen
>
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
> ---
> .../bindings/display/bridge/ite,it6505.yaml | 12
> 1 file changed, 12 in
I have a DRM master implementing a purpose-built compositor for a dedicated
use-case. It drives several different connectors, each on its own vsync cadence
(there's no clone mode happening here).
The goal is to have commits to each connector occur completely without respect
to whatever is happe
Remove the redundant semicolon
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2333
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915
On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
> We can't have a .remove callback that does nothing, this breaks
> removing the device while it's in use. Once we have the
> vfio_unregister_group_dev() fix below, we'll block until the device is
> unused, at which point vgpu->attac
1 - 100 of 131 matches
Mail list logo
