[Top] [All Lists]

Re: XFS_IOC_RESVSP64 for swap files

To: xfs@xxxxxxxxxxx
Subject: Re: XFS_IOC_RESVSP64 for swap files
From: Peter Cordes <peter@xxxxxxxxx>
Date: Thu, 21 Jun 2007 03:14:49 -0300
In-reply-to: <20070619043333.GJ86004887@xxxxxxx>
References: <20070617100822.GA4586@xxxxxxxxx> <20070619043333.GJ86004887@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Tue, Jun 19, 2007 at 02:33:33PM +1000, David Chinner wrote:
> On Sun, Jun 17, 2007 at 07:08:23AM -0300, Peter Cordes wrote:
> >  Hi XFS list.  I'm not subscribed, please CC me.
> > 
> >  Programs such as swapspace and swapd create new swap files when vmem runs
> > low.  They would benefit hugely from being able to create a swapfile without
> > any significant disk I/O.  (If a process grabs a lot of memory quickly, the
> > system will be swapping hard while swapspace(8) is writing a swapfile.)

> > but it [exposing stale data] would still be useful for making swap files
> > even if only root could do it.
> Still a potential security hole.

 Root can read the device file, so how is letting root expose stale data any
worse?  If a program run by root makes a file with mode 0600, and then calls
XFS_IOC_EXPOSE_MY_STALE_DATA_TO_EVERYONE, where's the security problem?

> >  Could swapon(2) in the kernel be made to work on XFS files with reserved
> > space?
> Basically, the swapon syscall calls bmap() for the block mapping of the
> file and XFS returns "holes" [...]

 Yeah, bad idea to put special case stuff in the kernel.

> > i.e. call something that would give XFS a chance to mark all the
> > extents as written, even though they're not.
> That's not going to happen.
> In fact, I plan to make unwritten extents non-optional soon (i.e. I've already
> got preliminary patches to do this) so that filesystems that have it turned
> off will get them turned on automatically.
> The reasons?
>       a) there is no good reason for unwritten=0 from a performance
>          perspective
>       b) there is good reason for unwritten=1 from a security perspective
>       c) we need to use unwritten extents in place of written extents
>          during delayed allocation to prevent stale data exposure on
>          crash and when using extent size hints.
> So soon unwritten=0 is likely to go the way of the dodo.....

 Ok.  I didn't really want to recreate my /var/tmp filesystem with
unwritten=0, but I really wish I had
XFS_IOC_EXPOSE_MY_STALE_DATA_TO_EVERYONE on my desktop machine.  I think
dynamic swap file creation is a cool idea, and that ioctl would make it work

 This ioctl is only useful for making swap files.  Nothing else cares if the
file has "holes" or not.  But for that one application, it's great.  There
are lots of ways root can shoot himself in the foot, and I don't think
adding one more is enough reason to not add an ioctl.

 Is it just that you don't want to take time to implement such a feature, or
would you reject a patch that added it?  (Not that I'm volunteering,

 BTW, thanks for taking the time to respond.

#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>