On Thu, 2008-02-14 at 09:12 -0800, Dave Hansen wrote:
..
> > > > - Use currently other not exported functions in kernel/resource.c, like
> > > > walk_memory_resource (where we would still need the maximum
> > > possible number
> > > > of pages NR_MEM_SECTIONS)
> > >
> > > It isn't the act of ex
em EXPORT_SYMBOL_GPL() ?
Otherwise, looks good to me.
I have been planning to send this as part of my next update
with ppc64 arch-specific remove support and generic __remove_pages()
support. If this is blocking your work, lets get this in.
Acked-by: Badari Pulavarty <[EMAIL PROTECTED]>
Simple compile warning fix. (against 2.6.23-git12)
Thanks,
Badari
vortex_up() should initialize 'err' for a successful return.
drivers/net/3c59x.c: In function `vortex_up':
drivers/net/3c59x.c:1494: warning: `err' might be used uninitialized in this
function
Signed-off-
Simple error handling fix (against 2.26.23-git12).
Thanks,
Badari
Need to initialize "err" in case of skb_clone() failure.
net/ipv4/ip_fragment.c: In function `ip_defrag':
net/ipv4/ip_fragment.c:540: warning: `err' might be used uninitialized in this
function
Signed-off-
for small fd sets.
core_sys_select() already has this optimization. This is
for compat version.
Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
---
fs/compat.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
Index: linux-2.6.22-rc1/fs/compat.c
===
On Tue, 2007-05-15 at 10:44 -0700, Andrew Morton wrote:
> On Tue, 15 May 2007 10:29:18 -0700
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Is select(0, ..) is a valid operation ?
>
> Probably - it becomes an elaborate way of doing a sl
Hi,
Is select(0, ..) is a valid operation ?
I see that there is no check to prevent this or return
success early, without doing any work. Do we need one ?
slub code is complaining that we are doing kmalloc(0).
Thanks,
Badari
[ cut here ]
Badness at include/linux/slub_de
keith mannthey wrote:
On Fri, 2006-10-06 at 01:35 +0200, Andi Kleen wrote:
As of yet I haven't been able to recreate the hang. I am running
similar HW to Steve.
I ran into this with -mm3
Memory: 24150368k/26738688k available (1933k kernel code, 490260k
reserved, 978k data, 308k in
On Thu, 2006-10-05 at 09:53 -0500, Steve Fox wrote:
> On Wed, 2006-10-04 at 18:08 -0700, Martin Bligh wrote:
> > Andi Kleen wrote:
> > >>I think most likely it would crash on 2.6.18. Keith mannthey had reported
> > >>a different crash on 2.6.18-rc4-mm2 when this patch was introduced first
> > >>tim
On Wed, 2006-10-04 at 16:02 -0500, Steve Fox wrote:
> On Wed, 2006-10-04 at 09:57 -0700, Andrew Morton wrote:
>
> > You might well find this bisection lands you on origin.patch. ie: a
> > mainline bug. I note that David merged a few more xfrm fixes this morning.
> >
> > So to confirm that, firs
On Fri, 2006-09-29 at 17:30 -0600, Eric W. Biederman wrote:
>
> So it looks like the kernel moved the ioapics.
>
> The following patch in 2.6.18-mm1 is known to have that effect.
> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
>
> Can you please try reverting that one patch?
>
Evgeniy Polyakov wrote:
AIO, aio_sendfile() implementation.
This patch includes asynchronous propagation of file's data into VFS
cache and aio_sendfile() implementation.
Network aio_sendfile() works lazily - it asynchronously populates pages
into the VFS cache (which can be used for various tric
On Thu, 2006-07-27 at 11:44 -0700, Ulrich Drepper wrote:
> Badari Pulavarty wrote:
> > Before we spend too much time cleaning up and merging into mainline -
> > I would like an agreement that what we add is good enough for glibc
> > POSIX AIO.
>
> I haven't seen a
On Thu, 2006-07-27 at 11:14 -0700, Zach Brown wrote:
> > Suparna mentioned at Ulrich wants us to concentrate on kernel-side
> > support, so that he can look at glibc side of things (along with
> > other work he is already doing). So, if we can get an agreement on
> > what kind of kernel support is
Sébastien Dugué wrote:
On Wed, 2006-07-26 at 09:22 -0700, Badari Pulavarty wrote:
Ulrich Drepper wrote:
Christoph Hellwig wrote:
My personal opinion on existing AIO is that it is not the right design.
Benjamin LaHaise agree with me (if I understood him right
Ulrich Drepper wrote:
Christoph Hellwig wrote:
My personal opinion on existing AIO is that it is not the right design.
Benjamin LaHaise agree with me (if I understood him right),
I completely agree with that aswell.
I agree, too, but the current code is not the last of the line
16 matches
Mail list logo