On Mon, Aug 1, 2016 at 5:04 AM, Matt Fleming wrote:
>
> On Sun, 24 Jul, at 10:27:49AM, SF Markus Elfring wrote:
> > From: Markus Elfring
> > Date: Sun, 24 Jul 2016 10:16:56 +0200
> >
> > The dma_pool_destroy() function tests whether its argument is NULL
> > and then returns immediately. Thus the
Hi Jean,
On Wed, May 14, 2014 at 12:23 PM, Jean Delvare wrote:
> Hi Mike,
>
> On Wed, 14 May 2014 08:52:36 -0700, Mike Waychison wrote:
>> On Wed, May 14, 2014 at 2:23 AM, Jean Delvare wrote:
>> > Sorry for joining the party a little late but I am just discovering t
Hi Jean,
On Wed, May 14, 2014 at 2:23 AM, Jean Delvare wrote:
> Hi Mike, Bjorn,
>
> Sorry for joining the party a little late but I am just discovering the
> dmi-sysfs kernel module. I have to admit that I am very curious about
> why it was needed. What does it let you achieve that you couldn't
>
Thanks Michel!
Acked-by: Mike Waychison
On Tue, Jan 28, 2014 at 5:06 AM, Michel Lespinasse wrote:
> Two small fixes for google firmware drivers.
>
> The patches are against v3.13; I am proposing this for inclusion to v3.14.
>
> Michel Lespinasse (2):
> firmware: fix goo
t results in a recursive dependency:
>>
>> arch/arm/Kconfig:1845:error: recursive dependency detected!
>> arch/arm/Kconfig:1845:symbol DMI depends on EFI
>>
>> Fix by changing the 'select EFI' to a 'depends on EFI'.
>>
>> Signed-off-by:
require access to __efivars.
>
> Note that because of the Kconfig rules, we don't need to use any kind of
> synchronisation primitive in register_efivars() - it's not possible to compile
> more than one set of EFI variable operations into the kernel.
>
> Cc: Tom Gun
fwiw, I was tempted to rename these to ucs2_*() last time I was here.
Reviewed-by: Mike Waychison
On Thu, Apr 4, 2013 at 5:18 AM, Matt Fleming wrote:
> From: Matt Fleming
>
> There are currently two implementations of the utf16 string functions.
> Somewhat confusingly, they'
Series Acked-by: Mike Waychison
Tony: Did you want to pull this?
On Thu, Nov 1, 2012 at 3:59 PM, Seiji Aguchi wrote:
> Changelog
>
> v3 -> v4
>- Rebase to 3.7-rc3
>- Add ctime to an argument of efi_pstore_erase to build successfully
> in case where CONFIG
On Tue, Oct 30, 2012 at 8:29 AM, Michael S. Tsirkin wrote:
> On Tue, Sep 11, 2012 at 12:10:18AM +0300, Michael S. Tsirkin wrote:
>> > On the plus side, having an exit taken here on each page turns out to
>> > be relatively cheap, as the vmexit from the page fault should be
>> > faster to process a
On Fri, Oct 26, 2012 at 2:43 PM, Seiji Aguchi wrote:
> [Issue]
>
> A format of variable name has been updated to type, id, count and ctime
> to support holding multiple logs.
>
> Format of current variable name
> dump-type0-1-2-12345678
>
> type:0
> id:1
> count:2
> ctime:12345678
>
> On
On Fri, Oct 26, 2012 at 2:43 PM, Seiji Aguchi wrote:
> [Issue]
>
> A format of variable name has been updated to type, id, count and ctime
> to support holding multiple logs.
>
> Format of current variable name
> dump-type0-1-2-12345678
>
> type:0
> id:1
> count:2
> ctime:12345678
>
> On
On Thu, Oct 25, 2012 at 1:51 PM, Seiji Aguchi wrote:
>> So doesn't this break erasing of existing dumps in pstore-efivars?
>> Unless efi_pstore_read still understands the older variable name formats,
>> users will be stranded with dumps consuming space in
>> efivars that aren't exported via pstor
On Thu, Oct 25, 2012 at 1:03 PM, Seiji Aguchi wrote:
>> > - list_del(&found->list);
>> > + sprintf(name, "dump-type%u-%u-%lu", type, part,
>> > + get_seconds());
>>
>> Actually, nothing seems to be ensuring that the value used here ends up
>> being the same as th
On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi wrote:
> [Issue]
>
> Currently, efi_pstore driver simply overwrites existing panic messages in
> NVRAM.
> So, in the following scenario, we will lose 1st panic messages.
>
> 1. kernel panics.
> 2. efi_pstore is kicked and writes panic messages to NVRA
Acked-by: Mike Waychison
On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi wrote:
> [Issue]
>
> Currently, efi_pstore driver simply overwrites existing panic messages in
> NVRAM.
> So, in the following scenario, we will lose 1st panic messages.
>
> 1. kernel panics.
> 2.
Acked-by: Mike Waychison
On Wed, Oct 24, 2012 at 6:51 PM, Seiji Aguchi wrote:
> [Issue]
>
> As discussed in a thread below, Running out of space in EFI isn't a
> well-tested scenario.
> And we wouldn't expect all firmware to handle it gracefully.
> http:/
On Fri, Oct 5, 2012 at 12:02 PM, Seiji Aguchi wrote:
> [Problem]
>
> Currently, a variable name, which distinguishes each entry, consists of type,
> id and ctime.
> But if multiple events happens in a short time, a second/third event may fail
> to log because
> efi_pstore can't distinguish each
Resending as text. See below.
On Fri, Oct 5, 2012 at 12:01 PM, Seiji Aguchi wrote:
> [Problem]
>
> Currently, efi_pstore driver simply overwrites existing panic messages in
> NVRAM.
> So, in the following scenario, we will lose 1st panic messages.
>
> 1. kernel panics.
> 2. efi_psto
On Mon, Sep 10, 2012 at 3:59 PM, Michael S. Tsirkin wrote:
> On Mon, Sep 10, 2012 at 01:37:06PM -0400, Mike Waychison wrote:
>> On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin wrote:
>> > On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote:
>> >> T
On Mon, Sep 10, 2012 at 2:04 PM, Rik van Riel wrote:
> On 09/10/2012 01:37 PM, Mike Waychison wrote:
>>
>> On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin
>> wrote:
>
>
>>> Also can you pls answer Avi's question?
>>> How is overcommit
On Mon, Sep 10, 2012 at 1:55 PM, Mike Waychison wrote:
> Greg,
>
> Can you please pick this patch up in one of your trees?
Resend using a good email addy for gregkh :)
>
> Thanks!
>
> Mike Waychison
>
> On Fri, Jul 13, 2012 at 1:42 PM, Khalid Aziz wrote:
>> So
Greg,
Can you please pick this patch up in one of your trees?
Thanks!
Mike Waychison
On Fri, Jul 13, 2012 at 1:42 PM, Khalid Aziz wrote:
> Some of the EFI variable attributes are missing from print out from
> /sys/firmware/efi/vars/*/attributes. This patch adds those in. It also
>
On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin wrote:
> On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote:
>> This implementation of a virtio balloon driver uses the page cache to
>> "store" pages that have been released to the host. The communication
>> (outside of target coun
On Tue, Aug 21, 2012 at 9:54 AM, Seiji Aguchi wrote:
> [Problem]
> efi_pstore creates sysfs entries ,which enable users to access to NVRAM,
> in a write callback. If a kernel panic happens in interrupt contexts,
> pstore may
> fail because it could sleep due to dynamic memory allocations du
On Mon, Aug 20, 2012 at 12:15 PM, Seiji Aguchi wrote:
> [Problem]
> efi_pstore creates sysfs files when logging kernel messages to NVRAM.
> Currently, the sysfs files are updated in a workqueue which is registered in
> a write callback.
>
> On the other hand, a situation which users need the sysf
On Mon, Aug 20, 2012 at 12:15 PM, Seiji Aguchi wrote:
> [Problem]
> efi_pstore creates sysfs entries ,which enable users to access to NVRAM,
> in a write callback. If a kernel panic happens in interrupt contexts,
> pstore may
> fail because it could sleep due to dynamic memory allocations d
Acked-by: Mike Waychison
> @@ -1101,11 +1107,12 @@ out_free:
> void unregister_efivars(struct efivars *efivars)
> {
> struct efivar_entry *entry, *n;
> + unsigned long flags;
>
> list_for_each_entry_safe(entry, n, &efivars->list, list) {
On Fri, Aug 17, 2012 at 2:15 PM, Seiji Aguchi wrote:
>
>> I'm not a fan of creating a periodic timer that wakes up here to check for
>> an event that should be considered very rare.
>>
>> Can this just become scheduled work? Scheduling work itself is a very
>> lightweight process and should be
On Fri, Aug 17, 2012 at 12:43 PM, Seiji Aguchi wrote:
> [Problem]
> efi_pstore creates sysfs entries ,which enable users to access to NVRAM,
> in a write callback. If a kernel panic happens in interrupt contexts, pstore
> may
> fail because it could sleep due to dynamic memory allocations duri
On Fri, Aug 17, 2012 at 12:42 PM, Seiji Aguchi wrote:
> [Problem]
> Currently, efivars doesn't disable interrupt while taking efivars->lock.
> So, there is a risk to be deadlocking in a write callback of efi_pstore
> if kernel panics in interrupt context while taking efivars->lock.
>
> [Patch D
al Message-
>> From: linux-kernel-ow...@vger.kernel.org
>> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Seiji Aguchi
>> Sent: Tuesday, August 14, 2012 2:52 PM
>> To: Mike Waychison
>> Cc: linux-kernel@vger.kernel.org; Luck, Tony (tony.l...@intel.com)
On Tue, Aug 14, 2012 at 9:05 AM, Seiji Aguchi wrote:
> Hi,
>
> I'm sending an email to discuss how to remove create_sysfs_entry() from a
> write callback.
>
> [Problem]
>
> Current efi_pstore creates sysfs entries ,which enable users to access to
> NVRAM, in a write callback.
> If a kernel panic
into the the
struct request's into the scheduler.
Similar changes are underway for making sure all AIO get the right ioprios.
It will take some cleaning to get it ready for lkml submission, though
I'm still a bit unsure of what we should do to avoid struct page growth.
Mike Wayc
Fengguang Wu wrote:
On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote:
On Wed, 16 Jan 2008 12:55:07 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
On Tue, Jan 15, 2008 at 08:42:36PM -0800, Andrew Morton wrote:
On Wed, 16 Jan 2008 12:25:53 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrot
Can you clarify what you mean above with an example? I don't really follow.
Thanks,
Mike Waychison
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/major
ate your-data-is-here-but-isn't-alone. But that's
more of a feature for the FIEMAP stuff.
I hadn't heard of FIEMAP, so I went back and read the thread from
April/May. It seems that this is a much better approach than
introducing a FIBMAP64.
What ever happened with this proposa
Introduce FIBMAP64. This is the same as FIBMAP, but takes a u64.
This new routine requires filesystems to implement bmap64 if they want to
support > 2^31 blocks in a logical file. We do this to give time for
filesystems to be properly audited.
Signed-off-by: Mike Waychison <[EMAIL PRO
Propagate an error (EFBIG) to userspace if the physical block is too large to
return in a 32bit int instead of truncating it.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
fs/ioctl.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
Index: linux-2.6.23/fs/i
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have permission to see where their data is
landing on disk, and there really isn't a good reason to keep them from getting
at this information.
Signed-off-by:
Attempt to deal with races with truncate paths.
I'm not really sure on the locking here, but these seem to be taken by the
truncate path. BKL is left as some filesystem may(?) still require it.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
fs/ioctl.c |8
1 file
Move FIBMAP logic out of file_ioctl() in preparation for introducing FIBMAP64.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
fs/ioctl.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
Index: linux-2.6.23/fs/i
Return an error if the user requests a negative logical block in a file.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
fs/ioctl.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.23/fs/ioctl.c
===
--- linux-
#x27;m unsure of the locking in [4/6] fix_race_with_truncate.patch. Any help here
would greatly be appreciated.
The last patch, [6/6] drop_cap_sys_rawio_for_fibmap.patch, is of course, not to
be applied until any remaining issues are fixed :)
Thanks,
Mike Waychison
--
-
To unsubscribe from
Jason Uhlenkott wrote:
On Fri, Oct 26, 2007 at 14:59:57 -0700, Mike Waychison wrote:
Jason Uhlenkott wrote:
Additionally, ext3_bmap() has this to say about it:
if (EXT3_I(inode)->i_state & EXT3_STATE_JDATA) {
/*
* This is a REALLY heavyweight a
Jason Uhlenkott wrote:
On Fri, Oct 26, 2007 at 01:22:17 +0100, Alan Cox wrote:
On Thu, 25 Oct 2007 16:06:40 -0700
Mike Waychison <[EMAIL PROTECTED]> wrote:
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users t
Alan Cox wrote:
On Thu, 25 Oct 2007 16:06:40 -0700
Mike Waychison <[EMAIL PROTECTED]> wrote:
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have permission to see where their data is
landing on disk, and
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have permission to see where their data is
landing on disk, and there really isn't a good reason to keep them from getting
at this information.
Signed-off-by:
Jan Engelhardt wrote:
Nfsd uses it to serve up nfs exports that don't cross mountpoints (or do, if
"crossmnt" is specified in /etc/exports.
Is not this called nohide?
On the command line it's a synonym, but the nfs-utils uses
NFSEXP_CROSSMOUNT to tell the kernel.
is specified in /etc/exports.
Thanks,
Mike Waychison
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
--- 2.6.13-rc6/fs/namespace.c~unexport-__mntput 2005-08-12 08:21:22.0
-0500
+++ 2.6.13-rc6/fs/namespace.c 2005-08-14 20:32:01.00
Andi Kleen wrote:
On Wed, Aug 10, 2005 at 04:14:19PM -0700, Mike Waychison wrote:
YhLu wrote:
andi,
please refer the patch, it will move cpu_set(, cpu_callin_map) from
smi_callin to start_secondary.
This patch fixes an apparent race / lockup on our 2-way dual cores (when
applied against
YhLu wrote:
andi,
please refer the patch, it will move cpu_set(, cpu_callin_map) from
smi_callin to start_secondary.
This patch fixes an apparent race / lockup on our 2-way dual cores (when
applied against 2.6.12.3). The machine was locking up after
"Initializing CPU#2".
Mike
This patch changes the /proc/sysvipc/shm|sem|msg files to use the generic
seq_file implementation for struct ipc_ids.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
include/linux/msg.h |1
include/linux/sem.h |1
ipc/msg.c
Add a generic method for ipc types to be displayed using seq_file. This patch
abstracts out seq_file iterating over struct ipc_ids into ipc/util.c
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
util.c | 156 +
util.h
The following two patches convert /proc/sysvipc/* to use seq_file.
This gives us the following:
- Self-consistent IPC records in proc.
- O(n) reading of the files themselves.
Please consider applying. Thanks,
Mike Waychison
-
To unsubscribe from this list: send the line "unsubscribe
Wichert Akkerman wrote:
Previously Mike Waychison wrote:
enums in C are (de?)promoted to integral types under most conditions, so
the type-checking is useless.
It's a warning in gcc afaik and spare should complain as well.
Check again.
You must be thinking of another language.
Sh
Wichert Akkerman wrote:
Previously Bryan Henderson wrote:
Two advantages of the enum declaration that haven't been mentioned yet,
that help me significantly:
There is another one: with enums the compiler checks types for you.
enums in C are (de?)promoted to integral types under most condi
Greg KH wrote:
> Here's a small patch against 2.6.13-rc2 that adds securityfs, a virtual
> fs that all LSMs can use instead of creating their own. The fs should
> be mounted at /sys/kernel/security, and the fs creates that mount point.
> This will make the LSB people happy that we aren't creating
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Torokhov wrote:
> On Monday 04 July 2005 16:14, Mike Waychison wrote:
>
>>Hi,
>>
>>I just upgrade my Tecra M2 this weekend to the latest GIT tree and
>>noticed that my mouse pointer/touchpad is now broken on
retries. In either case the pointer didn't come back.
Removing the psmouse_reset makes the pointer come back properly 100% of
the time.
Are you sure that the psmouse_reset is really the right thing to do?
(worked fine in 2.6.11-rc2).
Thanks,
Mike Waychison
-BEGIN PGP SIGNATURE-
V
uot;);
if main is run within a chroot where it's "/" is on the same vfsmount as
it's "..", then the application can step out of the chroot using clone(2).
Note: using chdir in a vfsmount outside of your namespace works, however
you won't be able to walk off tha
ve happen in a callback, similar to the
following patch I posted a couple months ago:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109871749900732&w=2
IMHO, this is a better interface as it allows module writers to make arbitrary
changes.
(Some interface for allowing modules to 'safe
This is a valid piece of API that is exported for future use.
Please stop blindly posting patches for unexports that make the APIs
half available.
--
Mike Waychison
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J. Bruce Fields wrote:
> On Wed, Feb 02, 2005 at 04:08:32PM -0500, Mike Waychison wrote:
>
>>Well, fwiw, I have the same kind of race in autofsng. I counter it by
>>building up the vfsmount tree elsewhere and mount --move'ing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ram wrote:
> On Wed, 2005-02-02 at 11:45, Mike Waychison wrote:
>
> Ram wrote:
>
>>On Tue, 2005-02-01 at 15:21, J. Bruce Fields wrote:
>
>
>>>On Tue, Jan 25, 2005 at 01:07:12PM -0800, Ram wrote:
>
>
>
ts
>
> step3:
> mkdir -p /tmp/m2
> mount --rbind /root /tmp/m2
At this step, you probably shouldn't be using --rbind, but --bind
instead to only bind a copy of the root vfsmount, so it now looks like:
> root
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Hmm.. something is up with my quoting again..)
Ram wrote:
> On Mon, 2005-01-31 at 23:02, Mike Waychison wrote:
>
> Ram wrote:
>
>>On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
>
>
>>>-BEGIN PGP SIGNED ME
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ram wrote:
> On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>Al Viro wrote:
>>
>>
>>>OK, here comes the first draft of proposed semantics
managed to do resets/wdt off gpio pin 5 though, and
there is a patch in Alan's 2.6.10-ac tree that handles it.
Whether or not it will work with your vaio? Probably not, though I
guess it wouldn't hurt to try (modprobe alim7101_wdt use_gpio=1).
- --
Mike Waychison
Sun Mic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry for the bad quoting below:
[EMAIL PROTECTED] wrote:
> On Fri, 28 Jan 2005, Mike Waychison wrote:
>
> Al Viro wrote:
>
>>>> OK, here comes the first draft of proposed semantics for subtree
>>>> sharing. Wha
fore and quickly vetoed, citing that it is a
security risk. I still fail to understand how allowing a mount to
happen cross-namespace given a dirfd target is any worse than what is
already possible given a dirfd. If you don't want someone to play with
your namespace, don't give th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J. Bruce Fields wrote:
> On Tue, Jan 25, 2005 at 04:47:04PM -0500, Mike Waychison wrote:
>
>>Although Al hasn't explicitly defined the semantics for mount
>>- --make-shared, I think the idea is that 'only' that moun
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar wrote:
> * Mike Waychison <[EMAIL PROTECTED]> wrote:
>
>
>>Hi Ingo,
>>
>>I noticed that the wait_for_completion API extensions made it into
>>mainline.
>>
>>However, I posted that the
that part of the subtree
> in /tmp/mnt2 no more mirrors its parent subtree.
>
> RP
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at
n by
inotify_super_block_umount when called by generic_shutdown_super.
There remains a small race though, in that the inotify ioctl may return
success for an added watch after the umount, but this would have to be
resolved by synchronizing in userspace anyway.
Incremen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Gleixner wrote:
> On Tue, 2005-01-25 at 15:22 -0500, Mike Waychison wrote:
>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>Hi Ingo,
>>
>>I noticed that the wait_for_completion API extensi
Thanks,
- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
~~
NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsyst
->unloaded is
>> copmleted.
>
> -->completed
Thanks for pointing that out. Updated patch attached.
- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
~~
tecting nothing and the actual
>>bus_remove_driver() is called outside critical section.
>>
>>Please apply.
>
>
> No, please read the comment in the code about why this is the way it is.
> The code is correct as is.
>
Why don't we clean this up as in the proposed attache
:)
>
>
> I like shell sort for small data sets too. And I agree it would be
> appropiate for the kernel.
>
FWIW, we already have a Shell sort for the ngroups stuff in
kernel/sys.c:groups_sort() that could be made generic.
- --
Mike Waychison
S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote:
> On Mon, Jan 17, 2005 at 03:11:18PM -0500, Mike Waychison wrote:
>
>
>>I don't think that solves the problem. B should receive copies (with
>>shared semantics if called for) of all mountpoints C1,..,Cn tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J. Bruce Fields wrote:
> On Mon, Jan 17, 2005 at 02:30:27PM -0500, Mike Waychison wrote:
>
>>Well, if I understand it correctly:
>>
>>(assuming /foo is vfsmount A)
>>
>>$> mount --make-shared /foo
>>
&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J. Bruce Fields wrote:
> On Mon, Jan 17, 2005 at 01:31:02PM -0500, Mike Waychison wrote:
>
>>Corner case: how do we handle the case where:
>>
>>mount --make-shared /foo
>>mount --bind /foo /foo/bar
>>
>>A
ow do we handle the case where:
mount --make-shared /foo
mount --bind /foo /foo/bar
A nested --bind without sharing makes sense, but doesn't when sharing is
enabled (infinite loop).
How about a rule that states that for all Ai,Aj in p-node p, Ai must not
parent Aj in the vfsmount tree. Thi
83 matches
Mail list logo
