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: <AE90C24D6B3A694183C094C60CF0A2F6026B7405@saturn3.aculab.com>
Date:	Tue, 12 Nov 2013 14:21:39 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Peter Zijlstra" <peterz@...radead.org>,
	"Geert Uytterhoeven" <geert@...ux-m68k.org>
Cc:	"Oleg Nesterov" <oleg@...hat.com>,
	"Ingo Molnar" <mingo@...nel.org>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] ipvs: Remove unused variable ret from sync_thread_master()

> > @@ -1637,7 +1637,7 @@ static int sync_thread_master(void *data)
> >  			continue;
> >  		}
> >  		while (ip_vs_send_sync_msg(tinfo->sock, sb->mesg) < 0) {
> > -			int ret = __wait_event_interruptible(*sk_sleep(sk),
> 
> So ideally there's be a comment here why we're using interruptible but
> then ignore interruptions.
> 
> Julian said (
> http://lkml.kernel.org/r/alpine.LFD.2.00.1310012245020.1782@ja.ssi.bg ):
> 
> " Yes, your patch looks ok to me. In the past
> we used ssleep() but IPVS users were confused why
> IPVS threads increase the load average. So, we
> switched to _interruptible calls and later the socket
> polling was added.  "

I've done this in the past so that the code sleeps interruptibly
unless there is a signal pending - which would cause it to return
early.

    /* Tell scheduler we are going to sleep... */
    if (signal_pending(current))
        /* We don't want waking immediately (again) */
        sleep_state = TASK_UNINTERRUPTIBLE;
    else
        sleep_state = TASK_INTERRUPTIBLE;
    set_current_state(sleep_state);

Shame there isn't a process flag to indicate that the process
will sleep uninterruptibly and that it doesn't matter.
So don't count to the load average and don't emit a warning
if it has been sleeping for a long time.

	David



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