Re: [PATCH] firmware-gsmi: Delete an unnecessary check before the function call "dma_pool_destroy"

On Mon, Aug 1, 2016 at 5:04 AM, Matt Fleming wrote: > > On Sun, 24 Jul, at 10:27:49AM, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Sun, 24 Jul 2016 10:16:56 +0200 > > > > The dma_pool_destroy() function tests whether its

Re: [PATCH] firmware-gsmi: Delete an unnecessary check before the function call "dma_pool_destroy"

On Mon, Aug 1, 2016 at 5:04 AM, Matt Fleming wrote: > > On Sun, 24 Jul, at 10:27:49AM, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Sun, 24 Jul 2016 10:16:56 +0200 > > > > The dma_pool_destroy() function tests whether its argument is NULL > > and then returns immediately. Thus the

Re: Purpose of dmi-sysfs kernel module

Hi Jean, On Wed, May 14, 2014 at 12:23 PM, Jean Delvare wrote: > Hi Mike, > > On Wed, 14 May 2014 08:52:36 -0700, Mike Waychison wrote: >> On Wed, May 14, 2014 at 2:23 AM, Jean Delvare wrote: >> > Sorry for joining the party a little late but I am just discovering t

Re: Purpose of dmi-sysfs kernel module

Hi Jean, On Wed, May 14, 2014 at 2:23 AM, Jean Delvare wrote: > Hi Mike, Bjorn, > > Sorry for joining the party a little late but I am just discovering the > dmi-sysfs kernel module. I have to admit that I am very curious about > why it was needed. What does it let you achieve that you couldn't

Re: Purpose of dmi-sysfs kernel module

Hi Jean, On Wed, May 14, 2014 at 2:23 AM, Jean Delvare jdelv...@suse.de wrote: Hi Mike, Bjorn, Sorry for joining the party a little late but I am just discovering the dmi-sysfs kernel module. I have to admit that I am very curious about why it was needed. What does it let you achieve that

Re: Purpose of dmi-sysfs kernel module

Hi Jean, On Wed, May 14, 2014 at 12:23 PM, Jean Delvare jdelv...@suse.de wrote: Hi Mike, On Wed, 14 May 2014 08:52:36 -0700, Mike Waychison wrote: On Wed, May 14, 2014 at 2:23 AM, Jean Delvare jdelv...@suse.de wrote: Sorry for joining the party a little late but I am just discovering

Re: [PATCH 0/2] Google firmware driver updates

Thanks Michel! Acked-by: Mike Waychison On Tue, Jan 28, 2014 at 5:06 AM, Michel Lespinasse wrote: > Two small fixes for google firmware drivers. > > The patches are against v3.13; I am proposing this for inclusion to v3.14. > > Michel Lespinasse (2): > firmware: fix goo

Re: [PATCH 0/2] Google firmware driver updates

Thanks Michel! Acked-by: Mike Waychison mi...@google.com On Tue, Jan 28, 2014 at 5:06 AM, Michel Lespinasse wal...@google.com wrote: Two small fixes for google firmware drivers. The patches are against v3.13; I am proposing this for inclusion to v3.14. Michel Lespinasse (2): firmware

Re: [PATCH] firmware/google: drop 'select EFI' to avoid recursive dependency

t results in a recursive dependency: >> >> arch/arm/Kconfig:1845:error: recursive dependency detected! >> arch/arm/Kconfig:1845:symbol DMI depends on EFI >> >> Fix by changing the 'select EFI' to a 'depends on EFI'. >> >> Signed-off-by: Ard Biesheuvel Ack

Re: [PATCH] firmware/google: drop 'select EFI' to avoid recursive dependency

in a recursive dependency: arch/arm/Kconfig:1845:error: recursive dependency detected! arch/arm/Kconfig:1845:symbol DMI depends on EFI Fix by changing the 'select EFI' to a 'depends on EFI'. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Acked-by: Mike Waychison mi...@google.com

Re: [PATCH 2/6] efivars: Keep a private global pointer to efivars

s. > > Note that because of the Kconfig rules, we don't need to use any kind of > synchronisation primitive in register_efivars() - it's not possible to compile > more than one set of EFI variable operations into the kernel. > > Cc: Tom Gundersen > Cc: Mike Waychison > Si

Re: [PATCH 1/6] efi: move utf16 string functions to efi.h

