The following coommand
ip route add default dev enp4s0 src 5.9.158.75 table 1
at a stable hardened Gentoo server
Linux mr-fox 5.10.17 #18 SMP Wed Feb 17 12:59:16 CET 2021 x86_64
Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux
with 2 ip addresses immediately
On 12/30/20 10:05 AM, Toralf Förster wrote:
On 12/29/20 11:55 PM, Randy Dunlap wrote:
No, this is wrong. 'size' in this case is the size of the read.
And it's zero. Is this fixed by commit
3644e2d2dda78e21edd8f5415b6d7ab03f5f54f3
Toralf, can you test with 5.11-rc1 (or later)
On 12/29/20 11:55 PM, Randy Dunlap wrote:
No, this is wrong. 'size' in this case is the size of the read.
And it's zero. Is this fixed by commit
3644e2d2dda78e21edd8f5415b6d7ab03f5f54f3
Toralf, can you test with 5.11-rc1 (or later)?
thanks.
My plan was to apply that commit on top of the up
On 12/29/20 9:00 PM, Randy Dunlap wrote:
Hi Toralf,
Do you want either or both of your
Reported-by: and Tested-by: on the patch?
thanks.
-- ~Randy
The first is enough, for a Tested-by: was the time frame too short IMO.
--
Toralf
On 12/23/20 2:50 AM, Randy Dunlap wrote:
What motivates this change? Is there any reason to think this can
happen?
Spotted in the wild:
I run 2 hardened Gentoo systems, a server and a desktop.
I patched the server with this:
mr-fox ~ # cat ubsan.patch
--- linux-5.10.1.orig/mm/readahead.c
+++
On 12/20/20 2:09 AM, Randy Dunlap wrote:
On 12/18/20 2:20 AM, Toralf Förster wrote:
On 12/18/20 7:54 AM, Randy Dunlap wrote:
Hi,
[adding linux-mm]
On 12/16/20 1:54 AM, Toralf Förster wrote:
Hi,
I got this recently at this hardened Gentoo Linux server:
Linux mr-fox 5.10.1 #1 SMP Tue Dec 15
On 12/18/20 7:54 AM, Randy Dunlap wrote:
Hi,
[adding linux-mm]
On 12/16/20 1:54 AM, Toralf Förster wrote:
Hi,
I got this recently at this hardened Gentoo Linux server:
Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R)
Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU
Hi,
I got this recently at this hardened Gentoo Linux server:
Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R)
Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux
Dec 15 23:31:51 mr-fox kernel: [ 1974.206972]
==
I do wonder about this value:
# grep ^9 /sys/fs/cgroup/memory/*/*/memory.memsw.limit_in_bytes
/sys/fs/cgroup/memory/tinderbox/17.1_developer-20200531-193248/memory.memsw.limit_in_bytes:9223372036854771712
/sys/fs/cgroup/memory/tinderbox/17.1_developer-libressl-20200531-194547/memory.memsw.limit_in
On 5/30/20 7:10 PM, Konstantin Ryabitsev wrote:
> (and the fact that you were seeing it in the first
> place suggests that you should update your openssl library, see
> https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-202
On 5/30/20 3:07 PM, Toralf Förster wrote:
> :-( :
>
> $ export GIT_TRACE=1
>
> $ git pull
> 15:07:08.488836 git.c:439 trace: built-in: git pull
> 15:07:08.504295 run-command.c:663 trace: run_command: git fetch
> --update-head-ok
> 15:07:08.506481 gi
:-( :
$ export GIT_TRACE=1
$ git pull
15:07:08.488836 git.c:439 trace: built-in: git pull
15:07:08.504295 run-command.c:663 trace: run_command: git fetch
--update-head-ok
15:07:08.506481 git.c:439 trace: built-in: git fetch
--update-head-ok
15:07:08.516608 run-
May I ask you to clarify why
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-5.2/net-ipv4-fib_trie-avoid-cryptic-ternary-expressions.patch?id=e1b76013997246a0d14b7443acbb393577d2a1e8
speaks about a ternary operator, whereas the diff shows a changed #define?
--
At a server (hardened stable Gentoo) I do usually do see values around 15,000
for that measure.
But 1 or 2 times per day that value gives a spike of 300,000 (or up to
1,500,000) over a 1 minute or so.
I do wonder how I can drill down the root cause for those spikes?
--
Toralf
PGP C4EACDDE 0076E9
at my docked ThinkPad T440s.
I'm just curious what this does mean?
...
sched_clock: Marking stable (765790894, 14019108)->(786693847, -6883845)
registered taskstats version 1
Loading compiled-in X.509 certificates
alg: No test for pkcs1pad(rsa,sha1) (pkcs1pad(rsa-generic,sha1))
Loaded X.509 cert
On 14.05.19 20:14, Jonathan Corbet wrote:
> On Tue, 14 May 2019 19:48:12 +0200
> Toralf Förster wrote:
>
>> But this link is mentioned in dmesg of 5.1.2
>
> It works for me. I think you just needed to wait for the relevant commit
> to make it upstream and the docs to be
But this link is mentioned in dmesg of 5.1.2
--
Toralf
PGP C4EACDDE 0076E94E
Hi
On Fri, Feb 08, 2019 at 08:44:32PM -0800, Mark D Rustad wrote:
> On Feb 8, 2019, at 2:54 AM, Greg KH wrote:
>
> > diff --git a/Documentation/networking/ip-sysctl.txt
> > b/Documentation/networking/ip-sysctl.txt
> > index 2ea4c45cf1c8..7c229f59016f 100644
> > --- a/Documentation/networking/ip-
Got at a stable hardened Gentoo this splat (BTW - no chance to get 4.19.0 nor
4.19.1 up and running at this headless server for longer than 1-2 minutes - it
dies w/o any further log message)
Oct 22 22:24:58 mr-fox kernel:
==
Oct 2
At a stable hardened Gentoo Linxu I observed with 4.18.17 at a headless server:
Nov 4 18:13:27 mr-fox kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Nov 4 18:13:27 mr-fox kernel: EXT4-fs (sda4): mounted filesystem with ordered
data mode. Opts: (null)
Nov 4 18:13:27 mr-fox kernel: VFS: Mounted r
I'm trying to get a new system and running with kernel 4.18.12, but run
into an APIC error as seen in [1].
It is a new system, never tried older kernels till now.
The kernel command line "noapic" doesn't help, now I do wonder what else
I can do.
The same kernel config was fine for 2 years with a
IIRC in the past I couldn't boot a remote system if that kernel config were
unset.
But I do wonder if I do need that option nowadays?
--
Toralf
PGP C4EACDDE 0076E94E
Got this at a chroot image at a stable hardened Gentoo Linux :
BuildKernel with randconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
YACCscripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/c
The attached dmesg contains non printable chars 0x01 33 around "ACPI BIOS Error
(bug): Could not resolve" which is a new issue compared to the dmesg of 4.17.2
System is a stable hardened Gentoo Linux at a ThinkPad T440s.
--
Toralf
PGP C4EACDDE 0076E94E
dmesg-4.17.3
Description: Binary data
Got this at a stable Gentoo hardened Linux server today and do wonder how to
react on it:
Feb 5 17:33:41 mr-fox kernel: [102822.981295] capability: warning:
`capget-54cLBXW7' uses 32-bit capabilities (legacy support in use)
Feb 5 17:33:50 mr-fox kernel: [102831.276626] perf: interrupt took to
It differs from the statement made at
https://www.kernel.org/category/releases.html
--
Toralf
PGP C4EACDDE 0076E94E
On 12/30/2017 02:13 AM, Alexander Tsoy wrote:
> You are right, It's due to fstack-check enabled in gentoo's gcc spec.
> "-fstack-check=no" in KBUILD_CFLAGS fixed this problem for me. =/
This made the issue go away :
diff --git a/Makefile b/Makefile
index ac8c441866b7..11a12947c550 100644
--- a/Ma
On 12/30/2017 04:49 AM, Josh Poimboeuf wrote:
> Alexander, would you mind reproducing again with the below patch? It
> should still fail, but this time it should hopefully show another
> RIP/RSP/EFLAGS instead of the "do_double_fault+0xb/0x140" line.
I applied that too on top of v4.15-rc5-114-g27
On 12/30/2017 10:14 AM, Alexander Tsoy wrote:
> Yes, and only in hardened profile, so most users don't have -fstack-
> check by default. :)
Indeed, I do run hardened Gentoo only.
--
Toralf
PGP C4EACDDE 0076E94E
On 12/30/2017 01:10 AM, Andy Lutomirski wrote:
> Toralf, can you send the complete output of:
>
> objdump -dr arch/x86/kernel/traps.o
>
> From the build tree of a nonworking kernel?
I attached it.
FWIW:
tfoerste@t44 ~/devel/linux $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPP
On 12/29/2017 11:53 PM, Linus Torvalds wrote:
> So just change the
>
> #ifdef CONFIG_X86_ESPFIX64
>
> into a
>
> #if 0
>
> and see if instead of the RCU stall after 20 seconds, you get an
> immediate double fault error report instead?
well, 3 IMG_20171230_0008* should show the results http
On 12/29/2017 10:17 PM, Linus Torvalds wrote:
> On Fri, Dec 29, 2017 at 1:02 PM, Toralf Förster
> wrote:
>> On 12/29/2017 09:12 PM, Linus Torvalds wrote:
>>> instead, and see if that makes a difference, that would narrow down
>>> the possible root cause of t
On 12/29/2017 09:12 PM, Linus Torvalds wrote:
> instead, and see if that makes a difference, that would narrow down
> the possible root cause of this problem.
not at this ThinkPad T440s (didn't test at the server with an i7-3930).
Boot stops just at:
tsc: Refined TSC clocksource calibrat
On 12/29/2017 04:48 PM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 12:14 +0100, Toralf Förster пишет:
>> I can confirm now, that that kernel breaks both a desktop (an
>> ThinkPad T440s i5) and a headless server (i3930) setup. For the
>> server the attached .config works fi
On 12/29/2017 02:33 PM, Sebastian Gottschall wrote:
> bootlog?
>
nothing in any logs, hang happens very early in the boot process
--
Toralf
PGP C4EACDDE 0076E94E
I can confirm now, that that kernel breaks both a desktop (an ThinkPad T440s
i5) and a headless server (i3930) setup. For the server the attached .config
works fine but switching from CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them
hang at boot w/op any messages. Similar picture at the desktop.
Bo
On 12/26/2017 10:16 PM, Ozgur wrote:
> You compile the kernel right? So, system is boot but not the network respond?
>
> Regards
Yes, I compile was fine the kernel (tried both new "kernel unwinder" kernel
options", made a distclean before).
All, what I can tell is in moment, it looks like that t
at a headless server: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, stable hardened
Gentoo Linux
The hang does occur before any log message is written.
A ping command shows, that the server does reboot and dies after 20 pings are
received.
The .config is attached
FWIW I'm surprised a little bit abou
Hello,
toray I realized this warning at a hardened stable Gentoo Linux server :
Nov 3 23:57:49 mr-fox kernel: [109232.200147] refcount_t: underflow;
use-after-free.
Nov 3 23:57:49 mr-fox kernel: [109232.200160] [ cut here
]
Nov 3 23:57:49 mr-fox kernel: [109232.200166
Hello,
got this today at a stable Gentoo Linux with recent kernel :
Nov 1 05:29:46 mr-fox kernel: [231282.542520]
Nov 1 05:29:46 mr-fox kernel: [231282.542523] UBSAN: Undefined behaviour in
./arch/x86/include/asm
I catched the following UBSAN spew at a stable Gentoo Linux server with
hardened tool chain (.config attached) :
FWIW - The lines before the UBSAN might be completely unrelated - I'm unsure.
They do come from the build bot [1] I do run at that machine for Gentoo.
Sep 6 02:18:43 mr-fox kernel: [
Got that at a hardened Gentoo Linux server with 4.12.0 (for the first time) at
a BTRFS logical volume occuping about 4/9 of a 5 TB volume group after an
uptime of about 2 days :
Had issues with processes accessing files at that volume now too.
Jul 6 15:33:53 mr-fox kernel: [158695.417132]
Whilst I'm wondering about missing kern.log entries of my server for about 13
hours within last night I stumbled over this :
May 1 05:53:19 mr-fox kernel: [63395.062218]
May 1 05:53:19 mr-fox kernel: [63395.06222
On 11/26/2016 02:16 PM, Pavel Machek wrote:
> Any chance to try 4.9?
> Pavel
sure - 4.9-rc6 is fine, both undocked and docked system allows hibernating
--
Toralf
PGP: C4EACDDE 0076E94E
Whilst 4.7.10 is fine, the current 4.8.10 kernel spews that message in
dmesg during boot and later can't be undocked any longer - the vt7
display then will stay black forever.
Switching to another vt works fine FWIW.
Update: attached dmesg
--
Toralf
PGP: C4EACDDE 0076E94E
Linux version 4.8.10-h
Whilst 4.7.10 is fine, the current 4.8.10 kernel spews that message in dmesg
during boot and later can't be undocked any longer - the vt7 display then will
stay black forever.
Switching to another vt works fine FWIW.
--
Toralf
PGP: C4EACDDE 0076E94E
I do wonder about this new dmesg entry at a ThinkdPad T440s since 4.6.5:
amd_nb: Cannot enumerate AMD northbridges
--
Toralf
PGP: C4EACDDE 0076E94E
This is a hardened stable Gentoo Linux ThinkPad T440s.
After wakeup from s2disk the console stays at line "clocksource: tsc: mask:"
forever.
FWIW (and maby completely unrelated) I do wonder why since that version I do
have a dmesg line :
amd_nb: Cannot enumerate AMD northbridges
The har
On 09/14/2016 02:49 PM, Theodore Ts'o wrote:
> What does "keyctl list @s" display? And what hapens if you try to
> rerun the add_key command? You should see something like this:
# keyctl list @s
1 key in keyring:
84804552: --alswrv 0 65534 keyring: _uid.0
A rerun of add_key won't help, the
I do run a hardened stable Gentoo Linux server w/ kernel 4.7.3-ahrdened-r1
where I use an ext4fs directory /var/lib/tor in the following way :
scp ~/.cryptoSalt user@host:/tmp
cat /tmp/.cryptoPass | ssh user@host 'sudo -u tor e4crypt add_key -S
$(cat /tmp/.cryptoSalt) /var/lib/to
On 08/25/2016 08:31 PM, Toralf Förster wrote:
> Aug 25 20:28:27 t44 kernel: DVB: registering new adapter (Terratec Cinergy T
> USB XXS (HD)/ T3)
> Aug 25 20:28:27 t44 kernel: DVB: Unable to find symbol dib7000p_attach()
> Aug 25 20:28:27 t44 kernel: dvb-usb: no frontend was attached
The dmesg now prints:
amd_nb: Cannot enumerate AMD northbridges
which is completely unexpected here at a non-AMD system (dmesg attaached).
--
Toralf
PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
Linux version 4.6.5-hardened (root@t44) (gcc version 4.9.3 (Gentoo Hardened
4.9.3 p1.5, pie
While reading the comment to 19ced623d :
"The hash buffer is really HASH_BLOCK_SIZE bytes, someone
must have thought that memmove takes n*u32 words by mistake.
Tests work as good/bad as before after this patch.
"
I was just curious why the tests doesn't fail now and since when the bug
otherwise the monitor is just black, although the docked ThinkPad T440s wakes
up fine iand is up and running.
(system: i5, i915, current kernel and older kernel versions of a 64 bit
hardened Gentoo linux).
Just to help to improve the kernel (if it is a kernel issue).
--
Toralf
PGP: C4EACDDE 00
This is a ThinkPad T440s with a stable 64bit hardened Gentoo.
If it is docked then the described behaviour happens.
I do run latest kernel, former kernel versions show the same behaviour.
All other functionality of the resumed system is fine, so it is just the
monitor which needs an extra kick.
A
On 06/16/2016 11:14 AM, Henrique de Moraes Holschuh wrote:
> Did you try setting the BIOS to "highest performance" mode even while on
> battery?
ough - that was it - *head smack*
> BTW: update the BIOS of the T440s if you haven't done so already, AFAIK
did it
Thx Henrique for the answer
--
Tora
This diff is reliable depending whether the T440s is docked (right) or not
(left) :
Linux t44 4.5.7-hardened-r2 #1 SMP Wed Jun 15 23:39:10 CEST 2016 x86_64
Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz GenuineIntel GNU/Linux
215c215
avx : 23504.000 MB
Toralf Förster:
> Got this at a 32 bit KVM during boot :
and later while fuzzying with trinity :
Apr 14 15:44:56 n22kvm-clone kernel:
Apr 14 15:44:56 n22kvm-clone kernel: UBSAN: Undefined behaviour in
./arch/
Got this at a 32 bit KVM during boot :
Apr 14 15:40:24 n22kvm-clone kernel:
Apr 14 15:40:24 n22kvm-clone kernel: UBSAN: Undefined behaviour in
./arch/x86/include/asm/atomic.h:156:2
Apr 14 15:40:24 n22kvm-clone kerne
Francois Romieu:
> Toralf Förster :
>> Today my server (64 bit hardened Gentoo kernel) was faced a SYN-flood attack.
>> I do wonder if the DMAR events points to an issue in the kernel ?
>
> Please send a compressed log including all 'fault addr' lines as well
&
Today my server (64 bit hardened Gentoo kernel) was faced a SYN-flood attack.
I do wonder if the DMAR events points to an issue in the kernel ?
Mar 12 21:56:51 ms-magpie kernel: [99582.831584] TCP: request_sock_TCP:
Possible SYN flooding on port 80. Sending cookies. Check SNMP counters.
Mar 12
James Bottomley:
> On Mon, 2016-02-29 at 13:31 +0000, Toralf Förster wrote:
> commit 564b026fbd0d28e9f70fb3831293d2922bb7855b
> Author: James Bottomley
> Date: Wed Jan 20 14:58:29 2016 -0800
>
> string_helpers: fix precision loss for some inputs
>
> James
>
I'm just curious about this diff in dmesg output between 4.3.2 and 4.3.3 at a
64 bit Gentoo hardened system:
$ diff dmesg-4.4.[23]-hardened | grep logical
< sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/223 GiB)
> sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB
Toralf Förster:
> Looking here
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs/tags/v4.4.2
> I see 12 hours here for 1cb8570b (4.4.2 tag) which is about 6 hours away from
> the right value, or ?
>
Hhm, pressing F5 changes the column "
Looking here
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs/tags/v4.4.2
I see 12 hours here for 1cb8570b (4.4.2 tag) which is about 6 hours away from
the right value, or ?
--
Toralf
PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
Got this at a 32 bit Gentoo Linux in a KVM fuzz tested with trinity :
Jan 27 15:43:30 n22kvm-clone kernel:
Jan 27 15:43:30 n22kvm-clone kernel: UBSAN: Undefined behaviour in
kernel/time/time.c:757:2
Jan 27 15:43:30
got this at a 32 bit Gentoo Linux KVM while fuzzying with trinity :
Jan 27 15:30:50 n22kvm-clone kernel:
Jan 27 15:30:50 n22kvm-clone kernel: UBSAN: Undefined behaviour in
mm/fadvise.c:72:10
Jan 27 15:30:50 n22kvm-c
at a 32 nbit KVM image of a Gentoo Linux runniogn v4.5-rc1 - attached is
/var/log/messages
--
Toralf, pgp: C4EACDDE 0076E94E
Jan 26 20:39:50 n22kvm-clone syslog-ng[1761]: syslog-ng starting up;
version='3.7.2'
Jan 26 20:39:50 n22kvm-clone /etc/init.d/net.eth0[2007]: config_eth0 not
specified;
As a n00b I do wonder about he following warning:
CC arch/x86/kernel/hw_breakpoint.o
arch/x86/kernel/hw_breakpoint.c: In function ‘arch_validate_hwbkpt_settings’:
arch/x86/kernel/hw_breakpoint.c:360:20: warning: ‘align’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
use the definition in include/uapi/linux/xattr.h
Signed-off-by: Toralf Förster
Reviewed-by: Jan Kara
---
fs/ext4/xattr_security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/xattr_security.c b/fs/ext4/xattr_security.c
index 36f4c1a..1a3d629 100644
--- a/fs/ext4
use the definition in include/uapi/linux/xattr.h
Signed-off-by: Toralf Förster
---
security/commoncap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index 1832cf7..907a3ef 100644
--- a/security/commoncap.c
+++ b/security
use the definition in include/uapi/linux/xattr.h
Signed-off-by: Toralf Förster
---
fs/ext4/xattr_security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/xattr_security.c b/fs/ext4/xattr_security.c
index 36f4c1a..1a3d629 100644
--- a/fs/ext4/xattr_security.c
+++ b
use the definition in include/uapi/linux/xattr.h
igned-off-by: Toralf Förster
---
security/commoncap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index 1832cf7..907a3ef 100644
--- a/security/commoncap.c
+++ b/security
The screen shots in [1] and [2] happened after I plugged + unplugged my
ThinkPad T440s into/from the docking station. I did that to investigate why
after few s2ram / docking cycles the external monitor stays black when docked.
This did not happen with 4.1.7, I'm unsure if this was the case wit
There's a regression in the stable 4.2.x series.
With 4.2.7 I get the following within kern.log:
Dec 16 14:58:41 t44 kernel: [111050.930350] dvb-usb: found a 'Terratec Cinergy
T USB XXS (HD)/ T3' in cold state, will try to load a firmware
Dec 16 14:58:41 t44 kernel: [111050.930436] dvb-usb: down
run into the following at a 64bit hardened stable Gentoo Linux while running
the following command at the host (probably just the ssh login was it yet) :
$ cd ~/devel/linux/; git archive --prefix linux-4.4.x/ v4.4-rc3 | (ssh
root@n22kvm "cd /usr/src/; sudo tar -xf-")
Dec 5 20:39:26 t44 kern
On 11/27/2015 12:53 PM, Filipe Manana wrote:
> Indeed.
> Try the following instead: http://paste.opensuse.org/view/raw/58412382
white-space damaged too, but the hint with --ingore- made it.
Will see, if it helps now. But FWIW the mentioned spew happened the first time
here AFAICT.
--
Toralf,
On 11/27/2015 12:07 PM, Filipe Manana wrote:
> Try the following (also pasted at
> https://friendpaste.com/5O6o1cqWqJZDIKrH1YqG7y):
Doesn't apply neither against the used 4.2.6 kernel nor aginst current git HEAD
:
t44 linux # patch -p1 --dry-run <
/home/tfoerste/Downloads/5O6o1cqWqJZDIKrH1YqG7y
Happened today few times in a row at a stable 64 bit Gentoo hardened system:
Nov 27 10:23:09 t44 kernel: [41619.519921] PAX: size overflow detected in
function try_merge_map fs/btrfs/extent_map.c:238 cicus.107_102 max, count: 13,
decl: block_len; num: 0; context: extent_map;
Nov 27 10:23:09 t4
At 22th of November at 21:26 UTC my server (64 bit stable Gentoo hardened)
suffered from a DDoS attack.
>From the kern.log:
Nov 20 22:26:29 tor-relay kernel: [2431358.124515] TCP: request_sock_TCP:
Possible SYN flooding on port 80. Sending cookies. Check SNMP counters.
Nov 20 22:26:4
Starting with 4.1 and still in 4.3-rc7 I get this in dmesg during boot phase at
a 64 bit Gentoo Linux at a Lenovo T440s:
[ cut here ]
WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:191
__ioremap_caller+0x233/0x380()
Info: mapping multiple BARs. Your kernel is fine.
Modu
On 10/29/2015 10:49 PM, Pavel Machek wrote:
> On Sun 2015-10-04 18:30:14, Toralf Förster wrote:
>> On 08/04/2015 02:29 PM, Toralf Förster wrote:
>>> On 08/02/2015 09:43 AM, Pavel Machek wrote:
>>>> Any chance to bisect it?
>>> Did it.
>>>
>>&g
On 08/04/2015 02:29 PM, Toralf Förster wrote:
> On 08/02/2015 09:43 AM, Pavel Machek wrote:
>> Any chance to bisect it?
> Did it.
>
> FWIW: the mentioned commit was introduced between 3.18 and 3.19.
> But my system (hardened 64 bit Gentoo) did not suffer from it till ve
On 08/04/2015 02:29 PM, Toralf Förster wrote:
> On 08/02/2015 09:43 AM, Pavel Machek wrote:
>> Any chance to bisect it?
> Did it.
>
> FWIW: the mentioned commit was introduced between 3.18 and 3.19.
> But my system (hardened 64 bit Gentoo) did not suffer from it till ve
This happen at a docked 64 bit Gentoo linux (hardened, but that's not the
culprit AFAICS) at a ThinkPad T440s. I attached the dmesg of both kernel
versions.
--
Toralf, pgp key: 872AE508 0076E94E
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuac
On 08/02/2015 09:43 AM, Pavel Machek wrote:
> Any chance to bisect it?
Did it.
FWIW: the mentioned commit was introduced between 3.18 and 3.19.
But my system (hardened 64 bit Gentoo) did not suffer from it till version
4.0.8.
The hardened kernel 4.1.x was the first where the bug was visible at my
On 08/03/2015 11:53 AM, Toralf Förster wrote:
> A quick look at the latest 4.1.3+hardened just shows that the power button at
> the docking station does not produce an ACPI event.
This is fixed between 4.1.3 and 4.1.4 - would be helpful to know the commit id
for the following bisecting
On 08/02/2015 09:43 AM, Pavel Machek wrote:
> On Wed 2015-07-29 15:54:00, Toralf Förster wrote:
>> Undocking helps, and then I can dock again.
>>
>> This happens at a hardened 64 bit Gentoo with i915, but I think, it is
>> not hardened related, or ?
>
> Any chan
Undocking helps, and then I can dock again.
This happens at a hardened 64 bit Gentoo with i915, but I think, it is
not hardened related, or ?
--
Toralf, pgp key: 872AE508 0076E94E
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
At a Gentoo Linux hardened amd64 desktop I got this trace after upgrading from
4.0.8 :
Jul 27 14:01:13 t44 kernel: [0.34] [ cut here ]
Jul 27 14:01:13 t44 kernel: [0.344453] WARNING: CPU: 1 PID: 1 at
arch/x86/mm/ioremap.c:202 __ioremap_caller+0x26f/0x3b0()
Ju
On 07/17/2015 12:10 PM, Florian Westphal wrote:
> Do you run containers?
No, I just run 4 Gentoo chroot images in parallel - but I do that since autumn
last year.
Unfortunately I cannot see any correlation to an os/sw upgrade or a config
change which could cause these messages nowadays to be ap
On 07/14/2015 08:43 AM, Emmanuel Grumbach wrote:
> You are not using the latest firmware. Please upgrade to 25.17.12.0.
At least with this firmware the issue is self-healing after a short while - I
do not need to restart the interface.
--
Toralf, pgp key: 872AE508 0076E94E
--
To unsubscribe fro
I do run a server with a 64 bit hardened Gentoo Linux (kernel currently 4.0.8).
Around 12th of July it started to spew those messages into kern.log :
/var/log/kern.log:Jul 12 15:26:07 tor-relay kernel: [538360.650490]
nf_conntrack: falling back to vmalloc.
/var/log/kern.log:Jul 12 15:26:07 tor-re
On 07/15/2015 09:47 PM, Emmanuel Grumbach wrote:
> Fritz!Box - oh well. We've had lots of issues with this kind of APs.
>
> There is already an open bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=97291
>
AH thx.
FWIW it worked flawlessly since Dec last year so far - no software upgrade at
t
On 07/15/2015 07:48 PM, Emmanuel Grumbach wrote:
> Can you reproduce easily?
>
Unfortunately not, it happens sometimes gtwice a day, and then I do have 5 or
more daays in a row w/o any problems.
> What bandwidth are you using? 20Mhz or 40Mhz?
20 MHz accordingly to my Fritz!Box 7360 display.
--
On 07/14/2015 08:43 AM, Emmanuel Grumbach wrote:
> Hi,
>
> On Tue, Jul 14, 2015 at 12:53 AM, Toralf Förster
> wrote:
>> At a Gentoo (hardened) I experienced - starting with hardened kernel
>> 4.0.6-r1 - the (attached) hickup of the "03:00.0 Network controller: I
At a Gentoo (hardened) I experienced - starting with hardened kernel 4.0.6-r1 -
the (attached) hickup of the "03:00.0 Network controller: Intel Corporation
Wireless 7260 (rev 83)" at a ThinkPad T440s. The network stucks till I do
restart the network device using /etc/init.d/net.wlp3s0.
Whilst i
>The casts are safe, since those conditions are only evaluated when sz >= 0.
Wouldn't in this case the condition "sz < 0" be superfluously ?
--
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
In [1] a clear opinion was stated out.
And therefore I do wonder if the build system at kernel.org should work in that
sense ?
[1] http://article.gmane.org/gmane.comp.version-control.git/180365
--
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E
--
To unsubscribe from this l
I created at a 3 TB btrfs formatted disk a btrfs subvolume, unpacked a minimal
Gentoo Linux in it, created in addition few files within it under ./tmp and
bind mount from the host few files onto those files. If I now delete in another
terminal the subvolume - then the server dies immediately
It
1 - 100 of 312 matches
Mail list logo
