linux-kernel - Re: [PATCH RFC v4 4/4] gnss: ai2: replace long sleeps by wait for acks

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: <Z4ZaOXiUVQXK_d7L@hovoldconsulting.com>
Date: Tue, 14 Jan 2025 13:36:09 +0100
From: Johan Hovold <johan@...nel.org>
To: Andreas Kemnade <andreas@...nade.info>
Cc: marcel@...tmann.org, luiz.dentz@...il.com, pmenzel@...gen.mpg.de,
	jirislaby@...nel.org, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org,
	Adam Ford <aford173@...il.com>, Tony Lindgren <tony@...mide.com>,
	tomi.valkeinen@...asonboard.com,
	Péter Ujfalusi <peter.ujfalusi@...il.com>,
	robh@...nel.org, hns@...delico.com
Subject: Re: [PATCH RFC v4 4/4] gnss: ai2: replace long sleeps by wait for
 acks

On Thu, Jun 06, 2024 at 08:30:32PM +0200, Andreas Kemnade wrote:
> Previously there were long sleeps for everything sent out.
> Replace the sleeps by some wait for completion.
> Wait times like 60ms are seen.
> There are ack packets sent out if requested. Unfortunately
> just waiting for them seems not stable, some open()/close()
> loop stress-testing brings the communication into complete
> disorder. Unfortunately these ack packets arrive before
> a complete answer of the command has been received but
> apparently after some processing has been done.
> Properly declaring expected answers might help but adding
> that can only be justified after some wider testing.
> 
> So leaving this part of the series as a RFC and base
> for future optimzations.

Haven't really looked at this patch, but based on the above this doesn't
really provide any confidence that this protocol should be handled in
the kernel rather than in user space...

Johan