fwiw, I was tempted to rename these to ucs2_*() last time I was here. Reviewed-by: Mike Waychison On Thu, Apr 4, 2013 at 5:18 AM, Matt Fleming wrote: > From: Matt Fleming > > There are currently two implementations of the utf16 string functions. > Somewhat confusingly, they've g

Re: [PATCH 1/6] efi: move utf16 string functions to efi.h

fwiw, I was tempted to rename these to ucs2_*() last time I was here. Reviewed-by: Mike Waychison mi...@google.com On Thu, Apr 4, 2013 at 5:18 AM, Matt Fleming m...@console-pimps.org wrote: From: Matt Fleming matt.flem...@intel.com There are currently two implementations of the utf16 string

Re: [PATCH 2/6] efivars: Keep a private global pointer to efivars

rules, we don't need to use any kind of synchronisation primitive in register_efivars() - it's not possible to compile more than one set of EFI variable operations into the kernel. Cc: Tom Gundersen t...@jklm.no Cc: Mike Waychison mi...@google.com Signed-off-by: Matt Fleming matt.flem

Re: [RESEND][PATCH v4 0/7] efi_pstore: multiple event logging support

Series Acked-by: Mike Waychison Tony: Did you want to pull this? On Thu, Nov 1, 2012 at 3:59 PM, Seiji Aguchi wrote: > Changelog > > v3 -> v4 >- Rebase to 3.7-rc3 >- Add ctime to an argument of efi_pstore_erase to build successfully > in case where CONFIG

Re: [RESEND][PATCH v4 0/7] efi_pstore: multiple event logging support

Series Acked-by: Mike Waychison mi...@google.com Tony: Did you want to pull this? On Thu, Nov 1, 2012 at 3:59 PM, Seiji Aguchi seiji.agu...@hds.com wrote: Changelog v3 - v4 - Rebase to 3.7-rc3 - Add ctime to an argument of efi_pstore_erase to build successfully in case where

Re: [PATCH] Add a page cache-backed balloon device driver.

On Tue, Oct 30, 2012 at 8:29 AM, Michael S. Tsirkin wrote: > On Tue, Sep 11, 2012 at 12:10:18AM +0300, Michael S. Tsirkin wrote: >> > On the plus side, having an exit taken here on each page turns out to >> > be relatively cheap, as the vmexit from the page fault should be >> > faster to process

Re: [PATCH] Add a page cache-backed balloon device driver.

On Tue, Oct 30, 2012 at 8:29 AM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Sep 11, 2012 at 12:10:18AM +0300, Michael S. Tsirkin wrote: On the plus side, having an exit taken here on each page turns out to be relatively cheap, as the vmexit from the page fault should be faster to

Re: [PATCH v3 7/7] Add a format check for an existing variable name at erasing time

On Fri, Oct 26, 2012 at 2:43 PM, Seiji Aguchi wrote: > [Issue] > > A format of variable name has been updated to type, id, count and ctime > to support holding multiple logs. > > Format of current variable name > dump-type0-1-2-12345678 > > type:0 > id:1 > count:2 > ctime:12345678 > >

Re: [PATCH v3 6/7] efi_pstore: Add a format check for an existing variable name at reading time

On Fri, Oct 26, 2012 at 2:43 PM, Seiji Aguchi wrote: > [Issue] > > A format of variable name has been updated to type, id, count and ctime > to support holding multiple logs. > > Format of current variable name > dump-type0-1-2-12345678 > > type:0 > id:1 > count:2 > ctime:12345678 > >

Re: [PATCH v3 6/7] efi_pstore: Add a format check for an existing variable name at reading time

On Fri, Oct 26, 2012 at 2:43 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Issue] A format of variable name has been updated to type, id, count and ctime to support holding multiple logs. Format of current variable name dump-type0-1-2-12345678 type:0 id:1 count:2

Re: [PATCH v3 7/7] Add a format check for an existing variable name at erasing time

On Fri, Oct 26, 2012 at 2:43 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Issue] A format of variable name has been updated to type, id, count and ctime to support holding multiple logs. Format of current variable name dump-type0-1-2-12345678 type:0 id:1 count:2

Re: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs

