[PATCH 1/2] Cygwin: lockf: Fix access violation in lf_clearlock().

[Corinna Vinschen]

On Nov 20 21:52, Takashi Yano wrote:
> On Tue, 19 Nov 2024 22:18:11 +0100
> Corinna Vinschen wrote:
> > On Nov 19 19:13, Takashi Yano wrote:
> > > On Tue, 19 Nov 2024 10:49:39 +0100
> > > Corinna Vinschen wrote:
> > > > >  [PATCH v2] Cygwin: flock: Fix overlap handling in lf_setlock() and lf_clearlock()
> > > > > as well?
> > > > 
> > > > Give me a bit of time.  While the patch might fix the problem, what
> > > > bugs me is the deviation from upstream code.  We will at least need
> > > > a few comments to explain why we don't follow the upstream behaviour.
> > > 
> > > I've got it. Does this code come from 'upstream'? From what code?
> > 
> > This was once ripped from FreeBSD code in 2008.  The upstream code
> > has changed considerably, though, so I'm not so sure if my reluctance
> > makes any sense.
> > 
> > > Essentially, the ovcase 1 can be a part of ovcase 3. I guess the
> > > 'upstream' does not add lock entry having same lock range unlike
> > > current cygwin (lf_ver related). So, ovcase 1 can break after
> > > handling 1 overlap. However, we need find overlap repeatedly
> > > because we have lf_ver.
> > 
> > Yeah, I get that.  What bugs me is that the structure of the upstream
> > snippets changed, not the necessity for change.  For that reason alone,
> > I would prefer that the `case 1:' expression stays where it is in
> > lf_clearlock.  But that's unreasonable.
> > 
> > It's a puzzle of life that one thinks in 2008, that this upstream
> > code will always stay what it is. A mere 16 years later...
> > 
> > Ok, never mind that.  Please push.  Maybe add a single-line comment
> > why we deviate from the original 2008 FreeBSD code at these points.
> 
> Thanks for reviewing. Pushed.

Thanks for the comments!


Corinna