linux-kernel - Re: 2.6.29 -mm merge plans

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200901151737.03600.nickpiggin@yahoo.com.au>
Date:	Thu, 15 Jan 2009 17:37:03 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.29 -mm merge plans

On Tuesday 13 January 2009 09:06:06 Andrew Morton wrote:
> On Mon, 5 Jan 2009 23:28:26 +1100
>
> Nick Piggin <nickpiggin@...oo.com.au> wrote:
> > On Monday 05 January 2009 19:43:00 Andrew Morton wrote:
> > > The individual patches are mostly at
> > > http://userweb.kernel.org/~akpm/mmotm/broken-out/
> > >
> > >
> > > mm-remove-the-might_sleep-from-lock_page.patch
> > >
> > >   Need to think about this.
> >
> > Removing this reduces a lot of might_sleep coverage scope. Page
> > lock isn't contended in a lot of cases. Why would you drop a
> > good debugging feature?
>
> For the reasons described in the changelog, of course.
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mm-remove-the-might_sleep-
>from-lock_page.patch

Yeah, but that's because voluntary preempt is somewhat of a hack.
In fact, we recently decided to turn this off in SLES11 because it
was causing a measurable performance slowdown.

If you are actually debugging a page lock problem or writing new
code, you would be very very happy to have a problem caught here
rather than the potentially much harder task of causing a
schedule on this lock.

> > > make-sure-nobodys-leaking-resources.patch
> > > releasing-resources-with-children.patch
> >
> > Any reason why not to add these upstream?
>
> Dunno.  Are they valuable?  I've never had a report of them triggering,
> I don't think.

I don't really know the code, but if it gives extra help to
people writing or testing new devices... is it difficult to
carry around? If not, then why *not* have it upstream? ;)

> > > put_bh-debug.patch
> >
> > This could just be implemented with a VM_BUG_ON (or FS_BUG_ON) like the
> > pagecache refcounting. Wouldn't be a bad idea.
>
> yup, I guess so.  Again, no reports of it triggering in ages.

Maybe I'll go through and add some such assertions for fs developers.
fsblock is riddled with them and it really really helps catching weird
and wonderful problems in the buffer layer, the pagecache layer, or
the filesystem, or some combination of them ;) Maybe that's just
because I write a lot of bugs though!

> > > add-a-refcount-check-in-dput.patch
> >
> > Again, why not an FS_BUG_ON for things like this too?
>
> Ditto.

OK.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/