kernel August 2011

kernel@lists.fedoraproject.org

11 participants
11 discussions

fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg 05 Jun '15

05 Jun '15

The other day I was running the stock fedora kernel on my ip forwarding setup, to see what the performance was, and the performance wasn't very good. system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad port 82580 adapters (12 ports). Traffic is bidirectional 64 byte packets being forwarded and received on each port, basically port to port routing. I am only using 12 flows currently. The driver is igb, and I am using an affinity script that lines up each pair of ports that are forwarding traffic into optimal configurations for cache locality. I am also disabling remote_node_defrag_ratio to stop cross node traffic. With the fedora default kernel from F14 it appears that CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if I stop iptables service. perf showed netfilter being prominent, and removing it gives me much higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a good thing to be able to disable netfilter if you want to? Jesse

5 9

[PATCHSET] utrace for 3.1 kernel
by Oleg Nesterov 07 Feb '12

07 Feb '12

Hello. utrace patches for 3.1 kernel. Untested, will try to do some tests tomorrow. I do not want to spam you all and the lists, please look at git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc.git utrace-3.1 Oleg Nesterov (29): utrace: add utrace_init_task/utrace_free_task calls tracehooks: add utrace hooks tracehooks: reintroduce tracehook_consider_fatal_signal() add utrace hooks into sig_ignored() and recalc_sigpending() restore the EXEC/EXIT/CLONE utrace hooks utrace: utrace_report_death() can use task_utrace_struct() restore the DEATH/REAP utrace hooks utrace: remove jobctl bits ptrace: take ->siglock around s/TRACED/RUNNING/ introduce wake_up_quiescent() introduce ptrace_signal_wake_up() wait_task_inactive: treat task->state and match_state as bitmasks introduce TASK_UTRACED state utrace: use TASK_UTRACED instead of TASK_TRACED reintroduce tracehook_finish_jctl() as utrace_end_stop() teach wake_up_quiescent() to do "selective" wake_up ptrace_stop: do not assume the task is running after wake_up_quiescent() get_signal_to_deliver: restore/restructure utrace/ptrace signal reporting utrace_get_signal: s/JOBCTL_STOP_PENDING/JOBCTL_PENDING_MASK/ introduce ptrace_set_syscall_trace() introduce PT_SYSCALL_TRACE flag utrace: don't clear TIF_SYSCALL_TRACE if it is needed by ptrace introduce task_utrace_lock/task_utrace_unlock teach ptrace_set_syscall_trace() to play well with utrace introduce PT_SINGLE_STEP and PT_SINGLE_BLOCK utrace: finish_resume_report: don't do user_xxx_step() if ptrace_wants_step() ptrace: shift user_*_step() from ptrace_resume() to ptrace_stop() ptrace_disable: no need to disable stepping ptrace_report_syscall: check TIF_SYSCALL_EMU Roland McGrath (1): utrace core Documentation/DocBook/Makefile | 2 +- Documentation/DocBook/utrace.tmpl | 589 +++++++++ arch/s390/kernel/traps.c | 4 +- arch/x86/kernel/ptrace.c | 1 - fs/exec.c | 5 +- fs/proc/array.c | 14 +- include/linux/ptrace.h | 7 + include/linux/sched.h | 25 +- include/linux/signal.h | 2 + include/linux/tracehook.h | 53 +- include/linux/utrace.h | 773 ++++++++++++ init/Kconfig | 9 + kernel/Makefile | 1 + kernel/exit.c | 5 + kernel/fork.c | 9 + kernel/ptrace.c | 57 +- kernel/sched.c | 2 +- kernel/signal.c | 97 ++- kernel/utrace.c | 2461 +++++++++++++++++++++++++++++++++++++ 19 files changed, 4062 insertions(+), 54 deletions(-) create mode 100644 Documentation/DocBook/utrace.tmpl create mode 100644 include/linux/utrace.h create mode 100644 kernel/utrace.c

4 39

[PATCH F-14] bz#573210: ptrace-utrace: fix PTRACE_GETEVENTMSG(pid) in LXC
by Oleg Nesterov 28 Aug '11

28 Aug '11

https://bugzilla.redhat.com/show_bug.cgi?id=573210 ptrace_report_clone() uses child->pid, this is obviously wrong unless the tracer is from the global namespace. Change it to use task_pid_vnr(). This is still not right, we should use the tracer's namespace, not parent's. But this matches upstream, and at least this works if they are from the same namespace. Reported-by: Robin Green <greenrd(a)greenrd.org> Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> --- a/kernel/ptrace-utrace.c +++ b/kernel/ptrace-utrace.c @@ -403,7 +403,7 @@ static u32 ptrace_report_clone(u32 actio return UTRACE_RESUME; set_stop_code(ctx, event); - ctx->eventmsg = child->pid; + ctx->eventmsg = task_pid_vnr(child); /* * We shouldn't stop now, inside the do_fork() path. * We will stop later, before return to user-mode.