On Thu, Oct 25, 2012 at 1:51 PM, Seiji Aguchi wrote: >> So doesn't this break erasing of existing dumps in pstore-efivars? >> Unless efi_pstore_read still understands the older variable name formats, >> users will be stranded with dumps consuming space in >> efivars that aren't exported via

Re: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs

On Thu, Oct 25, 2012 at 1:03 PM, Seiji Aguchi wrote: >> > - list_del(>list); >> > + sprintf(name, "dump-type%u-%u-%lu", type, part, >> > + get_seconds()); >> >> Actually, nothing seems to be ensuring that the value used here ends up >> being the same as the

Re: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs

On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi wrote: > [Issue] > > Currently, efi_pstore driver simply overwrites existing panic messages in > NVRAM. > So, in the following scenario, we will lose 1st panic messages. > > 1. kernel panics. > 2. efi_pstore is kicked and writes panic messages to

Re: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs

Acked-by: Mike Waychison On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi wrote: > [Issue] > > Currently, efi_pstore driver simply overwrites existing panic messages in > NVRAM. > So, in the following scenario, we will lose 1st panic messages. > > 1. kernel panics. >

Re: [PATCH v2 1/5] efi_pstore: Check remaining space with QueryVariableInfo() before writing data

Acked-by: Mike Waychison On Wed, Oct 24, 2012 at 6:51 PM, Seiji Aguchi wrote: > [Issue] > > As discussed in a thread below, Running out of space in EFI isn't a > well-tested scenario. > And we wouldn't expect all firmware to handle it gracefully. > http://marc.in

Re: [PATCH v2 1/5] efi_pstore: Check remaining space with QueryVariableInfo() before writing data

Acked-by: Mike Waychison mi...@google.com On Wed, Oct 24, 2012 at 6:51 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Issue] As discussed in a thread below, Running out of space in EFI isn't a well-tested scenario. And we wouldn't expect all firmware to handle it gracefully. http

Re: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs

Acked-by: Mike Waychison mi...@google.com On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Issue] Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM. So, in the following scenario, we will lose 1st panic messages. 1. kernel panics. 2

Re: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs

On Wed, Oct 24, 2012 at 6:54 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Issue] Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM. So, in the following scenario, we will lose 1st panic messages. 1. kernel panics. 2. efi_pstore is kicked and writes panic

Re: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs

On Thu, Oct 25, 2012 at 1:03 PM, Seiji Aguchi seiji.agu...@hds.com wrote: - list_del(found-list); + sprintf(name, dump-type%u-%u-%lu, type, part, + get_seconds()); Actually, nothing seems to be ensuring that the value used here ends up being the same as

Re: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from a write callback to hold multiple logs

On Thu, Oct 25, 2012 at 1:51 PM, Seiji Aguchi seiji.agu...@hds.com wrote: So doesn't this break erasing of existing dumps in pstore-efivars? Unless efi_pstore_read still understands the older variable name formats, users will be stranded with dumps consuming space in efivars that aren't

Re: [RFC][PATCH 2/2] efi_pstore: add a sequence counter to a variable name

On Fri, Oct 5, 2012 at 12:02 PM, Seiji Aguchi wrote: > [Problem] > > Currently, a variable name, which distinguishes each entry, consists of type, > id and ctime. > But if multiple events happens in a short time, a second/third event may fail > to log because > efi_pstore can't distinguish each

Re: [RFC][PATCH 1/2] efi_pstore: hold multiple logs

Resending as text. See below. On Fri, Oct 5, 2012 at 12:01 PM, Seiji Aguchi wrote: > [Problem] > > Currently, efi_pstore driver simply overwrites existing panic messages in > NVRAM. > So, in the following scenario, we will lose 1st panic messages. > > 1. kernel panics. > 2.

Re: [RFC][PATCH 1/2] efi_pstore: hold multiple logs

Resending as text. See below. On Fri, Oct 5, 2012 at 12:01 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Problem] Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM. So, in the following scenario, we will lose 1st panic messages. 1. kernel panics.

Re: [RFC][PATCH 2/2] efi_pstore: add a sequence counter to a variable name

On Fri, Oct 5, 2012 at 12:02 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Problem] Currently, a variable name, which distinguishes each entry, consists of type, id and ctime. But if multiple events happens in a short time, a second/third event may fail to log because efi_pstore can't

Re: [PATCH] Add a page cache-backed balloon device driver.

