Hello, Recently I've discovered the IO Accounting (I mean, /proc/PID/io). It's very interesting, specially together with iotop (thanks!) I wonder: is there something in the proc fs similar for network? How much bytes the _process_ are receiving/sending just now? I've checked and I haven't found. If there isn't any wat to get this information: is there any technical problem to not have it? It looks like it would be possible to add something similar in ipv4 level (net/ipv4/af_inet.c for ...

also make no_timer_check to be global on 64 bit, because vmi_32 is using that. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic_32.c | 15 ++++++++++++--- arch/x86/kernel/io_apic_64.c | 12 +++++++++--- 2 files changed, 21 insertions(+), 6 deletions(-) Index: linux-2.6/arch/x86/kernel/io_apic_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/io_apic_32.c +++ ...

do we have 64bit system with sis chipset? Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic_64.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) Index: linux-2.6/arch/x86/kernel/io_apic_64.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/io_apic_64.c +++ linux-2.6/arch/x86/kernel/io_apic_64.c @@ -65,7 +65,11 @@ int ioapic_force; -int sis_apic_bug; /* not ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic.c | 8 -------- 1 file changed, 8 deletions(-) Index: linux-2.6/arch/x86/kernel/io_apic.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/io_apic.c +++ linux-2.6/arch/x86/kernel/io_apic.c @@ -3785,7 +3785,6 @@ void __init setup_ioapic_dest(void) } #endif -#ifdef CONFIG_X86_64 #define IOAPIC_RESOURCE_NAME_SIZE 11 static struct resource ...

all the same except INTR_REMAPPING related and ioapic io resource Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic_32.c | 213 ++++++++++++- arch/x86/kernel/io_apic_64.c | 666 ++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 832 insertions(+), 47 deletions(-) Index: linux-2.6/arch/x86/kernel/io_apic_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/io_apic_32.c +++ ...

From: Arjan van de Ven <arjan@linux.intel.com> Subject: [PATCH] debug: add notifier chain debugging during some development we suspected a case where we left something in a notifier chain that was from a module that was unloaded already... and that sort of thing is rather hard to track down. This patch adds a very simple sanity check (which isn't all that expensive) to make sure the notifier we're about to call is actually from either the kernel itself of from a still-loaded module, avoiding ...

I just had the following oops on a wireless-testing.git kernel, which is based on 2.6.27-rc2. The oops happened while copying files. [27931.315928] Unable to handle kernel paging request for data at address 0x00000595 [27931.317713] Faulting instruction address: 0xc0082db0 [27931.318841] Oops: Kernel access of bad area, sig: 11 [#1] [27931.319341] PREEMPT PowerMac [27931.319784] Modules linked in: b43 ssb mac80211 appletouch rfkill_input rfkill led_class input_polldev af_packet ohci_hcd ...

Application programs should use a libraw1394 handle only in a single thread. The raw1394 driver was apparently relying on this, because it did nothing to protect its fi->state variable from corruption due to concurrent accesses. We now serialize the fi->state accesses. This affects the write() path. We re-use the state_mutex which was introduced to protect fi->iso_state accesses in the ioctl() path. These paths and accesses are independent of each other, hence separate mutexes could be used. ...

Responding to this for a second time: be advised that I am an end user, not a developer. I didn't even know the NMI watchdog existed! When developing my custom .config for the first time (~Feb 2007), I did read quite a bit of Documentation/*, but to be honest it mostly went over my head. Since then, I mostly have been only reading kernel documentation when presented with new features during 'make oldconfig'. If there are other obvious tricks like "NMI watchdog" that should be applied, ...

Hi, I run some barrier tests over device-mapper (which currently doesn't support barrier bio at all) and even if I set barrier=1 in ext3 mount, there is never any bio with barrier flag... (in 2.6.27-rc) How is the barrier=1 flag supposed to work in ext3 (JBD) now? See: If you specify barrier=1, JFS_BARRIER flag is set in ext3_init_journal_params journal->j_flags |= JFS_BARRIER; Now, journal_write_commit_record is called and this happens: if (journal->j_flags & JFS_BARRIER) ...

Hi, With a new iwlagn driver and 2.6.27-rc3, if I turn off the wireless (intel 4965ag) by RF kill switch, the CPU utilization of ksoftirqd process raises to 100% and stays there until I rmmod the module. Please let me know what further information I can provide. --

Linus, please pull more ACPI updates. This mainly includes the cpuidle latency updates Venki did some time ago for your system (due to some SNAFU they didn't get included earlier) and also a fix for a ioremap PAT regression exposed by ACPI. -Andi git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6 release-2.6.27 Andi Kleen (3): x86: Fix ioremap off by one BUG Merge branch 'ioremap' into release-2.6.27 Merge branch 'cpuidle' into ...

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- No cnages on binary level Index: linux-2.6.git/arch/x86/kernel/apic_32.c =================================================================== --- linux-2.6.git.orig/arch/x86/kernel/apic_32.c 2008-08-15 22:41:52.000000000 +0400 +++ linux-2.6.git/arch/x86/kernel/apic_32.c 2008-08-15 22:49:09.000000000 +0400 @@ -913,13 +913,15 @@ void __init sync_Arb_IDs(void) */ if (modern_apic() || boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ...

Ingo, Maciej, here is updated series (well... two patches only :). Nothing that new - just fixed the parts wich were not well formed in previous series. Please review. CID: tip/master 1a2450e636df465318fd9dcd31e37ea6af300405 - Cyrill - -- --

No, ACK from me for both. Maciej --

With CONFIG_SC520_CPUFREQ=y on AMD Elan (ancient CPU where rdtsc is not supported), I get: invalid opcode: 0000 [#1] Pid: 1, comm: swapper Not tainted (2.6.27-rc3-00216-gffaa5b9 #1) EIP: 0060:[<c0105b43>] EFLAGS: 00010082 CPU: 0 EIP is at native_read_tsc+0x6/0xf EAX: 1211fa10 EBX: 00000000 ECX: fffedb53 EDX: 00000000 ESI: 00000246 EDI: c0287fac EBP: c0281a6c ESP: c1c1ddec DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Process swapper (pid: 1, ti=c1c1c000 task=c1c1a000 ...

ah, in tip/master - that's a conflict resolution artifact i suspect. Thx. Ingo --

thanks, i've pulled it and rebased it to -git - as that's the best base this early in the cycle. I've pushed out the result into tip/x86/time - havent integrated it into tip/master yet. Ingo --

The usage of while_each_pid_task() construct in cap_set_pg() looks incorrect. The macro is meant to form 'do ... while' loop instead of a simple while loop. I think currently it will skip thread leader of a NPTL process. Fix by convert to 'do ... while' style. Signed-off-by: Ken Chen <kenchen@google.com> diff --git a/kernel/capability.c b/kernel/capability.c index 0101e84..26d8eda 100644 --- a/kernel/capability.c +++ b/kernel/capability.c @@ -167,7 +167,7 @@ static inline int cap_set_pg ...

applied to tip/x86/urgent - thanks Alex. Ingo --

I have created a git repository containing firmware files for use with the Linux kernel. There is a daily script¹ which extracts the contents of the firmware/ directory from the kernel itself, which is what has seeded the repository: git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=shortlog We are also able to include other firmware files from vendors who have chosen not to contribute their firmware ...

applied to tip/core/urgent, thanks Stephen. I'm wondering, could you send me the config that produces the build error? I do fairly comprehensive build testing but this one does not seem to trigger. Ingo --

KAPMANYALI PAKETİMİZİ İNCELEDİNİZ Mİ ? 50 MB alan 3 GB aylık transfer Sınırsız POP3 e-mail Sınırsız Subdomain 1 Mysql veritabanı MS Access desteği SOAP desteği ASP, ASP.NET, PHP, PERL,PHYTON,AJAX,WAP,XML Yıllık sadece 12 YTL ASP Bilişim ve İnternet Hizmetleri Ltd.Şti. Web : www.aspbilisim.net Msn Destek : destek@aspbilisim.com E-Mail : info@aspbilisim.net Tel : 0232 671 52 56 Gsm : 0506 276 54 37 --

actually, i thought of this as a quick hack to let -tip testing continue. Dont we have all the proper information available in kbuild and should just pass that to scripts/recordmcount.pl when called - like we pass in things like OBJDUMP which might have cross-build overrides, etc. Ingo --

Hi all, I'm trying to understand the issues surrounding the recent (2.6.2[456]) troubles involving unstable clocksources. Not being a kernel developer I'm somewhat in the dark. Also, if this isn't the correct forum to ask these questions, please direct me to the proper place. I have no wish to clutter the channel with off-topic discussion. My questions involve the characteristics and manifestations of the problems as related to the clocksource when it becomes unstable (whether it's tsc, ...

There were (and probably are) tty races and there might be some more so I'd actually be interested to know if its repeatable and if you can provide the test code that triggers it. Could be nVidiot stuff but quite frankly it looks like a quite believable real pty layer race in areas of code that were touched recently. Alan --

Thats definitely not good and wants digging into further. --

Now it looks more like this (with very frequent messages): ida_remove called for id=112 which is not allocated. ida_remove called for id=67 which is not allocated. ida_remove called for id=191 which is not allocated. ida_remove called for id=23 which is not allocated. ..and with no backtrace, so I guess it means "not harmful". Sorry for the noise. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually ...

Fix flags in usb code Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- drivers/usb/host/isp1760-hcd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.26-rt1/drivers/usb/host/isp1760-hcd.c =================================================================== --- linux-2.6.26-rt1.orig/drivers/usb/host/isp1760-hcd.c 2008-08-12 11:36:53.000000000 -0400 +++ linux-2.6.26-rt1/drivers/usb/host/isp1760-hcd.c 2008-08-12 11:37:40.000000000 -0400 @@ -1592,7 +1592,7 ...

Hi, I gave -rc3-gb635ace a spin on my laptop, but it oopses, I think somewhere in kgdb code. There were several backtraces, but I only got the last one, and here's what I could write down in a hurry: beyond end of test on 'singlestep_breakpoint_test' line 13 WARNING: drivers/misc/kgdbts.c:696 backtrace: run_simple_test kgdb_put_char put_packet kgdb_handle_exception kgdb_notify ... __die die do_page_fault error_code ... init_kgdbts I'm sorry for the poor report; it happens ...

The directory include2/asm can point wrongly to a non-existing directory on architectures that have moved include/asm under arch/*. This patch fixes it by checking firstly whether arch/*/include/asm is available. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- diff --git a/Makefile b/Makefile index 53bf6ec..bcbb764 100644 --- a/Makefile +++ b/Makefile @@ -934,7 +934,11 @@ ifneq ($(KBUILD_SRC),) fi; $(Q)if [ ! -d include2 ]; then \ mkdir -p ...

Patch tpm-correct-tpm-timeouts-to-jiffies-conversion reveals a bug in the Broadcom BCM0102 TPM chipset used in the Dell Latitude D820 - although most of the timeouts are returned in usecs as per the spec, one is apparently returned in msecs, which results in a too-small value leading to a timeout when the code treats it as usecs. To prevent a regression, we check for the known too-short value and adjust it to a value that makes things work. Version 2: Clarify comment somewhat, fix if statement ...

Yes, that's what I meant by the TLB optimizers. But it's going to be a fractional effect, isn't it, when you're trying to get the last 1% out of the machine? And in such a case, you might wonder more what all the 4k ones are actually being used for (no problem at all if they've ended up behind vmalloced module text). Hugh --

As soon as that kernel failed to boot, I chucked the patch away and erased it from my mind: much better to leave such a change to the people who are intimate with this sequence and can debug it. It wasn't anything much, the page to use has already been set aside for alloc_low_page, I thought it was just a matter of breaking the association with level2_ident_pgt at the right level then letting phys_pmd_init do its usual setup from scratch. Maybe it didn't work because I got it slightly ...

I made them unconditional to minimize the risk of some dumb parser not being able to deal with them. Longer term there will be more and more machines that support them. Admittedly that's not a very strong argument. -Andi --

I have to go to work for a few hours right now, but will try this out when I get home. (Actually, I'm late for work as I type this... but I have my priorities straight! ;) Quick question: a quick browse of 'Documentation/nmi_watchdog.txt' suggests that I should use "nmi_watchdog=1", since I have SMP (CPU = Athlon 64 X2, with CONFIG_SMP=y). Should I follow your suggestion later, or follow the recommendation of the 'nmi_watchdog.txt' doc? Much thanks, Dave W. --

Thanks for this Bill. I got home pretty late last night, so I only tried a few things before hitting the sack. Your suggestion is something I was planning, but didn't get to yet. It seems like any change after 3def3d6d that touches insert_resource() causes kernels to lock up on 2 of my 3 machines. Mike Galbraith sent an offlist reply with a very good idea for finding out whether a commit _before_ 3def3d6d is the actual cause of my troubles. I am more intrigued by this possibility than ...

This "permitted to execute" is what I feel is the wrong aproach with respect to malware. If you simply allow everything to 'execute', I think that untrusted programs may still be used for usefull things, but without the potential do do malice. If you start from the point where everything both trusted and untrusted is permitted to be executed, you could make it the job of SELinux or any other LSM to make untrusted code run without doing malice, but with the possibility to still run and do ...

They way I look at this. Most users complain that creating profiles for applications is too complex. Lets look for where a system that deals with the same kind of issue. Its in the firewall with ipset http://ipset.netfilter.org/. You have a set of rules to do things assigned in the firewall. With secuirty this would be the LSM. User gets to choose from a predefined list for applications without profiles. Lets look at some basics here. Firefox and most internet applications don't need ...

Hi all, Setting up my new AMD64 I noticed a curious one liner in syslogs: ^Iwith "disable_clustering=1" and report to maintainers The attached patch fixes this up so he goes back to his wife in /var/log/messages (or wherever KERN_INFO logs on the system): DC390: clustering now enabled by default. If you get problems load with "disable_clustering=1" and report to maintainers The patch was created on stable 2.6.26.2 git tree. Nick Signed off by: "Nick Warne" <nick@ukfsn.org> -- ...

The dummy driver uses runtime->private_free but still frees its pcm structures on error paths. This is esoteric because the error paths in question are unreachable. Thus the bug is only a problem when someone copies this code into other drivers. Signed-off-by: Daniel R Thompson <daniel.thompson@st.com> --- sound/drivers/dummy.c | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c index 4e4c69e..90fc1ce 100644 --- ...

thanks. To make sure it's all sorted out you might want to boot today's tip/master and check whether it just does the right thing by default. (it really should) Ingo --

With the overlaying of _PAGE_PSE and _PAGE_PAT there is a latent issue with the definition of _PAGE_PROTNONE: As soon as _PAGE_PAT gets actively used, it'll need to become part of _PAGE_CHG_MASK, and hence _PAGE_PROTNONE cannot use _PAGE_PSE anymore. One option certainly is to use one of the two remaining unused (available) bits, but it would seem to me that simply using _PAGE_ACCESSED here ought to work - but perhaps I'm overlooking some critical aspect? The background of this is that Xen's ...

Its called SELinux and SELinux can already do this sort of stuff, including things like "only rpm may create files you are permitted to execute" --

Hi folks, These the latest 4 Blackfin RTC driver updating patches. Thanks, -Bryan --

From: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/rtc/rtc-bfin.c | 51 ++++++++++++++++++----------------------------- 1 files changed, 20 insertions(+), 31 deletions(-) diff --git a/drivers/rtc/rtc-bfin.c b/drivers/rtc/rtc-bfin.c index a1af4c2..51741dc 100644 --- a/drivers/rtc/rtc-bfin.c +++ b/drivers/rtc/rtc-bfin.c @@ -218,26 +218,6 @@ static irqreturn_t bfin_rtc_interrupt(int irq, ...

From: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/rtc/rtc-bfin.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/rtc/rtc-bfin.c b/drivers/rtc/rtc-bfin.c index 9d2da1c..34439ce 100644 --- a/drivers/rtc/rtc-bfin.c +++ b/drivers/rtc/rtc-bfin.c @@ -363,6 +363,7 @@ static int __devinit bfin_rtc_probe(struct platform_device *pdev) struct bfin_rtc ...

From: Michael Hennerich <michael.hennerich@analog.com> Fix Bug: does nor properply resume after suspend mem Fix for PM_SUSPEND_MEM: Save and restore peripheral base registers Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/input/keyboard/bf54x-keys.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/input/keyboard/bf54x-keys.c b/drivers/input/keyboard/bf54x-keys.c index ...

From: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- scripts/checkpatch.pl | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index bc67793..eb764b0 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -1200,6 +1200,18 @@ sub process { WARN("adding a line without newline at end of file\n" . ...

--

Hi all, Changes since next-20080814: New trees: oprofile and fastboot. The tip-core tree lost its conflict. The cpus4096 tree lost its conflict. The ftrace tree gained a conflict against the driver-core tree and a build failure required the revert of a commit. The stackprotector tree gained a conflict against the ftrace tree. The x86 tree gained a conflict against the stackprotector tree but lost two conflicts and a build fix patch. The kvm tree gained a conflict against the ...

You've added that macro twice in MTD code already -- and now you're adding it twice more (although I suspect only one was intentional). Where are we with putting it in include/linux/ where it belongs? -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --

From: Mike Frysinger <vapier.adi@gmail.com> extend driver to handle arbitrary number of gpios Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/mtd/maps/Kconfig | 9 + drivers/mtd/maps/Makefile | 1 + drivers/mtd/maps/gpio-addr-flash.c | 419 ++++++++++++++++++++++++++++++++++++ 3 files changed, 429 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/maps/gpio-addr-flash.c diff --git ...

From: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/mtd/maps/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index df8e00b..50bb046 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -522,7 +522,7 @@ config MTD_BFIN_ASYNC config MTD_UCLINUX tristate "Generic uClinux RAM/ROM ...

applied to tip/irq/sparseirq - thanks. Ingo --

it doesnt really make sense to export the symbol or make it available when debugging is not enabled. -mike --

From: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/serial/bfin_5xx.c | 43 ++++++++++++++++++++++++++----------------- 1 files changed, 26 insertions(+), 17 deletions(-) diff --git a/drivers/serial/bfin_5xx.c b/drivers/serial/bfin_5xx.c index 487a562..a5ff54e 100644 --- a/drivers/serial/bfin_5xx.c +++ b/drivers/serial/bfin_5xx.c @@ -124,8 +124,6 @@ static void ...

BTW the original report you said you were using AR2425. I believe support for that was only added for 2.6.27. -- Bob Copeland %% www.bobcopeland.com --

PSK. I'll claim ignorance on EAP though I don't know why it wouldn't work. The change I was thinking of in 2.6.26 was related to some packets not being decrypted properly (http://marc.info/?l=linux-wireless&m=121064141521711). There was also this one related to association failures around .27-rc1: http://marc.info/?l=linux-wireless&m=121732394028001. Let us know what you find out. -- Bob Copeland %% www.bobcopeland.com --

Is this using WPA-PSK or WPA-EAP? I know my card works with PSK but I'm seeing similar results with EAP. Haven't had time to properly analyze the problem yet and my AP is in the office for the weekend. Regards, --

From: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- arch/blackfin/kernel/bfin_dma_5xx.c | 13 ++++----- drivers/serial/bfin_5xx.c | 50 +++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 7 deletions(-) diff --git a/arch/blackfin/kernel/bfin_dma_5xx.c b/arch/blackfin/kernel/bfin_dma_5xx.c index 93229b3..339293d 100644 --- a/arch/blackfin/kernel/bfin_dma_5xx.c +++ ...

On Fri, 15 Aug 2008 16:14:07 +0800 The existing ones were queued for 2.6.28 as I assumed that was what your email meant you want to do. If you have critical fixes at this point in the -rc series I would send them direct to Linus --

i'm still wondering whether we could try to figure out something about the nature of the hard lockup itself. Have you tried to activate the NMI watchdog? It _usually_ works fine if you use a boot option along the lines of: "lapic nmi_watchdog=2 idle=poll" The best test would be to first boot the broken kernel with also hpet=disable and the above options, and check in /proc/interrupts whether the NMI count is increasing. If the NMI watchdog is working, you should see a steady ...

Testing with a modified fsfuzzer reveals a couple of locations in omfs where filesystem variables are ultimately used as loop counters with insufficient sanity checking. In this case, dir->i_size is used to compute the number of buckets in the directory hash. If too large, readdir will overrun a buffer. Since it's an invariant that dir->i_size is equal to the sysblock size, and we already sanity check that, just use that value instead. This fixes the following oops: BUG: unable to handle ...

We don't need to use i_size_write() on this code path, but we do in other places. There's also i_size_read(). I wonder if omfs gets it right everywhere.. --

The notrace define belongs in compiler.h so that it can be used in init.h Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- include/linux/compiler.h | 2 ++ include/linux/linkage.h | 2 -- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-tip.git/include/linux/compiler.h =================================================================== --- linux-tip.git.orig/include/linux/compiler.h 2008-08-14 22:42:59.000000000 -0400 +++ ...

hm, massive build failures: ld: Relocatable linking with relocations from format elf32-i386 (init/.tmp_gl_calibrate.o) to format elf64-x86-64 (init/.tmp_mx_calibrate.o) i CC arch/x86/mm/extable.o objcopy: 'init/.tmp_mx_calibrate.o': No such file rm: cannot remove `init/.tmp_mx_calibrate.o': No such file or directory ld: Relocatable linking with relocations from format elf32-i386 (arch/x86/mm/extable.o) to format elf64-x86-64 (arch/x86/mm/.tmp_mx_extable.o) is not supported mv: cannot ...

the crude hack below got me going for now - but this needs a proper solution. Ingo ---------------------> From 52a4a65bcb5b796b7ad83ad069968c476142706f Mon Sep 17 00:00:00 2001 From: Ingo Molnar <mingo@elte.hu> Date: Mon, 9 Jun 2008 20:54:22 +0200 Subject: [PATCH] ftrace: scripts/recordmcount.pl cross-build hack hack around: ld: Relocatable linking with relocations from format elf32-i386 (init/.tmp_gl_calibrate.o) to format elf64-x86-64 (init/.tmp_mx_calibrate.o) i CC ...

applied to tip/tracing/ftrace - thanks Steve! I merged it into tip/master and started testing it. Ingo --

updated hack - it now works on 64-bit too. ( Btw., whoever came up with those fantastic variations of BFD, architecture name and ELF format names and sprinkled them around various tools with different command line switches and variants and underscore versus dash names, must not be let near any serious open-source code base again, until the end of his life. ) Ingo -------------> From 9f982af9fb45c438415c2c411cda0d8f1e5f1bb7 Mon Sep 17 00:00:00 2001 From: Ingo Molnar ...

Oops, that should read "Input updates for 2.6.27-rc3", damn mutt. -- Dmitry --

unrelated sidenote - shouldnt the scheduler define cpu_online_map to cpumask_of_cpu(0) on UP, to avoid such ugly #ifdefs? Ingo --

copy that from mach_default... should double check if cpu_online_map is cpu_mask_of_cpu(0) if !CONFIG_SMP YH --

yeah. Separate clean-up patch i think. Ingo --

applied to tip/irq/sparseirq - thanks Yinghai, great work! What do you think about Eric's abstraction suggestion, that irq_desc's structure should be hidden from all but kernel/irq/* code. I think that's a sane suggestion. We do it in mm/slab.c too: no external code knows the structure of 'struct kmem_cache'. Ingo --

need to check if desc is null in smp_irq_move_cleanup Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic_64.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/io_apic_64.c b/arch/x86/kernel/io_apic_64.c index 4d1b02d..e4f03cc 100644 --- a/arch/x86/kernel/io_apic_64.c +++ b/arch/x86/kernel/io_apic_64.c @@ -1950,6 +1950,9 @@ asmlinkage void smp_irq_move_cleanup_interrupt(void) irq = __get_cpu_var(vector_irq)[vector]; ...

Nope, git suggests I poke you about it.. :-) commit 243c7621aac4ed1aa79524c9a1cecf7c05a28124 Author: Ingo Molnar <mingo@elte.hu> Date: Mon Jul 3 00:25:06 2006 -0700 [PATCH] lockdep: annotate genirq Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> ...

need to check if desc is null in smp_irq_move_cleanup also migration need to reset vector too, so copy __target_IO_APIC_irq from 64bit Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic_32.c | 188 +++++++++++++++++++++++++---------------- 1 files changed, 115 insertions(+), 73 deletions(-) diff --git a/arch/x86/kernel/io_apic_32.c b/arch/x86/kernel/io_apic_32.c index 2d504fa..e0f85b5 100644 --- a/arch/x86/kernel/io_apic_32.c +++ ...

muhaha - i dont even know that guy who did this sloppy commit 2 years ago - "Ingo Molnar", or however he is called. I believe my (mistaken) thinking would have been that desc->irq lockdep class does not matter as long as we dont do irq-tracing. Which might have been borderline correct then but is wrong now, for things like lockstat? Ingo --

use cpu_online_map as target cpus for bigsmp. just like 64 bit doing also remove some unused TARGET_CPUS macro. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- include/asm-x86/bigsmp/apic.h | 15 +++++---------- include/asm-x86/es7000/apic.h | 3 +-- include/asm-x86/numaq/apic.h | 2 -- include/asm-x86/summit/apic.h | 1 - 4 files changed, 6 insertions(+), 15 deletions(-) diff --git a/include/asm-x86/bigsmp/apic.h b/include/asm-x86/bigsmp/apic.h index 0a9cd7c..1d9543b ...

can you check if #ifdef CONFIG_TRACE_IRQFLAGS void early_init_irq_lock_class(void) { #ifndef CONFIG_HAVE_DYN_ARRAY int i; for (i = 0; i < nr_irqs; i++) lockdep_set_class(&irq_descX[i].lock, &irq_desc_lock_class); #endif } #endif in kernel/irq/handle.c is right too? YH --

Yup, you're in the cool kid camp now, and this looks like the ACPI merges I remember from yore. Thanks, Linus --

I'll let the comments in the patch below to most of the talking. This came up because I wanted to use EVIOCGRAB in some code on an Openmoko Freerunner, and found that EVIOCGRAG does different things on that kernel to elsewhere. I looked into why, and found that there was a good reason but that the issues hadn't been completely resolved. I hope to help resolve the issues so that EVIOCGRAB can behave the same everywhere, and still meet everybody's needs. I would have Cc:ed to Magnus Vigerlof ...

applied to tip/x86/core - thanks! Ingo --

that's OK from a change of this width. And the #undefs are definitely #unnice as well. Ingo --

applied to tip/x86/urgent - thanks Darrick. Ingo --

ok. I've applied Steve's patch as it's a good bugfix. The extra paranoia about faulting on 0x90 seems excessive but doesnt hurt ;-) Ingo --

I think what we need to do is to test the NOPL instruction and create a Linux-specific CPUID bit for it. I'll do that and submit to tip:x86/cpu. -hpa --

Well, there's two distinct issues here. There's the need for a single-instruction 5 byte nop, and the need for efficient nops. It so happens in this case that they're the same thing. But in general, the generic nop interface is intended to return the most efficient nop, not an atomic nop (or with any other properties). To handle it generically, we'd either need to redefine the meaning of the existing nop-padding interface, or add an "atomic nop" interface. J --

device_can_wakeup() returns 'true' if the device is capable of generating PME# from at least one low power state (this is determined on the basis of the contents of the device's PCI PM registers - please have a look at drivers/pci/pci_pm_init() for details) or if ACPI tells us it can wake up. IOW, the BIOSes opinion doesn't matter if we find that the device is capable of generating PME#, so the regression must have been related to something else. I'm very interested in the details, if ...

drivers/pci/pci.c:pci_pm_init(), sorry. --

Full patch series applied to tip:x86/alternatives; we'll migrate it to tip:x86/urgent for upstream delivery after some testing. -hpa --

x86 : spinlock use LOCK_PREFIX Unless there a rationale for this, I think these be changed to LOCK_PREFIX too. grep "lock ;" include/asm-x86/spinlock.h "lock ; cmpxchgw %w1,%2\n\t" asm volatile("lock ; xaddl %0, %1\n" "lock ; cmpxchgl %1,%2\n\t" Applies to 2.6.27-rc2. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Linus Torvalds <torvalds@linux-foundation.org> CC: H. Peter Anvin <hpa@zytor.com> CC: Jeremy Fitzhardinge <jeremy@goop.org> CC: ...

a lot better. thanks Ingo -- Aristeu --

applied to tip/x86/urgent, thanks Aristeu. I've also done the cleanup below - those ugly linebreaks are gone this way as well. Ingo ----------------------> From 8bb851900f5d0a79d3fddac808cc670d9894ef67 Mon Sep 17 00:00:00 2001 From: Ingo Molnar <mingo@elte.hu> Date: Fri, 15 Aug 2008 15:34:32 +0200 Subject: [PATCH] x86, nmi: clean UP NMI watchdog failure message clean up the failure message - and redirect people to bugzilla instead of lkml. Signed-off-by: Ingo Molnar ...

btw., what was the effect - an oops on bootup, or a non-working applied to tip/x86/urgent - thanks Aristeu. Ingo --

Ah, Bruce reported the same error, and said this patch series fixed it. I assumed that this would fix your bug too. But if it does not, then I need to look deeper into what you are reporting. Could you recheck-out the latest tip/master and see if it works for you. Thanks, -- Steve --

(From the original mail) ^^^^^^^^^^ I obviously agree with this, so +1 Though, tbh, at the time I suggested it I didn't think of Steve's idea=20 to post-process which was quite clever. But I do agree that having gcc=20 do it will probably save some build time since it will probably be=20 trivial for it to do this when already processing -pg. It would have the = added benefit of letting the arch specific toolchain do the arch=20 specific work (though I think Steve's solution capitalizes ...

applied to tip/x86/urgent - thanks Dave. Ingo --

Hi Takashi, There were a couple of issues: getting the mute logic right from moving the assignment and increasing the number of inputs beyond the 11 required here to avoid the 'Too many connections' message and fixing the last input being skipped. With the updated patch, the problem is fully addressed; no resulting DC offset, so recording quality is great. This seems logically safe and a hopeful for 2.6.27-rc4... The updated patch is against 2.6.27-rc3. Thanks once again, ...

Bloody interesting. We never create negative hashed dentries in there and AFAICS we should never get d_delete() called on those... Missing barrier would mean serious trouble in dcache.c and not just for /proc/sys... Are you sure about oops decoding? At least disassembly of proc_sys_compare() in the kernel image in question would be nice to see... --

applied to tip/x86/amd-iommu - and merged into tip/x86/urgent as well for v2.6.27. Thanks Joerg, Ingo --

AT_EXECFN does provide one actual path, namely the one that was passed to namei. This path works for some uses and some cases, including some uses and some cases of $ORIGIN. The path which sometimes is revealed by readlink("/proc/self/exe",) also works for some uses and some cases, including some uses and some cases of $ORIGIN. Neither /proc/self/exe Please provide a statement or citation which describes "the problem with AT_EXECFN is useful when readlink("/proc/self/exe",) ...

It might be stable, but its effect of trashing the RTC makes it unsuitabl= e for non-experimental use. Therefore I'd prefer the dependency be kept. Thanks, Tilman

Hi. I think you're confusing 'experimental' and 'debugging'. You certainly wouldn't want to use it routinely, but that doesn't mean it's still an experimental feature. Regards, Nigel --

On Thu, Aug 14, 2008 at 5:11 PM, Eric W. Biederman TARGET_CPUS only used by ioapic_xx.c now 32bit and 64bit is the same page now... (bigsmp == phys_flat)... will continue to merge io_apic_xx.c YH --

yes - but in the end we should remove all the #ifdefs and try to hide well in the worst case just static array - but lets use the same APIs on them in .c files. i.e. we can make this all gradual and compatible - and we can allow dual use of old-style irq_desc[] _and_ the new APIs in the same kernel even (so that old architectures will work just fine, even if not touched) - ok. The suggestion from Eric is still valid, to use 0xffff0000, to exclude small negative numbers. (so ...

Note: Only vector_allocation_domain matters. That is where we setup the irq to be received. TARGET_CPUS is just a request to send the irq to someplace in that mask. Eric --

Set vector_allocation_domain to CPU_MASK_ALL on 32bit. That doesn't give us the benefit of per cpu vectors right now, but in my research there has not been a 32bit kernel yet that has needed it. We have never shared vectors between 2 gsi on 32bit x86, we have only collapsed the irq space. On x86_64 before I did the per cpu vectors there were machines that combined multiple interrupt sources (gsi) into the same irq. So x86_64 has needed the per cpu vectors. Which means in practice that ...

Hi Bruce! Yes, we did find this problem in production. More often than one would wish, installing new software in a system that has been running without a hiccup for weeks or months is the only thing you will need to bring For simplicity I think we could we get Nakano-san's patch merged first. If needed, moving to a work-based solution should be relatively easily. Thank you for you comments! - Fernando --

I doubt that would help because module_param()s are always registered even with acpi=off. They are not really processed by ACPI, but by kernel/params.c -Andi --

The NULL pointer reference further down actually looks like something foolish in the sysfs layer. But actually ACPI is not doing anything wrong here I think. According to the backtrace it happens when a kernel param (aka module_param) is set. And creating multiple params in the same acpi space is completely legal. It looks more like the high level code that sets up these parameters broke somehow and starts registering these twice and now ACPI is the first one to hit it (maybe because it ...

--- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/

Done. Full boot log is attached. Extract is: XXX adding modparam:'acpi.power_nocheck' 34 (ffffffff806a4cf0) XXX adding modparam:'processor.latency_factor' 35 (ffffffff806a4d18) XXX adding modparam:'processor.nocst' 36 (ffffffff806a4d40) XXX adding modparam:'processor.max_cstate' 37 (ffffffff806a4d68) XXX adding modparam:'processor.ignore_ppc' 38 (ffffffff806a4d90) XXX adding modparam:'thermal.psv' 39 (ffffffff806a4db8) XXX adding modparam:'thermal.off' 40 (ffffffff806a4de0) XXX adding ...

FYI, there's a built-in kernel debugger in the upstream kernel already: kernel/kgdb.c - and it does not need that export. So if you are interested in kernel debuggers i'd suggest to work with the KGDB folks to extend it with whatever feature-set is missing. They are friendly, very easy to work with and are open to the thousands-of-years-old scientific method of not duplicating effort, working together, going forward gradually, etc. Ingo --

I removed the export from this file and will resubmit the patch series. This will remove you from the decision list for this patch series. What other files do you claim to maintain so I can make certain remove them from my patches? Thanks Jeff --

Sorry, but I have my own path and direction, and its not as a tin can on a strong tied to the tail of kdb or kgdb. Again, it matters not what's in Linus' tree or not, but whether this is useful to others and they use it. From what I have seen based on the non-stop downloads from my FTP server, its needed for certain classes of users -- me included. I will continue to enhance it, release it, and move it forward. kdb and kgdb can go their way. I'm certain my code is being reviewed as we ...

Applied to 'next', thank you Matthew. -- Dmitry --

Hi Thomas, Your modification has been checked OK on our SB700 platform. Thank you. Now could you help us to merge your patch to kernel source? Or do I need to resubmit a patch on it? Best regards, - Crane --

Me thinks about naming my machine host-inline-real-virus-or-at-least-identifiable-part-here.cz, then having fun with people not able to access their apache logs. Returning an error when you think you see a virus is a great invitation to DoS attack, really. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

the threat model that was posted two days ago in the initial message of this thread specificly stated that actions of root are not something that this is trying to defend against. David Lang --

On Fri, 15 Aug 2008 16:16:22 -0400 I believe more that we need block-on-read ;-) (on open we can start an async scan to cut latency) read() (or mmap etc) is where the actual use/transfer of contaminated data happens, not in the open. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

according to the threat model actions of the administrator do not matter. David Lang --

This problem is actually identical to "new file scanned, but you don't have the signature available yet so malware isn't detected". Those of us who have seen large mail servers pile up queues in the 10s of millions in the 45 minutes between when the worm went critical-mass and when we got a signature might disagree on it not being a big problem in practice. Of course, if that's considered "outside" the threat model, somebody better start writing down exactly what small corner of threat model ...

This is the source of all that scan on write/close rambling I've seen go past the last couple of days.. So I'd not worry about this particular aspect --

the kernel should not kick off a scan, instead it should check to see an open/read should not kick off a scan, instead it should check to see if the scan generation tag(s) are current should be enough (remember, you may definantly not the kernel. the intent of this is to keep linux from being a storage repository for malware used by other systems. there is no need to penalize linux-only apps by making them wait for a scan to take place. If it lives in glibc there should be a way for ...

all you need is the ability to mark a file as 'dirty', and some way for programs that are interested in dirty files learning about it later and decideing to do a scan. if the file gets dirtied again after they do they scan they will need to do another one (this is a classic trade-off between the 'security' of looking for things quickly or 'efficiancy' of only looking when you don't think they will change again. in other words, policy -> userspace) David Lang --

one way this approach would be a pain is that as signature files got updated the attributes would accumulate. a couple ways of dealing with this. 1. scanners clean up after themselves (when they go to add a new one the remove the old one) 2. background sweep through the system removing all tags that aren't in the current 'blessed' set David Lang --

Or use either the Fuse or Coda kernel modules and handle such requests in userspace. With FUSE you should even be able to block on a per-page granularity, Coda only has session semantics so it will only notify userspace of the open and close events, while read and write and mmap are passed directly to the underlying file. Jan --

Not to mention removable media - it might be old hat, but infected/malware files can come in on floppies, CDs or USB flash discs careless left on the pavement outside an office. -- Douglas Leeder Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20. --

That is exactly the idea. However, the context of this particular thread was the following statement by Helge Hafting: It seems to me that this "scan on file open" business is the wrong way to do things - because it reduces performance. If you scan on file open, then your security sw is too late and getting in the way. We were just pointing out that this is not a good argument in practical terms AGAINST scanning on open. In fact, your reply completely reinforces that ...

It can never be free - what ever you do it has to happen some time and that can and will clash with something else. So your reason why it is The first thing you have to make clear is whether in your vision inode clean-dirty-unknown status is persistent or not? But in any case I think you are making a problem where there isn't one, think about it a bit. But the idea about the ability to make a clean copy is interesting. So we would need a copy done without userspace intervention and ...

Well, I agree that there are things you can't prevent, that's for sure. But the point is to build the "threat model" and application functionality around the idea that IF they happen, you want to be able to plug the resulting holes as well as you can. You can't simply close your eyes to the possibility. Jon Press --

I'm not sure. there are two situations (with the transition between them) 1. unscanned system, we want to do everything. (this happens immediatly after a new signature file is deployed) here you do just want to filter out the files that have been scanned from the list of everything, and you probably want to check at the time of scanning the file in case it was opened (and scanned) in the meantime. 2. mostly scanned system, we only want to scan files that have been dirtied. here ...

correct, and the threat model that was documented as what we are trying to defend against explicity says that actions by root (or other running programs, including running malware) are not part of the threat model they are trying to address (it doesn't mean that they aren't important, just that they are not trying to deal with them). All they are trying to do is to have a way to scan files. Since there is use in having support for this (for security theater, a little real security, and for ...

why would you not want the results of the viris scan to be persistant? assuming that you are not dual-booting( or otherwise taking explicit action to go around the OS), the fact that you scanned the file with signature set 123 is just as valid now as it was yesterday. If you are not trying to work around the actions of root, why are you trying to work around the actions of the person who has physical control of the system? (who could easily become root if they wanted to) David ...

applied to tip/x86/urgent - thanks Mark. Ingo --

How do you know? Is that just a guess based on some of Greg KH's and I don't see why any computation is needed. If the CPU will need to communicate with any devices on the bus (i.e., if any of these devices are not idle) then you need the connection to the bus, otherwise you don't. It's exactly the same with a tree. The fact that the interconnections form a bus rather than a tree is irrelevant. (Viewed in logical terms, even a true bus can be described as a tree. The nodes are ...

On Wed, 13 Aug 2008 15:24:15 -0700 (PDT) tty: remove resize window special case From: Alan Cox <alan@redhat.com> This moves it to being a tty operation. That removes special cases and now also means that resize can be picked up by um and other non vt consoles which may have a resize operation. Signed-off-by: Alan Cox <alan@redhat.com> --- drivers/char/tty_io.c | 72 +++++++++++++++++++++------------------ drivers/char/vt.c | 82 ...

MAP_32BIT was not actually added for this originally. It was originally added for the X server's old dynamic loader, which needed 2GB memory. Not sure what the semantics of that would be. For me it would seem ugly to hardcode specific semantics in the kernel for this ("mechanism not policy") But for most possible semantics I can think of the data structure would still IMHO the correct solution is to fix the data structure to not have such a bad complexity in this corner case. We ...

Of course - what you are missing is that _10 milliseconds_ thread creation overhead is completely unacceptable overhead: it is so bad as Nonsense, i had such a P4 based 64-bit box and it was painful. Everyone with half a brain used them as 32-bit machines. Nor is the context-switch overhead in any way significant. Plus, as Arjan mentioned that's a lot of handwaving with no actual numbers. The numbers in this discussion show that the context-switch overhead is small and that the ...

As soon as the patch hits Linus' tree I can change the code. --

I think the flag makes sense but it's name is confusing - 64BIT for a flag which means "maybe request 32-bit stack"! Suggest: +#define MAP_STACK 0x20000 /* 31bit or 64bit address for stack, */ + /* whichever is faster on this CPU */ Also, is this _only_ useful for thread stacks, or are there other memory allocations where 31-bitness affects execution speed on old P4s? -- Jamie --

Ah. That perhaps explains the recent jump in usage that has put allmodconfig over the limit. mmu_gathers is an int[NR_CPUS], and NR_CPUS was just raised from 1024 to 4096 -Tony --

Thanks. arch_setup_additional_pages -> map_compat_vdso -> __set_fixmap -> native_set_fixmap How about this one? --- From: Marcin Slusarz <marcin.slusarz@gmail.com> Subject: [PATCH v2] x86: fix section mismatch warning - spp_getpage() WARNING: vmlinux.o(.text+0x17a3e): Section mismatch in reference from the function set_pte_vaddr_pud() to the function .init.text:spp_getpage() The function set_pte_vaddr_pud() references the function __init spp_getpage(). This is often because ...

$ git grep arch_setup_additional_pages | cat arch/powerpc/include/asm/elf.h:/* vDSO has arch_setup_additional_pages */ arch/powerpc/include/asm/elf.h:extern int arch_setup_additional_pages(struct linux_binprm *bprm, arch/powerpc/kernel/vdso.c:int arch_setup_additional_pages(struct linux_binprm *bprm, arch/sh/include/asm/elf.h:/* vDSO has arch_setup_additional_pages */ arch/sh/include/asm/elf.h:extern int arch_setup_additional_pages(struct linux_binprm ...

Personally, I rather strongly prefer (*(type *)ptr). -hpa --

This looks fine. On the other hand, you really _should_ be able to just drop "result" entirely, and just do "return ret" at the end. But no, you can't do it right now, becasue the callers are broken crap. But that really isn't your fault. Also, you don't really need to change the if (ret < 0) goto out; to if (ret != 0) goto out; because the "filldir()" functions should all do the right thing anyway. But there's certainly nothing wrong with doing it ...

use the proper comment style please: /* * hm, what is this used for? also, instead of such an ugly inline, why not create a proper kernel/trace/* function for this. That would also give it access to all the proper locking mechanisms - instead of relying on some extral mechanism. Ingo --

Hi Andrew, Sorry for being so quiet. I've been carefully considering your email and composing what I hope is a much better description of why the code should eventually be merged: The cgroup freezer is useful to batch job management system which start and stop sets of tasks in order to schedule the resources of a machine according to the desires of a system administrator. This sort of program is often used on HPC clusters to schedule access to the cluster as a whole. The cgroup freezer ...

applied to tip/tracing/ftrace - thanks Frédéric! Ingo --

Ingo Molnar a

I tried doing this before but couldn't figure out an easy way, but the circumstances may have changed by now. Back then, the basic problem was that CONFIG_UID16 had side-effects that break the 64-bit versions of some syscalls. I don't see that being the case any more, but from what I can tell, you still need to add definitions for __kernel_old_uid_t etc on s390x. If that does the trick, great work! Arnd <>< --

Since I supplied a patch, I assume I don't need to do anything more. Let me know if my assumption is incorrect. Bjorn --

On Tue, 12 Aug 2008 10:58:12 -0400 Ack this. Will want some tweaking for the ttydev tree as it wants to switch to using krefs for vc->vc_tty as well now. Alan --

Is fault tolerance a requirement just for the TPM, or is it a general> Linux requirement? Has it always been there, or is it new? For example, does kernel software have to gracefully handle failures in the disk controller, processor, memory controller, BIOS flash memory, etc? I'd think it would be quite hard to code around motherboard failures in a commodity platform not designed for fault tolerance. --

Well, on a dual/quad core/socket/whatever system, a failing processor can be downed and the system keep going. On a NUMA box, you can yank a node with a bad memory controller after you take it down. Similarly for a disk controller if you have more than one, and the failed one isn't critical for system operation. And the TPM chip is more like a USB controller, in that there's a *high* degree of probability that the system will still be able to run even if it fails or goes insane (consider ...

Does that mean you are not going to incorporate the prio class system that is used in Linux? Please note that the three upper bits of ioprio contain the ioprio class. We currently have three classes encoded as follows: IOPRIO_CLASS_RT: 1 IOPRIO_CLASS_BE: 2 IOPRIO_CLASS_IDLE: 3 As things stand now, if we passed ioprio as is to the backend driver requests would get priority inverted. For example, requests in the idle class would be prioritized in detriment of the real time ...

[ Finally got my goodmis email back ] The new code does not discover the places at runtime. The old code did that. The "to kill a daemon" removed the runtime discovery and replaced it The current patch set, pretty much does exactly this. Yes, I patch at boot up all in one go, before the other CPUS are even active. This is the only advantage that you have. -- Steve --

FYI, this tab-to-space whitespace error caused this build failure in -tip testing: arch/x86/Kconfig:1500: unknown option "set" arch/x86/Kconfig:1501: unknown option "the" arch/x86/Kconfig:1503: unknown option "Systems" arch/x86/Kconfig:1504: unknown option "should" arch/x86/Kconfig:1519: unknown option "In" arch/x86/Kconfig:1520: unknown option "by" arch/x86/Kconfig:1521: unknown option "file" Ingo --

It was a very confusing use of the word thread. I have the same number of kernel threads running, but the single spindle on the drive has to deal with 3 different streams of writes. The seeks/sec portion of the graph shows a big enough increase in seeks on the duplication run to It does, I'll give the test a shot on other hardware too. To be honest I'm pretty happy at matching ext4 with duplication on. The graph shows even writeback and the times from each iteration are fairly ...

It sounds like ext4 would show the writeback_index bug with fragmentation on disk and btrfs would show it with seeks during the benchmark. I was only watching the throughput numbers and not looking pdflush and delalloc and raid stripe alignment and lots of other things don't play well together. In general, I think we need one or more pdflush threads per mounted FS so that write_cache_pages doesn't have to bail out every time it hits congestion. The current write_cache_pages code even ...

Looks like I can get the btrfs defaults up to 64MB/s with some writeback The async worker threads should be spreading the load across CPUs pretty well, and even a single CPU could keep up with 100MB/s checksumming. But, the async worker threads do randomize the IO somewhat because the IO goes from pdflush -> one worker thread per CPU -> submit_bio. So, maybe that 3rd thread is more than the drive can handle? btrfsck tells me the total size of the btree is only 20MB larger with The ...

I've been able to use compilebench to see the fragmentation problem very easily. Annesh has been workign on it, and has some fixes that he queued up. I'll have to point him at your proposed fix, thanks. This is what he came up with in the common code. What do you think? - Ted (From Annesh, on the linux-ext4 list.) As I explained in my previous patch the problem is due to pdflush background_writeout. Now when pdflush does the writeout we may have only few pages for the file and ...

Similar. I used compilebench -i 30 -r 0, which means create 30 initial kernel trees and then do nothing. compilebench simulates compiles by writing to the FS files of the same size that you would get by creating kernel trees or compiling them. The idea is to get all of the IO without needing to keep 2.6.28.tar.bz2 in cache or the compiler using up CPU. http://www.oracle.com/~mason/compilebench -chris --

Paul, one of your two recent RCU patches caused this lockdep splat in -tip testing: -------------------> Brought up 2 CPUs Total of 2 processors activated (6850.87 BogoMIPS). PM: Adding info for No Bus:platform khelper used greatest stack depth: 3124 bytes left ================================= [ INFO: inconsistent lock state ] 2.6.27-rc3-tip #1 --------------------------------- inconsistent {softirq-on-W} -> {in-softirq-W} usage. ksoftirqd/0/4 [HC0[0]:SC1[1]:HE1:SE0] takes: ...

yep, reverting that one made the lockdep warning go away. (note, i still kept the commit in tip/core/rcu so a delta fix against the previous patch would be preferred) Ingo --

I'm fine with it. I think there might still be cross-dependencies, but it doesn't break anything old, so we can deal with that via bug reports. The other thing that probably should be done is breaking out the Intel-specific versus generic parts of intel_cacheinfo.c. -hpa --

Every few hours?!? I hadn't noticed Windows AV programs getting updates that frequently, at least not the ones that I've been familiar with. (Semantec, Norton, McAfee) - Ted --

libmalware.so is shorthand for 'have a userspace library do the scanning nfs isn't secure anyway so you better control the border. it's only the kernel nfs daemon that won't use the library, so the answer is don't use that daemon. I beleive that there is a FUSE NFS option, or if nothing else, mount a filesystem with FUSE (linked against libmalware.so) libmalware can intercept the mmap call and decide to either prohibit it, copy the file so that the program is operating from it's own ...

Yes the current proposal has temporary markers in the in-memory representation if inodes. This is a problem for current anti-malware scanning, as virus data updates come every few hours (at which point the entire clean/infected state has to be cleared), so the loss after a reboot is limited. -- Douglas Leeder Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20. --

But Pavel is raising a good question. In Eric's proposed threat model, he claimed the only thing that he was trying to solve was "scanning". Just file scanning. That implies no root privileges, but it also implied that he wasn't worried about malware running with user privileges, either. Presumbly, that would be caught and stopped by the file scanner before the malware had a chance to run; that is the execve(2) system call would also be blocked until the executable was scanned. So if ...

Of course I mean't NOT a problem... -- Douglas Leeder Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20. --

Sure, as long as we're very clear about the semantics of the bits. If the bits are not persistent, but which get dropped if the inode is every evicted from memory, and it's considered OK, or even desirable, to rescan the file when it is brought back into memory, that may be acceptable to the rubber gloves folks (make people go through lots superflous of security scans, even when they are transfering betewen flights --- security is always more important than passengers' convenience!), but ...

On Fri, 15 Aug 2008 00:39:18 +0200 If you're trolling, you're not being very good at it. Just because you cannot easily infect a Linux system from a user application does not mean malware cannot do all kinds of damage with user privileges. Think of a key sniffer (using the same interface that the X screensavers use) or a spam bot running with user privileges. Firefox, OpenOffice.org and other (mostly desktop) programs are extremely large and complex, deal with untrusted data on a ...

On Thu, 14 Aug 2008 20:43:35 -0400 You bring up a very good point - malware does not need to be stored on a filesystem in order to run or cause damage. -- All rights reversed. --

(more people Cc:-ed) agreed - +12 seconds wait suggest some rather fundamental breakage. Did we go back to uncached for some critical display area that makes X start up (shut down) that slowly? Did we mark the BIOS uncacheable perhaps, causing X to execute BIOS code very slowly? Ingo --

applied to tip/x86/urgent, with your: Acked-by: Nick Piggin <npiggin@suse.de> thanks Jan. Ingo --

applied to tip/x86/pat - thanks! I've Cc:-ed more PAT folks - any objections? Ingo --

ok, agreed. Ingo --

applied to tip/x86/urgent - thanks. Ingo --

hm - i changed your patch to the one below, to align the break's vertically, which makes the original variant a lot more readable (and even more readable than the new one). Checkpatch still complains about it but that's OK, there are always exceptions. Ingo -------------------> Subject: x86: coding style fixes to arch/x86/kernel/bios_uv.c From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Date: Sat, 2 Aug 2008 21:24:06 +0200 paolo@paolo-desktop:~/linux.trees.git$ md5sum ...

applied to tip/x86/cleanups - thanks Gustavo! Ingo --

This is a first pass at converting the system to use the new PI library. We dont go for a wholesale replacement quite yet so that we can focus on getting the basic plumbing in place. Later in the series we will begin replacing some of the proprietary logic with the generic framework. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/sched.h | 37 +++++++-- include/linux/workqueue.h | 2 kernel/fork.c | 1 kernel/rcupreempt-boost.c | 23 ...

The system already has facilities to perform late/run-time init for rtmutexes. We want to add more advanced initialization later in the series so we force all rtmutexes through the init path in preparation for the later patches. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/rtmutex.h | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h index b263bac..14774ce 100644 --- ...

The kernel currently addresses priority-inversion through priority- inheritence. However, all of the priority-inheritence logic is integrated into the Real-Time Mutex infrastructure. This causes a few problems: 1) This tightly coupled relationship makes it difficult to extend to other areas of the kernel (for instance, pi-aware wait-queues may be desirable). 2) Enhancing the rtmutex infrastructure becomes challenging because there is no seperation between the locking code, and ...

This is a first pass at converting the system to use the new PI library. We dont go for a wholesale replacement quite yet so that we can focus on getting the basic plumbing in place. Later in the series we will begin replacing some of the proprietary logic with the generic framework. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/sched.h | 37 +++++++-- include/linux/workqueue.h | 2 kernel/fork.c | 1 kernel/rcupreempt-boost.c | 23 ...

** RFC for PREEMPT_RT branch, 26-rt1 ** Synopsis: We gain a 13%+ IO improvement in the PREEMPT_RT kernel by re-working some of the PI logic. [ pi-enhancements v2 Changes since v1: *) Added proper reference counting to prevent tasks from deleting while a node->update() is still in flight *) unified the RCU boost path ] [ fyi -> you can find this series at the following URLs in addition to this thread: ...

Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/sched.h | 5 +++-- kernel/fork.c | 32 +++++++++++++++----------------- kernel/sched.c | 23 +++++++++++++++++++++++ 3 files changed, 41 insertions(+), 19 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 63ddd1f..9132b42 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1305,6 +1305,8 @@ struct task_struct { struct pi_node node; struct pi_sink ...

PREEMPT_RT replaces most spinlock_t instances with a preemptible real-time lock that supports priority inheritance. An uncontended (fastpath) acquisition of this lock has no more overhead than its non-rt spinlock_t counterpart. However, the contended case has considerably more overhead so that the lock can maintain proper priority queue order and support pi-boosting of the lock owner, yet remaining fully preemptible. Instrumentation shows that the majority of acquisitions under ...

We have previously only laid some of the groundwork to use the PI library, but left the existing infrastructure in place in the rtmutex code. This patch converts the rtmutex PI code to officially use the PI library. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/rt_lock.h | 2 include/linux/rtmutex.h | 15 - include/linux/sched.h | 21 - kernel/fork.c | 2 kernel/rcupreempt-boost.c | 2 kernel/rtmutex-debug.c | 4 ...

Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/sched.h | 7 +++++-- kernel/fork.c | 32 +++++++++++++++----------------- kernel/sched.c | 21 +++++++++++++++++++++ 3 files changed, 41 insertions(+), 19 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 5521a64..7ae8eca 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1305,6 +1305,8 @@ struct task_struct { struct pi_node node; struct pi_sink ...

^^^^^^ --

applied to tip/core/rcu - thanks Paul. Ingo --

applied all 3 patches to tip/tracing/ftrace - thanks Steve. Ingo --

applied all 3 patches to tip/sched/devel - thanks Richard! Ingo --

ok, i've queued it up in tip/x86/pat. Ingo --

On Fri, 15 Aug 2008 17:25:55 +0200 nope is fine; the parser isn't that fragile against empty lines (in fact they get filtered out ;-) -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

i've applied it to tip/x86/geode. Should it go into v2.6.27 via x86/urgent, or should wait for v2.6.28? Ingo --

ok - i've put it into tip/x86/urgent as well. Ingo --

i've queued this up in tip/sched/urgent as it makes sense - but i'm also wondering, does this impact the volano numbers? Ingo --

From 62aa63382a5b20a6441f665c423a39f2f01e9b5e Mon Sep 17 00:00:00 2001 From: Ingo Molnar <mingo@elte.hu> Date: Fri, 15 Aug 2008 18:22:09 +0200 Subject: [PATCH] ftrace: ftrace_kill_atomic() build fix fix: kernel/built-in.o: In function `ftrace_dump': (.text+0x2e2ea): undefined reference to `ftrace_kill_atomic' Signed-off-by: Ingo Molnar <mingo@elte.hu> --- include/linux/ftrace.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/ftrace.h ...

applied to tip/core/rcu - thanks! Ingo --

Eeek! What is wrong with what we have already agreed to standardise on here people? dev_printk() for devices! It uniquely shows the device, what driver is bound to it (if any), the bus id, and everything else. It's in a parseable, standard format, that everyone agreed a few years was going to be the way to go! And now you want to create your own new one? Come on, please don't be that foolish. Please work with what we already have. Extend it or something to have these "magic tokens" ...

Please don't misinterpret. I don't want to make other errors parse like an ATA error, I want to make the plumbing be parallel. I want one umbrella mechanism for reporting things that are more important than just-another-printk(). Because frankly, "parse dmesg" is a pretty crappy way to have to monitor your system for failures, and I am tired of explaining to people why we still do that. Tim --

If I interpret Martins patches correctly he wants to be able to put add extended information to specific messages the kernel is printing. This is a good way to explain the rational of certain situations to people unwilling to read the sources ;) I don't think that he wants to unify all the printk's in the system. I don't think that reporting all errors "in the same way as an ATA error" makes any sense. That would just lead to very stupid and unnatural messages for all errors that are not like ...

That's great, then create something that can handle both! Don't throw away some wonderful information that way over half the kernel has access to just because the minority doesn't. That would mean that we would loose information in those drivers overall. thanks, greg k-h --

I suppose I could have worded the comment block better - the intent was to point out what the Broadcom chip returns, but by that point in the code Actually, that's probably a better idea, because my kernel is built with HZ=1000 - usecs_to_jiffies will do something different than ==1 for HZ=100 Let me go cook up and test another iteration of the patch, will probably be a few hours...

applied to tip/x86/gart, thanks! Any v2.6.27-urgency of this patch? Ingo --

Ingo, can you please send me details on the system? I'll try to track it down. --

ok, that's good - that's the latest, right? Ingo --

hm, looks good - but since i've got an earlier version of this included in -tip already: commit a24e8d36f5fc047dac9af6200322ed393f2e3175 Author: Mark Langsdorf <mark.langsdorf@amd.com> Date: Tue Jul 22 13:06:02 2008 -0500 x86: L3 cache index disable for 2.6.26 could you please send a delta patch against tip/master? http://people.redhat.com/mingo/tip.git/README Thanks, Ingo --

Yeah it doesn't seem to be very heavily used at this point. :) I see around 400 uses of id->driver_data right now, and only 2 of use_driver_data. If we remove the use_driver_data field, drivers (except for the 2 using the field) will start to see whatever values userspace passes to them rather than 0, and at least in some of the few cases I looked at that could cause breakage due to out of bounds references. So I think your point about dynamic IDs in general is a good one; this flag ...

So please identify at least one such driver where the only correct answer is 0. I even made it easy for you, i identified which drivers set dynamic_id and how. I identified specific drivers where its the wrong answer. So: If you are arguing the code is still needed, please identify at least one case that it is correct. (Oh, I don't buy that if 0 is safe but 1 is equally safe, that the existing code is correct). milton --

Hi Jesse, In fact we can do even better than that. We could accept from user-space only driver_data values which at least one device ID entry in the driver already uses. That should be fairly easy to implement, and would offer a level of safety an order of magnitude above what we have at the moment... And it works both ways: if 0 is not a valid data for some driver, that would force the user to provide a non-zero (and valid) data value. And it guarantees that the user can't ask for something ...

It is working! Thanks a lot David and Mikulas! alexb@sparky ~ $ zgrep LOCKDEP /proc/config.gz CONFIG_LOCKDEP_SUPPORT=y CONFIG_LOCKDEP=y CONFIG_DEBUG_LOCKDEP=y alexb@sparky ~ $ uname -a Linux sparky 2.6.27-rc3-00171-gb635ace-dirty #3 PREEMPT Fri Aug 15 14:52:40 MSD 2008 sparc64 sun4u TI UltraSparc IIi (Sabre) GNU/Linux --

[Empty message]

> This is a NUMA system right? True. My system is CPU: ia64 x8 Please let me know that operations ? --

As pointed out by Adrian D. off list: The max remote_node_defrag_ratio is 99. Maybe we need to change the comparison in remote_node_defrag_ratio_store() to allow 100 to switch off any node local allocs? --

I just questioned the purpose of reformatting the comment. I see no problem with lapic_is_integrated() appearing in 64-bit code -- if someone cannot figure out why it would appear there, they better practised some thinking at home before coming back. We have plenty of places with such constructs that expand to literals for some configurations all over our tree anyway. Maciej --

yeah - in fact for most unifications we did the 32-bit counterpart was the cleaner one. (which is no big surprise, 80%-90% of the x86 Linux use, even today, is on the 32-bit side - so most developers watch that one.) Ingo --

Indeed -- the change just moves a comment around from the obvious place (where it means: "the condition true applies to the 82489DX") to elsewhere while rephrasing it in a way that makes me wonder: "What the hell is that meant to mean?" Perhaps it is clearer to the others, but for me it is just obfuscation. I think the comment as it is is clear enough and is also clearly visible when browsing through the source, when you want to spot all the odd bits related to the discrete APIC. This ...

On Thu, Aug 14, 2008 at 11:44 PM, Maciej W. Rozycki Hi Maciej, don't really understand what do you mean. Do you mean it should be a separate patch for this code snippet? Actually since we always have lapic integrated on 64bit cpu gcc will eliminate this check. Cyrill --