On Wed, Mar 6, 2019 at 5:23 PM Enrico Weigelt, metux IT consult
wrote:
>
> On 07.03.19 01:33, Daniel Colascione wrote:
>
> > *There* *may* *be* *no* *filesystem*.
>
> A Linux system w/o any filesystem at all ? Well, that's interesting.
Entirely FS-less operation is unco
On Wed, Mar 6, 2019 at 4:33 PM H. Peter Anvin wrote:
>
> On 3/6/19 3:37 PM, Daniel Colascione wrote:
> >
> > I just don't get the opposition to Joel's work. The rest of the thread
> > already goes into detail about the problems with pure-filesystem
> >
On Wed, Mar 6, 2019 at 4:07 PM H. Peter Anvin wrote:
>
> On 3/6/19 3:37 PM, Daniel Colascione wrote:
> >
> > I just don't get the opposition to Joel's work. The rest of the thread
> > already goes into detail about the problems with pure-filesystem
> >
On Wed, Mar 6, 2019 at 3:09 PM Pavel Machek wrote:
>
>
> > > >Ok, I'll look into LZMA. Thanks for checking the compression sizes.
> > > >
> > > >- Joel
> > >
> > > Don't use lzma, use xz if you are going to do something.
> >
> > Ok, sounds good.
XZ is a file format for LZMA2. Everyone's right. :-
On Fri, Jan 25, 2019 at 12:28 PM wrote:
>
> On January 25, 2019 11:15:52 AM PST, Daniel Colascione
> wrote:
> >On Fri, Jan 25, 2019 at 11:01 AM wrote:
> >>
> >> On January 24, 2019 12:59:29 PM PST, Joel Fernandes
> > wrote:
> >> >On Thu, Jan
On Fri, Jan 25, 2019 at 11:01 AM wrote:
>
> On January 24, 2019 12:59:29 PM PST, Joel Fernandes
> wrote:
> >On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote:
> >>
> >> On 1/23/19 11:37 PM, Daniel Colascione wrote:
> >[..]
> >> >
On Wed, Jan 23, 2019 at 1:29 PM Karim Yaghmour
wrote:
> > By the way, we can easily write a script to just extract the .ko directly -
> > if the whole "load it as a module" thing bothers you. The kheaders.ko can
> > just be thought of as a tarball. There's already a script to extract
> > /proc/con
On Sat, Jan 19, 2019 at 11:27 AM Joel Fernandes wrote:
>
> On Sat, Jan 19, 2019 at 09:25:32AM +0100, Greg KH wrote:
> > On Fri, Jan 18, 2019 at 05:55:43PM -0500, Joel Fernandes wrote:
> > > --- /dev/null
> > > +++ b/kernel/kheaders.c
Thanks a ton for this work. It'll make it much easier to do coo
On Mon, Jan 7, 2019 at 5:32 PM Dave Chinner wrote:
>
> On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
> > As newer systems have more and more IRQs and CPUs available in their
> > system, the performance of reading /proc/stat frequently is getting
> > worse and worse.
>
> Because the
On Wed, Nov 21, 2018 at 6:36 PM Tim Murray wrote:
>
> On Wed, Nov 21, 2018 at 5:29 PM Andrew Morton
> wrote:
> >
> > On Wed, 21 Nov 2018 17:08:08 -0800 Daniel Colascione
> > wrote:
> >
> > > Have you done much
> > > retrospective long trace
On Wed, Nov 21, 2018 at 4:57 PM Andrew Morton wrote:
>
> On Wed, 21 Nov 2018 16:28:56 -0800 Daniel Colascione
> wrote:
>
> > > > The problem here is the possibility of confusion, even if it's rare.
> > > > Does the naive approach of just walking /proc an
On Wed, Nov 21, 2018 at 4:28 PM Daniel Colascione wrote:
>
> On Wed, Nov 21, 2018 at 4:22 PM Andrew Morton
> wrote:
> >
> > On Wed, 21 Nov 2018 15:21:40 -0800 Daniel Colascione
> > wrote:
> >
> > > On Wed, Nov 21, 2018 at 2:50 PM Andrew Morton
&
On Wed, Nov 21, 2018 at 4:22 PM Andrew Morton wrote:
>
> On Wed, 21 Nov 2018 15:21:40 -0800 Daniel Colascione
> wrote:
>
> > On Wed, Nov 21, 2018 at 2:50 PM Andrew Morton
> > wrote:
> > >
> > > On Wed, 21 Nov 2018 14:40:28 -0800 Daniel Colascione
On Wed, Nov 21, 2018 at 3:35 PM Andy Lutomirski wrote:
> > On Nov 21, 2018, at 4:21 PM, Daniel Colascione wrote:
> >
> >> On Wed, Nov 21, 2018 at 2:50 PM Andrew Morton
> >> wrote:
> >>
> >>> On Wed, 21 Nov 2018 14:40:28 -0800 Daniel Colascio
On Wed, Nov 21, 2018 at 2:50 PM Andrew Morton wrote:
>
> On Wed, 21 Nov 2018 14:40:28 -0800 Daniel Colascione
> wrote:
>
> > On Wed, Nov 21, 2018 at 2:12 PM Andrew Morton
> > wrote:
> > >
> > > On Wed, 21 Nov 2018 12:54:20 -0800 Daniel Colascione
On Wed, Nov 21, 2018 at 2:49 PM Jann Horn wrote:
>
> On Wed, Nov 21, 2018 at 11:40 PM Daniel Colascione wrote:
> > On Wed, Nov 21, 2018 at 2:12 PM Andrew Morton
> > wrote:
> > > On Wed, 21 Nov 2018 12:54:20 -0800 Daniel Colascione
> > > wrote:
>
On Wed, Nov 21, 2018 at 2:12 PM Andrew Morton wrote:
>
> On Wed, 21 Nov 2018 12:54:20 -0800 Daniel Colascione
> wrote:
>
> > Trace analysis code needs a coherent picture of the set of processes
> > and threads running on a system. While it's possible to enumerate
On Wed, Nov 21, 2018 at 12:31 PM Matthew Wilcox wrote:
>
> On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote:
> > This change adds a per-pid-namespace 64-bit generation number,
> > incremented on PID rollover, and exposes it via a new proc file
> >
On Tue, Nov 20, 2018 at 9:39 AM Matthew Wilcox wrote:
>
> On Tue, Nov 20, 2018 at 10:18:29AM +0100, Pavel Machek wrote:
> > > would ever rely on the pid being reused while having the descriptor
> > > open. How would that make sense?
> >
> > I agree this is corner space, but users might be surprise
On Mon, Nov 19, 2018 at 2:54 AM, Pavel Machek wrote:
> On Mon 2018-11-05 13:22:05, Daniel Colascione wrote:
>> State explicitly that holding a /proc/pid file descriptor open does
>> not reserve the PID. Also note that in the event of PID reuse, these
>> open file descriptors
On Wed, Nov 7, 2018 at 9:16 AM, Matthew Wilcox wrote:
> On Tue, Nov 06, 2018 at 08:01:13AM +0200, Mike Rapoport wrote:
>> > diff --git a/Documentation/filesystems/proc.txt
>> > b/Documentation/filesystems/proc.txt
>> > index 12a5e6e693b6..0b14460f721d 100644
>> > --- a/Documentation/filesystems/p
On Wed, Nov 7, 2018 at 4:00 PM, Michal Hocko wrote:
> On Wed 07-11-18 15:48:20, Daniel Colascione wrote:
>> On Tue, Nov 6, 2018 at 1:05 PM, Michal Hocko wrote:
>> > otherwise anybody could simply DoS the system
>> > by consuming all available pids.
>>
>
On Tue, Nov 6, 2018 at 1:05 PM, Michal Hocko wrote:
> On Mon 05-11-18 13:22:05, Daniel Colascione wrote:
>> State explicitly that holding a /proc/pid file descriptor open does
>> not reserve the PID. Also note that in the event of PID reuse, these
>> open file descriptors
23 matches
Mail list logo
