--
> Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
>
> Kerberos mailing list kerbe...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
ngs and errors of lint(1) fatal...
Ced
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On 25 September 2016 at 02:18, Linus Torvalds
wrote:
> On Sat, Sep 24, 2016 at 4:35 PM, Cedric Blancher
> wrote:
>>>
>>> void *entry = parent->slots[offset];
>>> int siboff = entry - parent->slots;
>>
>> If entry is a pointer
> think there is any huge need to explain what's going on, because the
> "magic" is unconditional.
>
> Willy?
>
> Linus
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
ill make this moot.
>
> (Basically adopting Konstantin's idea for using the *last* entry instead of
> the *first*, and then using entries of the form (offset << 2 |
> RADIX_TREE_INTERNAL_NODE), so we can identify sibling entries without knowing
> the parent pointer, and we can go straight from sibling entry to slot offset
> as a shift rather than as a pointer subtraction).
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
ace/trace.c | 2 -
> mm/filemap.c | 339
> ++
> 9 files changed, 281 insertions(+), 486 deletions(-)
>
> --
> 2.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel&
even more unpleasant ;-/
> We probably can ignore that one (until POSIX learns of its existence),
> thouhg...
I've forwarded your request to the Austin Group (who manage the POSIX stuff).
Ced
--
Cedric Blancher
Institute Pasteur
--
To unsubscribe from this list: send the line "
and even more worse with the
number of CPUS accessing such contested lines.
Ced
--
Cedric Blancher
Institute Pasteur
: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cedric Blancher
Institute Pasteur
does that file+offset hash work when trying to lock different
> ranges? file+offset hashing to determine the lock to use only works
> if we are dealing with fixed size ranges that the locks affect.
> e.g. offset has 4k granularity for a single page faults, but we also
> need to handle 2MB granularity for huge page faults, and IIRC 1GB
> granularity for giant page faults...
>
> What's the plan here?
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> da...@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cedric Blancher
Institute Pasteur
solving these
> issues one-by-one as they come up, that seems like a much better route.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cedric Blancher
Institute Pasteur
11 February 2016 at 11:55, Jan Kara wrote:
> On Wed 10-02-16 23:39:43, Cedric Blancher wrote:
>> AFAIK Solaris 11 uses a sparse tree instead of a array. Solves the
>> scalability problem AND deals with variable page size.
>
> Well, but then you have to have this locking tr
6/intel_sgx/le/include/sgx_encl.h
> create mode 100644 drivers/platform/x86/intel_sgx/le/main.c
> create mode 100644 drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S
> create mode 100644 drivers/platform/x86/intel_sgx/sgx.h
> create mode 100644 drivers/platform/x86/intel_sgx/sgx_encl.c
> create mode 100644 drivers/platform/x86/intel_sgx/sgx_ioctl.c
> create mode 100644 drivers/platform/x86/intel_sgx/sgx_le.c
> create mode 100644 drivers/platform/x86/intel_sgx/sgx_le_proxy_piggy.S
> create mode 100644 drivers/platform/x86/intel_sgx/sgx_main.c
> create mode 100644 drivers/platform/x86/intel_sgx/sgx_page_cache.c
> create mode 100644 drivers/platform/x86/intel_sgx/sgx_util.c
> create mode 100644 drivers/platform/x86/intel_sgx/sgx_vma.c
>
> --
> 2.14.1
>
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
; Thank you for your replay. I have two questions. First can you tell me what
> is the best practice way to store the credential cache and second where can I
> find more informations about the plan to remove the KEYRING from the kernel?
>
> Thorsten
>
> Kerberos mailing list
op that property, making it "if some addresses
> in the buffer(s) we are asked to write are invalid, the write will be
> shortened by up to a PAGE_SIZE from the first such invalid address", making
> writev() rules exactly the same as write() ones. Does anybody have objections
>
15 matches
Mail list logo