On Mon, Sep 10, 2012 at 3:59 PM, Michael S. Tsirkin wrote: > On Mon, Sep 10, 2012 at 01:37:06PM -0400, Mike Waychison wrote: >> On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin wrote: >> > On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote: >> >> T

Re: [PATCH] Add a page cache-backed balloon device driver.

On Mon, Sep 10, 2012 at 2:04 PM, Rik van Riel wrote: > On 09/10/2012 01:37 PM, Mike Waychison wrote: >> >> On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin >> wrote: > > >>> Also can you pls answer Avi's question? >>> How is overcommit ma

Re: [PATCH v2] Add missing attributes to EFI variable attribute print out from sysfs

On Mon, Sep 10, 2012 at 1:55 PM, Mike Waychison wrote: > Greg, > > Can you please pick this patch up in one of your trees? Resend using a good email addy for gregkh :) > > Thanks! > > Mike Waychison > > On Fri, Jul 13, 2012 at 1:42 PM, Khalid Aziz wrote: >> So

Re: [PATCH v2] Add missing attributes to EFI variable attribute print out from sysfs

Greg, Can you please pick this patch up in one of your trees? Thanks! Mike Waychison On Fri, Jul 13, 2012 at 1:42 PM, Khalid Aziz wrote: > Some of the EFI variable attributes are missing from print out from > /sys/firmware/efi/vars/*/attributes. This patch adds those in. It also >

Re: [PATCH] Add a page cache-backed balloon device driver.

On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin wrote: > On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote: >> This implementation of a virtio balloon driver uses the page cache to >> "store" pages that have been released to the host. The communication >> (outside of target

Re: [PATCH] Add a page cache-backed balloon device driver.

On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote: This implementation of a virtio balloon driver uses the page cache to store pages that have been released to the host. The communication (outside of

Re: [PATCH v2] Add missing attributes to EFI variable attribute print out from sysfs

Greg, Can you please pick this patch up in one of your trees? Thanks! Mike Waychison On Fri, Jul 13, 2012 at 1:42 PM, Khalid Aziz khalid.a...@hp.com wrote: Some of the EFI variable attributes are missing from print out from /sys/firmware/efi/vars/*/attributes. This patch adds those

Re: [PATCH v2] Add missing attributes to EFI variable attribute print out from sysfs

On Mon, Sep 10, 2012 at 1:55 PM, Mike Waychison mi...@google.com wrote: Greg, Can you please pick this patch up in one of your trees? Resend using a good email addy for gregkh :) Thanks! Mike Waychison On Fri, Jul 13, 2012 at 1:42 PM, Khalid Aziz khalid.a...@hp.com wrote: Some

Re: [PATCH] Add a page cache-backed balloon device driver.

On Mon, Sep 10, 2012 at 2:04 PM, Rik van Riel r...@redhat.com wrote: On 09/10/2012 01:37 PM, Mike Waychison wrote: On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin m...@redhat.com wrote: Also can you pls answer Avi's question? How is overcommit managed? Overcommit in our deployments

Re: [PATCH] Add a page cache-backed balloon device driver.

On Mon, Sep 10, 2012 at 3:59 PM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Sep 10, 2012 at 01:37:06PM -0400, Mike Waychison wrote: On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote

Re: [RFC][PATCH v3 2/3] efi_pstore: Introducing workqueue updating sysfs entries

On Tue, Aug 21, 2012 at 9:54 AM, Seiji Aguchi wrote: > [Problem] > efi_pstore creates sysfs entries ,which enable users to access to NVRAM, > in a write callback. If a kernel panic happens in interrupt contexts, > pstore may > fail because it could sleep due to dynamic memory allocations

Re: [RFC][PATCH v3 2/3] efi_pstore: Introducing workqueue updating sysfs entries

On Tue, Aug 21, 2012 at 9:54 AM, Seiji Aguchi seiji.agu...@hds.com wrote: [Problem] efi_pstore creates sysfs entries ,which enable users to access to NVRAM, in a write callback. If a kernel panic happens in interrupt contexts, pstore may fail because it could sleep due to dynamic

Re: [RFC][PATCH v2 3/3] efi_pstore: Skip scheduling a workqueue in cases other than oops

