fault.
kfree can handle a ZERO_SIZE_PTR in the same way as NULL.
FWIW, I am happy :-). We should add a comment to kmalloc() that we
return non-unique pointers for zero-length allocations though.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
Rene Herman wrote:
If I'd have a few small children around I'd show them the word
ZERO_SIZE_PTR and make pictures of them bursting out in tears.
I strongly recommend against it, linux/mm/*.c is for adults only.
Pekka
-
To unsubscribe from this list: send the line
before sending to Andrew.
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
Hi Cyrill,
On 5/23/07, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
@@ -2103,7 +1944,7 @@ long udf_block_map(struct inode *inode, sector_t block)
kernel_lb_addr eloc;
uint32_t elen;
sector_t offset;
- struct extent_position epos = { NULL, 0, { 0, 0}};
+ struct
On 5/24/07, Randy Dunlap [EMAIL PROTECTED] wrote:
but Lindent needs some hand-holding / eyeball help as well...
That's true but the point remains: it would be better to have
whitespace-only fixes first. But if Andrew is willing to eat Cyrill's
patch as-is, I have no real objections either...
-
Cyrill Gorcunov wrote:
And Pekka the patch I sent will be remaked anyway after some fixes. So
if you don't like the conversion you pointed - just let me know and
I'll not do that ;)
I would prefer whitespace-only first because it's easier to review. But
perhaps I am being overly paranoid
Hi Jean,
On 5/25/07, Jean Delvare [EMAIL PROTECTED] wrote:
- ltp = (struct ktermios *) kmalloc(sizeof(struct ktermios),
+ ltp = (struct ktermios *) kzalloc(sizeof(struct ktermios),
GFP_KERNEL);
When doing conversions
On 5/27/07, Kok, Auke [EMAIL PROTECTED] wrote:
that piece is a copy of mm/slab.c, and all over the core components of the
kernel (even fs/inode.c written by Linus). I strongly think that == NULL
doesn't add anything and that well-written functions and well-named variables
really do not need the
On 5/28/07, young dave [EMAIL PROTECTED] wrote:
Remove useless tolower in isofs
[snip]
c = tolower(*name++);
- hash = partial_name_hash(tolower(c), hash);
+ hash = partial_name_hash(c, hash);
Looks good to me.
Acked-by: Pekka Enberg [EMAIL
Hi Tero,
(I am cc'ing Alan as he's been working on tty code recently.)
On 5/27/07, Tero Roponen [EMAIL PROTECTED] wrote:
2.6.22-rc3 (with Reiser4 patch) oopses when watching videos with
mplayer using neofb console.
[snip]
Ok, everything seems to work and I can watch the video.
However,
On 5/28/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Can we have your .config please? Also, could you work out the file and
line number of vt_ioctl+0xda8/0x1482 like this:
gdb vmlinux
(gdb) l *0xc021e50e
Btw, this only works if you have CONFIG_DEBUG_INFO set. In case it
wasn't, please do
On 5/28/07, Pekka Enberg [EMAIL PROTECTED] wrote:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0731
EIP is at vt_ioctl+0xda8/0x1482
[snip]
On 5/28/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Call Trace:
[c0149fd9] link_path_walk+0xa5/0xaf
On 5/28/07, young dave [EMAIL PROTECTED] wrote:
Thanks, can this small fix be merged?
Yes. Please be patient and wait for Andrew to pick it 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
On 5/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[4294667.472000] BUG: at mm/slab.c:777 __find_general_cachep()
[snip]
Any suggestions before I go doing the bisect shuffle?
It's complaining about a kmalloc() with size zero. The warning is new
and harmless for now, so no need to
Hi Bryan,
On 5/28/07, Bryan Wu [EMAIL PROTECTED] wrote:
+P: Aubrey Li
+M: [EMAIL PROTECTED]
+P: Bernd Schmidt
+M: [EMAIL PROTECTED]
[snip, snip]
Would it be possible to have an email alias for this? It's a total
pain in the ass to cc that many maintainers when sending a patch
On 5/28/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
No, LZO as a visible option makes no practical sense. Why would
anyone want to build LZO into a kernel when there are no in-kernel
users of the code?
Agreed. It should be a auto-selected hidden config option.
-
To unsubscribe from this
Hi Tero,
On 5/29/07, Tero Roponen [EMAIL PROTECTED] wrote:
FYI, I just tested 2.6.21.3. I couldn't reproduce the problem with
that kernel.
Well, I went through all tty related patches that went in after 2.6.21
and didn't really find anything interesting, except this:
On 5/30/07, Tero Roponen [EMAIL PROTECTED] wrote:
Hmmm, I just found something interesting. In 2.6.21.3 the /sbin/init
gets corrupted when I watch the video!
$ cp /sbin/init init.before
$ mplayer kiwi.flv
$ cp /sbin/init init.after
The sha1sums are here:
On 5/30/07, Pekka Enberg [EMAIL PROTECTED] wrote:
The file at offset 001 - 0011348 is overwritten with the byte
pattern 79 06 00 00.
Do you see anything in the logs or is this a silent corruption? Did
you see this corruption with 2.6.19 or 2.6.22-rc3?
Btw, please send us a strace log
Tero Roponen wrote:
after some trial and error I found a simple way to trigger the
corruption:
Nice. This triggers on the file corruption on 2.6.21.3 also?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On 7/16/07, Nick Piggin [EMAIL PROTECTED] wrote:
Actually SLOB potentially has some fundamental CPU cache hotness
advantages over the other allocators, for the same reasons as
its space advantages.
Because consecutive allocations hit the same cache-hot page regardless
of requested size where
On 7/17/07, Al Viro [EMAIL PROTECTED] wrote:
- pri-compiled = um_kmalloc(sizeof(struct bpf_program));
+ pri-compiled = kmalloc(sizeof(struct bpf_program),
UM_GFP_KERNEL);
GFP_KERNEL?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On 7/17/07, Al Viro [EMAIL PROTECTED] wrote:
- pri-compiled = um_kmalloc(sizeof(struct bpf_program));
+ pri-compiled = kmalloc(sizeof(struct bpf_program),
UM_GFP_KERNEL);
On 7/17/07, Pekka Enberg [EMAIL PROTECTED] wrote:
GFP_KERNEL?
Uhm, missed this: http
Hi Heiko,
On 7/17/07, Heiko Carstens [EMAIL PROTECTED] wrote:
Hmm.. this breaks s390 and probably m68k and UML as well:
CC lib/check_signature.o
lib/check_signature.c: In function 'check_signature':
lib/check_signature.c:19: error: implicit declaration of function 'readb'
Just to
Hi Andi,
On 7/19/07, Andi Kleen [EMAIL PROTECTED] wrote:
qemu testing and booting test machines with i386 kernels wasn't very successfull
with recent git kernels. I got either BUGs because of failing sysfs
initialization
or oopses in kmalloc, but no user land.
I bisected it down to this
Linus Torvalds wrote:
Ok, I think I see it: I think the mm/slab.c conversion of kmalloc(0) is
totally broken.
The problem? It returns ZERO_SIZE_PTR from __find_general_cachep(), not
from __kmalloc(). So anythign that uses __find_general_cachep() will get
an invalid cachep pointer, which was
On 5/7/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Open source is about release early, release often. Not hide code in a
dark corner until Christoph thinks it is perfect. We have high
standards for upstream merged code, but that standard is not perfection.
Please. This has nothing to do with
Shani Moideen wrote:
ptr = kmap(page);
- memset(ptr, 0, PAGE_SIZE);
+ clear_page(ptr);
On 5/8/07, Michael Tokarev [EMAIL PROTECTED] wrote:
I wonder if it's worth to invent kzmap() or something like that... ;)
I am counting 59 kmap + memset
Hi Rene,
On 5/8/07, Rene Herman [EMAIL PROTECTED] wrote:
+static int __mitsumi_read_toc(struct mitsumi_cdrom *mcd)
+{
+ int tracks = mcd-header.cdth_trk1 - mcd-header.cdth_trk0 + 1;
+ int retries;
+ int err = 0;
+
+ kfree(mcd-toc);
+
+ mcd-toc = kzalloc(tracks *
* sizeof *mcd-toc, GFP_KERNEL);
On 5/8/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Perhaps we should use krealloc() + memset() here?
Strike that, krealloc() only makes it look ugly.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
On 5/8/07, Jörn Engel [EMAIL PROTECTED] wrote:
+typedef __be16 be16;
+typedef __be32 be32;
+typedef __be64 be64;
Why are those typedefs necessary ?
Not strictly. I tend to use the be* types fairly often in the code and
simply grew weary of seeing the underscores.
Any objections if I
On 5/9/07, Stefan Richter [EMAIL PROTECTED] wrote:
I don't know which form is better suited to the goal of well
maintainable code --- the compact, easy to read, winning guideline, or
the comprehensive norm.
Bah, it's a slippery slope. Too little guidelines and we end up people
submitting code
Hi Rusty,
On 5/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+static void add_lguest_device(unsigned int index)
+{
+ struct lguest_device *new;
+
+ lguest_devices[index].status |= LGUEST_DEVICE_S_ACKNOWLEDGE;
+ new = kmalloc(sizeof(struct lguest_device), GFP_KERNEL);
+
On 5/9/07, [EMAIL PROTECTED] [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();
+
Hi Rusty,
On 5/9/07, Rusty Russell [EMAIL PROTECTED] wrote:
Hmm, where would the error go?
Let it propagate: scan_devices - lguest_bus_init - do_initcalls. We
probably don't want to panic() if bus_register and device_register
fail there either.
-
To unsubscribe from this list: send
On 5/10/07, Alan Cox [EMAIL PROTECTED] wrote:
blobs of crap - in whose opinion. Yours. So you don't want the kernel
to mention things you personally don't approve of. Thats straight forward
censorship and has no place in free software.
Out of kernel code comes and goes, so why mention it
On 5/9/07, Andrew Morton [EMAIL PROTECTED] wrote:
ext2 has no truncate_mutex.
I think it does:
- mutex_init(ei-truncate_mutex);
- inode_init_once(ei-vfs_inode);
- }
-}
And fs/ext2/super.c:init_once() from 2.6.21-mm2 says:
On 5/10/07, Keith Packard [EMAIL PROTECTED] wrote:
Additional information available on the web: http://intellinuxgraphics.org
Are the datasheets available for non-Intel developers?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
for a long time
now and we really don't do much complex initialization that requires
undo (releasing resources).
Looks good to me.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
Pekka
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
[EMAIL PROTECTED] wrote:
There is no user of destructors left. There is no reason why we should
keep checking for destructors calls in the slab allocators.
Looks good to me.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Hi Cyrill
On 5/12/07, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
you know I've got a question (may be it's stupid) - what a
sense to discard UDF_I_* macroses? I mean as I see they
don't slow down execution of the code...
They make the code harder to read and maintain.
-
To unsubscribe from this
On 5/16/07, Jamie Lokier [EMAIL PROTECTED] wrote:
Given that the filesystem is still 'experimental', I'd concentrate on
getting it stable before worrying about immutable and xattrs unless
they are easy.
We will run into trouble if the on-disk format is not flexible enough
to accommodate xattrs
On 5/16/07, Jörn Engel [EMAIL PROTECTED] wrote:
+/* FIXME: all this mess should get replaced by using the page cache */
+static void fixup_from_wbuf(struct super_block *sb, struct logfs_area
*area,
+ void *read, u64 ofs, size_t readlen)
+{
Indeed. And I think you're
On 5/16/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Forgot to add (see below). Seems logfs_segment_read would be simpler
too if you fixed this.
Blah. Just to be clear: I forgot to add a (see below) text in the
original review comment.
-
To unsubscribe from this list: send the line unsubscribe
Jörn Engel wrote:
Compressing random data will actually enlarge it. If that happens I
simply store the verbatim uncompressed data instead and mark it as such.
There is also demand for a user-controlled bit in the inode to disable
compression completely. All those .jpg, .mpg, .mp3, etc. just
On 5/18/07, Pekka Enberg [EMAIL PROTECTED] wrote:
So how about making that a little less verbose. Say like:
Copyright (c) 1996-2005 Markus Franz Xaver and Johannes Oberhumer
Oh, the author's name really is Markus Franz Xaver Johannes
Oberhumer. But please make the copyright statement one line
On 5/18/07, Nitin Gupta [EMAIL PROTECTED] wrote:
+ Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
+ Copyright (C) 2004 Markus Franz Xaver Johannes Oberhumer
[snip]
So how about making that a little less verbose. Say like:
Copyright (c) 1996-2005 Markus Franz Xaver and Johannes
Hi Debian Developer,
On 5/18/07, debian developer [EMAIL PROTECTED] wrote:
Heres a patch. It's my first. so any mistakes to be pardoned. :)
Three major problems: (1) no real name in the email, (2) no patch
description and (3) no signed-off-by line. Please see the following
URL for details:
On 5/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
kmem_cache_ops is created as empty. Later patches populate kmem_cache_ops.
Hmm, would make more sense to me to move ctor in kmem_cache_ops in
this patch and not make kmem_cache_create() take both as parameters...
-
To unsubscribe from this
Christoph Lameter wrote:
Yeah earlier versions did this but then I have to do a patch that changes
all destructors and all kmem_cache_create calls in the kernel.
Yes, please ;-)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On 5/21/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
Given that there is no remaining usage of the deprecated kmem_cache_t
typedef anywhere in the tree, remove that typedef.
Looks good to me.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
Hi Bryan,
On 5/21/07, Bryan Wu [EMAIL PROTECTED] wrote:
-void *dma_memcpy(void *dest, const void *src, size_t size)
+void *_dma_memcpy(void *dest, const void *src, size_t size)
Minor nitpick: the established naming convention is two underscores, not one.
+void *dma_memcpy(void *dest, const
Hi Bryan,
On 5/21/07, Bryan Wu [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_DUMMY_CONSOLE
+ conswitchp = dummy_con;
+#endif
cclk = get_cclk();
sclk = get_sclk();
This patch has no changelog. While it is probably apparent to you why
this fixes a crash when using an USB
On 5/21/07, Hennerich, Michael [EMAIL PROTECTED] wrote:
I was fixing this issue some time ago.
[snip]
Makes sense. Please consider adding this to the changelog. Thanks.
Pekka
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On 5/21/07, Hennerich, Michael [EMAIL PROTECTED] wrote:
With CONFIG_VT (drivers/char/vt.c) enabled and a USB HID keyboard connected,
we were seeing bad pointer dereferences in drivers/char/keyboard.c
In function kbd_keycode vc_cons[fg_console].d was un-initialized.
On 5/21/07, Pekka Enberg
Hi Michael,
On 5/21/07, Hennerich, Michael [EMAIL PROTECTED] wrote:
During initcalls: con_init is called, and returns because of
!display_desc.
[snip]
Aah, I missed that bit.
On 5/21/07, Hennerich, Michael [EMAIL PROTECTED] wrote:
I don't see where vc_cons[].d in between there is
Nitin Gupta wrote:
What if compiler decides not to actully inline them? In that case
there will be significant perf. hit.
Then you use __always_inline.
Pekka
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Nitin Gupta wrote:
Ok. I will make them inline functions now.
Btw, the only reason why any sane compiler would not inline
them is because it has reason to believe the end-result will
be more efficient. AFAIK you only need to use
__always_inline where it matters for correctness (like, for
On 5/1/07, Andrew Morton [EMAIL PROTECTED] wrote:
revoke-special-mmap-handling.patch
[snip]
Hold. This is tricky stuff and I don't think we've seen sufficient
reviewing, testing and acking yet?
Agreed. While Peter and Nick have done some review of the patches, I
would really like VFS
Hi Andi,
On 01 May 2007 14:19:45 +0200, Andi Kleen [EMAIL PROTECTED] wrote:
Also have the cache performance concerns raised on the original review
been addressed?
I am only aware of the fget_light() related issues Eric Dumazet raised
but it's fixed. If you're thinking of something else, could
On 5/2/07, Richard Purdie [EMAIL PROTECTED] wrote:
I realise a maze of ifdefs still remain. I've already spent a lot of
time removing a ton of them and going much further might start to affect
diffability of the code - I hoping whats there is a good compromise.
I really don't think this is
On 5/2/07, Stefan Richter [EMAIL PROTECTED] wrote:
+/* The lib/crc16.c implementation uses the standard (0x8005)
+ * polynomial, but we need the ITU-T (or CCITT) polynomial (0x1021).
+ * The implementation below works on an array of host-endian u32
+ * words, assuming they'll be transmited msb
On 5/2/07, Christoph Lameter [EMAIL PROTECTED] wrote:
Owww... You throw my roadmap out of the window and may create too
high expectations of SLUB.
Me too!
On 5/2/07, Christoph Lameter [EMAIL PROTECTED] wrote:
I am the one who has to maintain SLAB and SLUB it seems and I have been
dealing
Christoph Lameter wrote:
Patch is already in mm. Could you download all the patches after that
before testing? There was quite a number.
I am on 2.6.21-rc7-mm2. Me goes to wonder where Andrew's snapshots are...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 5/2/07, Stefan Richter [EMAIL PROTECTED] wrote:
I looked around a bit with grep -R and a few search terms but didn't
find something definite. Is there any other user of a crc16_itu_t or
crc_ccitt or whatever which operates on a (CPU byte ordered) u32[]
instead of on a (network byte ordered)
On 5/3/07, kernel coder [EMAIL PROTECTED] wrote:
I'm profiling some part of kernel code.Mine profiling mechanism
is based on rdtsc instruction.
Why dont you use oprofile?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Hi Randy,
On 5/4/07, Randy Dunlap [EMAIL PROTECTED] wrote:
+extern void hex_dumper(void *buf, size_t len, char *linebuf, size_t
linebuflen);
Please do s/hex_dumper/hex_dump_to_buffer/ for consistency with print_hex_dump.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 5/4/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
Expost buffer_size in order to allow fair estimates on the actual space
used/needed.
[snip]
#ifdef CONFIG_SLAB_FAIR
-static inline int slab_alloc_rank(gfp_t flags)
+static __always_inline int slab_alloc_rank(gfp_t flags)
{
return
Christoph Lameter wrote:
Hmmm... Maybe lets have
unsigned kmem_estimate_pages(struct kmem_cache *slab_cache, int objects)
which would calculate the worst case memory scenario for allocation the
number of indicated objects?
IIRC this looks more or less what Peter had initially. I don't like
On Fri, 2007-05-04 at 11:30 -0700, Christoph Lameter wrote:
Hmmm... Maybe lets have
unsigned kmem_estimate_pages(struct kmem_cache *slab_cache, int objects)
which would calculate the worst case memory scenario for allocation the
number of indicated objects?
On Fri, 4 May 2007, Peter
Christoph Lameter wrote:
SLAB can calculate exactly how many pages are needed. The per
cpu and per node stuff is setup at boot and does not change. We are
talking about the worst case scenario here. True in case of an off slab
we have additional overhead that would also have to go into worst
Christoph Lameter wrote:
On Fri, 4 May 2007, Pekka Enberg wrote:
Again, slab has no way of actually estimating how many pages you need for a
given number of objects. So we end up calculating some upper bound which
doesn't belong in mm/slab.c. I am perfectly okay with:
It can give a worst
On 5/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
This patch gets rid constructors and destructors and replaces them
with a slab operations structure that is passed into SLUB.
Looks good to me.
On 5/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+struct slab_ops {
+ /* FIXME:
On 5/5/07, Andrew Morton [EMAIL PROTECTED] wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
Someone broke UML.
$ make ARCH=um defconfig
$ make
[snip]
UPD include/linux/version.h
CHK include/linux/utsrelease.h
UPD
On 5/5/07, Andrew Morton [EMAIL PROTECTED] wrote:
Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is inexplicably
dependent upon CONFIG_SLAB.
How come?
I think Adrian added it before we introduced krealloc() to fix uniofs
from poking slab internals.
-
To unsubscribe from this
;
+ details.restore_start = 0;
+
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
On 4/26/07, Amit K. Arora [EMAIL PROTECTED] wrote:
/*
+ * ext4_ext_try_to_merge:
+ * tries to merge the ex extent to the next extent in the tree.
+ * It always tries to merge towards right. If you want to merge towards
+ * left, pass ex - 1 as argument instead of ex.
+ * Returns 0 if the
On Mon, Aug 5, 2013 at 12:12 PM, Ingo Molnar mi...@kernel.org wrote:
Assuming that in the normal case it can be made to work like a full build
of perf today (i.e. without forcing LD_PRELOAD) then splitting the
libraries away looks like a much better solution than splitting the
binary.
Yup, if
' failed
perf: Segmentation fault
Cc: Jiri Olsa jo...@redhat.com
Cc: Pekka Enberg penb...@kernel.org
Cc: Andi Kleen a...@firstfloor.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Aug 6, 2013 at 8:14 AM, Namhyung Kim namhy...@kernel.org wrote:
Separate out GTK codes to a shared object called libperf-gtk.so. This
time only GTK codes are built with -fPIC and libperf remains as is.
Cc: Andi Kleen a...@linux.intel.com
Cc: Pekka Enberg penb...@kernel.org
Signed
On Tue, Aug 6, 2013 at 8:14 AM, Namhyung Kim namhy...@kernel.org wrote:
Call setup/exit GTK browser function using libdl.
Cc: Andi Kleen a...@linux.intel.com
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
On Tue, Aug 6, 2013 at 8:14 AM, Namhyung Kim namhy...@kernel.org wrote:
Run GTK hist and annotation browser using libdl.
Cc: Andi Kleen a...@linux.intel.com
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
On Tue, Aug 20, 2013 at 6:28 AM, Michael Neuling mi...@neuling.org wrote:
xics_init() assumes kvm-nrcpus is already setup. kvm-nrcpus is setup
in kvm_cpu_init()
Unfortunately xics_init() and kvm_cpu_init() both use base_init(). So
depending on the order randomly determined by the compiler,
On Tue, Aug 13, 2013 at 8:48 AM, Michael Ellerman
mich...@ellerman.id.au wrote:
On some powerpc systems, reboot is implemented by an RTAS call by the
name of system-reboot. Currently we don't implement it in kvmtool,
which means instead the guest prints an error and spins.
This is
On 8/14/13 6:44 AM, Tang Chen wrote:
In setup_arch() of x86, it set memblock.current_limit directly.
We should use memblock_set_current_limit(). If the implementation
is changed, it is easy to maintain.
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
Reviewed-by: Pekka Enberg penb
the setup_data header and allow parsing functions
for individual types to handle their own data remapping.
Signed-off-by: Linn Crosetto l...@hp.com
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 07/10/2013 03:07 AM, Stephen Rothwell wrote:
Hi all,
On Tue, 2 Jul 2013 17:09:57 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
We are in the merge window, so please do not add anything to your
linux-next included branches that is not destined for v3.11 until after
v3.11-rc1 is
On 07/10/2013 05:56 AM, Stephen Rothwell wrote:
Hi all,
After merging the slab tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/slab.h:17:0,
from include/linux/crypto.h:24,
from
On Wed, 10 Jul 2013, Pekka Enberg wrote:
Yes, it indeed interacts badly with kmemleak and tracing. I reverted the
commit.
On 07/10/2013 09:48 PM, Christoph Lameter wrote:
Here is the fix required. kmemleak.h is weird in that it cannot be
included at the top of slab.h due to its corresponding
(nine months later...)
On 10/31/2012 12:01 PM, Matthieu CASTET wrote:
This piece of code tends to break in peculiar ways every time someone
touches it. I could use some more convincing in the changelog this
time it won't...
Ok, is the following changelog is ok ?
The current slab code only
On Thu, Jul 11, 2013 at 10:00 AM, Vladimir Cernov
gg.kasper...@gmail.com wrote:
This fixes following errors:
- ERROR: (foo*) should be (foo *)
- ERROR: foo ** bar should be foo **bar
Signed-off-by: Vladimir Cernov gg.kasper...@gmail.com
Reviewed-by: Pekka Enberg penb
to slab.h
Joonsoo Kim (2):
slub: do not put a slab to cpu partial list when cpu_partial is 0
slub: Make cpu partial slab support configurable
Michael Opdenacker (1):
slab: add kmalloc() to kernel API documentation
Pekka Enberg (2):
Revert mm/sl[aou]b: Move kmalloc definitions
On 07/14/2013 10:58 PM, Linus Torvalds wrote:
On Sun, Jul 14, 2013 at 12:06 PM, Pekka Enberg penb...@kernel.org wrote:
The tree also contains Christoph's unification work that I merged in
too late had to revert because it broke things. We'll try again for
v3.12.
Ugh. I'll merge the commits
On Mon, Jul 15, 2013 at 9:12 AM, Pekka Enberg penb...@kernel.org wrote:
Ugh. I'll merge the commits leading up to that, but not the actual
broken try at unification at all.
There's just one one-liner patch in between the broken commits and
their reverts, I don't see the point of pulling
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/urgent
It contains a slab regression fix by Sasha Levin.
Pekka
--
The following changes since commit
On Tue, Jul 16, 2013 at 10:10 PM, Uwe Kleine-König
u.kleine-koe...@pengutronix.de wrote:
Hello,
(sorry for breaking the mail threading, but I failed to find the right
mail to reply to.)
while doing make oldconfig on an !SMP config using 3.11-rc1 I was asked
if I want
On Fri, Jul 19, 2013 at 5:45 PM, Alexandru Juncu al...@rosedu.org wrote:
Found using coccinelle. It suggested kmalloc/strcpy should be replaced
with kstrdup, but the entire function can be replaced by kstrdup.
Signed-off-by: Alexandru Juncu al...@rosedu.org
---
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/next
Nothing terribly exciting here apart from Christoph's kmalloc
unification patches that brings sl[aou]b implementations closer to
each other.
Pekka
On 10/16/13 10:34 PM, Andrew Morton wrote:
On Wed, 16 Oct 2013 17:43:57 +0900 Joonsoo Kim iamjoonsoo@lge.com wrote:
There is two main topics in this patchset. One is to reduce memory usage
and the other is to change a management method of free objects of a slab.
The SLAB allocate a struct
On 12/02/2013 02:23 AM, David Ahern wrote:
'perf sched timehist' provides an analysis of scheduling events.
Example usage:
perf sched record -- sleep 1
perf sched timehist
By default it shows the individual schedule events, including the time between
sched-in events for the task, the
601 - 700 of 1778 matches
Mail list logo
