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: <BA0C23DE-E2B5-42A9-8478-CE216D18A6C6@sun.com>
Date:	Wed, 17 Mar 2010 15:09:00 -0600
From:	Andreas Dilger <adilger@....com>
To:	Oren Laadan <orenl@...columbia.edu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-api@...r.kernel.org, Serge Hallyn <serue@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	containers@...ts.linux-foundation.org,
	Matt Helsley <matthltc@...ibm.com>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [C/R v20][PATCH 46/96] c/r: add checkpoint operation for opened
 files of generic filesystems

On 2010-03-17, at 10:08, Oren Laadan wrote:
> These patches extend the use of the generic file checkpoint  
> operation to
> non-extX filesystems which have lseek operations that ensure we can  
> save
> and restore the files for later use. Note that this does not include
> things like FUSE, network filesystems, or pseudo-filesystem kernel
> interfaces.

I didn't see any other patches posted to linux-fsdevel regarding what  
this code is, or what it is supposed to be doing.  Could you please  
repost the patches related to generic_file_checkpoint(), and the  
overview email that explains what you mean by "checkpoint".  I'm  
assuming this is related to HPC/process restart/migration, but better  
to not guess.

> @@ -718,6 +718,7 @@ static const struct file_operations  
> btrfs_ctl_fops = {
> 	.unlocked_ioctl	 = btrfs_control_ioctl,
> 	.compat_ioctl = btrfs_control_ioctl,
> 	.owner	 = THIS_MODULE,
> +	.checkpoint = generic_file_checkpoint,
> };
>
> const struct file_operations exofs_file_operations = {
> 	.llseek		= generic_file_llseek,
> +	.checkpoint	= generic_file_checkpoint,
> 	.read		= do_sync_read,
> 	.write		= do_sync_write,
> 	.aio_read	= generic_file_aio_read,
>
> static const struct file_operations hostfs_file_fops = {
> 	.llseek		= generic_file_llseek,
> +	.checkpoint	= generic_file_checkpoint,
> 	.read		= do_sync_read,
> 	.splice_read	= generic_file_splice_read,
> 	.aio_read	= generic_file_aio_read,
> @@ -430,6 +431,7 @@ static const struct file_operations  
> hostfs_file_fops = {
>
> static const struct file_operations hostfs_dir_fops = {
> 	.llseek		= generic_file_llseek,
> +	.checkpoint	= generic_file_checkpoint,
> 	.readdir	= hostfs_readdir,
> 	.read		= generic_read_dir,
> };
>
> const struct file_operations nilfs_file_operations = {
> 	.llseek		= generic_file_llseek,
> +	.checkpoint	= generic_file_checkpoint,
> 	.read		= do_sync_read,
> 	.write		= do_sync_write,
> 	.aio_read	= generic_file_aio_read,


Minor nit - it would be good to add this method in the same place in  
all of the *_file_operation structures for consistency.  Ideally these  
would already be in the order that they are declared in the structure,  
but at least new ones should be added consistently.

> static const struct vm_operations_struct nfs_file_vm_ops = {
> 	.fault = filemap_fault,
> 	.page_mkwrite = nfs_vm_page_mkwrite,
> +#ifdef CONFIG_CHECKPOINT
> +	.checkpoint = filemap_checkpoint,
> +#endif
> };

Why is this one conditional, but the others are not?


Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
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