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>] [day] [month] [year] [list]
Message-Id: <1161009890.24237.36.camel@localhost.localdomain>
Date:	Mon, 16 Oct 2006 15:44:50 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Constantine Gavrilov <constg@...sters.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Would SSI clustering extensions be of interest to
	kernelcommunity?

Ar Llu, 2006-10-16 am 16:07 +0200, ysgrifennodd Constantine Gavrilov:
> SSI intrudes kernel in two places: a) IO system calls, b ) page fault
> code for shared memory pages.
> 
> a) IO system calls are "packed" and forwarded to the "home" node,
> where original syscall code is executed. 
> b) A hook is inserted into page fault code that brings shared memory
> pages from other nodes when necessary.
> 
> Apart from these two hooks, SSI code is a "standalone" kernel API
> add-on ("add", not "change").
> 
> Currently, we can do both "intrusions" from the kernel module. I
> assume that if we submit code, you will require a kernel patch that
> explicitly calls our hooks. 

Yep. Thats probably the most critical single thing to review.
> 
> Also, continuous SSI in-kernel support may require SSI changes in the
> following cases: a) new fields in task struct that reflect process
> state (may affect task migration), b) changes in the page fault
> mechanism (may effect SSI shared memory code that brings and
> invalidates pages), c) addition of new system calls (may require
> implementation of  SSI suspport for them).

SSI changes triggered from core changes are fairly expected I think
because you need to serialize new objects.
-
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