All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* [Bug 216283] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_insert_extent() when mount and operate on crafted image
  @ 2022-08-01 22:45 82% ` bugzilla-daemon
  2022-08-02  9:28 82% ` bugzilla-daemon
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-08-01 22:45 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216283

--- Comment #6 from Dave Chinner (david@fromorbit.com) ---
On Thu, Jul 28, 2022 at 09:25:10AM +0200, Lukas Czerner wrote:
> On Thu, Jul 28, 2022 at 09:22:24AM +1000, Dave Chinner wrote:
> > On Wed, Jul 27, 2022 at 01:53:07PM +0200, Lukas Czerner wrote:
> > > On Tue, Jul 26, 2022 at 01:10:24PM -0700, Darrick J. Wong wrote:
> > > > If you are going to run some scripted tool to randomly
> > > > corrupt the filesystem to find failures, then you have an
> > > > ethical and moral responsibility to do some of the work to
> > > > narrow down and identify the cause of the failure, not just
> > > > throw them at someone to do all the work.
> > > > 
> > > > --D
> > > 
> > > While I understand the frustration with the fuzzer bug reports like this
> > > I very much disagree with your statement about ethical and moral
> > > responsibility.
> > > 
> > > The bug is in the code, it would have been there even if Wenqing Liu
> > > didn't run the tool.
> > 
> > Yes, but it's not just a bug. It's a format parser exploit.
> 
> And what do you think this is exploiting? A bug in a "format parser"
> perhaps?
> 
> Are you trying both downplay it to not-a-bug and elevate it to 'security
> vulnerability' at the same time ? ;)

How did you come to that conclusion?

"not just a bug" != "not a bug".

i.e. I said the complete opposite of what your comment implies I
said...

> > > We know there are bugs in the code we just don't
> > > know where all of them are. Now, thanks to this report, we know a little
> > > bit more about at least one of them. That's at least a little useful.
> > > But you seem to argue that the reporter should put more work in, or not
> > > bother at all.
> > > 
> > > That's wrong. Really, Wenqing Liu has no more ethical and moral
> > > responsibility than you finding and fixing the problem regardless of the
> > > bug report.
> > 
> > By this reasoning, the researchers that discovered RetBleed
> > should have just published their findings without notify any of the
> > affected parties.
> > 
> > i.e. your argument implies they have no responsibility and hence are
> > entitled to say "We aren't responsible for helping anyone understand
> > the problem or mitigating the impact of the flaw - we've got our
> > publicity and secured tenure with discovery and publication!"
> > 
> > That's not _responsible disclosure_.
> 
> Look, your entire argument hinges on the assumption that this is a
> security vulnerability that could be exploited and the report makes the
> situation worse. And that's very much debatable. I don't think it is and
> Ted described it very well in his comment.

On systems that automount filesytsems when you plug in a USB drive
(which most distros do out of the box) then a crash bug during mount
is, at minimum, an annoying DOS vector. And if it can result in a
buffer overflow, then....

> Asking for more information, or even asking reported to try to narrow
> down the problem is of course fine.

Sure, nobody is questioning how we triage these issues - the
question is over how they are reported and the forum under which the
initial triage takes place

> But making sweeping claims about
> moral and ethical responsibilities is always a little suspicious and
> completely bogus in this case IMO.

Hand waving away the fact that fuzzer crash bugs won't be a security
issue without having done any investigation is pretty much the whole
problem here. This is not responsible behaviour.

Cheers,

Dave.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 216283] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_insert_extent() when mount and operate on crafted image
  @ 2022-08-02  9:28 82%           ` Lukas Czerner
  0 siblings, 0 replies; 200+ results
From: Lukas Czerner @ 2022-08-02  9:28 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Darrick J. Wong, bugzilla-daemon, linux-ext4

On Tue, Aug 02, 2022 at 08:45:51AM +1000, Dave Chinner wrote:

--- snip ---

> > 
> > Look, your entire argument hinges on the assumption that this is a
> > security vulnerability that could be exploited and the report makes the
> > situation worse. And that's very much debatable. I don't think it is and
> > Ted described it very well in his comment.
> 
> On systems that automount filesytsems when you plug in a USB drive
> (which most distros do out of the box) then a crash bug during mount
> is, at minimum, an annoying DOS vector. And if it can result in a
> buffer overflow, then....
> 
> > Asking for more information, or even asking reported to try to narrow
> > down the problem is of course fine.
> 
> Sure, nobody is questioning how we triage these issues - the
> question is over how they are reported and the forum under which the
> initial triage takes place
> 
> > But making sweeping claims about
> > moral and ethical responsibilities is always a little suspicious and
> > completely bogus in this case IMO.
> 
> Hand waving away the fact that fuzzer crash bugs won't be a security
> issue without having done any investigation is pretty much the whole
> problem here. This is not responsible behaviour.

Since it's obvious that the security status of this is disputed, then
please feel free to create guidelines stating that fuzzer bugs for xfs
are considered a security issues and reporters should follow guidelines
of responsible disclosure and bugs are not to be reported publicly.

Problem solved and no moralizing needed.

-Lukas

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 


^ permalink raw reply	[relevance 82%]

* [Bug 216283] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_insert_extent() when mount and operate on crafted image
    2022-08-01 22:45 82% ` [Bug 216283] " bugzilla-daemon
@ 2022-08-02  9:28 82% ` bugzilla-daemon
  2022-10-04 19:42 82% ` bugzilla-daemon
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-08-02  9:28 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216283

--- Comment #9 from Lukas Czerner (lczerner@redhat.com) ---
On Tue, Aug 02, 2022 at 08:45:51AM +1000, Dave Chinner wrote:

--- snip ---

> > 
> > Look, your entire argument hinges on the assumption that this is a
> > security vulnerability that could be exploited and the report makes the
> > situation worse. And that's very much debatable. I don't think it is and
> > Ted described it very well in his comment.
> 
> On systems that automount filesytsems when you plug in a USB drive
> (which most distros do out of the box) then a crash bug during mount
> is, at minimum, an annoying DOS vector. And if it can result in a
> buffer overflow, then....
> 
> > Asking for more information, or even asking reported to try to narrow
> > down the problem is of course fine.
> 
> Sure, nobody is questioning how we triage these issues - the
> question is over how they are reported and the forum under which the
> initial triage takes place
> 
> > But making sweeping claims about
> > moral and ethical responsibilities is always a little suspicious and
> > completely bogus in this case IMO.
> 
> Hand waving away the fact that fuzzer crash bugs won't be a security
> issue without having done any investigation is pretty much the whole
> problem here. This is not responsible behaviour.

Since it's obvious that the security status of this is disputed, then
please feel free to create guidelines stating that fuzzer bugs for xfs
are considered a security issues and reporters should follow guidelines
of responsible disclosure and bugs are not to be reported publicly.

Problem solved and no moralizing needed.

-Lukas

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
>

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [BUG] video: fbdev: arkfb: Found a divide-by-zero bug which may cause DoS
  @ 2022-08-03  9:26 82%     ` Zheyu Ma
  0 siblings, 0 replies; 200+ results
From: Zheyu Ma @ 2022-08-03  9:26 UTC (permalink / raw)
  To: Helge Deller
  Cc: Geert Uytterhoeven, Linux Fbdev development list, DRI Development,
	Linux Kernel Mailing List

Hi,

On Mon, Aug 1, 2022 at 12:35 PM Helge Deller <deller@gmx.de> wrote:
>
> * Zheyu Ma <zheyuma97@gmail.com>:
> > I found a bug in the arkfb driver in the latest kernel, which may cause DoS.
> >
> > The reason for this bug is that the user controls some input to ioctl,
> > making 'mode' 0x7 on line 704, which causes hdiv = 1, hmul = 2, and if
> > the pixclock is controlled to be 1, it will cause a division error in
> > the function ark_set_pixclock().
>
> You are right.
> I see in:
>   drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul);
> with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0.
> and then in
>   drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock);
> you'll get a division-by-zero.
>
> > The easiest patch is to check the value of the argument 'pixclock' in
> > the ark_set_pixclock function, but this is perhaps too late, should we
> > do this check earlier? I'm not sure, so I'll report this bug to you.
>
> Yes, I think it should be done earlier.
>
> Geert always mentioned that an invalid pixclock from userspace should be
> rounded up to the next valid pixclock.
> But since I don't have that hardware, I'm not sure how this can be done
> best for this driver.
>
> Do you have the hardware to test?
> If so, could you check the patch below?

Thanks for your patch, it works for me :)

> It should at least prevent the division-by-zero.
> If it works, I'm happy if you could send a final patch...

I've sent a patch to the mailing list, thanks again for your reminder.

regards,

Zheyu Ma

^ permalink raw reply	[relevance 82%]

* Re: [BUG] video: fbdev: arkfb: Found a divide-by-zero bug which may cause DoS
@ 2022-08-03  9:26 82%     ` Zheyu Ma
  0 siblings, 0 replies; 200+ results
From: Zheyu Ma @ 2022-08-03  9:26 UTC (permalink / raw)
  To: Helge Deller
  Cc: Linux Fbdev development list, Geert Uytterhoeven,
	Linux Kernel Mailing List, DRI Development

Hi,

On Mon, Aug 1, 2022 at 12:35 PM Helge Deller <deller@gmx.de> wrote:
>
> * Zheyu Ma <zheyuma97@gmail.com>:
> > I found a bug in the arkfb driver in the latest kernel, which may cause DoS.
> >
> > The reason for this bug is that the user controls some input to ioctl,
> > making 'mode' 0x7 on line 704, which causes hdiv = 1, hmul = 2, and if
> > the pixclock is controlled to be 1, it will cause a division error in
> > the function ark_set_pixclock().
>
> You are right.
> I see in:
>   drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul);
> with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0.
> and then in
>   drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock);
> you'll get a division-by-zero.
>
> > The easiest patch is to check the value of the argument 'pixclock' in
> > the ark_set_pixclock function, but this is perhaps too late, should we
> > do this check earlier? I'm not sure, so I'll report this bug to you.
>
> Yes, I think it should be done earlier.
>
> Geert always mentioned that an invalid pixclock from userspace should be
> rounded up to the next valid pixclock.
> But since I don't have that hardware, I'm not sure how this can be done
> best for this driver.
>
> Do you have the hardware to test?
> If so, could you check the patch below?

Thanks for your patch, it works for me :)

> It should at least prevent the division-by-zero.
> If it works, I'm happy if you could send a final patch...

I've sent a patch to the mailing list, thanks again for your reminder.

regards,

Zheyu Ma

^ permalink raw reply	[relevance 82%]

* [bug report] drm/ttm: Fix dummy res NULL ptr deref bug
@ 2022-08-11  9:55 82% Dan Carpenter
  2022-08-11 11:06 82% ` Arunpravin Paneer Selvam
  0 siblings, 1 reply; 200+ results
From: Dan Carpenter @ 2022-08-11  9:55 UTC (permalink / raw)
  To: Arunpravin.PaneerSelvam; +Cc: dri-devel

Hello Arunpravin Paneer Selvam,

This is a semi-automatic email about new static checker warnings.

The patch cf4b7387c0a8: "drm/ttm: Fix dummy res NULL ptr deref bug"
from Aug 9, 2022, leads to the following Smatch complaint:

    drivers/gpu/drm/ttm/ttm_bo.c:915 ttm_bo_validate()
    warn: variable dereferenced before check 'bo->resource' (see line 907)

drivers/gpu/drm/ttm/ttm_bo.c
   906		 */
   907		if (!ttm_resource_compat(bo->resource, placement)) {
                                         ^^^^^^^^^^^^
Unchecked dereference here inside the function.

   908			ret = ttm_bo_move_buffer(bo, placement, ctx);
   909			if (ret)
   910				return ret;
   911		}
   912		/*
   913		 * We might need to add a TTM.
   914		 */
   915		if (!bo->resource || bo->resource->mem_type == TTM_PL_SYSTEM) {
                     ^^^^^^^^^^^^
Checked too late.

This NULL check was added deliberately based on a report from the kbuild
bot, but it's not clear why bo->resource is NULL at this point.  Was the
patch tested?  There is a stable@vger.kernel.org but there is no Fixes
tag.

   916			ret = ttm_tt_create(bo, true);
   917			if (ret)

regards,
dan carpenter

^ permalink raw reply	[relevance 82%]

* Re: [bug report] drm/ttm: Fix dummy res NULL ptr deref bug
  2022-08-11  9:55 82% [bug report] drm/ttm: Fix dummy res NULL ptr deref bug Dan Carpenter
@ 2022-08-11 11:06 82% ` Arunpravin Paneer Selvam
  2022-08-11 11:56 82%   ` Dan Carpenter
  0 siblings, 1 reply; 200+ results
From: Arunpravin Paneer Selvam @ 2022-08-11 11:06 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: dri-devel

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

Hi Dan,

drm-misc-fixes doesn't have the updated ttm_bo.c file, we have the 
updated ttm_bo.c version in
drm-misc-next branch. Please find below for the line number 907.

On 8/11/2022 3:25 PM, Dan Carpenter wrote:
> Hello Arunpravin Paneer Selvam,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch cf4b7387c0a8: "drm/ttm: Fix dummy res NULL ptr deref bug"
> from Aug 9, 2022, leads to the following Smatch complaint:
>
>      drivers/gpu/drm/ttm/ttm_bo.c:915 ttm_bo_validate()
>      warn: variable dereferenced before check 'bo->resource' (see line 907)
>
> drivers/gpu/drm/ttm/ttm_bo.c
>     906		 */
>     907		if (!ttm_resource_compat(bo->resource, placement)) {
>                                           ^^^^^^^^^^^^
> Unchecked dereference here inside the function.

|if (!bo->resource || !ttm_resource_compat(bo->resource, placement)) { 
we have this version in drm-misc-next Regards, Arun |

>
>     908			ret = ttm_bo_move_buffer(bo, placement, ctx);
>     909			if (ret)
>     910				return ret;
>     911		}
>     912		/*
>     913		 * We might need to add a TTM.
>     914		 */
>     915		if (!bo->resource || bo->resource->mem_type == TTM_PL_SYSTEM) {
>                       ^^^^^^^^^^^^
> Checked too late.
>
> This NULL check was added deliberately based on a report from the kbuild
> bot, but it's not clear why bo->resource is NULL at this point.  Was the
> patch tested?  There is astable@vger.kernel.org  but there is no Fixes
> tag.
>
>     916			ret = ttm_tt_create(bo, true);
>     917			if (ret)
>
> regards,
> dan carpenter

[-- Attachment #2: Type: text/html, Size: 2597 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: [bug report] drm/ttm: Fix dummy res NULL ptr deref bug
  2022-08-11 11:06 82% ` Arunpravin Paneer Selvam
@ 2022-08-11 11:56 82%   ` Dan Carpenter
  2022-08-14  6:00 82%     ` Arunpravin Paneer Selvam
  0 siblings, 1 reply; 200+ results
From: Dan Carpenter @ 2022-08-11 11:56 UTC (permalink / raw)
  To: Arunpravin Paneer Selvam; +Cc: dri-devel

On Thu, Aug 11, 2022 at 04:36:33PM +0530, Arunpravin Paneer Selvam wrote:
> Hi Dan,
> 
> drm-misc-fixes doesn't have the updated ttm_bo.c file, we have the updated
> ttm_bo.c version in
> drm-misc-next branch. Please find below for the line number 907.
> 
> On 8/11/2022 3:25 PM, Dan Carpenter wrote:
> > Hello Arunpravin Paneer Selvam,
> > 
> > This is a semi-automatic email about new static checker warnings.
> > 
> > The patch cf4b7387c0a8: "drm/ttm: Fix dummy res NULL ptr deref bug"
> > from Aug 9, 2022, leads to the following Smatch complaint:
> > 
> >      drivers/gpu/drm/ttm/ttm_bo.c:915 ttm_bo_validate()
> >      warn: variable dereferenced before check 'bo->resource' (see line 907)
> > 
> > drivers/gpu/drm/ttm/ttm_bo.c
> >     906		 */
> >     907		if (!ttm_resource_compat(bo->resource, placement)) {
> >                                           ^^^^^^^^^^^^
> > Unchecked dereference here inside the function.
> 
> |if (!bo->resource || !ttm_resource_compat(bo->resource, placement)) { we
> have this version in drm-misc-next Regards, Arun |
> 

Huh...  That's very interesting.  It appears there was a bug in
drm-misc-next, we applied the fix to the wrong tree, and now both trees
are wrong.  The drm-misc-next tree still has the bug and the other tree
has a static checker warning about nonsensical NULL checks.

Eventually drm-misc-next will get merged and everything will work.  Is
it too late to remove the bogus "CC: stable@vger.kernel.org"?

This could have been avoided if the NULL dereference fix had a Fixes tag.

regards,
dan carpenter


^ permalink raw reply	[relevance 82%]

* Re: [bug report] drm/ttm: Fix dummy res NULL ptr deref bug
  2022-08-11 11:56 82%   ` Dan Carpenter
@ 2022-08-14  6:00 82%     ` Arunpravin Paneer Selvam
  2022-08-14 17:50 82%       ` Christian König
  0 siblings, 1 reply; 200+ results
From: Arunpravin Paneer Selvam @ 2022-08-14  6:00 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: Christian König, dri-devel

Hi Dan,

On 8/11/2022 5:26 PM, Dan Carpenter wrote:
> On Thu, Aug 11, 2022 at 04:36:33PM +0530, Arunpravin Paneer Selvam wrote:
>> Hi Dan,
>>
>> drm-misc-fixes doesn't have the updated ttm_bo.c file, we have the updated
>> ttm_bo.c version in
>> drm-misc-next branch. Please find below for the line number 907.
>>
>> On 8/11/2022 3:25 PM, Dan Carpenter wrote:
>>> Hello Arunpravin Paneer Selvam,
>>>
>>> This is a semi-automatic email about new static checker warnings.
>>>
>>> The patch cf4b7387c0a8: "drm/ttm: Fix dummy res NULL ptr deref bug"
>>> from Aug 9, 2022, leads to the following Smatch complaint:
>>>
>>>       drivers/gpu/drm/ttm/ttm_bo.c:915 ttm_bo_validate()
>>>       warn: variable dereferenced before check 'bo->resource' (see line 907)
>>>
>>> drivers/gpu/drm/ttm/ttm_bo.c
>>>      906		 */
>>>      907		if (!ttm_resource_compat(bo->resource, placement)) {
>>>                                            ^^^^^^^^^^^^
>>> Unchecked dereference here inside the function.
>> |if (!bo->resource || !ttm_resource_compat(bo->resource, placement)) { we
>> have this version in drm-misc-next Regards, Arun |
>>
> Huh...  That's very interesting.  It appears there was a bug in
> drm-misc-next, we applied the fix to the wrong tree, and now both trees
> are wrong.  The drm-misc-next tree still has the bug and the other tree
> has a static checker warning about nonsensical NULL checks.
>
> Eventually drm-misc-next will get merged and everything will work.  Is
> it too late to remove the bogus "CC: stable@vger.kernel.org"?
I will look into this problem.
> This could have been avoided if the NULL dereference fix had a Fixes tag.
I should have added the below tag
Fixes: 347987a2cf0d ("drm/ttm: rename and cleanup ttm_bo_init")

I will check on this.

Thanks,
Arun
>
> regards,
> dan carpenter
>


^ permalink raw reply	[relevance 82%]

* Re: [bug report] drm/ttm: Fix dummy res NULL ptr deref bug
  2022-08-14  6:00 82%     ` Arunpravin Paneer Selvam
@ 2022-08-14 17:50 82%       ` Christian König
  0 siblings, 0 replies; 200+ results
From: Christian König @ 2022-08-14 17:50 UTC (permalink / raw)
  To: Arunpravin Paneer Selvam, Dan Carpenter; +Cc: dri-devel

Am 14.08.22 um 08:00 schrieb Arunpravin Paneer Selvam:
> Hi Dan,
>
> On 8/11/2022 5:26 PM, Dan Carpenter wrote:
>> On Thu, Aug 11, 2022 at 04:36:33PM +0530, Arunpravin Paneer Selvam 
>> wrote:
>>> Hi Dan,
>>>
>>> drm-misc-fixes doesn't have the updated ttm_bo.c file, we have the 
>>> updated
>>> ttm_bo.c version in
>>> drm-misc-next branch. Please find below for the line number 907.
>>>
>>> On 8/11/2022 3:25 PM, Dan Carpenter wrote:
>>>> Hello Arunpravin Paneer Selvam,
>>>>
>>>> This is a semi-automatic email about new static checker warnings.
>>>>
>>>> The patch cf4b7387c0a8: "drm/ttm: Fix dummy res NULL ptr deref bug"
>>>> from Aug 9, 2022, leads to the following Smatch complaint:
>>>>
>>>>       drivers/gpu/drm/ttm/ttm_bo.c:915 ttm_bo_validate()
>>>>       warn: variable dereferenced before check 'bo->resource' (see 
>>>> line 907)
>>>>
>>>> drivers/gpu/drm/ttm/ttm_bo.c
>>>>      906         */
>>>>      907        if (!ttm_resource_compat(bo->resource, placement)) {
>>>>                                            ^^^^^^^^^^^^
>>>> Unchecked dereference here inside the function.
>>> |if (!bo->resource || !ttm_resource_compat(bo->resource, placement)) 
>>> { we
>>> have this version in drm-misc-next Regards, Arun |
>>>
>> Huh...  That's very interesting.  It appears there was a bug in
>> drm-misc-next, we applied the fix to the wrong tree, and now both trees
>> are wrong.  The drm-misc-next tree still has the bug and the other tree
>> has a static checker warning about nonsensical NULL checks.
>>
>> Eventually drm-misc-next will get merged and everything will work.  Is
>> it too late to remove the bogus "CC: stable@vger.kernel.org"?
> I will look into this problem.

Mhm, if I'm not completely mistaken the "CC: stable@vger.kernel.org" is 
actually correct, we just need to limit to which version it applies.

>> This could have been avoided if the NULL dereference fix had a Fixes 
>> tag.
> I should have added the below tag
> Fixes: 347987a2cf0d ("drm/ttm: rename and cleanup ttm_bo_init")

WAIT! That's not the correct one. This patch just made the problem more 
obvious.

The real one is bfa3357ef9ab drm/ttm: allocate resource object instead 
of embedding it v2

Regards,
Christian.

>
> I will check on this.
>
> Thanks,
> Arun
>>
>> regards,
>> dan carpenter
>>
>


^ permalink raw reply	[relevance 82%]

* Re: [next] arm64: kernel BUG at fs/inode.c:622 - Internal error: Oops - BUG: 0 - pc : clear_inode
  @ 2022-08-16 19:10 82% ` Linus Torvalds
  2022-08-16 19:39 82%   ` Naresh Kamboju
  0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2022-08-16 19:10 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: open list, Linux-Next Mailing List, linux-fsdevel, regressions,
	lkft-triage, Alexander Viro, Christian Brauner

On Tue, Aug 16, 2022 at 12:00 PM Naresh Kamboju
<naresh.kamboju@linaro.org> wrote:
>
> Following kernel BUG found while booting arm64 Qcom dragonboard 410c with
> Linux next-20220816 kernel Image.

What kind of environment is this?

Havign that inode list corruption makes it smell a *bit* like the
crazy memory corruption that we saw with the google cloud instances,
but that would only happen wif you actually use VIRTIO for your
environment?

Do you see the same issue with plain v6.0-rc1?

            Linus

^ permalink raw reply	[relevance 82%]

* Re: [next] arm64: kernel BUG at fs/inode.c:622 - Internal error: Oops - BUG: 0 - pc : clear_inode
  2022-08-16 19:10 82% ` Linus Torvalds
@ 2022-08-16 19:39 82%   ` Naresh Kamboju
  2022-08-17  2:00 82%     ` Stephen Rothwell
  2022-08-16 19:42 82%     ` Linus Torvalds
  0 siblings, 2 replies; 200+ results
From: Naresh Kamboju @ 2022-08-16 19:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: open list, Linux-Next Mailing List, linux-fsdevel, regressions,
	lkft-triage, Alexander Viro, Christian Brauner

On Wed, 17 Aug 2022 at 00:40, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Aug 16, 2022 at 12:00 PM Naresh Kamboju
> <naresh.kamboju@linaro.org> wrote:
> >
> > Following kernel BUG found while booting arm64 Qcom dragonboard 410c with
> > Linux next-20220816 kernel Image.
>
> What kind of environment is this?
>
> Havign that inode list corruption makes it smell a *bit* like the
> crazy memory corruption that we saw with the google cloud instances,
> but that would only happen wif you actually use VIRTIO for your
> environment?

This is a physical hardware db410c device.
Following VIRTIO configs enabled.

CONFIG_BLK_MQ_VIRTIO=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_VIRTIO_BLK=y
CONFIG_SCSI_VIRTIO=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_VIRTIO_ANCHOR=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_PCI_LIB=y
CONFIG_VIRTIO_PCI_LIB_LEGACY=y
CONFIG_VIRTIO_MENU=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
CONFIG_CRYPTO_DEV_VIRTIO=y


>
> Do you see the same issue with plain v6.0-rc1?

Nope. I do not notice reported BUG on v6.0-rc1.

- Naresh

^ permalink raw reply	[relevance 82%]

* Re: [next] arm64: kernel BUG at fs/inode.c:622 - Internal error: Oops - BUG: 0 - pc : clear_inode
  2022-08-16 19:39 82%   ` Naresh Kamboju
  2022-08-17  2:00 82%     ` Stephen Rothwell
@ 2022-08-16 19:42 82%     ` Linus Torvalds
  1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2022-08-16 19:42 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: open list, Linux-Next Mailing List, linux-fsdevel, regressions,
	lkft-triage, Alexander Viro, Christian Brauner

On Tue, Aug 16, 2022 at 12:39 PM Naresh Kamboju
<naresh.kamboju@linaro.org> wrote:
>
> This is a physical hardware db410c device.
> Following VIRTIO configs enabled.

Yeah, it's not enough to just enable the VIRTIO support, it actually
needs to run in a virt environment, and with a hypervisor that gets
confused by the virtio changes.

Plus:

> > Do you see the same issue with plain v6.0-rc1?
>
> Nope. I do not notice reported BUG on v6.0-rc1.

Ok, so definitely not related to the google cloud issue we had in rc1.

               Linus

^ permalink raw reply	[relevance 82%]

* Re: [next] arm64: kernel BUG at fs/inode.c:622 - Internal error: Oops - BUG: 0 - pc : clear_inode
  2022-08-16 19:39 82%   ` Naresh Kamboju
@ 2022-08-17  2:00 82%     ` Stephen Rothwell
  2022-08-16 19:42 82%     ` Linus Torvalds
  1 sibling, 0 replies; 200+ results
From: Stephen Rothwell @ 2022-08-17  2:00 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Linus Torvalds, open list, Linux-Next Mailing List, linux-fsdevel,
	regressions, lkft-triage, Alexander Viro, Christian Brauner

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

Hi Naresh,

On Wed, 17 Aug 2022 01:09:40 +0530 Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> On Wed, 17 Aug 2022 at 00:40, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Tue, Aug 16, 2022 at 12:00 PM Naresh Kamboju
> > <naresh.kamboju@linaro.org> wrote:  
> > >
> > > Following kernel BUG found while booting arm64 Qcom dragonboard 410c with
> > > Linux next-20220816 kernel Image.  
> >
> > What kind of environment is this?
> >
> > Havign that inode list corruption makes it smell a *bit* like the
> > crazy memory corruption that we saw with the google cloud instances,
> > but that would only happen wif you actually use VIRTIO for your
> > environment?  
> 
> This is a physical hardware db410c device.
> Following VIRTIO configs enabled.
> 
> CONFIG_BLK_MQ_VIRTIO=y
> CONFIG_NET_9P_VIRTIO=y
> CONFIG_VIRTIO_BLK=y
> CONFIG_SCSI_VIRTIO=y
> CONFIG_VIRTIO_NET=y
> CONFIG_VIRTIO_CONSOLE=y
> CONFIG_VIRTIO_ANCHOR=y
> CONFIG_VIRTIO=y
> CONFIG_VIRTIO_PCI_LIB=y
> CONFIG_VIRTIO_PCI_LIB_LEGACY=y
> CONFIG_VIRTIO_MENU=y
> CONFIG_VIRTIO_PCI=y
> CONFIG_VIRTIO_PCI_LEGACY=y
> CONFIG_VIRTIO_BALLOON=y
> CONFIG_VIRTIO_MMIO=y
> CONFIG_CRYPTO_DEV_VIRTIO=y
> 
> 
> >
> > Do you see the same issue with plain v6.0-rc1?  
> 
> Nope. I do not notice reported BUG on v6.0-rc1.

Is it reliable enough that you could possibly do a bisection between
v6.0-rc1 and next-20220816?

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[relevance 82%]

* [Bug 215381] BUG: Unable to handle kernel data access on read at 0x6600cc00000004
  @ 2022-08-19 10:19 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-08-19 10:19 UTC (permalink / raw)
  To: linuxppc-dev

https://bugzilla.kernel.org/show_bug.cgi?id=215381

Erhard F. (erhard_f@mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
Have not seen this in quite some stable kernel releases...

Closing here. Will re-open in case I hit it again.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]
  @ 2022-08-26 14:36 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-08-26 14:36 UTC (permalink / raw)
  To: dri-devel

https://bugzilla.kernel.org/show_bug.cgi?id=215443

Erhard F. (erhard_f@mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Have not seen this since quite a few stable kernel releases on the same
hardware. I think it's save to close here.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]
  @ 2022-08-26 14:36 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-08-26 14:36 UTC (permalink / raw)
  To: linuxppc-dev

https://bugzilla.kernel.org/show_bug.cgi?id=215443

Erhard F. (erhard_f@mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Have not seen this since quite a few stable kernel releases on the same
hardware. I think it's save to close here.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216422] BUG: kernel NULL pointer dereference, address: 0000000000000000
    2022-08-28  0:21 82% ` [Bug 216422] " bugzilla-daemon
@ 2022-08-27 20:49 82% ` bugzilla-daemon
  2022-08-28 11:28 82% ` bugzilla-daemon
  2 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-08-27 20:49 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=216422

--- Comment #1 from Jan (kernel-bugzilla@janbruckner.de) ---
Created attachment 301687
  --> https://bugzilla.kernel.org/attachment.cgi?id=301687&action=edit
bisect log

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216422] BUG: kernel NULL pointer dereference, address: 0000000000000000
  @ 2022-08-28  0:21 82% ` bugzilla-daemon
  2022-08-27 20:49 82% ` bugzilla-daemon
  2022-08-28 11:28 82% ` bugzilla-daemon
  2 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-08-28  0:21 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=216422

Eric Haynes (ehaynes99@protonmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ehaynes99@protonmail.com

--- Comment #2 from Eric Haynes (ehaynes99@protonmail.com) ---
I am also experiencing this. I'm not sure if modern docking stations are more
than just a USB C hub, but in case it matters, I have an external monitor and a
keyboard connected via USB C but do not own a docking station.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216422] BUG: kernel NULL pointer dereference, address: 0000000000000000
    2022-08-28  0:21 82% ` [Bug 216422] " bugzilla-daemon
  2022-08-27 20:49 82% ` bugzilla-daemon
@ 2022-08-28 11:28 82% ` bugzilla-daemon
  2 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-08-28 11:28 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=216422

The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |regressions@leemhuis.info,
                   |                            |tiwai@suse.de

--- Comment #3 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
Thx for the bisect. That commits is known to cause some trouble. See this
thread:
https://lore.kernel.org/all/87r11cmbx0.wl-tiwai@suse.de/

A fix for that problem is heading towards mainline currently:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=master&id=5f73aa2cf8bef4a39baa1591c3144ede4788826e

Might be worth giving it a shot.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [BUG] drivers: adm9240: possible data race bug in adm9240_fan_read()
@ 2022-09-21 23:31 82% Li Zhong
  2022-09-22  3:16 82% ` Guenter Roeck
  0 siblings, 1 reply; 200+ results
From: Li Zhong @ 2022-09-21 23:31 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, jdelvare, Li Zhong

Hello,

My static analysis tool reports a possible bug in the adm9240 driver in Linux
v6.0:

drivers/hwmon/adm9240.c:

adm9240_read()
    adm9240_fan_read() --> Line 509
        adm9240_write_fan_div()

adm9240_write_fan_div() says 'callers must hold
data->update_lock'. However, it seems like the context does
not hold the lock it requires. So it may cause data race when
setting new fan div.

I am not quite sure whether this is a real bug. Any feedback would be
appreciated!

Thanks,
Li Zhong

^ permalink raw reply	[relevance 82%]

* Re: [BUG] drivers: adm9240: possible data race bug in adm9240_fan_read()
  2022-09-21 23:31 82% [BUG] drivers: adm9240: possible data race bug in adm9240_fan_read() Li Zhong
@ 2022-09-22  3:16 82% ` Guenter Roeck
  2022-09-22 20:37 82%   ` Li Zhong
  0 siblings, 1 reply; 200+ results
From: Guenter Roeck @ 2022-09-22  3:16 UTC (permalink / raw)
  To: Li Zhong, linux-hwmon; +Cc: jdelvare

On 9/21/22 16:31, Li Zhong wrote:
> Hello,
> 
> My static analysis tool reports a possible bug in the adm9240 driver in Linux
> v6.0:
> 
> drivers/hwmon/adm9240.c:
> 
> adm9240_read()
>      adm9240_fan_read() --> Line 509
>          adm9240_write_fan_div()
> 
> adm9240_write_fan_div() says 'callers must hold
> data->update_lock'. However, it seems like the context does
> not hold the lock it requires. So it may cause data race when
> setting new fan div.
> 
> I am not quite sure whether this is a real bug. Any feedback would be
> appreciated!
> 

You are correct, the code in adm9240_fan_read() should acquire
the mutex before calling adm9240_write_fan_div() and while
manipulating data->fan_div[channel].

Guenter

^ permalink raw reply	[relevance 82%]

* Re: [BUG] drivers: adm9240: possible data race bug in adm9240_fan_read()
  2022-09-22  3:16 82% ` Guenter Roeck
@ 2022-09-22 20:37 82%   ` Li Zhong
    0 siblings, 1 reply; 200+ results
From: Li Zhong @ 2022-09-22 20:37 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: linux-hwmon, jdelvare

On Wed, Sep 21, 2022 at 8:16 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 9/21/22 16:31, Li Zhong wrote:
> > Hello,
> >
> > My static analysis tool reports a possible bug in the adm9240 driver in Linux
> > v6.0:
> >
> > drivers/hwmon/adm9240.c:
> >
> > adm9240_read()
> >      adm9240_fan_read() --> Line 509
> >          adm9240_write_fan_div()
> >
> > adm9240_write_fan_div() says 'callers must hold
> > data->update_lock'. However, it seems like the context does
> > not hold the lock it requires. So it may cause data race when
> > setting new fan div.
> >
> > I am not quite sure whether this is a real bug. Any feedback would be
> > appreciated!
> >
>
> You are correct, the code in adm9240_fan_read() should acquire
> the mutex before calling adm9240_write_fan_div() and while
> manipulating data->fan_div[channel].
>
> Guenter

Thanks for your patient reply! Can I submit a patch on this? The draft will
be something like:

+  mutex_lock(&data->update_lock)
    err = adm9240_write_fan_div(data, channel, ++data->fan_div[channel]);
    if (err)
        return err;
+  mutex_unlock(&data->update_lock);

Let me know if you have any suggestions!

^ permalink raw reply	[relevance 82%]

* Re: [BUG] drivers: adm9240: possible data race bug in adm9240_fan_read()
  @ 2022-09-22 23:46 82%       ` Li Zhong
  0 siblings, 0 replies; 200+ results
From: Li Zhong @ 2022-09-22 23:46 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: linux-hwmon, jdelvare

On Thu, Sep 22, 2022 at 2:53 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 9/22/22 13:37, Li Zhong wrote:
> > On Wed, Sep 21, 2022 at 8:16 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> On 9/21/22 16:31, Li Zhong wrote:
> >>> Hello,
> >>>
> >>> My static analysis tool reports a possible bug in the adm9240 driver in Linux
> >>> v6.0:
> >>>
> >>> drivers/hwmon/adm9240.c:
> >>>
> >>> adm9240_read()
> >>>       adm9240_fan_read() --> Line 509
> >>>           adm9240_write_fan_div()
> >>>
> >>> adm9240_write_fan_div() says 'callers must hold
> >>> data->update_lock'. However, it seems like the context does
> >>> not hold the lock it requires. So it may cause data race when
> >>> setting new fan div.
> >>>
> >>> I am not quite sure whether this is a real bug. Any feedback would be
> >>> appreciated!
> >>>
> >>
> >> You are correct, the code in adm9240_fan_read() should acquire
> >> the mutex before calling adm9240_write_fan_div() and while
> >> manipulating data->fan_div[channel].
> >>
> >> Guenter
> >
> > Thanks for your patient reply! Can I submit a patch on this? The draft will
> > be something like:
> >
> > +  mutex_lock(&data->update_lock)
> >      err = adm9240_write_fan_div(data, channel, ++data->fan_div[channel]);
> >      if (err)
> >          return err;
> > +  mutex_unlock(&data->update_lock);
> >
> > Let me know if you have any suggestions!
>
> That would leave the mutex in locked state after an error, and it does not
> take into account that data->fan_div[channel] might still change after being
> checked but before being used. The lock has to be around the if() statement,
> and the lock must be released after an error was observed.
>
> At the very least, the code has to be something like
>
>         ...
>         mutex_lock(&data->update_lock);
>          if (regval == 255 && data->fan_div[channel] < 3) {
>                  /* adjust fan clock divider on overflow */
>                  err = adm9240_write_fan_div(data, channel,
>                                              ++data->fan_div[channel]);
>                  if (err) {
>                         mutex_unlock(&data->update_lock);
>                          return err;
>                 }
>          }
>         mutex_unlock(&data->update_lock);
>         ...
>
> However, that isn't perfect since the fan divisor and the fan speed
> register value are not in sync. Technically it needs to be something like
>
>         u8 fan_div;
>         ...
>
>         mutex_lock(&data->update_lock);
>         err = regmap_read(data->regmap, ADM9240_REG_FAN(channel), &regval);
>         if (err) {
>                 mutex_unlock(&data->update_lock);
>                 return err;
>         }
>         fan_div = data->fan_div[channel];
>         if (regval == 255 && fan_div < 3) {
>                 err = adm9240_write_fan_div(data, channel, fan_div + 1);
>                 if (err) {
>                         mutex_unlock(&data->update_lock);
>                         return err;
>                 }
>                 data->fan_div[channel] = fan_div + 1;
>         }
>         mutex_unlock(&data->update_lock);
>         *val = FAN_FROM_REG(regval, BIT(fan_div));
>         break;
>
> Thanks,
> Guenter

Thanks for your suggestions and drafts! I submit the patch.

^ permalink raw reply	[relevance 82%]

* [Bug 216529] [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
    2022-09-26  5:02 82% ` Theodore Ts'o
  2022-09-27 18:06 82% ` [Bug 216529] " bugzilla-daemon
@ 2022-09-26  5:02 82% ` bugzilla-daemon
  2022-10-10 17:01 82% ` bugzilla-daemon
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-09-26  5:02 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216529

--- Comment #1 from Theodore Tso (tytso@mit.edu) ---
On Sun, Sep 25, 2022 at 11:55:29AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216529
> 
> 
> Hit a panic on ppc64le, by running generic/048 with 1k block size:

Hmm, does this reproduce reliably for you?  I test with a 1k block
size on x86_64 as a proxy 4k block sizes on PPC64, where the blocksize
< pagesize... and this isn't reproducing for me on x86, and I don't
have access to a PPC64LE system.

Ritesh, is this something you can take a look at it?  Thanks!

                                       - Ted

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 216529] New: [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
  @ 2022-09-26  5:02 82% ` Theodore Ts'o
  2022-09-27 18:10 82%   ` Ritesh Harjani (IBM)
  2022-09-27 18:06 82% ` [Bug 216529] " bugzilla-daemon
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 200+ results
From: Theodore Ts'o @ 2022-09-26  5:02 UTC (permalink / raw)
  To: bugzilla-daemon; +Cc: linux-ext4, Ritesh Harjani (IBM)

On Sun, Sep 25, 2022 at 11:55:29AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216529
> 
> 
> Hit a panic on ppc64le, by running generic/048 with 1k block size:

Hmm, does this reproduce reliably for you?  I test with a 1k block
size on x86_64 as a proxy 4k block sizes on PPC64, where the blocksize
< pagesize... and this isn't reproducing for me on x86, and I don't
have access to a PPC64LE system.

Ritesh, is this something you can take a look at it?  Thanks!

	   		      	       - Ted

^ permalink raw reply	[relevance 82%]

* Re: [Bug 216529] [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
  @ 2022-09-27 18:06 82%   ` Theodore Ts'o
  0 siblings, 0 replies; 200+ results
From: Theodore Ts'o @ 2022-09-27 18:06 UTC (permalink / raw)
  To: bugzilla-daemon; +Cc: linux-ext4

On Tue, Sep 27, 2022 at 12:47:02AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216529
> 
> Yes, it's reproducible for me, I just reproduced it again on another ppc64le
> (P8) machine [1]. But it's not easy to reproduce by running generic/048 (maybe
> there's a better way to reproduce it).

Can you give a rough percentage of how often it reproduces?  e.g.,
does it reproduces 10% of the time?  50% of the time?  2-3 times after
100 tries, so 2-3%?  etc.  If it reproduces but rarely, it'll be a lot
harder to try to bisect.

Something perhaps to try is to enable KASAN, since both stack traces
seem to involve a null pointer derference while trying to free
buffers.   Maybe that will give us some hints towards the cause....

Thanks,

						- Ted

^ permalink raw reply	[relevance 82%]

* [Bug 216529] [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
    2022-09-26  5:02 82% ` Theodore Ts'o
@ 2022-09-27 18:06 82% ` bugzilla-daemon
  2022-09-26  5:02 82% ` bugzilla-daemon
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-09-27 18:06 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216529

--- Comment #3 from Theodore Tso (tytso@mit.edu) ---
On Tue, Sep 27, 2022 at 12:47:02AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216529
> 
> Yes, it's reproducible for me, I just reproduced it again on another ppc64le
> (P8) machine [1]. But it's not easy to reproduce by running generic/048
> (maybe
> there's a better way to reproduce it).

Can you give a rough percentage of how often it reproduces?  e.g.,
does it reproduces 10% of the time?  50% of the time?  2-3 times after
100 tries, so 2-3%?  etc.  If it reproduces but rarely, it'll be a lot
harder to try to bisect.

Something perhaps to try is to enable KASAN, since both stack traces
seem to involve a null pointer derference while trying to free
buffers.   Maybe that will give us some hints towards the cause....

Thanks,

                                                - Ted

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 216529] New: [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
  2022-09-26  5:02 82% ` Theodore Ts'o
@ 2022-09-27 18:10 82%   ` Ritesh Harjani (IBM)
  2022-10-10 17:01 82%     ` Ritesh Harjani (IBM)
  0 siblings, 1 reply; 200+ results
From: Ritesh Harjani (IBM) @ 2022-09-27 18:10 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: bugzilla-daemon, linux-ext4

On 22/09/26 01:02AM, Theodore Ts'o wrote:
> On Sun, Sep 25, 2022 at 11:55:29AM +0000, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=216529
> >
> >
> > Hit a panic on ppc64le, by running generic/048 with 1k block size:
>
> Hmm, does this reproduce reliably for you?  I test with a 1k block
> size on x86_64 as a proxy 4k block sizes on PPC64, where the blocksize
> < pagesize... and this isn't reproducing for me on x86, and I don't
> have access to a PPC64LE system.
>
> Ritesh, is this something you can take a look at it?  Thanks!

I was away for some personal work for last few days, but I am back to work from
today. Sure, I will take a look at this and will get back.

I did give this test a couple of runs though, but wasn't able to reproduce it.
But let me try few more things along with more iterations. Will update
accordingly.

-ritesh

^ permalink raw reply	[relevance 82%]

* [Bug 216529] [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
                     ` (3 preceding siblings ...)
  2022-10-10 17:01 82% ` bugzilla-daemon
@ 2022-09-27 18:10 82% ` bugzilla-daemon
    5 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-09-27 18:10 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216529

--- Comment #4 from ritesh.list@gmail.com ---
On 22/09/26 01:02AM, Theodore Ts'o wrote:
> On Sun, Sep 25, 2022 at 11:55:29AM +0000, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=216529
> >
> >
> > Hit a panic on ppc64le, by running generic/048 with 1k block size:
>
> Hmm, does this reproduce reliably for you?  I test with a 1k block
> size on x86_64 as a proxy 4k block sizes on PPC64, where the blocksize
> < pagesize... and this isn't reproducing for me on x86, and I don't
> have access to a PPC64LE system.
>
> Ritesh, is this something you can take a look at it?  Thanks!

I was away for some personal work for last few days, but I am back to work from
today. Sure, I will take a look at this and will get back.

I did give this test a couple of runs though, but wasn't able to reproduce it.
But let me try few more things along with more iterations. Will update
accordingly.

-ritesh

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 1087] [Bug] tcp data len is incorrectly calculated in gro_tcp4_reassemble function
@ 2022-09-29  1:40 82% bugzilla
  2022-11-10  1:45 82% ` bugzilla
  0 siblings, 1 reply; 200+ results
From: bugzilla @ 2022-09-29  1:40 UTC (permalink / raw)
  To: dev

https://bugs.dpdk.org/show_bug.cgi?id=1087

            Bug ID: 1087
           Summary: [Bug] tcp data len is incorrectly calculated in
                    gro_tcp4_reassemble function
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: other
          Assignee: dev@dpdk.org
          Reporter: 853048484@qq.com
  Target Milestone: ---

Hello:
In gro_tcp4_reassemble function, tcp data len is calculated:
tcp_dl = pkt->pkt_len - hdr_len;
https://github.com/DPDK/dpdk/blob/v22.07/lib/gro/gro_tcp4.c#L232

if packets < 60 bytes, pkt_len will contain padding bytes, tcp_dl is
incorrectly calculated. this will result the wrong data length after gro.

diff --git a/lib/gro/gro_tcp4.c b/lib/gro/gro_tcp4.c index
7498c66141..cbba9fed5e 100644
--- a/lib/gro/gro_tcp4.c
+++ b/lib/gro/gro_tcp4.c
@@ -229,7 +229,7 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt,
         * Don't process the packet whose payload length is less than or
         * equal to 0.
         */
-       tcp_dl = pkt->pkt_len - hdr_len;
+       tcp_dl = rte_be_to_cpu_16(ipv4_hdr->total_length) - hdr_len;
        if (tcp_dl <= 0)
                return -1;

-- 
You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  @ 2022-09-30 10:48 82% ` Mirsad Todorovac
  2022-09-30 11:21 82%   ` Slade Watkins
  2022-10-06 10:39 82%   ` Marc Miltenberger
    1 sibling, 2 replies; 200+ results
From: Mirsad Todorovac @ 2022-09-30 10:48 UTC (permalink / raw)
  To: linux-kernel

Hi all,

I can confirm this bug also on AlmaLinux (CentOS fork) with snapd 
version 105.0.1 of
Firefox.

After some time, tabs started crashing, but restarting Firefox binary 
was after that
unsuccessful, giving the message:

[marvin@pc-mtodorov ~]$ /snap/bin/firefox &
[1] 137734
[marvin@pc-mtodorov ~]$ /bin/bash: /lib/x86_64-linux-gnu/libdl.so.2: 
unsupported version 0 of Verdef record
/bin/bash: error while loading shared libraries: 
/lib/x86_64-linux-gnu/libdl.so.2: unsupported version 0 of Verneed record

[1]+  Exit 127                /snap/bin/firefox
[marvin@pc-mtodorov ~]$

Kind regards.

On 9/27/22 19:57, Mirsad Goran Todorovac wrote:
> Hello all,
>
> This is my first kernel BUG report, so please bear with me for a while 
> if I'm doing something wrong or otherwise awkward.
> I've noticed it in the 6.0.0-rc3 kernel and following patches to see 
> if it will be fixed by other testers.
>
> I've read the bug report instructions, so I hope this will be useful.
>
> However, now we are at rc7, so keeping it for myself when the kernel 
> is near production state might be an offence to good conscience.
>
> In particular, it is the problem with Firefox 104.x and 105.x, which 
> has tabs crashing, and later it refuses to restart.
>
> Exactly the same config works with the other Linux kernels tried 
> (5.15.x and 5.19.x) on the Ubuntu 22.04 system.
>
> Firefox is a snap. The bug persisted with apparmor ON and OFF.
>
> The kernel is compiled with KMEMLEAK and KASAN options, but otherwise 
> it is the default config file for Ubuntu's rc3 release candidate.
>
> Here is the syslog of the startup.
>
> Please find dmesg output. It is rather similar to the dmesg output of 
> production kernels.
>
> /var/log/syslog:
>
> Sep 27 18:43:20 IdeaPad-3 firefox_firefox.desktop[5811]: message 
> repeated 11 times: [ /snap/firefox/1883/usr/lib/firefox/firefox: 
> /snap/firefox/1883/usr/lib/firefox/firefox: no version information 
> available (required by 
> /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so)]
> Sep 27 18:43:20 IdeaPad-3 firefox_firefox.desktop[5811]: 
> /snap/firefox/1883/usr/lib/firefox/firefox: 
> /lib/x86_64-linux-gnu/libpthread.so.0: version `' not found (required 
> by /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so)
> Sep 27 18:43:20 IdeaPad-3 firefox_firefox.desktop[5811]: 
> /snap/firefox/1883/usr/lib/firefox/firefox: 
> /lib/x86_64-linux-gnu/librt.so.1: version `' not found (required by 
> /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so)
> Sep 27 18:43:20 IdeaPad-3 firefox_firefox.desktop[5811]: 
> /snap/firefox/1883/usr/lib/firefox/firefox: 
> /lib/x86_64-linux-gnu/libdl.so.2: version `' not found (required by 
> /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so)
> Sep 27 18:43:27 IdeaPad-3 firefox_firefox.desktop[2686]: Missing 
> chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
> Sep 27 18:43:31 IdeaPad-3 firefox_firefox.desktop[2921]: 
> /snap/firefox/1883/usr/lib/firefox/firefox: symbol lookup error: 
> /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so: undefined symbol: 
> , version
> Sep 27 18:43:33 IdeaPad-3 systemd[1791]: 
> snap.firefox.firefox.8b8574d2-116e-411a-9bba-c145e8cc0aa2.scope: 
> Consumed 10min 18.279s CPU time.
> Sep 27 18:44:49 IdeaPad-3 snapd[818]: storehelpers.go:748: cannot 
> refresh: snap has no updates available: "bare", "canonical-livepatch", 
> "core", "core18", "core20", "firefox", "gnome-3-34-1804", 
> "gnome-3-38-2004", "gtk-common-themes", "slack", "snap-store", 
> "snapd", "zoom-client"
> Sep 27 19:04:59 IdeaPad-3 systemd[1791]: Started 
> snap.firefox.firefox.d0067088-10d8-459d-a40d-fed0c95b1481.scope.
> Sep 27 19:05:04 IdeaPad-3 systemd[1791]: 
> snap.firefox.firefox.d0067088-10d8-459d-a40d-fed0c95b1481.scope: 
> Consumed 4.239s CPU time.
> Sep 27 19:05:41 IdeaPad-3 systemd[1791]: Started 
> snap.firefox.firefox.c93d07ee-bee6-492d-aa89-2e27db5d5ae7.scope.
> Sep 27 19:05:42 IdeaPad-3 systemd[1791]: 
> snap.firefox.firefox.c93d07ee-bee6-492d-aa89-2e27db5d5ae7.scope: 
> Consumed 1.256s CPU time.
> Sep 27 19:06:39 IdeaPad-3 systemd[1791]: Started 
> snap.firefox.firefox.b4550475-1ff8-41ee-9a39-305174eeaa44.scope.
> Sep 27 19:06:41 IdeaPad-3 systemd[1791]: 
> snap.firefox.firefox.b4550475-1ff8-41ee-9a39-305174eeaa44.scope: 
> Consumed 1.231s CPU time.
> Sep 27 19:06:55 IdeaPad-3 systemd[1791]: Started 
> snap.firefox.firefox.c42cb676-a7a7-49e6-8685-610bd9c1de81.scope.
>
> $ sudo dmesg -l err
> [    1.638759] ACPI BIOS Error (bug): Could not resolve symbol 
> [\_SB.PCI0], AE_NOT_FOUND (20220331/dswload2-162)
> [    1.638854] ACPI Error: AE_NOT_FOUND, During name lookup/catalog 
> (20220331/psobject-220)
> [    2.175611] ACPI BIOS Error (bug): Could not resolve symbol 
> [\_SB.PC00.DGPV], AE_NOT_FOUND (20220331/psargs-330)
> [    2.175731] ACPI Error: Aborting method \_SB.PC00.PEG0.PCRP._ON due 
> to previous error (AE_NOT_FOUND) (20220331/psparse-529)
> [    5.519037] integrity: Problem loading X.509 certificate -65
> [   10.010679] mtd device must be supplied (device name is empty)
> [   12.220863] i801_smbus 0000:00:1f.4: Transaction timeout
> [   12.222934] i801_smbus 0000:00:1f.4: Failed terminating the 
> transaction
> [   12.223023] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
> [   13.092867] rcu: INFO: rcu_preempt detected expedited stalls on 
> CPUs/tasks: { 3-.... } 6 jiffies s: 61 root: 0x8/.
> [   13.092878] rcu: blocking rcu_node structures (internal RCU debug):
> [   13.991053] mtd device must be supplied (device name is empty)
> [   15.315968] Bluetooth: hci0: Malformed MSFT vendor event: 0x02
> [   18.018388] ACPI BIOS Error (bug): Could not resolve symbol 
> [\_TZ.ETMD], AE_NOT_FOUND (20220331/psargs-330)
> [   18.018857] ACPI Error: Aborting method \_SB.IETM._OSC due to 
> previous error (AE_NOT_FOUND) (20220331/psparse-529)
>
> Please find attached the config file for the kernel build. Source is 
> rc7 "master" clean after rc7 rlse.
>
> Here is the demonstration of bug with apparmor ON and OFF:
>
> $ sudo systemctl stop apparmor
> $ firefox &
> [1] 7825
> $ date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: symbol lookup error: date: undefined symbol: , version GLIBC_2.2.5
> chmod: chmod: no version information available (required by chmod)
> chmod: chmod: no version information available (required by chmod)
> chmod: chmod: no version information available (required by chmod)
> chmod: chmod: no version information available (required by chmod)
> chmod: chmod: no version information available (required by chmod)
> chmod: symbol lookup error: chmod: undefined symbol: , version
> xdg-user-dirs-update: error while loading shared libraries: 
> xdg-user-dirs-update: unsupported version 0 of Verneed record
> rm: rm: no version information available (required by rm)
> rm: rm: no version information available (required by rm)
> rm: rm: no version information available (required by rm)
> rm: rm: no version information available (required by rm)
> rm: rm: no version information available (required by rm)
> rm: symbol lookup error: rm: undefined symbol: , version GLIBC_2.2.5
> XPCOMGlueLoad error for file 
> /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so:
> /lib/x86_64-linux-gnu/libpthread.so.0: version `' not found (required 
> by /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so)
> Couldn't load XPCOM.
>
> [1]+  Exit 255                firefox
> $
> $ sudo systemctl start apparmor
> $ firefox &
> [1] 7996
> $ date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: date: no version information available (required by date)
> date: symbol lookup error: date: undefined symbol: , version GLIBC_2.2.5
> chmod: chmod: no version information available (required by chmod)
> chmod: chmod: no version information available (required by chmod)
> chmod: chmod: no version information available (required by chmod)
> chmod: chmod: no version information available (required by chmod)
> chmod: chmod: no version information available (required by chmod)
> chmod: symbol lookup error: chmod: undefined symbol: , version
> xdg-user-dirs-update: error while loading shared libraries: 
> xdg-user-dirs-update: unsupported version 0 of Verneed record
> XPCOMGlueLoad error for file 
> /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so:
> /lib/x86_64-linux-gnu/libpthread.so.0: version `' not found (required 
> by /snap/firefox/1883/usr/lib/firefox/libmozsandbox.so)
> Couldn't load XPCOM.
>
> All other apps work OK AFAICS, however I suspected a kernel bug since 
> it only shows only in RC kernels
> (even the Ubuntu's own 6.0.0-rc3 mainline build).
>
> Hope this helps someone. I could provide more info at request.
>
> Kind regards,
>
> Mirsad
>
> .config:
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86 6.0.0-rc3 Kernel Configuration
> #
> CONFIG_CC_VERSION_TEXT="gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0"
> CONFIG_CC_IS_GCC=y
> CONFIG_GCC_VERSION=110200
> CONFIG_CLANG_VERSION=0
> CONFIG_AS_IS_GNU=y
> CONFIG_AS_VERSION=23800
> CONFIG_LD_IS_BFD=y
> CONFIG_LD_VERSION=23800
> CONFIG_LLD_VERSION=0
> CONFIG_CC_CAN_LINK=y
> CONFIG_CC_CAN_LINK_STATIC=y
> CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y
> CONFIG_CC_HAS_ASM_INLINE=y
> CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
> CONFIG_PAHOLE_VERSION=122
> CONFIG_CONSTRUCTORS=y
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_TABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
>
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> # CONFIG_COMPILE_TEST is not set
> # CONFIG_WERROR is not set
> CONFIG_LOCALVERSION=""
> # CONFIG_LOCALVERSION_AUTO is not set
> CONFIG_BUILD_SALT=""
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_HAVE_KERNEL_ZSTD=y
> # CONFIG_KERNEL_GZIP is not set
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_KERNEL_ZSTD=y
> CONFIG_DEFAULT_INIT=""
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_SYSVIPC_COMPAT=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_WATCH_QUEUE=y
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_USELIB=y
> CONFIG_AUDIT=y
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> CONFIG_AUDITSYSCALL=y
>
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_MIGRATION=y
> CONFIG_HARDIRQS_SW_RESEND=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_SIM=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> CONFIG_IRQ_MSI_IOMMU=y
> CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
> CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> # CONFIG_GENERIC_IRQ_DEBUGFS is not set
> # end of IRQ subsystem
>
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_INIT=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK=y
> CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y
> CONFIG_CONTEXT_TRACKING=y
> CONFIG_CONTEXT_TRACKING_IDLE=y
>
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US=100
> # end of Timers subsystem
>
> CONFIG_BPF=y
> CONFIG_HAVE_EBPF_JIT=y
> CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
>
> #
> # BPF subsystem
> #
> CONFIG_BPF_SYSCALL=y
> CONFIG_BPF_JIT=y
> CONFIG_BPF_JIT_ALWAYS_ON=y
> CONFIG_BPF_JIT_DEFAULT_ON=y
> CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
> CONFIG_USERMODE_DRIVER=y
> # CONFIG_BPF_PRELOAD is not set
> CONFIG_BPF_LSM=y
> # end of BPF subsystem
>
> CONFIG_PREEMPT_BUILD=y
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> # CONFIG_PREEMPT is not set
> CONFIG_PREEMPT_COUNT=y
> CONFIG_PREEMPTION=y
> CONFIG_PREEMPT_DYNAMIC=y
> CONFIG_SCHED_CORE=y
>
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> CONFIG_BSD_PROCESS_ACCT=y
> CONFIG_BSD_PROCESS_ACCT_V3=y
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> CONFIG_PSI=y
> # CONFIG_PSI_DEFAULT_DISABLED is not set
> # end of CPU/Task time and stats accounting
>
> CONFIG_CPU_ISOLATION=y
>
> #
> # RCU Subsystem
> #
> CONFIG_TREE_RCU=y
> CONFIG_PREEMPT_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> CONFIG_TREE_SRCU=y
> CONFIG_TASKS_RCU_GENERIC=y
> CONFIG_TASKS_RCU=y
> CONFIG_TASKS_RUDE_RCU=y
> CONFIG_TASKS_TRACE_RCU=y
> CONFIG_RCU_STALL_COMMON=y
> CONFIG_RCU_NEED_SEGCBLIST=y
> # end of RCU Subsystem
>
> CONFIG_BUILD_BIN2C=y
> # CONFIG_IKCONFIG is not set
> CONFIG_IKHEADERS=m
> CONFIG_LOG_BUF_SHIFT=18
> CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
> CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
> # CONFIG_PRINTK_INDEX is not set
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
>
> #
> # Scheduler features
> #
> CONFIG_UCLAMP_TASK=y
> CONFIG_UCLAMP_BUCKETS_COUNT=5
> # end of Scheduler features
>
> CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
> CONFIG_CC_HAS_INT128=y
> CONFIG_CC_IMPLICIT_FALLTHROUGH="-Wimplicit-fallthrough=5"
> CONFIG_GCC12_NO_ARRAY_BOUNDS=y
> CONFIG_ARCH_SUPPORTS_INT128=y
> CONFIG_NUMA_BALANCING=y
> CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
> CONFIG_CGROUPS=y
> CONFIG_PAGE_COUNTER=y
> # CONFIG_CGROUP_FAVOR_DYNMODS is not set
> CONFIG_MEMCG=y
> CONFIG_MEMCG_SWAP=y
> CONFIG_MEMCG_KMEM=y
> CONFIG_BLK_CGROUP=y
> CONFIG_CGROUP_WRITEBACK=y
> CONFIG_CGROUP_SCHED=y
> CONFIG_FAIR_GROUP_SCHED=y
> CONFIG_CFS_BANDWIDTH=y
> # CONFIG_RT_GROUP_SCHED is not set
> CONFIG_UCLAMP_TASK_GROUP=y
> CONFIG_CGROUP_PIDS=y
> CONFIG_CGROUP_RDMA=y
> CONFIG_CGROUP_FREEZER=y
> CONFIG_CGROUP_HUGETLB=y
> CONFIG_CPUSETS=y
> CONFIG_PROC_PID_CPUSET=y
> CONFIG_CGROUP_DEVICE=y
> CONFIG_CGROUP_CPUACCT=y
> CONFIG_CGROUP_PERF=y
> CONFIG_CGROUP_BPF=y
> CONFIG_CGROUP_MISC=y
> # CONFIG_CGROUP_DEBUG is not set
> CONFIG_SOCK_CGROUP_DATA=y
> CONFIG_NAMESPACES=y
> CONFIG_UTS_NS=y
> CONFIG_TIME_NS=y
> CONFIG_IPC_NS=y
> CONFIG_USER_NS=y
> CONFIG_PID_NS=y
> CONFIG_NET_NS=y
> CONFIG_CHECKPOINT_RESTORE=y
> CONFIG_SCHED_AUTOGROUP=y
> # CONFIG_SYSFS_DEPRECATED is not set
> CONFIG_RELAY=y
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_INITRAMFS_SOURCE=""
> CONFIG_RD_GZIP=y
> CONFIG_RD_BZIP2=y
> CONFIG_RD_LZMA=y
> CONFIG_RD_XZ=y
> CONFIG_RD_LZO=y
> CONFIG_RD_LZ4=y
> CONFIG_RD_ZSTD=y
> CONFIG_BOOT_CONFIG=y
> # CONFIG_BOOT_CONFIG_EMBED is not set
> CONFIG_INITRAMFS_PRESERVE_MTIME=y
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> CONFIG_LD_ORPHAN_WARN=y
> CONFIG_SYSCTL=y
> CONFIG_HAVE_UID16=y
> CONFIG_SYSCTL_EXCEPTION_TRACE=y
> CONFIG_HAVE_PCSPKR_PLATFORM=y
> CONFIG_EXPERT=y
> CONFIG_UID16=y
> CONFIG_MULTIUSER=y
> CONFIG_SGETMASK_SYSCALL=y
> CONFIG_SYSFS_SYSCALL=y
> CONFIG_FHANDLE=y
> CONFIG_POSIX_TIMERS=y
> CONFIG_PRINTK=y
> CONFIG_BUG=y
> CONFIG_ELF_CORE=y
> CONFIG_PCSPKR_PLATFORM=y
> CONFIG_BASE_FULL=y
> CONFIG_FUTEX=y
> CONFIG_FUTEX_PI=y
> CONFIG_EPOLL=y
> CONFIG_SIGNALFD=y
> CONFIG_TIMERFD=y
> CONFIG_EVENTFD=y
> CONFIG_SHMEM=y
> CONFIG_AIO=y
> CONFIG_IO_URING=y
> CONFIG_ADVISE_SYSCALLS=y
> CONFIG_MEMBARRIER=y
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_ALL=y
> CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
> CONFIG_KALLSYMS_BASE_RELATIVE=y
> CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
> CONFIG_KCMP=y
> CONFIG_RSEQ=y
> # CONFIG_DEBUG_RSEQ is not set
> # CONFIG_EMBEDDED is not set
> CONFIG_HAVE_PERF_EVENTS=y
> CONFIG_GUEST_PERF_EVENTS=y
> CONFIG_PC104=y
>
> #
> # Kernel Performance Events And Counters
> #
> CONFIG_PERF_EVENTS=y
> # CONFIG_DEBUG_PERF_USE_VMALLOC is not set
> # end of Kernel Performance Events And Counters
>
> CONFIG_SYSTEM_DATA_VERIFICATION=y
> CONFIG_PROFILING=y
> CONFIG_TRACEPOINTS=y
> # end of General setup
>
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_NR_GPIO=1024
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_KASAN_SHADOW_OFFSET=0xdffffc0000000000
> CONFIG_HAVE_INTEL_TXT=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_DYNAMIC_PHYSICAL_MASK=y
> CONFIG_PGTABLE_LEVELS=5
> CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
>
> #
> # Processor type and features
> #
> CONFIG_SMP=y
> CONFIG_X86_FEATURE_NAMES=y
> CONFIG_X86_X2APIC=y
> CONFIG_X86_MPPARSE=y
> # CONFIG_GOLDFISH is not set
> CONFIG_X86_CPU_RESCTRL=y
> CONFIG_X86_EXTENDED_PLATFORM=y
> CONFIG_X86_NUMACHIP=y
> # CONFIG_X86_VSMP is not set
> CONFIG_X86_UV=y
> # CONFIG_X86_GOLDFISH is not set
> # CONFIG_X86_INTEL_MID is not set
> CONFIG_X86_INTEL_LPSS=y
> CONFIG_X86_AMD_PLATFORM_DEVICE=y
> CONFIG_IOSF_MBI=y
> CONFIG_IOSF_MBI_DEBUG=y
> CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
> CONFIG_SCHED_OMIT_FRAME_POINTER=y
> CONFIG_HYPERVISOR_GUEST=y
> CONFIG_PARAVIRT=y
> CONFIG_PARAVIRT_XXL=y
> # CONFIG_PARAVIRT_DEBUG is not set
> CONFIG_PARAVIRT_SPINLOCKS=y
> CONFIG_X86_HV_CALLBACK_VECTOR=y
> CONFIG_XEN=y
> CONFIG_XEN_PV=y
> CONFIG_XEN_512GB=y
> CONFIG_XEN_PV_SMP=y
> CONFIG_XEN_PV_DOM0=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_PVHVM_SMP=y
> CONFIG_XEN_PVHVM_GUEST=y
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> CONFIG_XEN_PVH=y
> CONFIG_XEN_DOM0=y
> CONFIG_KVM_GUEST=y
> CONFIG_ARCH_CPUIDLE_HALTPOLL=y
> CONFIG_PVH=y
> # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
> CONFIG_PARAVIRT_CLOCK=y
> CONFIG_JAILHOUSE_GUEST=y
> CONFIG_ACRN_GUEST=y
> CONFIG_INTEL_TDX_GUEST=y
> # CONFIG_MK8 is not set
> # CONFIG_MPSC is not set
> # CONFIG_MCORE2 is not set
> # CONFIG_MATOM is not set
> CONFIG_GENERIC_CPU=y
> CONFIG_X86_INTERNODE_CACHE_SHIFT=6
> CONFIG_X86_L1_CACHE_SHIFT=6
> CONFIG_X86_TSC=y
> CONFIG_X86_CMPXCHG64=y
> CONFIG_X86_CMOV=y
> CONFIG_X86_MINIMUM_CPU_FAMILY=64
> CONFIG_X86_DEBUGCTLMSR=y
> CONFIG_IA32_FEAT_CTL=y
> CONFIG_X86_VMX_FEATURE_NAMES=y
> CONFIG_PROCESSOR_SELECT=y
> CONFIG_CPU_SUP_INTEL=y
> CONFIG_CPU_SUP_AMD=y
> CONFIG_CPU_SUP_HYGON=y
> CONFIG_CPU_SUP_CENTAUR=y
> CONFIG_CPU_SUP_ZHAOXIN=y
> CONFIG_HPET_TIMER=y
> CONFIG_HPET_EMULATE_RTC=y
> CONFIG_DMI=y
> CONFIG_GART_IOMMU=y
> CONFIG_BOOT_VESA_SUPPORT=y
> CONFIG_MAXSMP=y
> CONFIG_NR_CPUS_RANGE_BEGIN=8192
> CONFIG_NR_CPUS_RANGE_END=8192
> CONFIG_NR_CPUS_DEFAULT=8192
> CONFIG_NR_CPUS=8192
> CONFIG_SCHED_CLUSTER=y
> CONFIG_SCHED_SMT=y
> CONFIG_SCHED_MC=y
> CONFIG_SCHED_MC_PRIO=y
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_IO_APIC=y
> CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
> CONFIG_X86_MCE=y
> CONFIG_X86_MCELOG_LEGACY=y
> CONFIG_X86_MCE_INTEL=y
> CONFIG_X86_MCE_AMD=y
> CONFIG_X86_MCE_THRESHOLD=y
> CONFIG_X86_MCE_INJECT=m
>
> #
> # Performance monitoring
> #
> CONFIG_PERF_EVENTS_INTEL_UNCORE=y
> CONFIG_PERF_EVENTS_INTEL_RAPL=m
> CONFIG_PERF_EVENTS_INTEL_CSTATE=m
> # CONFIG_PERF_EVENTS_AMD_POWER is not set
> CONFIG_PERF_EVENTS_AMD_UNCORE=m
> CONFIG_PERF_EVENTS_AMD_BRS=y
> # end of Performance monitoring
>
> CONFIG_X86_16BIT=y
> CONFIG_X86_ESPFIX64=y
> CONFIG_X86_VSYSCALL_EMULATION=y
> CONFIG_X86_IOPL_IOPERM=y
> CONFIG_MICROCODE=y
> CONFIG_MICROCODE_INTEL=y
> CONFIG_MICROCODE_AMD=y
> # CONFIG_MICROCODE_LATE_LOADING is not set
> CONFIG_X86_MSR=m
> CONFIG_X86_CPUID=m
> CONFIG_X86_5LEVEL=y
> CONFIG_X86_DIRECT_GBPAGES=y
> # CONFIG_X86_CPA_STATISTICS is not set
> CONFIG_X86_MEM_ENCRYPT=y
> CONFIG_AMD_MEM_ENCRYPT=y
> # CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is not set
> CONFIG_NUMA=y
> CONFIG_AMD_NUMA=y
> CONFIG_X86_64_ACPI_NUMA=y
> # CONFIG_NUMA_EMU is not set
> CONFIG_NODES_SHIFT=10
> CONFIG_ARCH_SPARSEMEM_ENABLE=y
> CONFIG_ARCH_SPARSEMEM_DEFAULT=y
> CONFIG_ARCH_MEMORY_PROBE=y
> CONFIG_ARCH_PROC_KCORE_TEXT=y
> CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
> CONFIG_X86_PMEM_LEGACY_DEVICE=y
> CONFIG_X86_PMEM_LEGACY=y
> CONFIG_X86_CHECK_BIOS_CORRUPTION=y
> CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
> CONFIG_MTRR=y
> CONFIG_MTRR_SANITIZER=y
> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
> CONFIG_X86_PAT=y
> CONFIG_ARCH_USES_PG_UNCACHED=y
> CONFIG_X86_UMIP=y
> CONFIG_CC_HAS_IBT=y
> # CONFIG_X86_KERNEL_IBT is not set
> CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=y
> CONFIG_X86_INTEL_TSX_MODE_OFF=y
> # CONFIG_X86_INTEL_TSX_MODE_ON is not set
> # CONFIG_X86_INTEL_TSX_MODE_AUTO is not set
> CONFIG_X86_SGX=y
> CONFIG_EFI=y
> CONFIG_EFI_STUB=y
> CONFIG_EFI_MIXED=y
> # CONFIG_HZ_100 is not set
> CONFIG_HZ_250=y
> # CONFIG_HZ_300 is not set
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=250
> CONFIG_SCHED_HRTICK=y
> CONFIG_KEXEC=y
> CONFIG_KEXEC_FILE=y
> CONFIG_ARCH_HAS_KEXEC_PURGATORY=y
> CONFIG_KEXEC_SIG=y
> # CONFIG_KEXEC_SIG_FORCE is not set
> CONFIG_KEXEC_BZIMAGE_VERIFY_SIG=y
> CONFIG_CRASH_DUMP=y
> CONFIG_KEXEC_JUMP=y
> CONFIG_PHYSICAL_START=0x1000000
> CONFIG_RELOCATABLE=y
> CONFIG_RANDOMIZE_BASE=y
> CONFIG_X86_NEED_RELOCS=y
> CONFIG_PHYSICAL_ALIGN=0x200000
> CONFIG_DYNAMIC_MEMORY_LAYOUT=y
> CONFIG_RANDOMIZE_MEMORY=y
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
> CONFIG_HOTPLUG_CPU=y
> # CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
> # CONFIG_DEBUG_HOTPLUG_CPU0 is not set
> # CONFIG_COMPAT_VDSO is not set
> CONFIG_LEGACY_VSYSCALL_XONLY=y
> # CONFIG_LEGACY_VSYSCALL_NONE is not set
> # CONFIG_CMDLINE_BOOL is not set
> CONFIG_MODIFY_LDT_SYSCALL=y
> # CONFIG_STRICT_SIGALTSTACK_SIZE is not set
> CONFIG_HAVE_LIVEPATCH=y
> CONFIG_LIVEPATCH=y
> # end of Processor type and features
>
> CONFIG_CC_HAS_SLS=y
> CONFIG_CC_HAS_RETURN_THUNK=y
> CONFIG_SPECULATION_MITIGATIONS=y
> CONFIG_PAGE_TABLE_ISOLATION=y
> CONFIG_RETPOLINE=y
> CONFIG_RETHUNK=y
> CONFIG_CPU_UNRET_ENTRY=y
> CONFIG_CPU_IBPB_ENTRY=y
> CONFIG_CPU_IBRS_ENTRY=y
> CONFIG_SLS=y
> CONFIG_ARCH_HAS_ADD_PAGES=y
> CONFIG_ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE=y
>
> #
> # Power management and ACPI options
> #
> CONFIG_ARCH_HIBERNATION_HEADER=y
> CONFIG_SUSPEND=y
> CONFIG_SUSPEND_FREEZER=y
> # CONFIG_SUSPEND_SKIP_SYNC is not set
> CONFIG_HIBERNATE_CALLBACKS=y
> CONFIG_HIBERNATION=y
> CONFIG_HIBERNATION_SNAPSHOT_DEV=y
> CONFIG_PM_STD_PARTITION=""
> CONFIG_PM_SLEEP=y
> CONFIG_PM_SLEEP_SMP=y
> # CONFIG_PM_AUTOSLEEP is not set
> # CONFIG_PM_USERSPACE_AUTOSLEEP is not set
> CONFIG_PM_WAKELOCKS=y
> CONFIG_PM_WAKELOCKS_LIMIT=100
> CONFIG_PM_WAKELOCKS_GC=y
> CONFIG_PM=y
> CONFIG_PM_DEBUG=y
> CONFIG_PM_ADVANCED_DEBUG=y
> # CONFIG_PM_TEST_SUSPEND is not set
> CONFIG_PM_SLEEP_DEBUG=y
> # CONFIG_DPM_WATCHDOG is not set
> CONFIG_PM_TRACE=y
> CONFIG_PM_TRACE_RTC=y
> CONFIG_PM_CLK=y
> CONFIG_PM_GENERIC_DOMAINS=y
> CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
> CONFIG_PM_GENERIC_DOMAINS_SLEEP=y
> CONFIG_ENERGY_MODEL=y
> CONFIG_ARCH_SUPPORTS_ACPI=y
> CONFIG_ACPI=y
> CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
> CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
> CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
> CONFIG_ACPI_TABLE_LIB=y
> CONFIG_ACPI_DEBUGGER=y
> CONFIG_ACPI_DEBUGGER_USER=y
> CONFIG_ACPI_SPCR_TABLE=y
> CONFIG_ACPI_FPDT=y
> CONFIG_ACPI_LPIT=y
> CONFIG_ACPI_SLEEP=y
> CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
> CONFIG_ACPI_EC_DEBUGFS=m
> CONFIG_ACPI_AC=y
> CONFIG_ACPI_BATTERY=y
> CONFIG_ACPI_BUTTON=y
> CONFIG_ACPI_VIDEO=m
> CONFIG_ACPI_FAN=y
> CONFIG_ACPI_TAD=m
> CONFIG_ACPI_DOCK=y
> CONFIG_ACPI_CPU_FREQ_PSS=y
> CONFIG_ACPI_PROCESSOR_CSTATE=y
> CONFIG_ACPI_PROCESSOR_IDLE=y
> CONFIG_ACPI_CPPC_LIB=y
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_ACPI_IPMI=m
> CONFIG_ACPI_HOTPLUG_CPU=y
> CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
> CONFIG_ACPI_THERMAL=y
> CONFIG_ACPI_PLATFORM_PROFILE=m
> CONFIG_ACPI_CUSTOM_DSDT_FILE=""
> CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
> CONFIG_ACPI_TABLE_UPGRADE=y
> CONFIG_ACPI_DEBUG=y
> CONFIG_ACPI_PCI_SLOT=y
> CONFIG_ACPI_CONTAINER=y
> CONFIG_ACPI_HOTPLUG_MEMORY=y
> CONFIG_ACPI_HOTPLUG_IOAPIC=y
> CONFIG_ACPI_SBS=m
> CONFIG_ACPI_HED=y
> # CONFIG_ACPI_CUSTOM_METHOD is not set
> CONFIG_ACPI_BGRT=y
> # CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
> CONFIG_ACPI_NFIT=m
> # CONFIG_NFIT_SECURITY_DEBUG is not set
> CONFIG_ACPI_NUMA=y
> CONFIG_ACPI_HMAT=y
> CONFIG_HAVE_ACPI_APEI=y
> CONFIG_HAVE_ACPI_APEI_NMI=y
> CONFIG_ACPI_APEI=y
> CONFIG_ACPI_APEI_GHES=y
> CONFIG_ACPI_APEI_PCIEAER=y
> CONFIG_ACPI_APEI_MEMORY_FAILURE=y
> CONFIG_ACPI_APEI_EINJ=m
> # CONFIG_ACPI_APEI_ERST_DEBUG is not set
> CONFIG_ACPI_DPTF=y
> CONFIG_DPTF_POWER=m
> CONFIG_DPTF_PCH_FIVR=m
> CONFIG_ACPI_WATCHDOG=y
> CONFIG_ACPI_EXTLOG=m
> CONFIG_ACPI_ADXL=y
> CONFIG_ACPI_CONFIGFS=m
> CONFIG_ACPI_PFRUT=m
> CONFIG_ACPI_PCC=y
> CONFIG_PMIC_OPREGION=y
> CONFIG_BYTCRC_PMIC_OPREGION=y
> CONFIG_CHTCRC_PMIC_OPREGION=y
> CONFIG_XPOWER_PMIC_OPREGION=y
> CONFIG_BXT_WC_PMIC_OPREGION=y
> CONFIG_CHT_WC_PMIC_OPREGION=y
> CONFIG_CHT_DC_TI_PMIC_OPREGION=y
> CONFIG_TPS68470_PMIC_OPREGION=y
> CONFIG_ACPI_VIOT=y
> CONFIG_ACPI_PRMT=y
> CONFIG_X86_PM_TIMER=y
>
> #
> # CPU Frequency scaling
> #
> CONFIG_CPU_FREQ=y
> CONFIG_CPU_FREQ_GOV_ATTR_SET=y
> CONFIG_CPU_FREQ_GOV_COMMON=y
> CONFIG_CPU_FREQ_STAT=y
> # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
> # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
> CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y
> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
>
> #
> # CPU frequency scaling drivers
> #
> CONFIG_X86_INTEL_PSTATE=y
> CONFIG_X86_PCC_CPUFREQ=y
> CONFIG_X86_AMD_PSTATE=y
> CONFIG_X86_ACPI_CPUFREQ=y
> CONFIG_X86_ACPI_CPUFREQ_CPB=y
> CONFIG_X86_POWERNOW_K8=y
> CONFIG_X86_AMD_FREQ_SENSITIVITY=m
> CONFIG_X86_SPEEDSTEP_CENTRINO=y
> CONFIG_X86_P4_CLOCKMOD=m
>
> #
> # shared options
> #
> CONFIG_X86_SPEEDSTEP_LIB=m
> # end of CPU Frequency scaling
>
> #
> # CPU Idle
> #
> CONFIG_CPU_IDLE=y
> CONFIG_CPU_IDLE_GOV_LADDER=y
> CONFIG_CPU_IDLE_GOV_MENU=y
> CONFIG_CPU_IDLE_GOV_TEO=y
> CONFIG_CPU_IDLE_GOV_HALTPOLL=y
> CONFIG_HALTPOLL_CPUIDLE=m
> # end of CPU Idle
>
> CONFIG_INTEL_IDLE=y
> # end of Power management and ACPI options
>
> #
> # Bus options (PCI etc.)
> #
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_MMCONFIG=y
> CONFIG_PCI_XEN=y
> CONFIG_MMCONF_FAM10H=y
> # CONFIG_PCI_CNB20LE_QUIRK is not set
> CONFIG_ISA_BUS=y
> CONFIG_ISA_DMA_API=y
> CONFIG_AMD_NB=y
> # end of Bus options (PCI etc.)
>
> #
> # Binary Emulations
> #
> CONFIG_IA32_EMULATION=y
> # CONFIG_X86_X32_ABI is not set
> CONFIG_COMPAT_32=y
> CONFIG_COMPAT=y
> CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
> # end of Binary Emulations
>
> CONFIG_HAVE_KVM=y
> CONFIG_HAVE_KVM_PFNCACHE=y
> CONFIG_HAVE_KVM_IRQCHIP=y
> CONFIG_HAVE_KVM_IRQFD=y
> CONFIG_HAVE_KVM_IRQ_ROUTING=y
> CONFIG_HAVE_KVM_DIRTY_RING=y
> CONFIG_HAVE_KVM_EVENTFD=y
> CONFIG_KVM_MMIO=y
> CONFIG_KVM_ASYNC_PF=y
> CONFIG_HAVE_KVM_MSI=y
> CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
> CONFIG_KVM_VFIO=y
> CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
> CONFIG_KVM_COMPAT=y
> CONFIG_HAVE_KVM_IRQ_BYPASS=y
> CONFIG_HAVE_KVM_NO_POLL=y
> CONFIG_KVM_XFER_TO_GUEST_WORK=y
> CONFIG_HAVE_KVM_PM_NOTIFIER=y
> CONFIG_VIRTUALIZATION=y
> CONFIG_KVM=m
> CONFIG_KVM_WERROR=y
> CONFIG_KVM_INTEL=m
> CONFIG_X86_SGX_KVM=y
> CONFIG_KVM_AMD=m
> CONFIG_KVM_AMD_SEV=y
> CONFIG_KVM_XEN=y
> CONFIG_KVM_EXTERNAL_WRITE_TRACKING=y
> CONFIG_AS_AVX512=y
> CONFIG_AS_SHA1_NI=y
> CONFIG_AS_SHA256_NI=y
> CONFIG_AS_TPAUSE=y
>
> #
> # General architecture-dependent options
> #
> CONFIG_CRASH_CORE=y
> CONFIG_KEXEC_CORE=y
> CONFIG_HAVE_IMA_KEXEC=y
> CONFIG_HOTPLUG_SMT=y
> CONFIG_GENERIC_ENTRY=y
> CONFIG_KPROBES=y
> CONFIG_JUMP_LABEL=y
> # CONFIG_STATIC_KEYS_SELFTEST is not set
> # CONFIG_STATIC_CALL_SELFTEST is not set
> CONFIG_OPTPROBES=y
> CONFIG_KPROBES_ON_FTRACE=y
> CONFIG_UPROBES=y
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> CONFIG_ARCH_USE_BUILTIN_BSWAP=y
> CONFIG_KRETPROBES=y
> CONFIG_KRETPROBE_ON_RETHOOK=y
> CONFIG_USER_RETURN_NOTIFIER=y
> CONFIG_HAVE_IOREMAP_PROT=y
> CONFIG_HAVE_KPROBES=y
> CONFIG_HAVE_KRETPROBES=y
> CONFIG_HAVE_OPTPROBES=y
> CONFIG_HAVE_KPROBES_ON_FTRACE=y
> CONFIG_ARCH_CORRECT_STACKTRACE_ON_KRETPROBE=y
> CONFIG_HAVE_FUNCTION_ERROR_INJECTION=y
> CONFIG_HAVE_NMI=y
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> CONFIG_TRACE_IRQFLAGS_NMI_SUPPORT=y
> CONFIG_HAVE_ARCH_TRACEHOOK=y
> CONFIG_HAVE_DMA_CONTIGUOUS=y
> CONFIG_GENERIC_SMP_IDLE_THREAD=y
> CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
> CONFIG_ARCH_HAS_SET_MEMORY=y
> CONFIG_ARCH_HAS_SET_DIRECT_MAP=y
> CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y
> CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
> CONFIG_ARCH_WANTS_NO_INSTR=y
> CONFIG_HAVE_ASM_MODVERSIONS=y
> CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
> CONFIG_HAVE_RSEQ=y
> CONFIG_HAVE_FUNCTION_ARG_ACCESS_API=y
> CONFIG_HAVE_HW_BREAKPOINT=y
> CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
> CONFIG_HAVE_USER_RETURN_NOTIFIER=y
> CONFIG_HAVE_PERF_EVENTS_NMI=y
> CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y
> CONFIG_HAVE_PERF_REGS=y
> CONFIG_HAVE_PERF_USER_STACK_DUMP=y
> CONFIG_HAVE_ARCH_JUMP_LABEL=y
> CONFIG_HAVE_ARCH_JUMP_LABEL_RELATIVE=y
> CONFIG_MMU_GATHER_TABLE_FREE=y
> CONFIG_MMU_GATHER_RCU_TABLE_FREE=y
> CONFIG_MMU_GATHER_MERGE_VMAS=y
> CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
> CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
> CONFIG_HAVE_CMPXCHG_LOCAL=y
> CONFIG_HAVE_CMPXCHG_DOUBLE=y
> CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
> CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
> CONFIG_HAVE_ARCH_SECCOMP=y
> CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
> CONFIG_SECCOMP=y
> CONFIG_SECCOMP_FILTER=y
> # CONFIG_SECCOMP_CACHE_DEBUG is not set
> CONFIG_HAVE_ARCH_STACKLEAK=y
> CONFIG_HAVE_STACKPROTECTOR=y
> CONFIG_STACKPROTECTOR=y
> CONFIG_STACKPROTECTOR_STRONG=y
> CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
> CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
> CONFIG_LTO_NONE=y
> CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
> CONFIG_HAVE_CONTEXT_TRACKING_USER=y
> CONFIG_HAVE_CONTEXT_TRACKING_USER_OFFSTACK=y
> CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
> CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
> CONFIG_HAVE_MOVE_PUD=y
> CONFIG_HAVE_MOVE_PMD=y
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
> CONFIG_HAVE_ARCH_HUGE_VMAP=y
> CONFIG_HAVE_ARCH_HUGE_VMALLOC=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_HAVE_ARCH_SOFT_DIRTY=y
> CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
> CONFIG_MODULES_USE_ELF_RELA=y
> CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
> CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK=y
> CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
> CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
> CONFIG_HAVE_EXIT_THREAD=y
> CONFIG_ARCH_MMAP_RND_BITS=28
> CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
> CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES=y
> CONFIG_PAGE_SIZE_LESS_THAN_64KB=y
> CONFIG_PAGE_SIZE_LESS_THAN_256KB=y
> CONFIG_HAVE_OBJTOOL=y
> CONFIG_HAVE_JUMP_LABEL_HACK=y
> CONFIG_HAVE_NOINSTR_HACK=y
> CONFIG_HAVE_NOINSTR_VALIDATION=y
> CONFIG_HAVE_UACCESS_VALIDATION=y
> CONFIG_HAVE_STACK_VALIDATION=y
> CONFIG_HAVE_RELIABLE_STACKTRACE=y
> CONFIG_ISA_BUS_API=y
> CONFIG_OLD_SIGSUSPEND3=y
> CONFIG_COMPAT_OLD_SIGACTION=y
> CONFIG_COMPAT_32BIT_TIME=y
> CONFIG_HAVE_ARCH_VMAP_STACK=y
> CONFIG_HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET=y
> CONFIG_RANDOMIZE_KSTACK_OFFSET=y
> CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y
> CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
> CONFIG_STRICT_KERNEL_RWX=y
> CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
> CONFIG_STRICT_MODULE_RWX=y
> CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y
> CONFIG_ARCH_USE_MEMREMAP_PROT=y
> # CONFIG_LOCK_EVENT_COUNTS is not set
> CONFIG_ARCH_HAS_MEM_ENCRYPT=y
> CONFIG_ARCH_HAS_CC_PLATFORM=y
> CONFIG_HAVE_STATIC_CALL=y
> CONFIG_HAVE_STATIC_CALL_INLINE=y
> CONFIG_HAVE_PREEMPT_DYNAMIC=y
> CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y
> CONFIG_ARCH_WANT_LD_ORPHAN_WARN=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_ARCH_SUPPORTS_PAGE_TABLE_CHECK=y
> CONFIG_ARCH_HAS_ELFCORE_COMPAT=y
> CONFIG_ARCH_HAS_PARANOID_L1D_FLUSH=y
> CONFIG_DYNAMIC_SIGFRAME=y
> CONFIG_HAVE_ARCH_NODE_DEV_GROUP=y
>
> #
> # GCOV-based kernel profiling
> #
> # CONFIG_GCOV_KERNEL is not set
> CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
> # end of GCOV-based kernel profiling
>
> CONFIG_HAVE_GCC_PLUGINS=y
> # end of General architecture-dependent options
>
> CONFIG_RT_MUTEXES=y
> CONFIG_BASE_SMALL=0
> CONFIG_MODULE_SIG_FORMAT=y
> CONFIG_MODULES=y
> # CONFIG_MODULE_FORCE_LOAD is not set
> CONFIG_MODULE_UNLOAD=y
> # CONFIG_MODULE_FORCE_UNLOAD is not set
> # CONFIG_MODULE_UNLOAD_TAINT_TRACKING is not set
> CONFIG_MODVERSIONS=y
> CONFIG_ASM_MODVERSIONS=y
> CONFIG_MODULE_SRCVERSION_ALL=y
> CONFIG_MODULE_SIG=y
> # CONFIG_MODULE_SIG_FORCE is not set
> CONFIG_MODULE_SIG_ALL=y
> # CONFIG_MODULE_SIG_SHA1 is not set
> # CONFIG_MODULE_SIG_SHA224 is not set
> # CONFIG_MODULE_SIG_SHA256 is not set
> # CONFIG_MODULE_SIG_SHA384 is not set
> CONFIG_MODULE_SIG_SHA512=y
> CONFIG_MODULE_SIG_HASH="sha512"
> CONFIG_MODULE_COMPRESS_NONE=y
> # CONFIG_MODULE_COMPRESS_GZIP is not set
> # CONFIG_MODULE_COMPRESS_XZ is not set
> # CONFIG_MODULE_COMPRESS_ZSTD is not set
> # CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is not set
> CONFIG_MODPROBE_PATH="/sbin/modprobe"
> # CONFIG_TRIM_UNUSED_KSYMS is not set
> CONFIG_MODULES_TREE_LOOKUP=y
> CONFIG_BLOCK=y
> CONFIG_BLOCK_LEGACY_AUTOLOAD=y
> CONFIG_BLK_RQ_ALLOC_TIME=y
> CONFIG_BLK_CGROUP_RWSTAT=y
> CONFIG_BLK_DEV_BSG_COMMON=y
> CONFIG_BLK_ICQ=y
> CONFIG_BLK_DEV_BSGLIB=y
> CONFIG_BLK_DEV_INTEGRITY=y
> CONFIG_BLK_DEV_INTEGRITY_T10=y
> CONFIG_BLK_DEV_ZONED=y
> CONFIG_BLK_DEV_THROTTLING=y
> # CONFIG_BLK_DEV_THROTTLING_LOW is not set
> CONFIG_BLK_WBT=y
> CONFIG_BLK_WBT_MQ=y
> # CONFIG_BLK_CGROUP_IOLATENCY is not set
> CONFIG_BLK_CGROUP_FC_APPID=y
> CONFIG_BLK_CGROUP_IOCOST=y
> CONFIG_BLK_CGROUP_IOPRIO=y
> CONFIG_BLK_DEBUG_FS=y
> CONFIG_BLK_DEBUG_FS_ZONED=y
> CONFIG_BLK_SED_OPAL=y
> CONFIG_BLK_INLINE_ENCRYPTION=y
> CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
>
> #
> # Partition Types
> #
> CONFIG_PARTITION_ADVANCED=y
> # CONFIG_ACORN_PARTITION is not set
> CONFIG_AIX_PARTITION=y
> CONFIG_OSF_PARTITION=y
> CONFIG_AMIGA_PARTITION=y
> CONFIG_ATARI_PARTITION=y
> CONFIG_MAC_PARTITION=y
> CONFIG_MSDOS_PARTITION=y
> CONFIG_BSD_DISKLABEL=y
> CONFIG_MINIX_SUBPARTITION=y
> CONFIG_SOLARIS_X86_PARTITION=y
> CONFIG_UNIXWARE_DISKLABEL=y
> CONFIG_LDM_PARTITION=y
> # CONFIG_LDM_DEBUG is not set
> CONFIG_SGI_PARTITION=y
> CONFIG_ULTRIX_PARTITION=y
> CONFIG_SUN_PARTITION=y
> CONFIG_KARMA_PARTITION=y
> CONFIG_EFI_PARTITION=y
> CONFIG_SYSV68_PARTITION=y
> CONFIG_CMDLINE_PARTITION=y
> # end of Partition Types
>
> CONFIG_BLOCK_COMPAT=y
> CONFIG_BLK_MQ_PCI=y
> CONFIG_BLK_MQ_VIRTIO=y
> CONFIG_BLK_MQ_RDMA=y
> CONFIG_BLK_PM=y
> CONFIG_BLOCK_HOLDER_DEPRECATED=y
> CONFIG_BLK_MQ_STACKING=y
>
> #
> # IO Schedulers
> #
> CONFIG_MQ_IOSCHED_DEADLINE=y
> CONFIG_MQ_IOSCHED_KYBER=m
> CONFIG_IOSCHED_BFQ=m
> CONFIG_BFQ_GROUP_IOSCHED=y
> # CONFIG_BFQ_CGROUP_DEBUG is not set
> # end of IO Schedulers
>
> CONFIG_PREEMPT_NOTIFIERS=y
> CONFIG_PADATA=y
> CONFIG_ASN1=y
> CONFIG_UNINLINE_SPIN_UNLOCK=y
> CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
> CONFIG_MUTEX_SPIN_ON_OWNER=y
> CONFIG_RWSEM_SPIN_ON_OWNER=y
> CONFIG_LOCK_SPIN_ON_OWNER=y
> CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
> CONFIG_QUEUED_SPINLOCKS=y
> CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
> CONFIG_QUEUED_RWLOCKS=y
> CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE=y
> CONFIG_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE=y
> CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y
> CONFIG_FREEZER=y
>
> #
> # Executable file formats
> #
> CONFIG_BINFMT_ELF=y
> CONFIG_COMPAT_BINFMT_ELF=y
> CONFIG_ELFCORE=y
> CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
> CONFIG_BINFMT_SCRIPT=y
> CONFIG_BINFMT_MISC=m
> CONFIG_COREDUMP=y
> # end of Executable file formats
>
> #
> # Memory Management options
> #
> CONFIG_ZPOOL=y
> CONFIG_SWAP=y
> CONFIG_ZSWAP=y
> # CONFIG_ZSWAP_DEFAULT_ON is not set
> # CONFIG_ZSWAP_COMPRESSOR_DEFAULT_DEFLATE is not set
> CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZO=y
> # CONFIG_ZSWAP_COMPRESSOR_DEFAULT_842 is not set
> # CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZ4 is not set
> # CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZ4HC is not set
> # CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD is not set
> CONFIG_ZSWAP_COMPRESSOR_DEFAULT="lzo"
> CONFIG_ZSWAP_ZPOOL_DEFAULT_ZBUD=y
> # CONFIG_ZSWAP_ZPOOL_DEFAULT_Z3FOLD is not set
> # CONFIG_ZSWAP_ZPOOL_DEFAULT_ZSMALLOC is not set
> CONFIG_ZSWAP_ZPOOL_DEFAULT="zbud"
> CONFIG_ZBUD=y
> CONFIG_Z3FOLD=m
> CONFIG_ZSMALLOC=y
> # CONFIG_ZSMALLOC_STAT is not set
>
> #
> # SLAB allocator options
> #
> # CONFIG_SLAB is not set
> CONFIG_SLUB=y
> # CONFIG_SLOB is not set
> CONFIG_SLAB_MERGE_DEFAULT=y
> CONFIG_SLAB_FREELIST_RANDOM=y
> CONFIG_SLAB_FREELIST_HARDENED=y
> # CONFIG_SLUB_STATS is not set
> CONFIG_SLUB_CPU_PARTIAL=y
> # end of SLAB allocator options
>
> CONFIG_SHUFFLE_PAGE_ALLOCATOR=y
> # CONFIG_COMPAT_BRK is not set
> CONFIG_SPARSEMEM=y
> CONFIG_SPARSEMEM_EXTREME=y
> CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
> CONFIG_SPARSEMEM_VMEMMAP=y
> CONFIG_HAVE_FAST_GUP=y
> CONFIG_NUMA_KEEP_MEMINFO=y
> CONFIG_MEMORY_ISOLATION=y
> CONFIG_EXCLUSIVE_SYSTEM_RAM=y
> CONFIG_HAVE_BOOTMEM_INFO_NODE=y
> CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
> CONFIG_MEMORY_HOTPLUG=y
> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y
> CONFIG_MEMORY_HOTREMOVE=y
> CONFIG_MHP_MEMMAP_ON_MEMORY=y
> CONFIG_SPLIT_PTLOCK_CPUS=4
> CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
> CONFIG_MEMORY_BALLOON=y
> CONFIG_BALLOON_COMPACTION=y
> CONFIG_COMPACTION=y
> CONFIG_PAGE_REPORTING=y
> CONFIG_MIGRATION=y
> CONFIG_DEVICE_MIGRATION=y
> CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
> CONFIG_ARCH_ENABLE_THP_MIGRATION=y
> CONFIG_CONTIG_ALLOC=y
> CONFIG_PHYS_ADDR_T_64BIT=y
> CONFIG_MMU_NOTIFIER=y
> CONFIG_KSM=y
> CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
> CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
> CONFIG_MEMORY_FAILURE=y
> CONFIG_HWPOISON_INJECT=m
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ARCH_WANTS_THP_SWAP=y
> CONFIG_TRANSPARENT_HUGEPAGE=y
> # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
> CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
> CONFIG_THP_SWAP=y
> # CONFIG_READ_ONLY_THP_FOR_FS is not set
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_USE_PERCPU_NUMA_NODE_ID=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_FRONTSWAP=y
> # CONFIG_CMA is not set
> CONFIG_MEM_SOFT_DIRTY=y
> CONFIG_GENERIC_EARLY_IOREMAP=y
> # CONFIG_DEFERRED_STRUCT_PAGE_INIT is not set
> CONFIG_PAGE_IDLE_FLAG=y
> CONFIG_IDLE_PAGE_TRACKING=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_ARCH_HAS_CURRENT_STACK_POINTER=y
> CONFIG_ARCH_HAS_PTE_DEVMAP=y
> CONFIG_ARCH_HAS_ZONE_DMA_SET=y
> CONFIG_ZONE_DMA=y
> CONFIG_ZONE_DMA32=y
> CONFIG_ZONE_DEVICE=y
> CONFIG_HMM_MIRROR=y
> CONFIG_GET_FREE_REGION=y
> CONFIG_DEVICE_PRIVATE=y
> CONFIG_VMAP_PFN=y
> CONFIG_ARCH_USES_HIGH_VMA_FLAGS=y
> CONFIG_ARCH_HAS_PKEYS=y
> CONFIG_VM_EVENT_COUNTERS=y
> # CONFIG_PERCPU_STATS is not set
> # CONFIG_GUP_TEST is not set
> CONFIG_ARCH_HAS_PTE_SPECIAL=y
> CONFIG_MAPPING_DIRTY_HELPERS=y
> CONFIG_SECRETMEM=y
> CONFIG_ANON_VMA_NAME=y
> CONFIG_USERFAULTFD=y
> CONFIG_HAVE_ARCH_USERFAULTFD_WP=y
> CONFIG_HAVE_ARCH_USERFAULTFD_MINOR=y
> CONFIG_PTE_MARKER=y
> CONFIG_PTE_MARKER_UFFD_WP=y
>
> #
> # Data Access Monitoring
> #
> # CONFIG_DAMON is not set
> # end of Data Access Monitoring
> # end of Memory Management options
>
> CONFIG_NET=y
> CONFIG_WANT_COMPAT_NETLINK_MESSAGES=y
> CONFIG_COMPAT_NETLINK_MESSAGES=y
> CONFIG_NET_INGRESS=y
> CONFIG_NET_EGRESS=y
> CONFIG_NET_REDIRECT=y
> CONFIG_SKB_EXTENSIONS=y
>
> #
> # Networking options
> #
> CONFIG_PACKET=y
> CONFIG_PACKET_DIAG=m
> CONFIG_UNIX=y
> CONFIG_UNIX_SCM=y
> CONFIG_AF_UNIX_OOB=y
> CONFIG_UNIX_DIAG=m
> CONFIG_TLS=m
> CONFIG_TLS_DEVICE=y
> # CONFIG_TLS_TOE is not set
> CONFIG_XFRM=y
> CONFIG_XFRM_OFFLOAD=y
> CONFIG_XFRM_ALGO=m
> CONFIG_XFRM_USER=m
> CONFIG_XFRM_USER_COMPAT=m
> CONFIG_XFRM_INTERFACE=m
> # CONFIG_XFRM_SUB_POLICY is not set
> # CONFIG_XFRM_MIGRATE is not set
> CONFIG_XFRM_STATISTICS=y
> CONFIG_XFRM_AH=m
> CONFIG_XFRM_ESP=m
> CONFIG_XFRM_IPCOMP=m
> CONFIG_NET_KEY=m
> # CONFIG_NET_KEY_MIGRATE is not set
> CONFIG_XFRM_ESPINTCP=y
> CONFIG_SMC=m
> CONFIG_SMC_DIAG=m
> CONFIG_XDP_SOCKETS=y
> CONFIG_XDP_SOCKETS_DIAG=m
> CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> CONFIG_IP_ADVANCED_ROUTER=y
> CONFIG_IP_FIB_TRIE_STATS=y
> CONFIG_IP_MULTIPLE_TABLES=y
> CONFIG_IP_ROUTE_MULTIPATH=y
> CONFIG_IP_ROUTE_VERBOSE=y
> CONFIG_IP_ROUTE_CLASSID=y
> # CONFIG_IP_PNP is not set
> CONFIG_NET_IPIP=m
> CONFIG_NET_IPGRE_DEMUX=m
> CONFIG_NET_IP_TUNNEL=m
> CONFIG_NET_IPGRE=m
> CONFIG_NET_IPGRE_BROADCAST=y
> CONFIG_IP_MROUTE_COMMON=y
> CONFIG_IP_MROUTE=y
> CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
> CONFIG_IP_PIMSM_V1=y
> CONFIG_IP_PIMSM_V2=y
> CONFIG_SYN_COOKIES=y
> CONFIG_NET_IPVTI=m
> CONFIG_NET_UDP_TUNNEL=m
> CONFIG_NET_FOU=m
> CONFIG_NET_FOU_IP_TUNNELS=y
> CONFIG_INET_AH=m
> CONFIG_INET_ESP=m
> CONFIG_INET_ESP_OFFLOAD=m
> CONFIG_INET_ESPINTCP=y
> CONFIG_INET_IPCOMP=m
> CONFIG_INET_XFRM_TUNNEL=m
> CONFIG_INET_TUNNEL=m
> CONFIG_INET_DIAG=m
> CONFIG_INET_TCP_DIAG=m
> CONFIG_INET_UDP_DIAG=m
> CONFIG_INET_RAW_DIAG=m
> CONFIG_INET_DIAG_DESTROY=y
> CONFIG_TCP_CONG_ADVANCED=y
> CONFIG_TCP_CONG_BIC=m
> CONFIG_TCP_CONG_CUBIC=y
> CONFIG_TCP_CONG_WESTWOOD=m
> CONFIG_TCP_CONG_HTCP=m
> CONFIG_TCP_CONG_HSTCP=m
> CONFIG_TCP_CONG_HYBLA=m
> CONFIG_TCP_CONG_VEGAS=m
> CONFIG_TCP_CONG_NV=m
> CONFIG_TCP_CONG_SCALABLE=m
> CONFIG_TCP_CONG_LP=m
> CONFIG_TCP_CONG_VENO=m
> CONFIG_TCP_CONG_YEAH=m
> CONFIG_TCP_CONG_ILLINOIS=m
> CONFIG_TCP_CONG_DCTCP=m
> CONFIG_TCP_CONG_CDG=m
> CONFIG_TCP_CONG_BBR=m
> CONFIG_DEFAULT_CUBIC=y
> # CONFIG_DEFAULT_RENO is not set
> CONFIG_DEFAULT_TCP_CONG="cubic"
> CONFIG_TCP_MD5SIG=y
> CONFIG_IPV6=y
> CONFIG_IPV6_ROUTER_PREF=y
> CONFIG_IPV6_ROUTE_INFO=y
> # CONFIG_IPV6_OPTIMISTIC_DAD is not set
> CONFIG_INET6_AH=m
> CONFIG_INET6_ESP=m
> CONFIG_INET6_ESP_OFFLOAD=m
> CONFIG_INET6_ESPINTCP=y
> CONFIG_INET6_IPCOMP=m
> CONFIG_IPV6_MIP6=m
> CONFIG_IPV6_ILA=m
> CONFIG_INET6_XFRM_TUNNEL=m
> CONFIG_INET6_TUNNEL=m
> CONFIG_IPV6_VTI=m
> CONFIG_IPV6_SIT=m
> CONFIG_IPV6_SIT_6RD=y
> CONFIG_IPV6_NDISC_NODETYPE=y
> CONFIG_IPV6_TUNNEL=m
> CONFIG_IPV6_GRE=m
> CONFIG_IPV6_FOU=m
> CONFIG_IPV6_FOU_TUNNEL=m
> CONFIG_IPV6_MULTIPLE_TABLES=y
> CONFIG_IPV6_SUBTREES=y
> CONFIG_IPV6_MROUTE=y
> CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
> CONFIG_IPV6_PIMSM_V2=y
> CONFIG_IPV6_SEG6_LWTUNNEL=y
> CONFIG_IPV6_SEG6_HMAC=y
> CONFIG_IPV6_SEG6_BPF=y
> # CONFIG_IPV6_RPL_LWTUNNEL is not set
> CONFIG_IPV6_IOAM6_LWTUNNEL=y
> CONFIG_NETLABEL=y
> CONFIG_MPTCP=y
> CONFIG_INET_MPTCP_DIAG=m
> CONFIG_MPTCP_IPV6=y
> CONFIG_NETWORK_SECMARK=y
> CONFIG_NET_PTP_CLASSIFY=y
> CONFIG_NETWORK_PHY_TIMESTAMPING=y
> CONFIG_NETFILTER=y
> CONFIG_NETFILTER_ADVANCED=y
> CONFIG_BRIDGE_NETFILTER=m
>
> #
> # Core Netfilter Configuration
> #
> CONFIG_NETFILTER_INGRESS=y
> CONFIG_NETFILTER_EGRESS=y
> CONFIG_NETFILTER_SKIP_EGRESS=y
> CONFIG_NETFILTER_NETLINK=m
> CONFIG_NETFILTER_FAMILY_BRIDGE=y
> CONFIG_NETFILTER_FAMILY_ARP=y
> CONFIG_NETFILTER_NETLINK_HOOK=m
> CONFIG_NETFILTER_NETLINK_ACCT=m
> CONFIG_NETFILTER_NETLINK_QUEUE=m
> CONFIG_NETFILTER_NETLINK_LOG=m
> CONFIG_NETFILTER_NETLINK_OSF=m
> CONFIG_NF_CONNTRACK=m
> CONFIG_NF_LOG_SYSLOG=m
> CONFIG_NETFILTER_CONNCOUNT=m
> CONFIG_NF_CONNTRACK_MARK=y
> CONFIG_NF_CONNTRACK_SECMARK=y
> CONFIG_NF_CONNTRACK_ZONES=y
> # CONFIG_NF_CONNTRACK_PROCFS is not set
> CONFIG_NF_CONNTRACK_EVENTS=y
> CONFIG_NF_CONNTRACK_TIMEOUT=y
> CONFIG_NF_CONNTRACK_TIMESTAMP=y
> CONFIG_NF_CONNTRACK_LABELS=y
> CONFIG_NF_CT_PROTO_DCCP=y
> CONFIG_NF_CT_PROTO_GRE=y
> CONFIG_NF_CT_PROTO_SCTP=y
> CONFIG_NF_CT_PROTO_UDPLITE=y
> CONFIG_NF_CONNTRACK_AMANDA=m
> CONFIG_NF_CONNTRACK_FTP=m
> CONFIG_NF_CONNTRACK_H323=m
> CONFIG_NF_CONNTRACK_IRC=m
> CONFIG_NF_CONNTRACK_BROADCAST=m
> CONFIG_NF_CONNTRACK_NETBIOS_NS=m
> CONFIG_NF_CONNTRACK_SNMP=m
> CONFIG_NF_CONNTRACK_PPTP=m
> CONFIG_NF_CONNTRACK_SANE=m
> CONFIG_NF_CONNTRACK_SIP=m
> CONFIG_NF_CONNTRACK_TFTP=m
> CONFIG_NF_CT_NETLINK=m
> CONFIG_NF_CT_NETLINK_TIMEOUT=m
> CONFIG_NF_CT_NETLINK_HELPER=m
> CONFIG_NETFILTER_NETLINK_GLUE_CT=y
> CONFIG_NF_NAT=m
> CONFIG_NF_NAT_AMANDA=m
> CONFIG_NF_NAT_FTP=m
> CONFIG_NF_NAT_IRC=m
> CONFIG_NF_NAT_SIP=m
> CONFIG_NF_NAT_TFTP=m
> CONFIG_NF_NAT_REDIRECT=y
> CONFIG_NF_NAT_MASQUERADE=y
> CONFIG_NETFILTER_SYNPROXY=m
> CONFIG_NF_TABLES=m
> CONFIG_NF_TABLES_INET=y
> CONFIG_NF_TABLES_NETDEV=y
> CONFIG_NFT_NUMGEN=m
> CONFIG_NFT_CT=m
> CONFIG_NFT_FLOW_OFFLOAD=m
> CONFIG_NFT_CONNLIMIT=m
> CONFIG_NFT_LOG=m
> CONFIG_NFT_LIMIT=m
> CONFIG_NFT_MASQ=m
> CONFIG_NFT_REDIR=m
> CONFIG_NFT_NAT=m
> CONFIG_NFT_TUNNEL=m
> CONFIG_NFT_OBJREF=m
> CONFIG_NFT_QUEUE=m
> CONFIG_NFT_QUOTA=m
> CONFIG_NFT_REJECT=m
> CONFIG_NFT_REJECT_INET=m
> CONFIG_NFT_COMPAT=m
> CONFIG_NFT_HASH=m
> CONFIG_NFT_FIB=m
> CONFIG_NFT_FIB_INET=m
> CONFIG_NFT_XFRM=m
> CONFIG_NFT_SOCKET=m
> CONFIG_NFT_OSF=m
> CONFIG_NFT_TPROXY=m
> CONFIG_NFT_SYNPROXY=m
> CONFIG_NF_DUP_NETDEV=m
> CONFIG_NFT_DUP_NETDEV=m
> CONFIG_NFT_FWD_NETDEV=m
> CONFIG_NFT_FIB_NETDEV=m
> CONFIG_NFT_REJECT_NETDEV=m
> CONFIG_NF_FLOW_TABLE_INET=m
> CONFIG_NF_FLOW_TABLE=m
> # CONFIG_NF_FLOW_TABLE_PROCFS is not set
> CONFIG_NETFILTER_XTABLES=m
> CONFIG_NETFILTER_XTABLES_COMPAT=y
>
> #
> # Xtables combined modules
> #
> CONFIG_NETFILTER_XT_MARK=m
> CONFIG_NETFILTER_XT_CONNMARK=m
> CONFIG_NETFILTER_XT_SET=m
>
> #
> # Xtables targets
> #
> CONFIG_NETFILTER_XT_TARGET_AUDIT=m
> CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
> CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
> CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
> CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
> CONFIG_NETFILTER_XT_TARGET_CT=m
> CONFIG_NETFILTER_XT_TARGET_DSCP=m
> CONFIG_NETFILTER_XT_TARGET_HL=m
> CONFIG_NETFILTER_XT_TARGET_HMARK=m
> CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
> CONFIG_NETFILTER_XT_TARGET_LED=m
> CONFIG_NETFILTER_XT_TARGET_LOG=m
> CONFIG_NETFILTER_XT_TARGET_MARK=m
> CONFIG_NETFILTER_XT_NAT=m
> CONFIG_NETFILTER_XT_TARGET_NETMAP=m
> CONFIG_NETFILTER_XT_TARGET_NFLOG=m
> CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
> # CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set
> CONFIG_NETFILTER_XT_TARGET_RATEEST=m
> CONFIG_NETFILTER_XT_TARGET_REDIRECT=m
> CONFIG_NETFILTER_XT_TARGET_MASQUERADE=m
> CONFIG_NETFILTER_XT_TARGET_TEE=m
> CONFIG_NETFILTER_XT_TARGET_TPROXY=m
> CONFIG_NETFILTER_XT_TARGET_TRACE=m
> CONFIG_NETFILTER_XT_TARGET_SECMARK=m
> CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
> CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
>
> #
> # Xtables matches
> #
> CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
> CONFIG_NETFILTER_XT_MATCH_BPF=m
> CONFIG_NETFILTER_XT_MATCH_CGROUP=m
> CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
> CONFIG_NETFILTER_XT_MATCH_COMMENT=m
> CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
> CONFIG_NETFILTER_XT_MATCH_CONNLABEL=m
> CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
> CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
> CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
> CONFIG_NETFILTER_XT_MATCH_CPU=m
> CONFIG_NETFILTER_XT_MATCH_DCCP=m
> CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m
> CONFIG_NETFILTER_XT_MATCH_DSCP=m
> CONFIG_NETFILTER_XT_MATCH_ECN=m
> CONFIG_NETFILTER_XT_MATCH_ESP=m
> CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
> CONFIG_NETFILTER_XT_MATCH_HELPER=m
> CONFIG_NETFILTER_XT_MATCH_HL=m
> CONFIG_NETFILTER_XT_MATCH_IPCOMP=m
> CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
> CONFIG_NETFILTER_XT_MATCH_IPVS=m
> CONFIG_NETFILTER_XT_MATCH_L2TP=m
> CONFIG_NETFILTER_XT_MATCH_LENGTH=m
> CONFIG_NETFILTER_XT_MATCH_LIMIT=m
> CONFIG_NETFILTER_XT_MATCH_MAC=m
> CONFIG_NETFILTER_XT_MATCH_MARK=m
> CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
> CONFIG_NETFILTER_XT_MATCH_NFACCT=m
> CONFIG_NETFILTER_XT_MATCH_OSF=m
> CONFIG_NETFILTER_XT_MATCH_OWNER=m
> CONFIG_NETFILTER_XT_MATCH_POLICY=m
> CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
> CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
> CONFIG_NETFILTER_XT_MATCH_QUOTA=m
> CONFIG_NETFILTER_XT_MATCH_RATEEST=m
> CONFIG_NETFILTER_XT_MATCH_REALM=m
> CONFIG_NETFILTER_XT_MATCH_RECENT=m
> CONFIG_NETFILTER_XT_MATCH_SCTP=m
> CONFIG_NETFILTER_XT_MATCH_SOCKET=m
> CONFIG_NETFILTER_XT_MATCH_STATE=m
> CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
> CONFIG_NETFILTER_XT_MATCH_STRING=m
> CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
> CONFIG_NETFILTER_XT_MATCH_TIME=m
> CONFIG_NETFILTER_XT_MATCH_U32=m
> # end of Core Netfilter Configuration
>
> CONFIG_IP_SET=m
> CONFIG_IP_SET_MAX=256
> CONFIG_IP_SET_BITMAP_IP=m
> CONFIG_IP_SET_BITMAP_IPMAC=m
> CONFIG_IP_SET_BITMAP_PORT=m
> CONFIG_IP_SET_HASH_IP=m
> CONFIG_IP_SET_HASH_IPMARK=m
> CONFIG_IP_SET_HASH_IPPORT=m
> CONFIG_IP_SET_HASH_IPPORTIP=m
> CONFIG_IP_SET_HASH_IPPORTNET=m
> CONFIG_IP_SET_HASH_IPMAC=m
> CONFIG_IP_SET_HASH_MAC=m
> CONFIG_IP_SET_HASH_NETPORTNET=m
> CONFIG_IP_SET_HASH_NET=m
> CONFIG_IP_SET_HASH_NETNET=m
> CONFIG_IP_SET_HASH_NETPORT=m
> CONFIG_IP_SET_HASH_NETIFACE=m
> CONFIG_IP_SET_LIST_SET=m
> CONFIG_IP_VS=m
> CONFIG_IP_VS_IPV6=y
> # CONFIG_IP_VS_DEBUG is not set
> CONFIG_IP_VS_TAB_BITS=12
>
> #
> # IPVS transport protocol load balancing support
> #
> CONFIG_IP_VS_PROTO_TCP=y
> CONFIG_IP_VS_PROTO_UDP=y
> CONFIG_IP_VS_PROTO_AH_ESP=y
> CONFIG_IP_VS_PROTO_ESP=y
> CONFIG_IP_VS_PROTO_AH=y
> CONFIG_IP_VS_PROTO_SCTP=y
>
> #
> # IPVS scheduler
> #
> CONFIG_IP_VS_RR=m
> CONFIG_IP_VS_WRR=m
> CONFIG_IP_VS_LC=m
> CONFIG_IP_VS_WLC=m
> CONFIG_IP_VS_FO=m
> CONFIG_IP_VS_OVF=m
> CONFIG_IP_VS_LBLC=m
> CONFIG_IP_VS_LBLCR=m
> CONFIG_IP_VS_DH=m
> CONFIG_IP_VS_SH=m
> CONFIG_IP_VS_MH=m
> CONFIG_IP_VS_SED=m
> CONFIG_IP_VS_NQ=m
> CONFIG_IP_VS_TWOS=m
>
> #
> # IPVS SH scheduler
> #
> CONFIG_IP_VS_SH_TAB_BITS=8
>
> #
> # IPVS MH scheduler
> #
> CONFIG_IP_VS_MH_TAB_INDEX=12
>
> #
> # IPVS application helper
> #
> CONFIG_IP_VS_FTP=m
> CONFIG_IP_VS_NFCT=y
> CONFIG_IP_VS_PE_SIP=m
>
> #
> # IP: Netfilter Configuration
> #
> CONFIG_NF_DEFRAG_IPV4=m
> CONFIG_NF_SOCKET_IPV4=m
> CONFIG_NF_TPROXY_IPV4=m
> CONFIG_NF_TABLES_IPV4=y
> CONFIG_NFT_REJECT_IPV4=m
> CONFIG_NFT_DUP_IPV4=m
> CONFIG_NFT_FIB_IPV4=m
> CONFIG_NF_TABLES_ARP=y
> CONFIG_NF_DUP_IPV4=m
> CONFIG_NF_LOG_ARP=m
> CONFIG_NF_LOG_IPV4=m
> CONFIG_NF_REJECT_IPV4=m
> CONFIG_NF_NAT_SNMP_BASIC=m
> CONFIG_NF_NAT_PPTP=m
> CONFIG_NF_NAT_H323=m
> CONFIG_IP_NF_IPTABLES=m
> CONFIG_IP_NF_MATCH_AH=m
> CONFIG_IP_NF_MATCH_ECN=m
> CONFIG_IP_NF_MATCH_RPFILTER=m
> CONFIG_IP_NF_MATCH_TTL=m
> CONFIG_IP_NF_FILTER=m
> CONFIG_IP_NF_TARGET_REJECT=m
> CONFIG_IP_NF_TARGET_SYNPROXY=m
> CONFIG_IP_NF_NAT=m
> CONFIG_IP_NF_TARGET_MASQUERADE=m
> CONFIG_IP_NF_TARGET_NETMAP=m
> CONFIG_IP_NF_TARGET_REDIRECT=m
> CONFIG_IP_NF_MANGLE=m
> CONFIG_IP_NF_TARGET_CLUSTERIP=m
> CONFIG_IP_NF_TARGET_ECN=m
> CONFIG_IP_NF_TARGET_TTL=m
> CONFIG_IP_NF_RAW=m
> CONFIG_IP_NF_SECURITY=m
> CONFIG_IP_NF_ARPTABLES=m
> CONFIG_IP_NF_ARPFILTER=m
> CONFIG_IP_NF_ARP_MANGLE=m
> # end of IP: Netfilter Configuration
>
> #
> # IPv6: Netfilter Configuration
> #
> CONFIG_NF_SOCKET_IPV6=m
> CONFIG_NF_TPROXY_IPV6=m
> CONFIG_NF_TABLES_IPV6=y
> CONFIG_NFT_REJECT_IPV6=m
> CONFIG_NFT_DUP_IPV6=m
> CONFIG_NFT_FIB_IPV6=m
> CONFIG_NF_DUP_IPV6=m
> CONFIG_NF_REJECT_IPV6=m
> CONFIG_NF_LOG_IPV6=m
> CONFIG_IP6_NF_IPTABLES=m
> CONFIG_IP6_NF_MATCH_AH=m
> CONFIG_IP6_NF_MATCH_EUI64=m
> CONFIG_IP6_NF_MATCH_FRAG=m
> CONFIG_IP6_NF_MATCH_OPTS=m
> CONFIG_IP6_NF_MATCH_HL=m
> CONFIG_IP6_NF_MATCH_IPV6HEADER=m
> CONFIG_IP6_NF_MATCH_MH=m
> CONFIG_IP6_NF_MATCH_RPFILTER=m
> CONFIG_IP6_NF_MATCH_RT=m
> CONFIG_IP6_NF_MATCH_SRH=m
> CONFIG_IP6_NF_TARGET_HL=m
> CONFIG_IP6_NF_FILTER=m
> CONFIG_IP6_NF_TARGET_REJECT=m
> CONFIG_IP6_NF_TARGET_SYNPROXY=m
> CONFIG_IP6_NF_MANGLE=m
> CONFIG_IP6_NF_RAW=m
> CONFIG_IP6_NF_SECURITY=m
> CONFIG_IP6_NF_NAT=m
> CONFIG_IP6_NF_TARGET_MASQUERADE=m
> CONFIG_IP6_NF_TARGET_NPT=m
> # end of IPv6: Netfilter Configuration
>
> CONFIG_NF_DEFRAG_IPV6=m
>
> #
> # DECnet: Netfilter Configuration
> #
> CONFIG_DECNET_NF_GRABULATOR=m
> # end of DECnet: Netfilter Configuration
>
> CONFIG_NF_TABLES_BRIDGE=m
> CONFIG_NFT_BRIDGE_META=m
> CONFIG_NFT_BRIDGE_REJECT=m
> CONFIG_NF_CONNTRACK_BRIDGE=m
> CONFIG_BRIDGE_NF_EBTABLES=m
> CONFIG_BRIDGE_EBT_BROUTE=m
> CONFIG_BRIDGE_EBT_T_FILTER=m
> CONFIG_BRIDGE_EBT_T_NAT=m
> CONFIG_BRIDGE_EBT_802_3=m
> CONFIG_BRIDGE_EBT_AMONG=m
> CONFIG_BRIDGE_EBT_ARP=m
> CONFIG_BRIDGE_EBT_IP=m
> CONFIG_BRIDGE_EBT_IP6=m
> CONFIG_BRIDGE_EBT_LIMIT=m
> CONFIG_BRIDGE_EBT_MARK=m
> CONFIG_BRIDGE_EBT_PKTTYPE=m
> CONFIG_BRIDGE_EBT_STP=m
> CONFIG_BRIDGE_EBT_VLAN=m
> CONFIG_BRIDGE_EBT_ARPREPLY=m
> CONFIG_BRIDGE_EBT_DNAT=m
> CONFIG_BRIDGE_EBT_MARK_T=m
> CONFIG_BRIDGE_EBT_REDIRECT=m
> CONFIG_BRIDGE_EBT_SNAT=m
> CONFIG_BRIDGE_EBT_LOG=m
> CONFIG_BRIDGE_EBT_NFLOG=m
> CONFIG_BPFILTER=y
> CONFIG_BPFILTER_UMH=m
> CONFIG_IP_DCCP=m
> CONFIG_INET_DCCP_DIAG=m
>
> #
> # DCCP CCIDs Configuration
> #
> # CONFIG_IP_DCCP_CCID2_DEBUG is not set
> # CONFIG_IP_DCCP_CCID3 is not set
> # end of DCCP CCIDs Configuration
>
> #
> # DCCP Kernel Hacking
> #
> # CONFIG_IP_DCCP_DEBUG is not set
> # end of DCCP Kernel Hacking
>
> CONFIG_IP_SCTP=m
> # CONFIG_SCTP_DBG_OBJCNT is not set
> # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
> CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1=y
> # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set
> CONFIG_SCTP_COOKIE_HMAC_MD5=y
> CONFIG_SCTP_COOKIE_HMAC_SHA1=y
> CONFIG_INET_SCTP_DIAG=m
> CONFIG_RDS=m
> CONFIG_RDS_RDMA=m
> CONFIG_RDS_TCP=m
> # CONFIG_RDS_DEBUG is not set
> CONFIG_TIPC=m
> CONFIG_TIPC_MEDIA_IB=y
> CONFIG_TIPC_MEDIA_UDP=y
> CONFIG_TIPC_CRYPTO=y
> CONFIG_TIPC_DIAG=m
> CONFIG_ATM=m
> CONFIG_ATM_CLIP=m
> # CONFIG_ATM_CLIP_NO_ICMP is not set
> CONFIG_ATM_LANE=m
> CONFIG_ATM_MPOA=m
> CONFIG_ATM_BR2684=m
> # CONFIG_ATM_BR2684_IPFILTER is not set
> CONFIG_L2TP=m
> CONFIG_L2TP_DEBUGFS=m
> CONFIG_L2TP_V3=y
> CONFIG_L2TP_IP=m
> CONFIG_L2TP_ETH=m
> CONFIG_STP=m
> CONFIG_GARP=m
> CONFIG_MRP=m
> CONFIG_BRIDGE=m
> CONFIG_BRIDGE_IGMP_SNOOPING=y
> CONFIG_BRIDGE_VLAN_FILTERING=y
> CONFIG_BRIDGE_MRP=y
> CONFIG_BRIDGE_CFM=y
> CONFIG_NET_DSA=m
> CONFIG_NET_DSA_TAG_AR9331=m
> CONFIG_NET_DSA_TAG_BRCM_COMMON=m
> CONFIG_NET_DSA_TAG_BRCM=m
> CONFIG_NET_DSA_TAG_BRCM_LEGACY=m
> CONFIG_NET_DSA_TAG_BRCM_PREPEND=m
> CONFIG_NET_DSA_TAG_HELLCREEK=m
> CONFIG_NET_DSA_TAG_GSWIP=m
> CONFIG_NET_DSA_TAG_DSA_COMMON=m
> CONFIG_NET_DSA_TAG_DSA=m
> CONFIG_NET_DSA_TAG_EDSA=m
> CONFIG_NET_DSA_TAG_MTK=m
> CONFIG_NET_DSA_TAG_KSZ=m
> CONFIG_NET_DSA_TAG_OCELOT=m
> CONFIG_NET_DSA_TAG_OCELOT_8021Q=m
> CONFIG_NET_DSA_TAG_QCA=m
> CONFIG_NET_DSA_TAG_RTL4_A=m
> CONFIG_NET_DSA_TAG_RTL8_4=m
> CONFIG_NET_DSA_TAG_RZN1_A5PSW=m
> CONFIG_NET_DSA_TAG_LAN9303=m
> CONFIG_NET_DSA_TAG_SJA1105=m
> CONFIG_NET_DSA_TAG_TRAILER=m
> CONFIG_NET_DSA_TAG_XRS700X=m
> CONFIG_VLAN_8021Q=m
> CONFIG_VLAN_8021Q_GVRP=y
> CONFIG_VLAN_8021Q_MVRP=y
> CONFIG_DECNET=m
> # CONFIG_DECNET_ROUTER is not set
> CONFIG_LLC=m
> CONFIG_LLC2=m
> CONFIG_ATALK=m
> CONFIG_DEV_APPLETALK=m
> # CONFIG_IPDDP is not set
> CONFIG_X25=m
> CONFIG_LAPB=m
> CONFIG_PHONET=m
> CONFIG_6LOWPAN=m
> # CONFIG_6LOWPAN_DEBUGFS is not set
> CONFIG_6LOWPAN_NHC=m
> CONFIG_6LOWPAN_NHC_DEST=m
> CONFIG_6LOWPAN_NHC_FRAGMENT=m
> CONFIG_6LOWPAN_NHC_HOP=m
> CONFIG_6LOWPAN_NHC_IPV6=m
> CONFIG_6LOWPAN_NHC_MOBILITY=m
> CONFIG_6LOWPAN_NHC_ROUTING=m
> CONFIG_6LOWPAN_NHC_UDP=m
> # CONFIG_6LOWPAN_GHC_EXT_HDR_HOP is not set
> # CONFIG_6LOWPAN_GHC_UDP is not set
> # CONFIG_6LOWPAN_GHC_ICMPV6 is not set
> # CONFIG_6LOWPAN_GHC_EXT_HDR_DEST is not set
> # CONFIG_6LOWPAN_GHC_EXT_HDR_FRAG is not set
> # CONFIG_6LOWPAN_GHC_EXT_HDR_ROUTE is not set
> CONFIG_IEEE802154=m
> # CONFIG_IEEE802154_NL802154_EXPERIMENTAL is not set
> CONFIG_IEEE802154_SOCKET=m
> CONFIG_IEEE802154_6LOWPAN=m
> CONFIG_MAC802154=m
> CONFIG_NET_SCHED=y
>
> #
> # Queueing/Scheduling
> #
> CONFIG_NET_SCH_CBQ=m
> CONFIG_NET_SCH_HTB=m
> CONFIG_NET_SCH_HFSC=m
> CONFIG_NET_SCH_ATM=m
> CONFIG_NET_SCH_PRIO=m
> CONFIG_NET_SCH_MULTIQ=m
> CONFIG_NET_SCH_RED=m
> CONFIG_NET_SCH_SFB=m
> CONFIG_NET_SCH_SFQ=m
> CONFIG_NET_SCH_TEQL=m
> CONFIG_NET_SCH_TBF=m
> CONFIG_NET_SCH_CBS=m
> CONFIG_NET_SCH_ETF=m
> CONFIG_NET_SCH_TAPRIO=m
> CONFIG_NET_SCH_GRED=m
> CONFIG_NET_SCH_DSMARK=m
> CONFIG_NET_SCH_NETEM=m
> CONFIG_NET_SCH_DRR=m
> CONFIG_NET_SCH_MQPRIO=m
> CONFIG_NET_SCH_SKBPRIO=m
> CONFIG_NET_SCH_CHOKE=m
> CONFIG_NET_SCH_QFQ=m
> CONFIG_NET_SCH_CODEL=m
> CONFIG_NET_SCH_FQ_CODEL=m
> CONFIG_NET_SCH_CAKE=m
> CONFIG_NET_SCH_FQ=m
> CONFIG_NET_SCH_HHF=m
> CONFIG_NET_SCH_PIE=m
> CONFIG_NET_SCH_FQ_PIE=m
> CONFIG_NET_SCH_INGRESS=m
> CONFIG_NET_SCH_PLUG=m
> CONFIG_NET_SCH_ETS=m
> # CONFIG_NET_SCH_DEFAULT is not set
>
> #
> # Classification
> #
> CONFIG_NET_CLS=y
> CONFIG_NET_CLS_BASIC=m
> CONFIG_NET_CLS_TCINDEX=m
> CONFIG_NET_CLS_ROUTE4=m
> CONFIG_NET_CLS_FW=m
> CONFIG_NET_CLS_U32=m
> # CONFIG_CLS_U32_PERF is not set
> CONFIG_CLS_U32_MARK=y
> CONFIG_NET_CLS_RSVP=m
> CONFIG_NET_CLS_RSVP6=m
> CONFIG_NET_CLS_FLOW=m
> CONFIG_NET_CLS_CGROUP=m
> CONFIG_NET_CLS_BPF=m
> CONFIG_NET_CLS_FLOWER=m
> CONFIG_NET_CLS_MATCHALL=m
> CONFIG_NET_EMATCH=y
> CONFIG_NET_EMATCH_STACK=32
> CONFIG_NET_EMATCH_CMP=m
> CONFIG_NET_EMATCH_NBYTE=m
> CONFIG_NET_EMATCH_U32=m
> CONFIG_NET_EMATCH_META=m
> CONFIG_NET_EMATCH_TEXT=m
> CONFIG_NET_EMATCH_CANID=m
> CONFIG_NET_EMATCH_IPSET=m
> CONFIG_NET_EMATCH_IPT=m
> CONFIG_NET_CLS_ACT=y
> CONFIG_NET_ACT_POLICE=m
> CONFIG_NET_ACT_GACT=m
> CONFIG_GACT_PROB=y
> CONFIG_NET_ACT_MIRRED=m
> CONFIG_NET_ACT_SAMPLE=m
> CONFIG_NET_ACT_IPT=m
> CONFIG_NET_ACT_NAT=m
> CONFIG_NET_ACT_PEDIT=m
> CONFIG_NET_ACT_SIMP=m
> CONFIG_NET_ACT_SKBEDIT=m
> CONFIG_NET_ACT_CSUM=m
> CONFIG_NET_ACT_MPLS=m
> CONFIG_NET_ACT_VLAN=m
> CONFIG_NET_ACT_BPF=m
> CONFIG_NET_ACT_CONNMARK=m
> CONFIG_NET_ACT_CTINFO=m
> CONFIG_NET_ACT_SKBMOD=m
> # CONFIG_NET_ACT_IFE is not set
> CONFIG_NET_ACT_TUNNEL_KEY=m
> CONFIG_NET_ACT_CT=m
> CONFIG_NET_ACT_GATE=m
> CONFIG_NET_TC_SKB_EXT=y
> CONFIG_NET_SCH_FIFO=y
> CONFIG_DCB=y
> CONFIG_DNS_RESOLVER=y
> CONFIG_BATMAN_ADV=m
> # CONFIG_BATMAN_ADV_BATMAN_V is not set
> CONFIG_BATMAN_ADV_BLA=y
> CONFIG_BATMAN_ADV_DAT=y
> CONFIG_BATMAN_ADV_NC=y
> CONFIG_BATMAN_ADV_MCAST=y
> # CONFIG_BATMAN_ADV_DEBUG is not set
> # CONFIG_BATMAN_ADV_TRACING is not set
> CONFIG_OPENVSWITCH=m
> CONFIG_OPENVSWITCH_GRE=m
> CONFIG_OPENVSWITCH_VXLAN=m
> CONFIG_OPENVSWITCH_GENEVE=m
> CONFIG_VSOCKETS=m
> CONFIG_VSOCKETS_DIAG=m
> CONFIG_VSOCKETS_LOOPBACK=m
> CONFIG_VMWARE_VMCI_VSOCKETS=m
> CONFIG_VIRTIO_VSOCKETS=m
> CONFIG_VIRTIO_VSOCKETS_COMMON=m
> CONFIG_HYPERV_VSOCKETS=m
> CONFIG_NETLINK_DIAG=m
> CONFIG_MPLS=y
> CONFIG_NET_MPLS_GSO=m
> CONFIG_MPLS_ROUTING=m
> CONFIG_MPLS_IPTUNNEL=m
> CONFIG_NET_NSH=m
> CONFIG_HSR=m
> CONFIG_NET_SWITCHDEV=y
> CONFIG_NET_L3_MASTER_DEV=y
> CONFIG_QRTR=m
> CONFIG_QRTR_SMD=m
> CONFIG_QRTR_TUN=m
> CONFIG_QRTR_MHI=m
> CONFIG_NET_NCSI=y
> CONFIG_NCSI_OEM_CMD_GET_MAC=y
> # CONFIG_NCSI_OEM_CMD_KEEP_PHY is not set
> CONFIG_PCPU_DEV_REFCNT=y
> CONFIG_RPS=y
> CONFIG_RFS_ACCEL=y
> CONFIG_SOCK_RX_QUEUE_MAPPING=y
> CONFIG_XPS=y
> CONFIG_CGROUP_NET_PRIO=y
> CONFIG_CGROUP_NET_CLASSID=y
> CONFIG_NET_RX_BUSY_POLL=y
> CONFIG_BQL=y
> CONFIG_BPF_STREAM_PARSER=y
> CONFIG_NET_FLOW_LIMIT=y
>
> #
> # Network testing
> #
> CONFIG_NET_PKTGEN=m
> CONFIG_NET_DROP_MONITOR=y
> # end of Network testing
> # end of Networking options
>
> CONFIG_HAMRADIO=y
>
> #
> # Packet Radio protocols
> #
> CONFIG_AX25=m
> CONFIG_AX25_DAMA_SLAVE=y
> CONFIG_NETROM=m
> CONFIG_ROSE=m
>
> #
> # AX.25 network device drivers
> #
> CONFIG_MKISS=m
> CONFIG_6PACK=m
> CONFIG_BPQETHER=m
> CONFIG_BAYCOM_SER_FDX=m
> CONFIG_BAYCOM_SER_HDX=m
> CONFIG_BAYCOM_PAR=m
> CONFIG_YAM=m
> # end of AX.25 network device drivers
>
> CONFIG_CAN=m
> CONFIG_CAN_RAW=m
> CONFIG_CAN_BCM=m
> CONFIG_CAN_GW=m
> CONFIG_CAN_J1939=m
> CONFIG_CAN_ISOTP=m
> CONFIG_BT=m
> CONFIG_BT_BREDR=y
> CONFIG_BT_RFCOMM=m
> CONFIG_BT_RFCOMM_TTY=y
> CONFIG_BT_BNEP=m
> CONFIG_BT_BNEP_MC_FILTER=y
> CONFIG_BT_BNEP_PROTO_FILTER=y
> CONFIG_BT_CMTP=m
> CONFIG_BT_HIDP=m
> CONFIG_BT_HS=y
> CONFIG_BT_LE=y
> CONFIG_BT_6LOWPAN=m
> CONFIG_BT_LEDS=y
> CONFIG_BT_MSFTEXT=y
> CONFIG_BT_AOSPEXT=y
> CONFIG_BT_DEBUGFS=y
> # CONFIG_BT_SELFTEST is not set
>
> #
> # Bluetooth device drivers
> #
> CONFIG_BT_INTEL=m
> CONFIG_BT_BCM=m
> CONFIG_BT_RTL=m
> CONFIG_BT_QCA=m
> CONFIG_BT_MTK=m
> CONFIG_BT_HCIBTUSB=m
> CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y
> CONFIG_BT_HCIBTUSB_BCM=y
> CONFIG_BT_HCIBTUSB_MTK=y
> CONFIG_BT_HCIBTUSB_RTL=y
> CONFIG_BT_HCIBTSDIO=m
> CONFIG_BT_HCIUART=m
> CONFIG_BT_HCIUART_SERDEV=y
> CONFIG_BT_HCIUART_H4=y
> CONFIG_BT_HCIUART_NOKIA=m
> CONFIG_BT_HCIUART_BCSP=y
> CONFIG_BT_HCIUART_ATH3K=y
> CONFIG_BT_HCIUART_LL=y
> CONFIG_BT_HCIUART_3WIRE=y
> CONFIG_BT_HCIUART_INTEL=y
> CONFIG_BT_HCIUART_BCM=y
> CONFIG_BT_HCIUART_RTL=y
> CONFIG_BT_HCIUART_QCA=y
> CONFIG_BT_HCIUART_AG6XX=y
> CONFIG_BT_HCIUART_MRVL=y
> CONFIG_BT_HCIBCM203X=m
> CONFIG_BT_HCIBPA10X=m
> CONFIG_BT_HCIBFUSB=m
> CONFIG_BT_HCIDTL1=m
> CONFIG_BT_HCIBT3C=m
> CONFIG_BT_HCIBLUECARD=m
> CONFIG_BT_HCIVHCI=m
> CONFIG_BT_MRVL=m
> CONFIG_BT_MRVL_SDIO=m
> CONFIG_BT_ATH3K=m
> CONFIG_BT_MTKSDIO=m
> CONFIG_BT_MTKUART=m
> CONFIG_BT_HCIRSI=m
> CONFIG_BT_VIRTIO=m
> # end of Bluetooth device drivers
>
> CONFIG_AF_RXRPC=m
> CONFIG_AF_RXRPC_IPV6=y
> # CONFIG_AF_RXRPC_INJECT_LOSS is not set
> # CONFIG_AF_RXRPC_DEBUG is not set
> CONFIG_RXKAD=y
> CONFIG_AF_KCM=m
> CONFIG_STREAM_PARSER=y
> CONFIG_MCTP=y
> CONFIG_FIB_RULES=y
> CONFIG_WIRELESS=y
> CONFIG_WIRELESS_EXT=y
> CONFIG_WEXT_CORE=y
> CONFIG_WEXT_PROC=y
> CONFIG_WEXT_SPY=y
> CONFIG_WEXT_PRIV=y
> CONFIG_CFG80211=m
> # CONFIG_NL80211_TESTMODE is not set
> # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
> # CONFIG_CFG80211_CERTIFICATION_ONUS is not set
> CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y
> CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS=y
> CONFIG_CFG80211_DEFAULT_PS=y
> CONFIG_CFG80211_DEBUGFS=y
> CONFIG_CFG80211_CRDA_SUPPORT=y
> CONFIG_CFG80211_WEXT=y
> CONFIG_CFG80211_WEXT_EXPORT=y
> CONFIG_LIB80211=m
> CONFIG_LIB80211_CRYPT_WEP=m
> CONFIG_LIB80211_CRYPT_CCMP=m
> CONFIG_LIB80211_CRYPT_TKIP=m
> # CONFIG_LIB80211_DEBUG is not set
> CONFIG_MAC80211=m
> CONFIG_MAC80211_HAS_RC=y
> CONFIG_MAC80211_RC_MINSTREL=y
> CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
> CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
> CONFIG_MAC80211_MESH=y
> CONFIG_MAC80211_LEDS=y
> CONFIG_MAC80211_DEBUGFS=y
> CONFIG_MAC80211_MESSAGE_TRACING=y
> # CONFIG_MAC80211_DEBUG_MENU is not set
> CONFIG_MAC80211_STA_HASH_MAX_SIZE=0
> CONFIG_RFKILL=y
> CONFIG_RFKILL_LEDS=y
> CONFIG_RFKILL_INPUT=y
> CONFIG_RFKILL_GPIO=m
> CONFIG_NET_9P=m
> CONFIG_NET_9P_FD=m
> CONFIG_NET_9P_VIRTIO=m
> CONFIG_NET_9P_XEN=m
> CONFIG_NET_9P_RDMA=m
> # CONFIG_NET_9P_DEBUG is not set
> CONFIG_CAIF=m
> # CONFIG_CAIF_DEBUG is not set
> CONFIG_CAIF_NETDEV=m
> CONFIG_CAIF_USB=m
> CONFIG_CEPH_LIB=m
> # CONFIG_CEPH_LIB_PRETTYDEBUG is not set
> CONFIG_CEPH_LIB_USE_DNS_RESOLVER=y
> CONFIG_NFC=m
> CONFIG_NFC_DIGITAL=m
> CONFIG_NFC_NCI=m
> CONFIG_NFC_NCI_SPI=m
> CONFIG_NFC_NCI_UART=m
> CONFIG_NFC_HCI=m
> CONFIG_NFC_SHDLC=y
>
> #
> # Near Field Communication (NFC) devices
> #
> CONFIG_NFC_TRF7970A=m
> CONFIG_NFC_MEI_PHY=m
> CONFIG_NFC_SIM=m
> CONFIG_NFC_PORT100=m
> CONFIG_NFC_VIRTUAL_NCI=m
> CONFIG_NFC_FDP=m
> CONFIG_NFC_FDP_I2C=m
> CONFIG_NFC_PN544=m
> CONFIG_NFC_PN544_I2C=m
> CONFIG_NFC_PN544_MEI=m
> CONFIG_NFC_PN533=m
> CONFIG_NFC_PN533_USB=m
> CONFIG_NFC_PN533_I2C=m
> CONFIG_NFC_PN532_UART=m
> CONFIG_NFC_MICROREAD=m
> CONFIG_NFC_MICROREAD_I2C=m
> CONFIG_NFC_MICROREAD_MEI=m
> CONFIG_NFC_MRVL=m
> CONFIG_NFC_MRVL_USB=m
> CONFIG_NFC_MRVL_UART=m
> CONFIG_NFC_MRVL_I2C=m
> CONFIG_NFC_MRVL_SPI=m
> CONFIG_NFC_ST21NFCA=m
> CONFIG_NFC_ST21NFCA_I2C=m
> CONFIG_NFC_ST_NCI=m
> CONFIG_NFC_ST_NCI_I2C=m
> CONFIG_NFC_ST_NCI_SPI=m
> CONFIG_NFC_NXP_NCI=m
> CONFIG_NFC_NXP_NCI_I2C=m
> CONFIG_NFC_S3FWRN5=m
> CONFIG_NFC_S3FWRN5_I2C=m
> CONFIG_NFC_S3FWRN82_UART=m
> CONFIG_NFC_ST95HF=m
> # end of Near Field Communication (NFC) devices
>
> CONFIG_PSAMPLE=m
> CONFIG_NET_IFE=m
> CONFIG_LWTUNNEL=y
> CONFIG_LWTUNNEL_BPF=y
> CONFIG_DST_CACHE=y
> CONFIG_GRO_CELLS=y
> CONFIG_SOCK_VALIDATE_XMIT=y
> CONFIG_NET_SELFTESTS=y
> CONFIG_NET_SOCK_MSG=y
> CONFIG_NET_DEVLINK=y
> CONFIG_PAGE_POOL=y
> # CONFIG_PAGE_POOL_STATS is not set
> CONFIG_FAILOVER=m
> CONFIG_ETHTOOL_NETLINK=y
>
> #
> # Device Drivers
> #
> CONFIG_HAVE_EISA=y
> CONFIG_EISA=y
> CONFIG_EISA_VLB_PRIMING=y
> CONFIG_EISA_PCI_EISA=y
> CONFIG_EISA_VIRTUAL_ROOT=y
> CONFIG_EISA_NAMES=y
> CONFIG_HAVE_PCI=y
> CONFIG_PCI=y
> CONFIG_PCI_DOMAINS=y
> CONFIG_PCIEPORTBUS=y
> CONFIG_HOTPLUG_PCI_PCIE=y
> CONFIG_PCIEAER=y
> # CONFIG_PCIEAER_INJECT is not set
> # CONFIG_PCIE_ECRC is not set
> CONFIG_PCIEASPM=y
> CONFIG_PCIEASPM_DEFAULT=y
> # CONFIG_PCIEASPM_POWERSAVE is not set
> # CONFIG_PCIEASPM_POWER_SUPERSAVE is not set
> # CONFIG_PCIEASPM_PERFORMANCE is not set
> CONFIG_PCIE_PME=y
> CONFIG_PCIE_DPC=y
> CONFIG_PCIE_PTM=y
> CONFIG_PCIE_EDR=y
> CONFIG_PCI_MSI=y
> CONFIG_PCI_MSI_IRQ_DOMAIN=y
> CONFIG_PCI_QUIRKS=y
> # CONFIG_PCI_DEBUG is not set
> CONFIG_PCI_REALLOC_ENABLE_AUTO=y
> CONFIG_PCI_STUB=m
> CONFIG_PCI_PF_STUB=m
> CONFIG_XEN_PCIDEV_FRONTEND=m
> CONFIG_PCI_ATS=y
> CONFIG_PCI_DOE=y
> CONFIG_PCI_LOCKLESS_CONFIG=y
> CONFIG_PCI_IOV=y
> CONFIG_PCI_PRI=y
> CONFIG_PCI_PASID=y
> # CONFIG_PCI_P2PDMA is not set
> CONFIG_PCI_LABEL=y
> CONFIG_PCI_HYPERV=m
> # CONFIG_PCIE_BUS_TUNE_OFF is not set
> CONFIG_PCIE_BUS_DEFAULT=y
> # CONFIG_PCIE_BUS_SAFE is not set
> # CONFIG_PCIE_BUS_PERFORMANCE is not set
> # CONFIG_PCIE_BUS_PEER2PEER is not set
> CONFIG_VGA_ARB=y
> CONFIG_VGA_ARB_MAX_GPUS=16
> CONFIG_HOTPLUG_PCI=y
> CONFIG_HOTPLUG_PCI_ACPI=y
> CONFIG_HOTPLUG_PCI_ACPI_IBM=m
> CONFIG_HOTPLUG_PCI_CPCI=y
> CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
> CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
> CONFIG_HOTPLUG_PCI_SHPC=y
>
> #
> # PCI controller drivers
> #
> CONFIG_VMD=m
> CONFIG_PCI_HYPERV_INTERFACE=m
>
> #
> # DesignWare PCI Core Support
> #
> CONFIG_PCIE_DW=y
> CONFIG_PCIE_DW_HOST=y
> CONFIG_PCIE_DW_EP=y
> CONFIG_PCIE_DW_PLAT=y
> CONFIG_PCIE_DW_PLAT_HOST=y
> CONFIG_PCIE_DW_PLAT_EP=y
> # CONFIG_PCI_MESON is not set
> # end of DesignWare PCI Core Support
>
> #
> # Mobiveil PCIe Core Support
> #
> # end of Mobiveil PCIe Core Support
>
> #
> # Cadence PCIe controllers support
> #
> # end of Cadence PCIe controllers support
> # end of PCI controller drivers
>
> #
> # PCI Endpoint
> #
> CONFIG_PCI_ENDPOINT=y
> CONFIG_PCI_ENDPOINT_CONFIGFS=y
> # CONFIG_PCI_EPF_TEST is not set
> CONFIG_PCI_EPF_NTB=m
> CONFIG_PCI_EPF_VNTB=m
> # end of PCI Endpoint
>
> #
> # PCI switch controller drivers
> #
> CONFIG_PCI_SW_SWITCHTEC=m
> # end of PCI switch controller drivers
>
> CONFIG_CXL_BUS=m
> CONFIG_CXL_PCI=m
> # CONFIG_CXL_MEM_RAW_COMMANDS is not set
> CONFIG_CXL_ACPI=m
> CONFIG_CXL_PMEM=m
> CONFIG_CXL_MEM=m
> CONFIG_CXL_PORT=m
> CONFIG_CXL_SUSPEND=y
> CONFIG_CXL_REGION=y
> CONFIG_PCCARD=m
> CONFIG_PCMCIA=m
> CONFIG_PCMCIA_LOAD_CIS=y
> CONFIG_CARDBUS=y
>
> #
> # PC-card bridges
> #
> CONFIG_YENTA=m
> CONFIG_YENTA_O2=y
> CONFIG_YENTA_RICOH=y
> CONFIG_YENTA_TI=y
> CONFIG_YENTA_ENE_TUNE=y
> CONFIG_YENTA_TOSHIBA=y
> CONFIG_PD6729=m
> CONFIG_I82092=m
> CONFIG_PCCARD_NONSTATIC=y
> CONFIG_RAPIDIO=y
> CONFIG_RAPIDIO_TSI721=m
> CONFIG_RAPIDIO_DISC_TIMEOUT=30
> # CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS is not set
> CONFIG_RAPIDIO_DMA_ENGINE=y
> # CONFIG_RAPIDIO_DEBUG is not set
> CONFIG_RAPIDIO_ENUM_BASIC=m
> CONFIG_RAPIDIO_CHMAN=m
> CONFIG_RAPIDIO_MPORT_CDEV=m
>
> #
> # RapidIO Switch drivers
> #
> CONFIG_RAPIDIO_CPS_XX=m
> CONFIG_RAPIDIO_CPS_GEN2=m
> CONFIG_RAPIDIO_RXS_GEN3=m
> # end of RapidIO Switch drivers
>
> #
> # Generic Driver Options
> #
> CONFIG_AUXILIARY_BUS=y
> CONFIG_UEVENT_HELPER=y
> CONFIG_UEVENT_HELPER_PATH=""
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_DEVTMPFS_SAFE=y
> # CONFIG_STANDALONE is not set
> CONFIG_PREVENT_FIRMWARE_BUILD=y
>
> #
> # Firmware loader
> #
> CONFIG_FW_LOADER=y
> CONFIG_FW_LOADER_PAGED_BUF=y
> CONFIG_FW_LOADER_SYSFS=y
> CONFIG_EXTRA_FIRMWARE=""
> CONFIG_FW_LOADER_USER_HELPER=y
> # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
> CONFIG_FW_LOADER_COMPRESS=y
> CONFIG_FW_LOADER_COMPRESS_XZ=y
> CONFIG_FW_LOADER_COMPRESS_ZSTD=y
> CONFIG_FW_CACHE=y
> # CONFIG_FW_UPLOAD is not set
> # end of Firmware loader
>
> CONFIG_WANT_DEV_COREDUMP=y
> CONFIG_ALLOW_DEV_COREDUMP=y
> CONFIG_DEV_COREDUMP=y
> # CONFIG_DEBUG_DRIVER is not set
> # CONFIG_DEBUG_DEVRES is not set
> # CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set
> CONFIG_HMEM_REPORTING=y
> # CONFIG_TEST_ASYNC_DRIVER_PROBE is not set
> CONFIG_SYS_HYPERVISOR=y
> CONFIG_GENERIC_CPU_AUTOPROBE=y
> CONFIG_GENERIC_CPU_VULNERABILITIES=y
> CONFIG_REGMAP=y
> CONFIG_REGMAP_I2C=y
> CONFIG_REGMAP_SLIMBUS=m
> CONFIG_REGMAP_SPI=y
> CONFIG_REGMAP_SPMI=m
> CONFIG_REGMAP_W1=m
> CONFIG_REGMAP_MMIO=y
> CONFIG_REGMAP_IRQ=y
> CONFIG_REGMAP_SOUNDWIRE=m
> CONFIG_REGMAP_SOUNDWIRE_MBQ=m
> CONFIG_REGMAP_SCCB=m
> CONFIG_REGMAP_I3C=m
> CONFIG_REGMAP_SPI_AVMM=m
> CONFIG_DMA_SHARED_BUFFER=y
> # CONFIG_DMA_FENCE_TRACE is not set
> # end of Generic Driver Options
>
> #
> # Bus devices
> #
> CONFIG_MHI_BUS=m
> # CONFIG_MHI_BUS_DEBUG is not set
> CONFIG_MHI_BUS_PCI_GENERIC=m
> CONFIG_MHI_BUS_EP=m
> # end of Bus devices
>
> CONFIG_CONNECTOR=y
> CONFIG_PROC_EVENTS=y
>
> #
> # Firmware Drivers
> #
>
> #
> # ARM System Control and Management Interface Protocol
> #
> # end of ARM System Control and Management Interface Protocol
>
> CONFIG_EDD=y
> CONFIG_EDD_OFF=y
> CONFIG_FIRMWARE_MEMMAP=y
> CONFIG_DMIID=y
> CONFIG_DMI_SYSFS=m
> CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
> CONFIG_ISCSI_IBFT_FIND=y
> CONFIG_ISCSI_IBFT=m
> CONFIG_FW_CFG_SYSFS=m
> # CONFIG_FW_CFG_SYSFS_CMDLINE is not set
> CONFIG_SYSFB=y
> # CONFIG_SYSFB_SIMPLEFB is not set
> CONFIG_CS_DSP=m
> # CONFIG_GOOGLE_FIRMWARE is not set
>
> #
> # EFI (Extensible Firmware Interface) Support
> #
> CONFIG_EFI_ESRT=y
> CONFIG_EFI_VARS_PSTORE=m
> # CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set
> CONFIG_EFI_RUNTIME_MAP=y
> # CONFIG_EFI_FAKE_MEMMAP is not set
> CONFIG_EFI_SOFT_RESERVE=y
> CONFIG_EFI_DXE_MEM_ATTRIBUTES=y
> CONFIG_EFI_RUNTIME_WRAPPERS=y
> CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y
> CONFIG_EFI_BOOTLOADER_CONTROL=m
> CONFIG_EFI_CAPSULE_LOADER=m
> CONFIG_EFI_TEST=m
> CONFIG_EFI_DEV_PATH_PARSER=y
> CONFIG_APPLE_PROPERTIES=y
> CONFIG_RESET_ATTACK_MITIGATION=y
> CONFIG_EFI_RCI2_TABLE=y
> # CONFIG_EFI_DISABLE_PCI_DMA is not set
> CONFIG_EFI_EARLYCON=y
> CONFIG_EFI_CUSTOM_SSDT_OVERLAYS=y
> # CONFIG_EFI_DISABLE_RUNTIME is not set
> CONFIG_EFI_COCO_SECRET=y
> CONFIG_EFI_EMBEDDED_FIRMWARE=y
> # end of EFI (Extensible Firmware Interface) Support
>
> CONFIG_UEFI_CPER=y
> CONFIG_UEFI_CPER_X86=y
>
> #
> # Tegra firmware driver
> #
> # end of Tegra firmware driver
> # end of Firmware Drivers
>
> CONFIG_GNSS=m
> CONFIG_GNSS_SERIAL=m
> CONFIG_GNSS_MTK_SERIAL=m
> CONFIG_GNSS_SIRF_SERIAL=m
> CONFIG_GNSS_UBX_SERIAL=m
> CONFIG_GNSS_USB=m
> CONFIG_MTD=m
> # CONFIG_MTD_TESTS is not set
>
> #
> # Partition parsers
> #
> CONFIG_MTD_AR7_PARTS=m
> CONFIG_MTD_CMDLINE_PARTS=m
> CONFIG_MTD_REDBOOT_PARTS=m
> CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
> # CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
> # CONFIG_MTD_REDBOOT_PARTS_READONLY is not set
> # end of Partition parsers
>
> #
> # User Modules And Translation Layers
> #
> CONFIG_MTD_BLKDEVS=m
> CONFIG_MTD_BLOCK=m
> CONFIG_MTD_BLOCK_RO=m
>
> #
> # Note that in some cases UBI block is preferred. See MTD_UBI_BLOCK.
> #
> CONFIG_FTL=m
> CONFIG_NFTL=m
> CONFIG_NFTL_RW=y
> CONFIG_INFTL=m
> CONFIG_RFD_FTL=m
> CONFIG_SSFDC=m
> CONFIG_SM_FTL=m
> CONFIG_MTD_OOPS=m
> CONFIG_MTD_PSTORE=m
> CONFIG_MTD_SWAP=m
> # CONFIG_MTD_PARTITIONED_MASTER is not set
>
> #
> # RAM/ROM/Flash chip drivers
> #
> CONFIG_MTD_CFI=m
> CONFIG_MTD_JEDECPROBE=m
> CONFIG_MTD_GEN_PROBE=m
> # CONFIG_MTD_CFI_ADV_OPTIONS is not set
> CONFIG_MTD_MAP_BANK_WIDTH_1=y
> CONFIG_MTD_MAP_BANK_WIDTH_2=y
> CONFIG_MTD_MAP_BANK_WIDTH_4=y
> CONFIG_MTD_CFI_I1=y
> CONFIG_MTD_CFI_I2=y
> CONFIG_MTD_CFI_INTELEXT=m
> CONFIG_MTD_CFI_AMDSTD=m
> CONFIG_MTD_CFI_STAA=m
> CONFIG_MTD_CFI_UTIL=m
> CONFIG_MTD_RAM=m
> CONFIG_MTD_ROM=m
> CONFIG_MTD_ABSENT=m
> # end of RAM/ROM/Flash chip drivers
>
> #
> # Mapping drivers for chip access
> #
> CONFIG_MTD_COMPLEX_MAPPINGS=y
> CONFIG_MTD_PHYSMAP=m
> # CONFIG_MTD_PHYSMAP_COMPAT is not set
> CONFIG_MTD_PHYSMAP_GPIO_ADDR=y
> CONFIG_MTD_SBC_GXX=m
> CONFIG_MTD_AMD76XROM=m
> CONFIG_MTD_ICHXROM=m
> CONFIG_MTD_ESB2ROM=m
> CONFIG_MTD_CK804XROM=m
> CONFIG_MTD_SCB2_FLASH=m
> CONFIG_MTD_NETtel=m
> CONFIG_MTD_L440GX=m
> CONFIG_MTD_PCI=m
> CONFIG_MTD_PCMCIA=m
> # CONFIG_MTD_PCMCIA_ANONYMOUS is not set
> CONFIG_MTD_INTEL_VR_NOR=m
> CONFIG_MTD_PLATRAM=m
> # end of Mapping drivers for chip access
>
> #
> # Self-contained MTD device drivers
> #
> CONFIG_MTD_PMC551=m
> # CONFIG_MTD_PMC551_BUGFIX is not set
> # CONFIG_MTD_PMC551_DEBUG is not set
> CONFIG_MTD_DATAFLASH=m
> # CONFIG_MTD_DATAFLASH_WRITE_VERIFY is not set
> CONFIG_MTD_DATAFLASH_OTP=y
> CONFIG_MTD_MCHP23K256=m
> CONFIG_MTD_MCHP48L640=m
> CONFIG_MTD_SST25L=m
> CONFIG_MTD_SLRAM=m
> CONFIG_MTD_PHRAM=m
> CONFIG_MTD_MTDRAM=m
> CONFIG_MTDRAM_TOTAL_SIZE=4096
> CONFIG_MTDRAM_ERASE_SIZE=128
> CONFIG_MTD_BLOCK2MTD=m
>
> #
> # Disk-On-Chip Device Drivers
> #
> # CONFIG_MTD_DOCG3 is not set
> # end of Self-contained MTD device drivers
>
> #
> # NAND
> #
> CONFIG_MTD_NAND_CORE=m
> CONFIG_MTD_ONENAND=m
> CONFIG_MTD_ONENAND_VERIFY_WRITE=y
> CONFIG_MTD_ONENAND_GENERIC=m
> # CONFIG_MTD_ONENAND_OTP is not set
> CONFIG_MTD_ONENAND_2X_PROGRAM=y
> CONFIG_MTD_RAW_NAND=m
>
> #
> # Raw/parallel NAND flash controllers
> #
> CONFIG_MTD_NAND_DENALI=m
> CONFIG_MTD_NAND_DENALI_PCI=m
> CONFIG_MTD_NAND_CAFE=m
> CONFIG_MTD_NAND_MXIC=m
> CONFIG_MTD_NAND_GPIO=m
> CONFIG_MTD_NAND_PLATFORM=m
> CONFIG_MTD_NAND_ARASAN=m
>
> #
> # Misc
> #
> CONFIG_MTD_SM_COMMON=m
> CONFIG_MTD_NAND_NANDSIM=m
> CONFIG_MTD_NAND_RICOH=m
> CONFIG_MTD_NAND_DISKONCHIP=m
> # CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set
> CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0
> # CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set
> CONFIG_MTD_SPI_NAND=m
>
> #
> # ECC engine support
> #
> CONFIG_MTD_NAND_ECC=y
> CONFIG_MTD_NAND_ECC_SW_HAMMING=y
> # CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC is not set
> CONFIG_MTD_NAND_ECC_SW_BCH=y
> CONFIG_MTD_NAND_ECC_MXIC=y
> # end of ECC engine support
> # end of NAND
>
> #
> # LPDDR & LPDDR2 PCM memory drivers
> #
> CONFIG_MTD_LPDDR=m
> CONFIG_MTD_QINFO_PROBE=m
> # end of LPDDR & LPDDR2 PCM memory drivers
>
> CONFIG_MTD_SPI_NOR=m
> CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
> # CONFIG_MTD_SPI_NOR_SWP_DISABLE is not set
> CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE=y
> # CONFIG_MTD_SPI_NOR_SWP_KEEP is not set
> CONFIG_MTD_UBI=m
> CONFIG_MTD_UBI_WL_THRESHOLD=4096
> CONFIG_MTD_UBI_BEB_LIMIT=20
> CONFIG_MTD_UBI_FASTMAP=y
> CONFIG_MTD_UBI_GLUEBI=m
> CONFIG_MTD_UBI_BLOCK=y
> CONFIG_MTD_HYPERBUS=m
> # CONFIG_OF is not set
> CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
> CONFIG_PARPORT=m
> CONFIG_PARPORT_PC=m
> CONFIG_PARPORT_SERIAL=m
> CONFIG_PARPORT_PC_FIFO=y
> # CONFIG_PARPORT_PC_SUPERIO is not set
> CONFIG_PARPORT_PC_PCMCIA=m
> CONFIG_PARPORT_AX88796=m
> CONFIG_PARPORT_1284=y
> CONFIG_PARPORT_NOT_PC=y
> CONFIG_PNP=y
> # CONFIG_PNP_DEBUG_MESSAGES is not set
>
> #
> # Protocols
> #
> CONFIG_PNPACPI=y
> CONFIG_BLK_DEV=y
> CONFIG_BLK_DEV_NULL_BLK=m
> CONFIG_BLK_DEV_FD=m
> # CONFIG_BLK_DEV_FD_RAWCMD is not set
> CONFIG_CDROM=y
> CONFIG_PARIDE=m
>
> #
> # Parallel IDE high-level drivers
> #
> CONFIG_PARIDE_PD=m
> CONFIG_PARIDE_PCD=m
> CONFIG_PARIDE_PF=m
> CONFIG_PARIDE_PT=m
> CONFIG_PARIDE_PG=m
>
> #
> # Parallel IDE protocol modules
> #
> CONFIG_PARIDE_ATEN=m
> CONFIG_PARIDE_BPCK=m
> CONFIG_PARIDE_COMM=m
> CONFIG_PARIDE_DSTR=m
> CONFIG_PARIDE_FIT2=m
> CONFIG_PARIDE_FIT3=m
> CONFIG_PARIDE_EPAT=m
> CONFIG_PARIDE_EPATC8=y
> CONFIG_PARIDE_EPIA=m
> CONFIG_PARIDE_FRIQ=m
> CONFIG_PARIDE_FRPW=m
> CONFIG_PARIDE_KBIC=m
> CONFIG_PARIDE_KTTI=m
> CONFIG_PARIDE_ON20=m
> CONFIG_PARIDE_ON26=m
> CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m
> CONFIG_ZRAM=m
> CONFIG_ZRAM_DEF_COMP_LZORLE=y
> # CONFIG_ZRAM_DEF_COMP_ZSTD is not set
> # CONFIG_ZRAM_DEF_COMP_LZ4 is not set
> # CONFIG_ZRAM_DEF_COMP_LZO is not set
> # CONFIG_ZRAM_DEF_COMP_LZ4HC is not set
> # CONFIG_ZRAM_DEF_COMP_842 is not set
> CONFIG_ZRAM_DEF_COMP="lzo-rle"
> CONFIG_ZRAM_WRITEBACK=y
> CONFIG_ZRAM_MEMORY_TRACKING=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
> CONFIG_BLK_DEV_DRBD=m
> # CONFIG_DRBD_FAULT_INJECTION is not set
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_RAM=m
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=65536
> CONFIG_CDROM_PKTCDVD=m
> CONFIG_CDROM_PKTCDVD_BUFFERS=8
> # CONFIG_CDROM_PKTCDVD_WCACHE is not set
> CONFIG_ATA_OVER_ETH=m
> CONFIG_XEN_BLKDEV_FRONTEND=y
> CONFIG_XEN_BLKDEV_BACKEND=m
> CONFIG_VIRTIO_BLK=m
> CONFIG_BLK_DEV_RBD=m
> # CONFIG_BLK_DEV_UBLK is not set
> CONFIG_BLK_DEV_RNBD=y
> CONFIG_BLK_DEV_RNBD_CLIENT=m
> CONFIG_BLK_DEV_RNBD_SERVER=m
>
> #
> # NVME Support
> #
> CONFIG_NVME_COMMON=m
> CONFIG_NVME_CORE=m
> CONFIG_BLK_DEV_NVME=m
> CONFIG_NVME_MULTIPATH=y
> # CONFIG_NVME_VERBOSE_ERRORS is not set
> CONFIG_NVME_HWMON=y
> CONFIG_NVME_FABRICS=m
> CONFIG_NVME_RDMA=m
> CONFIG_NVME_FC=m
> CONFIG_NVME_TCP=m
> CONFIG_NVME_AUTH=y
> CONFIG_NVME_TARGET=m
> CONFIG_NVME_TARGET_PASSTHRU=y
> CONFIG_NVME_TARGET_LOOP=m
> CONFIG_NVME_TARGET_RDMA=m
> CONFIG_NVME_TARGET_FC=m
> # CONFIG_NVME_TARGET_FCLOOP is not set
> CONFIG_NVME_TARGET_TCP=m
> CONFIG_NVME_TARGET_AUTH=y
> # end of NVME Support
>
> #
> # Misc devices
> #
> CONFIG_SENSORS_LIS3LV02D=m
> CONFIG_AD525X_DPOT=m
> CONFIG_AD525X_DPOT_I2C=m
> CONFIG_AD525X_DPOT_SPI=m
> CONFIG_DUMMY_IRQ=m
> CONFIG_IBM_ASM=m
> CONFIG_PHANTOM=m
> CONFIG_TIFM_CORE=m
> CONFIG_TIFM_7XX1=m
> CONFIG_ICS932S401=m
> CONFIG_ENCLOSURE_SERVICES=m
> CONFIG_SGI_XP=m
> CONFIG_HP_ILO=m
> CONFIG_SGI_GRU=m
> # CONFIG_SGI_GRU_DEBUG is not set
> CONFIG_APDS9802ALS=m
> CONFIG_ISL29003=m
> CONFIG_ISL29020=m
> CONFIG_SENSORS_TSL2550=m
> CONFIG_SENSORS_BH1770=m
> CONFIG_SENSORS_APDS990X=m
> CONFIG_HMC6352=m
> CONFIG_DS1682=m
> CONFIG_VMWARE_BALLOON=m
> CONFIG_LATTICE_ECP3_CONFIG=m
> CONFIG_SRAM=y
> CONFIG_DW_XDATA_PCIE=m
> # CONFIG_PCI_ENDPOINT_TEST is not set
> CONFIG_XILINX_SDFEC=m
> CONFIG_MISC_RTSX=m
> CONFIG_C2PORT=m
> CONFIG_C2PORT_DURAMAR_2150=m
>
> #
> # EEPROM support
> #
> CONFIG_EEPROM_AT24=m
> CONFIG_EEPROM_AT25=m
> CONFIG_EEPROM_LEGACY=m
> CONFIG_EEPROM_MAX6875=m
> CONFIG_EEPROM_93CX6=m
> CONFIG_EEPROM_93XX46=m
> CONFIG_EEPROM_IDT_89HPESX=m
> CONFIG_EEPROM_EE1004=m
> # end of EEPROM support
>
> CONFIG_CB710_CORE=m
> # CONFIG_CB710_DEBUG is not set
> CONFIG_CB710_DEBUG_ASSUMPTIONS=y
>
> #
> # Texas Instruments shared transport line discipline
> #
> CONFIG_TI_ST=m
> # end of Texas Instruments shared transport line discipline
>
> CONFIG_SENSORS_LIS3_I2C=m
> CONFIG_ALTERA_STAPL=m
> CONFIG_INTEL_MEI=m
> CONFIG_INTEL_MEI_ME=m
> CONFIG_INTEL_MEI_TXE=m
> CONFIG_INTEL_MEI_GSC=m
> CONFIG_INTEL_MEI_HDCP=m
> CONFIG_INTEL_MEI_PXP=m
> CONFIG_VMWARE_VMCI=m
> CONFIG_GENWQE=m
> CONFIG_GENWQE_PLATFORM_ERROR_RECOVERY=0
> CONFIG_ECHO=m
> CONFIG_BCM_VK=m
> CONFIG_BCM_VK_TTY=y
> CONFIG_MISC_ALCOR_PCI=m
> CONFIG_MISC_RTSX_PCI=m
> CONFIG_MISC_RTSX_USB=m
> CONFIG_HABANA_AI=m
> CONFIG_UACCE=m
> CONFIG_PVPANIC=y
> CONFIG_PVPANIC_MMIO=m
> CONFIG_PVPANIC_PCI=m
> # end of Misc devices
>
> #
> # SCSI device support
> #
> CONFIG_SCSI_MOD=y
> CONFIG_RAID_ATTRS=m
> CONFIG_SCSI_COMMON=y
> CONFIG_SCSI=y
> CONFIG_SCSI_DMA=y
> CONFIG_SCSI_NETLINK=y
> CONFIG_SCSI_PROC_FS=y
>
> #
> # SCSI support type (disk, tape, CD-ROM)
> #
> CONFIG_BLK_DEV_SD=y
> CONFIG_CHR_DEV_ST=m
> CONFIG_BLK_DEV_SR=y
> CONFIG_CHR_DEV_SG=y
> CONFIG_BLK_DEV_BSG=y
> CONFIG_CHR_DEV_SCH=m
> CONFIG_SCSI_ENCLOSURE=m
> CONFIG_SCSI_CONSTANTS=y
> CONFIG_SCSI_LOGGING=y
> CONFIG_SCSI_SCAN_ASYNC=y
>
> #
> # SCSI Transports
> #
> CONFIG_SCSI_SPI_ATTRS=m
> CONFIG_SCSI_FC_ATTRS=m
> CONFIG_SCSI_ISCSI_ATTRS=m
> CONFIG_SCSI_SAS_ATTRS=m
> CONFIG_SCSI_SAS_LIBSAS=m
> CONFIG_SCSI_SAS_ATA=y
> CONFIG_SCSI_SAS_HOST_SMP=y
> CONFIG_SCSI_SRP_ATTRS=m
> # end of SCSI Transports
>
> CONFIG_SCSI_LOWLEVEL=y
> CONFIG_ISCSI_TCP=m
> CONFIG_ISCSI_BOOT_SYSFS=m
> CONFIG_SCSI_CXGB3_ISCSI=m
> CONFIG_SCSI_CXGB4_ISCSI=m
> CONFIG_SCSI_BNX2_ISCSI=m
> CONFIG_SCSI_BNX2X_FCOE=m
> CONFIG_BE2ISCSI=m
> CONFIG_BLK_DEV_3W_XXXX_RAID=m
> CONFIG_SCSI_HPSA=m
> CONFIG_SCSI_3W_9XXX=m
> CONFIG_SCSI_3W_SAS=m
> CONFIG_SCSI_ACARD=m
> CONFIG_SCSI_AHA1740=m
> CONFIG_SCSI_AACRAID=m
> CONFIG_SCSI_AIC7XXX=m
> CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
> CONFIG_AIC7XXX_RESET_DELAY_MS=5000
> # CONFIG_AIC7XXX_DEBUG_ENABLE is not set
> CONFIG_AIC7XXX_DEBUG_MASK=0
> CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
> CONFIG_SCSI_AIC79XX=m
> CONFIG_AIC79XX_CMDS_PER_DEVICE=32
> CONFIG_AIC79XX_RESET_DELAY_MS=5000
> # CONFIG_AIC79XX_DEBUG_ENABLE is not set
> CONFIG_AIC79XX_DEBUG_MASK=0
> CONFIG_AIC79XX_REG_PRETTY_PRINT=y
> CONFIG_SCSI_AIC94XX=m
> # CONFIG_AIC94XX_DEBUG is not set
> CONFIG_SCSI_MVSAS=m
> # CONFIG_SCSI_MVSAS_DEBUG is not set
> # CONFIG_SCSI_MVSAS_TASKLET is not set
> CONFIG_SCSI_MVUMI=m
> CONFIG_SCSI_ADVANSYS=m
> CONFIG_SCSI_ARCMSR=m
> CONFIG_SCSI_ESAS2R=m
> CONFIG_MEGARAID_NEWGEN=y
> CONFIG_MEGARAID_MM=m
> CONFIG_MEGARAID_MAILBOX=m
> CONFIG_MEGARAID_LEGACY=m
> CONFIG_MEGARAID_SAS=m
> CONFIG_SCSI_MPT3SAS=m
> CONFIG_SCSI_MPT2SAS_MAX_SGE=128
> CONFIG_SCSI_MPT3SAS_MAX_SGE=128
> CONFIG_SCSI_MPT2SAS=m
> CONFIG_SCSI_MPI3MR=m
> CONFIG_SCSI_SMARTPQI=m
> CONFIG_SCSI_HPTIOP=m
> CONFIG_SCSI_BUSLOGIC=m
> CONFIG_SCSI_FLASHPOINT=y
> CONFIG_SCSI_MYRB=m
> CONFIG_SCSI_MYRS=m
> CONFIG_VMWARE_PVSCSI=m
> CONFIG_XEN_SCSI_FRONTEND=m
> CONFIG_HYPERV_STORAGE=m
> CONFIG_LIBFC=m
> CONFIG_LIBFCOE=m
> CONFIG_FCOE=m
> CONFIG_FCOE_FNIC=m
> CONFIG_SCSI_SNIC=m
> # CONFIG_SCSI_SNIC_DEBUG_FS is not set
> CONFIG_SCSI_DMX3191D=m
> CONFIG_SCSI_FDOMAIN=m
> CONFIG_SCSI_FDOMAIN_PCI=m
> CONFIG_SCSI_ISCI=m
> CONFIG_SCSI_IPS=m
> CONFIG_SCSI_INITIO=m
> CONFIG_SCSI_INIA100=m
> CONFIG_SCSI_PPA=m
> CONFIG_SCSI_IMM=m
> # CONFIG_SCSI_IZIP_EPP16 is not set
> # CONFIG_SCSI_IZIP_SLOW_CTR is not set
> CONFIG_SCSI_STEX=m
> CONFIG_SCSI_SYM53C8XX_2=m
> CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
> CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
> CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
> CONFIG_SCSI_SYM53C8XX_MMIO=y
> CONFIG_SCSI_IPR=m
> CONFIG_SCSI_IPR_TRACE=y
> CONFIG_SCSI_IPR_DUMP=y
> CONFIG_SCSI_QLOGIC_1280=m
> CONFIG_SCSI_QLA_FC=m
> CONFIG_TCM_QLA2XXX=m
> # CONFIG_TCM_QLA2XXX_DEBUG is not set
> CONFIG_SCSI_QLA_ISCSI=m
> CONFIG_QEDI=m
> CONFIG_QEDF=m
> CONFIG_SCSI_LPFC=m
> # CONFIG_SCSI_LPFC_DEBUG_FS is not set
> CONFIG_SCSI_EFCT=m
> CONFIG_SCSI_SIM710=m
> CONFIG_SCSI_DC395x=m
> CONFIG_SCSI_AM53C974=m
> CONFIG_SCSI_WD719X=m
> CONFIG_SCSI_DEBUG=m
> CONFIG_SCSI_PMCRAID=m
> CONFIG_SCSI_PM8001=m
> CONFIG_SCSI_BFA_FC=m
> CONFIG_SCSI_VIRTIO=m
> CONFIG_SCSI_CHELSIO_FCOE=m
> CONFIG_SCSI_LOWLEVEL_PCMCIA=y
> CONFIG_PCMCIA_AHA152X=m
> CONFIG_PCMCIA_FDOMAIN=m
> CONFIG_PCMCIA_QLOGIC=m
> CONFIG_PCMCIA_SYM53C500=m
> CONFIG_SCSI_DH=y
> CONFIG_SCSI_DH_RDAC=m
> CONFIG_SCSI_DH_HP_SW=m
> CONFIG_SCSI_DH_EMC=m
> CONFIG_SCSI_DH_ALUA=m
> # end of SCSI device support
>
> CONFIG_ATA=y
> CONFIG_SATA_HOST=y
> CONFIG_PATA_TIMINGS=y
> CONFIG_ATA_VERBOSE_ERROR=y
> CONFIG_ATA_FORCE=y
> CONFIG_ATA_ACPI=y
> CONFIG_SATA_ZPODD=y
> CONFIG_SATA_PMP=y
>
> #
> # Controllers with non-SFF native interface
> #
> CONFIG_SATA_AHCI=m
> CONFIG_SATA_MOBILE_LPM_POLICY=3
> CONFIG_SATA_AHCI_PLATFORM=m
> CONFIG_SATA_INIC162X=m
> CONFIG_SATA_ACARD_AHCI=m
> CONFIG_SATA_SIL24=m
> CONFIG_ATA_SFF=y
>
> #
> # SFF controllers with custom DMA interface
> #
> CONFIG_PDC_ADMA=m
> CONFIG_SATA_QSTOR=m
> CONFIG_SATA_SX4=m
> CONFIG_ATA_BMDMA=y
>
> #
> # SATA SFF controllers with BMDMA
> #
> CONFIG_ATA_PIIX=y
> CONFIG_SATA_DWC=m
> CONFIG_SATA_DWC_OLD_DMA=y
> CONFIG_SATA_MV=m
> CONFIG_SATA_NV=m
> CONFIG_SATA_PROMISE=m
> CONFIG_SATA_SIL=m
> CONFIG_SATA_SIS=m
> CONFIG_SATA_SVW=m
> CONFIG_SATA_ULI=m
> CONFIG_SATA_VIA=m
> CONFIG_SATA_VITESSE=m
>
> #
> # PATA SFF controllers with BMDMA
> #
> CONFIG_PATA_ALI=m
> CONFIG_PATA_AMD=m
> CONFIG_PATA_ARTOP=m
> CONFIG_PATA_ATIIXP=m
> CONFIG_PATA_ATP867X=m
> CONFIG_PATA_CMD64X=m
> CONFIG_PATA_CYPRESS=m
> CONFIG_PATA_EFAR=m
> CONFIG_PATA_HPT366=m
> CONFIG_PATA_HPT37X=m
> CONFIG_PATA_HPT3X2N=m
> CONFIG_PATA_HPT3X3=m
> # CONFIG_PATA_HPT3X3_DMA is not set
> CONFIG_PATA_IT8213=m
> CONFIG_PATA_IT821X=m
> CONFIG_PATA_JMICRON=m
> CONFIG_PATA_MARVELL=m
> CONFIG_PATA_NETCELL=m
> CONFIG_PATA_NINJA32=m
> CONFIG_PATA_NS87415=m
> CONFIG_PATA_OLDPIIX=m
> CONFIG_PATA_OPTIDMA=m
> CONFIG_PATA_PDC2027X=m
> CONFIG_PATA_PDC_OLD=m
> CONFIG_PATA_RADISYS=m
> CONFIG_PATA_RDC=m
> CONFIG_PATA_SCH=m
> CONFIG_PATA_SERVERWORKS=m
> CONFIG_PATA_SIL680=m
> CONFIG_PATA_SIS=y
> CONFIG_PATA_TOSHIBA=m
> CONFIG_PATA_TRIFLEX=m
> CONFIG_PATA_VIA=m
> CONFIG_PATA_WINBOND=m
>
> #
> # PIO-only SFF controllers
> #
> CONFIG_PATA_CMD640_PCI=m
> CONFIG_PATA_MPIIX=m
> CONFIG_PATA_NS87410=m
> CONFIG_PATA_OPTI=m
> CONFIG_PATA_PCMCIA=m
> CONFIG_PATA_PLATFORM=m
> CONFIG_PATA_RZ1000=m
>
> #
> # Generic fallback / legacy drivers
> #
> CONFIG_PATA_ACPI=m
> CONFIG_ATA_GENERIC=y
> CONFIG_PATA_LEGACY=m
> CONFIG_MD=y
> CONFIG_BLK_DEV_MD=y
> CONFIG_MD_AUTODETECT=y
> CONFIG_MD_LINEAR=m
> CONFIG_MD_RAID0=m
> CONFIG_MD_RAID1=m
> CONFIG_MD_RAID10=m
> CONFIG_MD_RAID456=m
> CONFIG_MD_MULTIPATH=m
> CONFIG_MD_FAULTY=m
> CONFIG_MD_CLUSTER=m
> CONFIG_BCACHE=m
> # CONFIG_BCACHE_DEBUG is not set
> # CONFIG_BCACHE_CLOSURES_DEBUG is not set
> CONFIG_BCACHE_ASYNC_REGISTRATION=y
> CONFIG_BLK_DEV_DM_BUILTIN=y
> CONFIG_BLK_DEV_DM=y
> # CONFIG_DM_DEBUG is not set
> CONFIG_DM_BUFIO=m
> # CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING is not set
> CONFIG_DM_BIO_PRISON=m
> CONFIG_DM_PERSISTENT_DATA=m
> CONFIG_DM_UNSTRIPED=m
> CONFIG_DM_CRYPT=m
> CONFIG_DM_SNAPSHOT=m
> CONFIG_DM_THIN_PROVISIONING=m
> CONFIG_DM_CACHE=m
> CONFIG_DM_CACHE_SMQ=m
> CONFIG_DM_WRITECACHE=m
> CONFIG_DM_EBS=m
> CONFIG_DM_ERA=m
> CONFIG_DM_CLONE=m
> CONFIG_DM_MIRROR=m
> CONFIG_DM_LOG_USERSPACE=m
> CONFIG_DM_RAID=m
> CONFIG_DM_ZERO=m
> CONFIG_DM_MULTIPATH=m
> CONFIG_DM_MULTIPATH_QL=m
> CONFIG_DM_MULTIPATH_ST=m
> CONFIG_DM_MULTIPATH_HST=m
> CONFIG_DM_MULTIPATH_IOA=m
> CONFIG_DM_DELAY=m
> # CONFIG_DM_DUST is not set
> CONFIG_DM_INIT=y
> CONFIG_DM_UEVENT=y
> CONFIG_DM_FLAKEY=m
> CONFIG_DM_VERITY=m
> CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=y
> # CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING is not set
> # CONFIG_DM_VERITY_FEC is not set
> CONFIG_DM_SWITCH=m
> CONFIG_DM_LOG_WRITES=m
> CONFIG_DM_INTEGRITY=m
> CONFIG_DM_ZONED=m
> CONFIG_DM_AUDIT=y
> CONFIG_TARGET_CORE=m
> CONFIG_TCM_IBLOCK=m
> CONFIG_TCM_FILEIO=m
> CONFIG_TCM_PSCSI=m
> CONFIG_TCM_USER2=m
> CONFIG_LOOPBACK_TARGET=m
> CONFIG_TCM_FC=m
> CONFIG_ISCSI_TARGET=m
> CONFIG_ISCSI_TARGET_CXGB4=m
> CONFIG_SBP_TARGET=m
> CONFIG_FUSION=y
> CONFIG_FUSION_SPI=m
> CONFIG_FUSION_FC=m
> CONFIG_FUSION_SAS=m
> CONFIG_FUSION_MAX_SGE=128
> CONFIG_FUSION_CTL=m
> CONFIG_FUSION_LAN=m
> CONFIG_FUSION_LOGGING=y
>
> #
> # IEEE 1394 (FireWire) support
> #
> CONFIG_FIREWIRE=m
> CONFIG_FIREWIRE_OHCI=m
> CONFIG_FIREWIRE_SBP2=m
> CONFIG_FIREWIRE_NET=m
> CONFIG_FIREWIRE_NOSY=m
> # end of IEEE 1394 (FireWire) support
>
> CONFIG_MACINTOSH_DRIVERS=y
> CONFIG_MAC_EMUMOUSEBTN=m
> CONFIG_NETDEVICES=y
> CONFIG_MII=m
> CONFIG_NET_CORE=y
> CONFIG_BONDING=m
> CONFIG_DUMMY=m
> CONFIG_WIREGUARD=m
> # CONFIG_WIREGUARD_DEBUG is not set
> CONFIG_EQUALIZER=m
> CONFIG_NET_FC=y
> CONFIG_IFB=m
> CONFIG_NET_TEAM=m
> CONFIG_NET_TEAM_MODE_BROADCAST=m
> CONFIG_NET_TEAM_MODE_ROUNDROBIN=m
> CONFIG_NET_TEAM_MODE_RANDOM=m
> CONFIG_NET_TEAM_MODE_ACTIVEBACKUP=m
> CONFIG_NET_TEAM_MODE_LOADBALANCE=m
> CONFIG_MACVLAN=m
> CONFIG_MACVTAP=m
> CONFIG_IPVLAN_L3S=y
> CONFIG_IPVLAN=m
> CONFIG_IPVTAP=m
> CONFIG_VXLAN=m
> CONFIG_GENEVE=m
> CONFIG_BAREUDP=m
> CONFIG_GTP=m
> CONFIG_AMT=m
> CONFIG_MACSEC=m
> CONFIG_NETCONSOLE=m
> CONFIG_NETCONSOLE_DYNAMIC=y
> CONFIG_NETPOLL=y
> CONFIG_NET_POLL_CONTROLLER=y
> CONFIG_NTB_NETDEV=m
> CONFIG_RIONET=m
> CONFIG_RIONET_TX_SIZE=128
> CONFIG_RIONET_RX_SIZE=128
> CONFIG_TUN=y
> CONFIG_TAP=m
> # CONFIG_TUN_VNET_CROSS_LE is not set
> CONFIG_VETH=m
> CONFIG_VIRTIO_NET=m
> CONFIG_NLMON=m
> CONFIG_NET_VRF=m
> CONFIG_VSOCKMON=m
> CONFIG_MHI_NET=m
> CONFIG_SUNGEM_PHY=m
> CONFIG_ARCNET=m
> CONFIG_ARCNET_1201=m
> CONFIG_ARCNET_1051=m
> CONFIG_ARCNET_RAW=m
> CONFIG_ARCNET_CAP=m
> CONFIG_ARCNET_COM90xx=m
> CONFIG_ARCNET_COM90xxIO=m
> CONFIG_ARCNET_RIM_I=m
> CONFIG_ARCNET_COM20020=m
> CONFIG_ARCNET_COM20020_PCI=m
> CONFIG_ARCNET_COM20020_CS=m
> CONFIG_ATM_DRIVERS=y
> CONFIG_ATM_DUMMY=m
> CONFIG_ATM_TCP=m
> CONFIG_ATM_LANAI=m
> CONFIG_ATM_ENI=m
> # CONFIG_ATM_ENI_DEBUG is not set
> # CONFIG_ATM_ENI_TUNE_BURST is not set
> CONFIG_ATM_NICSTAR=m
> # CONFIG_ATM_NICSTAR_USE_SUNI is not set
> # CONFIG_ATM_NICSTAR_USE_IDT77105 is not set
> CONFIG_ATM_IDT77252=m
> # CONFIG_ATM_IDT77252_DEBUG is not set
> # CONFIG_ATM_IDT77252_RCV_ALL is not set
> CONFIG_ATM_IDT77252_USE_SUNI=y
> CONFIG_ATM_IA=m
> # CONFIG_ATM_IA_DEBUG is not set
> CONFIG_ATM_FORE200E=m
> # CONFIG_ATM_FORE200E_USE_TASKLET is not set
> CONFIG_ATM_FORE200E_TX_RETRY=16
> CONFIG_ATM_FORE200E_DEBUG=0
> CONFIG_ATM_HE=m
> CONFIG_ATM_HE_USE_SUNI=y
> CONFIG_ATM_SOLOS=m
> CONFIG_CAIF_DRIVERS=y
> CONFIG_CAIF_TTY=m
> CONFIG_CAIF_VIRTIO=m
>
> #
> # Distributed Switch Architecture drivers
> #
> CONFIG_B53=m
> CONFIG_B53_SPI_DRIVER=m
> CONFIG_B53_MDIO_DRIVER=m
> CONFIG_B53_MMAP_DRIVER=m
> CONFIG_B53_SRAB_DRIVER=m
> CONFIG_B53_SERDES=m
> CONFIG_NET_DSA_BCM_SF2=m
> # CONFIG_NET_DSA_LOOP is not set
> CONFIG_NET_DSA_HIRSCHMANN_HELLCREEK=m
> CONFIG_NET_DSA_LANTIQ_GSWIP=m
> CONFIG_NET_DSA_MT7530=m
> CONFIG_NET_DSA_MV88E6060=m
> CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON=m
> CONFIG_NET_DSA_MICROCHIP_KSZ9477_I2C=m
> CONFIG_NET_DSA_MICROCHIP_KSZ_SPI=m
> CONFIG_NET_DSA_MICROCHIP_KSZ8863_SMI=m
> CONFIG_NET_DSA_MV88E6XXX=m
> CONFIG_NET_DSA_MV88E6XXX_PTP=y
> CONFIG_NET_DSA_MSCC_SEVILLE=m
> CONFIG_NET_DSA_AR9331=m
> CONFIG_NET_DSA_QCA8K=m
> CONFIG_NET_DSA_SJA1105=m
> CONFIG_NET_DSA_SJA1105_PTP=y
> CONFIG_NET_DSA_SJA1105_TAS=y
> CONFIG_NET_DSA_SJA1105_VL=y
> CONFIG_NET_DSA_XRS700X=m
> CONFIG_NET_DSA_XRS700X_I2C=m
> CONFIG_NET_DSA_XRS700X_MDIO=m
> CONFIG_NET_DSA_REALTEK=m
> # CONFIG_NET_DSA_REALTEK_MDIO is not set
> # CONFIG_NET_DSA_REALTEK_SMI is not set
> CONFIG_NET_DSA_REALTEK_RTL8365MB=m
> CONFIG_NET_DSA_REALTEK_RTL8366RB=m
> CONFIG_NET_DSA_SMSC_LAN9303=m
> CONFIG_NET_DSA_SMSC_LAN9303_I2C=m
> CONFIG_NET_DSA_SMSC_LAN9303_MDIO=m
> CONFIG_NET_DSA_VITESSE_VSC73XX=m
> CONFIG_NET_DSA_VITESSE_VSC73XX_SPI=m
> CONFIG_NET_DSA_VITESSE_VSC73XX_PLATFORM=m
> # end of Distributed Switch Architecture drivers
>
> CONFIG_ETHERNET=y
> CONFIG_MDIO=m
> CONFIG_NET_VENDOR_3COM=y
> CONFIG_EL3=m
> CONFIG_PCMCIA_3C574=m
> CONFIG_PCMCIA_3C589=m
> CONFIG_VORTEX=m
> CONFIG_TYPHOON=m
> CONFIG_NET_VENDOR_ADAPTEC=y
> CONFIG_ADAPTEC_STARFIRE=m
> CONFIG_NET_VENDOR_AGERE=y
> CONFIG_ET131X=m
> CONFIG_NET_VENDOR_ALACRITECH=y
> CONFIG_SLICOSS=m
> CONFIG_NET_VENDOR_ALTEON=y
> CONFIG_ACENIC=m
> # CONFIG_ACENIC_OMIT_TIGON_I is not set
> CONFIG_ALTERA_TSE=m
> CONFIG_NET_VENDOR_AMAZON=y
> CONFIG_ENA_ETHERNET=m
> CONFIG_NET_VENDOR_AMD=y
> CONFIG_AMD8111_ETH=m
> CONFIG_PCNET32=m
> CONFIG_PCMCIA_NMCLAN=m
> CONFIG_AMD_XGBE=m
> CONFIG_AMD_XGBE_DCB=y
> CONFIG_AMD_XGBE_HAVE_ECC=y
> CONFIG_NET_VENDOR_AQUANTIA=y
> CONFIG_AQTION=m
> CONFIG_NET_VENDOR_ARC=y
> CONFIG_NET_VENDOR_ASIX=y
> CONFIG_SPI_AX88796C=m
> # CONFIG_SPI_AX88796C_COMPRESSION is not set
> CONFIG_NET_VENDOR_ATHEROS=y
> CONFIG_ATL2=m
> CONFIG_ATL1=m
> CONFIG_ATL1E=m
> CONFIG_ATL1C=m
> CONFIG_ALX=m
> CONFIG_CX_ECAT=m
> CONFIG_NET_VENDOR_BROADCOM=y
> CONFIG_B44=m
> CONFIG_B44_PCI_AUTOSELECT=y
> CONFIG_B44_PCICORE_AUTOSELECT=y
> CONFIG_B44_PCI=y
> CONFIG_BCMGENET=m
> CONFIG_BNX2=m
> CONFIG_CNIC=m
> CONFIG_TIGON3=m
> CONFIG_TIGON3_HWMON=y
> CONFIG_BNX2X=m
> CONFIG_BNX2X_SRIOV=y
> CONFIG_SYSTEMPORT=m
> CONFIG_BNXT=m
> CONFIG_BNXT_SRIOV=y
> CONFIG_BNXT_FLOWER_OFFLOAD=y
> CONFIG_BNXT_DCB=y
> CONFIG_BNXT_HWMON=y
> CONFIG_NET_VENDOR_CADENCE=y
> CONFIG_MACB=m
> CONFIG_MACB_USE_HWSTAMP=y
> CONFIG_MACB_PCI=m
> CONFIG_NET_VENDOR_CAVIUM=y
> CONFIG_THUNDER_NIC_PF=m
> CONFIG_THUNDER_NIC_VF=m
> CONFIG_THUNDER_NIC_BGX=m
> CONFIG_THUNDER_NIC_RGX=m
> CONFIG_CAVIUM_PTP=m
> CONFIG_LIQUIDIO=m
> CONFIG_LIQUIDIO_VF=m
> CONFIG_NET_VENDOR_CHELSIO=y
> CONFIG_CHELSIO_T1=m
> CONFIG_CHELSIO_T1_1G=y
> CONFIG_CHELSIO_T3=m
> CONFIG_CHELSIO_T4=m
> CONFIG_CHELSIO_T4_DCB=y
> CONFIG_CHELSIO_T4_FCOE=y
> CONFIG_CHELSIO_T4VF=m
> CONFIG_CHELSIO_LIB=m
> CONFIG_CHELSIO_INLINE_CRYPTO=y
> CONFIG_CHELSIO_IPSEC_INLINE=m
> CONFIG_CHELSIO_TLS_DEVICE=m
> CONFIG_NET_VENDOR_CIRRUS=y
> CONFIG_NET_VENDOR_CISCO=y
> CONFIG_ENIC=m
> CONFIG_NET_VENDOR_CORTINA=y
> CONFIG_NET_VENDOR_DAVICOM=y
> CONFIG_DM9051=m
> CONFIG_DNET=m
> CONFIG_NET_VENDOR_DEC=y
> CONFIG_NET_TULIP=y
> CONFIG_DE2104X=m
> CONFIG_DE2104X_DSL=0
> CONFIG_TULIP=m
> # CONFIG_TULIP_MWI is not set
> # CONFIG_TULIP_MMIO is not set
> # CONFIG_TULIP_NAPI is not set
> CONFIG_WINBOND_840=m
> CONFIG_DM9102=m
> CONFIG_ULI526X=m
> CONFIG_PCMCIA_XIRCOM=m
> CONFIG_NET_VENDOR_DLINK=y
> CONFIG_DL2K=m
> CONFIG_SUNDANCE=m
> # CONFIG_SUNDANCE_MMIO is not set
> CONFIG_NET_VENDOR_EMULEX=y
> CONFIG_BE2NET=m
> CONFIG_BE2NET_HWMON=y
> CONFIG_BE2NET_BE2=y
> CONFIG_BE2NET_BE3=y
> CONFIG_BE2NET_LANCER=y
> CONFIG_BE2NET_SKYHAWK=y
> CONFIG_NET_VENDOR_ENGLEDER=y
> CONFIG_TSNEP=m
> # CONFIG_TSNEP_SELFTESTS is not set
> CONFIG_NET_VENDOR_EZCHIP=y
> CONFIG_NET_VENDOR_FUJITSU=y
> CONFIG_PCMCIA_FMVJ18X=m
> CONFIG_NET_VENDOR_FUNGIBLE=y
> CONFIG_FUN_CORE=m
> CONFIG_FUN_ETH=m
> CONFIG_NET_VENDOR_GOOGLE=y
> CONFIG_GVE=m
> CONFIG_NET_VENDOR_HUAWEI=y
> CONFIG_HINIC=m
> CONFIG_NET_VENDOR_I825XX=y
> CONFIG_NET_VENDOR_INTEL=y
> CONFIG_E100=m
> CONFIG_E1000=m
> CONFIG_E1000E=m
> CONFIG_E1000E_HWTS=y
> CONFIG_IGB=m
> CONFIG_IGB_HWMON=y
> CONFIG_IGB_DCA=y
> CONFIG_IGBVF=m
> CONFIG_IXGB=m
> CONFIG_IXGBE=m
> CONFIG_IXGBE_HWMON=y
> CONFIG_IXGBE_DCA=y
> CONFIG_IXGBE_DCB=y
> CONFIG_IXGBE_IPSEC=y
> CONFIG_IXGBEVF=m
> CONFIG_IXGBEVF_IPSEC=y
> CONFIG_I40E=m
> CONFIG_I40E_DCB=y
> CONFIG_IAVF=m
> CONFIG_I40EVF=m
> CONFIG_ICE=m
> CONFIG_ICE_SWITCHDEV=y
> CONFIG_ICE_HWTS=y
> CONFIG_FM10K=m
> CONFIG_IGC=m
> CONFIG_NET_VENDOR_WANGXUN=y
> CONFIG_TXGBE=m
> CONFIG_JME=m
> CONFIG_NET_VENDOR_LITEX=y
> CONFIG_NET_VENDOR_MARVELL=y
> CONFIG_MVMDIO=m
> CONFIG_SKGE=m
> # CONFIG_SKGE_DEBUG is not set
> CONFIG_SKGE_GENESIS=y
> CONFIG_SKY2=m
> # CONFIG_SKY2_DEBUG is not set
> CONFIG_OCTEON_EP=m
> CONFIG_PRESTERA=m
> CONFIG_PRESTERA_PCI=m
> CONFIG_NET_VENDOR_MELLANOX=y
> CONFIG_MLX4_EN=m
> CONFIG_MLX4_EN_DCB=y
> CONFIG_MLX4_CORE=m
> CONFIG_MLX4_DEBUG=y
> CONFIG_MLX4_CORE_GEN2=y
> CONFIG_MLX5_CORE=m
> CONFIG_MLX5_FPGA=y
> CONFIG_MLX5_CORE_EN=y
> CONFIG_MLX5_EN_ARFS=y
> CONFIG_MLX5_EN_RXNFC=y
> CONFIG_MLX5_MPFS=y
> CONFIG_MLX5_ESWITCH=y
> CONFIG_MLX5_BRIDGE=y
> CONFIG_MLX5_CLS_ACT=y
> CONFIG_MLX5_TC_CT=y
> CONFIG_MLX5_TC_SAMPLE=y
> CONFIG_MLX5_CORE_EN_DCB=y
> CONFIG_MLX5_CORE_IPOIB=y
> CONFIG_MLX5_EN_IPSEC=y
> CONFIG_MLX5_EN_TLS=y
> CONFIG_MLX5_SW_STEERING=y
> CONFIG_MLX5_SF=y
> CONFIG_MLX5_SF_MANAGER=y
> CONFIG_MLXSW_CORE=m
> CONFIG_MLXSW_CORE_HWMON=y
> CONFIG_MLXSW_CORE_THERMAL=y
> CONFIG_MLXSW_PCI=m
> CONFIG_MLXSW_I2C=m
> CONFIG_MLXSW_SPECTRUM=m
> CONFIG_MLXSW_SPECTRUM_DCB=y
> CONFIG_MLXSW_MINIMAL=m
> CONFIG_MLXFW=m
> CONFIG_NET_VENDOR_MICREL=y
> CONFIG_KS8842=m
> CONFIG_KS8851=m
> CONFIG_KS8851_MLL=m
> CONFIG_KSZ884X_PCI=m
> CONFIG_NET_VENDOR_MICROCHIP=y
> CONFIG_ENC28J60=m
> # CONFIG_ENC28J60_WRITEVERIFY is not set
> CONFIG_ENCX24J600=m
> CONFIG_LAN743X=m
> CONFIG_NET_VENDOR_MICROSEMI=y
> CONFIG_MSCC_OCELOT_SWITCH_LIB=m
> CONFIG_NET_VENDOR_MICROSOFT=y
> CONFIG_MICROSOFT_MANA=m
> CONFIG_NET_VENDOR_MYRI=y
> CONFIG_MYRI10GE=m
> CONFIG_MYRI10GE_DCA=y
> CONFIG_FEALNX=m
> CONFIG_NET_VENDOR_NI=y
> CONFIG_NI_XGE_MANAGEMENT_ENET=m
> CONFIG_NET_VENDOR_NATSEMI=y
> CONFIG_NATSEMI=m
> CONFIG_NS83820=m
> CONFIG_NET_VENDOR_NETERION=y
> CONFIG_S2IO=m
> CONFIG_NET_VENDOR_NETRONOME=y
> CONFIG_NFP=m
> CONFIG_NFP_APP_FLOWER=y
> CONFIG_NFP_APP_ABM_NIC=y
> # CONFIG_NFP_DEBUG is not set
> CONFIG_NET_VENDOR_8390=y
> CONFIG_PCMCIA_AXNET=m
> CONFIG_NE2K_PCI=m
> CONFIG_PCMCIA_PCNET=m
> CONFIG_NET_VENDOR_NVIDIA=y
> CONFIG_FORCEDETH=m
> CONFIG_NET_VENDOR_OKI=y
> CONFIG_ETHOC=m
> CONFIG_NET_VENDOR_PACKET_ENGINES=y
> CONFIG_HAMACHI=m
> CONFIG_YELLOWFIN=m
> CONFIG_NET_VENDOR_PENSANDO=y
> CONFIG_IONIC=m
> CONFIG_NET_VENDOR_QLOGIC=y
> CONFIG_QLA3XXX=m
> CONFIG_QLCNIC=m
> CONFIG_QLCNIC_SRIOV=y
> CONFIG_QLCNIC_DCB=y
> CONFIG_QLCNIC_HWMON=y
> CONFIG_NETXEN_NIC=m
> CONFIG_QED=m
> CONFIG_QED_LL2=y
> CONFIG_QED_SRIOV=y
> CONFIG_QEDE=m
> CONFIG_QED_RDMA=y
> CONFIG_QED_ISCSI=y
> CONFIG_QED_FCOE=y
> CONFIG_QED_OOO=y
> CONFIG_NET_VENDOR_BROCADE=y
> CONFIG_BNA=m
> CONFIG_NET_VENDOR_QUALCOMM=y
> CONFIG_QCOM_EMAC=m
> CONFIG_RMNET=m
> CONFIG_NET_VENDOR_RDC=y
> CONFIG_R6040=m
> CONFIG_NET_VENDOR_REALTEK=y
> CONFIG_ATP=m
> CONFIG_8139CP=m
> CONFIG_8139TOO=m
> CONFIG_8139TOO_PIO=y
> # CONFIG_8139TOO_TUNE_TWISTER is not set
> CONFIG_8139TOO_8129=y
> # CONFIG_8139_OLD_RX_RESET is not set
> CONFIG_R8169=m
> CONFIG_NET_VENDOR_RENESAS=y
> CONFIG_NET_VENDOR_ROCKER=y
> CONFIG_ROCKER=m
> CONFIG_NET_VENDOR_SAMSUNG=y
> CONFIG_SXGBE_ETH=m
> CONFIG_NET_VENDOR_SEEQ=y
> CONFIG_NET_VENDOR_SILAN=y
> CONFIG_SC92031=m
> CONFIG_NET_VENDOR_SIS=y
> CONFIG_SIS900=m
> CONFIG_SIS190=m
> CONFIG_NET_VENDOR_SOLARFLARE=y
> CONFIG_SFC=m
> CONFIG_SFC_MTD=y
> CONFIG_SFC_MCDI_MON=y
> CONFIG_SFC_SRIOV=y
> CONFIG_SFC_MCDI_LOGGING=y
> CONFIG_SFC_FALCON=m
> CONFIG_SFC_FALCON_MTD=y
> CONFIG_SFC_SIENA=m
> CONFIG_SFC_SIENA_MTD=y
> CONFIG_SFC_SIENA_MCDI_MON=y
> CONFIG_SFC_SIENA_SRIOV=y
> CONFIG_SFC_SIENA_MCDI_LOGGING=y
> CONFIG_NET_VENDOR_SMSC=y
> CONFIG_PCMCIA_SMC91C92=m
> CONFIG_EPIC100=m
> CONFIG_SMSC911X=m
> CONFIG_SMSC9420=m
> CONFIG_NET_VENDOR_SOCIONEXT=y
> CONFIG_NET_VENDOR_STMICRO=y
> CONFIG_STMMAC_ETH=m
> # CONFIG_STMMAC_SELFTESTS is not set
> CONFIG_STMMAC_PLATFORM=m
> CONFIG_DWMAC_GENERIC=m
> CONFIG_DWMAC_INTEL=m
> CONFIG_DWMAC_LOONGSON=m
> CONFIG_STMMAC_PCI=m
> CONFIG_NET_VENDOR_SUN=y
> CONFIG_HAPPYMEAL=m
> CONFIG_SUNGEM=m
> CONFIG_CASSINI=m
> CONFIG_NIU=m
> CONFIG_NET_VENDOR_SYNOPSYS=y
> CONFIG_DWC_XLGMAC=m
> CONFIG_DWC_XLGMAC_PCI=m
> CONFIG_NET_VENDOR_TEHUTI=y
> CONFIG_TEHUTI=m
> CONFIG_NET_VENDOR_TI=y
> # CONFIG_TI_CPSW_PHY_SEL is not set
> CONFIG_TLAN=m
> CONFIG_NET_VENDOR_VERTEXCOM=y
> CONFIG_MSE102X=m
> CONFIG_NET_VENDOR_VIA=y
> CONFIG_VIA_RHINE=m
> CONFIG_VIA_RHINE_MMIO=y
> CONFIG_VIA_VELOCITY=m
> CONFIG_NET_VENDOR_WIZNET=y
> CONFIG_WIZNET_W5100=m
> CONFIG_WIZNET_W5300=m
> # CONFIG_WIZNET_BUS_DIRECT is not set
> # CONFIG_WIZNET_BUS_INDIRECT is not set
> CONFIG_WIZNET_BUS_ANY=y
> CONFIG_WIZNET_W5100_SPI=m
> CONFIG_NET_VENDOR_XILINX=y
> CONFIG_XILINX_EMACLITE=m
> CONFIG_XILINX_AXI_EMAC=m
> CONFIG_XILINX_LL_TEMAC=m
> CONFIG_NET_VENDOR_XIRCOM=y
> CONFIG_PCMCIA_XIRC2PS=m
> CONFIG_FDDI=y
> CONFIG_DEFXX=m
> CONFIG_SKFP=m
> # CONFIG_HIPPI is not set
> CONFIG_NET_SB1000=m
> CONFIG_PHYLINK=m
> CONFIG_PHYLIB=y
> CONFIG_SWPHY=y
> CONFIG_LED_TRIGGER_PHY=y
> CONFIG_FIXED_PHY=y
> CONFIG_SFP=m
>
> #
> # MII PHY device drivers
> #
> CONFIG_AMD_PHY=m
> CONFIG_ADIN_PHY=m
> CONFIG_ADIN1100_PHY=m
> CONFIG_AQUANTIA_PHY=m
> CONFIG_AX88796B_PHY=m
> CONFIG_BROADCOM_PHY=m
> CONFIG_BCM54140_PHY=m
> CONFIG_BCM7XXX_PHY=m
> CONFIG_BCM84881_PHY=y
> CONFIG_BCM87XX_PHY=m
> CONFIG_BCM_NET_PHYLIB=m
> CONFIG_BCM_NET_PHYPTP=m
> CONFIG_CICADA_PHY=m
> CONFIG_CORTINA_PHY=m
> CONFIG_DAVICOM_PHY=m
> CONFIG_ICPLUS_PHY=m
> CONFIG_LXT_PHY=m
> CONFIG_INTEL_XWAY_PHY=m
> CONFIG_LSI_ET1011C_PHY=m
> CONFIG_MARVELL_PHY=m
> CONFIG_MARVELL_10G_PHY=m
> CONFIG_MARVELL_88X2222_PHY=m
> CONFIG_MAXLINEAR_GPHY=m
> CONFIG_MEDIATEK_GE_PHY=m
> CONFIG_MICREL_PHY=m
> CONFIG_MICROCHIP_PHY=m
> CONFIG_MICROCHIP_T1_PHY=m
> CONFIG_MICROSEMI_PHY=m
> CONFIG_MOTORCOMM_PHY=m
> CONFIG_NATIONAL_PHY=m
> CONFIG_NXP_C45_TJA11XX_PHY=m
> CONFIG_NXP_TJA11XX_PHY=m
> CONFIG_AT803X_PHY=m
> CONFIG_QSEMI_PHY=m
> CONFIG_REALTEK_PHY=m
> CONFIG_RENESAS_PHY=m
> CONFIG_ROCKCHIP_PHY=m
> CONFIG_SMSC_PHY=m
> CONFIG_STE10XP=m
> CONFIG_TERANETICS_PHY=m
> CONFIG_DP83822_PHY=m
> CONFIG_DP83TC811_PHY=m
> CONFIG_DP83848_PHY=m
> CONFIG_DP83867_PHY=m
> CONFIG_DP83869_PHY=m
> CONFIG_DP83TD510_PHY=m
> CONFIG_VITESSE_PHY=m
> CONFIG_XILINX_GMII2RGMII=m
> CONFIG_MICREL_KS8995MA=m
> CONFIG_CAN_DEV=m
> CONFIG_CAN_VCAN=m
> CONFIG_CAN_VXCAN=m
> CONFIG_CAN_NETLINK=y
> CONFIG_CAN_CALC_BITTIMING=y
> CONFIG_CAN_RX_OFFLOAD=y
> CONFIG_CAN_CAN327=m
> CONFIG_CAN_JANZ_ICAN3=m
> CONFIG_CAN_KVASER_PCIEFD=m
> CONFIG_CAN_SLCAN=m
> CONFIG_CAN_C_CAN=m
> CONFIG_CAN_C_CAN_PLATFORM=m
> CONFIG_CAN_C_CAN_PCI=m
> CONFIG_CAN_CC770=m
> CONFIG_CAN_CC770_ISA=m
> CONFIG_CAN_CC770_PLATFORM=m
> CONFIG_CAN_CTUCANFD=m
> CONFIG_CAN_CTUCANFD_PCI=m
> CONFIG_CAN_IFI_CANFD=m
> CONFIG_CAN_M_CAN=m
> CONFIG_CAN_M_CAN_PCI=m
> CONFIG_CAN_M_CAN_PLATFORM=m
> CONFIG_CAN_M_CAN_TCAN4X5X=m
> CONFIG_CAN_PEAK_PCIEFD=m
> CONFIG_CAN_SJA1000=m
> CONFIG_CAN_EMS_PCI=m
> CONFIG_CAN_EMS_PCMCIA=m
> CONFIG_CAN_F81601=m
> CONFIG_CAN_KVASER_PCI=m
> CONFIG_CAN_PEAK_PCI=m
> CONFIG_CAN_PEAK_PCIEC=y
> CONFIG_CAN_PEAK_PCMCIA=m
> CONFIG_CAN_PLX_PCI=m
> CONFIG_CAN_SJA1000_ISA=m
> CONFIG_CAN_SJA1000_PLATFORM=m
> CONFIG_CAN_SOFTING=m
> CONFIG_CAN_SOFTING_CS=m
>
> #
> # CAN SPI interfaces
> #
> CONFIG_CAN_HI311X=m
> CONFIG_CAN_MCP251X=m
> CONFIG_CAN_MCP251XFD=m
> # CONFIG_CAN_MCP251XFD_SANITY is not set
> # end of CAN SPI interfaces
>
> #
> # CAN USB interfaces
> #
> CONFIG_CAN_8DEV_USB=m
> CONFIG_CAN_EMS_USB=m
> CONFIG_CAN_ESD_USB=m
> CONFIG_CAN_ETAS_ES58X=m
> CONFIG_CAN_GS_USB=m
> CONFIG_CAN_KVASER_USB=m
> CONFIG_CAN_MCBA_USB=m
> CONFIG_CAN_PEAK_USB=m
> CONFIG_CAN_UCAN=m
> # end of CAN USB interfaces
>
> # CONFIG_CAN_DEBUG_DEVICES is not set
>
> #
> # MCTP Device Drivers
> #
> CONFIG_MCTP_SERIAL=m
> # end of MCTP Device Drivers
>
> CONFIG_MDIO_DEVICE=y
> CONFIG_MDIO_BUS=y
> CONFIG_FWNODE_MDIO=y
> CONFIG_ACPI_MDIO=y
> CONFIG_MDIO_DEVRES=y
> CONFIG_MDIO_BITBANG=m
> CONFIG_MDIO_BCM_UNIMAC=m
> CONFIG_MDIO_CAVIUM=m
> CONFIG_MDIO_GPIO=m
> CONFIG_MDIO_I2C=m
> CONFIG_MDIO_MVUSB=m
> CONFIG_MDIO_MSCC_MIIM=m
> CONFIG_MDIO_THUNDER=m
>
> #
> # MDIO Multiplexers
> #
>
> #
> # PCS device drivers
> #
> CONFIG_PCS_XPCS=m
> CONFIG_PCS_LYNX=m
> # end of PCS device drivers
>
> CONFIG_PLIP=m
> CONFIG_PPP=y
> CONFIG_PPP_BSDCOMP=m
> CONFIG_PPP_DEFLATE=m
> CONFIG_PPP_FILTER=y
> CONFIG_PPP_MPPE=m
> CONFIG_PPP_MULTILINK=y
> CONFIG_PPPOATM=m
> CONFIG_PPPOE=m
> CONFIG_PPTP=m
> CONFIG_PPPOL2TP=m
> CONFIG_PPP_ASYNC=m
> CONFIG_PPP_SYNC_TTY=m
> CONFIG_SLIP=m
> CONFIG_SLHC=y
> CONFIG_SLIP_COMPRESSED=y
> CONFIG_SLIP_SMART=y
> CONFIG_SLIP_MODE_SLIP6=y
> CONFIG_USB_NET_DRIVERS=m
> CONFIG_USB_CATC=m
> CONFIG_USB_KAWETH=m
> CONFIG_USB_PEGASUS=m
> CONFIG_USB_RTL8150=m
> CONFIG_USB_RTL8152=m
> CONFIG_USB_LAN78XX=m
> CONFIG_USB_USBNET=m
> CONFIG_USB_NET_AX8817X=m
> CONFIG_USB_NET_AX88179_178A=m
> CONFIG_USB_NET_CDCETHER=m
> CONFIG_USB_NET_CDC_EEM=m
> CONFIG_USB_NET_CDC_NCM=m
> CONFIG_USB_NET_HUAWEI_CDC_NCM=m
> CONFIG_USB_NET_CDC_MBIM=m
> CONFIG_USB_NET_DM9601=m
> CONFIG_USB_NET_SR9700=m
> CONFIG_USB_NET_SR9800=m
> CONFIG_USB_NET_SMSC75XX=m
> CONFIG_USB_NET_SMSC95XX=m
> CONFIG_USB_NET_GL620A=m
> CONFIG_USB_NET_NET1080=m
> CONFIG_USB_NET_PLUSB=m
> CONFIG_USB_NET_MCS7830=m
> CONFIG_USB_NET_RNDIS_HOST=m
> CONFIG_USB_NET_CDC_SUBSET_ENABLE=m
> CONFIG_USB_NET_CDC_SUBSET=m
> CONFIG_USB_ALI_M5632=y
> CONFIG_USB_AN2720=y
> CONFIG_USB_BELKIN=y
> CONFIG_USB_ARMLINUX=y
> CONFIG_USB_EPSON2888=y
> CONFIG_USB_KC2190=y
> CONFIG_USB_NET_ZAURUS=m
> CONFIG_USB_NET_CX82310_ETH=m
> CONFIG_USB_NET_KALMIA=m
> CONFIG_USB_NET_QMI_WWAN=m
> CONFIG_USB_HSO=m
> CONFIG_USB_NET_INT51X1=m
> CONFIG_USB_CDC_PHONET=m
> CONFIG_USB_IPHETH=m
> CONFIG_USB_SIERRA_NET=m
> CONFIG_USB_VL600=m
> CONFIG_USB_NET_CH9200=m
> CONFIG_USB_NET_AQC111=m
> CONFIG_USB_RTL8153_ECM=m
> CONFIG_WLAN=y
> CONFIG_WLAN_VENDOR_ADMTEK=y
> CONFIG_ADM8211=m
> CONFIG_ATH_COMMON=m
> CONFIG_WLAN_VENDOR_ATH=y
> # CONFIG_ATH_DEBUG is not set
> CONFIG_ATH5K=m
> # CONFIG_ATH5K_DEBUG is not set
> # CONFIG_ATH5K_TRACER is not set
> CONFIG_ATH5K_PCI=y
> CONFIG_ATH9K_HW=m
> CONFIG_ATH9K_COMMON=m
> CONFIG_ATH9K_COMMON_DEBUG=y
> CONFIG_ATH9K_BTCOEX_SUPPORT=y
> CONFIG_ATH9K=m
> CONFIG_ATH9K_PCI=y
> CONFIG_ATH9K_AHB=y
> CONFIG_ATH9K_DEBUGFS=y
> CONFIG_ATH9K_STATION_STATISTICS=y
> # CONFIG_ATH9K_DYNACK is not set
> CONFIG_ATH9K_WOW=y
> CONFIG_ATH9K_RFKILL=y
> CONFIG_ATH9K_CHANNEL_CONTEXT=y
> CONFIG_ATH9K_PCOEM=y
> CONFIG_ATH9K_PCI_NO_EEPROM=m
> CONFIG_ATH9K_HTC=m
> CONFIG_ATH9K_HTC_DEBUGFS=y
> CONFIG_ATH9K_HWRNG=y
> CONFIG_ATH9K_COMMON_SPECTRAL=y
> CONFIG_CARL9170=m
> CONFIG_CARL9170_LEDS=y
> # CONFIG_CARL9170_DEBUGFS is not set
> CONFIG_CARL9170_WPC=y
> CONFIG_CARL9170_HWRNG=y
> CONFIG_ATH6KL=m
> CONFIG_ATH6KL_SDIO=m
> CONFIG_ATH6KL_USB=m
> # CONFIG_ATH6KL_DEBUG is not set
> # CONFIG_ATH6KL_TRACING is not set
> CONFIG_AR5523=m
> CONFIG_WIL6210=m
> CONFIG_WIL6210_ISR_COR=y
> CONFIG_WIL6210_TRACING=y
> CONFIG_WIL6210_DEBUGFS=y
> CONFIG_ATH10K=m
> CONFIG_ATH10K_CE=y
> CONFIG_ATH10K_PCI=m
> CONFIG_ATH10K_SDIO=m
> CONFIG_ATH10K_USB=m
> # CONFIG_ATH10K_DEBUG is not set
> CONFIG_ATH10K_DEBUGFS=y
> CONFIG_ATH10K_SPECTRAL=y
> CONFIG_ATH10K_TRACING=y
> CONFIG_WCN36XX=m
> # CONFIG_WCN36XX_DEBUGFS is not set
> CONFIG_ATH11K=m
> CONFIG_ATH11K_AHB=m
> CONFIG_ATH11K_PCI=m
> # CONFIG_ATH11K_DEBUG is not set
> CONFIG_ATH11K_DEBUGFS=y
> CONFIG_ATH11K_TRACING=y
> CONFIG_ATH11K_SPECTRAL=y
> CONFIG_WLAN_VENDOR_ATMEL=y
> CONFIG_ATMEL=m
> CONFIG_PCI_ATMEL=m
> CONFIG_PCMCIA_ATMEL=m
> CONFIG_AT76C50X_USB=m
> CONFIG_WLAN_VENDOR_BROADCOM=y
> CONFIG_B43=m
> CONFIG_B43_BCMA=y
> CONFIG_B43_SSB=y
> CONFIG_B43_BUSES_BCMA_AND_SSB=y
> # CONFIG_B43_BUSES_BCMA is not set
> # CONFIG_B43_BUSES_SSB is not set
> CONFIG_B43_PCI_AUTOSELECT=y
> CONFIG_B43_PCICORE_AUTOSELECT=y
> # CONFIG_B43_SDIO is not set
> CONFIG_B43_BCMA_PIO=y
> CONFIG_B43_PIO=y
> CONFIG_B43_PHY_G=y
> CONFIG_B43_PHY_N=y
> CONFIG_B43_PHY_LP=y
> CONFIG_B43_PHY_HT=y
> CONFIG_B43_LEDS=y
> CONFIG_B43_HWRNG=y
> # CONFIG_B43_DEBUG is not set
> CONFIG_B43LEGACY=m
> CONFIG_B43LEGACY_PCI_AUTOSELECT=y
> CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y
> CONFIG_B43LEGACY_LEDS=y
> CONFIG_B43LEGACY_HWRNG=y
> # CONFIG_B43LEGACY_DEBUG is not set
> CONFIG_B43LEGACY_DMA=y
> CONFIG_B43LEGACY_PIO=y
> CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
> # CONFIG_B43LEGACY_DMA_MODE is not set
> # CONFIG_B43LEGACY_PIO_MODE is not set
> CONFIG_BRCMUTIL=m
> CONFIG_BRCMSMAC=m
> CONFIG_BRCMSMAC_LEDS=y
> CONFIG_BRCMFMAC=m
> CONFIG_BRCMFMAC_PROTO_BCDC=y
> CONFIG_BRCMFMAC_PROTO_MSGBUF=y
> CONFIG_BRCMFMAC_SDIO=y
> CONFIG_BRCMFMAC_USB=y
> CONFIG_BRCMFMAC_PCIE=y
> CONFIG_BRCM_TRACING=y
> # CONFIG_BRCMDBG is not set
> CONFIG_WLAN_VENDOR_CISCO=y
> CONFIG_AIRO=m
> CONFIG_AIRO_CS=m
> CONFIG_WLAN_VENDOR_INTEL=y
> CONFIG_IPW2100=m
> CONFIG_IPW2100_MONITOR=y
> # CONFIG_IPW2100_DEBUG is not set
> CONFIG_IPW2200=m
> CONFIG_IPW2200_MONITOR=y
> CONFIG_IPW2200_RADIOTAP=y
> CONFIG_IPW2200_PROMISCUOUS=y
> CONFIG_IPW2200_QOS=y
> # CONFIG_IPW2200_DEBUG is not set
> CONFIG_LIBIPW=m
> # CONFIG_LIBIPW_DEBUG is not set
> CONFIG_IWLEGACY=m
> CONFIG_IWL4965=m
> CONFIG_IWL3945=m
>
> #
> # iwl3945 / iwl4965 Debugging Options
> #
> # CONFIG_IWLEGACY_DEBUG is not set
> CONFIG_IWLEGACY_DEBUGFS=y
> # end of iwl3945 / iwl4965 Debugging Options
>
> CONFIG_IWLWIFI=m
> CONFIG_IWLWIFI_LEDS=y
> CONFIG_IWLDVM=m
> CONFIG_IWLMVM=m
> CONFIG_IWLWIFI_OPMODE_MODULAR=y
>
> #
> # Debugging Options
> #
> # CONFIG_IWLWIFI_DEBUG is not set
> CONFIG_IWLWIFI_DEBUGFS=y
> CONFIG_IWLWIFI_DEVICE_TRACING=y
> # end of Debugging Options
>
> CONFIG_IWLMEI=m
> CONFIG_WLAN_VENDOR_INTERSIL=y
> CONFIG_HOSTAP=m
> CONFIG_HOSTAP_FIRMWARE=y
> CONFIG_HOSTAP_FIRMWARE_NVRAM=y
> CONFIG_HOSTAP_PLX=m
> CONFIG_HOSTAP_PCI=m
> CONFIG_HOSTAP_CS=m
> CONFIG_HERMES=m
> # CONFIG_HERMES_PRISM is not set
> CONFIG_HERMES_CACHE_FW_ON_INIT=y
> CONFIG_PLX_HERMES=m
> CONFIG_TMD_HERMES=m
> CONFIG_NORTEL_HERMES=m
> CONFIG_PCMCIA_HERMES=m
> CONFIG_PCMCIA_SPECTRUM=m
> CONFIG_ORINOCO_USB=m
> CONFIG_P54_COMMON=m
> CONFIG_P54_USB=m
> CONFIG_P54_PCI=m
> CONFIG_P54_SPI=m
> # CONFIG_P54_SPI_DEFAULT_EEPROM is not set
> CONFIG_P54_LEDS=y
> CONFIG_WLAN_VENDOR_MARVELL=y
> CONFIG_LIBERTAS=m
> CONFIG_LIBERTAS_USB=m
> CONFIG_LIBERTAS_CS=m
> CONFIG_LIBERTAS_SDIO=m
> CONFIG_LIBERTAS_SPI=m
> # CONFIG_LIBERTAS_DEBUG is not set
> CONFIG_LIBERTAS_MESH=y
> CONFIG_LIBERTAS_THINFIRM=m
> # CONFIG_LIBERTAS_THINFIRM_DEBUG is not set
> CONFIG_LIBERTAS_THINFIRM_USB=m
> CONFIG_MWIFIEX=m
> CONFIG_MWIFIEX_SDIO=m
> CONFIG_MWIFIEX_PCIE=m
> CONFIG_MWIFIEX_USB=m
> CONFIG_MWL8K=m
> CONFIG_WLAN_VENDOR_MEDIATEK=y
> CONFIG_MT7601U=m
> CONFIG_MT76_CORE=m
> CONFIG_MT76_LEDS=y
> CONFIG_MT76_USB=m
> CONFIG_MT76_SDIO=m
> CONFIG_MT76x02_LIB=m
> CONFIG_MT76x02_USB=m
> CONFIG_MT76_CONNAC_LIB=m
> CONFIG_MT76x0_COMMON=m
> CONFIG_MT76x0U=m
> CONFIG_MT76x0E=m
> CONFIG_MT76x2_COMMON=m
> CONFIG_MT76x2E=m
> CONFIG_MT76x2U=m
> CONFIG_MT7603E=m
> CONFIG_MT7615_COMMON=m
> CONFIG_MT7615E=m
> CONFIG_MT7663_USB_SDIO_COMMON=m
> CONFIG_MT7663U=m
> CONFIG_MT7663S=m
> CONFIG_MT7915E=m
> CONFIG_MT7921_COMMON=m
> CONFIG_MT7921E=m
> CONFIG_MT7921S=m
> CONFIG_MT7921U=m
> CONFIG_WLAN_VENDOR_MICROCHIP=y
> CONFIG_WILC1000=m
> CONFIG_WILC1000_SDIO=m
> CONFIG_WILC1000_SPI=m
> CONFIG_WILC1000_HW_OOB_INTR=y
> CONFIG_WLAN_VENDOR_PURELIFI=y
> CONFIG_PLFXLC=m
> CONFIG_WLAN_VENDOR_RALINK=y
> CONFIG_RT2X00=m
> CONFIG_RT2400PCI=m
> CONFIG_RT2500PCI=m
> CONFIG_RT61PCI=m
> CONFIG_RT2800PCI=m
> CONFIG_RT2800PCI_RT33XX=y
> CONFIG_RT2800PCI_RT35XX=y
> CONFIG_RT2800PCI_RT53XX=y
> CONFIG_RT2800PCI_RT3290=y
> CONFIG_RT2500USB=m
> CONFIG_RT73USB=m
> CONFIG_RT2800USB=m
> CONFIG_RT2800USB_RT33XX=y
> CONFIG_RT2800USB_RT35XX=y
> CONFIG_RT2800USB_RT3573=y
> CONFIG_RT2800USB_RT53XX=y
> CONFIG_RT2800USB_RT55XX=y
> CONFIG_RT2800USB_UNKNOWN=y
> CONFIG_RT2800_LIB=m
> CONFIG_RT2800_LIB_MMIO=m
> CONFIG_RT2X00_LIB_MMIO=m
> CONFIG_RT2X00_LIB_PCI=m
> CONFIG_RT2X00_LIB_USB=m
> CONFIG_RT2X00_LIB=m
> CONFIG_RT2X00_LIB_FIRMWARE=y
> CONFIG_RT2X00_LIB_CRYPTO=y
> CONFIG_RT2X00_LIB_LEDS=y
> # CONFIG_RT2X00_LIB_DEBUGFS is not set
> # CONFIG_RT2X00_DEBUG is not set
> CONFIG_WLAN_VENDOR_REALTEK=y
> CONFIG_RTL8180=m
> CONFIG_RTL8187=m
> CONFIG_RTL8187_LEDS=y
> CONFIG_RTL_CARDS=m
> CONFIG_RTL8192CE=m
> CONFIG_RTL8192SE=m
> CONFIG_RTL8192DE=m
> CONFIG_RTL8723AE=m
> CONFIG_RTL8723BE=m
> CONFIG_RTL8188EE=m
> CONFIG_RTL8192EE=m
> CONFIG_RTL8821AE=m
> CONFIG_RTL8192CU=m
> CONFIG_RTLWIFI=m
> CONFIG_RTLWIFI_PCI=m
> CONFIG_RTLWIFI_USB=m
> # CONFIG_RTLWIFI_DEBUG is not set
> CONFIG_RTL8192C_COMMON=m
> CONFIG_RTL8723_COMMON=m
> CONFIG_RTLBTCOEXIST=m
> CONFIG_RTL8XXXU=m
> CONFIG_RTL8XXXU_UNTESTED=y
> CONFIG_RTW88=m
> CONFIG_RTW88_CORE=m
> CONFIG_RTW88_PCI=m
> CONFIG_RTW88_8822B=m
> CONFIG_RTW88_8822C=m
> CONFIG_RTW88_8723D=m
> CONFIG_RTW88_8821C=m
> CONFIG_RTW88_8822BE=m
> CONFIG_RTW88_8822CE=m
> CONFIG_RTW88_8723DE=m
> CONFIG_RTW88_8821CE=m
> CONFIG_RTW88_DEBUG=y
> CONFIG_RTW88_DEBUGFS=y
> CONFIG_RTW89=m
> CONFIG_RTW89_CORE=m
> CONFIG_RTW89_PCI=m
> CONFIG_RTW89_8852A=m
> CONFIG_RTW89_8852C=m
> CONFIG_RTW89_8852AE=m
> CONFIG_RTW89_8852CE=m
> CONFIG_RTW89_DEBUG=y
> CONFIG_RTW89_DEBUGMSG=y
> CONFIG_RTW89_DEBUGFS=y
> CONFIG_WLAN_VENDOR_RSI=y
> CONFIG_RSI_91X=m
> # CONFIG_RSI_DEBUGFS is not set
> CONFIG_RSI_SDIO=m
> CONFIG_RSI_USB=m
> CONFIG_RSI_COEX=y
> CONFIG_WLAN_VENDOR_SILABS=y
> CONFIG_WFX=m
> CONFIG_WLAN_VENDOR_ST=y
> CONFIG_CW1200=m
> CONFIG_CW1200_WLAN_SDIO=m
> CONFIG_CW1200_WLAN_SPI=m
> CONFIG_WLAN_VENDOR_TI=y
> CONFIG_WL1251=m
> CONFIG_WL1251_SPI=m
> CONFIG_WL1251_SDIO=m
> CONFIG_WL12XX=m
> CONFIG_WL18XX=m
> CONFIG_WLCORE=m
> CONFIG_WLCORE_SDIO=m
> CONFIG_WILINK_PLATFORM_DATA=y
> CONFIG_WLAN_VENDOR_ZYDAS=y
> CONFIG_USB_ZD1201=m
> CONFIG_ZD1211RW=m
> # CONFIG_ZD1211RW_DEBUG is not set
> CONFIG_WLAN_VENDOR_QUANTENNA=y
> CONFIG_QTNFMAC=m
> CONFIG_QTNFMAC_PCIE=m
> CONFIG_PCMCIA_RAYCS=m
> CONFIG_PCMCIA_WL3501=m
> CONFIG_MAC80211_HWSIM=m
> CONFIG_USB_NET_RNDIS_WLAN=m
> CONFIG_VIRT_WIFI=m
> CONFIG_WAN=y
> CONFIG_HDLC=m
> CONFIG_HDLC_RAW=m
> CONFIG_HDLC_RAW_ETH=m
> CONFIG_HDLC_CISCO=m
> CONFIG_HDLC_FR=m
> CONFIG_HDLC_PPP=m
> CONFIG_HDLC_X25=m
> CONFIG_PCI200SYN=m
> CONFIG_WANXL=m
> CONFIG_PC300TOO=m
> CONFIG_FARSYNC=m
> CONFIG_LAPBETHER=m
> CONFIG_IEEE802154_DRIVERS=m
> CONFIG_IEEE802154_FAKELB=m
> CONFIG_IEEE802154_AT86RF230=m
> CONFIG_IEEE802154_MRF24J40=m
> CONFIG_IEEE802154_CC2520=m
> CONFIG_IEEE802154_ATUSB=m
> CONFIG_IEEE802154_ADF7242=m
> CONFIG_IEEE802154_CA8210=m
> CONFIG_IEEE802154_CA8210_DEBUGFS=y
> CONFIG_IEEE802154_MCR20A=m
> CONFIG_IEEE802154_HWSIM=m
>
> #
> # Wireless WAN
> #
> CONFIG_WWAN=y
> CONFIG_WWAN_DEBUGFS=y
> CONFIG_WWAN_HWSIM=m
> CONFIG_MHI_WWAN_CTRL=m
> CONFIG_MHI_WWAN_MBIM=m
> CONFIG_RPMSG_WWAN_CTRL=m
> CONFIG_IOSM=m
> CONFIG_MTK_T7XX=m
> # end of Wireless WAN
>
> CONFIG_XEN_NETDEV_FRONTEND=y
> CONFIG_XEN_NETDEV_BACKEND=m
> CONFIG_VMXNET3=m
> CONFIG_FUJITSU_ES=m
> CONFIG_USB4_NET=m
> CONFIG_HYPERV_NET=m
> CONFIG_NETDEVSIM=m
> CONFIG_NET_FAILOVER=m
> CONFIG_ISDN=y
> CONFIG_ISDN_CAPI=y
> CONFIG_CAPI_TRACE=y
> CONFIG_ISDN_CAPI_MIDDLEWARE=y
> CONFIG_MISDN=m
> CONFIG_MISDN_DSP=m
> CONFIG_MISDN_L1OIP=m
>
> #
> # mISDN hardware drivers
> #
> CONFIG_MISDN_HFCPCI=m
> CONFIG_MISDN_HFCMULTI=m
> CONFIG_MISDN_HFCUSB=m
> CONFIG_MISDN_AVMFRITZ=m
> CONFIG_MISDN_SPEEDFAX=m
> CONFIG_MISDN_INFINEON=m
> CONFIG_MISDN_W6692=m
> CONFIG_MISDN_NETJET=m
> CONFIG_MISDN_HDLC=m
> CONFIG_MISDN_IPAC=m
> CONFIG_MISDN_ISAR=m
>
> #
> # Input device support
> #
> CONFIG_INPUT=y
> CONFIG_INPUT_LEDS=m
> CONFIG_INPUT_FF_MEMLESS=m
> CONFIG_INPUT_SPARSEKMAP=m
> CONFIG_INPUT_MATRIXKMAP=m
> CONFIG_INPUT_VIVALDIFMAP=y
>
> #
> # Userland interfaces
> #
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> CONFIG_INPUT_JOYDEV=m
> CONFIG_INPUT_EVDEV=y
> CONFIG_INPUT_EVBUG=m
>
> #
> # Input Device Drivers
> #
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ADC=m
> CONFIG_KEYBOARD_ADP5520=m
> CONFIG_KEYBOARD_ADP5588=m
> CONFIG_KEYBOARD_ADP5589=m
> CONFIG_KEYBOARD_APPLESPI=m
> CONFIG_KEYBOARD_ATKBD=y
> CONFIG_KEYBOARD_QT1050=m
> CONFIG_KEYBOARD_QT1070=m
> CONFIG_KEYBOARD_QT2160=m
> CONFIG_KEYBOARD_DLINK_DIR685=m
> CONFIG_KEYBOARD_LKKBD=m
> CONFIG_KEYBOARD_GPIO=m
> CONFIG_KEYBOARD_GPIO_POLLED=m
> CONFIG_KEYBOARD_TCA6416=m
> CONFIG_KEYBOARD_TCA8418=m
> CONFIG_KEYBOARD_MATRIX=m
> CONFIG_KEYBOARD_LM8323=m
> CONFIG_KEYBOARD_LM8333=m
> CONFIG_KEYBOARD_MAX7359=m
> CONFIG_KEYBOARD_MCS=m
> CONFIG_KEYBOARD_MPR121=m
> CONFIG_KEYBOARD_NEWTON=m
> CONFIG_KEYBOARD_OPENCORES=m
> CONFIG_KEYBOARD_SAMSUNG=m
> CONFIG_KEYBOARD_STOWAWAY=m
> CONFIG_KEYBOARD_SUNKBD=m
> CONFIG_KEYBOARD_IQS62X=m
> CONFIG_KEYBOARD_TM2_TOUCHKEY=m
> CONFIG_KEYBOARD_TWL4030=m
> CONFIG_KEYBOARD_XTKBD=m
> CONFIG_KEYBOARD_CROS_EC=m
> CONFIG_KEYBOARD_MTK_PMIC=m
> CONFIG_KEYBOARD_CYPRESS_SF=m
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=m
> CONFIG_MOUSE_PS2_ALPS=y
> CONFIG_MOUSE_PS2_BYD=y
> CONFIG_MOUSE_PS2_LOGIPS2PP=y
> CONFIG_MOUSE_PS2_SYNAPTICS=y
> CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
> CONFIG_MOUSE_PS2_CYPRESS=y
> CONFIG_MOUSE_PS2_LIFEBOOK=y
> CONFIG_MOUSE_PS2_TRACKPOINT=y
> CONFIG_MOUSE_PS2_ELANTECH=y
> CONFIG_MOUSE_PS2_ELANTECH_SMBUS=y
> CONFIG_MOUSE_PS2_SENTELIC=y
> CONFIG_MOUSE_PS2_TOUCHKIT=y
> CONFIG_MOUSE_PS2_FOCALTECH=y
> CONFIG_MOUSE_PS2_VMMOUSE=y
> CONFIG_MOUSE_PS2_SMBUS=y
> CONFIG_MOUSE_SERIAL=m
> CONFIG_MOUSE_APPLETOUCH=m
> CONFIG_MOUSE_BCM5974=m
> CONFIG_MOUSE_CYAPA=m
> CONFIG_MOUSE_ELAN_I2C=m
> CONFIG_MOUSE_ELAN_I2C_I2C=y
> CONFIG_MOUSE_ELAN_I2C_SMBUS=y
> CONFIG_MOUSE_VSXXXAA=m
> CONFIG_MOUSE_GPIO=m
> CONFIG_MOUSE_SYNAPTICS_I2C=m
> CONFIG_MOUSE_SYNAPTICS_USB=m
> CONFIG_INPUT_JOYSTICK=y
> CONFIG_JOYSTICK_ANALOG=m
> CONFIG_JOYSTICK_A3D=m
> CONFIG_JOYSTICK_ADC=m
> CONFIG_JOYSTICK_ADI=m
> CONFIG_JOYSTICK_COBRA=m
> CONFIG_JOYSTICK_GF2K=m
> CONFIG_JOYSTICK_GRIP=m
> CONFIG_JOYSTICK_GRIP_MP=m
> CONFIG_JOYSTICK_GUILLEMOT=m
> CONFIG_JOYSTICK_INTERACT=m
> CONFIG_JOYSTICK_SIDEWINDER=m
> CONFIG_JOYSTICK_TMDC=m
> CONFIG_JOYSTICK_IFORCE=m
> CONFIG_JOYSTICK_IFORCE_USB=m
> CONFIG_JOYSTICK_IFORCE_232=m
> CONFIG_JOYSTICK_WARRIOR=m
> CONFIG_JOYSTICK_MAGELLAN=m
> CONFIG_JOYSTICK_SPACEORB=m
> CONFIG_JOYSTICK_SPACEBALL=m
> CONFIG_JOYSTICK_STINGER=m
> CONFIG_JOYSTICK_TWIDJOY=m
> CONFIG_JOYSTICK_ZHENHUA=m
> CONFIG_JOYSTICK_DB9=m
> CONFIG_JOYSTICK_GAMECON=m
> CONFIG_JOYSTICK_TURBOGRAFX=m
> CONFIG_JOYSTICK_AS5011=m
> CONFIG_JOYSTICK_JOYDUMP=m
> CONFIG_JOYSTICK_XPAD=m
> CONFIG_JOYSTICK_XPAD_FF=y
> CONFIG_JOYSTICK_XPAD_LEDS=y
> CONFIG_JOYSTICK_WALKERA0701=m
> CONFIG_JOYSTICK_PSXPAD_SPI=m
> CONFIG_JOYSTICK_PSXPAD_SPI_FF=y
> CONFIG_JOYSTICK_PXRC=m
> CONFIG_JOYSTICK_QWIIC=m
> CONFIG_JOYSTICK_FSIA6B=m
> CONFIG_JOYSTICK_SENSEHAT=m
> CONFIG_INPUT_TABLET=y
> CONFIG_TABLET_USB_ACECAD=m
> CONFIG_TABLET_USB_AIPTEK=m
> CONFIG_TABLET_USB_HANWANG=m
> CONFIG_TABLET_USB_KBTAB=m
> CONFIG_TABLET_USB_PEGASUS=m
> CONFIG_TABLET_SERIAL_WACOM4=m
> CONFIG_INPUT_TOUCHSCREEN=y
> CONFIG_TOUCHSCREEN_88PM860X=m
> CONFIG_TOUCHSCREEN_ADS7846=m
> CONFIG_TOUCHSCREEN_AD7877=m
> CONFIG_TOUCHSCREEN_AD7879=m
> CONFIG_TOUCHSCREEN_AD7879_I2C=m
> CONFIG_TOUCHSCREEN_AD7879_SPI=m
> CONFIG_TOUCHSCREEN_ADC=m
> CONFIG_TOUCHSCREEN_ATMEL_MXT=m
> CONFIG_TOUCHSCREEN_ATMEL_MXT_T37=y
> CONFIG_TOUCHSCREEN_AUO_PIXCIR=m
> CONFIG_TOUCHSCREEN_BU21013=m
> CONFIG_TOUCHSCREEN_BU21029=m
> CONFIG_TOUCHSCREEN_CHIPONE_ICN8505=m
> CONFIG_TOUCHSCREEN_CY8CTMA140=m
> CONFIG_TOUCHSCREEN_CY8CTMG110=m
> CONFIG_TOUCHSCREEN_CYTTSP_CORE=m
> CONFIG_TOUCHSCREEN_CYTTSP_I2C=m
> CONFIG_TOUCHSCREEN_CYTTSP_SPI=m
> CONFIG_TOUCHSCREEN_CYTTSP4_CORE=m
> CONFIG_TOUCHSCREEN_CYTTSP4_I2C=m
> CONFIG_TOUCHSCREEN_CYTTSP4_SPI=m
> CONFIG_TOUCHSCREEN_DA9034=m
> CONFIG_TOUCHSCREEN_DA9052=m
> CONFIG_TOUCHSCREEN_DYNAPRO=m
> CONFIG_TOUCHSCREEN_HAMPSHIRE=m
> CONFIG_TOUCHSCREEN_EETI=m
> CONFIG_TOUCHSCREEN_EGALAX_SERIAL=m
> CONFIG_TOUCHSCREEN_EXC3000=m
> CONFIG_TOUCHSCREEN_FUJITSU=m
> CONFIG_TOUCHSCREEN_GOODIX=m
> CONFIG_TOUCHSCREEN_HIDEEP=m
> CONFIG_TOUCHSCREEN_HYCON_HY46XX=m
> CONFIG_TOUCHSCREEN_ILI210X=m
> CONFIG_TOUCHSCREEN_ILITEK=m
> CONFIG_TOUCHSCREEN_S6SY761=m
> CONFIG_TOUCHSCREEN_GUNZE=m
> CONFIG_TOUCHSCREEN_EKTF2127=m
> CONFIG_TOUCHSCREEN_ELAN=y
> CONFIG_TOUCHSCREEN_ELO=m
> CONFIG_TOUCHSCREEN_WACOM_W8001=m
> CONFIG_TOUCHSCREEN_WACOM_I2C=m
> CONFIG_TOUCHSCREEN_MAX11801=m
> CONFIG_TOUCHSCREEN_MCS5000=m
> CONFIG_TOUCHSCREEN_MMS114=m
> CONFIG_TOUCHSCREEN_MELFAS_MIP4=m
> CONFIG_TOUCHSCREEN_MSG2638=m
> CONFIG_TOUCHSCREEN_MTOUCH=m
> CONFIG_TOUCHSCREEN_IMAGIS=m
> CONFIG_TOUCHSCREEN_INEXIO=m
> CONFIG_TOUCHSCREEN_MK712=m
> CONFIG_TOUCHSCREEN_PENMOUNT=m
> CONFIG_TOUCHSCREEN_EDT_FT5X06=m
> CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
> CONFIG_TOUCHSCREEN_TOUCHWIN=m
> CONFIG_TOUCHSCREEN_TI_AM335X_TSC=m
> CONFIG_TOUCHSCREEN_UCB1400=m
> CONFIG_TOUCHSCREEN_PIXCIR=m
> CONFIG_TOUCHSCREEN_WDT87XX_I2C=m
> CONFIG_TOUCHSCREEN_WM831X=m
> CONFIG_TOUCHSCREEN_WM97XX=m
> CONFIG_TOUCHSCREEN_WM9705=y
> CONFIG_TOUCHSCREEN_WM9712=y
> CONFIG_TOUCHSCREEN_WM9713=y
> CONFIG_TOUCHSCREEN_USB_COMPOSITE=m
> CONFIG_TOUCHSCREEN_MC13783=m
> CONFIG_TOUCHSCREEN_USB_EGALAX=y
> CONFIG_TOUCHSCREEN_USB_PANJIT=y
> CONFIG_TOUCHSCREEN_USB_3M=y
> CONFIG_TOUCHSCREEN_USB_ITM=y
> CONFIG_TOUCHSCREEN_USB_ETURBO=y
> CONFIG_TOUCHSCREEN_USB_GUNZE=y
> CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
> CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
> CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
> CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
> CONFIG_TOUCHSCREEN_USB_GOTOP=y
> CONFIG_TOUCHSCREEN_USB_JASTEC=y
> CONFIG_TOUCHSCREEN_USB_ELO=y
> CONFIG_TOUCHSCREEN_USB_E2I=y
> CONFIG_TOUCHSCREEN_USB_ZYTRONIC=y
> CONFIG_TOUCHSCREEN_USB_ETT_TC45USB=y
> CONFIG_TOUCHSCREEN_USB_NEXIO=y
> CONFIG_TOUCHSCREEN_USB_EASYTOUCH=y
> CONFIG_TOUCHSCREEN_TOUCHIT213=m
> CONFIG_TOUCHSCREEN_TSC_SERIO=m
> CONFIG_TOUCHSCREEN_TSC200X_CORE=m
> CONFIG_TOUCHSCREEN_TSC2004=m
> CONFIG_TOUCHSCREEN_TSC2005=m
> CONFIG_TOUCHSCREEN_TSC2007=m
> CONFIG_TOUCHSCREEN_TSC2007_IIO=y
> CONFIG_TOUCHSCREEN_PCAP=m
> CONFIG_TOUCHSCREEN_RM_TS=m
> CONFIG_TOUCHSCREEN_SILEAD=m
> CONFIG_TOUCHSCREEN_SIS_I2C=m
> CONFIG_TOUCHSCREEN_ST1232=m
> CONFIG_TOUCHSCREEN_STMFTS=m
> CONFIG_TOUCHSCREEN_SUR40=m
> CONFIG_TOUCHSCREEN_SURFACE3_SPI=m
> CONFIG_TOUCHSCREEN_SX8654=m
> CONFIG_TOUCHSCREEN_TPS6507X=m
> CONFIG_TOUCHSCREEN_ZET6223=m
> CONFIG_TOUCHSCREEN_ZFORCE=m
> CONFIG_TOUCHSCREEN_COLIBRI_VF50=m
> CONFIG_TOUCHSCREEN_ROHM_BU21023=m
> CONFIG_TOUCHSCREEN_IQS5XX=m
> CONFIG_TOUCHSCREEN_ZINITIX=m
> CONFIG_INPUT_MISC=y
> CONFIG_INPUT_88PM860X_ONKEY=m
> CONFIG_INPUT_88PM80X_ONKEY=m
> CONFIG_INPUT_AD714X=m
> CONFIG_INPUT_AD714X_I2C=m
> CONFIG_INPUT_AD714X_SPI=m
> CONFIG_INPUT_ARIZONA_HAPTICS=m
> CONFIG_INPUT_ATC260X_ONKEY=m
> CONFIG_INPUT_BMA150=m
> CONFIG_INPUT_E3X0_BUTTON=m
> CONFIG_INPUT_PCSPKR=m
> CONFIG_INPUT_MAX77693_HAPTIC=m
> CONFIG_INPUT_MAX8925_ONKEY=m
> CONFIG_INPUT_MAX8997_HAPTIC=m
> CONFIG_INPUT_MC13783_PWRBUTTON=m
> CONFIG_INPUT_MMA8450=m
> CONFIG_INPUT_APANEL=m
> CONFIG_INPUT_GPIO_BEEPER=m
> CONFIG_INPUT_GPIO_DECODER=m
> CONFIG_INPUT_GPIO_VIBRA=m
> CONFIG_INPUT_ATLAS_BTNS=m
> CONFIG_INPUT_ATI_REMOTE2=m
> CONFIG_INPUT_KEYSPAN_REMOTE=m
> CONFIG_INPUT_KXTJ9=m
> CONFIG_INPUT_POWERMATE=m
> CONFIG_INPUT_YEALINK=m
> CONFIG_INPUT_CM109=m
> CONFIG_INPUT_REGULATOR_HAPTIC=m
> CONFIG_INPUT_RETU_PWRBUTTON=m
> CONFIG_INPUT_AXP20X_PEK=m
> CONFIG_INPUT_TWL4030_PWRBUTTON=m
> CONFIG_INPUT_TWL4030_VIBRA=m
> CONFIG_INPUT_TWL6040_VIBRA=m
> CONFIG_INPUT_UINPUT=y
> CONFIG_INPUT_PALMAS_PWRBUTTON=m
> CONFIG_INPUT_PCF50633_PMU=m
> CONFIG_INPUT_PCF8574=m
> CONFIG_INPUT_PWM_BEEPER=m
> CONFIG_INPUT_PWM_VIBRA=m
> CONFIG_INPUT_GPIO_ROTARY_ENCODER=m
> CONFIG_INPUT_DA7280_HAPTICS=m
> CONFIG_INPUT_DA9052_ONKEY=m
> CONFIG_INPUT_DA9055_ONKEY=m
> CONFIG_INPUT_DA9063_ONKEY=m
> CONFIG_INPUT_WM831X_ON=m
> CONFIG_INPUT_PCAP=m
> CONFIG_INPUT_ADXL34X=m
> CONFIG_INPUT_ADXL34X_I2C=m
> CONFIG_INPUT_ADXL34X_SPI=m
> CONFIG_INPUT_IMS_PCU=m
> CONFIG_INPUT_IQS269A=m
> CONFIG_INPUT_IQS626A=m
> CONFIG_INPUT_IQS7222=m
> CONFIG_INPUT_CMA3000=m
> CONFIG_INPUT_CMA3000_I2C=m
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
> CONFIG_INPUT_IDEAPAD_SLIDEBAR=m
> CONFIG_INPUT_SOC_BUTTON_ARRAY=m
> CONFIG_INPUT_DRV260X_HAPTICS=m
> CONFIG_INPUT_DRV2665_HAPTICS=m
> CONFIG_INPUT_DRV2667_HAPTICS=m
> CONFIG_INPUT_RAVE_SP_PWRBUTTON=m
> CONFIG_RMI4_CORE=m
> CONFIG_RMI4_I2C=m
> CONFIG_RMI4_SPI=m
> CONFIG_RMI4_SMB=m
> CONFIG_RMI4_F03=y
> CONFIG_RMI4_F03_SERIO=m
> CONFIG_RMI4_2D_SENSOR=y
> CONFIG_RMI4_F11=y
> CONFIG_RMI4_F12=y
> CONFIG_RMI4_F30=y
> CONFIG_RMI4_F34=y
> CONFIG_RMI4_F3A=y
> CONFIG_RMI4_F54=y
> CONFIG_RMI4_F55=y
>
> #
> # Hardware I/O ports
> #
> CONFIG_SERIO=y
> CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
> CONFIG_SERIO_I8042=y
> CONFIG_SERIO_SERPORT=m
> CONFIG_SERIO_CT82C710=m
> CONFIG_SERIO_PARKBD=m
> CONFIG_SERIO_PCIPS2=m
> CONFIG_SERIO_LIBPS2=y
> CONFIG_SERIO_RAW=m
> CONFIG_SERIO_ALTERA_PS2=m
> CONFIG_SERIO_PS2MULT=m
> CONFIG_SERIO_ARC_PS2=m
> CONFIG_HYPERV_KEYBOARD=m
> CONFIG_SERIO_GPIO_PS2=m
> CONFIG_USERIO=m
> CONFIG_GAMEPORT=m
> CONFIG_GAMEPORT_NS558=m
> CONFIG_GAMEPORT_L4=m
> CONFIG_GAMEPORT_EMU10K1=m
> CONFIG_GAMEPORT_FM801=m
> # end of Hardware I/O ports
> # end of Input device support
>
> #
> # Character devices
> #
> CONFIG_TTY=y
> CONFIG_VT=y
> CONFIG_CONSOLE_TRANSLATIONS=y
> CONFIG_VT_CONSOLE=y
> CONFIG_VT_CONSOLE_SLEEP=y
> CONFIG_HW_CONSOLE=y
> CONFIG_VT_HW_CONSOLE_BINDING=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_LEGACY_PTYS=y
> CONFIG_LEGACY_PTY_COUNT=0
> CONFIG_LDISC_AUTOLOAD=y
>
> #
> # Serial drivers
> #
> CONFIG_SERIAL_EARLYCON=y
> CONFIG_SERIAL_8250=y
> # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
> CONFIG_SERIAL_8250_PNP=y
> CONFIG_SERIAL_8250_16550A_VARIANTS=y
> CONFIG_SERIAL_8250_FINTEK=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_DMA=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_EXAR=m
> CONFIG_SERIAL_8250_CS=m
> CONFIG_SERIAL_8250_MEN_MCB=m
> CONFIG_SERIAL_8250_NR_UARTS=48
> CONFIG_SERIAL_8250_RUNTIME_UARTS=32
> CONFIG_SERIAL_8250_EXTENDED=y
> CONFIG_SERIAL_8250_MANY_PORTS=y
> CONFIG_SERIAL_8250_SHARE_IRQ=y
> # CONFIG_SERIAL_8250_DETECT_IRQ is not set
> CONFIG_SERIAL_8250_RSA=y
> CONFIG_SERIAL_8250_DWLIB=y
> CONFIG_SERIAL_8250_DW=m
> CONFIG_SERIAL_8250_RT288X=y
> CONFIG_SERIAL_8250_LPSS=m
> CONFIG_SERIAL_8250_MID=m
> CONFIG_SERIAL_8250_PERICOM=m
>
> #
> # Non-8250 serial port support
> #
> CONFIG_SERIAL_KGDB_NMI=y
> CONFIG_SERIAL_MAX3100=m
> CONFIG_SERIAL_MAX310X=y
> CONFIG_SERIAL_UARTLITE=m
> CONFIG_SERIAL_UARTLITE_NR_UARTS=1
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_CONSOLE_POLL=y
> CONFIG_SERIAL_JSM=m
> CONFIG_SERIAL_LANTIQ=m
> CONFIG_SERIAL_SCCNXP=y
> CONFIG_SERIAL_SCCNXP_CONSOLE=y
> CONFIG_SERIAL_SC16IS7XX_CORE=m
> CONFIG_SERIAL_SC16IS7XX=m
> CONFIG_SERIAL_SC16IS7XX_I2C=y
> CONFIG_SERIAL_SC16IS7XX_SPI=y
> CONFIG_SERIAL_ALTERA_JTAGUART=m
> CONFIG_SERIAL_ALTERA_UART=m
> CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4
> CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200
> CONFIG_SERIAL_ARC=m
> CONFIG_SERIAL_ARC_NR_PORTS=1
> CONFIG_SERIAL_RP2=m
> CONFIG_SERIAL_RP2_NR_UARTS=32
> CONFIG_SERIAL_FSL_LPUART=m
> CONFIG_SERIAL_FSL_LINFLEXUART=m
> CONFIG_SERIAL_MEN_Z135=m
> CONFIG_SERIAL_SPRD=m
> # end of Serial drivers
>
> CONFIG_SERIAL_MCTRL_GPIO=y
> CONFIG_SERIAL_NONSTANDARD=y
> CONFIG_MOXA_INTELLIO=m
> CONFIG_MOXA_SMARTIO=m
> CONFIG_SYNCLINK_GT=m
> CONFIG_N_HDLC=m
> CONFIG_N_GSM=m
> CONFIG_NOZOMI=m
> CONFIG_NULL_TTY=m
> CONFIG_HVC_DRIVER=y
> CONFIG_HVC_IRQ=y
> CONFIG_HVC_XEN=y
> CONFIG_HVC_XEN_FRONTEND=y
> CONFIG_RPMSG_TTY=m
> CONFIG_SERIAL_DEV_BUS=y
> CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
> CONFIG_TTY_PRINTK=y
> CONFIG_TTY_PRINTK_LEVEL=6
> CONFIG_PRINTER=m
> # CONFIG_LP_CONSOLE is not set
> CONFIG_PPDEV=m
> CONFIG_VIRTIO_CONSOLE=y
> CONFIG_IPMI_HANDLER=m
> CONFIG_IPMI_DMI_DECODE=y
> CONFIG_IPMI_PLAT_DATA=y
> # CONFIG_IPMI_PANIC_EVENT is not set
> CONFIG_IPMI_DEVICE_INTERFACE=m
> CONFIG_IPMI_SI=m
> CONFIG_IPMI_SSIF=m
> CONFIG_IPMI_WATCHDOG=m
> CONFIG_IPMI_POWEROFF=m
> CONFIG_HW_RANDOM=y
> CONFIG_HW_RANDOM_TIMERIOMEM=m
> CONFIG_HW_RANDOM_INTEL=m
> CONFIG_HW_RANDOM_AMD=m
> CONFIG_HW_RANDOM_BA431=m
> CONFIG_HW_RANDOM_VIA=m
> CONFIG_HW_RANDOM_VIRTIO=m
> CONFIG_HW_RANDOM_XIPHERA=m
> CONFIG_APPLICOM=m
>
> #
> # PCMCIA character devices
> #
> CONFIG_SYNCLINK_CS=m
> CONFIG_CARDMAN_4000=m
> CONFIG_CARDMAN_4040=m
> CONFIG_SCR24X=m
> CONFIG_IPWIRELESS=m
> # end of PCMCIA character devices
>
> CONFIG_MWAVE=m
> CONFIG_DEVMEM=y
> CONFIG_NVRAM=m
> CONFIG_DEVPORT=y
> CONFIG_HPET=y
> CONFIG_HPET_MMAP=y
> CONFIG_HPET_MMAP_DEFAULT=y
> CONFIG_HANGCHECK_TIMER=m
> CONFIG_UV_MMTIMER=m
> CONFIG_TCG_TPM=y
> CONFIG_HW_RANDOM_TPM=y
> CONFIG_TCG_TIS_CORE=y
> CONFIG_TCG_TIS=y
> CONFIG_TCG_TIS_SPI=m
> CONFIG_TCG_TIS_SPI_CR50=y
> CONFIG_TCG_TIS_I2C=m
> CONFIG_TCG_TIS_I2C_CR50=m
> CONFIG_TCG_TIS_I2C_ATMEL=m
> CONFIG_TCG_TIS_I2C_INFINEON=m
> CONFIG_TCG_TIS_I2C_NUVOTON=m
> CONFIG_TCG_NSC=m
> CONFIG_TCG_ATMEL=m
> CONFIG_TCG_INFINEON=m
> CONFIG_TCG_XEN=m
> CONFIG_TCG_CRB=y
> CONFIG_TCG_VTPM_PROXY=m
> CONFIG_TCG_TIS_ST33ZP24=m
> CONFIG_TCG_TIS_ST33ZP24_I2C=m
> CONFIG_TCG_TIS_ST33ZP24_SPI=m
> CONFIG_TELCLOCK=m
> CONFIG_XILLYBUS_CLASS=m
> CONFIG_XILLYBUS=m
> CONFIG_XILLYBUS_PCIE=m
> CONFIG_XILLYUSB=m
> CONFIG_RANDOM_TRUST_CPU=y
> CONFIG_RANDOM_TRUST_BOOTLOADER=y
> # end of Character devices
>
> #
> # I2C support
> #
> CONFIG_I2C=y
> CONFIG_ACPI_I2C_OPREGION=y
> CONFIG_I2C_BOARDINFO=y
> CONFIG_I2C_COMPAT=y
> CONFIG_I2C_CHARDEV=y
> CONFIG_I2C_MUX=m
>
> #
> # Multiplexer I2C Chip support
> #
> CONFIG_I2C_MUX_GPIO=m
> CONFIG_I2C_MUX_LTC4306=m
> CONFIG_I2C_MUX_PCA9541=m
> CONFIG_I2C_MUX_PCA954x=m
> CONFIG_I2C_MUX_REG=m
> CONFIG_I2C_MUX_MLXCPLD=m
> # end of Multiplexer I2C Chip support
>
> CONFIG_I2C_HELPER_AUTO=y
> CONFIG_I2C_SMBUS=m
> CONFIG_I2C_ALGOBIT=m
> CONFIG_I2C_ALGOPCA=m
>
> #
> # I2C Hardware Bus support
> #
>
> #
> # PC SMBus host controller drivers
> #
> CONFIG_I2C_CCGX_UCSI=m
> CONFIG_I2C_ALI1535=m
> CONFIG_I2C_ALI1563=m
> CONFIG_I2C_ALI15X3=m
> CONFIG_I2C_AMD756=m
> CONFIG_I2C_AMD756_S4882=m
> CONFIG_I2C_AMD8111=m
> CONFIG_I2C_AMD_MP2=m
> CONFIG_I2C_I801=m
> CONFIG_I2C_ISCH=m
> CONFIG_I2C_ISMT=m
> CONFIG_I2C_PIIX4=m
> CONFIG_I2C_CHT_WC=m
> CONFIG_I2C_NFORCE2=m
> CONFIG_I2C_NFORCE2_S4985=m
> CONFIG_I2C_NVIDIA_GPU=m
> CONFIG_I2C_SIS5595=m
> CONFIG_I2C_SIS630=m
> CONFIG_I2C_SIS96X=m
> CONFIG_I2C_VIA=m
> CONFIG_I2C_VIAPRO=m
>
> #
> # ACPI drivers
> #
> CONFIG_I2C_SCMI=m
>
> #
> # I2C system bus drivers (mostly embedded / system-on-chip)
> #
> CONFIG_I2C_CBUS_GPIO=m
> CONFIG_I2C_DESIGNWARE_CORE=y
> # CONFIG_I2C_DESIGNWARE_SLAVE is not set
> CONFIG_I2C_DESIGNWARE_PLATFORM=y
> CONFIG_I2C_DESIGNWARE_AMDPSP=y
> CONFIG_I2C_DESIGNWARE_BAYTRAIL=y
> CONFIG_I2C_DESIGNWARE_PCI=m
> # CONFIG_I2C_EMEV2 is not set
> CONFIG_I2C_GPIO=m
> # CONFIG_I2C_GPIO_FAULT_INJECTOR is not set
> CONFIG_I2C_KEMPLD=m
> CONFIG_I2C_OCORES=m
> CONFIG_I2C_PCA_PLATFORM=m
> CONFIG_I2C_SIMTEC=m
> CONFIG_I2C_XILINX=m
>
> #
> # External I2C/SMBus adapter drivers
> #
> CONFIG_I2C_DIOLAN_U2C=m
> CONFIG_I2C_DLN2=m
> CONFIG_I2C_CP2615=m
> CONFIG_I2C_PARPORT=m
> CONFIG_I2C_ROBOTFUZZ_OSIF=m
> CONFIG_I2C_TAOS_EVM=m
> CONFIG_I2C_TINY_USB=m
> CONFIG_I2C_VIPERBOARD=m
>
> #
> # Other I2C/SMBus bus drivers
> #
> CONFIG_I2C_MLXCPLD=m
> CONFIG_I2C_CROS_EC_TUNNEL=m
> CONFIG_I2C_VIRTIO=m
> # end of I2C Hardware Bus support
>
> CONFIG_I2C_STUB=m
> # CONFIG_I2C_SLAVE is not set
> # CONFIG_I2C_DEBUG_CORE is not set
> # CONFIG_I2C_DEBUG_ALGO is not set
> # CONFIG_I2C_DEBUG_BUS is not set
> # end of I2C support
>
> CONFIG_I3C=m
> CONFIG_CDNS_I3C_MASTER=m
> CONFIG_DW_I3C_MASTER=m
> CONFIG_SVC_I3C_MASTER=m
> CONFIG_MIPI_I3C_HCI=m
> CONFIG_SPI=y
> # CONFIG_SPI_DEBUG is not set
> CONFIG_SPI_MASTER=y
> CONFIG_SPI_MEM=y
>
> #
> # SPI Master Controller Drivers
> #
> CONFIG_SPI_ALTERA=m
> CONFIG_SPI_ALTERA_CORE=m
> CONFIG_SPI_ALTERA_DFL=m
> CONFIG_SPI_AXI_SPI_ENGINE=m
> CONFIG_SPI_BITBANG=m
> CONFIG_SPI_BUTTERFLY=m
> CONFIG_SPI_CADENCE=m
> CONFIG_SPI_DESIGNWARE=m
> CONFIG_SPI_DW_DMA=y
> CONFIG_SPI_DW_PCI=m
> CONFIG_SPI_DW_MMIO=m
> CONFIG_SPI_DLN2=m
> CONFIG_SPI_NXP_FLEXSPI=m
> CONFIG_SPI_GPIO=m
> CONFIG_SPI_INTEL=m
> CONFIG_SPI_INTEL_PCI=m
> CONFIG_SPI_INTEL_PLATFORM=m
> CONFIG_SPI_LM70_LLP=m
> CONFIG_SPI_MICROCHIP_CORE=m
> CONFIG_SPI_LANTIQ_SSC=m
> CONFIG_SPI_OC_TINY=m
> CONFIG_SPI_PXA2XX=m
> CONFIG_SPI_PXA2XX_PCI=m
> CONFIG_SPI_ROCKCHIP=m
> CONFIG_SPI_SC18IS602=m
> CONFIG_SPI_SIFIVE=m
> CONFIG_SPI_MXIC=m
> CONFIG_SPI_XCOMM=m
> # CONFIG_SPI_XILINX is not set
> CONFIG_SPI_ZYNQMP_GQSPI=m
> CONFIG_SPI_AMD=m
>
> #
> # SPI Multiplexer support
> #
> CONFIG_SPI_MUX=m
>
> #
> # SPI Protocol Masters
> #
> CONFIG_SPI_SPIDEV=m
> CONFIG_SPI_LOOPBACK_TEST=m
> CONFIG_SPI_TLE62X0=m
> CONFIG_SPI_SLAVE=y
> CONFIG_SPI_SLAVE_TIME=m
> CONFIG_SPI_SLAVE_SYSTEM_CONTROL=m
> CONFIG_SPI_DYNAMIC=y
> CONFIG_SPMI=m
> CONFIG_SPMI_HISI3670=m
> CONFIG_HSI=m
> CONFIG_HSI_BOARDINFO=y
>
> #
> # HSI controllers
> #
>
> #
> # HSI clients
> #
> CONFIG_HSI_CHAR=m
> CONFIG_PPS=y
> # CONFIG_PPS_DEBUG is not set
>
> #
> # PPS clients support
> #
> # CONFIG_PPS_CLIENT_KTIMER is not set
> CONFIG_PPS_CLIENT_LDISC=m
> CONFIG_PPS_CLIENT_PARPORT=m
> CONFIG_PPS_CLIENT_GPIO=m
>
> #
> # PPS generators support
> #
>
> #
> # PTP clock support
> #
> CONFIG_PTP_1588_CLOCK=y
> CONFIG_PTP_1588_CLOCK_OPTIONAL=y
> CONFIG_DP83640_PHY=m
> CONFIG_PTP_1588_CLOCK_INES=m
> CONFIG_PTP_1588_CLOCK_KVM=m
> CONFIG_PTP_1588_CLOCK_IDT82P33=m
> CONFIG_PTP_1588_CLOCK_IDTCM=m
> CONFIG_PTP_1588_CLOCK_VMW=m
> CONFIG_PTP_1588_CLOCK_OCP=m
> # end of PTP clock support
>
> CONFIG_PINCTRL=y
> CONFIG_PINMUX=y
> CONFIG_PINCONF=y
> CONFIG_GENERIC_PINCONF=y
> # CONFIG_DEBUG_PINCTRL is not set
> CONFIG_PINCTRL_AMD=y
> CONFIG_PINCTRL_DA9062=m
> CONFIG_PINCTRL_MCP23S08_I2C=m
> CONFIG_PINCTRL_MCP23S08_SPI=m
> CONFIG_PINCTRL_MCP23S08=m
> CONFIG_PINCTRL_SX150X=y
> CONFIG_PINCTRL_MADERA=m
> CONFIG_PINCTRL_CS47L15=y
> CONFIG_PINCTRL_CS47L35=y
> CONFIG_PINCTRL_CS47L85=y
> CONFIG_PINCTRL_CS47L90=y
> CONFIG_PINCTRL_CS47L92=y
>
> #
> # Intel pinctrl drivers
> #
> CONFIG_PINCTRL_BAYTRAIL=y
> CONFIG_PINCTRL_CHERRYVIEW=y
> CONFIG_PINCTRL_LYNXPOINT=m
> CONFIG_PINCTRL_INTEL=y
> CONFIG_PINCTRL_ALDERLAKE=m
> CONFIG_PINCTRL_BROXTON=m
> CONFIG_PINCTRL_CANNONLAKE=m
> CONFIG_PINCTRL_CEDARFORK=m
> CONFIG_PINCTRL_DENVERTON=m
> CONFIG_PINCTRL_ELKHARTLAKE=m
> CONFIG_PINCTRL_EMMITSBURG=m
> CONFIG_PINCTRL_GEMINILAKE=m
> CONFIG_PINCTRL_ICELAKE=m
> CONFIG_PINCTRL_JASPERLAKE=m
> CONFIG_PINCTRL_LAKEFIELD=m
> CONFIG_PINCTRL_LEWISBURG=m
> CONFIG_PINCTRL_METEORLAKE=m
> CONFIG_PINCTRL_SUNRISEPOINT=m
> CONFIG_PINCTRL_TIGERLAKE=m
> # end of Intel pinctrl drivers
>
> #
> # Renesas pinctrl drivers
> #
> # end of Renesas pinctrl drivers
>
> CONFIG_GPIOLIB=y
> CONFIG_GPIOLIB_FASTPATH_LIMIT=512
> CONFIG_GPIO_ACPI=y
> CONFIG_GPIOLIB_IRQCHIP=y
> # CONFIG_DEBUG_GPIO is not set
> CONFIG_GPIO_SYSFS=y
> CONFIG_GPIO_CDEV=y
> CONFIG_GPIO_CDEV_V1=y
> CONFIG_GPIO_GENERIC=y
> CONFIG_GPIO_MAX730X=m
>
> #
> # Memory mapped GPIO drivers
> #
> CONFIG_GPIO_AMDPT=m
> CONFIG_GPIO_DWAPB=m
> CONFIG_GPIO_EXAR=m
> CONFIG_GPIO_GENERIC_PLATFORM=y
> CONFIG_GPIO_ICH=m
> CONFIG_GPIO_MB86S7X=m
> CONFIG_GPIO_MENZ127=m
> CONFIG_GPIO_SIOX=m
> CONFIG_GPIO_VX855=m
> CONFIG_GPIO_AMD_FCH=m
> # end of Memory mapped GPIO drivers
>
> #
> # Port-mapped I/O GPIO drivers
> #
> CONFIG_GPIO_I8255=m
> CONFIG_GPIO_104_DIO_48E=m
> CONFIG_GPIO_104_IDIO_16=m
> CONFIG_GPIO_104_IDI_48=m
> CONFIG_GPIO_F7188X=m
> CONFIG_GPIO_GPIO_MM=m
> CONFIG_GPIO_IT87=m
> CONFIG_GPIO_SCH=m
> CONFIG_GPIO_SCH311X=m
> CONFIG_GPIO_WINBOND=m
> CONFIG_GPIO_WS16C48=m
> # end of Port-mapped I/O GPIO drivers
>
> #
> # I2C GPIO expanders
> #
> CONFIG_GPIO_ADP5588=m
> CONFIG_GPIO_MAX7300=m
> CONFIG_GPIO_MAX732X=m
> CONFIG_GPIO_PCA953X=m
> CONFIG_GPIO_PCA953X_IRQ=y
> CONFIG_GPIO_PCA9570=m
> CONFIG_GPIO_PCF857X=m
> CONFIG_GPIO_TPIC2810=m
> # end of I2C GPIO expanders
>
> #
> # MFD GPIO expanders
> #
> CONFIG_GPIO_ADP5520=m
> CONFIG_GPIO_ARIZONA=m
> CONFIG_GPIO_BD9571MWV=m
> CONFIG_GPIO_CRYSTAL_COVE=y
> CONFIG_GPIO_DA9052=m
> CONFIG_GPIO_DA9055=m
> CONFIG_GPIO_DLN2=m
> CONFIG_GPIO_JANZ_TTL=m
> CONFIG_GPIO_KEMPLD=m
> CONFIG_GPIO_LP3943=m
> CONFIG_GPIO_LP873X=m
> CONFIG_GPIO_MADERA=m
> CONFIG_GPIO_PALMAS=y
> CONFIG_GPIO_RC5T583=y
> CONFIG_GPIO_TPS65086=m
> CONFIG_GPIO_TPS6586X=y
> CONFIG_GPIO_TPS65910=y
> CONFIG_GPIO_TPS65912=m
> CONFIG_GPIO_TPS68470=m
> CONFIG_GPIO_TQMX86=m
> CONFIG_GPIO_TWL4030=m
> CONFIG_GPIO_TWL6040=m
> CONFIG_GPIO_UCB1400=m
> CONFIG_GPIO_WHISKEY_COVE=m
> CONFIG_GPIO_WM831X=m
> CONFIG_GPIO_WM8350=m
> CONFIG_GPIO_WM8994=m
> # end of MFD GPIO expanders
>
> #
> # PCI GPIO expanders
> #
> CONFIG_GPIO_AMD8111=m
> CONFIG_GPIO_ML_IOH=m
> CONFIG_GPIO_PCI_IDIO_16=m
> CONFIG_GPIO_PCIE_IDIO_24=m
> CONFIG_GPIO_RDC321X=m
> # end of PCI GPIO expanders
>
> #
> # SPI GPIO expanders
> #
> CONFIG_GPIO_MAX3191X=m
> CONFIG_GPIO_MAX7301=m
> CONFIG_GPIO_MC33880=m
> CONFIG_GPIO_PISOSR=m
> CONFIG_GPIO_XRA1403=m
> # end of SPI GPIO expanders
>
> #
> # USB GPIO expanders
> #
> CONFIG_GPIO_VIPERBOARD=m
> # end of USB GPIO expanders
>
> #
> # Virtual GPIO drivers
> #
> CONFIG_GPIO_AGGREGATOR=m
> # CONFIG_GPIO_MOCKUP is not set
> CONFIG_GPIO_VIRTIO=m
> CONFIG_GPIO_SIM=m
> # end of Virtual GPIO drivers
>
> CONFIG_W1=m
> CONFIG_W1_CON=y
>
> #
> # 1-wire Bus Masters
> #
> CONFIG_W1_MASTER_MATROX=m
> CONFIG_W1_MASTER_DS2490=m
> CONFIG_W1_MASTER_DS2482=m
> CONFIG_W1_MASTER_DS1WM=m
> CONFIG_W1_MASTER_GPIO=m
> CONFIG_W1_MASTER_SGI=m
> # end of 1-wire Bus Masters
>
> #
> # 1-wire Slaves
> #
> CONFIG_W1_SLAVE_THERM=m
> CONFIG_W1_SLAVE_SMEM=m
> CONFIG_W1_SLAVE_DS2405=m
> CONFIG_W1_SLAVE_DS2408=m
> CONFIG_W1_SLAVE_DS2408_READBACK=y
> CONFIG_W1_SLAVE_DS2413=m
> CONFIG_W1_SLAVE_DS2406=m
> CONFIG_W1_SLAVE_DS2423=m
> CONFIG_W1_SLAVE_DS2805=m
> CONFIG_W1_SLAVE_DS2430=m
> CONFIG_W1_SLAVE_DS2431=m
> CONFIG_W1_SLAVE_DS2433=m
> # CONFIG_W1_SLAVE_DS2433_CRC is not set
> CONFIG_W1_SLAVE_DS2438=m
> CONFIG_W1_SLAVE_DS250X=m
> CONFIG_W1_SLAVE_DS2780=m
> CONFIG_W1_SLAVE_DS2781=m
> CONFIG_W1_SLAVE_DS28E04=m
> CONFIG_W1_SLAVE_DS28E17=m
> # end of 1-wire Slaves
>
> CONFIG_POWER_RESET=y
> CONFIG_POWER_RESET_ATC260X=m
> CONFIG_POWER_RESET_MT6323=y
> CONFIG_POWER_RESET_RESTART=y
> CONFIG_POWER_RESET_TPS65086=y
> CONFIG_POWER_SUPPLY=y
> # CONFIG_POWER_SUPPLY_DEBUG is not set
> CONFIG_POWER_SUPPLY_HWMON=y
> CONFIG_PDA_POWER=m
> CONFIG_GENERIC_ADC_BATTERY=m
> CONFIG_IP5XXX_POWER=m
> CONFIG_MAX8925_POWER=m
> CONFIG_WM831X_BACKUP=m
> CONFIG_WM831X_POWER=m
> CONFIG_WM8350_POWER=m
> CONFIG_TEST_POWER=m
> CONFIG_BATTERY_88PM860X=m
> CONFIG_CHARGER_ADP5061=m
> CONFIG_BATTERY_CW2015=m
> CONFIG_BATTERY_DS2760=m
> CONFIG_BATTERY_DS2780=m
> CONFIG_BATTERY_DS2781=m
> CONFIG_BATTERY_DS2782=m
> CONFIG_BATTERY_SAMSUNG_SDI=y
> CONFIG_BATTERY_SBS=m
> CONFIG_CHARGER_SBS=m
> CONFIG_MANAGER_SBS=m
> CONFIG_BATTERY_BQ27XXX=m
> CONFIG_BATTERY_BQ27XXX_I2C=m
> CONFIG_BATTERY_BQ27XXX_HDQ=m
> # CONFIG_BATTERY_BQ27XXX_DT_UPDATES_NVM is not set
> CONFIG_BATTERY_DA9030=m
> CONFIG_BATTERY_DA9052=m
> CONFIG_CHARGER_DA9150=m
> CONFIG_BATTERY_DA9150=m
> CONFIG_CHARGER_AXP20X=m
> CONFIG_BATTERY_AXP20X=m
> CONFIG_AXP20X_POWER=m
> CONFIG_AXP288_CHARGER=m
> CONFIG_AXP288_FUEL_GAUGE=m
> CONFIG_BATTERY_MAX17040=m
> CONFIG_BATTERY_MAX17042=m
> CONFIG_BATTERY_MAX1721X=m
> CONFIG_BATTERY_TWL4030_MADC=m
> CONFIG_CHARGER_88PM860X=m
> CONFIG_CHARGER_PCF50633=m
> CONFIG_BATTERY_RX51=m
> CONFIG_CHARGER_ISP1704=m
> CONFIG_CHARGER_MAX8903=m
> CONFIG_CHARGER_TWL4030=m
> CONFIG_CHARGER_LP8727=m
> CONFIG_CHARGER_LP8788=m
> CONFIG_CHARGER_GPIO=m
> CONFIG_CHARGER_MANAGER=y
> CONFIG_CHARGER_LT3651=m
> CONFIG_CHARGER_LTC4162L=m
> CONFIG_CHARGER_MAX14577=m
> CONFIG_CHARGER_MAX77693=m
> CONFIG_CHARGER_MAX77976=m
> CONFIG_CHARGER_MAX8997=m
> CONFIG_CHARGER_MAX8998=m
> CONFIG_CHARGER_MP2629=m
> CONFIG_CHARGER_MT6360=m
> CONFIG_CHARGER_BQ2415X=m
> CONFIG_CHARGER_BQ24190=m
> CONFIG_CHARGER_BQ24257=m
> CONFIG_CHARGER_BQ24735=m
> CONFIG_CHARGER_BQ2515X=m
> CONFIG_CHARGER_BQ25890=m
> CONFIG_CHARGER_BQ25980=m
> CONFIG_CHARGER_BQ256XX=m
> CONFIG_CHARGER_SMB347=m
> CONFIG_CHARGER_TPS65090=m
> CONFIG_BATTERY_GAUGE_LTC2941=m
> CONFIG_BATTERY_GOLDFISH=m
> CONFIG_BATTERY_RT5033=m
> CONFIG_CHARGER_RT9455=m
> CONFIG_CHARGER_CROS_USBPD=m
> CONFIG_CHARGER_CROS_PCHG=m
> CONFIG_CHARGER_BD99954=m
> CONFIG_CHARGER_WILCO=m
> CONFIG_BATTERY_SURFACE=m
> CONFIG_CHARGER_SURFACE=m
> CONFIG_BATTERY_UG3105=m
> CONFIG_HWMON=y
> CONFIG_HWMON_VID=m
> # CONFIG_HWMON_DEBUG_CHIP is not set
>
> #
> # Native drivers
> #
> CONFIG_SENSORS_ABITUGURU=m
> CONFIG_SENSORS_ABITUGURU3=m
> CONFIG_SENSORS_AD7314=m
> CONFIG_SENSORS_AD7414=m
> CONFIG_SENSORS_AD7418=m
> CONFIG_SENSORS_ADM1025=m
> CONFIG_SENSORS_ADM1026=m
> CONFIG_SENSORS_ADM1029=m
> CONFIG_SENSORS_ADM1031=m
> CONFIG_SENSORS_ADM1177=m
> CONFIG_SENSORS_ADM9240=m
> CONFIG_SENSORS_ADT7X10=m
> CONFIG_SENSORS_ADT7310=m
> CONFIG_SENSORS_ADT7410=m
> CONFIG_SENSORS_ADT7411=m
> CONFIG_SENSORS_ADT7462=m
> CONFIG_SENSORS_ADT7470=m
> CONFIG_SENSORS_ADT7475=m
> CONFIG_SENSORS_AHT10=m
> CONFIG_SENSORS_AQUACOMPUTER_D5NEXT=m
> CONFIG_SENSORS_AS370=m
> CONFIG_SENSORS_ASC7621=m
> CONFIG_SENSORS_AXI_FAN_CONTROL=m
> CONFIG_SENSORS_K8TEMP=m
> CONFIG_SENSORS_K10TEMP=m
> CONFIG_SENSORS_FAM15H_POWER=m
> CONFIG_SENSORS_APPLESMC=m
> CONFIG_SENSORS_ASB100=m
> CONFIG_SENSORS_ASPEED=m
> CONFIG_SENSORS_ATXP1=m
> CONFIG_SENSORS_CORSAIR_CPRO=m
> CONFIG_SENSORS_CORSAIR_PSU=m
> CONFIG_SENSORS_DRIVETEMP=m
> CONFIG_SENSORS_DS620=m
> CONFIG_SENSORS_DS1621=m
> CONFIG_SENSORS_DELL_SMM=m
> CONFIG_I8K=y
> CONFIG_SENSORS_DA9052_ADC=m
> CONFIG_SENSORS_DA9055=m
> CONFIG_SENSORS_I5K_AMB=m
> CONFIG_SENSORS_F71805F=m
> CONFIG_SENSORS_F71882FG=m
> CONFIG_SENSORS_F75375S=m
> CONFIG_SENSORS_MC13783_ADC=m
> CONFIG_SENSORS_FSCHMD=m
> CONFIG_SENSORS_FTSTEUTATES=m
> CONFIG_SENSORS_GL518SM=m
> CONFIG_SENSORS_GL520SM=m
> CONFIG_SENSORS_G760A=m
> CONFIG_SENSORS_G762=m
> CONFIG_SENSORS_HIH6130=m
> CONFIG_SENSORS_IBMAEM=m
> CONFIG_SENSORS_IBMPEX=m
> CONFIG_SENSORS_IIO_HWMON=m
> CONFIG_SENSORS_I5500=m
> CONFIG_SENSORS_CORETEMP=m
> CONFIG_SENSORS_IT87=m
> CONFIG_SENSORS_JC42=m
> CONFIG_SENSORS_POWR1220=m
> CONFIG_SENSORS_LINEAGE=m
> CONFIG_SENSORS_LTC2945=m
> CONFIG_SENSORS_LTC2947=m
> CONFIG_SENSORS_LTC2947_I2C=m
> CONFIG_SENSORS_LTC2947_SPI=m
> CONFIG_SENSORS_LTC2990=m
> CONFIG_SENSORS_LTC2992=m
> CONFIG_SENSORS_LTC4151=m
> CONFIG_SENSORS_LTC4215=m
> CONFIG_SENSORS_LTC4222=m
> CONFIG_SENSORS_LTC4245=m
> CONFIG_SENSORS_LTC4260=m
> CONFIG_SENSORS_LTC4261=m
> CONFIG_SENSORS_MAX1111=m
> CONFIG_SENSORS_MAX127=m
> CONFIG_SENSORS_MAX16065=m
> CONFIG_SENSORS_MAX1619=m
> CONFIG_SENSORS_MAX1668=m
> CONFIG_SENSORS_MAX197=m
> CONFIG_SENSORS_MAX31722=m
> CONFIG_SENSORS_MAX31730=m
> CONFIG_SENSORS_MAX6620=m
> CONFIG_SENSORS_MAX6621=m
> CONFIG_SENSORS_MAX6639=m
> CONFIG_SENSORS_MAX6650=m
> CONFIG_SENSORS_MAX6697=m
> CONFIG_SENSORS_MAX31790=m
> CONFIG_SENSORS_MCP3021=m
> CONFIG_SENSORS_MLXREG_FAN=m
> CONFIG_SENSORS_TC654=m
> CONFIG_SENSORS_TPS23861=m
> CONFIG_SENSORS_MENF21BMC_HWMON=m
> CONFIG_SENSORS_MR75203=m
> CONFIG_SENSORS_ADCXX=m
> CONFIG_SENSORS_LM63=m
> CONFIG_SENSORS_LM70=m
> CONFIG_SENSORS_LM73=m
> CONFIG_SENSORS_LM75=m
> CONFIG_SENSORS_LM77=m
> CONFIG_SENSORS_LM78=m
> CONFIG_SENSORS_LM80=m
> CONFIG_SENSORS_LM83=m
> CONFIG_SENSORS_LM85=m
> CONFIG_SENSORS_LM87=m
> CONFIG_SENSORS_LM90=m
> CONFIG_SENSORS_LM92=m
> CONFIG_SENSORS_LM93=m
> CONFIG_SENSORS_LM95234=m
> CONFIG_SENSORS_LM95241=m
> CONFIG_SENSORS_LM95245=m
> CONFIG_SENSORS_PC87360=m
> CONFIG_SENSORS_PC87427=m
> CONFIG_SENSORS_NTC_THERMISTOR=m
> CONFIG_SENSORS_NCT6683=m
> CONFIG_SENSORS_NCT6775_CORE=m
> CONFIG_SENSORS_NCT6775=m
> CONFIG_SENSORS_NCT6775_I2C=m
> CONFIG_SENSORS_NCT7802=m
> CONFIG_SENSORS_NCT7904=m
> CONFIG_SENSORS_NPCM7XX=m
> CONFIG_SENSORS_NZXT_KRAKEN2=m
> CONFIG_SENSORS_NZXT_SMART2=m
> CONFIG_SENSORS_PCF8591=m
> CONFIG_SENSORS_PECI_CPUTEMP=m
> CONFIG_SENSORS_PECI_DIMMTEMP=m
> CONFIG_SENSORS_PECI=m
> CONFIG_PMBUS=m
> CONFIG_SENSORS_PMBUS=m
> CONFIG_SENSORS_ADM1266=m
> CONFIG_SENSORS_ADM1275=m
> CONFIG_SENSORS_BEL_PFE=m
> CONFIG_SENSORS_BPA_RS600=m
> CONFIG_SENSORS_DELTA_AHE50DC_FAN=m
> CONFIG_SENSORS_FSP_3Y=m
> CONFIG_SENSORS_IBM_CFFPS=m
> CONFIG_SENSORS_DPS920AB=m
> CONFIG_SENSORS_INSPUR_IPSPS=m
> CONFIG_SENSORS_IR35221=m
> CONFIG_SENSORS_IR36021=m
> CONFIG_SENSORS_IR38064=m
> CONFIG_SENSORS_IR38064_REGULATOR=y
> CONFIG_SENSORS_IRPS5401=m
> CONFIG_SENSORS_ISL68137=m
> CONFIG_SENSORS_LM25066=m
> CONFIG_SENSORS_LM25066_REGULATOR=y
> CONFIG_SENSORS_LT7182S=m
> CONFIG_SENSORS_LTC2978=m
> CONFIG_SENSORS_LTC2978_REGULATOR=y
> CONFIG_SENSORS_LTC3815=m
> CONFIG_SENSORS_MAX15301=m
> CONFIG_SENSORS_MAX16064=m
> CONFIG_SENSORS_MAX16601=m
> CONFIG_SENSORS_MAX20730=m
> CONFIG_SENSORS_MAX20751=m
> CONFIG_SENSORS_MAX31785=m
> CONFIG_SENSORS_MAX34440=m
> CONFIG_SENSORS_MAX8688=m
> CONFIG_SENSORS_MP2888=m
> CONFIG_SENSORS_MP2975=m
> CONFIG_SENSORS_MP5023=m
> CONFIG_SENSORS_PIM4328=m
> CONFIG_SENSORS_PLI1209BC=m
> CONFIG_SENSORS_PLI1209BC_REGULATOR=y
> CONFIG_SENSORS_PM6764TR=m
> CONFIG_SENSORS_PXE1610=m
> CONFIG_SENSORS_Q54SJ108A2=m
> CONFIG_SENSORS_STPDDC60=m
> CONFIG_SENSORS_TPS40422=m
> CONFIG_SENSORS_TPS53679=m
> CONFIG_SENSORS_UCD9000=m
> CONFIG_SENSORS_UCD9200=m
> CONFIG_SENSORS_XDPE152=m
> CONFIG_SENSORS_XDPE122=m
> CONFIG_SENSORS_XDPE122_REGULATOR=y
> CONFIG_SENSORS_ZL6100=m
> CONFIG_SENSORS_SBTSI=m
> CONFIG_SENSORS_SBRMI=m
> CONFIG_SENSORS_SHT15=m
> CONFIG_SENSORS_SHT21=m
> CONFIG_SENSORS_SHT3x=m
> CONFIG_SENSORS_SHT4x=m
> CONFIG_SENSORS_SHTC1=m
> CONFIG_SENSORS_SIS5595=m
> CONFIG_SENSORS_SY7636A=m
> CONFIG_SENSORS_DME1737=m
> CONFIG_SENSORS_EMC1403=m
> CONFIG_SENSORS_EMC2103=m
> CONFIG_SENSORS_EMC6W201=m
> CONFIG_SENSORS_SMSC47M1=m
> CONFIG_SENSORS_SMSC47M192=m
> CONFIG_SENSORS_SMSC47B397=m
> CONFIG_SENSORS_SCH56XX_COMMON=m
> CONFIG_SENSORS_SCH5627=m
> CONFIG_SENSORS_SCH5636=m
> CONFIG_SENSORS_STTS751=m
> CONFIG_SENSORS_SMM665=m
> CONFIG_SENSORS_ADC128D818=m
> CONFIG_SENSORS_ADS7828=m
> CONFIG_SENSORS_ADS7871=m
> CONFIG_SENSORS_AMC6821=m
> CONFIG_SENSORS_INA209=m
> CONFIG_SENSORS_INA2XX=m
> CONFIG_SENSORS_INA238=m
> CONFIG_SENSORS_INA3221=m
> CONFIG_SENSORS_TC74=m
> CONFIG_SENSORS_THMC50=m
> CONFIG_SENSORS_TMP102=m
> CONFIG_SENSORS_TMP103=m
> CONFIG_SENSORS_TMP108=m
> CONFIG_SENSORS_TMP401=m
> CONFIG_SENSORS_TMP421=m
> CONFIG_SENSORS_TMP464=m
> CONFIG_SENSORS_TMP513=m
> CONFIG_SENSORS_VIA_CPUTEMP=m
> CONFIG_SENSORS_VIA686A=m
> CONFIG_SENSORS_VT1211=m
> CONFIG_SENSORS_VT8231=m
> CONFIG_SENSORS_W83773G=m
> CONFIG_SENSORS_W83781D=m
> CONFIG_SENSORS_W83791D=m
> CONFIG_SENSORS_W83792D=m
> CONFIG_SENSORS_W83793=m
> CONFIG_SENSORS_W83795=m
> # CONFIG_SENSORS_W83795_FANCTRL is not set
> CONFIG_SENSORS_W83L785TS=m
> CONFIG_SENSORS_W83L786NG=m
> CONFIG_SENSORS_W83627HF=m
> CONFIG_SENSORS_W83627EHF=m
> CONFIG_SENSORS_WM831X=m
> CONFIG_SENSORS_WM8350=m
> CONFIG_SENSORS_XGENE=m
> CONFIG_SENSORS_INTEL_M10_BMC_HWMON=m
>
> #
> # ACPI drivers
> #
> CONFIG_SENSORS_ACPI_POWER=m
> CONFIG_SENSORS_ATK0110=m
> CONFIG_SENSORS_ASUS_WMI=m
> CONFIG_SENSORS_ASUS_EC=m
> CONFIG_THERMAL=y
> CONFIG_THERMAL_NETLINK=y
> CONFIG_THERMAL_STATISTICS=y
> CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
> CONFIG_THERMAL_HWMON=y
> CONFIG_THERMAL_WRITABLE_TRIPS=y
> CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
> # CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
> # CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
> # CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set
> CONFIG_THERMAL_GOV_FAIR_SHARE=y
> CONFIG_THERMAL_GOV_STEP_WISE=y
> CONFIG_THERMAL_GOV_BANG_BANG=y
> CONFIG_THERMAL_GOV_USER_SPACE=y
> CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
> CONFIG_DEVFREQ_THERMAL=y
> CONFIG_THERMAL_EMULATION=y
>
> #
> # Intel thermal drivers
> #
> CONFIG_INTEL_POWERCLAMP=m
> CONFIG_X86_THERMAL_VECTOR=y
> CONFIG_X86_PKG_TEMP_THERMAL=m
> CONFIG_INTEL_SOC_DTS_IOSF_CORE=m
> CONFIG_INTEL_SOC_DTS_THERMAL=m
>
> #
> # ACPI INT340X thermal drivers
> #
> CONFIG_INT340X_THERMAL=m
> CONFIG_ACPI_THERMAL_REL=m
> CONFIG_INT3406_THERMAL=m
> CONFIG_PROC_THERMAL_MMIO_RAPL=m
> # end of ACPI INT340X thermal drivers
>
> CONFIG_INTEL_BXT_PMIC_THERMAL=m
> CONFIG_INTEL_PCH_THERMAL=m
> CONFIG_INTEL_TCC_COOLING=m
> CONFIG_INTEL_MENLOW=m
> CONFIG_INTEL_HFI_THERMAL=y
> # end of Intel thermal drivers
>
> CONFIG_GENERIC_ADC_THERMAL=m
> CONFIG_WATCHDOG=y
> CONFIG_WATCHDOG_CORE=y
> # CONFIG_WATCHDOG_NOWAYOUT is not set
> CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y
> CONFIG_WATCHDOG_OPEN_TIMEOUT=0
> CONFIG_WATCHDOG_SYSFS=y
> # CONFIG_WATCHDOG_HRTIMER_PRETIMEOUT is not set
>
> #
> # Watchdog Pretimeout Governors
> #
> CONFIG_WATCHDOG_PRETIMEOUT_GOV=y
> CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL=m
> CONFIG_WATCHDOG_PRETIMEOUT_GOV_NOOP=y
> CONFIG_WATCHDOG_PRETIMEOUT_GOV_PANIC=m
> CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_NOOP=y
> # CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC is not set
>
> #
> # Watchdog Device Drivers
> #
> CONFIG_SOFT_WATCHDOG=m
> CONFIG_SOFT_WATCHDOG_PRETIMEOUT=y
> CONFIG_DA9052_WATCHDOG=m
> CONFIG_DA9055_WATCHDOG=m
> CONFIG_DA9063_WATCHDOG=m
> CONFIG_DA9062_WATCHDOG=m
> CONFIG_MENF21BMC_WATCHDOG=m
> CONFIG_MENZ069_WATCHDOG=m
> CONFIG_WDAT_WDT=m
> CONFIG_WM831X_WATCHDOG=m
> CONFIG_WM8350_WATCHDOG=m
> CONFIG_XILINX_WATCHDOG=m
> CONFIG_ZIIRAVE_WATCHDOG=m
> CONFIG_RAVE_SP_WATCHDOG=m
> CONFIG_MLX_WDT=m
> CONFIG_CADENCE_WATCHDOG=m
> CONFIG_DW_WATCHDOG=m
> CONFIG_TWL4030_WATCHDOG=m
> CONFIG_MAX63XX_WATCHDOG=m
> CONFIG_RETU_WATCHDOG=m
> CONFIG_ACQUIRE_WDT=m
> CONFIG_ADVANTECH_WDT=m
> CONFIG_ALIM1535_WDT=m
> CONFIG_ALIM7101_WDT=m
> CONFIG_EBC_C384_WDT=m
> CONFIG_F71808E_WDT=m
> CONFIG_SP5100_TCO=m
> CONFIG_SBC_FITPC2_WATCHDOG=m
> CONFIG_EUROTECH_WDT=m
> CONFIG_IB700_WDT=m
> CONFIG_IBMASR=m
> CONFIG_WAFER_WDT=m
> CONFIG_I6300ESB_WDT=m
> CONFIG_IE6XX_WDT=m
> CONFIG_ITCO_WDT=m
> CONFIG_ITCO_VENDOR_SUPPORT=y
> CONFIG_IT8712F_WDT=m
> CONFIG_IT87_WDT=m
> CONFIG_HP_WATCHDOG=m
> CONFIG_HPWDT_NMI_DECODING=y
> CONFIG_KEMPLD_WDT=m
> CONFIG_SC1200_WDT=m
> CONFIG_PC87413_WDT=m
> CONFIG_NV_TCO=m
> CONFIG_60XX_WDT=m
> CONFIG_CPU5_WDT=m
> CONFIG_SMSC_SCH311X_WDT=m
> CONFIG_SMSC37B787_WDT=m
> CONFIG_TQMX86_WDT=m
> CONFIG_VIA_WDT=m
> CONFIG_W83627HF_WDT=m
> CONFIG_W83877F_WDT=m
> CONFIG_W83977F_WDT=m
> CONFIG_MACHZ_WDT=m
> CONFIG_SBC_EPX_C3_WATCHDOG=m
> CONFIG_INTEL_MEI_WDT=m
> CONFIG_NI903X_WDT=m
> CONFIG_NIC7018_WDT=m
> CONFIG_SIEMENS_SIMATIC_IPC_WDT=m
> CONFIG_MEN_A21_WDT=m
> CONFIG_XEN_WDT=m
>
> #
> # PCI-based Watchdog Cards
> #
> CONFIG_PCIPCWATCHDOG=m
> CONFIG_WDTPCI=m
>
> #
> # USB-based Watchdog Cards
> #
> CONFIG_USBPCWATCHDOG=m
> CONFIG_SSB_POSSIBLE=y
> CONFIG_SSB=m
> CONFIG_SSB_SPROM=y
> CONFIG_SSB_BLOCKIO=y
> CONFIG_SSB_PCIHOST_POSSIBLE=y
> CONFIG_SSB_PCIHOST=y
> CONFIG_SSB_B43_PCI_BRIDGE=y
> CONFIG_SSB_PCMCIAHOST_POSSIBLE=y
> # CONFIG_SSB_PCMCIAHOST is not set
> CONFIG_SSB_SDIOHOST_POSSIBLE=y
> CONFIG_SSB_SDIOHOST=y
> CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
> CONFIG_SSB_DRIVER_PCICORE=y
> CONFIG_SSB_DRIVER_GPIO=y
> CONFIG_BCMA_POSSIBLE=y
> CONFIG_BCMA=m
> CONFIG_BCMA_BLOCKIO=y
> CONFIG_BCMA_HOST_PCI_POSSIBLE=y
> CONFIG_BCMA_HOST_PCI=y
> CONFIG_BCMA_HOST_SOC=y
> CONFIG_BCMA_DRIVER_PCI=y
> CONFIG_BCMA_SFLASH=y
> CONFIG_BCMA_DRIVER_GMAC_CMN=y
> CONFIG_BCMA_DRIVER_GPIO=y
> # CONFIG_BCMA_DEBUG is not set
>
> #
> # Multifunction device drivers
> #
> CONFIG_MFD_CORE=y
> CONFIG_MFD_AS3711=y
> CONFIG_PMIC_ADP5520=y
> CONFIG_MFD_AAT2870_CORE=y
> CONFIG_MFD_BCM590XX=m
> CONFIG_MFD_BD9571MWV=m
> CONFIG_MFD_AXP20X=m
> CONFIG_MFD_AXP20X_I2C=m
> CONFIG_MFD_CROS_EC_DEV=m
> CONFIG_MFD_MADERA=m
> CONFIG_MFD_MADERA_I2C=m
> CONFIG_MFD_MADERA_SPI=m
> CONFIG_MFD_CS47L15=y
> CONFIG_MFD_CS47L35=y
> CONFIG_MFD_CS47L85=y
> CONFIG_MFD_CS47L90=y
> CONFIG_MFD_CS47L92=y
> CONFIG_PMIC_DA903X=y
> CONFIG_PMIC_DA9052=y
> CONFIG_MFD_DA9052_SPI=y
> CONFIG_MFD_DA9052_I2C=y
> CONFIG_MFD_DA9055=y
> CONFIG_MFD_DA9062=m
> CONFIG_MFD_DA9063=y
> CONFIG_MFD_DA9150=m
> CONFIG_MFD_DLN2=m
> CONFIG_MFD_MC13XXX=m
> CONFIG_MFD_MC13XXX_SPI=m
> CONFIG_MFD_MC13XXX_I2C=m
> CONFIG_MFD_MP2629=m
> CONFIG_HTC_PASIC3=m
> CONFIG_HTC_I2CPLD=y
> CONFIG_MFD_INTEL_QUARK_I2C_GPIO=m
> CONFIG_LPC_ICH=m
> CONFIG_LPC_SCH=m
> CONFIG_INTEL_SOC_PMIC=y
> CONFIG_INTEL_SOC_PMIC_BXTWC=m
> CONFIG_INTEL_SOC_PMIC_CHTWC=y
> CONFIG_INTEL_SOC_PMIC_CHTDC_TI=m
> CONFIG_INTEL_SOC_PMIC_MRFLD=m
> CONFIG_MFD_INTEL_LPSS=m
> CONFIG_MFD_INTEL_LPSS_ACPI=m
> CONFIG_MFD_INTEL_LPSS_PCI=m
> CONFIG_MFD_INTEL_PMC_BXT=m
> CONFIG_MFD_IQS62X=m
> CONFIG_MFD_JANZ_CMODIO=m
> CONFIG_MFD_KEMPLD=m
> CONFIG_MFD_88PM800=m
> CONFIG_MFD_88PM805=m
> CONFIG_MFD_88PM860X=y
> CONFIG_MFD_MAX14577=y
> CONFIG_MFD_MAX77693=y
> CONFIG_MFD_MAX77843=y
> CONFIG_MFD_MAX8907=m
> CONFIG_MFD_MAX8925=y
> CONFIG_MFD_MAX8997=y
> CONFIG_MFD_MAX8998=y
> CONFIG_MFD_MT6360=m
> CONFIG_MFD_MT6397=m
> CONFIG_MFD_MENF21BMC=m
> CONFIG_EZX_PCAP=y
> CONFIG_MFD_VIPERBOARD=m
> CONFIG_MFD_RETU=m
> CONFIG_MFD_PCF50633=m
> CONFIG_PCF50633_ADC=m
> CONFIG_PCF50633_GPIO=m
> CONFIG_UCB1400_CORE=m
> CONFIG_MFD_RDC321X=m
> CONFIG_MFD_RT4831=m
> CONFIG_MFD_RT5033=m
> CONFIG_MFD_RC5T583=y
> CONFIG_MFD_SI476X_CORE=m
> CONFIG_MFD_SIMPLE_MFD_I2C=m
> CONFIG_MFD_SM501=m
> CONFIG_MFD_SM501_GPIO=y
> CONFIG_MFD_SKY81452=m
> CONFIG_MFD_SYSCON=y
> CONFIG_MFD_TI_AM335X_TSCADC=m
> CONFIG_MFD_LP3943=m
> CONFIG_MFD_LP8788=y
> CONFIG_MFD_TI_LMU=m
> CONFIG_MFD_PALMAS=y
> CONFIG_TPS6105X=m
> CONFIG_TPS65010=m
> CONFIG_TPS6507X=m
> CONFIG_MFD_TPS65086=m
> CONFIG_MFD_TPS65090=y
> CONFIG_MFD_TI_LP873X=m
> CONFIG_MFD_TPS6586X=y
> CONFIG_MFD_TPS65910=y
> CONFIG_MFD_TPS65912=y
> CONFIG_MFD_TPS65912_I2C=y
> CONFIG_MFD_TPS65912_SPI=y
> CONFIG_TWL4030_CORE=y
> CONFIG_MFD_TWL4030_AUDIO=y
> CONFIG_TWL6040_CORE=y
> CONFIG_MFD_WL1273_CORE=m
> CONFIG_MFD_LM3533=m
> CONFIG_MFD_TQMX86=m
> CONFIG_MFD_VX855=m
> CONFIG_MFD_ARIZONA=m
> CONFIG_MFD_ARIZONA_I2C=m
> CONFIG_MFD_ARIZONA_SPI=m
> CONFIG_MFD_CS47L24=y
> CONFIG_MFD_WM5102=y
> CONFIG_MFD_WM5110=y
> CONFIG_MFD_WM8997=y
> CONFIG_MFD_WM8998=y
> CONFIG_MFD_WM8400=y
> CONFIG_MFD_WM831X=y
> CONFIG_MFD_WM831X_I2C=y
> CONFIG_MFD_WM831X_SPI=y
> CONFIG_MFD_WM8350=y
> CONFIG_MFD_WM8350_I2C=y
> CONFIG_MFD_WM8994=m
> CONFIG_MFD_WCD934X=m
> CONFIG_MFD_ATC260X=m
> CONFIG_MFD_ATC260X_I2C=m
> CONFIG_RAVE_SP_CORE=m
> CONFIG_MFD_INTEL_M10_BMC=m
> # end of Multifunction device drivers
>
> CONFIG_REGULATOR=y
> # CONFIG_REGULATOR_DEBUG is not set
> CONFIG_REGULATOR_FIXED_VOLTAGE=m
> CONFIG_REGULATOR_VIRTUAL_CONSUMER=m
> CONFIG_REGULATOR_USERSPACE_CONSUMER=m
> CONFIG_REGULATOR_88PG86X=m
> CONFIG_REGULATOR_88PM800=m
> CONFIG_REGULATOR_88PM8607=m
> CONFIG_REGULATOR_ACT8865=m
> CONFIG_REGULATOR_AD5398=m
> CONFIG_REGULATOR_AAT2870=m
> CONFIG_REGULATOR_ARIZONA_LDO1=m
> CONFIG_REGULATOR_ARIZONA_MICSUPP=m
> CONFIG_REGULATOR_AS3711=m
> CONFIG_REGULATOR_ATC260X=m
> CONFIG_REGULATOR_AXP20X=m
> CONFIG_REGULATOR_BCM590XX=m
> CONFIG_REGULATOR_BD9571MWV=m
> CONFIG_REGULATOR_DA903X=m
> CONFIG_REGULATOR_DA9052=m
> CONFIG_REGULATOR_DA9055=m
> CONFIG_REGULATOR_DA9062=m
> CONFIG_REGULATOR_DA9210=m
> CONFIG_REGULATOR_DA9211=m
> CONFIG_REGULATOR_FAN53555=m
> CONFIG_REGULATOR_GPIO=m
> CONFIG_REGULATOR_ISL9305=m
> CONFIG_REGULATOR_ISL6271A=m
> CONFIG_REGULATOR_LM363X=m
> CONFIG_REGULATOR_LP3971=m
> CONFIG_REGULATOR_LP3972=m
> CONFIG_REGULATOR_LP872X=m
> CONFIG_REGULATOR_LP8755=m
> CONFIG_REGULATOR_LP8788=m
> CONFIG_REGULATOR_LTC3589=m
> CONFIG_REGULATOR_LTC3676=m
> CONFIG_REGULATOR_MAX14577=m
> CONFIG_REGULATOR_MAX1586=m
> CONFIG_REGULATOR_MAX8649=m
> CONFIG_REGULATOR_MAX8660=m
> CONFIG_REGULATOR_MAX8893=m
> CONFIG_REGULATOR_MAX8907=m
> CONFIG_REGULATOR_MAX8925=m
> CONFIG_REGULATOR_MAX8952=m
> CONFIG_REGULATOR_MAX8997=m
> CONFIG_REGULATOR_MAX8998=m
> CONFIG_REGULATOR_MAX20086=m
> CONFIG_REGULATOR_MAX77693=m
> CONFIG_REGULATOR_MAX77826=m
> CONFIG_REGULATOR_MC13XXX_CORE=m
> CONFIG_REGULATOR_MC13783=m
> CONFIG_REGULATOR_MC13892=m
> CONFIG_REGULATOR_MP8859=m
> CONFIG_REGULATOR_MT6311=m
> CONFIG_REGULATOR_MT6315=m
> CONFIG_REGULATOR_MT6323=m
> CONFIG_REGULATOR_MT6358=m
> CONFIG_REGULATOR_MT6359=m
> CONFIG_REGULATOR_MT6360=m
> CONFIG_REGULATOR_MT6397=m
> CONFIG_REGULATOR_PALMAS=m
> CONFIG_REGULATOR_PCA9450=m
> CONFIG_REGULATOR_PCAP=m
> CONFIG_REGULATOR_PCF50633=m
> CONFIG_REGULATOR_PV88060=m
> CONFIG_REGULATOR_PV88080=m
> CONFIG_REGULATOR_PV88090=m
> CONFIG_REGULATOR_PWM=m
> CONFIG_REGULATOR_QCOM_SPMI=m
> CONFIG_REGULATOR_QCOM_USB_VBUS=m
> CONFIG_REGULATOR_RC5T583=m
> CONFIG_REGULATOR_RT4801=m
> CONFIG_REGULATOR_RT4831=m
> CONFIG_REGULATOR_RT5033=m
> CONFIG_REGULATOR_RT5190A=m
> CONFIG_REGULATOR_RT5759=m
> CONFIG_REGULATOR_RT6160=m
> CONFIG_REGULATOR_RT6245=m
> CONFIG_REGULATOR_RTQ2134=m
> CONFIG_REGULATOR_RTMV20=m
> CONFIG_REGULATOR_RTQ6752=m
> CONFIG_REGULATOR_SKY81452=m
> CONFIG_REGULATOR_SLG51000=m
> CONFIG_REGULATOR_SY7636A=m
> CONFIG_REGULATOR_TPS51632=m
> CONFIG_REGULATOR_TPS6105X=m
> CONFIG_REGULATOR_TPS62360=m
> CONFIG_REGULATOR_TPS65023=m
> CONFIG_REGULATOR_TPS6507X=m
> CONFIG_REGULATOR_TPS65086=m
> CONFIG_REGULATOR_TPS65090=m
> CONFIG_REGULATOR_TPS65132=m
> CONFIG_REGULATOR_TPS6524X=m
> CONFIG_REGULATOR_TPS6586X=m
> CONFIG_REGULATOR_TPS65910=m
> CONFIG_REGULATOR_TPS65912=m
> CONFIG_REGULATOR_TPS68470=m
> CONFIG_REGULATOR_TWL4030=m
> CONFIG_REGULATOR_WM831X=m
> CONFIG_REGULATOR_WM8350=m
> CONFIG_REGULATOR_WM8400=m
> CONFIG_REGULATOR_WM8994=m
> CONFIG_REGULATOR_QCOM_LABIBB=m
> CONFIG_RC_CORE=m
> CONFIG_LIRC=y
> CONFIG_RC_MAP=m
> CONFIG_RC_DECODERS=y
> CONFIG_IR_IMON_DECODER=m
> CONFIG_IR_JVC_DECODER=m
> CONFIG_IR_MCE_KBD_DECODER=m
> CONFIG_IR_NEC_DECODER=m
> CONFIG_IR_RC5_DECODER=m
> CONFIG_IR_RC6_DECODER=m
> CONFIG_IR_RCMM_DECODER=m
> CONFIG_IR_SANYO_DECODER=m
> CONFIG_IR_SHARP_DECODER=m
> CONFIG_IR_SONY_DECODER=m
> CONFIG_IR_XMP_DECODER=m
> CONFIG_RC_DEVICES=y
> CONFIG_IR_ENE=m
> CONFIG_IR_FINTEK=m
> CONFIG_IR_IGORPLUGUSB=m
> CONFIG_IR_IGUANA=m
> CONFIG_IR_IMON=m
> CONFIG_IR_IMON_RAW=m
> CONFIG_IR_ITE_CIR=m
> CONFIG_IR_MCEUSB=m
> CONFIG_IR_NUVOTON=m
> CONFIG_IR_REDRAT3=m
> CONFIG_IR_SERIAL=m
> CONFIG_IR_SERIAL_TRANSMITTER=y
> CONFIG_IR_STREAMZAP=m
> CONFIG_IR_TOY=m
> CONFIG_IR_TTUSBIR=m
> CONFIG_IR_WINBOND_CIR=m
> CONFIG_RC_ATI_REMOTE=m
> CONFIG_RC_LOOPBACK=m
> CONFIG_RC_XBOX_DVD=m
> CONFIG_CEC_CORE=m
> CONFIG_CEC_NOTIFIER=y
> CONFIG_CEC_PIN=y
>
> #
> # CEC support
> #
> CONFIG_MEDIA_CEC_RC=y
> # CONFIG_CEC_PIN_ERROR_INJ is not set
> CONFIG_MEDIA_CEC_SUPPORT=y
> CONFIG_CEC_CH7322=m
> CONFIG_CEC_CROS_EC=m
> CONFIG_CEC_GPIO=m
> CONFIG_CEC_SECO=m
> CONFIG_CEC_SECO_RC=y
> CONFIG_USB_PULSE8_CEC=m
> CONFIG_USB_RAINSHADOW_CEC=m
> # end of CEC support
>
> CONFIG_MEDIA_SUPPORT=m
> CONFIG_MEDIA_SUPPORT_FILTER=y
> CONFIG_MEDIA_SUBDRV_AUTOSELECT=y
>
> #
> # Media device types
> #
> CONFIG_MEDIA_CAMERA_SUPPORT=y
> CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
> CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
> CONFIG_MEDIA_RADIO_SUPPORT=y
> CONFIG_MEDIA_SDR_SUPPORT=y
> CONFIG_MEDIA_PLATFORM_SUPPORT=y
> CONFIG_MEDIA_TEST_SUPPORT=y
> # end of Media device types
>
> CONFIG_VIDEO_DEV=m
> CONFIG_MEDIA_CONTROLLER=y
> CONFIG_DVB_CORE=m
>
> #
> # Video4Linux options
> #
> CONFIG_VIDEO_V4L2_I2C=y
> CONFIG_VIDEO_V4L2_SUBDEV_API=y
> # CONFIG_VIDEO_ADV_DEBUG is not set
> # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
> CONFIG_VIDEO_TUNER=m
> CONFIG_V4L2_MEM2MEM_DEV=m
> CONFIG_V4L2_FLASH_LED_CLASS=m
> CONFIG_V4L2_FWNODE=m
> CONFIG_V4L2_ASYNC=m
> CONFIG_VIDEOBUF_GEN=m
> CONFIG_VIDEOBUF_DMA_SG=m
> CONFIG_VIDEOBUF_VMALLOC=m
> # end of Video4Linux options
>
> #
> # Media controller options
> #
> CONFIG_MEDIA_CONTROLLER_DVB=y
> CONFIG_MEDIA_CONTROLLER_REQUEST_API=y
> # end of Media controller options
>
> #
> # Digital TV options
> #
> # CONFIG_DVB_MMAP is not set
> CONFIG_DVB_NET=y
> CONFIG_DVB_MAX_ADAPTERS=8
> CONFIG_DVB_DYNAMIC_MINORS=y
> # CONFIG_DVB_DEMUX_SECTION_LOSS_LOG is not set
> # CONFIG_DVB_ULE_DEBUG is not set
> # end of Digital TV options
>
> #
> # Media drivers
> #
>
> #
> # Drivers filtered as selected at 'Filter media drivers'
> #
>
> #
> # Media drivers
> #
> CONFIG_MEDIA_USB_SUPPORT=y
>
> #
> # Webcam devices
> #
> CONFIG_VIDEO_CPIA2=m
> CONFIG_USB_GSPCA=m
> CONFIG_USB_GSPCA_BENQ=m
> CONFIG_USB_GSPCA_CONEX=m
> CONFIG_USB_GSPCA_CPIA1=m
> CONFIG_USB_GSPCA_DTCS033=m
> CONFIG_USB_GSPCA_ETOMS=m
> CONFIG_USB_GSPCA_FINEPIX=m
> CONFIG_USB_GSPCA_JEILINJ=m
> CONFIG_USB_GSPCA_JL2005BCD=m
> CONFIG_USB_GSPCA_KINECT=m
> CONFIG_USB_GSPCA_KONICA=m
> CONFIG_USB_GSPCA_MARS=m
> CONFIG_USB_GSPCA_MR97310A=m
> CONFIG_USB_GSPCA_NW80X=m
> CONFIG_USB_GSPCA_OV519=m
> CONFIG_USB_GSPCA_OV534=m
> CONFIG_USB_GSPCA_OV534_9=m
> CONFIG_USB_GSPCA_PAC207=m
> CONFIG_USB_GSPCA_PAC7302=m
> CONFIG_USB_GSPCA_PAC7311=m
> CONFIG_USB_GSPCA_SE401=m
> CONFIG_USB_GSPCA_SN9C2028=m
> CONFIG_USB_GSPCA_SN9C20X=m
> CONFIG_USB_GSPCA_SONIXB=m
> CONFIG_USB_GSPCA_SONIXJ=m
> CONFIG_USB_GSPCA_SPCA1528=m
> CONFIG_USB_GSPCA_SPCA500=m
> CONFIG_USB_GSPCA_SPCA501=m
> CONFIG_USB_GSPCA_SPCA505=m
> CONFIG_USB_GSPCA_SPCA506=m
> CONFIG_USB_GSPCA_SPCA508=m
> CONFIG_USB_GSPCA_SPCA561=m
> CONFIG_USB_GSPCA_SQ905=m
> CONFIG_USB_GSPCA_SQ905C=m
> CONFIG_USB_GSPCA_SQ930X=m
> CONFIG_USB_GSPCA_STK014=m
> CONFIG_USB_GSPCA_STK1135=m
> CONFIG_USB_GSPCA_STV0680=m
> CONFIG_USB_GSPCA_SUNPLUS=m
> CONFIG_USB_GSPCA_T613=m
> CONFIG_USB_GSPCA_TOPRO=m
> CONFIG_USB_GSPCA_TOUPTEK=m
> CONFIG_USB_GSPCA_TV8532=m
> CONFIG_USB_GSPCA_VC032X=m
> CONFIG_USB_GSPCA_VICAM=m
> CONFIG_USB_GSPCA_XIRLINK_CIT=m
> CONFIG_USB_GSPCA_ZC3XX=m
> CONFIG_USB_GL860=m
> CONFIG_USB_M5602=m
> CONFIG_USB_STV06XX=m
> CONFIG_USB_PWC=m
> # CONFIG_USB_PWC_DEBUG is not set
> CONFIG_USB_PWC_INPUT_EVDEV=y
> CONFIG_USB_S2255=m
> CONFIG_VIDEO_USBTV=m
> CONFIG_USB_VIDEO_CLASS=m
> CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
> CONFIG_USB_ZR364XX=m
>
> #
> # Analog TV USB devices
> #
> CONFIG_VIDEO_GO7007=m
> CONFIG_VIDEO_GO7007_USB=m
> CONFIG_VIDEO_GO7007_LOADER=m
> CONFIG_VIDEO_GO7007_USB_S2250_BOARD=m
> CONFIG_VIDEO_HDPVR=m
> CONFIG_VIDEO_PVRUSB2=m
> CONFIG_VIDEO_PVRUSB2_SYSFS=y
> CONFIG_VIDEO_PVRUSB2_DVB=y
> # CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
> CONFIG_VIDEO_STK1160_COMMON=m
> CONFIG_VIDEO_STK1160=m
>
> #
> # Analog/digital TV USB devices
> #
> CONFIG_VIDEO_AU0828=m
> CONFIG_VIDEO_AU0828_V4L2=y
> CONFIG_VIDEO_AU0828_RC=y
> CONFIG_VIDEO_CX231XX=m
> CONFIG_VIDEO_CX231XX_RC=y
> CONFIG_VIDEO_CX231XX_ALSA=m
> CONFIG_VIDEO_CX231XX_DVB=m
> CONFIG_VIDEO_TM6000=m
> CONFIG_VIDEO_TM6000_ALSA=m
> CONFIG_VIDEO_TM6000_DVB=m
>
> #
> # Digital TV USB devices
> #
> CONFIG_DVB_AS102=m
> CONFIG_DVB_B2C2_FLEXCOP_USB=m
> # CONFIG_DVB_B2C2_FLEXCOP_USB_DEBUG is not set
> CONFIG_DVB_USB_V2=m
> CONFIG_DVB_USB_AF9015=m
> CONFIG_DVB_USB_AF9035=m
> CONFIG_DVB_USB_ANYSEE=m
> CONFIG_DVB_USB_AU6610=m
> CONFIG_DVB_USB_AZ6007=m
> CONFIG_DVB_USB_CE6230=m
> CONFIG_DVB_USB_DVBSKY=m
> CONFIG_DVB_USB_EC168=m
> CONFIG_DVB_USB_GL861=m
> CONFIG_DVB_USB_LME2510=m
> CONFIG_DVB_USB_MXL111SF=m
> CONFIG_DVB_USB_RTL28XXU=m
> CONFIG_DVB_USB_ZD1301=m
> CONFIG_DVB_USB=m
> # CONFIG_DVB_USB_DEBUG is not set
> CONFIG_DVB_USB_A800=m
> CONFIG_DVB_USB_AF9005=m
> CONFIG_DVB_USB_AF9005_REMOTE=m
> CONFIG_DVB_USB_AZ6027=m
> CONFIG_DVB_USB_CINERGY_T2=m
> CONFIG_DVB_USB_CXUSB=m
> CONFIG_DVB_USB_CXUSB_ANALOG=y
> CONFIG_DVB_USB_DIB0700=m
> CONFIG_DVB_USB_DIB3000MC=m
> CONFIG_DVB_USB_DIBUSB_MB=m
> # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
> CONFIG_DVB_USB_DIBUSB_MC=m
> CONFIG_DVB_USB_DIGITV=m
> CONFIG_DVB_USB_DTT200U=m
> CONFIG_DVB_USB_DTV5100=m
> CONFIG_DVB_USB_DW2102=m
> CONFIG_DVB_USB_GP8PSK=m
> CONFIG_DVB_USB_M920X=m
> CONFIG_DVB_USB_NOVA_T_USB2=m
> CONFIG_DVB_USB_OPERA1=m
> CONFIG_DVB_USB_PCTV452E=m
> CONFIG_DVB_USB_TECHNISAT_USB2=m
> CONFIG_DVB_USB_TTUSB2=m
> CONFIG_DVB_USB_UMT_010=m
> CONFIG_DVB_USB_VP702X=m
> CONFIG_DVB_USB_VP7045=m
> CONFIG_SMS_USB_DRV=m
> CONFIG_DVB_TTUSB_BUDGET=m
> CONFIG_DVB_TTUSB_DEC=m
>
> #
> # Webcam, TV (analog/digital) USB devices
> #
> CONFIG_VIDEO_EM28XX=m
> CONFIG_VIDEO_EM28XX_V4L2=m
> CONFIG_VIDEO_EM28XX_ALSA=m
> CONFIG_VIDEO_EM28XX_DVB=m
> CONFIG_VIDEO_EM28XX_RC=m
>
> #
> # Software defined radio USB devices
> #
> CONFIG_USB_AIRSPY=m
> CONFIG_USB_HACKRF=m
> CONFIG_USB_MSI2500=m
> CONFIG_MEDIA_PCI_SUPPORT=y
>
> #
> # Media capture support
> #
> CONFIG_VIDEO_MEYE=m
> CONFIG_VIDEO_SOLO6X10=m
> CONFIG_VIDEO_TW5864=m
> CONFIG_VIDEO_TW68=m
> CONFIG_VIDEO_TW686X=m
>
> #
> # Media capture/analog TV support
> #
> CONFIG_VIDEO_DT3155=m
> CONFIG_VIDEO_IVTV=m
> CONFIG_VIDEO_IVTV_ALSA=m
> CONFIG_VIDEO_FB_IVTV=m
> CONFIG_VIDEO_FB_IVTV_FORCE_PAT=y
> CONFIG_VIDEO_HEXIUM_GEMINI=m
> CONFIG_VIDEO_HEXIUM_ORION=m
> CONFIG_VIDEO_MXB=m
>
> #
> # Media capture/analog/hybrid TV support
> #
> CONFIG_VIDEO_BT848=m
> CONFIG_DVB_BT8XX=m
> CONFIG_VIDEO_COBALT=m
> CONFIG_VIDEO_CX18=m
> CONFIG_VIDEO_CX18_ALSA=m
> CONFIG_VIDEO_CX23885=m
> CONFIG_MEDIA_ALTERA_CI=m
> CONFIG_VIDEO_CX25821=m
> CONFIG_VIDEO_CX25821_ALSA=m
> CONFIG_VIDEO_CX88=m
> CONFIG_VIDEO_CX88_ALSA=m
> CONFIG_VIDEO_CX88_BLACKBIRD=m
> CONFIG_VIDEO_CX88_DVB=m
> CONFIG_VIDEO_CX88_ENABLE_VP3054=y
> CONFIG_VIDEO_CX88_VP3054=m
> CONFIG_VIDEO_CX88_MPEG=m
> CONFIG_VIDEO_SAA7134=m
> CONFIG_VIDEO_SAA7134_ALSA=m
> CONFIG_VIDEO_SAA7134_RC=y
> CONFIG_VIDEO_SAA7134_DVB=m
> CONFIG_VIDEO_SAA7134_GO7007=m
> CONFIG_VIDEO_SAA7164=m
>
> #
> # Media digital TV PCI Adapters
> #
> CONFIG_DVB_B2C2_FLEXCOP_PCI=m
> # CONFIG_DVB_B2C2_FLEXCOP_PCI_DEBUG is not set
> CONFIG_DVB_DDBRIDGE=m
> # CONFIG_DVB_DDBRIDGE_MSIENABLE is not set
> CONFIG_DVB_DM1105=m
> CONFIG_MANTIS_CORE=m
> CONFIG_DVB_MANTIS=m
> CONFIG_DVB_HOPPER=m
> CONFIG_DVB_NETUP_UNIDVB=m
> CONFIG_DVB_NGENE=m
> CONFIG_DVB_PLUTO2=m
> CONFIG_DVB_PT1=m
> CONFIG_DVB_PT3=m
> CONFIG_DVB_SMIPCIE=m
> CONFIG_DVB_BUDGET_CORE=m
> CONFIG_DVB_BUDGET=m
> CONFIG_DVB_BUDGET_CI=m
> CONFIG_DVB_BUDGET_AV=m
> # CONFIG_VIDEO_PCI_SKELETON is not set
> CONFIG_VIDEO_IPU3_CIO2=m
> CONFIG_CIO2_BRIDGE=y
> CONFIG_RADIO_ADAPTERS=m
> CONFIG_RADIO_MAXIRADIO=m
> CONFIG_RADIO_SAA7706H=m
> CONFIG_RADIO_SHARK=m
> CONFIG_RADIO_SHARK2=m
> CONFIG_RADIO_SI4713=m
> CONFIG_RADIO_SI476X=m
> CONFIG_RADIO_TEA575X=m
> CONFIG_RADIO_TEA5764=m
> CONFIG_RADIO_TEF6862=m
> CONFIG_RADIO_WL1273=m
> CONFIG_USB_DSBR=m
> CONFIG_USB_KEENE=m
> CONFIG_USB_MA901=m
> CONFIG_USB_MR800=m
> CONFIG_USB_RAREMONO=m
> CONFIG_RADIO_SI470X=m
> CONFIG_USB_SI470X=m
> CONFIG_I2C_SI470X=m
> CONFIG_USB_SI4713=m
> CONFIG_PLATFORM_SI4713=m
> CONFIG_I2C_SI4713=m
> CONFIG_RADIO_WL128X=m
> CONFIG_MEDIA_PLATFORM_DRIVERS=y
> CONFIG_V4L_PLATFORM_DRIVERS=y
> CONFIG_SDR_PLATFORM_DRIVERS=y
> CONFIG_DVB_PLATFORM_DRIVERS=y
> CONFIG_V4L_MEM2MEM_DRIVERS=y
> CONFIG_VIDEO_MEM2MEM_DEINTERLACE=m
>
> #
> # Allegro DVT media platform drivers
> #
>
> #
> # Amlogic media platform drivers
> #
>
> #
> # Amphion drivers
> #
>
> #
> # Aspeed media platform drivers
> #
> CONFIG_VIDEO_ASPEED=m
>
> #
> # Atmel media platform drivers
> #
>
> #
> # Cadence media platform drivers
> #
> CONFIG_VIDEO_CADENCE_CSI2RX=m
> CONFIG_VIDEO_CADENCE_CSI2TX=m
>
> #
> # Chips&Media media platform drivers
> #
>
> #
> # Intel media platform drivers
> #
>
> #
> # Marvell media platform drivers
> #
> CONFIG_VIDEO_CAFE_CCIC=m
>
> #
> # Mediatek media platform drivers
> #
>
> #
> # NVidia media platform drivers
> #
>
> #
> # NXP media platform drivers
> #
>
> #
> # Qualcomm media platform drivers
> #
>
> #
> # Renesas media platform drivers
> #
>
> #
> # Rockchip media platform drivers
> #
>
> #
> # Samsung media platform drivers
> #
>
> #
> # STMicroelectronics media platform drivers
> #
>
> #
> # Sunxi media platform drivers
> #
>
> #
> # Texas Instruments drivers
> #
>
> #
> # VIA media platform drivers
> #
> CONFIG_VIDEO_VIA_CAMERA=m
>
> #
> # Xilinx media platform drivers
> #
>
> #
> # MMC/SDIO DVB adapters
> #
> CONFIG_SMS_SDIO_DRV=m
> CONFIG_V4L_TEST_DRIVERS=y
> CONFIG_VIDEO_VIM2M=m
> CONFIG_VIDEO_VICODEC=m
> CONFIG_VIDEO_VIMC=m
> CONFIG_VIDEO_VIVID=m
> CONFIG_VIDEO_VIVID_CEC=y
> CONFIG_VIDEO_VIVID_MAX_DEVS=64
> # CONFIG_DVB_TEST_DRIVERS is not set
>
> #
> # FireWire (IEEE 1394) Adapters
> #
> CONFIG_DVB_FIREDTV=m
> CONFIG_DVB_FIREDTV_INPUT=y
> CONFIG_MEDIA_COMMON_OPTIONS=y
>
> #
> # common driver options
> #
> CONFIG_CYPRESS_FIRMWARE=m
> CONFIG_TTPCI_EEPROM=m
> CONFIG_VIDEO_CX2341X=m
> CONFIG_VIDEO_TVEEPROM=m
> CONFIG_DVB_B2C2_FLEXCOP=m
> CONFIG_VIDEO_SAA7146=m
> CONFIG_VIDEO_SAA7146_VV=m
> CONFIG_SMS_SIANO_MDTV=m
> CONFIG_SMS_SIANO_RC=y
> CONFIG_SMS_SIANO_DEBUGFS=y
> CONFIG_VIDEO_V4L2_TPG=m
> CONFIG_VIDEOBUF2_CORE=m
> CONFIG_VIDEOBUF2_V4L2=m
> CONFIG_VIDEOBUF2_MEMOPS=m
> CONFIG_VIDEOBUF2_DMA_CONTIG=m
> CONFIG_VIDEOBUF2_VMALLOC=m
> CONFIG_VIDEOBUF2_DMA_SG=m
> CONFIG_VIDEOBUF2_DVB=m
> # end of Media drivers
>
> #
> # Media ancillary drivers
> #
> CONFIG_MEDIA_ATTACH=y
>
> #
> # IR I2C driver auto-selected by 'Autoselect ancillary drivers'
> #
> CONFIG_VIDEO_IR_I2C=m
>
> #
> # Camera sensor devices
> #
> CONFIG_VIDEO_APTINA_PLL=m
> CONFIG_VIDEO_CCS_PLL=m
> CONFIG_VIDEO_AR0521=m
> CONFIG_VIDEO_HI556=m
> CONFIG_VIDEO_HI846=m
> CONFIG_VIDEO_HI847=m
> CONFIG_VIDEO_IMX208=m
> CONFIG_VIDEO_IMX214=m
> CONFIG_VIDEO_IMX219=m
> CONFIG_VIDEO_IMX258=m
> CONFIG_VIDEO_IMX274=m
> CONFIG_VIDEO_IMX290=m
> CONFIG_VIDEO_IMX319=m
> CONFIG_VIDEO_IMX355=m
> CONFIG_VIDEO_MAX9271_LIB=m
> CONFIG_VIDEO_MT9M001=m
> CONFIG_VIDEO_MT9M032=m
> CONFIG_VIDEO_MT9M111=m
> CONFIG_VIDEO_MT9P031=m
> CONFIG_VIDEO_MT9T001=m
> CONFIG_VIDEO_MT9T112=m
> CONFIG_VIDEO_MT9V011=m
> CONFIG_VIDEO_MT9V032=m
> CONFIG_VIDEO_MT9V111=m
> CONFIG_VIDEO_NOON010PC30=m
> CONFIG_VIDEO_OG01A1B=m
> CONFIG_VIDEO_OV02A10=m
> CONFIG_VIDEO_OV08D10=m
> CONFIG_VIDEO_OV13858=m
> CONFIG_VIDEO_OV13B10=m
> CONFIG_VIDEO_OV2640=m
> CONFIG_VIDEO_OV2659=m
> CONFIG_VIDEO_OV2680=m
> CONFIG_VIDEO_OV2685=m
> CONFIG_VIDEO_OV2740=m
> CONFIG_VIDEO_OV5647=m
> CONFIG_VIDEO_OV5648=m
> CONFIG_VIDEO_OV5670=m
> CONFIG_VIDEO_OV5675=m
> CONFIG_VIDEO_OV5693=m
> CONFIG_VIDEO_OV5695=m
> CONFIG_VIDEO_OV6650=m
> CONFIG_VIDEO_OV7251=m
> CONFIG_VIDEO_OV7640=m
> CONFIG_VIDEO_OV7670=m
> CONFIG_VIDEO_OV772X=m
> CONFIG_VIDEO_OV7740=m
> CONFIG_VIDEO_OV8856=m
> CONFIG_VIDEO_OV8865=m
> CONFIG_VIDEO_OV9640=m
> CONFIG_VIDEO_OV9650=m
> CONFIG_VIDEO_OV9734=m
> CONFIG_VIDEO_RDACM20=m
> CONFIG_VIDEO_RDACM21=m
> CONFIG_VIDEO_RJ54N1=m
> CONFIG_VIDEO_S5C73M3=m
> CONFIG_VIDEO_S5K4ECGX=m
> CONFIG_VIDEO_S5K5BAF=m
> CONFIG_VIDEO_S5K6A3=m
> CONFIG_VIDEO_S5K6AA=m
> CONFIG_VIDEO_SR030PC30=m
> CONFIG_VIDEO_VS6624=m
> CONFIG_VIDEO_CCS=m
> CONFIG_VIDEO_ET8EK8=m
> CONFIG_VIDEO_M5MOLS=m
> # end of Camera sensor devices
>
> #
> # Lens drivers
> #
> CONFIG_VIDEO_AD5820=m
> CONFIG_VIDEO_AK7375=m
> CONFIG_VIDEO_DW9714=m
> CONFIG_VIDEO_DW9768=m
> CONFIG_VIDEO_DW9807_VCM=m
> # end of Lens drivers
>
> #
> # Flash devices
> #
> CONFIG_VIDEO_ADP1653=m
> CONFIG_VIDEO_LM3560=m
> CONFIG_VIDEO_LM3646=m
> # end of Flash devices
>
> #
> # Audio decoders, processors and mixers
> #
> CONFIG_VIDEO_CS3308=m
> CONFIG_VIDEO_CS5345=m
> CONFIG_VIDEO_CS53L32A=m
> CONFIG_VIDEO_MSP3400=m
> CONFIG_VIDEO_SONY_BTF_MPX=m
> CONFIG_VIDEO_TDA1997X=m
> CONFIG_VIDEO_TDA7432=m
> CONFIG_VIDEO_TDA9840=m
> CONFIG_VIDEO_TEA6415C=m
> CONFIG_VIDEO_TEA6420=m
> CONFIG_VIDEO_TLV320AIC23B=m
> CONFIG_VIDEO_TVAUDIO=m
> CONFIG_VIDEO_UDA1342=m
> CONFIG_VIDEO_VP27SMPX=m
> CONFIG_VIDEO_WM8739=m
> CONFIG_VIDEO_WM8775=m
> # end of Audio decoders, processors and mixers
>
> #
> # RDS decoders
> #
> CONFIG_VIDEO_SAA6588=m
> # end of RDS decoders
>
> #
> # Video decoders
> #
> CONFIG_VIDEO_ADV7180=m
> CONFIG_VIDEO_ADV7183=m
> CONFIG_VIDEO_ADV7604=m
> CONFIG_VIDEO_ADV7604_CEC=y
> CONFIG_VIDEO_ADV7842=m
> CONFIG_VIDEO_ADV7842_CEC=y
> CONFIG_VIDEO_BT819=m
> CONFIG_VIDEO_BT856=m
> CONFIG_VIDEO_BT866=m
> CONFIG_VIDEO_KS0127=m
> CONFIG_VIDEO_ML86V7667=m
> CONFIG_VIDEO_SAA7110=m
> CONFIG_VIDEO_SAA711X=m
> CONFIG_VIDEO_TC358743=m
> CONFIG_VIDEO_TC358743_CEC=y
> CONFIG_VIDEO_TVP514X=m
> CONFIG_VIDEO_TVP5150=m
> CONFIG_VIDEO_TVP7002=m
> CONFIG_VIDEO_TW2804=m
> CONFIG_VIDEO_TW9903=m
> CONFIG_VIDEO_TW9906=m
> CONFIG_VIDEO_TW9910=m
> CONFIG_VIDEO_VPX3220=m
>
> #
> # Video and audio decoders
> #
> CONFIG_VIDEO_SAA717X=m
> CONFIG_VIDEO_CX25840=m
> # end of Video decoders
>
> #
> # Video encoders
> #
> CONFIG_VIDEO_AD9389B=m
> CONFIG_VIDEO_ADV7170=m
> CONFIG_VIDEO_ADV7175=m
> CONFIG_VIDEO_ADV7343=m
> CONFIG_VIDEO_ADV7393=m
> CONFIG_VIDEO_ADV7511=m
> # CONFIG_VIDEO_ADV7511_CEC is not set
> CONFIG_VIDEO_AK881X=m
> CONFIG_VIDEO_SAA7127=m
> CONFIG_VIDEO_SAA7185=m
> CONFIG_VIDEO_THS8200=m
> # end of Video encoders
>
> #
> # Video improvement chips
> #
> CONFIG_VIDEO_UPD64031A=m
> CONFIG_VIDEO_UPD64083=m
> # end of Video improvement chips
>
> #
> # Audio/Video compression chips
> #
> CONFIG_VIDEO_SAA6752HS=m
> # end of Audio/Video compression chips
>
> #
> # SDR tuner chips
> #
> CONFIG_SDR_MAX2175=m
> # end of SDR tuner chips
>
> #
> # Miscellaneous helper chips
> #
> CONFIG_VIDEO_I2C=m
> CONFIG_VIDEO_M52790=m
> CONFIG_VIDEO_ST_MIPID02=m
> CONFIG_VIDEO_THS7303=m
> # end of Miscellaneous helper chips
>
> #
> # Media SPI Adapters
> #
> CONFIG_CXD2880_SPI_DRV=m
> CONFIG_VIDEO_GS1662=m
> # end of Media SPI Adapters
>
> CONFIG_MEDIA_TUNER=m
>
> #
> # Customize TV tuners
> #
> CONFIG_MEDIA_TUNER_E4000=m
> CONFIG_MEDIA_TUNER_FC0011=m
> CONFIG_MEDIA_TUNER_FC0012=m
> CONFIG_MEDIA_TUNER_FC0013=m
> CONFIG_MEDIA_TUNER_FC2580=m
> CONFIG_MEDIA_TUNER_IT913X=m
> CONFIG_MEDIA_TUNER_M88RS6000T=m
> CONFIG_MEDIA_TUNER_MAX2165=m
> CONFIG_MEDIA_TUNER_MC44S803=m
> CONFIG_MEDIA_TUNER_MSI001=m
> CONFIG_MEDIA_TUNER_MT2060=m
> CONFIG_MEDIA_TUNER_MT2063=m
> CONFIG_MEDIA_TUNER_MT20XX=m
> CONFIG_MEDIA_TUNER_MT2131=m
> CONFIG_MEDIA_TUNER_MT2266=m
> CONFIG_MEDIA_TUNER_MXL301RF=m
> CONFIG_MEDIA_TUNER_MXL5005S=m
> CONFIG_MEDIA_TUNER_MXL5007T=m
> CONFIG_MEDIA_TUNER_QM1D1B0004=m
> CONFIG_MEDIA_TUNER_QM1D1C0042=m
> CONFIG_MEDIA_TUNER_QT1010=m
> CONFIG_MEDIA_TUNER_R820T=m
> CONFIG_MEDIA_TUNER_SI2157=m
> CONFIG_MEDIA_TUNER_SIMPLE=m
> CONFIG_MEDIA_TUNER_TDA18212=m
> CONFIG_MEDIA_TUNER_TDA18218=m
> CONFIG_MEDIA_TUNER_TDA18250=m
> CONFIG_MEDIA_TUNER_TDA18271=m
> CONFIG_MEDIA_TUNER_TDA827X=m
> CONFIG_MEDIA_TUNER_TDA8290=m
> CONFIG_MEDIA_TUNER_TDA9887=m
> CONFIG_MEDIA_TUNER_TEA5761=m
> CONFIG_MEDIA_TUNER_TEA5767=m
> CONFIG_MEDIA_TUNER_TUA9001=m
> CONFIG_MEDIA_TUNER_XC2028=m
> CONFIG_MEDIA_TUNER_XC4000=m
> CONFIG_MEDIA_TUNER_XC5000=m
> # end of Customize TV tuners
>
> #
> # Customise DVB Frontends
> #
>
> #
> # Multistandard (satellite) frontends
> #
> CONFIG_DVB_M88DS3103=m
> CONFIG_DVB_MXL5XX=m
> CONFIG_DVB_STB0899=m
> CONFIG_DVB_STB6100=m
> CONFIG_DVB_STV090x=m
> CONFIG_DVB_STV0910=m
> CONFIG_DVB_STV6110x=m
> CONFIG_DVB_STV6111=m
>
> #
> # Multistandard (cable + terrestrial) frontends
> #
> CONFIG_DVB_DRXK=m
> CONFIG_DVB_MN88472=m
> CONFIG_DVB_MN88473=m
> CONFIG_DVB_SI2165=m
> CONFIG_DVB_TDA18271C2DD=m
>
> #
> # DVB-S (satellite) frontends
> #
> CONFIG_DVB_CX24110=m
> CONFIG_DVB_CX24116=m
> CONFIG_DVB_CX24117=m
> CONFIG_DVB_CX24120=m
> CONFIG_DVB_CX24123=m
> CONFIG_DVB_DS3000=m
> CONFIG_DVB_MB86A16=m
> CONFIG_DVB_MT312=m
> CONFIG_DVB_S5H1420=m
> CONFIG_DVB_SI21XX=m
> CONFIG_DVB_STB6000=m
> CONFIG_DVB_STV0288=m
> CONFIG_DVB_STV0299=m
> CONFIG_DVB_STV0900=m
> CONFIG_DVB_STV6110=m
> CONFIG_DVB_TDA10071=m
> CONFIG_DVB_TDA10086=m
> CONFIG_DVB_TDA8083=m
> CONFIG_DVB_TDA8261=m
> CONFIG_DVB_TDA826X=m
> CONFIG_DVB_TS2020=m
> CONFIG_DVB_TUA6100=m
> CONFIG_DVB_TUNER_CX24113=m
> CONFIG_DVB_TUNER_ITD1000=m
> CONFIG_DVB_VES1X93=m
> CONFIG_DVB_ZL10036=m
> CONFIG_DVB_ZL10039=m
>
> #
> # DVB-T (terrestrial) frontends
> #
> CONFIG_DVB_AF9013=m
> CONFIG_DVB_AS102_FE=m
> CONFIG_DVB_CX22700=m
> CONFIG_DVB_CX22702=m
> CONFIG_DVB_CXD2820R=m
> CONFIG_DVB_CXD2841ER=m
> CONFIG_DVB_DIB3000MB=m
> CONFIG_DVB_DIB3000MC=m
> CONFIG_DVB_DIB7000M=m
> CONFIG_DVB_DIB7000P=m
> CONFIG_DVB_DIB9000=m
> CONFIG_DVB_DRXD=m
> CONFIG_DVB_EC100=m
> CONFIG_DVB_GP8PSK_FE=m
> CONFIG_DVB_L64781=m
> CONFIG_DVB_MT352=m
> CONFIG_DVB_NXT6000=m
> CONFIG_DVB_RTL2830=m
> CONFIG_DVB_RTL2832=m
> CONFIG_DVB_RTL2832_SDR=m
> CONFIG_DVB_S5H1432=m
> CONFIG_DVB_SI2168=m
> CONFIG_DVB_SP887X=m
> CONFIG_DVB_STV0367=m
> CONFIG_DVB_TDA10048=m
> CONFIG_DVB_TDA1004X=m
> CONFIG_DVB_ZD1301_DEMOD=m
> CONFIG_DVB_ZL10353=m
> CONFIG_DVB_CXD2880=m
>
> #
> # DVB-C (cable) frontends
> #
> CONFIG_DVB_STV0297=m
> CONFIG_DVB_TDA10021=m
> CONFIG_DVB_TDA10023=m
> CONFIG_DVB_VES1820=m
>
> #
> # ATSC (North American/Korean Terrestrial/Cable DTV) frontends
> #
> CONFIG_DVB_AU8522=m
> CONFIG_DVB_AU8522_DTV=m
> CONFIG_DVB_AU8522_V4L=m
> CONFIG_DVB_BCM3510=m
> CONFIG_DVB_LG2160=m
> CONFIG_DVB_LGDT3305=m
> CONFIG_DVB_LGDT3306A=m
> CONFIG_DVB_LGDT330X=m
> CONFIG_DVB_MXL692=m
> CONFIG_DVB_NXT200X=m
> CONFIG_DVB_OR51132=m
> CONFIG_DVB_OR51211=m
> CONFIG_DVB_S5H1409=m
> CONFIG_DVB_S5H1411=m
>
> #
> # ISDB-T (terrestrial) frontends
> #
> CONFIG_DVB_DIB8000=m
> CONFIG_DVB_MB86A20S=m
> CONFIG_DVB_S921=m
>
> #
> # ISDB-S (satellite) & ISDB-T (terrestrial) frontends
> #
> CONFIG_DVB_MN88443X=m
> CONFIG_DVB_TC90522=m
>
> #
> # Digital terrestrial only tuners/PLL
> #
> CONFIG_DVB_PLL=m
> CONFIG_DVB_TUNER_DIB0070=m
> CONFIG_DVB_TUNER_DIB0090=m
>
> #
> # SEC control devices for DVB-S
> #
> CONFIG_DVB_A8293=m
> CONFIG_DVB_AF9033=m
> CONFIG_DVB_ASCOT2E=m
> CONFIG_DVB_ATBM8830=m
> CONFIG_DVB_HELENE=m
> CONFIG_DVB_HORUS3A=m
> CONFIG_DVB_ISL6405=m
> CONFIG_DVB_ISL6421=m
> CONFIG_DVB_ISL6423=m
> CONFIG_DVB_IX2505V=m
> CONFIG_DVB_LGS8GL5=m
> CONFIG_DVB_LGS8GXX=m
> CONFIG_DVB_LNBH25=m
> CONFIG_DVB_LNBH29=m
> CONFIG_DVB_LNBP21=m
> CONFIG_DVB_LNBP22=m
> CONFIG_DVB_M88RS2000=m
> CONFIG_DVB_TDA665x=m
> CONFIG_DVB_DRX39XYJ=m
>
> #
> # Common Interface (EN50221) controller drivers
> #
> CONFIG_DVB_CXD2099=m
> CONFIG_DVB_SP2=m
> # end of Customise DVB Frontends
>
> #
> # Tools to develop new frontends
> #
> CONFIG_DVB_DUMMY_FE=m
> # end of Media ancillary drivers
>
> #
> # Graphics support
> #
> CONFIG_APERTURE_HELPERS=y
> CONFIG_AGP=y
> CONFIG_AGP_AMD64=y
> CONFIG_AGP_INTEL=y
> CONFIG_AGP_SIS=m
> CONFIG_AGP_VIA=y
> CONFIG_INTEL_GTT=y
> CONFIG_VGA_SWITCHEROO=y
> CONFIG_DRM=m
> CONFIG_DRM_MIPI_DBI=m
> CONFIG_DRM_MIPI_DSI=y
> # CONFIG_DRM_DEBUG_SELFTEST is not set
> CONFIG_DRM_KMS_HELPER=m
> # CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS is not set
> # CONFIG_DRM_DEBUG_MODESET_LOCK is not set
> CONFIG_DRM_FBDEV_EMULATION=y
> CONFIG_DRM_FBDEV_OVERALLOC=100
> # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> CONFIG_DRM_LOAD_EDID_FIRMWARE=y
> CONFIG_DRM_DISPLAY_HELPER=m
> CONFIG_DRM_DISPLAY_DP_HELPER=y
> CONFIG_DRM_DISPLAY_HDCP_HELPER=y
> CONFIG_DRM_DISPLAY_HDMI_HELPER=y
> CONFIG_DRM_DP_AUX_CHARDEV=y
> CONFIG_DRM_DP_CEC=y
> CONFIG_DRM_TTM=m
> CONFIG_DRM_BUDDY=m
> CONFIG_DRM_VRAM_HELPER=m
> CONFIG_DRM_TTM_HELPER=m
> CONFIG_DRM_GEM_CMA_HELPER=m
> CONFIG_DRM_GEM_SHMEM_HELPER=m
> CONFIG_DRM_SCHED=m
>
> #
> # I2C encoder or helper chips
> #
> CONFIG_DRM_I2C_CH7006=m
> CONFIG_DRM_I2C_SIL164=m
> CONFIG_DRM_I2C_NXP_TDA998X=m
> CONFIG_DRM_I2C_NXP_TDA9950=m
> # end of I2C encoder or helper chips
>
> #
> # ARM devices
> #
> # end of ARM devices
>
> CONFIG_DRM_RADEON=m
> # CONFIG_DRM_RADEON_USERPTR is not set
> CONFIG_DRM_AMDGPU=m
> CONFIG_DRM_AMDGPU_SI=y
> CONFIG_DRM_AMDGPU_CIK=y
> CONFIG_DRM_AMDGPU_USERPTR=y
>
> #
> # ACP (Audio CoProcessor) Configuration
> #
> CONFIG_DRM_AMD_ACP=y
> # end of ACP (Audio CoProcessor) Configuration
>
> #
> # Display Engine Configuration
> #
> CONFIG_DRM_AMD_DC=y
> CONFIG_DRM_AMD_DC_DCN=y
> CONFIG_DRM_AMD_DC_HDCP=y
> CONFIG_DRM_AMD_DC_SI=y
> # CONFIG_DEBUG_KERNEL_DC is not set
> CONFIG_DRM_AMD_SECURE_DISPLAY=y
> # end of Display Engine Configuration
>
> CONFIG_HSA_AMD=y
> CONFIG_HSA_AMD_SVM=y
> CONFIG_DRM_NOUVEAU=m
> # CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
> CONFIG_NOUVEAU_DEBUG=5
> CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> # CONFIG_NOUVEAU_DEBUG_MMU is not set
> # CONFIG_NOUVEAU_DEBUG_PUSH is not set
> CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> # CONFIG_DRM_NOUVEAU_SVM is not set
> CONFIG_DRM_I915=m
> CONFIG_DRM_I915_FORCE_PROBE=""
> CONFIG_DRM_I915_CAPTURE_ERROR=y
> CONFIG_DRM_I915_COMPRESS_ERROR=y
> CONFIG_DRM_I915_USERPTR=y
> CONFIG_DRM_I915_GVT=y
> CONFIG_DRM_I915_GVT_KVMGT=m
> CONFIG_DRM_I915_PXP=y
>
> #
> # drm/i915 Debugging
> #
> # CONFIG_DRM_I915_WERROR is not set
> # CONFIG_DRM_I915_DEBUG is not set
> # CONFIG_DRM_I915_DEBUG_MMIO is not set
> # CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set
> # CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set
> # CONFIG_DRM_I915_DEBUG_GUC is not set
> # CONFIG_DRM_I915_SELFTEST is not set
> # CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS is not set
> # CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set
> # CONFIG_DRM_I915_DEBUG_RUNTIME_PM is not set
> # end of drm/i915 Debugging
>
> #
> # drm/i915 Profile Guided Optimisation
> #
> CONFIG_DRM_I915_REQUEST_TIMEOUT=20000
> CONFIG_DRM_I915_FENCE_TIMEOUT=10000
> CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND=250
> CONFIG_DRM_I915_HEARTBEAT_INTERVAL=2500
> CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
> CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT=8000
> CONFIG_DRM_I915_STOP_TIMEOUT=100
> CONFIG_DRM_I915_TIMESLICE_DURATION=1
> # end of drm/i915 Profile Guided Optimisation
>
> CONFIG_DRM_VGEM=m
> CONFIG_DRM_VKMS=m
> CONFIG_DRM_VMWGFX=m
> CONFIG_DRM_VMWGFX_FBCON=y
> # CONFIG_DRM_VMWGFX_MKSSTATS is not set
> CONFIG_DRM_GMA500=m
> CONFIG_DRM_UDL=m
> CONFIG_DRM_AST=m
> CONFIG_DRM_MGAG200=m
> CONFIG_DRM_QXL=m
> CONFIG_DRM_VIRTIO_GPU=m
> CONFIG_DRM_PANEL=y
>
> #
> # Display Panels
> #
> CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN=m
> CONFIG_DRM_PANEL_WIDECHIPS_WS2401=m
> # end of Display Panels
>
> CONFIG_DRM_BRIDGE=y
> CONFIG_DRM_PANEL_BRIDGE=y
>
> #
> # Display Interface Bridges
> #
> CONFIG_DRM_ANALOGIX_ANX78XX=m
> CONFIG_DRM_ANALOGIX_DP=m
> # end of Display Interface Bridges
>
> # CONFIG_DRM_ETNAVIV is not set
> CONFIG_DRM_BOCHS=m
> CONFIG_DRM_CIRRUS_QEMU=m
> CONFIG_DRM_GM12U320=m
> CONFIG_DRM_PANEL_MIPI_DBI=m
> CONFIG_DRM_SIMPLEDRM=m
> CONFIG_TINYDRM_HX8357D=m
> CONFIG_TINYDRM_ILI9163=m
> CONFIG_TINYDRM_ILI9225=m
> CONFIG_TINYDRM_ILI9341=m
> CONFIG_TINYDRM_ILI9486=m
> CONFIG_TINYDRM_MI0283QT=m
> CONFIG_TINYDRM_REPAPER=m
> CONFIG_TINYDRM_ST7586=m
> CONFIG_TINYDRM_ST7735R=m
> CONFIG_DRM_XEN=y
> CONFIG_DRM_XEN_FRONTEND=m
> CONFIG_DRM_VBOXVIDEO=m
> CONFIG_DRM_GUD=m
> CONFIG_DRM_SSD130X=m
> CONFIG_DRM_SSD130X_I2C=m
> CONFIG_DRM_SSD130X_SPI=m
> CONFIG_DRM_HYPERV=m
> # CONFIG_DRM_LEGACY is not set
> CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y
> CONFIG_DRM_NOMODESET=y
> CONFIG_DRM_PRIVACY_SCREEN=y
>
> #
> # Frame buffer Devices
> #
> CONFIG_FB_CMDLINE=y
> CONFIG_FB_NOTIFY=y
> CONFIG_FB=y
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_DDC=m
> CONFIG_FB_CFB_FILLRECT=y
> CONFIG_FB_CFB_COPYAREA=y
> CONFIG_FB_CFB_IMAGEBLIT=y
> CONFIG_FB_SYS_FILLRECT=m
> CONFIG_FB_SYS_COPYAREA=m
> CONFIG_FB_SYS_IMAGEBLIT=m
> # CONFIG_FB_FOREIGN_ENDIAN is not set
> CONFIG_FB_SYS_FOPS=m
> CONFIG_FB_DEFERRED_IO=y
> CONFIG_FB_HECUBA=m
> CONFIG_FB_SVGALIB=m
> CONFIG_FB_BACKLIGHT=m
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_TILEBLITTING=y
>
> #
> # Frame buffer hardware drivers
> #
> CONFIG_FB_CIRRUS=m
> CONFIG_FB_PM2=m
> CONFIG_FB_PM2_FIFO_DISCONNECT=y
> CONFIG_FB_CYBER2000=m
> CONFIG_FB_CYBER2000_DDC=y
> CONFIG_FB_ARC=m
> CONFIG_FB_ASILIANT=y
> CONFIG_FB_IMSTT=y
> CONFIG_FB_VGA16=m
> CONFIG_FB_UVESA=m
> CONFIG_FB_VESA=y
> CONFIG_FB_EFI=y
> CONFIG_FB_N411=m
> CONFIG_FB_HGA=m
> CONFIG_FB_OPENCORES=m
> CONFIG_FB_S1D13XXX=m
> CONFIG_FB_NVIDIA=m
> CONFIG_FB_NVIDIA_I2C=y
> # CONFIG_FB_NVIDIA_DEBUG is not set
> CONFIG_FB_NVIDIA_BACKLIGHT=y
> CONFIG_FB_RIVA=m
> CONFIG_FB_RIVA_I2C=y
> # CONFIG_FB_RIVA_DEBUG is not set
> CONFIG_FB_RIVA_BACKLIGHT=y
> CONFIG_FB_I740=m
> CONFIG_FB_LE80578=m
> CONFIG_FB_CARILLO_RANCH=m
> CONFIG_FB_INTEL=m
> # CONFIG_FB_INTEL_DEBUG is not set
> CONFIG_FB_INTEL_I2C=y
> CONFIG_FB_MATROX=m
> CONFIG_FB_MATROX_MILLENIUM=y
> CONFIG_FB_MATROX_MYSTIQUE=y
> CONFIG_FB_MATROX_G=y
> CONFIG_FB_MATROX_I2C=m
> CONFIG_FB_MATROX_MAVEN=m
> CONFIG_FB_RADEON=m
> CONFIG_FB_RADEON_I2C=y
> CONFIG_FB_RADEON_BACKLIGHT=y
> # CONFIG_FB_RADEON_DEBUG is not set
> CONFIG_FB_ATY128=m
> CONFIG_FB_ATY128_BACKLIGHT=y
> CONFIG_FB_ATY=m
> CONFIG_FB_ATY_CT=y
> # CONFIG_FB_ATY_GENERIC_LCD is not set
> CONFIG_FB_ATY_GX=y
> CONFIG_FB_ATY_BACKLIGHT=y
> CONFIG_FB_S3=m
> CONFIG_FB_S3_DDC=y
> CONFIG_FB_SAVAGE=m
> CONFIG_FB_SAVAGE_I2C=y
> # CONFIG_FB_SAVAGE_ACCEL is not set
> CONFIG_FB_SIS=m
> CONFIG_FB_SIS_300=y
> CONFIG_FB_SIS_315=y
> CONFIG_FB_VIA=m
> # CONFIG_FB_VIA_DIRECT_PROCFS is not set
> CONFIG_FB_VIA_X_COMPATIBILITY=y
> CONFIG_FB_NEOMAGIC=m
> CONFIG_FB_KYRO=m
> CONFIG_FB_3DFX=m
> # CONFIG_FB_3DFX_ACCEL is not set
> # CONFIG_FB_3DFX_I2C is not set
> CONFIG_FB_VOODOO1=m
> CONFIG_FB_VT8623=m
> CONFIG_FB_TRIDENT=m
> CONFIG_FB_ARK=m
> CONFIG_FB_PM3=m
> CONFIG_FB_CARMINE=m
> CONFIG_FB_CARMINE_DRAM_EVAL=y
> # CONFIG_CARMINE_DRAM_CUSTOM is not set
> CONFIG_FB_SM501=m
> CONFIG_FB_SMSCUFX=m
> CONFIG_FB_UDL=m
> # CONFIG_FB_IBM_GXT4500 is not set
> # CONFIG_FB_VIRTUAL is not set
> CONFIG_XEN_FBDEV_FRONTEND=m
> CONFIG_FB_METRONOME=m
> CONFIG_FB_MB862XX=m
> CONFIG_FB_MB862XX_PCI_GDC=y
> CONFIG_FB_MB862XX_I2C=y
> CONFIG_FB_HYPERV=m
> CONFIG_FB_SIMPLE=m
> CONFIG_FB_SSD1307=m
> CONFIG_FB_SM712=m
> # end of Frame buffer Devices
>
> #
> # Backlight & LCD device support
> #
> CONFIG_LCD_CLASS_DEVICE=m
> CONFIG_LCD_L4F00242T03=m
> CONFIG_LCD_LMS283GF05=m
> CONFIG_LCD_LTV350QV=m
> CONFIG_LCD_ILI922X=m
> CONFIG_LCD_ILI9320=m
> CONFIG_LCD_TDO24M=m
> CONFIG_LCD_VGG2432A4=m
> CONFIG_LCD_PLATFORM=m
> CONFIG_LCD_AMS369FG06=m
> CONFIG_LCD_LMS501KF03=m
> CONFIG_LCD_HX8357=m
> CONFIG_LCD_OTM3225A=m
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> CONFIG_BACKLIGHT_KTD253=m
> CONFIG_BACKLIGHT_LM3533=m
> CONFIG_BACKLIGHT_CARILLO_RANCH=m
> CONFIG_BACKLIGHT_PWM=m
> CONFIG_BACKLIGHT_DA903X=m
> CONFIG_BACKLIGHT_DA9052=m
> CONFIG_BACKLIGHT_MAX8925=m
> CONFIG_BACKLIGHT_APPLE=m
> CONFIG_BACKLIGHT_QCOM_WLED=m
> CONFIG_BACKLIGHT_RT4831=m
> CONFIG_BACKLIGHT_SAHARA=m
> CONFIG_BACKLIGHT_WM831X=m
> CONFIG_BACKLIGHT_ADP5520=m
> CONFIG_BACKLIGHT_ADP8860=m
> CONFIG_BACKLIGHT_ADP8870=m
> CONFIG_BACKLIGHT_88PM860X=m
> CONFIG_BACKLIGHT_PCF50633=m
> CONFIG_BACKLIGHT_AAT2870=m
> CONFIG_BACKLIGHT_LM3630A=m
> CONFIG_BACKLIGHT_LM3639=m
> CONFIG_BACKLIGHT_LP855X=m
> CONFIG_BACKLIGHT_LP8788=m
> CONFIG_BACKLIGHT_PANDORA=m
> CONFIG_BACKLIGHT_SKY81452=m
> CONFIG_BACKLIGHT_AS3711=m
> CONFIG_BACKLIGHT_GPIO=m
> CONFIG_BACKLIGHT_LV5207LP=m
> CONFIG_BACKLIGHT_BD6107=m
> CONFIG_BACKLIGHT_ARCXCNN=m
> CONFIG_BACKLIGHT_RAVE_SP=m
> # end of Backlight & LCD device support
>
> CONFIG_VGASTATE=m
> CONFIG_VIDEOMODE_HELPERS=y
> CONFIG_HDMI=y
>
> #
> # Console display driver support
> #
> CONFIG_VGA_CONSOLE=y
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_DUMMY_CONSOLE_COLUMNS=80
> CONFIG_DUMMY_CONSOLE_ROWS=25
> CONFIG_FRAMEBUFFER_CONSOLE=y
> # CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y
> # end of Console display driver support
>
> # CONFIG_LOGO is not set
> # end of Graphics support
>
> CONFIG_SOUND=m
> CONFIG_SOUND_OSS_CORE=y
> # CONFIG_SOUND_OSS_CORE_PRECLAIM is not set
> CONFIG_SND=m
> CONFIG_SND_TIMER=m
> CONFIG_SND_PCM=m
> CONFIG_SND_PCM_ELD=y
> CONFIG_SND_PCM_IEC958=y
> CONFIG_SND_DMAENGINE_PCM=m
> CONFIG_SND_HWDEP=m
> CONFIG_SND_SEQ_DEVICE=m
> CONFIG_SND_RAWMIDI=m
> CONFIG_SND_COMPRESS_OFFLOAD=m
> CONFIG_SND_JACK=y
> CONFIG_SND_JACK_INPUT_DEV=y
> CONFIG_SND_OSSEMUL=y
> CONFIG_SND_MIXER_OSS=m
> # CONFIG_SND_PCM_OSS is not set
> CONFIG_SND_PCM_TIMER=y
> CONFIG_SND_HRTIMER=m
> CONFIG_SND_DYNAMIC_MINORS=y
> CONFIG_SND_MAX_CARDS=32
> CONFIG_SND_SUPPORT_OLD_API=y
> CONFIG_SND_PROC_FS=y
> CONFIG_SND_VERBOSE_PROCFS=y
> # CONFIG_SND_VERBOSE_PRINTK is not set
> # CONFIG_SND_CTL_FAST_LOOKUP is not set
> # CONFIG_SND_DEBUG is not set
> # CONFIG_SND_CTL_INPUT_VALIDATION is not set
> CONFIG_SND_VMASTER=y
> CONFIG_SND_DMA_SGBUF=y
> CONFIG_SND_CTL_LED=m
> CONFIG_SND_SEQUENCER=m
> CONFIG_SND_SEQ_DUMMY=m
> # CONFIG_SND_SEQUENCER_OSS is not set
> CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
> CONFIG_SND_SEQ_MIDI_EVENT=m
> CONFIG_SND_SEQ_MIDI=m
> CONFIG_SND_SEQ_MIDI_EMUL=m
> CONFIG_SND_SEQ_VIRMIDI=m
> CONFIG_SND_MPU401_UART=m
> CONFIG_SND_OPL3_LIB=m
> CONFIG_SND_OPL3_LIB_SEQ=m
> CONFIG_SND_VX_LIB=m
> CONFIG_SND_AC97_CODEC=m
> CONFIG_SND_DRIVERS=y
> CONFIG_SND_PCSP=m
> CONFIG_SND_DUMMY=m
> CONFIG_SND_ALOOP=m
> CONFIG_SND_VIRMIDI=m
> CONFIG_SND_MTPAV=m
> CONFIG_SND_MTS64=m
> CONFIG_SND_SERIAL_U16550=m
> CONFIG_SND_MPU401=m
> CONFIG_SND_PORTMAN2X4=m
> CONFIG_SND_AC97_POWER_SAVE=y
> CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
> CONFIG_SND_SB_COMMON=m
> CONFIG_SND_PCI=y
> CONFIG_SND_AD1889=m
> CONFIG_SND_ALS300=m
> CONFIG_SND_ALS4000=m
> CONFIG_SND_ALI5451=m
> CONFIG_SND_ASIHPI=m
> CONFIG_SND_ATIIXP=m
> CONFIG_SND_ATIIXP_MODEM=m
> CONFIG_SND_AU8810=m
> CONFIG_SND_AU8820=m
> CONFIG_SND_AU8830=m
> CONFIG_SND_AW2=m
> CONFIG_SND_AZT3328=m
> CONFIG_SND_BT87X=m
> # CONFIG_SND_BT87X_OVERCLOCK is not set
> CONFIG_SND_CA0106=m
> CONFIG_SND_CMIPCI=m
> CONFIG_SND_OXYGEN_LIB=m
> CONFIG_SND_OXYGEN=m
> CONFIG_SND_CS4281=m
> CONFIG_SND_CS46XX=m
> CONFIG_SND_CS46XX_NEW_DSP=y
> CONFIG_SND_CTXFI=m
> CONFIG_SND_DARLA20=m
> CONFIG_SND_GINA20=m
> CONFIG_SND_LAYLA20=m
> CONFIG_SND_DARLA24=m
> CONFIG_SND_GINA24=m
> CONFIG_SND_LAYLA24=m
> CONFIG_SND_MONA=m
> CONFIG_SND_MIA=m
> CONFIG_SND_ECHO3G=m
> CONFIG_SND_INDIGO=m
> CONFIG_SND_INDIGOIO=m
> CONFIG_SND_INDIGODJ=m
> CONFIG_SND_INDIGOIOX=m
> CONFIG_SND_INDIGODJX=m
> CONFIG_SND_EMU10K1=m
> CONFIG_SND_EMU10K1_SEQ=m
> CONFIG_SND_EMU10K1X=m
> CONFIG_SND_ENS1370=m
> CONFIG_SND_ENS1371=m
> CONFIG_SND_ES1938=m
> CONFIG_SND_ES1968=m
> CONFIG_SND_ES1968_INPUT=y
> CONFIG_SND_ES1968_RADIO=y
> CONFIG_SND_FM801=m
> CONFIG_SND_FM801_TEA575X_BOOL=y
> CONFIG_SND_HDSP=m
> CONFIG_SND_HDSPM=m
> CONFIG_SND_ICE1712=m
> CONFIG_SND_ICE1724=m
> CONFIG_SND_INTEL8X0=m
> CONFIG_SND_INTEL8X0M=m
> CONFIG_SND_KORG1212=m
> CONFIG_SND_LOLA=m
> CONFIG_SND_LX6464ES=m
> CONFIG_SND_MAESTRO3=m
> CONFIG_SND_MAESTRO3_INPUT=y
> CONFIG_SND_MIXART=m
> CONFIG_SND_NM256=m
> CONFIG_SND_PCXHR=m
> CONFIG_SND_RIPTIDE=m
> CONFIG_SND_RME32=m
> CONFIG_SND_RME96=m
> CONFIG_SND_RME9652=m
> CONFIG_SND_SONICVIBES=m
> CONFIG_SND_TRIDENT=m
> CONFIG_SND_VIA82XX=m
> CONFIG_SND_VIA82XX_MODEM=m
> CONFIG_SND_VIRTUOSO=m
> CONFIG_SND_VX222=m
> CONFIG_SND_YMFPCI=m
>
> #
> # HD-Audio
> #
> CONFIG_SND_HDA=m
> CONFIG_SND_HDA_GENERIC_LEDS=y
> CONFIG_SND_HDA_INTEL=m
> CONFIG_SND_HDA_HWDEP=y
> CONFIG_SND_HDA_RECONFIG=y
> CONFIG_SND_HDA_INPUT_BEEP=y
> CONFIG_SND_HDA_INPUT_BEEP_MODE=0
> CONFIG_SND_HDA_PATCH_LOADER=y
> CONFIG_SND_HDA_SCODEC_CS35L41=m
> CONFIG_SND_HDA_CS_DSP_CONTROLS=m
> CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
> CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
> CONFIG_SND_HDA_CODEC_REALTEK=m
> CONFIG_SND_HDA_CODEC_ANALOG=m
> CONFIG_SND_HDA_CODEC_SIGMATEL=m
> CONFIG_SND_HDA_CODEC_VIA=m
> CONFIG_SND_HDA_CODEC_HDMI=m
> CONFIG_SND_HDA_CODEC_CIRRUS=m
> CONFIG_SND_HDA_CODEC_CS8409=m
> CONFIG_SND_HDA_CODEC_CONEXANT=m
> CONFIG_SND_HDA_CODEC_CA0110=m
> CONFIG_SND_HDA_CODEC_CA0132=m
> CONFIG_SND_HDA_CODEC_CA0132_DSP=y
> CONFIG_SND_HDA_CODEC_CMEDIA=m
> CONFIG_SND_HDA_CODEC_SI3054=m
> CONFIG_SND_HDA_GENERIC=m
> CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1
> # CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM is not set
> # end of HD-Audio
>
> CONFIG_SND_HDA_CORE=m
> CONFIG_SND_HDA_DSP_LOADER=y
> CONFIG_SND_HDA_COMPONENT=y
> CONFIG_SND_HDA_I915=y
> CONFIG_SND_HDA_EXT_CORE=m
> CONFIG_SND_HDA_PREALLOC_SIZE=0
> CONFIG_SND_INTEL_NHLT=y
> CONFIG_SND_INTEL_DSP_CONFIG=m
> CONFIG_SND_INTEL_SOUNDWIRE_ACPI=m
> CONFIG_SND_INTEL_BYT_PREFER_SOF=y
> CONFIG_SND_SPI=y
> CONFIG_SND_USB=y
> CONFIG_SND_USB_AUDIO=m
> CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER=y
> CONFIG_SND_USB_UA101=m
> CONFIG_SND_USB_USX2Y=m
> CONFIG_SND_USB_CAIAQ=m
> CONFIG_SND_USB_CAIAQ_INPUT=y
> CONFIG_SND_USB_US122L=m
> CONFIG_SND_USB_6FIRE=m
> CONFIG_SND_USB_HIFACE=m
> CONFIG_SND_BCD2000=m
> CONFIG_SND_USB_LINE6=m
> CONFIG_SND_USB_POD=m
> CONFIG_SND_USB_PODHD=m
> CONFIG_SND_USB_TONEPORT=m
> CONFIG_SND_USB_VARIAX=m
> CONFIG_SND_FIREWIRE=y
> CONFIG_SND_FIREWIRE_LIB=m
> CONFIG_SND_DICE=m
> CONFIG_SND_OXFW=m
> CONFIG_SND_ISIGHT=m
> CONFIG_SND_FIREWORKS=m
> CONFIG_SND_BEBOB=m
> CONFIG_SND_FIREWIRE_DIGI00X=m
> CONFIG_SND_FIREWIRE_TASCAM=m
> CONFIG_SND_FIREWIRE_MOTU=m
> CONFIG_SND_FIREFACE=m
> CONFIG_SND_PCMCIA=y
> CONFIG_SND_VXPOCKET=m
> CONFIG_SND_PDAUDIOCF=m
> CONFIG_SND_SOC=m
> CONFIG_SND_SOC_AC97_BUS=y
> CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM=y
> CONFIG_SND_SOC_COMPRESS=y
> CONFIG_SND_SOC_TOPOLOGY=y
> CONFIG_SND_SOC_ACPI=m
> CONFIG_SND_SOC_ADI=m
> CONFIG_SND_SOC_ADI_AXI_I2S=m
> CONFIG_SND_SOC_ADI_AXI_SPDIF=m
> CONFIG_SND_SOC_AMD_ACP=m
> CONFIG_SND_SOC_AMD_CZ_DA7219MX98357_MACH=m
> CONFIG_SND_SOC_AMD_CZ_RT5645_MACH=m
> CONFIG_SND_SOC_AMD_ST_ES8336_MACH=m
> CONFIG_SND_SOC_AMD_ACP3x=m
> CONFIG_SND_SOC_AMD_RV_RT5682_MACH=m
> CONFIG_SND_SOC_AMD_RENOIR=m
> CONFIG_SND_SOC_AMD_RENOIR_MACH=m
> CONFIG_SND_SOC_AMD_ACP5x=m
> CONFIG_SND_SOC_AMD_VANGOGH_MACH=m
> CONFIG_SND_SOC_AMD_ACP6x=m
> CONFIG_SND_SOC_AMD_YC_MACH=m
> CONFIG_SND_AMD_ACP_CONFIG=m
> CONFIG_SND_SOC_AMD_ACP_COMMON=m
> CONFIG_SND_SOC_AMD_ACP_PDM=m
> CONFIG_SND_SOC_AMD_ACP_I2S=m
> CONFIG_SND_SOC_AMD_ACP_PCM=m
> CONFIG_SND_SOC_AMD_ACP_PCI=m
> CONFIG_SND_AMD_ASOC_RENOIR=m
> CONFIG_SND_AMD_ASOC_REMBRANDT=m
> CONFIG_SND_SOC_AMD_MACH_COMMON=m
> CONFIG_SND_SOC_AMD_LEGACY_MACH=m
> CONFIG_SND_SOC_AMD_SOF_MACH=m
> CONFIG_SND_SOC_AMD_RPL_ACP6x=m
> CONFIG_SND_ATMEL_SOC=m
> CONFIG_SND_BCM63XX_I2S_WHISTLER=m
> CONFIG_SND_DESIGNWARE_I2S=m
> CONFIG_SND_DESIGNWARE_PCM=y
>
> #
> # SoC Audio for Freescale CPUs
> #
>
> #
> # Common SoC Audio options for Freescale CPUs:
> #
> CONFIG_SND_SOC_FSL_ASRC=m
> CONFIG_SND_SOC_FSL_SAI=m
> CONFIG_SND_SOC_FSL_MQS=m
> CONFIG_SND_SOC_FSL_AUDMIX=m
> CONFIG_SND_SOC_FSL_SSI=m
> CONFIG_SND_SOC_FSL_SPDIF=m
> CONFIG_SND_SOC_FSL_ESAI=m
> CONFIG_SND_SOC_FSL_MICFIL=m
> CONFIG_SND_SOC_FSL_EASRC=m
> CONFIG_SND_SOC_FSL_XCVR=m
> CONFIG_SND_SOC_FSL_UTILS=m
> CONFIG_SND_SOC_FSL_RPMSG=m
> CONFIG_SND_SOC_IMX_AUDMUX=m
> # end of SoC Audio for Freescale CPUs
>
> CONFIG_SND_I2S_HI6210_I2S=m
> CONFIG_SND_SOC_IMG=y
> CONFIG_SND_SOC_IMG_I2S_IN=m
> CONFIG_SND_SOC_IMG_I2S_OUT=m
> CONFIG_SND_SOC_IMG_PARALLEL_OUT=m
> CONFIG_SND_SOC_IMG_SPDIF_IN=m
> CONFIG_SND_SOC_IMG_SPDIF_OUT=m
> CONFIG_SND_SOC_IMG_PISTACHIO_INTERNAL_DAC=m
> CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y
> CONFIG_SND_SOC_INTEL_SST=m
> CONFIG_SND_SOC_INTEL_CATPT=m
> CONFIG_SND_SST_ATOM_HIFI2_PLATFORM=m
> CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_PCI=m
> CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI=m
> # CONFIG_SND_SOC_INTEL_SKYLAKE is not set
> CONFIG_SND_SOC_INTEL_SKL=m
> CONFIG_SND_SOC_INTEL_APL=m
> CONFIG_SND_SOC_INTEL_KBL=m
> CONFIG_SND_SOC_INTEL_GLK=m
> # CONFIG_SND_SOC_INTEL_CNL is not set
> # CONFIG_SND_SOC_INTEL_CFL is not set
> # CONFIG_SND_SOC_INTEL_CML_H is not set
> # CONFIG_SND_SOC_INTEL_CML_LP is not set
> CONFIG_SND_SOC_INTEL_SKYLAKE_FAMILY=m
> CONFIG_SND_SOC_INTEL_SKYLAKE_SSP_CLK=m
> CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC=y
> CONFIG_SND_SOC_INTEL_SKYLAKE_COMMON=m
> CONFIG_SND_SOC_ACPI_INTEL_MATCH=m
> CONFIG_SND_SOC_INTEL_AVS=m
>
> #
> # Intel AVS Machine drivers
> #
>
> #
> # Available DSP configurations
> #
> CONFIG_SND_SOC_INTEL_AVS_MACH_DA7219=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_DMIC=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_HDAUDIO=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_I2S_TEST=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_MAX98357A=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_MAX98373=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_NAU8825=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_RT274=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_RT286=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_RT298=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_RT5682=m
> CONFIG_SND_SOC_INTEL_AVS_MACH_SSM4567=m
> # end of Intel AVS Machine drivers
>
> CONFIG_SND_SOC_INTEL_MACH=y
> CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES=y
> CONFIG_SND_SOC_INTEL_HDA_DSP_COMMON=m
> CONFIG_SND_SOC_INTEL_SOF_MAXIM_COMMON=m
> CONFIG_SND_SOC_INTEL_SOF_REALTEK_COMMON=m
> CONFIG_SND_SOC_INTEL_SOF_CIRRUS_COMMON=m
> CONFIG_SND_SOC_INTEL_HASWELL_MACH=m
> CONFIG_SND_SOC_INTEL_BDW_RT5650_MACH=m
> CONFIG_SND_SOC_INTEL_BDW_RT5677_MACH=m
> CONFIG_SND_SOC_INTEL_BROADWELL_MACH=m
> CONFIG_SND_SOC_INTEL_BYTCR_RT5640_MACH=m
> CONFIG_SND_SOC_INTEL_BYTCR_RT5651_MACH=m
> CONFIG_SND_SOC_INTEL_BYTCR_WM5102_MACH=m
> CONFIG_SND_SOC_INTEL_CHT_BSW_RT5672_MACH=m
> CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH=m
> CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH=m
> CONFIG_SND_SOC_INTEL_CHT_BSW_NAU8824_MACH=m
> CONFIG_SND_SOC_INTEL_BYT_CHT_CX2072X_MACH=m
> CONFIG_SND_SOC_INTEL_BYT_CHT_DA7213_MACH=m
> CONFIG_SND_SOC_INTEL_BYT_CHT_ES8316_MACH=m
> # CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH is not set
> CONFIG_SND_SOC_INTEL_SKL_RT286_MACH=m
> CONFIG_SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH=m
> CONFIG_SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH=m
> CONFIG_SND_SOC_INTEL_DA7219_MAX98357A_GENERIC=m
> CONFIG_SND_SOC_INTEL_BXT_DA7219_MAX98357A_COMMON=m
> CONFIG_SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH=m
> CONFIG_SND_SOC_INTEL_BXT_RT298_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_WM8804_MACH=m
> CONFIG_SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH=m
> CONFIG_SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH=m
> CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98357A_MACH=m
> CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98927_MACH=m
> CONFIG_SND_SOC_INTEL_KBL_RT5660_MACH=m
> CONFIG_SND_SOC_INTEL_GLK_DA7219_MAX98357A_MACH=m
> CONFIG_SND_SOC_INTEL_GLK_RT5682_MAX98357A_MACH=m
> CONFIG_SND_SOC_INTEL_SKL_HDA_DSP_GENERIC_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_RT5682_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_CS42L42_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_PCM512x_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_ES8336_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_NAU8825_MACH=m
> CONFIG_SND_SOC_INTEL_CML_LP_DA7219_MAX98357A_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_DA7219_MAX98373_MACH=m
> CONFIG_SND_SOC_INTEL_SOF_SSP_AMP_MACH=m
> CONFIG_SND_SOC_INTEL_EHL_RT5660_MACH=m
> CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=m
> CONFIG_SND_SOC_MTK_BTCVSD=m
> CONFIG_SND_SOC_SOF_TOPLEVEL=y
> CONFIG_SND_SOC_SOF_PCI_DEV=m
> CONFIG_SND_SOC_SOF_PCI=m
> CONFIG_SND_SOC_SOF_ACPI=m
> CONFIG_SND_SOC_SOF_ACPI_DEV=m
> CONFIG_SND_SOC_SOF_DEBUG_PROBES=m
> CONFIG_SND_SOC_SOF_CLIENT=m
> # CONFIG_SND_SOC_SOF_DEVELOPER_SUPPORT is not set
> CONFIG_SND_SOC_SOF=m
> CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE=y
> CONFIG_SND_SOC_SOF_IPC3=y
> CONFIG_SND_SOC_SOF_INTEL_IPC4=y
> CONFIG_SND_SOC_SOF_AMD_TOPLEVEL=m
> CONFIG_SND_SOC_SOF_AMD_COMMON=m
> CONFIG_SND_SOC_SOF_AMD_RENOIR=m
> CONFIG_SND_SOC_SOF_INTEL_TOPLEVEL=y
> CONFIG_SND_SOC_SOF_INTEL_HIFI_EP_IPC=m
> CONFIG_SND_SOC_SOF_INTEL_ATOM_HIFI_EP=m
> CONFIG_SND_SOC_SOF_INTEL_COMMON=m
> CONFIG_SND_SOC_SOF_BAYTRAIL=m
> CONFIG_SND_SOC_SOF_BROADWELL=m
> CONFIG_SND_SOC_SOF_MERRIFIELD=m
> CONFIG_SND_SOC_SOF_INTEL_APL=m
> CONFIG_SND_SOC_SOF_APOLLOLAKE=m
> CONFIG_SND_SOC_SOF_GEMINILAKE=m
> CONFIG_SND_SOC_SOF_INTEL_CNL=m
> CONFIG_SND_SOC_SOF_CANNONLAKE=m
> CONFIG_SND_SOC_SOF_COFFEELAKE=m
> CONFIG_SND_SOC_SOF_COMETLAKE=m
> CONFIG_SND_SOC_SOF_INTEL_ICL=m
> CONFIG_SND_SOC_SOF_ICELAKE=m
> CONFIG_SND_SOC_SOF_JASPERLAKE=m
> CONFIG_SND_SOC_SOF_INTEL_TGL=m
> CONFIG_SND_SOC_SOF_TIGERLAKE=m
> CONFIG_SND_SOC_SOF_ELKHARTLAKE=m
> CONFIG_SND_SOC_SOF_ALDERLAKE=m
> CONFIG_SND_SOC_SOF_INTEL_MTL=m
> CONFIG_SND_SOC_SOF_METEORLAKE=m
> CONFIG_SND_SOC_SOF_HDA_COMMON=m
> CONFIG_SND_SOC_SOF_HDA_LINK=y
> CONFIG_SND_SOC_SOF_HDA_AUDIO_CODEC=y
> CONFIG_SND_SOC_SOF_HDA_LINK_BASELINE=m
> CONFIG_SND_SOC_SOF_HDA=m
> CONFIG_SND_SOC_SOF_HDA_PROBES=m
> CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE=m
> CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE=m
> CONFIG_SND_SOC_SOF_XTENSA=m
>
> #
> # STMicroelectronics STM32 SOC audio support
> #
> # end of STMicroelectronics STM32 SOC audio support
>
> CONFIG_SND_SOC_XILINX_I2S=m
> CONFIG_SND_SOC_XILINX_AUDIO_FORMATTER=m
> CONFIG_SND_SOC_XILINX_SPDIF=m
> CONFIG_SND_SOC_XTFPGA_I2S=m
> CONFIG_SND_SOC_I2C_AND_SPI=m
>
> #
> # CODEC drivers
> #
> CONFIG_SND_SOC_ARIZONA=m
> CONFIG_SND_SOC_WM_ADSP=m
> CONFIG_SND_SOC_AC97_CODEC=m
> CONFIG_SND_SOC_ADAU_UTILS=m
> CONFIG_SND_SOC_ADAU1372=m
> CONFIG_SND_SOC_ADAU1372_I2C=m
> CONFIG_SND_SOC_ADAU1372_SPI=m
> CONFIG_SND_SOC_ADAU1701=m
> CONFIG_SND_SOC_ADAU17X1=m
> CONFIG_SND_SOC_ADAU1761=m
> CONFIG_SND_SOC_ADAU1761_I2C=m
> CONFIG_SND_SOC_ADAU1761_SPI=m
> CONFIG_SND_SOC_ADAU7002=m
> CONFIG_SND_SOC_ADAU7118=m
> CONFIG_SND_SOC_ADAU7118_HW=m
> CONFIG_SND_SOC_ADAU7118_I2C=m
> CONFIG_SND_SOC_AK4104=m
> CONFIG_SND_SOC_AK4118=m
> CONFIG_SND_SOC_AK4375=m
> CONFIG_SND_SOC_AK4458=m
> CONFIG_SND_SOC_AK4554=m
> CONFIG_SND_SOC_AK4613=m
> CONFIG_SND_SOC_AK4642=m
> CONFIG_SND_SOC_AK5386=m
> CONFIG_SND_SOC_AK5558=m
> CONFIG_SND_SOC_ALC5623=m
> CONFIG_SND_SOC_AW8738=m
> CONFIG_SND_SOC_BD28623=m
> CONFIG_SND_SOC_BT_SCO=m
> CONFIG_SND_SOC_CROS_EC_CODEC=m
> CONFIG_SND_SOC_CS35L32=m
> CONFIG_SND_SOC_CS35L33=m
> CONFIG_SND_SOC_CS35L34=m
> CONFIG_SND_SOC_CS35L35=m
> CONFIG_SND_SOC_CS35L36=m
> CONFIG_SND_SOC_CS35L41_LIB=m
> CONFIG_SND_SOC_CS35L41=m
> CONFIG_SND_SOC_CS35L41_SPI=m
> CONFIG_SND_SOC_CS35L41_I2C=m
> CONFIG_SND_SOC_CS35L45_TABLES=m
> CONFIG_SND_SOC_CS35L45=m
> CONFIG_SND_SOC_CS35L45_SPI=m
> CONFIG_SND_SOC_CS35L45_I2C=m
> CONFIG_SND_SOC_CS42L42=m
> CONFIG_SND_SOC_CS42L51=m
> CONFIG_SND_SOC_CS42L51_I2C=m
> CONFIG_SND_SOC_CS42L52=m
> CONFIG_SND_SOC_CS42L56=m
> CONFIG_SND_SOC_CS42L73=m
> CONFIG_SND_SOC_CS4234=m
> CONFIG_SND_SOC_CS4265=m
> CONFIG_SND_SOC_CS4270=m
> CONFIG_SND_SOC_CS4271=m
> CONFIG_SND_SOC_CS4271_I2C=m
> CONFIG_SND_SOC_CS4271_SPI=m
> CONFIG_SND_SOC_CS42XX8=m
> CONFIG_SND_SOC_CS42XX8_I2C=m
> CONFIG_SND_SOC_CS43130=m
> CONFIG_SND_SOC_CS4341=m
> CONFIG_SND_SOC_CS4349=m
> CONFIG_SND_SOC_CS53L30=m
> CONFIG_SND_SOC_CX2072X=m
> CONFIG_SND_SOC_DA7213=m
> CONFIG_SND_SOC_DA7219=m
> CONFIG_SND_SOC_DMIC=m
> CONFIG_SND_SOC_HDMI_CODEC=m
> CONFIG_SND_SOC_ES7134=m
> CONFIG_SND_SOC_ES7241=m
> CONFIG_SND_SOC_ES8316=m
> CONFIG_SND_SOC_ES8328=m
> CONFIG_SND_SOC_ES8328_I2C=m
> CONFIG_SND_SOC_ES8328_SPI=m
> CONFIG_SND_SOC_GTM601=m
> CONFIG_SND_SOC_HDAC_HDMI=m
> CONFIG_SND_SOC_HDAC_HDA=m
> CONFIG_SND_SOC_HDA=m
> CONFIG_SND_SOC_ICS43432=m
> CONFIG_SND_SOC_INNO_RK3036=m
> CONFIG_SND_SOC_MAX98088=m
> CONFIG_SND_SOC_MAX98090=m
> CONFIG_SND_SOC_MAX98357A=m
> CONFIG_SND_SOC_MAX98504=m
> CONFIG_SND_SOC_MAX9867=m
> CONFIG_SND_SOC_MAX98927=m
> CONFIG_SND_SOC_MAX98520=m
> CONFIG_SND_SOC_MAX98373=m
> CONFIG_SND_SOC_MAX98373_I2C=m
> CONFIG_SND_SOC_MAX98373_SDW=m
> CONFIG_SND_SOC_MAX98390=m
> CONFIG_SND_SOC_MAX98396=m
> CONFIG_SND_SOC_MAX9860=m
> CONFIG_SND_SOC_MSM8916_WCD_ANALOG=m
> CONFIG_SND_SOC_MSM8916_WCD_DIGITAL=m
> CONFIG_SND_SOC_PCM1681=m
> CONFIG_SND_SOC_PCM1789=m
> CONFIG_SND_SOC_PCM1789_I2C=m
> CONFIG_SND_SOC_PCM179X=m
> CONFIG_SND_SOC_PCM179X_I2C=m
> CONFIG_SND_SOC_PCM179X_SPI=m
> CONFIG_SND_SOC_PCM186X=m
> CONFIG_SND_SOC_PCM186X_I2C=m
> CONFIG_SND_SOC_PCM186X_SPI=m
> CONFIG_SND_SOC_PCM3060=m
> CONFIG_SND_SOC_PCM3060_I2C=m
> CONFIG_SND_SOC_PCM3060_SPI=m
> CONFIG_SND_SOC_PCM3168A=m
> CONFIG_SND_SOC_PCM3168A_I2C=m
> CONFIG_SND_SOC_PCM3168A_SPI=m
> CONFIG_SND_SOC_PCM5102A=m
> CONFIG_SND_SOC_PCM512x=m
> CONFIG_SND_SOC_PCM512x_I2C=m
> CONFIG_SND_SOC_PCM512x_SPI=m
> CONFIG_SND_SOC_RK3328=m
> CONFIG_SND_SOC_RL6231=m
> CONFIG_SND_SOC_RL6347A=m
> CONFIG_SND_SOC_RT274=m
> CONFIG_SND_SOC_RT286=m
> CONFIG_SND_SOC_RT298=m
> CONFIG_SND_SOC_RT1011=m
> CONFIG_SND_SOC_RT1015=m
> CONFIG_SND_SOC_RT1015P=m
> CONFIG_SND_SOC_RT1019=m
> CONFIG_SND_SOC_RT1308=m
> CONFIG_SND_SOC_RT1308_SDW=m
> CONFIG_SND_SOC_RT1316_SDW=m
> CONFIG_SND_SOC_RT5514=m
> CONFIG_SND_SOC_RT5514_SPI=m
> CONFIG_SND_SOC_RT5616=m
> CONFIG_SND_SOC_RT5631=m
> CONFIG_SND_SOC_RT5640=m
> CONFIG_SND_SOC_RT5645=m
> CONFIG_SND_SOC_RT5651=m
> CONFIG_SND_SOC_RT5659=m
> CONFIG_SND_SOC_RT5660=m
> CONFIG_SND_SOC_RT5663=m
> CONFIG_SND_SOC_RT5670=m
> CONFIG_SND_SOC_RT5677=m
> CONFIG_SND_SOC_RT5677_SPI=m
> CONFIG_SND_SOC_RT5682=m
> CONFIG_SND_SOC_RT5682_I2C=m
> CONFIG_SND_SOC_RT5682_SDW=m
> CONFIG_SND_SOC_RT5682S=m
> CONFIG_SND_SOC_RT700=m
> CONFIG_SND_SOC_RT700_SDW=m
> CONFIG_SND_SOC_RT711=m
> CONFIG_SND_SOC_RT711_SDW=m
> CONFIG_SND_SOC_RT711_SDCA_SDW=m
> CONFIG_SND_SOC_RT715=m
> CONFIG_SND_SOC_RT715_SDW=m
> CONFIG_SND_SOC_RT715_SDCA_SDW=m
> CONFIG_SND_SOC_RT9120=m
> CONFIG_SND_SOC_SDW_MOCKUP=m
> CONFIG_SND_SOC_SGTL5000=m
> CONFIG_SND_SOC_SI476X=m
> CONFIG_SND_SOC_SIGMADSP=m
> CONFIG_SND_SOC_SIGMADSP_I2C=m
> CONFIG_SND_SOC_SIGMADSP_REGMAP=m
> CONFIG_SND_SOC_SIMPLE_AMPLIFIER=m
> CONFIG_SND_SOC_SIMPLE_MUX=m
> CONFIG_SND_SOC_SPDIF=m
> CONFIG_SND_SOC_SSM2305=m
> CONFIG_SND_SOC_SSM2518=m
> CONFIG_SND_SOC_SSM2602=m
> CONFIG_SND_SOC_SSM2602_SPI=m
> CONFIG_SND_SOC_SSM2602_I2C=m
> CONFIG_SND_SOC_SSM4567=m
> CONFIG_SND_SOC_STA32X=m
> CONFIG_SND_SOC_STA350=m
> CONFIG_SND_SOC_STI_SAS=m
> CONFIG_SND_SOC_TAS2552=m
> CONFIG_SND_SOC_TAS2562=m
> CONFIG_SND_SOC_TAS2764=m
> CONFIG_SND_SOC_TAS2770=m
> CONFIG_SND_SOC_TAS2780=m
> CONFIG_SND_SOC_TAS5086=m
> CONFIG_SND_SOC_TAS571X=m
> CONFIG_SND_SOC_TAS5720=m
> CONFIG_SND_SOC_TAS5805M=m
> CONFIG_SND_SOC_TAS6424=m
> CONFIG_SND_SOC_TDA7419=m
> CONFIG_SND_SOC_TFA9879=m
> CONFIG_SND_SOC_TFA989X=m
> CONFIG_SND_SOC_TLV320ADC3XXX=m
> CONFIG_SND_SOC_TLV320AIC23=m
> CONFIG_SND_SOC_TLV320AIC23_I2C=m
> CONFIG_SND_SOC_TLV320AIC23_SPI=m
> CONFIG_SND_SOC_TLV320AIC31XX=m
> CONFIG_SND_SOC_TLV320AIC32X4=m
> CONFIG_SND_SOC_TLV320AIC32X4_I2C=m
> CONFIG_SND_SOC_TLV320AIC32X4_SPI=m
> CONFIG_SND_SOC_TLV320AIC3X=m
> CONFIG_SND_SOC_TLV320AIC3X_I2C=m
> CONFIG_SND_SOC_TLV320AIC3X_SPI=m
> CONFIG_SND_SOC_TLV320ADCX140=m
> CONFIG_SND_SOC_TS3A227E=m
> CONFIG_SND_SOC_TSCS42XX=m
> CONFIG_SND_SOC_TSCS454=m
> CONFIG_SND_SOC_UDA1334=m
> CONFIG_SND_SOC_WCD9335=m
> CONFIG_SND_SOC_WCD_MBHC=m
> CONFIG_SND_SOC_WCD934X=m
> CONFIG_SND_SOC_WCD938X=m
> CONFIG_SND_SOC_WCD938X_SDW=m
> CONFIG_SND_SOC_WM5102=m
> CONFIG_SND_SOC_WM8510=m
> CONFIG_SND_SOC_WM8523=m
> CONFIG_SND_SOC_WM8524=m
> CONFIG_SND_SOC_WM8580=m
> CONFIG_SND_SOC_WM8711=m
> CONFIG_SND_SOC_WM8728=m
> CONFIG_SND_SOC_WM8731=m
> CONFIG_SND_SOC_WM8731_I2C=m
> CONFIG_SND_SOC_WM8731_SPI=m
> CONFIG_SND_SOC_WM8737=m
> CONFIG_SND_SOC_WM8741=m
> CONFIG_SND_SOC_WM8750=m
> CONFIG_SND_SOC_WM8753=m
> CONFIG_SND_SOC_WM8770=m
> CONFIG_SND_SOC_WM8776=m
> CONFIG_SND_SOC_WM8782=m
> CONFIG_SND_SOC_WM8804=m
> CONFIG_SND_SOC_WM8804_I2C=m
> CONFIG_SND_SOC_WM8804_SPI=m
> CONFIG_SND_SOC_WM8903=m
> CONFIG_SND_SOC_WM8904=m
> CONFIG_SND_SOC_WM8940=m
> CONFIG_SND_SOC_WM8960=m
> CONFIG_SND_SOC_WM8962=m
> CONFIG_SND_SOC_WM8974=m
> CONFIG_SND_SOC_WM8978=m
> CONFIG_SND_SOC_WM8985=m
> CONFIG_SND_SOC_WSA881X=m
> CONFIG_SND_SOC_WSA883X=m
> CONFIG_SND_SOC_ZL38060=m
> CONFIG_SND_SOC_MAX9759=m
> CONFIG_SND_SOC_MT6351=m
> CONFIG_SND_SOC_MT6358=m
> CONFIG_SND_SOC_MT6660=m
> CONFIG_SND_SOC_NAU8315=m
> CONFIG_SND_SOC_NAU8540=m
> CONFIG_SND_SOC_NAU8810=m
> CONFIG_SND_SOC_NAU8821=m
> CONFIG_SND_SOC_NAU8822=m
> CONFIG_SND_SOC_NAU8824=m
> CONFIG_SND_SOC_NAU8825=m
> CONFIG_SND_SOC_TPA6130A2=m
> CONFIG_SND_SOC_LPASS_MACRO_COMMON=m
> CONFIG_SND_SOC_LPASS_WSA_MACRO=m
> CONFIG_SND_SOC_LPASS_VA_MACRO=m
> CONFIG_SND_SOC_LPASS_RX_MACRO=m
> CONFIG_SND_SOC_LPASS_TX_MACRO=m
> # end of CODEC drivers
>
> CONFIG_SND_SIMPLE_CARD_UTILS=m
> CONFIG_SND_SIMPLE_CARD=m
> CONFIG_SND_X86=y
> CONFIG_HDMI_LPE_AUDIO=m
> CONFIG_SND_SYNTH_EMUX=m
> CONFIG_SND_XEN_FRONTEND=m
> CONFIG_SND_VIRTIO=m
> CONFIG_AC97_BUS=m
>
> #
> # HID support
> #
> CONFIG_HID=m
> CONFIG_HID_BATTERY_STRENGTH=y
> CONFIG_HIDRAW=y
> CONFIG_UHID=m
> CONFIG_HID_GENERIC=m
>
> #
> # Special HID drivers
> #
> CONFIG_HID_A4TECH=m
> CONFIG_HID_ACCUTOUCH=m
> CONFIG_HID_ACRUX=m
> CONFIG_HID_ACRUX_FF=y
> CONFIG_HID_APPLE=m
> CONFIG_HID_APPLEIR=m
> CONFIG_HID_ASUS=m
> CONFIG_HID_AUREAL=m
> CONFIG_HID_BELKIN=m
> CONFIG_HID_BETOP_FF=m
> CONFIG_HID_BIGBEN_FF=m
> CONFIG_HID_CHERRY=m
> CONFIG_HID_CHICONY=m
> CONFIG_HID_CORSAIR=m
> CONFIG_HID_COUGAR=m
> CONFIG_HID_MACALLY=m
> CONFIG_HID_PRODIKEYS=m
> CONFIG_HID_CMEDIA=m
> CONFIG_HID_CP2112=m
> CONFIG_HID_CREATIVE_SB0540=m
> CONFIG_HID_CYPRESS=m
> CONFIG_HID_DRAGONRISE=m
> CONFIG_DRAGONRISE_FF=y
> CONFIG_HID_EMS_FF=m
> CONFIG_HID_ELAN=m
> CONFIG_HID_ELECOM=m
> CONFIG_HID_ELO=m
> CONFIG_HID_EZKEY=m
> CONFIG_HID_FT260=m
> CONFIG_HID_GEMBIRD=m
> CONFIG_HID_GFRM=m
> CONFIG_HID_GLORIOUS=m
> CONFIG_HID_HOLTEK=m
> CONFIG_HOLTEK_FF=y
> CONFIG_HID_VIVALDI_COMMON=m
> CONFIG_HID_GOOGLE_HAMMER=m
> CONFIG_HID_VIVALDI=m
> CONFIG_HID_GT683R=m
> CONFIG_HID_KEYTOUCH=m
> CONFIG_HID_KYE=m
> CONFIG_HID_UCLOGIC=m
> CONFIG_HID_WALTOP=m
> CONFIG_HID_VIEWSONIC=m
> CONFIG_HID_XIAOMI=m
> CONFIG_HID_GYRATION=m
> CONFIG_HID_ICADE=m
> CONFIG_HID_ITE=m
> CONFIG_HID_JABRA=m
> CONFIG_HID_TWINHAN=m
> CONFIG_HID_KENSINGTON=m
> CONFIG_HID_LCPOWER=m
> CONFIG_HID_LED=m
> CONFIG_HID_LENOVO=m
> CONFIG_HID_LETSKETCH=m
> CONFIG_HID_LOGITECH=m
> CONFIG_HID_LOGITECH_DJ=m
> CONFIG_HID_LOGITECH_HIDPP=m
> CONFIG_LOGITECH_FF=y
> CONFIG_LOGIRUMBLEPAD2_FF=y
> CONFIG_LOGIG940_FF=y
> CONFIG_LOGIWHEELS_FF=y
> CONFIG_HID_MAGICMOUSE=m
> CONFIG_HID_MALTRON=m
> CONFIG_HID_MAYFLASH=m
> CONFIG_HID_MEGAWORLD_FF=m
> CONFIG_HID_REDRAGON=m
> CONFIG_HID_MICROSOFT=m
> CONFIG_HID_MONTEREY=m
> CONFIG_HID_MULTITOUCH=m
> CONFIG_HID_NINTENDO=m
> CONFIG_NINTENDO_FF=y
> CONFIG_HID_NTI=m
> CONFIG_HID_NTRIG=m
> CONFIG_HID_ORTEK=m
> CONFIG_HID_PANTHERLORD=m
> CONFIG_PANTHERLORD_FF=y
> CONFIG_HID_PENMOUNT=m
> CONFIG_HID_PETALYNX=m
> CONFIG_HID_PICOLCD=m
> CONFIG_HID_PICOLCD_FB=y
> CONFIG_HID_PICOLCD_BACKLIGHT=y
> CONFIG_HID_PICOLCD_LCD=y
> CONFIG_HID_PICOLCD_LEDS=y
> CONFIG_HID_PICOLCD_CIR=y
> CONFIG_HID_PLANTRONICS=m
> CONFIG_HID_PLAYSTATION=m
> CONFIG_PLAYSTATION_FF=y
> CONFIG_HID_RAZER=m
> CONFIG_HID_PRIMAX=m
> CONFIG_HID_RETRODE=m
> CONFIG_HID_ROCCAT=m
> CONFIG_HID_SAITEK=m
> CONFIG_HID_SAMSUNG=m
> CONFIG_HID_SEMITEK=m
> CONFIG_HID_SIGMAMICRO=m
> CONFIG_HID_SONY=m
> CONFIG_SONY_FF=y
> CONFIG_HID_SPEEDLINK=m
> CONFIG_HID_STEAM=m
> CONFIG_HID_STEELSERIES=m
> CONFIG_HID_SUNPLUS=m
> CONFIG_HID_RMI=m
> CONFIG_HID_GREENASIA=m
> CONFIG_GREENASIA_FF=y
> CONFIG_HID_HYPERV_MOUSE=m
> CONFIG_HID_SMARTJOYPLUS=m
> CONFIG_SMARTJOYPLUS_FF=y
> CONFIG_HID_TIVO=m
> CONFIG_HID_TOPSEED=m
> CONFIG_HID_THINGM=m
> CONFIG_HID_THRUSTMASTER=m
> CONFIG_THRUSTMASTER_FF=y
> CONFIG_HID_UDRAW_PS3=m
> CONFIG_HID_U2FZERO=m
> CONFIG_HID_WACOM=m
> CONFIG_HID_WIIMOTE=m
> CONFIG_HID_XINMO=m
> CONFIG_HID_ZEROPLUS=m
> CONFIG_ZEROPLUS_FF=y
> CONFIG_HID_ZYDACRON=m
> CONFIG_HID_SENSOR_HUB=m
> CONFIG_HID_SENSOR_CUSTOM_SENSOR=m
> CONFIG_HID_ALPS=m
> CONFIG_HID_MCP2221=m
> # end of Special HID drivers
>
> #
> # USB HID support
> #
> CONFIG_USB_HID=m
> CONFIG_HID_PID=y
> CONFIG_USB_HIDDEV=y
>
> #
> # USB HID Boot Protocol drivers
> #
> CONFIG_USB_KBD=m
> CONFIG_USB_MOUSE=m
> # end of USB HID Boot Protocol drivers
> # end of USB HID support
>
> #
> # I2C HID support
> #
> CONFIG_I2C_HID_ACPI=m
> # end of I2C HID support
>
> CONFIG_I2C_HID_CORE=m
>
> #
> # Intel ISH HID support
> #
> CONFIG_INTEL_ISH_HID=m
> CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER=m
> # end of Intel ISH HID support
>
> #
> # AMD SFH HID Support
> #
> CONFIG_AMD_SFH_HID=m
> # end of AMD SFH HID Support
>
> #
> # Surface System Aggregator Module HID support
> #
> CONFIG_SURFACE_HID=m
> CONFIG_SURFACE_KBD=m
> # end of Surface System Aggregator Module HID support
>
> CONFIG_SURFACE_HID_CORE=m
> # end of HID support
>
> CONFIG_USB_OHCI_LITTLE_ENDIAN=y
> CONFIG_USB_SUPPORT=y
> CONFIG_USB_COMMON=y
> CONFIG_USB_LED_TRIG=y
> CONFIG_USB_ULPI_BUS=m
> CONFIG_USB_CONN_GPIO=m
> CONFIG_USB_ARCH_HAS_HCD=y
> CONFIG_USB=y
> CONFIG_USB_PCI=y
> CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>
> #
> # Miscellaneous USB options
> #
> CONFIG_USB_DEFAULT_PERSIST=y
> # CONFIG_USB_FEW_INIT_RETRIES is not set
> CONFIG_USB_DYNAMIC_MINORS=y
> # CONFIG_USB_OTG is not set
> # CONFIG_USB_OTG_PRODUCTLIST is not set
> # CONFIG_USB_OTG_DISABLE_EXTERNAL_HUB is not set
> CONFIG_USB_LEDS_TRIGGER_USBPORT=m
> CONFIG_USB_AUTOSUSPEND_DELAY=2
> CONFIG_USB_MON=m
>
> #
> # USB Host Controller Drivers
> #
> CONFIG_USB_C67X00_HCD=m
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DBGCAP=y
> CONFIG_USB_XHCI_PCI=m
> CONFIG_USB_XHCI_PCI_RENESAS=m
> CONFIG_USB_XHCI_PLATFORM=m
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_EHCI_ROOT_HUB_TT=y
> CONFIG_USB_EHCI_TT_NEWSCHED=y
> CONFIG_USB_EHCI_PCI=y
> CONFIG_USB_EHCI_FSL=m
> CONFIG_USB_EHCI_HCD_PLATFORM=y
> CONFIG_USB_OXU210HP_HCD=m
> CONFIG_USB_ISP116X_HCD=m
> CONFIG_USB_FOTG210_HCD=m
> CONFIG_USB_MAX3421_HCD=m
> CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_OHCI_HCD_PCI=y
> CONFIG_USB_OHCI_HCD_PLATFORM=y
> CONFIG_USB_UHCI_HCD=y
> CONFIG_USB_U132_HCD=m
> CONFIG_USB_SL811_HCD=m
> CONFIG_USB_SL811_HCD_ISO=y
> CONFIG_USB_SL811_CS=m
> CONFIG_USB_R8A66597_HCD=m
> CONFIG_USB_HCD_BCMA=m
> CONFIG_USB_HCD_SSB=m
> # CONFIG_USB_HCD_TEST_MODE is not set
> CONFIG_USB_XEN_HCD=m
>
> #
> # USB Device Class drivers
> #
> CONFIG_USB_ACM=m
> CONFIG_USB_PRINTER=m
> CONFIG_USB_WDM=m
> CONFIG_USB_TMC=m
>
> #
> # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
> #
>
> #
> # also be needed; see USB_STORAGE Help for more info
> #
> CONFIG_USB_STORAGE=m
> # CONFIG_USB_STORAGE_DEBUG is not set
> CONFIG_USB_STORAGE_REALTEK=m
> CONFIG_REALTEK_AUTOPM=y
> CONFIG_USB_STORAGE_DATAFAB=m
> CONFIG_USB_STORAGE_FREECOM=m
> CONFIG_USB_STORAGE_ISD200=m
> CONFIG_USB_STORAGE_USBAT=m
> CONFIG_USB_STORAGE_SDDR09=m
> CONFIG_USB_STORAGE_SDDR55=m
> CONFIG_USB_STORAGE_JUMPSHOT=m
> CONFIG_USB_STORAGE_ALAUDA=m
> CONFIG_USB_STORAGE_ONETOUCH=m
> CONFIG_USB_STORAGE_KARMA=m
> CONFIG_USB_STORAGE_CYPRESS_ATACB=m
> CONFIG_USB_STORAGE_ENE_UB6250=m
> CONFIG_USB_UAS=m
>
> #
> # USB Imaging devices
> #
> CONFIG_USB_MDC800=m
> CONFIG_USB_MICROTEK=m
> CONFIG_USBIP_CORE=m
> CONFIG_USBIP_VHCI_HCD=m
> CONFIG_USBIP_VHCI_HC_PORTS=8
> CONFIG_USBIP_VHCI_NR_HCS=1
> CONFIG_USBIP_HOST=m
> CONFIG_USBIP_VUDC=m
> # CONFIG_USBIP_DEBUG is not set
> CONFIG_USB_CDNS_SUPPORT=m
> CONFIG_USB_CDNS_HOST=y
> CONFIG_USB_CDNS3=m
> CONFIG_USB_CDNS3_GADGET=y
> CONFIG_USB_CDNS3_HOST=y
> CONFIG_USB_CDNS3_PCI_WRAP=m
> CONFIG_USB_CDNSP_PCI=m
> CONFIG_USB_CDNSP_GADGET=y
> CONFIG_USB_CDNSP_HOST=y
> CONFIG_USB_MUSB_HDRC=m
> # CONFIG_USB_MUSB_HOST is not set
> # CONFIG_USB_MUSB_GADGET is not set
> CONFIG_USB_MUSB_DUAL_ROLE=y
>
> #
> # Platform Glue Layer
> #
>
> #
> # MUSB DMA mode
> #
> CONFIG_MUSB_PIO_ONLY=y
> CONFIG_USB_DWC3=m
> CONFIG_USB_DWC3_ULPI=y
> # CONFIG_USB_DWC3_HOST is not set
> # CONFIG_USB_DWC3_GADGET is not set
> CONFIG_USB_DWC3_DUAL_ROLE=y
>
> #
> # Platform Glue Driver Support
> #
> CONFIG_USB_DWC3_PCI=m
> CONFIG_USB_DWC3_HAPS=m
> CONFIG_USB_DWC2=y
> CONFIG_USB_DWC2_HOST=y
>
> #
> # Gadget/Dual-role mode requires USB Gadget support to be enabled
> #
> CONFIG_USB_DWC2_PCI=m
> # CONFIG_USB_DWC2_DEBUG is not set
> # CONFIG_USB_DWC2_TRACK_MISSED_SOFS is not set
> CONFIG_USB_CHIPIDEA=m
> CONFIG_USB_CHIPIDEA_UDC=y
> CONFIG_USB_CHIPIDEA_HOST=y
> CONFIG_USB_CHIPIDEA_PCI=m
> CONFIG_USB_CHIPIDEA_MSM=m
> CONFIG_USB_CHIPIDEA_GENERIC=m
> CONFIG_USB_ISP1760=m
> CONFIG_USB_ISP1760_HCD=y
> CONFIG_USB_ISP1761_UDC=y
> # CONFIG_USB_ISP1760_HOST_ROLE is not set
> # CONFIG_USB_ISP1760_GADGET_ROLE is not set
> CONFIG_USB_ISP1760_DUAL_ROLE=y
>
> #
> # USB port drivers
> #
> CONFIG_USB_USS720=m
> CONFIG_USB_SERIAL=m
> CONFIG_USB_SERIAL_GENERIC=y
> CONFIG_USB_SERIAL_SIMPLE=m
> CONFIG_USB_SERIAL_AIRCABLE=m
> CONFIG_USB_SERIAL_ARK3116=m
> CONFIG_USB_SERIAL_BELKIN=m
> CONFIG_USB_SERIAL_CH341=m
> CONFIG_USB_SERIAL_WHITEHEAT=m
> CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
> CONFIG_USB_SERIAL_CP210X=m
> CONFIG_USB_SERIAL_CYPRESS_M8=m
> CONFIG_USB_SERIAL_EMPEG=m
> CONFIG_USB_SERIAL_FTDI_SIO=m
> CONFIG_USB_SERIAL_VISOR=m
> CONFIG_USB_SERIAL_IPAQ=m
> CONFIG_USB_SERIAL_IR=m
> CONFIG_USB_SERIAL_EDGEPORT=m
> CONFIG_USB_SERIAL_EDGEPORT_TI=m
> CONFIG_USB_SERIAL_F81232=m
> CONFIG_USB_SERIAL_F8153X=m
> CONFIG_USB_SERIAL_GARMIN=m
> CONFIG_USB_SERIAL_IPW=m
> CONFIG_USB_SERIAL_IUU=m
> CONFIG_USB_SERIAL_KEYSPAN_PDA=m
> CONFIG_USB_SERIAL_KEYSPAN=m
> CONFIG_USB_SERIAL_KLSI=m
> CONFIG_USB_SERIAL_KOBIL_SCT=m
> CONFIG_USB_SERIAL_MCT_U232=m
> CONFIG_USB_SERIAL_METRO=m
> CONFIG_USB_SERIAL_MOS7720=m
> CONFIG_USB_SERIAL_MOS7715_PARPORT=y
> CONFIG_USB_SERIAL_MOS7840=m
> CONFIG_USB_SERIAL_MXUPORT=m
> CONFIG_USB_SERIAL_NAVMAN=m
> CONFIG_USB_SERIAL_PL2303=m
> CONFIG_USB_SERIAL_OTI6858=m
> CONFIG_USB_SERIAL_QCAUX=m
> CONFIG_USB_SERIAL_QUALCOMM=m
> CONFIG_USB_SERIAL_SPCP8X5=m
> CONFIG_USB_SERIAL_SAFE=m
> # CONFIG_USB_SERIAL_SAFE_PADDED is not set
> CONFIG_USB_SERIAL_SIERRAWIRELESS=m
> CONFIG_USB_SERIAL_SYMBOL=m
> CONFIG_USB_SERIAL_TI=m
> CONFIG_USB_SERIAL_CYBERJACK=m
> CONFIG_USB_SERIAL_WWAN=m
> CONFIG_USB_SERIAL_OPTION=m
> CONFIG_USB_SERIAL_OMNINET=m
> CONFIG_USB_SERIAL_OPTICON=m
> CONFIG_USB_SERIAL_XSENS_MT=m
> CONFIG_USB_SERIAL_WISHBONE=m
> CONFIG_USB_SERIAL_SSU100=m
> CONFIG_USB_SERIAL_QT2=m
> CONFIG_USB_SERIAL_UPD78F0730=m
> CONFIG_USB_SERIAL_XR=m
> CONFIG_USB_SERIAL_DEBUG=m
>
> #
> # USB Miscellaneous drivers
> #
> CONFIG_USB_EMI62=m
> CONFIG_USB_EMI26=m
> CONFIG_USB_ADUTUX=m
> CONFIG_USB_SEVSEG=m
> CONFIG_USB_LEGOTOWER=m
> CONFIG_USB_LCD=m
> CONFIG_USB_CYPRESS_CY7C63=m
> CONFIG_USB_CYTHERM=m
> CONFIG_USB_IDMOUSE=m
> CONFIG_USB_FTDI_ELAN=m
> CONFIG_USB_APPLEDISPLAY=m
> CONFIG_APPLE_MFI_FASTCHARGE=m
> CONFIG_USB_SISUSBVGA=m
> CONFIG_USB_LD=m
> CONFIG_USB_TRANCEVIBRATOR=m
> CONFIG_USB_IOWARRIOR=m
> CONFIG_USB_TEST=m
> CONFIG_USB_EHSET_TEST_FIXTURE=m
> CONFIG_USB_ISIGHTFW=m
> CONFIG_USB_YUREX=m
> CONFIG_USB_EZUSB_FX2=m
> CONFIG_USB_HUB_USB251XB=m
> CONFIG_USB_HSIC_USB3503=m
> CONFIG_USB_HSIC_USB4604=m
> CONFIG_USB_LINK_LAYER_TEST=m
> CONFIG_USB_CHAOSKEY=m
> CONFIG_USB_ATM=m
> CONFIG_USB_SPEEDTOUCH=m
> CONFIG_USB_CXACRU=m
> CONFIG_USB_UEAGLEATM=m
> CONFIG_USB_XUSBATM=m
>
> #
> # USB Physical Layer drivers
> #
> CONFIG_USB_PHY=y
> CONFIG_NOP_USB_XCEIV=m
> CONFIG_USB_GPIO_VBUS=m
> CONFIG_TAHVO_USB=m
> CONFIG_TAHVO_USB_HOST_BY_DEFAULT=y
> CONFIG_USB_ISP1301=m
> # end of USB Physical Layer drivers
>
> CONFIG_USB_GADGET=m
> # CONFIG_USB_GADGET_DEBUG is not set
> # CONFIG_USB_GADGET_DEBUG_FILES is not set
> # CONFIG_USB_GADGET_DEBUG_FS is not set
> CONFIG_USB_GADGET_VBUS_DRAW=2
> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
> CONFIG_U_SERIAL_CONSOLE=y
>
> #
> # USB Peripheral Controller
> #
> CONFIG_USB_FOTG210_UDC=m
> CONFIG_USB_GR_UDC=m
> CONFIG_USB_R8A66597=m
> CONFIG_USB_PXA27X=m
> CONFIG_USB_MV_UDC=m
> CONFIG_USB_MV_U3D=m
> CONFIG_USB_SNP_CORE=m
> # CONFIG_USB_M66592 is not set
> CONFIG_USB_BDC_UDC=m
> CONFIG_USB_AMD5536UDC=m
> CONFIG_USB_NET2272=m
> CONFIG_USB_NET2272_DMA=y
> CONFIG_USB_NET2280=m
> CONFIG_USB_GOKU=m
> CONFIG_USB_EG20T=m
> CONFIG_USB_MAX3420_UDC=m
> # CONFIG_USB_DUMMY_HCD is not set
> # end of USB Peripheral Controller
>
> CONFIG_USB_LIBCOMPOSITE=m
> CONFIG_USB_F_ACM=m
> CONFIG_USB_F_SS_LB=m
> CONFIG_USB_U_SERIAL=m
> CONFIG_USB_U_ETHER=m
> CONFIG_USB_U_AUDIO=m
> CONFIG_USB_F_SERIAL=m
> CONFIG_USB_F_OBEX=m
> CONFIG_USB_F_NCM=m
> CONFIG_USB_F_ECM=m
> CONFIG_USB_F_PHONET=m
> CONFIG_USB_F_EEM=m
> CONFIG_USB_F_SUBSET=m
> CONFIG_USB_F_RNDIS=m
> CONFIG_USB_F_MASS_STORAGE=m
> CONFIG_USB_F_FS=m
> CONFIG_USB_F_UAC1=m
> CONFIG_USB_F_UAC1_LEGACY=m
> CONFIG_USB_F_UAC2=m
> CONFIG_USB_F_UVC=m
> CONFIG_USB_F_MIDI=m
> CONFIG_USB_F_HID=m
> CONFIG_USB_F_PRINTER=m
> CONFIG_USB_F_TCM=m
> CONFIG_USB_CONFIGFS=m
> CONFIG_USB_CONFIGFS_SERIAL=y
> CONFIG_USB_CONFIGFS_ACM=y
> CONFIG_USB_CONFIGFS_OBEX=y
> CONFIG_USB_CONFIGFS_NCM=y
> CONFIG_USB_CONFIGFS_ECM=y
> CONFIG_USB_CONFIGFS_ECM_SUBSET=y
> CONFIG_USB_CONFIGFS_RNDIS=y
> CONFIG_USB_CONFIGFS_EEM=y
> CONFIG_USB_CONFIGFS_PHONET=y
> CONFIG_USB_CONFIGFS_MASS_STORAGE=y
> CONFIG_USB_CONFIGFS_F_LB_SS=y
> CONFIG_USB_CONFIGFS_F_FS=y
> CONFIG_USB_CONFIGFS_F_UAC1=y
> CONFIG_USB_CONFIGFS_F_UAC1_LEGACY=y
> CONFIG_USB_CONFIGFS_F_UAC2=y
> CONFIG_USB_CONFIGFS_F_MIDI=y
> CONFIG_USB_CONFIGFS_F_HID=y
> CONFIG_USB_CONFIGFS_F_UVC=y
> CONFIG_USB_CONFIGFS_F_PRINTER=y
> CONFIG_USB_CONFIGFS_F_TCM=y
>
> #
> # USB Gadget precomposed configurations
> #
> CONFIG_USB_ZERO=m
> CONFIG_USB_AUDIO=m
> CONFIG_GADGET_UAC1=y
> # CONFIG_GADGET_UAC1_LEGACY is not set
> CONFIG_USB_ETH=m
> CONFIG_USB_ETH_RNDIS=y
> CONFIG_USB_ETH_EEM=y
> CONFIG_USB_G_NCM=m
> CONFIG_USB_GADGETFS=m
> CONFIG_USB_FUNCTIONFS=m
> CONFIG_USB_FUNCTIONFS_ETH=y
> CONFIG_USB_FUNCTIONFS_RNDIS=y
> CONFIG_USB_FUNCTIONFS_GENERIC=y
> CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_GADGET_TARGET=m
> CONFIG_USB_G_SERIAL=m
> CONFIG_USB_MIDI_GADGET=m
> CONFIG_USB_G_PRINTER=m
> CONFIG_USB_CDC_COMPOSITE=m
> CONFIG_USB_G_NOKIA=m
> CONFIG_USB_G_ACM_MS=m
> # CONFIG_USB_G_MULTI is not set
> CONFIG_USB_G_HID=m
> CONFIG_USB_G_DBGP=m
> # CONFIG_USB_G_DBGP_PRINTK is not set
> CONFIG_USB_G_DBGP_SERIAL=y
> CONFIG_USB_G_WEBCAM=m
> CONFIG_USB_RAW_GADGET=m
> # end of USB Gadget precomposed configurations
>
> CONFIG_TYPEC=m
> CONFIG_TYPEC_TCPM=m
> CONFIG_TYPEC_TCPCI=m
> CONFIG_TYPEC_RT1711H=m
> CONFIG_TYPEC_MT6360=m
> CONFIG_TYPEC_TCPCI_MAXIM=m
> CONFIG_TYPEC_FUSB302=m
> CONFIG_TYPEC_WCOVE=m
> CONFIG_TYPEC_UCSI=m
> CONFIG_UCSI_CCG=m
> CONFIG_UCSI_ACPI=m
> CONFIG_UCSI_STM32G0=m
> CONFIG_TYPEC_TPS6598X=m
> CONFIG_TYPEC_ANX7411=m
> CONFIG_TYPEC_RT1719=m
> CONFIG_TYPEC_HD3SS3220=m
> CONFIG_TYPEC_STUSB160X=m
> CONFIG_TYPEC_WUSB3801=m
>
> #
> # USB Type-C Multiplexer/DeMultiplexer Switch support
> #
> CONFIG_TYPEC_MUX_FSA4480=m
> CONFIG_TYPEC_MUX_PI3USB30532=m
> CONFIG_TYPEC_MUX_INTEL_PMC=m
> # end of USB Type-C Multiplexer/DeMultiplexer Switch support
>
> #
> # USB Type-C Alternate Mode drivers
> #
> CONFIG_TYPEC_DP_ALTMODE=m
> CONFIG_TYPEC_NVIDIA_ALTMODE=m
> # end of USB Type-C Alternate Mode drivers
>
> CONFIG_USB_ROLE_SWITCH=y
> CONFIG_USB_ROLES_INTEL_XHCI=m
> CONFIG_MMC=y
> CONFIG_MMC_BLOCK=m
> CONFIG_MMC_BLOCK_MINORS=8
> CONFIG_SDIO_UART=m
> # CONFIG_MMC_TEST is not set
> CONFIG_MMC_CRYPTO=y
>
> #
> # MMC/SD/SDIO Host Controller Drivers
> #
> # CONFIG_MMC_DEBUG is not set
> CONFIG_MMC_SDHCI=m
> CONFIG_MMC_SDHCI_IO_ACCESSORS=y
> CONFIG_MMC_SDHCI_PCI=m
> CONFIG_MMC_RICOH_MMC=y
> CONFIG_MMC_SDHCI_ACPI=m
> CONFIG_MMC_SDHCI_PLTFM=m
> CONFIG_MMC_SDHCI_F_SDH30=m
> CONFIG_MMC_WBSD=m
> CONFIG_MMC_ALCOR=m
> CONFIG_MMC_TIFM_SD=m
> CONFIG_MMC_SPI=m
> CONFIG_MMC_SDRICOH_CS=m
> CONFIG_MMC_CB710=m
> CONFIG_MMC_VIA_SDMMC=m
> CONFIG_MMC_VUB300=m
> CONFIG_MMC_USHC=m
> CONFIG_MMC_USDHI6ROL0=m
> CONFIG_MMC_REALTEK_PCI=m
> CONFIG_MMC_REALTEK_USB=m
> CONFIG_MMC_CQHCI=m
> # CONFIG_MMC_HSQ is not set
> CONFIG_MMC_TOSHIBA_PCI=m
> CONFIG_MMC_MTK=m
> CONFIG_MMC_SDHCI_XENON=m
> CONFIG_SCSI_UFSHCD=m
> CONFIG_SCSI_UFS_BSG=y
> CONFIG_SCSI_UFS_CRYPTO=y
> CONFIG_SCSI_UFS_HPB=y
> # CONFIG_SCSI_UFS_HWMON is not set
> CONFIG_SCSI_UFSHCD_PCI=m
> CONFIG_SCSI_UFS_DWC_TC_PCI=m
> CONFIG_SCSI_UFSHCD_PLATFORM=m
> CONFIG_SCSI_UFS_CDNS_PLATFORM=m
> CONFIG_SCSI_UFS_DWC_TC_PLATFORM=m
> CONFIG_MEMSTICK=m
> # CONFIG_MEMSTICK_DEBUG is not set
>
> #
> # MemoryStick drivers
> #
> # CONFIG_MEMSTICK_UNSAFE_RESUME is not set
> CONFIG_MSPRO_BLOCK=m
> CONFIG_MS_BLOCK=m
>
> #
> # MemoryStick Host Controller Drivers
> #
> CONFIG_MEMSTICK_TIFM_MS=m
> CONFIG_MEMSTICK_JMICRON_38X=m
> CONFIG_MEMSTICK_R592=m
> CONFIG_MEMSTICK_REALTEK_PCI=m
> CONFIG_MEMSTICK_REALTEK_USB=m
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_CLASS_FLASH=m
> CONFIG_LEDS_CLASS_MULTICOLOR=m
> CONFIG_LEDS_BRIGHTNESS_HW_CHANGED=y
>
> #
> # LED drivers
> #
> CONFIG_LEDS_88PM860X=m
> CONFIG_LEDS_APU=m
> CONFIG_LEDS_LM3530=m
> CONFIG_LEDS_LM3532=m
> CONFIG_LEDS_LM3533=m
> CONFIG_LEDS_LM3642=m
> CONFIG_LEDS_MT6323=m
> CONFIG_LEDS_PCA9532=m
> CONFIG_LEDS_PCA9532_GPIO=y
> CONFIG_LEDS_GPIO=m
> CONFIG_LEDS_LP3944=m
> CONFIG_LEDS_LP3952=m
> CONFIG_LEDS_LP50XX=m
> CONFIG_LEDS_LP8788=m
> CONFIG_LEDS_PCA955X=m
> CONFIG_LEDS_PCA955X_GPIO=y
> CONFIG_LEDS_PCA963X=m
> CONFIG_LEDS_WM831X_STATUS=m
> CONFIG_LEDS_WM8350=m
> CONFIG_LEDS_DA903X=m
> CONFIG_LEDS_DA9052=m
> CONFIG_LEDS_DAC124S085=m
> CONFIG_LEDS_PWM=m
> CONFIG_LEDS_REGULATOR=m
> CONFIG_LEDS_BD2802=m
> CONFIG_LEDS_INTEL_SS4200=m
> CONFIG_LEDS_LT3593=m
> CONFIG_LEDS_ADP5520=m
> CONFIG_LEDS_MC13783=m
> CONFIG_LEDS_TCA6507=m
> CONFIG_LEDS_TLC591XX=m
> CONFIG_LEDS_MAX8997=m
> CONFIG_LEDS_LM355x=m
> CONFIG_LEDS_MENF21BMC=m
> CONFIG_LEDS_IS31FL319X=m
>
> #
> # LED driver for blink(1) USB RGB LED is under Special HID drivers 
> (HID_THINGM)
> #
> CONFIG_LEDS_BLINKM=m
> CONFIG_LEDS_MLXCPLD=m
> CONFIG_LEDS_MLXREG=m
> CONFIG_LEDS_USER=m
> CONFIG_LEDS_NIC78BX=m
> CONFIG_LEDS_TI_LMU_COMMON=m
> CONFIG_LEDS_LM36274=m
> CONFIG_LEDS_TPS6105X=m
>
> #
> # Flash and Torch LED drivers
> #
> CONFIG_LEDS_AS3645A=m
> CONFIG_LEDS_LM3601X=m
> CONFIG_LEDS_RT8515=m
> CONFIG_LEDS_SGM3140=m
>
> #
> # RGB LED drivers
> #
> CONFIG_LEDS_PWM_MULTICOLOR=m
>
> #
> # LED Triggers
> #
> CONFIG_LEDS_TRIGGERS=y
> CONFIG_LEDS_TRIGGER_TIMER=m
> CONFIG_LEDS_TRIGGER_ONESHOT=m
> CONFIG_LEDS_TRIGGER_DISK=y
> CONFIG_LEDS_TRIGGER_MTD=y
> CONFIG_LEDS_TRIGGER_HEARTBEAT=m
> CONFIG_LEDS_TRIGGER_BACKLIGHT=m
> CONFIG_LEDS_TRIGGER_CPU=y
> CONFIG_LEDS_TRIGGER_ACTIVITY=m
> CONFIG_LEDS_TRIGGER_GPIO=m
> CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
>
> #
> # iptables trigger is under Netfilter config (LED target)
> #
> CONFIG_LEDS_TRIGGER_TRANSIENT=m
> CONFIG_LEDS_TRIGGER_CAMERA=m
> CONFIG_LEDS_TRIGGER_PANIC=y
> CONFIG_LEDS_TRIGGER_NETDEV=m
> CONFIG_LEDS_TRIGGER_PATTERN=m
> CONFIG_LEDS_TRIGGER_AUDIO=m
> CONFIG_LEDS_TRIGGER_TTY=m
>
> #
> # Simple LED drivers
> #
> CONFIG_LEDS_SIEMENS_SIMATIC_IPC=m
> CONFIG_ACCESSIBILITY=y
> # CONFIG_A11Y_BRAILLE_CONSOLE is not set
>
> #
> # Speakup console speech
> #
> CONFIG_SPEAKUP=m
> CONFIG_SPEAKUP_SYNTH_ACNTSA=m
> CONFIG_SPEAKUP_SYNTH_APOLLO=m
> CONFIG_SPEAKUP_SYNTH_AUDPTR=m
> CONFIG_SPEAKUP_SYNTH_BNS=m
> CONFIG_SPEAKUP_SYNTH_DECTLK=m
> CONFIG_SPEAKUP_SYNTH_DECEXT=m
> CONFIG_SPEAKUP_SYNTH_LTLK=m
> CONFIG_SPEAKUP_SYNTH_SOFT=m
> CONFIG_SPEAKUP_SYNTH_SPKOUT=m
> CONFIG_SPEAKUP_SYNTH_TXPRT=m
> CONFIG_SPEAKUP_SYNTH_DUMMY=m
> # end of Speakup console speech
>
> CONFIG_INFINIBAND=m
> CONFIG_INFINIBAND_USER_MAD=m
> CONFIG_INFINIBAND_USER_ACCESS=m
> CONFIG_INFINIBAND_USER_MEM=y
> CONFIG_INFINIBAND_ON_DEMAND_PAGING=y
> CONFIG_INFINIBAND_ADDR_TRANS=y
> CONFIG_INFINIBAND_ADDR_TRANS_CONFIGFS=y
> CONFIG_INFINIBAND_VIRT_DMA=y
> CONFIG_INFINIBAND_BNXT_RE=m
> CONFIG_INFINIBAND_CXGB4=m
> CONFIG_INFINIBAND_EFA=m
> CONFIG_INFINIBAND_ERDMA=m
> CONFIG_INFINIBAND_HFI1=m
> # CONFIG_HFI1_DEBUG_SDMA_ORDER is not set
> # CONFIG_SDMA_VERBOSITY is not set
> CONFIG_INFINIBAND_IRDMA=m
> CONFIG_MLX4_INFINIBAND=m
> CONFIG_MLX5_INFINIBAND=m
> CONFIG_INFINIBAND_MTHCA=m
> # CONFIG_INFINIBAND_MTHCA_DEBUG is not set
> CONFIG_INFINIBAND_OCRDMA=m
> CONFIG_INFINIBAND_QEDR=m
> CONFIG_INFINIBAND_QIB=m
> CONFIG_INFINIBAND_QIB_DCA=y
> CONFIG_INFINIBAND_USNIC=m
> CONFIG_INFINIBAND_VMWARE_PVRDMA=m
> CONFIG_INFINIBAND_RDMAVT=m
> CONFIG_RDMA_RXE=m
> CONFIG_RDMA_SIW=m
> CONFIG_INFINIBAND_IPOIB=m
> CONFIG_INFINIBAND_IPOIB_CM=y
> # CONFIG_INFINIBAND_IPOIB_DEBUG is not set
> CONFIG_INFINIBAND_SRP=m
> CONFIG_INFINIBAND_SRPT=m
> CONFIG_INFINIBAND_ISER=m
> CONFIG_INFINIBAND_ISERT=m
> CONFIG_INFINIBAND_RTRS=m
> CONFIG_INFINIBAND_RTRS_CLIENT=m
> CONFIG_INFINIBAND_RTRS_SERVER=m
> CONFIG_INFINIBAND_OPA_VNIC=m
> CONFIG_EDAC_ATOMIC_SCRUB=y
> CONFIG_EDAC_SUPPORT=y
> CONFIG_EDAC=y
> # CONFIG_EDAC_LEGACY_SYSFS is not set
> # CONFIG_EDAC_DEBUG is not set
> CONFIG_EDAC_DECODE_MCE=m
> CONFIG_EDAC_GHES=y
> CONFIG_EDAC_AMD64=m
> CONFIG_EDAC_E752X=m
> CONFIG_EDAC_I82975X=m
> CONFIG_EDAC_I3000=m
> CONFIG_EDAC_I3200=m
> CONFIG_EDAC_IE31200=m
> CONFIG_EDAC_X38=m
> CONFIG_EDAC_I5400=m
> CONFIG_EDAC_I7CORE=m
> CONFIG_EDAC_I5000=m
> CONFIG_EDAC_I5100=m
> CONFIG_EDAC_I7300=m
> CONFIG_EDAC_SBRIDGE=m
> CONFIG_EDAC_SKX=m
> CONFIG_EDAC_I10NM=m
> CONFIG_EDAC_PND2=m
> CONFIG_EDAC_IGEN6=m
> CONFIG_RTC_LIB=y
> CONFIG_RTC_MC146818_LIB=y
> CONFIG_RTC_CLASS=y
> CONFIG_RTC_HCTOSYS=y
> CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
> CONFIG_RTC_SYSTOHC=y
> CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
> # CONFIG_RTC_DEBUG is not set
> CONFIG_RTC_NVMEM=y
>
> #
> # RTC interfaces
> #
> CONFIG_RTC_INTF_SYSFS=y
> CONFIG_RTC_INTF_PROC=y
> CONFIG_RTC_INTF_DEV=y
> # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
> # CONFIG_RTC_DRV_TEST is not set
>
> #
> # I2C RTC drivers
> #
> CONFIG_RTC_DRV_88PM860X=m
> CONFIG_RTC_DRV_88PM80X=m
> CONFIG_RTC_DRV_ABB5ZES3=m
> CONFIG_RTC_DRV_ABEOZ9=m
> CONFIG_RTC_DRV_ABX80X=m
> CONFIG_RTC_DRV_DS1307=m
> CONFIG_RTC_DRV_DS1307_CENTURY=y
> CONFIG_RTC_DRV_DS1374=m
> CONFIG_RTC_DRV_DS1374_WDT=y
> CONFIG_RTC_DRV_DS1672=m
> CONFIG_RTC_DRV_LP8788=m
> CONFIG_RTC_DRV_MAX6900=m
> CONFIG_RTC_DRV_MAX8907=m
> CONFIG_RTC_DRV_MAX8925=m
> CONFIG_RTC_DRV_MAX8998=m
> CONFIG_RTC_DRV_MAX8997=m
> CONFIG_RTC_DRV_RS5C372=m
> CONFIG_RTC_DRV_ISL1208=m
> CONFIG_RTC_DRV_ISL12022=m
> CONFIG_RTC_DRV_X1205=m
> CONFIG_RTC_DRV_PCF8523=m
> CONFIG_RTC_DRV_PCF85063=m
> CONFIG_RTC_DRV_PCF85363=m
> CONFIG_RTC_DRV_PCF8563=m
> CONFIG_RTC_DRV_PCF8583=m
> CONFIG_RTC_DRV_M41T80=m
> CONFIG_RTC_DRV_M41T80_WDT=y
> CONFIG_RTC_DRV_BQ32K=m
> CONFIG_RTC_DRV_PALMAS=m
> CONFIG_RTC_DRV_TPS6586X=m
> CONFIG_RTC_DRV_TPS65910=m
> CONFIG_RTC_DRV_RC5T583=m
> CONFIG_RTC_DRV_S35390A=m
> CONFIG_RTC_DRV_FM3130=m
> CONFIG_RTC_DRV_RX8010=m
> CONFIG_RTC_DRV_RX8581=m
> CONFIG_RTC_DRV_RX8025=m
> CONFIG_RTC_DRV_EM3027=m
> CONFIG_RTC_DRV_RV3028=m
> CONFIG_RTC_DRV_RV3032=m
> CONFIG_RTC_DRV_RV8803=m
> CONFIG_RTC_DRV_SD3078=m
>
> #
> # SPI RTC drivers
> #
> CONFIG_RTC_DRV_M41T93=m
> CONFIG_RTC_DRV_M41T94=m
> CONFIG_RTC_DRV_DS1302=m
> CONFIG_RTC_DRV_DS1305=m
> CONFIG_RTC_DRV_DS1343=m
> CONFIG_RTC_DRV_DS1347=m
> CONFIG_RTC_DRV_DS1390=m
> CONFIG_RTC_DRV_MAX6916=m
> CONFIG_RTC_DRV_R9701=m
> CONFIG_RTC_DRV_RX4581=m
> CONFIG_RTC_DRV_RS5C348=m
> CONFIG_RTC_DRV_MAX6902=m
> CONFIG_RTC_DRV_PCF2123=m
> CONFIG_RTC_DRV_MCP795=m
> CONFIG_RTC_I2C_AND_SPI=y
>
> #
> # SPI and I2C RTC drivers
> #
> CONFIG_RTC_DRV_DS3232=m
> CONFIG_RTC_DRV_DS3232_HWMON=y
> CONFIG_RTC_DRV_PCF2127=m
> CONFIG_RTC_DRV_RV3029C2=m
> CONFIG_RTC_DRV_RV3029_HWMON=y
> CONFIG_RTC_DRV_RX6110=m
>
> #
> # Platform RTC drivers
> #
> CONFIG_RTC_DRV_CMOS=y
> CONFIG_RTC_DRV_DS1286=m
> CONFIG_RTC_DRV_DS1511=m
> CONFIG_RTC_DRV_DS1553=m
> CONFIG_RTC_DRV_DS1685_FAMILY=m
> CONFIG_RTC_DRV_DS1685=y
> # CONFIG_RTC_DRV_DS1689 is not set
> # CONFIG_RTC_DRV_DS17285 is not set
> # CONFIG_RTC_DRV_DS17485 is not set
> # CONFIG_RTC_DRV_DS17885 is not set
> CONFIG_RTC_DRV_DS1742=m
> CONFIG_RTC_DRV_DS2404=m
> CONFIG_RTC_DRV_DA9052=m
> CONFIG_RTC_DRV_DA9055=m
> CONFIG_RTC_DRV_DA9063=m
> CONFIG_RTC_DRV_STK17TA8=m
> CONFIG_RTC_DRV_M48T86=m
> CONFIG_RTC_DRV_M48T35=m
> CONFIG_RTC_DRV_M48T59=m
> CONFIG_RTC_DRV_MSM6242=m
> CONFIG_RTC_DRV_BQ4802=m
> CONFIG_RTC_DRV_RP5C01=m
> CONFIG_RTC_DRV_V3020=m
> CONFIG_RTC_DRV_WM831X=m
> CONFIG_RTC_DRV_WM8350=m
> CONFIG_RTC_DRV_PCF50633=m
> CONFIG_RTC_DRV_CROS_EC=m
>
> #
> # on-CPU RTC drivers
> #
> CONFIG_RTC_DRV_FTRTC010=m
> CONFIG_RTC_DRV_PCAP=m
> CONFIG_RTC_DRV_MC13XXX=m
> CONFIG_RTC_DRV_MT6397=m
>
> #
> # HID Sensor RTC drivers
> #
> CONFIG_RTC_DRV_HID_SENSOR_TIME=m
> CONFIG_RTC_DRV_GOLDFISH=m
> CONFIG_RTC_DRV_WILCO_EC=m
> CONFIG_DMADEVICES=y
> # CONFIG_DMADEVICES_DEBUG is not set
>
> #
> # DMA Devices
> #
> CONFIG_DMA_ENGINE=y
> CONFIG_DMA_VIRTUAL_CHANNELS=y
> CONFIG_DMA_ACPI=y
> CONFIG_ALTERA_MSGDMA=m
> CONFIG_INTEL_IDMA64=m
> CONFIG_INTEL_IDXD_BUS=m
> CONFIG_INTEL_IDXD=m
> # CONFIG_INTEL_IDXD_COMPAT is not set
> CONFIG_INTEL_IDXD_SVM=y
> CONFIG_INTEL_IDXD_PERFMON=y
> CONFIG_INTEL_IOATDMA=m
> CONFIG_PLX_DMA=m
> CONFIG_AMD_PTDMA=m
> CONFIG_QCOM_HIDMA_MGMT=m
> CONFIG_QCOM_HIDMA=m
> CONFIG_DW_DMAC_CORE=m
> CONFIG_DW_DMAC=m
> CONFIG_DW_DMAC_PCI=m
> CONFIG_DW_EDMA=m
> CONFIG_DW_EDMA_PCIE=m
> CONFIG_HSU_DMA=m
> CONFIG_SF_PDMA=m
> CONFIG_INTEL_LDMA=y
>
> #
> # DMA Clients
> #
> CONFIG_ASYNC_TX_DMA=y
> # CONFIG_DMATEST is not set
> CONFIG_DMA_ENGINE_RAID=y
>
> #
> # DMABUF options
> #
> CONFIG_SYNC_FILE=y
> CONFIG_SW_SYNC=y
> CONFIG_UDMABUF=y
> # CONFIG_DMABUF_MOVE_NOTIFY is not set
> # CONFIG_DMABUF_DEBUG is not set
> # CONFIG_DMABUF_SELFTESTS is not set
> CONFIG_DMABUF_HEAPS=y
> # CONFIG_DMABUF_SYSFS_STATS is not set
> CONFIG_DMABUF_HEAPS_SYSTEM=y
> # end of DMABUF options
>
> CONFIG_DCA=m
> CONFIG_AUXDISPLAY=y
> CONFIG_CHARLCD=m
> CONFIG_LINEDISP=m
> CONFIG_HD44780_COMMON=m
> CONFIG_HD44780=m
> CONFIG_KS0108=m
> CONFIG_KS0108_PORT=0x378
> CONFIG_KS0108_DELAY=2
> CONFIG_CFAG12864B=m
> CONFIG_CFAG12864B_RATE=20
> CONFIG_IMG_ASCII_LCD=m
> CONFIG_HT16K33=m
> CONFIG_LCD2S=m
> CONFIG_PARPORT_PANEL=m
> CONFIG_PANEL_PARPORT=0
> CONFIG_PANEL_PROFILE=5
> # CONFIG_PANEL_CHANGE_MESSAGE is not set
> # CONFIG_CHARLCD_BL_OFF is not set
> # CONFIG_CHARLCD_BL_ON is not set
> CONFIG_CHARLCD_BL_FLASH=y
> CONFIG_PANEL=m
> CONFIG_UIO=m
> CONFIG_UIO_CIF=m
> CONFIG_UIO_PDRV_GENIRQ=m
> CONFIG_UIO_DMEM_GENIRQ=m
> CONFIG_UIO_AEC=m
> CONFIG_UIO_SERCOS3=m
> CONFIG_UIO_PCI_GENERIC=m
> CONFIG_UIO_NETX=m
> CONFIG_UIO_PRUSS=m
> CONFIG_UIO_MF624=m
> CONFIG_UIO_HV_GENERIC=m
> CONFIG_UIO_DFL=m
> CONFIG_VFIO=y
> CONFIG_VFIO_IOMMU_TYPE1=y
> CONFIG_VFIO_VIRQFD=y
> CONFIG_VFIO_NOIOMMU=y
> CONFIG_VFIO_PCI_CORE=y
> CONFIG_VFIO_PCI_MMAP=y
> CONFIG_VFIO_PCI_INTX=y
> CONFIG_VFIO_PCI=y
> CONFIG_VFIO_PCI_VGA=y
> CONFIG_VFIO_PCI_IGD=y
> CONFIG_MLX5_VFIO_PCI=m
> CONFIG_VFIO_MDEV=m
> CONFIG_IRQ_BYPASS_MANAGER=y
> CONFIG_VIRT_DRIVERS=y
> CONFIG_VMGENID=m
> CONFIG_VBOXGUEST=m
> CONFIG_NITRO_ENCLAVES=m
> CONFIG_ACRN_HSM=m
> CONFIG_EFI_SECRET=m
> CONFIG_SEV_GUEST=m
> CONFIG_VIRTIO_ANCHOR=y
> CONFIG_VIRTIO=y
> CONFIG_VIRTIO_PCI_LIB=y
> CONFIG_VIRTIO_PCI_LIB_LEGACY=y
> CONFIG_VIRTIO_MENU=y
> CONFIG_VIRTIO_PCI=y
> CONFIG_VIRTIO_PCI_LEGACY=y
> CONFIG_VIRTIO_VDPA=m
> CONFIG_VIRTIO_PMEM=m
> CONFIG_VIRTIO_BALLOON=y
> CONFIG_VIRTIO_MEM=m
> CONFIG_VIRTIO_INPUT=m
> CONFIG_VIRTIO_MMIO=y
> CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
> CONFIG_VIRTIO_DMA_SHARED_BUFFER=m
> CONFIG_VDPA=m
> CONFIG_VDPA_SIM=m
> CONFIG_VDPA_SIM_NET=m
> CONFIG_VDPA_SIM_BLOCK=m
> CONFIG_VDPA_USER=m
> CONFIG_IFCVF=m
> CONFIG_MLX5_VDPA=y
> CONFIG_MLX5_VDPA_NET=m
> CONFIG_VP_VDPA=m
> CONFIG_ALIBABA_ENI_VDPA=m
> CONFIG_VHOST_IOTLB=m
> CONFIG_VHOST_RING=m
> CONFIG_VHOST=m
> CONFIG_VHOST_MENU=y
> CONFIG_VHOST_NET=m
> CONFIG_VHOST_SCSI=m
> CONFIG_VHOST_VSOCK=m
> CONFIG_VHOST_VDPA=m
> # CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set
>
> #
> # Microsoft Hyper-V guest support
> #
> CONFIG_HYPERV=m
> CONFIG_HYPERV_TIMER=y
> CONFIG_HYPERV_UTILS=m
> CONFIG_HYPERV_BALLOON=m
> # end of Microsoft Hyper-V guest support
>
> #
> # Xen driver support
> #
> CONFIG_XEN_BALLOON=y
> CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
> CONFIG_XEN_MEMORY_HOTPLUG_LIMIT=512
> CONFIG_XEN_SCRUB_PAGES_DEFAULT=y
> CONFIG_XEN_DEV_EVTCHN=m
> CONFIG_XEN_BACKEND=y
> CONFIG_XENFS=m
> CONFIG_XEN_COMPAT_XENFS=y
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=m
> CONFIG_XEN_GNTDEV_DMABUF=y
> CONFIG_XEN_GRANT_DEV_ALLOC=m
> CONFIG_XEN_GRANT_DMA_ALLOC=y
> CONFIG_SWIOTLB_XEN=y
> CONFIG_XEN_PCI_STUB=y
> CONFIG_XEN_PCIDEV_BACKEND=m
> CONFIG_XEN_PVCALLS_FRONTEND=m
> # CONFIG_XEN_PVCALLS_BACKEND is not set
> CONFIG_XEN_SCSI_BACKEND=m
> CONFIG_XEN_PRIVCMD=m
> CONFIG_XEN_ACPI_PROCESSOR=y
> CONFIG_XEN_MCE_LOG=y
> CONFIG_XEN_HAVE_PVMMU=y
> CONFIG_XEN_EFI=y
> CONFIG_XEN_AUTO_XLATE=y
> CONFIG_XEN_ACPI=y
> CONFIG_XEN_SYMS=y
> CONFIG_XEN_HAVE_VPMU=y
> CONFIG_XEN_FRONT_PGDIR_SHBUF=m
> CONFIG_XEN_UNPOPULATED_ALLOC=y
> CONFIG_XEN_GRANT_DMA_OPS=y
> CONFIG_XEN_VIRTIO=y
> # CONFIG_XEN_VIRTIO_FORCE_GRANT is not set
> # end of Xen driver support
>
> CONFIG_GREYBUS=m
> CONFIG_GREYBUS_ES2=m
> CONFIG_COMEDI=m
> # CONFIG_COMEDI_DEBUG is not set
> CONFIG_COMEDI_DEFAULT_BUF_SIZE_KB=2048
> CONFIG_COMEDI_DEFAULT_BUF_MAXSIZE_KB=20480
> CONFIG_COMEDI_MISC_DRIVERS=y
> CONFIG_COMEDI_BOND=m
> CONFIG_COMEDI_TEST=m
> CONFIG_COMEDI_PARPORT=m
> CONFIG_COMEDI_ISA_DRIVERS=y
> CONFIG_COMEDI_PCL711=m
> CONFIG_COMEDI_PCL724=m
> CONFIG_COMEDI_PCL726=m
> CONFIG_COMEDI_PCL730=m
> CONFIG_COMEDI_PCL812=m
> CONFIG_COMEDI_PCL816=m
> CONFIG_COMEDI_PCL818=m
> CONFIG_COMEDI_PCM3724=m
> CONFIG_COMEDI_AMPLC_DIO200_ISA=m
> CONFIG_COMEDI_AMPLC_PC236_ISA=m
> CONFIG_COMEDI_AMPLC_PC263_ISA=m
> CONFIG_COMEDI_RTI800=m
> CONFIG_COMEDI_RTI802=m
> CONFIG_COMEDI_DAC02=m
> CONFIG_COMEDI_DAS16M1=m
> CONFIG_COMEDI_DAS08_ISA=m
> CONFIG_COMEDI_DAS16=m
> CONFIG_COMEDI_DAS800=m
> CONFIG_COMEDI_DAS1800=m
> CONFIG_COMEDI_DAS6402=m
> CONFIG_COMEDI_DT2801=m
> CONFIG_COMEDI_DT2811=m
> CONFIG_COMEDI_DT2814=m
> CONFIG_COMEDI_DT2815=m
> CONFIG_COMEDI_DT2817=m
> CONFIG_COMEDI_DT282X=m
> CONFIG_COMEDI_DMM32AT=m
> CONFIG_COMEDI_FL512=m
> CONFIG_COMEDI_AIO_AIO12_8=m
> CONFIG_COMEDI_AIO_IIRO_16=m
> CONFIG_COMEDI_II_PCI20KC=m
> CONFIG_COMEDI_C6XDIGIO=m
> CONFIG_COMEDI_MPC624=m
> CONFIG_COMEDI_ADQ12B=m
> CONFIG_COMEDI_NI_AT_A2150=m
> CONFIG_COMEDI_NI_AT_AO=m
> CONFIG_COMEDI_NI_ATMIO=m
> CONFIG_COMEDI_NI_ATMIO16D=m
> CONFIG_COMEDI_NI_LABPC_ISA=m
> CONFIG_COMEDI_PCMAD=m
> CONFIG_COMEDI_PCMDA12=m
> CONFIG_COMEDI_PCMMIO=m
> CONFIG_COMEDI_PCMUIO=m
> CONFIG_COMEDI_MULTIQ3=m
> CONFIG_COMEDI_S526=m
> CONFIG_COMEDI_PCI_DRIVERS=m
> CONFIG_COMEDI_8255_PCI=m
> CONFIG_COMEDI_ADDI_WATCHDOG=m
> CONFIG_COMEDI_ADDI_APCI_1032=m
> CONFIG_COMEDI_ADDI_APCI_1500=m
> CONFIG_COMEDI_ADDI_APCI_1516=m
> CONFIG_COMEDI_ADDI_APCI_1564=m
> CONFIG_COMEDI_ADDI_APCI_16XX=m
> CONFIG_COMEDI_ADDI_APCI_2032=m
> CONFIG_COMEDI_ADDI_APCI_2200=m
> CONFIG_COMEDI_ADDI_APCI_3120=m
> CONFIG_COMEDI_ADDI_APCI_3501=m
> CONFIG_COMEDI_ADDI_APCI_3XXX=m
> CONFIG_COMEDI_ADL_PCI6208=m
> CONFIG_COMEDI_ADL_PCI7X3X=m
> CONFIG_COMEDI_ADL_PCI8164=m
> CONFIG_COMEDI_ADL_PCI9111=m
> CONFIG_COMEDI_ADL_PCI9118=m
> CONFIG_COMEDI_ADV_PCI1710=m
> CONFIG_COMEDI_ADV_PCI1720=m
> CONFIG_COMEDI_ADV_PCI1723=m
> CONFIG_COMEDI_ADV_PCI1724=m
> CONFIG_COMEDI_ADV_PCI1760=m
> CONFIG_COMEDI_ADV_PCI_DIO=m
> CONFIG_COMEDI_AMPLC_DIO200_PCI=m
> CONFIG_COMEDI_AMPLC_PC236_PCI=m
> CONFIG_COMEDI_AMPLC_PC263_PCI=m
> CONFIG_COMEDI_AMPLC_PCI224=m
> CONFIG_COMEDI_AMPLC_PCI230=m
> CONFIG_COMEDI_CONTEC_PCI_DIO=m
> CONFIG_COMEDI_DAS08_PCI=m
> CONFIG_COMEDI_DT3000=m
> CONFIG_COMEDI_DYNA_PCI10XX=m
> CONFIG_COMEDI_GSC_HPDI=m
> CONFIG_COMEDI_MF6X4=m
> CONFIG_COMEDI_ICP_MULTI=m
> CONFIG_COMEDI_DAQBOARD2000=m
> CONFIG_COMEDI_JR3_PCI=m
> CONFIG_COMEDI_KE_COUNTER=m
> CONFIG_COMEDI_CB_PCIDAS64=m
> CONFIG_COMEDI_CB_PCIDAS=m
> CONFIG_COMEDI_CB_PCIDDA=m
> CONFIG_COMEDI_CB_PCIMDAS=m
> CONFIG_COMEDI_CB_PCIMDDA=m
> CONFIG_COMEDI_ME4000=m
> CONFIG_COMEDI_ME_DAQ=m
> CONFIG_COMEDI_NI_6527=m
> CONFIG_COMEDI_NI_65XX=m
> CONFIG_COMEDI_NI_660X=m
> CONFIG_COMEDI_NI_670X=m
> CONFIG_COMEDI_NI_LABPC_PCI=m
> CONFIG_COMEDI_NI_PCIDIO=m
> CONFIG_COMEDI_NI_PCIMIO=m
> CONFIG_COMEDI_RTD520=m
> CONFIG_COMEDI_S626=m
> CONFIG_COMEDI_MITE=m
> CONFIG_COMEDI_NI_TIOCMD=m
> CONFIG_COMEDI_PCMCIA_DRIVERS=m
> CONFIG_COMEDI_CB_DAS16_CS=m
> CONFIG_COMEDI_DAS08_CS=m
> CONFIG_COMEDI_NI_DAQ_700_CS=m
> CONFIG_COMEDI_NI_DAQ_DIO24_CS=m
> CONFIG_COMEDI_NI_LABPC_CS=m
> CONFIG_COMEDI_NI_MIO_CS=m
> CONFIG_COMEDI_QUATECH_DAQP_CS=m
> CONFIG_COMEDI_USB_DRIVERS=m
> CONFIG_COMEDI_DT9812=m
> CONFIG_COMEDI_NI_USB6501=m
> CONFIG_COMEDI_USBDUX=m
> CONFIG_COMEDI_USBDUXFAST=m
> CONFIG_COMEDI_USBDUXSIGMA=m
> CONFIG_COMEDI_VMK80XX=m
> CONFIG_COMEDI_8254=m
> CONFIG_COMEDI_8255=m
> CONFIG_COMEDI_8255_SA=m
> CONFIG_COMEDI_KCOMEDILIB=m
> CONFIG_COMEDI_AMPLC_DIO200=m
> CONFIG_COMEDI_AMPLC_PC236=m
> CONFIG_COMEDI_DAS08=m
> CONFIG_COMEDI_ISADMA=m
> CONFIG_COMEDI_NI_LABPC=m
> CONFIG_COMEDI_NI_LABPC_ISADMA=m
> CONFIG_COMEDI_NI_TIO=m
> CONFIG_COMEDI_NI_ROUTING=m
> CONFIG_COMEDI_TESTS=m
> CONFIG_COMEDI_TESTS_EXAMPLE=m
> CONFIG_COMEDI_TESTS_NI_ROUTES=m
> CONFIG_STAGING=y
> CONFIG_PRISM2_USB=m
> CONFIG_RTL8192U=m
> CONFIG_RTLLIB=m
> CONFIG_RTLLIB_CRYPTO_CCMP=m
> CONFIG_RTLLIB_CRYPTO_TKIP=m
> CONFIG_RTLLIB_CRYPTO_WEP=m
> CONFIG_RTL8192E=m
> CONFIG_RTL8723BS=m
> CONFIG_R8712U=m
> CONFIG_R8188EU=m
> CONFIG_RTS5208=m
> CONFIG_VT6655=m
> CONFIG_VT6656=m
>
> #
> # IIO staging drivers
> #
>
> #
> # Accelerometers
> #
> CONFIG_ADIS16203=m
> CONFIG_ADIS16240=m
> # end of Accelerometers
>
> #
> # Analog to digital converters
> #
> CONFIG_AD7816=m
> # end of Analog to digital converters
>
> #
> # Analog digital bi-direction converters
> #
> CONFIG_ADT7316=m
> CONFIG_ADT7316_SPI=m
> CONFIG_ADT7316_I2C=m
> # end of Analog digital bi-direction converters
>
> #
> # Capacitance to digital converters
> #
> CONFIG_AD7746=m
> # end of Capacitance to digital converters
>
> #
> # Direct Digital Synthesis
> #
> CONFIG_AD9832=m
> CONFIG_AD9834=m
> # end of Direct Digital Synthesis
>
> #
> # Network Analyzer, Impedance Converters
> #
> CONFIG_AD5933=m
> # end of Network Analyzer, Impedance Converters
>
> #
> # Active energy metering IC
> #
> CONFIG_ADE7854=m
> CONFIG_ADE7854_I2C=m
> CONFIG_ADE7854_SPI=m
> # end of Active energy metering IC
>
> #
> # Resolver to digital converters
> #
> CONFIG_AD2S1210=m
> # end of Resolver to digital converters
> # end of IIO staging drivers
>
> CONFIG_FB_SM750=m
> CONFIG_STAGING_MEDIA=y
> CONFIG_INTEL_ATOMISP=y
> CONFIG_VIDEO_ATOMISP=m
> CONFIG_VIDEO_ATOMISP_ISP2401=y
> CONFIG_VIDEO_ATOMISP_OV2722=m
> CONFIG_VIDEO_ATOMISP_GC2235=m
> CONFIG_VIDEO_ATOMISP_MSRLIST_HELPER=m
> CONFIG_VIDEO_ATOMISP_MT9M114=m
> CONFIG_VIDEO_ATOMISP_GC0310=m
> CONFIG_VIDEO_ATOMISP_OV2680=m
> CONFIG_VIDEO_ATOMISP_OV5693=m
> CONFIG_VIDEO_ATOMISP_LM3554=m
> CONFIG_DVB_AV7110_IR=y
> CONFIG_DVB_AV7110=m
> CONFIG_DVB_AV7110_OSD=y
> CONFIG_DVB_BUDGET_PATCH=m
> CONFIG_DVB_SP8870=m
> CONFIG_VIDEO_IPU3_IMGU=m
> # CONFIG_VIDEO_STKWEBCAM is not set
> # CONFIG_VIDEO_ZORAN is not set
> CONFIG_LTE_GDM724X=m
> CONFIG_FIREWIRE_SERIAL=m
> CONFIG_FWTTY_MAX_TOTAL_PORTS=64
> CONFIG_FWTTY_MAX_CARD_PORTS=32
> CONFIG_FB_TFT=m
> CONFIG_FB_TFT_AGM1264K_FL=m
> CONFIG_FB_TFT_BD663474=m
> CONFIG_FB_TFT_HX8340BN=m
> CONFIG_FB_TFT_HX8347D=m
> CONFIG_FB_TFT_HX8353D=m
> CONFIG_FB_TFT_HX8357D=m
> CONFIG_FB_TFT_ILI9163=m
> CONFIG_FB_TFT_ILI9320=m
> CONFIG_FB_TFT_ILI9325=m
> CONFIG_FB_TFT_ILI9340=m
> CONFIG_FB_TFT_ILI9341=m
> CONFIG_FB_TFT_ILI9481=m
> CONFIG_FB_TFT_ILI9486=m
> CONFIG_FB_TFT_PCD8544=m
> CONFIG_FB_TFT_RA8875=m
> CONFIG_FB_TFT_S6D02A1=m
> CONFIG_FB_TFT_S6D1121=m
> CONFIG_FB_TFT_SEPS525=m
> CONFIG_FB_TFT_SH1106=m
> CONFIG_FB_TFT_SSD1289=m
> CONFIG_FB_TFT_SSD1305=m
> CONFIG_FB_TFT_SSD1306=m
> CONFIG_FB_TFT_SSD1331=m
> CONFIG_FB_TFT_SSD1351=m
> CONFIG_FB_TFT_ST7735R=m
> CONFIG_FB_TFT_ST7789V=m
> CONFIG_FB_TFT_TINYLCD=m
> CONFIG_FB_TFT_TLS8204=m
> CONFIG_FB_TFT_UC1611=m
> CONFIG_FB_TFT_UC1701=m
> CONFIG_FB_TFT_UPD161704=m
> CONFIG_MOST_COMPONENTS=m
> CONFIG_MOST_NET=m
> CONFIG_MOST_VIDEO=m
> CONFIG_MOST_I2C=m
> CONFIG_KS7010=m
> CONFIG_GREYBUS_AUDIO=m
> CONFIG_GREYBUS_AUDIO_APB_CODEC=m
> CONFIG_GREYBUS_BOOTROM=m
> CONFIG_GREYBUS_FIRMWARE=m
> CONFIG_GREYBUS_HID=m
> CONFIG_GREYBUS_LIGHT=m
> CONFIG_GREYBUS_LOG=m
> CONFIG_GREYBUS_LOOPBACK=m
> CONFIG_GREYBUS_POWER=m
> CONFIG_GREYBUS_RAW=m
> CONFIG_GREYBUS_VIBRATOR=m
> CONFIG_GREYBUS_BRIDGED_PHY=m
> CONFIG_GREYBUS_GPIO=m
> CONFIG_GREYBUS_I2C=m
> CONFIG_GREYBUS_PWM=m
> CONFIG_GREYBUS_SDIO=m
> CONFIG_GREYBUS_SPI=m
> CONFIG_GREYBUS_UART=m
> CONFIG_GREYBUS_USB=m
> CONFIG_PI433=m
> CONFIG_FIELDBUS_DEV=m
> CONFIG_QLGE=m
> CONFIG_VME_BUS=y
>
> #
> # VME Bridge Drivers
> #
> CONFIG_VME_TSI148=m
> CONFIG_VME_FAKE=m
>
> #
> # VME Device Drivers
> #
> CONFIG_VME_USER=m
> CONFIG_CHROME_PLATFORMS=y
> CONFIG_CHROMEOS_ACPI=m
> CONFIG_CHROMEOS_LAPTOP=m
> CONFIG_CHROMEOS_PSTORE=m
> CONFIG_CHROMEOS_TBMC=m
> CONFIG_CROS_EC=m
> CONFIG_CROS_EC_I2C=m
> CONFIG_CROS_EC_ISHTP=m
> CONFIG_CROS_EC_SPI=m
> CONFIG_CROS_EC_LPC=m
> CONFIG_CROS_EC_PROTO=y
> CONFIG_CROS_KBD_LED_BACKLIGHT=m
> CONFIG_CROS_EC_CHARDEV=m
> CONFIG_CROS_EC_LIGHTBAR=m
> CONFIG_CROS_EC_DEBUGFS=m
> CONFIG_CROS_EC_SENSORHUB=m
> CONFIG_CROS_EC_SYSFS=m
> CONFIG_CROS_EC_TYPEC=m
> CONFIG_CROS_USBPD_LOGGER=m
> CONFIG_CROS_USBPD_NOTIFY=m
> CONFIG_CHROMEOS_PRIVACY_SCREEN=m
> CONFIG_WILCO_EC=m
> CONFIG_WILCO_EC_DEBUGFS=m
> CONFIG_WILCO_EC_EVENTS=m
> CONFIG_WILCO_EC_TELEMETRY=m
> CONFIG_MELLANOX_PLATFORM=y
> CONFIG_MLXREG_HOTPLUG=m
> CONFIG_MLXREG_IO=m
> CONFIG_MLXREG_LC=m
> CONFIG_NVSW_SN2201=m
> CONFIG_SURFACE_PLATFORMS=y
> CONFIG_SURFACE3_WMI=m
> CONFIG_SURFACE_3_POWER_OPREGION=m
> CONFIG_SURFACE_ACPI_NOTIFY=m
> CONFIG_SURFACE_AGGREGATOR_CDEV=m
> CONFIG_SURFACE_AGGREGATOR_HUB=m
> CONFIG_SURFACE_AGGREGATOR_REGISTRY=m
> CONFIG_SURFACE_AGGREGATOR_TABLET_SWITCH=m
> CONFIG_SURFACE_DTX=m
> CONFIG_SURFACE_GPE=m
> CONFIG_SURFACE_HOTPLUG=m
> CONFIG_SURFACE_PLATFORM_PROFILE=m
> CONFIG_SURFACE_PRO3_BUTTON=m
> CONFIG_SURFACE_AGGREGATOR=m
> CONFIG_SURFACE_AGGREGATOR_BUS=y
> # CONFIG_SURFACE_AGGREGATOR_ERROR_INJECTION is not set
> CONFIG_X86_PLATFORM_DEVICES=y
> CONFIG_ACPI_WMI=m
> CONFIG_WMI_BMOF=m
> CONFIG_HUAWEI_WMI=m
> CONFIG_UV_SYSFS=m
> CONFIG_MXM_WMI=m
> CONFIG_PEAQ_WMI=m
> CONFIG_NVIDIA_WMI_EC_BACKLIGHT=m
> CONFIG_XIAOMI_WMI=m
> CONFIG_GIGABYTE_WMI=m
> CONFIG_YOGABOOK_WMI=m
> CONFIG_ACERHDF=m
> CONFIG_ACER_WIRELESS=m
> CONFIG_ACER_WMI=m
> CONFIG_AMD_PMC=m
> CONFIG_AMD_HSMP=m
> CONFIG_ADV_SWBUTTON=m
> CONFIG_APPLE_GMUX=m
> CONFIG_ASUS_LAPTOP=m
> CONFIG_ASUS_WIRELESS=m
> CONFIG_ASUS_WMI=m
> CONFIG_ASUS_NB_WMI=m
> CONFIG_ASUS_TF103C_DOCK=m
> CONFIG_MERAKI_MX100=m
> CONFIG_EEEPC_LAPTOP=m
> CONFIG_EEEPC_WMI=m
> CONFIG_X86_PLATFORM_DRIVERS_DELL=y
> CONFIG_ALIENWARE_WMI=m
> CONFIG_DCDBAS=m
> CONFIG_DELL_LAPTOP=m
> CONFIG_DELL_RBU=m
> CONFIG_DELL_RBTN=m
> CONFIG_DELL_SMBIOS=m
> CONFIG_DELL_SMBIOS_WMI=y
> CONFIG_DELL_SMBIOS_SMM=y
> CONFIG_DELL_SMO8800=m
> CONFIG_DELL_WMI=m
> CONFIG_DELL_WMI_PRIVACY=y
> CONFIG_DELL_WMI_AIO=m
> CONFIG_DELL_WMI_DESCRIPTOR=m
> CONFIG_DELL_WMI_LED=m
> CONFIG_DELL_WMI_SYSMAN=m
> CONFIG_AMILO_RFKILL=m
> CONFIG_FUJITSU_LAPTOP=m
> CONFIG_FUJITSU_TABLET=m
> CONFIG_GPD_POCKET_FAN=m
> CONFIG_HP_ACCEL=m
> CONFIG_WIRELESS_HOTKEY=m
> CONFIG_HP_WMI=m
> CONFIG_IBM_RTL=m
> CONFIG_IDEAPAD_LAPTOP=m
> CONFIG_SENSORS_HDAPS=m
> CONFIG_THINKPAD_ACPI=m
> CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y
> CONFIG_THINKPAD_ACPI_DEBUGFACILITIES=y
> # CONFIG_THINKPAD_ACPI_DEBUG is not set
> # CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
> CONFIG_THINKPAD_ACPI_VIDEO=y
> CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
> CONFIG_THINKPAD_LMI=m
> CONFIG_INTEL_ATOMISP2_PDX86=y
> CONFIG_INTEL_ATOMISP2_LED=m
> CONFIG_INTEL_SAR_INT1092=m
> CONFIG_INTEL_SKL_INT3472=m
> CONFIG_INTEL_PMC_CORE=y
> CONFIG_INTEL_PMT_CLASS=m
> CONFIG_INTEL_PMT_TELEMETRY=m
> CONFIG_INTEL_PMT_CRASHLOG=m
>
> #
> # Intel Speed Select Technology interface support
> #
> CONFIG_INTEL_SPEED_SELECT_INTERFACE=m
> # end of Intel Speed Select Technology interface support
>
> CONFIG_INTEL_TELEMETRY=m
> CONFIG_INTEL_WMI=y
> CONFIG_INTEL_WMI_SBL_FW_UPDATE=m
> CONFIG_INTEL_WMI_THUNDERBOLT=m
>
> #
> # Intel Uncore Frequency Control
> #
> CONFIG_INTEL_UNCORE_FREQ_CONTROL=m
> # end of Intel Uncore Frequency Control
>
> CONFIG_INTEL_HID_EVENT=m
> CONFIG_INTEL_VBTN=m
> CONFIG_INTEL_INT0002_VGPIO=m
> CONFIG_INTEL_OAKTRAIL=m
> CONFIG_INTEL_BXTWC_PMIC_TMU=m
> CONFIG_INTEL_CHTDC_TI_PWRBTN=m
> CONFIG_INTEL_CHTWC_INT33FE=m
> CONFIG_INTEL_ISHTP_ECLITE=m
> CONFIG_INTEL_MRFLD_PWRBTN=m
> CONFIG_INTEL_PUNIT_IPC=m
> CONFIG_INTEL_RST=m
> CONFIG_INTEL_SDSI=m
> CONFIG_INTEL_SMARTCONNECT=m
> CONFIG_INTEL_TURBO_MAX_3=y
> CONFIG_INTEL_VSEC=m
> CONFIG_MSI_LAPTOP=m
> CONFIG_MSI_WMI=m
> CONFIG_PCENGINES_APU2=m
> CONFIG_BARCO_P50_GPIO=m
> CONFIG_SAMSUNG_LAPTOP=m
> CONFIG_SAMSUNG_Q10=m
> CONFIG_ACPI_TOSHIBA=m
> CONFIG_TOSHIBA_BT_RFKILL=m
> CONFIG_TOSHIBA_HAPS=m
> # CONFIG_TOSHIBA_WMI is not set
> CONFIG_ACPI_CMPC=m
> CONFIG_COMPAL_LAPTOP=m
> CONFIG_LG_LAPTOP=m
> CONFIG_PANASONIC_LAPTOP=m
> CONFIG_SONY_LAPTOP=m
> CONFIG_SONYPI_COMPAT=y
> CONFIG_SYSTEM76_ACPI=m
> CONFIG_TOPSTAR_LAPTOP=m
> CONFIG_SERIAL_MULTI_INSTANTIATE=m
> CONFIG_MLX_PLATFORM=m
> CONFIG_TOUCHSCREEN_DMI=y
> CONFIG_X86_ANDROID_TABLETS=m
> CONFIG_FW_ATTR_CLASS=m
> CONFIG_INTEL_IPS=m
> CONFIG_INTEL_SCU_IPC=y
> CONFIG_INTEL_SCU=y
> CONFIG_INTEL_SCU_PCI=y
> CONFIG_INTEL_SCU_PLATFORM=m
> CONFIG_INTEL_SCU_IPC_UTIL=m
> CONFIG_SIEMENS_SIMATIC_IPC=m
> CONFIG_WINMATE_FM07_KEYS=m
> CONFIG_P2SB=y
> CONFIG_HAVE_CLK=y
> CONFIG_HAVE_CLK_PREPARE=y
> CONFIG_COMMON_CLK=y
> CONFIG_COMMON_CLK_WM831X=m
> CONFIG_LMK04832=m
> CONFIG_COMMON_CLK_MAX9485=m
> CONFIG_COMMON_CLK_SI5341=m
> CONFIG_COMMON_CLK_SI5351=m
> CONFIG_COMMON_CLK_SI544=m
> CONFIG_COMMON_CLK_CDCE706=m
> CONFIG_COMMON_CLK_TPS68470=m
> CONFIG_COMMON_CLK_CS2000_CP=m
> CONFIG_CLK_TWL6040=m
> CONFIG_COMMON_CLK_PALMAS=m
> CONFIG_COMMON_CLK_PWM=m
> CONFIG_XILINX_VCU=m
> CONFIG_HWSPINLOCK=y
>
> #
> # Clock Source drivers
> #
> CONFIG_CLKEVT_I8253=y
> CONFIG_I8253_LOCK=y
> CONFIG_CLKBLD_I8253=y
> # end of Clock Source drivers
>
> CONFIG_MAILBOX=y
> CONFIG_PCC=y
> CONFIG_ALTERA_MBOX=m
> CONFIG_IOMMU_IOVA=y
> CONFIG_IOASID=y
> CONFIG_IOMMU_API=y
> CONFIG_IOMMU_SUPPORT=y
>
> #
> # Generic IOMMU Pagetable Support
> #
> CONFIG_IOMMU_IO_PGTABLE=y
> # end of Generic IOMMU Pagetable Support
>
> # CONFIG_IOMMU_DEBUGFS is not set
> # CONFIG_IOMMU_DEFAULT_DMA_STRICT is not set
> CONFIG_IOMMU_DEFAULT_DMA_LAZY=y
> # CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set
> CONFIG_IOMMU_DMA=y
> CONFIG_IOMMU_SVA=y
> CONFIG_AMD_IOMMU=y
> CONFIG_AMD_IOMMU_V2=m
> CONFIG_DMAR_TABLE=y
> CONFIG_INTEL_IOMMU=y
> CONFIG_INTEL_IOMMU_SVM=y
> # CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
> CONFIG_INTEL_IOMMU_FLOPPY_WA=y
> # CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON is not set
> CONFIG_IRQ_REMAP=y
> CONFIG_HYPERV_IOMMU=y
> CONFIG_VIRTIO_IOMMU=y
>
> #
> # Remoteproc drivers
> #
> CONFIG_REMOTEPROC=y
> CONFIG_REMOTEPROC_CDEV=y
> # end of Remoteproc drivers
>
> #
> # Rpmsg drivers
> #
> CONFIG_RPMSG=m
> CONFIG_RPMSG_CHAR=m
> CONFIG_RPMSG_CTRL=m
> CONFIG_RPMSG_NS=m
> CONFIG_RPMSG_QCOM_GLINK=m
> CONFIG_RPMSG_QCOM_GLINK_RPM=m
> CONFIG_RPMSG_VIRTIO=m
> # end of Rpmsg drivers
>
> CONFIG_SOUNDWIRE=m
>
> #
> # SoundWire Devices
> #
> CONFIG_SOUNDWIRE_CADENCE=m
> CONFIG_SOUNDWIRE_INTEL=m
> CONFIG_SOUNDWIRE_QCOM=m
> CONFIG_SOUNDWIRE_GENERIC_ALLOCATION=m
>
> #
> # SOC (System On Chip) specific Drivers
> #
>
> #
> # Amlogic SoC drivers
> #
> # end of Amlogic SoC drivers
>
> #
> # Broadcom SoC drivers
> #
> # end of Broadcom SoC drivers
>
> #
> # NXP/Freescale QorIQ SoC drivers
> #
> # end of NXP/Freescale QorIQ SoC drivers
>
> #
> # fujitsu SoC drivers
> #
> # end of fujitsu SoC drivers
>
> #
> # i.MX SoC drivers
> #
> # end of i.MX SoC drivers
>
> #
> # Enable LiteX SoC Builder specific drivers
> #
> # end of Enable LiteX SoC Builder specific drivers
>
> #
> # Qualcomm SoC drivers
> #
> CONFIG_QCOM_QMI_HELPERS=m
> # end of Qualcomm SoC drivers
>
> CONFIG_SOC_TI=y
>
> #
> # Xilinx SoC drivers
> #
> # end of Xilinx SoC drivers
> # end of SOC (System On Chip) specific Drivers
>
> CONFIG_PM_DEVFREQ=y
>
> #
> # DEVFREQ Governors
> #
> CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y
> CONFIG_DEVFREQ_GOV_PERFORMANCE=y
> CONFIG_DEVFREQ_GOV_POWERSAVE=y
> CONFIG_DEVFREQ_GOV_USERSPACE=y
> CONFIG_DEVFREQ_GOV_PASSIVE=y
>
> #
> # DEVFREQ Drivers
> #
> CONFIG_PM_DEVFREQ_EVENT=y
> CONFIG_EXTCON=y
>
> #
> # Extcon Device Drivers
> #
> CONFIG_EXTCON_ADC_JACK=m
> CONFIG_EXTCON_AXP288=m
> CONFIG_EXTCON_FSA9480=m
> CONFIG_EXTCON_GPIO=m
> CONFIG_EXTCON_INTEL_INT3496=m
> CONFIG_EXTCON_INTEL_CHT_WC=m
> CONFIG_EXTCON_INTEL_MRFLD=m
> CONFIG_EXTCON_MAX14577=m
> CONFIG_EXTCON_MAX3355=m
> CONFIG_EXTCON_MAX77693=m
> CONFIG_EXTCON_MAX77843=m
> CONFIG_EXTCON_MAX8997=m
> CONFIG_EXTCON_PALMAS=m
> CONFIG_EXTCON_PTN5150=m
> CONFIG_EXTCON_RT8973A=m
> CONFIG_EXTCON_SM5502=m
> CONFIG_EXTCON_USB_GPIO=m
> CONFIG_EXTCON_USBC_CROS_EC=m
> CONFIG_EXTCON_USBC_TUSB320=m
> CONFIG_MEMORY=y
> CONFIG_FPGA_DFL_EMIF=m
> CONFIG_IIO=m
> CONFIG_IIO_BUFFER=y
> CONFIG_IIO_BUFFER_CB=m
> CONFIG_IIO_BUFFER_DMA=m
> CONFIG_IIO_BUFFER_DMAENGINE=m
> CONFIG_IIO_BUFFER_HW_CONSUMER=m
> CONFIG_IIO_KFIFO_BUF=m
> CONFIG_IIO_TRIGGERED_BUFFER=m
> CONFIG_IIO_CONFIGFS=m
> CONFIG_IIO_TRIGGER=y
> CONFIG_IIO_CONSUMERS_PER_TRIGGER=2
> CONFIG_IIO_SW_DEVICE=m
> CONFIG_IIO_SW_TRIGGER=m
> CONFIG_IIO_TRIGGERED_EVENT=m
>
> #
> # Accelerometers
> #
> CONFIG_ADIS16201=m
> CONFIG_ADIS16209=m
> CONFIG_ADXL313=m
> CONFIG_ADXL313_I2C=m
> CONFIG_ADXL313_SPI=m
> CONFIG_ADXL355=m
> CONFIG_ADXL355_I2C=m
> CONFIG_ADXL355_SPI=m
> CONFIG_ADXL367=m
> CONFIG_ADXL367_SPI=m
> CONFIG_ADXL367_I2C=m
> CONFIG_ADXL372=m
> CONFIG_ADXL372_SPI=m
> CONFIG_ADXL372_I2C=m
> CONFIG_BMA220=m
> CONFIG_BMA400=m
> CONFIG_BMA400_I2C=m
> CONFIG_BMA400_SPI=m
> CONFIG_BMC150_ACCEL=m
> CONFIG_BMC150_ACCEL_I2C=m
> CONFIG_BMC150_ACCEL_SPI=m
> CONFIG_BMI088_ACCEL=m
> CONFIG_BMI088_ACCEL_SPI=m
> CONFIG_DA280=m
> CONFIG_DA311=m
> CONFIG_DMARD06=m
> CONFIG_DMARD09=m
> CONFIG_DMARD10=m
> CONFIG_FXLS8962AF=m
> CONFIG_FXLS8962AF_I2C=m
> CONFIG_FXLS8962AF_SPI=m
> CONFIG_HID_SENSOR_ACCEL_3D=m
> CONFIG_IIO_CROS_EC_ACCEL_LEGACY=m
> CONFIG_IIO_ST_ACCEL_3AXIS=m
> CONFIG_IIO_ST_ACCEL_I2C_3AXIS=m
> CONFIG_IIO_ST_ACCEL_SPI_3AXIS=m
> CONFIG_KXSD9=m
> CONFIG_KXSD9_SPI=m
> CONFIG_KXSD9_I2C=m
> CONFIG_KXCJK1013=m
> CONFIG_MC3230=m
> CONFIG_MMA7455=m
> CONFIG_MMA7455_I2C=m
> CONFIG_MMA7455_SPI=m
> CONFIG_MMA7660=m
> CONFIG_MMA8452=m
> CONFIG_MMA9551_CORE=m
> CONFIG_MMA9551=m
> CONFIG_MMA9553=m
> CONFIG_MXC4005=m
> CONFIG_MXC6255=m
> CONFIG_SCA3000=m
> CONFIG_SCA3300=m
> CONFIG_STK8312=m
> CONFIG_STK8BA50=m
> # end of Accelerometers
>
> #
> # Analog to digital converters
> #
> CONFIG_AD_SIGMA_DELTA=m
> CONFIG_AD7091R5=m
> CONFIG_AD7124=m
> CONFIG_AD7192=m
> CONFIG_AD7266=m
> CONFIG_AD7280=m
> CONFIG_AD7291=m
> CONFIG_AD7292=m
> CONFIG_AD7298=m
> CONFIG_AD7476=m
> CONFIG_AD7606=m
> CONFIG_AD7606_IFACE_PARALLEL=m
> CONFIG_AD7606_IFACE_SPI=m
> CONFIG_AD7766=m
> CONFIG_AD7768_1=m
> CONFIG_AD7780=m
> CONFIG_AD7791=m
> CONFIG_AD7793=m
> CONFIG_AD7887=m
> CONFIG_AD7923=m
> CONFIG_AD7949=m
> CONFIG_AD799X=m
> CONFIG_AXP20X_ADC=m
> CONFIG_AXP288_ADC=m
> CONFIG_CC10001_ADC=m
> CONFIG_DA9150_GPADC=m
> CONFIG_DLN2_ADC=m
> CONFIG_ENVELOPE_DETECTOR=m
> CONFIG_HI8435=m
> CONFIG_HX711=m
> CONFIG_INA2XX_ADC=m
> CONFIG_INTEL_MRFLD_ADC=m
> CONFIG_LP8788_ADC=m
> CONFIG_LTC2471=m
> CONFIG_LTC2485=m
> CONFIG_LTC2496=m
> CONFIG_LTC2497=m
> CONFIG_MAX1027=m
> CONFIG_MAX11100=m
> CONFIG_MAX1118=m
> CONFIG_MAX1241=m
> CONFIG_MAX1363=m
> CONFIG_MAX9611=m
> CONFIG_MCP320X=m
> CONFIG_MCP3422=m
> CONFIG_MCP3911=m
> CONFIG_MEDIATEK_MT6360_ADC=m
> CONFIG_MEN_Z188_ADC=m
> CONFIG_MP2629_ADC=m
> CONFIG_NAU7802=m
> CONFIG_PALMAS_GPADC=m
> CONFIG_QCOM_VADC_COMMON=m
> CONFIG_QCOM_SPMI_IADC=m
> CONFIG_QCOM_SPMI_VADC=m
> CONFIG_QCOM_SPMI_ADC5=m
> CONFIG_SD_ADC_MODULATOR=m
> CONFIG_STX104=m
> CONFIG_TI_ADC081C=m
> CONFIG_TI_ADC0832=m
> CONFIG_TI_ADC084S021=m
> CONFIG_TI_ADC12138=m
> CONFIG_TI_ADC108S102=m
> CONFIG_TI_ADC128S052=m
> CONFIG_TI_ADC161S626=m
> CONFIG_TI_ADS1015=m
> CONFIG_TI_ADS7950=m
> CONFIG_TI_ADS8344=m
> CONFIG_TI_ADS8688=m
> CONFIG_TI_ADS124S08=m
> CONFIG_TI_ADS131E08=m
> CONFIG_TI_AM335X_ADC=m
> CONFIG_TI_TLC4541=m
> CONFIG_TI_TSC2046=m
> CONFIG_TWL4030_MADC=m
> CONFIG_TWL6030_GPADC=m
> CONFIG_VF610_ADC=m
> CONFIG_VIPERBOARD_ADC=m
> CONFIG_XILINX_XADC=m
> # end of Analog to digital converters
>
> #
> # Analog to digital and digital to analog converters
> #
> CONFIG_AD74413R=m
> # end of Analog to digital and digital to analog converters
>
> #
> # Analog Front Ends
> #
> CONFIG_IIO_RESCALE=m
> # end of Analog Front Ends
>
> #
> # Amplifiers
> #
> CONFIG_AD8366=m
> CONFIG_ADA4250=m
> CONFIG_HMC425=m
> # end of Amplifiers
>
> #
> # Capacitance to digital converters
> #
> CONFIG_AD7150=m
> # end of Capacitance to digital converters
>
> #
> # Chemical Sensors
> #
> CONFIG_ATLAS_PH_SENSOR=m
> CONFIG_ATLAS_EZO_SENSOR=m
> CONFIG_BME680=m
> CONFIG_BME680_I2C=m
> CONFIG_BME680_SPI=m
> CONFIG_CCS811=m
> CONFIG_IAQCORE=m
> CONFIG_PMS7003=m
> CONFIG_SCD30_CORE=m
> CONFIG_SCD30_I2C=m
> CONFIG_SCD30_SERIAL=m
> CONFIG_SCD4X=m
> CONFIG_SENSIRION_SGP30=m
> CONFIG_SENSIRION_SGP40=m
> CONFIG_SPS30=m
> CONFIG_SPS30_I2C=m
> CONFIG_SPS30_SERIAL=m
> CONFIG_SENSEAIR_SUNRISE_CO2=m
> CONFIG_VZ89X=m
> # end of Chemical Sensors
>
> CONFIG_IIO_CROS_EC_SENSORS_CORE=m
> CONFIG_IIO_CROS_EC_SENSORS=m
> CONFIG_IIO_CROS_EC_SENSORS_LID_ANGLE=m
>
> #
> # Hid Sensor IIO Common
> #
> CONFIG_HID_SENSOR_IIO_COMMON=m
> CONFIG_HID_SENSOR_IIO_TRIGGER=m
> # end of Hid Sensor IIO Common
>
> CONFIG_IIO_MS_SENSORS_I2C=m
>
> #
> # IIO SCMI Sensors
> #
> # end of IIO SCMI Sensors
>
> #
> # SSP Sensor Common
> #
> CONFIG_IIO_SSP_SENSORS_COMMONS=m
> CONFIG_IIO_SSP_SENSORHUB=m
> # end of SSP Sensor Common
>
> CONFIG_IIO_ST_SENSORS_I2C=m
> CONFIG_IIO_ST_SENSORS_SPI=m
> CONFIG_IIO_ST_SENSORS_CORE=m
>
> #
> # Digital to analog converters
> #
> CONFIG_AD3552R=m
> CONFIG_AD5064=m
> CONFIG_AD5360=m
> CONFIG_AD5380=m
> CONFIG_AD5421=m
> CONFIG_AD5446=m
> CONFIG_AD5449=m
> CONFIG_AD5592R_BASE=m
> CONFIG_AD5592R=m
> CONFIG_AD5593R=m
> CONFIG_AD5504=m
> CONFIG_AD5624R_SPI=m
> CONFIG_LTC2688=m
> CONFIG_AD5686=m
> CONFIG_AD5686_SPI=m
> CONFIG_AD5696_I2C=m
> CONFIG_AD5755=m
> CONFIG_AD5758=m
> CONFIG_AD5761=m
> CONFIG_AD5764=m
> CONFIG_AD5766=m
> CONFIG_AD5770R=m
> CONFIG_AD5791=m
> CONFIG_AD7293=m
> CONFIG_AD7303=m
> CONFIG_AD8801=m
> CONFIG_CIO_DAC=m
> CONFIG_DPOT_DAC=m
> CONFIG_DS4424=m
> CONFIG_LTC1660=m
> CONFIG_LTC2632=m
> CONFIG_M62332=m
> CONFIG_MAX517=m
> CONFIG_MAX5821=m
> CONFIG_MCP4725=m
> CONFIG_MCP4922=m
> CONFIG_TI_DAC082S085=m
> CONFIG_TI_DAC5571=m
> CONFIG_TI_DAC7311=m
> CONFIG_TI_DAC7612=m
> CONFIG_VF610_DAC=m
> # end of Digital to analog converters
>
> #
> # IIO dummy driver
> #
> CONFIG_IIO_SIMPLE_DUMMY=m
> # CONFIG_IIO_SIMPLE_DUMMY_EVENTS is not set
> # CONFIG_IIO_SIMPLE_DUMMY_BUFFER is not set
> # end of IIO dummy driver
>
> #
> # Filters
> #
> CONFIG_ADMV8818=m
> # end of Filters
>
> #
> # Frequency Synthesizers DDS/PLL
> #
>
> #
> # Clock Generator/Distribution
> #
> CONFIG_AD9523=m
> # end of Clock Generator/Distribution
>
> #
> # Phase-Locked Loop (PLL) frequency synthesizers
> #
> CONFIG_ADF4350=m
> CONFIG_ADF4371=m
> CONFIG_ADMV1013=m
> CONFIG_ADMV1014=m
> CONFIG_ADMV4420=m
> CONFIG_ADRF6780=m
> # end of Phase-Locked Loop (PLL) frequency synthesizers
> # end of Frequency Synthesizers DDS/PLL
>
> #
> # Digital gyroscope sensors
> #
> CONFIG_ADIS16080=m
> CONFIG_ADIS16130=m
> CONFIG_ADIS16136=m
> CONFIG_ADIS16260=m
> CONFIG_ADXRS290=m
> CONFIG_ADXRS450=m
> CONFIG_BMG160=m
> CONFIG_BMG160_I2C=m
> CONFIG_BMG160_SPI=m
> CONFIG_FXAS21002C=m
> CONFIG_FXAS21002C_I2C=m
> CONFIG_FXAS21002C_SPI=m
> CONFIG_HID_SENSOR_GYRO_3D=m
> CONFIG_MPU3050=m
> CONFIG_MPU3050_I2C=m
> CONFIG_IIO_ST_GYRO_3AXIS=m
> CONFIG_IIO_ST_GYRO_I2C_3AXIS=m
> CONFIG_IIO_ST_GYRO_SPI_3AXIS=m
> CONFIG_ITG3200=m
> # end of Digital gyroscope sensors
>
> #
> # Health Sensors
> #
>
> #
> # Heart Rate Monitors
> #
> CONFIG_AFE4403=m
> CONFIG_AFE4404=m
> CONFIG_MAX30100=m
> CONFIG_MAX30102=m
> # end of Heart Rate Monitors
> # end of Health Sensors
>
> #
> # Humidity sensors
> #
> CONFIG_AM2315=m
> CONFIG_DHT11=m
> CONFIG_HDC100X=m
> CONFIG_HDC2010=m
> CONFIG_HID_SENSOR_HUMIDITY=m
> CONFIG_HTS221=m
> CONFIG_HTS221_I2C=m
> CONFIG_HTS221_SPI=m
> CONFIG_HTU21=m
> CONFIG_SI7005=m
> CONFIG_SI7020=m
> # end of Humidity sensors
>
> #
> # Inertial measurement units
> #
> CONFIG_ADIS16400=m
> CONFIG_ADIS16460=m
> CONFIG_ADIS16475=m
> CONFIG_ADIS16480=m
> CONFIG_BMI160=m
> CONFIG_BMI160_I2C=m
> CONFIG_BMI160_SPI=m
> CONFIG_FXOS8700=m
> CONFIG_FXOS8700_I2C=m
> CONFIG_FXOS8700_SPI=m
> CONFIG_KMX61=m
> CONFIG_INV_ICM42600=m
> CONFIG_INV_ICM42600_I2C=m
> CONFIG_INV_ICM42600_SPI=m
> CONFIG_INV_MPU6050_IIO=m
> CONFIG_INV_MPU6050_I2C=m
> CONFIG_INV_MPU6050_SPI=m
> CONFIG_IIO_ST_LSM6DSX=m
> CONFIG_IIO_ST_LSM6DSX_I2C=m
> CONFIG_IIO_ST_LSM6DSX_SPI=m
> CONFIG_IIO_ST_LSM6DSX_I3C=m
> CONFIG_IIO_ST_LSM9DS0=m
> CONFIG_IIO_ST_LSM9DS0_I2C=m
> CONFIG_IIO_ST_LSM9DS0_SPI=m
> # end of Inertial measurement units
>
> CONFIG_IIO_ADIS_LIB=m
> CONFIG_IIO_ADIS_LIB_BUFFER=y
>
> #
> # Light sensors
> #
> CONFIG_ACPI_ALS=m
> CONFIG_ADJD_S311=m
> CONFIG_ADUX1020=m
> CONFIG_AL3010=m
> CONFIG_AL3320A=m
> CONFIG_APDS9300=m
> CONFIG_APDS9960=m
> CONFIG_AS73211=m
> CONFIG_BH1750=m
> CONFIG_BH1780=m
> CONFIG_CM32181=m
> CONFIG_CM3232=m
> CONFIG_CM3323=m
> CONFIG_CM3605=m
> CONFIG_CM36651=m
> CONFIG_IIO_CROS_EC_LIGHT_PROX=m
> CONFIG_GP2AP002=m
> CONFIG_GP2AP020A00F=m
> CONFIG_IQS621_ALS=m
> CONFIG_SENSORS_ISL29018=m
> CONFIG_SENSORS_ISL29028=m
> CONFIG_ISL29125=m
> CONFIG_HID_SENSOR_ALS=m
> CONFIG_HID_SENSOR_PROX=m
> CONFIG_JSA1212=m
> CONFIG_RPR0521=m
> CONFIG_SENSORS_LM3533=m
> CONFIG_LTR501=m
> CONFIG_LV0104CS=m
> CONFIG_MAX44000=m
> CONFIG_MAX44009=m
> CONFIG_NOA1305=m
> CONFIG_OPT3001=m
> CONFIG_PA12203001=m
> CONFIG_SI1133=m
> CONFIG_SI1145=m
> CONFIG_STK3310=m
> CONFIG_ST_UVIS25=m
> CONFIG_ST_UVIS25_I2C=m
> CONFIG_ST_UVIS25_SPI=m
> CONFIG_TCS3414=m
> CONFIG_TCS3472=m
> CONFIG_SENSORS_TSL2563=m
> CONFIG_TSL2583=m
> CONFIG_TSL2591=m
> CONFIG_TSL2772=m
> CONFIG_TSL4531=m
> CONFIG_US5182D=m
> CONFIG_VCNL4000=m
> CONFIG_VCNL4035=m
> CONFIG_VEML6030=m
> CONFIG_VEML6070=m
> CONFIG_VL6180=m
> CONFIG_ZOPT2201=m
> # end of Light sensors
>
> #
> # Magnetometer sensors
> #
> CONFIG_AK8974=m
> CONFIG_AK8975=m
> CONFIG_AK09911=m
> CONFIG_BMC150_MAGN=m
> CONFIG_BMC150_MAGN_I2C=m
> CONFIG_BMC150_MAGN_SPI=m
> CONFIG_MAG3110=m
> CONFIG_HID_SENSOR_MAGNETOMETER_3D=m
> CONFIG_MMC35240=m
> CONFIG_IIO_ST_MAGN_3AXIS=m
> CONFIG_IIO_ST_MAGN_I2C_3AXIS=m
> CONFIG_IIO_ST_MAGN_SPI_3AXIS=m
> CONFIG_SENSORS_HMC5843=m
> CONFIG_SENSORS_HMC5843_I2C=m
> CONFIG_SENSORS_HMC5843_SPI=m
> CONFIG_SENSORS_RM3100=m
> CONFIG_SENSORS_RM3100_I2C=m
> CONFIG_SENSORS_RM3100_SPI=m
> CONFIG_YAMAHA_YAS530=m
> # end of Magnetometer sensors
>
> #
> # Multiplexers
> #
> CONFIG_IIO_MUX=m
> # end of Multiplexers
>
> #
> # Inclinometer sensors
> #
> CONFIG_HID_SENSOR_INCLINOMETER_3D=m
> CONFIG_HID_SENSOR_DEVICE_ROTATION=m
> # end of Inclinometer sensors
>
> #
> # Triggers - standalone
> #
> CONFIG_IIO_HRTIMER_TRIGGER=m
> CONFIG_IIO_INTERRUPT_TRIGGER=m
> CONFIG_IIO_TIGHTLOOP_TRIGGER=m
> CONFIG_IIO_SYSFS_TRIGGER=m
> # end of Triggers - standalone
>
> #
> # Linear and angular position sensors
> #
> CONFIG_IQS624_POS=m
> CONFIG_HID_SENSOR_CUSTOM_INTEL_HINGE=m
> # end of Linear and angular position sensors
>
> #
> # Digital potentiometers
> #
> CONFIG_AD5110=m
> CONFIG_AD5272=m
> CONFIG_DS1803=m
> CONFIG_MAX5432=m
> CONFIG_MAX5481=m
> CONFIG_MAX5487=m
> CONFIG_MCP4018=m
> CONFIG_MCP4131=m
> CONFIG_MCP4531=m
> CONFIG_MCP41010=m
> CONFIG_TPL0102=m
> # end of Digital potentiometers
>
> #
> # Digital potentiostats
> #
> CONFIG_LMP91000=m
> # end of Digital potentiostats
>
> #
> # Pressure sensors
> #
> CONFIG_ABP060MG=m
> CONFIG_BMP280=m
> CONFIG_BMP280_I2C=m
> CONFIG_BMP280_SPI=m
> CONFIG_IIO_CROS_EC_BARO=m
> CONFIG_DLHL60D=m
> CONFIG_DPS310=m
> CONFIG_HID_SENSOR_PRESS=m
> CONFIG_HP03=m
> CONFIG_ICP10100=m
> CONFIG_MPL115=m
> CONFIG_MPL115_I2C=m
> CONFIG_MPL115_SPI=m
> CONFIG_MPL3115=m
> CONFIG_MS5611=m
> CONFIG_MS5611_I2C=m
> CONFIG_MS5611_SPI=m
> CONFIG_MS5637=m
> CONFIG_IIO_ST_PRESS=m
> CONFIG_IIO_ST_PRESS_I2C=m
> CONFIG_IIO_ST_PRESS_SPI=m
> CONFIG_T5403=m
> CONFIG_HP206C=m
> CONFIG_ZPA2326=m
> CONFIG_ZPA2326_I2C=m
> CONFIG_ZPA2326_SPI=m
> # end of Pressure sensors
>
> #
> # Lightning sensors
> #
> CONFIG_AS3935=m
> # end of Lightning sensors
>
> #
> # Proximity and distance sensors
> #
> CONFIG_CROS_EC_MKBP_PROXIMITY=m
> CONFIG_ISL29501=m
> CONFIG_LIDAR_LITE_V2=m
> CONFIG_MB1232=m
> CONFIG_PING=m
> CONFIG_RFD77402=m
> CONFIG_SRF04=m
> CONFIG_SX_COMMON=m
> CONFIG_SX9310=m
> CONFIG_SX9324=m
> CONFIG_SX9360=m
> CONFIG_SX9500=m
> CONFIG_SRF08=m
> CONFIG_VCNL3020=m
> CONFIG_VL53L0X_I2C=m
> # end of Proximity and distance sensors
>
> #
> # Resolver to digital converters
> #
> CONFIG_AD2S90=m
> CONFIG_AD2S1200=m
> # end of Resolver to digital converters
>
> #
> # Temperature sensors
> #
> CONFIG_IQS620AT_TEMP=m
> CONFIG_LTC2983=m
> CONFIG_MAXIM_THERMOCOUPLE=m
> CONFIG_HID_SENSOR_TEMP=m
> CONFIG_MLX90614=m
> CONFIG_MLX90632=m
> CONFIG_TMP006=m
> CONFIG_TMP007=m
> CONFIG_TMP117=m
> CONFIG_TSYS01=m
> CONFIG_TSYS02D=m
> CONFIG_MAX31856=m
> CONFIG_MAX31865=m
> # end of Temperature sensors
>
> CONFIG_NTB=m
> CONFIG_NTB_MSI=y
> # CONFIG_NTB_AMD is not set
> CONFIG_NTB_IDT=m
> CONFIG_NTB_INTEL=m
> CONFIG_NTB_EPF=m
> CONFIG_NTB_SWITCHTEC=m
> CONFIG_NTB_PINGPONG=m
> CONFIG_NTB_TOOL=m
> CONFIG_NTB_PERF=m
> # CONFIG_NTB_MSI_TEST is not set
> CONFIG_NTB_TRANSPORT=m
> CONFIG_PWM=y
> CONFIG_PWM_SYSFS=y
> # CONFIG_PWM_DEBUG is not set
> CONFIG_PWM_CLK=m
> CONFIG_PWM_CRC=y
> CONFIG_PWM_CROS_EC=m
> CONFIG_PWM_DWC=m
> CONFIG_PWM_IQS620A=m
> CONFIG_PWM_LP3943=m
> CONFIG_PWM_LPSS=y
> CONFIG_PWM_LPSS_PCI=y
> CONFIG_PWM_LPSS_PLATFORM=y
> CONFIG_PWM_PCA9685=m
> CONFIG_PWM_TWL=m
> CONFIG_PWM_TWL_LED=m
>
> #
> # IRQ chip support
> #
> CONFIG_MADERA_IRQ=m
> # end of IRQ chip support
>
> CONFIG_IPACK_BUS=m
> CONFIG_BOARD_TPCI200=m
> CONFIG_SERIAL_IPOCTAL=m
> CONFIG_RESET_CONTROLLER=y
> CONFIG_RESET_SIMPLE=y
> CONFIG_RESET_TI_SYSCON=m
> CONFIG_RESET_TI_TPS380X=m
>
> #
> # PHY Subsystem
> #
> CONFIG_GENERIC_PHY=y
> CONFIG_USB_LGM_PHY=m
> CONFIG_PHY_CAN_TRANSCEIVER=m
>
> #
> # PHY drivers for Broadcom platforms
> #
> CONFIG_BCM_KONA_USB2_PHY=m
> # end of PHY drivers for Broadcom platforms
>
> CONFIG_PHY_PXA_28NM_HSIC=m
> CONFIG_PHY_PXA_28NM_USB2=m
> CONFIG_PHY_CPCAP_USB=m
> CONFIG_PHY_QCOM_USB_HS=m
> CONFIG_PHY_QCOM_USB_HSIC=m
> CONFIG_PHY_SAMSUNG_USB2=m
> CONFIG_PHY_TUSB1210=m
> CONFIG_PHY_INTEL_LGM_EMMC=m
> # end of PHY Subsystem
>
> CONFIG_POWERCAP=y
> CONFIG_INTEL_RAPL_CORE=m
> CONFIG_INTEL_RAPL=m
> CONFIG_IDLE_INJECT=y
> CONFIG_MCB=m
> CONFIG_MCB_PCI=m
> CONFIG_MCB_LPC=m
>
> #
> # Performance monitor support
> #
> # end of Performance monitor support
>
> CONFIG_RAS=y
> CONFIG_RAS_CEC=y
> # CONFIG_RAS_CEC_DEBUG is not set
> CONFIG_USB4=m
> # CONFIG_USB4_DEBUGFS_WRITE is not set
> # CONFIG_USB4_DMA_TEST is not set
>
> #
> # Android
> #
> # CONFIG_ANDROID_BINDER_IPC is not set
> # end of Android
>
> CONFIG_LIBNVDIMM=y
> CONFIG_BLK_DEV_PMEM=m
> CONFIG_ND_CLAIM=y
> CONFIG_ND_BTT=m
> CONFIG_BTT=y
> CONFIG_ND_PFN=m
> CONFIG_NVDIMM_PFN=y
> CONFIG_NVDIMM_DAX=y
> CONFIG_NVDIMM_KEYS=y
> CONFIG_DAX=y
> CONFIG_DEV_DAX=m
> CONFIG_DEV_DAX_PMEM=m
> CONFIG_DEV_DAX_HMEM=m
> CONFIG_DEV_DAX_HMEM_DEVICES=y
> CONFIG_DEV_DAX_KMEM=m
> CONFIG_NVMEM=y
> CONFIG_NVMEM_SYSFS=y
> CONFIG_NVMEM_SPMI_SDAM=m
> CONFIG_RAVE_SP_EEPROM=m
> CONFIG_NVMEM_RMEM=m
>
> #
> # HW tracing support
> #
> CONFIG_STM=m
> CONFIG_STM_PROTO_BASIC=m
> CONFIG_STM_PROTO_SYS_T=m
> CONFIG_STM_DUMMY=m
> CONFIG_STM_SOURCE_CONSOLE=m
> CONFIG_STM_SOURCE_HEARTBEAT=m
> CONFIG_STM_SOURCE_FTRACE=m
> CONFIG_INTEL_TH=m
> CONFIG_INTEL_TH_PCI=m
> CONFIG_INTEL_TH_ACPI=m
> CONFIG_INTEL_TH_GTH=m
> CONFIG_INTEL_TH_STH=m
> CONFIG_INTEL_TH_MSU=m
> CONFIG_INTEL_TH_PTI=m
> # CONFIG_INTEL_TH_DEBUG is not set
> # end of HW tracing support
>
> CONFIG_FPGA=m
> CONFIG_ALTERA_PR_IP_CORE=m
> CONFIG_FPGA_MGR_ALTERA_PS_SPI=m
> CONFIG_FPGA_MGR_ALTERA_CVP=m
> CONFIG_FPGA_MGR_XILINX_SPI=m
> CONFIG_FPGA_MGR_MACHXO2_SPI=m
> CONFIG_FPGA_BRIDGE=m
> CONFIG_ALTERA_FREEZE_BRIDGE=m
> CONFIG_XILINX_PR_DECOUPLER=m
> CONFIG_FPGA_REGION=m
> CONFIG_FPGA_DFL=m
> CONFIG_FPGA_DFL_FME=m
> CONFIG_FPGA_DFL_FME_MGR=m
> CONFIG_FPGA_DFL_FME_BRIDGE=m
> CONFIG_FPGA_DFL_FME_REGION=m
> CONFIG_FPGA_DFL_AFU=m
> CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000=m
> CONFIG_FPGA_DFL_PCI=m
> CONFIG_FPGA_MGR_MICROCHIP_SPI=m
> CONFIG_TEE=m
> CONFIG_AMDTEE=m
> CONFIG_MULTIPLEXER=m
>
> #
> # Multiplexer drivers
> #
> CONFIG_MUX_ADG792A=m
> CONFIG_MUX_ADGS1408=m
> CONFIG_MUX_GPIO=m
> # end of Multiplexer drivers
>
> CONFIG_PM_OPP=y
> CONFIG_SIOX=m
> CONFIG_SIOX_BUS_GPIO=m
> CONFIG_SLIMBUS=m
> CONFIG_SLIM_QCOM_CTRL=m
> CONFIG_INTERCONNECT=y
> CONFIG_COUNTER=m
> CONFIG_104_QUAD_8=m
> CONFIG_INTERRUPT_CNT=m
> CONFIG_INTEL_QEP=m
> CONFIG_MOST=m
> CONFIG_MOST_USB_HDM=m
> CONFIG_MOST_CDEV=m
> CONFIG_MOST_SND=m
> CONFIG_PECI=m
> CONFIG_PECI_CPU=m
> CONFIG_HTE=y
> # end of Device Drivers
>
> #
> # File systems
> #
> CONFIG_DCACHE_WORD_ACCESS=y
> CONFIG_VALIDATE_FS_PARSER=y
> CONFIG_FS_IOMAP=y
> # CONFIG_EXT2_FS is not set
> # CONFIG_EXT3_FS is not set
> CONFIG_EXT4_FS=y
> CONFIG_EXT4_USE_FOR_EXT2=y
> CONFIG_EXT4_FS_POSIX_ACL=y
> CONFIG_EXT4_FS_SECURITY=y
> # CONFIG_EXT4_DEBUG is not set
> CONFIG_JBD2=y
> # CONFIG_JBD2_DEBUG is not set
> CONFIG_FS_MBCACHE=y
> CONFIG_REISERFS_FS=m
> # CONFIG_REISERFS_CHECK is not set
> # CONFIG_REISERFS_PROC_INFO is not set
> CONFIG_REISERFS_FS_XATTR=y
> CONFIG_REISERFS_FS_POSIX_ACL=y
> CONFIG_REISERFS_FS_SECURITY=y
> CONFIG_JFS_FS=m
> CONFIG_JFS_POSIX_ACL=y
> CONFIG_JFS_SECURITY=y
> # CONFIG_JFS_DEBUG is not set
> CONFIG_JFS_STATISTICS=y
> CONFIG_XFS_FS=m
> CONFIG_XFS_SUPPORT_V4=y
> CONFIG_XFS_QUOTA=y
> CONFIG_XFS_POSIX_ACL=y
> CONFIG_XFS_RT=y
> # CONFIG_XFS_ONLINE_SCRUB is not set
> # CONFIG_XFS_WARN is not set
> # CONFIG_XFS_DEBUG is not set
> CONFIG_GFS2_FS=m
> CONFIG_GFS2_FS_LOCKING_DLM=y
> CONFIG_OCFS2_FS=m
> CONFIG_OCFS2_FS_O2CB=m
> CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m
> CONFIG_OCFS2_FS_STATS=y
> CONFIG_OCFS2_DEBUG_MASKLOG=y
> # CONFIG_OCFS2_DEBUG_FS is not set
> CONFIG_BTRFS_FS=m
> CONFIG_BTRFS_FS_POSIX_ACL=y
> # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
> # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
> # CONFIG_BTRFS_DEBUG is not set
> # CONFIG_BTRFS_ASSERT is not set
> # CONFIG_BTRFS_FS_REF_VERIFY is not set
> CONFIG_NILFS2_FS=m
> CONFIG_F2FS_FS=m
> CONFIG_F2FS_STAT_FS=y
> CONFIG_F2FS_FS_XATTR=y
> CONFIG_F2FS_FS_POSIX_ACL=y
> CONFIG_F2FS_FS_SECURITY=y
> # CONFIG_F2FS_CHECK_FS is not set
> # CONFIG_F2FS_FAULT_INJECTION is not set
> CONFIG_F2FS_FS_COMPRESSION=y
> CONFIG_F2FS_FS_LZO=y
> CONFIG_F2FS_FS_LZORLE=y
> CONFIG_F2FS_FS_LZ4=y
> CONFIG_F2FS_FS_LZ4HC=y
> CONFIG_F2FS_FS_ZSTD=y
> # CONFIG_F2FS_IOSTAT is not set
> CONFIG_F2FS_UNFAIR_RWSEM=y
> CONFIG_ZONEFS_FS=m
> CONFIG_FS_DAX=y
> CONFIG_FS_DAX_PMD=y
> CONFIG_FS_POSIX_ACL=y
> CONFIG_EXPORTFS=y
> CONFIG_EXPORTFS_BLOCK_OPS=y
> CONFIG_FILE_LOCKING=y
> CONFIG_FS_ENCRYPTION=y
> CONFIG_FS_ENCRYPTION_ALGS=y
> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
> CONFIG_FS_VERITY=y
> # CONFIG_FS_VERITY_DEBUG is not set
> CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y
> CONFIG_FSNOTIFY=y
> CONFIG_DNOTIFY=y
> CONFIG_INOTIFY_USER=y
> CONFIG_FANOTIFY=y
> CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
> CONFIG_QUOTA=y
> CONFIG_QUOTA_NETLINK_INTERFACE=y
> # CONFIG_PRINT_QUOTA_WARNING is not set
> # CONFIG_QUOTA_DEBUG is not set
> CONFIG_QUOTA_TREE=m
> CONFIG_QFMT_V1=m
> CONFIG_QFMT_V2=m
> CONFIG_QUOTACTL=y
> CONFIG_AUTOFS4_FS=m
> CONFIG_AUTOFS_FS=m
> CONFIG_FUSE_FS=y
> CONFIG_CUSE=m
> CONFIG_VIRTIO_FS=m
> CONFIG_FUSE_DAX=y
> CONFIG_OVERLAY_FS=m
> # CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
> CONFIG_OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW=y
> # CONFIG_OVERLAY_FS_INDEX is not set
> CONFIG_OVERLAY_FS_XINO_AUTO=y
> # CONFIG_OVERLAY_FS_METACOPY is not set
>
> #
> # Caches
> #
> CONFIG_NETFS_SUPPORT=m
> CONFIG_NETFS_STATS=y
> CONFIG_FSCACHE=m
> CONFIG_FSCACHE_STATS=y
> # CONFIG_FSCACHE_DEBUG is not set
> CONFIG_CACHEFILES=m
> # CONFIG_CACHEFILES_DEBUG is not set
> CONFIG_CACHEFILES_ERROR_INJECTION=y
> # CONFIG_CACHEFILES_ONDEMAND is not set
> # end of Caches
>
> #
> # CD-ROM/DVD Filesystems
> #
> CONFIG_ISO9660_FS=m
> CONFIG_JOLIET=y
> CONFIG_ZISOFS=y
> CONFIG_UDF_FS=m
> # end of CD-ROM/DVD Filesystems
>
> #
> # DOS/FAT/EXFAT/NT Filesystems
> #
> CONFIG_FAT_FS=y
> CONFIG_MSDOS_FS=m
> CONFIG_VFAT_FS=y
> CONFIG_FAT_DEFAULT_CODEPAGE=437
> CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
> # CONFIG_FAT_DEFAULT_UTF8 is not set
> CONFIG_EXFAT_FS=m
> CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
> CONFIG_NTFS_FS=m
> # CONFIG_NTFS_DEBUG is not set
> # CONFIG_NTFS_RW is not set
> CONFIG_NTFS3_FS=m
> # CONFIG_NTFS3_64BIT_CLUSTER is not set
> CONFIG_NTFS3_LZX_XPRESS=y
> CONFIG_NTFS3_FS_POSIX_ACL=y
> # end of DOS/FAT/EXFAT/NT Filesystems
>
> #
> # Pseudo filesystems
> #
> CONFIG_PROC_FS=y
> CONFIG_PROC_KCORE=y
> CONFIG_PROC_VMCORE=y
> CONFIG_PROC_VMCORE_DEVICE_DUMP=y
> CONFIG_PROC_SYSCTL=y
> CONFIG_PROC_PAGE_MONITOR=y
> CONFIG_PROC_CHILDREN=y
> CONFIG_PROC_PID_ARCH_STATUS=y
> CONFIG_PROC_CPU_RESCTRL=y
> CONFIG_KERNFS=y
> CONFIG_SYSFS=y
> CONFIG_TMPFS=y
> CONFIG_TMPFS_POSIX_ACL=y
> CONFIG_TMPFS_XATTR=y
> CONFIG_TMPFS_INODE64=y
> CONFIG_HUGETLBFS=y
> CONFIG_HUGETLB_PAGE=y
> CONFIG_ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y
> CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y
> # CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON is not set
> CONFIG_MEMFD_CREATE=y
> CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
> CONFIG_CONFIGFS_FS=y
> CONFIG_EFIVAR_FS=y
> # end of Pseudo filesystems
>
> CONFIG_MISC_FILESYSTEMS=y
> CONFIG_ORANGEFS_FS=m
> CONFIG_ADFS_FS=m
> # CONFIG_ADFS_FS_RW is not set
> CONFIG_AFFS_FS=m
> CONFIG_ECRYPT_FS=y
> CONFIG_ECRYPT_FS_MESSAGING=y
> CONFIG_HFS_FS=m
> CONFIG_HFSPLUS_FS=m
> CONFIG_BEFS_FS=m
> # CONFIG_BEFS_DEBUG is not set
> CONFIG_BFS_FS=m
> CONFIG_EFS_FS=m
> CONFIG_JFFS2_FS=m
> CONFIG_JFFS2_FS_DEBUG=0
> CONFIG_JFFS2_FS_WRITEBUFFER=y
> # CONFIG_JFFS2_FS_WBUF_VERIFY is not set
> # CONFIG_JFFS2_SUMMARY is not set
> CONFIG_JFFS2_FS_XATTR=y
> CONFIG_JFFS2_FS_POSIX_ACL=y
> CONFIG_JFFS2_FS_SECURITY=y
> CONFIG_JFFS2_COMPRESSION_OPTIONS=y
> CONFIG_JFFS2_ZLIB=y
> CONFIG_JFFS2_LZO=y
> CONFIG_JFFS2_RTIME=y
> # CONFIG_JFFS2_RUBIN is not set
> # CONFIG_JFFS2_CMODE_NONE is not set
> # CONFIG_JFFS2_CMODE_PRIORITY is not set
> # CONFIG_JFFS2_CMODE_SIZE is not set
> CONFIG_JFFS2_CMODE_FAVOURLZO=y
> CONFIG_UBIFS_FS=m
> # CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
> CONFIG_UBIFS_FS_LZO=y
> CONFIG_UBIFS_FS_ZLIB=y
> CONFIG_UBIFS_FS_ZSTD=y
> # CONFIG_UBIFS_ATIME_SUPPORT is not set
> CONFIG_UBIFS_FS_XATTR=y
> CONFIG_UBIFS_FS_SECURITY=y
> CONFIG_UBIFS_FS_AUTHENTICATION=y
> CONFIG_CRAMFS=m
> CONFIG_CRAMFS_BLOCKDEV=y
> CONFIG_CRAMFS_MTD=y
> CONFIG_SQUASHFS=y
> # CONFIG_SQUASHFS_FILE_CACHE is not set
> CONFIG_SQUASHFS_FILE_DIRECT=y
> CONFIG_SQUASHFS_DECOMP_SINGLE=y
> # CONFIG_SQUASHFS_DECOMP_MULTI is not set
> # CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set
> CONFIG_SQUASHFS_XATTR=y
> CONFIG_SQUASHFS_ZLIB=y
> CONFIG_SQUASHFS_LZ4=y
> CONFIG_SQUASHFS_LZO=y
> CONFIG_SQUASHFS_XZ=y
> CONFIG_SQUASHFS_ZSTD=y
> # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
> # CONFIG_SQUASHFS_EMBEDDED is not set
> CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
> CONFIG_VXFS_FS=m
> CONFIG_MINIX_FS=m
> CONFIG_OMFS_FS=m
> CONFIG_HPFS_FS=m
> CONFIG_QNX4FS_FS=m
> CONFIG_QNX6FS_FS=m
> # CONFIG_QNX6FS_DEBUG is not set
> CONFIG_ROMFS_FS=m
> CONFIG_ROMFS_BACKED_BY_BLOCK=y
> # CONFIG_ROMFS_BACKED_BY_MTD is not set
> # CONFIG_ROMFS_BACKED_BY_BOTH is not set
> CONFIG_ROMFS_ON_BLOCK=y
> CONFIG_PSTORE=y
> CONFIG_PSTORE_DEFAULT_KMSG_BYTES=10240
> CONFIG_PSTORE_DEFLATE_COMPRESS=y
> # CONFIG_PSTORE_LZO_COMPRESS is not set
> # CONFIG_PSTORE_LZ4_COMPRESS is not set
> # CONFIG_PSTORE_LZ4HC_COMPRESS is not set
> # CONFIG_PSTORE_842_COMPRESS is not set
> # CONFIG_PSTORE_ZSTD_COMPRESS is not set
> CONFIG_PSTORE_COMPRESS=y
> CONFIG_PSTORE_DEFLATE_COMPRESS_DEFAULT=y
> CONFIG_PSTORE_COMPRESS_DEFAULT="deflate"
> # CONFIG_PSTORE_CONSOLE is not set
> # CONFIG_PSTORE_PMSG is not set
> # CONFIG_PSTORE_FTRACE is not set
> CONFIG_PSTORE_RAM=m
> CONFIG_PSTORE_ZONE=m
> CONFIG_PSTORE_BLK=m
> CONFIG_PSTORE_BLK_BLKDEV=""
> CONFIG_PSTORE_BLK_KMSG_SIZE=64
> CONFIG_PSTORE_BLK_MAX_REASON=2
> CONFIG_SYSV_FS=m
> CONFIG_UFS_FS=m
> # CONFIG_UFS_FS_WRITE is not set
> # CONFIG_UFS_DEBUG is not set
> CONFIG_EROFS_FS=m
> # CONFIG_EROFS_FS_DEBUG is not set
> CONFIG_EROFS_FS_XATTR=y
> CONFIG_EROFS_FS_POSIX_ACL=y
> CONFIG_EROFS_FS_SECURITY=y
> CONFIG_EROFS_FS_ZIP=y
> # CONFIG_EROFS_FS_ZIP_LZMA is not set
> CONFIG_VBOXSF_FS=m
> CONFIG_NETWORK_FILESYSTEMS=y
> CONFIG_NFS_FS=m
> CONFIG_NFS_V2=m
> CONFIG_NFS_V3=m
> CONFIG_NFS_V3_ACL=y
> CONFIG_NFS_V4=m
> CONFIG_NFS_SWAP=y
> CONFIG_NFS_V4_1=y
> CONFIG_NFS_V4_2=y
> CONFIG_PNFS_FILE_LAYOUT=m
> CONFIG_PNFS_BLOCK=m
> CONFIG_PNFS_FLEXFILE_LAYOUT=m
> CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
> CONFIG_NFS_V4_1_MIGRATION=y
> CONFIG_NFS_V4_SECURITY_LABEL=y
> CONFIG_NFS_FSCACHE=y
> # CONFIG_NFS_USE_LEGACY_DNS is not set
> CONFIG_NFS_USE_KERNEL_DNS=y
> CONFIG_NFS_DEBUG=y
> CONFIG_NFS_DISABLE_UDP_SUPPORT=y
> # CONFIG_NFS_V4_2_READ_PLUS is not set
> CONFIG_NFSD=m
> CONFIG_NFSD_V2_ACL=y
> CONFIG_NFSD_V3_ACL=y
> CONFIG_NFSD_V4=y
> CONFIG_NFSD_PNFS=y
> CONFIG_NFSD_BLOCKLAYOUT=y
> CONFIG_NFSD_SCSILAYOUT=y
> CONFIG_NFSD_FLEXFILELAYOUT=y
> CONFIG_NFSD_V4_2_INTER_SSC=y
> CONFIG_NFSD_V4_SECURITY_LABEL=y
> CONFIG_GRACE_PERIOD=m
> CONFIG_LOCKD=m
> CONFIG_LOCKD_V4=y
> CONFIG_NFS_ACL_SUPPORT=m
> CONFIG_NFS_COMMON=y
> CONFIG_NFS_V4_2_SSC_HELPER=y
> CONFIG_SUNRPC=m
> CONFIG_SUNRPC_GSS=m
> CONFIG_SUNRPC_BACKCHANNEL=y
> CONFIG_SUNRPC_SWAP=y
> CONFIG_RPCSEC_GSS_KRB5=m
> CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES=y
> CONFIG_SUNRPC_DEBUG=y
> CONFIG_SUNRPC_XPRT_RDMA=m
> CONFIG_CEPH_FS=m
> CONFIG_CEPH_FSCACHE=y
> CONFIG_CEPH_FS_POSIX_ACL=y
> CONFIG_CEPH_FS_SECURITY_LABEL=y
> CONFIG_CIFS=m
> # CONFIG_CIFS_STATS2 is not set
> CONFIG_CIFS_ALLOW_INSECURE_LEGACY=y
> CONFIG_CIFS_UPCALL=y
> CONFIG_CIFS_XATTR=y
> CONFIG_CIFS_POSIX=y
> CONFIG_CIFS_DEBUG=y
> # CONFIG_CIFS_DEBUG2 is not set
> # CONFIG_CIFS_DEBUG_DUMP_KEYS is not set
> CONFIG_CIFS_DFS_UPCALL=y
> CONFIG_CIFS_SWN_UPCALL=y
> # CONFIG_CIFS_SMB_DIRECT is not set
> CONFIG_CIFS_FSCACHE=y
> CONFIG_SMB_SERVER=m
> CONFIG_SMB_SERVER_SMBDIRECT=y
> CONFIG_SMB_SERVER_CHECK_CAP_NET_ADMIN=y
> CONFIG_SMB_SERVER_KERBEROS5=y
> CONFIG_SMBFS_COMMON=m
> CONFIG_CODA_FS=m
> CONFIG_AFS_FS=m
> # CONFIG_AFS_DEBUG is not set
> CONFIG_AFS_FSCACHE=y
> # CONFIG_AFS_DEBUG_CURSOR is not set
> CONFIG_9P_FS=m
> CONFIG_9P_FSCACHE=y
> CONFIG_9P_FS_POSIX_ACL=y
> CONFIG_9P_FS_SECURITY=y
> CONFIG_NLS=y
> CONFIG_NLS_DEFAULT="utf8"
> CONFIG_NLS_CODEPAGE_437=y
> CONFIG_NLS_CODEPAGE_737=m
> CONFIG_NLS_CODEPAGE_775=m
> CONFIG_NLS_CODEPAGE_850=m
> CONFIG_NLS_CODEPAGE_852=m
> CONFIG_NLS_CODEPAGE_855=m
> CONFIG_NLS_CODEPAGE_857=m
> CONFIG_NLS_CODEPAGE_860=m
> CONFIG_NLS_CODEPAGE_861=m
> CONFIG_NLS_CODEPAGE_862=m
> CONFIG_NLS_CODEPAGE_863=m
> CONFIG_NLS_CODEPAGE_864=m
> CONFIG_NLS_CODEPAGE_865=m
> CONFIG_NLS_CODEPAGE_866=m
> CONFIG_NLS_CODEPAGE_869=m
> CONFIG_NLS_CODEPAGE_936=m
> CONFIG_NLS_CODEPAGE_950=m
> CONFIG_NLS_CODEPAGE_932=m
> CONFIG_NLS_CODEPAGE_949=m
> CONFIG_NLS_CODEPAGE_874=m
> CONFIG_NLS_ISO8859_8=m
> CONFIG_NLS_CODEPAGE_1250=m
> CONFIG_NLS_CODEPAGE_1251=m
> CONFIG_NLS_ASCII=m
> CONFIG_NLS_ISO8859_1=m
> CONFIG_NLS_ISO8859_2=m
> CONFIG_NLS_ISO8859_3=m
> CONFIG_NLS_ISO8859_4=m
> CONFIG_NLS_ISO8859_5=m
> CONFIG_NLS_ISO8859_6=m
> CONFIG_NLS_ISO8859_7=m
> CONFIG_NLS_ISO8859_9=m
> CONFIG_NLS_ISO8859_13=m
> CONFIG_NLS_ISO8859_14=m
> CONFIG_NLS_ISO8859_15=m
> CONFIG_NLS_KOI8_R=m
> CONFIG_NLS_KOI8_U=m
> CONFIG_NLS_MAC_ROMAN=m
> CONFIG_NLS_MAC_CELTIC=m
> CONFIG_NLS_MAC_CENTEURO=m
> CONFIG_NLS_MAC_CROATIAN=m
> CONFIG_NLS_MAC_CYRILLIC=m
> CONFIG_NLS_MAC_GAELIC=m
> CONFIG_NLS_MAC_GREEK=m
> CONFIG_NLS_MAC_ICELAND=m
> CONFIG_NLS_MAC_INUIT=m
> CONFIG_NLS_MAC_ROMANIAN=m
> CONFIG_NLS_MAC_TURKISH=m
> CONFIG_NLS_UTF8=m
> CONFIG_DLM=m
> # CONFIG_DLM_DEPRECATED_API is not set
> # CONFIG_DLM_DEBUG is not set
> CONFIG_UNICODE=y
> # CONFIG_UNICODE_NORMALIZATION_SELFTEST is not set
> CONFIG_IO_WQ=y
> # end of File systems
>
> #
> # Security options
> #
> CONFIG_KEYS=y
> CONFIG_KEYS_REQUEST_CACHE=y
> CONFIG_PERSISTENT_KEYRINGS=y
> CONFIG_TRUSTED_KEYS=y
> CONFIG_TRUSTED_KEYS_TPM=y
> CONFIG_ENCRYPTED_KEYS=y
> CONFIG_USER_DECRYPTED_DATA=y
> CONFIG_KEY_DH_OPERATIONS=y
> CONFIG_KEY_NOTIFICATIONS=y
> CONFIG_SECURITY_DMESG_RESTRICT=y
> CONFIG_SECURITY=y
> CONFIG_SECURITYFS=y
> CONFIG_SECURITY_NETWORK=y
> CONFIG_SECURITY_INFINIBAND=y
> CONFIG_SECURITY_NETWORK_XFRM=y
> CONFIG_SECURITY_PATH=y
> CONFIG_INTEL_TXT=y
> CONFIG_LSM_MMAP_MIN_ADDR=0
> CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
> CONFIG_HARDENED_USERCOPY=y
> CONFIG_FORTIFY_SOURCE=y
> # CONFIG_STATIC_USERMODEHELPER is not set
> CONFIG_SECURITY_SELINUX=y
> CONFIG_SECURITY_SELINUX_BOOTPARAM=y
> # CONFIG_SECURITY_SELINUX_DISABLE is not set
> CONFIG_SECURITY_SELINUX_DEVELOP=y
> CONFIG_SECURITY_SELINUX_AVC_STATS=y
> CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
> CONFIG_SECURITY_SELINUX_SIDTAB_HASH_BITS=9
> CONFIG_SECURITY_SELINUX_SID2STR_CACHE_SIZE=256
> CONFIG_SECURITY_SMACK=y
> # CONFIG_SECURITY_SMACK_BRINGUP is not set
> CONFIG_SECURITY_SMACK_NETFILTER=y
> CONFIG_SECURITY_SMACK_APPEND_SIGNALS=y
> CONFIG_SECURITY_TOMOYO=y
> CONFIG_SECURITY_TOMOYO_MAX_ACCEPT_ENTRY=2048
> CONFIG_SECURITY_TOMOYO_MAX_AUDIT_LOG=1024
> # CONFIG_SECURITY_TOMOYO_OMIT_USERSPACE_LOADER is not set
> CONFIG_SECURITY_TOMOYO_POLICY_LOADER="/sbin/tomoyo-init"
> CONFIG_SECURITY_TOMOYO_ACTIVATION_TRIGGER="/sbin/init"
> # CONFIG_SECURITY_TOMOYO_INSECURE_BUILTIN_SETTING is not set
> CONFIG_SECURITY_APPARMOR=y
> # CONFIG_SECURITY_APPARMOR_DEBUG is not set
> CONFIG_SECURITY_APPARMOR_INTROSPECT_POLICY=y
> CONFIG_SECURITY_APPARMOR_HASH=y
> CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
> CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y
> CONFIG_SECURITY_APPARMOR_PARANOID_LOAD=y
> # CONFIG_SECURITY_LOADPIN is not set
> CONFIG_SECURITY_YAMA=y
> CONFIG_SECURITY_SAFESETID=y
> CONFIG_SECURITY_LOCKDOWN_LSM=y
> CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
> CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
> # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set
> # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set
> CONFIG_SECURITY_LANDLOCK=y
> CONFIG_INTEGRITY=y
> CONFIG_INTEGRITY_SIGNATURE=y
> CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
> CONFIG_INTEGRITY_TRUSTED_KEYRING=y
> CONFIG_INTEGRITY_PLATFORM_KEYRING=y
> CONFIG_INTEGRITY_MACHINE_KEYRING=y
> CONFIG_LOAD_UEFI_KEYS=y
> CONFIG_INTEGRITY_AUDIT=y
> CONFIG_IMA=y
> CONFIG_IMA_KEXEC=y
> CONFIG_IMA_MEASURE_PCR_IDX=10
> CONFIG_IMA_LSM_RULES=y
> CONFIG_IMA_NG_TEMPLATE=y
> # CONFIG_IMA_SIG_TEMPLATE is not set
> CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> CONFIG_IMA_DEFAULT_HASH_SHA1=y
> # CONFIG_IMA_DEFAULT_HASH_SHA256 is not set
> # CONFIG_IMA_DEFAULT_HASH_SHA512 is not set
> CONFIG_IMA_DEFAULT_HASH="sha1"
> # CONFIG_IMA_WRITE_POLICY is not set
> # CONFIG_IMA_READ_POLICY is not set
> CONFIG_IMA_APPRAISE=y
> CONFIG_IMA_ARCH_POLICY=y
> # CONFIG_IMA_APPRAISE_BUILD_POLICY is not set
> CONFIG_IMA_APPRAISE_BOOTPARAM=y
> CONFIG_IMA_APPRAISE_MODSIG=y
> CONFIG_IMA_TRUSTED_KEYRING=y
> # CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is not set
> # CONFIG_IMA_BLACKLIST_KEYRING is not set
> # CONFIG_IMA_LOAD_X509 is not set
> CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
> CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
> CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
> # CONFIG_IMA_DISABLE_HTABLE is not set
> CONFIG_EVM=y
> CONFIG_EVM_ATTR_FSUUID=y
> CONFIG_EVM_EXTRA_SMACK_XATTRS=y
> CONFIG_EVM_ADD_XATTRS=y
> # CONFIG_EVM_LOAD_X509 is not set
> # CONFIG_DEFAULT_SECURITY_SELINUX is not set
> # CONFIG_DEFAULT_SECURITY_SMACK is not set
> # CONFIG_DEFAULT_SECURITY_TOMOYO is not set
> CONFIG_DEFAULT_SECURITY_APPARMOR=y
> # CONFIG_DEFAULT_SECURITY_DAC is not set
> CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor"
>
> #
> # Kernel hardening options
> #
>
> #
> # Memory initialization
> #
> CONFIG_INIT_STACK_NONE=y
> CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
> # CONFIG_INIT_ON_FREE_DEFAULT_ON is not set
> CONFIG_CC_HAS_ZERO_CALL_USED_REGS=y
> # CONFIG_ZERO_CALL_USED_REGS is not set
> # end of Memory initialization
>
> CONFIG_RANDSTRUCT_NONE=y
> # end of Kernel hardening options
> # end of Security options
>
> CONFIG_XOR_BLOCKS=m
> CONFIG_ASYNC_CORE=m
> CONFIG_ASYNC_MEMCPY=m
> CONFIG_ASYNC_XOR=m
> CONFIG_ASYNC_PQ=m
> CONFIG_ASYNC_RAID6_RECOV=m
> CONFIG_CRYPTO=y
>
> #
> # Crypto core or helper
> #
> CONFIG_CRYPTO_ALGAPI=y
> CONFIG_CRYPTO_ALGAPI2=y
> CONFIG_CRYPTO_AEAD=y
> CONFIG_CRYPTO_AEAD2=y
> CONFIG_CRYPTO_SKCIPHER=y
> CONFIG_CRYPTO_SKCIPHER2=y
> CONFIG_CRYPTO_HASH=y
> CONFIG_CRYPTO_HASH2=y
> CONFIG_CRYPTO_RNG=y
> CONFIG_CRYPTO_RNG2=y
> CONFIG_CRYPTO_RNG_DEFAULT=y
> CONFIG_CRYPTO_AKCIPHER2=y
> CONFIG_CRYPTO_AKCIPHER=y
> CONFIG_CRYPTO_KPP2=y
> CONFIG_CRYPTO_KPP=y
> CONFIG_CRYPTO_ACOMP2=y
> CONFIG_CRYPTO_MANAGER=y
> CONFIG_CRYPTO_MANAGER2=y
> CONFIG_CRYPTO_USER=m
> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
> CONFIG_CRYPTO_GF128MUL=y
> CONFIG_CRYPTO_NULL=y
> CONFIG_CRYPTO_NULL2=y
> CONFIG_CRYPTO_PCRYPT=m
> CONFIG_CRYPTO_CRYPTD=m
> CONFIG_CRYPTO_AUTHENC=m
> CONFIG_CRYPTO_TEST=m
> CONFIG_CRYPTO_SIMD=m
> CONFIG_CRYPTO_ENGINE=m
>
> #
> # Public-key cryptography
> #
> CONFIG_CRYPTO_RSA=y
> CONFIG_CRYPTO_DH=y
> CONFIG_CRYPTO_DH_RFC7919_GROUPS=y
> CONFIG_CRYPTO_ECC=m
> CONFIG_CRYPTO_ECDH=m
> CONFIG_CRYPTO_ECDSA=m
> CONFIG_CRYPTO_ECRDSA=m
> CONFIG_CRYPTO_SM2=m
> CONFIG_CRYPTO_CURVE25519=m
> CONFIG_CRYPTO_CURVE25519_X86=m
>
> #
> # Authenticated Encryption with Associated Data
> #
> CONFIG_CRYPTO_CCM=m
> CONFIG_CRYPTO_GCM=y
> CONFIG_CRYPTO_CHACHA20POLY1305=m
> CONFIG_CRYPTO_AEGIS128=m
> CONFIG_CRYPTO_AEGIS128_AESNI_SSE2=m
> CONFIG_CRYPTO_SEQIV=y
> CONFIG_CRYPTO_ECHAINIV=m
>
> #
> # Block modes
> #
> CONFIG_CRYPTO_CBC=y
> CONFIG_CRYPTO_CFB=m
> CONFIG_CRYPTO_CTR=y
> CONFIG_CRYPTO_CTS=y
> CONFIG_CRYPTO_ECB=y
> CONFIG_CRYPTO_LRW=m
> CONFIG_CRYPTO_OFB=m
> CONFIG_CRYPTO_PCBC=m
> CONFIG_CRYPTO_XCTR=m
> CONFIG_CRYPTO_XTS=y
> CONFIG_CRYPTO_KEYWRAP=m
> CONFIG_CRYPTO_NHPOLY1305=m
> CONFIG_CRYPTO_NHPOLY1305_SSE2=m
> CONFIG_CRYPTO_NHPOLY1305_AVX2=m
> CONFIG_CRYPTO_ADIANTUM=m
> CONFIG_CRYPTO_HCTR2=m
> CONFIG_CRYPTO_ESSIV=m
>
> #
> # Hash modes
> #
> CONFIG_CRYPTO_CMAC=m
> CONFIG_CRYPTO_HMAC=y
> CONFIG_CRYPTO_XCBC=m
> CONFIG_CRYPTO_VMAC=m
>
> #
> # Digest
> #
> CONFIG_CRYPTO_CRC32C=y
> CONFIG_CRYPTO_CRC32C_INTEL=y
> CONFIG_CRYPTO_CRC32=m
> CONFIG_CRYPTO_CRC32_PCLMUL=m
> CONFIG_CRYPTO_XXHASH=m
> CONFIG_CRYPTO_BLAKE2B=m
> CONFIG_CRYPTO_BLAKE2S_X86=y
> CONFIG_CRYPTO_CRCT10DIF=y
> CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
> CONFIG_CRYPTO_CRC64_ROCKSOFT=y
> CONFIG_CRYPTO_GHASH=y
> CONFIG_CRYPTO_POLYVAL=m
> CONFIG_CRYPTO_POLYVAL_CLMUL_NI=m
> CONFIG_CRYPTO_POLY1305=m
> CONFIG_CRYPTO_POLY1305_X86_64=m
> CONFIG_CRYPTO_MD4=m
> CONFIG_CRYPTO_MD5=y
> CONFIG_CRYPTO_MICHAEL_MIC=m
> CONFIG_CRYPTO_RMD160=m
> CONFIG_CRYPTO_SHA1=y
> CONFIG_CRYPTO_SHA1_SSSE3=m
> CONFIG_CRYPTO_SHA256_SSSE3=m
> CONFIG_CRYPTO_SHA512_SSSE3=m
> CONFIG_CRYPTO_SHA256=y
> CONFIG_CRYPTO_SHA512=y
> CONFIG_CRYPTO_SHA3=m
> CONFIG_CRYPTO_SM3=m
> CONFIG_CRYPTO_SM3_GENERIC=m
> CONFIG_CRYPTO_SM3_AVX_X86_64=m
> CONFIG_CRYPTO_STREEBOG=m
> CONFIG_CRYPTO_WP512=m
> CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
>
> #
> # Ciphers
> #
> CONFIG_CRYPTO_AES=y
> CONFIG_CRYPTO_AES_TI=m
> CONFIG_CRYPTO_AES_NI_INTEL=m
> CONFIG_CRYPTO_BLOWFISH=m
> CONFIG_CRYPTO_BLOWFISH_COMMON=m
> CONFIG_CRYPTO_BLOWFISH_X86_64=m
> CONFIG_CRYPTO_CAMELLIA=m
> CONFIG_CRYPTO_CAMELLIA_X86_64=m
> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
> CONFIG_CRYPTO_CAST_COMMON=m
> CONFIG_CRYPTO_CAST5=m
> CONFIG_CRYPTO_CAST5_AVX_X86_64=m
> CONFIG_CRYPTO_CAST6=m
> CONFIG_CRYPTO_CAST6_AVX_X86_64=m
> CONFIG_CRYPTO_DES=m
> CONFIG_CRYPTO_DES3_EDE_X86_64=m
> CONFIG_CRYPTO_FCRYPT=m
> CONFIG_CRYPTO_CHACHA20=m
> CONFIG_CRYPTO_CHACHA20_X86_64=m
> CONFIG_CRYPTO_ARIA=m
> CONFIG_CRYPTO_SERPENT=m
> CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
> CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
> CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
> CONFIG_CRYPTO_SM4=m
> CONFIG_CRYPTO_SM4_GENERIC=m
> CONFIG_CRYPTO_SM4_AESNI_AVX_X86_64=m
> CONFIG_CRYPTO_SM4_AESNI_AVX2_X86_64=m
> CONFIG_CRYPTO_TWOFISH=m
> CONFIG_CRYPTO_TWOFISH_COMMON=m
> CONFIG_CRYPTO_TWOFISH_X86_64=m
> CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
> CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
>
> #
> # Compression
> #
> CONFIG_CRYPTO_DEFLATE=y
> CONFIG_CRYPTO_LZO=y
> CONFIG_CRYPTO_842=m
> CONFIG_CRYPTO_LZ4=m
> CONFIG_CRYPTO_LZ4HC=m
> CONFIG_CRYPTO_ZSTD=m
>
> #
> # Random Number Generation
> #
> CONFIG_CRYPTO_ANSI_CPRNG=m
> CONFIG_CRYPTO_DRBG_MENU=y
> CONFIG_CRYPTO_DRBG_HMAC=y
> CONFIG_CRYPTO_DRBG_HASH=y
> CONFIG_CRYPTO_DRBG_CTR=y
> CONFIG_CRYPTO_DRBG=y
> CONFIG_CRYPTO_JITTERENTROPY=y
> CONFIG_CRYPTO_KDF800108_CTR=y
> CONFIG_CRYPTO_USER_API=m
> CONFIG_CRYPTO_USER_API_HASH=m
> CONFIG_CRYPTO_USER_API_SKCIPHER=m
> CONFIG_CRYPTO_USER_API_RNG=m
> # CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
> CONFIG_CRYPTO_USER_API_AEAD=m
> # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> CONFIG_CRYPTO_STATS=y
> CONFIG_CRYPTO_HASH_INFO=y
> CONFIG_CRYPTO_HW=y
> CONFIG_CRYPTO_DEV_PADLOCK=y
> CONFIG_CRYPTO_DEV_PADLOCK_AES=m
> CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
> CONFIG_CRYPTO_DEV_ATMEL_I2C=m
> CONFIG_CRYPTO_DEV_ATMEL_ECC=m
> CONFIG_CRYPTO_DEV_ATMEL_SHA204A=m
> CONFIG_CRYPTO_DEV_CCP=y
> CONFIG_CRYPTO_DEV_CCP_DD=m
> CONFIG_CRYPTO_DEV_SP_CCP=y
> CONFIG_CRYPTO_DEV_CCP_CRYPTO=m
> CONFIG_CRYPTO_DEV_SP_PSP=y
> # CONFIG_CRYPTO_DEV_CCP_DEBUGFS is not set
> CONFIG_CRYPTO_DEV_QAT=m
> CONFIG_CRYPTO_DEV_QAT_DH895xCC=m
> CONFIG_CRYPTO_DEV_QAT_C3XXX=m
> CONFIG_CRYPTO_DEV_QAT_C62X=m
> CONFIG_CRYPTO_DEV_QAT_4XXX=m
> CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
> CONFIG_CRYPTO_DEV_QAT_C3XXXVF=m
> CONFIG_CRYPTO_DEV_QAT_C62XVF=m
> CONFIG_CRYPTO_DEV_NITROX=m
> CONFIG_CRYPTO_DEV_NITROX_CNN55XX=m
> CONFIG_CRYPTO_DEV_CHELSIO=m
> CONFIG_CRYPTO_DEV_VIRTIO=m
> CONFIG_CRYPTO_DEV_SAFEXCEL=m
> CONFIG_CRYPTO_DEV_AMLOGIC_GXL=m
> # CONFIG_CRYPTO_DEV_AMLOGIC_GXL_DEBUG is not set
> CONFIG_ASYMMETRIC_KEY_TYPE=y
> CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
> CONFIG_X509_CERTIFICATE_PARSER=y
> CONFIG_PKCS8_PRIVATE_KEY_PARSER=m
> CONFIG_PKCS7_MESSAGE_PARSER=y
> CONFIG_PKCS7_TEST_KEY=m
> CONFIG_SIGNED_PE_FILE_VERIFICATION=y
> # CONFIG_FIPS_SIGNATURE_SELFTEST is not set
>
> #
> # Certificates for signature checking
> #
> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
> CONFIG_MODULE_SIG_KEY_TYPE_RSA=y
> # CONFIG_MODULE_SIG_KEY_TYPE_ECDSA is not set
> CONFIG_SYSTEM_TRUSTED_KEYRING=y
> CONFIG_SYSTEM_TRUSTED_KEYS=""
> CONFIG_SYSTEM_EXTRA_CERTIFICATE=y
> CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE=4096
> CONFIG_SECONDARY_TRUSTED_KEYRING=y
> CONFIG_SYSTEM_BLACKLIST_KEYRING=y
> CONFIG_SYSTEM_BLACKLIST_HASH_LIST=""
> CONFIG_SYSTEM_REVOCATION_LIST=y
> CONFIG_SYSTEM_REVOCATION_KEYS=""
> # CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE is not set
> # end of Certificates for signature checking
>
> CONFIG_BINARY_PRINTF=y
>
> #
> # Library routines
> #
> CONFIG_RAID6_PQ=m
> CONFIG_RAID6_PQ_BENCHMARK=y
> CONFIG_LINEAR_RANGES=y
> CONFIG_PACKING=y
> CONFIG_BITREVERSE=y
> CONFIG_GENERIC_STRNCPY_FROM_USER=y
> CONFIG_GENERIC_STRNLEN_USER=y
> CONFIG_GENERIC_NET_UTILS=y
> CONFIG_CORDIC=m
> # CONFIG_PRIME_NUMBERS is not set
> CONFIG_RATIONAL=y
> CONFIG_GENERIC_PCI_IOMAP=y
> CONFIG_GENERIC_IOMAP=y
> CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
> CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
> CONFIG_ARCH_USE_SYM_ANNOTATIONS=y
>
> #
> # Crypto library routines
> #
> CONFIG_CRYPTO_LIB_AES=y
> CONFIG_CRYPTO_LIB_ARC4=m
> CONFIG_CRYPTO_ARCH_HAVE_LIB_BLAKE2S=y
> CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
> CONFIG_CRYPTO_ARCH_HAVE_LIB_CHACHA=m
> CONFIG_CRYPTO_LIB_CHACHA_GENERIC=m
> CONFIG_CRYPTO_LIB_CHACHA=m
> CONFIG_CRYPTO_ARCH_HAVE_LIB_CURVE25519=m
> CONFIG_CRYPTO_LIB_CURVE25519_GENERIC=m
> CONFIG_CRYPTO_LIB_CURVE25519=m
> CONFIG_CRYPTO_LIB_DES=m
> CONFIG_CRYPTO_LIB_POLY1305_RSIZE=11
> CONFIG_CRYPTO_ARCH_HAVE_LIB_POLY1305=m
> CONFIG_CRYPTO_LIB_POLY1305_GENERIC=m
> CONFIG_CRYPTO_LIB_POLY1305=m
> CONFIG_CRYPTO_LIB_CHACHA20POLY1305=m
> CONFIG_CRYPTO_LIB_SHA1=y
> CONFIG_CRYPTO_LIB_SHA256=y
> # end of Crypto library routines
>
> CONFIG_LIB_MEMNEQ=y
> CONFIG_CRC_CCITT=y
> CONFIG_CRC16=y
> CONFIG_CRC_T10DIF=y
> CONFIG_CRC64_ROCKSOFT=y
> CONFIG_CRC_ITU_T=m
> CONFIG_CRC32=y
> # CONFIG_CRC32_SELFTEST is not set
> CONFIG_CRC32_SLICEBY8=y
> # CONFIG_CRC32_SLICEBY4 is not set
> # CONFIG_CRC32_SARWATE is not set
> # CONFIG_CRC32_BIT is not set
> CONFIG_CRC64=y
> CONFIG_CRC4=m
> CONFIG_CRC7=m
> CONFIG_LIBCRC32C=m
> CONFIG_CRC8=m
> CONFIG_XXHASH=y
> # CONFIG_RANDOM32_SELFTEST is not set
> CONFIG_842_COMPRESS=m
> CONFIG_842_DECOMPRESS=m
> CONFIG_ZLIB_INFLATE=y
> CONFIG_ZLIB_DEFLATE=y
> CONFIG_LZO_COMPRESS=y
> CONFIG_LZO_DECOMPRESS=y
> CONFIG_LZ4_COMPRESS=m
> CONFIG_LZ4HC_COMPRESS=m
> CONFIG_LZ4_DECOMPRESS=y
> CONFIG_ZSTD_COMPRESS=m
> CONFIG_ZSTD_DECOMPRESS=y
> CONFIG_XZ_DEC=y
> CONFIG_XZ_DEC_X86=y
> CONFIG_XZ_DEC_POWERPC=y
> CONFIG_XZ_DEC_IA64=y
> CONFIG_XZ_DEC_ARM=y
> CONFIG_XZ_DEC_ARMTHUMB=y
> CONFIG_XZ_DEC_SPARC=y
> CONFIG_XZ_DEC_MICROLZMA=y
> CONFIG_XZ_DEC_BCJ=y
> CONFIG_XZ_DEC_TEST=m
> CONFIG_DECOMPRESS_GZIP=y
> CONFIG_DECOMPRESS_BZIP2=y
> CONFIG_DECOMPRESS_LZMA=y
> CONFIG_DECOMPRESS_XZ=y
> CONFIG_DECOMPRESS_LZO=y
> CONFIG_DECOMPRESS_LZ4=y
> CONFIG_DECOMPRESS_ZSTD=y
> CONFIG_GENERIC_ALLOCATOR=y
> CONFIG_REED_SOLOMON=m
> CONFIG_REED_SOLOMON_ENC8=y
> CONFIG_REED_SOLOMON_DEC8=y
> CONFIG_REED_SOLOMON_DEC16=y
> CONFIG_BCH=m
> CONFIG_TEXTSEARCH=y
> CONFIG_TEXTSEARCH_KMP=m
> CONFIG_TEXTSEARCH_BM=m
> CONFIG_TEXTSEARCH_FSM=m
> CONFIG_BTREE=y
> CONFIG_INTERVAL_TREE=y
> CONFIG_XARRAY_MULTI=y
> CONFIG_ASSOCIATIVE_ARRAY=y
> CONFIG_HAS_IOMEM=y
> CONFIG_HAS_IOPORT_MAP=y
> CONFIG_HAS_DMA=y
> CONFIG_DMA_OPS=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> CONFIG_ARCH_HAS_FORCE_DMA_UNENCRYPTED=y
> CONFIG_SWIOTLB=y
> CONFIG_DMA_COHERENT_POOL=y
> # CONFIG_DMA_API_DEBUG is not set
> # CONFIG_DMA_MAP_BENCHMARK is not set
> CONFIG_SGL_ALLOC=y
> CONFIG_IOMMU_HELPER=y
> CONFIG_CHECK_SIGNATURE=y
> CONFIG_CPUMASK_OFFSTACK=y
> CONFIG_CPU_RMAP=y
> CONFIG_DQL=y
> CONFIG_GLOB=y
> # CONFIG_GLOB_SELFTEST is not set
> CONFIG_NLATTR=y
> CONFIG_LRU_CACHE=m
> CONFIG_CLZ_TAB=y
> CONFIG_IRQ_POLL=y
> CONFIG_MPILIB=y
> CONFIG_SIGNATURE=y
> CONFIG_DIMLIB=y
> CONFIG_OID_REGISTRY=y
> CONFIG_UCS2_STRING=y
> CONFIG_HAVE_GENERIC_VDSO=y
> CONFIG_GENERIC_GETTIMEOFDAY=y
> CONFIG_GENERIC_VDSO_TIME_NS=y
> CONFIG_FONT_SUPPORT=y
> CONFIG_FONTS=y
> CONFIG_FONT_8x8=y
> CONFIG_FONT_8x16=y
> # CONFIG_FONT_6x11 is not set
> # CONFIG_FONT_7x14 is not set
> # CONFIG_FONT_PEARL_8x8 is not set
> CONFIG_FONT_ACORN_8x8=y
> # CONFIG_FONT_MINI_4x6 is not set
> CONFIG_FONT_6x10=y
> # CONFIG_FONT_10x18 is not set
> # CONFIG_FONT_SUN8x16 is not set
> # CONFIG_FONT_SUN12x22 is not set
> CONFIG_FONT_TER16x32=y
> # CONFIG_FONT_6x8 is not set
> CONFIG_SG_POOL=y
> CONFIG_ARCH_HAS_PMEM_API=y
> CONFIG_MEMREGION=y
> CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
> CONFIG_ARCH_HAS_COPY_MC=y
> CONFIG_ARCH_STACKWALK=y
> CONFIG_STACKDEPOT=y
> CONFIG_STACKDEPOT_ALWAYS_INIT=y
> CONFIG_SBITMAP=y
> CONFIG_PARMAN=m
> CONFIG_OBJAGG=m
> # end of Library routines
>
> CONFIG_PLDMFW=y
> CONFIG_ASN1_ENCODER=y
> CONFIG_POLYNOMIAL=m
>
> #
> # Kernel hacking
> #
>
> #
> # printk and dmesg options
> #
> CONFIG_PRINTK_TIME=y
> # CONFIG_PRINTK_CALLER is not set
> # CONFIG_STACKTRACE_BUILD_ID is not set
> CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
> CONFIG_CONSOLE_LOGLEVEL_QUIET=4
> CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
> CONFIG_BOOT_PRINTK_DELAY=y
> CONFIG_DYNAMIC_DEBUG=y
> CONFIG_DYNAMIC_DEBUG_CORE=y
> CONFIG_SYMBOLIC_ERRNAME=y
> CONFIG_DEBUG_BUGVERBOSE=y
> # end of printk and dmesg options
>
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_MISC=y
>
> #
> # Compile-time checks and compiler options
> #
> CONFIG_DEBUG_INFO=y
> # CONFIG_DEBUG_INFO_NONE is not set
> # CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT is not set
> # CONFIG_DEBUG_INFO_DWARF4 is not set
> CONFIG_DEBUG_INFO_DWARF5=y
> # CONFIG_DEBUG_INFO_REDUCED is not set
> # CONFIG_DEBUG_INFO_COMPRESSED is not set
> # CONFIG_DEBUG_INFO_SPLIT is not set
> CONFIG_DEBUG_INFO_BTF=y
> CONFIG_PAHOLE_HAS_SPLIT_BTF=y
> CONFIG_DEBUG_INFO_BTF_MODULES=y
> # CONFIG_MODULE_ALLOW_BTF_MISMATCH is not set
> CONFIG_GDB_SCRIPTS=y
> CONFIG_FRAME_WARN=1024
> # CONFIG_STRIP_ASM_SYMS is not set
> # CONFIG_READABLE_ASM is not set
> # CONFIG_HEADERS_INSTALL is not set
> # CONFIG_DEBUG_SECTION_MISMATCH is not set
> CONFIG_SECTION_MISMATCH_WARN_ONLY=y
> # CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B is not set
> CONFIG_FRAME_POINTER=y
> CONFIG_OBJTOOL=y
> CONFIG_STACK_VALIDATION=y
> CONFIG_VMLINUX_MAP=y
> # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
> # end of Compile-time checks and compiler options
>
> #
> # Generic Kernel Debugging Instruments
> #
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6
> CONFIG_MAGIC_SYSRQ_SERIAL=y
> CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE=""
> CONFIG_DEBUG_FS=y
> CONFIG_DEBUG_FS_ALLOW_ALL=y
> # CONFIG_DEBUG_FS_DISALLOW_MOUNT is not set
> # CONFIG_DEBUG_FS_ALLOW_NONE is not set
> CONFIG_HAVE_ARCH_KGDB=y
> CONFIG_KGDB=y
> CONFIG_KGDB_HONOUR_BLOCKLIST=y
> CONFIG_KGDB_SERIAL_CONSOLE=y
> # CONFIG_KGDB_TESTS is not set
> CONFIG_KGDB_LOW_LEVEL_TRAP=y
> CONFIG_KGDB_KDB=y
> CONFIG_KDB_DEFAULT_ENABLE=0x1
> CONFIG_KDB_KEYBOARD=y
> CONFIG_KDB_CONTINUE_CATASTROPHIC=0
> CONFIG_ARCH_HAS_EARLY_DEBUG=y
> CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
> CONFIG_UBSAN=y
> # CONFIG_UBSAN_TRAP is not set
> CONFIG_CC_HAS_UBSAN_BOUNDS=y
> CONFIG_UBSAN_BOUNDS=y
> CONFIG_UBSAN_ONLY_BOUNDS=y
> CONFIG_UBSAN_SHIFT=y
> # CONFIG_UBSAN_DIV_ZERO is not set
> CONFIG_UBSAN_BOOL=y
> CONFIG_UBSAN_ENUM=y
> # CONFIG_UBSAN_ALIGNMENT is not set
> CONFIG_UBSAN_SANITIZE_ALL=y
> # CONFIG_TEST_UBSAN is not set
> CONFIG_HAVE_ARCH_KCSAN=y
> CONFIG_HAVE_KCSAN_COMPILER=y
> # end of Generic Kernel Debugging Instruments
>
> #
> # Networking Debugging
> #
> # CONFIG_NET_DEV_REFCNT_TRACKER is not set
> # CONFIG_NET_NS_REFCNT_TRACKER is not set
> # CONFIG_DEBUG_NET is not set
> # end of Networking Debugging
>
> #
> # Memory Debugging
> #
> # CONFIG_PAGE_EXTENSION is not set
> # CONFIG_DEBUG_PAGEALLOC is not set
> CONFIG_SLUB_DEBUG=y
> # CONFIG_SLUB_DEBUG_ON is not set
> # CONFIG_PAGE_OWNER is not set
> # CONFIG_PAGE_TABLE_CHECK is not set
> CONFIG_PAGE_POISONING=y
> # CONFIG_DEBUG_PAGE_REF is not set
> # CONFIG_DEBUG_RODATA_TEST is not set
> CONFIG_ARCH_HAS_DEBUG_WX=y
> CONFIG_DEBUG_WX=y
> CONFIG_GENERIC_PTDUMP=y
> CONFIG_PTDUMP_CORE=y
> # CONFIG_PTDUMP_DEBUGFS is not set
> # CONFIG_DEBUG_OBJECTS is not set
> # CONFIG_SHRINKER_DEBUG is not set
> CONFIG_HAVE_DEBUG_KMEMLEAK=y
> CONFIG_DEBUG_KMEMLEAK=y
> CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=16000
> # CONFIG_DEBUG_KMEMLEAK_TEST is not set
> # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
> CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y
> # CONFIG_DEBUG_STACK_USAGE is not set
> CONFIG_SCHED_STACK_END_CHECK=y
> CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE=y
> # CONFIG_DEBUG_VM is not set
> # CONFIG_DEBUG_VM_PGTABLE is not set
> CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
> # CONFIG_DEBUG_VIRTUAL is not set
> # CONFIG_DEBUG_MEMORY_INIT is not set
> CONFIG_MEMORY_NOTIFIER_ERROR_INJECT=m
> # CONFIG_DEBUG_PER_CPU_MAPS is not set
> CONFIG_HAVE_ARCH_KASAN=y
> CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
> CONFIG_CC_HAS_KASAN_GENERIC=y
> CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=y
> CONFIG_KASAN=y
> CONFIG_KASAN_GENERIC=y
> CONFIG_KASAN_OUTLINE=y
> # CONFIG_KASAN_INLINE is not set
> CONFIG_KASAN_STACK=y
> # CONFIG_KASAN_VMALLOC is not set
> # CONFIG_KASAN_MODULE_TEST is not set
> CONFIG_HAVE_ARCH_KFENCE=y
> CONFIG_KFENCE=y
> CONFIG_KFENCE_SAMPLE_INTERVAL=0
> CONFIG_KFENCE_NUM_OBJECTS=255
> # CONFIG_KFENCE_DEFERRABLE is not set
> # CONFIG_KFENCE_STATIC_KEYS is not set
> CONFIG_KFENCE_STRESS_TEST_FAULTS=0
> # end of Memory Debugging
>
> # CONFIG_DEBUG_SHIRQ is not set
>
> #
> # Debug Oops, Lockups and Hangs
> #
> # CONFIG_PANIC_ON_OOPS is not set
> CONFIG_PANIC_ON_OOPS_VALUE=0
> CONFIG_PANIC_TIMEOUT=0
> CONFIG_LOCKUP_DETECTOR=y
> CONFIG_SOFTLOCKUP_DETECTOR=y
> # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
> CONFIG_HARDLOCKUP_DETECTOR_PERF=y
> CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y
> CONFIG_HARDLOCKUP_DETECTOR=y
> # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
> CONFIG_DETECT_HUNG_TASK=y
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
> # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
> # CONFIG_WQ_WATCHDOG is not set
> # CONFIG_TEST_LOCKUP is not set
> # end of Debug Oops, Lockups and Hangs
>
> #
> # Scheduler Debugging
> #
> CONFIG_SCHED_DEBUG=y
> CONFIG_SCHED_INFO=y
> CONFIG_SCHEDSTATS=y
> # end of Scheduler Debugging
>
> # CONFIG_DEBUG_TIMEKEEPING is not set
> # CONFIG_DEBUG_PREEMPT is not set
>
> #
> # Lock Debugging (spinlocks, mutexes, etc...)
> #
> CONFIG_LOCK_DEBUGGING_SUPPORT=y
> # CONFIG_PROVE_LOCKING is not set
> # CONFIG_LOCK_STAT is not set
> # CONFIG_DEBUG_RT_MUTEXES is not set
> # CONFIG_DEBUG_SPINLOCK is not set
> # CONFIG_DEBUG_MUTEXES is not set
> # CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
> # CONFIG_DEBUG_RWSEMS is not set
> # CONFIG_DEBUG_LOCK_ALLOC is not set
> # CONFIG_DEBUG_ATOMIC_SLEEP is not set
> # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
> # CONFIG_LOCK_TORTURE_TEST is not set
> # CONFIG_WW_MUTEX_SELFTEST is not set
> # CONFIG_SCF_TORTURE_TEST is not set
> # CONFIG_CSD_LOCK_WAIT_DEBUG is not set
> # end of Lock Debugging (spinlocks, mutexes, etc...)
>
> # CONFIG_DEBUG_IRQFLAGS is not set
> CONFIG_STACKTRACE=y
> # CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set
> # CONFIG_DEBUG_KOBJECT is not set
>
> #
> # Debug kernel data structures
> #
> # CONFIG_DEBUG_LIST is not set
> # CONFIG_DEBUG_PLIST is not set
> # CONFIG_DEBUG_SG is not set
> # CONFIG_DEBUG_NOTIFIERS is not set
> # CONFIG_BUG_ON_DATA_CORRUPTION is not set
> # end of Debug kernel data structures
>
> # CONFIG_DEBUG_CREDENTIALS is not set
>
> #
> # RCU Debugging
> #
> # CONFIG_RCU_SCALE_TEST is not set
> # CONFIG_RCU_TORTURE_TEST is not set
> # CONFIG_RCU_REF_SCALE_TEST is not set
> CONFIG_RCU_CPU_STALL_TIMEOUT=60
> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=20
> # CONFIG_RCU_TRACE is not set
> # CONFIG_RCU_EQS_DEBUG is not set
> # end of RCU Debugging
>
> # CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
> # CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set
> # CONFIG_LATENCYTOP is not set
> CONFIG_USER_STACKTRACE_SUPPORT=y
> CONFIG_NOP_TRACER=y
> CONFIG_HAVE_RETHOOK=y
> CONFIG_RETHOOK=y
> CONFIG_HAVE_FUNCTION_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
> CONFIG_HAVE_DYNAMIC_FTRACE=y
> CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
> CONFIG_HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS=y
> CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS=y
> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
> CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> CONFIG_HAVE_FENTRY=y
> CONFIG_HAVE_OBJTOOL_MCOUNT=y
> CONFIG_HAVE_C_RECORDMCOUNT=y
> CONFIG_HAVE_BUILDTIME_MCOUNT_SORT=y
> CONFIG_BUILDTIME_MCOUNT_SORT=y
> CONFIG_TRACER_MAX_TRACE=y
> CONFIG_TRACE_CLOCK=y
> CONFIG_RING_BUFFER=y
> CONFIG_EVENT_TRACING=y
> CONFIG_CONTEXT_SWITCH_TRACER=y
> CONFIG_TRACING=y
> CONFIG_GENERIC_TRACER=y
> CONFIG_TRACING_SUPPORT=y
> CONFIG_FTRACE=y
> CONFIG_BOOTTIME_TRACING=y
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRAPH_TRACER=y
> CONFIG_DYNAMIC_FTRACE=y
> CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
> CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS=y
> CONFIG_DYNAMIC_FTRACE_WITH_ARGS=y
> CONFIG_FPROBE=y
> CONFIG_FUNCTION_PROFILER=y
> CONFIG_STACK_TRACER=y
> # CONFIG_IRQSOFF_TRACER is not set
> # CONFIG_PREEMPT_TRACER is not set
> CONFIG_SCHED_TRACER=y
> CONFIG_HWLAT_TRACER=y
> # CONFIG_OSNOISE_TRACER is not set
> # CONFIG_TIMERLAT_TRACER is not set
> CONFIG_MMIOTRACE=y
> CONFIG_FTRACE_SYSCALLS=y
> CONFIG_TRACER_SNAPSHOT=y
> # CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
> CONFIG_BRANCH_PROFILE_NONE=y
> # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
> CONFIG_BLK_DEV_IO_TRACE=y
> CONFIG_KPROBE_EVENTS=y
> # CONFIG_KPROBE_EVENTS_ON_NOTRACE is not set
> CONFIG_UPROBE_EVENTS=y
> CONFIG_BPF_EVENTS=y
> CONFIG_DYNAMIC_EVENTS=y
> CONFIG_PROBE_EVENTS=y
> CONFIG_BPF_KPROBE_OVERRIDE=y
> CONFIG_FTRACE_MCOUNT_RECORD=y
> CONFIG_FTRACE_MCOUNT_USE_CC=y
> CONFIG_TRACING_MAP=y
> CONFIG_SYNTH_EVENTS=y
> CONFIG_HIST_TRIGGERS=y
> CONFIG_TRACE_EVENT_INJECT=y
> # CONFIG_TRACEPOINT_BENCHMARK is not set
> # CONFIG_RING_BUFFER_BENCHMARK is not set
> # CONFIG_TRACE_EVAL_MAP_FILE is not set
> # CONFIG_FTRACE_RECORD_RECURSION is not set
> # CONFIG_FTRACE_STARTUP_TEST is not set
> # CONFIG_FTRACE_SORT_STARTUP_TEST is not set
> # CONFIG_RING_BUFFER_STARTUP_TEST is not set
> # CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS is not set
> # CONFIG_MMIOTRACE_TEST is not set
> # CONFIG_PREEMPTIRQ_DELAY_TEST is not set
> # CONFIG_SYNTH_EVENT_GEN_TEST is not set
> # CONFIG_KPROBE_EVENT_GEN_TEST is not set
> # CONFIG_HIST_TRIGGERS_DEBUG is not set
> CONFIG_DA_MON_EVENTS=y
> CONFIG_DA_MON_EVENTS_ID=y
> CONFIG_RV=y
> CONFIG_RV_MON_WWNR=y
> CONFIG_RV_REACTORS=y
> CONFIG_RV_REACT_PRINTK=y
> CONFIG_RV_REACT_PANIC=y
> # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
> CONFIG_SAMPLES=y
> # CONFIG_SAMPLE_AUXDISPLAY is not set
> # CONFIG_SAMPLE_TRACE_EVENTS is not set
> # CONFIG_SAMPLE_TRACE_CUSTOM_EVENTS is not set
> CONFIG_SAMPLE_TRACE_PRINTK=m
> CONFIG_SAMPLE_FTRACE_DIRECT=m
> # CONFIG_SAMPLE_FTRACE_DIRECT_MULTI is not set
> CONFIG_SAMPLE_TRACE_ARRAY=m
> # CONFIG_SAMPLE_KOBJECT is not set
> # CONFIG_SAMPLE_KPROBES is not set
> # CONFIG_SAMPLE_HW_BREAKPOINT is not set
> # CONFIG_SAMPLE_FPROBE is not set
> # CONFIG_SAMPLE_KFIFO is not set
> # CONFIG_SAMPLE_KDB is not set
> # CONFIG_SAMPLE_RPMSG_CLIENT is not set
> # CONFIG_SAMPLE_LIVEPATCH is not set
> # CONFIG_SAMPLE_CONFIGFS is not set
> # CONFIG_SAMPLE_VFIO_MDEV_MTTY is not set
> # CONFIG_SAMPLE_VFIO_MDEV_MDPY is not set
> # CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB is not set
> # CONFIG_SAMPLE_VFIO_MDEV_MBOCHS is not set
> # CONFIG_SAMPLE_WATCHDOG is not set
> CONFIG_HAVE_SAMPLE_FTRACE_DIRECT=y
> CONFIG_HAVE_SAMPLE_FTRACE_DIRECT_MULTI=y
> CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
> CONFIG_STRICT_DEVMEM=y
> # CONFIG_IO_STRICT_DEVMEM is not set
>
> #
> # x86 Debugging
> #
> CONFIG_EARLY_PRINTK_USB=y
> # CONFIG_X86_VERBOSE_BOOTUP is not set
> CONFIG_EARLY_PRINTK=y
> CONFIG_EARLY_PRINTK_DBGP=y
> CONFIG_EARLY_PRINTK_USB_XDBC=y
> # CONFIG_EFI_PGT_DUMP is not set
> # CONFIG_DEBUG_TLBFLUSH is not set
> # CONFIG_IOMMU_DEBUG is not set
> CONFIG_HAVE_MMIOTRACE_SUPPORT=y
> # CONFIG_X86_DECODER_SELFTEST is not set
> # CONFIG_IO_DELAY_0X80 is not set
> CONFIG_IO_DELAY_0XED=y
> # CONFIG_IO_DELAY_UDELAY is not set
> # CONFIG_IO_DELAY_NONE is not set
> # CONFIG_DEBUG_BOOT_PARAMS is not set
> # CONFIG_CPA_DEBUG is not set
> # CONFIG_DEBUG_ENTRY is not set
> # CONFIG_DEBUG_NMI_SELFTEST is not set
> CONFIG_X86_DEBUG_FPU=y
> CONFIG_PUNIT_ATOM_DEBUG=m
> # CONFIG_UNWINDER_ORC is not set
> CONFIG_UNWINDER_FRAME_POINTER=y
> # end of x86 Debugging
>
> #
> # Kernel Testing and Coverage
> #
> # CONFIG_KUNIT is not set
> CONFIG_NOTIFIER_ERROR_INJECTION=m
> CONFIG_PM_NOTIFIER_ERROR_INJECT=m
> # CONFIG_NETDEV_NOTIFIER_ERROR_INJECT is not set
> CONFIG_FUNCTION_ERROR_INJECTION=y
> # CONFIG_FAULT_INJECTION is not set
> CONFIG_ARCH_HAS_KCOV=y
> CONFIG_CC_HAS_SANCOV_TRACE_PC=y
> # CONFIG_KCOV is not set
> CONFIG_RUNTIME_TESTING_MENU=y
> # CONFIG_LKDTM is not set
> # CONFIG_TEST_MIN_HEAP is not set
> # CONFIG_TEST_DIV64 is not set
> # CONFIG_BACKTRACE_SELF_TEST is not set
> # CONFIG_TEST_REF_TRACKER is not set
> # CONFIG_RBTREE_TEST is not set
> # CONFIG_REED_SOLOMON_TEST is not set
> # CONFIG_INTERVAL_TREE_TEST is not set
> # CONFIG_PERCPU_TEST is not set
> # CONFIG_ATOMIC64_SELFTEST is not set
> # CONFIG_ASYNC_RAID6_TEST is not set
> # CONFIG_TEST_HEXDUMP is not set
> # CONFIG_STRING_SELFTEST is not set
> # CONFIG_TEST_STRING_HELPERS is not set
> # CONFIG_TEST_STRSCPY is not set
> # CONFIG_TEST_KSTRTOX is not set
> # CONFIG_TEST_PRINTF is not set
> # CONFIG_TEST_SCANF is not set
> # CONFIG_TEST_BITMAP is not set
> # CONFIG_TEST_UUID is not set
> # CONFIG_TEST_XARRAY is not set
> # CONFIG_TEST_RHASHTABLE is not set
> # CONFIG_TEST_SIPHASH is not set
> # CONFIG_TEST_IDA is not set
> # CONFIG_TEST_PARMAN is not set
> # CONFIG_TEST_LKM is not set
> # CONFIG_TEST_BITOPS is not set
> # CONFIG_TEST_VMALLOC is not set
> # CONFIG_TEST_USER_COPY is not set
> CONFIG_TEST_BPF=m
> CONFIG_TEST_BLACKHOLE_DEV=m
> # CONFIG_FIND_BIT_BENCHMARK is not set
> # CONFIG_TEST_FIRMWARE is not set
> # CONFIG_TEST_SYSCTL is not set
> # CONFIG_TEST_UDELAY is not set
> # CONFIG_TEST_STATIC_KEYS is not set
> # CONFIG_TEST_KMOD is not set
> # CONFIG_TEST_MEMCAT_P is not set
> # CONFIG_TEST_LIVEPATCH is not set
> # CONFIG_TEST_OBJAGG is not set
> # CONFIG_TEST_MEMINIT is not set
> # CONFIG_TEST_HMM is not set
> # CONFIG_TEST_FREE_PAGES is not set
> # CONFIG_TEST_FPU is not set
> # CONFIG_TEST_CLOCKSOURCE_WATCHDOG is not set
> CONFIG_ARCH_USE_MEMTEST=y
> CONFIG_MEMTEST=y
> # CONFIG_HYPERV_TESTING is not set
> # end of Kernel Testing and Coverage
> # end of Kernel hacking
>
-- 
Mirsad Goran Todorovac
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
-- 
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355


^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-09-30 10:48 82% ` BUG: " Mirsad Todorovac
@ 2022-09-30 11:21 82%   ` Slade Watkins
  2022-09-30 11:44 82%     ` Mirsad Todorovac
  2022-10-06 10:39 82%   ` Marc Miltenberger
  1 sibling, 1 reply; 200+ results
From: Slade Watkins @ 2022-09-30 11:21 UTC (permalink / raw)
  To: Mirsad Todorovac; +Cc: LKML

Hi,

> On Sep 30, 2022, at 6:48 AM, Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> wrote:
> 
> Hi all,
> 
> I can confirm this bug also on AlmaLinux (CentOS fork) with snapd version 105.0.1 of
> Firefox.
> 
> After some time, tabs started crashing, but restarting Firefox binary was after that
> unsuccessful, giving the message:
> 
> [marvin@pc-mtodorov ~]$ /snap/bin/firefox &
> [1] 137734
> [marvin@pc-mtodorov ~]$ /bin/bash: /lib/x86_64-linux-gnu/libdl.so.2: unsupported version 0 of Verdef record
> /bin/bash: error while loading shared libraries: /lib/x86_64-linux-gnu/libdl.so.2: unsupported version 0 of Verneed record
> 
> [1]+  Exit 127                /snap/bin/firefox
> [marvin@pc-mtodorov ~]$

Did you report this to the folks at Mozilla?

Best,

-srw


^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-09-30 11:21 82%   ` Slade Watkins
@ 2022-09-30 11:44 82%     ` Mirsad Todorovac
  2022-09-30 12:03 82%       ` Slade Watkins
  0 siblings, 1 reply; 200+ results
From: Mirsad Todorovac @ 2022-09-30 11:44 UTC (permalink / raw)
  To: Slade Watkins, Mirsad Todorovac; +Cc: LKML

On 9/30/2022 1:21 PM, Slade Watkins wrote:
> Hi,
>
>> On Sep 30, 2022, at 6:48 AM, Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> wrote:
>>
>> Hi all,
>>
>> I can confirm this bug also on AlmaLinux (CentOS fork) with snapd version 105.0.1 of
>> Firefox.
>>
>> After some time, tabs started crashing, but restarting Firefox binary was after that
>> unsuccessful, giving the message:
>>
>> [marvin@pc-mtodorov ~]$ /snap/bin/firefox &
>> [1] 137734
>> [marvin@pc-mtodorov ~]$ /bin/bash: /lib/x86_64-linux-gnu/libdl.so.2: unsupported version 0 of Verdef record
>> /bin/bash: error while loading shared libraries: /lib/x86_64-linux-gnu/libdl.so.2: unsupported version 0 of Verneed record
>>
>> [1]+  Exit 127                /snap/bin/firefox
>> [marvin@pc-mtodorov ~]$
> Did you report this to the folks at Mozilla?
>
> Best,
>
> -srw

Hi Slade,

Thank you for your message.

No, I did not think that it was a problem with Firefox snap build 104.x 
or 105.0.1, because with the
older 5.19.x line of kernels it works perfectly, without any crashed 
tabs or refusing to start.

After a reboot of OS, Firefox works again, but only for a stochastic, 
undetermined amount of time.
Once it gets "Tabs crashed" errors, it is impossible to restart until 
the next reboot.

The non-snap Firefox 91.x esr so far did not exhibit this problem, but 
the testing results are insufficient.

Kind regards,
mt

-- 
Mirsad Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
--
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355


^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-09-30 11:44 82%     ` Mirsad Todorovac
@ 2022-09-30 12:03 82%       ` Slade Watkins
  2022-09-30 18:27 82%         ` Slade Watkins
  0 siblings, 1 reply; 200+ results
From: Slade Watkins @ 2022-09-30 12:03 UTC (permalink / raw)
  To: Mirsad Todorovac; +Cc: Mirsad Todorovac, LKML

Hey Mirsad,

> On Sep 30, 2022, at 7:44 AM, Mirsad Todorovac <mirsad.todorovac@alu.hr> wrote:
> 
> No, I did not think that it was a problem with Firefox snap build 104.x or 105.0.1, because with the
> older 5.19.x line of kernels it works perfectly, without any crashed tabs or refusing to start.
> 
> After a reboot of OS, Firefox works again, but only for a stochastic, undetermined amount of time.
> Once it gets "Tabs crashed" errors, it is impossible to restart until the next reboot.
> 
> The non-snap Firefox 91.x esr so far did not exhibit this problem, but the testing results are insufficient.

Huh, okay, I’ll see if I can try to reproduce it again. 

I wasn’t having issues with kernel 6.0-rc7 but I’ll try a fresh install and see what that changes.

Cheers,
-srw


^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-09-30 12:03 82%       ` Slade Watkins
@ 2022-09-30 18:27 82%         ` Slade Watkins
  2022-10-03  8:18 82%           ` Mirsad Goran Todorovac
  0 siblings, 1 reply; 200+ results
From: Slade Watkins @ 2022-09-30 18:27 UTC (permalink / raw)
  To: Mirsad Todorovac; +Cc: Mirsad Todorovac, LKML

Hey there:
> On Sep 30, 2022, at 8:03 AM, Slade Watkins <srw@sladewatkins.net> wrote:
> 
> Huh, okay, I’ll see if I can try to reproduce it again. 
> 
> I wasn’t having issues with kernel 6.0-rc7 but I’ll try a fresh install and see what that changes.

I tried again twice (for “good measure,” so to speak.)
Once with my x86_64 test machine (fresh install of my distribution and 6.0-rc7 kernel, Firefox snap 104.x/105.0.1), and with your setup (AlmaLinux, 6.0-rc7, same versions of Firefox snaps previously mentioned) as described in a previous email [1] and couldn’t reproduce.

Not sure what’s happening here, or what’s to blame (the kernel, snapd, etc.), to be completely honest with you. But obviously, there’s an issue on your system with the snaps. So in that case, I do think somebody else with more insight into what could possibly affect this — or even Mozilla (specifically, the maintainers of their snap package) — may be more helpful.

But please feel free to keep me in the loop! Even though I’m not able to reproduce, I’d still like to help wherever possible.

[1] https://lore.kernel.org/lkml/1266113f-75a1-b276-bb8c-3cdfcbabf043@alu.unizg.hr/
[2] https://lore.kernel.org/lkml/77bc5046-7b69-6100-f991-60b4d53994ee@alu.hr/

Best,
-srw


^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-09-30 18:27 82%         ` Slade Watkins
@ 2022-10-03  8:18 82%           ` Mirsad Goran Todorovac
  2022-10-07  8:47 82%             ` Slade Watkins
  0 siblings, 1 reply; 200+ results
From: Mirsad Goran Todorovac @ 2022-10-03  8:18 UTC (permalink / raw)
  To: Slade Watkins; +Cc: LKML

On 30.9.2022. 20:27, Slade Watkins wrote:

> Hey there:
>> On Sep 30, 2022, at 8:03 AM, Slade Watkins <srw@sladewatkins.net> wrote:
>>
>> Huh, okay, I’ll see if I can try to reproduce it again.
>>
>> I wasn’t having issues with kernel 6.0-rc7 but I’ll try a fresh install and see what that changes.
> I tried again twice (for “good measure,” so to speak.)
> Once with my x86_64 test machine (fresh install of my distribution and 6.0-rc7 kernel, Firefox snap 104.x/105.0.1), and with your setup (AlmaLinux, 6.0-rc7, same versions of Firefox snaps previously mentioned) as described in a previous email [1] and couldn’t reproduce.
>
> Not sure what’s happening here, or what’s to blame (the kernel, snapd, etc.), to be completely honest with you. But obviously, there’s an issue on your system with the snaps. So in that case, I do think somebody else with more insight into what could possibly affect this — or even Mozilla (specifically, the maintainers of their snap package) — may be more helpful.
>
> But please feel free to keep me in the loop! Even though I’m not able to reproduce, I’d still like to help wherever possible.
>
> [1] https://lore.kernel.org/lkml/1266113f-75a1-b276-bb8c-3cdfcbabf043@alu.unizg.hr/
> [2] https://lore.kernel.org/lkml/77bc5046-7b69-6100-f991-60b4d53994ee@alu.hr/
>
> Best,
> -srw

Hi, Slate,

I'm sorry you couldn't reproduce the bug. I will try to provide the list of the installed pkgs the
next time, for both configs.

I will try the linux-6.0.y build on Ubuntu 22.04 "focal" and Almalinux 8.6.

Hopefully there will be a result later today.

I couldn't find an option to build both deb-pkg and rpm-pkg, so the Makefile is needlessly compiling
the source twice :-(

Kind regards,
mt

-- 
Mirsad Todorovac
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
--
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu


^ permalink raw reply	[relevance 82%]

* [Bug 215941] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image
  @ 2022-10-04  9:14 82% ` bugzilla-daemon
  2022-10-04 19:48 82% ` bugzilla-daemon
  1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-10-04  9:14 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=215941

Luis Henriques (lhenriques@suse.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lhenriques@suse.de

--- Comment #1 from Luis Henriques (lhenriques@suse.de) ---
I think that, with commit 29a5b8a137ac ("ext4: fix bug in extents parsing when
eh_entries == 0 and eh_depth > 0") merged, this bug can be closed.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216283] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_insert_extent() when mount and operate on crafted image
                     ` (2 preceding siblings ...)
  2022-10-04 19:42 82% ` bugzilla-daemon
@ 2022-10-04  9:15 82% ` bugzilla-daemon
    4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-10-04  9:15 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216283

Luis Henriques (lhenriques@suse.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lhenriques@suse.de

--- Comment #11 from Luis Henriques (lhenriques@suse.de) ---
I think that, with commit 29a5b8a137ac ("ext4: fix bug in extents parsing when
eh_entries == 0 and eh_depth > 0") merged, this bug can be closed.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216283] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_insert_extent() when mount and operate on crafted image
    2022-08-01 22:45 82% ` [Bug 216283] " bugzilla-daemon
  2022-08-02  9:28 82% ` bugzilla-daemon
@ 2022-10-04 19:42 82% ` bugzilla-daemon
  2022-10-04  9:15 82% ` bugzilla-daemon
    4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-10-04 19:42 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216283

Theodore Tso (tytso@mit.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |tytso@mit.edu
         Resolution|---                         |CODE_FIX

--- Comment #12 from Theodore Tso (tytso@mit.edu) ---
Yep, thanks for the patch!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 215941] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image
    2022-10-04  9:14 82% ` [Bug 215941] " bugzilla-daemon
@ 2022-10-04 19:48 82% ` bugzilla-daemon
  1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-10-04 19:48 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=215941

Theodore Tso (tytso@mit.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |tytso@mit.edu
         Resolution|---                         |CODE_FIX

--- Comment #2 from Theodore Tso (tytso@mit.edu) ---
Indeed, thanks for the patch!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug report] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
  @ 2022-10-05 11:13 82%         ` Michael Ellerman
  0 siblings, 0 replies; 200+ results
From: Michael Ellerman @ 2022-10-05 11:13 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: Zorro Lang, linux-mm, linux-ext4, linuxppc-dev

Matthew Wilcox <willy@infradead.org> writes:
> On Fri, Sep 30, 2022 at 12:01:26PM +1000, Michael Ellerman wrote:
>> Matthew Wilcox <willy@infradead.org> writes:
>> >> [ 4681.238745] Instruction dump: 
>> >> [ 4681.238749] fbc1fff0 f821ffc1 7c7d1b78 7c9c2378 ebc30028 7fdff378 48000018 60000000  
>> >> [ 4681.238765] 60000000 ebff0008 7c3ef840 41820048 <815f0060> e93f0000 5529077c 7d295378  
>> >
>> > Running that through scripts/decodecode (with some minor hacks .. how
>> > do PPC people do this properly?)
>> 
>> We've just always used our own scripts. Mine is here: https://github.com/mpe/misc-scripts/blob/master/ppc/ppc-disasm
>> 
>> I've added an issue to our tracker for us to get scripts/decodecode
>> working on our oopses (eventually).
>
> Would you be open to changing your oops printer to do
> s/Instruction dump/Code/ ?  That would make it work without any other
> changes.

Yeah, we're the only arch that uses "Instruction dump".
For userspace instructions we already print "code".

I'll send a patch switching to "Code:".

cheers


^ permalink raw reply	[relevance 82%]

* Re: [Bug report] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
@ 2022-10-05 11:13 82%         ` Michael Ellerman
  0 siblings, 0 replies; 200+ results
From: Michael Ellerman @ 2022-10-05 11:13 UTC (permalink / raw)
  To: Matthew Wilcox; +Cc: linux-mm, linux-ext4, linuxppc-dev, Zorro Lang

Matthew Wilcox <willy@infradead.org> writes:
> On Fri, Sep 30, 2022 at 12:01:26PM +1000, Michael Ellerman wrote:
>> Matthew Wilcox <willy@infradead.org> writes:
>> >> [ 4681.238745] Instruction dump: 
>> >> [ 4681.238749] fbc1fff0 f821ffc1 7c7d1b78 7c9c2378 ebc30028 7fdff378 48000018 60000000  
>> >> [ 4681.238765] 60000000 ebff0008 7c3ef840 41820048 <815f0060> e93f0000 5529077c 7d295378  
>> >
>> > Running that through scripts/decodecode (with some minor hacks .. how
>> > do PPC people do this properly?)
>> 
>> We've just always used our own scripts. Mine is here: https://github.com/mpe/misc-scripts/blob/master/ppc/ppc-disasm
>> 
>> I've added an issue to our tracker for us to get scripts/decodecode
>> working on our oopses (eventually).
>
> Would you be open to changing your oops printer to do
> s/Instruction dump/Code/ ?  That would make it work without any other
> changes.

Yeah, we're the only arch that uses "Instruction dump".
For userspace instructions we already print "code".

I'll send a patch switching to "Code:".

cheers

^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-09-30 10:48 82% ` BUG: " Mirsad Todorovac
  2022-09-30 11:21 82%   ` Slade Watkins
@ 2022-10-06 10:39 82%   ` Marc Miltenberger
  2022-10-06 16:27 82%     ` Slade Watkins
  1 sibling, 1 reply; 200+ results
From: Marc Miltenberger @ 2022-10-06 10:39 UTC (permalink / raw)
  To: linux-kernel

Hi there,

I have probably the same problem on Ubuntu kinetic kudu using 
6.0.0-060000rc7daily20221002-generic obtained from 
https://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2022-10-02/amd64/

Firefox tabs crash randomly and chromium does not start with the message
/bin/bash: /lib/x86_64-linux-gnu/libdl.so.2: unsupported version 0 of 
Verdef record
/bin/bash: error while loading shared libraries: 
/lib/x86_64-linux-gnu/libdl.so.2: unsupported version 0 of Verneed record

Chrome (without snap) works fine though.

On my machine, these issues also arose after installing 6.0.0; the 
previous version I used (5.19.5) worked fine. In fact, I've reverted to 
the older version without changing anything else and both firefox and 
chromium are happily working again.

Best regards,
Marc

^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-10-06 10:39 82%   ` Marc Miltenberger
@ 2022-10-06 16:27 82%     ` Slade Watkins
  0 siblings, 0 replies; 200+ results
From: Slade Watkins @ 2022-10-06 16:27 UTC (permalink / raw)
  To: Marc Miltenberger; +Cc: linux-kernel

Hey Marc,

On Thu, Oct 6, 2022 at 6:39 AM Marc Miltenberger
<marcmiltenberger@gmail.com> wrote:
>
> Hi there,
>
> I have probably the same problem on Ubuntu kinetic kudu using
> 6.0.0-060000rc7daily20221002-generic obtained from
> https://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2022-10-02/amd64/

For you specifically, this is more of a thing for Canonical/Ubuntu to
look at. They do their own customizations to their kernel (hence the
extra stuff after the dash) and thus, folks on this list can't do much
for it.

If you were using a compiled kernel from the repository at
git.kernel.org, that'd be different.

Best,
-srw

^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-10-03  8:18 82%           ` Mirsad Goran Todorovac
@ 2022-10-07  8:47 82%             ` Slade Watkins
  2022-10-07 10:55 82%               ` Mirsad Goran Todorovac
  0 siblings, 1 reply; 200+ results
From: Slade Watkins @ 2022-10-07  8:47 UTC (permalink / raw)
  To: Mirsad Goran Todorovac; +Cc: LKML, regressions, regressions

Hey Mirsad,

On 10/3/22 at 4:18 AM, Mirsad Goran Todorovac wrote:
> 
> I'm sorry you couldn't reproduce the bug. I will try to provide the list of the installed pkgs the
> next time, for both configs
So, I'm able to reproduce this now on Ubuntu 22.04 with 6.0 mainline. Unfortunately, I won't be able to bisect and send that info to Thorsten and the Regressions list until Monday afternoon most likely. Both are Cc'd on this update.

[+Thorsten, +Regressions List]

Best,
-srw

^ permalink raw reply	[relevance 82%]

* Re: BUG: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-10-07  8:47 82%             ` Slade Watkins
@ 2022-10-07 10:55 82%               ` Mirsad Goran Todorovac
  0 siblings, 0 replies; 200+ results
From: Mirsad Goran Todorovac @ 2022-10-07 10:55 UTC (permalink / raw)
  To: Slade Watkins; +Cc: LKML, regressions, regressions

Hi Slate,

On 7.10.2022. 10:47, Slade Watkins wrote:
> Hey Mirsad,
>
> On 10/3/22 at 4:18 AM, Mirsad Goran Todorovac wrote:
>> I'm sorry you couldn't reproduce the bug. I will try to provide the list of the installed pkgs the
>> next time, for both configs
> So, I'm able to reproduce this now on Ubuntu 22.04 with 6.0 mainline. Unfortunately, I won't be able to bisect and send that info to Thorsten and the Regressions list until Monday afternoon most likely. Both are Cc'd on this update.

This is a very good peace of news.

To repeat for clarity, I made a build with Ubuntu's 
config-5.19.13-051913 and linux stable git pull from branch linux-6.0.y
and now it is running as I am trying to reproduce the bug as Thorsten 
recommended.

The bug usually isn't showing immediately, but after a couple of hours 
of running (especially with multimedia running inside Firefox).

It occurred also with FF 105.x snap on AlmaLinux with 6.0-rc7 mainline 
build, but not with 91.x esr version that runs from a rpm rather than snap.

Regards,
-mt

-- 
Mirsad Todorovac
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
--
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu


^ permalink raw reply	[relevance 82%]

* Re: BUG reproduced: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  @ 2022-10-09 22:45 82%                   ` Slade Watkins
  2022-10-11 17:53 82%                     ` Mirsad Goran Todorovac
  0 siblings, 1 reply; 200+ results
From: Slade Watkins @ 2022-10-09 22:45 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: linux-kernel, Mirsad Goran Todorovac, Marc Miltenberger,
	regressions@lists.linux.dev

Hi all,

On 10/9/22 at 2:45 AM, Thorsten Leemhuis wrote:
> Yeah, then it's pretty certain that his is a regression. But it could be
> caused by all sorts of things and I have no idea where to start. We thus
> really could need a bisection to find the root of the problem. This will
> be hard, as this crash only happens infrequently. Thing is: the Ubuntu
> developers likely have a strong interest in this particular issue and
> due to their knowledge of snap have way better chances to pin-point the
> root case quickly. So submitting a bug report to them might be the best
> way forward in this situation, even if the kernel is likely at fault here.

Thorsten,
Yeah, agreed. I haven't had time to bisect -- though it's on my list of
things to do: I'm going to try and make time tomorrow. Wish we had more
of an idea of what exactly was happening here.

Mirsad,
I'd be happy to help with a report to the Ubuntu folks. :-)

Best,
-srw


^ permalink raw reply	[relevance 82%]

* [Bug 216566] [xfstests generic/648] BUG: unable to handle page fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700 [xfs]
  @ 2022-10-09 22:47 82% ` bugzilla-daemon
  2022-10-09 22:47 82% ` [Bug 216566] New: " Dave Chinner
  2022-10-10  1:31 82% ` [Bug 216566] " bugzilla-daemon
  2 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-10-09 22:47 UTC (permalink / raw)
  To: linux-xfs

https://bugzilla.kernel.org/show_bug.cgi?id=216566

--- Comment #1 from Dave Chinner (david@fromorbit.com) ---
On Sun, Oct 09, 2022 at 05:47:49PM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216566
> 
>             Bug ID: 216566
>            Summary: [xfstests generic/648] BUG: unable to handle page
>                     fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700
>                     [xfs]
>            Product: File System
>            Version: 2.5
>     Kernel Version: v6.1-rc0
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: XFS
>           Assignee: filesystem_xfs@kernel-bugs.kernel.org
>           Reporter: zlang@redhat.com
>         Regression: No
> 
> xfstests generic/648 hit kernel panic[1] on xfs with 64k directory block size
> (-n size=65536), before panic, there's a kernel assertion (not sure if it's
> related).
> 
> It's reproducable, but not easy. Generally I reproduced it by loop running
> generic/648 on xfs (-n size=65536) hundreds of time.
> 
> The last time I hit this panic on linux with HEAD=

Given that there have been no changes to XFS committed in v6.1-rc0
at this point in time, this won't be an XFS regression unless you
can reproduce it on 6.0 or 5.19 kernels, too. Regardless, I'd suggest
bisection is in order to find where the problem was introduced.

-Dave.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 216566] New: [xfstests generic/648] BUG: unable to handle page fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700 [xfs]
    2022-10-09 22:47 82% ` [Bug 216566] " bugzilla-daemon
@ 2022-10-09 22:47 82% ` Dave Chinner
  2022-10-10  1:31 82% ` [Bug 216566] " bugzilla-daemon
  2 siblings, 0 replies; 200+ results
From: Dave Chinner @ 2022-10-09 22:47 UTC (permalink / raw)
  To: bugzilla-daemon; +Cc: linux-xfs

On Sun, Oct 09, 2022 at 05:47:49PM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216566
> 
>             Bug ID: 216566
>            Summary: [xfstests generic/648] BUG: unable to handle page
>                     fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700
>                     [xfs]
>            Product: File System
>            Version: 2.5
>     Kernel Version: v6.1-rc0
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: XFS
>           Assignee: filesystem_xfs@kernel-bugs.kernel.org
>           Reporter: zlang@redhat.com
>         Regression: No
> 
> xfstests generic/648 hit kernel panic[1] on xfs with 64k directory block size
> (-n size=65536), before panic, there's a kernel assertion (not sure if it's
> related).
> 
> It's reproducable, but not easy. Generally I reproduced it by loop running
> generic/648 on xfs (-n size=65536) hundreds of time.
> 
> The last time I hit this panic on linux with HEAD=

Given that there have been no changes to XFS committed in v6.1-rc0
at this point in time, this won't be an XFS regression unless you
can reproduce it on 6.0 or 5.19 kernels, too. Regardless, I'd suggest
bisection is in order to find where the problem was introduced.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[relevance 82%]

* [Bug 216567] [xfstests generic/451] kernel BUG at mm/truncate.c:669!
  @ 2022-10-09 22:58 82% ` bugzilla-daemon
    1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-10-09 22:58 UTC (permalink / raw)
  To: linux-xfs

https://bugzilla.kernel.org/show_bug.cgi?id=216567

--- Comment #2 from Dave Chinner (david@fromorbit.com) ---
On Sun, Oct 09, 2022 at 05:58:33PM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216567
> 
> --- Comment #1 from Zorro Lang (zlang@redhat.com) ---
> Hmm... besides this panic, g/451 just hit another panic when I tried to
> reproduce this bug:
> 
> [ 1084.111233] run fstests generic/451 at 2022-10-09 11:12:39 
> [ 1099.015616] restraintd[2581]: *** Current Time: Sun Oct 09 11:12:56 2022 
> Localwatchdog at: Tue Oct 11 10:57:56 2022 
> [ 1101.932132] ------------[ cut here ]------------ 
> [ 1101.932220] ------------[ cut here ]------------ 
> [ 1101.936972] kernel BUG at include/linux/pagemap.h:1247! 
> [ 1101.936985] invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI 
> [ 1101.941681] kernel BUG at include/linux/pagemap.h:1247! 
> [ 1101.946825] CPU: 19 PID: 557513 Comm: xfs_io Kdump: loaded Not tainted
> 6.0.0+ #1 
> [ 1101.946831] Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.5.4
> 12/17/2021 
> [ 1101.946833] RIP: 0010:read_pages+0xa29/0xda0 
> [ 1101.976950] Code: ff ff be 01 00 00 00 e9 87 fe ff ff 0f b6 d0 be ff ff ff
> ff 4c 89 ff 88 44 24 18 e8 11 74 25 00 0f b6 44 24 18 e9 f1 fe ff ff <0f> 0b
> 4c
> 89 ff e8 1d 86 00 00 e9 ea fe ff ff 48 c7 c6 c0 85 55 99 
> [ 1101.995693] RSP: 0018:ffa00000396ef7f0 EFLAGS: 00010202 
> [ 1102.000921] RAX: 0000000000000002 RBX: dffffc0000000000 RCX:
> 0000000000000001 
> [ 1102.008054] RDX: 1fe220003427d324 RSI: 0000000000000004 RDI:
> ffd40000095e8500 
> [ 1102.015186] RBP: ffffffffc13f66c0 R08: 0000000000000000 R09:
> ffffffff9aa44067 
> [ 1102.022321] R10: fffffbfff354880c R11: 0000000000000001 R12:
> fff3fc00072ddf4a 
> [ 1102.029451] R13: ffa00000396efa54 R14: ffa00000396efa30 R15:
> 0000000000000003 
> [ 1102.036584] FS:  00007f1de484b740(0000) GS:ff11002033400000(0000)
> knlGS:0000000000000000 
> [ 1102.044671] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
> [ 1102.050418] CR2: 0000000001c81ff8 CR3: 000000016171e004 CR4:
> 0000000000771ee0 
> [ 1102.057549] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000 
> [ 1102.064681] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
> 0000000000000400 
> [ 1102.071815] PKRU: 55555554 
> [ 1102.074527] Call Trace: 
> [ 1102.076982]  <TASK> 
> [ 1102.079092]  ? file_ra_state_init+0xe0/0xe0 
> [ 1102.083283]  ? __xa_clear_mark+0x100/0x100 
> [ 1102.087385]  page_cache_ra_unbounded+0x269/0x510 
> [ 1102.092013]  filemap_get_pages+0x26d/0x980 
> [ 1102.096121]  ? filemap_add_folio+0x150/0x150 
> [ 1102.100403]  filemap_read+0x2a9/0xae0 
> [ 1102.104074]  ? lock_acquire+0x1d8/0x620 
> [ 1102.107921]  ? find_held_lock+0x33/0x120 
> [ 1102.111850]  ? filemap_get_pages+0x980/0x980 
> [ 1102.116121]  ? validate_chain+0x154/0xdf0 
> [ 1102.120133]  ? __lock_contended+0x980/0x980 
> [ 1102.124320]  ? xfs_ilock+0x1d0/0x4d0 [xfs] 
> [ 1102.128582]  ? xfs_ilock+0x1d0/0x4d0 [xfs] 
> [ 1102.132816]  xfs_file_buffered_read+0x16f/0x390 [xfs] 
> [ 1102.137995]  xfs_file_read_iter+0x274/0x560 [xfs] 
> [ 1102.142831]  vfs_read+0x585/0x810 

This is also a problem with the page cache, and doesn't seem related
to XFS or directory block size configuration:

        BUG_ON(ractl->_batch_count > ractl->_nr_pages);

Also, there haven't been any changes to XFS code so far in 6.1-rc0,
so this isn't a recent XFS regression, either. Perhaps a bisect
would be in order?

-Dave.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 216567] [xfstests generic/451] kernel BUG at mm/truncate.c:669!
  @ 2022-10-09 22:58 82%   ` Dave Chinner
  0 siblings, 0 replies; 200+ results
From: Dave Chinner @ 2022-10-09 22:58 UTC (permalink / raw)
  To: bugzilla-daemon; +Cc: linux-xfs

On Sun, Oct 09, 2022 at 05:58:33PM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216567
> 
> --- Comment #1 from Zorro Lang (zlang@redhat.com) ---
> Hmm... besides this panic, g/451 just hit another panic when I tried to
> reproduce this bug:
> 
> [ 1084.111233] run fstests generic/451 at 2022-10-09 11:12:39 
> [ 1099.015616] restraintd[2581]: *** Current Time: Sun Oct 09 11:12:56 2022 
> Localwatchdog at: Tue Oct 11 10:57:56 2022 
> [ 1101.932132] ------------[ cut here ]------------ 
> [ 1101.932220] ------------[ cut here ]------------ 
> [ 1101.936972] kernel BUG at include/linux/pagemap.h:1247! 
> [ 1101.936985] invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI 
> [ 1101.941681] kernel BUG at include/linux/pagemap.h:1247! 
> [ 1101.946825] CPU: 19 PID: 557513 Comm: xfs_io Kdump: loaded Not tainted
> 6.0.0+ #1 
> [ 1101.946831] Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.5.4
> 12/17/2021 
> [ 1101.946833] RIP: 0010:read_pages+0xa29/0xda0 
> [ 1101.976950] Code: ff ff be 01 00 00 00 e9 87 fe ff ff 0f b6 d0 be ff ff ff
> ff 4c 89 ff 88 44 24 18 e8 11 74 25 00 0f b6 44 24 18 e9 f1 fe ff ff <0f> 0b 4c
> 89 ff e8 1d 86 00 00 e9 ea fe ff ff 48 c7 c6 c0 85 55 99 
> [ 1101.995693] RSP: 0018:ffa00000396ef7f0 EFLAGS: 00010202 
> [ 1102.000921] RAX: 0000000000000002 RBX: dffffc0000000000 RCX:
> 0000000000000001 
> [ 1102.008054] RDX: 1fe220003427d324 RSI: 0000000000000004 RDI:
> ffd40000095e8500 
> [ 1102.015186] RBP: ffffffffc13f66c0 R08: 0000000000000000 R09:
> ffffffff9aa44067 
> [ 1102.022321] R10: fffffbfff354880c R11: 0000000000000001 R12:
> fff3fc00072ddf4a 
> [ 1102.029451] R13: ffa00000396efa54 R14: ffa00000396efa30 R15:
> 0000000000000003 
> [ 1102.036584] FS:  00007f1de484b740(0000) GS:ff11002033400000(0000)
> knlGS:0000000000000000 
> [ 1102.044671] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
> [ 1102.050418] CR2: 0000000001c81ff8 CR3: 000000016171e004 CR4:
> 0000000000771ee0 
> [ 1102.057549] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000 
> [ 1102.064681] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
> 0000000000000400 
> [ 1102.071815] PKRU: 55555554 
> [ 1102.074527] Call Trace: 
> [ 1102.076982]  <TASK> 
> [ 1102.079092]  ? file_ra_state_init+0xe0/0xe0 
> [ 1102.083283]  ? __xa_clear_mark+0x100/0x100 
> [ 1102.087385]  page_cache_ra_unbounded+0x269/0x510 
> [ 1102.092013]  filemap_get_pages+0x26d/0x980 
> [ 1102.096121]  ? filemap_add_folio+0x150/0x150 
> [ 1102.100403]  filemap_read+0x2a9/0xae0 
> [ 1102.104074]  ? lock_acquire+0x1d8/0x620 
> [ 1102.107921]  ? find_held_lock+0x33/0x120 
> [ 1102.111850]  ? filemap_get_pages+0x980/0x980 
> [ 1102.116121]  ? validate_chain+0x154/0xdf0 
> [ 1102.120133]  ? __lock_contended+0x980/0x980 
> [ 1102.124320]  ? xfs_ilock+0x1d0/0x4d0 [xfs] 
> [ 1102.128582]  ? xfs_ilock+0x1d0/0x4d0 [xfs] 
> [ 1102.132816]  xfs_file_buffered_read+0x16f/0x390 [xfs] 
> [ 1102.137995]  xfs_file_read_iter+0x274/0x560 [xfs] 
> [ 1102.142831]  vfs_read+0x585/0x810 

This is also a problem with the page cache, and doesn't seem related
to XFS or directory block size configuration:

	BUG_ON(ractl->_batch_count > ractl->_nr_pages);

Also, there haven't been any changes to XFS code so far in 6.1-rc0,
so this isn't a recent XFS regression, either. Perhaps a bisect
would be in order?

-Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[relevance 82%]

* [Bug 216566] [xfstests generic/648] BUG: unable to handle page fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700 [xfs]
    2022-10-09 22:47 82% ` [Bug 216566] " bugzilla-daemon
  2022-10-09 22:47 82% ` [Bug 216566] New: " Dave Chinner
@ 2022-10-10  1:31 82% ` bugzilla-daemon
  2 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-10-10  1:31 UTC (permalink / raw)
  To: linux-xfs

https://bugzilla.kernel.org/show_bug.cgi?id=216566

--- Comment #2 from Zorro Lang (zlang@redhat.com) ---
(In reply to Dave Chinner from comment #1)
> On Sun, Oct 09, 2022 at 05:47:49PM +0000, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=216566
> > 
> >             Bug ID: 216566
> >            Summary: [xfstests generic/648] BUG: unable to handle page
> >                     fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700
> >                     [xfs]
> >            Product: File System
> >            Version: 2.5
> >     Kernel Version: v6.1-rc0
> >           Hardware: All
> >                 OS: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: XFS
> >           Assignee: filesystem_xfs@kernel-bugs.kernel.org
> >           Reporter: zlang@redhat.com
> >         Regression: No
> > 
> > xfstests generic/648 hit kernel panic[1] on xfs with 64k directory block
> size
> > (-n size=65536), before panic, there's a kernel assertion (not sure if it's
> > related).
> > 
> > It's reproducable, but not easy. Generally I reproduced it by loop running
> > generic/648 on xfs (-n size=65536) hundreds of time.
> > 
> > The last time I hit this panic on linux with HEAD=
> 
> Given that there have been no changes to XFS committed in v6.1-rc0
> at this point in time, this won't be an XFS regression unless you
> can reproduce it on 6.0 or 5.19 kernels, too. Regardless, I'd suggest
> bisection is in order to find where the problem was introduced.

It's not a regression recently, I even can reproduce it on RHEL-9 (which base
on 5.14 kernel).

> 
> -Dave.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 216529] New: [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
  2022-09-27 18:10 82%   ` Ritesh Harjani (IBM)
@ 2022-10-10 17:01 82%     ` Ritesh Harjani (IBM)
  0 siblings, 0 replies; 200+ results
From: Ritesh Harjani (IBM) @ 2022-10-10 17:01 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: bugzilla-daemon, linux-ext4

On 22/09/27 11:40PM, Ritesh Harjani (IBM) wrote:
> On 22/09/26 01:02AM, Theodore Ts'o wrote:
> > On Sun, Sep 25, 2022 at 11:55:29AM +0000, bugzilla-daemon@kernel.org wrote:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=216529
> > >
> > >
> > > Hit a panic on ppc64le, by running generic/048 with 1k block size:
> >
> > Hmm, does this reproduce reliably for you?  I test with a 1k block
> > size on x86_64 as a proxy 4k block sizes on PPC64, where the blocksize
> > < pagesize... and this isn't reproducing for me on x86, and I don't
> > have access to a PPC64LE system.
> >
> > Ritesh, is this something you can take a look at it?  Thanks!
>
> I was away for some personal work for last few days, but I am back to work from
> today. Sure, I will take a look at this and will get back.
>
> I did give this test a couple of runs though, but wasn't able to reproduce it.
> But let me try few more things along with more iterations. Will update
> accordingly.

I thought I had updated this. But I guess I forgot to update on this mail
thread...

I tested this for quite some time in a loop and also gave it a overnight run,
but I couldn't hit this issue. I had kept low memory size guest, so that we
could see more reclaim activity (which I also ensured by doing perf trace to see
if we are going over that path or not while test was running).

I am not sure whether this could be a timing issue or what. Maybe if you could
share your defconfig, I could give a try with that on my setup once.

-ritesh

^ permalink raw reply	[relevance 82%]

* [Bug 216529] [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0
                     ` (2 preceding siblings ...)
  2022-09-26  5:02 82% ` bugzilla-daemon
@ 2022-10-10 17:01 82% ` bugzilla-daemon
  2022-09-27 18:10 82% ` bugzilla-daemon
    5 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-10-10 17:01 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216529

--- Comment #5 from ritesh.list@gmail.com ---
On 22/09/27 11:40PM, Ritesh Harjani (IBM) wrote:
> On 22/09/26 01:02AM, Theodore Ts'o wrote:
> > On Sun, Sep 25, 2022 at 11:55:29AM +0000, bugzilla-daemon@kernel.org wrote:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=216529
> > >
> > >
> > > Hit a panic on ppc64le, by running generic/048 with 1k block size:
> >
> > Hmm, does this reproduce reliably for you?  I test with a 1k block
> > size on x86_64 as a proxy 4k block sizes on PPC64, where the blocksize
> > < pagesize... and this isn't reproducing for me on x86, and I don't
> > have access to a PPC64LE system.
> >
> > Ritesh, is this something you can take a look at it?  Thanks!
>
> I was away for some personal work for last few days, but I am back to work
> from
> today. Sure, I will take a look at this and will get back.
>
> I did give this test a couple of runs though, but wasn't able to reproduce
> it.
> But let me try few more things along with more iterations. Will update
> accordingly.

I thought I had updated this. But I guess I forgot to update on this mail
thread...

I tested this for quite some time in a loop and also gave it a overnight run,
but I couldn't hit this issue. I had kept low memory size guest, so that we
could see more reclaim activity (which I also ensured by doing perf trace to
see
if we are going over that path or not while test was running).

I am not sure whether this could be a timing issue or what. Maybe if you could
share your defconfig, I could give a try with that on my setup once.

-ritesh

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: BUG reproduced: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  2022-10-09 22:45 82%                   ` Slade Watkins
@ 2022-10-11 17:53 82%                     ` Mirsad Goran Todorovac
  0 siblings, 0 replies; 200+ results
From: Mirsad Goran Todorovac @ 2022-10-11 17:53 UTC (permalink / raw)
  To: Slade Watkins, Thorsten Leemhuis
  Cc: linux-kernel, Marc Miltenberger, regressions@lists.linux.dev

On 10. 10. 2022. 00:45, Slade Watkins wrote:

> Hi all,
>
> On 10/9/22 at 2:45 AM, Thorsten Leemhuis wrote:
>> Yeah, then it's pretty certain that his is a regression. But it could be
>> caused by all sorts of things and I have no idea where to start. We thus
>> really could need a bisection to find the root of the problem. This will
>> be hard, as this crash only happens infrequently. Thing is: the Ubuntu
>> developers likely have a strong interest in this particular issue and
>> due to their knowledge of snap have way better chances to pin-point the
>> root case quickly. So submitting a bug report to them might be the best
>> way forward in this situation, even if the kernel is likely at fault here.
> Thorsten,
> Yeah, agreed. I haven't had time to bisect -- though it's on my list of
> things to do: I'm going to try and make time tomorrow. Wish we had more
> of an idea of what exactly was happening here.
>
> Mirsad,
> I'd be happy to help with a report to the Ubuntu folks. :-)

Hi, Slade,

Actually, I think I the project would benefit if you shared your 
experiences with
the Ubuntu folks. You know their English dialect.

This is not about the prestige, but about getting the bug fixed.

-mgt

--
Mirsad Goran Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
-- 
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
The European Union


^ permalink raw reply	[relevance 82%]

* Re: BUG reproduced: 6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7
  @ 2022-10-12 22:58 82%                   ` Slade Watkins
  0 siblings, 0 replies; 200+ results
From: Slade Watkins @ 2022-10-12 22:58 UTC (permalink / raw)
  To: Mirsad Todorovac
  Cc: Thorsten Leemhuis, linux-kernel, Marc Miltenberger,
	regressions@lists.linux.dev

On Wed, Oct 12, 2022 at 2:05 AM Mirsad Todorovac
<mirsad.todorovac@alu.unizg.hr> wrote:
>
> However, I haven't yet done informing the Ubuntu developers.
>
> I will try to do that later today.

Please let me know once you do!

Thanks,
-srw

^ permalink raw reply	[relevance 82%]

* Bug 216582 - BUG: kernel NULL pointer dereference - nlmclnt_setlockargs
@ 2022-10-16 11:21 82% Thorsten Leemhuis
  2022-10-16 11:56 82% ` Daire Byrne
  0 siblings, 1 reply; 200+ results
From: Thorsten Leemhuis @ 2022-10-16 11:21 UTC (permalink / raw)
  To: Trond Myklebust, Anna Schumaker
  Cc: Linux NFS Mailing List, LKML, regressions@lists.linux.dev,
	Daire Byrne

Hi, this is your Linux kernel regression tracker speaking.

I noticed a regression report in bugzilla.kernel.org. As many (most?)
kernel developer don't keep an eye on it, I decided to forward it by
mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216582 :

>  Daire Byrne 2022-10-13 22:04:19 UTC
> 
> Hi,
> 
> I've started seeing this crash at least once or twice a week with our
> NFS re-export workloads (re-exporting a Linux NFsv3 server as
> NFSv3).
> 
> We have been stepping through kernel versions a bit on the server
> recently so it feels like something new introduced somewhere around
> v5.17 but I also can't rule out that our clients are doing something
> "different" with their workloads to stress this code in some new way.
> It still occurs in v6.0 too.
> 
> [106412.314663] BUG: kernel NULL pointer dereference, address: 0000000000000020
> [106412.321879] #PF: supervisor read access in kernel mode
> [106412.327237] #PF: error_code(0x0000) - not-present page
> [106412.332599] PGD 0 P4D 0 
> [106412.335353] Oops: 0000 [#1] PREEMPT SMP NOPTI
> [106412.339935] CPU: 34 PID: 2382 Comm: lockd Tainted: G            E     5.18.10-1.dneg.x86_64 #1
> [106412.348773] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
> [106412.358223] RIP: 0010:nlmclnt_setlockargs+0x4a/0x100 [lockd]
> [106412.364116] Code: 00 00 49 81 c0 88 00 00 00 f0 0f c1 05 bf 06 01 00 83 c0 01 c7 47 30 04 00 00 00 48 8d 4f 44 48 8d 7f 4c 89 47 c4 48 8b 46 78 <48> 8b 40 20 48 8b 90 60 fe ff ff 48 8d b0 60 fe ff ff 48 89 57 f8
> [106412.383117] RSP: 0018:ffffb3db50cdfa80 EFLAGS: 00010202
> [106412.388569] RAX: 0000000000000000 RBX: ffff8a36749c9400 RCX: ffff8a36749c9444
> [106412.395924] RDX: ffff8a37f8696300 RSI: ffffb3db50cdfbd8 RDI: ffff8a36749c944c
> [106412.403277] RBP: ffffb3db50cdfa90 R08: ffff8a750b49bc88 R09: ffff8a37f8696300
> [106412.410634] R10: 0000000000000230 R11: ffffffffffffffff R12: ffffb3db50cdfbd8
> [106412.417984] R13: ffff8a7508beac00 R14: ffffb3db50cdfca0 R15: ffffb3db50cdfbd8
> [106412.425338] FS:  0000000000000000(0000) GS:ffff8a73ffa80000(0000) knlGS:0000000000000000
> [106412.433649] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [106412.439611] CR2: 0000000000000020 CR3: 00000001118e6006 CR4: 00000000003706e0
> [106412.446984] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [106412.454346] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [106412.461696] Call Trace:
> [106412.464361]  <TASK>
> [106412.466689]  nlmclnt_proc+0x1c6/0x5b0 [lockd]
> [106412.471272]  nfs3_proc_lock+0x33/0xb0 [nfsv3]
> [106412.475848]  ? nfs_put_lock_context+0x86/0x90 [nfs]
> [106412.481008]  do_unlk+0x8f/0xd0 [nfs]
> [106412.484837]  nfs_lock+0xcd/0x180 [nfs]
> [106412.488815]  ? nlmsvc_mark_host+0x30/0x30 [lockd]
> [106412.493752]  vfs_lock_file+0x1e/0x40
> [106412.497547]  nlm_unlock_files.isra.0+0x6d/0xc0 [lockd]
> [106412.502905]  nlm_traverse_files+0x163/0x2a0 [lockd]
> [106412.508020]  nlmsvc_free_host_resources+0x2b/0x40 [lockd]
> [106412.513648]  nlm_host_rebooted+0x2c/0x90 [lockd]
> [106412.518483]  nlmsvc_proc_sm_notify+0xc0/0x130 [lockd]
> [106412.523759]  ? nlmsvc_decode_reboot+0x7d/0xa0 [lockd]
> [106412.529027]  nlmsvc_dispatch+0x8e/0x1a0 [lockd]
> [106412.534312]  svc_process_common+0x484/0x620 [sunrpc]
> [106412.539521]  ? lockd+0x1d0/0x1d0 [lockd]
> [106412.543661]  ? set_grace_period+0xa0/0xa0 [lockd]
> [106412.548582]  svc_process+0xbc/0xf0 [sunrpc]
> [106412.553008]  lockd+0xd2/0x1d0 [lockd]
> [106412.556906]  ? set_grace_period+0xa0/0xa0 [lockd]
> [106412.561849]  kthread+0xee/0x120
> [106412.565228]  ? kthread_complete_and_exit+0x20/0x20
> [106412.570239]  ret_from_fork+0x1f/0x30
> [106412.574033]  </TASK>
> [106412.576436] Modules linked in: tcp_diag(E) inet_diag(E) nfsv3(E) nfs(E) cachefiles(E) fscache(E) netfs(E) ext4(E) mbcache(E) jbd2(E) intel_uncore_frequency_common(E) isst_if_common(E) sg(E) nfit(E) virtio_rng(E) rapl(E) i2c_piix4(E) input_leds(E) nfsd(E) sch_fq(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) tcp_bbr(E) binfmt_misc(E) ip_tables(E) xfs(E) libcrc32c(E) sd_mod(E) t10_pi(E) crc64_rocksoft_generic(E) crc64_rocksoft(E) crc64(E) crct10dif_pclmul(E) crc32_pclmul(E) virtio_scsi(E) crc32c_intel(E) ghash_clmulni_intel(E) 8021q(E) garp(E) mrp(E) virtio_pci(E) scsi_transport_iscsi(E) virtio_pci_legacy_dev(E) aesni_intel(E) virtio_pci_modern_dev(E) crypto_simd(E) virtio_ring(E) cryptd(E) gve(E) serio_raw(E) virtio(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) fuse(E)
> [106412.646242] CR2: 0000000000000020
> [106412.649780] ---[ end trace 0000000000000000 ]---
> [106412.654617] RIP: 0010:nlmclnt_setlockargs+0x4a/0x100 [lockd]
> [106412.660495] Code: 00 00 49 81 c0 88 00 00 00 f0 0f c1 05 bf 06 01 00 83 c0 01 c7 47 30 04 00 00 00 48 8d 4f 44 48 8d 7f 4c 89 47 c4 48 8b 46 78 <48> 8b 40 20 48 8b 90 60 fe ff ff 48 8d b0 60 fe ff ff 48 89 57 f8
> [106412.679481] RSP: 0018:ffffb3db50cdfa80 EFLAGS: 00010202
> [106412.684922] RAX: 0000000000000000 RBX: ffff8a36749c9400 RCX: ffff8a36749c9444
> [106412.692269] RDX: ffff8a37f8696300 RSI: ffffb3db50cdfbd8 RDI: ffff8a36749c944c
> [106412.699617] RBP: ffffb3db50cdfa90 R08: ffff8a750b49bc88 R09: ffff8a37f8696300
> [106412.706969] R10: 0000000000000230 R11: ffffffffffffffff R12: ffffb3db50cdfbd8
> [106412.714329] R13: ffff8a7508beac00 R14: ffffb3db50cdfca0 R15: ffffb3db50cdfbd8
> [106412.721676] FS:  0000000000000000(0000) GS:ffff8a73ffa80000(0000) knlGS:0000000000000000
> [106412.729981] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [106412.736472] CR2: 0000000000000020 CR3: 00000001118e6006 CR4: 00000000003706e0
> [106412.743821] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [106412.751171] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [106412.758520] Kernel panic - not syncing: Fatal exception
> [106412.764850] Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [106412.775850] ---[ end Kernel panic - not syncing: Fatal exception ]---
> 
> 
> All I know is that I didn't notice this crash from v5.12 to v5.16 but
> I have not been able to test this qualitatively yet. The crash is
> rare enough that it makes A/B testing quite tricky.
> 
> It's somewhat similar to
> https://bugzilla.kernel.org/show_bug.cgi?id=213273 but that was for a
> NFv4.2 re-export of NFSv3 and this is for a NFSv3 re-export of NFSv3
> (for WAN caching).
> 
> We are using nfs-utils-2.5.4.
> 
> Daire

See the ticket for more details.

BTW, let me use this mail to also add the report to the list of tracked
regressions to ensure it's doesn't fall through the cracks:

#regzbot introduced: v5.17..v5.18
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

^ permalink raw reply	[relevance 82%]

* Re: Bug 216582 - BUG: kernel NULL pointer dereference - nlmclnt_setlockargs
  2022-10-16 11:21 82% Bug 216582 - BUG: kernel NULL pointer dereference - nlmclnt_setlockargs Thorsten Leemhuis
@ 2022-10-16 11:56 82% ` Daire Byrne
  0 siblings, 0 replies; 200+ results
From: Daire Byrne @ 2022-10-16 11:56 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Trond Myklebust, Anna Schumaker, Linux NFS Mailing List, LKML,
	regressions@lists.linux.dev

Thorston,

Thanks, but I should just say that I'm not certain this is a
regression yet - it could just be a change in our workload that is
triggering something I haven't seen before.

I am slowly working back through kernel versions to verify that - but
it's really hard to trigger and does not happen often so it is slow
going. Also my workload and configuration is quite unique (NFS
re-exporting) so I may be the only one seeing this...

Cheers,

Daire

On Sun, 16 Oct 2022 at 12:21, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Hi, this is your Linux kernel regression tracker speaking.
>
> I noticed a regression report in bugzilla.kernel.org. As many (most?)
> kernel developer don't keep an eye on it, I decided to forward it by
> mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216582 :
>
> >  Daire Byrne 2022-10-13 22:04:19 UTC
> >
> > Hi,
> >
> > I've started seeing this crash at least once or twice a week with our
> > NFS re-export workloads (re-exporting a Linux NFsv3 server as
> > NFSv3).
> >
> > We have been stepping through kernel versions a bit on the server
> > recently so it feels like something new introduced somewhere around
> > v5.17 but I also can't rule out that our clients are doing something
> > "different" with their workloads to stress this code in some new way.
> > It still occurs in v6.0 too.
> >
> > [106412.314663] BUG: kernel NULL pointer dereference, address: 0000000000000020
> > [106412.321879] #PF: supervisor read access in kernel mode
> > [106412.327237] #PF: error_code(0x0000) - not-present page
> > [106412.332599] PGD 0 P4D 0
> > [106412.335353] Oops: 0000 [#1] PREEMPT SMP NOPTI
> > [106412.339935] CPU: 34 PID: 2382 Comm: lockd Tainted: G            E     5.18.10-1.dneg.x86_64 #1
> > [106412.348773] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
> > [106412.358223] RIP: 0010:nlmclnt_setlockargs+0x4a/0x100 [lockd]
> > [106412.364116] Code: 00 00 49 81 c0 88 00 00 00 f0 0f c1 05 bf 06 01 00 83 c0 01 c7 47 30 04 00 00 00 48 8d 4f 44 48 8d 7f 4c 89 47 c4 48 8b 46 78 <48> 8b 40 20 48 8b 90 60 fe ff ff 48 8d b0 60 fe ff ff 48 89 57 f8
> > [106412.383117] RSP: 0018:ffffb3db50cdfa80 EFLAGS: 00010202
> > [106412.388569] RAX: 0000000000000000 RBX: ffff8a36749c9400 RCX: ffff8a36749c9444
> > [106412.395924] RDX: ffff8a37f8696300 RSI: ffffb3db50cdfbd8 RDI: ffff8a36749c944c
> > [106412.403277] RBP: ffffb3db50cdfa90 R08: ffff8a750b49bc88 R09: ffff8a37f8696300
> > [106412.410634] R10: 0000000000000230 R11: ffffffffffffffff R12: ffffb3db50cdfbd8
> > [106412.417984] R13: ffff8a7508beac00 R14: ffffb3db50cdfca0 R15: ffffb3db50cdfbd8
> > [106412.425338] FS:  0000000000000000(0000) GS:ffff8a73ffa80000(0000) knlGS:0000000000000000
> > [106412.433649] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [106412.439611] CR2: 0000000000000020 CR3: 00000001118e6006 CR4: 00000000003706e0
> > [106412.446984] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [106412.454346] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [106412.461696] Call Trace:
> > [106412.464361]  <TASK>
> > [106412.466689]  nlmclnt_proc+0x1c6/0x5b0 [lockd]
> > [106412.471272]  nfs3_proc_lock+0x33/0xb0 [nfsv3]
> > [106412.475848]  ? nfs_put_lock_context+0x86/0x90 [nfs]
> > [106412.481008]  do_unlk+0x8f/0xd0 [nfs]
> > [106412.484837]  nfs_lock+0xcd/0x180 [nfs]
> > [106412.488815]  ? nlmsvc_mark_host+0x30/0x30 [lockd]
> > [106412.493752]  vfs_lock_file+0x1e/0x40
> > [106412.497547]  nlm_unlock_files.isra.0+0x6d/0xc0 [lockd]
> > [106412.502905]  nlm_traverse_files+0x163/0x2a0 [lockd]
> > [106412.508020]  nlmsvc_free_host_resources+0x2b/0x40 [lockd]
> > [106412.513648]  nlm_host_rebooted+0x2c/0x90 [lockd]
> > [106412.518483]  nlmsvc_proc_sm_notify+0xc0/0x130 [lockd]
> > [106412.523759]  ? nlmsvc_decode_reboot+0x7d/0xa0 [lockd]
> > [106412.529027]  nlmsvc_dispatch+0x8e/0x1a0 [lockd]
> > [106412.534312]  svc_process_common+0x484/0x620 [sunrpc]
> > [106412.539521]  ? lockd+0x1d0/0x1d0 [lockd]
> > [106412.543661]  ? set_grace_period+0xa0/0xa0 [lockd]
> > [106412.548582]  svc_process+0xbc/0xf0 [sunrpc]
> > [106412.553008]  lockd+0xd2/0x1d0 [lockd]
> > [106412.556906]  ? set_grace_period+0xa0/0xa0 [lockd]
> > [106412.561849]  kthread+0xee/0x120
> > [106412.565228]  ? kthread_complete_and_exit+0x20/0x20
> > [106412.570239]  ret_from_fork+0x1f/0x30
> > [106412.574033]  </TASK>
> > [106412.576436] Modules linked in: tcp_diag(E) inet_diag(E) nfsv3(E) nfs(E) cachefiles(E) fscache(E) netfs(E) ext4(E) mbcache(E) jbd2(E) intel_uncore_frequency_common(E) isst_if_common(E) sg(E) nfit(E) virtio_rng(E) rapl(E) i2c_piix4(E) input_leds(E) nfsd(E) sch_fq(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) tcp_bbr(E) binfmt_misc(E) ip_tables(E) xfs(E) libcrc32c(E) sd_mod(E) t10_pi(E) crc64_rocksoft_generic(E) crc64_rocksoft(E) crc64(E) crct10dif_pclmul(E) crc32_pclmul(E) virtio_scsi(E) crc32c_intel(E) ghash_clmulni_intel(E) 8021q(E) garp(E) mrp(E) virtio_pci(E) scsi_transport_iscsi(E) virtio_pci_legacy_dev(E) aesni_intel(E) virtio_pci_modern_dev(E) crypto_simd(E) virtio_ring(E) cryptd(E) gve(E) serio_raw(E) virtio(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) fuse(E)
> > [106412.646242] CR2: 0000000000000020
> > [106412.649780] ---[ end trace 0000000000000000 ]---
> > [106412.654617] RIP: 0010:nlmclnt_setlockargs+0x4a/0x100 [lockd]
> > [106412.660495] Code: 00 00 49 81 c0 88 00 00 00 f0 0f c1 05 bf 06 01 00 83 c0 01 c7 47 30 04 00 00 00 48 8d 4f 44 48 8d 7f 4c 89 47 c4 48 8b 46 78 <48> 8b 40 20 48 8b 90 60 fe ff ff 48 8d b0 60 fe ff ff 48 89 57 f8
> > [106412.679481] RSP: 0018:ffffb3db50cdfa80 EFLAGS: 00010202
> > [106412.684922] RAX: 0000000000000000 RBX: ffff8a36749c9400 RCX: ffff8a36749c9444
> > [106412.692269] RDX: ffff8a37f8696300 RSI: ffffb3db50cdfbd8 RDI: ffff8a36749c944c
> > [106412.699617] RBP: ffffb3db50cdfa90 R08: ffff8a750b49bc88 R09: ffff8a37f8696300
> > [106412.706969] R10: 0000000000000230 R11: ffffffffffffffff R12: ffffb3db50cdfbd8
> > [106412.714329] R13: ffff8a7508beac00 R14: ffffb3db50cdfca0 R15: ffffb3db50cdfbd8
> > [106412.721676] FS:  0000000000000000(0000) GS:ffff8a73ffa80000(0000) knlGS:0000000000000000
> > [106412.729981] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [106412.736472] CR2: 0000000000000020 CR3: 00000001118e6006 CR4: 00000000003706e0
> > [106412.743821] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [106412.751171] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [106412.758520] Kernel panic - not syncing: Fatal exception
> > [106412.764850] Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> > [106412.775850] ---[ end Kernel panic - not syncing: Fatal exception ]---
> >
> >
> > All I know is that I didn't notice this crash from v5.12 to v5.16 but
> > I have not been able to test this qualitatively yet. The crash is
> > rare enough that it makes A/B testing quite tricky.
> >
> > It's somewhat similar to
> > https://bugzilla.kernel.org/show_bug.cgi?id=213273 but that was for a
> > NFv4.2 re-export of NFSv3 and this is for a NFSv3 re-export of NFSv3
> > (for WAN caching).
> >
> > We are using nfs-utils-2.5.4.
> >
> > Daire
>
> See the ticket for more details.
>
> BTW, let me use this mail to also add the report to the list of tracked
> regressions to ensure it's doesn't fall through the cracks:
>
> #regzbot introduced: v5.17..v5.18
> #regzbot ignore-activity
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.

^ permalink raw reply	[relevance 82%]

* [Bug 1087] [Bug] tcp data len is incorrectly calculated in gro_tcp4_reassemble function
  2022-09-29  1:40 82% [Bug 1087] [Bug] tcp data len is incorrectly calculated in gro_tcp4_reassemble function bugzilla
@ 2022-11-10  1:45 82% ` bugzilla
  0 siblings, 0 replies; 200+ results
From: bugzilla @ 2022-11-10  1:45 UTC (permalink / raw)
  To: dev

https://bugs.dpdk.org/show_bug.cgi?id=1087

jinag (853048484@qq.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from jinag (853048484@qq.com) ---
fixed by: 
https://github.com/DPDK/dpdk/commit/b8a55871d5af6f5b8694b1cb5eacbc629734e403
https://github.com/DPDK/dpdk/commit/72f51b097a71fb9bdea13bdd254ff620b34c852e

-- 
You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680
@ 2022-11-13  7:29 82% bugzilla-daemon
  2022-11-14  6:09 82% ` [Bug 216686] " bugzilla-daemon
                   ` (8 more replies)
  0 siblings, 9 replies; 200+ results
From: bugzilla-daemon @ 2022-11-13  7:29 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

            Bug ID: 216686
           Summary: BUG: kernel NULL pointer dereference, address:
                    0000000000000680
           Product: Drivers
           Version: 2.5
    Kernel Version: 6.0.0, 6.0.3, 6.0.8, 6.1-rc3
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: frc.gabriel@gmail.com
        Regression: Yes

Hi, good morning,

I noticed few bluetooth crashes starting with kernel 6.0.0 release.

With 5.19.x I didn't see this oops and bluetooth works ok.

Kernel oops comes pretty randomly and/or takes some time to occur.

I noticed it happens more frequently when returning from suspend or when trying
to reconnect an already paired earphone headset.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021905 (kernel=6.0.0,
firmware-linux=20210818, bios=1.19)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023076 (kernel=6.0.3,
firmware-linux=20221012, bios=1.19)

This kernel oops is also appearing with 6.0.8 and 6.1-rc3 from debian
experimental + firmware-linux=20221012 and lenovo bios=1.21.

Have a nice day,
Gabriel Francisco

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
                   ` (3 preceding siblings ...)
  2022-11-13  7:31 82% ` bugzilla-daemon
@ 2022-11-13  7:30 82% ` bugzilla-daemon
  2022-11-14  6:32 82% ` bugzilla-daemon
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-13  7:30 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #1 from frc.gabriel@gmail.com ---
Created attachment 303162
  --> https://bugzilla.kernel.org/attachment.cgi?id=303162&action=edit
6.1-rc3 oops

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
  2022-11-14  6:09 82% ` [Bug 216686] " bugzilla-daemon
@ 2022-11-13  7:31 82% ` bugzilla-daemon
  2022-11-14  5:39 82% ` bugzilla-daemon
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-13  7:31 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #2 from frc.gabriel@gmail.com ---
Created attachment 303163
  --> https://bugzilla.kernel.org/attachment.cgi?id=303163&action=edit
6.0.8 oops

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
                   ` (2 preceding siblings ...)
  2022-11-14  5:39 82% ` bugzilla-daemon
@ 2022-11-13  7:31 82% ` bugzilla-daemon
  2022-11-13  7:30 82% ` bugzilla-daemon
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-13  7:31 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #3 from frc.gabriel@gmail.com ---
Created attachment 303164
  --> https://bugzilla.kernel.org/attachment.cgi?id=303164&action=edit
opcode failed

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
                   ` (5 preceding siblings ...)
  2022-11-14  6:32 82% ` bugzilla-daemon
@ 2022-11-13  8:44 82% ` bugzilla-daemon
  2022-11-14  5:45 82% ` bugzilla-daemon
  2022-11-14  5:40 82% ` bugzilla-daemon
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-13  8:44 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #4 from frc.gabriel@gmail.com ---
Created attachment 303165
  --> https://bugzilla.kernel.org/attachment.cgi?id=303165&action=edit
suspend after oops

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
  2022-11-14  6:09 82% ` [Bug 216686] " bugzilla-daemon
  2022-11-13  7:31 82% ` bugzilla-daemon
@ 2022-11-14  5:39 82% ` bugzilla-daemon
  2022-11-13  7:31 82% ` bugzilla-daemon
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-14  5:39 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #9 from frc.gabriel@gmail.com ---
Created attachment 303169
  --> https://bugzilla.kernel.org/attachment.cgi?id=303169&action=edit
kernel messages from kern.log

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
                   ` (7 preceding siblings ...)
  2022-11-14  5:45 82% ` bugzilla-daemon
@ 2022-11-14  5:40 82% ` bugzilla-daemon
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-14  5:40 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #10 from frc.gabriel@gmail.com ---
Created attachment 303170
  --> https://bugzilla.kernel.org/attachment.cgi?id=303170&action=edit
btmon file when the computer crashed running kernel from bluetooth-next

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
                   ` (6 preceding siblings ...)
  2022-11-13  8:44 82% ` bugzilla-daemon
@ 2022-11-14  5:45 82% ` bugzilla-daemon
  2022-11-14  5:40 82% ` bugzilla-daemon
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-14  5:45 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #11 from frc.gabriel@gmail.com ---
Hi, these two attachments are when running the kernel from
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
(bluetooth-next branch).

I will try master branch.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
@ 2022-11-14  6:09 82% ` bugzilla-daemon
  2022-11-13  7:31 82% ` bugzilla-daemon
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-14  6:09 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #13 from frc.gabriel@gmail.com ---
Created attachment 303172
  --> https://bugzilla.kernel.org/attachment.cgi?id=303172&action=edit
btmon file when the computer crashed running kernel from bluetooth-next master
branch HEAD

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216686] BUG: kernel NULL pointer dereference, address: 0000000000000680
  2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
                   ` (4 preceding siblings ...)
  2022-11-13  7:30 82% ` bugzilla-daemon
@ 2022-11-14  6:32 82% ` bugzilla-daemon
  2022-11-13  8:44 82% ` bugzilla-daemon
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-14  6:32 UTC (permalink / raw)
  To: linux-bluetooth

https://bugzilla.kernel.org/show_bug.cgi?id=216686

--- Comment #14 from frc.gabriel@gmail.com ---
I noticed these messages after a some minutes:

```
[  350.120656] note: kworker/u33:1[860] exited with preempt_count 1
[ 1873.559221] wlp3s0: deauthenticating from e4:bf:fa:cc:15:70 by local choice
(Reason: 3=DEAUTH_LEAVING)
[ 1877.096203] PM: suspend entry (deep)
[ 1877.106898] Filesystems sync: 0.010 seconds
[ 1879.113564] Bluetooth: hci0: Opcode 0x c1a failed: -110
[ 1881.129302] Bluetooth: hci0: Opcode 0x2042 failed: -110
[ 1881.129327] Bluetooth: hci0: Unable to disable scanning: -110
[ 1883.145290] Bluetooth: hci0: Opcode 0x 406 failed: -110
[ 1885.161292] Bluetooth: hci0: Opcode 0x c01 failed: -110
[ 1887.177319] Bluetooth: hci0: Opcode 0x2042 failed: -110
[ 1887.177330] Bluetooth: hci0: Unable to disable scanning: -110
[ 1887.177335] Bluetooth: hci0: disable scanning failed: -110
[ 1887.177337] Bluetooth: hci0: start background scanning failed: -110
```

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216713] BUG: Bad page map in process init  pte:c0ab684c pmd:01182000 (on a PowerMac G4 DP)
  @ 2022-11-20 20:37 82% ` bugzilla-daemon
  2022-11-30 21:49 82% ` bugzilla-daemon
  1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-20 20:37 UTC (permalink / raw)
  To: linuxppc-dev

https://bugzilla.kernel.org/show_bug.cgi?id=216713

--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 303244
  --> https://bugzilla.kernel.org/attachment.cgi?id=303244&action=edit
kernel .config (6.0.9, PowerMac G4 DP)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216713] BUG: Bad page map in process init  pte:c0ab684c pmd:01182000 (on a PowerMac G4 DP)
    2022-11-20 20:37 82% ` [Bug 216713] " bugzilla-daemon
@ 2022-11-30 21:49 82% ` bugzilla-daemon
  1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-11-30 21:49 UTC (permalink / raw)
  To: linuxppc-dev

https://bugzilla.kernel.org/show_bug.cgi?id=216713

Erhard F. (erhard_f@mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
Moved to linux-mm.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: FOUND BUG WITH TITLE: <kernel BUG in ext4_getblk>
       [not found]     <AOsAKwAOFVqmSoeI4YmdXKoQ.1.1669897562230.Hmail.3014218099@tju.edu.cn>
@ 2022-12-01 18:46 82% ` Eric Biggers
  0 siblings, 0 replies; 200+ results
From: Eric Biggers @ 2022-12-01 18:46 UTC (permalink / raw)
  To: Haichi Wang; +Cc: tytso, adilger.kernel, linux-ext4, linux-kernel, syzkaller

On Thu, Dec 01, 2022 at 08:26:02PM +0800, Haichi Wang wrote:
> Kernel Version: 64570fbc14f8d7cb3fe3995f20e26bc25ce4b3cc(v5.15-rc6)

Please test the latest kernel version.

- Eric

^ permalink raw reply	[relevance 82%]

* Re: [BUG REPORT] kernel BUG in ext4_write_inline_data_end or ext4_writepages
  @ 2022-12-07  6:39 82%   ` yebin (H)
  0 siblings, 0 replies; 200+ results
From: yebin (H) @ 2022-12-07  6:39 UTC (permalink / raw)
  To: Jun Nie, harshadshirwadkar, tytso, adilger.kernel, linux-ext4,
	Linux Kernel Mailing List, Ye Bin
  Cc: Lee Jones



On 2022/12/5 16:54, Jun Nie wrote:
> Hi,
> syzbot find a new bug[1] in ext4 that's similar with bug[0], that
> leads to reboot.
> While the bug[0] can be fixed with patch[2] from Bin. This new bug is still
> triggered with the patch[2], and log[3] is collected. Both log[1] and
> log[3] are
> collected when testing bug[4] on the mainline.
>
> [0] https://syzkaller.appspot.com/bug?id=5bafe4554067100b70f58a81268aa06ea3f9c345
> [1] https://syzkaller.appspot.com/text?tag=CrashLog&x=16325fc3880000
> [2] https://lore.kernel.org/lkml/CABymUCN+NSzkunRqFs8LgqjT6vXz-gyyZYn0hQWf8V9kmcO0Hw@mail.gmail.com/T/
> [3] https://syzkaller.appspot.com/text?tag=CrashLog&x=155abe7b880000
> [4] https://syzkaller.appspot.com/bug?id=899b37f20ce4072bcdfecfe1647b39602e956e36
>
>
> [   38.932317][  T494] Call Trace:
> [   38.935437][  T494]  <TASK>
> [   38.938393][  T494]  ext4_write_inline_data_end+0xa39/0xdf0
> [   38.943946][  T494]  ? put_page+0xa0/0xa0
> [   38.947936][  T494]  ? ext4_da_write_begin+0x6f0/0x8d0
> [   38.953055][  T494]  ? pipe_zero+0x240/0x240
> [   38.957308][  T494]  ext4_da_write_end+0x1e2/0x950
> [   38.962082][  T494]  ? ext4_da_write_begin+0x8d0/0x8d0
> [   38.967204][  T494]  generic_perform_write+0x401/0x5f0
> [   38.972326][  T494]  ? generic_file_direct_write+0x6c0/0x6c0
> [   38.977994][  T494]  ? generic_write_checks_count+0x4b0/0x4b0
> [   38.983694][  T494]  ext4_buffered_write_iter+0x35f/0x640
> [   38.989074][  T494]  ext4_file_write_iter+0x198/0x1cd0
> [   38.994194][  T494]  ? futex_unqueue+0x156/0x180
> [   38.998795][  T494]  ? futex_wait+0x4c5/0x5c0
> [   39.003307][  T494]  ? futex_wait_setup+0x320/0x320
> [   39.008168][  T494]  ? avc_policy_seqno+0x1b/0x70
> [   39.012862][  T494]  ? ext4_file_read_iter+0x470/0x470
> [   39.017976][  T494]  vfs_write+0x8b5/0xef0
> [   39.022056][  T494]  ? file_end_write+0x1b0/0x1b0
> [   39.026739][  T494]  ? mutex_lock+0xb6/0x130
> [   39.030994][  T494]  ? bit_wait_io_timeout+0x110/0x110
> [   39.036117][  T494]  ? __fget_files+0x2d9/0x330
> [   39.040630][  T494]  ? __fdget_pos+0x268/0x300
> [   39.045054][  T494]  ? ksys_write+0x77/0x2c0
> [   39.049307][  T494]  ksys_write+0x198/0x2c0
> [   39.053472][  T494]  ? save_fpregs_to_fpstate+0x210/0x210
> [   39.058855][  T494]  ? __ia32_sys_read+0x90/0x90
> [   39.063465][  T494]  ? __kasan_check_write+0x14/0x20
> [   39.068403][  T494]  ? switch_fpu_return+0x129/0x270
> [   39.073348][  T494]  __x64_sys_write+0x7b/0x90
> [   39.077783][  T494]  do_syscall_64+0x2f/0x50
> [   39.082030][  T494]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> Regards,
> Jun
> .

I analyze that the above issue should be caused by the concurrency
of inline data conversion and buffer write.
At present, I haven't thought of any good solution.



^ permalink raw reply	[relevance 82%]

* [Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
                     ` (2 preceding siblings ...)
  2022-12-12  7:30 82% ` bugzilla-daemon
@ 2022-12-11 13:19 82% ` bugzilla-daemon
    3 siblings, 1 reply; 200+ results
From: bugzilla-daemon @ 2022-12-11 13:19 UTC (permalink / raw)
  To: linuxppc-dev

https://bugzilla.kernel.org/show_bug.cgi?id=214913

--- Comment #7 from Zorro Lang (zlang@redhat.com) ---
(In reply to Michael Ellerman from comment #5)
> Sorry I don't have any idea which commit could have fixed this.
> 
> The process that crashed was "fsstress", do you know if it uses io_uring?

Yes, fsstress has io_uring read/write operations. And from the kernel .config
file(as attachment), the CONFIG_IO_URING=y

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
  @ 2022-12-12  5:57 82% ` bugzilla-daemon
  2022-12-12  7:19 82%   ` Nicholas Piggin
  2022-12-12  7:19 82% ` bugzilla-daemon
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 200+ results
From: bugzilla-daemon @ 2022-12-12  5:57 UTC (permalink / raw)
  To: linuxppc-dev

https://bugzilla.kernel.org/show_bug.cgi?id=214913

--- Comment #9 from Michael Ellerman (michael@ellerman.id.au) ---
I assume it's an io_uring IO worker.

They're created via create_io_worker() -> create_io_thread().

They pass a non-NULL `args->fn` to copy_process() -> copy_thread(), so we end
up in the "kernel thread" branch of the if, which sets p->thread.regs = NULL.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
  2022-12-12  5:57 82% ` [Bug 214913] " bugzilla-daemon
@ 2022-12-12  7:19 82%   ` Nicholas Piggin
  0 siblings, 0 replies; 200+ results
From: Nicholas Piggin @ 2022-12-12  7:19 UTC (permalink / raw)
  To: bugzilla-daemon, linuxppc-dev; +Cc: Eric Biederman

On Mon Dec 12, 2022 at 3:57 PM AEST,  wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=214913
>
> --- Comment #9 from Michael Ellerman (michael@ellerman.id.au) ---
> I assume it's an io_uring IO worker.
>
> They're created via create_io_worker() -> create_io_thread().
>
> They pass a non-NULL `args->fn` to copy_process() -> copy_thread(), so we end
> up in the "kernel thread" branch of the if, which sets p->thread.regs = NULL.

Hmm, you might be right. These things are created with the memory and
thread  / signal context shared with the userspace process.

Still doesn't seem like they should be involved in core dumping though,
pt_regs would have no meaning even if we did set something there. How
best to catch these and filter them out of the core dump? Check for
PF_IO_WORKER in the coredump gathering?

Thanks,
Nick

^ permalink raw reply	[relevance 82%]

* [Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
    2022-12-12  5:57 82% ` [Bug 214913] " bugzilla-daemon
@ 2022-12-12  7:19 82% ` bugzilla-daemon
  2022-12-12  7:30 82% ` bugzilla-daemon
  2022-12-11 13:19 82% ` bugzilla-daemon
  3 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-12-12  7:19 UTC (permalink / raw)
  To: linuxppc-dev

https://bugzilla.kernel.org/show_bug.cgi?id=214913

--- Comment #10 from npiggin@gmail.com ---
On Mon Dec 12, 2022 at 3:57 PM AEST,  wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=214913
>
> --- Comment #9 from Michael Ellerman (michael@ellerman.id.au) ---
> I assume it's an io_uring IO worker.
>
> They're created via create_io_worker() -> create_io_thread().
>
> They pass a non-NULL `args->fn` to copy_process() -> copy_thread(), so we end
> up in the "kernel thread" branch of the if, which sets p->thread.regs = NULL.

Hmm, you might be right. These things are created with the memory and
thread  / signal context shared with the userspace process.

Still doesn't seem like they should be involved in core dumping though,
pt_regs would have no meaning even if we did set something there. How
best to catch these and filter them out of the core dump? Check for
PF_IO_WORKER in the coredump gathering?

Thanks,
Nick

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
    2022-12-12  5:57 82% ` [Bug 214913] " bugzilla-daemon
  2022-12-12  7:19 82% ` bugzilla-daemon
@ 2022-12-12  7:30 82% ` bugzilla-daemon
  2022-12-11 13:19 82% ` bugzilla-daemon
  3 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2022-12-12  7:30 UTC (permalink / raw)
  To: linuxppc-dev

https://bugzilla.kernel.org/show_bug.cgi?id=214913

--- Comment #11 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
Le 12/12/2022 à 04:52, Nicholas Piggin a écrit :
> On Sun Dec 11, 2022 at 11:19 PM AEST,  wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=214913
>>
>> --- Comment #7 from Zorro Lang (zlang@redhat.com) ---
>> (In reply to Michael Ellerman from comment #5)
>>> Sorry I don't have any idea which commit could have fixed this.
>>>
>>> The process that crashed was "fsstress", do you know if it uses io_uring?
>>
>> Yes, fsstress has io_uring read/write operations. And from the kernel
>> .config
>> file(as attachment), the CONFIG_IO_URING=y
> 
> The task being dumped seems like it's lost its task->thread.regs. The
> NULL pointer is here:
> 
> int tm_cgpr_active(struct task_struct *target, const struct user_regset
> *regset)
> {
>          if (!cpu_has_feature(CPU_FTR_TM))
>                  return -ENODEV;
> 
>          if (!MSR_TM_ACTIVE(target->thread.regs->msr))
>                  return 0;
> 
>          return regset->n;
> }
> 
> On that regs->msr deref. r9 contains the regs pointer.
> 
> The kernel attempt to read user page - exploit attempt? message is
> I think a red herring it's coming up because of the NULL deref I
> think (I thought we fixed that).
> 

No we didn't fix that, my patch was rejected see 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/8b865b93d25c15c8e6d41e71c368bfc28da4489d.1606816701.git.christophe.leroy@csgroup.eu/

The reason for the rejection was:

   The first page can be mapped if mmap_min_addr is 0.

   Blocking all faults to the first page would potentially break any
   program that does that.

   Also if there is something mapped at 0 it's a good chance it is an
   exploit attempt :)



Christophe

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
  @ 2022-12-12  7:30 82%     ` Christophe Leroy
  0 siblings, 0 replies; 200+ results
From: Christophe Leroy @ 2022-12-12  7:30 UTC (permalink / raw)
  To: Nicholas Piggin, bugzilla-daemon@kernel.org,
	linuxppc-dev@lists.ozlabs.org



Le 12/12/2022 à 04:52, Nicholas Piggin a écrit :
> On Sun Dec 11, 2022 at 11:19 PM AEST,  wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=214913
>>
>> --- Comment #7 from Zorro Lang (zlang@redhat.com) ---
>> (In reply to Michael Ellerman from comment #5)
>>> Sorry I don't have any idea which commit could have fixed this.
>>>
>>> The process that crashed was "fsstress", do you know if it uses io_uring?
>>
>> Yes, fsstress has io_uring read/write operations. And from the kernel .config
>> file(as attachment), the CONFIG_IO_URING=y
> 
> The task being dumped seems like it's lost its task->thread.regs. The
> NULL pointer is here:
> 
> int tm_cgpr_active(struct task_struct *target, const struct user_regset *regset)
> {
>          if (!cpu_has_feature(CPU_FTR_TM))
>                  return -ENODEV;
> 
>          if (!MSR_TM_ACTIVE(target->thread.regs->msr))
>                  return 0;
> 
>          return regset->n;
> }
> 
> On that regs->msr deref. r9 contains the regs pointer.
> 
> The kernel attempt to read user page - exploit attempt? message is
> I think a red herring it's coming up because of the NULL deref I
> think (I thought we fixed that).
> 

No we didn't fix that, my patch was rejected see 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/8b865b93d25c15c8e6d41e71c368bfc28da4489d.1606816701.git.christophe.leroy@csgroup.eu/

The reason for the rejection was:

   The first page can be mapped if mmap_min_addr is 0.

   Blocking all faults to the first page would potentially break any
   program that does that.

   Also if there is something mapped at 0 it's a good chance it is an
   exploit attempt :)



Christophe

^ permalink raw reply	[relevance 82%]

* Re: [BUG] gropdf, tbl: Completely broken table (was: Ping^1: Chapters of the manual (was: Bug#1018737: ...))
    2022-12-18 11:46 82%     ` Alejandro Colomar
@ 2022-12-17 21:26 82%     ` Deri
  2022-12-18 11:25 82%       ` Alejandro Colomar
  1 sibling, 1 reply; 200+ results
From: Deri @ 2022-12-17 21:26 UTC (permalink / raw)
  To: Alejandro Colomar, G. Branden Robinson; +Cc: groff, linux-man

On Saturday, 17 December 2022 16:08:30 GMT G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2022-12-17T14:19:55+0100, Alejandro Colomar wrote:
> > Another bug report (but not about the script; this seems to be about
> > tbl(1) interaction with gropdf(1), I guess):
> > 
> > <http://chuzzlewit.co.uk/LinuxManBook.pdf#pdf%3Abm11813>
> 
> The suffixes(7) page, which I've managed to never see in 25 years as a
> GNU/Linux user!  Ah, well.
> 
> Dude, I'm friggin' _trying_ to get groff ready for 1.23.0.rc2 and you
> nerd-snipe me with this huge list of things that hasn't been updated in
> twenty years and has all kinds of fiddly little things wrong with it--
> this of course constitutes an OCD emergency for me!

Hi Alex,

This is a bug in my perl script which assembles the Linux Manpage Book, 
nothing to do with groff, tbl or gropdf, just a bad habit I have of scrubbing 
leading spaces before parsing a line, normally fine, but disastrous when the 
space is intended to protect a full stop being the first character.

For this reason, if you find issues with the book it probably is not relevent 
to the groff list, since it is more likely to be an issue with code which is 
just a few hours old. Any faults, or changes you would like, please send to 
me, since it is not relevent to the groff list.

Cheers 

Deri




^ permalink raw reply	[relevance 82%]

* Re: [BUG] gropdf, tbl: Completely broken table (was: Ping^1: Chapters of the manual (was: Bug#1018737: ...))
  2022-12-17 21:26 82%     ` Deri
@ 2022-12-18 11:25 82%       ` Alejandro Colomar
  0 siblings, 0 replies; 200+ results
From: Alejandro Colomar @ 2022-12-18 11:25 UTC (permalink / raw)
  To: Deri, G. Branden Robinson; +Cc: groff, linux-man


[-- Attachment #1.1: Type: text/plain, Size: 993 bytes --]

Hi Deri,

On 12/17/22 22:26, Deri wrote:
> Hi Alex,
> 
> This is a bug in my perl script which assembles the Linux Manpage Book,
> nothing to do with groff, tbl or gropdf, just a bad habit I have of scrubbing
> leading spaces before parsing a line, normally fine, but disastrous when the
> space is intended to protect a full stop being the first character.

Ahh, makes sense.

I thought it could be a bug in groff, since I had seen the same issue last year, 
I think with grohtml (but I'm talking from memory).  Maybe Branden remembers.

> 
> For this reason, if you find issues with the book it probably is not relevent
> to the groff list, since it is more likely to be an issue with code which is
> just a few hours old. Any faults, or changes you would like, please send to
> me, since it is not relevent to the groff list.

Understood!

I'm impatient to see that script :)

Cheers,

Alex

> 
> Cheers
> 
> Deri

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: [BUG] gropdf, tbl: Completely broken table (was: Ping^1: Chapters of the manual (was: Bug#1018737: ...))
  @ 2022-12-18 11:46 82%     ` Alejandro Colomar
  2022-12-17 21:26 82%     ` Deri
  1 sibling, 0 replies; 200+ results
From: Alejandro Colomar @ 2022-12-18 11:46 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: Deri, groff, linux-man


[-- Attachment #1.1: Type: text/plain, Size: 5051 bytes --]

Hi Branden,

On 12/17/22 17:08, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2022-12-17T14:19:55+0100, Alejandro Colomar wrote:
>> Another bug report (but not about the script; this seems to be about
>> tbl(1) interaction with gropdf(1), I guess):
>>
>> <http://chuzzlewit.co.uk/LinuxManBook.pdf#pdf%3Abm11813>
> 
> The suffixes(7) page, which I've managed to never see in 25 years as a
> GNU/Linux user!  Ah, well.
> 
> Dude, I'm friggin' _trying_ to get groff ready for 1.23.0.rc2 and you
> nerd-snipe me with this huge list of things that hasn't been updated in
> twenty years and has all kinds of fiddly little things wrong with it--
> this of course constitutes an OCD emergency for me!
> 
> https://xkcd.com/356/

:D

BTW, how is the status of 1.23.0?  How many RC bugs are there?  Are they growing 
faster than they are eaten by birds?  :P

> 
>> Running all the linters I know doesn't trigger any warnings on the
>> page source:
> 
> That tbl(1) source isn't invalid but it is pretty weird.
> 
> I tend to agree that there is a gropdf(1) bug here, as grops(1) handles
> the same input fine.  But Deri is the real expert and I will let him
> speak to that.
> 
> I'm attaching a patch that does three things:
> 
> 1. Removes the hack to shut up warnings from grotty(1).  This was indeed
>     a bug, it's been around forever (possibly since ~1990), and it is
>     fixed in groff Git.  Expect that in 1.23.0.  man-db man(1) conceals
>     these diagnostic messages anyway.
> 
>     https://savannah.gnu.org/bugs/index.php?63449
> 
> 2. Stops using leading spaces in table entries.  This is a kind of weird
>     thing to do.  The likely reason is that the table author(s) had a ton
>     of entries that started with dots (the *roff control character) and
>     didn't know to prefix them with the *roff dummy character (`\&`) to
>     keep them from being interpreted as requests or macro calls.  The
>     tbl(1) page in groff 1.23.0 explicitly documents this use (the old
>     one seems to have expected the reader to have access to CSTR #49 by
>     Lesk).
> 
>      Rows of table entries can be interleaved with groff control lines;
>      these do not count as table data.  On such lines the default control
>      character (.) must be used (and not changed); the no‐break control
>      character is not recognized.  To start the first table entry in a
>      row with a dot, precede it with the token \&.
> 
> 3. I added the dummy character even on "continuation" lines where a
>     description overran.  This does no damage since the tab character
>     remains there as an entry separator and the dummy character by itself
>     is harmless as a marker of an empty table entry.  I even recommend
>     this in the GNU tbl 1.23.0 man page; it's much nicer for people whose



>     text editors don't visibly highlight tabs.

BTW, I've seen in groff really bad cases of broken indentation where some lines 
use tabs, others use spaces, and others use a mix.  What's the coding style 
regarding tabs in groff source code?  I want to know in case I send a patch some 
day.

> 
> A _more_ idiomatic thing to do would be to use a spanning table
> entry `\^` for rows where the description get continued, but that makes
> no practical difference for a simple table layout like this one.
> 
> More idiomatic still, and well worth considering for the future, is
> setting _all_ of these descriptions in text blocks.  This table looks to
> me like it was laid out for an 80-column terminal with the excessively
> long descriptions manually broken.  This looks suboptimal when typeset
> and will look ridiculous on a wide terminal.

Yep.  Probably I'll do that; but (probably) not soon.

> 
> Also, use of a text block enables the employment of man(7) macros
> instead of font selection escape sequences to change the typeface, and,
> importantly for the near Linux man-pages future, use of the new `MR`
> macro to cross reference the many pages referred to in these
> descriptions.
> 
> I didn't pursue further revision along either of these lines because the
> as I look at these the entries, the intensity of my urge to do a
> top-to-bottom revision fixing the many infelicities and a few outright
> errors increases exponentially with time.  There is even at least one
> unescaped hyphen!  🤯 >
> Regrettably, if a moderately experienced GNU/Linux user has gone 25
> years without seeing this page, likely many others will go 25 more
> without seeing it.  A good intro(1) page would cross reference it,
> aiding the novice.

But if the intro(*) page references _everything_, then it would be a huge page 
(there are thousands of pages in the Linux man-pages).  Although, in the PDF, 
I'd like to have an index.  That might help.

> 
> Unofficial patch attached.

Do you like the patch?  Should I apply it, or is it just a draft?

> 
> Regards,
> Branden

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: [bug report]BUG: KFENCE: use-after-free read in bfq_exit_icq_bfqq+0x132/0x270
  @ 2022-12-19 17:52 82% ` Jens Axboe
  2022-12-22 14:49 82%   ` Jan Kara
  0 siblings, 1 reply; 200+ results
From: Jens Axboe @ 2022-12-19 17:52 UTC (permalink / raw)
  To: Yi Zhang, linux-block; +Cc: Paolo Valente, Jan Kara

On 12/19/22 12:16 AM, Yi Zhang wrote:
> Hello
> Below issue was triggered during blktests nvme-tcp with for-next
> (6.1.0, block, 2280cbf6), pls help check it
> 
> [  782.395936] run blktests nvme/013 at 2022-12-18 07:32:09
> [  782.425739] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
> [  782.435780] nvmet_tcp: enabling port 0 (127.0.0.1:4420)
> [  782.446357] nvmet: creating nvm controller 1 for subsystem
> blktests-subsystem-1 for NQN
> nqn.2014-08.org.nvmexpress:uuid:4c4c4544-0042-3910-8039-c6c04f544833.
> [  782.460744] nvme nvme0: creating 32 I/O queues.
> [  782.466760] nvme nvme0: mapped 32/0/0 default/read/poll queues.
> [  782.479615] nvme nvme0: new ctrl: NQN "blktests-subsystem-1", addr
> 127.0.0.1:4420
> [  783.612793] XFS (nvme0n1): Mounting V5 Filesystem
> [  783.650705] XFS (nvme0n1): Ending clean mount
> [  799.653271] ==================================================================
> [  799.660496] BUG: KFENCE: use-after-free read in bfq_exit_icq_bfqq+0x132/0x270
> [  799.669117] Use-after-free read at 0x000000008c692c21 (in kfence-#11):
> [  799.675647]  bfq_exit_icq_bfqq+0x132/0x270
> [  799.679753]  bfq_exit_icq+0x5b/0x80
> [  799.683255]  exit_io_context+0x81/0xb0
> [  799.687015]  do_exit+0x74b/0xaf0
> [  799.690256]  kthread_exit+0x25/0x30
> [  799.693758]  kthread+0xc8/0x110
> [  799.696904]  ret_from_fork+0x1f/0x30
> [  799.701991] kfence-#11: 0x00000000f1839eaa-0x0000000011c747a1,
> size=568, cache=bfq_queue
> [  799.711549] allocated by task 19533 on cpu 9 at 499.180335s:
> [  799.717218]  bfq_get_queue+0xe0/0x530
> [  799.720884]  bfq_get_bfqq_handle_split+0x75/0x120
> [  799.725592]  bfq_insert_requests+0x1d15/0x2710
> [  799.730045]  blk_mq_sched_insert_requests+0x5c/0x170
> [  799.735021]  blk_mq_flush_plug_list+0x115/0x2e0
> [  799.739551]  __blk_flush_plug+0xf2/0x130
> [  799.743479]  blk_finish_plug+0x25/0x40
> [  799.747231]  __iomap_dio_rw+0x520/0x7b0
> [  799.751070]  btrfs_dio_write+0x42/0x50
> [  799.754832]  btrfs_do_write_iter+0x2f4/0x5d0
> [  799.759112]  nvmet_file_submit_bvec+0xa6/0xe0 [nvmet]
> [  799.764193]  nvmet_file_execute_io+0x1a4/0x250 [nvmet]
> [  799.769349]  process_one_work+0x1c4/0x380
> [  799.773361]  worker_thread+0x4d/0x380
> [  799.777028]  kthread+0xe6/0x110
> [  799.780174]  ret_from_fork+0x1f/0x30
> [  799.785252] freed by task 19533 on cpu 9 at 799.653250s:
> [  799.790584]  bfq_put_queue+0x183/0x2c0
> [  799.794344]  bfq_exit_icq_bfqq+0x129/0x270
> [  799.798442]  bfq_exit_icq+0x5b/0x80
> [  799.801934]  exit_io_context+0x81/0xb0
> [  799.805687]  do_exit+0x74b/0xaf0
> [  799.808920]  kthread_exit+0x25/0x30
> [  799.812413]  kthread+0xc8/0x110
> [  799.815561]  ret_from_fork+0x1f/0x30
> [  799.820648] CPU: 9 PID: 19533 Comm: kworker/dying Not tainted 6.1.0 #1
> [  799.827181] Hardware name: Dell Inc. PowerEdge R640/0X45NX, BIOS
> 2.15.1 06/15/2022
> [  799.834746] ==================================================================
> [  823.081364] XFS (nvme0n1): Unmounting Filesystem
> [  823.159994] nvme nvme0: Removing ctrl: NQN "blktests-subsystem-1"

Please CC maintainers on stuff like this (added).

-- 
Jens Axboe



^ permalink raw reply	[relevance 82%]

* Re: [bug report]BUG: KFENCE: use-after-free read in bfq_exit_icq_bfqq+0x132/0x270
  2022-12-19 17:52 82% ` Jens Axboe
@ 2022-12-22 14:49 82%   ` Jan Kara
  2022-12-26  1:17 82%     ` Yu Kuai
  0 siblings, 1 reply; 200+ results
From: Jan Kara @ 2022-12-22 14:49 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Yi Zhang, linux-block, Paolo Valente, Jan Kara, yukuai3

Thanks for report and the CC!

On Mon 19-12-22 10:52:57, Jens Axboe wrote:
> On 12/19/22 12:16 AM, Yi Zhang wrote:
> > Below issue was triggered during blktests nvme-tcp with for-next
> > (6.1.0, block, 2280cbf6), pls help check it
> > 
> > [  782.395936] run blktests nvme/013 at 2022-12-18 07:32:09
> > [  782.425739] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
> > [  782.435780] nvmet_tcp: enabling port 0 (127.0.0.1:4420)
> > [  782.446357] nvmet: creating nvm controller 1 for subsystem
> > blktests-subsystem-1 for NQN
> > nqn.2014-08.org.nvmexpress:uuid:4c4c4544-0042-3910-8039-c6c04f544833.
> > [  782.460744] nvme nvme0: creating 32 I/O queues.
> > [  782.466760] nvme nvme0: mapped 32/0/0 default/read/poll queues.
> > [  782.479615] nvme nvme0: new ctrl: NQN "blktests-subsystem-1", addr
> > 127.0.0.1:4420
> > [  783.612793] XFS (nvme0n1): Mounting V5 Filesystem
> > [  783.650705] XFS (nvme0n1): Ending clean mount
> > [  799.653271] ==================================================================
> > [  799.660496] BUG: KFENCE: use-after-free read in bfq_exit_icq_bfqq+0x132/0x270
> > [  799.669117] Use-after-free read at 0x000000008c692c21 (in kfence-#11):
> > [  799.675647]  bfq_exit_icq_bfqq+0x132/0x270
> > [  799.679753]  bfq_exit_icq+0x5b/0x80
> > [  799.683255]  exit_io_context+0x81/0xb0
> > [  799.687015]  do_exit+0x74b/0xaf0
> > [  799.690256]  kthread_exit+0x25/0x30
> > [  799.693758]  kthread+0xc8/0x110
> > [  799.696904]  ret_from_fork+0x1f/0x30
> > [  799.701991] kfence-#11: 0x00000000f1839eaa-0x0000000011c747a1,
> > size=568, cache=bfq_queue
> > [  799.711549] allocated by task 19533 on cpu 9 at 499.180335s:
> > [  799.717218]  bfq_get_queue+0xe0/0x530
> > [  799.720884]  bfq_get_bfqq_handle_split+0x75/0x120
> > [  799.725592]  bfq_insert_requests+0x1d15/0x2710
> > [  799.730045]  blk_mq_sched_insert_requests+0x5c/0x170
> > [  799.735021]  blk_mq_flush_plug_list+0x115/0x2e0
> > [  799.739551]  __blk_flush_plug+0xf2/0x130
> > [  799.743479]  blk_finish_plug+0x25/0x40
> > [  799.747231]  __iomap_dio_rw+0x520/0x7b0
> > [  799.751070]  btrfs_dio_write+0x42/0x50
> > [  799.754832]  btrfs_do_write_iter+0x2f4/0x5d0
> > [  799.759112]  nvmet_file_submit_bvec+0xa6/0xe0 [nvmet]
> > [  799.764193]  nvmet_file_execute_io+0x1a4/0x250 [nvmet]
> > [  799.769349]  process_one_work+0x1c4/0x380
> > [  799.773361]  worker_thread+0x4d/0x380
> > [  799.777028]  kthread+0xe6/0x110
> > [  799.780174]  ret_from_fork+0x1f/0x30
> > [  799.785252] freed by task 19533 on cpu 9 at 799.653250s:
> > [  799.790584]  bfq_put_queue+0x183/0x2c0
> > [  799.794344]  bfq_exit_icq_bfqq+0x129/0x270
> > [  799.798442]  bfq_exit_icq+0x5b/0x80
> > [  799.801934]  exit_io_context+0x81/0xb0
> > [  799.805687]  do_exit+0x74b/0xaf0
> > [  799.808920]  kthread_exit+0x25/0x30
> > [  799.812413]  kthread+0xc8/0x110
> > [  799.815561]  ret_from_fork+0x1f/0x30
> > [  799.820648] CPU: 9 PID: 19533 Comm: kworker/dying Not tainted 6.1.0 #1
> > [  799.827181] Hardware name: Dell Inc. PowerEdge R640/0X45NX, BIOS
> > 2.15.1 06/15/2022
> > [  799.834746] ==================================================================
> > [  823.081364] XFS (nvme0n1): Unmounting Filesystem
> > [  823.159994] nvme nvme0: Removing ctrl: NQN "blktests-subsystem-1"

Can you use addr2line to find which dereference is exactly causing the
problem? Hum, it seems to point to some strange issue because we've just
freed bfqq in this exit_io_context() invocation and seeing you are testing
linux-block tree I think the problem might be caused by 64dc8c732f5c
("block, bfq: fix possible uaf for 'bfqq->bic'"). Kuai, I think we've
messed up bfq_exit_icq_bfqq() and now bic_set_bfqq() can access already
freed 'old_bfqq'. So we need something like:


                spin_lock_irqsave(&bfqd->lock, flags);
                bfqq->bic = NULL;
-               bfq_exit_bfqq(bfqd, bfqq);
                bic_set_bfqq(bic, NULL, is_sync);
+               bfq_exit_bfqq(bfqd, bfqq);
                spin_unlock_irqrestore(&bfqd->lock, flags);

so free bfqq only after it is removed from the bic...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[relevance 82%]

* Re: [bug report]BUG: KFENCE: use-after-free read in bfq_exit_icq_bfqq+0x132/0x270
  2022-12-22 14:49 82%   ` Jan Kara
@ 2022-12-26  1:17 82%     ` Yu Kuai
  0 siblings, 0 replies; 200+ results
From: Yu Kuai @ 2022-12-26  1:17 UTC (permalink / raw)
  To: Jan Kara, Jens Axboe; +Cc: Yi Zhang, linux-block, Paolo Valente, yukuai (C)

Hi, Jan!

在 2022/12/22 22:49, Jan Kara 写道:
> Thanks for report and the CC!
> 
> On Mon 19-12-22 10:52:57, Jens Axboe wrote:
>> On 12/19/22 12:16 AM, Yi Zhang wrote:
>>> Below issue was triggered during blktests nvme-tcp with for-next
>>> (6.1.0, block, 2280cbf6), pls help check it
>>>
>>> [  782.395936] run blktests nvme/013 at 2022-12-18 07:32:09
>>> [  782.425739] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
>>> [  782.435780] nvmet_tcp: enabling port 0 (127.0.0.1:4420)
>>> [  782.446357] nvmet: creating nvm controller 1 for subsystem
>>> blktests-subsystem-1 for NQN
>>> nqn.2014-08.org.nvmexpress:uuid:4c4c4544-0042-3910-8039-c6c04f544833.
>>> [  782.460744] nvme nvme0: creating 32 I/O queues.
>>> [  782.466760] nvme nvme0: mapped 32/0/0 default/read/poll queues.
>>> [  782.479615] nvme nvme0: new ctrl: NQN "blktests-subsystem-1", addr
>>> 127.0.0.1:4420
>>> [  783.612793] XFS (nvme0n1): Mounting V5 Filesystem
>>> [  783.650705] XFS (nvme0n1): Ending clean mount
>>> [  799.653271] ==================================================================
>>> [  799.660496] BUG: KFENCE: use-after-free read in bfq_exit_icq_bfqq+0x132/0x270
>>> [  799.669117] Use-after-free read at 0x000000008c692c21 (in kfence-#11):
>>> [  799.675647]  bfq_exit_icq_bfqq+0x132/0x270
>>> [  799.679753]  bfq_exit_icq+0x5b/0x80
>>> [  799.683255]  exit_io_context+0x81/0xb0
>>> [  799.687015]  do_exit+0x74b/0xaf0
>>> [  799.690256]  kthread_exit+0x25/0x30
>>> [  799.693758]  kthread+0xc8/0x110
>>> [  799.696904]  ret_from_fork+0x1f/0x30
>>> [  799.701991] kfence-#11: 0x00000000f1839eaa-0x0000000011c747a1,
>>> size=568, cache=bfq_queue
>>> [  799.711549] allocated by task 19533 on cpu 9 at 499.180335s:
>>> [  799.717218]  bfq_get_queue+0xe0/0x530
>>> [  799.720884]  bfq_get_bfqq_handle_split+0x75/0x120
>>> [  799.725592]  bfq_insert_requests+0x1d15/0x2710
>>> [  799.730045]  blk_mq_sched_insert_requests+0x5c/0x170
>>> [  799.735021]  blk_mq_flush_plug_list+0x115/0x2e0
>>> [  799.739551]  __blk_flush_plug+0xf2/0x130
>>> [  799.743479]  blk_finish_plug+0x25/0x40
>>> [  799.747231]  __iomap_dio_rw+0x520/0x7b0
>>> [  799.751070]  btrfs_dio_write+0x42/0x50
>>> [  799.754832]  btrfs_do_write_iter+0x2f4/0x5d0
>>> [  799.759112]  nvmet_file_submit_bvec+0xa6/0xe0 [nvmet]
>>> [  799.764193]  nvmet_file_execute_io+0x1a4/0x250 [nvmet]
>>> [  799.769349]  process_one_work+0x1c4/0x380
>>> [  799.773361]  worker_thread+0x4d/0x380
>>> [  799.777028]  kthread+0xe6/0x110
>>> [  799.780174]  ret_from_fork+0x1f/0x30
>>> [  799.785252] freed by task 19533 on cpu 9 at 799.653250s:
>>> [  799.790584]  bfq_put_queue+0x183/0x2c0
>>> [  799.794344]  bfq_exit_icq_bfqq+0x129/0x270
>>> [  799.798442]  bfq_exit_icq+0x5b/0x80
>>> [  799.801934]  exit_io_context+0x81/0xb0
>>> [  799.805687]  do_exit+0x74b/0xaf0
>>> [  799.808920]  kthread_exit+0x25/0x30
>>> [  799.812413]  kthread+0xc8/0x110
>>> [  799.815561]  ret_from_fork+0x1f/0x30
>>> [  799.820648] CPU: 9 PID: 19533 Comm: kworker/dying Not tainted 6.1.0 #1
>>> [  799.827181] Hardware name: Dell Inc. PowerEdge R640/0X45NX, BIOS
>>> 2.15.1 06/15/2022
>>> [  799.834746] ==================================================================
>>> [  823.081364] XFS (nvme0n1): Unmounting Filesystem
>>> [  823.159994] nvme nvme0: Removing ctrl: NQN "blktests-subsystem-1"
> 
> Can you use addr2line to find which dereference is exactly causing the
> problem? Hum, it seems to point to some strange issue because we've just
> freed bfqq in this exit_io_context() invocation and seeing you are testing
> linux-block tree I think the problem might be caused by 64dc8c732f5c
> ("block, bfq: fix possible uaf for 'bfqq->bic'"). Kuai, I think we've
> messed up bfq_exit_icq_bfqq() and now bic_set_bfqq() can access already
> freed 'old_bfqq'. So we need something like:
> 
> 
>                  spin_lock_irqsave(&bfqd->lock, flags);
>                  bfqq->bic = NULL;
> -               bfq_exit_bfqq(bfqd, bfqq);
>                  bic_set_bfqq(bic, NULL, is_sync);
> +               bfq_exit_bfqq(bfqd, bfqq);
>                  spin_unlock_irqrestore(&bfqd->lock, flags);
> 
> so free bfqq only after it is removed from the bic...

Sorry for the delay, and you're right, that's definitely a problem. 😒

Thanks,
Kuai
> 
> 								Honza
> 


^ permalink raw reply	[relevance 82%]

* [Bug 216871] bug: use after free when journal read failed
  @ 2023-01-01  3:15 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-01  3:15 UTC (permalink / raw)
  To: reiserfs-devel

https://bugzilla.kernel.org/show_bug.cgi?id=216871

eriri (1527030098@qq.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|use after free when journal |bug: use after free when
                   |read failed                 |journal read failed

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Intel-gfx] [cache coherency bug] [hw bug?] i915 and PAT attributes
  @ 2023-01-02  1:58 82%                 ` Marek Marczykowski-Górecki
  0 siblings, 0 replies; 200+ results
From: Marek Marczykowski-Górecki @ 2023-01-02  1:58 UTC (permalink / raw)
  To: Demi Marie Obenour
  Cc: Andrew Cooper, intel-gfx@lists.freedesktop.org,
	the arch/x86 maintainers, Lucas De Marchi, Daniel Vetter,
	Rodrigo Vivi, xen-devel

[-- Attachment #1: Type: text/plain, Size: 7658 bytes --]

On Sun, Jan 01, 2023 at 08:48:13PM -0500, Demi Marie Obenour wrote:
> On Sun, Jan 01, 2023 at 08:17:52PM -0500, Demi Marie Obenour wrote:
> > On Mon, Jan 02, 2023 at 02:00:51AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Sun, Jan 01, 2023 at 07:03:18PM -0500, Demi Marie Obenour wrote:
> > > > On Mon, Jan 02, 2023 at 12:24:54AM +0100, Marek Marczykowski-Górecki wrote:
> > > > > On Thu, Dec 22, 2022 at 10:29:57AM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Dec 16, 2022 at 03:30:13PM +0000, Andrew Cooper wrote:
> > > > > > > On 08/12/2022 1:55 pm, Marek Marczykowski-Górecki wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > There is an issue with i915 on Xen PV (dom0). The end result is a lot of
> > > > > > > > glitches, like here: https://openqa.qubes-os.org/tests/54748#step/startup/8
> > > > > > > > (this one is on ADL, Linux 6.1-rc7 as a Xen PV dom0). It's using Xorg
> > > > > > > > with "modesetting" driver.
> > > > > > > >
> > > > > > > > After some iterations of debugging, we narrowed it down to i915 handling
> > > > > > > > caching. The main difference is that PAT is setup differently on Xen PV
> > > > > > > > than on native Linux. Normally, Linux does have appropriate abstraction
> > > > > > > > for that, but apparently something related to i915 doesn't play well
> > > > > > > > with it. The specific difference is:
> > > > > > > > native linux:
> > > > > > > > x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
> > > > > > > > xen pv:
> > > > > > > > x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC
> > > > > > > >                                   ~~          ~~      ~~  ~~
> > > > > > > >
> > > > > > > > The specific impact depends on kernel version and the hardware. The most
> > > > > > > > severe issues I see on >=ADL, but some older hardware is affected too -
> > > > > > > > sometimes only if composition is disabled in the window manager.
> > > > > > > > Some more information is collected at
> > > > > > > > https://github.com/QubesOS/qubes-issues/issues/4782 (and few linked
> > > > > > > > duplicates...).
> > > > > > > >
> > > > > > > > Kind-of related commit is here:
> > > > > > > > https://github.com/torvalds/linux/commit/bdd8b6c98239cad ("drm/i915:
> > > > > > > > replace X86_FEATURE_PAT with pat_enabled()") - it is the place where
> > > > > > > > i915 explicitly checks for PAT support, so I'm cc-ing people mentioned
> > > > > > > > there too.
> > > > > > > >
> > > > > > > > Any ideas?
> > > > > > > >
> > > > > > > > The issue can be easily reproduced without Xen too, by adjusting PAT in
> > > > > > > > Linux:
> > > > > > > > -----8<-----
> > > > > > > > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> > > > > > > > index 66a209f7eb86..319ab60c8d8c 100644
> > > > > > > > --- a/arch/x86/mm/pat/memtype.c
> > > > > > > > +++ b/arch/x86/mm/pat/memtype.c
> > > > > > > > @@ -400,8 +400,8 @@ void pat_init(void)
> > > > > > > >  		 * The reserved slots are unused, but mapped to their
> > > > > > > >  		 * corresponding types in the presence of PAT errata.
> > > > > > > >  		 */
> > > > > > > > -		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> > > > > > > > -		      PAT(4, WB) | PAT(5, WP) | PAT(6, UC_MINUS) | PAT(7, WT);
> > > > > > > > +		pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
> > > > > > > > +		      PAT(4, WC) | PAT(5, WP) | PAT(6, UC)       | PAT(7, UC);
> > > > > > > >  	}
> > > > > > > >  
> > > > > > > >  	if (!pat_bp_initialized) {
> > > > > > > > -----8<-----
> > > > > > > >
> > > > > > > 
> > > > > > > Hello, can anyone help please?
> > > > > > > 
> > > > > > > Intel's CI has taken this reproducer of the bug, and confirmed the
> > > > > > > regression. 
> > > > > > > https://lore.kernel.org/intel-gfx/Y5Hst0bCxQDTN7lK@mail-itl/T/#m4480c15a0d117dce6210562eb542875e757647fb
> > > > > > > 
> > > > > > > We're reasonably confident that it is an i915 bug (given the repro with
> > > > > > > no Xen in the mix), but we're out of any further ideas.
> > > > > > 
> > > > > > I don't think we have any code that assumes anything about the PAT,
> > > > > > apart from WC being available (which seems like it should still be
> > > > > > the case with your modified PAT). I suppose you'll just have to 
> > > > > > start digging from pgprot_writecombine()/noncached() and make sure
> > > > > > everything ends up using the correct PAT entry.
> > > > > 
> > > > > I tried several approach to this, without success. Here is an update on
> > > > > debugging (reported also on #intel-gfx live):
> > > > > 
> > > > > I did several tests with different PAT configuration (by modifying Xen
> > > > > that sets the MSR). Full table is at https://pad.itl.space/sheet/#/2/sheet/view/HD1qT2Zf44Ha36TJ3wj2YL+PchsTidyNTFepW5++ZKM/
> > > > > Some highlights:
> > > > > - 1=WC, 4=WT - good
> > > > > - 1=WT, 4=WC - bad
> > > > > - 1=WT, 3=WC (4=WC too) - good
> > > > > - 1=WT, 5=WC - good
> > > > > 
> > > > > So, for me it seems WC at index 4 is problematic for some reason.
> > > > > 
> > > > > Next, I tried to trap all the places in arch/x86/xen/mmu_pv.c that
> > > > > write PTEs and verify requested cache attributes. There, it seems all
> > > > > the requested WC are properly translated (using either index 1, 3, 4, or
> > > > > 5 according to PAT settings). And then after reading PTE back, it indeed
> > > > > seems to be correctly set. I didn't added reading back after
> > > > > HYPERVISOR_update_va_mapping, but verified it isn't used for setting WC.
> > > > > 
> > > > > Using the same method, I also checked that indexes that aren't supposed
> > > > > to be used (for example index 4 when both 3 and 4 are WC) indeed are not
> > > > > used. So, the hypothesis that specific indexes are hardcoded somewhere
> > > > > is unlikely.
> > > > > 
> > > > > This all looks very weird to me. Any ideas?
> > > > 
> > > > Old CPUs have had hardware errata that caused the top bit of the PAT
> > > > entry to be ignored in certain cases.  Could modern CPUs be ignoring
> > > > this bit when accessing iGPU memory or registers?  With WC at position
> > > > 4, this would cause WC to be treated as WB, which is consistent with the
> > > > observed behavior.  WC at position 3 would not be impacted, and WC at
> > > > position 5 would be treated as WT which I expect to be safe.  One way to
> > > > test this is to test 1=WB, 5=WC.  If my hypothesis is correct, this
> > > > should trigger the bug, even if entry 1 in the PAT is unused because
> > > > entry 0 is also WB.
> > > 
> > > This looks like a very probable situation, indeed 1=WB, 5=WC does
> > > trigger the bug! Specifically this layout:
> > > 
> > >     WB	WB	UC-	UC	WP	WC	WT	UC
> > 
> > What about WB WT WB UC WB WP WC UC- and WB WT WT UC WB WP WC UC-?  Those
> > only differ in entry 2, which will not be used as it duplicates entry 0
> > or 1.  Therefore, architecturally, these should behave identically.  If
> > I am correct, the second will work fine, but the first will trigger the
> > bug.

Bingo! This also behaves as predicted.

So, it indeed looks like the _PAGE_PAT bit is ignored by the hardware,
even though set in relevant PTEs.

> Also worth testing:
> 
> WB  UC- UC  WB  WB  WP  WT  WC
> WB  UC- UC  UC  WB  WP  WT  WC
> 
> These differ only in (unused) entry 3.

I'll skip this, as I think it's pretty clear what will be the result.
But if somebody else think it's worth testing anyway, let me know.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: [Intel-gfx] [cache coherency bug] [hw bug?] i915 and PAT attributes
@ 2023-01-02  1:58 82%                 ` Marek Marczykowski-Górecki
  0 siblings, 0 replies; 200+ results
From: Marek Marczykowski-Górecki @ 2023-01-02  1:58 UTC (permalink / raw)
  To: Demi Marie Obenour
  Cc: Ville Syrjälä, Andrew Cooper,
	intel-gfx@lists.freedesktop.org, the arch/x86 maintainers,
	Lucas De Marchi, Daniel Vetter, Rodrigo Vivi, xen-devel

[-- Attachment #1: Type: text/plain, Size: 7658 bytes --]

On Sun, Jan 01, 2023 at 08:48:13PM -0500, Demi Marie Obenour wrote:
> On Sun, Jan 01, 2023 at 08:17:52PM -0500, Demi Marie Obenour wrote:
> > On Mon, Jan 02, 2023 at 02:00:51AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Sun, Jan 01, 2023 at 07:03:18PM -0500, Demi Marie Obenour wrote:
> > > > On Mon, Jan 02, 2023 at 12:24:54AM +0100, Marek Marczykowski-Górecki wrote:
> > > > > On Thu, Dec 22, 2022 at 10:29:57AM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Dec 16, 2022 at 03:30:13PM +0000, Andrew Cooper wrote:
> > > > > > > On 08/12/2022 1:55 pm, Marek Marczykowski-Górecki wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > There is an issue with i915 on Xen PV (dom0). The end result is a lot of
> > > > > > > > glitches, like here: https://openqa.qubes-os.org/tests/54748#step/startup/8
> > > > > > > > (this one is on ADL, Linux 6.1-rc7 as a Xen PV dom0). It's using Xorg
> > > > > > > > with "modesetting" driver.
> > > > > > > >
> > > > > > > > After some iterations of debugging, we narrowed it down to i915 handling
> > > > > > > > caching. The main difference is that PAT is setup differently on Xen PV
> > > > > > > > than on native Linux. Normally, Linux does have appropriate abstraction
> > > > > > > > for that, but apparently something related to i915 doesn't play well
> > > > > > > > with it. The specific difference is:
> > > > > > > > native linux:
> > > > > > > > x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
> > > > > > > > xen pv:
> > > > > > > > x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC
> > > > > > > >                                   ~~          ~~      ~~  ~~
> > > > > > > >
> > > > > > > > The specific impact depends on kernel version and the hardware. The most
> > > > > > > > severe issues I see on >=ADL, but some older hardware is affected too -
> > > > > > > > sometimes only if composition is disabled in the window manager.
> > > > > > > > Some more information is collected at
> > > > > > > > https://github.com/QubesOS/qubes-issues/issues/4782 (and few linked
> > > > > > > > duplicates...).
> > > > > > > >
> > > > > > > > Kind-of related commit is here:
> > > > > > > > https://github.com/torvalds/linux/commit/bdd8b6c98239cad ("drm/i915:
> > > > > > > > replace X86_FEATURE_PAT with pat_enabled()") - it is the place where
> > > > > > > > i915 explicitly checks for PAT support, so I'm cc-ing people mentioned
> > > > > > > > there too.
> > > > > > > >
> > > > > > > > Any ideas?
> > > > > > > >
> > > > > > > > The issue can be easily reproduced without Xen too, by adjusting PAT in
> > > > > > > > Linux:
> > > > > > > > -----8<-----
> > > > > > > > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> > > > > > > > index 66a209f7eb86..319ab60c8d8c 100644
> > > > > > > > --- a/arch/x86/mm/pat/memtype.c
> > > > > > > > +++ b/arch/x86/mm/pat/memtype.c
> > > > > > > > @@ -400,8 +400,8 @@ void pat_init(void)
> > > > > > > >  		 * The reserved slots are unused, but mapped to their
> > > > > > > >  		 * corresponding types in the presence of PAT errata.
> > > > > > > >  		 */
> > > > > > > > -		pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> > > > > > > > -		      PAT(4, WB) | PAT(5, WP) | PAT(6, UC_MINUS) | PAT(7, WT);
> > > > > > > > +		pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
> > > > > > > > +		      PAT(4, WC) | PAT(5, WP) | PAT(6, UC)       | PAT(7, UC);
> > > > > > > >  	}
> > > > > > > >  
> > > > > > > >  	if (!pat_bp_initialized) {
> > > > > > > > -----8<-----
> > > > > > > >
> > > > > > > 
> > > > > > > Hello, can anyone help please?
> > > > > > > 
> > > > > > > Intel's CI has taken this reproducer of the bug, and confirmed the
> > > > > > > regression. 
> > > > > > > https://lore.kernel.org/intel-gfx/Y5Hst0bCxQDTN7lK@mail-itl/T/#m4480c15a0d117dce6210562eb542875e757647fb
> > > > > > > 
> > > > > > > We're reasonably confident that it is an i915 bug (given the repro with
> > > > > > > no Xen in the mix), but we're out of any further ideas.
> > > > > > 
> > > > > > I don't think we have any code that assumes anything about the PAT,
> > > > > > apart from WC being available (which seems like it should still be
> > > > > > the case with your modified PAT). I suppose you'll just have to 
> > > > > > start digging from pgprot_writecombine()/noncached() and make sure
> > > > > > everything ends up using the correct PAT entry.
> > > > > 
> > > > > I tried several approach to this, without success. Here is an update on
> > > > > debugging (reported also on #intel-gfx live):
> > > > > 
> > > > > I did several tests with different PAT configuration (by modifying Xen
> > > > > that sets the MSR). Full table is at https://pad.itl.space/sheet/#/2/sheet/view/HD1qT2Zf44Ha36TJ3wj2YL+PchsTidyNTFepW5++ZKM/
> > > > > Some highlights:
> > > > > - 1=WC, 4=WT - good
> > > > > - 1=WT, 4=WC - bad
> > > > > - 1=WT, 3=WC (4=WC too) - good
> > > > > - 1=WT, 5=WC - good
> > > > > 
> > > > > So, for me it seems WC at index 4 is problematic for some reason.
> > > > > 
> > > > > Next, I tried to trap all the places in arch/x86/xen/mmu_pv.c that
> > > > > write PTEs and verify requested cache attributes. There, it seems all
> > > > > the requested WC are properly translated (using either index 1, 3, 4, or
> > > > > 5 according to PAT settings). And then after reading PTE back, it indeed
> > > > > seems to be correctly set. I didn't added reading back after
> > > > > HYPERVISOR_update_va_mapping, but verified it isn't used for setting WC.
> > > > > 
> > > > > Using the same method, I also checked that indexes that aren't supposed
> > > > > to be used (for example index 4 when both 3 and 4 are WC) indeed are not
> > > > > used. So, the hypothesis that specific indexes are hardcoded somewhere
> > > > > is unlikely.
> > > > > 
> > > > > This all looks very weird to me. Any ideas?
> > > > 
> > > > Old CPUs have had hardware errata that caused the top bit of the PAT
> > > > entry to be ignored in certain cases.  Could modern CPUs be ignoring
> > > > this bit when accessing iGPU memory or registers?  With WC at position
> > > > 4, this would cause WC to be treated as WB, which is consistent with the
> > > > observed behavior.  WC at position 3 would not be impacted, and WC at
> > > > position 5 would be treated as WT which I expect to be safe.  One way to
> > > > test this is to test 1=WB, 5=WC.  If my hypothesis is correct, this
> > > > should trigger the bug, even if entry 1 in the PAT is unused because
> > > > entry 0 is also WB.
> > > 
> > > This looks like a very probable situation, indeed 1=WB, 5=WC does
> > > trigger the bug! Specifically this layout:
> > > 
> > >     WB	WB	UC-	UC	WP	WC	WT	UC
> > 
> > What about WB WT WB UC WB WP WC UC- and WB WT WT UC WB WP WC UC-?  Those
> > only differ in entry 2, which will not be used as it duplicates entry 0
> > or 1.  Therefore, architecturally, these should behave identically.  If
> > I am correct, the second will work fine, but the first will trigger the
> > bug.

Bingo! This also behaves as predicted.

So, it indeed looks like the _PAGE_PAT bit is ignored by the hardware,
even though set in relevant PTEs.

> Also worth testing:
> 
> WB  UC- UC  WB  WB  WP  WT  WC
> WB  UC- UC  UC  WB  WP  WT  WC
> 
> These differ only in (unused) entry 3.

I'll skip this, as I think it's pretty clear what will be the result.
But if somebody else think it's worth testing anyway, let me know.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
  @ 2023-01-12 11:47 82% ` Yu Kuai
  2023-01-12 13:14 82%   ` Shinichiro Kawasaki
  2023-01-12 11:53 82%   ` Yu Kuai
  0 siblings, 2 replies; 200+ results
From: Yu Kuai @ 2023-01-12 11:47 UTC (permalink / raw)
  To: Shinichiro Kawasaki, linux-block@vger.kernel.org
  Cc: Paolo Valente, Jan Kara, yukuai (C)

Hi,

在 2023/01/12 19:38, Shinichiro Kawasaki 写道:
> I observed another KASAN uaf related to bfq. I would like to ask bfq experts
> to take a look in it. Whole KASAN message is attached below. It looks different
> from another uaf fixed with 246cf66e300b ("block, bfq: fix uaf for bfqq in
> bfq_exit_icq_bfqq").
> 
> It was observed first time during blktests test case block/027 run on kernel
> v6.2-rc3. Depending on test machines, it was recreated during system boot or ssh
> login occasionally. When I repeat system reboot and ssh-login twice, the uaf is
> recreated.
> 
> I guess 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'") could be
> the trigger commit. I cherry-picked the two commits 64dc8c732f5c and
> 246cf66e300b on top of v6.1. With this kernel, I observed the KASAN uaf in
> bic_set_bfqq.
> 
> 
> BUG: KASAN: use-after-free in bic_set_bfqq+0x15f/0x190
> device offline error, dev sdr, sector 245352968 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
> Read of size 8 at addr ffff88811de85f88 by task in:imjournal/815
> 
Thanks for the report, is the problem easy to reporduce? If so, can you
try the following patch?

diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index 1b2829e99dad..81d2f401fa3f 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data 
*bfqd,
                                  * request from the old cgroup.
                                  */
                                 bfq_put_cooperator(sync_bfqq);
-                               bfq_release_process_ref(bfqd, sync_bfqq);
                                 bic_set_bfqq(bic, NULL, true);
+                               bfq_release_process_ref(bfqd, sync_bfqq);
                         }
                 }
         }


> CPU: 5 PID: 815 Comm: in:imjournal Not tainted 6.2.0-rc3-kts+ #1
> Hardware name: Supermicro Super Server/X10SRL-F, BIOS 3.2 11/22/2019
> Call Trace:
>   <TASK>
>   dump_stack_lvl+0x5b/0x77
>   print_report+0x182/0x47e
>   ? bic_set_bfqq+0x15f/0x190
>   ? bic_set_bfqq+0x15f/0x190
>   kasan_report+0xbb/0xf0
>   ? bic_set_bfqq+0x15f/0x190
>   bic_set_bfqq+0x15f/0x190
>   bfq_bic_update_cgroup+0x386/0x950
>   bfq_bio_merge+0x132/0x2c0
>   ? __pfx_bfq_bio_merge+0x10/0x10
>   blk_mq_submit_bio+0xc5c/0x1b40
>   ? __pfx_blk_mq_submit_bio+0x10/0x10
>   ? find_held_lock+0x2d/0x110
>   __submit_bio+0x24d/0x2c0
>   ? __pfx___submit_bio+0x10/0x10
>   submit_bio_noacct_nocheck+0x5b1/0x820
>   ? __pfx_submit_bio_noacct_nocheck+0x10/0x10
>   ? rcu_read_lock_sched_held+0x3f/0x80
>   ext4_io_submit+0x86/0x110
>   ext4_do_writepages+0xb97/0x2f70
>   ? __pfx_ext4_do_writepages+0x10/0x10
>   ? lock_is_held_type+0xe3/0x140
>   ext4_writepages+0x21c/0x4b0
>   ? __pfx_ext4_writepages+0x10/0x10
>   ? __lock_acquire+0xc75/0x5520
>   do_writepages+0x166/0x630
>   ? __pfx_do_writepages+0x10/0x10
>   ? lock_release+0x365/0x730
>   ? wbc_attach_and_unlock_inode+0x3a3/0x780
>   ? __pfx_lock_release+0x10/0x10
>   ? __pfx_lock_release+0x10/0x10
>   ? __pfx_lock_acquire+0x10/0x10
>   ? do_raw_spin_unlock+0x54/0x1f0
>   ? _raw_spin_unlock+0x29/0x50
>   ? wbc_attach_and_unlock_inode+0x3a3/0x780
>   filemap_fdatawrite_wbc+0x111/0x170
>   ? kfree+0x115/0x190
>   __filemap_fdatawrite_range+0x9a/0xc0
>   ? __pfx___filemap_fdatawrite_range+0x10/0x10
>   ? __pfx_ext4_find_entry+0x10/0x10
>   ? __pfx___dquot_initialize+0x10/0x10
>   ? rcu_read_lock_sched_held+0x3f/0x80
>   ? ext4_alloc_da_blocks+0x177/0x210
>   ext4_rename+0x1123/0x23d0
>   ? __pfx_ext4_rename+0x10/0x10
>   ? __pfx___lock_acquire+0x10/0x10
>   ? lock_acquire+0x1a4/0x4f0
>   ? down_write_nested+0x141/0x200
>   ? ext4_rename2+0x88/0x200
>   vfs_rename+0xa6e/0x14f0
>   ? __pfx_lock_release+0x10/0x10
>   ? hook_file_open+0x780/0x790
>   ? __pfx_vfs_rename+0x10/0x10
>   ? __d_lookup+0x1fd/0x330
>   ? d_lookup+0x37/0x50
>   ? security_path_rename+0x111/0x1e0
>   do_renameat2+0x81c/0xa00
>   ? __pfx_do_renameat2+0x10/0x10
>   ? lock_release+0x365/0x730
>   ? __might_fault+0xbc/0x160
>   ? __pfx_lock_release+0x10/0x10
>   ? getname_flags.part.0+0x8d/0x430
>   ? lockdep_hardirqs_on_prepare+0x17b/0x410
>   __x64_sys_rename+0x7d/0xa0
>   do_syscall_64+0x5b/0x80
>   ? lockdep_hardirqs_on+0x7d/0x100
>   ? do_syscall_64+0x67/0x80
>   ? do_syscall_64+0x67/0x80
>   ? lockdep_hardirqs_on+0x7d/0x100
>   ? do_syscall_64+0x67/0x80
>   ? do_syscall_64+0x67/0x80
>   ? lockdep_hardirqs_on+0x7d/0x100
>   ? do_syscall_64+0x67/0x80
>   ? do_syscall_64+0x67/0x80
>   ? do_syscall_64+0x67/0x80
>   ? lockdep_hardirqs_on+0x7d/0x100
>   entry_SYSCALL_64_after_hwframe+0x72/0xdc
> RIP: 0033:0x7f8a2a5e3eab
> Code: e8 ba 2a 0a 00 f7 d8 19 c0 5b c3 0f 1f 40 00 b8 ff ff ff ff 5b c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 52 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05
> +c3 0f 1f 40 00 48 8b 15 51 8f 17 00 f7 d8
> RSP: 002b:00007f8a213fcc28 EFLAGS: 00000206 ORIG_RAX: 0000000000000052
> RAX: ffffffffffffffda RBX: 00007f8a1c00c640 RCX: 00007f8a2a5e3eab
> RDX: 0000000000000001 RSI: 000055d94c238820 RDI: 00007f8a213fcc30
> RBP: 00007f8a213fcc30 R08: 0000000000000000 R09: 00007f8a1c000130
> R10: 0000000000000000 R11: 0000000000000206 R12: 00007f8a1c00b480
> R13: 0000000000000067 R14: 00007f8a213fdce0 R15: 00007f8a1c00b180
>   </TASK>
> 
> Allocated by task 815:
>   kasan_save_stack+0x1c/0x40
>   kasan_set_track+0x21/0x30
>   __kasan_slab_alloc+0x88/0x90
>   kmem_cache_alloc_node+0x175/0x420
> 


^ permalink raw reply related	[relevance 82%]

* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
  2023-01-12 11:47 82% ` Yu Kuai
  2023-01-12 13:14 82%   ` Shinichiro Kawasaki
@ 2023-01-12 11:53 82%   ` Yu Kuai
  2023-01-12 13:18 82%     ` Shinichiro Kawasaki
  1 sibling, 1 reply; 200+ results
From: Yu Kuai @ 2023-01-12 11:53 UTC (permalink / raw)
  To: Yu Kuai, Shinichiro Kawasaki, linux-block@vger.kernel.org
  Cc: Paolo Valente, Jan Kara, yukuai (C)

Hi,

在 2023/01/12 19:47, Yu Kuai 写道:
> Thanks for the report, is the problem easy to reporduce? If so, can you
> try the following patch?
> 
> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> index 1b2829e99dad..81d2f401fa3f 100644
> --- a/block/bfq-cgroup.c
> +++ b/block/bfq-cgroup.c
> @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data 
> *bfqd,
>                                   * request from the old cgroup.
>                                   */
>                                  bfq_put_cooperator(sync_bfqq);
> -                               bfq_release_process_ref(bfqd, sync_bfqq);
>                                  bic_set_bfqq(bic, NULL, true);
> +                               bfq_release_process_ref(bfqd, sync_bfqq);
>                          }
>                  }
>          }
> 
Just in case you hit the problem in another place, please using the
following patch:

diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index 1b2829e99dad..81d2f401fa3f 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data 
*bfqd,
                                  * request from the old cgroup.
                                  */
                                 bfq_put_cooperator(sync_bfqq);
-                               bfq_release_process_ref(bfqd, sync_bfqq);
                                 bic_set_bfqq(bic, NULL, true);
+                               bfq_release_process_ref(bfqd, sync_bfqq);
                         }
                 }
         }
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 16f43bbc575a..687285612e57 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -5425,9 +5425,10 @@ static void bfq_check_ioprio_change(struct 
bfq_io_cq *bic, struct bio *bio)

         bfqq = bic_to_bfqq(bic, false);
         if (bfqq) {
-               bfq_release_process_ref(bfqd, bfqq);
+               struct bfq_queue *old_bfqq = bfqq;
                 bfqq = bfq_get_queue(bfqd, bio, false, bic, true);
                 bic_set_bfqq(bic, bfqq, false);
+               bfq_release_process_ref(bfqd, old_bfqq);
         }

         bfqq = bic_to_bfqq(bic, true);


^ permalink raw reply related	[relevance 82%]

* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
  2023-01-12 11:47 82% ` Yu Kuai
@ 2023-01-12 13:14 82%   ` Shinichiro Kawasaki
  2023-01-12 11:53 82%   ` Yu Kuai
  1 sibling, 0 replies; 200+ results
From: Shinichiro Kawasaki @ 2023-01-12 13:14 UTC (permalink / raw)
  To: Yu Kuai; +Cc: linux-block@vger.kernel.org, Paolo Valente, Jan Kara, yukuai (C)

On Jan 12, 2023 / 19:47, Yu Kuai wrote:
> Hi,
> 
> 在 2023/01/12 19:38, Shinichiro Kawasaki 写道:
> > I observed another KASAN uaf related to bfq. I would like to ask bfq experts
> > to take a look in it. Whole KASAN message is attached below. It looks different
> > from another uaf fixed with 246cf66e300b ("block, bfq: fix uaf for bfqq in
> > bfq_exit_icq_bfqq").
> > 
> > It was observed first time during blktests test case block/027 run on kernel
> > v6.2-rc3. Depending on test machines, it was recreated during system boot or ssh
> > login occasionally. When I repeat system reboot and ssh-login twice, the uaf is
> > recreated.
> > 
> > I guess 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'") could be
> > the trigger commit. I cherry-picked the two commits 64dc8c732f5c and
> > 246cf66e300b on top of v6.1. With this kernel, I observed the KASAN uaf in
> > bic_set_bfqq.
> > 
> > 
> > BUG: KASAN: use-after-free in bic_set_bfqq+0x15f/0x190
> > device offline error, dev sdr, sector 245352968 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
> > Read of size 8 at addr ffff88811de85f88 by task in:imjournal/815
> > 
> Thanks for the report, is the problem easy to reporduce? If so, can you
> try the following patch?
> 
> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> index 1b2829e99dad..81d2f401fa3f 100644
> --- a/block/bfq-cgroup.c
> +++ b/block/bfq-cgroup.c
> @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> *bfqd,
>                                  * request from the old cgroup.
>                                  */
>                                 bfq_put_cooperator(sync_bfqq);
> -                               bfq_release_process_ref(bfqd, sync_bfqq);
>                                 bic_set_bfqq(bic, NULL, true);
> +                               bfq_release_process_ref(bfqd, sync_bfqq);
>                         }
>                 }
>         }

Thanks for the quick response. Yes, I can recreate the problem reliably using
one of my test machines. With your fix patch above, the problem disappeared :)
I repeated system reboot and ssh login 6 times and the problem was not observed.

-- 
Shin'ichiro Kawasaki

^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
  2023-01-12 11:53 82%   ` Yu Kuai
@ 2023-01-12 13:18 82%     ` Shinichiro Kawasaki
  2023-01-13  1:04 82%       ` Shinichiro Kawasaki
  0 siblings, 1 reply; 200+ results
From: Shinichiro Kawasaki @ 2023-01-12 13:18 UTC (permalink / raw)
  To: Yu Kuai; +Cc: linux-block@vger.kernel.org, Paolo Valente, Jan Kara, yukuai (C)

On Jan 12, 2023 / 19:53, Yu Kuai wrote:
> Hi,
> 
> 在 2023/01/12 19:47, Yu Kuai 写道:
> > Thanks for the report, is the problem easy to reporduce? If so, can you
> > try the following patch?
> > 
> > diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> > index 1b2829e99dad..81d2f401fa3f 100644
> > --- a/block/bfq-cgroup.c
> > +++ b/block/bfq-cgroup.c
> > @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> > *bfqd,
> >                                   * request from the old cgroup.
> >                                   */
> >                                  bfq_put_cooperator(sync_bfqq);
> > -                               bfq_release_process_ref(bfqd, sync_bfqq);
> >                                  bic_set_bfqq(bic, NULL, true);
> > +                               bfq_release_process_ref(bfqd, sync_bfqq);
> >                          }
> >                  }
> >          }
> > 
> Just in case you hit the problem in another place, please using the
> following patch:
> 
> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> index 1b2829e99dad..81d2f401fa3f 100644
> --- a/block/bfq-cgroup.c
> +++ b/block/bfq-cgroup.c
> @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> *bfqd,
>                                  * request from the old cgroup.
>                                  */
>                                 bfq_put_cooperator(sync_bfqq);
> -                               bfq_release_process_ref(bfqd, sync_bfqq);
>                                 bic_set_bfqq(bic, NULL, true);
> +                               bfq_release_process_ref(bfqd, sync_bfqq);
>                         }
>                 }
>         }
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 16f43bbc575a..687285612e57 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -5425,9 +5425,10 @@ static void bfq_check_ioprio_change(struct bfq_io_cq
> *bic, struct bio *bio)
> 
>         bfqq = bic_to_bfqq(bic, false);
>         if (bfqq) {
> -               bfq_release_process_ref(bfqd, bfqq);
> +               struct bfq_queue *old_bfqq = bfqq;
>                 bfqq = bfq_get_queue(bfqd, bio, false, bic, true);
>                 bic_set_bfqq(bic, bfqq, false);
> +               bfq_release_process_ref(bfqd, old_bfqq);
>         }
> 
>         bfqq = bic_to_bfqq(bic, true);
> 

Ah, I've just noticed this e-mail. Will test this patch tomorrow.

-- 
Shin'ichiro Kawasaki

^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
  2023-01-12 13:18 82%     ` Shinichiro Kawasaki
@ 2023-01-13  1:04 82%       ` Shinichiro Kawasaki
  2023-01-13  1:11 82%         ` Yu Kuai
  0 siblings, 1 reply; 200+ results
From: Shinichiro Kawasaki @ 2023-01-13  1:04 UTC (permalink / raw)
  To: Yu Kuai; +Cc: linux-block@vger.kernel.org, Paolo Valente, Jan Kara, yukuai (C)

On Jan 12, 2023 / 22:18, Shin'ichiro Kawasaki wrote:
> On Jan 12, 2023 / 19:53, Yu Kuai wrote:
> > Hi,
> > 
> > 在 2023/01/12 19:47, Yu Kuai 写道:
> > > Thanks for the report, is the problem easy to reporduce? If so, can you
> > > try the following patch?
> > > 
> > > diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> > > index 1b2829e99dad..81d2f401fa3f 100644
> > > --- a/block/bfq-cgroup.c
> > > +++ b/block/bfq-cgroup.c
> > > @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> > > *bfqd,
> > >                                   * request from the old cgroup.
> > >                                   */
> > >                                  bfq_put_cooperator(sync_bfqq);
> > > -                               bfq_release_process_ref(bfqd, sync_bfqq);
> > >                                  bic_set_bfqq(bic, NULL, true);
> > > +                               bfq_release_process_ref(bfqd, sync_bfqq);
> > >                          }
> > >                  }
> > >          }
> > > 
> > Just in case you hit the problem in another place, please using the
> > following patch:
> > 
> > diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> > index 1b2829e99dad..81d2f401fa3f 100644
> > --- a/block/bfq-cgroup.c
> > +++ b/block/bfq-cgroup.c
> > @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> > *bfqd,
> >                                  * request from the old cgroup.
> >                                  */
> >                                 bfq_put_cooperator(sync_bfqq);
> > -                               bfq_release_process_ref(bfqd, sync_bfqq);
> >                                 bic_set_bfqq(bic, NULL, true);
> > +                               bfq_release_process_ref(bfqd, sync_bfqq);
> >                         }
> >                 }
> >         }
> > diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> > index 16f43bbc575a..687285612e57 100644
> > --- a/block/bfq-iosched.c
> > +++ b/block/bfq-iosched.c
> > @@ -5425,9 +5425,10 @@ static void bfq_check_ioprio_change(struct bfq_io_cq
> > *bic, struct bio *bio)
> > 
> >         bfqq = bic_to_bfqq(bic, false);
> >         if (bfqq) {
> > -               bfq_release_process_ref(bfqd, bfqq);
> > +               struct bfq_queue *old_bfqq = bfqq;
> >                 bfqq = bfq_get_queue(bfqd, bio, false, bic, true);
> >                 bic_set_bfqq(bic, bfqq, false);
> > +               bfq_release_process_ref(bfqd, old_bfqq);
> >         }
> > 
> >         bfqq = bic_to_bfqq(bic, true);
> > 
> 
> Ah, I've just noticed this e-mail. Will test this patch tomorrow.

This second trial patch also avoided the KASAN uaf message. I repeated the
system boot and ssh login 6 times and did not observe the failure. Looks good.

-- 
Shin'ichiro Kawasaki

^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
  2023-01-13  1:04 82%       ` Shinichiro Kawasaki
@ 2023-01-13  1:11 82%         ` Yu Kuai
  0 siblings, 0 replies; 200+ results
From: Yu Kuai @ 2023-01-13  1:11 UTC (permalink / raw)
  To: Shinichiro Kawasaki, Yu Kuai
  Cc: linux-block@vger.kernel.org, Paolo Valente, Jan Kara, yukuai (C)

Hi!

在 2023/01/13 9:04, Shinichiro Kawasaki 写道:

> This second trial patch also avoided the KASAN uaf message. I repeated the
> system boot and ssh login 6 times and did not observe the failure. Looks good.
> 

Thanks for the feedback! I'll send a patch soon.

Kuai


^ permalink raw reply	[relevance 82%]

* [Bug 216920] Running IDE eventually leads to BUG: kernel NULL pointer dereference
  @ 2023-01-16  9:31 82% ` bugzilla-daemon
  2023-01-16  9:33 82% ` bugzilla-daemon
  1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-16  9:31 UTC (permalink / raw)
  To: dri-devel

https://bugzilla.kernel.org/show_bug.cgi?id=216920

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |ANSWERED

--- Comment #1 from Artem S. Tashkinov (aros@gmx.com) ---
Please re-report here: https://gitlab.freedesktop.org/drm/intel/-/issues

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216920] Running IDE eventually leads to BUG: kernel NULL pointer dereference
    2023-01-16  9:31 82% ` [Bug 216920] " bugzilla-daemon
@ 2023-01-16  9:33 82% ` bugzilla-daemon
  1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-16  9:33 UTC (permalink / raw)
  To: dri-devel

https://bugzilla.kernel.org/show_bug.cgi?id=216920

--- Comment #2 from Artem S. Tashkinov (aros@gmx.com) ---
Sorry, wrong URL,

https://gitlab.freedesktop.org/drm/amd/-/issues

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216953] BUG: kernel NULL pointer dereference, address: 0000000000000008
  2023-01-19 18:25 82% [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008 bugzilla-daemon
                   ` (4 preceding siblings ...)
  2023-01-19 20:36 82% ` bugzilla-daemon
@ 2023-01-19 18:26 82% ` bugzilla-daemon
  2023-01-19 18:26 82% ` bugzilla-daemon
  6 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-19 18:26 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216953

--- Comment #1 from Gene (gjunk2@sapience.com) ---
Created attachment 303628
  --> https://bugzilla.kernel.org/attachment.cgi?id=303628&action=edit
ver_linux output

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216953] BUG: kernel NULL pointer dereference, address: 0000000000000008
  2023-01-19 18:25 82% [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008 bugzilla-daemon
  2023-01-22 11:23 82% ` [Bug 216953] " bugzilla-daemon
  2023-01-19 18:32 82% ` bugzilla-daemon
@ 2023-01-19 18:26 82% ` bugzilla-daemon
  2023-01-19 18:45 82% ` bugzilla-daemon
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-19 18:26 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216953

--- Comment #2 from Gene (gjunk2@sapience.com) ---
Created attachment 303629
  --> https://bugzilla.kernel.org/attachment.cgi?id=303629&action=edit
crash log

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216953] BUG: kernel NULL pointer dereference, address: 0000000000000008
  2023-01-19 18:25 82% [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008 bugzilla-daemon
                   ` (5 preceding siblings ...)
  2023-01-19 18:26 82% ` bugzilla-daemon
@ 2023-01-19 18:26 82% ` bugzilla-daemon
  6 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-19 18:26 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216953

--- Comment #3 from Gene (gjunk2@sapience.com) ---
Created attachment 303630
  --> https://bugzilla.kernel.org/attachment.cgi?id=303630&action=edit
log run rhought decode_stacktrace

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216953] BUG: kernel NULL pointer dereference, address: 0000000000000008
  2023-01-19 18:25 82% [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008 bugzilla-daemon
  2023-01-22 11:23 82% ` [Bug 216953] " bugzilla-daemon
@ 2023-01-19 18:32 82% ` bugzilla-daemon
  2023-01-19 18:26 82% ` bugzilla-daemon
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-19 18:32 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216953

Gene (gjunk2@sapience.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Regression|No                          |Yes

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216953] BUG: kernel NULL pointer dereference, address: 0000000000000008
  2023-01-19 18:25 82% [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008 bugzilla-daemon
                   ` (2 preceding siblings ...)
  2023-01-19 18:26 82% ` bugzilla-daemon
@ 2023-01-19 18:45 82% ` bugzilla-daemon
  2023-01-19 20:36 82% ` bugzilla-daemon
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-19 18:45 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216953

--- Comment #4 from Gene (gjunk2@sapience.com) ---
system also has 2 x 8TB usb drives using btrfs - but last read/write on that
filesystem was 7 or more hours before the crash.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216953] BUG: kernel NULL pointer dereference, address: 0000000000000008
  2023-01-19 18:25 82% [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008 bugzilla-daemon
                   ` (3 preceding siblings ...)
  2023-01-19 18:45 82% ` bugzilla-daemon
@ 2023-01-19 20:36 82% ` bugzilla-daemon
  2023-01-19 18:26 82% ` bugzilla-daemon
  2023-01-19 18:26 82% ` bugzilla-daemon
  6 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-19 20:36 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216953

--- Comment #6 from Gene (gjunk2@sapience.com) ---
Thanks Ted - sorry to not have a reproducer - this is the only machine that had
a problem and just the once (so far!)

I have a second machine running same kernel also with mdadm RAID 6 setup with
ext4 - but no problems on that one as of now.

The other item of note, perhaps, is the compiler used was gcc 12.2.1 - earlier
kernels used 12.2.0. Build started on fresh base (git -fddx).

Thanks again and sorry for pointing this down the wrong road.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008
@ 2023-01-19 18:25 82% bugzilla-daemon
  2023-01-22 11:23 82% ` [Bug 216953] " bugzilla-daemon
                   ` (6 more replies)
  0 siblings, 7 replies; 200+ results
From: bugzilla-daemon @ 2023-01-19 18:25 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216953

            Bug ID: 216953
           Summary: BUG: kernel NULL pointer dereference, address:
                    0000000000000008
           Product: File System
           Version: 2.5
    Kernel Version: 6.1.7
          Hardware: Intel
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: gjunk2@sapience.com
        Regression: No

Created attachment 303627
  --> https://bugzilla.kernel.org/attachment.cgi?id=303627&action=edit
kernel config

System has RAID6 with ext4 filesystem - 6 x 8TB drives.

Attached are config used to build kernel, output of ver_linux, the raw journal
as well as same run through scripts/decode_stacktrace.sh.

Note that while selinux is in kernel, there it is not being used.

thanks.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 216953] BUG: kernel NULL pointer dereference, address: 0000000000000008
  2023-01-19 18:25 82% [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008 bugzilla-daemon
@ 2023-01-22 11:23 82% ` bugzilla-daemon
  2023-01-19 18:32 82% ` bugzilla-daemon
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-22 11:23 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=216953

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aros@gmx.com
          Component|ext4                        |Loadable Security Modules
                   |                            |(LSM)
           Assignee|fs_ext4@kernel-bugs.osdl.or |other_lsm@kernel-bugs.osdl.
                   |g                           |org
            Product|File System                 |Other

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 204293] When destroying guests, hypervisor freezes for some seconds and get BUG: soft lockup - CPU* stuck for Xs
  @ 2023-01-27 13:06 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-01-27 13:06 UTC (permalink / raw)
  To: kvm

https://bugzilla.kernel.org/show_bug.cgi?id=204293

Roland Kletzing (devzero@web.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |devzero@web.de

--- Comment #1 from Roland Kletzing (devzero@web.de) ---
this may be caused by intense IO on the host if your VM is not using virtio
dataplance.

i have seen such when copying data or live migrating virtual machines

have a look at 
https://bugzilla.kernel.org/show_bug.cgi?id=199727 and
https://gitlab.com/qemu-project/qemu/-/issues/819

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [BUG REPORT] usb: dwc3: Bug while trying to use a RF ID Reader connected to USB port
  @ 2023-02-02  8:26 82% ` Greg KH
  0 siblings, 0 replies; 200+ results
From: Greg KH @ 2023-02-02  8:26 UTC (permalink / raw)
  To: hector; +Cc: felipe.balbi, linux-usb, Federico Nuñez

On Wed, Feb 01, 2023 at 05:32:15PM -0300, hector@ikatu.com wrote:
> Hi!
> 
> thanks in advance if you read this!

Note, Felipe is no longer the maintainer of this driver, you might want
to update your kernel tree.  And along those lines:

> I'm having issues trying to use a RF ID Reader connected to USB port.
> The platform I'm using is based on rockchip rk3328. Linux version:
> 5.15.78-yocto-standard.

That is very old, the dwc3 driver has changed a lot in the years since
the 5.15 kernel was released.  Any chance you can try 6.1 instead?

thanks,

greg k-h

^ permalink raw reply	[relevance 82%]

* Re: [BUG]  run rcutorture  BUG: unable to handle page fault for address: ffffffff84d05000
  @ 2023-02-09  3:49 82% ` Paul E. McKenney
  0 siblings, 0 replies; 200+ results
From: Paul E. McKenney @ 2023-02-09  3:49 UTC (permalink / raw)
  To: Zhang, Qiang1
  Cc: frederic@kernel.org, joel@joelfernandes.org, RCU,
	linux-kernel@vger.kernel.org

On Thu, Feb 09, 2023 at 02:57:42AM +0000, Zhang, Qiang1 wrote:
> 
> Test based on the following branches:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  branch dev, arch X86_64 
> 
> 
> runqemu kvm slirp nographic qemuparams="-m 1024 -smp 4" bootparams="nokaslr console=ttyS0 rcutorture.torture_type=rcu rcutorture.shuffle_interval=0 isolcpus=0,1 rcu_nocbs=0,1 nohz_full=0,1 rcutree.dump_tree=1 rcutorture.onoff_holdoff=30 rcutorture.onoff_interval=10" -d
> 
> [   39.392925] BUG: unable to handle page fault for address: ffffffff84d05000
> [   39.393244] #PF: supervisor read access in kernel mode
> [   39.393480] #PF: error_code(0x0000) - not-present page
> [   39.393715] PGD 3e19067 P4D 3e19067 PUD 3e1a063 PMD 800ffffffb3ff062
> [   39.394014] Oops: 0000 [#1] PREEMPT SMP KASAN PTI
> [   39.394231] CPU: 0 PID: 16 Comm: rcu_preempt Not tainted 6.2.0-rc1-yocto-standard+ #635
> [   39.394590] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4
> [   39.395085] RIP: 0010:do_raw_spin_trylock+0x70/0x120
> [   39.395320] Code: 81 c7 00 f1 f1 f1 f1 c7 40 04 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 e0 31 c0 e8 c8 0
> [   39.396143] RSP: 0018:ffff8880072d7b30 EFLAGS: 00010046
> [   39.396381] RAX: 0000000000000000 RBX: ffffffff84d05000 RCX: dffffc0000000000
> [   39.396703] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffffff84d05000
> [   39.397027] RBP: ffff8880072d7ba8 R08: ffffffff811d74a0 R09: fffffbfff09a0a01
> [   39.397346] R10: ffffffff84d05003 R11: fffffbfff09a0a00 R12: 1ffff11000e5af66
> [   39.397669] R13: ffffffff84d05018 R14: ffffffff84d05000 R15: ffff8880072d7cd8
> [   39.397990] FS:  0000000000000000(0000) GS:ffff888035400000(0000) knlGS:0000000000000000
> [   39.398353] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   39.398615] CR2: ffffffff84d05000 CR3: 000000000a22c000 CR4: 00000000001506f0
> [   39.398936] Call Trace:
> [   39.399053]  <TASK>
> [   39.399156]  ? __pfx_do_raw_spin_trylock+0x10/0x10
> [   39.399379]  ? trace_preempt_off+0x2a/0x110
> [   39.399576]  _raw_spin_lock+0x41/0x80
> [   39.399751]  ? schedule_timeout+0x242/0x580
> [   39.399945]  schedule_timeout+0x242/0x580
> [   39.400133]  ? __pfx_schedule_timeout+0x10/0x10
> [   39.400346]  ? __pfx_do_raw_spin_trylock+0x10/0x10
> [   39.400567]  ? __pfx_process_timeout+0x10/0x10
> [   39.400776]  ? _raw_spin_unlock_irqrestore+0x46/0x80
> [   39.401006]  ? prepare_to_swait_event+0xb8/0x210
> [   39.401221]  rcu_gp_fqs_loop+0x60b/0xd50
> [   39.401405]  ? rcu_gp_init+0x89c/0x1250
> [   39.401587]  ? __pfx_rcu_gp_fqs_loop+0x10/0x10
> [   39.401793]  ? _raw_spin_unlock_irqrestore+0x46/0x80
> [   39.402022]  rcu_gp_kthread+0x2b7/0x620
> [   39.402201]  ? __pfx_do_raw_spin_trylock+0x10/0x10
> [   39.402421]  ? __pfx_rcu_gp_kthread+0x10/0x10
> [   39.402625]  ? __kasan_check_read+0x11/0x20
> [   39.402818]  ? __kthread_parkme+0xe8/0x110
> [   39.403010]  ? __pfx_rcu_gp_kthread+0x10/0x10
> [   39.403213]  kthread+0x192/0x1d0
> [   39.403366]  ? __pfx_kthread+0x10/0x10
> [   39.403541]  ret_from_fork+0x2c/0x50
> [   39.403712]  </TASK>
> [   39.403818] Modules linked in:
> [   39.403972] CR2: ffffffff84d05000
> [   39.404128] ---[ end trace 0000000000000000 ]---
> [   39.404340] RIP: 0010:do_raw_spin_trylock+0x70/0x120
> [   39.404569] Code: 81 c7 00 f1 f1 f1 f1 c7 40 04 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 e0 31 c0 e8 c8 0
> [   39.405400] RSP: 0018:ffff8880072d7b30 EFLAGS: 00010046
> [   39.405639] RAX: 0000000000000000 RBX: ffffffff84d05000 RCX: dffffc0000000000
> [   39.405959] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffffff84d05000
> [   39.406281] RBP: ffff8880072d7ba8 R08: ffffffff811d74a0 R09: fffffbfff09a0a01
> [   39.406602] R10: ffffffff84d05003 R11: fffffbfff09a0a00 R12: 1ffff11000e5af66
> [   39.406922] R13: ffffffff84d05018 R14: ffffffff84d05000 R15: ffff8880072d7cd8
> [   39.407245] FS:  0000000000000000(0000) GS:ffff888035400000(0000) knlGS:0000000000000000
> [   39.407607] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   39.407871] CR2: ffffffff84d05000 CR3: 000000000a22c000 CR4: 00000000001506f0
> [   39.408195] Kernel panic - not syncing: Fatal exception
> [   39.408450] Kernel Offset: disabled
> [   39.408615] ---[ end Kernel panic - not syncing: Fatal exception ]---
> 
> After remove isolcpus=0,1 and nohz_full=0,1, there is no Oops.

That certainly isn't what we want the kernel to be doing!  ;-)

Could you please try bisecting?

							Thanx, Paul

^ permalink raw reply	[relevance 82%]

* Re: [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h>
  @ 2023-02-13 13:13 82%   ` Jan Beulich
  2023-02-14 16:44 82%     ` Oleksii
  0 siblings, 1 reply; 200+ results
From: Jan Beulich @ 2023-02-13 13:13 UTC (permalink / raw)
  To: Oleksii Kurochko
  Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
	Wei Liu, xen-devel

On 03.02.2023 18:05, Oleksii Kurochko wrote:
> Since the generic version of bug.h stuff was introduced it
> is necessary to rename all uses of <asm/bug.h> to <xen/bug.h>
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Doesn't this change need to come ahead of at least what currently is patch 3?
Or else why do you say "necessary" (I take this to mean the build otherwise
is broken)? If the build works after patch 3, the change here may want to be
drop the unnecessary asm/bug.h includes instead.

Jan


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-02-13 13:13 82%   ` Jan Beulich
@ 2023-02-14 16:44 82%     ` Oleksii
  0 siblings, 0 replies; 200+ results
From: Oleksii @ 2023-02-14 16:44 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
	Wei Liu, xen-devel

On Mon, 2023-02-13 at 14:13 +0100, Jan Beulich wrote:
> On 03.02.2023 18:05, Oleksii Kurochko wrote:
> > Since the generic version of bug.h stuff was introduced it
> > is necessary to rename all uses of <asm/bug.h> to <xen/bug.h>
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> Doesn't this change need to come ahead of at least what currently is
> patch 3?
> Or else why do you say "necessary" (I take this to mean the build
> otherwise
> is broken)? If the build works after patch 3, the change here may
> want to be
> drop the unnecessary asm/bug.h includes instead.
> 
I'll double-check if the build works after patch 3 and fix the comment.
Thanks for the comment.
> Jan

~Oleksii



^ permalink raw reply	[relevance 82%]

* Re: [PATCH v2 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  @ 2023-02-23 13:34 82%   ` Jan Beulich
  2023-02-23 15:14 82%     ` Oleksii
  0 siblings, 1 reply; 200+ results
From: Jan Beulich @ 2023-02-23 13:34 UTC (permalink / raw)
  To: Oleksii Kurochko
  Cc: Andrew Cooper, Stefano Stabellini, Gianluca Guida, Julien Grall,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, xen-devel

On 20.02.2023 17:40, Oleksii Kurochko wrote:
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -24,12 +24,12 @@
>  
>  #ifndef __ASSEMBLY__
>  
> +#include <xen/bug.h>
>  #include <xen/inttypes.h>
>  #include <xen/stdarg.h>
>  #include <xen/types.h>
>  #include <xen/xmalloc.h>
>  #include <xen/string.h>
> -#include <asm/bug.h>
>  
>  #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
>  #define WARN_ON(p)  ({                  \

As just said in reply to patch 1 - I can't see how this would build
at this point. There looks to be an ordering problem; you first need
to remove from asm/bug.h what's now also available from xen/bug.h.
Possibly parts of patches 3 and 4 need to move here.

Jan


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v2 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-02-23 13:34 82%   ` Jan Beulich
@ 2023-02-23 15:14 82%     ` Oleksii
  0 siblings, 0 replies; 200+ results
From: Oleksii @ 2023-02-23 15:14 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Andrew Cooper, Stefano Stabellini, Gianluca Guida, Julien Grall,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, xen-devel

On Thu, 2023-02-23 at 14:34 +0100, Jan Beulich wrote:
> On 20.02.2023 17:40, Oleksii Kurochko wrote:
> > --- a/xen/include/xen/lib.h
> > +++ b/xen/include/xen/lib.h
> > @@ -24,12 +24,12 @@
> >  
> >  #ifndef __ASSEMBLY__
> >  
> > +#include <xen/bug.h>
> >  #include <xen/inttypes.h>
> >  #include <xen/stdarg.h>
> >  #include <xen/types.h>
> >  #include <xen/xmalloc.h>
> >  #include <xen/string.h>
> > -#include <asm/bug.h>
> >  
> >  #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
> >  #define WARN_ON(p)  ({                  \
> 
> As just said in reply to patch 1 - I can't see how this would build
> at this point. There looks to be an ordering problem; you first need
> to remove from asm/bug.h what's now also available from xen/bug.h.
> Possibly parts of patches 3 and 4 need to move here.
Yeah, you are right as I answared to your reply to patch 1. I missed
that because I tested only RISC-V and didn't run tests for all
architectures.

I'll remove generic parts from patches 3 and 4 to patch 2 and will add
define BUG_FRAME_STRUCT to asm/bug.h specific headers.
> 
> Jan
~ Oleksii



^ permalink raw reply	[relevance 82%]

* Re: [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  @ 2023-02-25 16:47 82%   ` Julien Grall
  2023-02-28 13:07 82%     ` Oleksii
  2023-02-28 12:38 82%     ` Oleksii
  2023-02-27 14:29 82%   ` Jan Beulich
  1 sibling, 2 replies; 200+ results
From: Julien Grall @ 2023-02-25 16:47 UTC (permalink / raw)
  To: Oleksii Kurochko, xen-devel
  Cc: Jan Beulich, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné

Hi Oleksii,

On 24/02/2023 11:31, Oleksii Kurochko wrote:
> Since the generic version of bug.h stuff was introduced use <xen/bug.h>
> instead of unnecessary <asm/bug.h>
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
> Changes in V3:
>   * Update patch 2 not to break compilation: move some parts from patches 3 and 4
>     to patch 2:
>     * move some generic parts from <asm/bug.h> to <xen/bug.h>
>     * add define BUG_FRAME_STRUCT in ARM's <asm/bug.h>
> ---
> Changes in V2:
>   * Put [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h> as second patch,
>     update the patch to change all <asm/bug.h> to <xen/bug.h> among the whole project
>     to not break build.
>   * Update the commit message.
> ---
>   xen/arch/arm/include/asm/bug.h       | 19 +++----------------
>   xen/arch/arm/include/asm/div64.h     |  2 +-
>   xen/arch/arm/vgic/vgic-v2.c          |  2 +-
>   xen/arch/arm/vgic/vgic.c             |  2 +-
>   xen/arch/x86/acpi/cpufreq/cpufreq.c  |  2 +-
>   xen/arch/x86/include/asm/asm_defns.h |  2 +-
>   xen/arch/x86/include/asm/bug.h       | 19 ++-----------------
>   xen/drivers/cpufreq/cpufreq.c        |  2 +-
>   xen/include/xen/lib.h                |  2 +-
>   9 files changed, 12 insertions(+), 40 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/bug.h b/xen/arch/arm/include/asm/bug.h
> index f4088d0913..cacaf014ab 100644
> --- a/xen/arch/arm/include/asm/bug.h
> +++ b/xen/arch/arm/include/asm/bug.h
> @@ -1,6 +1,8 @@
>   #ifndef __ARM_BUG_H__
>   #define __ARM_BUG_H__
>   
> +#include <xen/types.h>

You are not adding new code in bug.h, so can you explain why this is now 
necessary?

> +
>   #if defined(CONFIG_ARM_32)
>   # include <asm/arm32/bug.h>
>   #elif defined(CONFIG_ARM_64)
> @@ -9,9 +11,7 @@
>   # error "unknown ARM variant"
>   #endif
>   
> -#define BUG_DISP_WIDTH    24
> -#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> -#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)

Even if the values are the same as the one you defined in the common 
bug.h, it doesn't feel right to remove them as long as...

> +#define BUG_FRAME_STRUCT

the arch is defining BUG_FRAME_STRUCT. So I would say the generic one 
should be defined within BUG_FRAME_STRUCT.

Cheers,

-- 
Julien Grall


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h>
    2023-02-25 16:47 82%   ` Julien Grall
@ 2023-02-27 14:29 82%   ` Jan Beulich
  2023-02-28 13:14 82%     ` Oleksii
  1 sibling, 1 reply; 200+ results
From: Jan Beulich @ 2023-02-27 14:29 UTC (permalink / raw)
  To: Oleksii Kurochko
  Cc: Andrew Cooper, Stefano Stabellini, Gianluca Guida, Julien Grall,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, xen-devel

On 24.02.2023 12:31, Oleksii Kurochko wrote:
> Since the generic version of bug.h stuff was introduced use <xen/bug.h>
> instead of unnecessary <asm/bug.h>

You keep saying "unnecessary" here, but that's not really correct.
Including asm/bug.h alone simply becomes meaningless. So how about
"... instead of now useless (in isolation) <asm/bug.h>"?

> --- a/xen/arch/x86/include/asm/bug.h
> +++ b/xen/arch/x86/include/asm/bug.h
> @@ -1,19 +1,10 @@
>  #ifndef __X86_BUG_H__
>  #define __X86_BUG_H__
>  
> -#define BUG_DISP_WIDTH    24
> -#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> -#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
> -
> -#define BUGFRAME_run_fn 0
> -#define BUGFRAME_warn   1
> -#define BUGFRAME_bug    2
> -#define BUGFRAME_assert 3
> -
> -#define BUGFRAME_NR     4
> -
>  #ifndef __ASSEMBLY__
>  
> +#define BUG_FRAME_STRUCT
> +
>  struct bug_frame {
>      signed int loc_disp:BUG_DISP_WIDTH;
>      unsigned int line_hi:BUG_LINE_HI_WIDTH;

Why would x86 continue to define its own bug_frame (and other items)?

Jan


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-02-25 16:47 82%   ` Julien Grall
  2023-02-28 13:07 82%     ` Oleksii
@ 2023-02-28 12:38 82%     ` Oleksii
  2023-02-28 14:04 82%       ` Julien Grall
  1 sibling, 1 reply; 200+ results
From: Oleksii @ 2023-02-28 12:38 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: Jan Beulich, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné

Hi Julien,

On Sat, 2023-02-25 at 16:47 +0000, Julien Grall wrote:
> Hi Oleksii,
> 
> On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > Since the generic version of bug.h stuff was introduced use
> > <xen/bug.h>
> > instead of unnecessary <asm/bug.h>
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > ---
> > Changes in V3:
> >   * Update patch 2 not to break compilation: move some parts from
> > patches 3 and 4
> >     to patch 2:
> >     * move some generic parts from <asm/bug.h> to <xen/bug.h>
> >     * add define BUG_FRAME_STRUCT in ARM's <asm/bug.h>
> > ---
> > Changes in V2:
> >   * Put [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h> as
> > second patch,
> >     update the patch to change all <asm/bug.h> to <xen/bug.h> among
> > the whole project
> >     to not break build.
> >   * Update the commit message.
> > ---
> >   xen/arch/arm/include/asm/bug.h       | 19 +++----------------
> >   xen/arch/arm/include/asm/div64.h     |  2 +-
> >   xen/arch/arm/vgic/vgic-v2.c          |  2 +-
> >   xen/arch/arm/vgic/vgic.c             |  2 +-
> >   xen/arch/x86/acpi/cpufreq/cpufreq.c  |  2 +-
> >   xen/arch/x86/include/asm/asm_defns.h |  2 +-
> >   xen/arch/x86/include/asm/bug.h       | 19 ++-----------------
> >   xen/drivers/cpufreq/cpufreq.c        |  2 +-
> >   xen/include/xen/lib.h                |  2 +-
> >   9 files changed, 12 insertions(+), 40 deletions(-)
> > 
> > diff --git a/xen/arch/arm/include/asm/bug.h
> > b/xen/arch/arm/include/asm/bug.h
> > index f4088d0913..cacaf014ab 100644
> > --- a/xen/arch/arm/include/asm/bug.h
> > +++ b/xen/arch/arm/include/asm/bug.h
> > @@ -1,6 +1,8 @@
> >   #ifndef __ARM_BUG_H__
> >   #define __ARM_BUG_H__
> >   
> > +#include <xen/types.h>
> 
> You are not adding new code in bug.h, so can you explain why this is
> now 
> necessary?
> 
> > +
> >   #if defined(CONFIG_ARM_32)
> >   # include <asm/arm32/bug.h>
> >   #elif defined(CONFIG_ARM_64)
> > @@ -9,9 +11,7 @@
> >   # error "unknown ARM variant"
> >   #endif
> >   
> > -#define BUG_DISP_WIDTH    24
> > -#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> > -#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
> 
> Even if the values are the same as the one you defined in the common 
> bug.h, it doesn't feel right to remove them as long as...
> 
> > +#define BUG_FRAME_STRUCT
> 
> the arch is defining BUG_FRAME_STRUCT. So I would say the generic one
> should be defined within BUG_FRAME_STRUCT.
> 
One of the reason BUG_DISP_WIDTH, BUG_LINE_* were removed is that they
don't use in ARM at all...

But generally I agree that it should be part of "#ifndef
BUG_FRAME_STRUCT" as it is 'struct bug_frame is dependent on it and
these defines look 'struct bug_frame' specific.

I'll update that in new version of the patch.
> Cheers,
> 
~ Oleksii


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-02-25 16:47 82%   ` Julien Grall
@ 2023-02-28 13:07 82%     ` Oleksii
  2023-02-28 13:30 82%       ` Jan Beulich
  2023-02-28 12:38 82%     ` Oleksii
  1 sibling, 1 reply; 200+ results
From: Oleksii @ 2023-02-28 13:07 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: Jan Beulich, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné

On Sat, 2023-02-25 at 16:47 +0000, Julien Grall wrote:
> Hi Oleksii,
> 
> On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > Since the generic version of bug.h stuff was introduced use
> > <xen/bug.h>
> > instead of unnecessary <asm/bug.h>
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > ---
> > Changes in V3:
> >   * Update patch 2 not to break compilation: move some parts from
> > patches 3 and 4
> >     to patch 2:
> >     * move some generic parts from <asm/bug.h> to <xen/bug.h>
> >     * add define BUG_FRAME_STRUCT in ARM's <asm/bug.h>
> > ---
> > Changes in V2:
> >   * Put [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h> as
> > second patch,
> >     update the patch to change all <asm/bug.h> to <xen/bug.h> among
> > the whole project
> >     to not break build.
> >   * Update the commit message.
> > ---
> >   xen/arch/arm/include/asm/bug.h       | 19 +++----------------
> >   xen/arch/arm/include/asm/div64.h     |  2 +-
> >   xen/arch/arm/vgic/vgic-v2.c          |  2 +-
> >   xen/arch/arm/vgic/vgic.c             |  2 +-
> >   xen/arch/x86/acpi/cpufreq/cpufreq.c  |  2 +-
> >   xen/arch/x86/include/asm/asm_defns.h |  2 +-
> >   xen/arch/x86/include/asm/bug.h       | 19 ++-----------------
> >   xen/drivers/cpufreq/cpufreq.c        |  2 +-
> >   xen/include/xen/lib.h                |  2 +-
> >   9 files changed, 12 insertions(+), 40 deletions(-)
> > 
> > diff --git a/xen/arch/arm/include/asm/bug.h
> > b/xen/arch/arm/include/asm/bug.h
> > index f4088d0913..cacaf014ab 100644
> > --- a/xen/arch/arm/include/asm/bug.h
> > +++ b/xen/arch/arm/include/asm/bug.h
> > @@ -1,6 +1,8 @@
> >   #ifndef __ARM_BUG_H__
> >   #define __ARM_BUG_H__
> >   
> > +#include <xen/types.h>
> 
> You are not adding new code in bug.h, so can you explain why this is
> now 
> necessary?
I am not adding new code but inside 'struct bug_frame' there are
uint16_t and uint32_t which are defined in <xen/types.h>.

And after <asm/bug.h> was changed to <xen/bug.h> it started to complain
on these types.
> 
> > +
> >   #if defined(CONFIG_ARM_32)
> >   # include <asm/arm32/bug.h>
> >   #elif defined(CONFIG_ARM_64)
> > @@ -9,9 +11,7 @@
> >   # error "unknown ARM variant"
> >   #endif
> >   
> > -#define BUG_DISP_WIDTH    24
> > -#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> > -#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
> 
> Even if the values are the same as the one you defined in the common 
> bug.h, it doesn't feel right to remove them as long as...
> 
> > +#define BUG_FRAME_STRUCT
> 
> the arch is defining BUG_FRAME_STRUCT. So I would say the generic one
> should be defined within BUG_FRAME_STRUCT.
One of the reason BUG_DISP_WIDTH, BUG_LINE_* were removed is that they
don't use in ARM at all...

But generally I agree that it should be part of "#ifndef
BUG_FRAME_STRUCT" as it is 'struct bug_frame is dependent on it and
these defines look 'struct bug_frame' specific.

I'll update that in new version of the patch.
> 
> Cheers,
> 



^ permalink raw reply	[relevance 82%]

* Re: [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-02-27 14:29 82%   ` Jan Beulich
@ 2023-02-28 13:14 82%     ` Oleksii
  0 siblings, 0 replies; 200+ results
From: Oleksii @ 2023-02-28 13:14 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Andrew Cooper, Stefano Stabellini, Gianluca Guida, Julien Grall,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, xen-devel

On Mon, 2023-02-27 at 15:29 +0100, Jan Beulich wrote:
> On 24.02.2023 12:31, Oleksii Kurochko wrote:
> > Since the generic version of bug.h stuff was introduced use
> > <xen/bug.h>
> > instead of unnecessary <asm/bug.h>
> 
> You keep saying "unnecessary" here, but that's not really correct.
> Including asm/bug.h alone simply becomes meaningless. So how about
> "... instead of now useless (in isolation) <asm/bug.h>"?
> 
> > --- a/xen/arch/x86/include/asm/bug.h
> > +++ b/xen/arch/x86/include/asm/bug.h
> > @@ -1,19 +1,10 @@
> >  #ifndef __X86_BUG_H__
> >  #define __X86_BUG_H__
> >  
> > -#define BUG_DISP_WIDTH    24
> > -#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> > -#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
> > -
> > -#define BUGFRAME_run_fn 0
> > -#define BUGFRAME_warn   1
> > -#define BUGFRAME_bug    2
> > -#define BUGFRAME_assert 3
> > -
> > -#define BUGFRAME_NR     4
> > -
> >  #ifndef __ASSEMBLY__
> >  
> > +#define BUG_FRAME_STRUCT
> > +
> >  struct bug_frame {
> >      signed int loc_disp:BUG_DISP_WIDTH;
> >      unsigned int line_hi:BUG_LINE_HI_WIDTH;
> 
> Why would x86 continue to define its own bug_frame (and other items)?
> 
Because x86 will be switched to generic one in the following patches of
the patch series and right now it defines only BUG_FRAME_STRUCT which
means that it will not use generic one implemetation now.
The idea of the patch was to rename <asm/bug.h> to <xen/bug.h> with
minimal required changes to keep Xen compilable.

And I am going to back:

-#define BUG_DISP_WIDTH    24
-#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
-#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)

for the same reason as in ARM. these defines are related to 'stuct
bug_frame' so should go with it.
These defines will be removed when an architecture will be switched to
generic implementation.

> Jan
~ Oleksii



^ permalink raw reply	[relevance 82%]

* Re: [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-02-28 13:07 82%     ` Oleksii
@ 2023-02-28 13:30 82%       ` Jan Beulich
  2023-02-28 16:00 82%         ` Oleksii
  0 siblings, 1 reply; 200+ results
From: Jan Beulich @ 2023-02-28 13:30 UTC (permalink / raw)
  To: Oleksii
  Cc: Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, Julien Grall, xen-devel

On 28.02.2023 14:07, Oleksii wrote:
> On Sat, 2023-02-25 at 16:47 +0000, Julien Grall wrote:
>> On 24/02/2023 11:31, Oleksii Kurochko wrote:
>>> --- a/xen/arch/arm/include/asm/bug.h
>>> +++ b/xen/arch/arm/include/asm/bug.h
>>> @@ -1,6 +1,8 @@
>>>   #ifndef __ARM_BUG_H__
>>>   #define __ARM_BUG_H__
>>>   
>>> +#include <xen/types.h>
>>
>> You are not adding new code in bug.h, so can you explain why this is
>> now 
>> necessary?
> I am not adding new code but inside 'struct bug_frame' there are
> uint16_t and uint32_t which are defined in <xen/types.h>.
> 
> And after <asm/bug.h> was changed to <xen/bug.h> it started to complain
> on these types.

Wouldn't xen/bug.h want to include xen/types.h anyway, and then clearly
before including asm/bug.h?

Jan


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-02-28 12:38 82%     ` Oleksii
@ 2023-02-28 14:04 82%       ` Julien Grall
  0 siblings, 0 replies; 200+ results
From: Julien Grall @ 2023-02-28 14:04 UTC (permalink / raw)
  To: Oleksii, xen-devel
  Cc: Jan Beulich, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné



On 28/02/2023 12:38, Oleksii wrote:
> Hi Julien,

Hi,

> On Sat, 2023-02-25 at 16:47 +0000, Julien Grall wrote:
>> Hi Oleksii,
>>
>> On 24/02/2023 11:31, Oleksii Kurochko wrote:
>>> Since the generic version of bug.h stuff was introduced use
>>> <xen/bug.h>
>>> instead of unnecessary <asm/bug.h>
>>>
>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>> ---
>>> Changes in V3:
>>>    * Update patch 2 not to break compilation: move some parts from
>>> patches 3 and 4
>>>      to patch 2:
>>>      * move some generic parts from <asm/bug.h> to <xen/bug.h>
>>>      * add define BUG_FRAME_STRUCT in ARM's <asm/bug.h>
>>> ---
>>> Changes in V2:
>>>    * Put [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h> as
>>> second patch,
>>>      update the patch to change all <asm/bug.h> to <xen/bug.h> among
>>> the whole project
>>>      to not break build.
>>>    * Update the commit message.
>>> ---
>>>    xen/arch/arm/include/asm/bug.h       | 19 +++----------------
>>>    xen/arch/arm/include/asm/div64.h     |  2 +-
>>>    xen/arch/arm/vgic/vgic-v2.c          |  2 +-
>>>    xen/arch/arm/vgic/vgic.c             |  2 +-
>>>    xen/arch/x86/acpi/cpufreq/cpufreq.c  |  2 +-
>>>    xen/arch/x86/include/asm/asm_defns.h |  2 +-
>>>    xen/arch/x86/include/asm/bug.h       | 19 ++-----------------
>>>    xen/drivers/cpufreq/cpufreq.c        |  2 +-
>>>    xen/include/xen/lib.h                |  2 +-
>>>    9 files changed, 12 insertions(+), 40 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/include/asm/bug.h
>>> b/xen/arch/arm/include/asm/bug.h
>>> index f4088d0913..cacaf014ab 100644
>>> --- a/xen/arch/arm/include/asm/bug.h
>>> +++ b/xen/arch/arm/include/asm/bug.h
>>> @@ -1,6 +1,8 @@
>>>    #ifndef __ARM_BUG_H__
>>>    #define __ARM_BUG_H__
>>>    
>>> +#include <xen/types.h>
>>
>> You are not adding new code in bug.h, so can you explain why this is
>> now
>> necessary?
>>
>>> +
>>>    #if defined(CONFIG_ARM_32)
>>>    # include <asm/arm32/bug.h>
>>>    #elif defined(CONFIG_ARM_64)
>>> @@ -9,9 +11,7 @@
>>>    # error "unknown ARM variant"
>>>    #endif
>>>    
>>> -#define BUG_DISP_WIDTH    24
>>> -#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
>>> -#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
>>
>> Even if the values are the same as the one you defined in the common
>> bug.h, it doesn't feel right to remove them as long as...
>>
>>> +#define BUG_FRAME_STRUCT
>>
>> the arch is defining BUG_FRAME_STRUCT. So I would say the generic one
>> should be defined within BUG_FRAME_STRUCT.
>>
> One of the reason BUG_DISP_WIDTH, BUG_LINE_* were removed is that they
> don't use in ARM at all...

Hmmm ok. But this sort of things should have been documented in the 
commit message even thought it doesn't feel this is related to what the 
patch is doing.

Cheers,

-- 
Julien Grall


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-02-28 13:30 82%       ` Jan Beulich
@ 2023-02-28 16:00 82%         ` Oleksii
  0 siblings, 0 replies; 200+ results
From: Oleksii @ 2023-02-28 16:00 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, Julien Grall, xen-devel

On Tue, 2023-02-28 at 14:30 +0100, Jan Beulich wrote:
> On 28.02.2023 14:07, Oleksii wrote:
> > On Sat, 2023-02-25 at 16:47 +0000, Julien Grall wrote:
> > > On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/arm/include/asm/bug.h
> > > > +++ b/xen/arch/arm/include/asm/bug.h
> > > > @@ -1,6 +1,8 @@
> > > >   #ifndef __ARM_BUG_H__
> > > >   #define __ARM_BUG_H__
> > > >   
> > > > +#include <xen/types.h>
> > > 
> > > You are not adding new code in bug.h, so can you explain why this
> > > is
> > > now 
> > > necessary?
> > I am not adding new code but inside 'struct bug_frame' there are
> > uint16_t and uint32_t which are defined in <xen/types.h>.
> > 
> > And after <asm/bug.h> was changed to <xen/bug.h> it started to
> > complain
> > on these types.
> 
> Wouldn't xen/bug.h want to include xen/types.h anyway, and then
> clearly
> before including asm/bug.h?
<xen/types.h> can be moved to <xen/bug.h> but generic implementation
doesn't use any specific from <xen/types.h> types.
But probably you are right that it would be better move to
<xen/bug.h>...
> 
> Jan
~ Oleksii



^ permalink raw reply	[relevance 82%]

* Re: [PATCH v5 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  @ 2023-03-06 10:24 82%   ` Jan Beulich
  0 siblings, 0 replies; 200+ results
From: Jan Beulich @ 2023-03-06 10:24 UTC (permalink / raw)
  To: Oleksii Kurochko
  Cc: Julien Grall, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, xen-devel

On 03.03.2023 11:38, Oleksii Kurochko wrote:
> The idea of the patch is to change all <asm/bug.h> to <xen/bug.h> and
> keep Xen compilable with adding only minimal amount of changes:
> 1. It was added "#include <xen/types.h>" to ARM's "<asm/bug.h>" as it
>   uses uint_{16,32}t in 'struct bug_frame'.
> 2. It was added '#define BUG_FRAME_STRUCT' which means that ARM hasn't
>   been switched to generic implementation yet.
> 3. It was added '#define BUG_FRAME_STRUCT' which means that x86 hasn't
>   been switched to generic implementation yet.
> 4. BUGFRAME_* and _start_bug_frame[], _stop_bug_frame_*[] were removed
>   for ARM & x86 to deal with compilation errors such as:
>       redundant redeclaration of ...
> 
> In the following two patches x86 and ARM archictectures will be
> switched fully:
> * xen/arm: switch ARM to use generic implementation of bug.h
> * xen/x86: switch x86 to use generic implemetation of bug.h
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
> Changes in V5:
>  - Nothing changed
> ---
> Changes in V4:
> 	- defines BUG_DISP_WIDTH, BUG_LINE_LO_WIDTH, BUG_LINE_HI_WIDTH were moved into
> 	  "ifndef BUG_FRAME_STRUCT" in <xen/bug.h> as they are specific for 'struct bug_frame' and so should
> 	  co-exist together. So the defines were back to <asm/bug.h> until BUG_FRAME_STRUCT will be defined in
> 	  <asm/bug.h>.
> 	- Update the comment message.
> ---
> Changes in V3:
>  * Update patch 2 not to break compilation: move some parts from patches 3 and 4
>    to patch 2:
>    * move some generic parts from <asm/bug.h> to <xen/bug.h>
>    * add define BUG_FRAME_STRUCT in ARM's <asm/bug.h>
> ---
> Changes in V2:
>  * Put [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h> as second patch,
>    update the patch to change all <asm/bug.h> to <xen/bug.h> among the whole project
>    to not break build.
>  * Update the commit message.
> ---
>  xen/arch/arm/include/asm/bug.h       | 17 ++++-------------
>  xen/arch/arm/include/asm/div64.h     |  2 +-
>  xen/arch/arm/vgic/vgic-v2.c          |  2 +-
>  xen/arch/arm/vgic/vgic.c             |  2 +-
>  xen/arch/x86/acpi/cpufreq/cpufreq.c  |  2 +-
>  xen/arch/x86/include/asm/asm_defns.h |  2 +-
>  xen/arch/x86/include/asm/bug.h       | 15 ++-------------
>  xen/drivers/cpufreq/cpufreq.c        |  2 +-
>  xen/include/xen/lib.h                |  2 +-
>  9 files changed, 13 insertions(+), 33 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/bug.h b/xen/arch/arm/include/asm/bug.h
> index f4088d0913..9315662c6e 100644
> --- a/xen/arch/arm/include/asm/bug.h
> +++ b/xen/arch/arm/include/asm/bug.h
> @@ -1,6 +1,8 @@
>  #ifndef __ARM_BUG_H__
>  #define __ARM_BUG_H__
>  
> +#include <xen/types.h>
> +
>  #if defined(CONFIG_ARM_32)
>  # include <asm/arm32/bug.h>
>  #elif defined(CONFIG_ARM_64)
> @@ -13,6 +15,8 @@
>  #define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
>  #define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
>  
> +#define BUG_FRAME_STRUCT
> +
>  struct bug_frame {
>      signed int loc_disp;    /* Relative address to the bug address */
>      signed int file_disp;   /* Relative address to the filename */
> @@ -26,13 +30,6 @@ struct bug_frame {
>  #define bug_line(b) ((b)->line)
>  #define bug_msg(b) ((const char *)(b) + (b)->msg_disp)
>  
> -#define BUGFRAME_run_fn 0
> -#define BUGFRAME_warn   1
> -#define BUGFRAME_bug    2
> -#define BUGFRAME_assert 3
> -
> -#define BUGFRAME_NR     4
> -
>  /* Many versions of GCC doesn't support the asm %c parameter which would
>   * be preferable to this unpleasantness. We use mergeable string
>   * sections to avoid multiple copies of the string appearing in the
> @@ -89,12 +86,6 @@ struct bug_frame {
>      unreachable();                                              \
>  } while (0)
>  
> -extern const struct bug_frame __start_bug_frames[],
> -                              __stop_bug_frames_0[],
> -                              __stop_bug_frames_1[],
> -                              __stop_bug_frames_2[],
> -                              __stop_bug_frames_3[];
> -
>  #endif /* __ARM_BUG_H__ */
>  /*
>   * Local variables:
> diff --git a/xen/arch/arm/include/asm/div64.h b/xen/arch/arm/include/asm/div64.h
> index 1cd58bc51a..fc667a80f9 100644
> --- a/xen/arch/arm/include/asm/div64.h
> +++ b/xen/arch/arm/include/asm/div64.h
> @@ -74,7 +74,7 @@
>  
>  #elif __GNUC__ >= 4
>  
> -#include <asm/bug.h>
> +#include <xen/bug.h>
>  
>  /*
>   * If the divisor happens to be constant, we determine the appropriate
> diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
> index 1a99d3a8b4..c90e88fddb 100644
> --- a/xen/arch/arm/vgic/vgic-v2.c
> +++ b/xen/arch/arm/vgic/vgic-v2.c
> @@ -16,8 +16,8 @@
>   */
>  
>  #include <asm/new_vgic.h>
> -#include <asm/bug.h>
>  #include <asm/gic.h>
> +#include <xen/bug.h>
>  #include <xen/sched.h>
>  #include <xen/sizes.h>
>  
> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
> index f0f2ea5021..b9463a5f27 100644
> --- a/xen/arch/arm/vgic/vgic.c
> +++ b/xen/arch/arm/vgic/vgic.c
> @@ -15,9 +15,9 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <xen/bug.h>
>  #include <xen/list_sort.h>
>  #include <xen/sched.h>
> -#include <asm/bug.h>
>  #include <asm/event.h>
>  #include <asm/new_vgic.h>
>  
> diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> index c27cbb2304..18ff2a443b 100644
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -27,6 +27,7 @@
>   * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   */
>  
> +#include <xen/bug.h>
>  #include <xen/types.h>
>  #include <xen/errno.h>
>  #include <xen/delay.h>
> @@ -35,7 +36,6 @@
>  #include <xen/sched.h>
>  #include <xen/timer.h>
>  #include <xen/xmalloc.h>
> -#include <asm/bug.h>
>  #include <asm/msr.h>
>  #include <asm/io.h>
>  #include <asm/processor.h>
> diff --git a/xen/arch/x86/include/asm/asm_defns.h b/xen/arch/x86/include/asm/asm_defns.h
> index d9431180cf..a8526cf36c 100644
> --- a/xen/arch/x86/include/asm/asm_defns.h
> +++ b/xen/arch/x86/include/asm/asm_defns.h
> @@ -6,7 +6,7 @@
>  /* NB. Auto-generated from arch/.../asm-offsets.c */
>  #include <asm/asm-offsets.h>
>  #endif
> -#include <asm/bug.h>
> +#include <xen/bug.h>
>  #include <asm/x86-defns.h>
>  #include <xen/stringify.h>
>  #include <asm/cpufeature.h>

While there's an unhelpful mix of asm/ and xen/ here already, may I ask
that you try to avoid making things yet worse: Unless there's a reason
not to, please move the added line past asm/x86-defns.h, adjacent to
xen/stringify.h. Then non-Arm parts
Acked-by: Jan Beulich <jbeulich@suse.com>
(assuming of course no further large rework is necessary because of the
comments on patch 1).

Jan


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: slab-use-after-free in bfq_setup_cooperator
  @ 2023-03-07  8:57 82% ` Yu Kuai
  2023-03-07  9:13 82%   ` Shinichiro Kawasaki
  0 siblings, 1 reply; 200+ results
From: Yu Kuai @ 2023-03-07  8:57 UTC (permalink / raw)
  To: Shinichiro Kawasaki, linux-block@vger.kernel.org
  Cc: Gabriele Felici, Gianmarco Lusvardi, Giulio Barabino,
	Emiliano Maccaferri, Paolo Valente, Damien Le Moal, yukuai (C),
	Jan Kara

Hi,

在 2023/03/07 15:14, Shinichiro Kawasaki 写道:
> I observe the KASAN BUG message with kernel v6.3-rc1 during my system boot [1].
> The BUG is reliably recreated. I bisected and found that the trigger commit is
> fd571df0ac5b ("block, bfq: turn bfqq_data into an array in bfq_io_cq"). I
> reverted the commit from v6.3-rc1, and observed the BUG disappears. Action for
> fix will be appreciated. I can take actions on my system if it helps.
> 
> [1]
> 
> ...
> [   49.534400] NET: Registered PF_QIPCRTR protocol family
> [   51.420663] ==================================================================
> [   51.422452] BUG: KASAN: slab-use-after-free in bfq_setup_cooperator+0x120b/0x1650
> [   51.423576] Read of size 4 at addr ffff88811a8bd600 by task NetworkManager/724
> 
> [   51.425032] CPU: 3 PID: 724 Comm: NetworkManager Not tainted 6.3.0-rc1-kts #1
> [   51.426105] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014
> [   51.427647] Call Trace:
> [   51.428103]  <TASK>
> [   51.428472]  dump_stack_lvl+0x57/0x90
> [   51.429042]  print_report+0xcf/0x630
> [   51.429642]  ? bfq_setup_cooperator+0x120b/0x1650
> [   51.430296]  kasan_report+0xbb/0xf0
> [   51.430843]  ? bfq_setup_cooperator+0x120b/0x1650
> [   51.431487]  bfq_setup_cooperator+0x120b/0x1650
> [   51.432175]  ? __pfx_lock_release+0x10/0x10
> [   51.432769]  ? __pfx_bfq_setup_cooperator+0x10/0x10
> [   51.433442]  ? lock_is_held_type+0xe3/0x140
> [   51.434046]  bfq_insert_requests+0xdfc/0x9360
> [   51.434622]  ? __pfx___lock_acquire+0x10/0x10
> [   51.435248]  ? set_operstate+0x193/0x1f0
> [   51.435778]  ? __pfx_bfq_insert_requests+0x10/0x10
> [   51.436440]  ? blk_mq_sched_insert_requests+0xba/0x880
> [   51.437091]  ? __pfx_lock_release+0x10/0x10
> [   51.437700]  blk_mq_sched_insert_requests+0x16b/0x880
> [   51.438356]  blk_mq_flush_plug_list+0x341/0xdb0
> [   51.438930]  ? __pfx_blk_mq_flush_plug_list+0x10/0x10
> [   51.439600]  __blk_flush_plug+0x28d/0x450
> [   51.440117]  ? __pfx___blk_flush_plug+0x10/0x10
> [   51.440734]  blk_finish_plug+0x4b/0xa0
> [   51.441199]  read_pages+0x50a/0xb90
> [   51.441627]  ? __pfx_read_pages+0x10/0x10
> [   51.442147]  ? free_unref_page_commit+0x243/0x500
> [   51.442698]  ? _raw_spin_unlock+0x29/0x50
> [   51.443176]  ? free_unref_page+0x2f2/0x400
> [   51.443687]  page_cache_ra_order+0x617/0x870
> [   51.444198]  filemap_fault+0xe45/0x1eb0
> [   51.444714]  ? __pfx_filemap_fault+0x10/0x10
> [   51.445221]  ? lock_is_held_type+0xe3/0x140
> [   51.445711]  ? lock_is_held_type+0xe3/0x140
> [   51.446238]  __xfs_filemap_fault+0x141/0x7d0 [xfs]
> [   51.447406]  ? __pfx___xfs_filemap_fault+0x10/0x10 [xfs]
> [   51.448302]  ? xfs_filemap_map_pages+0x9d/0xd0 [xfs]
> [   51.449200]  ? __pfx_xfs_filemap_map_pages+0x10/0x10 [xfs]
> [   51.450073]  ? __pfx_xfs_filemap_map_pages+0x10/0x10 [xfs]
> [   51.450953]  __do_fault+0xef/0x5b0
> [   51.451357]  ? __pfx_xfs_filemap_map_pages+0x10/0x10 [xfs]
> [   51.452236]  do_fault+0x4c1/0xec0
> [   51.452619]  ? __pfx_pmd_page_vaddr+0x10/0x10
> [   51.453139]  __handle_mm_fault+0xc40/0x2410
> [   51.453605]  ? lock_is_held_type+0xe3/0x140
> [   51.454063]  ? __pfx___handle_mm_fault+0x10/0x10
> [   51.454617]  ? count_memcg_events.constprop.0+0x40/0x50
> [   51.455171]  handle_mm_fault+0x21f/0x7a0
> [   51.455616]  do_user_addr_fault+0x344/0xed0
> [   51.456130]  exc_page_fault+0x65/0x100
> [   51.456555]  asm_exc_page_fault+0x22/0x30
> [   51.456999] RIP: 0033:0x562259a3da00
> [   51.457472] Code: Unable to access opcode bytes at 0x562259a3d9d6.
> [   51.458109] RSP: 002b:00007ffcd8f6c5d8 EFLAGS: 00010287
> [   51.458718] RAX: 0000562259a3da00 RBX: 0000000000000000 RCX: 0000000000000000
> [   51.459449] RDX: 00007f07c1ce9310 RSI: 000056225a0bb6f0 RDI: 000056225a07d8f0
> [   51.460224] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000001
> [   51.460919] R10: 0000000000000001 R11: 00007f07c1b58c80 R12: 000056225a07d8f0
> [   51.461669] R13: 0000000000000000 R14: 000056225a0c43d0 R15: 00007ffcd8f6c780
> [   51.462382]  </TASK>
> 
> [   51.462907] Allocated by task 723:
> [   51.463287]  kasan_save_stack+0x1c/0x40
> [   51.463705]  kasan_set_track+0x21/0x30
> [   51.464163]  __kasan_slab_alloc+0x85/0x90
> [   51.464602]  kmem_cache_alloc_node+0x16a/0x330
> [   51.465068]  bfq_get_queue+0x1fc/0x1420
> [   51.465537]  bfq_get_bfqq_handle_split+0x11a/0x510
> [   51.466029]  bfq_insert_requests+0x731/0x9360
> [   51.466492]  blk_mq_sched_insert_requests+0x16b/0x880
> [   51.467068]  blk_mq_flush_plug_list+0x341/0xdb0
> [   51.513146]  __blk_flush_plug+0x28d/0x450
> [   51.743436]  blk_finish_plug+0x4b/0xa0
> [   51.800072]  _xfs_buf_ioapply+0x68c/0xab0 [xfs]
> [   51.800884]  __xfs_buf_submit+0x1e8/0x7b0 [xfs]
> [   51.801677]  xfs_buf_read_map+0x301/0xad0 [xfs]
> [   51.802521]  xfs_trans_read_buf_map+0x280/0x7c0 [xfs]
> [   51.803368]  xfs_imap_to_bp+0xe6/0x140 [xfs]
> [   51.804164]  xfs_iget+0x780/0x2a60 [xfs]
> [   51.804909]  xfs_lookup+0x234/0x390 [xfs]
> [   51.805669]  xfs_vn_lookup+0x108/0x150 [xfs]
> [   51.806442]  lookup_open.isra.0+0x7e8/0x1280
> [   51.806965]  path_openat+0x829/0x25d0
> [   51.807388]  do_filp_open+0x19f/0x3b0
> [   51.807803]  do_open_execat+0xa8/0x570
> [   51.808282]  bprm_execve+0x3da/0x15e0
> [   51.808698]  do_execveat_common.isra.0+0x4d6/0x6c0
> [   51.809213]  __x64_sys_execve+0x88/0xb0
> [   51.809678]  do_syscall_64+0x37/0x90
> [   51.810084]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> 
> [   51.810895] Freed by task 724:
> [   51.811256]  kasan_save_stack+0x1c/0x40
> [   51.811688]  kasan_set_track+0x21/0x30
> [   51.812161]  kasan_save_free_info+0x2a/0x50
> [   51.812627]  ____kasan_slab_free+0x169/0x1c0
> [   51.813096]  slab_free_freelist_hook+0xdb/0x1b0
> [   51.813642]  kmem_cache_free+0xdb/0x390
> [   51.814071]  bfq_put_queue+0x439/0x950
> [   51.814497]  bfq_setup_cooperator+0xa41/0x1650
> [   51.815030]  bfq_insert_requests+0xdfc/0x9360
> [   51.815503]  blk_mq_sched_insert_requests+0x16b/0x880
> [   51.816042]  blk_mq_flush_plug_list+0x341/0xdb0
> [   51.816583]  __blk_flush_plug+0x28d/0x450
> [   51.817027]  blk_finish_plug+0x4b/0xa0
> [   51.817451]  read_pages+0x50a/0xb90
> [   51.817897]  page_cache_ra_order+0x617/0x870
> [   51.818368]  filemap_fault+0xe45/0x1eb0
> [   51.818801]  __xfs_filemap_fault+0x141/0x7d0 [xfs]
> [   51.819622]  __do_fault+0xef/0x5b0
> [   51.820011]  do_fault+0x4c1/0xec0
> [   51.820448]  __handle_mm_fault+0xc40/0x2410
> [   51.820910]  handle_mm_fault+0x21f/0x7a0
> [   51.821352]  do_user_addr_fault+0x344/0xed0
> [   51.821864]  exc_page_fault+0x65/0x100
> [   51.822289]  asm_exc_page_fault+0x22/0x30
> 
> [   51.822956] The buggy address belongs to the object at ffff88811a8bd600
>                  which belongs to the cache bfq_queue of size 576
> [   51.824269] The buggy address is located 0 bytes inside of
>                  freed 576-byte region [ffff88811a8bd600, ffff88811a8bd840)
> 
> [   51.825761] The buggy address belongs to the physical page:
> [   51.826393] page:00000000e11d915c refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88811a8bc2c0 pfn:0x11a8bc
> [   51.827462] head:00000000e11d915c order:2 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> [   51.828247] flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
> [   51.829021] raw: 0017ffffc0010200 ffff888100a95cc0 dead000000000122 0000000000000000
> [   51.829779] raw: ffff88811a8bc2c0 0000000080170011 00000001ffffffff 0000000000000000
> [   51.830581] page dumped because: kasan: bad access detected
> 
> [   51.831358] Memory state around the buggy address:
> [   51.831907]  ffff88811a8bd500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [   51.832615]  ffff88811a8bd580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [   51.833371] >ffff88811a8bd600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [   51.834077]                    ^
> [   51.834496]  ffff88811a8bd680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [   51.835228]  ffff88811a8bd700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [   51.836009] ==================================================================
> [   51.836739] Disabling lock debugging due to kernel taint
> [   51.999350] e1000: ens3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
> ...
> 

Thanks for the report, can you help to provide the result of add2line of
following?

bfq_setup_cooperator+0x120b/0x1650
bfq_setup_cooperator+0xa41/0x1650

That will help to locate the problem.

Thanks,
Kuai
> 


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: slab-use-after-free in bfq_setup_cooperator
  2023-03-07  8:57 82% ` Yu Kuai
@ 2023-03-07  9:13 82%   ` Shinichiro Kawasaki
    0 siblings, 1 reply; 200+ results
From: Shinichiro Kawasaki @ 2023-03-07  9:13 UTC (permalink / raw)
  To: Yu Kuai
  Cc: linux-block@vger.kernel.org, Gabriele Felici, Gianmarco Lusvardi,
	Giulio Barabino, Emiliano Maccaferri, Paolo Valente,
	Damien Le Moal, yukuai (C), Jan Kara

On Mar 07, 2023 / 16:57, Yu Kuai wrote:
[...]
> Thanks for the report, can you help to provide the result of add2line of
> following?
> 
> bfq_setup_cooperator+0x120b/0x1650
> bfq_setup_cooperator+0xa41/0x1650
> 
> That will help to locate the problem.

Hi, Yu thanks for looking into this. Here are the faddr2line outputs:

$ ./scripts/faddr2line vmlinux bfq_setup_cooperator+0x120b/0x1650
bfq_setup_cooperator+0x120b/0x1650:
bfqq_process_refs at block/bfq-iosched.c:1200
(inlined by) bfq_setup_stable_merge at block/bfq-iosched.c:2855
(inlined by) bfq_setup_cooperator at block/bfq-iosched.c:2941

$ ./scripts/faddr2line vmlinux bfq_setup_cooperator+0xa41/0x1650
bfq_setup_cooperator+0xa41/0x1650:
bfq_setup_cooperator at block/bfq-iosched.c:2939

-- 
Shin'ichiro Kawasaki

^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: slab-use-after-free in bfq_setup_cooperator
  @ 2023-03-07 10:20 82%       ` Jan Kara
  2023-03-07 10:28 82%         ` Yu Kuai
  0 siblings, 1 reply; 200+ results
From: Jan Kara @ 2023-03-07 10:20 UTC (permalink / raw)
  To: Yu Kuai
  Cc: Shinichiro Kawasaki, linux-block@vger.kernel.org, Gabriele Felici,
	Gianmarco Lusvardi, Giulio Barabino, Emiliano Maccaferri,
	Paolo Valente, Damien Le Moal, Jan Kara, yukuai (C)

On Tue 07-03-23 17:36:19, Yu Kuai wrote:
> Hi,
> 
> 在 2023/03/07 17:13, Shinichiro Kawasaki 写道:
> > On Mar 07, 2023 / 16:57, Yu Kuai wrote:
> > [...]
> > > Thanks for the report, can you help to provide the result of add2line of
> > > following?
> > > 
> > > bfq_setup_cooperator+0x120b/0x1650
> > > bfq_setup_cooperator+0xa41/0x1650
> > > 
> > > That will help to locate the problem.
> > 
> > Hi, Yu thanks for looking into this. Here are the faddr2line outputs:
> > 
> > $ ./scripts/faddr2line vmlinux bfq_setup_cooperator+0x120b/0x1650
> > bfq_setup_cooperator+0x120b/0x1650:
> > bfqq_process_refs at block/bfq-iosched.c:1200
> > (inlined by) bfq_setup_stable_merge at block/bfq-iosched.c:2855
> > (inlined by) bfq_setup_cooperator at block/bfq-iosched.c:2941
> > 
> > $ ./scripts/faddr2line vmlinux bfq_setup_cooperator+0xa41/0x1650
> > bfq_setup_cooperator+0xa41/0x1650:
> > bfq_setup_cooperator at block/bfq-iosched.c:2939
> > 
> 
> So, after a quick look at the code, the difference is that fd571df0ac5b
> changes the logic when bfqq_proces_refs(stable_merge_bfqq) is 0.
> 
> I think perhaps following patch can work, at least 'stable_merge_bfqq'
> won't be accessed after bfq_put_stable_ref() in this case:
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 8a8d4441519c..881f74b3a556 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -2856,6 +2856,11 @@ bfq_setup_stable_merge(struct bfq_data *bfqd, struct
> bfq_queue *bfqq,
>                            bfqq_process_refs(stable_merge_bfqq));
>         struct bfq_queue *new_bfqq;
> 
> +       /* deschedule stable merge, because done or aborted here */
> +       bfq_put_stable_ref(stable_merge_bfqq);
> +
> +       bfqq_data->stable_merge_bfqq = NULL;
> +

I don't think this is going to help. stable_merge_bfqq is used just a few
lines below again in bfq_setup_merge(). The problem really is that the
reference from stable merge can be the last one keeping bfqq alive so in
bfq_setup_cooperator() we need to see if stable_merge_bfqq still has
process references (and cancel the merge if not) before dropping our ref.

So rather doing something like:

		bfqq_data->stable_merge_bfqq = NULL;
		new_bfqq = bfq_setup_stable_merge(bfqd, bfqq,
						  stable_merge_bfqq, bfqq_data);
		bfq_put_stable_ref(stable_merge_bfqq);
		return new_bfqq;

should work in bfq_setup_cooperator().

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: slab-use-after-free in bfq_setup_cooperator
  2023-03-07 10:20 82%       ` Jan Kara
@ 2023-03-07 10:28 82%         ` Yu Kuai
  2023-03-07 11:49 82%           ` Shinichiro Kawasaki
  0 siblings, 1 reply; 200+ results
From: Yu Kuai @ 2023-03-07 10:28 UTC (permalink / raw)
  To: Jan Kara, Yu Kuai
  Cc: Shinichiro Kawasaki, linux-block@vger.kernel.org, Gabriele Felici,
	Gianmarco Lusvardi, Giulio Barabino, Emiliano Maccaferri,
	Paolo Valente, Damien Le Moal, yukuai (C)

Hi, Jan

在 2023/03/07 18:20, Jan Kara 写道:
> On Tue 07-03-23 17:36:19, Yu Kuai wrote:
>> Hi,
>>
>> 在 2023/03/07 17:13, Shinichiro Kawasaki 写道:
>>> On Mar 07, 2023 / 16:57, Yu Kuai wrote:
>>> [...]
>>>> Thanks for the report, can you help to provide the result of add2line of
>>>> following?
>>>>
>>>> bfq_setup_cooperator+0x120b/0x1650
>>>> bfq_setup_cooperator+0xa41/0x1650
>>>>
>>>> That will help to locate the problem.
>>>
>>> Hi, Yu thanks for looking into this. Here are the faddr2line outputs:
>>>
>>> $ ./scripts/faddr2line vmlinux bfq_setup_cooperator+0x120b/0x1650
>>> bfq_setup_cooperator+0x120b/0x1650:
>>> bfqq_process_refs at block/bfq-iosched.c:1200
>>> (inlined by) bfq_setup_stable_merge at block/bfq-iosched.c:2855
>>> (inlined by) bfq_setup_cooperator at block/bfq-iosched.c:2941
>>>
>>> $ ./scripts/faddr2line vmlinux bfq_setup_cooperator+0xa41/0x1650
>>> bfq_setup_cooperator+0xa41/0x1650:
>>> bfq_setup_cooperator at block/bfq-iosched.c:2939
>>>
>>
>> So, after a quick look at the code, the difference is that fd571df0ac5b
>> changes the logic when bfqq_proces_refs(stable_merge_bfqq) is 0.
>>
>> I think perhaps following patch can work, at least 'stable_merge_bfqq'
>> won't be accessed after bfq_put_stable_ref() in this case:
>>
>> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
>> index 8a8d4441519c..881f74b3a556 100644
>> --- a/block/bfq-iosched.c
>> +++ b/block/bfq-iosched.c
>> @@ -2856,6 +2856,11 @@ bfq_setup_stable_merge(struct bfq_data *bfqd, struct
>> bfq_queue *bfqq,
>>                             bfqq_process_refs(stable_merge_bfqq));
>>          struct bfq_queue *new_bfqq;
>>
>> +       /* deschedule stable merge, because done or aborted here */
>> +       bfq_put_stable_ref(stable_merge_bfqq);
>> +
>> +       bfqq_data->stable_merge_bfqq = NULL;
>> +
> 
> I don't think this is going to help. stable_merge_bfqq is used just a few
> lines below again in bfq_setup_merge(). The problem really is that the
> reference from stable merge can be the last one keeping bfqq alive so in
> bfq_setup_cooperator() we need to see if stable_merge_bfqq still has
> process references (and cancel the merge if not) before dropping our ref.

I was thinking that bfq_setup_merge() will only be called if 'proc_ref'
is not 0, which means that stable_merge_bfqq won't be freed.
> 
> So rather doing something like:
> 
> 		bfqq_data->stable_merge_bfqq = NULL;
> 		new_bfqq = bfq_setup_stable_merge(bfqd, bfqq,
> 						  stable_merge_bfqq, bfqq_data);
> 		bfq_put_stable_ref(stable_merge_bfqq);
> 		return new_bfqq;
> 
> should work in bfq_setup_cooperator().

Yes, this will work.

Thanks,
Kuai
> 
> 								Honza
> 


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: slab-use-after-free in bfq_setup_cooperator
  2023-03-07 10:28 82%         ` Yu Kuai
@ 2023-03-07 11:49 82%           ` Shinichiro Kawasaki
  2023-03-07 14:26 82%             ` Jens Axboe
  0 siblings, 1 reply; 200+ results
From: Shinichiro Kawasaki @ 2023-03-07 11:49 UTC (permalink / raw)
  To: Yu Kuai
  Cc: Jan Kara, linux-block@vger.kernel.org, Gabriele Felici,
	Gianmarco Lusvardi, Giulio Barabino, Emiliano Maccaferri,
	Paolo Valente, Damien Le Moal, yukuai (C)

On Mar 07, 2023 / 18:28, Yu Kuai wrote:
> Hi, Jan
> 
> 在 2023/03/07 18:20, Jan Kara 写道:

[...]

> > So rather doing something like:
> > 
> > 		bfqq_data->stable_merge_bfqq = NULL;
> > 		new_bfqq = bfq_setup_stable_merge(bfqd, bfqq,
> > 						  stable_merge_bfqq, bfqq_data);
> > 		bfq_put_stable_ref(stable_merge_bfqq);
> > 		return new_bfqq;
> > 
> > should work in bfq_setup_cooperator().
> 
> Yes, this will work.

Based on the description above, I quickly created the dirty patch below, and
confirmed it avoids the BUG. Looks good. Jan, Yu, thanks for the quick actions.
Let me wait for the formal patch.

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 8a8d4441519c..50eb435efed0 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2932,15 +2932,15 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq,
 					   msecs_to_jiffies(bfq_late_stable_merging))) {
 			struct bfq_queue *stable_merge_bfqq =
 				bfqq_data->stable_merge_bfqq;
+			static struct bfq_queue *new_bfqq;
 
 			/* deschedule stable merge, because done or aborted here */
-			bfq_put_stable_ref(stable_merge_bfqq);
-
 			bfqq_data->stable_merge_bfqq = NULL;
-
-			return bfq_setup_stable_merge(bfqd, bfqq,
-						      stable_merge_bfqq,
-						      bfqq_data);
+			new_bfqq = bfq_setup_stable_merge(bfqd, bfqq,
+							  stable_merge_bfqq,
+							  bfqq_data);
+			bfq_put_stable_ref(stable_merge_bfqq);
+			return new_bfqq;
 		}
 	}
 


-- 
Shin'ichiro Kawasaki

^ permalink raw reply related	[relevance 82%]

* Re: [bug report] BUG: KASAN: slab-use-after-free in bfq_setup_cooperator
  2023-03-07 11:49 82%           ` Shinichiro Kawasaki
@ 2023-03-07 14:26 82%             ` Jens Axboe
  0 siblings, 0 replies; 200+ results
From: Jens Axboe @ 2023-03-07 14:26 UTC (permalink / raw)
  To: Shinichiro Kawasaki, Yu Kuai
  Cc: Jan Kara, linux-block@vger.kernel.org, Gabriele Felici,
	Gianmarco Lusvardi, Giulio Barabino, Emiliano Maccaferri,
	Paolo Valente, Damien Le Moal, yukuai (C)

On 3/7/23 4:49 AM, Shinichiro Kawasaki wrote:
> On Mar 07, 2023 / 18:28, Yu Kuai wrote:
>> Hi, Jan
>>
>> 在 2023/03/07 18:20, Jan Kara 写道:
> 
> [...]
> 
>>> So rather doing something like:
>>>
>>> 		bfqq_data->stable_merge_bfqq = NULL;
>>> 		new_bfqq = bfq_setup_stable_merge(bfqd, bfqq,
>>> 						  stable_merge_bfqq, bfqq_data);
>>> 		bfq_put_stable_ref(stable_merge_bfqq);
>>> 		return new_bfqq;
>>>
>>> should work in bfq_setup_cooperator().
>>
>> Yes, this will work.
> 
> Based on the description above, I quickly created the dirty patch below, and
> confirmed it avoids the BUG. Looks good. Jan, Yu, thanks for the quick actions.
> Let me wait for the formal patch.
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 8a8d4441519c..50eb435efed0 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -2932,15 +2932,15 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq,
>  					   msecs_to_jiffies(bfq_late_stable_merging))) {
>  			struct bfq_queue *stable_merge_bfqq =
>  				bfqq_data->stable_merge_bfqq;
> +			static struct bfq_queue *new_bfqq;
>  
>  			/* deschedule stable merge, because done or aborted here */
> -			bfq_put_stable_ref(stable_merge_bfqq);
> -
>  			bfqq_data->stable_merge_bfqq = NULL;
> -
> -			return bfq_setup_stable_merge(bfqd, bfqq,
> -						      stable_merge_bfqq,
> -						      bfqq_data);
> +			new_bfqq = bfq_setup_stable_merge(bfqd, bfqq,
> +							  stable_merge_bfqq,
> +							  bfqq_data);
> +			bfq_put_stable_ref(stable_merge_bfqq);
> +			return new_bfqq;
>  		}
>  	}

Can you or Jan post this as a real patch so we can get it queued
up?

-- 
Jens Axboe



^ permalink raw reply	[relevance 82%]

* [f2fs-dev] [Bug 215902] kernel BUG at fs/inode.c:611!
       [not found]     <bug-215902-202145@https.bugzilla.kernel.org/>
@ 2023-03-08  7:45 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-03-08  7:45 UTC (permalink / raw)
  To: linux-f2fs-devel

https://bugzilla.kernel.org/show_bug.cgi?id=215902

Monthero Ronald (rhmcruiser@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rhmcruiser@gmail.com

--- Comment #5 from Monthero Ronald (rhmcruiser@gmail.com) ---
And is the panic readily reproducible without the  - 'test_dummy_encryption'
mount option too ?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are on the CC list for the bug.

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[relevance 82%]

* Re: [PATCH v6 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  @ 2023-03-08 15:27 82%   ` Jan Beulich
  2023-03-08 17:25 82%     ` Oleksii
  0 siblings, 1 reply; 200+ results
From: Jan Beulich @ 2023-03-08 15:27 UTC (permalink / raw)
  To: Oleksii Kurochko
  Cc: Julien Grall, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, xen-devel

On 07.03.2023 16:50, Oleksii Kurochko wrote:
> --- a/xen/arch/arm/include/asm/bug.h
> +++ b/xen/arch/arm/include/asm/bug.h
> @@ -1,6 +1,8 @@
>  #ifndef __ARM_BUG_H__
>  #define __ARM_BUG_H__
>  
> +#include <xen/types.h>
> +
>  #if defined(CONFIG_ARM_32)
>  # include <asm/arm32/bug.h>
>  #elif defined(CONFIG_ARM_64)
> @@ -9,10 +11,16 @@
>  # error "unknown ARM variant"
>  #endif
>  
> +#undef BUG_DISP_WIDTH
> +#undef BUG_LINE_LO_WIDTH
> +#undef BUG_LINE_HI_WIDTH

Why? For Arm ...

>  #define BUG_DISP_WIDTH    24
>  #define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
>  #define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)

... you could purge these as unused, even in a standalone prereq patch.
And on x86 ...

> --- a/xen/arch/x86/include/asm/bug.h
> +++ b/xen/arch/x86/include/asm/bug.h
> @@ -1,19 +1,18 @@
>  #ifndef __X86_BUG_H__
>  #define __X86_BUG_H__
>  
> +#undef BUG_DISP_WIDTH
> +#undef BUG_LINE_LO_WIDTH
> +#undef BUG_LINE_HI_WIDTH
> +
>  #define BUG_DISP_WIDTH    24
>  #define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
>  #define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)

... there's no reason to #undef just to the #define again to the same
values. All of this would be removed in a subsequent patch anyway, and
it's less code churn (with code nevertheless being correct) if you get
rid of the #define-s right away (as iirc you had it in an earlier
version). If you agree then with these adjustments
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v6 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-03-08 15:27 82%   ` Jan Beulich
@ 2023-03-08 17:25 82%     ` Oleksii
  2023-03-09  9:49 82%       ` Jan Beulich
  0 siblings, 1 reply; 200+ results
From: Oleksii @ 2023-03-08 17:25 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Julien Grall, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, xen-devel

On Wed, 2023-03-08 at 16:27 +0100, Jan Beulich wrote:
> On 07.03.2023 16:50, Oleksii Kurochko wrote:
> > --- a/xen/arch/arm/include/asm/bug.h
> > +++ b/xen/arch/arm/include/asm/bug.h
> > @@ -1,6 +1,8 @@
> >  #ifndef __ARM_BUG_H__
> >  #define __ARM_BUG_H__
> >  
> > +#include <xen/types.h>
> > +
> >  #if defined(CONFIG_ARM_32)
> >  # include <asm/arm32/bug.h>
> >  #elif defined(CONFIG_ARM_64)
> > @@ -9,10 +11,16 @@
> >  # error "unknown ARM variant"
> >  #endif
> >  
> > +#undef BUG_DISP_WIDTH
> > +#undef BUG_LINE_LO_WIDTH
> > +#undef BUG_LINE_HI_WIDTH
> 
> Why? For Arm ...
> 
> >  #define BUG_DISP_WIDTH    24
> >  #define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> >  #define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
> 
> ... you could purge these as unused, even in a standalone prereq
> patch.
> And on x86 ...
> 
> > --- a/xen/arch/x86/include/asm/bug.h
> > +++ b/xen/arch/x86/include/asm/bug.h
> > @@ -1,19 +1,18 @@
> >  #ifndef __X86_BUG_H__
> >  #define __X86_BUG_H__
> >  
> > +#undef BUG_DISP_WIDTH
> > +#undef BUG_LINE_LO_WIDTH
> > +#undef BUG_LINE_HI_WIDTH
> > +
> >  #define BUG_DISP_WIDTH    24
> >  #define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> >  #define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
> 
> ... there's no reason to #undef just to the #define again to the same
> values. All of this would be removed in a subsequent patch anyway,
> and
> it's less code churn (with code nevertheless being correct) if you
> get
> rid of the #define-s right away (as iirc you had it in an earlier
> version). If you agree then with these adjustments
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

It won't be compilation issue (redefinition) in the current one case
because defines are the same as in <xen/bug.h> so it is possible to not
add #undef in this patch.

~ Oleksii


^ permalink raw reply	[relevance 82%]

* Re: [PATCH v6 2/4] xen: change <asm/bug.h> to <xen/bug.h>
  2023-03-08 17:25 82%     ` Oleksii
@ 2023-03-09  9:49 82%       ` Jan Beulich
  0 siblings, 0 replies; 200+ results
From: Jan Beulich @ 2023-03-09  9:49 UTC (permalink / raw)
  To: Oleksii
  Cc: Julien Grall, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné, xen-devel

On 08.03.2023 18:25, Oleksii wrote:
> On Wed, 2023-03-08 at 16:27 +0100, Jan Beulich wrote:
>> On 07.03.2023 16:50, Oleksii Kurochko wrote:
>>> --- a/xen/arch/arm/include/asm/bug.h
>>> +++ b/xen/arch/arm/include/asm/bug.h
>>> @@ -1,6 +1,8 @@
>>>  #ifndef __ARM_BUG_H__
>>>  #define __ARM_BUG_H__
>>>  
>>> +#include <xen/types.h>
>>> +
>>>  #if defined(CONFIG_ARM_32)
>>>  # include <asm/arm32/bug.h>
>>>  #elif defined(CONFIG_ARM_64)
>>> @@ -9,10 +11,16 @@
>>>  # error "unknown ARM variant"
>>>  #endif
>>>  
>>> +#undef BUG_DISP_WIDTH
>>> +#undef BUG_LINE_LO_WIDTH
>>> +#undef BUG_LINE_HI_WIDTH
>>
>> Why? For Arm ...
>>
>>>  #define BUG_DISP_WIDTH    24
>>>  #define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
>>>  #define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
>>
>> ... you could purge these as unused, even in a standalone prereq
>> patch.
>> And on x86 ...
>>
>>> --- a/xen/arch/x86/include/asm/bug.h
>>> +++ b/xen/arch/x86/include/asm/bug.h
>>> @@ -1,19 +1,18 @@
>>>  #ifndef __X86_BUG_H__
>>>  #define __X86_BUG_H__
>>>  
>>> +#undef BUG_DISP_WIDTH
>>> +#undef BUG_LINE_LO_WIDTH
>>> +#undef BUG_LINE_HI_WIDTH
>>> +
>>>  #define BUG_DISP_WIDTH    24
>>>  #define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
>>>  #define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
>>
>> ... there's no reason to #undef just to the #define again to the same
>> values. All of this would be removed in a subsequent patch anyway,
>> and
>> it's less code churn (with code nevertheless being correct) if you
>> get
>> rid of the #define-s right away (as iirc you had it in an earlier
>> version). If you agree then with these adjustments
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> It won't be compilation issue (redefinition) in the current one case
> because defines are the same as in <xen/bug.h> so it is possible to not
> add #undef in this patch.

Avoiding to add the #undef is the minimal approach. Yet as indicated I
think the #define-s should also be dropped right here (x86) and in a
prereq patch (Arm).

Jan


^ permalink raw reply	[relevance 82%]

* [Bug 217216] [Syzkaller & bisect] There is BUG: unable to handle kernel NULL pointer dereference in xfs_filestream_select_ag in v6.3-rc3
  @ 2023-03-20  8:32 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-03-20  8:32 UTC (permalink / raw)
  To: linux-xfs

https://bugzilla.kernel.org/show_bug.cgi?id=217216

--- Comment #1 from xupengfe (pengfei.xu@intel.com) ---
Related community link:
https://lore.kernel.org/linux-xfs/ZBgCH%2F8EguhJkwPI@xpf.sh.intel.com/T/#u

Thanks!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 217247] BUG: kernel NULL pointer dereference, address: 000000000000000c / speculation_ctrl_update
    2023-03-30 17:41 82% ` [Bug 217247] " bugzilla-daemon
@ 2023-03-25 13:59 82% ` bugzilla-daemon
  1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-03-25 13:59 UTC (permalink / raw)
  To: kvm

https://bugzilla.kernel.org/show_bug.cgi?id=217247

--- Comment #1 from Sami Farin (hvtaifwkbgefbaei@gmail.com) ---
Created attachment 304024
  --> https://bugzilla.kernel.org/attachment.cgi?id=304024&action=edit
lspci

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 217247] BUG: kernel NULL pointer dereference, address: 000000000000000c / speculation_ctrl_update
  @ 2023-03-30 17:41 82% ` bugzilla-daemon
  2023-03-25 13:59 82% ` bugzilla-daemon
  1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-03-30 17:41 UTC (permalink / raw)
  To: kvm

https://bugzilla.kernel.org/show_bug.cgi?id=217247

--- Comment #3 from Sami Farin (hvtaifwkbgefbaei@gmail.com) ---
Thanks. I am now running 6.1.22 with that patch applied.

The only difference in kernel messages 6.1.21 → 6.1.22:
 smpboot: SMP disabled
+smpboot: CPU0: AMD Ryzen 5 1600X Six-Core Processor (family: 0x17, model: 0x1,
stepping: 0x1)

qemu works OK so far (only 30 minutes of usage so far)...

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [PATCH v9 3/5] xen: change <asm/bug.h> to <xen/bug.h>
  @ 2023-03-31 20:36 82%   ` Julien Grall
  0 siblings, 0 replies; 200+ results
From: Julien Grall @ 2023-03-31 20:36 UTC (permalink / raw)
  To: Oleksii Kurochko, xen-devel
  Cc: Jan Beulich, Andrew Cooper, Stefano Stabellini, Gianluca Guida,
	Bertrand Marquis, Volodymyr Babchuk, George Dunlap, Wei Liu,
	Roger Pau Monné

Hi Oleksii,

On 29/03/2023 11:50, Oleksii Kurochko wrote:
> The idea of the patch is to change all <asm/bug.h> to <xen/bug.h> and
> keep Xen compilable with adding only minimal amount of changes:
> 1. It was added "#include <xen/types.h>" to ARM's "<asm/bug.h>" as it
>    uses uint_{16,32}t in 'struct bug_frame'.
> 2. It was added '#define BUG_FRAME_STRUCT' which means that ARM hasn't
>    been switched to generic implementation yet.
> 3. It was added '#define BUG_FRAME_STRUCT' which means that x86 hasn't
>    been switched to generic implementation yet.
> 4. BUGFRAME_* and _start_bug_frame[], _stop_bug_frame_*[] were removed
>    for ARM & x86 to deal with compilation errors such as:
>        redundant redeclaration of ...
> 5. Remove BUG_DISP_WIDTH, BUG_LINE_LO_WIDTH, BUG_LINE_HI_WIDTH from
>    x86's <asm.bug.h> to not to produce #undef for them and #define again
>    with the same values as in <xen/bug.h>. These #undef and #define will
>    be anyway removed in the patch [2]
> 6. Remove <asm/bug.h> from <x86/acpi/cpufreq/cpufreq.c> and
>    <drivers/cpufreq/cpufreq.c> as nothing from <xen/bug.h> are used in
>    <*/cpufreq.c>
> 
> In the following two patches x86 and ARM archictectures will be
> switched fully:
> [1] xen/arm: switch ARM to use generic implementation of bug.h
> [2] xen/x86: switch x86 to use generic implemetation of bug.h
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall


^ permalink raw reply	[relevance 82%]

* Re: [PATCH] soundwire: amd: fix an IS_ERR() vs NULL bug
  @ 2023-04-06 12:02 82% ` Mukunda,Vijendar via Alsa-devel
  0 siblings, 0 replies; 200+ results
From: Mukunda,Vijendar via Alsa-devel @ 2023-04-06 12:02 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Bard Liao, Pierre-Louis Bossart, Sanyog Kale, alsa-devel,
	kernel-janitors


[-- Attachment #0: Type: message/rfc822, Size: 11504 bytes --]

From: "Mukunda,Vijendar" <vijendar.mukunda@amd.com>
To: Dan Carpenter <error27@gmail.com>
Cc: Bard Liao <yung-chuan.liao@linux.intel.com>, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, Sanyog Kale <sanyog.r.kale@intel.com>, alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] soundwire: amd: fix an IS_ERR() vs NULL bug
Date: Thu, 6 Apr 2023 17:32:21 +0530
Message-ID: <701bef7f-77bb-63a6-429f-1293519a6b21@amd.com>

On 06/04/23 14:26, Dan Carpenter wrote:
> The devm_ioremap() function returns NULL on error.  It never returns
> error pointers.  Update the error checking accordingly.
>
> Fixes: a673a8dfc214 ("soundwire: amd: Add support for AMD Manager driver")
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
>  drivers/soundwire/amd_manager.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soundwire/amd_manager.c b/drivers/soundwire/amd_manager.c
> index 9fb7f91ca182..9bb8ae8c5f32 100644
> --- a/drivers/soundwire/amd_manager.c
> +++ b/drivers/soundwire/amd_manager.c
> @@ -910,9 +910,9 @@ static int amd_sdw_manager_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	amd_manager->acp_mmio = devm_ioremap(dev, res->start, resource_size(res));
> -	if (IS_ERR(amd_manager->mmio)) {
> +	if (!amd_manager->mmio) {
This will break the functionality.  Condition should be
if (!amd_manager->acp_mmio)

>  		dev_err(dev, "mmio not found\n");
> -		return PTR_ERR(amd_manager->mmio);
> +		return -ENOMEM;
>  	}
>  	amd_manager->instance = pdata->instance;
>  	amd_manager->mmio = amd_manager->acp_mmio +


^ permalink raw reply	[relevance 82%]

* Re: BUG: drivers/net/wireless: iwlwifi: IWL Error: "BUG: kernel NULL pointer dereference, address: 0000000000000150"
  @ 2023-04-11  8:47 82%   ` Greenman, Gregory
    0 siblings, 1 reply; 200+ results
From: Greenman, Gregory @ 2023-04-11  8:47 UTC (permalink / raw)
  To: linux-wireless@vger.kernel.org, mirsad.todorovac@alu.unizg.hr,
	netdev@vger.kernel.org
  Cc: kvalo@kernel.org, edumazet@google.com, davem@davemloft.net,
	kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org

On Mon, 2023-04-10 at 01:43 +0200, Mirsad Goran Todorovac wrote:
> On 10. 04. 2023. 00:21, Mirsad Goran Todorovac wrote:
> > Hi all,
> > 
> > This is an error is the syslog found after investigating a Youtube FF chirping hang
> > while running kseftest of 6.3-rc6 torvalds tree kernel.
> > 
> > Running multimedia and kselftest might seem off, but multimedia performance on Linux
> > and open source software is a very interesting research area.
> > 
> > Here is the trace from the log:
> > 
> > Apr  9 23:01:11 marvin-IdeaPad-3-15ITL6 kernel: [  615.957145] mmiotrace: disabled.
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.881758] iwlwifi 0000:00:14.3: Error sending STATISTICS_CMD: time out after 2000ms.
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.882332] iwlwifi 0000:00:14.3: Current CMD queue read_ptr 67 write_ptr 68
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884299] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884373] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884446] iwlwifi 0000:00:14.3: Loaded firmware version: 73.35c0a2c6.0 QuZ-a0-jf-b0-73.ucode
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884520] iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN       
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884624] iwlwifi 0000:00:14.3: 0x000022F0 | trm_hw_status0
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884695] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884766] iwlwifi 0000:00:14.3: 0x004C352E | branchlink2
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884837] iwlwifi 0000:00:14.3: 0x004BA12A | interruptlink1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884907] iwlwifi 0000:00:14.3: 0x004BA12A | interruptlink2
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885309] iwlwifi 0000:00:14.3: 0x0000CEEA | data1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885444] iwlwifi 0000:00:14.3: 0x01000000 | data2
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885526] iwlwifi 0000:00:14.3: 0x00000000 | data3
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885598] iwlwifi 0000:00:14.3: 0x840075C7 | beacon time
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885670] iwlwifi 0000:00:14.3: 0x5282AA44 | tsf low
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885741] iwlwifi 0000:00:14.3: 0x00000082 | tsf hi
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885812] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885885] iwlwifi 0000:00:14.3: 0x24D400DC | time gp2
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885963] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886040] iwlwifi 0000:00:14.3: 0x00000049 | uCode version major
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886117] iwlwifi 0000:00:14.3: 0x35C0A2C6 | uCode version minor
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886193] iwlwifi 0000:00:14.3: 0x00000351 | hw version
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886268] iwlwifi 0000:00:14.3: 0x00489001 | board version
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886344] iwlwifi 0000:00:14.3: 0x80B3F400 | hcmd
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886420] iwlwifi 0000:00:14.3: 0x00020000 | isr0
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886496] iwlwifi 0000:00:14.3: 0x00000000 | isr1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886632] iwlwifi 0000:00:14.3: 0x08F00002 | isr2
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886750] iwlwifi 0000:00:14.3: 0x00C3028C | isr3
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886889] iwlwifi 0000:00:14.3: 0x00000000 | isr4
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887035] iwlwifi 0000:00:14.3: 0x05C8001C | last cmd Id
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887180] iwlwifi 0000:00:14.3: 0x0000CEEA | wait_event
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887326] iwlwifi 0000:00:14.3: 0x00000854 | l2p_control
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887467] iwlwifi 0000:00:14.3: 0x00000020 | l2p_duration
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887610] iwlwifi 0000:00:14.3: 0x0000000F | l2p_mhvalid
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887756] iwlwifi 0000:00:14.3: 0x00000000 | l2p_addr_match
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887895] iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.888150] iwlwifi 0000:00:14.3: 0x00000000 | timestamp
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.888288] iwlwifi 0000:00:14.3: 0x00006868 | flow_handler
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.888730] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.888867] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 7
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889159] iwlwifi 0000:00:14.3: 0x20000066 | NMI_INTERRUPT_HOST
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889306] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889450] iwlwifi 0000:00:14.3: 0x80453B88 | umac branchlink2
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889594] iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889740] iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink2
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889886] iwlwifi 0000:00:14.3: 0x01000000 | umac data1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890033] iwlwifi 0000:00:14.3: 0x8046FE32 | umac data2
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890176] iwlwifi 0000:00:14.3: 0x00000000 | umac data3
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890323] iwlwifi 0000:00:14.3: 0x00000049 | umac major
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890468] iwlwifi 0000:00:14.3: 0x35C0A2C6 | umac minor
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890613] iwlwifi 0000:00:14.3: 0x24D400DA | frame pointer
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890759] iwlwifi 0000:00:14.3: 0xC0886264 | stack pointer
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890905] iwlwifi 0000:00:14.3: 0x0043019C | last host cmd
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891050] iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891323] iwlwifi 0000:00:14.3: IML/ROM dump:
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891469] iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891731] iwlwifi 0000:00:14.3: 0x000053F8 | IML/ROM data1
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891997] iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.892216] iwlwifi 0000:00:14.3: Fseq Registers:
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.893775] iwlwifi 0000:00:14.3: 0x60000000 | FSEQ_ERROR_CODE
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.893927] iwlwifi 0000:00:14.3: 0x80260000 | FSEQ_TOP_INIT_VERSION
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894077] iwlwifi 0000:00:14.3: 0x00020006 | FSEQ_CNVIO_INIT_VERSION
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894227] iwlwifi 0000:00:14.3: 0x0000A384 | FSEQ_OTP_VERSION
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894374] iwlwifi 0000:00:14.3: 0x3D544A68 | FSEQ_TOP_CONTENT_VERSION
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894526] iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894675] iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894826] iwlwifi 0000:00:14.3: 0x01300202 | FSEQ_CNVR_ID
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894976] iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.895129] iwlwifi 0000:00:14.3: 0x01300202 | CNVR_AUX_MISC_CHIP
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.895282] iwlwifi 0000:00:14.3: 0x0000485B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.895463] iwlwifi 0000:00:14.3: 0xA5A5A5A2 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.898477] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
> > Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.899785] ieee80211 phy0: Hardware restart was requested
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.878162] iwlwifi 0000:00:14.3: HCMD_ACTIVE already clear for command STATISTICS_CMD
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.878273] iwlwifi 0000:00:14.3: Hardware error detected. Restarting.
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.881860] ------------[ cut here ]------------
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.882201] WARNING: CPU: 5 PID: 47 at drivers/net/wireless/intel/iwlwifi/mvm/../iwl-trans.h:1200 iwl_mvm_rx_tx_cmd+0xc65/0xd50 [iwlmvm]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.882380] Modules linked in: ftrace_direct ccm rfcomm snd_seq_dummy snd_hrtimer cmac algif_skcipher snd_ctl_led snd_soc_skl_hda_dsp
> > snd_soc_intel_hda_dsp_common snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio bnep joydev uvcvideo videobuf2_vmalloc btusb uvc
> > videobuf2_memops btrtl videobuf2_v4l2 btbcm videodev btintel btmtk usbhid videobuf2_common bluetooth mc ecdh_generic ecc snd_soc_dmic snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel
> > soundwire_generic_allocation soundwire_cadence hid_multitouch snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof hid_generic snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core
> > snd_soc_acpi_intel_match snd_soc_acpi intel_tcc_cooling soundwire_bus x86_pkg_temp_thermal sunrpc mei_pxp intel_powerclamp mei_hdcp snd_soc_core snd_compress coretemp ac97_bus spi_pxa2xx_platform
> > crct10dif_pclmul snd_pcm_dmaengine dw_dmac crc32_pclmul dw_dmac_core ghash_clmulni_intel snd_hda_intel sha512_ssse3 8250_dw
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.885849]  snd_intel_dspcfg snd_intel_sdw_acpi aesni_intel crypto_simd wmi_bmof snd_hda_codec cryptd binfmt_misc snd_hda_core rapl snd_hwdep
> > pmt_telemetry intel_rapl_msr pmt_class intel_cstate snd_pcm i2c_hid_acpi i915 iwlmvm i2c_hid snd_seq_midi snd_seq_midi_event nls_iso8859_1 snd_rawmidi mac80211 drm_buddy libarc4 ttm snd_seq
> > drm_display_helper processor_thermal_device_pci_legacy cec snd_seq_device ideapad_laptop snd_timer btrfs sparse_keymap processor_thermal_device drm_kms_helper iwlwifi platform_profile
> > processor_thermal_rfim processor_thermal_mbox int3400_thermal mei_me blake2b_generic xhci_pci xor processor_thermal_rapl video wmi acpi_thermal_rel mei acpi_tad i2c_algo_bit acpi_pad
> > int3403_thermal intel_rapl_common snd xhci_pci_renesas i2c_i801 syscopyarea ahci cfg80211 intel_vsec int340x_thermal_zone intel_lpss_pci sysfillrect soundcore i2c_smbus intel_lpss sysimgblt
> > intel_soc_dts_iosf libahci igen6_edac idma64 raid6_pq msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone drm
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.886823]  efi_pstore ip_tables x_tables autofs4 nvme nvme_core input_leds vmd serio_raw mac_hid pinctrl_tigerlake [last unloaded:
> > ftrace_direct]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.886986] CPU: 5 PID: 47 Comm: ksoftirqd/5 Not tainted 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887006] Hardware name: LENOVO 82H8/LNVNB161216, BIOS GGCN51WW 11/16/2022
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887022] RIP: 0010:iwl_mvm_rx_tx_cmd+0xc65/0xd50 [iwlmvm]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887096] Code: 85 c0 74 0d 0f b6 40 27 89 f1 21 c1 84 c0 0f 45 f1 40 0f b6 f6 4c 89 ff e8 e8 3f ff ff 41 88 84 24 7e 14 00 00 e9 7c fe ff ff
> > <0f> 0b 48 8b 7f 40 48 c7 c1 10 ba fa c0 48 c7 c2 58 ce fb c0 31 f6
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887114] RSP: 0018:ffffb60200267b70 EFLAGS: 00010293
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887142] RAX: 0000000000001c80 RBX: ffff8b5af378c000 RCX: 0000000000000005
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887159] RDX: 0000000000000000 RSI: ffffb60200267bb0 RDI: ffff8b5a8ff20028
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887174] RBP: ffffb60200267c40 R08: 0000000000000000 R09: 0000000000000001
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887189] R10: ffffb60200267c58 R11: 0000000000000000 R12: 0000000000000000
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887205] R13: 0000000000000030 R14: ffffb60200267d18 R15: ffff8b5aa39d33e8
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887221] FS:  0000000000000000(0000) GS:ffff8b5c27a80000(0000) knlGS:0000000000000000
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887238] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887255] CR2: 00007f49f4dfe008 CR3: 000000017d850001 CR4: 0000000000f70ee0
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887271] PKRU: 55555554
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887286] Call Trace:
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887302]  <TASK>
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887359]  ? __pfx_iwl_mvm_rx_tx_cmd+0x10/0x10 [iwlmvm]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887446]  ? iwl_mvm_rx_tx_cmd+0x9/0xd50 [iwlmvm]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887540]  ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887563]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887582]  ? iwl_mvm_rx_common+0xde/0x390 [iwlmvm]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887650]  ? iwl_mvm_rx_mq+0x9/0xc0 [iwlmvm]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887739]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887757]  iwl_mvm_rx_mq+0x79/0xc0 [iwlmvm]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887821]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887839]  iwl_pcie_rx_handle+0x402/0xaa0 [iwlwifi]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887979]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887997]  iwl_pcie_napi_poll_msix+0x39/0xf0 [iwlwifi]
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888086]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888105]  __napi_poll+0x2e/0x1f0
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888146]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888164]  net_rx_action+0x1a5/0x330
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888240]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888258]  __do_softirq+0xb4/0x3a4
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888311]  ? smpboot_thread_fn+0x2a/0x290
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888340]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888358]  run_ksoftirqd+0x44/0x80
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888382]  ? ftrace_regs_caller_end+0x66/0x66
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888400]  smpboot_thread_fn+0x1d9/0x290
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888435]  ? __pfx_smpboot_thread_fn+0x10/0x10
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888458]  kthread+0x10f/0x140
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888481]  ? __pfx_kthread+0x10/0x10
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888517]  ret_from_fork+0x29/0x50
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888609]  </TASK>
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888623] irq event stamp: 4206602
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888636] hardirqs last  enabled at (4206608): [<ffffffffb9a51c98>] __up_console_sem+0x68/0x80
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888657] hardirqs last disabled at (4206613): [<ffffffffb9a51c7d>] __up_console_sem+0x4d/0x80
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888676] softirqs last  enabled at (4196852): [<ffffffffb9965b60>] return_to_handler+0x0/0x40
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888695] softirqs last disabled at (4196891): [<ffffffffb9965b60>] return_to_handler+0x0/0x40
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888714] ---[ end trace 0000000000000000 ]---
> > Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888732] iwlwifi 0000:00:14.3: iwl_trans_reclaim bad state = 0
> > 
> > Hope this helps.
> > 
> > The platform is Ubuntu 22.10 kinetic kudu on Lenovo IdeaPad 3 15ITL6,
> > the above mentioned 6.3-rc6 torvalds tree kernel and GGCN51WW original
> > Lenovo BIOS.
> > 
> > Please find the config and the lshw output and this listing at the URL:
> > 
> > → https://domac.alu.unizg.hr/~mtodorov/linux/bugreports/intel/iwlwifi/
> 
> The fault was reproduced while running complete "make kselftest" and having
> at the same time Firefox with 100+ tabs and 2 Youtube tabs running.
> 
> Apr 10 00:32:16 marvin-IdeaPad-3-15ITL6 kernel: mmiotrace: disabled.
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Error sending STATISTICS_CMD: time out after 2000ms.
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Current CMD queue read_ptr 54 write_ptr 55
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Loaded firmware version: 73.35c0a2c6.0 QuZ-a0-jf-b0-73.ucode
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN       
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x1080A200 | trm_hw_status0
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00010000 | trm_hw_status1
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x004C352E | branchlink2
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000638C | interruptlink1
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000638C | interruptlink2
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00011864 | data1
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01000000 | data2
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | data3
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x5F008D9F | beacon time
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x9892726D | tsf low
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000083 | tsf hi
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00008D3B | time gp1
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x2124C243 | time gp2
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000049 | uCode version major
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x35C0A2C6 | uCode version minor
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000351 | hw version
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00489001 | board version
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0489001C | hcmd
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xE682B000 | isr0
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x09040000 | isr1
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x08F0011A | isr2
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00C3028C | isr3
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | isr4
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0488001C | last cmd Id
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00011864 | wait_event
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x000000C4 | l2p_control
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00018034 | l2p_duration
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000007 | l2p_mhvalid
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000081 | l2p_addr_match
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | timestamp
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000808 | flow_handler
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 7
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000066 | NMI_INTERRUPT_HOST
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x80453B88 | umac branchlink2
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink1
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink2
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01000000 | umac data1
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac data2
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | umac data3
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000049 | umac major
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x35C0A2C6 | umac minor
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x2124C241 | frame pointer
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xC0886264 | stack pointer
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0036019C | last host cmd
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: IML/ROM dump:
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00005404 | IML/ROM data1
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Fseq Registers:
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x60000000 | FSEQ_ERROR_CODE
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x80260000 | FSEQ_TOP_INIT_VERSION
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00020006 | FSEQ_CNVIO_INIT_VERSION
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000A384 | FSEQ_OTP_VERSION
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x3D544A68 | FSEQ_TOP_CONTENT_VERSION
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01300202 | FSEQ_CNVR_ID
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01300202 | CNVR_AUX_MISC_CHIP
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000485B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xA5A5A5A2 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: ieee80211 phy0: Hardware restart was requested
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Hardware error detected. Restarting.
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: BUG: Apr 10 00:32:16 marvin-IdeaPad-3-15ITL6 kernel: mmiotrace: disabled.
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Error sending STATISTICS_CMD: time out after 2000ms.
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Current CMD queue read_ptr 54 write_ptr 55
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Loaded firmware version: 73.35c0a2c6.0 QuZ-a0-jf-b0-73.ucode
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN       
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x1080A200 | trm_hw_status0
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00010000 | trm_hw_status1
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x004C352E | branchlink2
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000638C | interruptlink1
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000638C | interruptlink2
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00011864 | data1
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01000000 | data2
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | data3
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x5F008D9F | beacon time
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x9892726D | tsf low
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000083 | tsf hi
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00008D3B | time gp1
> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x2124C243 | time gp2
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000049 | uCode version major
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x35C0A2C6 | uCode version minor
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000351 | hw version
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00489001 | board version
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0489001C | hcmd
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xE682B000 | isr0
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x09040000 | isr1
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x08F0011A | isr2
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00C3028C | isr3
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | isr4
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0488001C | last cmd Id
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00011864 | wait_event
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x000000C4 | l2p_control
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00018034 | l2p_duration
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000007 | l2p_mhvalid
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000081 | l2p_addr_match
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | timestamp
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000808 | flow_handler
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 7
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000066 | NMI_INTERRUPT_HOST
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x80453B88 | umac branchlink2
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink1
> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink2
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01000000 | umac data1
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac data2
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | umac data3
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000049 | umac major
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x35C0A2C6 | umac minor
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x2124C241 | frame pointer
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xC0886264 | stack pointer
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0036019C | last host cmd
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: IML/ROM dump:
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00005404 | IML/ROM data1
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Fseq Registers:
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x60000000 | FSEQ_ERROR_CODE
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x80260000 | FSEQ_TOP_INIT_VERSION
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00020006 | FSEQ_CNVIO_INIT_VERSION
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000A384 | FSEQ_OTP_VERSION
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x3D544A68 | FSEQ_TOP_CONTENT_VERSION
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01300202 | FSEQ_CNVR_ID
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01300202 | CNVR_AUX_MISC_CHIP
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000485B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xA5A5A5A2 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: ieee80211 phy0: Hardware restart was requested
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Hardware error detected. Restarting.
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: #PF: supervisor read access in kernel mode
> -- Boot 60997fcc74c1448a967138e3f6d00cbf --
> Apr 10 00:34:49 marvin-IdeaPad-3-15ITL6 kernel: microcode: updated early: 0xa4 -> 0xa6, date = 2022-06-28
> 
> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: #PF: supervisor read access in kernel mode
> -- Boot 60997fcc74c1448a967138e3f6d00cbf --
> Apr 10 00:34:49 marvin-IdeaPad-3-15ITL6 kernel: microcode: updated early: 0xa4 -> 0xa6, date = 2022-06-28
> 
> I will add "make kselftest" log to the directory with lshw and config.
> 
> Best regards,
> Mirsad
> 
Thanks for the report!
The kernel stack there is not a real kernel crash, but is a result of a WARN_ON() in the code.
However, there's a kernel NULL pointer deref later. Can I ask you to collect a log of the
crash itself? Maybe with netconsole if the machine completely crashes?

Thanks,
Gregory

^ permalink raw reply	[relevance 82%]

* Re: BUG: drivers/net/wireless: iwlwifi: IWL Error: "BUG: kernel NULL pointer dereference, address: 0000000000000150"
  @ 2023-04-13  6:38 82%       ` Mirsad Goran Todorovac
  0 siblings, 0 replies; 200+ results
From: Mirsad Goran Todorovac @ 2023-04-13  6:38 UTC (permalink / raw)
  To: Greenman, Gregory, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org
  Cc: kvalo@kernel.org, edumazet@google.com, davem@davemloft.net,
	kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org

On 12.4.2023. 13:46, Mirsad Todorovac wrote:
> On 4/11/23 10:47, Greenman, Gregory wrote:
>> On Mon, 2023-04-10 at 01:43 +0200, Mirsad Goran Todorovac wrote:
>>> On 10. 04. 2023. 00:21, Mirsad Goran Todorovac wrote:
>>>> Hi all,
>>>>
>>>> This is an error is the syslog found after investigating a Youtube FF chirping hang
>>>> while running kseftest of 6.3-rc6 torvalds tree kernel.
>>>>
>>>> Running multimedia and kselftest might seem off, but multimedia performance on Linux
>>>> and open source software is a very interesting research area.
>>>>
>>>> Here is the trace from the log:
>>>>
>>>> Apr  9 23:01:11 marvin-IdeaPad-3-15ITL6 kernel: [  615.957145] mmiotrace: disabled.
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.881758] iwlwifi 0000:00:14.3: Error sending STATISTICS_CMD: time out 
>>>> after 2000ms.
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.882332] iwlwifi 0000:00:14.3: Current CMD queue read_ptr 67 write_ptr 68
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884299] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884373] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884446] iwlwifi 0000:00:14.3: Loaded firmware version: 73.35c0a2c6.0 
>>>> QuZ-a0-jf-b0-73.ucode
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884520] iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884624] iwlwifi 0000:00:14.3: 0x000022F0 | trm_hw_status0
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884695] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884766] iwlwifi 0000:00:14.3: 0x004C352E | branchlink2
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884837] iwlwifi 0000:00:14.3: 0x004BA12A | interruptlink1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.884907] iwlwifi 0000:00:14.3: 0x004BA12A | interruptlink2
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885309] iwlwifi 0000:00:14.3: 0x0000CEEA | data1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885444] iwlwifi 0000:00:14.3: 0x01000000 | data2
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885526] iwlwifi 0000:00:14.3: 0x00000000 | data3
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885598] iwlwifi 0000:00:14.3: 0x840075C7 | beacon time
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885670] iwlwifi 0000:00:14.3: 0x5282AA44 | tsf low
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885741] iwlwifi 0000:00:14.3: 0x00000082 | tsf hi
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885812] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885885] iwlwifi 0000:00:14.3: 0x24D400DC | time gp2
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.885963] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886040] iwlwifi 0000:00:14.3: 0x00000049 | uCode version major
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886117] iwlwifi 0000:00:14.3: 0x35C0A2C6 | uCode version minor
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886193] iwlwifi 0000:00:14.3: 0x00000351 | hw version
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886268] iwlwifi 0000:00:14.3: 0x00489001 | board version
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886344] iwlwifi 0000:00:14.3: 0x80B3F400 | hcmd
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886420] iwlwifi 0000:00:14.3: 0x00020000 | isr0
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886496] iwlwifi 0000:00:14.3: 0x00000000 | isr1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886632] iwlwifi 0000:00:14.3: 0x08F00002 | isr2
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886750] iwlwifi 0000:00:14.3: 0x00C3028C | isr3
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.886889] iwlwifi 0000:00:14.3: 0x00000000 | isr4
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887035] iwlwifi 0000:00:14.3: 0x05C8001C | last cmd Id
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887180] iwlwifi 0000:00:14.3: 0x0000CEEA | wait_event
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887326] iwlwifi 0000:00:14.3: 0x00000854 | l2p_control
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887467] iwlwifi 0000:00:14.3: 0x00000020 | l2p_duration
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887610] iwlwifi 0000:00:14.3: 0x0000000F | l2p_mhvalid
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887756] iwlwifi 0000:00:14.3: 0x00000000 | l2p_addr_match
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.887895] iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.888150] iwlwifi 0000:00:14.3: 0x00000000 | timestamp
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.888288] iwlwifi 0000:00:14.3: 0x00006868 | flow_handler
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.888730] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.888867] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 7
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889159] iwlwifi 0000:00:14.3: 0x20000066 | NMI_INTERRUPT_HOST
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889306] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889450] iwlwifi 0000:00:14.3: 0x80453B88 | umac branchlink2
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889594] iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889740] iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink2
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.889886] iwlwifi 0000:00:14.3: 0x01000000 | umac data1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890033] iwlwifi 0000:00:14.3: 0x8046FE32 | umac data2
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890176] iwlwifi 0000:00:14.3: 0x00000000 | umac data3
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890323] iwlwifi 0000:00:14.3: 0x00000049 | umac major
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890468] iwlwifi 0000:00:14.3: 0x35C0A2C6 | umac minor
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890613] iwlwifi 0000:00:14.3: 0x24D400DA | frame pointer
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890759] iwlwifi 0000:00:14.3: 0xC0886264 | stack pointer
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.890905] iwlwifi 0000:00:14.3: 0x0043019C | last host cmd
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891050] iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891323] iwlwifi 0000:00:14.3: IML/ROM dump:
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891469] iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891731] iwlwifi 0000:00:14.3: 0x000053F8 | IML/ROM data1
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.891997] iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.892216] iwlwifi 0000:00:14.3: Fseq Registers:
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.893775] iwlwifi 0000:00:14.3: 0x60000000 | FSEQ_ERROR_CODE
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.893927] iwlwifi 0000:00:14.3: 0x80260000 | FSEQ_TOP_INIT_VERSION
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894077] iwlwifi 0000:00:14.3: 0x00020006 | FSEQ_CNVIO_INIT_VERSION
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894227] iwlwifi 0000:00:14.3: 0x0000A384 | FSEQ_OTP_VERSION
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894374] iwlwifi 0000:00:14.3: 0x3D544A68 | FSEQ_TOP_CONTENT_VERSION
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894526] iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894675] iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894826] iwlwifi 0000:00:14.3: 0x01300202 | FSEQ_CNVR_ID
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.894976] iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.895129] iwlwifi 0000:00:14.3: 0x01300202 | CNVR_AUX_MISC_CHIP
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.895282] iwlwifi 0000:00:14.3: 0x0000485B | 
>>>> CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.895463] iwlwifi 0000:00:14.3: 0xA5A5A5A2 | 
>>>> CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.898477] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired 
>>>> (delay=0ms).
>>>> Apr  9 23:01:25 marvin-IdeaPad-3-15ITL6 kernel: [  629.899785] ieee80211 phy0: Hardware restart was requested
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.878162] iwlwifi 0000:00:14.3: HCMD_ACTIVE already clear for command 
>>>> STATISTICS_CMD
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.878273] iwlwifi 0000:00:14.3: Hardware error detected. Restarting.
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.881860] ------------[ cut here ]------------
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.882201] WARNING: CPU: 5 PID: 47 at 
>>>> drivers/net/wireless/intel/iwlwifi/mvm/../iwl-trans.h:1200 iwl_mvm_rx_tx_cmd+0xc65/0xd50 [iwlmvm]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.882380] Modules linked in: ftrace_direct ccm rfcomm snd_seq_dummy 
>>>> snd_hrtimer cmac algif_skcipher snd_ctl_led snd_soc_skl_hda_dsp
>>>> snd_soc_intel_hda_dsp_common snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic 
>>>> ledtrig_audio bnep joydev uvcvideo videobuf2_vmalloc btusb uvc
>>>> videobuf2_memops btrtl videobuf2_v4l2 btbcm videodev btintel btmtk usbhid videobuf2_common bluetooth mc ecdh_generic ecc 
>>>> snd_soc_dmic snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel
>>>> soundwire_generic_allocation soundwire_cadence hid_multitouch snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof 
>>>> hid_generic snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core
>>>> snd_soc_acpi_intel_match snd_soc_acpi intel_tcc_cooling soundwire_bus x86_pkg_temp_thermal sunrpc mei_pxp intel_powerclamp 
>>>> mei_hdcp snd_soc_core snd_compress coretemp ac97_bus spi_pxa2xx_platform
>>>> crct10dif_pclmul snd_pcm_dmaengine dw_dmac crc32_pclmul dw_dmac_core ghash_clmulni_intel snd_hda_intel sha512_ssse3 8250_dw
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.885849]  snd_intel_dspcfg snd_intel_sdw_acpi aesni_intel crypto_simd 
>>>> wmi_bmof snd_hda_codec cryptd binfmt_misc snd_hda_core rapl snd_hwdep
>>>> pmt_telemetry intel_rapl_msr pmt_class intel_cstate snd_pcm i2c_hid_acpi i915 iwlmvm i2c_hid snd_seq_midi snd_seq_midi_event 
>>>> nls_iso8859_1 snd_rawmidi mac80211 drm_buddy libarc4 ttm snd_seq
>>>> drm_display_helper processor_thermal_device_pci_legacy cec snd_seq_device ideapad_laptop snd_timer btrfs sparse_keymap 
>>>> processor_thermal_device drm_kms_helper iwlwifi platform_profile
>>>> processor_thermal_rfim processor_thermal_mbox int3400_thermal mei_me blake2b_generic xhci_pci xor processor_thermal_rapl video 
>>>> wmi acpi_thermal_rel mei acpi_tad i2c_algo_bit acpi_pad
>>>> int3403_thermal intel_rapl_common snd xhci_pci_renesas i2c_i801 syscopyarea ahci cfg80211 intel_vsec int340x_thermal_zone 
>>>> intel_lpss_pci sysfillrect soundcore i2c_smbus intel_lpss sysimgblt
>>>> intel_soc_dts_iosf libahci igen6_edac idma64 raid6_pq msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon 
>>>> pstore_zone drm
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.886823]  efi_pstore ip_tables x_tables autofs4 nvme nvme_core input_leds 
>>>> vmd serio_raw mac_hid pinctrl_tigerlake [last unloaded:
>>>> ftrace_direct]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.886986] CPU: 5 PID: 47 Comm: ksoftirqd/5 Not tainted 
>>>> 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887006] Hardware name: LENOVO 82H8/LNVNB161216, BIOS GGCN51WW 11/16/2022
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887022] RIP: 0010:iwl_mvm_rx_tx_cmd+0xc65/0xd50 [iwlmvm]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887096] Code: 85 c0 74 0d 0f b6 40 27 89 f1 21 c1 84 c0 0f 45 f1 40 0f b6 
>>>> f6 4c 89 ff e8 e8 3f ff ff 41 88 84 24 7e 14 00 00 e9 7c fe ff ff
>>>> <0f> 0b 48 8b 7f 40 48 c7 c1 10 ba fa c0 48 c7 c2 58 ce fb c0 31 f6
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887114] RSP: 0018:ffffb60200267b70 EFLAGS: 00010293
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887142] RAX: 0000000000001c80 RBX: ffff8b5af378c000 RCX: 0000000000000005
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887159] RDX: 0000000000000000 RSI: ffffb60200267bb0 RDI: ffff8b5a8ff20028
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887174] RBP: ffffb60200267c40 R08: 0000000000000000 R09: 0000000000000001
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887189] R10: ffffb60200267c58 R11: 0000000000000000 R12: 0000000000000000
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887205] R13: 0000000000000030 R14: ffffb60200267d18 R15: ffff8b5aa39d33e8
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887221] FS:  0000000000000000(0000) GS:ffff8b5c27a80000(0000) 
>>>> knlGS:0000000000000000
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887238] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887255] CR2: 00007f49f4dfe008 CR3: 000000017d850001 CR4: 0000000000f70ee0
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887271] PKRU: 55555554
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887286] Call Trace:
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887302]  <TASK>
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887359]  ? __pfx_iwl_mvm_rx_tx_cmd+0x10/0x10 [iwlmvm]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887446]  ? iwl_mvm_rx_tx_cmd+0x9/0xd50 [iwlmvm]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887540]  ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887563]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887582]  ? iwl_mvm_rx_common+0xde/0x390 [iwlmvm]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887650]  ? iwl_mvm_rx_mq+0x9/0xc0 [iwlmvm]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887739]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887757]  iwl_mvm_rx_mq+0x79/0xc0 [iwlmvm]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887821]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887839]  iwl_pcie_rx_handle+0x402/0xaa0 [iwlwifi]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887979]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.887997]  iwl_pcie_napi_poll_msix+0x39/0xf0 [iwlwifi]
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888086]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888105]  __napi_poll+0x2e/0x1f0
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888146]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888164]  net_rx_action+0x1a5/0x330
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888240]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888258]  __do_softirq+0xb4/0x3a4
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888311]  ? smpboot_thread_fn+0x2a/0x290
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888340]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888358]  run_ksoftirqd+0x44/0x80
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888382]  ? ftrace_regs_caller_end+0x66/0x66
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888400]  smpboot_thread_fn+0x1d9/0x290
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888435]  ? __pfx_smpboot_thread_fn+0x10/0x10
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888458]  kthread+0x10f/0x140
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888481]  ? __pfx_kthread+0x10/0x10
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888517]  ret_from_fork+0x29/0x50
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888609]  </TASK>
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888623] irq event stamp: 4206602
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888636] hardirqs last  enabled at (4206608): [<ffffffffb9a51c98>] 
>>>> __up_console_sem+0x68/0x80
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888657] hardirqs last disabled at (4206613): [<ffffffffb9a51c7d>] 
>>>> __up_console_sem+0x4d/0x80
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888676] softirqs last  enabled at (4196852): [<ffffffffb9965b60>] 
>>>> return_to_handler+0x0/0x40
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888695] softirqs last disabled at (4196891): [<ffffffffb9965b60>] 
>>>> return_to_handler+0x0/0x40
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888714] ---[ end trace 0000000000000000 ]---
>>>> Apr  9 23:01:26 marvin-IdeaPad-3-15ITL6 kernel: [  630.888732] iwlwifi 0000:00:14.3: iwl_trans_reclaim bad state = 0
>>>>
>>>> Hope this helps.
>>>>
>>>> The platform is Ubuntu 22.10 kinetic kudu on Lenovo IdeaPad 3 15ITL6,
>>>> the above mentioned 6.3-rc6 torvalds tree kernel and GGCN51WW original
>>>> Lenovo BIOS.
>>>>
>>>> Please find the config and the lshw output and this listing at the URL:
>>>>
>>>> → https://domac.alu.unizg.hr/~mtodorov/linux/bugreports/intel/iwlwifi/
>>>
>>> The fault was reproduced while running complete "make kselftest" and having
>>> at the same time Firefox with 100+ tabs and 2 Youtube tabs running.
>>>
>>> Apr 10 00:32:16 marvin-IdeaPad-3-15ITL6 kernel: mmiotrace: disabled.
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Error sending STATISTICS_CMD: time out after 2000ms.
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Current CMD queue read_ptr 54 write_ptr 55
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Loaded firmware version: 73.35c0a2c6.0 QuZ-a0-jf-b0-73.ucode
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x1080A200 | trm_hw_status0
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00010000 | trm_hw_status1
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x004C352E | branchlink2
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000638C | interruptlink1
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000638C | interruptlink2
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00011864 | data1
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01000000 | data2
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | data3
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x5F008D9F | beacon time
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x9892726D | tsf low
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000083 | tsf hi
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00008D3B | time gp1
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x2124C243 | time gp2
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000049 | uCode version major
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x35C0A2C6 | uCode version minor
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000351 | hw version
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00489001 | board version
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0489001C | hcmd
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xE682B000 | isr0
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x09040000 | isr1
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x08F0011A | isr2
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00C3028C | isr3
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | isr4
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0488001C | last cmd Id
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00011864 | wait_event
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x000000C4 | l2p_control
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00018034 | l2p_duration
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000007 | l2p_mhvalid
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000081 | l2p_addr_match
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | timestamp
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000808 | flow_handler
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 7
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000066 | NMI_INTERRUPT_HOST
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x80453B88 | umac branchlink2
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink1
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink2
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01000000 | umac data1
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac data2
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | umac data3
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000049 | umac major
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x35C0A2C6 | umac minor
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x2124C241 | frame pointer
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xC0886264 | stack pointer
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0036019C | last host cmd
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: IML/ROM dump:
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00005404 | IML/ROM data1
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Fseq Registers:
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x60000000 | FSEQ_ERROR_CODE
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x80260000 | FSEQ_TOP_INIT_VERSION
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00020006 | FSEQ_CNVIO_INIT_VERSION
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000A384 | FSEQ_OTP_VERSION
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x3D544A68 | FSEQ_TOP_CONTENT_VERSION
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01300202 | FSEQ_CNVR_ID
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01300202 | CNVR_AUX_MISC_CHIP
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000485B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xA5A5A5A2 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: ieee80211 phy0: Hardware restart was requested
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Hardware error detected. Restarting.
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: BUG: Apr 10 00:32:16 marvin-IdeaPad-3-15ITL6 kernel: mmiotrace: disabled.
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Error sending STATISTICS_CMD: time out after 2000ms.
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Current CMD queue read_ptr 54 write_ptr 55
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Loaded firmware version: 73.35c0a2c6.0 QuZ-a0-jf-b0-73.ucode
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x1080A200 | trm_hw_status0
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00010000 | trm_hw_status1
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x004C352E | branchlink2
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000638C | interruptlink1
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000638C | interruptlink2
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00011864 | data1
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01000000 | data2
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | data3
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x5F008D9F | beacon time
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x9892726D | tsf low
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000083 | tsf hi
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00008D3B | time gp1
>>> Apr 10 00:32:36 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x2124C243 | time gp2
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000049 | uCode version major
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x35C0A2C6 | uCode version minor
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000351 | hw version
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00489001 | board version
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0489001C | hcmd
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xE682B000 | isr0
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x09040000 | isr1
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x08F0011A | isr2
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00C3028C | isr3
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | isr4
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0488001C | last cmd Id
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00011864 | wait_event
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x000000C4 | l2p_control
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00018034 | l2p_duration
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000007 | l2p_mhvalid
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000081 | l2p_addr_match
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | timestamp
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000808 | flow_handler
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 7
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000066 | NMI_INTERRUPT_HOST
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x80453B88 | umac branchlink2
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink1
>>> Apr 10 00:32:37 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac interruptlink2
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01000000 | umac data1
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x8046FE32 | umac data2
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | umac data3
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000049 | umac major
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x35C0A2C6 | umac minor
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x2124C241 | frame pointer
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xC0886264 | stack pointer
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0036019C | last host cmd
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: IML/ROM dump:
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00005404 | IML/ROM data1
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Fseq Registers:
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x60000000 | FSEQ_ERROR_CODE
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x80260000 | FSEQ_TOP_INIT_VERSION
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x00020006 | FSEQ_CNVIO_INIT_VERSION
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000A384 | FSEQ_OTP_VERSION
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x3D544A68 | FSEQ_TOP_CONTENT_VERSION
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01300202 | FSEQ_CNVR_ID
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x01300202 | CNVR_AUX_MISC_CHIP
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0x0000485B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: 0xA5A5A5A2 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: ieee80211 phy0: Hardware restart was requested
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: iwlwifi 0000:00:14.3: Hardware error detected. Restarting.
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: #PF: supervisor read access in kernel mode
>>> -- Boot 60997fcc74c1448a967138e3f6d00cbf --
>>> Apr 10 00:34:49 marvin-IdeaPad-3-15ITL6 kernel: microcode: updated early: 0xa4 -> 0xa6, date = 2022-06-28
>>>
>>> Apr 10 00:32:38 marvin-IdeaPad-3-15ITL6 kernel: #PF: supervisor read access in kernel mode
>>> -- Boot 60997fcc74c1448a967138e3f6d00cbf --
>>> Apr 10 00:34:49 marvin-IdeaPad-3-15ITL6 kernel: microcode: updated early: 0xa4 -> 0xa6, date = 2022-06-28
>>>
>>> I will add "make kselftest" log to the directory with lshw and config.
>>>
>>> Best regards,
>>> Mirsad
>>>
>> Thanks for the report!
>> The kernel stack there is not a real kernel crash, but is a result of a WARN_ON() in the code.
>> However, there's a kernel NULL pointer deref later. Can I ask you to collect a log of the
>> crash itself? Maybe with netconsole if the machine completely crashes?
> 
> Hi, Mr. Greenman,
> 
> Did you see the provided journalctl at the link?
> 
> I have found this interesting information:
> 
>                                                  other info that might help us debug this:
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  Possible unsafe locking scenario:
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:        CPU0
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:        ----
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:   lock(&local->queue_stop_reason_lock);
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:   <Interrupt>
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:     lock(&local->queue_stop_reason_lock);
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:
>                                                   *** DEADLOCK ***
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: 8 locks held by kworker/5:0/25656:
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: 
> process_one_work+0x1ca/0x530
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: 
> process_one_work+0x1ce/0x530
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  #3: ffff9d6190778728 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  #4: ffff9d619077b480 (&mvm->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  #5: ffff9d61907bacd8 (&trans_pcie->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  #6: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: 
> iwl_mvm_queue_state_change+0x59/0x3a0 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  #7: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: 
> iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:
>                                                  stack backtrace:
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: CPU: 5 PID: 25656 Comm: kworker/5:0 Tainted: G        W 
> 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: Hardware name: LENOVO 82H8/LNVNB161216, BIOS GGCN51WW 11/16/2022
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: Workqueue: events_freezable ieee80211_restart_work [mac80211]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel: Call Trace:
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  <TASK>
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  dump_stack_lvl+0x5f/0xa0
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  dump_stack+0x14/0x20
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  print_usage_bug.part.46+0x208/0x2a0
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  mark_lock.part.47+0x605/0x630
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? sched_clock+0xd/0x20
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? trace_clock_local+0x14/0x30
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? __rb_reserve_next+0x5f/0x490
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? _raw_spin_lock+0x1b/0x50
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  __lock_acquire+0x464/0x1990
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? mark_held_locks+0x4e/0x80
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  lock_acquire+0xc7/0x2d0
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_return_to_handler+0x8b/0x100
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? preempt_count_add+0x4/0x70
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  _raw_spin_lock+0x36/0x50
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? prepare_ftrace_return+0xc5/0x190
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_graph_func+0x16/0x20
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? 0xffffffffc02ab0b1
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? lock_acquire+0xc7/0x2d0
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ieee80211_tx_dequeue+0x9/0x1330 [mac80211]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? __rcu_read_lock+0x4/0x40
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_mvm_queue_state_change+0x311/0x3a0 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_mvm_wake_sw_queue+0x17/0x20 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_txq_gen2_unmap+0x1c9/0x1f0 [iwlwifi]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_txq_gen2_free+0x55/0x130 [iwlwifi]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_txq_gen2_tx_free+0x63/0x80 [iwlwifi]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  _iwl_trans_pcie_gen2_stop_device+0x3f3/0x5b0 [iwlwifi]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? _iwl_trans_pcie_gen2_stop_device+0x9/0x5b0 [iwlwifi]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? mutex_lock_nested+0x4/0x30
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_trans_pcie_gen2_stop_device+0x5f/0x90 [iwlwifi]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_mvm_stop_device+0x78/0xd0 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  __iwl_mvm_mac_start+0x114/0x210 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  iwl_mvm_mac_start+0x76/0x150 [iwlmvm]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  drv_start+0x79/0x180 [mac80211]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ieee80211_reconfig+0x1523/0x1ce0 [mac80211]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? synchronize_net+0x4/0x50
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ieee80211_restart_work+0x108/0x170 [mac80211]
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  process_one_work+0x250/0x530
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? ftrace_regs_caller_end+0x66/0x66
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  worker_thread+0x48/0x3a0
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? __pfx_worker_thread+0x10/0x10
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  kthread+0x10f/0x140
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ? __pfx_kthread+0x10/0x10
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  ret_from_fork+0x29/0x50
> Apr 10 00:58:33 marvin-IdeaPad-3-15ITL6 kernel:  </TASK>
> 
> Other than this, I am not technically savvy enough to give the other possible logs
> than /var/log/syslog and journalctl ...
> 
> Could you please give additional instructions.
> 
> Thank you very much.

Hi, Gregory,

I have browsed through the material I provided, and somehow the NULL pointer dereference is not
there in the logs. But I am certain that I have copied this line with the kernel BUG from the
logs. I haven't erased any logs yet, so I believe I will be able to recover these log lines
as soon as I get physically to the device.

Best regards,
Mirsad

-- 
Mirsad Todorovac
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union

Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu



^ permalink raw reply	[relevance 82%]

* RE: [BUG] DAX access of Memory Expander on RCH topology fires BUG on page_table_check
  @ 2023-04-18  6:35 82% ` Dan Williams
  2023-04-20  1:29 82%   ` Gregory Price
    1 sibling, 1 reply; 200+ results
From: Dan Williams @ 2023-04-18  6:35 UTC (permalink / raw)
  To: Gregory Price, linux-cxl; +Cc: Dan Williams, Dave Jiang

Gregory Price wrote:
> 
> 
> I was looking to validate mlock-ability of various pages when CXL is in
> different states (numa, dax, etc), and I discovered a page_table_check
> BUG when accessing MemExp memory while a device is in daxdev mode.
> 
> this happens essentially on a fault of the first accessed page
> 
> int dax_fd = open(device_path, O_RDWR);
> void *mapped_memory = mmap(NULL, (1024*1024*2), PROT_READ | PROT_WRITE, MAP_SHARED, dax_fd, 0);
> ((char*)mapped_memory)[0] = 1;
> 
> 
> Full details of my test here:
> 
> Step 1) Test that memory onlined in NUMA node works
> 
> [user@host0 ~]# numactl --hardware
> available: 2 nodes (0-1)
> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> node 0 size: 63892 MB
> node 0 free: 59622 MB
> node 1 cpus:
> node 1 size: 129024 MB
> node 1 free: 129024 MB
> node distances:
> node   0   1
>   0:  10  50
>   1:  255  10
> 
> 
> [user@host0 ~]# numactl --preferred=1 memhog 128G
> ... snip ...
> 
> Passes no problem, all memory is accessible and used.
> 
> 
> 
> Next, reconfigure the device to daxdev mode
> 
> 
> [user@host0 ~]# daxctl list
> [
>   {
>     "chardev":"dax0.0",
>     "size":137438953472,
>     "target_node":1,
>     "align":2097152,
>     "mode":"system-ram",
>     "online_memblocks":63,
>     "total_memblocks":63,
>     "movable":true
>   }
> ]
> [user@host0 ~]# daxctl offline-memory dax0.0
> offlined memory for 1 device
> [user@host0 ~]# daxctl reconfigure-device --human --mode=devdax dax0.0
> {
>   "chardev":"dax0.0",
>   "size":"128.00 GiB (137.44 GB)",
>   "target_node":1,
>   "align":2097152,
>   "mode":"devdax"
> }
> reconfigured 1 device
> [user@host0 mapping0]# daxctl list -M -u
> {
>   "chardev":"dax0.0",
>   "size":"128.00 GiB (137.44 GB)",
>   "target_node":1,
>   "align":2097152,
>   "mode":"devdax",
>   "mappings":[
>     {
>       "page_offset":"0",
>       "start":"0x1050000000",
>       "end":"0x304fffffff",
>       "size":"128.00 GiB (137.44 GB)"
>     }
>   ]
> }
> 
> 
> Now map and access the memory via /dev/dax0.0  (test program attached)
> 
> [ 1028.430734] kernel BUG at mm/page_table_check.c:53!

I have never tested DAX with CONFIG_PAGE_TABLE_CHECK=y, so would need to
dig in further here. A quick test passes the unit tests, but the unit
tests don't have this, "map dax after system-ram" scenario. Just for
completenees, does it behave without that debug option enabled?

[..] 
> 
> Test program:
> 
> #include <sys/mman.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <errno.h>
> #include <string.h>
> 
> int main() {
>     // Open the DAX device
>     const char *device_path = "/dev/dax0.0"; // Replace with your DAX device path
>     int dax_fd = open(device_path, O_RDWR);
> 
>     if (dax_fd < 0) {
>         printf("Error: Unable to open DAX device: %s\n", strerror(errno));
>         return 1;
>     }
>     printf("file opened\n");
> 
>     // Memory-map the DAX device
>     size_t size = 1024*1024*2; // 2MB
>     void *mapped_memory = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, dax_fd, 0);
> 
>     if (mapped_memory == MAP_FAILED) {
>         printf("Error: Unable to mmap DAX device: %s\n", strerror(errno));
>         close(dax_fd);
>         return 1;
>     }
>     printf("mmaped\n");
> 
>     ((char*)mapped_memory)[0] = 1;
> 
> /*

i.e. just touching the memory fails, no need to mlock it? This smells
more like the CONFIG_PAGE_TABLE_CHECK machinery is getting confused, but
I would have expected its metadata to be reset by the dax device
reconfiguration.

^ permalink raw reply	[relevance 82%]

* Re: [BUG] DAX access of Memory Expander on RCH topology fires BUG on page_table_check
  @ 2023-04-18  6:43 82%   ` Dan Williams
  2023-04-20  0:58 82%     ` Gregory Price
  0 siblings, 1 reply; 200+ results
From: Dan Williams @ 2023-04-18  6:43 UTC (permalink / raw)
  To: Gregory Price, linux-cxl; +Cc: Dan Williams, Dave Jiang

Gregory Price wrote:
> On Wed, Apr 12, 2023 at 02:43:33PM -0400, Gregory Price wrote:
> > 
> > 
> > I was looking to validate mlock-ability of various pages when CXL is in
> > different states (numa, dax, etc), and I discovered a page_table_check
> > BUG when accessing MemExp memory while a device is in daxdev mode.
> > 
> > this happens essentially on a fault of the first accessed page
> > 
> > int dax_fd = open(device_path, O_RDWR);
> > void *mapped_memory = mmap(NULL, (1024*1024*2), PROT_READ | PROT_WRITE, MAP_SHARED, dax_fd, 0);
> > ((char*)mapped_memory)[0] = 1;
> > 
> > 
> > Full details of my test here:
> > 
> > Step 1) Test that memory onlined in NUMA node works
> > 
> > [user@host0 ~]# numactl --hardware
> > available: 2 nodes (0-1)
> > node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> > node 0 size: 63892 MB
> > node 0 free: 59622 MB
> > node 1 cpus:
> > node 1 size: 129024 MB
> > node 1 free: 129024 MB
> > node distances:
> > node   0   1
> >   0:  10  50
> >   1:  255  10
> > 
> > 
> > [user@host0 ~]# numactl --preferred=1 memhog 128G
> > ... snip ...
> > 
> > Passes no problem, all memory is accessible and used.
> > 
> > 
> > 
> > Next, reconfigure the device to daxdev mode
> > 
> > 
> > [user@host0 ~]# daxctl list
> > [
> >   {
> >     "chardev":"dax0.0",
> >     "size":137438953472,
> >     "target_node":1,
> >     "align":2097152,
> >     "mode":"system-ram",
> >     "online_memblocks":63,
> >     "total_memblocks":63,
> >     "movable":true
> >   }
> > ]
> 
> 
> Follow up - i was investigating why my dax region here only created 63
> 2GB MemBlocks for a 128GB region, and the reason is a forced alignment
> of dax devices against the CXL Fixed Memory Window.
> 
> [    0.000000] BIOS-e820: [mem 0x0000001050000000-0x000000304fffffff] soft reserved
> [    0.000000] BIOS-e820: [mem 0x00003ffc00000000-0x00003ffc03ffffff] reserved
> [    0.000000] reserve setup_data: [mem 0x0000001050000000-0x000000304fffffff] soft reserved
> [    0.000000] reserve setup_data: [mem 0x00003ffc00000000-0x00003ffc03ffffff] reserved
> 
> 
> some debug prints i added
> 
> [   20.726483] dax cxl probe
> [   20.727330] cxl_dax_region dax_region0: alloc_dax_region: start 1050000000 end 304fffffff
> [   20.728405] Creating dev_dev
> [   20.729033] dev_dax nr_range: 0
> [   20.735481]  dax0.0: alloc range[0]: 0x0000001050000000:0x000000304fffffff
> 
> The memory backing this dax region gets squashed by this code:
> 
> +++ b/drivers/dax/kmem.c
> static int dax_kmem_range(struct dev_dax *dev_dax, int i, struct range *r)
>         struct dev_dax_range *dax_range = &dev_dax->ranges[i];
>         struct range *range = &dax_range->range;
> 
>         /* memory-block align the hotplug range */
>         r->start = ALIGN(range->start, memory_block_size_bytes());
>         r->end = ALIGN_DOWN(range->end + 1, memory_block_size_bytes()) - 1;
>         if (r->start >= r->end) {
>                 r->start = range->start;
>                 r->end = range->end;
> 
> 
> and we end up with a mapping range of:
> 
> start=0x1080000000
> end=0x2fffffffff
> 
> 
> Why NUMA-mode works under these conditions without crashing the system
> is escaping me at the moment,

Why would it crash? That range is valid within
0x1050000000-0x304fffffff.

>  given that the page faulting system goes
> through the same driver.  But my guess is that pfn-to-page mappings are
> off in some way when placed in devdax mode, whereas they're correct
> under numa mode.

pfn-to-page is pretty simple, its the pfn to page_ext that's concerning
for CONFIG_PAGE_TABLE_CHECK.

> Note that the above code chops off the first 768MB of the dax region and
> the last 1.25GB of the dax region.

Yes, if the core-mm picks 2GB for the block size (which it does for
systems with more the 64GB of memory, then it will align hot-added
ranges.

> The CFWM is required to be 256MB aligned, but this code will force
> anything mapped into that area to be 2GB aligned.  I don't think it's
> safe to safe the BIOS is wrong.

The *minimum* alignment of the CFMWS window is 256M, but if they don't
want to waste memory on Linux they had better make it 2GB aligned.

BIOS looks ok here.

> It seems like the dax region ranges are being tied to memory block size,
> but that a raw devdax does not necessarily utilize memory blocks.  Is
> there a potential bug in the mode-switching code?

No memory-blocks to worry about in dax-mode. Until evidence to the
contrary, I'm still looking for how CONFIG_PAGE_TABLE_CHECK might get
confused by DAX mode switches.

^ permalink raw reply	[relevance 82%]

* Re: [BUG] DAX access of Memory Expander on RCH topology fires BUG on page_table_check
  2023-04-18  6:43 82%   ` Dan Williams
@ 2023-04-20  0:58 82%     ` Gregory Price
  0 siblings, 0 replies; 200+ results
From: Gregory Price @ 2023-04-20  0:58 UTC (permalink / raw)
  To: Dan Williams; +Cc: linux-cxl, Dave Jiang

On Mon, Apr 17, 2023 at 11:43:27PM -0700, Dan Williams wrote:
> Gregory Price wrote:
> > Why NUMA-mode works under these conditions without crashing the system
> > is escaping me at the moment,
> 
> Why would it crash? That range is valid within
> 0x1050000000-0x304fffffff.
> 

Basically I was expecting a page-fault in NUMA to produce the same
effects as a fault fault in DAX, clearly this is not the case and either
the switch from numa to dax is causing 

> >  given that the page faulting system goes
> > through the same driver.  But my guess is that pfn-to-page mappings are
> > off in some way when placed in devdax mode, whereas they're correct
> > under numa mode.
> 
> pfn-to-page is pretty simple, its the pfn to page_ext that's concerning
> for CONFIG_PAGE_TABLE_CHECK.
> 

Testing CONFIG_PAGE_TABLE_CHECK=n now, will report back when done.

> > Note that the above code chops off the first 768MB of the dax region and
> > the last 1.25GB of the dax region.
> 
> Yes, if the core-mm picks 2GB for the block size (which it does for
> systems with more the 64GB of memory, then it will align hot-added
> ranges.
> 
> > The CFWM is required to be 256MB aligned, but this code will force
> > anything mapped into that area to be 2GB aligned.  I don't think it's
> > safe to safe the BIOS is wrong.
> 
> The *minimum* alignment of the CFMWS window is 256M, but if they don't
> want to waste memory on Linux they had better make it 2GB aligned.
> 
> BIOS looks ok here.
>

FWIW i have a QEMU instance with 64GB that puts CXL devices on 256MB
alignment as well, so QEMU instances over a certain amount of DRAM
produce the same effect as hardware - lost memory.

~Gregory

^ permalink raw reply	[relevance 82%]

* Re: [BUG] DAX access of Memory Expander on RCH topology fires BUG on page_table_check
  2023-04-18  6:35 82% ` Dan Williams
@ 2023-04-20  1:29 82%   ` Gregory Price
  0 siblings, 0 replies; 200+ results
From: Gregory Price @ 2023-04-20  1:29 UTC (permalink / raw)
  To: Dan Williams; +Cc: linux-cxl, Dave Jiang

On Mon, Apr 17, 2023 at 11:35:15PM -0700, Dan Williams wrote:
> Gregory Price wrote:
> > Now map and access the memory via /dev/dax0.0  (test program attached)
> > 
> > [ 1028.430734] kernel BUG at mm/page_table_check.c:53!
> 
> I have never tested DAX with CONFIG_PAGE_TABLE_CHECK=y, so would need to
> dig in further here. A quick test passes the unit tests, but the unit
> tests don't have this, "map dax after system-ram" scenario. Just for
> completenees, does it behave without that debug option enabled?
> 

Confirmed passes without issues when this debug option is disabled.
Also confirmed on production hardware with a release build where this
check is disabled.

So something is up with page table check code and going numa to dax.

> 
> i.e. just touching the memory fails, no need to mlock it? This smells
> more like the CONFIG_PAGE_TABLE_CHECK machinery is getting confused, but
> I would have expected its metadata to be reset by the dax device
> reconfiguration.

Yes, just touching is faults, without mlocking it.

I dug in and the page_ext for the page is NULL, which is what causes the
BUG().  I don't know the subsystem well enough to know why converting to
dax would cause the page_ext to be NULL.

The reason why this got convoluted with the other hardware/firmware/bios
issues is that I was thinking the alignment issue with memory blocks may
have been part of the issue, but clearly that's not the case.

~Gregory

^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 00000000000000fc
  @ 2023-04-25  3:27 82% ` Ming Lei
    0 siblings, 1 reply; 200+ results
From: Ming Lei @ 2023-04-25  3:27 UTC (permalink / raw)
  To: Changhui Zhong; +Cc: linux-block, ming.lei

On Tue, Apr 25, 2023 at 10:37:05AM +0800, Changhui Zhong wrote:
> Hello,
> 
> Below issue was triggered in my test,it caused system panic ,please
> help check it.
> branch: for-6.4/block
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
> 
> mdadm -CR /dev/md0 -l 1 -n 2 /dev/sda /dev/sdb -e 1.0
> sgdisk -n 0:0:+100MiB /dev/md0
> cat /proc/partitions
> mdadm -S /dev/md0
> mdadm -A /dev/md0 /dev/sda /dev/sdb
> cat /proc/partitions
> 
> 
> [   34.219123] BUG: kernel NULL pointer dereference, address: 00000000000000fc
> [   34.219507] #PF: supervisor read access in kernel mode
> [   34.219784] #PF: error_code(0x0000) - not-present page
> [   34.220039] PGD 0 P4D 0
> [   34.220176] Oops: 0000 [#1] PREEMPT SMP PTI
> [   34.220374] CPU: 8 PID: 1956 Comm: systemd-udevd Kdump: loaded Not
> tainted 6.3.0-rc2+ #1
> [   34.220787] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
> Gen9, BIOS P89 05/21/2018
> [   34.221188] RIP: 0010:blk_mq_sched_bio_merge+0x6d/0xf0

Hi Changhui,

Please try the following fix:

diff --git a/block/bdev.c b/block/bdev.c
index 850852fe4b78..fa2838ca2e6d 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -419,7 +419,11 @@ struct block_device *bdev_alloc(struct gendisk *disk, u8 partno)
        bdev->bd_inode = inode;
        bdev->bd_queue = disk->queue;
        bdev->bd_stats = alloc_percpu(struct disk_stats);
-       bdev->bd_has_submit_bio = false;
+
+       if (partno)
+               bdev->bd_has_submit_bio = disk->part0->bd_has_submit_bio;
+       else
+               bdev->bd_has_submit_bio = false;
        if (!bdev->bd_stats) {
                iput(inode);
                return NULL;

Fixes: 9f4107b07b17 ("block: store bdev->bd_disk->fops->submit_bio state in bdev")


Thanks, 
Ming


^ permalink raw reply related	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 00000000000000fc
  @ 2023-04-26  6:05 82%     ` Yu Kuai
  2023-04-26  6:20 82%       ` Changhui Zhong
  0 siblings, 1 reply; 200+ results
From: Yu Kuai @ 2023-04-26  6:05 UTC (permalink / raw)
  To: Changhui Zhong, Ming Lei; +Cc: linux-block, yukuai (C)

Hi,

在 2023/04/26 13:56, Changhui Zhong 写道:
> On Tue, Apr 25, 2023 at 11:27 AM Ming Lei <ming.lei@redhat.com> wrote:
>>
>> On Tue, Apr 25, 2023 at 10:37:05AM +0800, Changhui Zhong wrote:
>>> Hello,
>>>
>>> Below issue was triggered in my test,it caused system panic ,please
>>> help check it.
>>> branch: for-6.4/block
>>> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
>>>
>>> mdadm -CR /dev/md0 -l 1 -n 2 /dev/sda /dev/sdb -e 1.0
>>> sgdisk -n 0:0:+100MiB /dev/md0
>>> cat /proc/partitions
>>> mdadm -S /dev/md0
>>> mdadm -A /dev/md0 /dev/sda /dev/sdb
>>> cat /proc/partitions
>>>
>>>
>>> [   34.219123] BUG: kernel NULL pointer dereference, address: 00000000000000fc
>>> [   34.219507] #PF: supervisor read access in kernel mode
>>> [   34.219784] #PF: error_code(0x0000) - not-present page
>>> [   34.220039] PGD 0 P4D 0
>>> [   34.220176] Oops: 0000 [#1] PREEMPT SMP PTI
>>> [   34.220374] CPU: 8 PID: 1956 Comm: systemd-udevd Kdump: loaded Not
>>> tainted 6.3.0-rc2+ #1
>>> [   34.220787] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
>>> Gen9, BIOS P89 05/21/2018
>>> [   34.221188] RIP: 0010:blk_mq_sched_bio_merge+0x6d/0xf0
>>
>> Hi Changhui,
>>
>> Please try the following fix:
>>
>> diff --git a/block/bdev.c b/block/bdev.c
>> index 850852fe4b78..fa2838ca2e6d 100644
>> --- a/block/bdev.c
>> +++ b/block/bdev.c
>> @@ -419,7 +419,11 @@ struct block_device *bdev_alloc(struct gendisk *disk, u8 partno)
>>          bdev->bd_inode = inode;
>>          bdev->bd_queue = disk->queue;
>>          bdev->bd_stats = alloc_percpu(struct disk_stats);
>> -       bdev->bd_has_submit_bio = false;
>> +
>> +       if (partno)
>> +               bdev->bd_has_submit_bio = disk->part0->bd_has_submit_bio;
>> +       else
>> +               bdev->bd_has_submit_bio = false;
>>          if (!bdev->bd_stats) {
>>                  iput(inode);
>>                  return NULL;
>>
>> Fixes: 9f4107b07b17 ("block: store bdev->bd_disk->fops->submit_bio state in bdev")
>>
> 
> Hi,Ming
> 
> I retest the latest updated branch for-6.4/block
> (https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/log/?h=for-6.4/block),
> which contain your fix patch "block: sync part's ->bd_has_submit_bio
> with disk's".
> the kernel panic  no longer happen, but the test will failed, the
> system will reread partition table on exclusively open device,

Is this patch in the branch for-6.4/block?

3723091ea188 ("block: don't set GD_NEED_PART_SCAN if scan partition failed")
> 
> :: [ 01:50:05 ] :: [  BEGIN   ] :: Running 'mdadm -S /dev/md0'
> mdadm: stopped /dev/md0
> :: [ 01:50:06 ] :: [   PASS   ] :: Command 'mdadm -S /dev/md0'
> (Expected 0, got 0)
> :: [ 01:50:06 ] :: [  BEGIN   ] :: Running 'mdadm -A /dev/md0
> /dev/"$dev0" /dev/"$dev1"'
> mdadm: /dev/md0 has been started with 2 drives.
> :: [ 01:50:06 ] :: [   PASS   ] :: Command 'mdadm -A /dev/md0
> /dev/"$dev0" /dev/"$dev1"' (Expected 0, got 0)
> :: [ 01:50:09 ] :: [  BEGIN   ] :: Running 'lsblk'
> NAME                         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
> sda                            8:0    1 447.1G  0 disk
> ├─sda1                         8:1    1     1G  0 part  /boot
> └─sda2                         8:2    1 446.1G  0 part
>    ├─rhel_storageqe--104-root 253:0    0    70G  0 lvm   /
>    ├─rhel_storageqe--104-swap 253:1    0   7.7G  0 lvm   [SWAP]
>    └─rhel_storageqe--104-home 253:2    0 368.4G  0 lvm   /home
> sdb                            8:16   1 447.1G  0 disk
> ├─sdb1                         8:17   1   100M  0 part
> └─md0                          9:0    0 447.1G  0 raid1
>    └─md0p1                    259:0    0   100M  0 part
> sdc                            8:32   1 447.1G  0 disk
> ├─sdc1                         8:33   1   100M  0 part
> └─md0                          9:0    0 447.1G  0 raid1
>    └─md0p1                    259:0    0   100M  0 part
> sdd                            8:48   1 447.1G  0 disk
> :: [ 01:50:09 ] :: [   PASS   ] :: Command 'lsblk' (Expected 0, got 0)
> :: [ 01:50:09 ] :: [  BEGIN   ] :: Running 'cat /proc/partitions'
> major minor  #blocks  name
> 
>     8        0  468851544 sda
>     8        1    1048576 sda1
>     8        2  467801088 sda2
>     8       48  468851544 sdd
>     8       32  468851544 sdc
>     8       33     102400 sdc1
>     8       16  468851544 sdb
>     8       17     102400 sdb1
>   253        0   73400320 dm-0
>   253        1    8060928 dm-1
>   253        2  386338816 dm-2
>     9        0  468851392 md0
>   259        0     102400 md0p1
> 
> Thanks,
> 
> .
> 


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 00000000000000fc
  2023-04-26  6:05 82%     ` Yu Kuai
@ 2023-04-26  6:20 82%       ` Changhui Zhong
  2023-04-26  6:24 82%         ` Yu Kuai
  0 siblings, 1 reply; 200+ results
From: Changhui Zhong @ 2023-04-26  6:20 UTC (permalink / raw)
  To: Yu Kuai; +Cc: Ming Lei, linux-block, yukuai (C)

On Wed, Apr 26, 2023 at 2:06 PM Yu Kuai <yukuai1@huaweicloud.com> wrote:
>
> Hi,
>
> 在 2023/04/26 13:56, Changhui Zhong 写道:
> > On Tue, Apr 25, 2023 at 11:27 AM Ming Lei <ming.lei@redhat.com> wrote:
> >>
> >> On Tue, Apr 25, 2023 at 10:37:05AM +0800, Changhui Zhong wrote:
> >>> Hello,
> >>>
> >>> Below issue was triggered in my test,it caused system panic ,please
> >>> help check it.
> >>> branch: for-6.4/block
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
> >>>
> >>> mdadm -CR /dev/md0 -l 1 -n 2 /dev/sda /dev/sdb -e 1.0
> >>> sgdisk -n 0:0:+100MiB /dev/md0
> >>> cat /proc/partitions
> >>> mdadm -S /dev/md0
> >>> mdadm -A /dev/md0 /dev/sda /dev/sdb
> >>> cat /proc/partitions
> >>>
> >>>
> >>> [   34.219123] BUG: kernel NULL pointer dereference, address: 00000000000000fc
> >>> [   34.219507] #PF: supervisor read access in kernel mode
> >>> [   34.219784] #PF: error_code(0x0000) - not-present page
> >>> [   34.220039] PGD 0 P4D 0
> >>> [   34.220176] Oops: 0000 [#1] PREEMPT SMP PTI
> >>> [   34.220374] CPU: 8 PID: 1956 Comm: systemd-udevd Kdump: loaded Not
> >>> tainted 6.3.0-rc2+ #1
> >>> [   34.220787] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
> >>> Gen9, BIOS P89 05/21/2018
> >>> [   34.221188] RIP: 0010:blk_mq_sched_bio_merge+0x6d/0xf0
> >>
> >> Hi Changhui,
> >>
> >> Please try the following fix:
> >>
> >> diff --git a/block/bdev.c b/block/bdev.c
> >> index 850852fe4b78..fa2838ca2e6d 100644
> >> --- a/block/bdev.c
> >> +++ b/block/bdev.c
> >> @@ -419,7 +419,11 @@ struct block_device *bdev_alloc(struct gendisk *disk, u8 partno)
> >>          bdev->bd_inode = inode;
> >>          bdev->bd_queue = disk->queue;
> >>          bdev->bd_stats = alloc_percpu(struct disk_stats);
> >> -       bdev->bd_has_submit_bio = false;
> >> +
> >> +       if (partno)
> >> +               bdev->bd_has_submit_bio = disk->part0->bd_has_submit_bio;
> >> +       else
> >> +               bdev->bd_has_submit_bio = false;
> >>          if (!bdev->bd_stats) {
> >>                  iput(inode);
> >>                  return NULL;
> >>
> >> Fixes: 9f4107b07b17 ("block: store bdev->bd_disk->fops->submit_bio state in bdev")
> >>
> >
> > Hi,Ming
> >
> > I retest the latest updated branch for-6.4/block
> > (https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/log/?h=for-6.4/block),
> > which contain your fix patch "block: sync part's ->bd_has_submit_bio
> > with disk's".
> > the kernel panic  no longer happen, but the test will failed, the
> > system will reread partition table on exclusively open device,
>
> Is this patch in the branch for-6.4/block?
>
> 3723091ea188 ("block: don't set GD_NEED_PART_SCAN if scan partition failed")
> >

Hi, Yu Kuai

this patch was not found in the for-6.4/block branch, and found it
exist in the master branch


> > :: [ 01:50:05 ] :: [  BEGIN   ] :: Running 'mdadm -S /dev/md0'
> > mdadm: stopped /dev/md0
> > :: [ 01:50:06 ] :: [   PASS   ] :: Command 'mdadm -S /dev/md0'
> > (Expected 0, got 0)
> > :: [ 01:50:06 ] :: [  BEGIN   ] :: Running 'mdadm -A /dev/md0
> > /dev/"$dev0" /dev/"$dev1"'
> > mdadm: /dev/md0 has been started with 2 drives.
> > :: [ 01:50:06 ] :: [   PASS   ] :: Command 'mdadm -A /dev/md0
> > /dev/"$dev0" /dev/"$dev1"' (Expected 0, got 0)
> > :: [ 01:50:09 ] :: [  BEGIN   ] :: Running 'lsblk'
> > NAME                         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
> > sda                            8:0    1 447.1G  0 disk
> > ├─sda1                         8:1    1     1G  0 part  /boot
> > └─sda2                         8:2    1 446.1G  0 part
> >    ├─rhel_storageqe--104-root 253:0    0    70G  0 lvm   /
> >    ├─rhel_storageqe--104-swap 253:1    0   7.7G  0 lvm   [SWAP]
> >    └─rhel_storageqe--104-home 253:2    0 368.4G  0 lvm   /home
> > sdb                            8:16   1 447.1G  0 disk
> > ├─sdb1                         8:17   1   100M  0 part
> > └─md0                          9:0    0 447.1G  0 raid1
> >    └─md0p1                    259:0    0   100M  0 part
> > sdc                            8:32   1 447.1G  0 disk
> > ├─sdc1                         8:33   1   100M  0 part
> > └─md0                          9:0    0 447.1G  0 raid1
> >    └─md0p1                    259:0    0   100M  0 part
> > sdd                            8:48   1 447.1G  0 disk
> > :: [ 01:50:09 ] :: [   PASS   ] :: Command 'lsblk' (Expected 0, got 0)
> > :: [ 01:50:09 ] :: [  BEGIN   ] :: Running 'cat /proc/partitions'
> > major minor  #blocks  name
> >
> >     8        0  468851544 sda
> >     8        1    1048576 sda1
> >     8        2  467801088 sda2
> >     8       48  468851544 sdd
> >     8       32  468851544 sdc
> >     8       33     102400 sdc1
> >     8       16  468851544 sdb
> >     8       17     102400 sdb1
> >   253        0   73400320 dm-0
> >   253        1    8060928 dm-1
> >   253        2  386338816 dm-2
> >     9        0  468851392 md0
> >   259        0     102400 md0p1
> >
> > Thanks,
> >
> > .
> >
>


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 00000000000000fc
  2023-04-26  6:20 82%       ` Changhui Zhong
@ 2023-04-26  6:24 82%         ` Yu Kuai
  2023-04-26  6:32 82%           ` Changhui Zhong
  0 siblings, 1 reply; 200+ results
From: Yu Kuai @ 2023-04-26  6:24 UTC (permalink / raw)
  To: Changhui Zhong, Yu Kuai; +Cc: Ming Lei, linux-block, yukuai (C)

Hi,

在 2023/04/26 14:20, Changhui Zhong 写道:
>> Is this patch in the branch for-6.4/block?
>>
>> 3723091ea188 ("block: don't set GD_NEED_PART_SCAN if scan partition failed")
>>>
> 
> Hi, Yu Kuai
> 
> this patch was not found in the for-6.4/block branch, and found it
> exist in the master branch
> 

Can you try to test with this patch?

Thanks,
Kuai


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 00000000000000fc
  2023-04-26  6:24 82%         ` Yu Kuai
@ 2023-04-26  6:32 82%           ` Changhui Zhong
  0 siblings, 0 replies; 200+ results
From: Changhui Zhong @ 2023-04-26  6:32 UTC (permalink / raw)
  To: Yu Kuai; +Cc: Ming Lei, linux-block, yukuai (C)

On Wed, Apr 26, 2023 at 2:24 PM Yu Kuai <yukuai1@huaweicloud.com> wrote:
>
> Hi,
>
> 在 2023/04/26 14:20, Changhui Zhong 写道:
> >> Is this patch in the branch for-6.4/block?
> >>
> >> 3723091ea188 ("block: don't set GD_NEED_PART_SCAN if scan partition failed")
> >>>
> >
> > Hi, Yu Kuai
> >
> > this patch was not found in the for-6.4/block branch, and found it
> > exist in the master branch
> >
>
> Can you try to test with this patch?
>
> Thanks,
> Kuai
>

ok,I will retest with this patch,will feedback test result later

Thanks,


^ permalink raw reply	[relevance 82%]

* Re: [bug report] ceph: fix potential use-after-free bug when trimming caps
  @ 2023-05-06  1:32 82% ` Xiubo Li
  2023-05-06  7:13 82%   ` Dan Carpenter
  0 siblings, 1 reply; 200+ results
From: Xiubo Li @ 2023-05-06  1:32 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: ceph-devel

Hi Dan,

On 5/5/23 17:21, Dan Carpenter wrote:
> Hello Xiubo Li,
>
> The patch aaf67de78807: "ceph: fix potential use-after-free bug when
> trimming caps" from Apr 19, 2023, leads to the following Smatch
> static checker warning:
>
> 	fs/ceph/mds_client.c:3968 reconnect_caps_cb()
> 	warn: missing error code here? '__get_cap_for_mds()' failed. 'err' = '0'
>
> fs/ceph/mds_client.c
>      3933 static int reconnect_caps_cb(struct inode *inode, int mds, void *arg)
>      3934 {
>      3935         union {
>      3936                 struct ceph_mds_cap_reconnect v2;
>      3937                 struct ceph_mds_cap_reconnect_v1 v1;
>      3938         } rec;
>      3939         struct ceph_inode_info *ci = ceph_inode(inode);
>      3940         struct ceph_reconnect_state *recon_state = arg;
>      3941         struct ceph_pagelist *pagelist = recon_state->pagelist;
>      3942         struct dentry *dentry;
>      3943         struct ceph_cap *cap;
>      3944         char *path;
>      3945         int pathlen = 0, err = 0;
>      3946         u64 pathbase;
>      3947         u64 snap_follows;
>      3948
>      3949         dentry = d_find_primary(inode);
>      3950         if (dentry) {
>      3951                 /* set pathbase to parent dir when msg_version >= 2 */
>      3952                 path = ceph_mdsc_build_path(dentry, &pathlen, &pathbase,
>      3953                                             recon_state->msg_version >= 2);
>      3954                 dput(dentry);
>      3955                 if (IS_ERR(path)) {
>      3956                         err = PTR_ERR(path);
>      3957                         goto out_err;
>      3958                 }
>      3959         } else {
>      3960                 path = NULL;
>      3961                 pathbase = 0;
>      3962         }
>      3963
>      3964         spin_lock(&ci->i_ceph_lock);
>      3965         cap = __get_cap_for_mds(ci, mds);
>      3966         if (!cap) {
>      3967                 spin_unlock(&ci->i_ceph_lock);
> --> 3968                 goto out_err;
>
> Set an error code?

This was intended, the 'err' was initialized as '0' in line 3945.

It's no harm to skip this _cb() for current cap, so just succeeds it.

Thanks

- Xiubo


>
>      3969         }
>      3970         dout(" adding %p ino %llx.%llx cap %p %lld %s\n",
>      3971              inode, ceph_vinop(inode), cap, cap->cap_id,
>      3972              ceph_cap_string(cap->issued));
>      3973
>      3974         cap->seq = 0;        /* reset cap seq */
>      3975         cap->issue_seq = 0;  /* and issue_seq */
>      3976         cap->mseq = 0;       /* and migrate_seq */
>      3977         cap->cap_gen = atomic_read(&cap->session->s_cap_gen);
>      3978
>      3979         /* These are lost when the session goes away */
>      3980         if (S_ISDIR(inode->i_mode)) {
>      3981                 if (cap->issued & CEPH_CAP_DIR_CREATE) {
>      3982                         ceph_put_string(rcu_dereference_raw(ci->i_cached_layout.pool_ns));
>      3983                         memset(&ci->i_cached_layout, 0, sizeof(ci->i_cached_layout));
>      3984                 }
>      3985                 cap->issued &= ~CEPH_CAP_ANY_DIR_OPS;
>      3986         }
>      3987
>      3988         if (recon_state->msg_version >= 2) {
>      3989                 rec.v2.cap_id = cpu_to_le64(cap->cap_id);
>      3990                 rec.v2.wanted = cpu_to_le32(__ceph_caps_wanted(ci));
>      3991                 rec.v2.issued = cpu_to_le32(cap->issued);
>      3992                 rec.v2.snaprealm = cpu_to_le64(ci->i_snap_realm->ino);
>      3993                 rec.v2.pathbase = cpu_to_le64(pathbase);
>      3994                 rec.v2.flock_len = (__force __le32)
>      3995                         ((ci->i_ceph_flags & CEPH_I_ERROR_FILELOCK) ? 0 : 1);
>      3996         } else {
>      3997                 rec.v1.cap_id = cpu_to_le64(cap->cap_id);
>      3998                 rec.v1.wanted = cpu_to_le32(__ceph_caps_wanted(ci));
>      3999                 rec.v1.issued = cpu_to_le32(cap->issued);
>      4000                 rec.v1.size = cpu_to_le64(i_size_read(inode));
>      4001                 ceph_encode_timespec64(&rec.v1.mtime, &inode->i_mtime);
>      4002                 ceph_encode_timespec64(&rec.v1.atime, &inode->i_atime);
>      4003                 rec.v1.snaprealm = cpu_to_le64(ci->i_snap_realm->ino);
>      4004                 rec.v1.pathbase = cpu_to_le64(pathbase);
>      4005         }
>      4006
>      4007         if (list_empty(&ci->i_cap_snaps)) {
>      4008                 snap_follows = ci->i_head_snapc ? ci->i_head_snapc->seq : 0;
>      4009         } else {
>      4010                 struct ceph_cap_snap *capsnap =
>      4011                         list_first_entry(&ci->i_cap_snaps,
>      4012                                          struct ceph_cap_snap, ci_item);
>      4013                 snap_follows = capsnap->follows;
>      4014         }
>      4015         spin_unlock(&ci->i_ceph_lock);
>      4016
>      4017         if (recon_state->msg_version >= 2) {
>      4018                 int num_fcntl_locks, num_flock_locks;
>      4019                 struct ceph_filelock *flocks = NULL;
>      4020                 size_t struct_len, total_len = sizeof(u64);
>      4021                 u8 struct_v = 0;
>      4022
>      4023 encode_again:
>      4024                 if (rec.v2.flock_len) {
>      4025                         ceph_count_locks(inode, &num_fcntl_locks, &num_flock_locks);
>      4026                 } else {
>      4027                         num_fcntl_locks = 0;
>      4028                         num_flock_locks = 0;
>      4029                 }
>      4030                 if (num_fcntl_locks + num_flock_locks > 0) {
>      4031                         flocks = kmalloc_array(num_fcntl_locks + num_flock_locks,
>      4032                                                sizeof(struct ceph_filelock),
>      4033                                                GFP_NOFS);
>      4034                         if (!flocks) {
>      4035                                 err = -ENOMEM;
>      4036                                 goto out_err;
>      4037                         }
>      4038                         err = ceph_encode_locks_to_buffer(inode, flocks,
>      4039                                                           num_fcntl_locks,
>      4040                                                           num_flock_locks);
>      4041                         if (err) {
>      4042                                 kfree(flocks);
>      4043                                 flocks = NULL;
>      4044                                 if (err == -ENOSPC)
>      4045                                         goto encode_again;
>      4046                                 goto out_err;
>      4047                         }
>      4048                 } else {
>      4049                         kfree(flocks);
>      4050                         flocks = NULL;
>      4051                 }
>      4052
>      4053                 if (recon_state->msg_version >= 3) {
>      4054                         /* version, compat_version and struct_len */
>      4055                         total_len += 2 * sizeof(u8) + sizeof(u32);
>      4056                         struct_v = 2;
>      4057                 }
>      4058                 /*
>      4059                  * number of encoded locks is stable, so copy to pagelist
>      4060                  */
>      4061                 struct_len = 2 * sizeof(u32) +
>      4062                             (num_fcntl_locks + num_flock_locks) *
>      4063                             sizeof(struct ceph_filelock);
>      4064                 rec.v2.flock_len = cpu_to_le32(struct_len);
>      4065
>      4066                 struct_len += sizeof(u32) + pathlen + sizeof(rec.v2);
>      4067
>      4068                 if (struct_v >= 2)
>      4069                         struct_len += sizeof(u64); /* snap_follows */
>      4070
>      4071                 total_len += struct_len;
>      4072
>      4073                 if (pagelist->length + total_len > RECONNECT_MAX_SIZE) {
>      4074                         err = send_reconnect_partial(recon_state);
>      4075                         if (err)
>      4076                                 goto out_freeflocks;
>      4077                         pagelist = recon_state->pagelist;
>      4078                 }
>      4079
>      4080                 err = ceph_pagelist_reserve(pagelist, total_len);
>      4081                 if (err)
>      4082                         goto out_freeflocks;
>      4083
>      4084                 ceph_pagelist_encode_64(pagelist, ceph_ino(inode));
>      4085                 if (recon_state->msg_version >= 3) {
>      4086                         ceph_pagelist_encode_8(pagelist, struct_v);
>      4087                         ceph_pagelist_encode_8(pagelist, 1);
>      4088                         ceph_pagelist_encode_32(pagelist, struct_len);
>      4089                 }
>      4090                 ceph_pagelist_encode_string(pagelist, path, pathlen);
>      4091                 ceph_pagelist_append(pagelist, &rec, sizeof(rec.v2));
>      4092                 ceph_locks_to_pagelist(flocks, pagelist,
>      4093                                        num_fcntl_locks, num_flock_locks);
>      4094                 if (struct_v >= 2)
>      4095                         ceph_pagelist_encode_64(pagelist, snap_follows);
>      4096 out_freeflocks:
>      4097                 kfree(flocks);
>      4098         } else {
>      4099                 err = ceph_pagelist_reserve(pagelist,
>      4100                                             sizeof(u64) + sizeof(u32) +
>      4101                                             pathlen + sizeof(rec.v1));
>      4102                 if (err)
>      4103                         goto out_err;
>      4104
>      4105                 ceph_pagelist_encode_64(pagelist, ceph_ino(inode));
>      4106                 ceph_pagelist_encode_string(pagelist, path, pathlen);
>      4107                 ceph_pagelist_append(pagelist, &rec, sizeof(rec.v1));
>      4108         }
>      4109
>      4110 out_err:
>      4111         ceph_mdsc_free_path(path, pathlen);
>      4112         if (!err)
>      4113                 recon_state->nr_caps++;
>      4114         return err;
>      4115 }
>
> regards,
> dan carpenter
>


^ permalink raw reply	[relevance 82%]

* Re: [bug report] ceph: fix potential use-after-free bug when trimming caps
  2023-05-06  1:32 82% ` Xiubo Li
@ 2023-05-06  7:13 82%   ` Dan Carpenter
  2023-05-08  6:42 82%     ` Xiubo Li
  0 siblings, 1 reply; 200+ results
From: Dan Carpenter @ 2023-05-06  7:13 UTC (permalink / raw)
  To: Xiubo Li; +Cc: ceph-devel

On Sat, May 06, 2023 at 09:32:30AM +0800, Xiubo Li wrote:
> Hi Dan,
> 
> On 5/5/23 17:21, Dan Carpenter wrote:
> > Hello Xiubo Li,
> > 
> > The patch aaf67de78807: "ceph: fix potential use-after-free bug when
> > trimming caps" from Apr 19, 2023, leads to the following Smatch
> > static checker warning:
> > 
> > 	fs/ceph/mds_client.c:3968 reconnect_caps_cb()
> > 	warn: missing error code here? '__get_cap_for_mds()' failed. 'err' = '0'
> > 
> > fs/ceph/mds_client.c
> >      3933 static int reconnect_caps_cb(struct inode *inode, int mds, void *arg)
> >      3934 {
> >      3935         union {
> >      3936                 struct ceph_mds_cap_reconnect v2;
> >      3937                 struct ceph_mds_cap_reconnect_v1 v1;
> >      3938         } rec;
> >      3939         struct ceph_inode_info *ci = ceph_inode(inode);
> >      3940         struct ceph_reconnect_state *recon_state = arg;
> >      3941         struct ceph_pagelist *pagelist = recon_state->pagelist;
> >      3942         struct dentry *dentry;
> >      3943         struct ceph_cap *cap;
> >      3944         char *path;
> >      3945         int pathlen = 0, err = 0;
> >      3946         u64 pathbase;
> >      3947         u64 snap_follows;
> >      3948
> >      3949         dentry = d_find_primary(inode);
> >      3950         if (dentry) {
> >      3951                 /* set pathbase to parent dir when msg_version >= 2 */
> >      3952                 path = ceph_mdsc_build_path(dentry, &pathlen, &pathbase,
> >      3953                                             recon_state->msg_version >= 2);
> >      3954                 dput(dentry);
> >      3955                 if (IS_ERR(path)) {
> >      3956                         err = PTR_ERR(path);
> >      3957                         goto out_err;
> >      3958                 }
> >      3959         } else {
> >      3960                 path = NULL;
> >      3961                 pathbase = 0;
> >      3962         }
> >      3963
> >      3964         spin_lock(&ci->i_ceph_lock);
> >      3965         cap = __get_cap_for_mds(ci, mds);
> >      3966         if (!cap) {
> >      3967                 spin_unlock(&ci->i_ceph_lock);
> > --> 3968                 goto out_err;
> > 
> > Set an error code?
> 
> This was intended, the 'err' was initialized as '0' in line 3945.
> 
> It's no harm to skip this _cb() for current cap, so just succeeds it.
> 

Smatch considers it intentional of the "ret = 0;" assignment is within
4 or 5 (I forget) lines of the goto.  Otherwise adding a comment would
help reviewers.

regards,
dan carpenter


^ permalink raw reply	[relevance 82%]

* Re: [bug report] ceph: fix potential use-after-free bug when trimming caps
  2023-05-06  7:13 82%   ` Dan Carpenter
@ 2023-05-08  6:42 82%     ` Xiubo Li
  0 siblings, 0 replies; 200+ results
From: Xiubo Li @ 2023-05-08  6:42 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: ceph-devel


On 5/6/23 15:13, Dan Carpenter wrote:
> On Sat, May 06, 2023 at 09:32:30AM +0800, Xiubo Li wrote:
>> Hi Dan,
>>
>> On 5/5/23 17:21, Dan Carpenter wrote:
>>> Hello Xiubo Li,
>>>
>>> The patch aaf67de78807: "ceph: fix potential use-after-free bug when
>>> trimming caps" from Apr 19, 2023, leads to the following Smatch
>>> static checker warning:
>>>
>>> 	fs/ceph/mds_client.c:3968 reconnect_caps_cb()
>>> 	warn: missing error code here? '__get_cap_for_mds()' failed. 'err' = '0'
>>>
>>> fs/ceph/mds_client.c
>>>       3933 static int reconnect_caps_cb(struct inode *inode, int mds, void *arg)
>>>       3934 {
>>>       3935         union {
>>>       3936                 struct ceph_mds_cap_reconnect v2;
>>>       3937                 struct ceph_mds_cap_reconnect_v1 v1;
>>>       3938         } rec;
>>>       3939         struct ceph_inode_info *ci = ceph_inode(inode);
>>>       3940         struct ceph_reconnect_state *recon_state = arg;
>>>       3941         struct ceph_pagelist *pagelist = recon_state->pagelist;
>>>       3942         struct dentry *dentry;
>>>       3943         struct ceph_cap *cap;
>>>       3944         char *path;
>>>       3945         int pathlen = 0, err = 0;
>>>       3946         u64 pathbase;
>>>       3947         u64 snap_follows;
>>>       3948
>>>       3949         dentry = d_find_primary(inode);
>>>       3950         if (dentry) {
>>>       3951                 /* set pathbase to parent dir when msg_version >= 2 */
>>>       3952                 path = ceph_mdsc_build_path(dentry, &pathlen, &pathbase,
>>>       3953                                             recon_state->msg_version >= 2);
>>>       3954                 dput(dentry);
>>>       3955                 if (IS_ERR(path)) {
>>>       3956                         err = PTR_ERR(path);
>>>       3957                         goto out_err;
>>>       3958                 }
>>>       3959         } else {
>>>       3960                 path = NULL;
>>>       3961                 pathbase = 0;
>>>       3962         }
>>>       3963
>>>       3964         spin_lock(&ci->i_ceph_lock);
>>>       3965         cap = __get_cap_for_mds(ci, mds);
>>>       3966         if (!cap) {
>>>       3967                 spin_unlock(&ci->i_ceph_lock);
>>> --> 3968                 goto out_err;
>>>
>>> Set an error code?
>> This was intended, the 'err' was initialized as '0' in line 3945.
>>
>> It's no harm to skip this _cb() for current cap, so just succeeds it.
>>
> Smatch considers it intentional of the "ret = 0;" assignment is within
> 4 or 5 (I forget) lines of the goto.  Otherwise adding a comment would
> help reviewers.

Yeah, I will revise this to dismiss the warning.

Thanks

- Xiubo


> regards,
> dan carpenter
>


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048
  @ 2023-05-10  1:29 82% ` Yu Kuai
  2023-05-10  1:49 82%   ` Yu Kuai
  0 siblings, 1 reply; 200+ results
From: Yu Kuai @ 2023-05-10  1:29 UTC (permalink / raw)
  To: Guangwu Zhang, linux-block, io-uring, Jeff Moyer, Ming Lei,
	yukuai (C)

Hi,

在 2023/05/10 8:49, Guangwu Zhang 写道:
> Hi,
> 
> We found this kernel NULL pointer issue with latest
> linux-block/for-next, please check it.
> 
> Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
> 
> 
> [  112.483804] BUG: kernel NULL pointer dereference, address: 0000000000000048
> [  112.490809] #PF: supervisor read access in kernel mode
> [  112.495976] #PF: error_code(0x0000) - not-present page
> [  112.501141] PGD 800000044d20c067 P4D 800000044d20c067 PUD 4734d5067 PMD 0
> [  112.508057] Oops: 0000 [#1] PREEMPT SMP PTI
> [  112.512265] CPU: 24 PID: 7767 Comm: user-data Kdump: loaded Not
> tainted 6.4.0-rc1+ #1
> [  112.520141] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380
> Gen10, BIOS U30 06/20/2018
> [  112.528713] RIP: 0010:bfq_bio_bfqg+0x8/0x80

Can you show more details about addr2line result? It'll be much helpful.

Thanks,
Kuai
> [  112.532925] Code: 6b 70 48 89 43 60 5b 5d c3 cc cc cc cc 0f 1f 44
> 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00
> 41 54 53 <48> 8b 46 48 48 89 fb 48 89 f7 48 85 c0 74 26 48 63 15 72 40
> 6b 01
> [  112.551805] RSP: 0018:ffffaed687ef3b30 EFLAGS: 00010096
> [  112.557058] RAX: ffff9a90f2600000 RBX: ffff9a90f2600000 RCX: 0000000000000001
> [  112.564232] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9a90f2600000
> [  112.571408] RBP: ffff9a90c508d500 R08: ffff9a90e2b8a688 R09: ffff9a90e2b8a688
> [  112.578581] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> [  112.585756] R13: ffff9a90c508d500 R14: 0000000000000000 R15: 0000000000000000
> [  112.592930] FS:  00007fe41b0f0880(0000) GS:ffff9a94afc00000(0000)
> knlGS:0000000000000000
> [  112.601065] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  112.606842] CR2: 0000000000000048 CR3: 000000046346e005 CR4: 00000000007706e0
> [  112.614016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  112.621189] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [  112.628362] PKRU: 55555554
> [  112.631082] Call Trace:
> [  112.633539]  <TASK>
> [  112.635650]  bfq_bic_update_cgroup+0x2c/0x240
> [  112.640033]  bfq_init_rq+0xdd/0x670
> [  112.643545]  ? blk_rq_map_user_iov+0xc5/0x2f0
> [  112.647931]  bfq_insert_request.isra.0+0x5d/0x250
> [  112.652663]  bfq_insert_requests+0x59/0x80
> [  112.656782]  blk_mq_flush_plug_list+0x172/0x570
> [  112.661342]  blk_add_rq_to_plug+0x45/0x150
> [  112.665462]  nvme_uring_cmd_io+0x242/0x390 [nvme_core]
> [  112.670652]  io_uring_cmd+0x95/0x120
> [  112.674250]  io_issue_sqe+0x199/0x3d0
> [  112.677932]  io_submit_sqes+0x119/0x3d0
> [  112.681788]  __do_sys_io_uring_enter+0x2c2/0x470
> [  112.686433]  do_syscall_64+0x59/0x90
> [  112.690031]  ? exc_page_fault+0x65/0x150
> [  112.693977]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> [  112.699057] RIP: 0033:0x7fe41ae3ee5d
> [  112.702651] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e
> fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 93 af 1b 00 f7 d8 64 89
> 01 48
> [  112.721530] RSP: 002b:00007ffc6fdebc28 EFLAGS: 00000206 ORIG_RAX:
> 00000000000001aa
> [  112.729143] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fe41ae3ee5d
> [  112.736317] RDX: 0000000000000001 RSI: 0000000000000080 RDI: 0000000000000005
> [  112.743492] RBP: 00007ffc6fdec730 R08: 0000000000000000 R09: 0000000000000080
> [  112.750666] R10: 0000000000000001 R11: 0000000000000206 R12: 00007ffc6fdec848
> [  112.757841] R13: 0000000000401346 R14: 0000000000403de8 R15: 00007fe41b32c000
> [  112.765019]  </TASK>
> 
> .
> 


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048
  2023-05-10  1:29 82% ` Yu Kuai
@ 2023-05-10  1:49 82%   ` Yu Kuai
  2023-05-10  2:00 82%     ` Yu Kuai
  0 siblings, 1 reply; 200+ results
From: Yu Kuai @ 2023-05-10  1:49 UTC (permalink / raw)
  To: Yu Kuai, Guangwu Zhang, linux-block, io-uring, Jeff Moyer,
	Ming Lei, yukuai (C)

Hi,

在 2023/05/10 9:29, Yu Kuai 写道:
> Hi,
> 
> 在 2023/05/10 8:49, Guangwu Zhang 写道:
>> Hi,
>>
>> We found this kernel NULL pointer issue with latest
>> linux-block/for-next, please check it.
>>
>> Kernel repo: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
>>
>>
>> [  112.483804] BUG: kernel NULL pointer dereference, address: 
>> 0000000000000048

Base on this offset, 0x48 match bio->bi_blkg, so I guess this is because
bio is NULL, so the problem is that passthrough request insert into
elevator.

Can you try follwing patch?

diff --git a/block/blk-mq.c b/block/blk-mq.c
index f6dad0886a2f..fe3ed0a647e6 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2731,7 +2731,7 @@ static void blk_mq_dispatch_plug_list(struct 
blk_plug *plug, bool from_sched)
         trace_block_unplug(this_hctx->queue, depth, !from_sched);

         percpu_ref_get(&this_hctx->queue->q_usage_counter);
-       if (this_hctx->queue->elevator) {
+       if (this_hctx->queue->elevator && !blk_rq_is_passthrough(rq)) {
 
this_hctx->queue->elevator->type->ops.insert_requests(this_hctx,
                                 &list, 0);
                 blk_mq_run_hw_queue(this_hctx, from_sched);

Thanks,
Kuai
>> [  112.490809] #PF: supervisor read access in kernel mode
>> [  112.495976] #PF: error_code(0x0000) - not-present page
>> [  112.501141] PGD 800000044d20c067 P4D 800000044d20c067 PUD 4734d5067 
>> PMD 0
>> [  112.508057] Oops: 0000 [#1] PREEMPT SMP PTI
>> [  112.512265] CPU: 24 PID: 7767 Comm: user-data Kdump: loaded Not
>> tainted 6.4.0-rc1+ #1
>> [  112.520141] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380
>> Gen10, BIOS U30 06/20/2018
>> [  112.528713] RIP: 0010:bfq_bio_bfqg+0x8/0x80
> 
> Can you show more details about addr2line result? It'll be much helpful.
> 
> Thanks,
> Kuai
>> [  112.532925] Code: 6b 70 48 89 43 60 5b 5d c3 cc cc cc cc 0f 1f 44
>> 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00
>> 41 54 53 <48> 8b 46 48 48 89 fb 48 89 f7 48 85 c0 74 26 48 63 15 72 40
>> 6b 01
>> [  112.551805] RSP: 0018:ffffaed687ef3b30 EFLAGS: 00010096
>> [  112.557058] RAX: ffff9a90f2600000 RBX: ffff9a90f2600000 RCX: 
>> 0000000000000001
>> [  112.564232] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 
>> ffff9a90f2600000
>> [  112.571408] RBP: ffff9a90c508d500 R08: ffff9a90e2b8a688 R09: 
>> ffff9a90e2b8a688
>> [  112.578581] R10: 0000000000000000 R11: 0000000000000000 R12: 
>> 0000000000000000
>> [  112.585756] R13: ffff9a90c508d500 R14: 0000000000000000 R15: 
>> 0000000000000000
>> [  112.592930] FS:  00007fe41b0f0880(0000) GS:ffff9a94afc00000(0000)
>> knlGS:0000000000000000
>> [  112.601065] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [  112.606842] CR2: 0000000000000048 CR3: 000000046346e005 CR4: 
>> 00000000007706e0
>> [  112.614016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
>> 0000000000000000
>> [  112.621189] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 
>> 0000000000000400
>> [  112.628362] PKRU: 55555554
>> [  112.631082] Call Trace:
>> [  112.633539]  <TASK>
>> [  112.635650]  bfq_bic_update_cgroup+0x2c/0x240
>> [  112.640033]  bfq_init_rq+0xdd/0x670
>> [  112.643545]  ? blk_rq_map_user_iov+0xc5/0x2f0
>> [  112.647931]  bfq_insert_request.isra.0+0x5d/0x250
>> [  112.652663]  bfq_insert_requests+0x59/0x80
>> [  112.656782]  blk_mq_flush_plug_list+0x172/0x570
>> [  112.661342]  blk_add_rq_to_plug+0x45/0x150
>> [  112.665462]  nvme_uring_cmd_io+0x242/0x390 [nvme_core]
>> [  112.670652]  io_uring_cmd+0x95/0x120
>> [  112.674250]  io_issue_sqe+0x199/0x3d0
>> [  112.677932]  io_submit_sqes+0x119/0x3d0
>> [  112.681788]  __do_sys_io_uring_enter+0x2c2/0x470
>> [  112.686433]  do_syscall_64+0x59/0x90
>> [  112.690031]  ? exc_page_fault+0x65/0x150
>> [  112.693977]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
>> [  112.699057] RIP: 0033:0x7fe41ae3ee5d
>> [  112.702651] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e
>> fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
>> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 93 af 1b 00 f7 d8 64 89
>> 01 48
>> [  112.721530] RSP: 002b:00007ffc6fdebc28 EFLAGS: 00000206 ORIG_RAX:
>> 00000000000001aa
>> [  112.729143] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 
>> 00007fe41ae3ee5d
>> [  112.736317] RDX: 0000000000000001 RSI: 0000000000000080 RDI: 
>> 0000000000000005
>> [  112.743492] RBP: 00007ffc6fdec730 R08: 0000000000000000 R09: 
>> 0000000000000080
>> [  112.750666] R10: 0000000000000001 R11: 0000000000000206 R12: 
>> 00007ffc6fdec848
>> [  112.757841] R13: 0000000000401346 R14: 0000000000403de8 R15: 
>> 00007fe41b32c000
>> [  112.765019]  </TASK>
>>
>> .
>>
> 
> .
> 


^ permalink raw reply related	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048
  2023-05-10  1:49 82%   ` Yu Kuai
@ 2023-05-10  2:00 82%     ` Yu Kuai
  2023-05-10  2:17 82%       ` Jens Axboe
  0 siblings, 1 reply; 200+ results
From: Yu Kuai @ 2023-05-10  2:00 UTC (permalink / raw)
  To: Yu Kuai, Guangwu Zhang, linux-block, io-uring, Jeff Moyer,
	Ming Lei, yukuai (C)

Hi,

在 2023/05/10 9:49, Yu Kuai 写道:
> Hi,
> 
> 在 2023/05/10 9:29, Yu Kuai 写道:
>> Hi,
>>
>> 在 2023/05/10 8:49, Guangwu Zhang 写道:
>>> Hi,
>>>
>>> We found this kernel NULL pointer issue with latest
>>> linux-block/for-next, please check it.
>>>
>>> Kernel repo: 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
>>>
>>>
>>> [  112.483804] BUG: kernel NULL pointer dereference, address: 
>>> 0000000000000048
> 
> Base on this offset, 0x48 match bio->bi_blkg, so I guess this is because
> bio is NULL, so the problem is that passthrough request insert into
> elevator.
> 
Sorry that attached patch has some problem, please try this one.

diff --git a/block/blk-mq.c b/block/blk-mq.c
index f6dad0886a2f..bd94d8a5416f 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2712,6 +2712,7 @@ static void blk_mq_dispatch_plug_list(struct 
blk_plug *plug, bool from_sched)
         struct request **requeue_lastp = &requeue_list;
         unsigned int depth = 0;
         LIST_HEAD(list);
+       LIST_HEAD(passthrough_list);

         do {
                 struct request *rq = rq_list_pop(&plug->mq_list);
@@ -2723,7 +2724,10 @@ static void blk_mq_dispatch_plug_list(struct 
blk_plug *plug, bool from_sched)
                         rq_list_add_tail(&requeue_lastp, rq);
                         continue;
                 }
-               list_add(&rq->queuelist, &list);
+               if (blk_rq_is_passthrough(rq))
+                       list_add(&rq->queuelist, &passthrough_list);
+               else
+                       list_add(&rq->queuelist, &list);
                 depth++;
         } while (!rq_list_empty(plug->mq_list));

@@ -2731,6 +2735,9 @@ static void blk_mq_dispatch_plug_list(struct 
blk_plug *plug, bool from_sched)
         trace_block_unplug(this_hctx->queue, depth, !from_sched);

         percpu_ref_get(&this_hctx->queue->q_usage_counter);
+       if (!list_empty(&passthrough_list))
+               blk_mq_insert_requests(this_hctx, this_ctx, 
&passthrough_list,
+                                      from_sched);
         if (this_hctx->queue->elevator) {
 
this_hctx->queue->elevator->type->ops.insert_requests(this_hctx,
                                 &list, 0);

Thanks,
Kuai


^ permalink raw reply related	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048
  2023-05-10  2:00 82%     ` Yu Kuai
@ 2023-05-10  2:17 82%       ` Jens Axboe
  2023-05-10  3:20 82%         ` Yu Kuai
  0 siblings, 1 reply; 200+ results
From: Jens Axboe @ 2023-05-10  2:17 UTC (permalink / raw)
  To: Yu Kuai, Guangwu Zhang, linux-block, io-uring, Jeff Moyer,
	Ming Lei, yukuai (C)

On 5/9/23 8:00?PM, Yu Kuai wrote:
> Hi,
> 
> ? 2023/05/10 9:49, Yu Kuai ??:
>> Hi,
>>
>> ? 2023/05/10 9:29, Yu Kuai ??:
>>> Hi,
>>>
>>> ? 2023/05/10 8:49, Guangwu Zhang ??:
>>>> Hi,
>>>>
>>>> We found this kernel NULL pointer issue with latest
>>>> linux-block/for-next, please check it.
>>>>
>>>> Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
>>>>
>>>>
>>>> [  112.483804] BUG: kernel NULL pointer dereference, address: 0000000000000048
>>
>> Base on this offset, 0x48 match bio->bi_blkg, so I guess this is because
>> bio is NULL, so the problem is that passthrough request insert into
>> elevator.
>>
> Sorry that attached patch has some problem, please try this one.

Let's please fix this in bfq, this isn't a core issue and it's not a
good idea to work around it there.

-- 
Jens Axboe


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048
  2023-05-10  2:17 82%       ` Jens Axboe
@ 2023-05-10  3:20 82%         ` Yu Kuai
       [not found]               ` <CAGS2=YocNy9PkgRzzRdHAK1gGdjMxzA--PYS=sPrX_nCe4U6QA@mail.gmail.com>
  0 siblings, 1 reply; 200+ results
From: Yu Kuai @ 2023-05-10  3:20 UTC (permalink / raw)
  To: Jens Axboe, Yu Kuai, Guangwu Zhang, linux-block, io-uring,
	Jeff Moyer, Ming Lei, Jan Kara, Paolo Valente, yukuai (C)

Hi, Jens

在 2023/05/10 10:17, Jens Axboe 写道:
> On 5/9/23 8:00?PM, Yu Kuai wrote:
>> Hi,
>>
>> ? 2023/05/10 9:49, Yu Kuai ??:
>>> Hi,
>>>
>>> ? 2023/05/10 9:29, Yu Kuai ??:
>>>> Hi,
>>>>
>>>> ? 2023/05/10 8:49, Guangwu Zhang ??:
>>>>> Hi,
>>>>>
>>>>> We found this kernel NULL pointer issue with latest
>>>>> linux-block/for-next, please check it.
>>>>>
>>>>> Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
>>>>>
>>>>>
>>>>> [  112.483804] BUG: kernel NULL pointer dereference, address: 0000000000000048
>>>
>>> Base on this offset, 0x48 match bio->bi_blkg, so I guess this is because
>>> bio is NULL, so the problem is that passthrough request insert into
>>> elevator.
>>>
>> Sorry that attached patch has some problem, please try this one.
> 
> Let's please fix this in bfq, this isn't a core issue and it's not a
> good idea to work around it there.
> 

I can do that, but I'm not sure because it seems passthrough rq is not
supposed to insert into elevator.

Bfq always expect that bio is not NULL, and before this commit
a327c341dc65 ("blk-mq: fix passthrough plugging"), passthrough rq can
never insert into plug, and therefor passthrough rq can never insert
into elevator.

Thanks,
Kuai



^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048
       [not found]               ` <CAGS2=YocNy9PkgRzzRdHAK1gGdjMxzA--PYS=sPrX_nCe4U6QA@mail.gmail.com>
@ 2023-05-10  6:39 82%             ` Ming Lei
  2023-05-10 12:08 82%               ` Guangwu Zhang
  2023-05-10  6:55 82%               ` Yu Kuai
  0 siblings, 2 replies; 200+ results
From: Ming Lei @ 2023-05-10  6:39 UTC (permalink / raw)
  To: Guangwu Zhang
  Cc: Yu Kuai, Jens Axboe, linux-block, io-uring, Jeff Moyer, Jan Kara,
	Paolo Valente, yukuai (C)

On Wed, May 10, 2023 at 12:05:07PM +0800, Guangwu Zhang wrote:
> HI,
> after apply your patch[1], the system will panic after reboot.
> 

Maybe you can try the following patch?

diff --git a/block/blk-mq.c b/block/blk-mq.c
index f6dad0886a2f..d84174a7e997 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1303,7 +1303,7 @@ void blk_execute_rq_nowait(struct request *rq, bool at_head)
         * device, directly accessing the plug instead of using blk_mq_plug()
         * should not have any consequences.
         */
-       if (current->plug && !at_head) {
+       if (current->plug && !at_head && rq->bio) {
                blk_add_rq_to_plug(current->plug, rq);
                return;
        }


thanks, 
Ming


^ permalink raw reply related	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048
  2023-05-10  6:39 82%             ` Ming Lei
  2023-05-10 12:08 82%               ` Guangwu Zhang
@ 2023-05-10  6:55 82%               ` Yu Kuai
  1 sibling, 0 replies; 200+ results
From: Yu Kuai @ 2023-05-10  6:55 UTC (permalink / raw)
  To: Ming Lei, Guangwu Zhang
  Cc: Yu Kuai, Jens Axboe, linux-block, io-uring, Jeff Moyer, Jan Kara,
	Paolo Valente, yukuai (C)

Hi,

在 2023/05/10 14:39, Ming Lei 写道:
> On Wed, May 10, 2023 at 12:05:07PM +0800, Guangwu Zhang wrote:
>> HI,
>> after apply your patch[1], the system will panic after reboot.

This is werid, I just reporduce this problem in my VM, and I verified
this patch can fix the problem.

Anyway, Ming's patch looks better, you can try it.

Thanks,
Kuai
>>
> 
> Maybe you can try the following patch?
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index f6dad0886a2f..d84174a7e997 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1303,7 +1303,7 @@ void blk_execute_rq_nowait(struct request *rq, bool at_head)
>           * device, directly accessing the plug instead of using blk_mq_plug()
>           * should not have any consequences.
>           */
> -       if (current->plug && !at_head) {
> +       if (current->plug && !at_head && rq->bio) {
>                  blk_add_rq_to_plug(current->plug, rq);
>                  return;
>          }
> 
> 
> thanks,
> Ming
> 
> .
> 


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048
  2023-05-10  6:39 82%             ` Ming Lei
@ 2023-05-10 12:08 82%               ` Guangwu Zhang
  2023-05-10  6:55 82%               ` Yu Kuai
  1 sibling, 0 replies; 200+ results
From: Guangwu Zhang @ 2023-05-10 12:08 UTC (permalink / raw)
  To: Ming Lei
  Cc: Yu Kuai, Jens Axboe, linux-block, io-uring, Jeff Moyer, Jan Kara,
	Paolo Valente, yukuai (C)

Hi,
Don't hit the issue after apply your patch.
thanks

Ming Lei <ming.lei@redhat.com> 于2023年5月10日周三 14:39写道:
>
> On Wed, May 10, 2023 at 12:05:07PM +0800, Guangwu Zhang wrote:
> > HI,
> > after apply your patch[1], the system will panic after reboot.
> >
>
> Maybe you can try the following patch?
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index f6dad0886a2f..d84174a7e997 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1303,7 +1303,7 @@ void blk_execute_rq_nowait(struct request *rq, bool at_head)
>          * device, directly accessing the plug instead of using blk_mq_plug()
>          * should not have any consequences.
>          */
> -       if (current->plug && !at_head) {
> +       if (current->plug && !at_head && rq->bio) {
>                 blk_add_rq_to_plug(current->plug, rq);
>                 return;
>         }
>
>
> thanks,
> Ming
>


-- 

Guangwu Zhang, RHCE, ISTQB, ITIL

Quality Engineer, Kernel Storage QE

Red Hat


^ permalink raw reply	[relevance 82%]

* Re: [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in __bpf_prog_put()
  @ 2023-05-16 17:08 82% ` Yonghong Song
       [not found]       ` <CALyQVax8X63qekZVhvRTmZFFs+ucPKRkBB7UnRZk6Hu3ggi7Og@mail.gmail.com>
  0 siblings, 1 reply; 200+ results
From: Yonghong Song @ 2023-05-16 17:08 UTC (permalink / raw)
  To: starmiku1207184332, ast, daniel, john.fastabend, andrii,
	martin.lau, song, yhs, kpsingh, sdf, haoluo, jolsa, davem, kuba,
	hawk
  Cc: bpf, linux-kernel, netdev



On 5/16/23 4:18 AM, starmiku1207184332@gmail.com wrote:
> From: Teng Qi <starmiku1207184332@gmail.com>
> 
> Hi, bpf developers,
> 
> We are developing a static tool to check the matching between helpers and the
> context of hooks. During our analysis, we have discovered some important
> findings that we would like to report.
> 
> ‘kernel/bpf/syscall.c: 2097 __bpf_prog_put()’ shows that function
> bpf_prog_put_deferred() won`t be called in the condition of
> ‘in_irq() || irqs_disabled()’.
> if (in_irq() || irqs_disabled()) {
>      INIT_WORK(&aux->work, bpf_prog_put_deferred);
>      schedule_work(&aux->work);
> } else {
> 
>      bpf_prog_put_deferred(&aux->work);
> }
> 
> We suspect this condition exists because there might be sleepable operations
> in the callees of the bpf_prog_put_deferred() function:
> kernel/bpf/syscall.c: 2097 __bpf_prog_put()
> kernel/bpf/syscall.c: 2084 bpf_prog_put_deferred()
> kernel/bpf/syscall.c: 2063 __bpf_prog_put_noref()
> kvfree(prog->aux->jited_linfo);
> kvfree(prog->aux->linfo);

Looks like you only have suspicion here. Could you find a real violation 
here where __bpf_prog_put() is called with !in_irq() && 
!irqs_disabled(), but inside spin_lock or rcu read lock? I have not seen
things like that.

> 
> Additionally, we found that array prog->aux->jited_linfo is initialized in
> ‘kernel/bpf/core.c: 157 bpf_prog_alloc_jited_linfo()’:
> prog->aux->jited_linfo = kvcalloc(prog->aux->nr_linfo,
>    sizeof(*prog->aux->jited_linfo), bpf_memcg_flags(GFP_KERNEL | __GFP_NOWARN));

Any problem here?

> 
> Our question is whether the condition 'in_irq() || irqs_disabled() == false' is
> sufficient for calling 'kvfree'. We are aware that calling 'kvfree' within the
> context of a spin lock or an RCU lock is unsafe.
> 
> Therefore, we propose modifying the condition to include in_atomic(). Could we
> update the condition as follows: "in_irq() || irqs_disabled() || in_atomic()"?
> 
> Thank you! We look forward to your feedback.
> 
> Signed-off-by: Teng Qi <starmiku1207184332@gmail.com>

^ permalink raw reply	[relevance 82%]

* Re: [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in __bpf_prog_put()
       [not found]       ` <CALyQVax8X63qekZVhvRTmZFFs+ucPKRkBB7UnRZk6Hu3ggi7Og@mail.gmail.com>
@ 2023-05-21  3:44 82%     ` Yonghong Song
       [not found]           ` <CALyQVazb=D1ejapiFdTnan6JbjFJA2q9ifhSsmF4OC9MDz3oAw@mail.gmail.com>
  0 siblings, 1 reply; 200+ results
From: Yonghong Song @ 2023-05-21  3:44 UTC (permalink / raw)
  To: Teng Qi
  Cc: ast, daniel, john.fastabend, andrii, martin.lau, song, yhs,
	kpsingh, sdf, haoluo, jolsa, davem, kuba, hawk, bpf, linux-kernel,
	netdev



On 5/19/23 7:18 AM, Teng Qi wrote:
> Thank you for your response.
>  > Looks like you only have suspicion here. Could you find a real violation
>  > here where __bpf_prog_put() is called with !in_irq() &&
>  > !irqs_disabled(), but inside spin_lock or rcu read lock? I have not seen
>  > things like that.
> 
> For the complex conditions to call bpf_prog_put() with 1 refcnt, we have 
> been
> unable to really trigger this atomic violation after trying to construct
> test cases manually. But we found that it is possible to show cases with
> !in_irq() && !irqs_disabled(), but inside spin_lock or rcu read lock.
> For example, even a failed case, one of selftest cases of bpf, netns_cookie,
> calls bpf_sock_map_update() and may indirectly call bpf_prog_put()
> only inside rcu read lock: The possible call stack is:
> net/core/sock_map.c: 615 bpf_sock_map_update()
> net/core/sock_map.c: 468 sock_map_update_common()
> net/core/sock_map.c:  217 sock_map_link()
> kernel/bpf/syscall.c: 2111 bpf_prog_put()
> 
> The files about netns_cookie include
> tools/testing/selftests/bpf/progs/netns_cookie_prog.c and
> tools/testing/selftests/bpf/prog_tests/netns_cookie.c. We inserted the
> following code in
> ‘net/core/sock_map.c: 468 sock_map_update_common()’:
> static int sock_map_update_common(..)
> {
>          int inIrq = in_irq();
>          int irqsDisabled = irqs_disabled();
>          int preemptBits = preempt_count();
>          int inAtomic = in_atomic();
>          int rcuHeld = rcu_read_lock_held();
>          printk("in_irq() %d, irqs_disabled() %d, preempt_count() %d,
>            in_atomic() %d, rcu_read_lock_held() %d", inIrq, irqsDisabled,
>            preemptBits, inAtomic, rcuHeld);
> }
> 
> The output message is as follows:
> root@(none):/root/bpf# ./test_progs -t netns_cookie
> [  137.639188] in_irq() 0, irqs_disabled() 0, preempt_count() 0, 
> in_atomic() 0,
>          rcu_read_lock_held() 1
> #113     netns_cookie:OK
> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
> 
> We notice that there are numerous callers in kernel/, net/ and drivers/, 
> so we
> highly suggest modifying __bpf_prog_put() to address this gap. The gap 
> exists
> because __bpf_prog_put() is only safe under in_irq() || irqs_disabled()
> but not in_atomic() || rcu_read_lock_held(). The following code snippet may
> mislead developers into thinking that bpf_prog_put() is safe in all 
> contexts.
> if (in_irq() || irqs_disabled()) {
>          INIT_WORK(&aux->work, bpf_prog_put_deferred);
>          schedule_work(&aux->work);
> } else {
>          bpf_prog_put_deferred(&aux->work);
> }
> 
> Implicit dependency may lead to issues.
> 
>  > Any problem here?
> We mentioned it to demonstrate the possibility of kvfree() being
> called by __bpf_prog_put_noref().
> 
> Thanks.
> -- Teng Qi
> 
> On Wed, May 17, 2023 at 1:08 AM Yonghong Song <yhs@meta.com 
> <mailto:yhs@meta.com>> wrote:
> 
> 
> 
>     On 5/16/23 4:18 AM, starmiku1207184332@gmail.com
>     <mailto:starmiku1207184332@gmail.com> wrote:
>      > From: Teng Qi <starmiku1207184332@gmail.com
>     <mailto:starmiku1207184332@gmail.com>>
>      >
>      > Hi, bpf developers,
>      >
>      > We are developing a static tool to check the matching between
>     helpers and the
>      > context of hooks. During our analysis, we have discovered some
>     important
>      > findings that we would like to report.
>      >
>      > ‘kernel/bpf/syscall.c: 2097 __bpf_prog_put()’ shows that function
>      > bpf_prog_put_deferred() won`t be called in the condition of
>      > ‘in_irq() || irqs_disabled()’.
>      > if (in_irq() || irqs_disabled()) {
>      >      INIT_WORK(&aux->work, bpf_prog_put_deferred);
>      >      schedule_work(&aux->work);
>      > } else {
>      >
>      >      bpf_prog_put_deferred(&aux->work);
>      > }
>      >
>      > We suspect this condition exists because there might be sleepable
>     operations
>      > in the callees of the bpf_prog_put_deferred() function:
>      > kernel/bpf/syscall.c: 2097 __bpf_prog_put()
>      > kernel/bpf/syscall.c: 2084 bpf_prog_put_deferred()
>      > kernel/bpf/syscall.c: 2063 __bpf_prog_put_noref()
>      > kvfree(prog->aux->jited_linfo);
>      > kvfree(prog->aux->linfo);
> 
>     Looks like you only have suspicion here. Could you find a real
>     violation
>     here where __bpf_prog_put() is called with !in_irq() &&
>     !irqs_disabled(), but inside spin_lock or rcu read lock? I have not seen
>     things like that.
> 
>      >
>      > Additionally, we found that array prog->aux->jited_linfo is
>     initialized in
>      > ‘kernel/bpf/core.c: 157 bpf_prog_alloc_jited_linfo()’:
>      > prog->aux->jited_linfo = kvcalloc(prog->aux->nr_linfo,
>      >    sizeof(*prog->aux->jited_linfo), bpf_memcg_flags(GFP_KERNEL |
>     __GFP_NOWARN));
> 
>     Any problem here?
> 
>      >
>      > Our question is whether the condition 'in_irq() ||
>     irqs_disabled() == false' is
>      > sufficient for calling 'kvfree'. We are aware that calling
>     'kvfree' within the
>      > context of a spin lock or an RCU lock is unsafe.

Your above analysis makes sense if indeed that kvfree cannot appear
inside a spin lock region or RCU read lock region. But is it true?
I checked a few code paths in kvfree/kfree. It is either guarded
with local_irq_save/restore or by 
spin_lock_irqsave/spin_unlock_irqrestore, etc. Did I miss
anything? Are you talking about RT kernel here?


>      >
>      > Therefore, we propose modifying the condition to include
>     in_atomic(). Could we
>      > update the condition as follows: "in_irq() || irqs_disabled() ||
>     in_atomic()"?
>      >
>      > Thank you! We look forward to your feedback.
>      >
>      > Signed-off-by: Teng Qi <starmiku1207184332@gmail.com
>     <mailto:starmiku1207184332@gmail.com>>
> 

^ permalink raw reply	[relevance 82%]

* [Bug 217470] [Syzkaller & bisect] There is BUG: unable to handle kernel NULL pointer dereference in xfs_extent_free_diff_items in v6.4-rc3
  @ 2023-05-22  2:11 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-05-22  2:11 UTC (permalink / raw)
  To: linux-xfs

https://bugzilla.kernel.org/show_bug.cgi?id=217470

--- Comment #1 from xupengfe (pengfei.xu@intel.com) ---
Here is the xfs Linux kernel community link:
https://lore.kernel.org/linux-xfs/ZGrOYDZf+k0i4jyM@xpf.sh.intel.com/T/#u

Thanks!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in __bpf_prog_put()
  @ 2023-05-24 19:34 82%             ` Yonghong Song
  2023-05-24 19:44 82%               ` Alexei Starovoitov
    0 siblings, 2 replies; 200+ results
From: Yonghong Song @ 2023-05-24 19:34 UTC (permalink / raw)
  To: Teng Qi
  Cc: ast, daniel, john.fastabend, andrii, martin.lau, song, yhs,
	kpsingh, sdf, haoluo, jolsa, davem, kuba, hawk, bpf, linux-kernel,
	netdev



On 5/24/23 5:42 AM, Teng Qi wrote:
> Thank you.
> 
>> We cannot use rcu_read_lock_held() in the 'if' statement. The return
>> value rcu_read_lock_held() could be 1 for some configurations regardless
>> whether rcu_read_lock() is really held or not. In most cases,
>> rcu_read_lock_held() is used in issuing potential warnings.
>> Maybe there are other ways to record whether rcu_read_lock() is held or not?
> 
> Sorry. I was not aware of the dependency of configurations of
> rcu_read_lock_held().
> 
>> If we cannot resolve rcu_read_lock() presence issue, maybe the condition
>> can be !in_interrupt(), so any process-context will go to a workqueue.
> 
> I agree that using !in_interrupt() as a condition is an acceptable solution.

This should work although it could be conservative.

> 
>> Alternatively, we could have another solution. We could add another
>> function e.g., bpf_prog_put_rcu(), which indicates that bpf_prog_put()
>> will be done in rcu context.
> 
> Implementing a new function like bpf_prog_put_rcu() is a solution that involves
> more significant changes.

Maybe we can change signature of bpf_prog_put instead? Like
    void bpf_prog_put(struct bpf_prog *prog, bool in_rcu)
and inside bpf_prog_put we can add
    WARN_ON_ONCE(in_rcu && !bpf_rcu_lock_held());

> 
>> So if in_interrupt(), do kvfree, otherwise,
>> put into a workqueue.
> 
> Shall we proceed with submitting a patch following this approach?

You could choose either of the above although I think with newer 
bpf_prog_put() is better.

BTW, please do create a test case, e.g, sockmap test case which
can show the problem with existing code base.

> 
> I would like to mention something unrelated to the possible bug. At this
> moment, things seem to be more puzzling. vfree() is safe under in_interrupt()
> but not safe under other atomic contexts.
> This disorder challenges our conventional belief, a monotonic incrementation
> of limitations of the hierarchical atomic contexts, that programer needs
> to be more and more careful to write code under rcu read lock, spin lock,
> bh disable, interrupt...
> This disorder can lead to unexpected consequences, such as code being safe
> under interrupts but not safe under spin locks.
> The disorder makes kernel programming more complex and may result in more bugs.
> Even though we find a way to resolve the possible bug about the bpf_prog_put(),
> I feel sad for undermining of kernel`s maintainability and disorder of
> hierarchy of atomic contexts.
> 
> -- Teng Qi
> 
> On Tue, May 23, 2023 at 12:33 PM Yonghong Song <yhs@meta.com> wrote:
>>
>>
>>
>> On 5/21/23 6:39 AM, Teng Qi wrote:
>>> Thank you.
>>>
>>>   > Your above analysis makes sense if indeed that kvfree cannot appear
>>>   > inside a spin lock region or RCU read lock region. But is it true?
>>>   > I checked a few code paths in kvfree/kfree. It is either guarded
>>>   > with local_irq_save/restore or by
>>>   > spin_lock_irqsave/spin_unlock_
>>>   > irqrestore, etc. Did I miss
>>>   > anything? Are you talking about RT kernel here?
>>>
>>> To see the sleepable possibility of kvfree, it is important to analyze the
>>> following calling stack:
>>> mm/util.c: 645 kvfree()
>>> mm/vmalloc.c: 2763 vfree()
>>>
>>> In kvfree(), to call vfree, if the pointer addr points to memory
>>> allocated by
>>> vmalloc(), it calls vfree().
>>> void kvfree(const void *addr)
>>> {
>>>           if (is_vmalloc_addr(addr))
>>>                   vfree(addr);
>>>           else
>>>                   kfree(addr);
>>> }
>>>
>>> In vfree(), in_interrupt() and might_sleep() need to be considered.
>>> void vfree(const void *addr)
>>> {
>>>           // ...
>>>           if (unlikely(in_interrupt()))
>>>           {
>>>                   vfree_atomic(addr);
>>>                   return;
>>>           }
>>>           // ...
>>>           might_sleep();
>>>           // ...
>>> }
>>
>> Sorry. I didn't check vfree path. So it does look like that
>> we need to pay special attention to non interrupt part.
>>
>>>
>>> The vfree() may sleep if in_interrupt() == false. The RCU read lock region
>>> could have in_interrupt() == false and spin lock region which only disables
>>> preemption also has in_interrupt() == false. So the kvfree() cannot appear
>>> inside a spin lock region or RCU read lock region if the pointer addr points
>>> to memory allocated by vmalloc().
>>>
>>>   > > Therefore, we propose modifying the condition to include
>>>   > > in_atomic(). Could we
>>>   > > update the condition as follows: "in_irq() || irqs_disabled() ||
>>>   > > in_atomic()"?
>>>   > Thank you! We look forward to your feedback.
>>>
>>> We now think that ‘irqs_disabled() || in_atomic() ||
>>> rcu_read_lock_held()’ is
>>> more proper. irqs_disabled() is for irq flag reg, in_atomic() is for
>>> preempt count and rcu_read_lock_held() is for RCU read lock region.
>>
>> We cannot use rcu_read_lock_held() in the 'if' statement. The return
>> value rcu_read_lock_held() could be 1 for some configuraitons regardless
>> whether rcu_read_lock() is really held or not. In most cases,
>> rcu_read_lock_held() is used in issuing potential warnings.
>> Maybe there are other ways to record whether rcu_read_lock() is held or not?
>>
>> I agree with your that 'irqs_disabled() || in_atomic()' makes sense
>> since it covers process context local_irq_save() and spin_lock() cases.
>>
>> If we cannot resolve rcu_read_lock() presence issue, maybe the condition
>> can be !in_interrupt(), so any process-context will go to a workqueue.
>>
>> Alternatively, we could have another solution. We could add another
>> function e.g., bpf_prog_put_rcu(), which indicates that bpf_prog_put()
>> will be done in rcu context. So if in_interrupt(), do kvfree, otherwise,
>> put into a workqueue.
>>
>>
>>>
>>> -- Teng Qi
>>>
>>> On Sun, May 21, 2023 at 11:45 AM Yonghong Song <yhs@meta.com
>>> <mailto:yhs@meta.com>> wrote:
>>>
>>>
>>>
>>>      On 5/19/23 7:18 AM, Teng Qi wrote:
>>>       > Thank you for your response.
>>>       >  > Looks like you only have suspicion here. Could you find a real
>>>      violation
>>>       >  > here where __bpf_prog_put() is called with !in_irq() &&
>>>       >  > !irqs_disabled(), but inside spin_lock or rcu read lock? I
>>>      have not seen
>>>       >  > things like that.
>>>       >
>>>       > For the complex conditions to call bpf_prog_put() with 1 refcnt,
>>>      we have
>>>       > been
>>>       > unable to really trigger this atomic violation after trying to
>>>      construct
>>>       > test cases manually. But we found that it is possible to show
>>>      cases with
>>>       > !in_irq() && !irqs_disabled(), but inside spin_lock or rcu read lock.
>>>       > For example, even a failed case, one of selftest cases of bpf,
>>>      netns_cookie,
>>>       > calls bpf_sock_map_update() and may indirectly call bpf_prog_put()
>>>       > only inside rcu read lock: The possible call stack is:
>>>       > net/core/sock_map.c: 615 bpf_sock_map_update()
>>>       > net/core/sock_map.c: 468 sock_map_update_common()
>>>       > net/core/sock_map.c:  217 sock_map_link()
>>>       > kernel/bpf/syscall.c: 2111 bpf_prog_put()
>>>       >
>>>       > The files about netns_cookie include
>>>       > tools/testing/selftests/bpf/progs/netns_cookie_prog.c and
>>>       > tools/testing/selftests/bpf/prog_tests/netns_cookie.c. We
>>>      inserted the
>>>       > following code in
>>>       > ‘net/core/sock_map.c: 468 sock_map_update_common()’:
>>>       > static int sock_map_update_common(..)
>>>       > {
>>>       >          int inIrq = in_irq();
>>>       >          int irqsDisabled = irqs_disabled();
>>>       >          int preemptBits = preempt_count();
>>>       >          int inAtomic = in_atomic();
>>>       >          int rcuHeld = rcu_read_lock_held();
>>>       >          printk("in_irq() %d, irqs_disabled() %d, preempt_count() %d,
>>>       >            in_atomic() %d, rcu_read_lock_held() %d", inIrq,
>>>      irqsDisabled,
>>>       >            preemptBits, inAtomic, rcuHeld);
>>>       > }
>>>       >
>>>       > The output message is as follows:
>>>       > root@(none):/root/bpf# ./test_progs -t netns_cookie
>>>       > [  137.639188] in_irq() 0, irqs_disabled() 0, preempt_count() 0,
>>>       > in_atomic() 0,
>>>       >          rcu_read_lock_held() 1
>>>       > #113     netns_cookie:OK
>>>       > Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>>>       >
>>>       > We notice that there are numerous callers in kernel/, net/ and
>>>      drivers/,
>>>       > so we
>>>       > highly suggest modifying __bpf_prog_put() to address this gap.
>>>      The gap
>>>       > exists
>>>       > because __bpf_prog_put() is only safe under in_irq() ||
>>>      irqs_disabled()
>>>       > but not in_atomic() || rcu_read_lock_held(). The following code
>>>      snippet may
>>>       > mislead developers into thinking that bpf_prog_put() is safe in all
>>>       > contexts.
>>>       > if (in_irq() || irqs_disabled()) {
>>>       >          INIT_WORK(&aux->work, bpf_prog_put_deferred);
>>>       >          schedule_work(&aux->work);
>>>       > } else {
>>>       >          bpf_prog_put_deferred(&aux->work);
>>>       > }
>>>       >
>>>       > Implicit dependency may lead to issues.
>>>       >
>>>       >  > Any problem here?
>>>       > We mentioned it to demonstrate the possibility of kvfree() being
>>>       > called by __bpf_prog_put_noref().
>>>       >
>>>       > Thanks.
>>>       > -- Teng Qi
>>>       >
>>>       > On Wed, May 17, 2023 at 1:08 AM Yonghong Song <yhs@meta.com
>>>      <mailto:yhs@meta.com>
>>>       > <mailto:yhs@meta.com <mailto:yhs@meta.com>>> wrote:
>>>       >
>>>       >
>>>       >
>>>       >     On 5/16/23 4:18 AM, starmiku1207184332@gmail.com
>>>      <mailto:starmiku1207184332@gmail.com>
>>>       >     <mailto:starmiku1207184332@gmail.com
>>>      <mailto:starmiku1207184332@gmail.com>> wrote:
>>>       >      > From: Teng Qi <starmiku1207184332@gmail.com
>>>      <mailto:starmiku1207184332@gmail.com>
>>>       >     <mailto:starmiku1207184332@gmail.com
>>>      <mailto:starmiku1207184332@gmail.com>>>
>>>       >      >
>>>       >      > Hi, bpf developers,
>>>       >      >
>>>       >      > We are developing a static tool to check the matching between
>>>       >     helpers and the
>>>       >      > context of hooks. During our analysis, we have discovered some
>>>       >     important
>>>       >      > findings that we would like to report.
>>>       >      >
>>>       >      > ‘kernel/bpf/syscall.c: 2097 __bpf_prog_put()’ shows that
>>>      function
>>>       >      > bpf_prog_put_deferred() won`t be called in the condition of
>>>       >      > ‘in_irq() || irqs_disabled()’.
>>>       >      > if (in_irq() || irqs_disabled()) {
>>>       >      >      INIT_WORK(&aux->work, bpf_prog_put_deferred);
>>>       >      >      schedule_work(&aux->work);
>>>       >      > } else {
>>>       >      >
>>>       >      >      bpf_prog_put_deferred(&aux->work);
>>>       >      > }
>>>       >      >
>>>       >      > We suspect this condition exists because there might be
>>>      sleepable
>>>       >     operations
>>>       >      > in the callees of the bpf_prog_put_deferred() function:
>>>       >      > kernel/bpf/syscall.c: 2097 __bpf_prog_put()
>>>       >      > kernel/bpf/syscall.c: 2084 bpf_prog_put_deferred()
>>>       >      > kernel/bpf/syscall.c: 2063 __bpf_prog_put_noref()
>>>       >      > kvfree(prog->aux->jited_linfo);
>>>       >      > kvfree(prog->aux->linfo);
>>>       >
>>>       >     Looks like you only have suspicion here. Could you find a real
>>>       >     violation
>>>       >     here where __bpf_prog_put() is called with !in_irq() &&
>>>       >     !irqs_disabled(), but inside spin_lock or rcu read lock? I
>>>      have not seen
>>>       >     things like that.
>>>       >
>>>       >      >
>>>       >      > Additionally, we found that array prog->aux->jited_linfo is
>>>       >     initialized in
>>>       >      > ‘kernel/bpf/core.c: 157 bpf_prog_alloc_jited_linfo()’:
>>>       >      > prog->aux->jited_linfo = kvcalloc(prog->aux->nr_linfo,
>>>       >      >    sizeof(*prog->aux->jited_linfo),
>>>      bpf_memcg_flags(GFP_KERNEL |
>>>       >     __GFP_NOWARN));
>>>       >
>>>       >     Any problem here?
>>>       >
>>>       >      >
>>>       >      > Our question is whether the condition 'in_irq() ||
>>>       >     irqs_disabled() == false' is
>>>       >      > sufficient for calling 'kvfree'. We are aware that calling
>>>       >     'kvfree' within the
>>>       >      > context of a spin lock or an RCU lock is unsafe.
>>>
>>>      Your above analysis makes sense if indeed that kvfree cannot appear
>>>      inside a spin lock region or RCU read lock region. But is it true?
>>>      I checked a few code paths in kvfree/kfree. It is either guarded
>>>      with local_irq_save/restore or by
>>>      spin_lock_irqsave/spin_unlock_irqrestore, etc. Did I miss
>>>      anything? Are you talking about RT kernel here?
>>>
>>>
>>>       >      >
>>>       >      > Therefore, we propose modifying the condition to include
>>>       >     in_atomic(). Could we
>>>       >      > update the condition as follows: "in_irq() ||
>>>      irqs_disabled() ||
>>>       >     in_atomic()"?
>>>       >      >
>>>       >      > Thank you! We look forward to your feedback.
>>>       >      >
>>>       >      > Signed-off-by: Teng Qi <starmiku1207184332@gmail.com
>>>      <mailto:starmiku1207184332@gmail.com>
>>>       >     <mailto:starmiku1207184332@gmail.com
>>>      <mailto:starmiku1207184332@gmail.com>>>
>>>       >
>>>

^ permalink raw reply	[relevance 82%]

* Re: [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in __bpf_prog_put()
  2023-05-24 19:34 82%             ` Yonghong Song
@ 2023-05-24 19:44 82%               ` Alexei Starovoitov
    1 sibling, 0 replies; 200+ results
From: Alexei Starovoitov @ 2023-05-24 19:44 UTC (permalink / raw)
  To: Yonghong Song
  Cc: Teng Qi, Alexei Starovoitov, Daniel Borkmann, John Fastabend,
	Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
	KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, David S. Miller,
	Jakub Kicinski, Jesper Dangaard Brouer, bpf, LKML,
	Network Development

On Wed, May 24, 2023 at 12:34 PM Yonghong Song <yhs@meta.com> wrote:
>
>
>
> On 5/24/23 5:42 AM, Teng Qi wrote:
> > Thank you.
> >
> >> We cannot use rcu_read_lock_held() in the 'if' statement. The return
> >> value rcu_read_lock_held() could be 1 for some configurations regardless
> >> whether rcu_read_lock() is really held or not. In most cases,
> >> rcu_read_lock_held() is used in issuing potential warnings.
> >> Maybe there are other ways to record whether rcu_read_lock() is held or not?
> >
> > Sorry. I was not aware of the dependency of configurations of
> > rcu_read_lock_held().
> >
> >> If we cannot resolve rcu_read_lock() presence issue, maybe the condition
> >> can be !in_interrupt(), so any process-context will go to a workqueue.
> >
> > I agree that using !in_interrupt() as a condition is an acceptable solution.
>
> This should work although it could be conservative.
>
> >
> >> Alternatively, we could have another solution. We could add another
> >> function e.g., bpf_prog_put_rcu(), which indicates that bpf_prog_put()
> >> will be done in rcu context.
> >
> > Implementing a new function like bpf_prog_put_rcu() is a solution that involves
> > more significant changes.
>
> Maybe we can change signature of bpf_prog_put instead? Like
>     void bpf_prog_put(struct bpf_prog *prog, bool in_rcu)
> and inside bpf_prog_put we can add
>     WARN_ON_ONCE(in_rcu && !bpf_rcu_lock_held());

bpf_rcu_lock_held() is used for different cases.

Here s/in_irq/in_interrupt/ inside bpf_prog_put() is enough
to address this theoretical issue.

^ permalink raw reply	[relevance 82%]

* Re: [BUG 6.4-rc3] BUG: kernel NULL pointer dereference in __dev_fwnode
  @ 2023-05-25 16:42 82%   ` Sebastian Reichel
  2023-05-26  2:08 82%     ` Steven Rostedt
  0 siblings, 1 reply; 200+ results
From: Sebastian Reichel @ 2023-05-25 16:42 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, LKML, Masami Hiramatsu, Linus Walleij,
	Matti Vaittinen, linux-pm

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

Hi,

On Wed, May 24, 2023 at 11:28:41AM -0700, Linus Torvalds wrote:
> On Wed, May 24, 2023 at 10:12 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > I started adding fixes to my urgent branch rebased on top of v6.4-rc3
> > and ran my tests. Unfortunately they crashed on unrelated code.
> >
> > Here's the dump:
> >
> >  BUG: kernel NULL pointer dereference, address: 00000000000003e8
> >  RIP: 0010:__dev_fwnode+0x9/0x2a
> >  Code: ff 85 c0 78 16 48 8b 3c 24 89 c6 59 e9 e0 f7 ff ff b8 ea ff ff ff c3 cc cc cc cc 5a c3 cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 <48> 8b 87 e8 03 00 00 48
> >  83 c0 18 c3 cc cc cc cc 48
> 
> That disassembles to
> 
>     endbr64
>     nopl   0x0(%rax,%rax,1)
>     mov    0x3e8(%rdi),%rax
>     add    $0x18,%rax
>     ret
> 
> which looks like it must be the
> 
>     return dev->fwnode;
> 
> with a NULL 'dev'. Which makes sense for __dev_fwnode with CONFIG_OF
> not enabled.
> 
> Except I have no idea what that odd 'add $0x18" is all about. Strange.
> 
> Anyway, the caller seems to be this code in power_supply_get_battery_info():
> 
>         if (psy->of_node) {
>             .. presumably not this ..
>         } else {
>                 err = fwnode_property_get_reference_args(
>                                         dev_fwnode(psy->dev.parent),
>                                         "monitored-battery", NULL, 0, 0, &args);
>                 ...
> 
> so I suspect we have psy->dev.parent being NULL.
> 
> >  I ran a bisect and it found it to be this commit:
> >
> > 27a2195efa8d2 ("power: supply: core: auto-exposure of simple-battery data")
> >
> > I checked out that commit and tested it, and it crashed. I then
> > reverted that commit, and the crash goes away.
> 
> At a guess, it's
> 
>  (a) the new code to expose battery info at registration time:
> 
> +       /*
> +        * Expose constant battery info, if it is available. While there are
> +        * some chargers accessing constant battery data, we only want to
> +        * expose battery data to userspace for battery devices.
> +        */
> +       if (desc->type == POWER_SUPPLY_TYPE_BATTERY) {
> +               rc = power_supply_get_battery_info(psy, &psy->battery_info);
> +               if (rc && rc != -ENODEV && rc != -ENOENT)
> +                       goto check_supplies_failed;
> +       }
> 
> interacting with
> 
>  (b) the test_power_init() that does that
> 
>                 test_power_supplies[i] = power_supply_register(NULL,
>                                                 &test_power_desc[i],
>                                                 &test_power_configs[i]);
> 
> which passes in NULL for the "parent" pointer.
> 
> So it looks like a dodgy test that was a bit lazy. But maybe a NULL
> parent is supposed to work.
> 
>                 Linus

I have a fix for that in my fixes branch, that I planned to send
this week:

https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/commit/?h=fixes&id=44c524b642996148a8e94f1a1b8751076edcf577

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: [BUG 6.4-rc3] BUG: kernel NULL pointer dereference in __dev_fwnode
  2023-05-25 16:42 82%   ` Sebastian Reichel
@ 2023-05-26  2:08 82%     ` Steven Rostedt
  0 siblings, 0 replies; 200+ results
From: Steven Rostedt @ 2023-05-26  2:08 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Linus Torvalds, LKML, Masami Hiramatsu, Linus Walleij,
	Matti Vaittinen, linux-pm

On Thu, 25 May 2023 18:42:48 +0200
Sebastian Reichel <sre@kernel.org> wrote:

> I have a fix for that in my fixes branch, that I planned to send
> this week:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/commit/?h=fixes&id=44c524b642996148a8e94f1a1b8751076edcf577

This appears to fix the bug I reported.

Tested-by: Steven Rostedt (Google) <rostedt@goodmis.org>

-- Steve

^ permalink raw reply	[relevance 82%]

* Re: Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
  @ 2023-05-30 11:22 82%                   ` Salvatore Bonaccorso
  0 siblings, 0 replies; 200+ results
From: Salvatore Bonaccorso @ 2023-05-30 11:22 UTC (permalink / raw)
  To: Nick Hastings, 1036530
  Cc: Mario Limonciello, Rafael J. Wysocki, Len Brown, linux-acpi,
	linux-kernel, regressions

Hi Nick,

Thanks to you both for triaging the issue!

On Tue, May 30, 2023 at 04:01:04PM +0900, Nick Hastings wrote:
> Hi,
> 
> * Mario Limonciello <mario.limonciello@amd.com> [230530 13:00]:
> > On 5/29/23 18:01, Nick Hastings wrote:
> > > Hi,
> > > 
> > > * Nick Hastings <nicholaschastings@gmail.com> [230529 12:51]:
> > > > * Mario Limonciello <mario.limonciello@amd.com> [230529 10:14]:
> > > > > On 5/28/23 19:56, Nick Hastings wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > * Mario Limonciello <mario.limonciello@amd.com> [230528 21:44]:
> > > > > > > On 5/28/23 01:49, Salvatore Bonaccorso wrote:
> > > > > > > > Hi Mario
> > > > > > > > 
> > > > > > > > Nick Hastings reported in Debian in https://bugs.debian.org/1036530
> > > > > > > > lockups from his system after updating from a 6.0 based version to
> > > > > > > > 6.1.y. >
> > > > > > > > #regzbot ^introduced 24867516f06d
> > > > > > > > 
> > > > > > > > he bisected the issue and tracked it down to:
> > > > > > > > 
> > > > > > > > On Sun, May 28, 2023 at 10:14:51AM +0900, Nick Hastings wrote:
> > > > > > > > > Control: tags -1 - moreinfo
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > I repeated the git bisect, and the bad commit seems to be:
> > > > > > > > > 
> > > > > > > > > (git)-[v6.1-rc1~206^2~4^5~3|bisect] % git bisect bad
> > > > > > > > > 24867516f06dabedef3be7eea0ef0846b91538bc is the first bad commit
> > > > > > > > > commit 24867516f06dabedef3be7eea0ef0846b91538bc
> > > > > > > > > Author: Mario Limonciello <mario.limonciello@amd.com>
> > > > > > > > > Date:   Tue Aug 23 13:51:31 2022 -0500
> > > > > > > > > 
> > > > > > > > >        ACPI: OSI: Remove Linux-Dell-Video _OSI string
> > > > > > > > >        This string was introduced because drivers for NVIDIA hardware
> > > > > > > > >        had bugs supporting RTD3 in the past.
> > > > > > > > >        Before proprietary NVIDIA driver started to support RTD3, Ubuntu had
> > > > > > > > >        had a mechanism for switching PRIME on and off, though it had required
> > > > > > > > >        to logout/login to make the library switch happen.
> > > > > > > > >        When the PRIME had been off, the mechanism had unloaded the NVIDIA
> > > > > > > > >        driver and put the device into D3cold, but the GPU had never come back
> > > > > > > > >        to D0 again which is why ODMs used the _OSI to expose an old _DSM
> > > > > > > > >        method to switch the power on/off.
> > > > > > > > >        That has been fixed by commit 5775b843a619 ("PCI: Restore config space
> > > > > > > > >        on runtime resume despite being unbound"). so vendors shouldn't be
> > > > > > > > >        using this string to modify ASL any more.
> > > > > > > > >        Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > > > >        Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> > > > > > > > >        Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > > > > > > 
> > > > > > > > >     drivers/acpi/osi.c | 9 ---------
> > > > > > > > >     1 file changed, 9 deletions(-)
> > > > > > > > > 
> > > > > > > > > This machine is a Dell with an nvidia chip so it looks like this really
> > > > > > > > > could be the commit that that is causing the problems. The description
> > > > > > > > > of the commit also seems (to my untrained eye) to be consistent with the
> > > > > > > > > error reported on the console when the lockup occurs:
> > > > > > > > > 
> > > > > > > > > [   58.729863] ACPI Error: Aborting method \_SB.PCI0.PGON due to previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
> > > > > > > > > [   58.729904] ACPI Error: Aborting method \_SB.PCI0.PEG0.PG00._ON due to previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
> > > > > > > > > [   60.083261] vfio-pci 0000:01:00.0 Unable to change power state from D3cold to D0, device inaccessible
> > > > > > > > > 
> > > > > > > > > Hopefully this is enough information for experts to resolve this.
> > > > > > > > 
> > > > > > > > Does this ring some bell for you? Do you need any further information
> > > > > > > > from Nick?
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Salvatore
> > > > > > > 
> > > > > > 
> > > > > > > Have Nick try using "pcie_port_pm=off" and see if it helps the issue.
> > > > > > 
> > > > > > I booted into a 6.1 kernel with this option. It has been running without
> > > > > > problems for 1.5 hours. Usually I would expect the lockup to have
> > > > > > occurred by now.
> > > > 
> > > > I let this run for 3 hours without issue.
> > > > 
> > > > > > > Does this happen in the latest 6.4 RC as well?
> > > > > > 
> > > > > > I have compiled that kernel and will boot into it after running this one
> > > > > > with the pcie_port_pm=off for another hour or so.
> > > > 
> > > > I'm now running 6.4.0-rc4 without seeing the problem after 1 hour.
> > > 
> > > I did eventually see a lockup of this kernel. On the console I saw:
> > > 
> > > [  151.035036] vfio-pci 0000:01:00.0 Unable to change power state from D3cold to D0, device inaccessible
> > > 
> > > I did not see the other two lines that were present in earlier lock ups >
> > > > I did however see two unrelated problems that I include here for
> > > > completeness:
> > > > 1. iwlwifi module did not automatically load
> > > > 2. Xwayland used huge amount of CPU even though was not running any X
> > > > programs. Recompiling my wayland compositor without XWayland support
> > > > "fixed" this.
> > > > 
> > > > > > > I think we need to see a full dmesg and acpidump to better
> > > > > > > characterize it.
> > > > > > 
> > > > > > Please find attached. Let me know if there is anything else I can provide.
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > Nick.
> > > > > 
> > > > > I don't see nouveau loading, are you explicitly preventing it from
> > > > > loading?
> > > > 
> > > > Yes nouveau is blacklisted.
> > > > 
> > > > > Can I see the journal from a boot when it reproduced?
> > > > 
> > > > Hmm not sure which n for "journalctl -b n" maps to which kernel (is that
> > > > what you are requesting?). The commit hash doesn't not seem to be
> > > > listed. I may have to boot into a bad kernel again.
> > > 
> > > Please find attached the output from a "journalctl --system -bN" for a
> > > kernel that has this issue.
> > > 
> > > Regards,
> > > 
> > > Nick.
> > 
> > In this log I see nouveau loaded, but I also don't see the failure
> > occurring.
> 
> I never saw anything in the logs from a lockup either. I had assumed it
> was no longer able to write to disk. The failure did occur on that
> occasion.

Can you try if you would get more out of it using netconsole?

https://www.kernel.org/doc/html/latest/networking/netconsole.html

Regards,
Salvatore

^ permalink raw reply	[relevance 82%]

* Re: [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in __bpf_prog_put()
  @ 2023-06-12  0:01 82%                 ` Yonghong Song
  0 siblings, 0 replies; 200+ results
From: Yonghong Song @ 2023-06-12  0:01 UTC (permalink / raw)
  To: Teng Qi
  Cc: ast, daniel, john.fastabend, andrii, martin.lau, song, yhs,
	kpsingh, sdf, haoluo, jolsa, davem, kuba, hawk, bpf, linux-kernel,
	netdev



On 6/11/23 6:02 AM, Teng Qi wrote:
> Hello!
>> BTW, please do create a test case, e.g, sockmap test case which
>> can show the problem with existing code base.
> 
> I add a printk in bpf_prog_put_deferred():
> static void bpf_prog_put_deferred(struct work_struct *work)
> {
>          // . . .
>          int inIrq = in_irq();
>          int irqsDisabled = irqs_disabled();
>          int preemptBits = preempt_count();
>          int inAtomic = in_atomic();
>          int rcuHeld = rcu_read_lock_held();
>          printk("bpf_prog_put: in_irq() %d, irqs_disabled() %d, preempt_count()
>           %d, in_atomic() %d, rcu_read_lock_held() %d",
>          inIrq, irqsDisabled, preemptBits, inAtomic, rcuHeld);
>          // . . .
> }
> 
> When running the selftest, I see the following output:
> [255340.388339] bpf_prog_put: in_irq() 0, irqs_disabled() 0,
>          preempt_count() 256, in_atomic() 1, rcu_read_lock_held() 1
> [255393.237632] bpf_prog_put: in_irq() 0, irqs_disabled() 0,
>          preempt_count() 0, in_atomic() 0, rcu_read_lock_held() 1

It would be great if you also print out in_interrupt() value, so we know
whether softirq or nmi is enabled or not.

We cannot really WARN with !rcu_read_lock_held() since the 
__bpf_prog_put funciton is called in different contexts.

Also, note that rcu_read_lock_held() may not be reliable. rcu subsystem
will return 1 if not tracked or not sure about the result.

> 
> Based on this output, I believe it is sufficient to construct a self-test case
> for bpf_prog_put_deferred() called under preempt disabled or rcu read lock
> region. However, I'm a bit confused about what I should do to build the
> self-test case. Are we looking to create a checker that verifies the
> context of bpf_prog_put_deferred() is valid? Or do we need a test case that
> can trigger this bug?
> 
> Could you show me more ideas to construct a self test case? I am not familiar
> with it and have no idea.

Okay, I see. It seems hard to create a test case with warnings since
bpf_prog_put_deferred is called in different context. So some
examples for possible issues (through code analysis) should be good enough.

> 
> -- Teng Qi
> 
> On Thu, May 25, 2023 at 3:34 AM Yonghong Song <yhs@meta.com> wrote:
>>
>>
>>
>> On 5/24/23 5:42 AM, Teng Qi wrote:
>>> Thank you.
>>>
>>>> We cannot use rcu_read_lock_held() in the 'if' statement. The return
>>>> value rcu_read_lock_held() could be 1 for some configurations regardless
>>>> whether rcu_read_lock() is really held or not. In most cases,
>>>> rcu_read_lock_held() is used in issuing potential warnings.
>>>> Maybe there are other ways to record whether rcu_read_lock() is held or not?
>>>
>>> Sorry. I was not aware of the dependency of configurations of
>>> rcu_read_lock_held().
>>>
>>>> If we cannot resolve rcu_read_lock() presence issue, maybe the condition
>>>> can be !in_interrupt(), so any process-context will go to a workqueue.
>>>
>>> I agree that using !in_interrupt() as a condition is an acceptable solution.
>>
>> This should work although it could be conservative.
>>
>>>
>>>> Alternatively, we could have another solution. We could add another
>>>> function e.g., bpf_prog_put_rcu(), which indicates that bpf_prog_put()
>>>> will be done in rcu context.
>>>
>>> Implementing a new function like bpf_prog_put_rcu() is a solution that involves
>>> more significant changes.
>>
>> Maybe we can change signature of bpf_prog_put instead? Like
>>      void bpf_prog_put(struct bpf_prog *prog, bool in_rcu)
>> and inside bpf_prog_put we can add
>>      WARN_ON_ONCE(in_rcu && !bpf_rcu_lock_held());
>>
>>>
>>>> So if in_interrupt(), do kvfree, otherwise,
>>>> put into a workqueue.
>>>
>>> Shall we proceed with submitting a patch following this approach?
>>
>> You could choose either of the above although I think with newer
>> bpf_prog_put() is better.
>>
>> BTW, please do create a test case, e.g, sockmap test case which
>> can show the problem with existing code base.
>>
>>>
>>> I would like to mention something unrelated to the possible bug. At this
>>> moment, things seem to be more puzzling. vfree() is safe under in_interrupt()
>>> but not safe under other atomic contexts.
>>> This disorder challenges our conventional belief, a monotonic incrementation
>>> of limitations of the hierarchical atomic contexts, that programer needs
>>> to be more and more careful to write code under rcu read lock, spin lock,
>>> bh disable, interrupt...
>>> This disorder can lead to unexpected consequences, such as code being safe
>>> under interrupts but not safe under spin locks.
>>> The disorder makes kernel programming more complex and may result in more bugs.
>>> Even though we find a way to resolve the possible bug about the bpf_prog_put(),
>>> I feel sad for undermining of kernel`s maintainability and disorder of
>>> hierarchy of atomic contexts.
>>>
>>> -- Teng Qi
>>>
>>> On Tue, May 23, 2023 at 12:33 PM Yonghong Song <yhs@meta.com> wrote:
>>>>
>>>>
>>>>
>>>> On 5/21/23 6:39 AM, Teng Qi wrote:
>>>>> Thank you.
>>>>>
>>>>>    > Your above analysis makes sense if indeed that kvfree cannot appear
>>>>>    > inside a spin lock region or RCU read lock region. But is it true?
>>>>>    > I checked a few code paths in kvfree/kfree. It is either guarded
>>>>>    > with local_irq_save/restore or by
>>>>>    > spin_lock_irqsave/spin_unlock_
>>>>>    > irqrestore, etc. Did I miss
>>>>>    > anything? Are you talking about RT kernel here?
>>>>>
>>>>> To see the sleepable possibility of kvfree, it is important to analyze the
>>>>> following calling stack:
>>>>> mm/util.c: 645 kvfree()
>>>>> mm/vmalloc.c: 2763 vfree()
>>>>>
>>>>> In kvfree(), to call vfree, if the pointer addr points to memory
>>>>> allocated by
>>>>> vmalloc(), it calls vfree().
>>>>> void kvfree(const void *addr)
>>>>> {
>>>>>            if (is_vmalloc_addr(addr))
>>>>>                    vfree(addr);
>>>>>            else
>>>>>                    kfree(addr);
>>>>> }
>>>>>
>>>>> In vfree(), in_interrupt() and might_sleep() need to be considered.
>>>>> void vfree(const void *addr)
>>>>> {
>>>>>            // ...
>>>>>            if (unlikely(in_interrupt()))
>>>>>            {
>>>>>                    vfree_atomic(addr);
>>>>>                    return;
>>>>>            }
>>>>>            // ...
>>>>>            might_sleep();
>>>>>            // ...
>>>>> }
>>>>
>>>> Sorry. I didn't check vfree path. So it does look like that
>>>> we need to pay special attention to non interrupt part.
>>>>
>>>>>
>>>>> The vfree() may sleep if in_interrupt() == false. The RCU read lock region
>>>>> could have in_interrupt() == false and spin lock region which only disables
>>>>> preemption also has in_interrupt() == false. So the kvfree() cannot appear
>>>>> inside a spin lock region or RCU read lock region if the pointer addr points
>>>>> to memory allocated by vmalloc().
>>>>>
>>>>>    > > Therefore, we propose modifying the condition to include
>>>>>    > > in_atomic(). Could we
>>>>>    > > update the condition as follows: "in_irq() || irqs_disabled() ||
>>>>>    > > in_atomic()"?
>>>>>    > Thank you! We look forward to your feedback.
>>>>>
>>>>> We now think that ‘irqs_disabled() || in_atomic() ||
>>>>> rcu_read_lock_held()’ is
>>>>> more proper. irqs_disabled() is for irq flag reg, in_atomic() is for
>>>>> preempt count and rcu_read_lock_held() is for RCU read lock region.
>>>>
>>>> We cannot use rcu_read_lock_held() in the 'if' statement. The return
>>>> value rcu_read_lock_held() could be 1 for some configuraitons regardless
>>>> whether rcu_read_lock() is really held or not. In most cases,
>>>> rcu_read_lock_held() is used in issuing potential warnings.
>>>> Maybe there are other ways to record whether rcu_read_lock() is held or not?
>>>>
>>>> I agree with your that 'irqs_disabled() || in_atomic()' makes sense
>>>> since it covers process context local_irq_save() and spin_lock() cases.
>>>>
>>>> If we cannot resolve rcu_read_lock() presence issue, maybe the condition
>>>> can be !in_interrupt(), so any process-context will go to a workqueue.
>>>>
>>>> Alternatively, we could have another solution. We could add another
>>>> function e.g., bpf_prog_put_rcu(), which indicates that bpf_prog_put()
>>>> will be done in rcu context. So if in_interrupt(), do kvfree, otherwise,
>>>> put into a workqueue.
>>>>
>>>>
>>>>>
>>>>> -- Teng Qi
>>>>>
>>>>> On Sun, May 21, 2023 at 11:45 AM Yonghong Song <yhs@meta.com
>>>>> <mailto:yhs@meta.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>       On 5/19/23 7:18 AM, Teng Qi wrote:
>>>>>        > Thank you for your response.
>>>>>        >  > Looks like you only have suspicion here. Could you find a real
>>>>>       violation
>>>>>        >  > here where __bpf_prog_put() is called with !in_irq() &&
>>>>>        >  > !irqs_disabled(), but inside spin_lock or rcu read lock? I
>>>>>       have not seen
>>>>>        >  > things like that.
>>>>>        >
>>>>>        > For the complex conditions to call bpf_prog_put() with 1 refcnt,
>>>>>       we have
>>>>>        > been
>>>>>        > unable to really trigger this atomic violation after trying to
>>>>>       construct
>>>>>        > test cases manually. But we found that it is possible to show
>>>>>       cases with
>>>>>        > !in_irq() && !irqs_disabled(), but inside spin_lock or rcu read lock.
>>>>>        > For example, even a failed case, one of selftest cases of bpf,
>>>>>       netns_cookie,
>>>>>        > calls bpf_sock_map_update() and may indirectly call bpf_prog_put()
>>>>>        > only inside rcu read lock: The possible call stack is:
>>>>>        > net/core/sock_map.c: 615 bpf_sock_map_update()
>>>>>        > net/core/sock_map.c: 468 sock_map_update_common()
>>>>>        > net/core/sock_map.c:  217 sock_map_link()
>>>>>        > kernel/bpf/syscall.c: 2111 bpf_prog_put()
>>>>>        >
>>>>>        > The files about netns_cookie include
>>>>>        > tools/testing/selftests/bpf/progs/netns_cookie_prog.c and
>>>>>        > tools/testing/selftests/bpf/prog_tests/netns_cookie.c. We
>>>>>       inserted the
>>>>>        > following code in
>>>>>        > ‘net/core/sock_map.c: 468 sock_map_update_common()’:
>>>>>        > static int sock_map_update_common(..)
>>>>>        > {
>>>>>        >          int inIrq = in_irq();
>>>>>        >          int irqsDisabled = irqs_disabled();
>>>>>        >          int preemptBits = preempt_count();
>>>>>        >          int inAtomic = in_atomic();
>>>>>        >          int rcuHeld = rcu_read_lock_held();
>>>>>        >          printk("in_irq() %d, irqs_disabled() %d, preempt_count() %d,
>>>>>        >            in_atomic() %d, rcu_read_lock_held() %d", inIrq,
>>>>>       irqsDisabled,
>>>>>        >            preemptBits, inAtomic, rcuHeld);
>>>>>        > }
>>>>>        >
>>>>>        > The output message is as follows:
>>>>>        > root@(none):/root/bpf# ./test_progs -t netns_cookie
>>>>>        > [  137.639188] in_irq() 0, irqs_disabled() 0, preempt_count() 0,
>>>>>        > in_atomic() 0,
>>>>>        >          rcu_read_lock_held() 1
>>>>>        > #113     netns_cookie:OK
>>>>>        > Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>>>>>        >
>>>>>        > We notice that there are numerous callers in kernel/, net/ and
>>>>>       drivers/,
>>>>>        > so we
>>>>>        > highly suggest modifying __bpf_prog_put() to address this gap.
>>>>>       The gap
>>>>>        > exists
>>>>>        > because __bpf_prog_put() is only safe under in_irq() ||
>>>>>       irqs_disabled()
>>>>>        > but not in_atomic() || rcu_read_lock_held(). The following code
>>>>>       snippet may
>>>>>        > mislead developers into thinking that bpf_prog_put() is safe in all
>>>>>        > contexts.
>>>>>        > if (in_irq() || irqs_disabled()) {
>>>>>        >          INIT_WORK(&aux->work, bpf_prog_put_deferred);
>>>>>        >          schedule_work(&aux->work);
>>>>>        > } else {
>>>>>        >          bpf_prog_put_deferred(&aux->work);
>>>>>        > }
>>>>>        >
>>>>>        > Implicit dependency may lead to issues.
>>>>>        >
>>>>>        >  > Any problem here?
>>>>>        > We mentioned it to demonstrate the possibility of kvfree() being
>>>>>        > called by __bpf_prog_put_noref().
>>>>>        >
>>>>>        > Thanks.
>>>>>        > -- Teng Qi
>>>>>        >
>>>>>        > On Wed, May 17, 2023 at 1:08 AM Yonghong Song <yhs@meta.com
>>>>>       <mailto:yhs@meta.com>
>>>>>        > <mailto:yhs@meta.com <mailto:yhs@meta.com>>> wrote:
>>>>>        >
>>>>>        >
>>>>>        >
>>>>>        >     On 5/16/23 4:18 AM, starmiku1207184332@gmail.com
>>>>>       <mailto:starmiku1207184332@gmail.com>
>>>>>        >     <mailto:starmiku1207184332@gmail.com
>>>>>       <mailto:starmiku1207184332@gmail.com>> wrote:
>>>>>        >      > From: Teng Qi <starmiku1207184332@gmail.com
>>>>>       <mailto:starmiku1207184332@gmail.com>
>>>>>        >     <mailto:starmiku1207184332@gmail.com
>>>>>       <mailto:starmiku1207184332@gmail.com>>>
>>>>>        >      >
>>>>>        >      > Hi, bpf developers,
>>>>>        >      >
>>>>>        >      > We are developing a static tool to check the matching between
>>>>>        >     helpers and the
>>>>>        >      > context of hooks. During our analysis, we have discovered some
>>>>>        >     important
>>>>>        >      > findings that we would like to report.
>>>>>        >      >
>>>>>        >      > ‘kernel/bpf/syscall.c: 2097 __bpf_prog_put()’ shows that
>>>>>       function
>>>>>        >      > bpf_prog_put_deferred() won`t be called in the condition of
>>>>>        >      > ‘in_irq() || irqs_disabled()’.
>>>>>        >      > if (in_irq() || irqs_disabled()) {
>>>>>        >      >      INIT_WORK(&aux->work, bpf_prog_put_deferred);
>>>>>        >      >      schedule_work(&aux->work);
>>>>>        >      > } else {
>>>>>        >      >
>>>>>        >      >      bpf_prog_put_deferred(&aux->work);
>>>>>        >      > }
>>>>>        >      >
>>>>>        >      > We suspect this condition exists because there might be
>>>>>       sleepable
>>>>>        >     operations
>>>>>        >      > in the callees of the bpf_prog_put_deferred() function:
>>>>>        >      > kernel/bpf/syscall.c: 2097 __bpf_prog_put()
>>>>>        >      > kernel/bpf/syscall.c: 2084 bpf_prog_put_deferred()
>>>>>        >      > kernel/bpf/syscall.c: 2063 __bpf_prog_put_noref()
>>>>>        >      > kvfree(prog->aux->jited_linfo);
>>>>>        >      > kvfree(prog->aux->linfo);
>>>>>        >
>>>>>        >     Looks like you only have suspicion here. Could you find a real
>>>>>        >     violation
>>>>>        >     here where __bpf_prog_put() is called with !in_irq() &&
>>>>>        >     !irqs_disabled(), but inside spin_lock or rcu read lock? I
>>>>>       have not seen
>>>>>        >     things like that.
>>>>>        >
>>>>>        >      >
>>>>>        >      > Additionally, we found that array prog->aux->jited_linfo is
>>>>>        >     initialized in
>>>>>        >      > ‘kernel/bpf/core.c: 157 bpf_prog_alloc_jited_linfo()’:
>>>>>        >      > prog->aux->jited_linfo = kvcalloc(prog->aux->nr_linfo,
>>>>>        >      >    sizeof(*prog->aux->jited_linfo),
>>>>>       bpf_memcg_flags(GFP_KERNEL |
>>>>>        >     __GFP_NOWARN));
>>>>>        >
>>>>>        >     Any problem here?
>>>>>        >
>>>>>        >      >
>>>>>        >      > Our question is whether the condition 'in_irq() ||
>>>>>        >     irqs_disabled() == false' is
>>>>>        >      > sufficient for calling 'kvfree'. We are aware that calling
>>>>>        >     'kvfree' within the
>>>>>        >      > context of a spin lock or an RCU lock is unsafe.
>>>>>
>>>>>       Your above analysis makes sense if indeed that kvfree cannot appear
>>>>>       inside a spin lock region or RCU read lock region. But is it true?
>>>>>       I checked a few code paths in kvfree/kfree. It is either guarded
>>>>>       with local_irq_save/restore or by
>>>>>       spin_lock_irqsave/spin_unlock_irqrestore, etc. Did I miss
>>>>>       anything? Are you talking about RT kernel here?
>>>>>
>>>>>
>>>>>        >      >
>>>>>        >      > Therefore, we propose modifying the condition to include
>>>>>        >     in_atomic(). Could we
>>>>>        >      > update the condition as follows: "in_irq() ||
>>>>>       irqs_disabled() ||
>>>>>        >     in_atomic()"?
>>>>>        >      >
>>>>>        >      > Thank you! We look forward to your feedback.
>>>>>        >      >
>>>>>        >      > Signed-off-by: Teng Qi <starmiku1207184332@gmail.com
>>>>>       <mailto:starmiku1207184332@gmail.com>
>>>>>        >     <mailto:starmiku1207184332@gmail.com
>>>>>       <mailto:starmiku1207184332@gmail.com>>>
>>>>>        >
>>>>>

^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] "kernel BUG at mm/swap.c:393!" on commit b9c91c43412f2e
  @ 2023-06-21  7:03 82%   ` Hyeonggon Yoo
    1 sibling, 0 replies; 200+ results
From: Hyeonggon Yoo @ 2023-06-21  7:03 UTC (permalink / raw)
  To: Yosry Ahmed
  Cc: Andrew Morton, Konrad Rzeszutek Wilk, Seth Jennings,
	Dan Streetman, Vitaly Wool, Johannes Weiner, Nhat Pham,
	Domenico Cerasuolo, Yu Zhao, linux-mm, linux-kernel

On Wed, Jun 21, 2023 at 4:01 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
>
> On Wed, Jun 07, 2023 at 07:51:43PM +0000, Yosry Ahmed wrote:
> > Commit 71024cb4a0bf ("frontswap: remove frontswap_tmem_exclusive_gets")
> > removed support for exclusive loads from frontswap as it was not used.
> > Bring back exclusive loads support to frontswap by adding an "exclusive"
> > output parameter to frontswap_ops->load.
> >
> > On the zswap side, add a module parameter to enable/disable exclusive
> > loads, and a config option to control the boot default value.
> > Refactor zswap entry invalidation in zswap_frontswap_invalidate_page()
> > into zswap_invalidate_entry() to reuse it in zswap_frontswap_load() if
> > exclusive loads are enabled.
> >
> > With exclusive loads, we avoid having two copies of the same page in
> > memory (compressed & uncompressed) after faulting it in from zswap. On
> > the other hand, if the page is to be reclaimed again without being
> > dirtied, it will be re-compressed. Compression is not usually slow, and
> > a page that was just faulted in is less likely to be reclaimed again
> > soon.
> >
> > Suggested-by: Yu Zhao <yuzhao@google.com>
> > Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> > ---
> >
> > v1 -> v2:
> > - Add a module parameter to control whether exclusive loads are enabled
> >   or not, the config option now controls the default boot value instead.
> >   Replaced frontswap_ops->exclusive_loads by an output parameter to
> >   frontswap_ops->load() (Johannes Weiner).
> > ---
>
> Hi Yosry, I was testing the latest mm-unstable and encountered a bug.
> It was bisectable and this is the first bad commit.

Oh, I forgot to mention how I was able to reproduce this:

$ stress-ng --bigheap 12
(my box have 24 cores)

>
> Attached config file and bisect log.
> The oops message is available at:
>
> https://social.kernel.org/media/eace06d71655b3cc76411366573e4a8ce240ad65b8fd20977d7c73eec9dc2253.jpg
>
> (the head commit is b9c91c43412f2e07 "mm: zswap: support exclusive loads")
> (it's an image because I tested it on real machine)
>
>
> This is what I have as swap space:
>
> $ cat /proc/swaps
> Filename                                Type            Size            Used            Priority
> /var/swap                               file            134217724       0               -2
> /dev/zram0                              partition       8388604         0               100

^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] "kernel BUG at mm/swap.c:393!" on commit b9c91c43412f2e
    2023-06-21  9:18 82%     ` Domenico Cerasuolo
@ 2023-06-21  9:06 82%     ` Hyeonggon Yoo
  2023-06-21  9:09 82%       ` Yosry Ahmed
  1 sibling, 1 reply; 200+ results
From: Hyeonggon Yoo @ 2023-06-21  9:06 UTC (permalink / raw)
  To: Yosry Ahmed
  Cc: Andrew Morton, Konrad Rzeszutek Wilk, Seth Jennings,
	Dan Streetman, Vitaly Wool, Johannes Weiner, Nhat Pham,
	Domenico Cerasuolo, Yu Zhao, linux-mm, linux-kernel

On Wed, Jun 21, 2023 at 01:05:56AM -0700, Yosry Ahmed wrote:
> On Wed, Jun 21, 2023 at 12:01 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> > Hi Yosry, I was testing the latest mm-unstable and encountered a bug.
> > It was bisectable and this is the first bad commit.
> >
> >
> > Attached config file and bisect log.
> > The oops message is available at:
> >
> > https://social.kernel.org/media/eace06d71655b3cc76411366573e4a8ce240ad65b8fd20977d7c73eec9dc2253.jpg
> >
> > (the head commit is b9c91c43412f2e07 "mm: zswap: support exclusive loads")
> > (it's an image because I tested it on real machine)
> >
> >
> > This is what I have as swap space:
> >
> > $ cat /proc/swaps
> > Filename                                Type            Size            Used            Priority
> > /var/swap                               file            134217724       0               -2
> > /dev/zram0                              partition       8388604         0               100
> 
> 
> Hi Hyeonggon,
> 
> Thanks for reporting this! I think I know what went wrong. Could you
> please verify if the below fix works if possible?
>

Works fine and I was not able to reproduce the bug with the patch
applied.

Not sure Andrew would prefer squashing it into original one or applying it
as separate patch, though (I'm totally fine with both way).

Anyway:

Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>

> Domenico, I believe the below fix would also fix a problem with the
> recent writeback series. If the entry is invalidated before we grab the
> lock to put the local ref in zswap_frontswap_load(), then the entry
> will be freed once we call zswap_entry_put(), and the movement to the
> beginning LRU will be operating on a freed entry. It also modifies
> your recently added commit 418fd29d9de5 ("mm: zswap: invaldiate entry
> after writeback"). I would appreciate it if you also take a look.
> 
> If this works as intended, I can send a formal patch (applies on top
> of fd247f029cd0 ("mm/gup: do not return 0 from pin_user_pages_fast()
> for bad args")):
> 
> From 4b7f949b3ffb42d969d525d5b576fad474f55276 Mon Sep 17 00:00:00 2001
> From: Yosry Ahmed <yosryahmed@google.com>
> Date: Wed, 21 Jun 2023 07:43:51 +0000
> Subject: [PATCH] mm: zswap: fix double invalidate with exclusive loads
> 
> If exclusive loads are enabled for zswap, we invalidate the entry before
> returning from zswap_frontswap_load(), after dropping the local
> reference. However, the tree lock is dropped during decompression after
> the local reference is acquired, so the entry could be invalidated
> before we drop the local ref. If this happens, the entry is freed once
> we drop the local ref, and zswap_invalidate_entry() tries to invalidate
> an already freed entry.
> 
> Fix this by:
> (a) Making sure zswap_invalidate_entry() is always called with a local
>     ref held, to avoid being called on a freed entry.
> (b) Making sure zswap_invalidate_entry() only drops the ref if the entry
>     was actually on the rbtree. Otherwise, another invalidation could
>     have already happened, and the initial ref is already dropped.
> 
> With these changes, there is no need to check that there is no need to
> make sure the entry still exists in the tree in zswap_reclaim_entry()
> before invalidating it, as zswap_reclaim_entry() will make this check
> internally.
> 
> Fixes: b9c91c43412f ("mm: zswap: support exclusive loads")
> Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
> Signed-off-by: Yosry Ahmed <yosryahmed@google.com>

<...snip...>

-- 
Hyeonggon Yoo

Undergraduate | Chungnam National University

^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] "kernel BUG at mm/swap.c:393!" on commit b9c91c43412f2e
  2023-06-21  9:06 82%     ` Hyeonggon Yoo
@ 2023-06-21  9:09 82%       ` Yosry Ahmed
  0 siblings, 0 replies; 200+ results
From: Yosry Ahmed @ 2023-06-21  9:09 UTC (permalink / raw)
  To: Hyeonggon Yoo
  Cc: Andrew Morton, Konrad Rzeszutek Wilk, Seth Jennings,
	Dan Streetman, Vitaly Wool, Johannes Weiner, Nhat Pham,
	Domenico Cerasuolo, Yu Zhao, linux-mm, linux-kernel

On Wed, Jun 21, 2023 at 2:06 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
>
> On Wed, Jun 21, 2023 at 01:05:56AM -0700, Yosry Ahmed wrote:
> > On Wed, Jun 21, 2023 at 12:01 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> > > Hi Yosry, I was testing the latest mm-unstable and encountered a bug.
> > > It was bisectable and this is the first bad commit.
> > >
> > >
> > > Attached config file and bisect log.
> > > The oops message is available at:
> > >
> > > https://social.kernel.org/media/eace06d71655b3cc76411366573e4a8ce240ad65b8fd20977d7c73eec9dc2253.jpg
> > >
> > > (the head commit is b9c91c43412f2e07 "mm: zswap: support exclusive loads")
> > > (it's an image because I tested it on real machine)
> > >
> > >
> > > This is what I have as swap space:
> > >
> > > $ cat /proc/swaps
> > > Filename                                Type            Size            Used            Priority
> > > /var/swap                               file            134217724       0               -2
> > > /dev/zram0                              partition       8388604         0               100
> >
> >
> > Hi Hyeonggon,
> >
> > Thanks for reporting this! I think I know what went wrong. Could you
> > please verify if the below fix works if possible?
> >
>
> Works fine and I was not able to reproduce the bug with the patch
> applied.
>
> Not sure Andrew would prefer squashing it into original one or applying it
> as separate patch, though (I'm totally fine with both way).

I think it already landed in mm-stable so it cannot be squashed at this point.

>
> Anyway:
>
> Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>

Thanks a lot for reporting and testing this!

I will wait for Domenico to also respond then send the fix to Andrew.
Hopefully it's not too late for this rc.

>
> > Domenico, I believe the below fix would also fix a problem with the
> > recent writeback series. If the entry is invalidated before we grab the
> > lock to put the local ref in zswap_frontswap_load(), then the entry
> > will be freed once we call zswap_entry_put(), and the movement to the
> > beginning LRU will be operating on a freed entry. It also modifies
> > your recently added commit 418fd29d9de5 ("mm: zswap: invaldiate entry
> > after writeback"). I would appreciate it if you also take a look.
> >
> > If this works as intended, I can send a formal patch (applies on top
> > of fd247f029cd0 ("mm/gup: do not return 0 from pin_user_pages_fast()
> > for bad args")):
> >
> > From 4b7f949b3ffb42d969d525d5b576fad474f55276 Mon Sep 17 00:00:00 2001
> > From: Yosry Ahmed <yosryahmed@google.com>
> > Date: Wed, 21 Jun 2023 07:43:51 +0000
> > Subject: [PATCH] mm: zswap: fix double invalidate with exclusive loads
> >
> > If exclusive loads are enabled for zswap, we invalidate the entry before
> > returning from zswap_frontswap_load(), after dropping the local
> > reference. However, the tree lock is dropped during decompression after
> > the local reference is acquired, so the entry could be invalidated
> > before we drop the local ref. If this happens, the entry is freed once
> > we drop the local ref, and zswap_invalidate_entry() tries to invalidate
> > an already freed entry.
> >
> > Fix this by:
> > (a) Making sure zswap_invalidate_entry() is always called with a local
> >     ref held, to avoid being called on a freed entry.
> > (b) Making sure zswap_invalidate_entry() only drops the ref if the entry
> >     was actually on the rbtree. Otherwise, another invalidation could
> >     have already happened, and the initial ref is already dropped.
> >
> > With these changes, there is no need to check that there is no need to
> > make sure the entry still exists in the tree in zswap_reclaim_entry()
> > before invalidating it, as zswap_reclaim_entry() will make this check
> > internally.
> >
> > Fixes: b9c91c43412f ("mm: zswap: support exclusive loads")
> > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
> > Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
>
> <...snip...>
>
> --
> Hyeonggon Yoo
>
> Undergraduate | Chungnam National University

^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] "kernel BUG at mm/swap.c:393!" on commit b9c91c43412f2e
  @ 2023-06-21  9:18 82%     ` Domenico Cerasuolo
  2023-06-21  9:26 82%       ` Yosry Ahmed
  2023-06-21  9:06 82%     ` Hyeonggon Yoo
  1 sibling, 1 reply; 200+ results
From: Domenico Cerasuolo @ 2023-06-21  9:18 UTC (permalink / raw)
  To: Yosry Ahmed
  Cc: Hyeonggon Yoo, Andrew Morton, Konrad Rzeszutek Wilk,
	Seth Jennings, Dan Streetman, Vitaly Wool, Johannes Weiner,
	Nhat Pham, Yu Zhao, linux-mm, linux-kernel

On Wed, Jun 21, 2023 at 10:06 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Wed, Jun 21, 2023 at 12:01 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> >
> > On Wed, Jun 07, 2023 at 07:51:43PM +0000, Yosry Ahmed wrote:
> > > Commit 71024cb4a0bf ("frontswap: remove frontswap_tmem_exclusive_gets")
> > > removed support for exclusive loads from frontswap as it was not used.
> > > Bring back exclusive loads support to frontswap by adding an "exclusive"
> > > output parameter to frontswap_ops->load.
> > >
> > > On the zswap side, add a module parameter to enable/disable exclusive
> > > loads, and a config option to control the boot default value.
> > > Refactor zswap entry invalidation in zswap_frontswap_invalidate_page()
> > > into zswap_invalidate_entry() to reuse it in zswap_frontswap_load() if
> > > exclusive loads are enabled.
> > >
> > > With exclusive loads, we avoid having two copies of the same page in
> > > memory (compressed & uncompressed) after faulting it in from zswap. On
> > > the other hand, if the page is to be reclaimed again without being
> > > dirtied, it will be re-compressed. Compression is not usually slow, and
> > > a page that was just faulted in is less likely to be reclaimed again
> > > soon.
> > >
> > > Suggested-by: Yu Zhao <yuzhao@google.com>
> > > Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> > > ---
> > >
> > > v1 -> v2:
> > > - Add a module parameter to control whether exclusive loads are enabled
> > >   or not, the config option now controls the default boot value instead.
> > >   Replaced frontswap_ops->exclusive_loads by an output parameter to
> > >   frontswap_ops->load() (Johannes Weiner).
> > > ---
> >
> > Hi Yosry, I was testing the latest mm-unstable and encountered a bug.
> > It was bisectable and this is the first bad commit.
> >
> >
> > Attached config file and bisect log.
> > The oops message is available at:
> >
> > https://social.kernel.org/media/eace06d71655b3cc76411366573e4a8ce240ad65b8fd20977d7c73eec9dc2253.jpg
> >
> > (the head commit is b9c91c43412f2e07 "mm: zswap: support exclusive loads")
> > (it's an image because I tested it on real machine)
> >
> >
> > This is what I have as swap space:
> >
> > $ cat /proc/swaps
> > Filename                                Type            Size            Used            Priority
> > /var/swap                               file            134217724       0               -2
> > /dev/zram0                              partition       8388604         0               100
>
>
> Hi Hyeonggon,
>
> Thanks for reporting this! I think I know what went wrong. Could you
> please verify if the below fix works if possible?
>
> Domenico, I believe the below fix would also fix a problem with the
> recent writeback series. If the entry is invalidated before we grab the
> lock to put the local ref in zswap_frontswap_load(), then the entry
> will be freed once we call zswap_entry_put(), and the movement to the
> beginning LRU will be operating on a freed entry. It also modifies
> your recently added commit 418fd29d9de5 ("mm: zswap: invaldiate entry
> after writeback"). I would appreciate it if you also take a look.

Hi Yosry,

Thanks, this makes sense indeed. I've been running a stress test too for
an hour now and it seems fine.

>
> If this works as intended, I can send a formal patch (applies on top
> of fd247f029cd0 ("mm/gup: do not return 0 from pin_user_pages_fast()
> for bad args")):
>
> From 4b7f949b3ffb42d969d525d5b576fad474f55276 Mon Sep 17 00:00:00 2001
> From: Yosry Ahmed <yosryahmed@google.com>
> Date: Wed, 21 Jun 2023 07:43:51 +0000
> Subject: [PATCH] mm: zswap: fix double invalidate with exclusive loads
>
> If exclusive loads are enabled for zswap, we invalidate the entry before
> returning from zswap_frontswap_load(), after dropping the local
> reference. However, the tree lock is dropped during decompression after
> the local reference is acquired, so the entry could be invalidated
> before we drop the local ref. If this happens, the entry is freed once
> we drop the local ref, and zswap_invalidate_entry() tries to invalidate
> an already freed entry.
>
> Fix this by:
> (a) Making sure zswap_invalidate_entry() is always called with a local
>     ref held, to avoid being called on a freed entry.
> (b) Making sure zswap_invalidate_entry() only drops the ref if the entry
>     was actually on the rbtree. Otherwise, another invalidation could
>     have already happened, and the initial ref is already dropped.
>
> With these changes, there is no need to check that there is no need to
> make sure the entry still exists in the tree in zswap_reclaim_entry()
> before invalidating it, as zswap_reclaim_entry() will make this check
> internally.
>
> Fixes: b9c91c43412f ("mm: zswap: support exclusive loads")
> Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
> Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> ---
>  mm/zswap.c | 21 ++++++++++++---------
>  1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index 87b204233115..62195f72bf56 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -355,12 +355,14 @@ static int zswap_rb_insert(struct rb_root *root,
> struct zswap_entry *entry,
>         return 0;
>  }
>
> -static void zswap_rb_erase(struct rb_root *root, struct zswap_entry *entry)
> +static bool zswap_rb_erase(struct rb_root *root, struct zswap_entry *entry)
>  {
>         if (!RB_EMPTY_NODE(&entry->rbnode)) {
>                 rb_erase(&entry->rbnode, root);
>                 RB_CLEAR_NODE(&entry->rbnode);
> +               return true;
>         }
> +       return false;
>  }
>
>  /*
> @@ -599,14 +601,16 @@ static struct zswap_pool
> *zswap_pool_find_get(char *type, char *compressor)
>         return NULL;
>  }
>
> +/*
> + * If the entry is still valid in the tree, drop the initial ref and remove it
> + * from the tree. This function must be called with an additional ref held,
> + * otherwise it may race with another invalidation freeing the entry.
> + */
>  static void zswap_invalidate_entry(struct zswap_tree *tree,
>                                    struct zswap_entry *entry)
>  {
> -       /* remove from rbtree */
> -       zswap_rb_erase(&tree->rbroot, entry);
> -
> -       /* drop the initial reference from entry creation */
> -       zswap_entry_put(tree, entry);
> +       if (zswap_rb_erase(&tree->rbroot, entry))
> +               zswap_entry_put(tree, entry);
>  }
>
>  static int zswap_reclaim_entry(struct zswap_pool *pool)
> @@ -659,8 +663,7 @@ static int zswap_reclaim_entry(struct zswap_pool *pool)
>          * swapcache. Drop the entry from zswap - unless invalidate already
>          * took it out while we had the tree->lock released for IO.
>          */
> -       if (entry == zswap_rb_search(&tree->rbroot, swpoffset))
> -               zswap_invalidate_entry(tree, entry);
> +       zswap_invalidate_entry(tree, entry);
>
>  put_unlock:
>         /* Drop local reference */
> @@ -1466,7 +1469,6 @@ static int zswap_frontswap_load(unsigned type,
> pgoff_t offset,
>                 count_objcg_event(entry->objcg, ZSWPIN);
>  freeentry:
>         spin_lock(&tree->lock);
> -       zswap_entry_put(tree, entry);
>         if (!ret && zswap_exclusive_loads_enabled) {
>                 zswap_invalidate_entry(tree, entry);
>                 *exclusive = true;
> @@ -1475,6 +1477,7 @@ static int zswap_frontswap_load(unsigned type,
> pgoff_t offset,
>                 list_move(&entry->lru, &entry->pool->lru);
>                 spin_unlock(&entry->pool->lru_lock);
>         }
> +       zswap_entry_put(tree, entry);
>         spin_unlock(&tree->lock);
>
>         return ret;
> --
> 2.41.0.162.gfafddb0af9-goog

^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] "kernel BUG at mm/swap.c:393!" on commit b9c91c43412f2e
  2023-06-21  9:18 82%     ` Domenico Cerasuolo
@ 2023-06-21  9:26 82%       ` Yosry Ahmed
  0 siblings, 0 replies; 200+ results
From: Yosry Ahmed @ 2023-06-21  9:26 UTC (permalink / raw)
  To: Domenico Cerasuolo
  Cc: Hyeonggon Yoo, Andrew Morton, Konrad Rzeszutek Wilk,
	Seth Jennings, Dan Streetman, Vitaly Wool, Johannes Weiner,
	Nhat Pham, Yu Zhao, linux-mm, linux-kernel

On Wed, Jun 21, 2023 at 2:19 AM Domenico Cerasuolo
<cerasuolodomenico@gmail.com> wrote:
>
> On Wed, Jun 21, 2023 at 10:06 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > On Wed, Jun 21, 2023 at 12:01 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> > >
> > > On Wed, Jun 07, 2023 at 07:51:43PM +0000, Yosry Ahmed wrote:
> > > > Commit 71024cb4a0bf ("frontswap: remove frontswap_tmem_exclusive_gets")
> > > > removed support for exclusive loads from frontswap as it was not used.
> > > > Bring back exclusive loads support to frontswap by adding an "exclusive"
> > > > output parameter to frontswap_ops->load.
> > > >
> > > > On the zswap side, add a module parameter to enable/disable exclusive
> > > > loads, and a config option to control the boot default value.
> > > > Refactor zswap entry invalidation in zswap_frontswap_invalidate_page()
> > > > into zswap_invalidate_entry() to reuse it in zswap_frontswap_load() if
> > > > exclusive loads are enabled.
> > > >
> > > > With exclusive loads, we avoid having two copies of the same page in
> > > > memory (compressed & uncompressed) after faulting it in from zswap. On
> > > > the other hand, if the page is to be reclaimed again without being
> > > > dirtied, it will be re-compressed. Compression is not usually slow, and
> > > > a page that was just faulted in is less likely to be reclaimed again
> > > > soon.
> > > >
> > > > Suggested-by: Yu Zhao <yuzhao@google.com>
> > > > Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> > > > ---
> > > >
> > > > v1 -> v2:
> > > > - Add a module parameter to control whether exclusive loads are enabled
> > > >   or not, the config option now controls the default boot value instead.
> > > >   Replaced frontswap_ops->exclusive_loads by an output parameter to
> > > >   frontswap_ops->load() (Johannes Weiner).
> > > > ---
> > >
> > > Hi Yosry, I was testing the latest mm-unstable and encountered a bug.
> > > It was bisectable and this is the first bad commit.
> > >
> > >
> > > Attached config file and bisect log.
> > > The oops message is available at:
> > >
> > > https://social.kernel.org/media/eace06d71655b3cc76411366573e4a8ce240ad65b8fd20977d7c73eec9dc2253.jpg
> > >
> > > (the head commit is b9c91c43412f2e07 "mm: zswap: support exclusive loads")
> > > (it's an image because I tested it on real machine)
> > >
> > >
> > > This is what I have as swap space:
> > >
> > > $ cat /proc/swaps
> > > Filename                                Type            Size            Used            Priority
> > > /var/swap                               file            134217724       0               -2
> > > /dev/zram0                              partition       8388604         0               100
> >
> >
> > Hi Hyeonggon,
> >
> > Thanks for reporting this! I think I know what went wrong. Could you
> > please verify if the below fix works if possible?
> >
> > Domenico, I believe the below fix would also fix a problem with the
> > recent writeback series. If the entry is invalidated before we grab the
> > lock to put the local ref in zswap_frontswap_load(), then the entry
> > will be freed once we call zswap_entry_put(), and the movement to the
> > beginning LRU will be operating on a freed entry. It also modifies
> > your recently added commit 418fd29d9de5 ("mm: zswap: invaldiate entry
> > after writeback"). I would appreciate it if you also take a look.
>
> Hi Yosry,
>
> Thanks, this makes sense indeed. I've been running a stress test too for
> an hour now and it seems fine.

Thanks! I will send the patch to Andrew then!

>
> >
> > If this works as intended, I can send a formal patch (applies on top
> > of fd247f029cd0 ("mm/gup: do not return 0 from pin_user_pages_fast()
> > for bad args")):
> >
> > From 4b7f949b3ffb42d969d525d5b576fad474f55276 Mon Sep 17 00:00:00 2001
> > From: Yosry Ahmed <yosryahmed@google.com>
> > Date: Wed, 21 Jun 2023 07:43:51 +0000
> > Subject: [PATCH] mm: zswap: fix double invalidate with exclusive loads
> >
> > If exclusive loads are enabled for zswap, we invalidate the entry before
> > returning from zswap_frontswap_load(), after dropping the local
> > reference. However, the tree lock is dropped during decompression after
> > the local reference is acquired, so the entry could be invalidated
> > before we drop the local ref. If this happens, the entry is freed once
> > we drop the local ref, and zswap_invalidate_entry() tries to invalidate
> > an already freed entry.
> >
> > Fix this by:
> > (a) Making sure zswap_invalidate_entry() is always called with a local
> >     ref held, to avoid being called on a freed entry.
> > (b) Making sure zswap_invalidate_entry() only drops the ref if the entry
> >     was actually on the rbtree. Otherwise, another invalidation could
> >     have already happened, and the initial ref is already dropped.
> >
> > With these changes, there is no need to check that there is no need to
> > make sure the entry still exists in the tree in zswap_reclaim_entry()
> > before invalidating it, as zswap_reclaim_entry() will make this check
> > internally.
> >
> > Fixes: b9c91c43412f ("mm: zswap: support exclusive loads")
> > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
> > Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> > ---
> >  mm/zswap.c | 21 ++++++++++++---------
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index 87b204233115..62195f72bf56 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -355,12 +355,14 @@ static int zswap_rb_insert(struct rb_root *root,
> > struct zswap_entry *entry,
> >         return 0;
> >  }
> >
> > -static void zswap_rb_erase(struct rb_root *root, struct zswap_entry *entry)
> > +static bool zswap_rb_erase(struct rb_root *root, struct zswap_entry *entry)
> >  {
> >         if (!RB_EMPTY_NODE(&entry->rbnode)) {
> >                 rb_erase(&entry->rbnode, root);
> >                 RB_CLEAR_NODE(&entry->rbnode);
> > +               return true;
> >         }
> > +       return false;
> >  }
> >
> >  /*
> > @@ -599,14 +601,16 @@ static struct zswap_pool
> > *zswap_pool_find_get(char *type, char *compressor)
> >         return NULL;
> >  }
> >
> > +/*
> > + * If the entry is still valid in the tree, drop the initial ref and remove it
> > + * from the tree. This function must be called with an additional ref held,
> > + * otherwise it may race with another invalidation freeing the entry.
> > + */
> >  static void zswap_invalidate_entry(struct zswap_tree *tree,
> >                                    struct zswap_entry *entry)
> >  {
> > -       /* remove from rbtree */
> > -       zswap_rb_erase(&tree->rbroot, entry);
> > -
> > -       /* drop the initial reference from entry creation */
> > -       zswap_entry_put(tree, entry);
> > +       if (zswap_rb_erase(&tree->rbroot, entry))
> > +               zswap_entry_put(tree, entry);
> >  }
> >
> >  static int zswap_reclaim_entry(struct zswap_pool *pool)
> > @@ -659,8 +663,7 @@ static int zswap_reclaim_entry(struct zswap_pool *pool)
> >          * swapcache. Drop the entry from zswap - unless invalidate already
> >          * took it out while we had the tree->lock released for IO.
> >          */
> > -       if (entry == zswap_rb_search(&tree->rbroot, swpoffset))
> > -               zswap_invalidate_entry(tree, entry);
> > +       zswap_invalidate_entry(tree, entry);
> >
> >  put_unlock:
> >         /* Drop local reference */
> > @@ -1466,7 +1469,6 @@ static int zswap_frontswap_load(unsigned type,
> > pgoff_t offset,
> >                 count_objcg_event(entry->objcg, ZSWPIN);
> >  freeentry:
> >         spin_lock(&tree->lock);
> > -       zswap_entry_put(tree, entry);
> >         if (!ret && zswap_exclusive_loads_enabled) {
> >                 zswap_invalidate_entry(tree, entry);
> >                 *exclusive = true;
> > @@ -1475,6 +1477,7 @@ static int zswap_frontswap_load(unsigned type,
> > pgoff_t offset,
> >                 list_move(&entry->lru, &entry->pool->lru);
> >                 spin_unlock(&entry->pool->lru_lock);
> >         }
> > +       zswap_entry_put(tree, entry);
> >         spin_unlock(&tree->lock);
> >
> >         return ret;
> > --
> > 2.41.0.162.gfafddb0af9-goog

^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0
  @ 2023-06-21 13:40 82% ` Jens Axboe
  2023-06-21 14:04 82%   ` Jens Axboe
    0 siblings, 2 replies; 200+ results
From: Jens Axboe @ 2023-06-21 13:40 UTC (permalink / raw)
  To: Guangwu Zhang, linux-block, Ming Lei, Jeff Moyer, io-uring

On 6/21/23 1:38?AM, Guangwu Zhang wrote:
> HI,
> Found the io_req_local_work_add error when run  liburing testing.
> 
> kernel repo :
>     Merge branch 'for-6.5/block' into for-next
>     * for-6.5/block:
>       reiserfs: fix blkdev_put() warning from release_journal_dev()
> 
> [ 1733.389012] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0
> [ 1733.395900] Read of size 4 at addr ffff888133320458 by task
> iou-wrk-97057/97138
> [ 1733.403205]
> [ 1733.404706] CPU: 4 PID: 97138 Comm: iou-wrk-97057 Kdump: loaded Not
> tainted 6.4.0-rc3.kasan+ #1
> [ 1733.413404] Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS
> 2.13.3 12/13/2021
> [ 1733.420972] Call Trace:
> [ 1733.423425]  <TASK>
> [ 1733.425533]  dump_stack_lvl+0x33/0x50
> [ 1733.429207]  print_address_description.constprop.0+0x2c/0x3e0
> [ 1733.434959]  print_report+0xb5/0x270
> [ 1733.438539]  ? kasan_addr_to_slab+0x9/0xa0
> [ 1733.442639]  ? io_req_local_work_add+0x3b1/0x4a0
> [ 1733.447258]  kasan_report+0xcf/0x100
> [ 1733.450839]  ? io_req_local_work_add+0x3b1/0x4a0
> [ 1733.455456]  io_req_local_work_add+0x3b1/0x4a0
> [ 1733.459903]  ? __pfx_io_req_local_work_add+0x10/0x10
> [ 1733.464871]  ? __schedule+0x616/0x1530
> [ 1733.468622]  __io_req_task_work_add+0x1bc/0x270
> [ 1733.473156]  io_issue_sqe+0x55a/0xe80
> [ 1733.476831]  io_wq_submit_work+0x23e/0xa00
> [ 1733.480930]  io_worker_handle_work+0x2f5/0xa80
> [ 1733.485384]  io_wq_worker+0x6c5/0x9d0
> [ 1733.489051]  ? __pfx_io_wq_worker+0x10/0x10
> [ 1733.493246]  ? _raw_spin_lock_irq+0x82/0xe0
> [ 1733.497430]  ? __pfx_io_wq_worker+0x10/0x10
> [ 1733.501616]  ret_from_fork+0x29/0x50
> [ 1733.505204]  </TASK>
> [ 1733.507396]
> [ 1733.508894] Allocated by task 97057:
> [ 1733.512475]  kasan_save_stack+0x1e/0x40
> [ 1733.516313]  kasan_set_track+0x21/0x30
> [ 1733.520068]  __kasan_slab_alloc+0x83/0x90
> [ 1733.524080]  kmem_cache_alloc_bulk+0x13a/0x1e0
> [ 1733.528526]  __io_alloc_req_refill+0x238/0x510
> [ 1733.532971]  io_submit_sqes+0x65a/0xcd0
> [ 1733.536810]  __do_sys_io_uring_enter+0x4e9/0x830
> [ 1733.541430]  do_syscall_64+0x59/0x90
> [ 1733.545010]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> [ 1733.550071]
> [ 1733.551571] The buggy address belongs to the object at ffff8881333203c0
> [ 1733.551571]  which belongs to the cache io_kiocb of size 224
> [ 1733.563816] The buggy address is located 152 bytes inside of
> [ 1733.563816]  224-byte region [ffff8881333203c0, ffff8881333204a0)
> [ 1733.575544]
> [ 1733.577042] The buggy address belongs to the physical page:
> [ 1733.582617] page:00000000edbe178c refcount:1 mapcount:0
> mapping:0000000000000000 index:0x0 pfn:0x133320
> [ 1733.592011] head:00000000edbe178c order:1 entire_mapcount:0
> nr_pages_mapped:0 pincount:0
> [ 1733.600096] memcg:ffff88810cd49001
> [ 1733.603501] flags:
> 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
> [ 1733.610896] page_type: 0xffffffff()
> [ 1733.614390] raw: 0017ffffc0010200 ffff888101222280 ffffea0004473900
> 0000000000000002
> [ 1733.622128] raw: 0000000000000000 0000000000190019 00000001ffffffff
> ffff88810cd49001
> [ 1733.629866] page dumped because: kasan: bad access detected
> [ 1733.635439]
> [ 1733.636938] Memory state around the buggy address:
> [ 1733.641731]  ffff888133320300: 00 00 00 00 00 00 00 00 00 00 00 00
> fc fc fc fc
> [ 1733.648952]  ffff888133320380: fc fc fc fc fc fc fc fc 00 00 00 00
> 00 00 00 00
> [ 1733.656169] >ffff888133320400: 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00
> [ 1733.663389]                                                        ^
> [ 1733.669743]  ffff888133320480: 00 00 00 00 fc fc fc fc fc fc fc fc
> fc fc fc fc
> [ 1733.676961]  ffff888133320500: 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00

I appreciate you running tests and sending in failures, but can you
please be more specific about what exactly was run? We seem to need to
do this dance every time, which is just wasting time. So:

1) What test triggered this?
2) Was it invoked with any arguments?

In general, a good bug report should include exactly HOW you ended
up there.

-- 
Jens Axboe


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0
  2023-06-21 13:40 82% ` Jens Axboe
@ 2023-06-21 14:04 82%   ` Jens Axboe
    1 sibling, 0 replies; 200+ results
From: Jens Axboe @ 2023-06-21 14:04 UTC (permalink / raw)
  To: Guangwu Zhang, linux-block, Ming Lei, Jeff Moyer, io-uring

On 6/21/23 7:40?AM, Jens Axboe wrote:
> On 6/21/23 1:38?AM, Guangwu Zhang wrote:
>> HI,
>> Found the io_req_local_work_add error when run  liburing testing.
>>
>> kernel repo :
>>     Merge branch 'for-6.5/block' into for-next
>>     * for-6.5/block:
>>       reiserfs: fix blkdev_put() warning from release_journal_dev()
>>
>> [ 1733.389012] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0
>> [ 1733.395900] Read of size 4 at addr ffff888133320458 by task
>> iou-wrk-97057/97138
>> [ 1733.403205]
>> [ 1733.404706] CPU: 4 PID: 97138 Comm: iou-wrk-97057 Kdump: loaded Not
>> tainted 6.4.0-rc3.kasan+ #1
>> [ 1733.413404] Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS
>> 2.13.3 12/13/2021
>> [ 1733.420972] Call Trace:
>> [ 1733.423425]  <TASK>
>> [ 1733.425533]  dump_stack_lvl+0x33/0x50
>> [ 1733.429207]  print_address_description.constprop.0+0x2c/0x3e0
>> [ 1733.434959]  print_report+0xb5/0x270
>> [ 1733.438539]  ? kasan_addr_to_slab+0x9/0xa0
>> [ 1733.442639]  ? io_req_local_work_add+0x3b1/0x4a0
>> [ 1733.447258]  kasan_report+0xcf/0x100
>> [ 1733.450839]  ? io_req_local_work_add+0x3b1/0x4a0
>> [ 1733.455456]  io_req_local_work_add+0x3b1/0x4a0
>> [ 1733.459903]  ? __pfx_io_req_local_work_add+0x10/0x10
>> [ 1733.464871]  ? __schedule+0x616/0x1530
>> [ 1733.468622]  __io_req_task_work_add+0x1bc/0x270
>> [ 1733.473156]  io_issue_sqe+0x55a/0xe80
>> [ 1733.476831]  io_wq_submit_work+0x23e/0xa00
>> [ 1733.480930]  io_worker_handle_work+0x2f5/0xa80
>> [ 1733.485384]  io_wq_worker+0x6c5/0x9d0
>> [ 1733.489051]  ? __pfx_io_wq_worker+0x10/0x10
>> [ 1733.493246]  ? _raw_spin_lock_irq+0x82/0xe0
>> [ 1733.497430]  ? __pfx_io_wq_worker+0x10/0x10
>> [ 1733.501616]  ret_from_fork+0x29/0x50
>> [ 1733.505204]  </TASK>
>> [ 1733.507396]
>> [ 1733.508894] Allocated by task 97057:
>> [ 1733.512475]  kasan_save_stack+0x1e/0x40
>> [ 1733.516313]  kasan_set_track+0x21/0x30
>> [ 1733.520068]  __kasan_slab_alloc+0x83/0x90
>> [ 1733.524080]  kmem_cache_alloc_bulk+0x13a/0x1e0
>> [ 1733.528526]  __io_alloc_req_refill+0x238/0x510
>> [ 1733.532971]  io_submit_sqes+0x65a/0xcd0
>> [ 1733.536810]  __do_sys_io_uring_enter+0x4e9/0x830
>> [ 1733.541430]  do_syscall_64+0x59/0x90
>> [ 1733.545010]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
>> [ 1733.550071]
>> [ 1733.551571] The buggy address belongs to the object at ffff8881333203c0
>> [ 1733.551571]  which belongs to the cache io_kiocb of size 224
>> [ 1733.563816] The buggy address is located 152 bytes inside of
>> [ 1733.563816]  224-byte region [ffff8881333203c0, ffff8881333204a0)
>> [ 1733.575544]
>> [ 1733.577042] The buggy address belongs to the physical page:
>> [ 1733.582617] page:00000000edbe178c refcount:1 mapcount:0
>> mapping:0000000000000000 index:0x0 pfn:0x133320
>> [ 1733.592011] head:00000000edbe178c order:1 entire_mapcount:0
>> nr_pages_mapped:0 pincount:0
>> [ 1733.600096] memcg:ffff88810cd49001
>> [ 1733.603501] flags:
>> 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
>> [ 1733.610896] page_type: 0xffffffff()
>> [ 1733.614390] raw: 0017ffffc0010200 ffff888101222280 ffffea0004473900
>> 0000000000000002
>> [ 1733.622128] raw: 0000000000000000 0000000000190019 00000001ffffffff
>> ffff88810cd49001
>> [ 1733.629866] page dumped because: kasan: bad access detected
>> [ 1733.635439]
>> [ 1733.636938] Memory state around the buggy address:
>> [ 1733.641731]  ffff888133320300: 00 00 00 00 00 00 00 00 00 00 00 00
>> fc fc fc fc
>> [ 1733.648952]  ffff888133320380: fc fc fc fc fc fc fc fc 00 00 00 00
>> 00 00 00 00
>> [ 1733.656169] >ffff888133320400: 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 00
>> [ 1733.663389]                                                        ^
>> [ 1733.669743]  ffff888133320480: 00 00 00 00 fc fc fc fc fc fc fc fc
>> fc fc fc fc
>> [ 1733.676961]  ffff888133320500: 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 00
> 
> I appreciate you running tests and sending in failures, but can you
> please be more specific about what exactly was run? We seem to need to
> do this dance every time, which is just wasting time. So:
> 
> 1) What test triggered this?
> 2) Was it invoked with any arguments?
> 
> In general, a good bug report should include exactly HOW you ended
> up there.

Another thing that's really handy in bug reports like this is a
disassemble of where the bad memory access occured.  We have this:

BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0

and you can look that up in gdb, for example.

-- 
Jens Axboe


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0
  @ 2023-06-21 15:56 82%     ` Jens Axboe
    0 siblings, 1 reply; 200+ results
From: Jens Axboe @ 2023-06-21 15:56 UTC (permalink / raw)
  To: Ming Lei; +Cc: Guangwu Zhang, linux-block, Jeff Moyer, io-uring

On 6/21/23 8:04?AM, Ming Lei wrote:
> On Wed, Jun 21, 2023 at 07:40:49AM -0600, Jens Axboe wrote:
>> On 6/21/23 1:38?AM, Guangwu Zhang wrote:
>>> HI,
>>> Found the io_req_local_work_add error when run  liburing testing.
>>>
>>> kernel repo :
>>>     Merge branch 'for-6.5/block' into for-next
>>>     * for-6.5/block:
>>>       reiserfs: fix blkdev_put() warning from release_journal_dev()
>>>
>>> [ 1733.389012] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0
>>> [ 1733.395900] Read of size 4 at addr ffff888133320458 by task
>>> iou-wrk-97057/97138
>>> [ 1733.403205]
>>> [ 1733.404706] CPU: 4 PID: 97138 Comm: iou-wrk-97057 Kdump: loaded Not
>>> tainted 6.4.0-rc3.kasan+ #1
>>> [ 1733.413404] Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS
>>> 2.13.3 12/13/2021
>>> [ 1733.420972] Call Trace:
>>> [ 1733.423425]  <TASK>
>>> [ 1733.425533]  dump_stack_lvl+0x33/0x50
>>> [ 1733.429207]  print_address_description.constprop.0+0x2c/0x3e0
>>> [ 1733.434959]  print_report+0xb5/0x270
>>> [ 1733.438539]  ? kasan_addr_to_slab+0x9/0xa0
>>> [ 1733.442639]  ? io_req_local_work_add+0x3b1/0x4a0
>>> [ 1733.447258]  kasan_report+0xcf/0x100
>>> [ 1733.450839]  ? io_req_local_work_add+0x3b1/0x4a0
>>> [ 1733.455456]  io_req_local_work_add+0x3b1/0x4a0
>>> [ 1733.459903]  ? __pfx_io_req_local_work_add+0x10/0x10
>>> [ 1733.464871]  ? __schedule+0x616/0x1530
>>> [ 1733.468622]  __io_req_task_work_add+0x1bc/0x270
>>> [ 1733.473156]  io_issue_sqe+0x55a/0xe80
>>> [ 1733.476831]  io_wq_submit_work+0x23e/0xa00
>>> [ 1733.480930]  io_worker_handle_work+0x2f5/0xa80
>>> [ 1733.485384]  io_wq_worker+0x6c5/0x9d0
>>> [ 1733.489051]  ? __pfx_io_wq_worker+0x10/0x10
>>> [ 1733.493246]  ? _raw_spin_lock_irq+0x82/0xe0
>>> [ 1733.497430]  ? __pfx_io_wq_worker+0x10/0x10
>>> [ 1733.501616]  ret_from_fork+0x29/0x50
>>> [ 1733.505204]  </TASK>
>>> [ 1733.507396]
>>> [ 1733.508894] Allocated by task 97057:
>>> [ 1733.512475]  kasan_save_stack+0x1e/0x40
>>> [ 1733.516313]  kasan_set_track+0x21/0x30
>>> [ 1733.520068]  __kasan_slab_alloc+0x83/0x90
>>> [ 1733.524080]  kmem_cache_alloc_bulk+0x13a/0x1e0
>>> [ 1733.528526]  __io_alloc_req_refill+0x238/0x510
>>> [ 1733.532971]  io_submit_sqes+0x65a/0xcd0
>>> [ 1733.536810]  __do_sys_io_uring_enter+0x4e9/0x830
>>> [ 1733.541430]  do_syscall_64+0x59/0x90
>>> [ 1733.545010]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
>>> [ 1733.550071]
>>> [ 1733.551571] The buggy address belongs to the object at ffff8881333203c0
>>> [ 1733.551571]  which belongs to the cache io_kiocb of size 224
>>> [ 1733.563816] The buggy address is located 152 bytes inside of
>>> [ 1733.563816]  224-byte region [ffff8881333203c0, ffff8881333204a0)
>>> [ 1733.575544]
>>> [ 1733.577042] The buggy address belongs to the physical page:
>>> [ 1733.582617] page:00000000edbe178c refcount:1 mapcount:0
>>> mapping:0000000000000000 index:0x0 pfn:0x133320
>>> [ 1733.592011] head:00000000edbe178c order:1 entire_mapcount:0
>>> nr_pages_mapped:0 pincount:0
>>> [ 1733.600096] memcg:ffff88810cd49001
>>> [ 1733.603501] flags:
>>> 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
>>> [ 1733.610896] page_type: 0xffffffff()
>>> [ 1733.614390] raw: 0017ffffc0010200 ffff888101222280 ffffea0004473900
>>> 0000000000000002
>>> [ 1733.622128] raw: 0000000000000000 0000000000190019 00000001ffffffff
>>> ffff88810cd49001
>>> [ 1733.629866] page dumped because: kasan: bad access detected
>>> [ 1733.635439]
>>> [ 1733.636938] Memory state around the buggy address:
>>> [ 1733.641731]  ffff888133320300: 00 00 00 00 00 00 00 00 00 00 00 00
>>> fc fc fc fc
>>> [ 1733.648952]  ffff888133320380: fc fc fc fc fc fc fc fc 00 00 00 00
>>> 00 00 00 00
>>> [ 1733.656169] >ffff888133320400: 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 00 00 00
>>> [ 1733.663389]                                                        ^
>>> [ 1733.669743]  ffff888133320480: 00 00 00 00 fc fc fc fc fc fc fc fc
>>> fc fc fc fc
>>> [ 1733.676961]  ffff888133320500: 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 00 00 00
>>
>> I appreciate you running tests and sending in failures, but can you
>> please be more specific about what exactly was run? We seem to need to
>> do this dance every time, which is just wasting time. So:
>>
>> 1) What test triggered this?
>> 2) Was it invoked with any arguments?
> 
> I can see the whole dmesg log, and it seems from "sq-full-cpp.c /dev/sda":
> 
> [ 1340.918880] Running test sq-full-cpp.t:
> [ 1341.009225] Running test sq-full-cpp.t /dev/sda:
> [ 1342.025292] restraintd[1061]: *** Current Time: Tue Jun 20 21:17:57 2023  Localwatchdog at: Wed Jun 21 01:03:56 2023
> [ 1402.053433] restraintd[1061]: *** Current Time: Tue Jun 20 21:18:57 2023  Localwatchdog at: Wed Jun 21 01:03:56 2023
> [ 1462.047970] restraintd[1061]: *** Current Time: Tue Jun 20 21:19:57 2023  Localwatchdog at: Wed Jun 21 01:03:56 2023
> [-- MARK -- Wed Jun 21 01:20:00 2023]
> [ 1522.029598] restraintd[1061]: *** Current Time: Tue Jun 20 21:20:57 2023  Localwatchdog at: Wed Jun 21 01:03:56 2023
> [ 1582.029278] restraintd[1061]: *** Current Time: Tue Jun 20 21:21:57 2023  Localwatchdog at: Wed Jun 21 01:03:56 2023
> [ 1642.034617] restraintd[1061]: *** Current Time: Tue Jun 20 21:22:57 2023  Localwatchdog at: Wed Jun 21 01:03:56 2023
> [ 1702.034344] restraintd[1061]: *** Current Time: Tue Jun 20 21:23:57 2023  Localwatchdog at: Wed Jun 21 01:03:56 2023
> [ 1733.381782] ==================================================================
> [ 1733.389012] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0
> [ 1733.395900] Read of size 4 at addr ffff888133320458 by task iou-wrk-97057/97138

I don't think that's right - sq-full-cpp doesn't do anything if passed
an argument, and you also have a lot of time passing in between that
test being run and the warning being spewed. Maybe the tests are run
both as root and non-root? The root run ones will add the dmesg spew on
which test is being run, the non-root will not.

-- 
Jens Axboe


^ permalink raw reply	[relevance 82%]

* Re: [bug report] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0
  @ 2023-06-23 12:14 82%         ` Jeff Moyer
  0 siblings, 0 replies; 200+ results
From: Jeff Moyer @ 2023-06-23 12:14 UTC (permalink / raw)
  To: Guangwu Zhang; +Cc: Jens Axboe, Ming Lei, linux-block, io-uring

Guangwu Zhang <guazhang@redhat.com> writes:

> Just hit the bug one time with liburing testing, so it hard to said
> which case triggered the issue,
> here is the test steps
> 1) enable kernel KASAN module
> 2) mkfs and mount with sda and set TEST_FILES=/dev/sda
> 3) copy all liburing cases to mount point
> 4) make runtests as root

Just a note on the test procedure: you shouldn't mount sda *and* set
TEST_FILES to sda.  You can leave TEST_FILES empty for this case.

-Jeff


^ permalink raw reply	[relevance 82%]

* Bug#1036530: Info received (Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system))
  @ 2023-06-26 12:36 82% ` Debian Bug Tracking System
  0 siblings, 0 replies; 200+ results
From: Debian Bug Tracking System @ 2023-06-26 12:36 UTC (permalink / raw)
  To: Linux regressions mailing list

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Kernel Team <debian-kernel@lists.debian.org>

If you wish to submit further information on this problem, please
send it to 1036530@bugs.debian.org.

Please do not send mail to owner@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
1036530: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

^ permalink raw reply	[relevance 82%]

* Re: [BUG]Bluetooth: HCI_Command_Status: possible semantic bug when Num_HCI_Command_Packets set to zero
       [not found]     <259e755c.4eaad.188f817a0f3.Coremail.lxybhu@buaa.edu.cn>
@ 2023-06-26 19:25 82% ` Luiz Augusto von Dentz
  0 siblings, 0 replies; 200+ results
From: Luiz Augusto von Dentz @ 2023-06-26 19:25 UTC (permalink / raw)
  To: 刘新宇
  Cc: marcel, johan.hedberg, davem, edumazet, kuba, pabeni,
	baijiaju1990, sy2239101, linux-bluetooth, linux-kernel, netdev

Hi,

On Mon, Jun 26, 2023 at 7:25 AM 刘新宇 <lxybhu@buaa.edu.cn> wrote:
>
> Hello,
>
> Our fuzzing tool finds a possible semantic bug in the Bluetooth system in Linux 5.18:
>
> During the connection process, the host server needs to receive the HCI_Command_Status packet from the hardware controller. In normal cases, the Num_HCI_Command_Packets field of this packet is not zero, and the host server can normally handle this packet. However, in our testing, when the Num_HCI_Command_Packets field is set to zero, the Bluetooth functionality is totally stopped until it is manually reopened.
>
> In the Bluetooth Core Specification 5.4, the section 7.7.15 "Command Status event" says that:
>
> "The Num_HCI_Command_Packets event parameter allows the Controller to indicate the number of HCI command packets the Host can send to the Controller. If the Controller requires the Host to stop sending commands, the Num_HCI_Command_Packets event parameter will be set to zero."
>
> This section does not mean that the Bluetooth functionality needs to be totally stopped when Num_HCI_Command_Packets is zero. Maybe in this case, the Bluetooth functionality could be still available, but the host server could reject any packet until Num_HCI_Command_Packets is not zero.

Well it says, If the Controller requires the Host to stop sending
commands, so if your tool is sending 0 then it is requesting he host
to stop sending more commands, if you want it to continue just send
another Num_HCI_Command_Packets, or are you saying some other
functionality that doesn't require sending commands shall still work?

> We are not sure whether this is a semantic bug or implementation feature in the Linux kernel. Any feedback would be appreciated, thanks!
>
>
> Best wishes,
> Xin-Yu Liu



-- 
Luiz Augusto von Dentz

^ permalink raw reply	[relevance 82%]

* [Bug 217613] [BUG] [media] dvb-usb: possible data-inconsistency due to data races in dib0700_rc_query_old_firmware()
                     ` (2 preceding siblings ...)
  2023-06-30  8:11 82% ` [Bug 217613] " bugzilla-daemon
@ 2023-06-30  1:48 82% ` bugzilla-daemon
  3 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-06-30  1:48 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217613

Tuo Li (islituo@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Tuo Li (islituo@gmail.com) ---


*** This bug has been marked as a duplicate of bug 217614 ***

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 217614] [BUG] [media] dvb-usb: possible data-inconsistency due to data races in dib0700_rc_query_old_firmware()
  @ 2023-06-30  1:48 82% ` bugzilla-daemon
  0 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-06-30  1:48 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217614

--- Comment #1 from Tuo Li (islituo@gmail.com) ---
*** Bug 217613 has been marked as a duplicate of this bug. ***

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [Bug 217613] New: [BUG] [media] dvb-usb: possible data-inconsistency due to data races in dib0700_rc_query_old_firmware()
    2023-06-30  5:22 82% ` [Bug 217613] " bugzilla-daemon
@ 2023-06-30  5:22 82% ` Greg KH
  2023-06-30  8:11 82% ` [Bug 217613] " bugzilla-daemon
  2023-06-30  1:48 82% ` bugzilla-daemon
  3 siblings, 0 replies; 200+ results
From: Greg KH @ 2023-06-30  5:22 UTC (permalink / raw)
  To: bugzilla-daemon; +Cc: linux-usb

On Fri, Jun 30, 2023 at 01:35:28AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=217613
> 
>             Bug ID: 217613
>            Summary: [BUG] [media] dvb-usb: possible data-inconsistency due
>                     to data races in dib0700_rc_query_old_firmware()
>            Product: Drivers
>            Version: 2.5
>           Hardware: All
>                 OS: Linux
>             Status: NEW
>           Severity: normal
>           Priority: P3
>          Component: USB
>           Assignee: drivers_usb@kernel-bugs.kernel.org
>           Reporter: islituo@gmail.com
>         Regression: No
> 
> Our static analysis tool finds some possible data races in the
> DVB USB driver in Linux 6.4.0.

Please report this to the mailing lists for these drivers, not in
bugzilla.

thanks,

greg k-h

^ permalink raw reply	[relevance 82%]

* [Bug 217613] [BUG] [media] dvb-usb: possible data-inconsistency due to data races in dib0700_rc_query_old_firmware()
  @ 2023-06-30  5:22 82% ` bugzilla-daemon
  2023-06-30  5:22 82% ` [Bug 217613] New: " Greg KH
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-06-30  5:22 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217613

--- Comment #2 from Greg Kroah-Hartman (greg@kroah.com) ---
On Fri, Jun 30, 2023 at 01:35:28AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=217613
> 
>             Bug ID: 217613
>            Summary: [BUG] [media] dvb-usb: possible data-inconsistency due
>                     to data races in dib0700_rc_query_old_firmware()
>            Product: Drivers
>            Version: 2.5
>           Hardware: All
>                 OS: Linux
>             Status: NEW
>           Severity: normal
>           Priority: P3
>          Component: USB
>           Assignee: drivers_usb@kernel-bugs.kernel.org
>           Reporter: islituo@gmail.com
>         Regression: No
> 
> Our static analysis tool finds some possible data races in the
> DVB USB driver in Linux 6.4.0.

Please report this to the mailing lists for these drivers, not in
bugzilla.

thanks,

greg k-h

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 217613] [BUG] [media] dvb-usb: possible data-inconsistency due to data races in dib0700_rc_query_old_firmware()
    2023-06-30  5:22 82% ` [Bug 217613] " bugzilla-daemon
  2023-06-30  5:22 82% ` [Bug 217613] New: " Greg KH
@ 2023-06-30  8:11 82% ` bugzilla-daemon
  2023-06-30  1:48 82% ` bugzilla-daemon
  3 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-06-30  8:11 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217613

--- Comment #3 from Tuo Li (islituo@gmail.com) ---
(In reply to Greg Kroah-Hartman from comment #2)
> On Fri, Jun 30, 2023 at 01:35:28AM +0000, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=217613
> > 
> >             Bug ID: 217613
> >            Summary: [BUG] [media] dvb-usb: possible data-inconsistency due
> >                     to data races in dib0700_rc_query_old_firmware()
> >            Product: Drivers
> >            Version: 2.5
> >           Hardware: All
> >                 OS: Linux
> >             Status: NEW
> >           Severity: normal
> >           Priority: P3
> >          Component: USB
> >           Assignee: drivers_usb@kernel-bugs.kernel.org
> >           Reporter: islituo@gmail.com
> >         Regression: No
> > 
> > Our static analysis tool finds some possible data races in the
> > DVB USB driver in Linux 6.4.0.
> 
> Please report this to the mailing lists for these drivers, not in
> bugzilla.
> 
> thanks,
> 
> greg k-h

Thanks for your reply! I am really sorry to bother you. I have 
reported this to the mailing lists for these drivers, but have 
not received any reply.I have resent a report to the mailing lists
just now, and any feedback would be appreciated.

Thanks,
Tuo Li

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0
  @ 2023-07-07 16:46 82%       ` Hyeonggon Yoo
  0 siblings, 0 replies; 200+ results
From: Hyeonggon Yoo @ 2023-07-07 16:46 UTC (permalink / raw)
  To: David Howells
  Cc: Andrew Morton, Matthew Wilcox, Linus Torvalds, Jeff Layton,
	Christoph Hellwig, linux-afs, linux-nfs, linux-cifs, ceph-devel,
	v9fs-developer, linux-erofs, linux-ext4, linux-cachefs,
	linux-fsdevel, Rohith Surabattula, Steve French, Shyam Prasad N,
	Dave Wysochanski, Dominique Martinet, Ilya Dryomov, linux-mm

On Sat, Jul 8, 2023 at 1:39 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
>
> On Wed, Jun 28, 2023 at 11:48:52AM +0100, David Howells wrote:
> > Fscache has an optimisation by which reads from the cache are skipped until
> > we know that (a) there's data there to be read and (b) that data isn't
> > entirely covered by pages resident in the netfs pagecache.  This is done
> > with two flags manipulated by fscache_note_page_release():
> >
> >       if (...
> >           test_bit(FSCACHE_COOKIE_HAVE_DATA, &cookie->flags) &&
> >           test_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags))
> >               clear_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags);
> >
> > where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to indicate
> > that netfslib should download from the server or clear the page instead.
> >
> > The fscache_note_page_release() function is intended to be called from
> > ->releasepage() - but that only gets called if PG_private or PG_private_2
> > is set - and currently the former is at the discretion of the network
> > filesystem and the latter is only set whilst a page is being written to the
> > cache, so sometimes we miss clearing the optimisation.
> >
> > Fix this by following Willy's suggestion[1] and adding an address_space
> > flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to always call
> > ->release_folio() if it's set, even if PG_private or PG_private_2 aren't
> > set.
> >
> > Note that this would require folio_test_private() and page_has_private() to
> > become more complicated.  To avoid that, in the places[*] where these are
> > used to conditionalise calls to filemap_release_folio() and
> > try_to_release_page(), the tests are removed the those functions just
> > jumped to unconditionally and the test is performed there.
> >
> > [*] There are some exceptions in vmscan.c where the check guards more than
> > just a call to the releaser.  I've added a function, folio_needs_release()
> > to wrap all the checks for that.
> >
> > AS_RELEASE_ALWAYS should be set if a non-NULL cookie is obtained from
> > fscache and cleared in ->evict_inode() before truncate_inode_pages_final()
> > is called.
> >
> > Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be cleared
> > and the optimisation cancelled if a cachefiles object already contains data
> > when we open it.
> >
> > Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release of a page")
> > Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines")
> > Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
> > Suggested-by: Matthew Wilcox <willy@infradead.org>
> > Signed-off-by: David Howells <dhowells@redhat.com>
>
> Hi David,
>
> I was bisecting a use-after-free BUG on the latest mm-unstable,
> where HEAD is 347e208de0e4 ("rmap: pass the folio to __page_check_anon_rmap()").
>
> According to my bisection, this is the first bad commit.
> Use-After-Free is triggered on reclamation path when swap is enabled.

This was originally occurred during kernel compilation but
can easily be reproduced via:

stress-ng --bigheap $(nproc)

> (and couldn't trigger without swap enabled)
>
> the config, KASAN splat, bisect log are attached.
> hope this isn't too late :(
>
> > cc: Matthew Wilcox <willy@infradead.org>
> > cc: Linus Torvalds <torvalds@linux-foundation.org>
> > cc: Steve French <sfrench@samba.org>
> > cc: Shyam Prasad N <nspmangalore@gmail.com>
> > cc: Rohith Surabattula <rohiths.msft@gmail.com>
> > cc: Dave Wysochanski <dwysocha@redhat.com>
> > cc: Dominique Martinet <asmadeus@codewreck.org>
> > cc: Ilya Dryomov <idryomov@gmail.com>
> > cc: linux-cachefs@redhat.com
> > cc: linux-cifs@vger.kernel.org
> > cc: linux-afs@lists.infradead.org
> > cc: v9fs-developer@lists.sourceforge.net
> > cc: ceph-devel@vger.kernel.org
> > cc: linux-nfs@vger.kernel.org
> > cc: linux-fsdevel@vger.kernel.org
> > cc: linux-mm@kvack.org
> > ---
> >
> > Notes:
> >     ver #7)
> >      - Make NFS set AS_RELEASE_ALWAYS.
> >
> >     ver #4)
> >      - Split out merging of folio_has_private()/filemap_release_folio() call
> >        pairs into a preceding patch.
> >      - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode().
> >
> >     ver #3)
> >      - Fixed mapping_clear_release_always() to use clear_bit() not set_bit().
> >      - Moved a '&&' to the correct line.
> >
> >     ver #2)
> >      - Rewrote entirely according to Willy's suggestion[1].
> >
> >  fs/9p/cache.c           |  2 ++
> >  fs/afs/internal.h       |  2 ++
> >  fs/cachefiles/namei.c   |  2 ++
> >  fs/ceph/cache.c         |  2 ++
> >  fs/nfs/fscache.c        |  3 +++
> >  fs/smb/client/fscache.c |  2 ++
> >  include/linux/pagemap.h | 16 ++++++++++++++++
> >  mm/internal.h           |  5 ++++-
> >  8 files changed, 33 insertions(+), 1 deletion(-)

^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0
@ 2023-07-07 16:46 82%       ` Hyeonggon Yoo
  0 siblings, 0 replies; 200+ results
From: Hyeonggon Yoo @ 2023-07-07 16:46 UTC (permalink / raw)
  To: David Howells
  Cc: Shyam Prasad N, linux-cifs, linux-nfs, Ilya Dryomov, linux-mm,
	Rohith Surabattula, linux-erofs, Dave Wysochanski, Jeff Layton,
	Matthew Wilcox, Christoph Hellwig, Steve French, linux-cachefs,
	v9fs-developer, linux-fsdevel, ceph-devel, Andrew Morton,
	linux-ext4, Linus Torvalds, linux-afs, Dominique Martinet

On Sat, Jul 8, 2023 at 1:39 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
>
> On Wed, Jun 28, 2023 at 11:48:52AM +0100, David Howells wrote:
> > Fscache has an optimisation by which reads from the cache are skipped until
> > we know that (a) there's data there to be read and (b) that data isn't
> > entirely covered by pages resident in the netfs pagecache.  This is done
> > with two flags manipulated by fscache_note_page_release():
> >
> >       if (...
> >           test_bit(FSCACHE_COOKIE_HAVE_DATA, &cookie->flags) &&
> >           test_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags))
> >               clear_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags);
> >
> > where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to indicate
> > that netfslib should download from the server or clear the page instead.
> >
> > The fscache_note_page_release() function is intended to be called from
> > ->releasepage() - but that only gets called if PG_private or PG_private_2
> > is set - and currently the former is at the discretion of the network
> > filesystem and the latter is only set whilst a page is being written to the
> > cache, so sometimes we miss clearing the optimisation.
> >
> > Fix this by following Willy's suggestion[1] and adding an address_space
> > flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to always call
> > ->release_folio() if it's set, even if PG_private or PG_private_2 aren't
> > set.
> >
> > Note that this would require folio_test_private() and page_has_private() to
> > become more complicated.  To avoid that, in the places[*] where these are
> > used to conditionalise calls to filemap_release_folio() and
> > try_to_release_page(), the tests are removed the those functions just
> > jumped to unconditionally and the test is performed there.
> >
> > [*] There are some exceptions in vmscan.c where the check guards more than
> > just a call to the releaser.  I've added a function, folio_needs_release()
> > to wrap all the checks for that.
> >
> > AS_RELEASE_ALWAYS should be set if a non-NULL cookie is obtained from
> > fscache and cleared in ->evict_inode() before truncate_inode_pages_final()
> > is called.
> >
> > Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be cleared
> > and the optimisation cancelled if a cachefiles object already contains data
> > when we open it.
> >
> > Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release of a page")
> > Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines")
> > Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
> > Suggested-by: Matthew Wilcox <willy@infradead.org>
> > Signed-off-by: David Howells <dhowells@redhat.com>
>
> Hi David,
>
> I was bisecting a use-after-free BUG on the latest mm-unstable,
> where HEAD is 347e208de0e4 ("rmap: pass the folio to __page_check_anon_rmap()").
>
> According to my bisection, this is the first bad commit.
> Use-After-Free is triggered on reclamation path when swap is enabled.

This was originally occurred during kernel compilation but
can easily be reproduced via:

stress-ng --bigheap $(nproc)

> (and couldn't trigger without swap enabled)
>
> the config, KASAN splat, bisect log are attached.
> hope this isn't too late :(
>
> > cc: Matthew Wilcox <willy@infradead.org>
> > cc: Linus Torvalds <torvalds@linux-foundation.org>
> > cc: Steve French <sfrench@samba.org>
> > cc: Shyam Prasad N <nspmangalore@gmail.com>
> > cc: Rohith Surabattula <rohiths.msft@gmail.com>
> > cc: Dave Wysochanski <dwysocha@redhat.com>
> > cc: Dominique Martinet <asmadeus@codewreck.org>
> > cc: Ilya Dryomov <idryomov@gmail.com>
> > cc: linux-cachefs@redhat.com
> > cc: linux-cifs@vger.kernel.org
> > cc: linux-afs@lists.infradead.org
> > cc: v9fs-developer@lists.sourceforge.net
> > cc: ceph-devel@vger.kernel.org
> > cc: linux-nfs@vger.kernel.org
> > cc: linux-fsdevel@vger.kernel.org
> > cc: linux-mm@kvack.org
> > ---
> >
> > Notes:
> >     ver #7)
> >      - Make NFS set AS_RELEASE_ALWAYS.
> >
> >     ver #4)
> >      - Split out merging of folio_has_private()/filemap_release_folio() call
> >        pairs into a preceding patch.
> >      - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode().
> >
> >     ver #3)
> >      - Fixed mapping_clear_release_always() to use clear_bit() not set_bit().
> >      - Moved a '&&' to the correct line.
> >
> >     ver #2)
> >      - Rewrote entirely according to Willy's suggestion[1].
> >
> >  fs/9p/cache.c           |  2 ++
> >  fs/afs/internal.h       |  2 ++
> >  fs/cachefiles/namei.c   |  2 ++
> >  fs/ceph/cache.c         |  2 ++
> >  fs/nfs/fscache.c        |  3 +++
> >  fs/smb/client/fscache.c |  2 ++
> >  include/linux/pagemap.h | 16 ++++++++++++++++
> >  mm/internal.h           |  5 ++++-
> >  8 files changed, 33 insertions(+), 1 deletion(-)

^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0
  2023-07-07 16:46 82%       ` Hyeonggon Yoo
  (?)
@ 2023-07-07 18:12 82%       ` David Wysochanski
  2023-07-07 19:23 82%         ` SeongJae Park
  2023-07-07 18:27 82%           ` Hyeonggon Yoo
  -1 siblings, 2 replies; 200+ results
From: David Wysochanski @ 2023-07-07 18:12 UTC (permalink / raw)
  To: Hyeonggon Yoo
  Cc: Dominique Martinet, David Howells, linux-mm, linux-afs,
	Shyam Prasad N, linux-cifs, Matthew Wilcox, Christoph Hellwig,
	Linus Torvalds, linux-cachefs, v9fs-developer, Ilya Dryomov,
	linux-ext4, ceph-devel, linux-nfs, Rohith Surabattula,
	Daire Byrne, Jeff Layton, Steve French, linux-fsdevel,
	Andrew Morton, linux-erofs

On Fri, Jul 7, 2023 at 12:46 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
>
> On Sat, Jul 8, 2023 at 1:39 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> >
> > On Wed, Jun 28, 2023 at 11:48:52AM +0100, David Howells wrote:
> > > Fscache has an optimisation by which reads from the cache are skipped until
> > > we know that (a) there's data there to be read and (b) that data isn't
> > > entirely covered by pages resident in the netfs pagecache.  This is done
> > > with two flags manipulated by fscache_note_page_release():
> > >
> > >       if (...
> > >           test_bit(FSCACHE_COOKIE_HAVE_DATA, &cookie->flags) &&
> > >           test_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags))
> > >               clear_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags);
> > >
> > > where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to indicate
> > > that netfslib should download from the server or clear the page instead.
> > >
> > > The fscache_note_page_release() function is intended to be called from
> > > ->releasepage() - but that only gets called if PG_private or PG_private_2
> > > is set - and currently the former is at the discretion of the network
> > > filesystem and the latter is only set whilst a page is being written to the
> > > cache, so sometimes we miss clearing the optimisation.
> > >
> > > Fix this by following Willy's suggestion[1] and adding an address_space
> > > flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to always call
> > > ->release_folio() if it's set, even if PG_private or PG_private_2 aren't
> > > set.
> > >
> > > Note that this would require folio_test_private() and page_has_private() to
> > > become more complicated.  To avoid that, in the places[*] where these are
> > > used to conditionalise calls to filemap_release_folio() and
> > > try_to_release_page(), the tests are removed the those functions just
> > > jumped to unconditionally and the test is performed there.
> > >
> > > [*] There are some exceptions in vmscan.c where the check guards more than
> > > just a call to the releaser.  I've added a function, folio_needs_release()
> > > to wrap all the checks for that.
> > >
> > > AS_RELEASE_ALWAYS should be set if a non-NULL cookie is obtained from
> > > fscache and cleared in ->evict_inode() before truncate_inode_pages_final()
> > > is called.
> > >
> > > Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be cleared
> > > and the optimisation cancelled if a cachefiles object already contains data
> > > when we open it.
> > >
> > > Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release of a page")
> > > Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines")
> > > Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
> > > Suggested-by: Matthew Wilcox <willy@infradead.org>
> > > Signed-off-by: David Howells <dhowells@redhat.com>
> >
> > Hi David,
> >
> > I was bisecting a use-after-free BUG on the latest mm-unstable,
> > where HEAD is 347e208de0e4 ("rmap: pass the folio to __page_check_anon_rmap()").
> >
> > According to my bisection, this is the first bad commit.
> > Use-After-Free is triggered on reclamation path when swap is enabled.
>
> This was originally occurred during kernel compilation but
> can easily be reproduced via:
>
> stress-ng --bigheap $(nproc)
>
> > (and couldn't trigger without swap enabled)
> >
> > the config, KASAN splat, bisect log are attached.
> > hope this isn't too late :(
> >
> > > cc: Matthew Wilcox <willy@infradead.org>
> > > cc: Linus Torvalds <torvalds@linux-foundation.org>
> > > cc: Steve French <sfrench@samba.org>
> > > cc: Shyam Prasad N <nspmangalore@gmail.com>
> > > cc: Rohith Surabattula <rohiths.msft@gmail.com>
> > > cc: Dave Wysochanski <dwysocha@redhat.com>
> > > cc: Dominique Martinet <asmadeus@codewreck.org>
> > > cc: Ilya Dryomov <idryomov@gmail.com>
> > > cc: linux-cachefs@redhat.com
> > > cc: linux-cifs@vger.kernel.org
> > > cc: linux-afs@lists.infradead.org
> > > cc: v9fs-developer@lists.sourceforge.net
> > > cc: ceph-devel@vger.kernel.org
> > > cc: linux-nfs@vger.kernel.org
> > > cc: linux-fsdevel@vger.kernel.org
> > > cc: linux-mm@kvack.org
> > > ---
> > >
> > > Notes:
> > >     ver #7)
> > >      - Make NFS set AS_RELEASE_ALWAYS.
> > >
> > >     ver #4)
> > >      - Split out merging of folio_has_private()/filemap_release_folio() call
> > >        pairs into a preceding patch.
> > >      - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode().
> > >
> > >     ver #3)
> > >      - Fixed mapping_clear_release_always() to use clear_bit() not set_bit().
> > >      - Moved a '&&' to the correct line.
> > >
> > >     ver #2)
> > >      - Rewrote entirely according to Willy's suggestion[1].
> > >
> > >  fs/9p/cache.c           |  2 ++
> > >  fs/afs/internal.h       |  2 ++
> > >  fs/cachefiles/namei.c   |  2 ++
> > >  fs/ceph/cache.c         |  2 ++
> > >  fs/nfs/fscache.c        |  3 +++
> > >  fs/smb/client/fscache.c |  2 ++
> > >  include/linux/pagemap.h | 16 ++++++++++++++++
> > >  mm/internal.h           |  5 ++++-
> > >  8 files changed, 33 insertions(+), 1 deletion(-)


I think myself / Daire Byrne may have already tracked this down and I
found a 1-liner that fixed a similar crash in his environment.

Can you try this patch on top and let me know if it still crashes?
https://github.com/DaveWysochanskiRH/kernel/commit/902c990e311120179fa5de99d68364b2947b79ec


^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0
  2023-07-07 18:12 82%       ` David Wysochanski
@ 2023-07-07 18:27 82%           ` Hyeonggon Yoo
  2023-07-07 18:27 82%           ` Hyeonggon Yoo
  1 sibling, 0 replies; 200+ results
From: Hyeonggon Yoo @ 2023-07-07 18:27 UTC (permalink / raw)
  To: David Wysochanski
  Cc: David Howells, Andrew Morton, Matthew Wilcox, Linus Torvalds,
	Jeff Layton, Christoph Hellwig, linux-afs, linux-nfs, linux-cifs,
	ceph-devel, v9fs-developer, linux-erofs, linux-ext4,
	linux-cachefs, linux-fsdevel, Rohith Surabattula, Steve French,
	Shyam Prasad N, Dominique Martinet, Ilya Dryomov, linux-mm,
	Daire Byrne

On Fri, Jul 07, 2023 at 02:12:06PM -0400, David Wysochanski wrote:
> On Fri, Jul 7, 2023 at 12:46 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> >
> > On Sat, Jul 8, 2023 at 1:39 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> > >
> > > On Wed, Jun 28, 2023 at 11:48:52AM +0100, David Howells wrote:
> > > > Fscache has an optimisation by which reads from the cache are skipped until
> > > > we know that (a) there's data there to be read and (b) that data isn't
> > > > entirely covered by pages resident in the netfs pagecache.  This is done
> > > > with two flags manipulated by fscache_note_page_release():
> > > >
> > > >       if (...
> > > >           test_bit(FSCACHE_COOKIE_HAVE_DATA, &cookie->flags) &&
> > > >           test_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags))
> > > >               clear_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags);
> > > >
> > > > where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to indicate
> > > > that netfslib should download from the server or clear the page instead.
> > > >
> > > > The fscache_note_page_release() function is intended to be called from
> > > > ->releasepage() - but that only gets called if PG_private or PG_private_2
> > > > is set - and currently the former is at the discretion of the network
> > > > filesystem and the latter is only set whilst a page is being written to the
> > > > cache, so sometimes we miss clearing the optimisation.
> > > >
> > > > Fix this by following Willy's suggestion[1] and adding an address_space
> > > > flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to always call
> > > > ->release_folio() if it's set, even if PG_private or PG_private_2 aren't
> > > > set.
> > > >
> > > > Note that this would require folio_test_private() and page_has_private() to
> > > > become more complicated.  To avoid that, in the places[*] where these are
> > > > used to conditionalise calls to filemap_release_folio() and
> > > > try_to_release_page(), the tests are removed the those functions just
> > > > jumped to unconditionally and the test is performed there.
> > > >
> > > > [*] There are some exceptions in vmscan.c where the check guards more than
> > > > just a call to the releaser.  I've added a function, folio_needs_release()
> > > > to wrap all the checks for that.
> > > >
> > > > AS_RELEASE_ALWAYS should be set if a non-NULL cookie is obtained from
> > > > fscache and cleared in ->evict_inode() before truncate_inode_pages_final()
> > > > is called.
> > > >
> > > > Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be cleared
> > > > and the optimisation cancelled if a cachefiles object already contains data
> > > > when we open it.
> > > >
> > > > Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release of a page")
> > > > Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines")
> > > > Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
> > > > Suggested-by: Matthew Wilcox <willy@infradead.org>
> > > > Signed-off-by: David Howells <dhowells@redhat.com>
> > >
> > > Hi David,
> > >
> > > I was bisecting a use-after-free BUG on the latest mm-unstable,
> > > where HEAD is 347e208de0e4 ("rmap: pass the folio to __page_check_anon_rmap()").
> > >
> > > According to my bisection, this is the first bad commit.
> > > Use-After-Free is triggered on reclamation path when swap is enabled.
> >
> > This was originally occurred during kernel compilation but
> > can easily be reproduced via:
> >
> > stress-ng --bigheap $(nproc)
> >
> > > (and couldn't trigger without swap enabled)
> > >
> > > the config, KASAN splat, bisect log are attached.
> > > hope this isn't too late :(
> > >
> > > > cc: Matthew Wilcox <willy@infradead.org>
> > > > cc: Linus Torvalds <torvalds@linux-foundation.org>
> > > > cc: Steve French <sfrench@samba.org>
> > > > cc: Shyam Prasad N <nspmangalore@gmail.com>
> > > > cc: Rohith Surabattula <rohiths.msft@gmail.com>
> > > > cc: Dave Wysochanski <dwysocha@redhat.com>
> > > > cc: Dominique Martinet <asmadeus@codewreck.org>
> > > > cc: Ilya Dryomov <idryomov@gmail.com>
> > > > cc: linux-cachefs@redhat.com
> > > > cc: linux-cifs@vger.kernel.org
> > > > cc: linux-afs@lists.infradead.org
> > > > cc: v9fs-developer@lists.sourceforge.net
> > > > cc: ceph-devel@vger.kernel.org
> > > > cc: linux-nfs@vger.kernel.org
> > > > cc: linux-fsdevel@vger.kernel.org
> > > > cc: linux-mm@kvack.org
> > > > ---
> > > >
> > > > Notes:
> > > >     ver #7)
> > > >      - Make NFS set AS_RELEASE_ALWAYS.
> > > >
> > > >     ver #4)
> > > >      - Split out merging of folio_has_private()/filemap_release_folio() call
> > > >        pairs into a preceding patch.
> > > >      - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode().
> > > >
> > > >     ver #3)
> > > >      - Fixed mapping_clear_release_always() to use clear_bit() not set_bit().
> > > >      - Moved a '&&' to the correct line.
> > > >
> > > >     ver #2)
> > > >      - Rewrote entirely according to Willy's suggestion[1].
> > > >
> > > >  fs/9p/cache.c           |  2 ++
> > > >  fs/afs/internal.h       |  2 ++
> > > >  fs/cachefiles/namei.c   |  2 ++
> > > >  fs/ceph/cache.c         |  2 ++
> > > >  fs/nfs/fscache.c        |  3 +++
> > > >  fs/smb/client/fscache.c |  2 ++
> > > >  include/linux/pagemap.h | 16 ++++++++++++++++
> > > >  mm/internal.h           |  5 ++++-
> > > >  8 files changed, 33 insertions(+), 1 deletion(-)
> 
> 
> I think myself / Daire Byrne may have already tracked this down and I
> found a 1-liner that fixed a similar crash in his environment.
> 
> Can you try this patch on top and let me know if it still crashes?
> https://github.com/DaveWysochanskiRH/kernel/commit/902c990e311120179fa5de99d68364b2947b79ec

Oh, it does not crash with the patch applied.

Hmm, was it UAF because it references wrong field ->mapping,
instead of swapper address space?


^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0
@ 2023-07-07 18:27 82%           ` Hyeonggon Yoo
  0 siblings, 0 replies; 200+ results
From: Hyeonggon Yoo @ 2023-07-07 18:27 UTC (permalink / raw)
  To: David Wysochanski
  Cc: Dominique Martinet, David Howells, linux-mm, linux-afs,
	Shyam Prasad N, linux-cifs, Matthew Wilcox, Christoph Hellwig,
	Linus Torvalds, linux-cachefs, v9fs-developer, Ilya Dryomov,
	linux-ext4, ceph-devel, linux-nfs, Rohith Surabattula,
	Daire Byrne, Jeff Layton, Steve French, linux-fsdevel,
	Andrew Morton, linux-erofs

On Fri, Jul 07, 2023 at 02:12:06PM -0400, David Wysochanski wrote:
> On Fri, Jul 7, 2023 at 12:46 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> >
> > On Sat, Jul 8, 2023 at 1:39 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> > >
> > > On Wed, Jun 28, 2023 at 11:48:52AM +0100, David Howells wrote:
> > > > Fscache has an optimisation by which reads from the cache are skipped until
> > > > we know that (a) there's data there to be read and (b) that data isn't
> > > > entirely covered by pages resident in the netfs pagecache.  This is done
> > > > with two flags manipulated by fscache_note_page_release():
> > > >
> > > >       if (...
> > > >           test_bit(FSCACHE_COOKIE_HAVE_DATA, &cookie->flags) &&
> > > >           test_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags))
> > > >               clear_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags);
> > > >
> > > > where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to indicate
> > > > that netfslib should download from the server or clear the page instead.
> > > >
> > > > The fscache_note_page_release() function is intended to be called from
> > > > ->releasepage() - but that only gets called if PG_private or PG_private_2
> > > > is set - and currently the former is at the discretion of the network
> > > > filesystem and the latter is only set whilst a page is being written to the
> > > > cache, so sometimes we miss clearing the optimisation.
> > > >
> > > > Fix this by following Willy's suggestion[1] and adding an address_space
> > > > flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to always call
> > > > ->release_folio() if it's set, even if PG_private or PG_private_2 aren't
> > > > set.
> > > >
> > > > Note that this would require folio_test_private() and page_has_private() to
> > > > become more complicated.  To avoid that, in the places[*] where these are
> > > > used to conditionalise calls to filemap_release_folio() and
> > > > try_to_release_page(), the tests are removed the those functions just
> > > > jumped to unconditionally and the test is performed there.
> > > >
> > > > [*] There are some exceptions in vmscan.c where the check guards more than
> > > > just a call to the releaser.  I've added a function, folio_needs_release()
> > > > to wrap all the checks for that.
> > > >
> > > > AS_RELEASE_ALWAYS should be set if a non-NULL cookie is obtained from
> > > > fscache and cleared in ->evict_inode() before truncate_inode_pages_final()
> > > > is called.
> > > >
> > > > Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be cleared
> > > > and the optimisation cancelled if a cachefiles object already contains data
> > > > when we open it.
> > > >
> > > > Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release of a page")
> > > > Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines")
> > > > Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
> > > > Suggested-by: Matthew Wilcox <willy@infradead.org>
> > > > Signed-off-by: David Howells <dhowells@redhat.com>
> > >
> > > Hi David,
> > >
> > > I was bisecting a use-after-free BUG on the latest mm-unstable,
> > > where HEAD is 347e208de0e4 ("rmap: pass the folio to __page_check_anon_rmap()").
> > >
> > > According to my bisection, this is the first bad commit.
> > > Use-After-Free is triggered on reclamation path when swap is enabled.
> >
> > This was originally occurred during kernel compilation but
> > can easily be reproduced via:
> >
> > stress-ng --bigheap $(nproc)
> >
> > > (and couldn't trigger without swap enabled)
> > >
> > > the config, KASAN splat, bisect log are attached.
> > > hope this isn't too late :(
> > >
> > > > cc: Matthew Wilcox <willy@infradead.org>
> > > > cc: Linus Torvalds <torvalds@linux-foundation.org>
> > > > cc: Steve French <sfrench@samba.org>
> > > > cc: Shyam Prasad N <nspmangalore@gmail.com>
> > > > cc: Rohith Surabattula <rohiths.msft@gmail.com>
> > > > cc: Dave Wysochanski <dwysocha@redhat.com>
> > > > cc: Dominique Martinet <asmadeus@codewreck.org>
> > > > cc: Ilya Dryomov <idryomov@gmail.com>
> > > > cc: linux-cachefs@redhat.com
> > > > cc: linux-cifs@vger.kernel.org
> > > > cc: linux-afs@lists.infradead.org
> > > > cc: v9fs-developer@lists.sourceforge.net
> > > > cc: ceph-devel@vger.kernel.org
> > > > cc: linux-nfs@vger.kernel.org
> > > > cc: linux-fsdevel@vger.kernel.org
> > > > cc: linux-mm@kvack.org
> > > > ---
> > > >
> > > > Notes:
> > > >     ver #7)
> > > >      - Make NFS set AS_RELEASE_ALWAYS.
> > > >
> > > >     ver #4)
> > > >      - Split out merging of folio_has_private()/filemap_release_folio() call
> > > >        pairs into a preceding patch.
> > > >      - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode().
> > > >
> > > >     ver #3)
> > > >      - Fixed mapping_clear_release_always() to use clear_bit() not set_bit().
> > > >      - Moved a '&&' to the correct line.
> > > >
> > > >     ver #2)
> > > >      - Rewrote entirely according to Willy's suggestion[1].
> > > >
> > > >  fs/9p/cache.c           |  2 ++
> > > >  fs/afs/internal.h       |  2 ++
> > > >  fs/cachefiles/namei.c   |  2 ++
> > > >  fs/ceph/cache.c         |  2 ++
> > > >  fs/nfs/fscache.c        |  3 +++
> > > >  fs/smb/client/fscache.c |  2 ++
> > > >  include/linux/pagemap.h | 16 ++++++++++++++++
> > > >  mm/internal.h           |  5 ++++-
> > > >  8 files changed, 33 insertions(+), 1 deletion(-)
> 
> 
> I think myself / Daire Byrne may have already tracked this down and I
> found a 1-liner that fixed a similar crash in his environment.
> 
> Can you try this patch on top and let me know if it still crashes?
> https://github.com/DaveWysochanskiRH/kernel/commit/902c990e311120179fa5de99d68364b2947b79ec

Oh, it does not crash with the patch applied.

Hmm, was it UAF because it references wrong field ->mapping,
instead of swapper address space?


^ permalink raw reply	[relevance 82%]

* Re: [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0
  2023-07-07 18:12 82%       ` David Wysochanski
@ 2023-07-07 19:23 82%         ` SeongJae Park
  2023-07-07 18:27 82%           ` Hyeonggon Yoo
  1 sibling, 0 replies; 200+ results
From: SeongJae Park @ 2023-07-07 19:23 UTC (permalink / raw)
  To: David Wysochanski
  Cc: Dominique Martinet, David Howells, linux-mm, Hyeonggon Yoo,
	linux-afs, Shyam Prasad N, linux-cifs, Matthew Wilcox,
	Christoph Hellwig, linux-cachefs, v9fs-developer, Ilya Dryomov,
	linux-ext4, ceph-devel, linux-nfs, SeongJae Park,
	Rohith Surabattula, Linus Torvalds, Jeff Layton, Steve French,
	Daire Byrne, linux-fsdevel, Andrew Morton, linux-erofs

On Fri, 7 Jul 2023 14:12:06 -0400 David Wysochanski <dwysocha@redhat.com> wrote:

> On Fri, Jul 7, 2023 at 12:46 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> >
> > On Sat, Jul 8, 2023 at 1:39 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
> > >
> > > On Wed, Jun 28, 2023 at 11:48:52AM +0100, David Howells wrote:
> > > > Fscache has an optimisation by which reads from the cache are skipped until
> > > > we know that (a) there's data there to be read and (b) that data isn't
> > > > entirely covered by pages resident in the netfs pagecache.  This is done
> > > > with two flags manipulated by fscache_note_page_release():
> > > >
> > > >       if (...
> > > >           test_bit(FSCACHE_COOKIE_HAVE_DATA, &cookie->flags) &&
> > > >           test_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags))
> > > >               clear_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags);
> > > >
> > > > where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to indicate
> > > > that netfslib should download from the server or clear the page instead.
> > > >
> > > > The fscache_note_page_release() function is intended to be called from
> > > > ->releasepage() - but that only gets called if PG_private or PG_private_2
> > > > is set - and currently the former is at the discretion of the network
> > > > filesystem and the latter is only set whilst a page is being written to the
> > > > cache, so sometimes we miss clearing the optimisation.
> > > >
> > > > Fix this by following Willy's suggestion[1] and adding an address_space
> > > > flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to always call
> > > > ->release_folio() if it's set, even if PG_private or PG_private_2 aren't
> > > > set.
> > > >
> > > > Note that this would require folio_test_private() and page_has_private() to
> > > > become more complicated.  To avoid that, in the places[*] where these are
> > > > used to conditionalise calls to filemap_release_folio() and
> > > > try_to_release_page(), the tests are removed the those functions just
> > > > jumped to unconditionally and the test is performed there.
> > > >
> > > > [*] There are some exceptions in vmscan.c where the check guards more than
> > > > just a call to the releaser.  I've added a function, folio_needs_release()
> > > > to wrap all the checks for that.
> > > >
> > > > AS_RELEASE_ALWAYS should be set if a non-NULL cookie is obtained from
> > > > fscache and cleared in ->evict_inode() before truncate_inode_pages_final()
> > > > is called.
> > > >
> > > > Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be cleared
> > > > and the optimisation cancelled if a cachefiles object already contains data
> > > > when we open it.
> > > >
> > > > Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release of a page")
> > > > Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines")
> > > > Reported-by: Rohith Surabattula <rohiths.msft@gmail.com>
> > > > Suggested-by: Matthew Wilcox <willy@infradead.org>
> > > > Signed-off-by: David Howells <dhowells@redhat.com>
> > >
> > > Hi David,
> > >
> > > I was bisecting a use-after-free BUG on the latest mm-unstable,
> > > where HEAD is 347e208de0e4 ("rmap: pass the folio to __page_check_anon_rmap()").
> > >
> > > According to my bisection, this is the first bad commit.
> > > Use-After-Free is triggered on reclamation path when swap is enabled.
> >
> > This was originally occurred during kernel compilation but
> > can easily be reproduced via:
> >
> > stress-ng --bigheap $(nproc)
> >
> > > (and couldn't trigger without swap enabled)
> > >
> > > the config, KASAN splat, bisect log are attached.
> > > hope this isn't too late :(
> > >
> > > > cc: Matthew Wilcox <willy@infradead.org>
> > > > cc: Linus Torvalds <torvalds@linux-foundation.org>
> > > > cc: Steve French <sfrench@samba.org>
> > > > cc: Shyam Prasad N <nspmangalore@gmail.com>
> > > > cc: Rohith Surabattula <rohiths.msft@gmail.com>
> > > > cc: Dave Wysochanski <dwysocha@redhat.com>
> > > > cc: Dominique Martinet <asmadeus@codewreck.org>
> > > > cc: Ilya Dryomov <idryomov@gmail.com>
> > > > cc: linux-cachefs@redhat.com
> > > > cc: linux-cifs@vger.kernel.org
> > > > cc: linux-afs@lists.infradead.org
> > > > cc: v9fs-developer@lists.sourceforge.net
> > > > cc: ceph-devel@vger.kernel.org
> > > > cc: linux-nfs@vger.kernel.org
> > > > cc: linux-fsdevel@vger.kernel.org
> > > > cc: linux-mm@kvack.org
> > > > ---
> > > >
> > > > Notes:
> > > >     ver #7)
> > > >      - Make NFS set AS_RELEASE_ALWAYS.
> > > >
> > > >     ver #4)
> > > >      - Split out merging of folio_has_private()/filemap_release_folio() call
> > > >        pairs into a preceding patch.
> > > >      - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode().
> > > >
> > > >     ver #3)
> > > >      - Fixed mapping_clear_release_always() to use clear_bit() not set_bit().
> > > >      - Moved a '&&' to the correct line.
> > > >
> > > >     ver #2)
> > > >      - Rewrote entirely according to Willy's suggestion[1].
> > > >
> > > >  fs/9p/cache.c           |  2 ++
> > > >  fs/afs/internal.h       |  2 ++
> > > >  fs/cachefiles/namei.c   |  2 ++
> > > >  fs/ceph/cache.c         |  2 ++
> > > >  fs/nfs/fscache.c        |  3 +++
> > > >  fs/smb/client/fscache.c |  2 ++
> > > >  include/linux/pagemap.h | 16 ++++++++++++++++
> > > >  mm/internal.h           |  5 ++++-
> > > >  8 files changed, 33 insertions(+), 1 deletion(-)
> 
> 
> I think myself / Daire Byrne may have already tracked this down and I
> found a 1-liner that fixed a similar crash in his environment.
> 
> Can you try this patch on top and let me know if it still crashes?
> https://github.com/DaveWysochanskiRH/kernel/commit/902c990e311120179fa5de99d68364b2947b79ec

I also encountered this issue with my DAMON tests, and was trying to find a
time slot for deep dive.  And I confirmed your fix works.  Thank you for this
great work.  Please Cc me when you post the patch if possible.

Tested-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

> 
> 

^ permalink raw reply	[relevance 82%]

* Re: Bug#1042753: nouveau bug in linux/6.1.38-2
    2023-08-04 13:38 82%       ` Diederik de Haas
@ 2023-08-04 13:38 82%       ` Diederik de Haas
  0 siblings, 0 replies; 200+ results
From: Diederik de Haas @ 2023-08-04 13:38 UTC (permalink / raw)
  To: Karol Herbst, Thorsten Leemhuis, Olaf Skibbe
  Cc: dri-devel, nouveau, 1042753, Ben Skeggs, Lyude Paul,
	Linux kernel regressions list, stable@vger.kernel.org

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Friday, 4 August 2023 15:11:46 CEST Olaf Skibbe wrote:
> (On the occasion a maybe silly question: am I right assuming that the
> kernel has to be build on the machine we want to reproduce the bug on?
> Otherwise it could use much faster hardware (running also bookworm).)

If that is also an amd64 machine running Debian kernel 6.1.38-2, it should be 
fine to build the kernel on the faster machine.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: Bug#1042753: nouveau bug in linux/6.1.38-2
@ 2023-08-04 13:38 82%       ` Diederik de Haas
  0 siblings, 0 replies; 200+ results
From: Diederik de Haas @ 2023-08-04 13:38 UTC (permalink / raw)
  To: Karol Herbst, Thorsten Leemhuis, Olaf Skibbe
  Cc: Linux kernel regressions list, nouveau, 1042753, dri-devel,
	Ben Skeggs, stable@vger.kernel.org

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Friday, 4 August 2023 15:11:46 CEST Olaf Skibbe wrote:
> (On the occasion a maybe silly question: am I right assuming that the
> kernel has to be build on the machine we want to reproduce the bug on?
> Otherwise it could use much faster hardware (running also bookworm).)

If that is also an amd64 machine running Debian kernel 6.1.38-2, it should be 
fine to build the kernel on the faster machine.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: [BUG]Bluetooth: possible semantic bug when the status field of the HCI_Connection_Complete packet set to non-zero
       [not found]     <ed32aad7-41c0-c84d-c1f3-085a4d43ce09@buaa.edu.cn>
@ 2023-08-07 17:22 82% ` Jakub Kicinski
  0 siblings, 0 replies; 200+ results
From: Jakub Kicinski @ 2023-08-07 17:22 UTC (permalink / raw)
  To: Xinyu Liu
  Cc: marcel, johan.hedberg, luiz.dentz, davem, edumazet, pabeni,
	baijiaju1990, sy2239101, linux-bluetooth, linux-kernel, netdev

On Sat, 5 Aug 2023 12:35:25 +0800 Xinyu Liu wrote:
> Our fuzzing tool finds a possible semantic bug in the Bluetooth system 
> in Linux 6.2

Sorry this is independent from your report.
Why are you fuzzing 6.2? It's end of life. Even 6.3 is at this point.
Please use latest kernels in your testing.

^ permalink raw reply	[relevance 82%]

* Re: [BUG]Bluetooth: possible semantic bug when the status field of the HCI_Connection_Complete packet set to non-zero
  @ 2023-08-09 15:10 82% ` Xin-Yu Liu
  0 siblings, 0 replies; 200+ results
From: Xin-Yu Liu @ 2023-08-09 15:10 UTC (permalink / raw)
  To: Luiz Augusto von Dentz
  Cc: marcel, johan.hedberg, davem, edumazet, kuba, pabeni,
	baijiaju1990, sy2239101, linux-bluetooth, linux-kernel, netdev

Hi,

Thanks for your reply.

After carefully considering your feedback, we now realize that the scenario we were assuming is indeed quite exceptional. It has become clear that there is no necessity for any supplementary mechanisms to reset the Bluetooth system. In our forthcoming work, we plan to engage in an in-depth exploration of the spec and Linux Bluetooth source code, with the aim of deriving more valuable insights and outcomes.

Once again, thank you for your active engagement and for taking the time to address our queries. Your assistance has been instrumental in guiding our approach.

Wishing you all the best and looking forward to future interactions.

Warm regards,
Xin-Yu Liu

2023/8/8 1:48, Luiz Augusto von Dentz :
> Hi,
>
> On Mon, Aug 7, 2023 at 8:17 AM Xin-Yu Liu <LXYbhu@buaa.edu.cn> wrote:
>> Hello,
>>
>> Thanks for your reply.
>>
>> I apologize for my previous unclear statement, which may have misled you.
>>
>> Let me rephrase our question:
>>
>> When a Bluetooth device initiates a connection to another device, its host sends an HCI_Create_Connection command (OGF: 0x01, OCF: 0x0005) to the controller. Once the connection is established, the controller sends an HCI_Connection_Complete event (Event Code: 0x03) back to the host. If a valid HCI_Connection_Complete event has its parameter "Status" altered (with all other parameters unchanged), changing 0x00 to any value between 0x01 and 0xFF for example, the host will considerd that the connection fails to complete.
>>
>> In reality, if the HCI_Connection_Complete event's parameter "Connection_Handle" is valid and unaltered, it means the handle resource exists and has not been released. The observations we made support this statement:
>>
> Well according to the spec we can only assume the handle is valid if
> the status is set to 0x00, so I am not really sure how we can possibly
> check if the handle is valid if the status indicates a connection
> failure?
>
>> (a) When the tampered HCI_Connection_Complete event with altered "Status" is sent to the host, if we attempt to reconnect to the same device by sending another HCI_Create_Connection command, the controller will send an HCI_Command_Status event (Event Code: 0x0F) to the host, with the "Status" parameter set to 0x0B, indicating "CONNECTION ALREADY EXISTS" and leading to the connection failure.
>>
>> (b) When the tampered HCI_Connection_Complete event is sent to the host, if we manually send an HCI_Disconnect command, with the "Connection_Handle" parameter set to the same value as the previous HCI_Connection_Complete event's "Connection_Handle," and the "Reason" parameter set to 0x15, indicating "REMOTE DEVICE TERMINATED CONNECTION DUE TO POWER OFF," we receive a proper response, signifying that the Connection_Handle is valid and exists. Additionally, the issue described in (a) disappears.
> Just read again the sentence above: 'TERMINATED CONNECTION', it can't
> possible mean the handle is valid and exists, I'm afraid you are
> arguing based on a controller implementation that doesn't comply with
> the spec text above, it shall either disconnect the link so we
> invalidate the handle on the host, then later we can reconnect, or
> indicate the status is 0x00.
>
>> Well we can't do much about the dangling connection if we don't know
>> its handle to be able to disconnect since there is no command to
>> disconnect by address if that is what you were expecting us to do, so
>> the bottom line seems to be that sending 0x0b to the controller is
>> useless since we can't do anything about at the host, well other than
>> reset but would likely affect other functionality as well.
>>
>> With knowledge of the handle, we think we can manually send an HCI_Disconnect command to deal with the dangling connection, just as we mentioned in (b).
> Assuming the handle is valid on status != 0x00 would probably not work
> with most controllers following the spec to the letter, in which case
> the HCI_Disconnect would fail and in the meantime we have an hci_conn
> with invalid state, so I don't think it is worth going sideways just
> to get it working under special circumstances, where this special
> circumstances might be a bug in the way status is used.
>
>> We believe that, in the situation we mentioned, the handle is valid but is rendered useless. Implementing an automated mechanism to handle the release of the handle (e.g., by sending an HCI_Disconnect command) might be a better choice.
> Sorry but I have to disagree, in that case HCI_Disconnect would need
> to be sent every time, which can also fail if the link-layer had
> terminated the connection as indicated in the status.
>
>> Best wishes,
>> Xin-Yu Liu
>>
>> 2023/8/5 13:09, Luiz Augusto von Dentz :
>>
>> Hi,
>>
>> On Fri, Aug 4, 2023 at 9:35 PM Xinyu Liu <LXYbhu@buaa.edu.cn> wrote:
>>
>> Hello,
>>
>> Our fuzzing tool finds a possible semantic bug in the Bluetooth system in Linux 6.2:
>>
>> During the connection process, the host server needs to receive the HCI_Connection_Complete packet from the hardware controller. In normal cases, the status field of this packet is zero, which means that the connection is successfully completed:
>>
>> However, in our testing, when the status field was set to non-zero, 47 for instance, the Bluetooth connection failed. After that, when we attempt to reestablish a Bluetooth connection, the connection always fails. Upon analyzing the event packets sent from the controller to the host server, we observed that the Status field of the HCI_Command_Status packet becomes 0B, indicating that the controller believes the connection already exists. This situation has been causing the connection failure persistently:
>>
>> That seems like a link-layer issue, the controller is saying the
>> connection had failed, and 0x0b also doesn't help either except if you
>> are saying that the other parameters are actually valid (e.g. handle),
>> that said the spec seems pretty clear about status other than 0x00
>> means the connection had failed:
>>
>> BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E
>> page 2170
>>
>> 0x01 to 0xFF Connection failed to Complete. See [Vol 1] Part F,
>> Controller Error Codes
>> for a list of error codes and descriptions.
>>
>> In our understanding, it would be more preferable if a single failed Bluetooth connection does not result in subsequent connections also failing. We believe that having some mechanism to facilitate Bluetooth's recovery and restoration to normal functionality could be considered as a potentially better option.
>>
>> We are not sure whether this is a semantic bug or implementation feature in the Linux kernel. Any feedback would be appreciated, thanks!
>>
>> Well we can't do much about the dangling connection if we don't know
>> its handle to be able to disconnect since there is no command to
>> disconnect by address if that is what you were expecting us to do, so
>> the bottom line seems to be that sending 0x0b to the controller is
>> useless since we can't do anything about at the host, well other than
>> reset but would likely affect other functionality as well.
>>
>>
>


^ permalink raw reply	[relevance 82%]

* Re: [Nouveau] Bug#1042753: nouveau bug in linux/6.1.38-2
@ 2023-08-04 13:38 82%       ` Diederik de Haas
  0 siblings, 0 replies; 200+ results
From: Diederik de Haas @ 2023-08-04 13:38 UTC (permalink / raw)
  To: Karol Herbst, Thorsten Leemhuis, Olaf Skibbe
  Cc: Linux kernel regressions list, nouveau, 1042753, dri-devel,
	Ben Skeggs, stable@vger.kernel.org

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Friday, 4 August 2023 15:11:46 CEST Olaf Skibbe wrote:
> (On the occasion a maybe silly question: am I right assuming that the
> kernel has to be build on the machine we want to reproduce the bug on?
> Otherwise it could use much faster hardware (running also bookworm).)

If that is also an amd64 machine running Debian kernel 6.1.38-2, it should be 
fine to build the kernel on the faster machine.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[relevance 82%]

* Re: [BUG]Bluetooth: HCI_Connection_Complete: possible semantic bug when HCI_Connection_Complete is discarded
       [not found]     <869240bf-7f91-4131-b56a-7ac2585dee4e@buaa.edu.cn>
@ 2023-08-15 17:53 82% ` Luiz Augusto von Dentz
  0 siblings, 0 replies; 200+ results
From: Luiz Augusto von Dentz @ 2023-08-15 17:53 UTC (permalink / raw)
  To: Xin-Yu Liu
  Cc: marcel, johan.hedberg, davem, edumazet, kuba, pabeni,
	baijiaju1990, sy2239101, linux-bluetooth, linux-kernel, netdev

Hi,

On Tue, Aug 15, 2023 at 6:56 AM Xin-Yu Liu <LXYbhu@buaa.edu.cn> wrote:
>
> Hello,
>
> Our fuzzing tool finds a possible semantic bug in the Bluetooth system in Linux 6.2:
>
> According to the core specification v5.4, when connecting to a remote device, the Host sends an HCI_Create_Connection command to the Controller, and upon successful execution of this command, the Host receives an HCI_Connection_Complete event:
>
>
>
> In our testing, if the HCI_Connection_Complete event is discarded and not received by the Host, it will result in a connection failure. Subsequently, when attempting to reconnect to the same device, the Host does not send an HCI_Create_Connection command, but instead sends a Create Connection Cancel command and receives the corresponding HCI_Command_Complete event. However, the connection still fails. Performing the same steps after some time yields the same result:
>
>
>
> We are inclined to consider the possibility of occasional HCI event loss, and it is reasonable to expect Bluetooth to incorporate some solution for managing packet loss or implementing a timeout mechanism. However, based on our testing observations, the loss of an HCI_Connection_Complete event during a connection attempt appears to lead to subsequent connection failures, which could potentially be seen as less than optimal. There could be corresponding remedies to address this issue; for instance, implementing a timeout mechanism might be a more favorable option.

There is already a command timeout in place, as for packet loss that
should be handled by the underline driver as it depends on how
reliable the transport is. If you are saying the connection
cancel/abort logic does prevent new connection with the same peer that
would be a bug, that said if the attempts are concurrent, within the
command timeout, then the same hci_conn would be used as there should
be only 1 ACL at time for a given peer.

> We are not sure whether this is a semantic bug or implementation feature in the Linux kernel. Any feedback would be appreciated, thanks!
>
> Best wishes,
> Xinyu Liu



-- 
Luiz Augusto von Dentz

^ permalink raw reply	[relevance 82%]

* [Bug 217862] [BUG] Alauda driver causes oops when inserted with card in with transfer buffer is on stack, throws errors if card is inserted afterwards.
  @ 2023-09-02  1:05 82% ` bugzilla-daemon
  2023-09-05 16:16 82% ` bugzilla-daemon
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-09-02  1:05 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217862

--- Comment #1 from pawlick3r@proton.me ---
Created attachment 305022
  --> https://bugzilla.kernel.org/attachment.cgi?id=305022&action=edit
dmesg error from the card reader

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 217862] [BUG] Alauda driver causes oops when inserted with card in with transfer buffer is on stack, throws errors if card is inserted afterwards.
                     ` (3 preceding siblings ...)
  2023-09-03 16:09 82% ` bugzilla-daemon
@ 2023-09-02  2:49 82% ` bugzilla-daemon
  4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-09-02  2:49 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217862

--- Comment #2 from Alan Stern (stern@rowland.harvard.edu) ---
Please try this again after applying the commit in

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?id=a6ff6e7a9dd69364547751db0f626a10a6d628d2

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 217862] [BUG] Alauda driver causes oops when inserted with card in with transfer buffer is on stack, throws errors if card is inserted afterwards.
                     ` (2 preceding siblings ...)
  2023-09-05  0:46 82% ` bugzilla-daemon
@ 2023-09-03 16:09 82% ` bugzilla-daemon
  2023-09-02  2:49 82% ` bugzilla-daemon
  4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-09-03 16:09 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217862

--- Comment #4 from Alan Stern (stern@rowland.harvard.edu) ---
Created attachment 305027
  --> https://bugzilla.kernel.org/attachment.cgi?id=305027&action=edit
Fix IO buffer on stack in alauda subdriver

Try the attached patch.  It should fix all the other instances of I/O done to a
buffer on the stack in the alauda driver.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 217862] [BUG] Alauda driver causes oops when inserted with card in with transfer buffer is on stack, throws errors if card is inserted afterwards.
    2023-09-02  1:05 82% ` [Bug 217862] " bugzilla-daemon
  2023-09-05 16:16 82% ` bugzilla-daemon
@ 2023-09-05  0:46 82% ` bugzilla-daemon
  2023-09-03 16:09 82% ` bugzilla-daemon
  2023-09-02  2:49 82% ` bugzilla-daemon
  4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-09-05  0:46 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217862

--- Comment #6 from Alan Stern (stern@rowland.harvard.edu) ---
There really isn't enough information in that crash report to tell what's going
wrong.  Can you rebuild the driver with CONFIG_USB_DEBUG turned on and run the
test again?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

* [Bug 217862] [BUG] Alauda driver causes oops when inserted with card in with transfer buffer is on stack, throws errors if card is inserted afterwards.
    2023-09-02  1:05 82% ` [Bug 217862] " bugzilla-daemon
@ 2023-09-05 16:16 82% ` bugzilla-daemon
  2023-09-05  0:46 82% ` bugzilla-daemon
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2023-09-05 16:16 UTC (permalink / raw)
  To: linux-usb

https://bugzilla.kernel.org/show_bug.cgi?id=217862

--- Comment #7 from pawlick3r@proton.me ---
Created attachment 305037
  --> https://bugzilla.kernel.org/attachment.cgi?id=305037&action=edit
entire dmesg

I enabled debug messages for the mass storage driver and USB, recompiled, and
this is what I got. Instead of oopsing it instead ran past the error and failed
to read the 8mb card. I'm going to test the reader on a second computer with
the proper OS to rule out any reader issues as well.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[relevance 82%]

Results 201-400 of ~385453   |  | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
     [not found]     <259e755c.4eaad.188f817a0f3.Coremail.lxybhu@buaa.edu.cn>
2023-06-26 19:25 82% ` [BUG]Bluetooth: HCI_Command_Status: possible semantic bug when Num_HCI_Command_Packets set to zero Luiz Augusto von Dentz
     [not found]     <bug-215902-202145@https.bugzilla.kernel.org/>
2023-03-08  7:45 82% ` [f2fs-dev] [Bug 215902] kernel BUG at fs/inode.c:611! bugzilla-daemon
2022-10-16 11:21 82% Bug 216582 - BUG: kernel NULL pointer dereference - nlmclnt_setlockargs Thorsten Leemhuis
2022-10-16 11:56 82% ` Daire Byrne
     [not found]     <ZHKrC4/G6ZyvRReI@xps>
2023-05-28  6:49     ` Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system) Salvatore Bonaccorso
2023-05-28 12:44       ` Mario Limonciello
2023-05-29  0:56         ` Nick Hastings
2023-05-29  1:14           ` Mario Limonciello
2023-05-29  3:51             ` Nick Hastings
2023-05-29 23:01               ` Nick Hastings
2023-05-30  4:00                 ` Mario Limonciello
     [not found]                   ` <168471337231.1913606.15905047692536779158.reportbug@xps>
2023-05-30  7:01                     ` Nick Hastings
2023-05-30 11:22 82%                   ` Bug#1036530: " Salvatore Bonaccorso
     [not found]     <AOsAKwAOFVqmSoeI4YmdXKoQ.1.1669897562230.Hmail.3014218099@tju.edu.cn>
2022-12-01 18:46 82% ` FOUND BUG WITH TITLE: <kernel BUG in ext4_getblk> Eric Biggers
     [not found]     <ed32aad7-41c0-c84d-c1f3-085a4d43ce09@buaa.edu.cn>
2023-08-07 17:22 82% ` [BUG]Bluetooth: possible semantic bug when the status field of the HCI_Connection_Complete packet set to non-zero Jakub Kicinski
2022-08-11  9:55 82% [bug report] drm/ttm: Fix dummy res NULL ptr deref bug Dan Carpenter
2022-08-11 11:06 82% ` Arunpravin Paneer Selvam
2022-08-11 11:56 82%   ` Dan Carpenter
2022-08-14  6:00 82%     ` Arunpravin Paneer Selvam
2022-08-14 17:50 82%       ` Christian König
     [not found]     <869240bf-7f91-4131-b56a-7ac2585dee4e@buaa.edu.cn>
2023-08-15 17:53 82% ` [BUG]Bluetooth: HCI_Connection_Complete: possible semantic bug when HCI_Connection_Complete is discarded Luiz Augusto von Dentz
     [not found]     <20220906191320.447t5awx3rcb5d5b@illithid>
     [not found]     ` <1719285.QkHrqEjB74@pip>
     [not found]       ` <01989003-349f-fb6b-f460-89106b82bc34@gmail.com>
     [not found]         ` <2176657.1BCLMh4Saa@pip>
2022-12-17 11:51           ` Ping^1: Chapters of the manual (was: Bug#1018737: /usr/bin/rst2man: rst2man: .TH 5th field shouldn't be empty) Alejandro Colomar
2022-12-17 13:19     ` [BUG] gropdf, tbl: Completely broken table (was: Ping^1: Chapters of the manual (was: Bug#1018737: ...)) Alejandro Colomar
2022-12-17 16:08       ` G. Branden Robinson
2022-12-18 11:46 82%     ` Alejandro Colomar
2022-12-17 21:26 82%     ` Deri
2022-12-18 11:25 82%       ` Alejandro Colomar
2022-09-21 23:31 82% [BUG] drivers: adm9240: possible data race bug in adm9240_fan_read() Li Zhong
2022-09-22  3:16 82% ` Guenter Roeck
2022-09-22 20:37 82%   ` Li Zhong
2022-09-22 21:53         ` Guenter Roeck
2022-09-22 23:46 82%       ` Li Zhong
2023-01-19 18:25 82% [Bug 216953] New: BUG: kernel NULL pointer dereference, address: 0000000000000008 bugzilla-daemon
2023-01-22 11:23 82% ` [Bug 216953] " bugzilla-daemon
2023-01-19 18:32 82% ` bugzilla-daemon
2023-01-19 18:26 82% ` bugzilla-daemon
2023-01-19 18:45 82% ` bugzilla-daemon
2023-01-19 20:36 82% ` bugzilla-daemon
2023-01-19 18:26 82% ` bugzilla-daemon
2023-01-19 18:26 82% ` bugzilla-daemon
2022-09-29  1:40 82% [Bug 1087] [Bug] tcp data len is incorrectly calculated in gro_tcp4_reassemble function bugzilla
2022-11-10  1:45 82% ` bugzilla
2022-11-13  7:29 82% [Bug 216686] New: BUG: kernel NULL pointer dereference, address: 0000000000000680 bugzilla-daemon
2022-11-14  6:09 82% ` [Bug 216686] " bugzilla-daemon
2022-11-13  7:31 82% ` bugzilla-daemon
2022-11-14  5:39 82% ` bugzilla-daemon
2022-11-13  7:31 82% ` bugzilla-daemon
2022-11-13  7:30 82% ` bugzilla-daemon
2022-11-14  6:32 82% ` bugzilla-daemon
2022-11-13  8:44 82% ` bugzilla-daemon
2022-11-14  5:45 82% ` bugzilla-daemon
2022-11-14  5:40 82% ` bugzilla-daemon
2023-03-20  6:52     [Bug 217216] New: [Syzkaller & bisect] There is BUG: unable to handle kernel NULL pointer dereference in xfs_filestream_select_ag in v6.3-rc3 bugzilla-daemon
2023-03-20  8:32 82% ` [Bug 217216] " bugzilla-daemon
2023-06-30  1:35     [Bug 217613] New: [BUG] [media] dvb-usb: possible data-inconsistency due to data races in dib0700_rc_query_old_firmware() bugzilla-daemon
2023-06-30  5:22 82% ` [Bug 217613] " bugzilla-daemon
2023-06-30  5:22 82% ` [Bug 217613] New: " Greg KH
2023-06-30  8:11 82% ` [Bug 217613] " bugzilla-daemon
2023-06-30  1:48 82% ` bugzilla-daemon
2023-08-02 21:28     nouveau bug in linux/6.1.38-2 Olaf Skibbe
     [not found]     ` <169080024768.2498.7944943374763908742.reportbug@oma-1>
2023-08-04 13:11       ` Olaf Skibbe
2023-08-04 13:38 82%     ` [Nouveau] Bug#1042753: " Diederik de Haas
2023-08-04 13:38 82%       ` Diederik de Haas
2023-08-04 13:38 82%       ` Diederik de Haas
2023-02-09  2:57     [BUG] run rcutorture BUG: unable to handle page fault for address: ffffffff84d05000 Zhang, Qiang1
2023-02-09  3:49 82% ` Paul E. McKenney
2022-07-27  9:07     [BUG] video: fbdev: arkfb: Found a divide-by-zero bug which may cause DoS Zheyu Ma
2022-08-01  4:34     ` Helge Deller
2022-08-03  9:26 82%   ` Zheyu Ma
2022-08-03  9:26 82%     ` Zheyu Ma
2022-11-17  7:55     [BUG REPORT] kernel BUG in ext4_write_inline_data_end Jun Nie
2022-12-05  8:54     ` [BUG REPORT] kernel BUG in ext4_write_inline_data_end or ext4_writepages Jun Nie
2022-12-07  6:39 82%   ` yebin (H)
2023-02-03 17:05     [PATCH v1 0/4] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-02-03 17:05     ` [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-02-13 13:13 82%   ` Jan Beulich
2023-02-14 16:44 82%     ` Oleksii
2022-01-01 14:35     [Bug 215443] New: [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1] bugzilla-daemon
2022-08-26 14:36 82% ` [Bug 215443] " bugzilla-daemon
2023-03-25 13:58     [Bug 217247] New: BUG: kernel NULL pointer dereference, address: 000000000000000c / speculation_ctrl_update bugzilla-daemon
2023-03-30 17:41 82% ` [Bug 217247] " bugzilla-daemon
2023-03-25 13:59 82% ` bugzilla-daemon
2022-08-27 20:48     [Bug 216422] New: BUG: kernel NULL pointer dereference, address: 0000000000000000 bugzilla-daemon
2022-08-28  0:21 82% ` [Bug 216422] " bugzilla-daemon
2022-08-27 20:49 82% ` bugzilla-daemon
2022-08-28 11:28 82% ` bugzilla-daemon
2022-08-16 19:00     [next] arm64: kernel BUG at fs/inode.c:622 - Internal error: Oops - BUG: 0 - pc : clear_inode Naresh Kamboju
2022-08-16 19:10 82% ` Linus Torvalds
2022-08-16 19:39 82%   ` Naresh Kamboju
2022-08-17  2:00 82%     ` Stephen Rothwell
2022-08-16 19:42 82%     ` Linus Torvalds
2022-12-19  7:16     [bug report]BUG: KFENCE: use-after-free read in bfq_exit_icq_bfqq+0x132/0x270 Yi Zhang
2022-12-19 17:52 82% ` Jens Axboe
2022-12-22 14:49 82%   ` Jan Kara
2022-12-26  1:17 82%     ` Yu Kuai
2022-07-26 19:35     [Bug 216283] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_insert_extent() when mount and operate on crafted image bugzilla-daemon
2022-08-01 22:45 82% ` [Bug 216283] " bugzilla-daemon
2022-08-02  9:28 82% ` bugzilla-daemon
2022-10-04 19:42 82% ` bugzilla-daemon
2022-10-04  9:15 82% ` bugzilla-daemon
2022-07-26 20:10     ` [Bug 216283] New: " Darrick J. Wong
2022-07-27 11:53       ` Lukas Czerner
2022-07-27 23:22         ` Dave Chinner
2022-07-28  7:25           ` Lukas Czerner
2022-08-01 22:45             ` Dave Chinner
2022-08-02  9:28 82%           ` Lukas Czerner
2021-12-21 18:50     [Bug 215381] New: BUG: Unable to handle kernel data access on read at 0x6600cc00000004 bugzilla-daemon
2022-08-19 10:19 82% ` [Bug 215381] " bugzilla-daemon
2023-05-10  0:49     [bug report] BUG: kernel NULL pointer dereference, address: 0000000000000048 Guangwu Zhang
2023-05-10  1:29 82% ` Yu Kuai
2023-05-10  1:49 82%   ` Yu Kuai
2023-05-10  2:00 82%     ` Yu Kuai
2023-05-10  2:17 82%       ` Jens Axboe
2023-05-10  3:20 82%         ` Yu Kuai
     [not found]               ` <CAGS2=YocNy9PkgRzzRdHAK1gGdjMxzA--PYS=sPrX_nCe4U6QA@mail.gmail.com>
2023-05-10  6:39 82%             ` Ming Lei
2023-05-10 12:08 82%               ` Guangwu Zhang
2023-05-10  6:55 82%               ` Yu Kuai
2023-06-21  7:38     [bug report] BUG: KASAN: out-of-bounds in io_req_local_work_add+0x3b1/0x4a0 Guangwu Zhang
2023-06-21 13:40 82% ` Jens Axboe
2023-06-21 14:04 82%   ` Jens Axboe
2023-06-21 14:04       ` Ming Lei
2023-06-21 15:56 82%     ` Jens Axboe
2023-06-23  5:51           ` Guangwu Zhang
2023-06-23 12:14 82%         ` Jeff Moyer
2023-05-22  2:11     [Bug 217470] New: [Syzkaller & bisect] There is BUG: unable to handle kernel NULL pointer dereference in xfs_extent_free_diff_items in v6.4-rc3 bugzilla-daemon
2023-05-22  2:11 82% ` [Bug 217470] " bugzilla-daemon
2023-09-02  1:05     [Bug 217862] New: [BUG] Alauda driver causes oops when inserted with card in with transfer buffer is on stack, throws errors if card is inserted afterwards bugzilla-daemon
2023-09-02  1:05 82% ` [Bug 217862] " bugzilla-daemon
2023-09-05 16:16 82% ` bugzilla-daemon
2023-09-05  0:46 82% ` bugzilla-daemon
2023-09-03 16:09 82% ` bugzilla-daemon
2023-09-02  2:49 82% ` bugzilla-daemon
2023-02-24 11:31     [PATCH v3 0/4] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-02-24 11:31     ` [PATCH v3 2/4] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-02-25 16:47 82%   ` Julien Grall
2023-02-28 13:07 82%     ` Oleksii
2023-02-28 13:30 82%       ` Jan Beulich
2023-02-28 16:00 82%         ` Oleksii
2023-02-28 12:38 82%     ` Oleksii
2023-02-28 14:04 82%       ` Julien Grall
2023-02-27 14:29 82%   ` Jan Beulich
2023-02-28 13:14 82%     ` Oleksii
2023-01-12 15:57     [Bug 216920] New: Running IDE eventually leads to BUG: kernel NULL pointer dereference bugzilla-daemon
2023-01-16  9:31 82% ` [Bug 216920] " bugzilla-daemon
2023-01-16  9:33 82% ` bugzilla-daemon
2023-03-03 10:38     [PATCH v5 0/4] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-03-03 10:38     ` [PATCH v5 2/4] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-03-06 10:24 82%   ` Jan Beulich
2023-04-09 22:21     BUG: drivers/net/wireless: iwlwifi: IWL Error: ieee80211 phy0: Hardware restart was requested Mirsad Goran Todorovac
2023-04-09 23:43     ` BUG: drivers/net/wireless: iwlwifi: IWL Error: "BUG: kernel NULL pointer dereference, address: 0000000000000150" Mirsad Goran Todorovac
2023-04-11  8:47 82%   ` Greenman, Gregory
2023-04-12 11:46         ` Mirsad Todorovac
2023-04-13  6:38 82%       ` Mirsad Goran Todorovac
2023-04-06  8:56     [PATCH] soundwire: amd: fix an IS_ERR() vs NULL bug Dan Carpenter
2023-04-06 12:02 82% ` Mukunda,Vijendar via Alsa-devel
2023-06-26 12:09     Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system) Linux regression tracking (Thorsten Leemhuis)
2023-06-26 12:36 82% ` Bug#1036530: Info received (Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)) Debian Bug Tracking System
2023-04-12 18:43     [BUG] DAX access of Memory Expander on RCH topology fires BUG on page_table_check Gregory Price
2023-04-18  6:35 82% ` Dan Williams
2023-04-20  1:29 82%   ` Gregory Price
2023-04-13 11:39     ` Gregory Price
2023-04-18  6:43 82%   ` Dan Williams
2023-04-20  0:58 82%     ` Gregory Price
2023-06-07 19:51     [PATCH v2 1/2] mm: zswap: support exclusive loads Yosry Ahmed
2023-06-21  7:01     ` [BUG mm-unstable] "kernel BUG at mm/swap.c:393!" on commit b9c91c43412f2e Hyeonggon Yoo
2023-06-21  7:03 82%   ` Hyeonggon Yoo
2023-06-21  8:05       ` Yosry Ahmed
2023-06-21  9:18 82%     ` Domenico Cerasuolo
2023-06-21  9:26 82%       ` Yosry Ahmed
2023-06-21  9:06 82%     ` Hyeonggon Yoo
2023-06-21  9:09 82%       ` Yosry Ahmed
2023-06-28 10:48     [PATCH v7 0/2] mm, netfs, fscache: Stop read optimisation when folio removed from pagecache David Howells
2023-06-28 10:48     ` [PATCH v7 2/2] " David Howells
2023-07-07 16:38       ` [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0 Hyeonggon Yoo
2023-07-07 16:46 82%     ` Hyeonggon Yoo
2023-07-07 16:46 82%       ` Hyeonggon Yoo
2023-07-07 18:12 82%       ` David Wysochanski
2023-07-07 19:23 82%         ` SeongJae Park
2023-07-07 18:27 82%         ` Hyeonggon Yoo
2023-07-07 18:27 82%           ` Hyeonggon Yoo
2019-07-24 13:02     [Bug 204293] New: When destroying guests, hypervisor freezes for some seconds and get BUG: soft lockup - CPU* stuck for Xs bugzilla-daemon
2023-01-27 13:06 82% ` [Bug 204293] " bugzilla-daemon
2022-09-27  1:17     [Bug report] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0 Zorro Lang
2022-09-29 21:28     ` Matthew Wilcox
2022-09-30  2:01       ` Michael Ellerman
2022-09-30 18:59         ` Matthew Wilcox
2022-10-05 11:13 82%       ` Michael Ellerman
2022-10-05 11:13 82%         ` Michael Ellerman
2022-01-01 14:35     [Bug 215443] New: [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1] bugzilla-daemon
2022-08-26 14:36 82% ` [Bug 215443] " bugzilla-daemon
2022-05-04 19:42     [Bug 215941] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon
2022-10-04  9:14 82% ` [Bug 215941] " bugzilla-daemon
2022-10-04 19:48 82% ` bugzilla-daemon
2021-11-02  9:27     [Bug 214913] New: [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40 bugzilla-daemon
2022-12-12  5:57 82% ` [Bug 214913] " bugzilla-daemon
2022-12-12  7:19 82%   ` Nicholas Piggin
2022-12-12  7:19 82% ` bugzilla-daemon
2022-12-12  7:30 82% ` bugzilla-daemon
2022-12-11 13:19 82% ` bugzilla-daemon
2022-12-12  3:52       ` Nicholas Piggin
2022-12-12  7:30 82%     ` Christophe Leroy
2023-01-12 11:38     [bug report] BUG: KASAN: use-after-free in bic_set_bfqq Shinichiro Kawasaki
2023-01-12 11:47 82% ` Yu Kuai
2023-01-12 13:14 82%   ` Shinichiro Kawasaki
2023-01-12 11:53 82%   ` Yu Kuai
2023-01-12 13:18 82%     ` Shinichiro Kawasaki
2023-01-13  1:04 82%       ` Shinichiro Kawasaki
2023-01-13  1:11 82%         ` Yu Kuai
2022-10-09 17:47     [Bug 216566] New: [xfstests generic/648] BUG: unable to handle page fault, RIP: 0010:__xfs_dir3_data_check+0x171/0x700 [xfs] bugzilla-daemon
2022-10-09 22:47 82% ` [Bug 216566] " bugzilla-daemon
2022-10-09 22:47 82% ` [Bug 216566] New: " Dave Chinner
2022-10-10  1:31 82% ` [Bug 216566] " bugzilla-daemon
2023-08-07 17:48     [BUG]Bluetooth: possible semantic bug when the status field of the HCI_Connection_Complete packet set to non-zero Luiz Augusto von Dentz
2023-08-09 15:10 82% ` Xin-Yu Liu
2023-04-25  2:37     [bug report] BUG: kernel NULL pointer dereference, address: 00000000000000fc Changhui Zhong
2023-04-25  3:27 82% ` Ming Lei
2023-04-26  5:56       ` Changhui Zhong
2023-04-26  6:05 82%     ` Yu Kuai
2023-04-26  6:20 82%       ` Changhui Zhong
2023-04-26  6:24 82%         ` Yu Kuai
2023-04-26  6:32 82%           ` Changhui Zhong
2022-12-31 12:13     [Bug 216871] New: use after free when journal read failed bugzilla-daemon
2023-01-01  3:15 82% ` [Bug 216871] bug: " bugzilla-daemon
2022-09-27 17:57     6.0.0-RC kernels trigger Firefox snap bug with 6.0.0-rc3 through 6.0.0-rc7 Mirsad Goran Todorovac
2022-09-30 10:48 82% ` BUG: " Mirsad Todorovac
2022-09-30 11:21 82%   ` Slade Watkins
2022-09-30 11:44 82%     ` Mirsad Todorovac
2022-09-30 12:03 82%       ` Slade Watkins
2022-09-30 18:27 82%         ` Slade Watkins
2022-10-03  8:18 82%           ` Mirsad Goran Todorovac
2022-10-07  8:47 82%             ` Slade Watkins
2022-10-07 10:55 82%               ` Mirsad Goran Todorovac
2022-10-06 10:39 82%   ` Marc Miltenberger
2022-10-06 16:27 82%     ` Slade Watkins
2022-10-06 12:00     ` Thorsten Leemhuis
2022-10-06 12:25       ` Thorsten Leemhuis
2022-10-06 12:43         ` Mirsad Todorovac
2022-10-06 13:23           ` Thorsten Leemhuis
     [not found]             ` <c05134cc-92fa-dac2-e738-cf6fae194521@alu.unizg.hr>
2022-10-06 16:58               ` Thorsten Leemhuis
2022-10-08 13:41                 ` Mirsad Goran Todorovac
     [not found]                   ` <c40786ab-8b3b-9b64-683f-dac589c024df@alu.unizg.hr>
2022-10-12  6:05                     ` BUG reproduced: " Mirsad Todorovac
2022-10-12 22:58 82%                   ` Slade Watkins
2022-10-09  6:45                     ` Thorsten Leemhuis
2022-10-09 22:45 82%                   ` Slade Watkins
2022-10-11 17:53 82%                     ` Mirsad Goran Todorovac
2023-03-07 15:50     [PATCH v6 0/4] [PATCH v5 0/4] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-03-07 15:50     ` [PATCH v6 2/4] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-03-08 15:27 82%   ` Jan Beulich
2023-03-08 17:25 82%     ` Oleksii
2023-03-09  9:49 82%       ` Jan Beulich
2023-05-24 17:12     [BUG 6.4-rc3] BUG: kernel NULL pointer dereference in __dev_fwnode Steven Rostedt
2023-05-24 18:28     ` Linus Torvalds
2023-05-25 16:42 82%   ` Sebastian Reichel
2023-05-26  2:08 82%     ` Steven Rostedt
2023-03-07  7:14     [bug report] BUG: KASAN: slab-use-after-free in bfq_setup_cooperator Shinichiro Kawasaki
2023-03-07  8:57 82% ` Yu Kuai
2023-03-07  9:13 82%   ` Shinichiro Kawasaki
2023-03-07  9:36         ` Yu Kuai
2023-03-07 10:20 82%       ` Jan Kara
2023-03-07 10:28 82%         ` Yu Kuai
2023-03-07 11:49 82%           ` Shinichiro Kawasaki
2023-03-07 14:26 82%             ` Jens Axboe
2022-11-20 20:33     [Bug 216713] New: BUG: Bad page map in process init pte:c0ab684c pmd:01182000 (on a PowerMac G4 DP) bugzilla-daemon
2022-11-20 20:37 82% ` [Bug 216713] " bugzilla-daemon
2022-11-30 21:49 82% ` bugzilla-daemon
2022-09-25 11:55     [Bug 216529] New: [fstests generic/048] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0 bugzilla-daemon
2022-09-26  5:02 82% ` Theodore Ts'o
2022-09-27 18:10 82%   ` Ritesh Harjani (IBM)
2022-10-10 17:01 82%     ` Ritesh Harjani (IBM)
2022-09-27 18:06 82% ` [Bug 216529] " bugzilla-daemon
2022-09-26  5:02 82% ` bugzilla-daemon
2022-10-10 17:01 82% ` bugzilla-daemon
2022-09-27 18:10 82% ` bugzilla-daemon
2022-09-27  0:47     ` bugzilla-daemon
2022-09-27 18:06 82%   ` Theodore Ts'o
2023-02-20 16:40     [PATCH v2 0/4] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-02-20 16:40     ` [PATCH v2 2/4] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-02-23 13:34 82%   ` Jan Beulich
2023-02-23 15:14 82%     ` Oleksii
2023-02-01 20:32     [BUG REPORT] usb: dwc3: Bug while trying to use a RF ID Reader connected to USB port hector
2023-02-02  8:26 82% ` Greg KH
2023-05-05  9:21     [bug report] ceph: fix potential use-after-free bug when trimming caps Dan Carpenter
2023-05-06  1:32 82% ` Xiubo Li
2023-05-06  7:13 82%   ` Dan Carpenter
2023-05-08  6:42 82%     ` Xiubo Li
2023-06-30  1:38     [Bug 217614] New: [BUG] [media] dvb-usb: possible data-inconsistency due to data races in dib0700_rc_query_old_firmware() bugzilla-daemon
2023-06-30  1:48 82% ` [Bug 217614] " bugzilla-daemon
2022-12-08 13:55     i915 and PAT attributes on Xen PV Marek Marczykowski-Górecki
2022-12-16 15:30     ` [cache coherency bug] i915 and PAT attributes Andrew Cooper
2022-12-22  8:29       ` [Intel-gfx] " Ville Syrjälä
2023-01-01 23:24         ` Marek Marczykowski-Górecki
2023-01-02  0:03           ` Demi Marie Obenour
2023-01-02  1:00             ` Marek Marczykowski-Górecki
2023-01-02  1:17               ` Demi Marie Obenour
2023-01-02  1:48                 ` Demi Marie Obenour
2023-01-02  1:58 82%               ` [Intel-gfx] [cache coherency bug] [hw bug?] " Marek Marczykowski-Górecki
2023-01-02  1:58 82%                 ` Marek Marczykowski-Górecki
2023-05-16 11:18     [bug] kernel: bpf: syscall: a possible sleep-in-atomic bug in __bpf_prog_put() starmiku1207184332
2023-05-16 17:08 82% ` Yonghong Song
     [not found]       ` <CALyQVax8X63qekZVhvRTmZFFs+ucPKRkBB7UnRZk6Hu3ggi7Og@mail.gmail.com>
2023-05-21  3:44 82%     ` Yonghong Song
     [not found]           ` <CALyQVazb=D1ejapiFdTnan6JbjFJA2q9ifhSsmF4OC9MDz3oAw@mail.gmail.com>
2023-05-23  4:33             ` Yonghong Song
2023-05-24 12:42               ` Teng Qi
2023-05-24 19:34 82%             ` Yonghong Song
2023-05-24 19:44 82%               ` Alexei Starovoitov
2023-06-11 13:02                   ` Teng Qi
2023-06-12  0:01 82%                 ` Yonghong Song
2022-10-09 17:57     [Bug 216567] New: [xfstests generic/451] kernel BUG at mm/truncate.c:669! bugzilla-daemon
2022-10-09 22:58 82% ` [Bug 216567] " bugzilla-daemon
2022-10-09 17:58     ` bugzilla-daemon
2022-10-09 22:58 82%   ` Dave Chinner
2023-03-29 10:50     [PATCH v9 0/5] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-03-29 10:50     ` [PATCH v9 3/5] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-03-31 20:36 82%   ` Julien Grall

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.