gmane.linux.kernel.api

[PATCH 2/2] Documentation: sysfs for Physical Presence Interface

Zhang, Xiaoyan — 2012-05-23T03:35:07

From: Xiaoyan Zhang <xiaoyan.zhang-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>

Signed-off-by: Xiaoyan Zhang <xiaoyan.zhang-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>
---
 Documentation/ABI/testing/sysfs-driver-ppi |   70 ++++++++++++++++++++++++++++
 1 files changed, 70 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-ppi

diff --git a/Documentation/ABI/testing/sysfs-driver-ppi b/Documentation/ABI/testing/sysfs-driver-ppi
new file mode 100644
index 0000000..5da9acd
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-ppi
< at >< at > -0,0 +1,70 < at >< at >
+What:/sys/devices/pnp0/<bus-num>/ppi/
+Date:May 2012
+Kernel Version:3.4
+Contact:xiaoyan.zhang-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org
+Description:
+This folder includes the attributes related with PPI (Physical
+Presence Interface). Only if TPM is supported by BIOS, this
+folder makes sense. The folder path can be got by command
+'find /sys/ -name 'pcrs''. For the detail information of PPI,
+please refer to the PP

[PATCH 1/2] driver: add PPI support in tpm driver

Zhang, Xiaoyan — 2012-05-23T03:34:12

From: Xiaoyan Zhang <xiaoyan.zhang-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>

The Physical Presence Interface enables the OS and the BIOS to cooperate
and provides a simple and straightforward platform user experience for
administering the TPM without sacrificing security.

Signed-off-by: Xiaoyan Zhang <xiaoyan.zhang-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>
---
 drivers/char/tpm/tpm.c |  462 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/char/tpm/tpm.h |   18 ++
 2 files changed, 480 insertions(+), 0 deletions(-)

diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index ad7c732..afa7ec4 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
< at >< at > -28,6 +28,8 < at >< at >
 #include <linux/mutex.h>
 #include <linux/spinlock.h>
 #include <linux/freezer.h>
+#include <linux/acpi.h>
+#include <acpi/acpi_drivers.h>
 
 #include "tpm.h"
 
< at >< at > -331,6 +333,50 < at >< at > static const u8 tpm_ordinal_duration[TPM_MAX_ORDINAL] = {
 TPM_MEDIUM,
 };
 
+static const u8 tpm_ppi_uuid[] = {
+0xA6, 0xFA, 0xDD, 0x3D,
+0

[PATCH 0/2] Add PPI support in tpm driver

Zhang, Xiaoyan — 2012-05-23T03:33:58

The series of patches add PPI support in linux kernel.

The Physical Presence Interface enables the OS and the BIOS to cooperate to provide a simple and straightforward platform user experience for administering the TPM without sacrificing security.

PATCH 1: drivers: Add PPI support in tpm driver
PATCH 2: Documentation: sysfs for physical presence interface

Re: Extended file stat: Splitting file- and fs-specific info?

Christoph Hellwig — 2012-05-09T12:05:44

NFS does not and should not look at the inode generation.  Except for a
bit of legacy code for the old pre-Linux 2.4 filehandles it looks at the
opaque file handle returned and only interpreted by the filesystem.  Any
userspace NFS server should do the same.

Re: Extended file stat: Splitting file- and fs-specific info?

Christoph Hellwig — 2012-05-09T11:19:58

It's entirely broken, as a generation number might be part of the file
handle (and for Linux-like filesystems normally is), but it's entirely
up to the filesystem to decide how it works.  That's why we added system
calls to do operations on opaque file handles that the file system
controls.  Exposing a completely meaningless "generation" is a bad idea.

Re: Extended file stat: Splitting file- and fs-specific info?

J. Bruce Fields — 2012-05-09T11:14:20

That's OK.  The only requirement would be that the (inode number, inode
generation) pair be different for different inodes on the same
filesystem.


That's true of a number of these new attributes.


Sure.

Since the only use case given for this has been constructing
filehandles, and since we already have an interface for that, I don't
feel particularly strongly about this.

--b.

Re: Extended file stat: Splitting file- and fs-specific info?

David Howells — 2012-05-09T09:21:14


