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

Reply via email to