On Wed, Jun 04, 2025 at 04:54:43PM +0200, Simona Vetter wrote: > On Tue, Jun 03, 2025 at 07:29:52PM -0300, Jason Gunthorpe wrote: > > On Mon, May 26, 2025 at 10:15:17PM +0530, Ghimiray, Himal Prasad wrote: > > > > > > > > > On 26-05-2025 20:36, Dan Carpenter wrote: > > > > Hello Himal Prasad Ghimiray, > > > > > > > > Commit 09ba0a8f06cd ("drm/xe/svm: Implement prefetch support for SVM > > > > ranges") from May 13, 2025 (linux-next), leads to the following > > > > Smatch static checker warning: > > > > > > > > drivers/gpu/drm/xe/xe_vm.c:2922 prefetch_ranges() > > > > warn: passing positive error code > > > > 's32min-(-96),(-94)-(-15),(-13)-(-12),(-10)-(-2),1' to 'ERR_PTR' > > > > > > Hi Dan, > > > > > > Thanks for pointing this out. I see there's a gap in how hmm_range_fault() > > > adheres to its documented behavior. I believe the function should sanitize > > > positive return values from walk_page_range() to ensure consistency. > > > > > > Jason can comment further on same. > > > > Yeah, I don't think it should return positive error code, whatever is > > doing that should be fixed. Can you send a patch? > > Not sure that's what's going on, from the comment and reading the code > (albeit non-exhaustively) I think you can only get positive error return > values from walk_page_range if the ops you provide do so. The hmm ones > don't, so I think this should be ok without any code changes? > > Maybe a WARN_ON and patching that up for paranoia, but I don't see how > this can happen. >
Thanks. A comment is enough probably. A WARN_ON() just bloats the code and it doesn't silence the warning. I'm going to have to add a line to the smatch_data/db/kernel.return_fixes to tell smatch that hmm_range_fault() doesn't return postives. regards, dan carpenter