On 29.11.2006 [09:38:28 +1100], David Gibson wrote:
> On Tue, Nov 28, 2006 at 02:18:05PM -0800, Nishanth Aravamudan wrote:
> > On 28.11.2006 [13:51:28 -0800], Nishanth Aravamudan wrote:
> > > On 28.11.2006 [10:41:13 +1100], David Gibson wrote:
> > > > On Mon, Nov 27, 2006 at 12:21:05PM -0800, Nisha
On Tue, Nov 28, 2006 at 02:18:05PM -0800, Nishanth Aravamudan wrote:
> On 28.11.2006 [13:51:28 -0800], Nishanth Aravamudan wrote:
> > On 28.11.2006 [10:41:13 +1100], David Gibson wrote:
> > > On Mon, Nov 27, 2006 at 12:21:05PM -0800, Nishanth Aravamudan wrote:
>
> > > Huh? Setting HUGETLB_PATH sh
On 28.11.2006 [13:51:28 -0800], Nishanth Aravamudan wrote:
> On 28.11.2006 [10:41:13 +1100], David Gibson wrote:
> > On Mon, Nov 27, 2006 at 12:21:05PM -0800, Nishanth Aravamudan wrote:
> > Huh? Setting HUGETLB_PATH should work fine. It even won't have
> > problems with spaces, as long as the do
On 28.11.2006 [10:41:13 +1100], David Gibson wrote:
> On Mon, Nov 27, 2006 at 12:21:05PM -0800, Nishanth Aravamudan wrote:
> > [resending due to user error on my end]
> >
> > On 20.11.2006 [10:45:49 -0800], Dave Hansen wrote:
> > > On Tue, 2006-11-14 at 09:55 -0800, Nishanth Aravamudan wrote:
> > >
On Mon, Nov 27, 2006 at 12:21:05PM -0800, Nishanth Aravamudan wrote:
> [resending due to user error on my end]
>
> On 20.11.2006 [10:45:49 -0800], Dave Hansen wrote:
> > On Tue, 2006-11-14 at 09:55 -0800, Nishanth Aravamudan wrote:
> > > +rm -rf `hugetlbfs_path`/elflink-uid-`id -u`
> >
> > Ju
On 27.11.2006 [11:59:47 -0800], Dave Hansen wrote:
> Nishanth Aravamudan wrote:
> >In any case, how would you ever work around this in bash? We either
> >trust the user or we trust /proc/mounts to be sane. In both cases, if
> >they are not trustable, it's operator error (at the admin level,
> >pres
[resending due to user error on my end]
On 20.11.2006 [10:45:49 -0800], Dave Hansen wrote:
> On Tue, 2006-11-14 at 09:55 -0800, Nishanth Aravamudan wrote:
> > +rm -rf `hugetlbfs_path`/elflink-uid-`id -u`
>
> Just a note: this will break with spaces in hugetlbfs_path. Even worse,
> if somebod
Nishanth Aravamudan wrote:
> In any case, how would you ever work around this in bash? We either
> trust the user or we trust /proc/mounts to be sane. In both cases, if
> they are not trustable, it's operator error (at the admin level,
> presumably).
"$(hugetlbfs_path)" or "`hugetlbfs_path" would
On Tue, 2006-11-14 at 09:55 -0800, Nishanth Aravamudan wrote:
> On 14.11.2006 [12:29:01 +1100], David Gibson wrote:
> diff --git a/tests/run_tests.sh b/tests/run_tests.sh
> index d0be9d1..adda47c 100755
> --- a/tests/run_tests.sh
> +++ b/tests/run_tests.sh
> @@ -75,10 +75,15 @@ elfshare_test () {
>
On 14.11.2006 [12:29:01 +1100], David Gibson wrote:
> On Mon, Nov 13, 2006 at 04:46:14PM -0800, Nishanth Aravamudan wrote:
> > On 02.11.2006 [11:52:41 +1100], David Gibson wrote:
> > > On Tue, Oct 31, 2006 at 07:26:12AM -0800, Nishanth Aravamudan wrote:
> >
> >
> >
> > > Ok. I tend to think it
On Mon, Nov 13, 2006 at 04:46:14PM -0800, Nishanth Aravamudan wrote:
> On 02.11.2006 [11:52:41 +1100], David Gibson wrote:
> > On Tue, Oct 31, 2006 at 07:26:12AM -0800, Nishanth Aravamudan wrote:
>
>
>
> > Ok. I tend to think it will get its testing fastest if we merge into
> > the git tree now
On 02.11.2006 [11:52:41 +1100], David Gibson wrote:
> On Tue, Oct 31, 2006 at 07:26:12AM -0800, Nishanth Aravamudan wrote:
> Ok. I tend to think it will get its testing fastest if we merge into
> the git tree now. Again, we can branch from 1.0.1 if we need to make
> more maintenance releases f
On 02.11.2006 [11:52:41 +1100], David Gibson wrote:
> On Tue, Oct 31, 2006 at 07:26:12AM -0800, Nishanth Aravamudan wrote:
> > On 31.10.2006 [13:18:18 +1100], David Gibson wrote:
> > > On Mon, Oct 30, 2006 at 04:01:54PM -0800, Nishanth Aravamudan wrote:
> > > > On 31.10.2006 [10:26:47 +1100], David
On Tue, Oct 31, 2006 at 07:43:09AM -0800, Nishanth Aravamudan wrote:
> On 31.10.2006 [13:16:34 +1100], David Gibson wrote:
[snip]
> > > So you can just return -1 here or something... Why are you aborting by
> > > the way? Shouldn't it just fail to share? [1]
> >
> > No. It's an abort() for simpli
On 31.10.2006 [13:18:18 +1100], David Gibson wrote:
> On Mon, Oct 30, 2006 at 04:01:54PM -0800, Nishanth Aravamudan wrote:
> > On 31.10.2006 [10:26:47 +1100], David Gibson wrote:
> > > On Mon, Oct 30, 2006 at 10:26:56AM -0800, Nishanth Aravamudan wrote:
> > > > On 30.10.2006 [15:56:43 +1100], David
On 31.10.2006 [13:16:34 +1100], David Gibson wrote:
> On Mon, Oct 30, 2006 at 01:45:41PM -0800, Nishanth Aravamudan wrote:
> > On 30.10.2006 [15:56:43 +1100], David Gibson wrote:
> > > Latest daemon removal path. Updated to apply clean on top of the
> > > latest changes in the git tree, otherwise
On Mon, Oct 30, 2006 at 01:45:41PM -0800, Nishanth Aravamudan wrote:
> On 30.10.2006 [15:56:43 +1100], David Gibson wrote:
> > Latest daemon removal path. Updated to apply clean on top of the
> > latest changes in the git tree, otherwise nothing new.
> >
> > Now that 1.0.1 is out, are we ready to
On Mon, Oct 30, 2006 at 04:01:54PM -0800, Nishanth Aravamudan wrote:
> On 31.10.2006 [10:26:47 +1100], David Gibson wrote:
> > On Mon, Oct 30, 2006 at 10:26:56AM -0800, Nishanth Aravamudan wrote:
> > > On 30.10.2006 [15:56:43 +1100], David Gibson wrote:
> > > > Latest daemon removal path. Updated
On 31.10.2006 [10:26:47 +1100], David Gibson wrote:
> On Mon, Oct 30, 2006 at 10:26:56AM -0800, Nishanth Aravamudan wrote:
> > On 30.10.2006 [15:56:43 +1100], David Gibson wrote:
> > > Latest daemon removal path. Updated to apply clean on top of the
> > > latest changes in the git tree, otherwise
On Mon, Oct 30, 2006 at 10:26:56AM -0800, Nishanth Aravamudan wrote:
> On 30.10.2006 [15:56:43 +1100], David Gibson wrote:
> > Latest daemon removal path. Updated to apply clean on top of the
> > latest changes in the git tree, otherwise nothing new.
> >
> > Now that 1.0.1 is out, are we ready to
On 30.10.2006 [15:56:43 +1100], David Gibson wrote:
> Latest daemon removal path. Updated to apply clean on top of the
> latest changes in the git tree, otherwise nothing new.
>
> Now that 1.0.1 is out, are we ready to merge this? Remember that we
> can make a git branch to hold strictly-mainten
On 30.10.2006 [15:56:43 +1100], David Gibson wrote:
> Latest daemon removal path. Updated to apply clean on top of the
> latest changes in the git tree, otherwise nothing new.
>
> Now that 1.0.1 is out, are we ready to merge this? Remember that we
> can make a git branch to hold strictly-mainten
Latest daemon removal path. Updated to apply clean on top of the
latest changes in the git tree, otherwise nothing new.
Now that 1.0.1 is out, are we ready to merge this? Remember that we
can make a git branch to hold strictly-maintenance revisions of
1.0/1.0.1 for Red Hat, if necessary.
Index:
And another. I have now implemented the subdirectories-in-hugetlbfs
model for security. There are basically two options for setting up
sharing:
- Set up your own directory, with whatever permission model
you want, and explicitly point libhugetlbfs there by setting
HUGETLB_SHARE_PATH. If
Latest version of the daemon killing patch. I've cleaned up the
previously rather contorted code paths for sharing in elflink.c. Next
step per-user hugetlbfs directories. For sure, this time ;-).
Index: libhugetlbfs/HOWTO
===
--- l
And another revised version. Synchonization is even simpler, and I'm
rather more convinced it's correct this time. Works as follows:
- first open 'filename.tmp' with O_EXCL
- second open 'filename' with O_RDONLY (even if the first open
succeeded).
Then:
- If both
Here is a revised version of Nish's patch to abolish hugetlbd. The
main change is an improved method of synchronising the preparing
process with other sharers: it's simpler than flock() and I *think*
it's race free (make that thought it was race free, see below). It
works like this:
1. ea
27 matches
Mail list logo
