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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:   Thu, 31 Mar 2022 08:53:22 +0000
From:   HARDERS Bernd <Bernd.Harders@...lesgroup.com>
To:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
CC:     PFLANZ Roger <Roger.Pflanz@...lesgroup.com>
Subject: Realtime behavior of named pipes

Hello, 

my name is Bernd Harders, I'm working for the thales company and I just have analyzed a real-time issue in context of named pipes, ext4 and jbd2, using ftrace and trace compass.

While the issue can be fixed by moving the pipe to the ramfs, I want to understand what's going on under the hood. 
I'm also interested in the question, if this issue belongs to the use of the very old RedHat7 and kernel 3.10, or if this behavior is still to be expectable. 

Here comes a short description of the behavior:

We have two high priority realtime threads, which communicate and synchronize in a high frequent manner using a named pipe. The named pipe directory entry is located on an ext4 partition, a lvm is in use. 

I found that in seldom cases the threads are blocked  for milliseconds, while a block_io, forced by the jbd2/dm thread is active. In this case there is no deterministic latency anymore, because it seems that the duration of the blocking also depends on other block_io's.  

Our idea is that this behavior is related to timestamp updates in the directory, forcing the journaling activities. 

While I can totally understand that io to a file is blocked, when journaling is doing its work, it is not obviously clear why this also happen on the pipe, because as I'm told the pipe io internally works to memory. We only write and read an integer value per transfer, so there is no need for temporary file io storage.

I'm looking forward to any explanations.

Best regards
Bernd Harders

{OPEN}


 
Bernd Harders
Senior Software Engineer
Naval Systems
Thales Deutschland
Switchboard Phone: +49 431-88737-344
Mobile: +49 172 828 14 50

E-Mail:   bernd.harders@...lesgroup.com

Thales Deutschland GmbH
Am Kiel-Kanal 3 - 24106 Kiel - Germany
 
[DEU] Achtung: Neue Anschrift! 
[ENG] Attention: New address!
www.thalesgroup.com
 









Sitz der Gesellschaft/Domicile of the Company: Stuttgart
Amtsgericht/District Court: Stuttgart HRB 728793
Geschäftsführer/Managing Directors:
Oliver Dörre (Vorsitzender/Chairman), Dr. Henning Biebinger, Dirk J.H. de Bruijn, Dr. Yves Joannic
Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Bernhard Gerwert


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