On Mon, Aug 20, 2012 at 12:15 PM, Seiji Aguchi wrote: > [Problem] > efi_pstore creates sysfs files when logging kernel messages to NVRAM. > Currently, the sysfs files are updated in a workqueue which is registered in > a write callback. > > On the other hand, a situation which users need the

Re: [RFC][PATCH v2 2/3] efi_pstore: Introducing workqueue updating sysfs entries

On Mon, Aug 20, 2012 at 12:15 PM, Seiji Aguchi wrote: > [Problem] > efi_pstore creates sysfs entries ,which enable users to access to NVRAM, > in a write callback. If a kernel panic happens in interrupt contexts, > pstore may > fail because it could sleep due to dynamic memory allocations

Re: [RFC][PATCH v2 1/3] efivars: Disable external interrupt while holding efivars->lock

Acked-by: Mike Waychison > @@ -1101,11 +1107,12 @@ out_free: > void unregister_efivars(struct efivars *efivars) > { > struct efivar_entry *entry, *n; > + unsigned long flags; > > list_for_each_entry_safe(entry, n, >list, list) { > -

Re: [RFC][PATCH v2 1/3] efivars: Disable external interrupt while holding efivars-lock

Acked-by: Mike Waychison mi...@google.com @@ -1101,11 +1107,12 @@ out_free: void unregister_efivars(struct efivars *efivars) { struct efivar_entry *entry, *n; + unsigned long flags; list_for_each_entry_safe(entry, n, efivars-list, list) { - spin_lock

Re: [RFC][PATCH v2 2/3] efi_pstore: Introducing workqueue updating sysfs entries

On Mon, Aug 20, 2012 at 12:15 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Problem] efi_pstore creates sysfs entries ,which enable users to access to NVRAM, in a write callback. If a kernel panic happens in interrupt contexts, pstore may fail because it could sleep due to dynamic

Re: [RFC][PATCH v2 3/3] efi_pstore: Skip scheduling a workqueue in cases other than oops

On Mon, Aug 20, 2012 at 12:15 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Problem] efi_pstore creates sysfs files when logging kernel messages to NVRAM. Currently, the sysfs files are updated in a workqueue which is registered in a write callback. On the other hand, a situation which

Re: [RFC][PATCH 2/2] efi_pstore: Introducing workqueue updating sysfs entries

On Fri, Aug 17, 2012 at 2:15 PM, Seiji Aguchi wrote: > >> I'm not a fan of creating a periodic timer that wakes up here to check for >> an event that should be considered very rare. >> >> Can this just become scheduled work? Scheduling work itself is a very >> lightweight process and should be

Re: [RFC][PATCH 2/2] efi_pstore: Introducing workqueue updating sysfs entries

On Fri, Aug 17, 2012 at 12:43 PM, Seiji Aguchi wrote: > [Problem] > efi_pstore creates sysfs entries ,which enable users to access to NVRAM, > in a write callback. If a kernel panic happens in interrupt contexts, pstore > may > fail because it could sleep due to dynamic memory allocations

Re: [RFC][PATCH 1/2] efivars: Disable external interrupt while holding efivars->lock

On Fri, Aug 17, 2012 at 12:42 PM, Seiji Aguchi wrote: > [Problem] > Currently, efivars doesn't disable interrupt while taking efivars->lock. > So, there is a risk to be deadlocking in a write callback of efi_pstore > if kernel panics in interrupt context while taking efivars->lock. > > [Patch

Re: [RFC][PATCH 1/2] efivars: Disable external interrupt while holding efivars-lock

On Fri, Aug 17, 2012 at 12:42 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Problem] Currently, efivars doesn't disable interrupt while taking efivars-lock. So, there is a risk to be deadlocking in a write callback of efi_pstore if kernel panics in interrupt context while taking

Re: [RFC][PATCH 2/2] efi_pstore: Introducing workqueue updating sysfs entries

On Fri, Aug 17, 2012 at 12:43 PM, Seiji Aguchi seiji.agu...@hds.com wrote: [Problem] efi_pstore creates sysfs entries ,which enable users to access to NVRAM, in a write callback. If a kernel panic happens in interrupt contexts, pstore may fail because it could sleep due to dynamic memory

Re: [RFC][PATCH 2/2] efi_pstore: Introducing workqueue updating sysfs entries

On Fri, Aug 17, 2012 at 2:15 PM, Seiji Aguchi seiji.agu...@hds.com wrote: I'm not a fan of creating a periodic timer that wakes up here to check for an event that should be considered very rare. Can this just become scheduled work? Scheduling work itself is a very lightweight process and

Re: efi_pstore: question about how to remove create_sysfs_entry() from a write callback.

>> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Seiji Aguchi >> Sent: Tuesday, August 14, 2012 2:52 PM >> To: Mike Waychison >> Cc: linux-kernel@vger.kernel.org; Luck, Tony (tony.l...@intel.com); Matthew >> Garrett (m...@redhat.com); dzic...@r

Re: efi_pstore: question about how to remove create_sysfs_entry() from a write callback.

On Tue, Aug 14, 2012 at 9:05 AM, Seiji Aguchi wrote: > Hi, > > I'm sending an email to discuss how to remove create_sysfs_entry() from a > write callback. > > [Problem] > > Current efi_pstore creates sysfs entries ,which enable users to access to > NVRAM, in a write callback. > If a kernel

Re: efi_pstore: question about how to remove create_sysfs_entry() from a write callback.

On Tue, Aug 14, 2012 at 9:05 AM, Seiji Aguchi seiji.agu...@hds.com wrote: Hi, I'm sending an email to discuss how to remove create_sysfs_entry() from a write callback. [Problem] Current efi_pstore creates sysfs entries ,which enable users to access to NVRAM, in a write callback. If a

Re: efi_pstore: question about how to remove create_sysfs_entry() from a write callback.

-kernel-ow...@vger.kernel.org] On Behalf Of Seiji Aguchi Sent: Tuesday, August 14, 2012 2:52 PM To: Mike Waychison Cc: linux-kernel@vger.kernel.org; Luck, Tony (tony.l...@intel.com); Matthew Garrett (m...@redhat.com); dzic...@redhat.com; dle- deve...@lists.sourceforge.net; Satoru Moriya

