On Wed, Nov 25, 2015 at 7:19 PM, Steinar H. Gunderson wrote:
> Add a new interface for userspace to preallocate memory that can be
> used with usbfs. This gives two primary benefits:
I got this when trying to allocate a little bit large buffer (~4MB)
using the new userspace libusb_dev_mem_alloc()
time garbage collection also works. But the write takes 5 seconds.
Lingzhu Xiang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 05/15/2013 02:35 AM, Tejun Heo wrote:
Hello,
On Tue, May 14, 2013 at 11:35:29AM +0800, Lingzhu Xiang wrote:
On 05/06/2013 03:55 PM, CAI Qian wrote:
[0.928031] [ cut here ]
[0.934231] kernel BUG at include/linux/gfp.h:323!
...
[1.662913
d -i s/for_each_node/for_each_online_node/ kernel/workqueue.c,
panic no longer happens.
Lingzhu Xiang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.
specific code. Also return EOF
for reading zero-length files, which is what users would expect.
Cc: Josh Boyer
Cc: Jeremy Kerr
Cc: Lee, Chun-Yi
Cc: Andy Whitcroft
Signed-off-by: Lingzhu Xiang
---
This is to be applied against mainline or Matt Fleming's chainsaw branch.
fs/efivarfs/file.c
Hit VM_BUG_ON(PageSwapCache(page)) in mm/memcontrol.c twice with 3.9-rc8
and 3.7.6 during LTP run on ppc64 machines.
[ 9699.793674] [ cut here ]
[ 9699.793719] kernel BUG at mm/memcontrol.c:3994!
[ 9699.793745] Oops: Exception in kernel mode, sig: 5 [#1]
[ 9699.793756]
On 04/17/2013 09:28 PM, Luis Henriques wrote:
> On Wed, Apr 17, 2013 at 08:13:57PM +0800, Lingzhu Xiang wrote:
>> On 04/17/2013 07:56 PM, Andy Whitcroft wrote:
>>> On Wed, Apr 17, 2013 at 12:37:43PM +0800, Lingzhu Xiang wrote:
>>>> On 04/16/2013
On 04/17/2013 07:56 PM, Andy Whitcroft wrote:
On Wed, Apr 17, 2013 at 12:37:43PM +0800, Lingzhu Xiang wrote:
On 04/16/2013 06:33 PM, Luis Henriques wrote:
68d929862e29a8b52a7f2f2f86a0600423b093cd efi: be more paranoid about available
space when creating variables
This prevents a bricking
On 04/16/2013 04:09 AM, Matthew Garrett wrote:
EFI implementations distinguish between space that is actively used by a
variable and space that merely hasn't been garbage collected yet. Space
that hasn't yet been garbage collected isn't available for use and so isn't
counted in the remaining_spac
On 04/16/2013 06:33 PM, Luis Henriques wrote:
68d929862e29a8b52a7f2f2f86a0600423b093cd efi: be more paranoid about available
space when creating variables
This prevents a bricking issue for some Samsung devices but causes
regression on many other machines.
https://bugzilla.kernel.org/show_b
s.
Since QueryVariableInfo is no longer trusted and the accounting is done
by the kernel, I'm somewhat concerned that variables can be repeatedly
created and deleted until nvram is full of garbage to collect and the
firmware hits EFI_OUT_OF_RESOURCES. Could this be any kind of problem?
Ling
On 04/11/2013 01:46 AM, Matthew Garrett wrote:
ops.query_variable_store = efi_query_variable_store;
Can't apply here. ops.query_variable_info = efi.query_variable_info?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
er than the
length of VariableName.
Since VariableName is a string, we can calculate its size by searching
for the terminating NULL character.
Reported-by: Frederic Crozat
Cc: Matthew Garrett
Cc: Josh Boyer
Cc: Michael Schroeder
Cc: Lee, Chun-Yi
Cc: Lingzhu Xiang
Cc: Seiji Aguchi
Signed-off-by:
On 04/10/2013 10:41 AM, Matthew Garrett wrote:
+ if (!storage_size || size > remaining_size ||
+ ((active_size + size + VAR_METADATA_SIZE > storage_size / 2) &&
+(remaining_size - size - VAR_METADATA_SIZE < storage_size / 2)))
This could overflow.
(u64)32768 - (u64)
On 03/06/2013 03:34 PM, joeyli wrote:
> +static unsigned long variable_name_length(efi_char16_t *variable_name)
> +{
> + unsigned long len;
> + efi_char16_t c;
> +
> + len = 2;
> + do {
> + c = variable_name[len / sizeof(c) - 1];
> + if (c)
> +
able_name actually is, wouldn't new_efivar->var.VariableName
also gets filled with trailing garbage?
In efivar_store_raw the VariableName's trailing garbage can cause
problem for comparison. You might want to also cover that or fix
variable_name_size.
Lingzhu Xiang
--
To unsubscribe from thi
On 01/28/2013 08:38 PM, Matt Fleming wrote:
> On Mon, 2013-01-28 at 10:38 +0800, Lingzhu Xiang wrote:
>> On 01/25/2013 09:18 PM, Matt Fleming wrote:
>>>> 4. EFI_VARIABLE_APPEND_WRITE with EFI_OUT_OF_RESOURCES truncates size but
>>>> you
>>>> can
On 01/25/2013 09:18 PM, Matt Fleming wrote:
4. EFI_VARIABLE_APPEND_WRITE with EFI_OUT_OF_RESOURCES truncates size but you
can still read its content.
I'm not sure what you mean by this. Could you please explain?
Oops, this one is incorrect. I was testing EFI_VARIABLE_APPEND_WRITE
using th
On 01/25/2013 08:25 AM, Al Viro wrote:
> 1) process A does write() on efivars file, reaches ->get_variable(),
> gets newdatasize set, drops efivars->lock and loses CPU before an attempt to
> grab ->i_mutex. process B comes and does the same thing, replacing the
> variable contents. Then it
19 matches
Mail list logo
