On Mon, Jun 22, 2020 at 03:01:55PM +0200, Oleg Nesterov wrote:
> On 06/22, Christian Brauner wrote:
> >
> > It is a supported case however unlikely. I just tried to answer
> > Dominique's specific question pointing out that even in that unlikely
> > case sighand_struct is stable.
>
> I too tried
On 06/22, Christian Brauner wrote:
>
> It is a supported case however unlikely. I just tried to answer
> Dominique's specific question pointing out that even in that unlikely
> case sighand_struct is stable.
I too tried to say this, but apparently just added more confusion ;)
> Just as an fyi,
On Mon, Jun 22, 2020 at 02:03:00PM +0200, Oleg Nesterov wrote:
> On 06/22, Christian Brauner wrote:
> >
> > On Mon, Jun 22, 2020 at 12:24:01PM +0200, Dominique Martinet wrote:
> > > Christian Brauner wrote on Mon, Jun 22, 2020:
> > > > On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote:
On 06/22, Christian Brauner wrote:
>
> On Mon, Jun 22, 2020 at 12:24:01PM +0200, Dominique Martinet wrote:
> > Christian Brauner wrote on Mon, Jun 22, 2020:
> > > On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote:
> > >> current->sighand is stable and can't go away. Unless "current" is
On Mon, Jun 22, 2020 at 12:24:01PM +0200, Dominique Martinet wrote:
> Christian Brauner wrote on Mon, Jun 22, 2020:
> > On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote:
> >> current->sighand is stable and can't go away. Unless "current" is exiting
> >> and
> >> has already passed
On 06/22, Dominique Martinet wrote:
>
> What about the possibility of sighand being null that the function does
> check, is that impossible for current as well?
It is only possible if "current" has already exited and passed exit_notify(),
iow if it is already a zombie and can be (auto)reaped.
Christian Brauner wrote on Mon, Jun 22, 2020:
> On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote:
>> current->sighand is stable and can't go away. Unless "current" is exiting and
>> has already passed exit_notify(). So I don't think net/9p needs this helper.
>
> From what I can
On Mon, Jun 22, 2020 at 11:40 AM Christian Brauner
wrote:
>
> On Sun, Jun 21, 2020 at 03:54:37PM +0200, Dominique Martinet wrote:
> > Alexander Kapshuk wrote on Sun, Jun 21, 2020:
> > > Export symbol __lock_task_sighand, so it is accessible from code compiled
> > > as modules.
> > > This fixes
On Sun, Jun 21, 2020 at 03:54:37PM +0200, Dominique Martinet wrote:
> Alexander Kapshuk wrote on Sun, Jun 21, 2020:
> > Export symbol __lock_task_sighand, so it is accessible from code compiled
> > as modules.
> > This fixes the following modpost error:
> > ERROR: modpost: "__lock_task_sighand"
On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote:
> On 06/21, Alexander Kapshuk wrote:
> >
> > Export symbol __lock_task_sighand, so it is accessible from code compiled
> > as modules.
> > This fixes the following modpost error:
> > ERROR: modpost: "__lock_task_sighand"
On 06/21, Alexander Kapshuk wrote:
>
> Export symbol __lock_task_sighand, so it is accessible from code compiled
> as modules.
> This fixes the following modpost error:
> ERROR: modpost: "__lock_task_sighand" [net/9p/9pnet.ko] undefined!
>
> Where __lock_task_sighand is called via
Alexander Kapshuk wrote on Sun, Jun 21, 2020:
> Export symbol __lock_task_sighand, so it is accessible from code compiled
> as modules.
> This fixes the following modpost error:
> ERROR: modpost: "__lock_task_sighand" [net/9p/9pnet.ko] undefined!
This can't fix something that's not broken (yet)!
Export symbol __lock_task_sighand, so it is accessible from code compiled
as modules.
This fixes the following modpost error:
ERROR: modpost: "__lock_task_sighand" [net/9p/9pnet.ko] undefined!
Where __lock_task_sighand is called via lock_task_sighand in net/9p/client.c
See
13 matches
Mail list logo
