Is it possible to tell the kernel what time zone the RTC is in?
Right now it appears to assume that it's always in UTC, and this
causes a few headaches during the boot process.
As it is I tried to file a bug to have openrc activate hwclock
earlier, but it was rejected.
Would there be any benefit to allowing an in-progress core dump to be
aborted if the dumping process receives a fatal signal?
Example:
Process segfaults, starts dumping core, but it has a lot of virtual
memory allocated so it promptly leads to a queue-clogging deluge of I/O
that takes in some cas
My personal opinion is that even looking at esp/rsp is asking for
trouble. The only reliable information is VM_STACK or another VM flag
that makes the area expand in response to stack growth.
Besides, userspace could always play funky trampoline games with the
stack pointer, or even dynamical
On Mon, Oct 3, 2016 at 9:12 PM, Linus Torvalds
wrote:
On Mon, Oct 3, 2016 at 9:07 PM, Andrew Morton
wrote:
Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM.
Ehh. If by "few people" you mean "pretty much everybody", you'd be
right, but your choice of wording would be somewhat
Hey, don't know if this is important enough, but could I request that
the removal of wchan be reverted, or at least wrapped in an optional
config setting?
I happen to enjoy monitoring this information with a secure top, and
it's useful for understanding how my system works and I've used it a
On Mon, Oct 12, 2015 at 7:46 PM, Theodore Ts'o wrote:
On Mon, Oct 12, 2015 at 04:30:59PM -0400, George Spelvin wrote:
> Segregating abusers solves both problems. If we do this then we
don't
> need to drop the locks from the nonblocking pool, which solves the
> security problem.
Er, sor
On 09/20/15 11:05, Linus Torvalds wrote:
On Sun, Sep 20, 2015 at 5:56 AM, Oleg Nesterov wrote:
In this case the workqueue thread will block.
What workqueue thread?
pagefault_out_of_memory ->
out_of_memory ->
oom_kill_process
as far as I can tell, this can be called by an
On 09/19/15 15:24, Linus Torvalds wrote:
On Sat, Sep 19, 2015 at 8:03 AM, Oleg Nesterov wrote:
+
+static void oom_unmap_func(struct work_struct *work)
+{
+ struct mm_struct *mm = xchg(&oom_unmap_mm, NULL);
+
+ if (!atomic_inc_not_zero(&mm->mm_users))
+ return;
+
+
On 09/18/15 00:42, Greg KH wrote:
On Thu, Sep 17, 2015 at 11:12:51PM -0400, Theodore Ts'o wrote:
On Wed, Sep 16, 2015 at 01:26:51PM -0400, Josh Boyer wrote:
That isn't true. It helps the submitter understand the workflow and
expectations. What you meant to say is that it doesn't help you.
Th
On 09/16/15 09:40, Theodore Ts'o wrote:
On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
Hi Greg,
As I said in the subject of the mail (which I have been since told I
shouldn't have done this), I'm a noob to kernel code. I tried to pick
off something super simple to just see what
On 09/04/15 14:30, Stas Sergeev wrote:
05.09.2015 00:16, Stas Sergeev пишет:
I agree. vm86() is a mess.
My point is that its risky parts and useless funtionality
is _already_ known (even I can point to the particular code
parts than can simply be removed). As such, it simply had
to be re-visited
On 09/01/15 20:30, Albino B Neto wrote:
2015-08-31 23:53 GMT-03:00 Theodore Ts'o :
Yes, you can go back to ext3-only. In fact, we do *not* automatically
upgrade the file system to use ext4-specific features.
So it's not just a "you can use ext4 instead" issue. Can you do that
*without* then fo
On 08/31/15 15:31, Raymond Jennings wrote:
On 08/31/15 14:37, Linus Torvalds wrote:
On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara wrote:
The biggest change in the pull is the removal of ext3 filesystem driver
(~28k lines removed).
I really am not ready to just remove ext3 without a lot of good
On 08/31/15 15:39, Linus Torvalds wrote:
On Mon, Aug 31, 2015 at 3:31 PM, Raymond Jennings wrote:
That said, I wouldn't mind myself if the ext4 driver were given a very
grueling regression test to make sure it can actually handle old ext3
systems as well as the ext3 driver can.
That
On 08/31/15 14:37, Linus Torvalds wrote:
On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara wrote:
The biggest change in the pull is the removal of ext3 filesystem driver
(~28k lines removed).
I really am not ready to just remove ext3 without a lot of good
arguments. There might well be people who thi
Hey, I remembered that there's an option to put third level page tables
in highmem.
This might be a stupid question, but is there a way to move more kernel
data into highmem?
For example, page directories, first level page tables?
I even remember a few articles on lwn about how much space is
On 08/10/15 02:31, Raymond Jennings wrote:
I noticed that vfs.txt looked kinda funky, so I went ahead and
reformatted it.
Signed-off-by: Raymond Jennings
Cc: Andrew Morton
---
diff --git a/Documentation/filesystems/vfs.txt
b/Documentation/filesystems/vfs.txt
index 5eb8456..8ddfe06 100644
On 08/13/15 16:18, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
wrote:
The _only_ thing that matters is that something broke.
To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a wor
On 08/13/15 14:46, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings wrote:
I am curious about what's supposed to happen normally on signal delivery.
Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
signal is delivered?
What ex
On 08/13/15 13:09, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov wrote:
If only I'm not missin something obvious this should not hurt us.
But I gonna build test kernel and check to be sure tomorrow, ok?
Thanks,
Linus
--
To unsubscribe from this list:
I noticed that vfs.txt looked kinda funky, so I went ahead and
reformatted it.
Signed-off-by: Raymond Jennings
Cc: Andrew Morton
---
diff --git a/Documentation/filesystems/vfs.txt
b/Documentation/filesystems/vfs.txt
index 5eb8456..8ddfe06 100644
--- a/Documentation/filesystems/vfs.txt
+++ b
On Thu, 2015-07-23 at 13:21 -0700, Andy Lutomirski wrote:
> [moved to a new thread, cc list trimmed]
>
> Hi all-
>
> We've considered two approaches to dealing with NMIs:
>
> 1. Allow nesting. We know quite well how messy that is.
This might be a stupid question, but
1. What exactly does the
On Mon, 2015-07-06 at 10:59 -0700, Andy Lutomirski wrote:
> On Mon, Jul 6, 2015 at 10:40 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> > My reasoning: on modern uarchs there's no penalty for 32-bit
> >> > misalignment of
> >> > 64-bit variables, only if they cross 64-byte cach
On Fri, 2015-02-27 at 18:40 +0100, Jiri Slaby wrote:
> So check the absolute difference of times and if it large than "8
> seconds or so", always update the time. That means we will update
> immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
> check, but it was always that way.
If I
hen-a-swap-area-overflows-the-maximum-size.patch
If you could fix my test transcript and properly credit Rik for
reviewing my patch before you ship it to linus I'd appreciate it.
The correctly formatted patch and description with corrections and tags
follows:
----
From: Raymond Jennings
Sub
On Mon, 2013-07-15 at 15:38 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt wrote:
> >
> > Can we please make this into a Kernel Summit discussion. I highly doubt
> > we would solve anything, but it certainly would be a fun segment to
> > watch :-)
>
> I think we sh
On Mon, 2013-07-15 at 17:53 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 5:46 PM, Raymond Jennings wrote:
> >
> > I'd like to point out that Google Chrome also makes use of CONFIG_ tests
> > to detect support for namespaces and pid containers and stuff.
&
On Mon, 2013-07-15 at 10:17 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 8:40 AM, Konrad Rzeszutek Wilk
> wrote:
> >
> > I am hoping you can help me draw an understanding and a line in sand
> > whether:
> > a) Tools should not depend on /proc/config.gz to figure out whether
> > a k
On Mon, 2013-07-15 at 12:23 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau wrote:
> >
> > BTW, I was amazed that you managed to get him have a much softer tone inr
> > his last e-mail, you probably found a weakness here in his management
> > process :-)
>
> Hey, I
Screwed up and didn't attach my fixed test log to the second version.
See below.
On Sun, 2013-07-07 at 15:31 -0400, Rik van Riel wrote:
> On 07/07/2013 03:13 PM, Raymond Jennings wrote:
> > Turned the comparison around for clarity of "bigger than"
> >
> &
ap: warn when a swap area overflows the maximum size
It is possible to swapon a swap area that is too big for the pte width
to handle.
Presently this failure happens silently.
Instead, emit a diagnostic to warn the user.
Signed-off-by: Raymond Jennings
Acked-by: Valdis Kletnieks
diff --git
...I hate you gmail...
On Sun, 2013-07-07 at 04:52 -0700, Raymond Jennings wrote:
> # lvresize /dev/system/swap --size 16G
Typo in the second test.
The first line should read:
# lvresize /dev/system/swap --size 64G
First ever serious patch, got excited and burned the copypasta.
> #
Silly me, wrong email address
On Sun, 2013-07-07 at 04:44 -0700, Raymond Jennings wrote:
swap: warn when a swap area overflows the maximum size
It is possible to swapon a swap area that is too big for the pte width
to handle.
Presently this failure happens silently.
Instead, emit a diagnostic
swap: warn when a swap area overflows the maximum size
It is possible to swapon a swap area that is too big for the pte width
to handle.
Presently this failure happens silently.
Instead, emit a diagnostic to warn the user.
Signed-off-by: Raymond Jennings
Acked-by: Valdis Kletnieks
On Wed, 2013-07-03 at 14:21 -0700, Raymond Jennings wrote:
> Ok, so I just upgraded to 3.10.0 (gentoo system) and made a nice big
> 64GiB swap volume on lvm as usual.
>
> Suddenly, swapon doesn't recognize more than 32GiB, as top lists only
> that much swap space.
>
> s
Ok, so I just upgraded to 3.10.0 (gentoo system) and made a nice big
64GiB swap volume on lvm as usual.
Suddenly, swapon doesn't recognize more than 32GiB, as top lists only
that much swap space.
swapon using *two* separate 32GiB partitions works fine, but for some
reason a swap partition bigger
On Wed, 2013-06-12 at 13:26 -0700, Linus Torvalds wrote:
> On Wed, Jun 12, 2013 at 1:03 PM, Davidlohr Bueso
> wrote:
> >
> > According to him:
> >
> > "the short workload calls security functions like getpwnam(),
> > getpwuid(), getgrgid() a couple of times. These functions open
> > the /etc/pass
On Wed, Mar 27, 2013 at 9:33 AM, Linus Torvalds
wrote:
> On Wed, Mar 27, 2013 at 8:20 AM, Al Viro wrote:
>>
>> Actually, that's my fault - check lost in patch reordering. My apologies ;-/
>> Eventually, we want that in fs/splice.c side of things (no point repeating it
>> for every buffer, after
On Sat, Mar 2, 2013 at 10:10 AM, Borislav Petkov wrote:
> On Sat, Mar 02, 2013 at 08:28:56AM -0800, Linus Torvalds wrote:
>> On Sat, Mar 2, 2013 at 2:22 AM, James Hogan wrote:
>> >
>> > Okay, I've rebased the arch/metag tree onto mainline to make all the
>> > back-merges unnecessary and applied t
My two cents on this subject btw is that anything to do with
Microsoft's intentions or plans is an issue of policy that belongs
entirely in userspace.
"mechanism, not policy"
Besides, what do modules have to do with this if we're talking about
UEFI? Doesn't the kernel have to be loaded before mo
On Fri, Feb 15, 2013 at 6:20 PM, Al Viro wrote:
> Arrgh... OK, I'm a blind idiot. These places in binfmt_elf.c currently use
> force_sig(), not send_sig_info(). Currently == since 2006 when somebody
> noticed the problem. Their counterparts in binfmt_elf_fdpic.c were *not*
> noticed. Anyway,
Some useless troll said:
> nouveau is useless garbage as most open source graphics drivers.
Coming to an open source mailing list like LKML just to bitch about open
source being garbage? Come on...at least entertain us with better
subtlety.
I'm ready to ignore this guy, how about everyone else?
On Thu, 2012-08-23 at 12:41 +0200, wbrana wrote:
> Microsoft will drop support for x86-32 in Windows 9.
> Linux could do same.
> http://www.networkworld.com/community/blog/windows-9-details-are-already-emerging
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the
On Sun, 2012-08-19 at 20:47 -0400, Theodore Ts'o wrote:
> On Mon, Aug 20, 2012 at 01:06:20AM +0200, Carlos Alberto Lopez Perez wrote:
> >
> > > I also seriously question the niche of people who want to use a thumb
> > > drive to transfer > 4GB files. Try it sometime and see what a painful
> > > u
44 matches
Mail list logo
