lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTi=f0Am-iMZM=xU5_Hqw4ni1effrqhUxpKE9opFj@mail.gmail.com>
Date:	Mon, 6 Sep 2010 14:33:42 +0200
From:	Martin Fuzzey <mfuzzey@...il.com>
To:	Prabhu Chawandi <prabhu.chavandi@...il.com>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org, kernelnewbies@...linux.org
Subject: Re: Crash on reducing the kernel mem.

On Mon, Sep 6, 2010 at 12:47 PM, Prabhu Chawandi
<prabhu.chavandi@...il.com> wrote:
> Hi Greg,
>
>  I am specifying the memory as part of command line parameter "mem=".
> I know only that what ever amount specify against "mem=" will be a
> kernel memory and rest is used for the drivers.
>
No it doesn't work like that.

Setting mem= will reduce the total amount of memory used.
If your system has 256M and you specify mem=128M the result
is that the other 128M is unused.

The kernel makes no separation between "kernel" and "drivers".
Drivers are part of the kernel (ie they live in the same address
space and can touch any memory).

There is a separation between kernel and userspace (ie
userspace processes cannot touch each others memory nor kernel
memory). However even the "userspace memory" comes from
the same "pool" reduced by mem=.

So when you changed mem=128M to mem=110M (intending
to give more memory to "drivers") what you actually did was
to reduce the memory available to the system. If that causes
a crash its likely just not enough memory available, probably
nothing specific to USB just that's where it happens to run out.

Why are you reducing memory in this way?
Normally the bootloader knows / detects how much memory
is available and informs the kernel. Reducing it is generally
only done for testing purposes (such as the case where you
have a development board that has more memory than the
production unit will so you artificially reduce the available
memory to see how it will behave on a production board).

Hope this helps,

Regards,
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