On Monday 08 October 2007 23:37, Hugh Dickins wrote: > On Mon, 8 Oct 2007, Yan Zheng wrote: > > The test for VM_CAN_NONLINEAR always fails > > Good catch indeed. Though I was puzzled how we do nonlinear at all, > until I realized it's "The test for not VM_CAN_NONLINEAR always fails". > > It's not as serious as it appears, since code further down has been > added more recently to simulate nonlinear on non-RAM-backed filesystems, > instead of going the real nonlinear way; so most filesystems are now not > required to do what VM_CAN_NONLINEAR was put in to ensure they could do. Well, I think all filesystems can do VM_CAN_NONLINEAR anyway. Device drivers and "weird" things tend to have trouble... > I'm confused as to where that leaves us: is this actually a fix that > needs to go into 2.6.23? or will it suddenly disable a system call > which has been silently working fine on various filesystems which did > not add VM_CAN_NONLINEAR? could we just rip out VM_CAN_NONLINEAR? We probably should keep VM_CAN_NONLINEAR for the moment, I think. But now that we have the fallback path, we _could_ use that instead of failing. I doubt anybody will be using nonlinear mappings on anything but regular files for the time being, but as a trivial fix, I think this probably should go into 2.6.23. Thanks for spotting this problem Acked-by: Nick Piggin <npiggin@xxxxxxx> > I hope Nick or Miklos is clearer on what the risks are. > > (Apologies for all the "not"s and "non"s here, I'm embarrassed > after just criticizing Ingo's SCHED_NO_NO_OMIT_FRAME_POINTER!) > > Hugh > > > Signed-off-by: Yan Zheng<yanzheng@xxxxxxxx> > > ---- > > diff -ur linux-2.6.23-rc9/mm/fremap.c linux/mm/fremap.c > > --- linux-2.6.23-rc9/mm/fremap.c 2007-10-07 15:03:33.000000000 +0800 > > +++ linux/mm/fremap.c 2007-10-08 19:33:44.000000000 +0800 > > @@ -160,7 +160,7 @@ > > if (vma->vm_private_data && !(vma->vm_flags & VM_NONLINEAR)) > > goto out; > > > > - if (!vma->vm_flags & VM_CAN_NONLINEAR) > > + if (!(vma->vm_flags & VM_CAN_NONLINEAR)) > > goto out; > > > > if (end <= start || start < vma->vm_start || end > vma->vm_end) > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > > in the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
