summaryrefslogtreecommitdiff
path: root/firmware
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2011-06-16 00:35:09 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-06-16 00:35:09 -0700
commit9be34c9d526c305efb332ad53460b57d5f8edb3e (patch)
tree43db860557f3080b254291dac1035be1468dfdff /firmware
parent19a1166fa2352f9c07a5ab34a3c2aab462cff35d (diff)
mm: get rid of the most spurious find_vma_prev() users
We have some users of this function that date back to before the vma list was doubly linked, and just are silly. These days, you can find the previous vma by just following the vma->vm_prev pointer. In some cases you don't need any find_vma() lookup at all, and in other cases you're better off with the regular "find_vma()" that uses the vma cache front-end lookup. Some "find_vma_prev()" users are still valid, though. For example, in the case of a stack that grows up, it can be the case that we don't find any 'vma' at all (because we're looking up an address that is past the last vma), and that the stack that we want to grow is the 'prev' vma. But that kind of special case aside, we generally should prefer to use 'find_vma()'. Noticed due to a totally unrelated POWER memory corruption bug that just happened to hit in 'find_vma_prev()' and made me go "Hmm - why are we using that function here?". Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'firmware')
0 files changed, 0 insertions, 0 deletions