Re: [PATCH][next] drm/vkms: Fix missing kmalloc allocation failure check

On 01/15, Sumera Priyadarsini wrote: > On Fri, Jan 15, 2021 at 6:39 PM Colin King wrote: > > > > From: Colin Ian King > > > > Currently the kmalloc allocation for config is not being null > > checked and could potentially lead to a null pointer dereference. &

Re: [PATCH][next] drm/vkms: Fix missing kmalloc allocation failure check

On Fri, Jan 15, 2021 at 6:39 PM Colin King wrote: > > From: Colin Ian King > > Currently the kmalloc allocation for config is not being null > checked and could potentially lead to a null pointer dereference. > Fix this by adding the missing null check. > > Addresses-Cove

[PATCH][next] drm/vkms: Fix missing kmalloc allocation failure check

From: Colin Ian King Currently the kmalloc allocation for config is not being null checked and could potentially lead to a null pointer dereference. Fix this by adding the missing null check. Addresses-Coverity: ("Dereference null return value") Fixes: 2df7af93fdad ("drm/vkms:

Re: [PATCH] staging: wilc1000: check for kmalloc allocation failures

On 26/03/18 16:35, Ajay Singh wrote: > Thanks for submitting the patch. > > On Wed, 21 Mar 2018 13:03:18 -0700 > Joe Perches wrote: > >> On Wed, 2018-03-21 at 19:19 +, Colin King wrote: >>> From: Colin Ian King >>> >>> There are three kmalloc

Re: [PATCH] staging: wilc1000: check for kmalloc allocation failures

On 26/03/18 16:35, Ajay Singh wrote: > Thanks for submitting the patch. > > On Wed, 21 Mar 2018 13:03:18 -0700 > Joe Perches wrote: > >> On Wed, 2018-03-21 at 19:19 +, Colin King wrote: >>> From: Colin Ian King >>> >>> There are three kmalloc allocations that are not null checked which >>>

Re: [PATCH] staging: wilc1000: check for kmalloc allocation failures

Thanks for submitting the patch. On Wed, 21 Mar 2018 13:03:18 -0700 Joe Perches wrote: > On Wed, 2018-03-21 at 19:19 +, Colin King wrote: > > From: Colin Ian King > > > > There are three kmalloc allocations that are not null checked which > >

Re: [PATCH] staging: wilc1000: check for kmalloc allocation failures

Thanks for submitting the patch. On Wed, 21 Mar 2018 13:03:18 -0700 Joe Perches wrote: > On Wed, 2018-03-21 at 19:19 +, Colin King wrote: > > From: Colin Ian King > > > > There are three kmalloc allocations that are not null checked which > > potentially could lead to null pointer

Re: [PATCH] staging: wilc1000: check for kmalloc allocation failures

On Wed, 2018-03-21 at 19:19 +, Colin King wrote: > From: Colin Ian King > > There are three kmalloc allocations that are not null checked which > potentially could lead to null pointer dereference issues. Fix this > by adding null pointer return checks. looks like

Re: [PATCH] staging: wilc1000: check for kmalloc allocation failures

On Wed, 2018-03-21 at 19:19 +, Colin King wrote: > From: Colin Ian King > > There are three kmalloc allocations that are not null checked which > potentially could lead to null pointer dereference issues. Fix this > by adding null pointer return checks. looks like all of these should be

[PATCH] staging: wilc1000: check for kmalloc allocation failures

From: Colin Ian King There are three kmalloc allocations that are not null checked which potentially could lead to null pointer dereference issues. Fix this by adding null pointer return checks. Detected by CoverityScan, CID#1466025-27 ("Dereference null return")

[PATCH] staging: wilc1000: check for kmalloc allocation failures

From: Colin Ian King There are three kmalloc allocations that are not null checked which potentially could lead to null pointer dereference issues. Fix this by adding null pointer return checks. Detected by CoverityScan, CID#1466025-27 ("Dereference null return") Signed-off-by: Colin Ian King

[PATCH 4.9 005/241] staging: wilc1000: add check for kmalloc allocation failure.

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Colin Ian King [ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on

[PATCH 4.9 005/241] staging: wilc1000: add check for kmalloc allocation failure.

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Colin Ian King [ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling

[PATCH 4.4 004/134] staging: wilc1000: add check for kmalloc allocation failure.

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Colin Ian King [ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on

[PATCH 4.4 004/134] staging: wilc1000: add check for kmalloc allocation failure.

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Colin Ian King [ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling

[PATCH AUTOSEL for 4.9 007/219] staging: wilc1000: add check for kmalloc allocation failure.

From: Colin Ian King [ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling ether_add_copy. Detected by CoverityScan, CID#1369537 ("Dereference null return

[PATCH AUTOSEL for 4.9 007/219] staging: wilc1000: add check for kmalloc allocation failure.

From: Colin Ian King [ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling ether_add_copy. Detected by CoverityScan, CID#1369537 ("Dereference null return value") Signed-off-by:

[PATCH AUTOSEL for 4.4 004/115] staging: wilc1000: add check for kmalloc allocation failure.

From: Colin Ian King [ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling ether_add_copy. Detected by CoverityScan, CID#1369537 ("Dereference null return

[PATCH AUTOSEL for 4.4 004/115] staging: wilc1000: add check for kmalloc allocation failure.

From: Colin Ian King [ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ] Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling ether_add_copy. Detected by CoverityScan, CID#1369537 ("Dereference null return value") Signed-off-by:

Re: [PATCH] Add checks for kmalloc allocation failures

Hello. On 03/29/2017 06:21 PM, Eric Dumazet wrote: On Wed, 2017-03-29 at 16:54 +0100, Colin King wrote: From: Colin Ian King Ensure we don't end up with a null pointer dereferences by checking for for allocation failures. Allocate by sizeof(*ptr) rather than the

Re: [PATCH] Add checks for kmalloc allocation failures

Hello. On 03/29/2017 06:21 PM, Eric Dumazet wrote: On Wed, 2017-03-29 at 16:54 +0100, Colin King wrote: From: Colin Ian King Ensure we don't end up with a null pointer dereferences by checking for for allocation failures. Allocate by sizeof(*ptr) rather than the type to fix checkpack

Re: [PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

Hi Colin, > Ensure we don't end up with a null pointer dereferences by checking > for for allocation failures. Allocate by sizeof(*ptr) rather than > the type to fix checkpack warnings. Also merge multiple lines into > one line for the kmalloc call. > > Detected by CoverityScan, CID#1422435

Re: [PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

Hi Colin, > Ensure we don't end up with a null pointer dereferences by checking > for for allocation failures. Allocate by sizeof(*ptr) rather than > the type to fix checkpack warnings. Also merge multiple lines into > one line for the kmalloc call. > > Detected by CoverityScan, CID#1422435

Re: [PATCH] Add checks for kmalloc allocation failures

Am 29.03.2017 17:54, schrieb Colin King: > From: Colin Ian King > > Ensure we don't end up with a null pointer dereferences by checking > for for allocation failures. Allocate by sizeof(*ptr) rather than > the type to fix checkpack warnings. Also merge multiple

Re: [PATCH] Add checks for kmalloc allocation failures

Am 29.03.2017 17:54, schrieb Colin King: > From: Colin Ian King > > Ensure we don't end up with a null pointer dereferences by checking > for for allocation failures. Allocate by sizeof(*ptr) rather than > the type to fix checkpack warnings. Also merge multiple lines into > one line for the

Re: [PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

Hi Dave, >> drivers/net/ieee802154/ca8210.c | 18 ++ > > This file doesn't exist in any of my trees. > because we have not send you a bluetooth-next pull request yet. I review it and take it through my tree first. Regards Marcel

Re: [PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

Hi Dave, >> drivers/net/ieee802154/ca8210.c | 18 ++ > > This file doesn't exist in any of my trees. > because we have not send you a bluetooth-next pull request yet. I review it and take it through my tree first. Regards Marcel

Re: [PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

From: Colin King Date: Wed, 29 Mar 2017 18:05:40 +0100 > drivers/net/ieee802154/ca8210.c | 18 ++ This file doesn't exist in any of my trees.

Re: [PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

From: Colin King Date: Wed, 29 Mar 2017 18:05:40 +0100 > drivers/net/ieee802154/ca8210.c | 18 ++ This file doesn't exist in any of my trees.

[PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

From: Colin Ian King Ensure we don't end up with a null pointer dereferences by checking for for allocation failures. Allocate by sizeof(*ptr) rather than the type to fix checkpack warnings. Also merge multiple lines into one line for the kmalloc call. Detected by

[PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

From: Colin Ian King Ensure we don't end up with a null pointer dereferences by checking for for allocation failures. Allocate by sizeof(*ptr) rather than the type to fix checkpack warnings. Also merge multiple lines into one line for the kmalloc call. Detected by CoverityScan, CID#1422435

Re: [PATCH] Add checks for kmalloc allocation failures

On Wed, 2017-03-29 at 16:54 +0100, Colin King wrote: > From: Colin Ian King > > Ensure we don't end up with a null pointer dereferences by checking > for for allocation failures. Allocate by sizeof(*ptr) rather than > the type to fix checkpack warnings. Also merge

Re: [PATCH] Add checks for kmalloc allocation failures

On Wed, 2017-03-29 at 16:54 +0100, Colin King wrote: > From: Colin Ian King > > Ensure we don't end up with a null pointer dereferences by checking > for for allocation failures. Allocate by sizeof(*ptr) rather than > the type to fix checkpack warnings. Also merge multiple lines into > one

[PATCH] Add checks for kmalloc allocation failures

From: Colin Ian King Ensure we don't end up with a null pointer dereferences by checking for for allocation failures. Allocate by sizeof(*ptr) rather than the type to fix checkpack warnings. Also merge multiple lines into one line for the kmalloc call. Detected by

[PATCH] Add checks for kmalloc allocation failures

From: Colin Ian King Ensure we don't end up with a null pointer dereferences by checking for for allocation failures. Allocate by sizeof(*ptr) rather than the type to fix checkpack warnings. Also merge multiple lines into one line for the kmalloc call. Detected by CoverityScan, CID#1422435

[PATCH] staging: wilc1000: add check for kmalloc allocation failure.

From: Colin Ian King Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling ether_add_copy. Detected by CoverityScan, CID#1369537 ("Dereference null return value") Signed-off-by: Colin Ian King

[PATCH] staging: wilc1000: add check for kmalloc allocation failure.

From: Colin Ian King Add a sanity check that wid.val has been allocated, fixes a null pointer deference on stamac when calling ether_add_copy. Detected by CoverityScan, CID#1369537 ("Dereference null return value") Signed-off-by: Colin Ian King --- drivers/staging/wilc1000/host_interface.c |

[PATCH v3 02/16] slub: use free_page instead of put_page for freeing kmalloc allocation

When freeing objects, the slub allocator will most of the time free empty pages by calling __free_pages(). But high-order kmalloc will be diposed by means of put_page() instead. It makes no sense to call put_page() in kernel pages that are provided by the object allocators, so we shouldn't be

[PATCH v3 02/16] slub: use free_page instead of put_page for freeing kmalloc allocation

When freeing objects, the slub allocator will most of the time free empty pages by calling __free_pages(). But high-order kmalloc will be diposed by means of put_page() instead. It makes no sense to call put_page() in kernel pages that are provided by the object allocators, so we shouldn't be

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On 08/02/2012 09:10 PM, Johannes Weiner wrote: > On Thu, Aug 02, 2012 at 08:51:31PM +0400, Glauber Costa wrote: >> On 08/02/2012 08:42 PM, Johannes Weiner wrote: >>> On Thu, Aug 02, 2012 at 09:06:41AM -0500, Christoph Lameter wrote: On Thu, 2 Aug 2012, Glauber Costa wrote: > diff

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On Thu, Aug 02, 2012 at 08:51:31PM +0400, Glauber Costa wrote: > On 08/02/2012 08:42 PM, Johannes Weiner wrote: > > On Thu, Aug 02, 2012 at 09:06:41AM -0500, Christoph Lameter wrote: > >> On Thu, 2 Aug 2012, Glauber Costa wrote: > >> > >>> diff --git a/mm/slub.c b/mm/slub.c > >>> index

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On 08/02/2012 08:42 PM, Johannes Weiner wrote: > On Thu, Aug 02, 2012 at 09:06:41AM -0500, Christoph Lameter wrote: >> On Thu, 2 Aug 2012, Glauber Costa wrote: >> >>> diff --git a/mm/slub.c b/mm/slub.c >>> index e517d43..9ca4e20 100644 >>> --- a/mm/slub.c >>> +++ b/mm/slub.c >>> @@ -3453,7 +3453,7

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On Thu, Aug 02, 2012 at 09:06:41AM -0500, Christoph Lameter wrote: > On Thu, 2 Aug 2012, Glauber Costa wrote: > > > diff --git a/mm/slub.c b/mm/slub.c > > index e517d43..9ca4e20 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3453,7 +3453,7 @@ void kfree(const void *x) > > if

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On Thu, 2 Aug 2012, Glauber Costa wrote: > diff --git a/mm/slub.c b/mm/slub.c > index e517d43..9ca4e20 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -3453,7 +3453,7 @@ void kfree(const void *x) > if (unlikely(!PageSlab(page))) { > BUG_ON(!PageCompound(page)); >

[PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

The slab allocators provide its users with memory regions, with very few placement guarantees. No user should assume an actual page is given by kmalloc calls that are multiple of a page in size. This means that we can be sure that every sane user of the interface would not mess with the page

[PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

The slab allocators provide its users with memory regions, with very few placement guarantees. No user should assume an actual page is given by kmalloc calls that are multiple of a page in size. This means that we can be sure that every sane user of the interface would not mess with the page

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On Thu, 2 Aug 2012, Glauber Costa wrote: diff --git a/mm/slub.c b/mm/slub.c index e517d43..9ca4e20 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3453,7 +3453,7 @@ void kfree(const void *x) if (unlikely(!PageSlab(page))) { BUG_ON(!PageCompound(page));

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On Thu, Aug 02, 2012 at 09:06:41AM -0500, Christoph Lameter wrote: On Thu, 2 Aug 2012, Glauber Costa wrote: diff --git a/mm/slub.c b/mm/slub.c index e517d43..9ca4e20 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3453,7 +3453,7 @@ void kfree(const void *x) if

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On 08/02/2012 08:42 PM, Johannes Weiner wrote: On Thu, Aug 02, 2012 at 09:06:41AM -0500, Christoph Lameter wrote: On Thu, 2 Aug 2012, Glauber Costa wrote: diff --git a/mm/slub.c b/mm/slub.c index e517d43..9ca4e20 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3453,7 +3453,7 @@ void kfree(const

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On Thu, Aug 02, 2012 at 08:51:31PM +0400, Glauber Costa wrote: On 08/02/2012 08:42 PM, Johannes Weiner wrote: On Thu, Aug 02, 2012 at 09:06:41AM -0500, Christoph Lameter wrote: On Thu, 2 Aug 2012, Glauber Costa wrote: diff --git a/mm/slub.c b/mm/slub.c index e517d43..9ca4e20 100644

Re: [PATCH] slub: use free_page instead of put_page for freeing kmalloc allocation

On 08/02/2012 09:10 PM, Johannes Weiner wrote: On Thu, Aug 02, 2012 at 08:51:31PM +0400, Glauber Costa wrote: On 08/02/2012 08:42 PM, Johannes Weiner wrote: On Thu, Aug 02, 2012 at 09:06:41AM -0500, Christoph Lameter wrote: On Thu, 2 Aug 2012, Glauber Costa wrote: diff --git a/mm/slub.c

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 02:11:24PM -0200, Rik van Riel wrote: [PCAC] > It's a nice idea, but you still want to be sure you won't > allocate eg. page tables randomly in the middle of the > PCACs ;) Yes. That's why we check later, whether our hint is still true. If we cannot free or move all

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Ingo Oeser wrote: > On Tue, Oct 31, 2000 at 11:35:46AM -0200, Rik van Riel wrote: > > > Rik: What do you think about this (physical cont. area cache) for 2.5? >^ == PCAC > > > >

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Alan Cox wrote: > > The code for vmalloc allocates the pages at vmalloc time, not after. The > > TLB is populated lazily, but most definately not the page tables. > > Is the lazy tlb population interrupt safe or do I need to change any driver > using vmalloced memory from

Re: kmalloc() allocation.

On Tue, 31 Oct 2000 around 08:59:53 -0500, Richard B. Johnson wrote: [snip] > Since Linux is starting to be used in many 'strange' non-desktop > environments, maybe it's time to provide a hook to reserve the > top N kilobytes of RAM for strange buffers. Like: > > append="..,reserve=2M". >

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 11:35:46AM -0200, Rik van Riel wrote: > > Rik: What do you think about this (physical cont. area cache) for 2.5? ^ == PCAC > > http://www.surriel.com/zone-alloc.html Read it when you published it first, but

Re: kmalloc() allocation.

> The code for vmalloc allocates the pages at vmalloc time, not after. The > TLB is populated lazily, but most definately not the page tables. Is the lazy tlb population interrupt safe or do I need to change any driver using vmalloced memory from an IRQ ? - To unsubscribe from this list: send

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Brian Gerst wrote: > Andi Kleen wrote: > > > > On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote: > > > This was just changed in 2.4 so that vmalloced pages are faulted in on > > > demand. > > > > Could you explain how it handles the vmalloc() -- vfree() --

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Ingo Oeser wrote: > On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote: > > > There are 256 megabytes of SDRAM available. I don't think it's > > > reasonable that a 1/2 megabyte allocation would fail, especially > > > since it's the first module being installed.

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Rik van Riel wrote: > On Tue, 31 Oct 2000, Ingo Oeser wrote: > > On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote: > > > > If you write the defragmentation code for the VM, I'll > > > be happy to bump up the limit a bit ... > > > > Should become easier once we

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Ingo Oeser wrote: > On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote: > > If you write the defragmentation code for the VM, I'll > > be happy to bump up the limit a bit ... > > Should become easier once we start doing physical page scannings. > > We could

Re: kmalloc() allocation.

Andi Kleen wrote: > > On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote: > > This was just changed in 2.4 so that vmalloced pages are faulted in on > > demand. > > Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same > virtual space but different physical

Re: kmalloc() allocation.

On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote: > > There are 256 megabytes of SDRAM available. I don't think it's > > reasonable that a 1/2 megabyte allocation would fail, especially > > since it's the first module being installed. > If you write the defragmentation code for the

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 09:07:29AM +, Tigran Aivazian wrote: > On Tue, 31 Oct 2000, Andi Kleen wrote: > > > On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote: > > > > > > what do you mean?! That is, of course, impossible because it would break > > > all existing software, so I

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Andi Kleen wrote: > On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote: > > > > what do you mean?! That is, of course, impossible because it would break > > all existing software, so I won't even bother checking the code, safely > > assuming that you perhaps

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote: > > what do you mean?! That is, of course, impossible because it would break > all existing software, so I won't even bother checking the code, safely > assuming that you perhaps meant something else, ok? He refers to faulting

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Brian Gerst wrote: > "H. Peter Anvin" wrote: > > > > Followup to: <[EMAIL PROTECTED]> > > By author:"Richard B. Johnson" <[EMAIL PROTECTED]> > > In newsgroup: linux.dev.kernel > > > > > > > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will > >

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote: > This was just changed in 2.4 so that vmalloced pages are faulted in on > demand. Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same virtual space but different physical race ? -Andi - To unsubscribe from

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote: This was just changed in 2.4 so that vmalloced pages are faulted in on demand. Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same virtual space but different physical race ? -Andi - To unsubscribe from

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Brian Gerst wrote: "H. Peter Anvin" wrote: Followup to: [EMAIL PROTECTED] By author:"Richard B. Johnson" [EMAIL PROTECTED] In newsgroup: linux.dev.kernel 64K probably less. kmalloc allocates physically linear spaces. vmalloc will happily grab you

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote: what do you mean?! That is, of course, impossible because it would break all existing software, so I won't even bother checking the code, safely assuming that you perhaps meant something else, ok? He refers to faulting into

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Andi Kleen wrote: On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote: what do you mean?! That is, of course, impossible because it would break all existing software, so I won't even bother checking the code, safely assuming that you perhaps meant

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 09:07:29AM +, Tigran Aivazian wrote: On Tue, 31 Oct 2000, Andi Kleen wrote: On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote: what do you mean?! That is, of course, impossible because it would break all existing software, so I won't even

Re: kmalloc() allocation.

On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote: There are 256 megabytes of SDRAM available. I don't think it's reasonable that a 1/2 megabyte allocation would fail, especially since it's the first module being installed. If you write the defragmentation code for the VM, I'll

Re: kmalloc() allocation.

Andi Kleen wrote: On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote: This was just changed in 2.4 so that vmalloced pages are faulted in on demand. Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same virtual space but different physical race ? As

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Ingo Oeser wrote: On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote: If you write the defragmentation code for the VM, I'll be happy to bump up the limit a bit ... Should become easier once we start doing physical page scannings. We could record

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Rik van Riel wrote: On Tue, 31 Oct 2000, Ingo Oeser wrote: On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote: If you write the defragmentation code for the VM, I'll be happy to bump up the limit a bit ... Should become easier once we start doing

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Ingo Oeser wrote: On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote: There are 256 megabytes of SDRAM available. I don't think it's reasonable that a 1/2 megabyte allocation would fail, especially since it's the first module being installed. If you

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Brian Gerst wrote: Andi Kleen wrote: On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote: This was just changed in 2.4 so that vmalloced pages are faulted in on demand. Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same

Re: kmalloc() allocation.

The code for vmalloc allocates the pages at vmalloc time, not after. The TLB is populated lazily, but most definately not the page tables. Is the lazy tlb population interrupt safe or do I need to change any driver using vmalloced memory from an IRQ ? - To unsubscribe from this list: send

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 11:35:46AM -0200, Rik van Riel wrote: Rik: What do you think about this (physical cont. area cache) for 2.5? ^ == PCAC http://www.surriel.com/zone-alloc.html Read it when you published it first, but

Re: kmalloc() allocation.

On Tue, 31 Oct 2000 around 08:59:53 -0500, Richard B. Johnson wrote: [snip] Since Linux is starting to be used in many 'strange' non-desktop environments, maybe it's time to provide a hook to reserve the top N kilobytes of RAM for strange buffers. Like: append="..,reserve=2M".

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Alan Cox wrote: The code for vmalloc allocates the pages at vmalloc time, not after. The TLB is populated lazily, but most definately not the page tables. Is the lazy tlb population interrupt safe or do I need to change any driver using vmalloced memory from an IRQ

Re: kmalloc() allocation.

On Tue, 31 Oct 2000, Ingo Oeser wrote: On Tue, Oct 31, 2000 at 11:35:46AM -0200, Rik van Riel wrote: Rik: What do you think about this (physical cont. area cache) for 2.5? ^ == PCAC http://www.surriel.com/zone-alloc.html

Re: kmalloc() allocation.

On Tue, Oct 31, 2000 at 02:11:24PM -0200, Rik van Riel wrote: [PCAC] It's a nice idea, but you still want to be sure you won't allocate eg. page tables randomly in the middle of the PCACs ;) Yes. That's why we check later, whether our hint is still true. If we cannot free or move all pages

Re: kmalloc() allocation.

"Richard B. Johnson" wrote: > > Hello, > How much memory would it be reasonable for kmalloc() to be able > to allocate to a module? > > Oct 30 10:48:31 chaos kernel: kmalloc: Size (524288) too large > > Using Version 2.2.17, I can't allocate more than 64k! I need > to allocate at least 1/2

Re: kmalloc() allocation.

"H. Peter Anvin" wrote: > > Followup to: <[EMAIL PROTECTED]> > By author:"Richard B. Johnson" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will > > > happily grab you 2Mb of space but it will not be

Re: kmalloc() allocation.

Followup to: <[EMAIL PROTECTED]> By author:"Richard B. Johnson" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will > > happily grab you 2Mb of space but it will not be physically linear > > > > Okay. Thanks.

Re: kmalloc() allocation.

On Mon, 30 Oct 2000, Alan Cox wrote: > > How much memory would it be reasonable for kmalloc() to be able > > to allocate to a module? > > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will > happily grab you 2Mb of space but it will not be physically linear > Okay.

Re: kmalloc() allocation.

> How much memory would it be reasonable for kmalloc() to be able > to allocate to a module? 64K probably less. kmalloc allocates physically linear spaces. vmalloc will happily grab you 2Mb of space but it will not be physically linear - To unsubscribe from this list: send the line "unsubscribe

Re: kmalloc() allocation.

"Richard B. Johnson" wrote: > > On Mon, 30 Oct 2000, Jeff Garzik wrote: > > > "Richard B. Johnson" wrote: > > > Now, I could set up a linked-list of buffers and use vmalloc() > > > if the buffers were allocated from non-paged RAM. I don't think > > > they are. These buffers must be present

Re: kmalloc() allocation.

On Mon, 30 Oct 2000, Jeff Garzik wrote: > Tigran Aivazian wrote: > > > > On Mon, 30 Oct 2000, Jeff Garzik wrote: > > > > > "Richard B. Johnson" wrote: > > > > Now, I could set up a linked-list of buffers and use vmalloc() > > > > if the buffers were allocated from non-paged RAM. I don't think

Re: kmalloc() allocation.

On Mon, 30 Oct 2000, Jeff Garzik wrote: > "Richard B. Johnson" wrote: > > Now, I could set up a linked-list of buffers and use vmalloc() > > if the buffers were allocated from non-paged RAM. I don't think > > they are. These buffers must be present during an interrupt. > > Non-paged RAM? I'm

Re: kmalloc() allocation.

On Mon, 30 Oct 2000, Tigran Aivazian wrote: > On Mon, 30 Oct 2000, Richard B. Johnson wrote: > > > So, if you don't need physically contiguous (and fast) allocations perhaps > > > you could make use of vmalloc()/vfree() instead? There must be also some > > > "exotic" allocation APIs like bootmem

Re: kmalloc() allocation.

Tigran Aivazian wrote: > > On Mon, 30 Oct 2000, Jeff Garzik wrote: > > > "Richard B. Johnson" wrote: > > > Now, I could set up a linked-list of buffers and use vmalloc() > > > if the buffers were allocated from non-paged RAM. I don't think > > > they are. These buffers must be present during an

Re: kmalloc() allocation.

On Mon, 30 Oct 2000, Jeff Garzik wrote: > "Richard B. Johnson" wrote: > > Now, I could set up a linked-list of buffers and use vmalloc() > > if the buffers were allocated from non-paged RAM. I don't think > > they are. These buffers must be present during an interrupt. > > Non-paged RAM? I'm

Re: kmalloc() allocation.

"Richard B. Johnson" wrote: > Now, I could set up a linked-list of buffers and use vmalloc() > if the buffers were allocated from non-paged RAM. I don't think > they are. These buffers must be present during an interrupt. Non-paged RAM? I'm not sure what you mean by that. Both kmalloc and

Re: kmalloc() allocation.

On Mon, 30 Oct 2000, John Levon wrote: > On Mon, 30 Oct 2000, Richard B. Johnson wrote: > > > > > Hello, > > How much memory would it be reasonable for kmalloc() to be able > > to allocate to a module? > > > > Oct 30 10:48:31 chaos kernel: kmalloc: Size (524288) too large > > > > Using

Re: kmalloc() allocation.

On Mon, 30 Oct 2000, Richard B. Johnson wrote: > How much memory would it be reasonable for kmalloc() to be able > to allocate to a module? > There are 256 megabytes of SDRAM available. I don't think it's > reasonable that a 1/2 megabyte allocation would fail, especially > since it's the first

Re: kmalloc() allocation.

On Mon, 30 Oct 2000, Tigran Aivazian wrote: > Hi Dick, > > Sorry, I thought you knew this already :) The maximum for kmalloc is 128K > and is defined in mm/slab.c. It is trivial to "enhance" slab.c to support > more but it is in practice not very useful because requesting too much >

  1   2   >