> Pavel Machek wrote:
> > On Sun 2008-01-20 09:23:00, Miklos Szeredi wrote:
> >>> Miklos Szeredi wrote:
> - for mount ID's use IDA (from the IDR library) instead of a 32bit
> counter, which could overflow
> >>> IDAs tend to get reused quickly, which can cause race conditions. Any
> >>
Pavel Machek wrote:
On Sun 2008-01-20 09:23:00, Miklos Szeredi wrote:
Miklos Szeredi wrote:
- for mount ID's use IDA (from the IDR library) instead of a 32bit
counter, which could overflow
IDAs tend to get reused quickly, which can cause race conditions. Any
reason not to just use a 64-bit
On Sun 2008-01-20 09:23:00, Miklos Szeredi wrote:
> > Miklos Szeredi wrote:
> > > - for mount ID's use IDA (from the IDR library) instead of a 32bit
> > > counter, which could overflow
> >
> > IDAs tend to get reused quickly, which can cause race conditions. Any
> > reason not to just use a 64
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > On Mon, 2008-01-21 at 22:25 +0100, Miklos Szeredi wrote:
> > > > You have removed the code that checked if the peer or
> > > > master mount was in the same namespace before reporting their
> > > > corresponding mount-ids. One d
> On Mon, 2008-01-21 at 22:25 +0100, Miklos Szeredi wrote:
> > > You have removed the code that checked if the peer or
> > > master mount was in the same namespace before reporting their
> > > corresponding mount-ids. One downside of that approach is the
> > > user will see an mount_id in t
On Mon, 2008-01-21 at 22:25 +0100, Miklos Szeredi wrote:
> > You have removed the code that checked if the peer or
> > master mount was in the same namespace before reporting their
> > corresponding mount-ids. One downside of that approach is the
> > user will see an mount_id in the
> You have removed the code that checked if the peer or
> master mount was in the same namespace before reporting their
> corresponding mount-ids. One downside of that approach is the
> user will see an mount_id in the output with no corresponding
> line to explain the
Miklos,
You have removed the code that checked if the peer or
master mount was in the same namespace before reporting their
corresponding mount-ids. One downside of that approach is the
user will see an mount_id in the output with no corresponding
line to e
> On Jan 19 2008 12:05, Miklos Szeredi wrote:
> >+
> >+/*
> >+ * Write full pathname from the root of the filesystem into the buffer.
> >+ */
> >+char *dentry_path(struct dentry *dentry, char *buf, int buflen)
>
> Hm, this functions looks very much like __d_path(). Is it
> an unintentional copy?
On Jan 19 2008 12:05, Miklos Szeredi wrote:
>+
>+/*
>+ * Write full pathname from the root of the filesystem into the buffer.
>+ */
>+char *dentry_path(struct dentry *dentry, char *buf, int buflen)
Hm, this functions looks very much like __d_path(). Is it
an unintentional copy?
>+{
>+ char
> Miklos Szeredi wrote:
> > - for mount ID's use IDA (from the IDR library) instead of a 32bit
> > counter, which could overflow
>
> IDAs tend to get reused quickly, which can cause race conditions. Any
> reason not to just use a 64-bit counter?
They tend to become hard to parse/compare for h
Miklos Szeredi wrote:
- for mount ID's use IDA (from the IDR library) instead of a 32bit
counter, which could overflow
IDAs tend to get reused quickly, which can cause race conditions. Any
reason not to just use a 64-bit counter?
-hpa
--
To unsubscribe from this list: send the lin
Seems, most people would be happier with a new file, instead of
extending /proc/mounts.
This patch is the first attempt at doing that, as well as fixing the
issues found in the previous submission.
Thanks,
Miklos
---
From: Ram Pai <[EMAIL PROTECTED]>
/proc/mounts in its current state fail to di
13 matches
Mail list logo
