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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20090107.122653.111144635.ryusuke@osrg.net>
Date:	Wed, 07 Jan 2009 12:26:53 +0900 (JST)
From:	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
To:	penberg@...helsinki.fi
Cc:	konishi.ryusuke@....ntt.co.jp, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Chris Mason <chris.mason@...cle.com>
Subject: Re: 2.6.29 -mm merge plans

Hi Pekka,

On Tue, 6 Jan 2009 15:30:59 +0200, "Pekka Enberg" wrote:
> Hi Ryusuke,
> 
> [snip nilfs patches]
> 
> On Mon, Jan 5, 2009 at 11:40 AM, Ryusuke Konishi
> <konishi.ryusuke@....ntt.co.jp> wrote:
> >>  Dunno.   Has this been reviewed enough?
> >>
> >
> > I'm now working to follow some comments from Chris, and
> > I think nilfs should be reviewed more widely.
> >
> > I'll aim for the next merge window or so.
> 
> It would be nice if BUG(), BUG_ON(), and panic() calls would be
> converted to proper error handling using WARN_ON() calls. The BUG()
> call in nilfs_cpfile_delete_checkpoints(), for example, looks to be
> triggerable from user-space via the ioctl() system call (albeit I
> didn't look too closely).

Thanks for looking at the code.

Well, there are too many BUG() and BUG_ON() calls.
I'll try to convert them as your advice.

The use of panic() call is a mimic of ext2/3, and this is called only
if an "errors=panic" mount option is specified.
Do you think it should be removed along with the mount option for
new filesystems ?

> Furthermore, the BUG() calls in error paths
> of fs/nilfs2/ioctl.c look really fishy.

I agree, but this seems to need some consideration.
I'll try to remove them separately if not easy.

> On a related note, there are quite a few new ioctls there. Are they
> described somewhere?

Not yet.  Where is the recommended place to put it in?

And, Chris Mason today gave me another comment on the ioctls; he
pointed out there is a structure using unfixed sized types (compat
ioctls are used to instead).

I agree with his comment.  I'd like to rewrite the ioctl declarations
and remove compat ioctls some time soon.

> Also, can they be converted to use
> ->unlocked_ioctl? It's bit sad that we're adding new users of BKL in
> shiny new code.

All right, I'll do some tests for it.

Regards,
Ryusuke Konishi
--
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/