[PATCH 0/1] LP#309378 -- port dm-raid4-5 to 2.6.28 and re-enable

Andy Whitcroft apw at canonical.com
Sat Dec 27 11:17:32 UTC 2008


On Fri, Dec 26, 2008 at 10:58:54AM -0700, Tim Gardner wrote:
> Andy Whitcroft wrote:
> > Someone seems to be using dm-raid4-5 and has filed a bug on it.  There
> > is no later version available upstream.  I have therefore attempted a
> > forward port of this.  The port seems trivial enough but raid is obviously
> > something rather sensitive as its failure mode is unpleasant.
> > 
> > The main thing is that an interface in the kernel was no longer used
> > by anything and was removed (a common occurance), so I have had to
> > reinstate this.  Basically all internal users of the locked form
> > of {set,clear}_page_locked() had gone so they were removed.  Now it
> > is entirly possible we could move to the unlocked interfaces, but it
> > is significantly safer to assume not and reinstate them; based on the
> > assumption that upstream will port this forward to 2.6.28 at some point
> > after release and is far better placed to make that call.
> > 
> > Comments?
> > 
> > -apw
> > 
> > Andy Whitcroft (1):
> >   UBUNTU: ubuntu: Add dm-raid4-5 driver -- port to 2.6.28
> > 
> >  include/linux/pagemap.h        |    8 ++++++++
> >  ubuntu/dm-raid4-5/Makefile     |    2 +-
> >  ubuntu/dm-raid4-5/dm-raid4-5.c |    2 +-
> >  3 files changed, 10 insertions(+), 2 deletions(-)
> > 
> > 
> 
> Applied, though with a slight modification. I moved
> {set,clear}_page_locked() into dm-raid4-5.c. I don't see the benefit of
> cluttering the mainline include files. Are you concerned that
> set_page_locked()/clear_page_locked() might be reintroduced to mainline
> with different semantics?

I was concerned that _set_page_locked() might change.  So placing it
there might trigger a failure merge failure should that happen.  A
difficult balance between the benefits of that against the obvious
advantage of keeping the whole of it in the ubuntu directory.  I am
happy either way.

-apw




More information about the kernel-team mailing list