On Sun, Oct 21, 2007 at 07:51:14PM -0400, Erez Zadok wrote:
From: Andrew Morton [EMAIL PROTECTED]
ERROR: security_inode_permission [fs/unionfs/unionfs.ko] undefined!
ERROR: security_file_ioctl [fs/unionfs/unionfs.ko] undefined!
Need these back.
These should never used by modules. You'll
The stable util-linux-ng 2.13.0.1 release is available at
ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/
Release Notes
=
Fixed security issue:
CVE-2007-5191 - mount: doesn't drop privileges properly when calling helpers
Changelog:
-
For
Hello.
Theodore Tso wrote:
Secondly, what results do you get when you run the command hdparm -tT
/dev/sda (or /dev/hda if you are using an IDE disk)?
[EMAIL PROTECTED] Ubuntu7.10]# hdparm -tT /dev/hda1
/dev/hda1:
Timing cached reads: 10384 MB in 2.00 seconds = 5196.44 MB/sec
Timing
On Mon, Oct 22, 2007 at 08:58:11PM +0900, Tetsuo Handa wrote:
--- Start VM ---
--- Suspend VM ---
[EMAIL PROTECTED] Ubuntu7.10]# filefrag Ubuntu7.10.vmem
Ubuntu7.10.vmem: 751 extents found, perfection would be 5 extents
[EMAIL PROTECTED] Ubuntu7.10]# sync
[EMAIL PROTECTED] Ubuntu7.10]#
Originally vfs_getxattr would pull the security xattr variable using
the inode getxattr handle and then proceed to clobber it with a subsequent call
to the LSM. This patch reorders the two operations such that when the xattr
requested is in the security namespace it first attempts to grab the
This patch series addresses two concerns. Currently when a developer
wishes to obtain a security blob from the LSM he/she has to guess at the
length of the blob being returned. We modify security_inode_getsecurity
to return an appropriately sized buffer populated with the security
information and
This patch modifies the interface to inode_getsecurity to have the
function return a buffer containing the security blob and its length via
parameters instead of relying on the calling function to give it an
appropriately sized buffer. Security blobs obtained with this function
should be
Sorry for my delay, here are a few replies.
On Sun, 14 Oct 2007, Erez Zadok wrote:
In message [EMAIL PROTECTED], Pekka Enberg writes:
However, I don't think the mapping_cap_writeback_dirty() check in
__filemap_fdatawrite_range() works as expected when tmpfs is a lower
mount for an
On Sun, 14 Oct 2007, Erez Zadok wrote:
In message [EMAIL PROTECTED], Pekka J Enberg writes:
Look at mm/filemap.c:__filemap_fdatawrite_range(). You shouldn't be
calling unionfs_writepage() _at all_ if the lower mapping has
BDI_CAP_NO_WRITEBACK capability set. Perhaps something like the
On Mon, 15 Oct 2007, Pekka Enberg wrote:
I wonder whether _not setting_ BDI_CAP_NO_WRITEBACK implies that
-writepage() will never return AOP_WRITEPAGE_ACTIVATE for
!wbc-for_reclaim case which would explain why we haven't hit this bug
before. Hugh, Andrew?
Only ramdisk and shmem have been
Hi Hugh,
On 10/22/07, Hugh Dickins [EMAIL PROTECTED] wrote:
I don't disagree with your unionfs_writepages patch, Pekka, but I think
it should be viewed as an optimization (don't waste time trying to write
a group of pages when we know that nothing will be done) rather than as
essential.
Ok,
Hi Hugh,
On Mon, 15 Oct 2007, Pekka Enberg wrote:
I wonder whether _not setting_ BDI_CAP_NO_WRITEBACK implies that
-writepage() will never return AOP_WRITEPAGE_ACTIVATE for
!wbc-for_reclaim case which would explain why we haven't hit this bug
before. Hugh, Andrew?
On 10/22/07, Hugh
In message [EMAIL PROTECTED], Hugh Dickins writes:
On Mon, 15 Oct 2007, Pekka Enberg wrote:
I wonder whether _not setting_ BDI_CAP_NO_WRITEBACK implies that
-writepage() will never return AOP_WRITEPAGE_ACTIVATE for
!wbc-for_reclaim case which would explain why we haven't hit this bug
In message [EMAIL PROTECTED], Hugh Dickins writes:
Sorry for my delay, here are a few replies.
In unionfs_writepage() I tried to emulate as best possible what the lower
f/s will have returned to the VFS. Since tmpfs's -writepage can return
AOP_WRITEPAGE_ACTIVATE and re-mark its page as
On Sat, 6 Oct 2007 12:15:08 +0400
Alexey Dobriyan [EMAIL PROTECTED] wrote:
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
fs/Kconfig | 191 --
fs/ext2/Kconfig | 55 +
fs/ext3/Kconfig | 67
In v9fs_vfs_rename function labels don't match the fids that are clunked.
The correct clunk order is clunking newdirfid first and then olddirfid next.
Signed-off-by: Latchesar Ionkov [EMAIL PROTECTED]
---
commit 0c9269a1384273b7a409a2163fdf91cd39092889
tree
In message [EMAIL PROTECTED], Christoph Hellwig writes:
On Sun, Oct 21, 2007 at 07:51:14PM -0400, Erez Zadok wrote:
From: Andrew Morton [EMAIL PROTECTED]
ERROR: security_inode_permission [fs/unionfs/unionfs.ko] undefined!
ERROR: security_file_ioctl [fs/unionfs/unionfs.ko] undefined!
17 matches
Mail list logo