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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