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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240816121657.69898770@foz.lan>
Date: Fri, 16 Aug 2024 12:16:57 +0200
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>, linux-media@...r.kernel.org,
 linux-kernel@...r.kernel.org, Hans Verkuil <hverkuil-cisco@...all.nl>
Subject: Re: [PATCH v2 2/2] media: drivers/media/dvb-core: Refactor
 dvb_frontend_open locking

Em Fri, 16 Aug 2024 10:20:47 +0200
Ricardo Ribalda <ribalda@...omium.org> escreveu:

> Hi Mauro
> 
> On Fri, 16 Aug 2024 at 10:17, Mauro Carvalho Chehab
> <mchehab+huawei@...nel.org> wrote:
> >
> > Em Wed, 14 Aug 2024 14:10:23 +0000
> > Ricardo Ribalda <ribalda@...omium.org> escreveu:
> >  
> > > Split out the wait function, and introduce some new toys: guard and
> > > lockdep.
> > >
> > > This fixes the following cocci warnings:
> > > drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2776
> > > drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2786
> > > drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2809  
> >
> > Hi Ricardo,  
> 
> Hi Mauro
> 
> >
> > Every time someone tries to fix this lock, we end having regression reports,
> > because of the diversity of devices, and the way they registers there.
> >
> > That's specially true for devices with multiple frontends and custom
> > zigzag methods.
> >
> > On what devices have you tested this patch?  
> 
> I do not have access to any device, it is just "compiled tested".
> 
> I think that the patch is mainly a refactor, it does not really change
> how the lock is handled.

While I liked your approach, in the specific case of this lock, I have 
to disagree: there were at least 2 or 3 previous attempts to fix 
issues on it, with patches made by someone and dully tested on some
hardware, ended being reverted due to corner cases with some boards.

So, I'm not willing to take the risk of accept patches touching
dvb frontend locking schema without tests with real hardware covering
common and corner cases (multi-frontend, custom zigzag, ...) and/or 
a formal code verification to proof that the lock works on all 
circumstances.

Regards,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