On Wed, 2019-06-12 at 09:39 +0800, Ming Lei wrote: > Hi Martin, > > On Tue, Jun 11, 2019 at 07:50:01PM -0400, Martin K. Petersen wrote: > > > > Ming, > > > > > 1) revert the 3 first, then re-organize the whole patchset in > > > correct order(convert drivers first, then the 3 above drivers) > > > > > > 2) simply apply the 5 patches now > > > > > > Any comments? > > > > I'm on the fence about this. Your patches were some of the first > > ones that went into the 5.3 tree. So I'd have to rebase pretty much > > the whole 5.3 queue. > > > > Whereas merging your updates leaves a sequence of 100+ commits that > > could lead to bisection problems in the future. I'm particularly > > worried about ipr and lpfc but all these drivers are actively used. > > The issue has been introduced, and people has complained, so I think > we have to do something. Studying the issue further, I think we have to do the rebase. The problem is that any driver which hasn't been updated can be persuaded to walk of the end of the request and dereference the next struct request. It's not impossible for userspace to set up both requests, so it looks like this could be used at least to leak information from the kernel if not exploit it outright. I think that means we have to have every driver updated before this goes in. > > As much as I like to see all drivers, without exception, use the sg > > iterators, it would have been nice to have a smoother transition. > > All the 5 drivers are found via static code analysis by eyes, and not > see other ways for looking at this issue. Can't coccinelle be persuaded? All we're looking for is a semantic search where we have a struct scatterlist that is either incremented or indexed. That said, it looks like the microtek scanner is yet another driver that needs updating. James > That said it is quite hard to prove 'all drivers, without exception, > use the sg iterators'. > > Even though some of them is missed, it should have been triggered > easily if drivers are actively used, then it can be fixed easily too.
