Re: slab allocators: Remove obsolete SLAB_MUST_HWCACHE_ALIGN
On 4/17/07, Christoph Lameter [EMAIL PROTECTED] wrote: The flag SLAB_MUST_HWCACHE_ALIGN is 1. Never checked by SLAB at all. 2. A duplicate of SLAB_HWCACHE_ALIGN for SLUB 3. Fulfills the role of SLAB_HWCACHE_ALIGN for SLOB. The only remaining use is in sparc64 and ppc64 and their use there reflects some earlier role that the slab flag once may have had. If its specified then SLAB_HWCACHE_ALIGN is also specified. The flag is confusing, inconsistent and has no purpose. Remove it. Acked-by: Pekka Enberg [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] Show slab memory usage on OOM and SysRq-M
Hi,
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Makes sense.
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
diff --git a/mm/slab.c b/mm/slab.c
index 21b3c61..9a5829a 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -749,6 +749,7 @@ static inline void init_lock_keys(void)
* 2. Protect sanity of cpu_online_map against cpu hotplug events
*/
static DEFINE_MUTEX(cache_chain_mutex);
+static DEFINE_SPINLOCK(cache_chain_lock);
So, now we have two locks protecting cache_chain? Please explain why
you can't use the mutex.
+static unsigned long get_cache_size(struct kmem_cache *cachep)
+{
+ unsigned long slabs;
+ struct kmem_list3 *l3;
+ struct list_head *lh;
+ int node;
+
+ slabs = 0;
+
+ for_each_online_node (node) {
+ l3 = cachep-nodelists[node];
+ if (l3 == NULL)
+ continue;
+
+ spin_lock(l3-list_lock);
+ list_for_each (lh, l3-slabs_full)
+ slabs++;
+ list_for_each (lh, l3-slabs_partial)
+ slabs++;
+ list_for_each (lh, l3-slabs_free)
+ slabs++;
+ spin_unlock(l3-list_lock);
+ }
+
+ return slabs * ((PAGE_SIZE cachep-gfporder) +
+ (OFF_SLAB(cachep) ? cachep-slabp_cache-buffer_size : 0));
+}
Considering you're doing this at out_of_memory() time, wouldn't it
make more sense to add a -nr_pages to struct kmem_cache and do the
tracking in kmem_getpages/kmem_freepages?
I would also drop the OFF_SLAB bits because it really doesn't matter
that much for your purposes. Besides, you're already per-node and
per-CPU caches here which attribute to much more memory on NUMA setups
for example.
-
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] Show slab memory usage on OOM and SysRq-M (v2)
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote: The out_of_memory() function and SysRq-M handler call show_mem() to show the current memory usage state. I am still somewhat unhappy about the spinlock, but I don't really have a better suggestion either. Other than that, looks good to me. Acked-by: Pekka Enberg [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 2/7] revoke: add f_light flag for struct file
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote: Cannot we use a flag in 'struct files_struct', set to one when the task is mono-thread (at task creation in fact), and set to 0 when it creates a new thread (or when someone remotely access to this struct files_struct in /proc/pid/fd/... ) How does that work? fget_light() has a built-in assumption that as long as you don't share files_struct, it's okay not to take an extra reference as current is only one doing close(2) and revoke(2) changes that. So it's not really about being single-threaded or not. On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote: Also, the thing is racy. Aah, fget_light() indeed has a race window between fcheck_files() and set_f_light(). - 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 2/7] revoke: add f_light flag for struct file
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote: Then just drop the fget_light() 'optimisation' and always take a reference (atomic on f_count) regardless of single-thread or not. Instead of dirtying f_light, just do the straightforward thing and be with it. That's what I did first but akpm thought it was unfortunate. Hmm.. ;-) - 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 2/7] revoke: add f_light flag for struct file
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote: Then just drop the fget_light() 'optimisation' and always take a reference (atomic on f_count) regardless of single-thread or not. Instead of dirtying f_light, just do the straightforward thing and be with it. On 3/9/07, Pekka Enberg [EMAIL PROTECTED] wrote: That's what I did first but akpm thought it was unfortunate. Hmm.. ;-) Btw, what we can do is delay closing the actual revoked file until the task terminates. This has the unfortunate side-effect that a task has no way of freeing the resources now. But, I am beginning to think it's not a big problem because the inode mapping will be zapped immediately upon revoke anyway... - 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] revoke: delayed file closing
On 3/9/07, Pekka J Enberg [EMAIL PROTECTED] wrote: To fix this, change sys_revoke() not to close the actual revoked file immediately. Instead, we do filp_close() when the user does close(2) on the revoked file descriptor. Btw, this is safe because a filesystem implementing f_ops-revoke must ensure there are no pending writes after it has completed so f_ops-flush will not do any actual flushing when it is invoked by a delayed close. - 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/7] revoke: wire up s390 system calls
Hi Martin, Martin Schwidefsky wrote: Yes, please put me or Heiko on CC if you add system calls to s390. Ok, sorry about that. I would expect akpm to send it to you guys though whenever revoke graduates from -mm and not merge it to mainline. 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 2/7] revoke: add f_light flag for struct file
On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote: Then just drop the fget_light() 'optimisation' and always take a reference (atomic on f_count) regardless of single-thread or not. Instead of dirtying f_light, just do the straightforward thing and be with it. (that is : fget_light() = fget() = no more keeping fput_needed everywhere, and convoluted things in some dark sides of the kernel. On 3/9/07, Benjamin LaHaise [EMAIL PROTECTED] wrote: And it makes things rather slower for a lot of single threaded applications on modern systems. Yes, fget_light can be done much more cleanly, but please don't go around ripping out optimizations just because. Don't worry, the fget_light() bits are no longer needed: http://lkml.org/lkml/2007/3/9/151 - 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/7] revoke: core code
On Fri, 2007-03-09 at 10:15 +0200, Pekka J Enberg wrote:
+ again:
+ restart_addr = zap_page_range(vma, start_addr, end_addr - start_addr,
+ details);
+
+ need_break = need_resched() || need_lockbreak(details-i_mmap_lock);
+ if (need_break)
+ goto out_need_break;
+
+ if (restart_addr end_addr) {
+ start_addr = restart_addr;
+ goto again;
+ }
+ return 0;
+
+ out_need_break:
+ spin_unlock(details-i_mmap_lock);
+ cond_resched();
+ spin_lock(details-i_mmap_lock);
+ return -EINTR;
On Fri, 2007-03-09 at 13:30 +0100, Peter Zijlstra wrote:
I'm not sure this scheme works, given a sufficiently loaded machine,
this might never complete.
Hmm, so what's the alternative? It's better to fail revoke than lock up
the box.
On Fri, 2007-03-09 at 13:30 +0100, Peter Zijlstra wrote:
I'm never sure of operator precedence and prefer:
(vma-vm_flags VM_SHARED) ...
which leaves no room for error.
Thanks, fixed.
-
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/4] [TULIP] Rev tulip version
Hi, On 3/12/07, Valerie Henson [EMAIL PROTECTED] wrote: --- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c +++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c @@ -17,11 +17,11 @@ #define DRV_NAME tulip #ifdef CONFIG_TULIP_NAPI -#define DRV_VERSION1.1.14-NAPI /* Keep at least for test */ +#define DRV_VERSION1.1.15-NAPI /* Keep at least for test */ #else -#define DRV_VERSION1.1.14 +#define DRV_VERSION1.1.15 #endif -#define DRV_RELDATEMay 11, 2002 +#define DRV_RELDATEFeb 27, 2007 Why not just drop this? What purpose does a per-module revision have for in-kernel drivers anyway? 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] [REVISED] net/ipv4/multipath_wrandom.c: check kmalloc() return value.
On 3/12/07, Jarek Poplawski [EMAIL PROTECTED] wrote: So, maybe it's less evil to check those NULLs where possible and add some WARN_ONs here and there... No, it's much better to oops rather than paper over a bug. - 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: kernel BUG at mm/slab.c:610
Hi Marco, On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote: Hello everybody. Sorry for posting to this list, but I'm pretty lost. Don't worry, this is the proper mailing list for bug reports. On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote: I don't think this is related to buggy hardware because it is happening on 3 different boxes with the same hardware config. No, looks like someone is feeding a bad pointer to slab. The debug check is relatively new and in previous kernels the problem would might have gone unnoticed causing silent corruption of the slab. On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote: ksymoops 2.4.10 on i686 2.6.20. Options used From Documentation/oops-tracing.txt: NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format (from dmesg, etc). Ignore any references in this or other docs to decoding the Oops or running it through ksymoops. If you post an Oops from 2.6 that has been run through ksymoops, people will just tell you to repost it. So, can you please repost the original oops? Also, please enable CONFIG_DEBUG_SLAB and try to reproduce. Thanks. - 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: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory
Hi Chris, On 3/10/07, Chris Rankin [EMAIL PROTECTED] wrote: It looks like 2.6.20.2 is still doing Bad Things in /sys. I have seen other reports of this too so can you please open a bug at bugzilla.kernel.org so this is not lost in the noise? - 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: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory
Hi Greg, I think there's some sort of reference counting problem with sysfs in 2.6.20 kernels. Can you please help us debug it further? On 3/10/07, Chris Rankin [EMAIL PROTECTED] wrote: It looks like 2.6.20.2 is still doing Bad Things in /sys. BUG: unable to handle kernel paging request at virtual address 6b6b6d6b [snip] EIP:0060:[c01300ff]Not tainted VLI EFLAGS: 00010202 (2.6.20.2 #1) EIP is at module_put+0x20/0x52 eax: 6b6b6d6b ebx: 6b6b6b6b ecx: 0001 edx: e7a01000 esi: edb7e4e4 edi: 6b6b6b6b ebp: e79fd50c esp: e7a01f58 ds: 007b es: 007b ss: 0068 Process udevd (pid: 9656, ti=e7a01000 task=f7a46030 task.ti=e7a01000) Stack: eba628a0 c0183a1e 0010 ed570870 e7a641d0 c0151263 f7ff2208 ed570870 f745b678 ed570870 c014eda0 0003 0003 f745b678 f745b6f8 c014fd99 0003 0007 0003 e7a01000 c0102bde Call Trace: [c0183a1e] sysfs_release+0x2d/0x4c [c0151263] __fput+0x96/0x13c [c014eda0] filp_close+0x51/0x58 [c014fd99] sys_close+0x70/0xa7 [c0102bde] sysenter_past_esp+0x5f/0x85 [c0270033] __sched_text_start+0x613/0x971 There's also some previous discussion here: http://lkml.org/lkml/2007/3/1/114 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: kernel BUG at mm/slab.c:610
On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote: Only to tell you, that on the console linux was printing this message: atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. Probably unrelated. CONFIG_SLAB_DEBUG should tell us what's corrupting the slab. - 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 2/5] revoke: core code
Hi Andrew,
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg
[EMAIL PROTECTED] wrote:
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
n all system calls must return long.
Fixed.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
so the modification of vm_flags is racy?
+ smp_mb();
Please always document barriers. There's presumably some vm_flags reader
we're concerned about here, but how is the code reader to know what the
code writer was thinking?
We're need to watch out for page faults after the shared mappings have
been taken down and mmap(2) trying to remap. I'll add a comment here.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
This all looks very strange. If the calling process expires its timeslice,
the entire system call fails?
What's happening here?
Me being stupid. I followed what unmap_mapping_range_vma is doing but
failed to see what its callers are doing. I'll fix it up.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
do_fsync() is seriously suboptimal - it will run an ext3 commit.
do_sync_file_range(...,
SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER)
will run maybe five times quicker.
But otoh, do_sync_file_range() will fail to write back the pages for a
data=journal ext3 file, I expect (oops).
But it's good enough for generic_file_revoke, no? Ext3 should probably
implement it's own revoke hook so you can drop the ext2 and ext3 hooks
if you're worried, I did them mostly for testing.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
Why is this code using invalidate_inode_pages2()? That function keeps on
breaking, has ill-defined semantics and will probably change in the future.
Exactly what semantics are you looking for here, and why?
What the comment says make pending reads fail. When revoking an
inode, we need to make sure there are no pending I/O that will
complete after revocation and thus leak information.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
The blank line before the EXPORT_SYMBOL() is a waste of space.
I'll fix that up.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
+static struct inode *revokefs_alloc_inode(struct super_block *sb)
+{
+ struct revokefs_inode_info *info;
+
+ info = kmem_cache_alloc(revokefs_inode_cache, GFP_NOFS);
+ if (!info)
+ return NULL;
+
+ return info-vfs_inode;
+}
Why GFP_NOFS?
GFP_KERNEL should be sufficient. I'll fix that up.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ uml-2.6/include/linux/revoked_fs_i.h 2007-03-11 13:09:20.0
+0200
@@ -0,0 +1,20 @@
+#ifndef _LINUX_REVOKED_FS_I_H
+#define _LINUX_REVOKED_FS_I_H
+
+#define REVOKEFS_MAGIC 0x5245564B /* REVK */
This is supposed to go into magic.h.
Will do. Thank you Andrew.
-
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: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory
On 3/16/07, Greg KH [EMAIL PROTECTED] wrote: Is there any way you can use 'git bisect' to try to track down the root cause of this? Chris, If 2.6.19 works for you, could you please do a git bisect for this bug? See the following URL for details: http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt - 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/3] revoke: misc fixes
On 3/16/07, Nick Piggin [EMAIL PROTECTED] wrote: Also, a down_write_trylock attempt inside i_mmap_lock should be a valid optimisation. I am not sure what you're thinking here. down_write_trylock acquires -mmap_sem which can deadlock with -i_mmap_lock, no? - 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: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory
Hi Chris, On 3/16/07, Chris Rankin [EMAIL PROTECTED] wrote: That would take ages - the only reason I kept on plugging away with winecfg last night was because I was fairly certain the kernel was going to oops eventually (which it did). But when exactly would I be able to declare a kernel good during a git bisect? Yeah, if you can't reproduce at will, git bisect is very impractical. Please try out the following patch to see if we catch a reference counting underflow: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/detect-atomic-counter-underflows.patch - 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 2/5] revoke: core code
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote: Serious question - do we actually need revoke() on a normal file ? BSD has never had this, SYS5 has never had this. It's needed for forced unmount (bits of it anyway) and partial-revocation in SLIM. - 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 2/5] revoke: core code
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote: I'm not sure that running do_fsync() will guarantee that all sys_write() callers will have finished their syscall. Probably they will have, in practice. But there is logic in the sync paths to deliberately bale out if we're competing with ongoing dirtyings, to avoid livelocking. For device files you really need to call into the device driver for this (-flush etc). Sure but the do_fsync() bits are part of generic_file_revoke() which is not meant for device files at all. - 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 2/5] revoke: core code
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote: Serious question - do we actually need revoke() on a normal file ? BSD has never had this, SYS5 has never had this. On 3/16/07, Pekka Enberg [EMAIL PROTECTED] wrote: It's needed for forced unmount (bits of it anyway) and partial-revocation in SLIM. And btw, you do need support for tearing down mmap for device files too, right? - 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 2/5] revoke: core code
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote: However, modifying i_size like this might be a problem - the inode could be dirty and it'll get written to disk! Perhaps we could change i_size_read() to cheat and to return zero if there's a revoke in progress. I don't think we can actually abuse i_size_read() in any sane manner because the inode needs to be usable for anyone who just did open(2) after revoke or whoever called frevoke(2). What we could do is add a I am revoked flag to struct file which blocks any future -readpage, -readpages, and -direct_IO on the file. Alternatively, we could change the -f_mapping to point to an address space that has revoked address space operations. Hmm. - 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] Re: NAK new drivers without proper power management?
On 2/11/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: Unfortunately it has to be done in one shot for all of the known good drivers to avoid user-observable regressions. No you don't. You can make it a config option that defaults to n during a transition period. - 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: somebody dropped a (warning) bomb
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote: May I suggest another definition for a warning being entirely sucks? The warning is entirely sucks if and only if it never has true positives. In all other cases it's only more or less sucks, IMHO. You're totally missing the point. False positives are not a minor annoyance, they're actively harmful as they hide other _useful_ warnings. So, you really want warnings to be about things that can and should be fixed. So you really should aim for _zero false positives_ even if you risk not detecting some real positives. - 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: somebody dropped a (warning) bomb
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote: With almost any warning out there one makes more or less efforts to suppress the warning where it gives false positives, isn't it? Yes, as long it's the _compiler_ that's doing the effort. You shouldn't need to annotate the source just to make the compiler shut up. Once the compiler starts issuing enough false positives, it's time to turn off that warning completely. Therefore, the only sane strategy for a warning is to aim for zero false positives. 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 07/21] Xen-paravirt: remove ctor for pgd cache
On 2/16/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Remove the ctor for the pgd cache. There's no point in having the cache machinery do this via an indirect call when all pgd are freed in the one place anyway. The reason we have slab constructors and destructors is to _avoid_ reinitializing every time we allocate an object. AFAICT your changing the code now to do _more_ work than before, so is there some other reason why you want to do this than avoiding an indirect call? - 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 12/44 take 2] [UBI] allocation unit implementation
On 2/17/07, Artem Bityutskiy [EMAIL PROTECTED] wrote:
+void *ubi_kzalloc(size_t size)
+{
+ void *ret;
+
+ ret = kzalloc(size, GFP_KERNEL);
+ if (unlikely(!ret)) {
+ ubi_err(cannot allocate %zd bytes, size);
+ dump_stack();
+ return NULL;
+ }
+
+ return ret;
+}
[snip, snip]
NAK. Please drop all of these utterly pointless kmalloc() and
kmem_cache_alloc() wrappers.
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: forced umount?
On 3/17/07, Mike Snitzer [EMAIL PROTECTED] wrote: Thanks for the heads up; its good to see that Pekka Enberg's work has continued. I actually stumbled onto that line of work earlier while searching for more info on Tigran Aivazian's forced unmount (badfs) patches: http://lwn.net/Articles/192632/ FYI, the revoke implementation have since been changed to follow the badfs-style approach of the forced unmount patches. However, there are some problems with the forced unmount patches that are now fixed in the revoke implementation: - You can't use munmap() to take down shared memory mappings because the application can accidentally remap something completely different to that region. - The -f_light bits slow down other fget_light() users and there's a race between fcheck_files() and set_f_light(). - The operation can live-lock if a malicious process keeps forking. The revoke implementation solves this by revoking in two passes: (1) take down the descriptors and (2) take down the actual inodes. 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: Bug in pci_restore_msi_state
On 3/17/07, Thomas Meyer [EMAIL PROTECTED] wrote: Hello everybody. I get this bug after suspending to disk twice: http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png This happens with current git head cd05a1f818073a623455a58e756c5b419fc98db9. If you know a kernel that works, please consider doing git bisect: http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt - 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.20.3: kernel BUG at mm/slab.c:597 try#2
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote: BUG_ON(!PageSlab(page)); that's seriously screwed up. Do you have CONFIG_DEBUG_SLAB enabled? If not, please enable it and retest. This is scary. Looking at disassembly of the OOPS: Disassembly of section .text: .text: 0: 5f pop%edi 1: c3 ret 2: 57 push %edi 3: 89 c1 mov%eax,%ecx 5: 89 d7 mov%edx,%edi 7: 8d 92 00 00 00 40 lea0x4000(%edx),%edx d: 56 push %esi e: c1 ea 0cshr$0xc,%edx 11: 53 push %ebx 12: c1 e2 05shl$0x5,%edx 15: 03 15 40 5d 5a c0 add0xc05a5d40,%edx At this point, edx has the result of virt_to_page(). 1b: 8b 02 mov(%edx),%eax 1d: f6 c4 40test $0x40,%ah 20: 74 03 je 0x25 If it's a compound page, look up the real page from -private. 22: 8b 52 0cmov0xc(%edx),%edx Now, reload page flags. 25: 8b 02 mov(%edx),%eax And test... 27: a8 80 test $0x80,%al 29: 75 04 jne0x2f 2b: 0f 0b ud2a 2d: eb fe jmp0x2d 2f: 39 4a 18cmp%ecx,0x18(%edx) [snip, snip] EIP is at kmem_cache_free+0x29/0x5a eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180 esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14 ds: 007b es: 007b ss: 0068 But somehow eax and edx have the same value 0xc180 here. Hmm? 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: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote: EIP is at kmem_cache_free+0x29/0x5a eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180 esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14 ds: 007b es: 007b ss: 0068 But somehow eax and edx have the same value 0xc180 here. Hmm? Aah, but if you look at contents of the stack: Stack: f0ae12c0 c1919de0 ffea c0137f97 f0ae12c0 c1919e20 c0168d45 f0ae12c0 1000 c0168fb9 c02a77e3 1000 c17bb6e0 1000 f1b38be8 0003 f54ac050 c1b9d6e8 Call Trace: [c0137f97] mempool_free+0x48/0x4c [c0168d45] bio_free+0x21/0x2c [c0168fb9] bio_put+0x22/0x23 You can see that mempool_free is passing a NULL pointer to kmem_cache_free() which doesn't handle it properly. The NULL pointer comes from bio_free() where -bi_io_vec is NULL because nr_iovecs passed to bio_alloc_bioset() was zero. The question is, why is nr_pages zero in scsi_req_map_sg()? - 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.20.3: kernel BUG at mm/slab.c:597 try#2
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote: You can see that mempool_free is passing a NULL pointer to kmem_cache_free() which doesn't handle it properly. The NULL pointer comes from bio_free() where -bi_io_vec is NULL because nr_iovecs passed to bio_alloc_bioset() was zero. The question is, why is nr_pages zero in scsi_req_map_sg()? Note that the following patch I posted only addresses the part where slab is clearly failing here: http://lkml.org/lkml/2007/3/19/42 So, while it should fix the oops, there might be a bug lurking in the SCSI or block layer still. - 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] slab: deal with NULL pointers passed to kmem_cache_free
On 3/19/2007, Andrew Morton [EMAIL PROTECTED] wrote:
Would prefer to do:
static inline void kmem_cache_free_if_not_null(struct kmem_cache *cachep,
void *objp)
{
if (objp)
kmem_cache_free(cachep, objp);
}
so that we don't add extra overhead to all the thousands of existing,
well-behaved callsites.
That bloats kernel text all the same so it's much cleaner to just make
the callers explicitly check for NULL then. That said, I'm sorry but I
just don't buy the overhead part of your argument since it's one
branch and no extra data cache pressure especially as we're already
doing the BUG_ON and page flag checking.
But, since you're NAKing my patch, we need to get the mempool for from
the original thread in to fix the oops.
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] slab: deal with NULL pointers passed to kmem_cache_free
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote: The BUG_ON (at least) should probably be moved into CONFIG_DEBUG_SLAB. No it shouldn't. Letting non-slab pages pass through causes nasty and hard to debug problems which is why we have the BUG_ONs in the first place: http://lkml.org/lkml/2006/5/8/101 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] slab: deal with NULL pointers passed to kmem_cache_free
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote: This is a super-hot path. Super-hot exactly where? - 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] slab: deal with NULL pointers passed to kmem_cache_free
On 3/21/07, Jarek Poplawski [EMAIL PROTECTED] wrote: I think Pekka was right (it looks he changed his mind now) something should be done here. I think something like this should be a minimum: BUG_ON(!objp || virt_to_cache(objp) != cachep); to show distinctly what's going on. No, if we were to add a NULL check in kmem_cache_free(), it should behave like kfree() does. Anyway, if you feel about this strongly I suspect the best solution is to add a __kmem_cache_free which does _not_ have the NULL check and convert those super-hot paths to use it. Sort of what Andrew suggested already. - 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] SLAB : [NUMA] keep nodeid in struct page instead of struct slab
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:
In order to avoid a cache miss in kmem_cache_free() on NUMA and reduce hot path
length, we could exploit the following common facts.
It would be nice if you could cc me for slab patches.
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:
-static inline void page_set_cache(struct page *page, struct kmem_cache *cache)
+static inline void page_set_cache_slab_nodeid(struct page *page,
+ struct kmem_cache *cache, struct slab *slab, int nodeid)
{
+ page-lru.prev = (struct list_head *)slab;
+#ifdef KEEP_NODEID_IN_PAGE
+ page-lru.next = (struct list_head *)((long)cache + nodeid);
+#else
page-lru.next = (struct list_head *)cache;
+#endif
+#ifdef KEEP_NODEID_IN_SLAB
+ slab-nodeid = nodeid;
+#endif
Can we please have a slab_get_nid() and slab_set_nid() instead which
reduces the need for #ifdefs?
-
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] SLAB : [NUMA] keep nodeid in struct page instead of struct slab
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote: +#ifdef KEEP_NODEID_IN_PAGE + /* kmem_cache addresses must be multiple of 64 */ + cache_cache.buffer_size = ALIGN(cache_cache.buffer_size, + max(64, cache_line_size())); +#else cache_cache.buffer_size = ALIGN(cache_cache.buffer_size, cache_line_size()); +#endif Please introduce cache_cache_align() to hide the #ifdeffing. - 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] SLAB : Use num_possible_cpus() in enable_cpucache()
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote: As most shiped linux kernels are now compiled with CONFIG_SMP, there is no way a preprocessor #if can detect if the machine is UP or SMP. Better to use num_possible_cpus(). Looks good to me. Acked-by: Pekka Enberg [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] SLAB : Dont allocate empty shared caches
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote: We can avoid allocating empty shared caches and avoid unecessary check of cache-limit. We save some memory. We avoid bringing into CPU cache unecessary cache lines. All accesses to l3-shared are already checking NULL pointers so this patch is safe. Looks good to me. Acked-by: Pekka Enberg [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] slab: deal with NULL pointers passed to kmem_cache_free
On 3/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: IMHO one way to find them is to actually slow down kmem_cache_free() and see where the performance is hurt. Yeah, I'll try to sneak a patch past Andrew. - 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] SLAB : [NUMA] keep nodeid in struct page instead of struct slab
On 3/21/07, Christoph Lameter [EMAIL PROTECTED] wrote: None of that please. The page flags already contain a node number that is accessible via page_to_nid(). Just make sure that we never put a slab onto the wrong node. Sounds good. Do you know for a fact that we don't or are you just afraid we have a bug? - 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] SLAB : [NUMA] keep nodeid in struct page instead of struct slab
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Last time I checked 'struct page', they was no nodeid in it.
Hmm, page_to_nid() in include/linx/mm.h doesn't agree with you:
#ifdef NODE_NOT_IN_PAGE_FLAGS
extern int page_to_nid(struct page *page);
#else
static inline int page_to_nid(struct page *page)
{
return (page-flags NODES_PGSHIFT) NODES_MASK;
}
#endif
-
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] SLAB : [NUMA] keep nodeid in struct page instead of struct slab
On 3/21/2007, Andi Kleen [EMAIL PROTECTED] wrote: You can always use numa emulation on x86-64. Boot with numa=fake=NODES Yes, I know, but I don't have a x86-64 box either =) - 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] slab: deal with NULL pointers passed to kmem_cache_free
On 3/21/2007, Andrew Morton [EMAIL PROTECTED] wrote: Thing is, such a patch would amount to adding a test-for-NULL to codepaths which we *know* do not need it. There is no point in doing that. Now you're just being stubborn, Andrew ;-). The extra check does not matter much at all for most cases. What it buys us is consistent API with kfree(), more robust slab, and less bugs, no? All the super-hot paths can be fixed with __kmem_cache_free(). As an added bonus, we can remove all extra debugging checks when CONFIG_SLAB_DEBUG is disabled from __kmem_cache_free() as it will be only used in tested, known good code paths so performance for those cases will be even better! So I'll whoop up a patch soonish and send it to you. Perhaps your evil twin will apply it. - 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] NUMA : could we introduce virt_to_nid() ?
On 3/23/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Checking Christoph quicklist implementation, I found the same cache miss in
free() than SLAB has.
/* common implementation *
int virt_to_nid(const void *addr)
{
struct page *page = virt_to_page(addr);
return page_to_nid(page);
}
On some platforms (x86_64 for example), could we have a better implementation,
not accessing struct page, but using phys_to_nid() ?
Sounds good to me. At least cache_free_alien() in mm/slab.c to should
be converted to use it.
-
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: [-mm patch] fs/revoke.c: cleanups (and bugfix for 64bit systems)
On 3/24/07, Adrian Bunk [EMAIL PROTECTED] wrote: This patch contains the following: - every file should #include the headers containing the prototypes for it's global functions - fix the wrong return value of sys_frevoke() gcc was now able to detect - make 2 needlessly global structs static Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Looks good. Thanks! Acked-by: Pekka Enberg [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: kmem_cache_create loop for find the proper gfporder
On 3/25/07, Bin Chen [EMAIL PROTECTED] wrote: It is done by increase gfporder for low number to high(possibly 0 to MAX_GFP_ORDER). But why increase the gfporder(or slab size) can decrease the internal fragmentation?) A simple example, suppose the slab management stuff is kept off-slab, if the gfporder is zero, and the object size in slab is 1000, the wasted space is 4096 mod 1000 = 96, but with 4096 * 2(increase gfporder by 1), the space is 8192 mod 1000 = 192, 192 96. You didn't simulate the algorithm long enough. If you had, you'd hit order five which wastes only 72 bytes in your example. 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: Reiser4. BEST FILESYSTEM EVER.
On 4/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I checked what bonnie++ actually writes to its test files, for you. It is about 98-99% zeros. Still, the results record sequential reads, of 232,729 K/sec, nearly four times the physical disk read rate, 63,160 K/sec, of the hard drive. Excellent! You've established the undeniable hard cold fact that reiser4 beats the crap out of all other filesystems, when the files are 98-99% filled with zeros. You've proven your point, so can we stop this thread now? - 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: REISER4 FOR INCLUSION IN THE LINUX KERNEL.
On 4/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: YOU GUYS WILL LAUGH ABOUT THIS: No, I am crying actually. Dear post-masters, can we have this thread shit-canned, please? - 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] lguest: the block driver
Hi Rusty,
On 4/10/07, Rusty Russell [EMAIL PROTECTED] wrote:
+/* Jens gave me this nice helper to end all chunks of a request. */
+static void end_entire_request(struct request *req, int uptodate)
+{
+ if (end_that_request_first(req, uptodate, req-hard_nr_sectors))
+ BUG();
+ add_disk_randomness(req-rq_disk);
+ blkdev_dequeue_request(req);
+ end_that_request_last(req, uptodate);
+}
Perhaps we should move this to generic code (i.e. block/ll_rw_blk.c)?
-
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] lguest: the block driver
On 4/10/07, Rusty Russell [EMAIL PROTECTED] wrote:
+/* Jens gave me this nice helper to end all chunks of a request. */
+static void end_entire_request(struct request *req, int uptodate)
+{
+ if (end_that_request_first(req, uptodate, req-hard_nr_sectors))
+ BUG();
+ add_disk_randomness(req-rq_disk);
+ blkdev_dequeue_request(req);
+ end_that_request_last(req, uptodate);
+}
On 4/10/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Perhaps we should move this to generic code (i.e. block/ll_rw_blk.c)?
Uhm, I am bit confused now. Why don't you just use end_request() here?
-
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] lguest: the block driver
On 4/11/07, Rusty Russell [EMAIL PROTECTED] wrote: What a question! end_request() doesn't end a request! What a crazy idea! Aah, indeed, end_request() uses req-hard_cur_sectors while end_entire_request() uses req-hard_nr_sectors which I missed. On 4/11/07, Rusty Russell [EMAIL PROTECTED] wrote: Hope that clarifies! It does. Thanks Rusty :) 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: Why kmem_cache_free occupy CPU for more than 10 seconds?
On 4/11/07, Zhao Forrest [EMAIL PROTECTED] wrote: We're using RHEL5 with kernel version 2.6.18-8.el5. When doing a stress test on raw device for about 3-4 hours, we found the soft lockup message in dmesg. I know we're not reporting the bug on the latest kernel, but does any expert know if this is the known issue in old kernel? Or why kmem_cache_free occupy CPU for more than 10 seconds? Sounds like slab corruption. CONFIG_DEBUG_SLAB should tell you more. - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On 4/15/07, hui Bill Huey [EMAIL PROTECTED] wrote: The perception here is that there is that there is this expectation that sections of the Linux kernel are intentionally churn squated to prevent any other ideas from creeping in other than of the owner of that subsytem Strangely enough, my perception is that Ingo is simply trying to address the issues Mike's testing discovered in RDSL and SD. It's not surprising Ingo made it a separate patch set as Con has repeatedly stated that the problems are in fact by design and won't be fixed. - 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: [-mm patch] UNION_FS must depend on SLAB
On 2/20/07, Adrian Bunk [EMAIL PROTECTED] wrote: CC fs/unionfs/copyup.o /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In function 'create_parents_named': /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error: 'malloc_sizes' undeclared (first use in this function) /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error: (Each undeclared identifier is reported only once /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error: for each function it appears in.) make[3]: *** [fs/unionfs/copyup.o] Error 1 Hmm, why is unionfs playing around with malloc_sizes in the first place? Jeff? - 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/3] slab: introduce krealloc
On 2/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote: please mark this one __must_check.. not storing realloc() return values is one of the more nasty types of bugs... but gcc can help us greatly here ;) So I guess we want the same thing for the other allocator functions (__kmalloc et al) as well? - 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/3] slab: introduce krealloc
Christoph Lameter wrote: Well could you check ksize for the old object first and if ksize = new size then just skip the copy? I think this may allow you to get rid of the ksize callers. And not reallocate at all, right? I thought about that but then you wouldn't be able to use realloc() to make the buffer smaller. 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] slab: ensure cache_alloc_refill terminates
On Wed, 21 Feb 2007, Pekka J Enberg wrote:
+ */
+ BUG_ON(slabp-inuse 0 || slabp-inuse = cachep-num);
+
while (slabp-inuse cachep-num batchcount--) {
On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote:
I think you only need to check for 0. If slabp-inuse cachep-num then
the loop will not be taken.
...and batchcount is not decremented and we're effectively in an
infinite loop. Or am I missing something here?
-
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/3] slab: introduce krealloc
Hi Christoph, Christoph Lameter wrote: 1. Just do not allow shrinking via realloc. Probably no big loss and best performance. Not a big loss if you can afford the wasted memory. But, I don't think we should do this, there's no way for the caller to know that we will hold on to the memory indefinitely. Christoph Lameter wrote: 2. Check if the size specified is larger than the next smallest general cache and only copy if we would really would allocate from a different cache. Yeah, I was thinking about this too but decided against it (for now) as I am mostly concerned with removing the slab abuses from unionfs. Also, it is not immediately obvious we want to do this for all cases of krealloc so I'd prefer to keep the API for a while and decide to optimize or not optimize later. Note that we would only get rid of one of the kfree callers, the other one doesn't want to do krealloc(), it never reuses the old values. 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 1/3] slab: introduce krealloc
On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote: Why not? Its a realloc call and these are the classic semantics of realloc. Otherwise realloc will always move the memory. Well, as a reference, the user-space equivalent is defined in SUSv3 as: The realloc() function shall change the size of the memory object pointed to by ptr to the size specified by size. I think it is reasonable to expect krealloc() to not waste too much space if I, say, reallocate a 128 byte buffer to 32 bytes. On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote: Check that both sizes fall into the same general cache. Do the following at the beginning of the function Not available in the slob allocator AFAIK but yeah, I'll add this optimization to the slab version. Thanks Christoph. 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: [-mm patch] UNION_FS must depend on SLAB
Hi Andrew, Andrew Morton wrote: Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. I think we can merge krealloc without unionfs. I'll whoop up a new patch as per Christoph's suggestions. I think at least XFS already has its own realloc and there might be some other open-coded users. It's not _changing_ the slab as much as adding new functionality that makes sense fron a general point of view. The ksize exports we can add later if unionfs is to be merged. 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: [-mm patch] UNION_FS must depend on SLAB
Pekka Enberg wrote: The ksize exports we can add later if unionfs is to be merged. Actually, we probably don't need it after the krealloc optimizations. I think we need a new unionfs patch too... :) 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: SLUB: The unqueued Slab allocator
Hi Christoph, On 2/22/07, Christoph Lameter [EMAIL PROTECTED] wrote: This is a new slab allocator which was motivated by the complexity of the existing code in mm/slab.c. It attempts to address a variety of concerns with the existing implementation. So do you want to add a new allocator or replace slab? On 2/22/07, Christoph Lameter [EMAIL PROTECTED] wrote: B. Storage overhead of object queues Does this make sense for non-NUMA too? If not, can we disable the queues for NUMA in current slab? On 2/22/07, Christoph Lameter [EMAIL PROTECTED] wrote: C. SLAB metadata overhead Can be done for the current slab code too, no? 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 02/29] mm: slab allocation fairness
On 2/21/07, Peter Zijlstra [EMAIL PROTECTED] wrote: [AIM9 results go here] Yes please. I would really like to know what we gain by making the slab even more complex. - 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 08/29] mm: kmem_cache_objs_to_pages()
Hi Peter, On 2/21/07, Peter Zijlstra [EMAIL PROTECTED] wrote: Provide a method to calculate the number of pages needed to store a given number of slab objects (upper bound when considering possible partial and free slabs). So how does this work? You ask the slab allocator how many pages you need for a given number of objects and then those pages are available to it via the page allocator? Can other users also dip into those reserves? I would prefer we simply have an API for telling the slab allocator to keep certain number of pages in a reserve for a cache rather than exposing internals such as object size to rest of the world. 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 08/29] mm: kmem_cache_objs_to_pages()
Hi Peter, On Wed, 2007-02-21 at 17:47 +0200, Pekka Enberg wrote: So how does this work? You ask the slab allocator how many pages you need for a given number of objects and then those pages are available to it via the page allocator? Can other users also dip into those reserves? On 2/22/07, Peter Zijlstra [EMAIL PROTECTED] wrote: Everybody (ab)using PF_MEMALLOC or the new __GFP_EMERGENCY. So you are only interested in rough estimation of how much many pages you need for a given amount of objects? Why not use ksize() for that then? 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 08/29] mm: kmem_cache_objs_to_pages()
On 2/22/07, Pekka Enberg [EMAIL PROTECTED] wrote: So you are only interested in rough estimation of how much many pages you need for a given amount of objects? Why not use ksize() for that then? Uhm, I obviously meant, why not expose obj_size() instead. - 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] revokeat/frevoke system calls V5
Hi Alan, On 2/26/07, Alan [EMAIL PROTECTED] wrote: Whats the status on this, I was suprised to see something so important just go dead ? It's not dead. You can find the latest patches here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/ and user-space tests here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/utils/ What they are lacking is review so I am not sure how to proceed with the patches. 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: [BUG] Linux 2.6.20.1 - unable to handle kernel paging request - accessing freed memory?
Hi, On 2/26/07, Chris Rankin [EMAIL PROTECTED] wrote: BUG: unable to handle kernel paging request at virtual address 6b6b6ceb [snip] EIP is at module_put+0x20/0x52 eax: 6b6b6ceb ebx: 6b6b6b6b ecx: 0001 edx: e5bf esi: e9040b08 edi: 6b6b6b6b ebp: eae0bb3c esp: e5bf0f58 ds: 007b es: 007b ss: 0068 Process udevd (pid: 18662, ti=e5bf task=e6aaa030 task.ti=e5bf) Stack: eb3ff7bc c01839fe 0010 ed009b7c ed9291d0 c015124b f7ff2208 ed009b7c f7bd0678 ed009b7c c014ed88 0003 0003 f7bd0678 f7bd06f8 c014fd81 0003 0007 0003 e5bf c0102bce Call Trace: [c01839fe] sysfs_release+0x2d/0x4c [c015124b] __fput+0x96/0x13c So udevd is closing a sysfs attribute file but the pointer passed to module_put is bogus. Looks like the sysfs dentry was already taken down by release_sysfs_dirent(). Can you reproduce this at will? Does the oops happen in older kernels? 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: [Alsa-devel] [BUG] Linux 2.6.20.1 - unable to handle kernel paging request - accessing freed memory?
On 2/27/07, Chris Rankin [EMAIL PROTECTED] wrote: Hmm, this bug looks interesting: http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/0514.html Yes, my machine *is* a dual P4 with HT enabled... Yeah, but the oops looks more like a reference counting problem with sysfs dentries. No harm in trying out the patch or reproducing without CONFIG_SCHED_SMT though. - 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 2/2] revoke: break cow for private mappings
On 3/28/07, Nick Piggin [EMAIL PROTECTED] wrote: + ret = get_user_pages(tsk, tsk-mm, vma-vm_start, + vma-vm_end-vma-vm_start, 1, 1, NULL, + NULL); get_user_pages length argument is in # of pages, rather than address range, I think. vma_pages is what you want? Yes. On 3/28/07, Nick Piggin [EMAIL PROTECTED] wrote: + up_write(mm-mmap_sem); I think you just need down_read of mmap_sem here? Indeed. Thanks Nick. 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: [QUESTION] check for mem in slab
On 3/30/07, Heiko Carstens [EMAIL PROTECTED] wrote:
in file mm/slab.c and routine kmem_cache_init() I found there
is no checking for allocated memory on line:
/* 4) Replace the bootstrap head arrays */
{
struct array_cache *ptr;
ptr = kmalloc(sizeof(struct arraycache_init), GFP_KERNEL);
-- no check for ptr == NULL --
[...]
is that OK? or it's a bug?
It's ok. If that allocation fails your machine won't come up anyway.
We ought to add a BUG_ON or comment at least there as this keeps
popping up again and again.
-
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: [powerpc] RS/6000 43p-150 no longer boots as of 2.6.18
Hi Peter, On 3/31/07, Peter Samuelson [EMAIL PROTECTED] wrote: ...and here it hangs. This happened between 2.6.17-git21 and -git22. .config is attached. I'd be happy to test patches and provide more information. You could try git bisect to find the exact commit that broke your kernel: http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt - 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: mcdx -- do_request(): non-read command to cd!!
On 3/31/07, Rene Herman [EMAIL PROTECTED] wrote: There's quite a bit of noise in dmesg though. Repeated 5 times: ===BUG: scheduling while atomic: mount/0x0001/1166 [c1170bff] __sched_text_start+0x57/0x574 [c1171964] schedule_timeout+0x70/0x8f [c10199b2] process_timeout+0x0/0x5 [c11716a2] interruptible_sleep_on_timeout+0x5d/0xa5 [c100e695] default_wake_function+0x0/0xc [c482b8fb] mcdx_xfer+0xae/0x2a5 [mcdx] [snip] [c482b473] do_mcdx_request+0x9b/0xd2 [mcdx] [c1096d06] __generic_unplug_device+0x1d/0x1f [c1096d19] generic_unplug_device+0x11/0x29 Looks like mcdx_xfer is sleeping while holding q-queue_lock. The attached (untested) patch should fix it. mcdx-drop-queue_lock-before-sleeping Description: Binary data
Re: mcdx -- do_request(): non-read command to cd!!
On 4/1/07, Pekka Enberg [EMAIL PROTECTED] wrote: Looks like mcdx_xfer is sleeping while holding q-queue_lock. The attached (untested) patch should fix it. You also need to add a spin_lock_irq() before the call to end_request() to Jens' patch. - 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: usb hid: reset NumLock
On 3/30/07, Pete Zaitcev [EMAIL PROTECTED] wrote: Dell people (Stuart and Charles) complained that on some USB keyboards, if BIOS enables NumLock, it stays on even after Linux has started. Since we always start with NumLock off, this confuses users. Quick double dab at NumLock fixes it, but it's not nice. What I am seeing on my Thinkpad is that when I boot _without_ an USB keyboard NumLock is enabled. Switching to virtual console and back to X fixes it which is why I have never bothered to debug it further. Perhaps this is related? Should I give your patch a spin to see if it fixes the problem? - 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: mcdx -- do_request(): non-read command to cd!!
Hi Rene, On 4/2/07, Rene Herman [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~# dd if=/dev/mcdx0 of=/dev/null bs=2048 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000221955 seconds, 0.0 kB/s [EMAIL PROTECTED]:~# This I know isn't: [EMAIL PROTECTED]:~# readcd dev=/dev/mcdx0 f=/dev/null Segmentation fault [EMAIL PROTECTED]:~# (leaves a note: readcd[1174] exited with preempt_count 1 in the log) and after a mount -t iso9660 /dev/mcdx0 /mnt/cdrom, a: [EMAIL PROTECTED]:~# tar cv /mnt/cdrom /dev/null has upto now done all of: [snip] Try with CONFIG_PREEMPT_NONE as suggested by Jens. Can we see strace for the dd, readcd, and tar runs, please? - 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: mcdx -- do_request(): non-read command to cd!!
On 4/4/07, Rene Herman [EMAIL PROTECTED] wrote:
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Can you get anything out with sysrq-t? The original oops would be
enough to conclude it's a double-free if it weren't for this:
if (stuffp-toc) {
kfree(stuffp-toc);
stuffp-toc = NULL;
}
While the code is obviously unsafe, we would have to be interrupted
between the read and the assignment, but you don't even have preempt
enabled! So I don't quite yet see where the concurrency is coming
from.
What you can do here is protect the above sequence with a spinlock,
for example, which might paper-over the double-free enough to get you
running again...
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: New linux arch
Hi Michael, On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL PROTECTED] wrote: Is it possible to create git repository in git.kernel.org for Microblaze cpu? You need to ask the kernel.org administrators for that: http://www.kernel.org/faq/#account On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL PROTECTED] wrote: What are maintainers responsibilities? Do you have any page about? I am U-BOOT maintainer at denx.de and I hope that the responsibilities will be similar. How many maintainers are acceptable? (one or more) You can have as many maintainers as you want but you probably don't want to make it too many. There aren't any official responsibilities as a maintainer, it really depends on how much time and effort you're willing to put in. On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL PROTECTED] wrote: I see the right way to push all changes to public git repository and then send patches in small logical group to LKML with CC to people from microblaze community. And then wait for comments from you, solve problems, update git repository and send changes again. You don't necessarily need a public git repository before sending your patches to LKML but yeah, you definitely want some public exposure before asking for Linus/Andrew to merge your port. 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: New linux arch
Hi Michal, On Jan 7, 2008 3:00 PM, Michal Simek [EMAIL PROTECTED] wrote: You can have as many maintainers as you want but you probably don't want to make it too many. There aren't any official responsibilities as a maintainer, it really depends on how much time and effort you're willing to put in. OK. Don't you have idea how many linux kernels are maintained by more people? Well, just look up some mainstream architectures in MAINTAINERS. The x86 architecture, for example, has three but the point here is that you probably don't want to end up with ten individual maintainers (how are you going to coordinate the work?) whereas more than one is definitely okay. If you have a lot of people maintaining your port, then just create a mailing list and put that in MAINTAINERS with only few top maintainers listed by their individual email to make life easy for patch submitters. 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: New linux arch
Hi Bryan, On Jan 8, 2008 10:28 AM, Bryan Wu [EMAIL PROTECTED] wrote: 1. Push patches to LKML when merge window open (2 weeks after a stable kernel version release, for example 2 weeks after 2.6.24 released) You shouldn't wait for the merge window to open to send patches for review for the first time; otherwise you'll just miss the opportunity to merge ;-). 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: slab quirks in DEBUG, ctor, and initialization
Hi John, On Dec 17, 2007 5:47 PM, John Reiser [EMAIL PROTECTED] wrote: In mm/slab.c, the DEBUG variant of cache_alloc_debugcheck_after might call cachep-ctor(objp, cachep, 0); but the non-DEBUG variant does absolutely nothing. idr_pre_get is a routine which notices the difference. How does ipr_pre_get notice this? On Dec 17, 2007 5:47 PM, John Reiser [EMAIL PROTECTED] wrote: Even when cache_alloc_debugcheck_after does invoke the ctor, then it is conditional upon cachep-flags SLAB_POISON. This assumes that the only two states are poisoned and all-zero (from .bss static, or via a cleared new page frame.) So if SLAB_POISON is not specified, then a ctor which does anything other than memset(,0,) is out of luck. Instead: if a ctor is specified then it should be called for each successful allocation. Sorry, I don't understand at all what's the problem is here. For the common (non-poison) case, we initialize all objects *once* whenever a cache is grown (see cache_grow calling cache_init_objs) which is the whole point of having constructors. When poisoning is enabled, we obviously cannot do this which is why we call the constructor for every allocation. 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
Hi, On Dec 20, 2007 4:38 PM, David Newall [EMAIL PROTECTED] wrote: and another one, this time tainted with the nvidia module: 5194.130985] Unable to handle kernel paging request at 0300 RIP: Numbers like that don't suggest hardware faults. All those zeros: It's far too round. Sounds very like software. In fact, it sounds like the start of significant hardware region. Nah, it's just that vma-anon_vma is probably supposed to be NULL here. And if you look at all the oopses, they do suggest one particular byte lane is dodgy (the corruption is in bits 41-43 and 45). The whole thing reminds me of another bug where memtest86 didn't find anything because it's doing cached memory accesses: http://lkml.org/lkml/2007/10/3/259 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: Major regression on hackbench with SLUB (more numbers)
Hi, Christoph Lameter [EMAIL PROTECTED] wrote: In an extreme case (boot with slub_min_order=9 to get huge page sized slabs) SLUB can win against SLAB: N=10 Time: 0.338 Minimally faster N=20 Time: 0.560 10% faster N=50 Time: 1.353 15% faster On Dec 21, 2007 2:09 PM, Ingo Molnar [EMAIL PROTECTED] wrote: what's up with this regression? There's been absolutely no activity about it in the last 8 days: upstream still regresses, -mm still regresses and there are no patches posted for testing. Christoph, did you see Steven's oprofile results for the hackbench runs (http://lkml.org/lkml/2007/12/8/198)? Any ideas why we're hitting add_partial like crazy? 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: Major regression on hackbench with SLUB (more numbers)
Hi, On Dec 22, 2007 1:17 AM, Ingo Molnar [EMAIL PROTECTED] wrote: yep, and i ran a quick comparison test on a 2-core box with 3 kernels: [ best of 5 runs in a row which had a relative jitter of less than 10% ] MIN v2.6.24.slab v2.6.24.slub v2.6.24.slub.fix -- mmap:429.00402.00 ( -6%)385.00 (-10%) select: 11.38 10.46 ( -8%) 11.41 ( 0%) proc-exec:121.52116.77 ( -3%)120.77 ( 0%) proc-fork:106.84106.19 ( 0%)107.92 ( 1%) syscall-open: 3.09 3.13 ( 1%) 3.25 ( 4%) hackbench-50: 2.85 3.47 ( 21%) 2.88 ( 1%) and the regression seems to be largely fixed! Not only is the hackbench one fixed, but mmap shows an above-noise improvement as well. Acked-by: Ingo Molnar [EMAIL PROTECTED] I thought it might be a bug but couldn't figure it out. The patch looks good to me too, Christoph. Reviewed-by: Pekka Enberg [EMAIL PROTECTED] On Dec 22, 2007 1:17 AM, Ingo Molnar [EMAIL PROTECTED] wrote: And i hereby nominate Pekka as SLUB/SLAB co-maintainer and spokesperson ;-) Heh, thanks, but grep me from MAINTAINERS some day, Ingo :-). 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] SC26XX: New serial driver for SC2681 uarts
Hi Thomas, On Dec 5, 2007 11:25 AM, Thomas Bogendoerfer [EMAIL PROTECTED] wrote: These: +#define READ_SC(p, r)readb((p)-membase + RD_##r) +#define WRITE_SC(p, r, v)writeb((v), (p)-membase + WR_##r) and these: +#define READ_SC_PORT(p, r) read_sc_port(p, RD_PORT_##r) +#define WRITE_SC_PORT(p, r, v) write_sc_port(p, WR_PORT_##r, v) really don't need to exist. All they do is make the code harder to read. but they make the code safer. The chip has common register and port registers, which are randomly splattered over the address range. And some of them are read only, some write only. Read only and Write only register live at the same register offset and their function usually doesn't have anything in common. By using these macros I'll get compile errors when doing a READ_SC from a write only register and vice versa. I will also get compile errors, if I try to access a common register via READ_SC_PORT/WRITE_SC_PORT. You can use grep to make sure there are no reads to a write-only register. What you have there is not safety but macro obfuscation at its best. It makes the code harder to read for anyone not intimately familiar with the driver. -- 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: Major regression on hackbench with SLUB (more numbers)
Hi, On Dec 22, 2007 2:37 PM, Andi Kleen [EMAIL PROTECTED] wrote: Removing an interface that exposes lots of internal details when you rewrite the subsystem and those internal details all change seems like a good reason to me. Yeah but then again removing an interface that has been around for ever is a real PITA for users. Besides, emulating /proc/slabinfo ain't so bad: http://lkml.org/lkml/2007/12/22/58 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: Major regression on hackbench with SLUB (more numbers)
Hi Andi, On Dec 22, 2007 2:54 PM, Andi Kleen [EMAIL PROTECTED] wrote: Yeah but then again removing an interface that has been around for ever Version 2.1 hasn't been around forever and at least slabtop does not work over version number changes in my experience. True but the default user-visible ABI (the one without statistics) is unchanged since version 2.0: http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=7ee832030b3a5d3a87f8f85b1fc773be15e98608 http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=e79fbf181ba738ca410f2c457ced220b738e8856 But anyway, I don't care too much either way so I'll just let Andrew sort this out, as usual. 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] slub: /proc/slabinfo ABI compatibility
Hi Ingo, On Dec 22, 2007 3:14 PM, Ingo Molnar [EMAIL PROTECTED] wrote: Also please apply the cleanup patch below, it fixes 34 checkpatch errors and warnings in mm/slub.c. Those are already fixed in -mm: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/broken-out/slub-fix-coding-style-violations.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/broken-out/slub-fix-coding-style-violations-checkpatch-fixes.patch 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] slub: /proc/slabinfo ABI compatibility
Hi Ingo, On Dec 22, 2007 3:37 PM, Ingo Molnar [EMAIL PROTECTED] wrote: Pekka, i stuck your patch into the x86.git random-test-grid, and it found the following build error after a few iterations: mm/slub.c: In function 's_show': mm/slub.c:4188: error: implicit declaration of function 'count_partial' Looks good. Thanks! Reviewed-by: Pekka Enberg [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] slub: /proc/slabinfo ABI compatibility
Hi Ingo, On Dec 22, 2007 3:40 PM, Ingo Molnar [EMAIL PROTECTED] wrote: ah, didnt see that. Could you pick up bits of my patch because it seems to do a better job, such as proper c99 initializer: [snip] also, my patch fixes all the warnings as well, not just the errors. So please give it a second look ;-) Sure, I'm fine with that. Can you Andrew please drop mine and use Ingo's instead? Acked-by: Pekka Enberg [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: [BUG 2.6.24-rc3-git6] SLUB's ksize() fails for size 2048.
Hi Vegard, On 12/2/07, Vegard Nossum [EMAIL PROTECTED] wrote: diff --git a/mm/slub.c b/mm/slub.c index 9acb413..b9f37cb 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2558,8 +2558,12 @@ size_t ksize(const void *object) if (unlikely(object == ZERO_SIZE_PTR)) return 0; - page = get_object_page(object); + page = virt_to_head_page(object); BUG_ON(!page); + + if (unlikely(!PageSlab(page))) + return PAGE_SIZE compound_order(page); + s = page-slab; BUG_ON(!s); Looks good to me. Reviewed-by: Pekka Enberg [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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
Hi, On Mon, Dec 03, 2007 at 12:59:00PM +0100, Ingo Molnar wrote: audit thousands of callsites in 8 million lines of code first is a nice euphemism for hiding from the blame forever. We had 10 years for it On Dec 3, 2007 2:13 PM, Andi Kleen [EMAIL PROTECTED] wrote: Ok your approach is then to let's warn about it and hope it will go away It's more like lets warn about it and fix the problems when we find some. Btw, how is this different from how the lockdep patches went in? 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] Add EXPORT_SYMBOL(ksize);
Hi, On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote: We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and we can know it 2.6 era. But are we going back to 2.4 era for out-of-tree kernel modules? On Dec 3, 2007 3:57 PM, Adrian Bunk [EMAIL PROTECTED] wrote: The interesting fact is that there are zero in-kernel modules using it. Yeah, and now that we have krealloc() I don't expect that many callers actually need ksize() either. 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] pktcdvd : add kobject_put when kobject register fails
Hi Dave,
On Dec 4, 2007 3:31 AM, Dave Young [EMAIL PROTECTED] wrote:
Kobject_put should be called when kobject register functioin fails, so the
the kobj ref count touch zero and then the proper cleanup routines will be
called.
[snip]
diff -upr linux/drivers/block/pktcdvd.c linux.new/drivers/block/pktcdvd.c
--- linux/drivers/block/pktcdvd.c 2007-11-30 13:13:44.0 +0800
+++ linux.new/drivers/block/pktcdvd.c 2007-11-30 13:24:08.0 +0800
@@ -117,8 +117,10 @@ static struct pktcdvd_kobj* pkt_kobj_cre
p-kobj.parent = parent;
p-kobj.ktype = ktype;
p-pd = pd;
- if (kobject_register(p-kobj) != 0)
+ if (kobject_register(p-kobj) != 0) {
+ kobject_put(p-kobj);
return NULL;
This looks wrong to me. AFAICT the only thing that can fail
kobject_register() is kobject_add() and it cleans up after itself. Am
I missing something here?
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/
[PROBLEM] uml doesn't compile on i386
Hi, Current git head doesn't compile. Looks like fall-out from the x86 merge? [EMAIL PROTECTED]:~/src/linux/uml-2.6$ make ARCH=um SYMLINK arch/um/include/kern_constants.h SYMLINK arch/um/include/sysdep make[1]: `arch/um/sys-i386/user-offsets.s' is up to date. CHK arch/um/include/user_constants.h CHK include/linux/version.h CHK include/linux/utsrelease.h CC arch/um/kernel/asm-offsets.s In file included from include/asm/arch/atomic.h:2, from include/asm/atomic.h:9, from include/linux/spinlock.h:333, from include/linux/seqlock.h:29, from include/linux/time.h:8, from include/linux/timex.h:57, from include/linux/sched.h:53, from arch/um/include/sysdep/kernel-offsets.h:2, from arch/um/kernel/asm-offsets.c:1: include/asm/arch/atomic_32.h: In function 'atomic_add_unless': include/asm/arch/atomic_32.h:237: error: 'struct cpuinfo_um' has no member named 'x86' In file included from include/asm/rwsem.h:4, from include/linux/rwsem.h:24, from include/linux/mm_types.h:11, from include/linux/sched.h:60, from arch/um/include/sysdep/kernel-offsets.h:2, from arch/um/kernel/asm-offsets.c:1: include/asm/arch/rwsem.h: In function '__down_write_trylock': include/asm/arch/rwsem.h:165: error: 'struct cpuinfo_um' has no member named 'x86' make[1]: *** [arch/um/kernel/asm-offsets.s] Error 1 make: *** [prepare0] Error 2 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: [PROBLEM] uml doesn't compile on i386
Hi, On Fri, Nov 23, 2007 at 10:52:06AM +0200, Pekka Enberg wrote: Current git head doesn't compile. Looks like fall-out from the x86 merge? On Nov 23, 2007 12:13 PM, WANG Cong [EMAIL PROTECTED] wrote: Hmm, I believe this patch[1] from Jeff can solve the problem. ;-) [1] http://lkml.org/lkml/2007/11/19/220 Thanks! Jeff, can we get this into mainline, please? - 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/
