stop using no_llseek

[heitbaum]

Since kernel commit 868941b ("fs: remove no_llseek"), no_llseek() is simply defined to be NULL, and a NULL llseek means seeking is unsupported.

refs:

• torvalds/linux@cb787f4
• torvalds/linux@868941b

no_llseek has been hard dropped in linux-6.12

[gtxaspec]

confirmed, fixes building on 6.12

[Handrail9]

I'm not usually one to flood GitHub PRs with comments asking to have something merge, but I am breaking that rule as I have not had access to my Frigate security system for a while due to the kernel update. I'm hoping this gets merged soon.

[chrBrd]

Aye.

@mbrooksx - this is a simple, well-researched, backwards compatible, verified in prod fix.

This repo is no doubt very low on your list of priorities these days, but merging this will make life much easier for quite a lot of people. 😁

[8none1]

This PR is needed to get the gasket drivers to install on Ubuntu 25.04. Thank you @heitbaum

[oglok]

@chrBrd just curious. Why not using noop_llseek? it seems it won't break things as no_llseek and still userspace can perform the seek operation.

https://lore.kernel.org/lkml/[email protected]/

[chrBrd]

@oglok I should start by saying I'm just some random contributor who's thrown up a few PRs that got merged, I'm not officially involved with Google or this driver, so my opinion doesn't count for much.

However, I think removal is better than a redefinition because:

• They're not entirely equivalent functions. no_llseek() returned an ESPIPE (illegal seek) error, noop_llseek() returns the current pointer position in a file. The returned types are the same, but the returned values aren't.

• As per @heitbaum's second link above:

  all callers of ->llseek are going through vfs_llseek()

  vfs_llseek() will, as no_llseek() did, return an ESPIPE error if appropriate (it used to call no_llseek() internally before it was refactored and no_llseek() was removed).

• Related to the above, @heitbaum's first link shows that .llseek = no_llseek was removed from every upstreamed driver in which it was present - if that's what the kernel devs are doing it's probably what this driver should be doing too.

The change in this PR should (hopefully) mean a userspace seek operation behaves in exactly the same way it always has done - receiving an ESPIPE error.

[heitbaum]

@yenkwang @atvrager @davidgao @derekjchow @derekjchow-google

Hi Coral Team, sorry for reaching out this way, but is seems @mbrooksx is no longer available. Hoping one of you could reach out as the google team and approve some of the open PRs in this repo? Thanks in advance.

[derekcentrico]

Likely we need a community managed repo because this is dead now. Google graveyard.

[heitbaum]

@atvrager do you still have commit rights, can you merge some of the required updates?

[atvrager]

@heitbaum Doesn't seem like I have commit rights (or even the ability to assign the PR....), sorry.
Can try to track down someone and maybe get that access.

More generally -- I'm not opposed to accepting PRs here, but there's no way at the moment for me to know that what you've uploaded is "good" -- it looks fine to my eyes, but there's no CI flow or anything of the like, and I've got no access to hardware or a build system for it.

Even if it's just a paste of the log from debuild or the like, it'll go a decent ways towards someone actually approving the PR, imo.