Re: [patch] Converting writeback linked lists to a tree based data structure

sed into the the struct request's into the scheduler. Similar changes are underway for making sure all AIO get the right ioprios. It will take some cleaning to get it ready for lkml submission, though I'm still a bit unsure of what we should do to avoid struct page growth. Mike Waychison Andi Kleen wr

Re: [patch] Converting writeback linked lists to a tree based data structure

Fengguang Wu wrote: On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote: On Wed, 16 Jan 2008 12:55:07 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote: On Tue, Jan 15, 2008 at 08:42:36PM -0800, Andrew Morton wrote: On Wed, 16 Jan 2008 12:25:53 +0800 Fengguang Wu <[EMAIL PROTECTED]>

Re: [patch] Converting writeback linked lists to a tree based data structure

into the the struct request's into the scheduler. Similar changes are underway for making sure all AIO get the right ioprios. It will take some cleaning to get it ready for lkml submission, though I'm still a bit unsure of what we should do to avoid struct page growth. Mike Waychison Andi Kleen wrote

Re: [patch 0/6][RFC] Cleanup FIBMAP

rify what you mean above with an example? I don't really follow. Thanks, Mike Waychison - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Pleas

Re: [patch 0/6][RFC] Cleanup FIBMAP

ndicate your-data-is-here-but-isn't-alone. But that's more of a feature for the FIEMAP stuff. I hadn't heard of FIEMAP, so I went back and read the thread from April/May. It seems that this is a much better approach than introducing a FIBMAP64. What ever happened with this proposal? Mike Waychi

Re: [patch 0/6][RFC] Cleanup FIBMAP

-alone. But that's more of a feature for the FIEMAP stuff. I hadn't heard of FIEMAP, so I went back and read the thread from April/May. It seems that this is a much better approach than introducing a FIBMAP64. What ever happened with this proposal? Mike Waychison - To unsubscribe from this list

Re: [patch 0/6][RFC] Cleanup FIBMAP

above with an example? I don't really follow. Thanks, Mike Waychison - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

[patch 5/6][RFC] Introduce FIBMAP64

Introduce FIBMAP64. This is the same as FIBMAP, but takes a u64. This new routine requires filesystems to implement bmap64 if they want to support > 2^31 blocks in a logical file. We do this to give time for filesystems to be properly audited. Signed-off-by: Mike Waychison <[EMAIL PRO

[patch 2/6][RFC] Allow FIBMAP to return EFBIG on large filesystems.

Propagate an error (EFBIG) to userspace if the physical block is too large to return in a 32bit int instead of truncating it. Signed-off-by: Mike Waychison <[EMAIL PROTECTED]> fs/ioctl.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) Index: linux-2.6.23/fs/i