2 2

[PATCH 0/2] cifs: fix a couple of mount time problems
by Jeff Layton 25 Aug '11

25 Aug '11

We've had a number of panics reported by people using cifs mounts on F15. See the following reported bugs: 727927 731278 732934 I'd like to see both of the following patches added to 2.6.40.3 and above until they make it into the stable series. The second may also be appropriate for F16, but it may be simpler to just wait for the stable series to catch up there. The patches are pretty straightforward fixes, let me know if anything with them isn't clear. Pavel Shilovsky (1): CIFS: Fix ERR_PTR dereference in cifs_get_root Steve French (1): [CIFS] possible memory corruption on mount fs/cifs/cifsfs.c | 10 ++++++---- fs/cifs/connect.c | 3 ++- 2 files changed, 8 insertions(+), 5 deletions(-) -- 1.7.6

1 2

3.1. kernel
by Genes MailLists 23 Aug '11

23 Aug '11

Dave - any chance you'd put together an F15 2.6.41 based on 3.1? gene

5 5

2.6. 40-3 / F15
by Genes MailLists 17 Aug '11

17 Aug '11

Thanks for working on this 3.0.x for f15. Just to let you know I've been testing 2.6.40.3-0.fc15.x86_64 (for a few hours) and so far its working well (lenovo W520 I7 sandy bridge laptop). Will keep you posted of any issues should they arise. Thanks !! gene

1 0

3.1 pushed to f16
by Josh Boyer 16 Aug '11

16 Aug '11

Hi All, Moving forward with our plan to release Fedora 16 with the 3.1 kernel, I pushed 3.1-rc2 into the F16 branch this morning. Dave and I have both been running it in rawhide for a bit now, and it's been fairly stable. There will, of course, be bugs but getting some testing on the rc's will hopefully allow us to get them resolved before 3.1 final is out. I will submit a build for f16 updates-testing a bit later this week. NOTE: This will not impact the Alpha release. That will go out with 3.0. josh

1 0

Experimental kernels with inode-uprobes, without utrace
by Josh Stone 12 Aug '11

12 Aug '11

Hi all, To facilitate systemtap testing and development on the new inode-based uprobes, I've build and posted a few kernels with that patch applied, and without utrace. I also added a few exports for stap module use. The builds and an appropriate yum repo file are here: http://repos.fedorapeople.org/repos/jistone/kernel-uprobes/ This is currently using the June 7 patchset from Srikar. https://lkml.org/lkml/2011/6/7/232 http://git.kernel.org/?p=linux/kernel/git/srikar/linux-uprobes.git I only built for f15 and f16, as those 3.0(ish) kernels patch cleanly. In 3.1-rc there are conflicts in the perf parts, so I'll probably just wait for the next update from Srikar. It's also not the full complement of kernel variations, as I quickly hit my quota thanks to debuginfo size. I posted kernel-PAE.i686, kernel.x86_64, and their supporting packages. We're not ready for prime-time yet, but hopefully this is useful to anyone who wants to try the new uprobes. Most of the issues I mentioned in my previous mail still stand. Some of that will depend on PR10994, which David is working on, and some will just need this new uprobes to redevelop features that the old type had. http://sourceware.org/ml/systemtap/2011-q2/msg00206.html http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=shortlog;h=refs/head… http://sourceware.org/bugzilla/show_bug.cgi?id=10994 Let me know if you see any issues... Thanks, Josh

1 0

[RFC v2 00/19] utrace for 3.0 kernel
by Oleg Nesterov 09 Aug '11

09 Aug '11

Another attempt. This version tries to decouple utrace and ptrace. This way it is much simpler to follow the upstream changes, afaics. TODO: - The single-stepping updates in ptrace_resume() can race with utrace_reset()->user_disable_single_step(). This was fixed by 20/20, but I noticed that this patch is buggy right before sending. - Perhaps PTRACE_SYSEMU/TIF_SYSCALL_EMU logic was broken, I need to recheck. - Testing. Oleg.

6 41

2.6.40 ecryptfs oops (Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks)))
by Michał Piotrowski 06 Aug '11

06 Aug '11

