linux-kernel - Re: [PATCH 18/20] exit/rtl8723bs: Replace the macro thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <875ytqifip.fsf@disp2133>
Date:   Thu, 21 Oct 2021 10:06:22 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 18/20] exit/rtl8723bs: Replace the macro thread_exit with a simple return 0

Greg KH <gregkh@...uxfoundation.org> writes:

> On Wed, Oct 20, 2021 at 12:44:04PM -0500, Eric W. Biederman wrote:
>> Every place thread_exit is called is at the end of a function started
>> with kthread_run.  The code in kthread_run has arranged things so a
>> kernel thread can just return and do_exit will be called.
>> 
>> So just have the threads return instead of calling complete_and_exit.
>> 
>> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> ---
>>  drivers/staging/rtl8723bs/core/rtw_cmd.c                | 2 +-
>>  drivers/staging/rtl8723bs/core/rtw_xmit.c               | 2 +-
>>  drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c          | 2 +-
>>  drivers/staging/rtl8723bs/include/osdep_service_linux.h | 2 --
>>  4 files changed, 3 insertions(+), 5 deletions(-)
>
> You "forgot" to cc: the linux-staging and the staging driver maintainer
> on these drivers/staging/ changes...

Yes I did.  Sorry about that.

> Anyway, they look fine to me, but you will get some conflicts with some
> of these changes based on cleanups already in my staging-next tree (in
> linux-next if you want to see them).  But feel free to take these all in
> your tree if that makes it easier:

I just did a test merge and there was one file that was completely
removed and one file with had changes a line or two above where my code
changed.  So nothing too difficult to result.

I don't really mind either way.  But keeping them all in one tree makes
them easier to keep track of, and allows me to do things like see if
I can remove EXPORT_SYMBOL(do_exit) as Christoph suggested.

Eric

> Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>