I was asked for it by Bernd Schubert for userspace NFS servers and FUSE -
maybe he can say what he wants it for.

I also have a note that Jeremy Allison asked for it, but I can't find where or
why, so that might be an error.

It looks like FreeBSD do have an st_gen field in their stat struct, but it's
only filled in for root.  Maybe I could do something like that?

David

Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP

Michael Kerrisk (man-pages — 2012-04-28T07:29:32

Hello Jason,

On Sat, Apr 28, 2012 at 6:43 AM, Jason Baron <jbaron-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org> wrote:

Thanks! I tweaked this patch a little and applied the version below.

Cheers,

Michael

--- a/man2/madvise.2
+++ b/man2/madvise.2
< at >< at > -247,6 +247,24 < at >< at > Ensures that memory in the address range specified by
 and
 .IR length
 will not be collapsed into huge pages.
+.TP
+.BR MADV_DONTDUMP " (since Linux 3.4)"
+Exclude from a core dump those pages in the range specified by
+.I addr
+and
+.IR length .
+This is useful in applications that have large areas of memory
+that are known not to be useful in a core dump.
+The effect of
+.BR MADV_DONTDUMP
+takes precedence over the bit mask that is set via the
+.I /proc/PID/coredump_filter
+file (see
+.BR core (5)).
+.TP
+.BR MADV_DODUMP " (since Linux 3.4)"
+Undo the effect of an earlier
+.BR MADV_DONTDUMP .
 .SH "RETURN VALUE"
 On success
 .BR madvise ()
< at >< at > -356,4 +374,5 < at >< at > from the system call, as it should).
 .BR mmap (2),
 .BR mprotect (2),
 .BR msync (2)

Re: [PATCH 0/6] Extended file stat system call

Dave Chinner — 2012-04-27T01:06:10

If we are adding per-inode flags, then what do we do with filesystem
specific flags? e.g. XFS has quite a number of per-inode flags that
don't align with any other filesystem (e.g. filestream allocator,
real time file, behaviour inheritence flags, etc), but may be useful
to retrieve in such a call. We currently have an ioctl to get that
information from each inode. Have you thought about how to handle
such flags?

Along the same lines, filesytsems can have different allocation
constraints to IO the filesystem block size - ext4 with it's
bigalloc hack, XFS with it's per-inode extent size hints and the
realtime device, etc. Then there's optimal IO characteristics
(e.g. geometery hints like stripe unit/stripe width for the
allocation policy of that given file) that applications could use
if they were present rather than having to expose them through
ioctls that nobody even knows about...

Perhaps also exposing the project ID for quota purposes, like we do
UID and GID. That way we wouldn't need a filesystem spe

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

Dave Chinner — 2012-04-27T00:51:21

It can be variable for local filesystems, too. XFS will vary the
block size based on the configuration of the inode. e.g. if there is
an extent allocation size hint on the inode, or it's on the realtime
device, and so on. There is no guarantee that from file to file that
it is constant.


More likely it probably needs to be non-zero to prevent applications
doing division by block size from exploding... ;)

Cheers,

Dave.

Re: [PATCH 0/6] Extended file stat system call

Roland McGrath — 2012-04-26T22:05:52

It's certainly possible with symbol versioning, though it seems much more
likely that we'd stick with the existing struct stat and stat* interfaces
and only have the implementation using statx underneath (e.g. for new
machines or kernel ABIs where the kernel stops providing any calls except
for statxat), at least for the foreseeable future.


POSIX requires that st_ino have a useful value for the standard *stat calls.


Thanks,
Roland

Re: [PATCH 0/6] Extended file stat system call

Roland McGrath — 2012-04-26T22:02:42

Names like that were all I had thought of when I said I hadn't thought of
any good ones. ;-)

Re: [PATCH 0/6] Extended file stat system call

David Howells — 2012-04-26T21:57:56


What if the xstat() and struct xstat eventually becomes what userspace uses as
stat() (as a wrapper) and struct stat (if such a thing is possible with glibc
versioning)?  Do older programs that think they're using stat() and don't know
about the extra fields available expect to see a useful value in st_ino?

David

Re: [PATCH 0/6] Extended file stat system call