[patch 6/6][RFC] Drop CAP_SYS_RAWIO requirement on FIBMAP

Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. It would be nice to allow users to have permission to see where their data is landing on disk, and there really isn't a good reason to keep them from getting at this information. Signed-off-by: Mike

[patch 4/6][RFC] Attempt to plug race with truncate

Attempt to deal with races with truncate paths. I'm not really sure on the locking here, but these seem to be taken by the truncate path. BKL is left as some filesystem may(?) still require it. Signed-off-by: Mike Waychison <[EMAIL PROTECTED]> fs/ioctl.c |8 1 file chan

[patch 3/6][RFC] Move FIBMAP logic

Move FIBMAP logic out of file_ioctl() in preparation for introducing FIBMAP64. Signed-off-by: Mike Waychison <[EMAIL PROTECTED]> fs/ioctl.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) Index: linux-2.6.23/fs/i

[patch 1/6][RFC] Keep FIBMAP from looking at negative block nrs

Return an error if the user requests a negative logical block in a file. Signed-off-by: Mike Waychison <[EMAIL PROTECTED]> fs/ioctl.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6.23/fs/ioctl.c === --- linux-

[patch 0/6][RFC] Cleanup FIBMAP

of the locking in [4/6] fix_race_with_truncate.patch. Any help here would greatly be appreciated. The last patch, [6/6] drop_cap_sys_rawio_for_fibmap.patch, is of course, not to be applied until any remaining issues are fixed :) Thanks, Mike Waychison -- - To unsubscribe from this list: send

Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

