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

[Takashi Yano]

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.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>