David Howells wrote:
> Partially revert commit 41c89b64d7184a780f12f2cccdabe65cb2408893:
>
> Author: Petko Manolov
> Date: Wed Dec 2 17:47:55 2015 +0200
> IMA: create machine owner and blacklist keyrings
>
> The problem is that prep->trusted is
Mimi Zohar wrote:
> Once the builtin keys are loaded onto the system keyring, isn't the
> system keyring locked?
No.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
I appreciate what the patch is trying to do, I don't think this is
quite the right solution.
Signed-off-by: David Howells
cc: Petko Manolov
cc: Mimi Zohar
cc: keyri...@vger.kernel.org
---
crypto/asymmetric_keys/x509_public_key.c |2 --
1 file changed, 2 deletions(-)
diff --git a/cryp
Mimi Zohar wrote:
> The x509_validate_trust() was originally added for IMA to ensure, on a
> secure boot system, a certificate chain of trust rooted in hardware.
> The IMA MOK keyring extends this certificate chain of trust to the
> running system.
The problem is that because 'trusted' is a bool
Mimi Zohar wrote:
> You're missing Petko's patch:
> 41c89b6 IMA: create machine owner and blacklist keyrings
It should also be cc'd to the keyrings mailing list.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger
Mimi Zohar wrote:
> You're missing Petko's patch:
> 41c89b6 IMA: create machine owner and blacklist keyrings
Hmmm... This is wrong. x509_key_preparse() shouldn't be polling the IMA MOK
keyring under all circumstances.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-s
bility check on a
self-signed cert then succeeding. This is most likely to happen when a
duplicate of the certificate is already on the trust keyring - in which
case it shouldn't be a problem.
Signed-off-by: David Howells
cc: David Woodhouse
cc: Mimi Zohar
---
crypto/asymmetric_keys/x509
David Howells wrote:
> If a certificate is self-signed, don't bother checking the validity of the
> signature. The cert cannot be checked by validation against the next one
> in the chain as this is the root of the chain. Trust for this certificate
> can only be determi
e RSA module when the result of calculating "m =
s^e mod n" is checked.
Signed-off-by: David Howells
cc: David Woodhouse
cc: Mimi Zohar
---
crypto/asymmetric_keys/x509_public_key.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/crypto/
e RSA module when the result of calculating "m =
s^e mod n" is checked.
Signed-off-by: David Howells
cc: David Woodhouse
cc: Mimi Zohar
---
crypto/asymmetric_keys/x509_public_key.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/crypto/
Signed-off-by: David Howells
cc: Arnd Bergmann
cc: David Woodhouse
cc: John Stultz
---
crypto/asymmetric_keys/x509_cert_parser.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
ind
nt them as valid parameters.
These facility will be used by the X.509 parser. Doing it in mktime64()
makes the policy common to the whole kernel and easier to find.
Signed-off-by: David Howells
cc: Arnd Bergmann
cc: John Stultz
---
kernel/time/time.c |9 -
1 file changed, 8 insert
udolf Polzer
Signed-off-by: David Howells
cc: David Woodhouse
cc: John Stultz
cc: Arnd Bergmann
---
crypto/asymmetric_keys/x509_cert_parser.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_par
00". It's also easier to read.
(2) The default month length for any February where the year doesn't
divide by four exactly is obtained from the month_length[] array where
the value is 29, not 28.
This is fixed by altering the table.
Reported-by: Rudolf Polzer
Sig
Here's a set of patches that fix X.509 time handling in three ways:
(1) Fix leap year handling.
(2) Add leap second handling (where you get a time of 23:59:60).
(3) Add end-of-day midnight encoding (where you get a time of 24:00:00).
David
---
David Howells (4):
X.509: Fix leap
Linus Torvalds wrote:
> Side note: the key handling extra checks seem pretty pointless too.
Except that it has been argued that they have to be there or someone can use
dates that contribute to the signature to fake a signed content. Admittedly
being able to have a seconds=60 value in somewhere
Linus Torvalds wrote:
> > David Howells (7):
> > Handle leap seconds in mktime64()
>
> This one is completely wrong.
>
> Leap seconds are inserted *at* the minute, not at the secodn before the
> minute.
>
> So this code:
>
> + /* Handle
Josh Boyer wrote:
> Should this also be Cc'd to stable?
Argh. Probably.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
h can be
summarised as:
BUG: unable to handle kernel NULL pointer dereference at
0010
IP: [] user_read+0x56/0xa3
...
Call Trace:
[] keyctl_read_key+0xb6/0xd7
[] SyS_keyctl+0x83/0xe0
[] entry_SYSCALL_64_fastpath+0x12/0x6f
Reported-
rkers from all the parameters since
they don't really achieve anything and we do need to alter the sec
parameter.
Signed-off-by: David Howells
cc: John Stultz
cc: Arnd Bergmann
cc: sta...@vger.kernel.org
---
include/linux/time.h | 13 ++---
kernel/time/time.c | 14 +++--
d if the
Issuer and Subject names differ.
Signed-off-by: David Howells
cc: David Woodhouse
---
crypto/asymmetric_keys/x509_public_key.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_public_key.c
b/crypto/asymmetric_keys/x509_pub
00". It's also easier to read.
(2) The default month length for any February where the year doesn't
divide by four exactly is obtained from the month_length[] array where
the value is 29, not 28.
This is fixed by altering the table.
Reported-by: Rudolf Polzer
Sig
Reported-by: Rudolf Polzer
Signed-off-by: David Howells
cc: David Woodhouse
cc: John Stultz
cc: Arnd Bergmann
cc: sta...@vger.kernel.org
---
crypto/asymmetric_keys/x509_cert_parser.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_cer
8601 dates.
Signed-off-by: David Howells
cc: John Stultz
cc: Arnd Bergmann
cc: sta...@vger.kernel.org
---
kernel/time/time.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/time/time.c b/kernel/time/time.c
index 1858b10602f5..56e7ada38471 100644
--- a/kernel/t
().
Without this patch, certain X.509 certificates will be rejected and could
lead to an unbootable kernel.
Reported-by: Rudolf Polzer
Signed-off-by: David Howells
cc: David Woodhouse
cc: John Stultz
cc: Arnd Bergmann
cc: sta...@vger.kernel.org
---
crypto/asymmetric_keys/x509_cert_parser.c | 12
Here's a set of patches that fix X.509 time handling in three ways:
(1) Fix leap year handling.
(2) Add leap second handling (where you get a time of 23:59:60).
(3) Add end-of-day midnight encoding (where you get a time of 24:00:00).
David
---
David Howells (5):
X.509: Fix leap
Greg Kroah-Hartman wrote:
> David, any reason you didn't put a cc: stable in the commit for it to be
> picked up in the stable releases?
I did cc it to stable.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.k
Paul Gortmaker wrote:
> Paul Gortmaker (2):
> security/keys: make big_key.c explicitly non-modular
> security/integrity: make ima/ima_mok.c explicitly non-modular
Note that I only see patch 1. Note also that keyri...@linux-nfs.org should
now be keyri...@vger.kernel.org.
David
--
To unsubsc
David Howells wrote:
> > the leap second support still looks a bit suspect, as mktime64 will convert
> > mm/dd/ HH/MM/60 and mm/dd/ HH/MM+1/00 to the same time64_t,
> > essentially meaning that two different inputs can yield the same output,
> > possibly violating
Rudolf Polzer wrote:
> Also, while at it - apparently hour 24 is allowed by ISO 8601 too as long as
> minutes and seconds are zero, leading to even more non-canonicality... can
> you check whether this is also valid ASN.1 then?
Sorry, I missed this bit. The ASN.1 spec says that GeneralizedTime
Petko Manolov wrote:
> 0) does keyrings keep a timestamp when created or last updated? David?
No.
> 0) is crucial. If there is no such thing as "time of the last update" for
> keyrings i guess we'll either have to implement it or use another mechanism
> to get similar result.
You haven
Rudolf Polzer wrote:
> the leap second support still looks a bit suspect, as mktime64 will convert
> mm/dd/ HH/MM/60 and mm/dd/ HH/MM+1/00 to the same time64_t,
> essentially meaning that two different inputs can yield the same output,
> possibly violating ASN.1 CER and DER rules.
That's
ly supports a seconds value in the range 00-59.
Reported-by: Rudolf Polzer
Signed-off-by: David Howells
---
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 021d39c0ba75..f57c3c1b5ae7 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.
Mehmet Kayaalp wrote:
> Place a system_extra_cert buffer of configurable size, right after the
> system_certificate_list, so that inserted keys can be readily processed by
> the existing mechanism.
Do you have a particular use case for this?
David
--
To unsubscribe from this list: send the line
James Morris wrote:
> Is this triggerable by normal users?
Yes.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi James,
Can this be passed straight to Linus please?
Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d or it will fail with EINVAL before getting to the bit that
will crashes.
Reported-by: Dmitry Vyukov
Signed-off-by: David Howells
Acked-by: Mimi Zohar
---
security/keys/encrypted-keys/encrypted.c |2 ++
security/keys/trusted.c |5 -
security/keys/user_defined.c
Al Viro wrote:
> All of them? I see two kinds there - one is magical symlink (recognized
> by contents in afs_iget()), another is this autocell thing, the latter
> having no ->readlink(). Both serve as automount points, don't they?
The "autocell" thing is where you don't have an AFS file of th
Hi Marcel, Mimi, Tadeus,
I want to consider adding or doing the following bits to the keyrings
facility, aiming for the next merge window:
(*) Bring in the patches that I posted to change how the trust model on a
keyring works.
The model will then be that keys aren't automatically mar
Al Viro wrote:
> How would those tools know that this particular pathname _is_ a magical
> symlink? Sure, if you see a symlink with body that starts with % or #,
> you could figure out that it's not a regular one and go parse the body,
> but for stat(2) it looks like a directory. Do those tools
Al Viro wrote:
> 3) normally, readlink(2) fails for non-symlinks. Moreover, according to
> POSIX it should do so (with -EINVAL). There is a pathological case when
> it succeeds for a directory, though. Namely, one of the kinds of AFS
> "mountpoints".
All AFS mountpoints are magic symlinks tha
doing the following:
cat <
Signed-off-by: David Howells
Tested-by: Mimi Zohar
Acked-by: David Woodhouse
---
crypto/asymmetric_keys/x509_cert_parser.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/cry
doing the following:
cat <
Signed-off-by: David Howells
Tested-by: Mimi Zohar
Acked-by: David Woodhouse
---
crypto/asymmetric_keys/x509_cert_parser.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/cry
doing the following:
cat <
Signed-off-by: David Howells
Tested-by: Mimi Zohar
Acked-by: David Woodhouse
---
crypto/asymmetric_keys/x509_cert_parser.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/cry
James Morris wrote:
> Have these been in next yet?
No.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
15:18:36
+0100)
Keyring changes for next
--------
David Howells (3):
KEYS: Provide a script to extract the sys cert list from a vmlinux file
KEYS: Provide a script to extract a module signature
KEYS: Merge the type-spe
Add key identifier pointers to public_key_signature struct so that they can
be used to retain the identifier of the key to be used to verify the
signature in both PKCS#7 and X.509.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/public_key.c |2 ++
include/crypto/public_key.h
Retain the key verification data (ie. the struct public_key_signature)
including the digest and the key identifiers.
Note that this means that we need to take a separate copy of the digest in
x509_get_sig_params() rather than lumping it in with the crypto layer data.
Signed-off-by: David Howells
-only keyring being searched.
(3) KEY_ALLOC_TRUSTED now acts as an override. If this is passed to
key_create_or_update() then the ->verify_trust() method will be
ignored and the key will be added anyway.
Signed-off-by: David Howells
---
Documentation/security/keys.txt
Make the determination of the trustworthiness of a key dependent on whether
a key that can verify it is present in the ring of trusted keys rather than
whether or not the verifying key has KEY_FLAG_TRUSTED set.
Signed-off-by: David Howells
---
certs/system_keyring.c | 13
function. If the callback is not required, that can be set to NULL.
The function is now called verify_pkcs7_signature() to contrast with
verify_pefile_signature() and the definitions of both have been moved into
linux/verification.h along with the key_being_used_for enum.
Signed-off-by: David Howells
Allow authentication data to be stored in an asymmetric key in the 4th
element of the key payload and provide a way for it to be destroyed.
For the public key subtype, this will be a public_key_signature struct.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/asymmetric_type.c |7
git/log/?h=keys-trust
and are tagged with:
keys-trust-20151021
David
---
David Howells (10):
KEYS: Generalise system_verify_data() to provide access to internal
content
PKCS#7: Make trust determination dependent on contents of trust keyring
KEYS: Add facility to
We just can't add it to a ring
of trusted keys or follow it further up the chain of trust.
Making these checks earlier allows x509_check_signature() to be removed and
replaced with direct calls to public_key_verify_signature().
Signed-off-by: David Howells
---
crypto/asymmetric_
means we can use
public_key_free() to get rid of the signature record.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/pkcs7_parser.c | 38 +++-
crypto/asymmetric_keys/pkcs7_parser.h | 10 +++---
crypto/asymmetric_keys/pkcs7_trust.c |4 +--
crypto
Move the X.509 trust validation code out to its own file so that it can be
generalised.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/Makefile |2
crypto/asymmetric_keys/public_key_trust.c | 192 +
crypto/asymmetric_keys/x509_parser.h
ich it could
be secondarily linked.
To accomplish this, the authentication data associated with the key source
must now be retained. For an X.509 cert, this means the contents of the
AuthorityKeyIdentifier and the signature data.
Signed-off-by: David Howells
---
certs/s
These patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-next
And tagged with:
keys-next-20151021
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to ma
e key identifier contents.
(*) "-s". Dumps the cryptographic signature contents.
In the case that the signature is a PKCS#7 (or CMS) message, -n and -k will
print a warning to stderr and dump nothing to stdout, but will otherwise
complete okay; the entire PKCS#7/CMS message will
From: Insu Yun
key->description and key->index_key.description are same because
they are unioned. But, for readability, using same name for
duplication and validation seems better.
Signed-off-by: Insu Yun
Signed-off-by: David Howells
---
security/keys/key.c |2 +-
1 file chan
Certificate list at file offset 0x141c540
If vmlinux contains symbols then that is used rather than System.map - even
if one is given.
Signed-off-by: David Howells
---
scripts/extract-sys-certs.pl | 144 ++
1 file changed, 144 insertions(+)
create mode 100755
re
entry at the same time. I didn't bother to dig through git history to
see when it moved, since it is just a minor annoyance at most.
Cc: David Woodhouse
Cc: keyri...@linux-nfs.org
Signed-off-by: Paul Gortmaker
Signed-off-by: David Howells
---
certs/.gitignore |4
kernel/.gi
Merge the type-specific data with the payload data into one four-word chunk
as it seems pointless to keep them separate.
Use user_key_payload() for accessing the payloads of overloaded
user-defined keys.
Signed-off-by: David Howells
cc: linux-c...@vger.kernel.org
cc: ecryp...@vger.kernel.org
cc
From: Geliang Tang
There is no need to make a flag to tell that this memory is allocated by
kmalloc or vmalloc. Just use kvfree to free the memory.
Signed-off-by: Geliang Tang
Signed-off-by: David Howells
---
security/keys/keyctl.c |8 +---
1 file changed, 1 insertion(+), 7
Petko Manolov wrote:
> > > As far as i know there is no concept of write-once to a keyring in the
> > > kernel. David will correct me if i am wrong. I wonder how hard would
> > > it be to add such functionality, in case it is missing?
> >
> > Not hard, particularly if it's only an attribute th
Mimi Zohar wrote:
> > I need to think about this. Should -EKEYREVOKED be the same as -ENOKEY in
> > this case? I guess the end result is pretty much the same from IMA view
> > point, but there may be a requirement to list all revoked keys...
>
> When checking the blacklist, getting -EKEYREVOKE
Petko Manolov wrote:
> As far as i know there is no concept of write-once to a keyring in the
> kernel. David will correct me if i am wrong. I wonder how hard would it be
> to add such functionality, in case it is missing?
Not hard, particularly if it's only an attribute that the kernel can se
Mimi Zohar wrote:
> Thinking about the blacklist keyring some more...
Are we talking about a blacklist keyring that userspace can use - or can it be
only usable by the kernel?
> My concern is more that keys can be added and removed at run time from
> either of the .ima or the ima_mok keyrings.
ioned with
keyring metadata.
Now the kernel gives an error:
request_key("keyring", "#selinux,bdekeyring", "keyring",
KEY_SPEC_USER_SESSION_KEYRING) = -1 EPERM (Operation not permitted)
Signed-off-by: David Howells
---
security/keys/request_key.c |3 ++
m_fork+0x3f/0x70
[] ? kthread_create_on_node+0x1c2/0x1c2
Note the value in RAX. This is a 32-bit representation of -ENOKEY.
The solution is to only call ->destroy() if the key was successfully
instantiated.
Reported-by: Dmitry Vyukov
Signed-off-by: David Howells
Tested-by: Dmitry Vyukov
---
okay with patch (2) being deferred to the next merge window if we're only
fixing security bugs at this time upstream.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
David
---
David Howells (2):
KEYS:
Dmitry Vyukov wrote:
> Do you mean in addition or instead of the previous one? From your
> description, it sounds like it alone should prevent the crash.
I'm going to submit them both, so if you could test them together. You're
right, though, I think this should also prevent the crash.
David
-
previous one also?
Thanks,
David
---
commit 27874345bb8d2c39f3d493607a86ecbfcb100405
Author: David Howells
Date: Mon Oct 19 11:20:28 2015 +0100
KEYS: Don't permit request_key() to construct a new keyring
If request_key() is used to find a keyring, only do the search part -
Dmitry Vyukov wrote:
> Yes, sure. Do I need to say something like:
>
> Tested-by: Dmitry Vyukov
>
> in future?
That helps:-)
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Dmitry Vyukov wrote:
> > Does the attached patch fix it for you?
>
> Yes, it fixes the crash for me.
Can I put you down as a Tested-by?
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordom
Hi Jarkko,
For some reason I don't see patch 1.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Insu Yun wrote:
> key->description and key->index_key.description are same because
> they are unioned. But, for readability, using same name for
> duplication and validation seems better.
>
> Signed-off-by: Insu Yun
I've applied this, but I've changed the subject line to:
keys: Be mo
Insu Yun wrote:
> Thanks David. Then it is not a bug.
> It's a pure question.
> Why use different name for allocation and check?
> For me, it is quite confusing.
Either I didn't notice at the time, or the shorter variant is the original.
If you want to give me a patch making it consistent, fe
Does the attached patch fix it for you?
David
---
commit a7609e0bb3973d6ee3c9f1ecd0b6a382d99d6248
Author: David Howells
Date: Thu Oct 15 17:21:37 2015 +0100
KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring
The following sequence of commands
Insu Yun wrote:
> kmemdup return value is saved in 'key->index_key.description', not
> 'key->descrption' and kmemdup can be failed in memory pressure.
> Therefore, key->index_key.description should be checked.
The fields are unioned. It makes no difference.
David
--
To unsubscribe from this li
Dmitry Vyukov wrote:
> RAX: ff82
This is the value that matters. It would appear to be -ENOKEY and would be in
key->type_data.reject_error, I think.
David
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> I need to respond to this in pieces... first the bit that is bugging
> me:
>
> > > * two new page flags
> >
> > I need to keep track of two bits of per-cached-page information:
> >
> > (1) This page is known by the cache, and that the cache must b
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Monday 25 February 2008 15:19, David Howells wrote:
> > So I guess there's a problem in cachefiles's efficiency - possibly due
> > to the fact that it tries to be fully asynchronous.
>
> OK, not just my ima
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> This factor of four (even worse on XFS, not quite as bad on Ext3) is
> worth ruminating upon. Is all of the difference explained by avoiding
> seeks on the server, which has the files in memory?
Here are some more stats for you to consider:
(1) Cop
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> I am eventually going to suggest cutting the backing filesystem entirely out
> of the picture,
You still need a database to manage the cache. A filesystem such as Ext3
makes a very handy database for four reasons:
(1) It exists and works.
(2) It h
Chris Mason <[EMAIL PROTECTED]> wrote:
> Thanks for trying this, of course I'll ask you to try again with the latest
> v0.13 code, it has a number of optimizations especially for CPU usage.
Here you go. The numbers are very similar.
David
=
FEW BIG FILES TEST O
David Howells <[EMAIL PROTECTED]> wrote:
> > > Have you got before/after benchmark results?
> >
> > See attached.
>
> Attached here are results using BTRFS (patched so that it'll work at all)
> rather than Ext3 on the client on the partition backing the
Chris Mason <[EMAIL PROTECTED]> wrote:
> > The interesting case is where the disk cache is warm, but the pagecache is
> > cold (ie: just after a reboot after filling the caches). Here, for the two
> > big files case, BTRFS appears quite a bit better than Ext3, showing a 21%
> > reduction in time
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> > +static int smack_task_kernel_act_as(struct task_struct *p,
> > + struct task_security *sec, u32 secid)
> > +{
> > + return -ENOTSUPP;
> > +}
> ...
> > +static int smack_task_create_files_as(struct task_struct *p,
> > +
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > The way the client works is like this:
>
> Thanks for the excellent ascii art, that cleared up the confusion right
> away.
You know what they say about pictures... :-)
> > What are you trying to do exactly? Are you actually playing with it, or
> >
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> When you say Ext3 cache vs NFS cache is the first on the server and the
> second on the client?
The filesystem on the server is pretty much irrelevant as long as (a) it
doesn't change, and (b) all the data is in memory on the server anyway.
The way t
David Howells <[EMAIL PROTECTED]> wrote:
> > Have you got before/after benchmark results?
>
> See attached.
Attached here are results using BTRFS (patched so that it'll work at all)
rather than Ext3 on the client on the partition backing the cache.
Note that I didn
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> Have you got before/after benchmark results?
See attached.
These show a couple of things:
(1) Dealing with lots of metadata slows things down a lot. Note the result of
looking and reading lots of small files with tar (the last result). The
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > These patches add local caching for network filesystems such as NFS.
>
> Have you got before/after benchmark results?
I need to get a new hard drive for my test machine before I can go and get
some more up to date benchmark results. It does seem, h
Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> Seems *really* weird that every time you send this, patch 6 doesn't seem
> to reach me in any of my mailboxes... (did get it from the url
> you listed)
It's the largest of the patches, so that's not entirely surprising. Hence why
I included the URL t
ng and give
a warning into the kernel log.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
fs/nfs/client.c |2 ++
fs/nfs/internal.h |1 +
fs/nfs/super.c| 25 +
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/client.c
Add read context retention so that FS-Cache can call back into NFS when a read
operation on the cache fails EIO rather than reading data. This permits NFS to
then fetch the data from the server instead using the appropriate security
context.
Signed-off-by: David Howells <[EMAIL PROTEC
Add some new NFS I/O event counters for FS-Cache events. They have to be
added as byte counters because I may need to be able to increase the numbers
by more than 1 at a time.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
fs/nfs/iostat.h |7 +++
1 files changed, 7 inse
Store pages from an NFS inode into the cache data storage object associated
with that inode.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
fs/nfs/fscache.c | 26 ++
fs/nfs/fscache.h | 16
fs/nfs/read.c|5 +
3 files chang
.
Supply a generic implementation for this that uses the write_begin() and
write_end() address_space operations to bind a copy directly into the page
cache.
Hook the Ext2 and Ext3 operations to the generic implementation.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
fs/ext2/inode.c
1 - 100 of 393 matches
Mail list logo
