Re: [PATCH v2] Add support for usbfs zerocopy.

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

Re: [PATCH v2] Add support for usbfs zerocopy.

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

Re: [PATCH] Modify UEFI anti-bricking code

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/

Re: [PATCH] Modify UEFI anti-bricking code

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/

Re: 3.9.0: panic during boot - kernel BUG at include/linux/gfp.h:323!

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

Re: 3.9.0: panic during boot - kernel BUG at include/linux/gfp.h:323!

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

Re: 3.9.0: panic during boot - kernel BUG at include/linux/gfp.h:323!

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.

Re: 3.9.0: panic during boot - kernel BUG at include/linux/gfp.h:323!

, this panic no longer happens. - After sed -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

[PATCH] efivarfs: Never return ENOENT from firmware again

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 | 14

[PATCH] efivarfs: Never return ENOENT from firmware again

specific code. Also return EOF for reading zero-length files, which is what users would expect. Cc: Josh Boyer jwbo...@redhat.com Cc: Jeremy Kerr j...@ozlabs.org Cc: Lee, Chun-Yi j...@suse.com Cc: Andy Whitcroft a...@canonical.com Signed-off-by: Lingzhu Xiang lxi...@redhat.com

BUG in __mem_cgroup_uncharge_common

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]

BUG in __mem_cgroup_uncharge_common

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]

Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

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

Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

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

Re: [PATCH V6 3/3] efi: Distinguish between "remaining space" and actually used space

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

Re: [PATCH V6 3/3] efi: Distinguish between remaining space and actually used space

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

Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

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

Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

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 06:33 PM, Luis Henriques wrote

Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

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.

Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

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.

Re: [PATCH V4 1/3] efi: Determine how much space is used by boot services-only variables

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? Lingzhu Xiang

Re: [PATCH V4 1/3] efi: Determine how much space is used by boot services-only variables

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

Re: [PATCH V4 1/3] efi: Determine how much space is used by boot services-only variables

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

Re: [PATCH V4 1/3] efi: Determine how much space is used by boot services-only variables

? 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/

Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

e 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: Matt Flemi

Re: [PATCH 3/3] efi: Distinguish between "remaining space" and actually used space

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 -

Re: [PATCH 3/3] efi: Distinguish between remaining space and actually used space

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 -

Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

...@suse.com Cc: Lingzhu Xiang lxi...@redhat.com Cc: Seiji Aguchi seiji.agu...@hds.com Signed-off-by: Matt Fleming matt.flem...@intel.com [ Backported for 3.4-stable. Removed workqueue code added in a93bc0c 3.9-rc1. ] [...] I thought the workqueue addition was a worthwhile fix in its own right, so

Re: [PATCH] efivarfs: fix abnormal GUID in variable name by using strcpy to replace null with dash

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) > +

Re: [PATCH] efivarfs: fix abnormal GUID in variable name by using strcpy to replace null with dash

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) + len

Re: [PATCH] efivarfs: fix abnormal GUID in variable name by using strcpy to replace null with dash

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 this list: send the line "unsubscribe linux

Re: [PATCH] efivarfs: fix abnormal GUID in variable name by using strcpy to replace null with dash

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 this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: [RFC] efivars write(2) races

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

Re: [RFC] efivars write(2) races

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 still read its content. I'm not sure what you mean

Re: [RFC] efivars write(2) races

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

Re: [RFC] efivars write(2) races

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

Re: [RFC] efivars write(2) races

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

Re: [RFC] efivars write(2) races

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 grabs