Jason Uhlenkott wrote: On Fri, Oct 26, 2007 at 14:59:57 -0700, Mike Waychison wrote: Jason Uhlenkott wrote: Additionally, ext3_bmap() has this to say about it: if (EXT3_I(inode)->i_state & EXT3_STATE_JDATA) { /* * This is a REALLY heavyweight a

Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

Jason Uhlenkott wrote: On Fri, Oct 26, 2007 at 01:22:17 +0100, Alan Cox wrote: On Thu, 25 Oct 2007 16:06:40 -0700 Mike Waychison <[EMAIL PROTECTED]> wrote: Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. It would be nice to allow users t

Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

Jason Uhlenkott wrote: On Fri, Oct 26, 2007 at 01:22:17 +0100, Alan Cox wrote: On Thu, 25 Oct 2007 16:06:40 -0700 Mike Waychison [EMAIL PROTECTED] wrote: Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. It would be nice to allow users to have

Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

Jason Uhlenkott wrote: On Fri, Oct 26, 2007 at 14:59:57 -0700, Mike Waychison wrote: Jason Uhlenkott wrote: Additionally, ext3_bmap() has this to say about it: if (EXT3_I(inode)-i_state EXT3_STATE_JDATA) { /* * This is a REALLY heavyweight approach

[patch 0/6][RFC] Cleanup FIBMAP

of the locking in [4/6] fix_race_with_truncate.patch. Any help here would greatly be appreciated. The last patch, [6/6] drop_cap_sys_rawio_for_fibmap.patch, is of course, not to be applied until any remaining issues are fixed :) Thanks, Mike Waychison -- - To unsubscribe from this list: send

[patch 1/6][RFC] Keep FIBMAP from looking at negative block nrs

Return an error if the user requests a negative logical block in a file. Signed-off-by: Mike Waychison [EMAIL PROTECTED] fs/ioctl.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6.23/fs/ioctl.c === --- linux-2.6.23.orig

[patch 3/6][RFC] Move FIBMAP logic

Move FIBMAP logic out of file_ioctl() in preparation for introducing FIBMAP64. Signed-off-by: Mike Waychison [EMAIL PROTECTED] fs/ioctl.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) Index: linux-2.6.23/fs/ioctl.c

[patch 6/6][RFC] Drop CAP_SYS_RAWIO requirement on FIBMAP

Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. It would be nice to allow users to have permission to see where their data is landing on disk, and there really isn't a good reason to keep them from getting at this information. Signed-off-by: Mike

[patch 4/6][RFC] Attempt to plug race with truncate

Attempt to deal with races with truncate paths. I'm not really sure on the locking here, but these seem to be taken by the truncate path. BKL is left as some filesystem may(?) still require it. Signed-off-by: Mike Waychison [EMAIL PROTECTED] fs/ioctl.c |8 1 file changed, 8

[patch 5/6][RFC] Introduce FIBMAP64

Introduce FIBMAP64. This is the same as FIBMAP, but takes a u64. This new routine requires filesystems to implement bmap64 if they want to support 2^31 blocks in a logical file. We do this to give time for filesystems to be properly audited. Signed-off-by: Mike Waychison [EMAIL PROTECTED

[patch 2/6][RFC] Allow FIBMAP to return EFBIG on large filesystems.

Propagate an error (EFBIG) to userspace if the physical block is too large to return in a 32bit int instead of truncating it. Signed-off-by: Mike Waychison [EMAIL PROTECTED] fs/ioctl.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) Index: linux-2.6.23/fs/ioctl.c

Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

Alan Cox wrote: On Thu, 25 Oct 2007 16:06:40 -0700 Mike Waychison <[EMAIL PROTECTED]> wrote: Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. It would be nice to allow users to have permission to see where their data is landing o

[patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. It would be nice to allow users to have permission to see where their data is landing on disk, and there really isn't a good reason to keep them from getting at this information. Signed-off-by: Mike

[patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. It would be nice to allow users to have permission to see where their data is landing on disk, and there really isn't a good reason to keep them from getting at this information. Signed-off-by: Mike

Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

Alan Cox wrote: On Thu, 25 Oct 2007 16:06:40 -0700 Mike Waychison [EMAIL PROTECTED] wrote: Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. It would be nice to allow users to have permission to see where their data is landing on disk

Re: [patch] unexport __mntput()

Jan Engelhardt wrote: Nfsd uses it to serve up nfs exports that don't cross mountpoints (or do, if "crossmnt" is specified in /etc/exports. Is not this called nohide? On the command line it's a synonym, but the nfs-utils uses NFSEXP_CROSSMOUNT to tell the kernel. Mike

Re: [patch] unexport __mntput()

Jan Engelhardt wrote: Nfsd uses it to serve up nfs exports that don't cross mountpoints (or do, if crossmnt is specified in /etc/exports. Is not this called nohide? On the command line it's a synonym, but the nfs-utils uses NFSEXP_CROSSMOUNT to tell the kernel. Mike Waychison

Re: [patch] unexport __mntput()

ed in /etc/exports. Thanks, Mike Waychison Coywolf Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]> --- 2.6.13-rc6/fs/namespace.c~unexport-__mntput 2005-08-12 08:21:22.0 -0500 +++ 2.6.13-rc6/fs/namespace.c 2005-08-14 20:32:01.0 -0500

Re: [patch] unexport __mntput()

/exports. Thanks, Mike Waychison Coywolf Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED] --- 2.6.13-rc6/fs/namespace.c~unexport-__mntput 2005-08-12 08:21:22.0 -0500 +++ 2.6.13-rc6/fs/namespace.c 2005-08-14 20:32:01.0 -0500 @@ -180,8 +180,6

Re: [discuss] Re: 2.6.13-rc2 with dual way dual core ck804 MB

Andi Kleen wrote: On Wed, Aug 10, 2005 at 04:14:19PM -0700, Mike Waychison wrote: YhLu wrote: andi, please refer the patch, it will move cpu_set(, cpu_callin_map) from smi_callin to start_secondary. This patch fixes an apparent race / lockup on our 2-way dual cores (when applied against

Re: 2.6.13-rc2 with dual way dual core ck804 MB

YhLu wrote: andi, please refer the patch, it will move cpu_set(, cpu_callin_map) from smi_callin to start_secondary. This patch fixes an apparent race / lockup on our 2-way dual cores (when applied against 2.6.12.3). The machine was locking up after "Initializing CPU#2". Mike

Re: 2.6.13-rc2 with dual way dual core ck804 MB

YhLu wrote: andi, please refer the patch, it will move cpu_set(, cpu_callin_map) from smi_callin to start_secondary. This patch fixes an apparent race / lockup on our 2-way dual cores (when applied against 2.6.12.3). The machine was locking up after Initializing CPU#2. Mike Waychison

  1   2   >