W dniu 12 lipca 2011 22:45 użytkownik Michał Piotrowski <mkkp4x4(a)gmail.com> napisał: > I tested it, but it still corrupts data. On Thursday I'll do more > tests. Sorry for the nearly month delay :) Today I tried to copy a file over samba to my encrypted dir and operation still fails. When I tried to copy a file from other dir on the same machine to my encrypted dir I get this oops [41829.771957] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-28] [41829.772174] ecryptfs_writepage: Error encrypting page (upper index [0x000000000003598f]) [41829.772602] ------------[ cut here ]------------ [41829.772701] kernel BUG at fs/ecryptfs/read_write.c:47! [41829.772789] invalid opcode: 0000 [#1] SMP [41829.772881] CPU 0 [41829.772888] Modules linked in: ecryptfs smsc47m192 hwmon_vid smsc47m1 coretemp serio_raw i2c_i801 iTCO_wdt iTCO_vendor_support r8169 mii sata_sil i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [41829.773371] [41829.773381] Pid: 10839, comm: flush-ecryptfs- Not tainted 2.6.40-4.fc15.x86_64 #1 /D945GCLF2 [41829.773381] RIP: 0010:[<ffffffffa013a218>] [<ffffffffa013a218>] ecryptfs_write_lower+0x26/0x7d [ecryptfs] [41829.773381] RSP: 0018:ffff88007b2059e0 EFLAGS: 00010246 [41829.773381] RAX: 0000000000035990 RBX: ffff880079f14400 RCX: 0000000000001000 [41829.773381] RDX: 0000000000001000 RSI: ffff880079e98000 RDI: ffff880079f14400 [41829.773381] RBP: ffff88007b205a10 R08: 0000000000001000 R09: ffff88007b205990 [41829.773381] R10: ffff880079c3b888 R11: ffff880079e98ff0 R12: 0000000000000000 [41829.773381] R13: ffffea0001aab140 R14: ffffea0000829250 R15: ffff880079f14688 [41829.773381] FS: 0000000000000000(0000) GS:ffff88007f200000(0000) knlGS:0000000000000000 [41829.773381] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [41829.773381] CR2: 00007f52ddb57000 CR3: 0000000037a06000 CR4: 00000000000006f0 [41829.773381] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [41829.773381] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [41829.773381] Process flush-ecryptfs- (pid: 10839, threadinfo ffff88007b204000, task ffff88007b865cc0) [41829.773381] Stack: [41829.773381] ffff88007b2059f0 0000000035992000 0000000000000000 ffff880079f14400 [41829.773381] 0000000000000000 ffffea0001aab140 ffff88007b205a60 ffffffffa013b5a1 [41829.773381] ffffea0000829288 ffff880079e98000 ffff88007b205a80 ffffea0000829250 [41829.773381] Call Trace: [41829.773381] [<ffffffffa013b5a1>] ecryptfs_encrypt_page+0xeb/0x151 [ecryptfs] [41829.773381] [<ffffffffa0139b72>] ecryptfs_writepage+0x36/0x78 [ecryptfs] [41829.773381] [<ffffffff810e353d>] __writepage+0x15/0x2e [41829.773381] [<ffffffff810e3363>] write_cache_pages+0x203/0x33f [41829.773381] [<ffffffff810e3528>] ? set_page_dirty_lock+0x33/0x33 [41829.773381] [<ffffffff810e34df>] generic_writepages+0x40/0x56 [41829.773381] [<ffffffff810e4066>] do_writepages+0x28/0x2a [41829.773381] [<ffffffff8114488d>] writeback_single_inode+0xb2/0x1bc [41829.773381] [<ffffffff81144bdc>] writeback_sb_inodes+0xcd/0x161 [41829.773381] [<ffffffff81144fac>] writeback_inodes_wb+0x119/0x12b [41829.773381] [<ffffffff811451a3>] wb_writeback+0x1e5/0x356 [41829.773381] [<ffffffff810e391c>] ? global_dirty_limits+0x2b/0xd1 [41829.773381] [<ffffffff8114548a>] wb_do_writeback+0x176/0x1a9 [41829.773381] [<ffffffff814b6ffa>] ? _raw_spin_lock_irqsave+0x12/0x2f [41829.773381] [<ffffffff81145538>] bdi_writeback_thread+0x7b/0x1f8 [41829.773381] [<ffffffff811454bd>] ? wb_do_writeback+0x1a9/0x1a9 [41829.773381] [<ffffffff8106fd0b>] kthread+0x84/0x8c [41829.773381] [<ffffffff814be8e4>] kernel_thread_helper+0x4/0x10 [41829.773381] [<ffffffff8106fc87>] ? kthread_worker_fn+0x148/0x148 [41829.773381] [<ffffffff814be8e0>] ? gs_change+0x13/0x13 [41829.773381] Code: 01 d8 5b 5d c3 55 48 89 e5 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 48 83 bf 80 02 00 00 00 48 89 55 d8 48 89 fb 48 89 ca 75 02 <0f> 0b 65 4c 8b 24 25 48 cd 00 00 4d 8b ac 24 48 e0 ff ff 49 c7 [41829.773381] RIP [<ffffffffa013a218>] ecryptfs_write_lower+0x26/0x7d [ecryptfs] [41829.773381] RSP <ffff88007b2059e0> [41829.778779] ---[ end trace 32ff51ffa8acda79 ]--- I'm using ecryptfs-utils-87-8.fc15.x86_64 kernel-2.6.40-4.fc15.x86_64 > Data corruption does not happen always, so now I'm not too sure > whether this has to do with eCryptfs itself. May simply not happened > when I tested samba on not encrypted filesystem. > -- Best regards, Michal http://eventhorizon.pl/

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel August 2011