linux-kernel - Re: [EDT][PATCH 1/1] msgsnd use freezable blocking call

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>] [day] [month] [year] [list]

Date:	Thu, 07 May 2015 07:19:07 +0000 (GMT)
From:	Maninder Singh <maninder1.s@...sung.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Vaneet Narang <v.narang@...sung.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"yn.gaur@...sung.com" <yn.gaur@...sung.com>
Subject: Re: [EDT][PATCH 1/1] msgsnd use freezable blocking call

EP-F6AA0618C49C4AEDA73BFF1B39950BAB
>On Wed, 06 May 2015 11:29:57 +0000 (GMT) Maninder Singh wrote:

>> EP-F6AA0618C49C4AEDA73BFF1B39950BAB
>> 
>> Hi ,
>> 
>> Recently shared a patch for using freezable_schedule instead of schedule in msgrcv,
>> and after analysing message queuie implemntation we have realized even msgsnd can also block, if queue is full,
>> So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can schedule function, similar behaviour as msgrcv.
>> This change is applicable for msgsnd as well.
>> 
>> we have created patch for remotes/linux-next/akpm, because msgrcv patch is already applied at this branch.
.> so we didnt include  
>> 

>This changelog is quite poor.  It doesn't explain why the change is
>being made, it doesn't explain the user-visible effects which are being
>fixed, etc.

>So I threw it away and copied text from "ipc/msg.c: use freezable
>blocking call":

>One thing which isn't clear to me: *why* do we want to "Avoid waking up
>every thread sleeping in XXX during suspend and resume"?  Suspend and
>resume are rare operations.  Why do we care if a few threads wake up
>then go to sleep again?

When any task is stuck in Interruptible or Uninterruptible state then waking up of that task fails.
If wakeup fails, then suspend operation fails and all process send to frezeer state at this moment also gets wakeup.
Correct implementation is that if suspend fails, then kernel would retry suspend operation again after some specific timeinterval for some fixed retry count.
But as changes suggested by Mr Colin Cross on LKML https://lkml.org/lkml/2013/5/1/424, for the system calls for which issue has been faced process flag being appended with PF_FREEZER_SKIP.

we are testing some scenerio in which we have to do multi suspend-resume scenario, and we faced the problem thats why suggested the change for msgsnd and msgrcv


Signed-off-by: Vaneet narang <v.narang@...sung.com>
Signed-off-by: Maninder Singh <maninder1.s@...sung.com>
Cc: Yogesh Gaur <yn.gaur@...sung.com>
Cc: Manjeet Pawar <manjeet.p@...sung.com>
Cc: Ajeet Yadav <ajeet.y@...sung.com>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Tejun Heo <tj@...nel.org>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 ipc/msg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call ipc/msg.c
--- a/ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call
+++ a/ipc/msg.c
@@ -673,7 +673,7 @@ long do_msgsnd(int msqid, long mtype, vo
 
 		ipc_unlock_object(&msq->q_perm);
 		rcu_read_unlock();
-		schedule();
+		freezable_schedule();
 
 		rcu_read_lock();
 		ipc_lock_object(&msq->q_perm);
_