Re: konqueror deadlocks on 2.6.22
On Sun, 2008-01-20 at 08:41 +0300, Al Boldi wrote: > logic. Any ideas how this could be fixed? BTW, no idea, fs is taboo land here. (panic() is my very favorite function...;) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
> I think I do. You appear to be arguing that small businesses, such as > paint shops or garages, could re-install iBCS2 support. You seem to be under the illusion that iBCS2 support works currently in mainline and that only this patch would break it. That's not the case. It's a significant patchkit that was only available in 2.4 and is now missing a lot of infrastructure and would probably be significant non-trivial work to forward port. Now if someone does that work they can as well readd the few hunks I'm removing here. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: konqueror deadlocks on 2.6.22
On Sun, 2008-01-20 at 08:41 +0300, Al Boldi wrote: > BTW Mike: Your server bounces my messages. Hm. I don't have a server. Might have something to do with some naughty task frequently scribbling zeros to /etc/resolv.conf when I brutally reboot my box (i give myself cause to do that quite a lot). Fixed for the thousandth time. Some day I'll track/shoot the bugger. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc8-mm1 kernel panic while bootup
On Sun, 20 Jan 2008 11:54:46 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Thu, 17 Jan 2008 19:24:13 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> > > wrote: > > > >> Hi Andrew, > >> > >> The 2.6.24-rc8-mm1 kernel panic while bootup with bootup message > > > > Can you please bisect it? I'd start with git-x86. These: > > > > ssb-add-ssb_pcihost_set_power_state-function.patch > > b44-power-down-phy-when-interface-down.patch > > drivers-net-wireless-iwlwifi-iwl-3945c-fix-printk-warning.patch > > drivers-net-wireless-iwlwifi-iwl-4965c-fix-printk-warning.patch > > > > drivers-net-wireless-rt2x00-rt2x00usbc-fix-uninitialized-var-warning.patch > > -> git-ipwireless_cs.patch > > > The kernel boots up while patches applied till here and fails with the next > check point. > of iommu-sg-merging-add-device_dma_parameters-structure.patch. > > > # > > revert-kvm-stuff-to-make-git-x86-apply.patch > > git-x86.patch > > git-x86-fixup.patch > > git-x86-fixup-2.patch > > acpi-default-unmap-fixpatch.patch > > git-x86-vs-pm-acquire-device-locks-on-suspend-rev-3.patch > > git-x86-fix-doubly-merged-patch.patch > > pci-dont-load-acpi_php-when-acpi-is-disabled.patch > > pci-dont-load-acpi_php-when-acpi-is-disabled-fix.patch > > # > > #X86-ANDI-START > > #X86-ANDI-END > > # > > # > > -> iommu-sg-merging-add-device_dma_parameters-structure.patch > > > > would be suitable test points. > > > >> Dual Core AMD Opteron(tm) Processor 270 stepping 02 > >> Unable to handle kernel paging request at 4a78 RIP: > >> [] __alloc_pages+0x40/0x31e > >> PGD 0 > >> Oops: [1] SMP > >> last sysfs file: > >> CPU 0 > >> Modules linked in: > >> Pid: 1, comm: swapper Not tainted 2.6.24-rc8-mm1-autotest #1 > >> RIP: 0010:[] [] > >> __alloc_pages+0x40/0x31e > >> RSP: :81003f9b9c60 EFLAGS: 00010246 > >> RAX: RBX: RCX: 0002 > >> RDX: 4a70 RSI: 0605 RDI: 805a6f66 > >> RBP: 00d0 R08: 003808c0 R09: 0003db89 > >> R10: e2fe6880 R11: 806287b0 R12: 4a70 > >> R13: R14: 0286 R15: 81003f9b6000 > >> FS: () GS:80664000() > >> knlGS: > >> CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > >> CR2: 4a78 CR3: 00201000 CR4: 06e0 > >> DR0: DR1: DR2: > >> DR3: DR6: 0ff0 DR7: 0400 > >> Process swapper (pid: 1, threadinfo 81003f9b8000, task > >> 81003f9b6000) > >> Stack: c0d0 0010 8027574f 8100e5c8 > >> c0d0 8026f320 81003f9b9c88 > >> 807fac90 807fac90 0286 > >> Call Trace: > >> [] ? zone_statistics+0x3f/0x97 > >> [] ? get_page_from_freelist+0x463/0x5b5 > >> [] ? new_slab+0x10e/0x261 > >> [] ? get_new_slab+0x20/0xaa > >> [] ? __slab_alloc+0x123/0x182 > >> [] ? process_zones+0x79/0x15e > >> [] ? kmem_cache_alloc_node+0x3c/0x70 > >> [] ? process_zones+0x79/0x15e > >> [] ? _spin_lock_irqsave+0x9/0xe > >> [] ? pageset_cpuup_callback+0x33/0x91 > >> [] ? notifier_call_chain+0x29/0x56 > >> [] ? _cpu_up+0x68/0x101 > >> [] ? cpu_up+0x54/0x61 > >> [] ? kernel_init+0xbf/0x2ef > >> [] ? _spin_unlock_irq+0x9/0xc > >> [] ? child_rip+0xa/0x12 > >> [] ? kernel_init+0x0/0x2ef > >> [] ? child_rip+0x0/0x12 > > > > Who added these question marks to the backtrace output and what are they > > for? > > > >> Code: 83 ec 38 65 4c 8b 3c 25 00 00 00 00 83 e0 10 89 44 24 0c 74 16 be 05 > >> 06 00 00 48 c7 c7 66 6f 5a 80 e8 a9 f4 fb ff e8 20 05 28 00 <49> 83 7c 24 > >> 08 00 49 8d 44 24 08 48 89 44 24 18 75 1a 48 c7 44 > >> RIP [] __alloc_pages+0x40/0x31e > >> RSP > >> CR2: 4a78 There is no way in which iommu-sg-merging-add-device_dma_parameters-structure.patch can cause __alloc_pages to crash. I'd be suspecting some weird interaction between this patch's changes to kernel layout and the real bug. I don't know what the real bug is though. Perhaps x86_64 memory enumeration or NUMA initialisation problems. Does it look familar to anyone? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sysfs network namespace support - was this patch set forgotten ?
Hello, I saw some posts (from about a month ago) about network namespace support patches; I wonder: what is the status of this patch set ? was it somehow forgotten ? (I don't see it in v2.6.24-rc8 mm tree). see: http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-12/msg07720.html http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-12/msg00096.html Regards, Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: disable_mtrr_trim only need for x86_64
On Jan 19, 2008 9:37 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Yinghai Lu wrote: > > [PATCH] x86: disable_mtrr_trim only need for x86_64 > > > > mtrr_trim_uncached_memory is only used in x86_64, > > > > so disable_mtrr_trim is not needed for x86_32 > > > > Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> > > That seems like a bug, and if so this patch goes the wrong direction. > (If the 32-bit code has another solution for the same problem, they > should be unified.) > > The trimming of uncachable memory affects both 32- and 64-bit kernels; > it's the same hardware, and even 32-bit kernels (with PAE) can access > memory above 4 GB. > the trim fix for x86_64 is update end_pfn, and use that as max_pfn, and max_low_pfn in setup_arch. but i386 is setup_arch is only using max_low_pfn. to make you happy, the simple way is update e820 table so code could be unified between i386 and x86_64 update the e820 table by checking mtrr like checking gart hole... is that OK? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc8 oops ext3_clear_inode+0x25/0xa0
On Sat, 2008-01-19 at 22:00 -0600, Eric Sandeen wrote: > Soeren Sonnenburg wrote: > > Dear all, > > > > I've just got this oops (causing the machine to hang finally)... > > > > Any ideas? > > Soeren > > I've seen an awful lot of oopses out there on this path, > kswapd->shrink_icache_memory; some get a little further and oops in > ext3_discard_reservation. > > A few were chalked up to bad memory, but others were not. Do you happen > to use suspend/resume? Indeed, I suspended/resumed this machine a couple of times before seeing this... And indeed it sometimes (on high activity, i.e. network/cpu/disk load as happens when backups are done) oopses/freezes - but only when I have suspended at least once... So I am quite confident it is not the memory - but yes if something corrupts memory on a suspend/resume cycle on this macbookpro1,1 then the effect could be the same :( > Thanks to kerneloops.org... :) > > All code > >0: 12 11 adc(%ecx),%dl >2: f8 clc >3: ff 66 90jmp*0xff90(%esi) >6: 83 ec 0csub$0xc,%esp >9: 89 1c 24mov%ebx,(%esp) >c: 8d 98 60 ff ff ff lea0xff60(%eax),%ebx > 12: 89 74 24 04 mov%esi,0x4(%esp) > 16: 89 c6 mov%eax,%esi > 18: 89 7c 24 08 mov%edi,0x8(%esp) > 1c: 8b 53 70mov0x70(%ebx),%edx > 1f: 8b 7b 54mov0x54(%ebx),%edi > 22: 85 d2 test %edx,%edx > 24: 74 16 je 0x3c > 26: 83 fa ffcmp$0x,%edx > 29: 74 11 je 0x3c > 2b:*f0 ff 0alock decl (%edx) <-- trapping > instruction > > Looks like it blew up in (inlined) posix_acl_release(), I think > EXT3_I(inode)->i_acl passed to it was 66e88e66, in %edx. > > I think %edi is the i_block_alloc_info, 0f01c883, which also looks > crunchy. Use after free perhaps? > > > BUG: unable to handle kernel paging request at virtual address 66e88e66 > > Nice symmetric number, anyway. :) > > I've seen enough of these now, something real seems to be going on but I > don't know what yet. And I unfortunately have no idea how to trace this down further/how to help you with this... Soeren > -Eric > > > printing eip: c01fac85 *pde = > > Oops: 0002 [#1] PREEMPT SMP > > Modules linked in: hci_usb hidp rfcomm l2cap bluetooth tun cpufreq_stats > > coretemp xfrm_user xfrm4_tunnel tunnel4 ipcomp esp4 ah4 aes_generic hfsplus > > binfmt_misc fuse ebtable_broute bridge llc ebtable_nat ebtable_filter > > ebtables eeprom applesmc hwmon input_polldev snd_hda_intel snd_pcm_oss > > snd_mixer_oss snd_pcm snd_timer appletouch evdev i2c_i801 snd soundcore > > snd_page_alloc sky2 video intel_agp output agpgart > > > > Pid: 205, comm: kswapd0 Not tainted (2.6.24-rc8-sonne #7) > > EIP: 0060:[] EFLAGS: 00010213 CPU: 1 > > EIP is at ext3_clear_inode+0x25/0xa0 > > EAX: c008f0a0 EBX: c008f000 ECX: EDX: 66e88e66 > > ESI: c008f0a0 EDI: 0f01c883 EBP: 004d ESP: f7d29ebc > > DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 > > Process kswapd0 (pid: 205, ti=f7d28000 task=f7fdf540 task.ti=f7d28000) > > Stack: c008f0a0 f7d29ef8 c0192d62 004d c008f0a0 c008f0a8 > > c019309a > >e98b9ac8 0080 0080 f7d29ef8 c01932ec 0080 > > c008f2b0 > >ea1bdcd8 0002d438 013f c04ac24c 00d0 c0166e4c 2e0b > > > > Call Trace: > > [] clear_inode+0x62/0x140 > > [] dispose_list+0x1a/0xe0 > > [] shrink_icache_memory+0x18c/0x250 > > [] shrink_slab+0x12c/0x1a0 > > [] kswapd+0x32d/0x4d0 > > [] autoremove_wake_function+0x0/0x40 > > [] complete+0x3d/0x60 > > [] kswapd+0x0/0x4d0 > > [] kthread+0x42/0x70 > > [] kthread+0x0/0x70 > > [] kernel_thread_helper+0x7/0x14 > > === > > Code: 12 11 f8 ff 66 90 83 ec 0c 89 1c 24 8d 98 60 ff ff ff 89 74 24 04 89 > > c6 89 7c 24 08 8b 53 70 8b 7b 54 85 d2 74 16 83 fa ff 74 11 ff 0a 0f > > 94 c0 84 c0 75 51 c7 43 70 ff ff ff ff 8b 53 74 85 > > EIP: [] ext3_clear_inode+0x25/0xa0 SS:ESP 0068:f7d29ebc > > ---[ end trace 8dd028de7ae6e34e ]--- > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
Andi Kleen wrote: > On Sun, Jan 20, 2008 at 04:03:22PM +1030, David Newall wrote: > >> It's not necessarily that simple. It might be for KFC and Dominoes, but >> for others, SCO is not the complete story. Many legacy systems are >> written in COBOL, and must pay a per-seat licence for that on top of the >> per-seat licence for UNIX. It is these systems that are most attracted >> towards SCO compatibility. >> > > Well I'm sure if they migrate they can either recompile or pay someone > to forward port and apply and support the iBCS emulation patchkit. > If they migrate they buy a new run-time licence. These costs about a thousand dollars for small sites. > But assuming there is no cache miss (which is a very conservative > assumption) and the strcmps cost 20 cycles and you got 1 million > 2Ghz Linux systems out there doing 100k execs each day we're talking > about 1000 CPU seconds wasted each day. That's not a very useful metric. It says nothing about what the benefit will be. Will any job complete sooner? Not measurably. Will less hardware be required? No. > (e.g. the old default ldt code which was for iBCS was just dropped -- > strangely you didn't raise your voice against that) > I wasn't around then, or I would have. >> Perhaps KFC could >> employ somebody to add it, but they'd more likely be able to convert >> their entire software stack instead. The paint shops and mechanics of >> the world would have little chance of that. >> > > Sorry, but I don't think you know what you're talking about here. I think I do. You appear to be arguing that small businesses, such as paint shops or garages, could re-install iBCS2 support. That is, of course, a nonsense in any other sense other than the purely theoretical, devoid as it is of realities such as--and this is just the most obvious--a sound business case. It's just not going to happen that way. Perhaps it's best we all ignore the outburst. I've stated the disadvantage, such as it is, in removing iBCS. What's the benefit? Is it, as I say, a tiny performance improvement per exec versus removing an itch that leads towards market domination? :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc8-mm1 kernel panic while bootup
Andrew Morton wrote: > On Thu, 17 Jan 2008 19:24:13 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > >> Hi Andrew, >> >> The 2.6.24-rc8-mm1 kernel panic while bootup with bootup message > > Can you please bisect it? I'd start with git-x86. These: > > ssb-add-ssb_pcihost_set_power_state-function.patch > b44-power-down-phy-when-interface-down.patch > drivers-net-wireless-iwlwifi-iwl-3945c-fix-printk-warning.patch > drivers-net-wireless-iwlwifi-iwl-4965c-fix-printk-warning.patch > drivers-net-wireless-rt2x00-rt2x00usbc-fix-uninitialized-var-warning.patch > -> git-ipwireless_cs.patch The kernel boots up while patches applied till here and fails with the next check point. of iommu-sg-merging-add-device_dma_parameters-structure.patch. > # > revert-kvm-stuff-to-make-git-x86-apply.patch > git-x86.patch > git-x86-fixup.patch > git-x86-fixup-2.patch > acpi-default-unmap-fixpatch.patch > git-x86-vs-pm-acquire-device-locks-on-suspend-rev-3.patch > git-x86-fix-doubly-merged-patch.patch > pci-dont-load-acpi_php-when-acpi-is-disabled.patch > pci-dont-load-acpi_php-when-acpi-is-disabled-fix.patch > # > #X86-ANDI-START > #X86-ANDI-END > # > # > -> iommu-sg-merging-add-device_dma_parameters-structure.patch > > would be suitable test points. > >> Dual Core AMD Opteron(tm) Processor 270 stepping 02 >> Unable to handle kernel paging request at 4a78 RIP: >> [] __alloc_pages+0x40/0x31e >> PGD 0 >> Oops: [1] SMP >> last sysfs file: >> CPU 0 >> Modules linked in: >> Pid: 1, comm: swapper Not tainted 2.6.24-rc8-mm1-autotest #1 >> RIP: 0010:[] [] __alloc_pages+0x40/0x31e >> RSP: :81003f9b9c60 EFLAGS: 00010246 >> RAX: RBX: RCX: 0002 >> RDX: 4a70 RSI: 0605 RDI: 805a6f66 >> RBP: 00d0 R08: 003808c0 R09: 0003db89 >> R10: e2fe6880 R11: 806287b0 R12: 4a70 >> R13: R14: 0286 R15: 81003f9b6000 >> FS: () GS:80664000() knlGS: >> CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b >> CR2: 4a78 CR3: 00201000 CR4: 06e0 >> DR0: DR1: DR2: >> DR3: DR6: 0ff0 DR7: 0400 >> Process swapper (pid: 1, threadinfo 81003f9b8000, task 81003f9b6000) >> Stack: c0d0 0010 8027574f 8100e5c8 >> c0d0 8026f320 81003f9b9c88 >> 807fac90 807fac90 0286 >> Call Trace: >> [] ? zone_statistics+0x3f/0x97 >> [] ? get_page_from_freelist+0x463/0x5b5 >> [] ? new_slab+0x10e/0x261 >> [] ? get_new_slab+0x20/0xaa >> [] ? __slab_alloc+0x123/0x182 >> [] ? process_zones+0x79/0x15e >> [] ? kmem_cache_alloc_node+0x3c/0x70 >> [] ? process_zones+0x79/0x15e >> [] ? _spin_lock_irqsave+0x9/0xe >> [] ? pageset_cpuup_callback+0x33/0x91 >> [] ? notifier_call_chain+0x29/0x56 >> [] ? _cpu_up+0x68/0x101 >> [] ? cpu_up+0x54/0x61 >> [] ? kernel_init+0xbf/0x2ef >> [] ? _spin_unlock_irq+0x9/0xc >> [] ? child_rip+0xa/0x12 >> [] ? kernel_init+0x0/0x2ef >> [] ? child_rip+0x0/0x12 > > Who added these question marks to the backtrace output and what are they for? > >> Code: 83 ec 38 65 4c 8b 3c 25 00 00 00 00 83 e0 10 89 44 24 0c 74 16 be 05 >> 06 00 00 48 c7 c7 66 6f 5a 80 e8 a9 f4 fb ff e8 20 05 28 00 <49> 83 7c 24 08 >> 00 49 8d 44 24 08 48 89 44 24 18 75 1a 48 c7 44 >> RIP [] __alloc_pages+0x40/0x31e >> RSP >> CR2: 4a78 -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup
On Sat, 19 Jan 2008, Mike Travis wrote:
> >> Excuse my ignorance but why wouldn't this work:
> >>
> >> static numanode_t pxm_to_node_map[MAX_PXM_DOMAINS]
> >> = { [0 ... MAX_PXM_DOMAINS - 1] =
> >> NUMA_NO_NODE };
> >> ...
> int acpi_map_pxm_to_node(int pxm)
> {
> >>> int node = pxm_to_node_map[pxm];
> >>>
> >>> if (node < 0)
> >> numanode_t node = pxm_to_node_map[pxm];
> >>
> >
> > Because NUMA_NO_NODE is 0xff on x86. That's a valid node id for
> > configurations with CONFIG_NODES_SHIFT equal to or greater than 8.
>
> Perhaps numanode_t should be set to u16 if MAX_NUMNODES > 255 to
> allow for an invalid value of 255?
>
Throughout the NUMA code you need a way to distinguish between an invalid
mapping and an actual node id. NID_INVAL is used to say there are no
additional node ids available for this system, the pxm-to-node mapping
doesn't yet exist, etc.
You can't get away with using a magic positive integer with those
semantics because CONFIG_NODES_SHIFT determines MAX_NUMNODES. All
nodemasks will have that many bits in their struct. So 255 will always be
a valid node id for shifts of 8 or larger. It isn't feasible to say for
these types of systems (or ia64 where the default shift is 10) that 255 is
some magic node id that means its invalid.
NID_INVAL is the only way to signify an invalid node id and that has
always been done with -1. So objects that store node ids that have the
possibility of being invalid must be signed. The only time you can use
unsigned objects are when you are guaranteed to have valid node ids.
> > Additionally, Linux has always discouraged typedefs when they do not
> > define an architecture-specific size. The savings from your patch for
> > CONFIG_NODES_SHIFT == 7 would be 256 bytes for this mapping.
> >
> > It's simply not worth it.
>
> So are you saying that I should just use u16 for all node ids whether
> CONFIG_NODES_SHIFT > 7 or not? Othersise, I would think that defining a
> typedef is a fairly clean solution.
>
You're assuming that CONFIG_NODES_SHIFT will never been larger than that
and you still wouldn't be able to use your new numanode_t for anything
that could return NID_INVAL.
> A quick grep shows that there are 35 arrays defined by MAX_NUMNODES in
> x86_64, 38 in X86_32 (not verified.) So it's not exactly a trivial
> amount of memory.
>
You're spinning the argument. Most of those arrays are not simply
returning node ids; most are returning structs or are arrays of unsigned
long type that return addresses. Those are unaffected by your change.
Others are initdata and is freed after boot anyway.
The handful of arrays thoughout the source that return node ids and are
not initdata would only save MAX_NUMNODES number of bytes with your
change for 8-bytes instead of 16-bytes. You're right, you might save a
KB of memory with the change. It's not worth it, especially since they
need to be signed anyway.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] VFS: create /proc//mountinfo
Miklos Szeredi wrote: - for mount ID's use IDA (from the IDR library) instead of a 32bit counter, which could overflow IDAs tend to get reused quickly, which can cause race conditions. Any reason not to just use a 64-bit counter? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: konqueror deadlocks on 2.6.22
Mike Galbraith wrote: > On Sat, 2008-01-19 at 21:14 +0300, Al Boldi wrote: > > I was just attacked by some deadlock issue involving sqlite3 and > > konqueror. While sqlite3 continues to slowly fill a 7M-record db in > > transaction mode, konqueror hangs for a few minutes, then continues only > > to hang again and again. > > > > Looks like an fs/blockIO issue involving fsync. > > > > As a workaround, is there a way to make fsync soft? > > Do you have the fs mounted data=writeback? A while back, I ran into > starvation on the order of minutes with my old/full ext2 fs until > mounting data=writeback. You are absolutely right. With data=writeback the hangs completely disappear, and sqlite3 insert performance increases 10x fold. Now data=writeback is known to be faster than data=ordered, but a 10x fold increase probably points to some sync contention within the data=ordered logic. Any ideas how this could be fixed? Thanks a lot! BTW Mike: Your server bounces my messages. -- Al -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
On Sun, Jan 20, 2008 at 04:03:22PM +1030, David Newall wrote: > It's not necessarily that simple. It might be for KFC and Dominoes, but > for others, SCO is not the complete story. Many legacy systems are > written in COBOL, and must pay a per-seat licence for that on top of the > per-seat licence for UNIX. It is these systems that are most attracted > towards SCO compatibility. Well I'm sure if they migrate they can either recompile or pay someone to forward port and apply and support the iBCS emulation patchkit. And for that person it will be only a few minutes to readd these hunks. However it doesn't make any sense to have all Linux systems ever out there who can't even run these binaries without significantly changing the kernel have carry the overhead of these unnecessary checks. > > >>> But it does not make sense for all Linux kernels to always check for iBCS > >>> executables > >>> when they don't have to code to run them anyways. > >>> > >>> > >> I don't suppose you're suggesting this will make a big difference. Even > >> if every exec did nothing but immediately exit, it still wouldn't make > >> much difference. > >> > > > > It's not a big difference, but why do unnecessary work on all > > Linux kernels? There are a lot of Linux machines out there and > > if all of them only do a little unnecessary work each fork() > > over a year it adds up to really a lot of wasted cycles. > > > > It still adds up to something that nobody can perceive, not even using a > very fine stopwatch and counting over a period of years. I'm not sure the cost is that low because they access one (or more likely two) out of line data cache line for the two strings and kernel often runs cache cold because userland tends to fill the caches and then a cache miss can be actually hundreds of cycles, possibly multiplied by two. But assuming there is no cache miss (which is a very conservative assumption) and the strcmps cost 20 cycles and you got 1 million 2Ghz Linux systems out there doing 100k execs each day we're talking about 1000 CPU seconds wasted each day. That should be certainly measurable on most stop watches. > > > Especially since the few people who might really > > need it can easily readd it. > > > No. Very few people can add it, easily or otherwise. They have to patch the kernel in non trivial ways anyways because they would need to patch in the whole old iBCS emulation layer. (e.g. the old default ldt code which was for iBCS was just dropped -- strangely you didn't raise your voice against that) > Perhaps KFC could > employ somebody to add it, but they'd more likely be able to convert > their entire software stack instead. The paint shops and mechanics of > the world would have little chance of that. Sorry, but I don't think you know what you're talking about here. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Celeron Core
On Sun, Jan 20, 2008 at 03:53:41PM +1030, David Newall wrote: > Andi Kleen wrote: > >> Isn't it the case that an idle machine will use > >> less power when throttled than when not? > >> > > > > No that is not the case (not even on old CPUs) > > > Then why would it run cooler? Ok for one more (but last) time: Throttling just lowers the short term heat spikes to prevent short term damage to the silicon. For that it focusses on lowering the absolute temperature at a given point. That only applies when the CPU is busy. But for total power consumption (or rather more concretly conserving your battery) you don't care about absolute temperature at a given point (as long as it is not high enough that it destroys the CPU) you care about how much power is consumed (and heat generated from that) averaged out over a longer time. And for most typical workloads (not running endless loops; significant idle time) throttling makes no difference and in fact often (especially on laptop CPUs with deeper sleep modi like the original reported had one) makes it likely worse (see previous mails for details why) > I'm not convinced. I'm along way from that. Frankly that's fine for me. I don't really feel any need to convince you. I can live with your metal model of CPU physics not being accurate. -Andi (feeling a bit like a broken record) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: disable_mtrr_trim only need for x86_64
Yinghai Lu wrote: [PATCH] x86: disable_mtrr_trim only need for x86_64 mtrr_trim_uncached_memory is only used in x86_64, so disable_mtrr_trim is not needed for x86_32 Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> That seems like a bug, and if so this patch goes the wrong direction. (If the 32-bit code has another solution for the same problem, they should be unified.) The trimming of uncachable memory affects both 32- and 64-bit kernels; it's the same hardware, and even 32-bit kernels (with PAE) can access memory above 4 GB. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
Andi Kleen wrote: > On Sun, Jan 20, 2008 at 03:16:25PM +1030, David Newall wrote: > >> Andi Kleen wrote: >> >>> On Sun, Jan 20, 2008 at 12:57:29PM +1030, David Newall wrote: >>> >>> compatibility. This is a sleeping giant for Linux. There are plenty of >>> Interesting choice of words. >>> >>> >> KFC and Dominoes use SCO for their cash registers, to pick just two >> enormous future opportunities. >> > > I suppose if they update their cash registers they will just go > with fully Linux binaries. > It's not necessarily that simple. It might be for KFC and Dominoes, but for others, SCO is not the complete story. Many legacy systems are written in COBOL, and must pay a per-seat licence for that on top of the per-seat licence for UNIX. It is these systems that are most attracted towards SCO compatibility. >>> But it does not make sense for all Linux kernels to always check for iBCS >>> executables >>> when they don't have to code to run them anyways. >>> >>> >> I don't suppose you're suggesting this will make a big difference. Even >> if every exec did nothing but immediately exit, it still wouldn't make >> much difference. >> > > It's not a big difference, but why do unnecessary work on all > Linux kernels? There are a lot of Linux machines out there and > if all of them only do a little unnecessary work each fork() > over a year it adds up to really a lot of wasted cycles. > It still adds up to something that nobody can perceive, not even using a very fine stopwatch and counting over a period of years. > Especially since the few people who might really > need it can easily readd it. > No. Very few people can add it, easily or otherwise. Perhaps KFC could employ somebody to add it, but they'd more likely be able to convert their entire software stack instead. The paint shops and mechanics of the world would have little chance of that. > But Linux is not good for this currently, at least not unless you > add a significant patch (which I'm not sure does even exist > for modern 2.6; iBCS was mainly deployed on 2.4 kernels). And when you > add that patch you can easily readd the strcmps too. > Yes, I agree. Neither side of this issue is of great moment. On the one hand we have something that's half-baked at best; on the other hand we want to remove it for non perceivable gain or benefit. >> simplification of the story, I know, but still hits the plot highlights. >> > > You're worried about this patch generating headlines? No, I don't see this as headline making material. The existing code, though, is a rough spot in the kernel. So long as it's there, somebody will feel the need to scratch it, as you do. Absent the choice of removing the code, and the only way left to scratch is to complete it. Remove the code and there's nothing there that itches, which is a bad thing in this case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Update emacs indentation instructions.
On Sun, Jan 20, 2008 at 02:40:29AM +0100, Johannes Weiner wrote: +(setq c-default-style "linux") This variable is not defined when emacs starts up. Best is to always use a hook. Both of these examples are directly copied out of the emacs manual. Setting a variable before a module is loaded will override the default set in the module. No need to use a hook for something simple like this. c-default-style is defined with 'defcustom': Declare SYMBOL as a customizable variable that defaults to VALUE. DOC is the variable documentation. Neither SYMBOL nor VALUE need to be quoted. If SYMBOL is not already bound, initialize it to VALUE. so the intent is to allow the user to override the value by setting it before the module is loaded. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Celeron Core
Andi Kleen wrote: >> Isn't it the case that an idle machine will use >> less power when throttled than when not? >> > > No that is not the case (not even on old CPUs) > Then why would it run cooler? What generates the heat when not throttled? What stops generating heat when throttled? And you say this happens without reducing power consumption? I'm not convinced. I'm a long way from that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
On Sun, Jan 20, 2008 at 03:16:25PM +1030, David Newall wrote: > Andi Kleen wrote: > > On Sun, Jan 20, 2008 at 12:57:29PM +1030, David Newall wrote: > > > >> compatibility. This is a sleeping giant for Linux. There are plenty of > >> > > > > Interesting choice of words. > > > KFC and Dominoes use SCO for their cash registers, to pick just two > enormous future opportunities. I suppose if they update their cash registers they will just go with fully Linux binaries. > > But it does not make sense for all Linux kernels to always check for iBCS > > executables > > when they don't have to code to run them anyways. > > > > I don't suppose you're suggesting this will make a big difference. Even > if every exec did nothing but immediately exit, it still wouldn't make > much difference. It's not a big difference, but why do unnecessary work on all Linux kernels? There are a lot of Linux machines out there and if all of them only do a little unnecessary work each fork() over a year it adds up to really a lot of wasted cycles. Especially since the few people who might really need it can easily readd it. > Likewise, I take your point about proper iBCS support (and I suppose > it's really iBCS2 that we're talking about.) My concern is that > removing this now gains almost nothing, 2 strcmp per exec is as close to > nothing as anything, but it sends a message with which I disagree. The > message should be that Linux is good for, well the same things FreeBSD > is, and includes running Solaris and SCO binaries. This is a major But Linux is not good for this currently, at least not unless you add a significant patch (which I'm not sure does even exist for modern 2.6; iBCS was mainly deployed on 2.4 kernels). And when you add that patch you can easily readd the strcmps too. > simplification of the story, I know, but still hits the plot highlights. You're worried about this patch generating headlines? -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Celeron Core
> Isn't it the case that an idle machine will use > less power when throttled than when not? No that is not the case (not even on old CPUs) -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fill in missing pv_mmu_ops entries for PAGETABLE_LEVELS >= 3
Marcelo Tosatti wrote:
On Fri, Jan 18, 2008 at 03:20:15PM -0200, Glauber de Oliveira Costa wrote:
Hi,
This small series provides some more fixes towards the goal
to have the PARAVIRT selectable for x86_64. After that, just
some more small steps are needed.
The first fix is not even specific for PARAVIRT, and it's actually
preventing the whole tree from booting.
And the following allows PARAVIRT kernels to boot on x86_64.
-
Fill in missing pagetable manipulation entries in pv_mmu_ops
for PAGETABLE_LEVELS >= 3.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Looks good, thanks.
Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Index: linux-2.6-x86/arch/x86/kernel/paravirt.c
===
--- linux-2.6-x86.orig/arch/x86/kernel/paravirt.c
+++ linux-2.6-x86/arch/x86/kernel/paravirt.c
@@ -396,16 +396,25 @@ struct pv_mmu_ops pv_mmu_ops = {
.kmap_atomic_pte = kmap_atomic,
#endif
+#if PAGETABLE_LEVELS >= 3
#ifdef CONFIG_X86_PAE
.set_pte_atomic = native_set_pte_atomic,
.set_pte_present = native_set_pte_present,
- .set_pud = native_set_pud,
.pte_clear = native_pte_clear,
.pmd_clear = native_pmd_clear,
-
+#endif
+ .set_pud = native_set_pud,
+ .set_pgd = native_set_pgd,
+ .pgd_clear = native_pgd_clear,
.pmd_val = native_pmd_val,
.make_pmd = native_make_pmd,
+
+#if PAGETABLE_LEVELS == 4
+ .pud_val = native_pud_val,
+ .make_pud = native_make_pud,
+ .pud_clear = native_pud_clear,
#endif
+#endif /* PAGETABLE_LEVELS >= 3 */
.pte_val = native_pte_val,
.pgd_val = native_pgd_val,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: fix unconditional arch/x86/kernel/pcspeaker.c?compiling
On Friday 18 January 2008 11:10:19 Matt Mackall wrote: > > * Disable support for readahead, page writeback, pdflush and swap > > when we have no storage at all (typically booting from an > > initramfs). This corresponds to 69 KB of source code! > > That'd be nice, yes. It would probably make sense to be able to disable > just readahead support when we're working with only solid-state devices. Very nice. From a UI standpoint, shouldn't disabling the block layer take at least some of that out? (Or disabling the block layer and all network filesystems. /me tries to remember whether jffs2 depends on the block layer. Now that qemu can fake an mtd, I really need to start playing with that...) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
Andi Kleen wrote: > On Sun, Jan 20, 2008 at 12:57:29PM +1030, David Newall wrote: > >> compatibility. This is a sleeping giant for Linux. There are plenty of >> > > Interesting choice of words. > KFC and Dominoes use SCO for their cash registers, to pick just two enormous future opportunities. > But it does not make sense for all Linux kernels to always check for iBCS > executables > when they don't have to code to run them anyways. > I don't suppose you're suggesting this will make a big difference. Even if every exec did nothing but immediately exit, it still wouldn't make much difference. Likewise, I take your point about proper iBCS support (and I suppose it's really iBCS2 that we're talking about.) My concern is that removing this now gains almost nothing, 2 strcmp per exec is as close to nothing as anything, but it sends a message with which I disagree. The message should be that Linux is good for, well the same things FreeBSD is, and includes running Solaris and SCO binaries. This is a major simplification of the story, I know, but still hits the plot highlights. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: disable_mtrr_trim only need for x86_64
[PATCH] x86: disable_mtrr_trim only need for x86_64
mtrr_trim_uncached_memory is only used in x86_64,
so disable_mtrr_trim is not needed for x86_32
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 46763e3..608c88a 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_driver = {
.resume = mtrr_restore,
};
+#ifdef CONFIG_X86_64
static int disable_mtrr_trim;
static int __init disable_mtrr_trim_setup(char *str)
@@ -633,7 +634,6 @@ static int __init disable_mtrr_trim_setup(char *str)
}
early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
-#ifdef CONFIG_X86_64
/**
* mtrr_trim_uncached_memory - trim RAM not covered by MTRRs
*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Celeron Core
Andi Kleen wrote: > I think the misunderstanding on your side is relative to what there > is less heat. Throttling essentially reduces temporary heat spikes on > the silicon, but does not make the system overall take less power > or generate less heat as measured over a longer time because it will > be idle less. > I don't understand this, and it seems wrong. Most machines spend most of their time doing nothing, or as close to nothing as they're allowed. Idle, in other words. Isn't it the case that an idle machine will use less power when throttled than when not? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]
On Thursday 17 January 2008 04:47, Abhishek Rai wrote: > > if Abhishek wants to pursue it, would be to pull in all of the > > indirect blocks when the file is opened, and create an in-memory > > extent tree that would speed up access to the file. It's rarely > > worth doing this without metaclustering, since it doesn't help for > > sequential I/O, only random I/O, but with metaclustering it would > > also be a win for sequential I/O. (This would also remove the > > minor performance degradation for sequential I/O imposed by > > metaclustering, and in fact improve it slightly for really big > > files.) > > Also, since the in memory extent tree will now occupy much less > space, we can keep them cached for a much longer time which will > improve performance of random reads. The new metaclustering patch is > more amenable to this trick since it reduces fragmentation thereby > reducing the number of extents. I can see value in preemptively loading indirect blocks into the buffer cache, but is building a second-order extent tree really worth the effort? Probing the buffer cache is very fast. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression with idle cpu cycle handling in 2.6.24 (compared to 2.6.22)
On Sun, Jan 20, 2008 at 09:03:38AM +0530, Dhaval Giani wrote: > On Sat, Jan 19, 2008 at 03:52:44PM +0100, dAniel hAhler wrote: > > Hello, > > > > I've now found the reason and a workaround for this. Apparently, it's > > related to CONFIG_FAIR_USER_SCHED and can be worked around by > > assigning a really small value to the boinc users cpu_share (125 is > > the uid of "boinc"): > > $ echo 2 | sudo tee /sys/kernel/uids/125/cpu_share > > > > Correct, that is the way to go about it. > > > While looking around, I've found the following patch, which seems to > > address this: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0710.3/3849.html > > > > It has been posted here, but without any response. > > > > btw: writing 1 into "cpu_share" totally locks up the computer! > > > > Can you please provide some more details. Can you go into another > console (try ctrl-alt-f1) and try to reproduce the issue there. Could > you take a photo of the oops/panic and upload it somewhere so that we > can see it? > I've not been able to reproduce this problem on my system here. Do you try to change the cpu_share of the current user? -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc8 oops ext3_clear_inode+0x25/0xa0
Soeren Sonnenburg wrote: > Dear all, > > I've just got this oops (causing the machine to hang finally)... > > Any ideas? > Soeren I've seen an awful lot of oopses out there on this path, kswapd->shrink_icache_memory; some get a little further and oops in ext3_discard_reservation. A few were chalked up to bad memory, but others were not. Do you happen to use suspend/resume? Thanks to kerneloops.org... :) All code 0: 12 11 adc(%ecx),%dl 2: f8 clc 3: ff 66 90jmp*0xff90(%esi) 6: 83 ec 0csub$0xc,%esp 9: 89 1c 24mov%ebx,(%esp) c: 8d 98 60 ff ff ff lea0xff60(%eax),%ebx 12: 89 74 24 04 mov%esi,0x4(%esp) 16: 89 c6 mov%eax,%esi 18: 89 7c 24 08 mov%edi,0x8(%esp) 1c: 8b 53 70mov0x70(%ebx),%edx 1f: 8b 7b 54mov0x54(%ebx),%edi 22: 85 d2 test %edx,%edx 24: 74 16 je 0x3c 26: 83 fa ffcmp$0x,%edx 29: 74 11 je 0x3c 2b:* f0 ff 0alock decl (%edx) <-- trapping instruction Looks like it blew up in (inlined) posix_acl_release(), I think EXT3_I(inode)->i_acl passed to it was 66e88e66, in %edx. I think %edi is the i_block_alloc_info, 0f01c883, which also looks crunchy. Use after free perhaps? > BUG: unable to handle kernel paging request at virtual address 66e88e66 Nice symmetric number, anyway. :) I've seen enough of these now, something real seems to be going on but I don't know what yet. -Eric > printing eip: c01fac85 *pde = > Oops: 0002 [#1] PREEMPT SMP > Modules linked in: hci_usb hidp rfcomm l2cap bluetooth tun cpufreq_stats > coretemp xfrm_user xfrm4_tunnel tunnel4 ipcomp esp4 ah4 aes_generic hfsplus > binfmt_misc fuse ebtable_broute bridge llc ebtable_nat ebtable_filter > ebtables eeprom applesmc hwmon input_polldev snd_hda_intel snd_pcm_oss > snd_mixer_oss snd_pcm snd_timer appletouch evdev i2c_i801 snd soundcore > snd_page_alloc sky2 video intel_agp output agpgart > > Pid: 205, comm: kswapd0 Not tainted (2.6.24-rc8-sonne #7) > EIP: 0060:[] EFLAGS: 00010213 CPU: 1 > EIP is at ext3_clear_inode+0x25/0xa0 > EAX: c008f0a0 EBX: c008f000 ECX: EDX: 66e88e66 > ESI: c008f0a0 EDI: 0f01c883 EBP: 004d ESP: f7d29ebc > DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 > Process kswapd0 (pid: 205, ti=f7d28000 task=f7fdf540 task.ti=f7d28000) > Stack: c008f0a0 f7d29ef8 c0192d62 004d c008f0a0 c008f0a8 > c019309a >e98b9ac8 0080 0080 f7d29ef8 c01932ec 0080 > c008f2b0 >ea1bdcd8 0002d438 013f c04ac24c 00d0 c0166e4c 2e0b > > Call Trace: > [] clear_inode+0x62/0x140 > [] dispose_list+0x1a/0xe0 > [] shrink_icache_memory+0x18c/0x250 > [] shrink_slab+0x12c/0x1a0 > [] kswapd+0x32d/0x4d0 > [] autoremove_wake_function+0x0/0x40 > [] complete+0x3d/0x60 > [] kswapd+0x0/0x4d0 > [] kthread+0x42/0x70 > [] kthread+0x0/0x70 > [] kernel_thread_helper+0x7/0x14 > === > Code: 12 11 f8 ff 66 90 83 ec 0c 89 1c 24 8d 98 60 ff ff ff 89 74 24 04 89 c6 > 89 7c 24 08 8b 53 70 8b 7b 54 85 d2 74 16 83 fa ff 74 11 ff 0a 0f 94 c0 > 84 c0 75 51 c7 43 70 ff ff ff ff 8b 53 74 85 > EIP: [] ext3_clear_inode+0x25/0xa0 SS:ESP 0068:f7d29ebc > ---[ end trace 8dd028de7ae6e34e ]--- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]
On Tuesday 15 January 2008 03:04, Andrew Morton wrote: > I'm wondering about the real value of this change, really. > > In any decent environment, people will fsck their ext3 filesystems > during planned downtime, and the benefit of reducing that downtime > from 6 hours/machine to 2 hours/machine is probably fairly small, > given that there is no service interruption. (The same applies to > desktops and laptops). > > Sure, the benefit is not *zero*, but it's small. Much less than it > would be with ext2. I mean, the "avoid unplanned fscks" feature is > the whole reason why ext3 has journalling (and boy is that feature > expensive during normal operation). > > So... it's unobvious that the benefit of this feature is worth its > risks and costs? Since I am waiting for an Ext3 fsck to complete right now, I thought I would while away the time by tagging on my "me too" to the concensus that faster fsck is indeed worth the cost, which is (ahem) free. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Where's the create() pointer?
Trond Myklebust wrote > > On Sat, 2008-01-19 at 12:02 -0700, Justin Banks wrote: > > Trond Myklebust wrote > > > > > > On Sat, 2008-01-19 at 08:07 -0700, Justin Banks wrote: > > > > It's probably been this way for a long time, and I'm just noticing, but > > > > I can't seem to find the create() (among others) pointer for NFS > > > > filesystems. > > > > > > > > Specifically, If I look at sb->s_root->d_inode->i_op there's no create > > > > there. How do I find it? I'm guessing that the ability to share mount > > > > structures between multiple NFS mounts resulted in some kind of fake > > > > superblock, but I just can't figure out where to find the functions. > > > > > > Why would you want to do this in the first place? > > > > I'm just looking at trapping new creates on NFS, and so I need to find > > the pointer. > > What is your purpose in trapping creates on the client? Is this for > accounting purposes? If so, why wouldn't inotify, or even a systemtap > script suffice? Could do inotify, except on a large-ish filesystem, it's really unuseable, if you want to track everything that's going on. > Anyhow, the simplest way to find the pointer is to grep for nfs_create > in /proc/kallsyms. Ugh. That's an ugly way, seems to me. Isn't there a way, given the superblock? I mean, the VFS does it that way, doesn't it? -justinb -- Justin Banks BakBone Software [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression with idle cpu cycle handling in 2.6.24 (compared to 2.6.22)
On Sat, Jan 19, 2008 at 03:52:44PM +0100, dAniel hAhler wrote: > Hello, > > I've now found the reason and a workaround for this. Apparently, it's > related to CONFIG_FAIR_USER_SCHED and can be worked around by > assigning a really small value to the boinc users cpu_share (125 is > the uid of "boinc"): > $ echo 2 | sudo tee /sys/kernel/uids/125/cpu_share > Correct, that is the way to go about it. > While looking around, I've found the following patch, which seems to > address this: > http://www.ussg.iu.edu/hypermail/linux/kernel/0710.3/3849.html > > It has been posted here, but without any response. > > btw: writing 1 into "cpu_share" totally locks up the computer! > Can you please provide some more details. Can you go into another console (try ctrl-alt-f1) and try to reproduce the issue there. Could you take a photo of the oops/panic and upload it somewhere so that we can see it? Thanks -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
On Sun, Jan 20, 2008 at 12:57:29PM +1030, David Newall wrote: > Andi Kleen wrote: > > Can you please queue this patch in -mm for .25. It was posted earlier > > and nobody complained. > > I'm sure I complained. I'm sure I said something about SCO Did you? > compatibility. This is a sleeping giant for Linux. There are plenty of Interesting choice of words. > machines running legacy SCO applications, just waiting for painless > migration to some other platform. > > We should not be dismantling the scaffolding that's needed for that. See the rationale in the patch -- any iBCS application will need a significant kernel patch. If people add this kernel patch they can easily patch the three more places that detect the executables. But it does not make sense for all Linux kernels to always check for iBCS executables when they don't have to code to run them anyways. Now if iBCS support is truly as important as you claim I'm sure someone will eventually submit a patch for mainline to support it properly. If yes the hooks can be readded in a clean way, not in a hackish way like they currently exists. -Andi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
Andi Kleen wrote: > Can you please queue this patch in -mm for .25. It was posted earlier > and nobody complained. I'm sure I complained. I'm sure I said something about SCO compatibility. This is a sleeping giant for Linux. There are plenty of machines running legacy SCO applications, just waiting for painless migration to some other platform. We should not be dismantling the scaffolding that's needed for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Update emacs indentation instructions.
Hi, David Brown <[EMAIL PROTECTED]> writes: > +Fortunately, modern versions of GNU emacs support different indentation > +styles. If you want to use the Linux kernel style for all C code, place > +the following in your .emacs file: > + > +(setq c-default-style "linux") This variable is not defined when emacs starts up. Best is to always use a hook. So I'd suggest either (add-hook 'c-mode-hook (lambda () (c-set-style "linux"))) or for the conditional case (add-hook 'c-mode-hook (lambda () (c-set-style (or (and (string-match "/usr/src/linux" (or (buffer-file-name) "")) "linux") "free-group-style" Perhaps the logic could be a bit more readable :-) Other than that, good idea to finally remove this ugly recommendation! Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup
On Jan 19, 2008 4:41 PM, Mike Travis <[EMAIL PROTECTED]> wrote:
> David Rientjes wrote:
> > On Sat, 19 Jan 2008, Mike Travis wrote:
> >
> >>> Yeah, NID_INVAL is negative so no unsigned type will work here,
> >>> unfortunately. And that reduces the intended savings of your change since
> >>> the smaller type can only be used with a smaller CONFIG_NODES_SHIFT.
> >>>
> >> Excuse my ignorance but why wouldn't this work:
> >>
> >> static numanode_t pxm_to_node_map[MAX_PXM_DOMAINS]
> >> = { [0 ... MAX_PXM_DOMAINS - 1] =
> >> NUMA_NO_NODE };
> >> ...
> int acpi_map_pxm_to_node(int pxm)
> {
> >>> int node = pxm_to_node_map[pxm];
> >>>
> >>> if (node < 0)
> >> numanode_t node = pxm_to_node_map[pxm];
> >>
> >
> > Because NUMA_NO_NODE is 0xff on x86. That's a valid node id for
> > configurations with CONFIG_NODES_SHIFT equal to or greater than 8.
>
> Perhaps numanode_t should be set to u16 if MAX_NUMNODES > 255 to
> allow for an invalid value of 255?
>
> #if MAX_NUMNODES > 255
> typedef u16 numanode_t;
> #else
> typedef u8 numanode_t;
> #endif
>
> >
> >> if (node != NUMA_NO_NODE) {
> >
> > Wrong, this should be
> >
> > node == NUMA_NO_NODE
>
> Oops, yes you're right.
>
>
> if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
> return NID_INVAL;
> node = first_unset_node(nodes_found_map);
> __acpi_map_pxm_to_node(pxm, node);
> node_set(node, nodes_found_map);
> }
> >
> > The net result of this is that if a proximity domain is looked up through
> > acpi_map_pxm_to_node() and already has a mapping to node 255 (legal with
> > CONFIG_NODES_SHIFT == 8), this function will return NID_INVAL since the
> > weight of nodes_found_map is equal to MAX_NUMNODES.
>
> >
> > You simply can't use valid node id's to signify invalid or unused node
> > ids.
> >
> >> or change:
> >> #define NID_INVAL (-1)
> >> to
> >> #define NID_INVAL ((numanode_t)(-1))
> >> ...
> >> if (node != NID_INVAL) {
> >
> > You mean
> >
> > node == NID_INVAL
> >
> if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
> return NID_INVAL;
> node = first_unset_node(nodes_found_map);
> __acpi_map_pxm_to_node(pxm, node);
> node_set(node, nodes_found_map);
> }
> >
> > That's the equivalent of your NUMA_NO_NODE code above. The fact remains
> > that (numanode_t)-1 is still a valid node id for MAX_NUMNODES >= 256.
> >
> > So, as I said in my initial reply, the only way to get the savings you're
> > looking for is to use u8 for CONFIG_NODES_SHIFT <= 7 and then convert all
> > NID_INVAL users to use NUMA_NO_NODE.
>
> Yes, I agree. I'll do the changes you're suggesting.
>
> > Additionally, Linux has always discouraged typedefs when they do not
> > define an architecture-specific size. The savings from your patch for
> > CONFIG_NODES_SHIFT == 7 would be 256 bytes for this mapping.
> >
> > It's simply not worth it.
>
> So are you saying that I should just use u16 for all node ids whether
> CONFIG_NODES_SHIFT > 7 or not? Othersise, I would think that defining a
> typedef is a fairly clean solution.
>
> A quick grep shows that there are 35 arrays defined by MAX_NUMNODES in
> x86_64, 38 in X86_32 (not verified.) So it's not exactly a trivial
> amount of memory.
just use int for node id, and -1 will be NON_VALID...
or s16?
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: new file in kernel.
On Sat, 2008-01-19 12:12:10 -0300, Rafael Sisto <[EMAIL PROTECTED]> wrote: > Dear Jan, > > The idea of the indirection is to make it transparent for the user. > The idea is to do almost the same as what IPC does. The user calls > "get", then "attach". In the "get" syscall I create a tmp file and > return some id. Then the user calls an "attach" syscall with the > returned id. > > The result is that he gets a shared memorymapped to his vma. So my understanding is that you want to get a "IPC shared memory for dummies" API. You're already willing to use custom-numbered system calls, requiring to recompile the Linux kernel, having to add these system calls to libc (or putting _syscallX macros into the application's code) and loosing all portability for the application using this API. My point of view is that this is a planed nightmare :) I'd suggest to dig into "Unix Network Programming, Volume 2. Interprocess Communications" and implement that API as a library instead of using a set of new kernel system calls. That way, the applications using it will use that API and only that. They won't require operatins system specific modifications afterwards. OTOH, this library will probably quite portable by itself and shouldn't need any kernel changes, independent of the underlying kernel. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: http://perl.plover.com/Questions.html the second : signature.asc Description: Digital signature
Re: [PATCH 4/5] x86: Add config variables for SMP_MAX
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> and then it crashes with:
>>
>> [0.00] Bootmem setup node 0 -3fff
>> [0.00] KERN_NOTICE cpu_to_node(0): usage too early!
>> PANIC: early exception 06 rip 10:81f77f30 error 0 cr2 f06f53
>> [0.00] Pid: 0, comm: swapper Not tainted 2.6.24-rc8 #422
>> [0.00]
>> [0.00] Call Trace:
>> [0.00] [] ? setup_node_bootmem+0x1a0/0x1b8
>> [0.00] [] ? acpi_scan_nodes+0x204/0x255
>> [0.00] [] ? acpi_scan_nodes+0x204/0x255
>> [0.00] [] ? numa_initmem_init+0x343/0x471
>>
I *think* but have not been able to verify that this will fix the above panic:
--- a/arch/x86/mm/srat_64.c
+++ b/arch/x86/mm/srat_64.c
@@ -393,7 +393,7 @@ int __init acpi_scan_nodes(unsigned long
setup_node_bootmem(i, nodes[i].start, nodes[i].end);
for (i = 0; i < NR_CPUS; i++) {
- int node = cpu_to_node(i);
+ int node = early_cpu_to_node(i);
if (node == NUMA_NO_NODE)
continue;
if (!node_isset(node, node_possible_map))
The problem is that the x86 test tree kernel doesn't boot, even without my
changes. And the stack trace I don't think is correct.
Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc8-mm1: WARN_ON() in clockevents_register_device() on HP nx6325
On Thursday, 17 of January 2008, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/ > > - selinux is busted on one of my two selinux-enabled test machines. > > - suspend-to-ram and suspend-to-disk are totally hosed on one of my test > machines. I guess I get to bisect this. Something goes wrong in the timers land. I get this on boot: ..MP-BIOS bug: 8254 timer not connected to IO-APIC Disabling APIC timer [ cut here ] WARNING: at /home/rafael/src/mm/linux-2.6.24-rc8-mm1/kernel/time/clockevents.c:1 65 clockevents_register_device+0x36/0xc4() Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.24-rc8-mm1-rjw #7 Call Trace: [] warn_on_slowpath+0x58/0x6b [] ? native_read_tsc+0x18/0x22 [] ? printk+0x67/0x69 [] clockevents_register_device+0x36/0xc4 [] setup_APIC_timer+0x61/0x68 [] setup_boot_APIC_clock+0x1ba/0x1c5 [] smp_prepare_cpus+0x521/0x542 [] kernel_init+0x64/0x2ef [] child_rip+0xa/0x12 [] ? kernel_init+0x0/0x2ef [] ? child_rip+0x0/0x12 ---[ end trace ca143223eefdc828 ]--- SMP alternatives: switching to SMP code Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 3990.34 BogoMIPS (lpj=7980687) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping 02 [ cut here ] Brought up 2 CPUs WARNING: at /home/rafael/src/mm/linux-2.6.24-rc8-mm1/kernel/time/clockevents.c:1 65 clockevents_register_device+0x36/0xc4() Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1-rjw #7 Call Trace: CPU0 attaching sched-domain: [] warn_on_slowpath+0x58/0x6b domain 0: span ,,,0003 groups: ,,,0001 ,,,000 2 [] ? printk+0x67/0x69 CPU1 attaching sched-domain: domain 0: span ,,,0003 groups: ,,,0002 ,,,000 1 [] ? post_set+0x20/0x3d [] clockevents_register_device+0x36/0xc4 [] setup_APIC_timer+0x61/0x68 [] setup_secondary_APIC_clock+0xe/0x10 [] start_secondary+0x3e1/0x3f5 ---[ end trace ca143223eefdc828 ]--- and this on resume from RAM: Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 1596.25 BogoMIPS (lpj=3192500) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping 02 [ cut here ] CPU0 attaching sched-domain: domain 0: span ,,,0003 groups: ,,,0001 ,,,000 2 CPU1 attaching sched-domain: domain 0: span ,,,0003 groups: ,,,0002 ,,,000 1 WARNING: at /home/rafael/src/mm/linux-2.6.24-rc8-mm1/kernel/time/clockevents.c:1 65 clockevents_register_device+0x36/0xc4() Modules linked in: ip6t_LOG nf_conntrack_ipv6 xt_pkttype ipt_LOG xt_limit af_pac ket snd_pcm_oss rfkill_input snd_mixer_oss snd_seq snd_seq_device ip6t_REJECT xt _tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6 table_mangle nf_conntrack_ipv4 nf_conntrack ip_tables ip6table_filter ip6_tables cpufreq_conservative cpufreq_ondemand cpufreq_userspace x_tables cpufreq_powers ave ipv6 powernow_k8 freq_table fuse dm_crypt loop dm_mod arc4 ecb crypto_blkcip her b43 rfkill mac80211 rfcomm snd_hda_intel l2cap cfg80211 snd_pcm snd_timer in put_polldev led_class yenta_socket snd_page_alloc sdhci ohci1394 fan ssb pcmcia snd_hwdep rsrc_nonstatic mmc_core tg3 snd usbhid pcmcia_core rtc_cmos battery th ermal tifm_7xx1 ieee1394 ide_cd_mod button cdrom processor ff_memless joydev hci _usb rtc_core bluetooth shpchp pci_hotplug k8temp hwmon i2c_piix4 i2c_core tifm_ core ac rtc_lib firmware_class psmouse serio_raw soundcore sg ehci_hcd ohci_hcd usbcore edd ext3 jbd atiixp ide_core Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1-rjw #7 Call Trace: [] warn_on_slowpath+0x58/0x6b [] ? printk+0x67/0x69 [] ? post_set+0x20/0x3d [] clockevents_register_device+0x36/0xc4 [] setup_APIC_timer+0x61/0x68 [] setup_secondary_APIC_clock+0xe/0x10 [] start_secondary+0x3e1/0x3f5 ---[ end trace ca143223eefdc828 ]--- CPU1 is up -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lguest build regression fix] Re: 2.6.24-rc8-git1: Reported regressions from 2.6.23
On Sunday 20 January 2008 10:49:45 Adrian Bunk wrote: > On Sun, Jan 20, 2008 at 10:24:47AM +1100, Rusty Russell wrote: > > On Sunday 20 January 2008 05:06:04 Ingo Molnar wrote: > > > # CONFIG_PARAVIRT_GUEST is not set > > > CONFIG_LGUEST_GUEST=y > > > > This looks like a "randconfig" bug, to be honest. > > According to GNU grep we have two CONFIG_LGUEST_GUEST variables (sic), > one in arch/x86/lguest/Kconfig and one in drivers/lguest/Kconfig. > > Rusty, don't blame randconfig for finding bugs in this mess you > created... My apologies, it is my mess. The one in drivers/lguest/Kconfig is the old (bogus) one: looks like I lost the removal part in a patch merge back in September. I've tested this patch. It correctly handles Ingo's config (removes lguest guest support). Both lguest and lguest guest support can be turned on independently, and it still compiles. How embarrassing, Rusty. --- Remove bogus duplicate CONFIG_LGUEST_GUEST entry. It was moved to arch/x86/lguest/Kconfig, but I lost the deletion part in a patch suffle. My confused one-liner "fix" to turn it on is also reverted: 84f7466ee20cc094aa38617abfa2f3834871f054 Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> diff -r 3db2cadc1a30 drivers/lguest/Kconfig --- a/drivers/lguest/KconfigSun Jan 20 11:25:15 2008 +1100 +++ b/drivers/lguest/KconfigSun Jan 20 11:47:57 2008 +1100 @@ -2,7 +2,6 @@ config LGUEST tristate "Linux hypervisor example code" depends on X86_32 && EXPERIMENTAL && !X86_PAE && FUTEX && !(X86_VISWS || X86_VOYAGER) select HVC_DRIVER - select LGUEST_GUEST ---help--- This is a very simple module which allows you to run multiple instances of the same Linux kernel, using the @@ -11,9 +10,3 @@ config LGUEST not "rustyvisor". See Documentation/lguest/lguest.txt. If unsure, say N. If curious, say M. If masochistic, say Y. - -config LGUEST_GUEST - bool - help - The guest needs code built-in, even if the host has lguest - support as a module. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] W1: w1_therm.c ds18b20 decode freezing temperatures correctly
commit c4ad974f3acef11e538e825ca0cb73be6faf2461
Author: David Fries <[EMAIL PROTECTED]>
Date: Sun Nov 4 18:14:21 2007 -0600
Corrected the decoding of negative C temperatures. The code did a binary
OR of two bytes to make a 16 bit value, but assignd it to an integer.
This caused the value to not be sign extended and to loose that it was a
negative number in the assignment.
Before the patch (in my freezer),
w1_slave
ed fe 4b 46 7f ff 03 10 e4 : crc=e4 YES
ed fe 4b 46 7f ff 03 10 e4 t=4078
With the patch,
e3 fe 4b 46 7f ff 0d 10 81 : crc=81 YES
e3 fe 4b 46 7f ff 0d 10 81 t=-17
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 4318935..feed89e 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -112,7 +112,7 @@ static struct w1_therm_family_converter w1_therm_families[]
= {
static inline int w1_DS18B20_convert_temp(u8 rom[9])
{
- int t = (rom[1] << 8) | rom[0];
+ s16 t = (rom[1] << 8) | rom[0];
t /= 16;
return t;
}
--
David Fries <[EMAIL PROTECTED]>
http://fries.net/~david/ (PGP encryption key available)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] W1: w1_therm.c is flagging 0C etc as invalid
commit d05074b1beb66d40283228bd226f7244407375bb Author: David Fries <[EMAIL PROTECTED]> Date: Sat Jan 19 18:06:49 2008 -0600 The extra rom[0] check is flagging valid temperatures as invalid when there is already a CRC data transmission check. w1_therm_read_bin() if (rom[8] == crc && rom[0]) verdict = 1; Requiring rom[0] to be non-zero will flag as invalid temperature conversions when the low byte is zero, specifically the temperatures 0C, 16C, 32C, 48C, -16C, -32C, and -48C. The CRC check is produced on the device for the previous 8 bytes and is required to ensure the data integrity in transmission. I don't see why the extra check for rom[0] being non-zero is in there. Evgeniy Polyakov didn't know either. Just for a check I unplugged the sensor, executed a temperature conversion, and read the results. The read was all ff's, which also failed the CRC, so it doesn't need to protect against a disconnected sensor. I have more extensive patches in the work, but these two trivial ones will do for today. I would like to hear from people who use the ds2490 USB to one wire dongle. 1 if you would be willing to test the patches as I currently only have the one sensor on a short parisite powered wire, 2 if there is any cheap sources for the ds2490. Signed-off-by: David Fries <[EMAIL PROTECTED]> diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c index feed89e..112f4ec 100644 --- a/drivers/w1/slaves/w1_therm.c +++ b/drivers/w1/slaves/w1_therm.c @@ -204,7 +204,7 @@ static ssize_t w1_therm_read_bin(struct kobject *kobj, crc = w1_calc_crc8(rom, 8); - if (rom[8] == crc && rom[0]) + if (rom[8] == crc) verdict = 1; } } -- David Fries <[EMAIL PROTECTED]> http://fries.net/~david/ (PGP encryption key available) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup
David Rientjes wrote:
> On Sat, 19 Jan 2008, Mike Travis wrote:
>
>>> Yeah, NID_INVAL is negative so no unsigned type will work here,
>>> unfortunately. And that reduces the intended savings of your change since
>>> the smaller type can only be used with a smaller CONFIG_NODES_SHIFT.
>>>
>> Excuse my ignorance but why wouldn't this work:
>>
>> static numanode_t pxm_to_node_map[MAX_PXM_DOMAINS]
>> = { [0 ... MAX_PXM_DOMAINS - 1] =
>> NUMA_NO_NODE };
>> ...
int acpi_map_pxm_to_node(int pxm)
{
>>> int node = pxm_to_node_map[pxm];
>>>
>>> if (node < 0)
>> numanode_t node = pxm_to_node_map[pxm];
>>
>
> Because NUMA_NO_NODE is 0xff on x86. That's a valid node id for
> configurations with CONFIG_NODES_SHIFT equal to or greater than 8.
Perhaps numanode_t should be set to u16 if MAX_NUMNODES > 255 to
allow for an invalid value of 255?
#if MAX_NUMNODES > 255
typedef u16 numanode_t;
#else
typedef u8 numanode_t;
#endif
>
>> if (node != NUMA_NO_NODE) {
>
> Wrong, this should be
>
> node == NUMA_NO_NODE
Oops, yes you're right.
if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
return NID_INVAL;
node = first_unset_node(nodes_found_map);
__acpi_map_pxm_to_node(pxm, node);
node_set(node, nodes_found_map);
}
>
> The net result of this is that if a proximity domain is looked up through
> acpi_map_pxm_to_node() and already has a mapping to node 255 (legal with
> CONFIG_NODES_SHIFT == 8), this function will return NID_INVAL since the
> weight of nodes_found_map is equal to MAX_NUMNODES.
>
> You simply can't use valid node id's to signify invalid or unused node
> ids.
>
>> or change:
>> #define NID_INVAL (-1)
>> to
>> #define NID_INVAL ((numanode_t)(-1))
>> ...
>> if (node != NID_INVAL) {
>
> You mean
>
> node == NID_INVAL
>
if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
return NID_INVAL;
node = first_unset_node(nodes_found_map);
__acpi_map_pxm_to_node(pxm, node);
node_set(node, nodes_found_map);
}
>
> That's the equivalent of your NUMA_NO_NODE code above. The fact remains
> that (numanode_t)-1 is still a valid node id for MAX_NUMNODES >= 256.
>
> So, as I said in my initial reply, the only way to get the savings you're
> looking for is to use u8 for CONFIG_NODES_SHIFT <= 7 and then convert all
> NID_INVAL users to use NUMA_NO_NODE.
Yes, I agree. I'll do the changes you're suggesting.
> Additionally, Linux has always discouraged typedefs when they do not
> define an architecture-specific size. The savings from your patch for
> CONFIG_NODES_SHIFT == 7 would be 256 bytes for this mapping.
>
> It's simply not worth it.
So are you saying that I should just use u16 for all node ids whether
CONFIG_NODES_SHIFT > 7 or not? Othersise, I would think that defining a
typedef is a fairly clean solution.
A quick grep shows that there are 35 arrays defined by MAX_NUMNODES in
x86_64, 38 in X86_32 (not verified.) So it's not exactly a trivial
amount of memory.
>
>> And btw, shouldn't the pxm value be sized to numanode_t size as well?
>> Will it ever be larger than the largest node id?
>>
>
> Section 6.2.9 of ACPI 2.0 states that PXM's return an integer, so that
> would be non-conforming to the standard.
>
> Additionally, PXM's are not nodes, so casting them to anything called
> numanode_t shows the semantic flaw in your patch.
Thanks for the info. I wasn't sure exactly what the PXM value represents.
>
> David
Thanks again,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg
Just merged into the cifs-2.6 tree, changing the last patch as you just suggested to take out the logged path name. On Jan 19, 2008 5:25 PM, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Sat, Jan 19, 2008 at 04:55:53PM -0600, Steve French wrote: > > On Jan 19, 2008 4:30 PM, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > On Sat, Jan 19, 2008 at 04:06:57PM -0600, Steve French wrote: > > > > The access denied message in the dmesg log reveals no more information > > > > than strace on stat of a local file does (which also returns access > > > > > > You can't strace a process you don't own. And you might not be able > > > to access the directory below which the file is. > > > > If you can't access the directory that the file is in then you get > > access denied on stat of the file (local over ext3 or remote over > > cifs) - it does not tell you anything about whether the file existed > > or not. If you do "stat > > /mnt/dir-with-0700-perm/file-which-does-not-exist" I get access > > denied. I don't think that it really tells you anything interesting > > since the same error comes back whether or not the file existed. > > The problem is that the file name ends up in the log for everybody to > read even if they're totally unrelated. So if someone in a protected directory > tree where they have access to does something that is denied the > file names will still leak to everybody else to the log. > > e.g. more concrete example. you do something and get that message. > > Now even 'nobody" running in a chroot will know that you tried > that and that at least parts of the file name likely exist. > > That is an information leak and imho a privacy problem. > > > Other unexpected errors (e.g. -EIO) should be logged because they > > indicate possibly severe problems with the network, but also don't > > tell you anything about whether the file exists. > > Sure errors should be logged, but not with path names. > > -Andi > -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allocate pnp resources dynamically via krealloc
Hi Thomas,
On Jan 19, 2008 10:00 PM, Thomas Renninger <[EMAIL PROTECTED]> wrote:
> +static int pnp_alloc_port(struct pnp_resource_table *res)
> +{
[snip]
> + res->port_resource = krealloc(res->port_resource,
> + (sizeof(struct resource) * res->allocated_ports)
> + + (sizeof(struct resource) * PNP_ALLOC_PORT), GFP_KERNEL);
> +
> + if (!res->port_resource)
> + return -ENOMEM;
When krealloc() returns NULL, there wasn't enough memory to fit the
new size but the original memory region remains unchanged. Therefore
you must not unconditionally overwrite the res->port_resource with the
return value of krealloc(); otherwise you might leak memory.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.
Andi Kleen wrote: That will break if the kernel is > 4GB won't it? Also same for pmd. The kernel can't be > 4 GB; after all, we're running here with paging disabled, so inherently we're < 4 GB... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lguest build regression fix] Re: 2.6.24-rc8-git1: Reported regressions from 2.6.23
On Sun, Jan 20, 2008 at 10:24:47AM +1100, Rusty Russell wrote: > On Sunday 20 January 2008 05:06:04 Ingo Molnar wrote: > > x86 randconfig testing found the following build failure: > > > > arch/x86/lguest/boot.c: In function 'lazy_hcall': > > arch/x86/lguest/boot.c:151: error: implicit declaration of function > > 'paravirt_get_lazy_mode' arch/x86/lguest/boot.c:151: error: > > 'PARAVIRT_LAZY_NONE' undeclared (first use in this function) > > > > which i bisected down to this very fresh commit: > > > > commit 84f7466ee20cc094aa38617abfa2f3834871f054 > > Author: Rusty Russell <[EMAIL PROTECTED]> > > Date: Sat Jan 19 07:02:29 2008 +1100 > > > > Selecting LGUEST should turn on Guest support, as in 2.6.23. > > > > which allows the following .config variation: > > > > # CONFIG_PARAVIRT_GUEST is not set > > CONFIG_LGUEST_GUEST=y > > This looks like a "randconfig" bug, to be honest. > > CONFIG_LGUEST_GUEST and CONFIG_LGUEST are within "if PARAVIRT_GUEST" (include > is in arch/x86/Kconfig). According to GNU grep we have two CONFIG_LGUEST_GUEST variables (sic), one in arch/x86/lguest/Kconfig and one in drivers/lguest/Kconfig. And CONFIG_LGUEST (which selects CONFIG_LGUEST_GUEST) is in drivers/lguest/Kconfig which gets included from drivers/kvm/Kconfig (sic) which in turn gets included from drivers/Kconfig which in turn is not within the "if PARAVIRT_GUEST". Rusty, don't blame randconfig for finding bugs in this mess you created... > Rusty. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux device ordering at boot time
> Well, it's a major pain in the a**. I've no idea, what reversed the order of > PCI devices, but I had to disable the automatic dvb driver loading in order It depends on the order you load the modules Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Makes lguest's irq handler typesafe
On Saturday 19 January 2008 15:08:28 Tejun Heo wrote: > Rusty Russell wrote: > > There are three possibilities: (1) force everyone to use void *, (2) > > force everyone to be type-correct, (3) allow both with some tricks. > > Currently we're on (1). For kthread, with only dozens of users, I chose > > (2) (very simple, easy to understand). I think for widespread things > > like timer and interrupt handlers, I think (3) is the right way to go. > > Yeah, during transition, we definitely want (3). Hi Tejun. I'm thinking an open-ended transition. I don't see a big reason to churn working code, since we can easily support both. > Yeah, I think we need a good flame war to determine our > heading and converting timer shouldn't take too much of your time, right? Insightful comment, you've convinced me! Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] x86: Add config variables for SMP_MAX
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> and then it crashes with:
>>
>> [0.00] Bootmem setup node 0 -3fff
>> [0.00] KERN_NOTICE cpu_to_node(0): usage too early!
>> PANIC: early exception 06 rip 10:81f77f30 error 0 cr2 f06f53
>> [0.00] Pid: 0, comm: swapper Not tainted 2.6.24-rc8 #422
>> [0.00]
>> [0.00] Call Trace:
>> [0.00] [] ? setup_node_bootmem+0x1a0/0x1b8
>> [0.00] [] ? acpi_scan_nodes+0x204/0x255
>> [0.00] [] ? acpi_scan_nodes+0x204/0x255
>> [0.00] [] ? numa_initmem_init+0x343/0x471
>>
>> moral: PLEASE do not use BUG() on in early init code, unless
>> absolutely necessary.
>
> the right fix is below.
>
> Ingo
>
> ---
> include/asm-x86/topology.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux/include/asm-x86/topology.h
> ===
> --- linux.orig/include/asm-x86/topology.h
> +++ linux/include/asm-x86/topology.h
> @@ -70,10 +70,10 @@ static inline int cpu_to_node(int cpu)
> if(x86_cpu_to_node_map_early_ptr) {
> printk("KERN_NOTICE cpu_to_node(%d): usage too early!\n",
> (int)cpu);
> - BUG();
> + dump_stack();
> }
> #endif
> - if(per_cpu_offset(cpu))
> + if (per_cpu_offset(cpu))
> return per_cpu(x86_cpu_to_node_map, cpu);
> else
> return NUMA_NO_NODE;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Except the function needs to return a valid node id if it's to continue:
--- linux.orig/include/asm-x86/topology.h 2008-01-19 15:23:04.996551867
-0800
+++ linux/include/asm-x86/topology.h2008-01-19 15:23:05.208564537 -0800
@@ -67,10 +67,11 @@ static inline int early_cpu_to_node(int
static inline int cpu_to_node(int cpu)
{
#ifdef CONFIG_DEBUG_PER_CPU_MAPS
- if(x86_cpu_to_node_map_early_ptr) {
+ if (x86_cpu_to_node_map_early_ptr) {
printk("KERN_NOTICE cpu_to_node(%d): usage too early!\n",
(int)cpu);
dump_stack();
+ return ((numanode_t *)x86_cpu_to_node_map_early_ptr)[cpu];
}
#endif
if (per_cpu_offset(cpu))
??
Thannks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lguest build regression fix] Re: 2.6.24-rc8-git1: Reported regressions from 2.6.23
On Sunday 20 January 2008 05:06:04 Ingo Molnar wrote: > x86 randconfig testing found the following build failure: > > arch/x86/lguest/boot.c: In function 'lazy_hcall': > arch/x86/lguest/boot.c:151: error: implicit declaration of function > 'paravirt_get_lazy_mode' arch/x86/lguest/boot.c:151: error: > 'PARAVIRT_LAZY_NONE' undeclared (first use in this function) > > which i bisected down to this very fresh commit: > > commit 84f7466ee20cc094aa38617abfa2f3834871f054 > Author: Rusty Russell <[EMAIL PROTECTED]> > Date: Sat Jan 19 07:02:29 2008 +1100 > > Selecting LGUEST should turn on Guest support, as in 2.6.23. > > which allows the following .config variation: > > # CONFIG_PARAVIRT_GUEST is not set > CONFIG_LGUEST_GUEST=y This looks like a "randconfig" bug, to be honest. CONFIG_LGUEST_GUEST and CONFIG_LGUEST are within "if PARAVIRT_GUEST" (include is in arch/x86/Kconfig). Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.
Ian Campbell <[EMAIL PROTECTED]> writes:
> +1:
> +#ifdef CONFIG_X86_PAE
> + btl $5, %eax
> + jnc err_no_pae
> +#endif
>
> xorl %ebx,%ebx /* This is the boot CPU (BSP) */
> jmp 3f
> +
> +#ifdef CONFIG_X86_PAE
> +err_no_pae:
> + /* It is probably too early but we might as well try... */
Without a low identity mapping early_printk will not work and printk
definitely not.
> +#ifdef CONFIG_PRINTK
You should do the test in the 16 bit boot code. In fact it should
already do it by testing the CPUID REQUIRED_MASK.
The only way this could be entered is if someone skips the 16bit boot code
by using kexec, but has the wrong flags. I'm not sure how to handle
it there.
> +/*
> + * Since a paravirt guest will never come down this path we want
> + * native style page table accessors here.
> + */
> +#undef CONFIG_PARAVIRT
Seems quite fragile. I'm sure that would hurt later.
> +
> +static inline __init pud_t *early_pud_offset(pgd_t *pgd, unsigned long vaddr)
> +{
> + return (pud_t *)(pgd + pgd_index(vaddr));
> +}
> +
> +static inline __init pmd_t *early_pmd_offset(pud_t *pud, unsigned long vaddr)
> +{
> +#ifndef CONFIG_X86_PAE
> + return (pmd_t *)pud;
> +#else
> + return ((pmd_t *)(u32)(pud_val(*pud) & PAGE_MASK))
> + + pmd_index(vaddr);
> +#endif
> +}
> +
> +static inline __init pte_t *early_pte_offset(pmd_t *pmd, unsigned long vaddr)
> +{
> + return ((pte_t *)(u32)(pmd_val(*pmd) & PAGE_MASK))
That will break if the kernel is > 4GB won't it? Also same for pmd.
Also not handling NX is dubious, although you can probably get away from it
there.
> + + pte_index(vaddr);
> +}
> +
> +static inline __init pmd_t *
> +early_pmd_alloc(pgd_t *pgd_base, unsigned long vaddr, unsigned long *end)
> +{
> + pud_t *pud = early_pud_offset(pgd_base, vaddr);
> +
> +#ifdef CONFIG_X86_PAE
> + if (!(pud_val(*pud) & _PAGE_PRESENT)) {
Why not set it in the pgd which is identical? Also the proper test is
!pgd_none()
> +{
> + pmd_t *pmd;
> +
> + pmd = early_pmd_alloc(pgd_base, vaddr, end);
> + if (!(pmd_val(*pmd) & _PAGE_PRESENT)) {
!pmd_none()
> + unsigned long phys = *end;
> + memset((void *)phys, 0, PAGE_SIZE);
> + set_pmd(pmd, __pmd(phys | _PAGE_TABLE));
> + *end += PAGE_SIZE;
> + }
> + return early_pte_offset(pmd, vaddr);
> +}
> +
> +static __init void early_set_pte_phys(pgd_t *pgd_base, unsigned long vaddr,
> + unsigned long phys, unsigned long *end)
> +{
> + pte_t *pte;
> + pte = early_pte_alloc(pgd_base, vaddr, end);
> + set_pte(pte, __pte(phys | _PAGE_KERNEL_EXEC));
> +}
> +
> +void __init early_pgtable_init(void)
> +{
> + unsigned long addr, end;
> + pgd_t *pgd_base;
> +
> + pgd_base = __pavar(swapper_pg_dir);
> + end = __pa_symbol(pg0);
Are you sure there will be enough memory here? You might need to use
an e820 allocator similar to x86-64.
Typical problems is you running into some other memory used by
someone else.
> {
> enum fixed_addresses idx;
> - unsigned long *pte, phys, addr;
> + unsigned long addr, phys;
> + pte_t *pte;
>
> after_paging_init = 1;
> for (idx = FIX_BTMAP_BEGIN; idx <= FIX_BTMAP_END; idx--) {
> addr = fix_to_virt(idx);
> pte = early_ioremap_pte(addr);
> - if (!*pte & _PAGE_PRESENT) {
> - phys = *pte & PAGE_MASK;
> + if (!(pte_val(*pte) & _PAGE_PRESENT)) {
pte_present(). Ok the old code was wrong too, but no need to do that again.
> set_fixmap(idx, phys);
> }
> }
> @@ -298,7 +304,8 @@ void __init early_ioremap_reset(void)
> static void __init __early_set_fixmap(enum fixed_addresses idx,
> unsigned long phys, pgprot_t flags)
> {
> - unsigned long *pte, addr = __fix_to_virt(idx);
> + unsigned long addr = __fix_to_virt(idx);
> + pte_t *pte;
Unrelated?
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg
On Sat, Jan 19, 2008 at 04:55:53PM -0600, Steve French wrote: > On Jan 19, 2008 4:30 PM, Andi Kleen <[EMAIL PROTECTED]> wrote: > > On Sat, Jan 19, 2008 at 04:06:57PM -0600, Steve French wrote: > > > The access denied message in the dmesg log reveals no more information > > > than strace on stat of a local file does (which also returns access > > > > You can't strace a process you don't own. And you might not be able > > to access the directory below which the file is. > > If you can't access the directory that the file is in then you get > access denied on stat of the file (local over ext3 or remote over > cifs) - it does not tell you anything about whether the file existed > or not. If you do "stat > /mnt/dir-with-0700-perm/file-which-does-not-exist" I get access > denied. I don't think that it really tells you anything interesting > since the same error comes back whether or not the file existed. The problem is that the file name ends up in the log for everybody to read even if they're totally unrelated. So if someone in a protected directory tree where they have access to does something that is denied the file names will still leak to everybody else to the log. e.g. more concrete example. you do something and get that message. Now even 'nobody" running in a chroot will know that you tried that and that at least parts of the file name likely exist. That is an information leak and imho a privacy problem. > Other unexpected errors (e.g. -EIO) should be logged because they > indicate possibly severe problems with the network, but also don't > tell you anything about whether the file exists. Sure errors should be logged, but not with path names. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux device ordering at boot time
Am Samstag, 19. Januar 2008 schrieben Sie: > I have a question concerning the ordering of devices during the boot > process and I hope that the kernel mailing list is the right place for > this question. In my computer are two raid controllers with one raid > array connected to each of them (/dev/sda, /dev/sdb). In the debian > 2.6.18 boot process the ordering is root @ /dev/sda and data are on > /dev/sdb. This behaviour has changed in the plain 2.6.23.1 (and 2.6.23.8) > kernel. The /dev/sd(a|b) devices have switched so that root @ /dev/sdb. > So my standard fstab does not work. What determines the device ordering > during the boot process? What is a workaround for this problem? Well, it's a major pain in the a**. I've no idea, what reversed the order of PCI devices, but I had to disable the automatic dvb driver loading in order to get the picture back (dedicated vdr system with one FF and one budget card). I could have taken the route of exchanging the cards, but that would have been even more painful.. Oh well, Pete -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] (2.6.24-rc8-mm1) -mm v2 Smack socket label setting fix
From: Casey Schaufler <[EMAIL PROTECTED]>
Correct the checks in smack_inode_setxattr to include the
socket labeling attributes. Simplify and correct
smack_sock_graft, while the values it was setting were
safe they were not correct and the job was not being
done efficiently. smack_inode_setsecurity wasn't
invoking the required netlabel function in the case
where smk_ipout was set. It does now, but that change
required the hook to be moved in the file. This
movement accounts for the bulk of the patch.
Signed-off-by: Casey Schaufler <[EMAIL PROTECTED]>
---
This version corrects an indentation error in the previous patch.
security/smack/smack.h |2
security/smack/smack_lsm.c | 136 ---
2 files changed, 67 insertions(+), 71 deletions(-)
diff -uprN -X linux-2.6.24-rc8-mm1-base/Documentation/dontdiff
linux-2.6.24-rc8-mm1-base/security/smack/smack.h
linux-2.6.24-rc8-mm1-smack/security/smack/smack.h
--- linux-2.6.24-rc8-mm1-base/security/smack/smack.h2008-01-18
14:12:26.0 -0800
+++ linux-2.6.24-rc8-mm1-smack/security/smack/smack.h 2008-01-18
15:09:43.0 -0800
@@ -130,6 +130,8 @@ struct smack_known {
#define XATTR_SMACK_IPIN "SMACK64IPIN"
#define XATTR_SMACK_IPOUT "SMACK64IPOUT"
#define XATTR_NAME_SMACK XATTR_SECURITY_PREFIX XATTR_SMACK_SUFFIX
+#define XATTR_NAME_SMACKIPIN XATTR_SECURITY_PREFIX XATTR_SMACK_IPIN
+#define XATTR_NAME_SMACKIPOUT XATTR_SECURITY_PREFIX XATTR_SMACK_IPOUT
/*
* smackfs macic number
diff -uprN -X linux-2.6.24-rc8-mm1-base/Documentation/dontdiff
linux-2.6.24-rc8-mm1-base/security/smack/smack_lsm.c
linux-2.6.24-rc8-mm1-smack/security/smack/smack_lsm.c
--- linux-2.6.24-rc8-mm1-base/security/smack/smack_lsm.c2008-01-18
14:12:26.0 -0800
+++ linux-2.6.24-rc8-mm1-smack/security/smack/smack_lsm.c 2008-01-18
20:22:19.0 -0800
@@ -584,8 +584,12 @@ static int smack_inode_getattr(struct vf
static int smack_inode_setxattr(struct dentry *dentry, char *name,
void *value, size_t size, int flags)
{
- if (strcmp(name, XATTR_NAME_SMACK) == 0 && !capable(CAP_MAC_ADMIN))
- return -EPERM;
+ if (!capable(CAP_MAC_ADMIN)) {
+ if (strcmp(name, XATTR_NAME_SMACK) == 0 ||
+ strcmp(name, XATTR_NAME_SMACKIPIN) == 0 ||
+ strcmp(name, XATTR_NAME_SMACKIPOUT) == 0)
+ return -EPERM;
+ }
return smk_curacc(smk_of_inode(dentry->d_inode), MAY_WRITE);
}
@@ -718,57 +722,6 @@ static int smack_inode_getsecurity(const
return rc;
}
-/**
- * smack_inode_setsecurity - set smack xattrs
- * @inode: the object
- * @name: attribute name
- * @value: attribute value
- * @size: size of the attribute
- * @flags: unused
- *
- * Sets the named attribute in the appropriate blob
- *
- * Returns 0 on success, or an error code
- */
-static int smack_inode_setsecurity(struct inode *inode, const char *name,
- const void *value, size_t size, int flags)
-{
- char *sp;
- struct inode_smack *nsp = inode->i_security;
- struct socket_smack *ssp;
- struct socket *sock;
-
- if (value == NULL || size > SMK_LABELLEN)
- return -EACCES;
-
- sp = smk_import(value, size);
- if (sp == NULL)
- return -EINVAL;
-
- if (strcmp(name, XATTR_SMACK_SUFFIX) == 0) {
- nsp->smk_inode = sp;
- return 0;
- }
- /*
-* The rest of the Smack xattrs are only on sockets.
-*/
- if (inode->i_sb->s_magic != SOCKFS_MAGIC)
- return -EOPNOTSUPP;
-
- sock = SOCKET_I(inode);
- if (sock == NULL)
- return -EOPNOTSUPP;
-
- ssp = sock->sk->sk_security;
-
- if (strcmp(name, XATTR_SMACK_IPIN) == 0)
- ssp->smk_in = sp;
- else if (strcmp(name, XATTR_SMACK_IPOUT) == 0)
- ssp->smk_out = sp;
- else
- return -EOPNOTSUPP;
- return 0;
-}
/**
* smack_inode_listsecurity - list the Smack attributes
@@ -1341,6 +1294,60 @@ static int smack_netlabel(struct sock *s
}
/**
+ * smack_inode_setsecurity - set smack xattrs
+ * @inode: the object
+ * @name: attribute name
+ * @value: attribute value
+ * @size: size of the attribute
+ * @flags: unused
+ *
+ * Sets the named attribute in the appropriate blob
+ *
+ * Returns 0 on success, or an error code
+ */
+static int smack_inode_setsecurity(struct inode *inode, const char *name,
+ const void *value, size_t size, int flags)
+{
+ char *sp;
+ struct inode_smack *nsp = inode->i_security;
+ struct socket_smack *ssp;
+ struct socket *sock;
+
+ if (value == NULL || size > SMK_LABELLEN)
+ return -EACCES;
+
+ sp = smk_import(value, size);
+ if (sp == NULL)
+ return -EINVAL;
+
+ if (strcmp(name,
Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg
On Jan 19, 2008 4:30 PM, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Sat, Jan 19, 2008 at 04:06:57PM -0600, Steve French wrote: > > The access denied message in the dmesg log reveals no more information > > than strace on stat of a local file does (which also returns access > > You can't strace a process you don't own. And you might not be able > to access the directory below which the file is. If you can't access the directory that the file is in then you get access denied on stat of the file (local over ext3 or remote over cifs) - it does not tell you anything about whether the file existed or not. If you do "stat /mnt/dir-with-0700-perm/file-which-does-not-exist" I get access denied. I don't think that it really tells you anything interesting since the same error comes back whether or not the file existed. Other unexpected errors (e.g. -EIO) should be logged because they indicate possibly severe problems with the network, but also don't tell you anything about whether the file exists. > Logging the path would be only safe if you determine that the > file and all its parent directories were world read (and accessable)able, > but that would be probably difficult. If the parent of the parent were not readable/accessable then you would not have gotten this far (the stat of the parent directory rather than the file would have returned the error). If the parent were readable then the access denied on stat is the same over cifs and ext3 - and the logging of the error only occurs in cases like EIO in which e.g. the network has crashed (but you can't tell from the error whether the file exists or not). I don't mind taking out the path name from the logging of EIO in this case but it could make debugging harder if we ever hit a strange bug. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Update emacs indentation instructions.
For quite some time now, Emacs has supported multiple coding styles,
including one very close to the Linux style. Update the Emacs
configuration instructions in the documentation to reflect this.
Signed-off-by: David Brown <[EMAIL PROTECTED]>
---
Documentation/CodingStyle | 39 ++-
1 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index b49b92e..4511b99 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -456,27 +456,24 @@ uses are less than desirable (in fact, they are worse
than random
typing - an infinite number of monkeys typing into GNU emacs would never
make a good program).
-So, you can either get rid of GNU emacs, or change it to use saner
-values. To do the latter, you can stick the following in your .emacs file:
-
-(defun linux-c-mode ()
- "C mode with adjusted defaults for use with the Linux kernel."
- (interactive)
- (c-mode)
- (c-set-style "K")
- (setq tab-width 8)
- (setq indent-tabs-mode t)
- (setq c-basic-offset 8))
-
-This will define the M-x linux-c-mode command. When hacking on a
-module, if you put the string -*- linux-c -*- somewhere on the first
-two lines, this mode will be automatically invoked. Also, you may want
-to add
-
-(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
- auto-mode-alist))
-
-to your .emacs file if you want to have linux-c-mode switched on
+Fortunately, modern versions of GNU emacs support different indentation
+styles. If you want to use the Linux kernel style for all C code, place
+the following in your .emacs file:
+
+(setq c-default-style "linux")
+
+If you only want to use Linux indenting on Linux source files, you can
+insert something like the following:
+
+(defun my-c-mode-hook ()
+ (c-set-style
+ (if (and (buffer-file-name)
+(string-match "/usr/src/linux" (buffer-file-name)))
+ "linux"
+ "free-group-style")))
+(add-hook 'c-mode-hook 'my-c-mode-hook)
+
+to your .emacs file if you want to have linux style switched on
automagically when you edit source files under /usr/src/linux.
But even if you fail in getting emacs to do sane formatting, not
--
1.5.3.8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [updated PATCH] xen: fix section usage in xen-head.S and setup.c
On Sat, Jan 19, 2008 at 02:23:51PM -0800, Jeremy Fitzhardinge wrote: > Sam Ravnborg wrote: > >Failing to specify "ax" in the pushsection caused ld to generate > >an additional section for .init.text appending a number. > > > > Thanks for tracking this down. I think the "ax" appeared and > disappeared over time, but this looks like the proper solution. > > Are you going to submit this, or do you want me to pick it up? Please pick it up as this is xen specific. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why not creating a GIT RT tree ?
> "Francis" == Francis Moreau <[EMAIL PROTECTED]> writes: >> It is in the one-head per patch style, and has the single-file >> patches applied rather than the quilt queue. Francis> Why don't you have one commit per patch ? I started it before they had the broken out patches and haven't spent the time to put together a process for the broken out patches akin to what I figured out for the all-in-one patches. In other words, intertia. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup
On Sat, 19 Jan 2008, Mike Travis wrote:
> > Yeah, NID_INVAL is negative so no unsigned type will work here,
> > unfortunately. And that reduces the intended savings of your change since
> > the smaller type can only be used with a smaller CONFIG_NODES_SHIFT.
> >
>
> Excuse my ignorance but why wouldn't this work:
>
> static numanode_t pxm_to_node_map[MAX_PXM_DOMAINS]
> = { [0 ... MAX_PXM_DOMAINS - 1] =
> NUMA_NO_NODE };
> ...
> >> int acpi_map_pxm_to_node(int pxm)
> >> {
> > int node = pxm_to_node_map[pxm];
> >
> > if (node < 0)
>
> numanode_t node = pxm_to_node_map[pxm];
>
Because NUMA_NO_NODE is 0xff on x86. That's a valid node id for
configurations with CONFIG_NODES_SHIFT equal to or greater than 8.
> if (node != NUMA_NO_NODE) {
Wrong, this should be
node == NUMA_NO_NODE
> >> if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
> >> return NID_INVAL;
> >> node = first_unset_node(nodes_found_map);
> >> __acpi_map_pxm_to_node(pxm, node);
> >> node_set(node, nodes_found_map);
> >> }
>
The net result of this is that if a proximity domain is looked up through
acpi_map_pxm_to_node() and already has a mapping to node 255 (legal with
CONFIG_NODES_SHIFT == 8), this function will return NID_INVAL since the
weight of nodes_found_map is equal to MAX_NUMNODES.
You simply can't use valid node id's to signify invalid or unused node
ids.
> or change:
> #define NID_INVAL (-1)
> to
> #define NID_INVAL ((numanode_t)(-1))
> ...
> if (node != NID_INVAL) {
You mean
node == NID_INVAL
> >> if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
> >> return NID_INVAL;
> >> node = first_unset_node(nodes_found_map);
> >> __acpi_map_pxm_to_node(pxm, node);
> >> node_set(node, nodes_found_map);
> >> }
>
That's the equivalent of your NUMA_NO_NODE code above. The fact remains
that (numanode_t)-1 is still a valid node id for MAX_NUMNODES >= 256.
So, as I said in my initial reply, the only way to get the savings you're
looking for is to use u8 for CONFIG_NODES_SHIFT <= 7 and then convert all
NID_INVAL users to use NUMA_NO_NODE.
Additionally, Linux has always discouraged typedefs when they do not
define an architecture-specific size. The savings from your patch for
CONFIG_NODES_SHIFT == 7 would be 256 bytes for this mapping.
It's simply not worth it.
> And btw, shouldn't the pxm value be sized to numanode_t size as well?
> Will it ever be larger than the largest node id?
>
Section 6.2.9 of ACPI 2.0 states that PXM's return an integer, so that
would be non-conforming to the standard.
Additionally, PXM's are not nodes, so casting them to anything called
numanode_t shows the semantic flaw in your patch.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [4/7] Convert TSC disabling to generic cpuid disable bitmap
On Sat, 2008-01-19 at 19:57 +0100, Andi Kleen wrote: > On Saturday 19 January 2008 19:15:48 Ian Campbell wrote: > > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > > index 6f5c74a..b3721fd 100644 > > --- a/arch/x86/xen/time.c > > +++ b/arch/x86/xen/time.c > > @@ -592,7 +592,7 @@ __init void xen_time_init(void) > > set_normalized_timespec(_to_monotonic, > > -xtime.tv_sec, -xtime.tv_nsec); > > > > - setup_clear_cpu_cap(X86_FEATURE_TSC); > > + setup_force_cpu_cap(X86_FEATURE_TSC); > > Actually that would be only needed if someone else disabled TSC explicitely > before. > > Simply deleting this should be sufficient. Does this patch work for you? Yes. > It would break if someone passes notsc to a Xen kernel, but then a lot of > options make the kernel > break if you don't know what you're doing so that doesn't seem like a big > issue. I'm happy either way. I think the Xen paravirt subsystem will use TSC where it has to due to the Xen architecture regardless of this setting. Ian. -- Ian Campbell Good day for overcoming obstacles. Try a steeplechase. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg
On Sat, Jan 19, 2008 at 04:06:57PM -0600, Steve French wrote: > The access denied message in the dmesg log reveals no more information > than strace on stat of a local file does (which also returns access You can't strace a process you don't own. And you might not be able to access the directory below which the file is. But there is no such access control on "dmesg". So if there is an access error you leak the potentially protected information in the file name > denied and displays access denied), but I agree that logging on > -EACCESS on lookup does clutter the log. > > I think it is ok to log a message on unexpected errors (for > QueryPathInfo those would include anything other than ENOENT and > EACCESS - Simo, can you think of others?) I don't mind ratelimiting > logging on this clause (for errors other than ENOENT and EACCESS) but > it would complicate the code for a case I have not seen in the wild. > > I prefer the following to remove the log cluttering on this case: That would still be an information leak for other errors. Logging the path would be only safe if you determine that the file and all its parent directories were world read (and accessable)able, but that would be probably difficult. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [updated PATCH] xen: fix section usage in xen-head.S and setup.c
Sam Ravnborg wrote: Failing to specify "ax" in the pushsection caused ld to generate an additional section for .init.text appending a number. Thanks for tracking this down. I think the "ax" appeared and disappeared over time, but this looks like the proper solution. Are you going to submit this, or do you want me to pick it up? A side effect of this was a section mismatch warning because modpost did not recognize a .init.text section named .init.text.1: WARNING: vmlinux.o(.text.head+0x247): Section mismatch: reference to .init.text.1:start_kernel (between 'is386' and 'check_x87') Fix this by hardcoding the "ax" in the pushsection. Thanks to Torlaf for reporting this. Alan Modra provided the hint that made me able to locate the root cause of this warning. And Mike Frysinger told me how to properly fix it using __INIT/__FINIT. Fix following Section mismatch warning in addition: WARNING: vmlinux.o(.text+0x14c8): Section mismatch: reference to .init.data:vsyscall_int80_start (between 'fiddle_vdso' and 'xen_setup_features') fiddle_vdso was only used from a __init function - so declare it __init. Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Thanks, J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Core driver for WM97xx touchscreens
Hi, 2008/1/20, Mark Brown <[EMAIL PROTECTED]>: > On Sat, Jan 19, 2008 at 10:48:32PM +0300, Dmitry wrote: > > > Well... It's a common suggestion not to duplicate code. The wm97xx bus > > looks mostly like platform. The only difference is the name. To help > > visualisation, devices can have parents. Just set (in pseudocode) > > wm97xx-touchscreen->parent to wm97xx, do the same for wm97xx-battery > > and so on. Thus all devices would be on the platform device but with > > proper parent <-> child notation. > > That's exactly what I had understood you to mean. I guess it's just > that using the platform bus for this purpose feels like an abstraction > violation to me due to having platform devices parented off a device on > another bus. Obviously it's just my model of a platform device that's > wrong here. I will change the driver to use the platform bus for my > next submission. Hmm. I forgot about rooting this onto ac97 bus. But I would still suggest using platform bus just for the sake of code clarity and simplicity. > > > git://git.mnementh.co.uk/linux-2.6-im.git#tmio_dev_try3. Look for > > Thanks, I'll take a look. > > > 2008/1/19, Mark Brown <[EMAIL PROTECTED]>: > > > > current patch series these chips all also provide an audio codec which > > > requires a reasonably substantial driver for full support. > > > This would only touch child devices organisation. > > Indeed - I mention it mostly for additional motivation. > -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: " Change size of node ids from u8 to u16 fixup" causes early panic in __build_all_zonelists
Ingo Molnar wrote: > * Andi Kleen <[EMAIL PROTECTED]> wrote: > >> One of my test systems didn't boot with latest git-x86. I bisected it >> down to f1321f875910172bcc3e1f302fe145a9e4d3bdf7 >> >> With later patches the fault seemed to happen even earlier before >> other initialization messages. >> >> Config is available at http://halobates.de/config > > i've reverted that patch for now, but we need to figure this crash out - > the patch looks a trivial extension so it's probably some bad assumption > elsewhere, which we want to fix. > > Ingo I'm testing the new version of the patch using: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git mm The straight mm version doesn't like your .config file. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: konqueror deadlocks on 2.6.22
add cc (ingo) and then please update to CFS-v24.1 http://people.redhat.com/~mingo/cfs-scheduler/sched-cfs-v2.6.22.15-v24.1.patch On 1/19/08, Al Boldi <[EMAIL PROTECTED]> wrote: > Oliver Pinter (Pintér Olivér) wrote: > > This kernel is vanilla 2.6.22.y or with CFS? > > Yes with CFSv20.4, as in the log. > > It also hangs on 2.6.23.13 > > > On 1/19/08, Al Boldi <[EMAIL PROTECTED]> wrote: > > > I was just attacked by some deadlock issue involving sqlite3 and > > > konqueror. While sqlite3 continues to slowly fill a 7M-record db in > > > transaction mode, konqueror hangs for a few minutes, then continues only > > > to hang again and again. > > > > > > Looks like an fs/blockIO issue involving fsync. > > > > > > As a workaround, is there a way to make fsync soft? > > > Thanks! > > -- > Al > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Thanks, Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS client
The access denied message in the dmesg log reveals no more information
than strace on stat of a local file does (which also returns access
denied and displays access denied), but I agree that logging on
-EACCESS on lookup does clutter the log.
I think it is ok to log a message on unexpected errors (for
QueryPathInfo those would include anything other than ENOENT and
EACCESS - Simo, can you think of others?) I don't mind ratelimiting
logging on this clause (for errors other than ENOENT and EACCESS) but
it would complicate the code for a case I have not seen in the wild.
I prefer the following to remove the log cluttering on this case:
diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index 37dc97a..b2802e5 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -517,12 +517,11 @@ cifs_lookup(struct inode *parent_dir_inode,
struct dentry *direntry,
d_add(direntry, NULL);
/* if it was once a directory (but how can we tell?) we could do
shrink_dcache_parent(direntry); */
- } else {
+ } else if (rc != -EACCES) {
cERROR(1, ("Error 0x%x on cifs_get_inode_info in lookup of %s",
rc, full_path));
- /* BB special case check for Access Denied - watch security
- exposure of returning dir info implicitly via different rc
- if file exists or not but no access BB */
+ /* We special case check for Access Denied - since that
+ is a common return code */
}
kfree(full_path);
On Jan 19, 2008 2:18 AM, simo <[EMAIL PROTECTED]> wrote:
>
>
> On Sat, 2008-01-19 at 05:55 +0100, Andi Kleen wrote:
> > Fix information leak in CIFS client lookup
> >
> > Putting arbitary file names on lookup failures into the system log is not
> > a good idea, because usually everybody can read dmesg and that is thus
> > an information leak if a directory was read protected.
> >
> > Also changed the error printout for this case to a signed number, because
> > it is normally negative and that makes it easier to read.
> >
> > I'm not sure the message is all that useful anyways. Perhaps it
> > should be just removed completely? Or at least rate limited because
> > it allows to spam the kernel log nicely.
> >
> > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
> >
> > Index: linux/fs/cifs/dir.c
> > ===
> > --- linux.orig/fs/cifs/dir.c
> > +++ linux/fs/cifs/dir.c
> > @@ -518,7 +518,7 @@ cifs_lookup(struct inode *parent_dir_ino
> > /* if it was once a directory (but how can we tell?) we could do
> > shrink_dcache_parent(direntry); */
> > } else {
> > - cERROR(1, ("Error 0x%x on cifs_get_inode_info in lookup of
> > %s",
> > + cERROR(1, ("Error %d on cifs_get_inode_info in lookup of
> > file",
> > rc, full_path));
>
> then please remove also full_path here
>
> Simo.
>
> --
> Simo Sorce
> Samba Team GPL Compliance Officer <[EMAIL PROTECTED]>
> Senior Software Engineer at Red Hat Inc. <[EMAIL PROTECTED]>
>
>
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Core driver for WM97xx touchscreens
On Sat, Jan 19, 2008 at 10:48:32PM +0300, Dmitry wrote: > Well... It's a common suggestion not to duplicate code. The wm97xx bus > looks mostly like platform. The only difference is the name. To help > visualisation, devices can have parents. Just set (in pseudocode) > wm97xx-touchscreen->parent to wm97xx, do the same for wm97xx-battery > and so on. Thus all devices would be on the platform device but with > proper parent <-> child notation. That's exactly what I had understood you to mean. I guess it's just that using the platform bus for this purpose feels like an abstraction violation to me due to having platform devices parented off a device on another bus. Obviously it's just my model of a platform device that's wrong here. I will change the driver to use the platform bus for my next submission. > git://git.mnementh.co.uk/linux-2.6-im.git#tmio_dev_try3. Look for Thanks, I'll take a look. > 2008/1/19, Mark Brown <[EMAIL PROTECTED]>: > > current patch series these chips all also provide an audio codec which > > requires a reasonably substantial driver for full support. > This would only touch child devices organisation. Indeed - I mention it mostly for additional motivation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] x86: Add config variables for SMP_MAX
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> and then it crashes with:
>>
>> [0.00] Bootmem setup node 0 -3fff
>> [0.00] KERN_NOTICE cpu_to_node(0): usage too early!
>> PANIC: early exception 06 rip 10:81f77f30 error 0 cr2 f06f53
>> [0.00] Pid: 0, comm: swapper Not tainted 2.6.24-rc8 #422
>> [0.00]
>> [0.00] Call Trace:
>> [0.00] [] ? setup_node_bootmem+0x1a0/0x1b8
>> [0.00] [] ? acpi_scan_nodes+0x204/0x255
>> [0.00] [] ? acpi_scan_nodes+0x204/0x255
>> [0.00] [] ? numa_initmem_init+0x343/0x471
>>
>> moral: PLEASE do not use BUG() on in early init code, unless
>> absolutely necessary.
>
> the right fix is below.
>
> Ingo
>
> ---
> include/asm-x86/topology.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux/include/asm-x86/topology.h
> ===
> --- linux.orig/include/asm-x86/topology.h
> +++ linux/include/asm-x86/topology.h
> @@ -70,10 +70,10 @@ static inline int cpu_to_node(int cpu)
> if(x86_cpu_to_node_map_early_ptr) {
> printk("KERN_NOTICE cpu_to_node(%d): usage too early!\n",
> (int)cpu);
> - BUG();
> + dump_stack();
> }
> #endif
> - if(per_cpu_offset(cpu))
> + if (per_cpu_offset(cpu))
> return per_cpu(x86_cpu_to_node_map, cpu);
> else
> return NUMA_NO_NODE;
Thanks. I had pulled this from the patch as ak suggested. But it seems
that it's finding real errors that need to be fixed.
Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Help needed to fix section mismatch warnings
> > > > > > > WARNING: vmlinux.o(.text+0x43524): Section mismatch: reference to > > > .init.text: (between 'timer_cpu_notify' and 'msleep') > > > WARNING: vmlinux.o(.text+0x4c6f6): Section mismatch: reference to > > > .init.text: (between 'rcu_cpu_notify' and 'wakeme_after_rcu') > > > WARNING: vmlinux.o(.text+0x51cbe): Section mismatch: reference to > > > .init.text: (between 'hrtimer_cpu_notify' and 'down_read_trylock') > > > > I'll post patches for the 3 above. However, the rcu code in -mm > > is quite different, so the rcu patch may have a short life. > > Hi Randy. > > Thanks for your efforts! And I just reviewd the three patches. All oops triggers under special conditions. It is stuff like this that makes me wonder why some people still say that the Section mismatch warnings are not worth fixing?!?!? Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] timer: fix section mismatch
On Sat, Jan 19, 2008 at 11:57:15AM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> The caller is __cpuinit.
> Also, this code block and its caller are inside #ifdef CONFIG_HOTPLUG_CPU
> blocks, so this code should reflect that config symbol's usage.
>
> WARNING: vmlinux.o(.text+0x4252f): Section mismatch: reference to .init.text:
> (between 'timer_cpu_notify' and 'msleep')
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: Sam Ravnborg <[EMAIL PROTECTED]>
Andrew - another 2.6.24 candidate.
With
CONFIG_HOTPLUG=n
CONFIG_HOTPLUG_CPU=y
if the CPU_DEAD, CPU_DEAD_FROZEN happens then we will
call migrate_timers which is _devinit and we just triggered
a nice oops.
Sam
> ---
> kernel/timer.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.24-rc8-git2.orig/kernel/timer.c
> +++ linux-2.6.24-rc8-git2/kernel/timer.c
> @@ -1289,7 +1289,7 @@ static void migrate_timer_list(tvec_base
> }
> }
>
> -static void __devinit migrate_timers(int cpu)
> +static void __cpuinit migrate_timers(int cpu)
> {
> tvec_base_t *old_base;
> tvec_base_t *new_base;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] util-linux-ng: unprivileged mounts support
On Sat, 19 Jan 2008, Miklos Szeredi wrote: > > But 'fusermount -u /tmp/test' does work, doesn't it? You're submitting patches to get rid of fusermount, aren't you? Most users absolutely have no idea what fusermount is and they would __really__ like to see umount(8) working finally. Szaka -- NTFS-3G: http://ntfs-3g.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hrtimer: fix section mismatch
On Sat, Jan 19, 2008 at 10:31:46PM +0100, Sam Ravnborg wrote:
> On Sat, Jan 19, 2008 at 11:57:10AM -0800, Randy Dunlap wrote:
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > Fix section mismatch in hrtimer.c:
> >
> > WARNING: vmlinux.o(.text+0x50c61): Section mismatch: reference to
> > .init.text: (between 'hrtimer_cpu_notify' and 'down_read_trylock')
> >
> > Noticed by Johannes Berg and confirmed by Sam Ravnborg.
> >
> > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> Acked-by: Sam Ravnborg <[EMAIL PROTECTED]>
And looking at bit closer this looks like a 2.6.24 candidate.
With:
CONFIG_HOTPLUG=n
CONFIG_HOTPLUG_CPU=y
then we may see a call to init_hrtimers_cpu() from hrtimer_cpu_notify()
in the:
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
cases.
And this will oops.
[It these a cases will be hit I dunno - I just follow the
logic of the code here.]
Sam
>
> > ---
> > kernel/hrtimer.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- linux-2.6.24-rc8-git2.orig/kernel/hrtimer.c
> > +++ linux-2.6.24-rc8-git2/kernel/hrtimer.c
> > @@ -1378,7 +1378,7 @@ sys_nanosleep(struct timespec __user *rq
> > /*
> > * Functions related to boot-time initialization:
> > */
> > -static void __devinit init_hrtimers_cpu(int cpu)
> > +static void __cpuinit init_hrtimers_cpu(int cpu)
> > {
> > struct hrtimer_cpu_base *cpu_base = _cpu(hrtimer_bases, cpu);
> > int i;
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] x86: Add config variables for SMP_MAX
Ingo Molnar wrote: > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Adds and increases some config variables to accomodate larger SMP >> configurations: >> >> NR_CPUS: max limit now 4096 >> NODES_SHIFT: max limit now 9 >> THREAD_ORDER: max limit now 3 >> X86_SMP_MAX: say Y to enable possible cpus == NR_CPUS >> >> Signed-off-by: Mike Travis <[EMAIL PROTECTED]> > > i've bisected a boot failure down to this patch (sans the THREAD_ORDER > bits): it causes an instant reboot of the 64-bit kernel upon bootup. > Failing config attached. > > Ingo > Thanks Ingo! I've pulled the THREAD_ORDER change from my next version of the patch. Seems SMP_MAX is just not ready for prime time yet. One problem that I'm having appears to be that the !NUMA config of the current -mm version also doesn't boot so I haven't been able to verify that. (At least it doesn't seem to make it worse... ;-) Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hrtimer: fix section mismatch
On Sat, Jan 19, 2008 at 11:57:10AM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix section mismatch in hrtimer.c:
>
> WARNING: vmlinux.o(.text+0x50c61): Section mismatch: reference to .init.text:
> (between 'hrtimer_cpu_notify' and 'down_read_trylock')
>
> Noticed by Johannes Berg and confirmed by Sam Ravnborg.
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: Sam Ravnborg <[EMAIL PROTECTED]>
> ---
> kernel/hrtimer.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.24-rc8-git2.orig/kernel/hrtimer.c
> +++ linux-2.6.24-rc8-git2/kernel/hrtimer.c
> @@ -1378,7 +1378,7 @@ sys_nanosleep(struct timespec __user *rq
> /*
> * Functions related to boot-time initialization:
> */
> -static void __devinit init_hrtimers_cpu(int cpu)
> +static void __cpuinit init_hrtimers_cpu(int cpu)
> {
> struct hrtimer_cpu_base *cpu_base = _cpu(hrtimer_bases, cpu);
> int i;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup
David Rientjes wrote:
> On Fri, 18 Jan 2008, Yinghai Lu wrote:
>
>>> +#if MAX_NUMNODES > 256
>>> +typedef u16 numanode_t;
>>> +#else
>>> +typedef u8 numanode_t;
>>> +#endif
>>> +
>>> #endif /* _LINUX_NUMA_H */
>> that is wrong, you can not change pxm_to_node_map from int to u8 or u16.
>>
Thanks for finding this!
>
> Yeah, NID_INVAL is negative so no unsigned type will work here,
> unfortunately. And that reduces the intended savings of your change since
> the smaller type can only be used with a smaller CONFIG_NODES_SHIFT.
>
Excuse my ignorance but why wouldn't this work:
static numanode_t pxm_to_node_map[MAX_PXM_DOMAINS]
= { [0 ... MAX_PXM_DOMAINS - 1] = NUMA_NO_NODE
};
...
>> int acpi_map_pxm_to_node(int pxm)
>> {
> int node = pxm_to_node_map[pxm];
>
> if (node < 0)
numanode_t node = pxm_to_node_map[pxm];
if (node != NUMA_NO_NODE) {
>> if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
>> return NID_INVAL;
>> node = first_unset_node(nodes_found_map);
>> __acpi_map_pxm_to_node(pxm, node);
>> node_set(node, nodes_found_map);
>> }
or change:
#define NID_INVAL (-1)
to
#define NID_INVAL ((numanode_t)(-1))
...
if (node != NID_INVAL) {
>> if (nodes_weight(nodes_found_map) >= MAX_NUMNODES)
>> return NID_INVAL;
>> node = first_unset_node(nodes_found_map);
>> __acpi_map_pxm_to_node(pxm, node);
>> node_set(node, nodes_found_map);
>> }
Though why there two "node invalid" values I'm not sure... ?
>>
>> return node;
>> }
And btw, shouldn't the pxm value be sized to numanode_t size as well?
Will it ever be larger than the largest node id?
Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rcu: fix section mismatch
On Sat, Jan 19, 2008 at 11:56:43AM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> rcu_online_cpu() should be __cpuinit instead of __devinit.
>
> WARNING: vmlinux.o(.text+0x4b6d5): Section mismatch: reference to .init.text:
> (between 'rcu_cpu_notify' and 'wakeme_after_rcu')
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: Sam Ravnborg <[EMAIL PROTECTED]>
So if we have:
CONFIG_HOTPLUG=n
CONFIG_HOTPLUG_CPU=y
then this is a oops candidate.
Andrew - this looks like a 2.6.24 candidate.
Sam
> ---
> kernel/rcupdate.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.24-rc8-git2.orig/kernel/rcupdate.c
> +++ linux-2.6.24-rc8-git2/kernel/rcupdate.c
> @@ -549,7 +549,7 @@ static void rcu_init_percpu_data(int cpu
> rdp->blimit = blimit;
> }
>
> -static void __devinit rcu_online_cpu(int cpu)
> +static void __cpuinit rcu_online_cpu(int cpu)
> {
> struct rcu_data *rdp = _cpu(rcu_data, cpu);
> struct rcu_data *bh_rdp = _cpu(rcu_bh_data, cpu);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Help needed to fix section mismatch warnings
On Sat, Jan 19, 2008 at 11:52:55AM -0800, Randy Dunlap wrote: > On Sun, 6 Jan 2008 15:07:28 +0100 Sam Ravnborg wrote: > > > kbuild emit section mismatch warnings when it detects that someone does a > > call from a non-init section to a init section. > > The rationale here is that the init section are discarded at runtime and > > if this call happens after the init section has gone we have an oops. > > > > This check is planned to be turned into an error soon but we still > > see a bit too many warnings. > > > > To see the list below build a kernel like this: > > > > make allyesconfig > > Set CONFIG_HOTPLUG to n > > (In General Setup | Configure standard kernel features | Support for > > hot-plugable devices) > > > > Then build the kernel like this: > > make KCFLAGS=-fno-unit-at-a-time > > > > The flag "-fno-unit-at-a-time" tell gcc to avoid additional inlining which > > otherwise would hide several section mismatch warnings. > > > > With latest kernel I got 113 warnings and most should fixable. > > Try to look at how other section mismatch warnings has been fixed for > > inspiration. > > > > Patches can be cc:ed to me but always send it to the maintainer and lkml. > > > > Sam > > > > This is the current list of warnings > > > > WARNING: vmlinux.o(.text+0x1ffd0): Section mismatch: reference to > > .init.text:register_cpu (between 'arch_register_cpu' and > > 'arch_unregister_cpu') > > > WARNING: vmlinux.o(.text+0x21a39): Section mismatch: reference to > > .init.text:absent_pages_in_range (between 'reserve_hotadd' and > > 'unparse_node') > > WARNING: vmlinux.o(.text+0x21ae9): Section mismatch: reference to > > .init.data: (between 'unparse_node' and 'null_slit_node_compare') > > > WARNING: vmlinux.o(.text+0x38b43): Section mismatch: reference to > > .init.text:idle_regs (between 'fork_idle' and 'fork_traceflag') > > Above 4 seem to be mostly fixed in -mm. I made patches for them > and then checked -mm, so I won't post the patches... > > > > WARNING: vmlinux.o(.text+0x43524): Section mismatch: reference to > > .init.text: (between 'timer_cpu_notify' and 'msleep') > > WARNING: vmlinux.o(.text+0x4c6f6): Section mismatch: reference to > > .init.text: (between 'rcu_cpu_notify' and 'wakeme_after_rcu') > > WARNING: vmlinux.o(.text+0x51cbe): Section mismatch: reference to > > .init.text: (between 'hrtimer_cpu_notify' and 'down_read_trylock') > > I'll post patches for the 3 above. However, the rcu code in -mm > is quite different, so the rcu patch may have a short life. Hi Randy. Thanks for your efforts! Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[updated PATCH] xen: fix section usage in xen-head.S and setup.c
Failing to specify "ax" in the pushsection caused ld to generate
an additional section for .init.text appending a number.
A side effect of this was a section mismatch warning because modpost
did not recognize a .init.text section named .init.text.1:
WARNING: vmlinux.o(.text.head+0x247): Section mismatch: reference to
.init.text.1:start_kernel (between 'is386' and 'check_x87')
Fix this by hardcoding the "ax" in the pushsection.
Thanks to Torlaf for reporting this.
Alan Modra provided the hint that made me able to
locate the root cause of this warning.
And Mike Frysinger told me how to properly fix it
using __INIT/__FINIT.
Fix following Section mismatch warning in addition:
WARNING: vmlinux.o(.text+0x14c8): Section mismatch: reference to
.init.data:vsyscall_int80_start (between 'fiddle_vdso' and 'xen_setup_features')
fiddle_vdso was only used from a __init function - so declare it __init.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: WANG Cong <[EMAIL PROTECTED]>
Cc: Toralf Förster <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index f84e772..5e24f67 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -59,7 +59,7 @@ static void xen_idle(void)
/*
* Set the bit indicating "nosegneg" library variants should be used.
*/
-static void fiddle_vdso(void)
+static void __init fiddle_vdso(void)
{
extern u32 VDSO_NOTE_MASK; /* See ../kernel/vsyscall-note.S. */
extern char vsyscall_int80_start;
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index f8d6937..288d587 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -4,16 +4,18 @@
#ifdef CONFIG_XEN
#include
+#include
#include
#include
-.pushsection .init.text
+ __INIT
ENTRY(startup_xen)
movl %esi,xen_start_info
cld
movl $(init_thread_union+THREAD_SIZE),%esp
jmp xen_start_kernel
-.popsection
+
+ __FINIT
.pushsection .bss.page_aligned
.align PAGE_SIZE_asm
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] arch: Ignore arch/i386 and arch/x86_64
The i386 and x86_64 arch directories contain nothing but a generated symlink to arch/x86/boot/bzImage when a tree a built. Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]> --- arch/.gitignore |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 arch/.gitignore diff --git a/arch/.gitignore b/arch/.gitignore new file mode 100644 index 000..7414689 --- /dev/null +++ b/arch/.gitignore @@ -0,0 +1,2 @@ +i386 +x86_64 -- 1.5.4.rc2.85.g9de45-dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: konqueror deadlocks on 2.6.22
Oliver Pinter (Pintér Olivér) wrote: > This kernel is vanilla 2.6.22.y or with CFS? Yes with CFSv20.4, as in the log. It also hangs on 2.6.23.13 > On 1/19/08, Al Boldi <[EMAIL PROTECTED]> wrote: > > I was just attacked by some deadlock issue involving sqlite3 and > > konqueror. While sqlite3 continues to slowly fill a 7M-record db in > > transaction mode, konqueror hangs for a few minutes, then continues only > > to hang again and again. > > > > Looks like an fs/blockIO issue involving fsync. > > > > As a workaround, is there a way to make fsync soft? Thanks! -- Al -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why not creating a GIT RT tree ?
On 1/18/08, Steven Rostedt <[EMAIL PROTECTED]> wrote: > > On Fri, 18 Jan 2008, Francis Moreau wrote: > > > Maybe I missed it but I'm wondering why GIT is not used for > > the RT development ? I can't find a rt tree anywhere and all > > new rt release spoke about a patchset to apply on mainline > > kernels. > > The answer to this is pretty much the same as why the -mm tree isn't in > git either. > > The RT tree is made up of lots of patches (over 300). Our goal is to get > RT into mainline Linux. RT isn't just one type of system, it extends all > over the kernel, and the patches may be rewriten over and over. Managing > this in quilt is a lot easier than managing it in git. > > That said, there's been talk about making a git tree for others based on > the quilt queue. The thing is that a new git tree will need to be created > for every release. Which means that it will be difficult for others to > simply update their local repo since you will get a bunch of errors with > not being from the same head. stgit is worth checking out. It's basically quilt for git. I'm using to juggle about 30 patches. I believe there is a way to set up the git config file on the server to force updating clients onto the new head without triggering an error messages. Ask on the git list and you'll get at least a dozen different suggestions on how to make your repo available on git. > > > > > > Another question, is there a TODO list somewhere which would > > help to port the RT patch to a new architecture ? > > Which arch? We are already on PowerPC, ARM and MIPS. Thinking about sh? > > The best would be to read the code and look at my paper: > > http://ols.108.redhat.com/2007/Reprints/rostedt-Reprint.pdf > (Internals of the RT Patch) > > This will give you an idea of what is needed to port to another arch. > > > > > Sorry if the questions are dumbed but I'm just new to this > > project. > > No, in fact, I think it's about time to add these to our FAQ: > > http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions > > Thanks, > > -- Steve > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Jon Smirl [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] util-linux-ng: unprivileged mounts support
> > This is an experimental patch for supporing unprivileged mounts and > > umounts. > > User unmount unfortunately still doesn't work if the kernel doesn't have > the unprivileged mount support but as we discussed this in last July that > shouldn't be needed for this case. > > % mount -t ntfs-3g /dev/hda10 /tmp/test > % cat /proc/mounts | grep /tmp/test > > /dev/hda10 /tmp/test fuseblk > rw,nosuid,nodev,user_id=501,group_id=501,allow_other 0 0 > % mount | grep /tmp/test > /dev/hda10 on /tmp/test type fuseblk > (rw,nosuid,nodev,allow_other,blksize=1024,user=szaka) > % umount /tmp/test > umount: /dev/hda10: not mounted > umount: /tmp/test: must be superuser to umount > umount: /dev/hda10: not mounted > umount: /tmp/test: must be superuser to umount But 'fusermount -u /tmp/test' does work, doesn't it? Yes, this should probably be fixed in umount(8), but it's an (almost) completely separate issue. Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why not creating a GIT RT tree ?
Hello, On Jan 18, 2008 10:59 PM, James Cloos <[EMAIL PROTECTED]> wrote: > > "Francis" == Francis Moreau <[EMAIL PROTECTED]> writes: > > Francis> I can't find a rt tree anywhere and all new rt release spoke > Francis> about a patchset to apply on mainline kernels. > > It is not perfect, but I do have a git repo of the rt history-of-patches > up at: > > git://git.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git > http://www.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git > > Gitweb URL is: > > http://git.kernel.org/?p=linux/kernel/git/cloos/rt-2.6.git > > It is in the one-head per patch style, and has the single-file patches > applied rather than the quilt queue. Why don't you have one commit per patch ? Thanks -- Francis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Where's the create() pointer?
On Sat, 2008-01-19 at 12:02 -0700, Justin Banks wrote: > Trond Myklebust wrote > > > > On Sat, 2008-01-19 at 08:07 -0700, Justin Banks wrote: > > > It's probably been this way for a long time, and I'm just noticing, but > > > I can't seem to find the create() (among others) pointer for NFS > > > filesystems. > > > > > > Specifically, If I look at sb->s_root->d_inode->i_op there's no create > > > there. How do I find it? I'm guessing that the ability to share mount > > > structures between multiple NFS mounts resulted in some kind of fake > > > superblock, but I just can't figure out where to find the functions. > > > > Why would you want to do this in the first place? > > I'm just looking at trapping new creates on NFS, and so I need to find > the pointer. What is your purpose in trapping creates on the client? Is this for accounting purposes? If so, why wouldn't inotify, or even a systemtap script suffice? Anyhow, the simplest way to find the pointer is to grep for nfs_create in /proc/kallsyms. Trond -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Allocate pnp resources dynamically via krealloc
Allocate pnp resources dynamically via krealloc The patch is against 2.6.24-rc6-mm1. Latest BIOS ACPI PNP device resource descriptions may have (especially on the general device PNP0c02) more than 20 IO port resources. Reserve the space in a static array wastes a lot of memory on every PNP device and is not a real option as the number of IO ports could be much greater than 20. This approach allocates the memory for PNP resources at runtime. The memory is reallocated in e.g. 8 (for IO port) resource portions. That means that the previously allocated pointers will get a new address. Therefore this address must not be stored or re-used as long as krealloc might still allocate new resources. First #define pnp_port_ptr(dev,bar) returned the X port pointer of a pnp_resource_table. I changed it to true/false to not let the idea come up to store the pointer for later use. The name must still be changed, but I had no idea for now. The patch also needs another patch from Rene Herman: "[PATCH] sound/isa: kill pnp_resource_change." Sent to the alsa-devel list and it's already included in Takashi's tree for 2.6.25 inclusion. This additional patch is only needed for some BIOS workarounds for very old isa sound cards, so it should not be a problem to have only this one in someones tree for a while. (This will cause some minor merging conflicts, though. The rarely used function (pnp_manual_config_dev) return 1 through this patch and the other one rips it out). Signed-off-by: Thomas Renninger <[EMAIL PROTECTED]> --- drivers/pnp/core.c |2 drivers/pnp/interface.c| 44 +++- drivers/pnp/isapnp/core.c | 33 ++- drivers/pnp/manager.c | 419 +++-- drivers/pnp/pnpacpi/rsparser.c | 142 ++--- drivers/pnp/pnpbios/rsparser.c | 112 +- drivers/pnp/resource.c | 16 - drivers/pnp/support.c | 11 - drivers/pnp/system.c | 34 +-- include/linux/pnp.h| 59 - 10 files changed, 620 insertions(+), 252 deletions(-) Index: linux-2.6.24-rc6-mm1/include/linux/pnp.h === --- linux-2.6.24-rc6-mm1.orig/include/linux/pnp.h +++ linux-2.6.24-rc6-mm1/include/linux/pnp.h @@ -13,10 +13,6 @@ #include #include -#define PNP_MAX_PORT 24 -#define PNP_MAX_MEM12 -#define PNP_MAX_IRQ2 -#define PNP_MAX_DMA2 #define PNP_NAME_LEN 50 struct pnp_protocol; @@ -26,13 +22,26 @@ struct pnp_dev; * Resource Management */ -/* Use these instead of directly reading pnp_dev to get resource information */ +/* + * NULL pointer alarm: always check with pnp_port_ptr or pnp_port_valid before + * accessing start/end/flags/len values or you might access not allocated mem. + * Same for mem, irq and dma macros + * + * Pointers are not static and they might change, do not store addresses + * of resources in the pnp resource table! + */ + +#define pnp_port_ptr(dev,bar) ((dev)->res.allocated_ports > (bar) \ +? (1) : (0)) + #define pnp_port_start(dev,bar) ((dev)->res.port_resource[(bar)].start) #define pnp_port_end(dev,bar) ((dev)->res.port_resource[(bar)].end) #define pnp_port_flags(dev,bar) ((dev)->res.port_resource[(bar)].flags) #define pnp_port_valid(dev,bar) \ + (pnp_port_ptr((dev),(bar)) ? \ ((pnp_port_flags((dev),(bar)) & (IORESOURCE_IO | IORESOURCE_UNSET)) \ - == IORESOURCE_IO) + == IORESOURCE_IO) : \ +(0)) #define pnp_port_len(dev,bar) \ ((pnp_port_start((dev),(bar)) == 0 && \ pnp_port_end((dev),(bar)) == \ @@ -41,12 +50,16 @@ struct pnp_dev; (pnp_port_end((dev),(bar)) - \ pnp_port_start((dev),(bar)) + 1)) +#define pnp_mem_ptr(dev,bar) ((dev)->res.allocated_mems > (bar) \ +? (1) : (0)) #define pnp_mem_start(dev,bar) ((dev)->res.mem_resource[(bar)].start) #define pnp_mem_end(dev,bar) ((dev)->res.mem_resource[(bar)].end) #define pnp_mem_flags(dev,bar) ((dev)->res.mem_resource[(bar)].flags) #define pnp_mem_valid(dev,bar) \ + (pnp_mem_ptr((dev),(bar)) ? \ ((pnp_mem_flags((dev),(bar)) & (IORESOURCE_MEM | IORESOURCE_UNSET)) \ - == IORESOURCE_MEM) + == IORESOURCE_MEM) : \ +(0)) #define pnp_mem_len(dev,bar) \ ((pnp_mem_start((dev),(bar)) == 0 &&\ pnp_mem_end((dev),(bar)) == \ @@ -55,17 +68,25 @@ struct pnp_dev; (pnp_mem_end((dev),(bar)) -\ pnp_mem_start((dev),(bar)) + 1)) +#define pnp_irq_ptr(dev,bar) ((dev)->res.allocated_irqs > (bar) \ +? (1) : (0)) #define pnp_irq(dev,bar)((dev)->res.irq_resource[(bar)].start) #define pnp_irq_flags(dev,bar) ((dev)->res.irq_resource[(bar)].flags) #define pnp_irq_valid(dev,bar) \ +
Re: [PATCH] x86 reboot: Remove inb_p usage
> Stupid question from the peanut gallery: If you're going to go through
> all this, maybe it would be better to define an inline
> isa_bus_delay(void) { udelay(2); } and use that instead? I can only
There are very few places it crops up - in fact that one is the only non
pic/pit/cmos example in the core arch code.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hrtimer: fix section mismatch
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch in hrtimer.c:
WARNING: vmlinux.o(.text+0x50c61): Section mismatch: reference to .init.text:
(between 'hrtimer_cpu_notify' and 'down_read_trylock')
Noticed by Johannes Berg and confirmed by Sam Ravnborg.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
kernel/hrtimer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc8-git2.orig/kernel/hrtimer.c
+++ linux-2.6.24-rc8-git2/kernel/hrtimer.c
@@ -1378,7 +1378,7 @@ sys_nanosleep(struct timespec __user *rq
/*
* Functions related to boot-time initialization:
*/
-static void __devinit init_hrtimers_cpu(int cpu)
+static void __cpuinit init_hrtimers_cpu(int cpu)
{
struct hrtimer_cpu_base *cpu_base = _cpu(hrtimer_bases, cpu);
int i;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] timer: fix section mismatch
From: Randy Dunlap <[EMAIL PROTECTED]>
The caller is __cpuinit.
Also, this code block and its caller are inside #ifdef CONFIG_HOTPLUG_CPU
blocks, so this code should reflect that config symbol's usage.
WARNING: vmlinux.o(.text+0x4252f): Section mismatch: reference to .init.text:
(between 'timer_cpu_notify' and 'msleep')
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
kernel/timer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc8-git2.orig/kernel/timer.c
+++ linux-2.6.24-rc8-git2/kernel/timer.c
@@ -1289,7 +1289,7 @@ static void migrate_timer_list(tvec_base
}
}
-static void __devinit migrate_timers(int cpu)
+static void __cpuinit migrate_timers(int cpu)
{
tvec_base_t *old_base;
tvec_base_t *new_base;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rcu: fix section mismatch
From: Randy Dunlap <[EMAIL PROTECTED]>
rcu_online_cpu() should be __cpuinit instead of __devinit.
WARNING: vmlinux.o(.text+0x4b6d5): Section mismatch: reference to .init.text:
(between 'rcu_cpu_notify' and 'wakeme_after_rcu')
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
kernel/rcupdate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc8-git2.orig/kernel/rcupdate.c
+++ linux-2.6.24-rc8-git2/kernel/rcupdate.c
@@ -549,7 +549,7 @@ static void rcu_init_percpu_data(int cpu
rdp->blimit = blimit;
}
-static void __devinit rcu_online_cpu(int cpu)
+static void __cpuinit rcu_online_cpu(int cpu)
{
struct rcu_data *rdp = _cpu(rcu_data, cpu);
struct rcu_data *bh_rdp = _cpu(rcu_bh_data, cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Help needed to fix section mismatch warnings
On Sun, 6 Jan 2008 15:07:28 +0100 Sam Ravnborg wrote: > kbuild emit section mismatch warnings when it detects that someone does a > call from a non-init section to a init section. > The rationale here is that the init section are discarded at runtime and > if this call happens after the init section has gone we have an oops. > > This check is planned to be turned into an error soon but we still > see a bit too many warnings. > > To see the list below build a kernel like this: > > make allyesconfig > Set CONFIG_HOTPLUG to n > (In General Setup | Configure standard kernel features | Support for > hot-plugable devices) > > Then build the kernel like this: > make KCFLAGS=-fno-unit-at-a-time > > The flag "-fno-unit-at-a-time" tell gcc to avoid additional inlining which > otherwise would hide several section mismatch warnings. > > With latest kernel I got 113 warnings and most should fixable. > Try to look at how other section mismatch warnings has been fixed for > inspiration. > > Patches can be cc:ed to me but always send it to the maintainer and lkml. > > Sam > > This is the current list of warnings > > WARNING: vmlinux.o(.text+0x1ffd0): Section mismatch: reference to > .init.text:register_cpu (between 'arch_register_cpu' and > 'arch_unregister_cpu') > WARNING: vmlinux.o(.text+0x21a39): Section mismatch: reference to > .init.text:absent_pages_in_range (between 'reserve_hotadd' and 'unparse_node') > WARNING: vmlinux.o(.text+0x21ae9): Section mismatch: reference to .init.data: > (between 'unparse_node' and 'null_slit_node_compare') > WARNING: vmlinux.o(.text+0x38b43): Section mismatch: reference to > .init.text:idle_regs (between 'fork_idle' and 'fork_traceflag') Above 4 seem to be mostly fixed in -mm. I made patches for them and then checked -mm, so I won't post the patches... > WARNING: vmlinux.o(.text+0x43524): Section mismatch: reference to .init.text: > (between 'timer_cpu_notify' and 'msleep') > WARNING: vmlinux.o(.text+0x4c6f6): Section mismatch: reference to .init.text: > (between 'rcu_cpu_notify' and 'wakeme_after_rcu') > WARNING: vmlinux.o(.text+0x51cbe): Section mismatch: reference to .init.text: > (between 'hrtimer_cpu_notify' and 'down_read_trylock') I'll post patches for the 3 above. However, the rcu code in -mm is quite different, so the rcu patch may have a short life. --- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Core driver for WM97xx touchscreens
Ben Dooks wrote: > On Fri, Jan 18, 2008 at 06:11:45PM +, Dmitry Baryshkov wrote: >> Hi, >> >> Dmitry Torokhov wrote: >> >> > I will need some more time to review and understand the need for the >> > new bus in the driver. >> >> Most likely this can be converted to platform_bus. Maybe this can also >> get help from soon-to-be posted MFD (multi function devices) helpers. > > Is there any current discussion of these in public? I'm interested > mainly due to my involvement in the SM501 core and FB driver. Can I also > request to be Cc'd when these are posted? You can find the current work at git://git.mnementh.co.uk/linux-2.6-im.git#tmio_dev_try3. Look for "Core MFD support" changeset. For CC concact Ian <[EMAIL PROTECTED]>. > > -- > Ben ([EMAIL PROTECTED], http://www.fluff.org/) > > 'a smiley only costs 4 bytes' -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Core driver for WM97xx touchscreens
Hi, 2008/1/19, Mark Brown <[EMAIL PROTECTED]>: > On Fri, Jan 18, 2008 at 06:11:45PM +, Dmitry Baryshkov wrote: > > Dmitry Torokhov wrote: > > > > I will need some more time to review and understand the need for the new > > > bus in the driver. > > > Most likely this can be converted to platform_bus. Maybe this can also get > > Could you expand on how you see that being implemented, please? It > doesn't feel entirely comfortable to me - providing a bus for the chip > seems more direct and the platform bus not what I'd think of using for > something hanging off another bus - but I think I'm just not visualising > what you're thinking of properly. Well... It's a common suggestion not to duplicate code. The wm97xx bus looks mostly like platform. The only difference is the name. To help visualisation, devices can have parents. Just set (in pseudocode) wm97xx-touchscreen->parent to wm97xx, do the same for wm97xx-battery and so on. Thus all devices would be on the platform device but with proper parent <-> child notation. > > help from soon-to-be posted MFD (multi function devices) helpers. > > The multi-function device support does feel like it could be a good fit. > I'd seen it discussed sometime last year but don't recall seeing > anything for quite a while. Like Ben said, any pointers to current work > would be appreciated. You can find the current work at git://git.mnementh.co.uk/linux-2.6-im.git#tmio_dev_try3. Look for "Core MFD support" changeset. > > It's probably worth mentioning that in addition to what is in the > current patch series these chips all also provide an audio codec which > requires a reasonably substantial driver for full support. > This would only touch child devices organisation. -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LatencyTop: make reason (blk_execute_rq+0x7a/0xd) known
Arjan van de Ven wrote: > Török Edwin wrote: >> >> Cause Maximum >> Average >> SCSI device ioctl 34.2 msec >> 14.4 msec > > great! I'll put this into my patchkit! Thanks. >> I also noticed some unsigned overflows, my top latency was sometimes a >> very large number (18), which >> was probably -1, or some other negative number. I haven't found a way >> to reproduce it yet (it happens very rarely). > > > I've not seen this; I'll take another peak at the code. I just captured this: Cause Maximum Average Waiting for userspace lock18446744073638300.0 msec9223372036783524.0 msec Waiting for processes to die (waitpid)18446744073638296.0 msec9223372036783520.0 msec Waiting for event (poll) 18446744073565216.0 msec764505121372.0 msec SCSI device ioctl 35.2 msec 13.7 msec Application requested delay19.5 msec 0.0 msec page fault 18.6 msec 4.0 msec Reading from file 16.6 msec 1.5 msec Waiting for buffer IO 15.2 msec 3.0 msec mutex lock 15.0 msec 15.0 msec I was also looking at /proc/latency_stats using watch, and I've seen that there were negative number. Unfortunately I couldn't copy+paste it, because it was gone too fast. I was running a program with 4 threads doing usleep(0) in an inf-loop. However I can't reproduce the overflow now with the same program. Best regards, --Edwin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux device ordering at boot time
On Jan 19 2008 20:14, Oliver Pinter (Pintér Olivér) wrote: > >I don't know, what the proble, but the fstab workaround functioniert: >form: >/dev/sda3 / xfs defaults0 1 >to: >UUID=7c167a53-30ff-4d47-a206-ce8caf2397ba / xfs > defaults0 1 > >in this fix switched form device name to UUID based fstab. > >the uuid-s queried with /lib/udev/vol_id program Any distro that uses udev can use /dev/disk/by-.../... without having to resort to per-program specific implementations (or lack thereof) of UUID= or LABEL=. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LatencyTop: make reason (blk_execute_rq+0x7a/0xd) known
Arjan van de Ven <[EMAIL PROTECTED]> writes: > Török Edwin wrote: >> [...] >> P.S.: LatencyTop could have a feature to ask for more details on unknown >> latency reasons, and it would generate a systemtap script itself, that >> would show the backtraces to help figure out whats going on. > > I've considered having an option inside the code itself that would print a > backtrace for, say, an unknown latency larger than 100msec > but the code got ugly (the accounting gets done in the scheduler path, > where you can't printk). [...] Systemtap does not use printk, and can generate decent backtraces from the kernel (and into userspace before too long). (FWIW, it seems to be only a small stretch to implement tools like *top via systemtap rather than custom-written kernel code.) - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why not creating a GIT RT tree ?
On Jan 18, 2008 8:12 PM, Steven Rostedt <[EMAIL PROTECTED]> wrote: > True, but then how would you do it. One thing is that most of these > branches would interact with each other. Touching the same code quite > a bit. So it doesn't always help. But pulling out patches can help us to > an extent. > I see, it would probably be too painful in this context, that's pity. > > Great! Looking forward to it ;-) > Well actually it seems already supported. Some files in arch/sh are already touched by RT patches. I took a look to your interesting paper and I have now a question about the BKL: Why is it so hard to get ride of it completely ? Do you have any advices or starting point to get involved in RT kernel ? I'm almost new in this area but I'd like to acquire some knowledges and try to contribute if possible... Thanks ! -- Francis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [7/8] CPA: Implement GBpages support in change_page_attr()
On Saturday 19 January 2008 19:53:14 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > arch/x86/mm/pageattr_64.c | 150 > > -- > > 1 file changed, 119 insertions(+), 31 deletions(-) > > please unify the files first, we dont want to let pageattr_32.c and > pageattr_64.c diverge even more. Once we get these files unified we > layer more features ontop of it. They work significantly differently in a few important areas (e.g. particularly regarding NX handling and the kernel mapping) Off the top of my head I don't know of a clean way to unify them. 32bit and 64bit kernel mappings differ in many significant ways. Maybe it's possible, but it's certainly not something I would want to tackle short term in a hurry. The kernel mappings between 32bit and 64bit are quite different. However I would like GBPAGES definitely to make the .25 merge window and they won't work without the upgraded c_p_a(). So please reconsider. > While gbpages is not available on > 32-bit and probably wont ever be, this code has been historically very > fragile, I'm sure a hurried up unification would make it even more fragile. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux device ordering at boot time
I don't know, what the proble, but the fstab workaround functioniert: form: /dev/sda3 / xfs defaults0 1 to: UUID=7c167a53-30ff-4d47-a206-ce8caf2397ba / xfs defaults0 1 in this fix switched form device name to UUID based fstab. the uuid-s queried with /lib/udev/vol_id program /*sorry for bad english*/ On 1/19/08, Lars Callenbach <[EMAIL PROTECTED]> wrote: > I have a question concerning the ordering of devices during the boot process > and I hope that the kernel mailing list is the right place for this > question. > In my computer are two raid controllers with one raid array connected to > each of them (/dev/sda, /dev/sdb). In the debian 2.6.18 boot process the > ordering is root @ /dev/sda and data are on /dev/sdb. This behaviour has > changed in the plain 2.6.23.1 (and 2.6.23.8) kernel. The /dev/sd(a|b) > devices have switched so that root @ /dev/sdb. So my standard fstab does not > work. > What determines the device ordering during the boot process? What is a > workaround for this problem? > > Thank you very much for some hints, >Lars > > -- > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Thanks, Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI early ioremap problems
> hm, so are you saying that on 64-bit there's in essence no usable > ioremap facility between zap_low_mappings() and paging_init()? > (early_ioremap() is not usable anymore, and ioremap() is not yet > usable.) I guess we'll have to pick up the 32-bit early_ioremap() code > for 64-bit as well. No early_ioremap() should work. Or rather used to work. It does map into the kernel mapping which is not zapped. It just broke recently. But it definitely used to work because several users used it before paging_init() even before the recent PAT changes. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Where's the create() pointer?
Trond Myklebust wrote > > On Sat, 2008-01-19 at 08:07 -0700, Justin Banks wrote: > > It's probably been this way for a long time, and I'm just noticing, but > > I can't seem to find the create() (among others) pointer for NFS > > filesystems. > > > > Specifically, If I look at sb->s_root->d_inode->i_op there's no create > > there. How do I find it? I'm guessing that the ability to share mount > > structures between multiple NFS mounts resulted in some kind of fake > > superblock, but I just can't figure out where to find the functions. > > Why would you want to do this in the first place? I'm just looking at trapping new creates on NFS, and so I need to find the pointer. > Anyhow, to answer the question: sb->s_root is not guaranteed to be a > real file on NFS. The real mountpoints are usually in the anonymous > dentry list. Okay, I'll look there, thanks. -justinb -- Justin Banks BakBone Software [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