Roland McGrath — 2012-04-26T18:25:24

I prefer something other than xstat and statx(at) seems acceptable enough.
What I'd really prefer is a name that is less meaninglessly arcane,
but I haven't thought of any good ones.


Thanks,
Roland

Re: [PATCH 0/6] Extended file stat system call

Roland McGrath — 2012-04-26T18:22:02

OK.  It was just worth a look.


Thanks,
Roland

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

Steve French — 2012-04-24T22:08:28

I also would prefer that we simply treat the time granularity as part
of the superblock (mounted volume) ie returned on fstat rather than on
every stat of the filesystem.   For cifs mounts we could conceivably
have different time granularity (1 or 2 second) on mounts to old
servers rather than 100 nanoseconds.

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

J. Bruce Fields — 2012-04-24T21:29:11

It looks like you're including this with *each* time?  But surely
there's no filesystem with different granularity (say) for ctime than
for mtime.  Also, nfsd will want only one time_delta, not one for each
time.

Note also we need to document carefully what this means: I think it
should be the granularity that the filesystem is capable of
representing, but people are sometimes surprised to find out that the
actual time source is usually more coarse-grained than that.

--b.

Re: [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP

Michael Kerrisk — 2012-04-23T22:42:16

Jason,

On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron <jbaron-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org> wrote:

Since we have
MADV_DODUMP
MADV_DONTDUMP
MADV_NODUMP
heading for userspace in 3.4, would you be willing to write patches
for the madvise(2) man page to describe these flags?

See http://www.kernel.org/doc/man-pages/download.html for details on
accessing man-pages Git.

Cheers,

Michael

PS Please also CC linux-api< at > when making API/ABI changes.

Re: [PATCH 0/6] Extended file stat system call

Steve French — 2012-04-19T17:11:11

 stat functions.
<snip>

Even though we can use leases (oplocks) to avoid the roundrtrip, it is
probably too expensive to default to forcing a cache flush, especially
when a common case is to get the file creation time or inode number
information (stable vs volatile).

Would it be better to make the stable vs volatile inode number an attribute
of the volume  or something returned by the proposed xstat?


Today I export these through an psuedo-xattr in cifs.ko, I am curious how
NTFS and FAT export these on linux.


Given the overlap in optional attributes between the network
protocol and local NTFS (and ReFS and to a lesser extent FAT)
I would expect cifs.ko and the ntfs implementations
info to map pretty closely.


You already have support for an indicator for offline files (HSM),
would XSTAT_INFO_OFFLINE be intended for the case
where the network session to the server is disconnected
(and in which you case the application does not want to reconnect)?

Re: [PATCH 2/6] xstat: Ext4: Return extended attributes

Steve French — 2012-04-19T16:03:54

This patch reminds me of a question on time stamps - how can an
application query the time granularity ie sb_s_time_gran for a mount
(e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1
nanosecond for others etc.)

On Thu, Apr 19, 2012 at 9:06 AM, David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org> wrote:

[PATCH 6/6] xstat: eCryptFS: Return extended attributes

David Howells — 2012-04-19T14:07:19

Return extended attributes from the eCryptFS filesystem, dredged up from the
lower filesystem.  XSTAT_INFO_ENCRYPTED is set on the files whose cryptography
is handled by eCryptFS.

Possibly eCryptFS should also set FS_COMPR_FL on its compressed files.

Signed-off-by: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
---

 fs/ecryptfs/inode.c |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index ab35b11..62865e9 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
< at >< at > -1060,13 +1060,23 < at >< at > int ecryptfs_getattr(struct vfsmount *mnt, struct dentry *dentry,
 struct kstat lower_stat;
 int rc;
 
-rc = vfs_getattr(ecryptfs_dentry_to_lower_mnt(dentry),
- ecryptfs_dentry_to_lower(dentry), &lower_stat);
+lower_stat.query_flags = stat->query_flags;
+lower_stat.request_mask = stat->request_mask | XSTAT_BLOCKS;
+rc = vfs_xgetattr(ecryptfs_dentry_to_lower_mnt(dentry),
+  ecryptfs_dentry_to_lower(dentry), &lower_