linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Pavlu <petr.pavlu@suse.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Petr Mladek <pmladek@suse.com>,
	Prarit Bhargava <prarit@redhat.com>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	Borislav Petkov <bp@alien8.de>, NeilBrown <neilb@suse.de>,
	Goldwyn Rodrigues <rgoldwyn@suse.com>,
	david@redhat.com, mwilck@suse.com, linux-modules@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] module: Don't wait for GOING modules
Date: Thu, 19 Jan 2023 13:26:48 +0100	[thread overview]
Message-ID: <34fc4221-bb17-ab42-282c-e82f344c8a7c@suse.com> (raw)
In-Reply-To: <Y8g9lTBnCgB7g08/@bombadil.infradead.org>

On 1/18/23 19:42, Luis Chamberlain wrote:
> On Wed, Jan 18, 2023 at 04:12:05PM +0100, Petr Pavlu wrote:
>> On 1/18/23 01:04, Luis Chamberlain wrote:
>>> The rationale for making a regression fix with a new userspace return value
>>> is fair given the old fix made things even much worse the point some kernel
>>> boots would fail. So the rationale to suggest we *must* short-cut
>>> parallel loads as effectively as possible seems sensible *iff* that
>>> could not make things worse too but sadly I've found an isssue
>>> proactively with this fix, or at least that this issue is also not fixed:
>>>
>>> ./tools/testing/selftests/kmod/kmod.sh -t 0006
>>> Tue Jan 17 23:18:13 UTC 2023
>>> Running test: kmod_test_0006 - run #0
>>> kmod_test_0006: OK! - loading kmod test
>>> kmod_test_0006: FAIL, test expects SUCCESS (0) - got -EINVAL (-22)
>>> ----------------------------------------------------
>>> Custom trigger configuration for: test_kmod0
>>> Number of threads:      50
>>> Test_case:      TEST_KMOD_FS_TYPE (2)
>>> driver: test_module
>>> fs:     xfs
>>> ----------------------------------------------------
>>> Test completed
>>>
>>> When can multiple get_fs_type() calls be issued on a system? When
>>> mounting a large number of filesystems. Sadly though this issue seems
>>> to have gone unnoticed for a while now. Even reverting commit
>>> 6e6de3dee51a doesn't fix it, and I've run into issues with trying
>>> to bisect, first due to missing Kees' patch which fixes a compiler
>>> failure on older kernel [0] and now I'm seeing this while trying to
>>> build v5.1:
>>>
>>> ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of `__force_order';
>>> arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first defined here
>>> ld: warning: arch/x86/boot/compressed/efi_thunk_64.o: missing .note.GNU-stack section implies executable stack
>>> ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
>>> ld: warning: arch/x86/boot/compressed/vmlinux has a LOAD segment with RWX permissions
>>> ld: warning: creating DT_TEXTREL in a PIE
>>> make[2]: *** [arch/x86/boot/compressed/Makefile:118: arch/x86/boot/compressed/vmlinux] Error 1
>>> make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
>>> make: *** [arch/x86/Makefile:283: bzImage] Error 2
>>>
>>> [0] http://lore.kernel.org/lkml/20220213182443.4037039-1-keescook@chromium.org
>>>
>>> But we should try to bisect to see what cauased the above kmod test 0006
>>> to start failing.
>>
>> It is not clear to me from your description if the observed failure of
>> kmod_test_0006 is related to the fix in this thread.
> 
> The issue happens with and without the patch in this thread, I'd just hate to
> exacerbate the issue further.
> 
>> The problem was not possible for me to reproduce on my system. My test was on
>> an 8-CPU x86_64 machine using v6.2-rc4 with "defconfig + kvm_guest.config +
>> tools/testing/selftests/kmod/config".
> 
> With the patch?

It is same for me without and with the patch. The test doesn't produce any
failure on my test system. The complete kmod.sh selftest passes too.

Cheers,
Petr

  reply	other threads:[~2023-01-19 12:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 10:35 [PATCH v2] module: Don't wait for GOING modules Petr Pavlu
2022-12-05 19:54 ` Petr Mladek
2022-12-06 16:57   ` Petr Pavlu
2022-12-07 15:15     ` Petr Mladek
2022-12-08  2:44       ` Luis Chamberlain
2022-12-12 11:29         ` Petr Pavlu
2022-12-13  2:58           ` Luis Chamberlain
2022-12-13  5:09 ` Luis Chamberlain
2022-12-13 10:17   ` Petr Mladek
2022-12-13 13:36     ` Petr Pavlu
2023-01-18  0:04     ` Luis Chamberlain
2023-01-18  0:18       ` Luis Chamberlain
2023-01-18 15:12       ` Petr Pavlu
2023-01-18 18:42         ` Luis Chamberlain
2023-01-19 12:26           ` Petr Pavlu [this message]
2023-01-19 15:47         ` Petr Mladek
2023-01-20  0:51           ` Luis Chamberlain
2023-01-20  0:58             ` Luis Chamberlain
2023-01-21 22:40               ` Luis Chamberlain
2023-03-11 21:36                 ` Luis Chamberlain
2023-03-12  6:25                 ` Lucas De Marchi
2023-03-22 22:31                   ` Luis Chamberlain
2023-03-23 15:01                     ` Lucas De Marchi
2023-03-23 15:08                       ` Luis Chamberlain
2023-03-24  6:03                         ` Lucas De Marchi
2023-03-24 18:47                           ` Luis Chamberlain
2023-01-24 19:58           ` Luis Chamberlain
2023-01-18 20:02       ` Borislav Petkov
2023-01-19  1:23         ` Luis Chamberlain
2023-01-19 23:37           ` Luis Chamberlain
2023-01-19  1:15       ` Lucas De Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=34fc4221-bb17-ab42-282c-e82f344c8a7c@suse.com \
    --to=petr.pavlu@suse.com \
    --cc=bp@alien8.de \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mwilck@suse.com \
    --cc=neilb@suse.de \
    --cc=pmladek@suse.com \
    --cc=prarit@redhat.com \
    --cc=rgoldwyn@suse.com \
    --cc=stable@vger.kernel.org \
    --cc=vegard.nossum@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).