Re: [PATCH v3 2/2] tpm: add support for nonblocking operation

On 6/12/18 10:58 AM, Tadeusz Struk wrote: Currently the TPM driver only supports blocking calls, which doesn't allow asynchronous IO operations to the TPM hardware. This patch changes it and adds support for nonblocking write and a new poll function to enable applications, which want to take

Re: [PATCH v3 2/2] tpm: add support for nonblocking operation

On 6/12/18 10:58 AM, Tadeusz Struk wrote: Currently the TPM driver only supports blocking calls, which doesn't allow asynchronous IO operations to the TPM hardware. This patch changes it and adds support for nonblocking write and a new poll function to enable applications, which want to take

Re: [PATCH V3 3/5 selinux-next] selinux: sidtab_clone switch to use rwlock.

+int sidtab_clone(struct sidtab *s, struct sidtab *d) +{ + int i, rc = 0; If s or d are NULL (see if() below), why would we want rc, the return value, to be 0?  How about defaulting rc to an error value (-EINVAL)? + struct sidtab_node *cur; + + if (!s || !d) +

Re: [PATCH V3 3/5 selinux-next] selinux: sidtab_clone switch to use rwlock.

+int sidtab_clone(struct sidtab *s, struct sidtab *d) +{ + int i, rc = 0; If s or d are NULL (see if() below), why would we want rc, the return value, to be 0?  How about defaulting rc to an error value (-EINVAL)? + struct sidtab_node *cur; + + if (!s || !d) +

Re: [PATCH v3 2/2] tpm: reduce polling time to usecs for even finer granularity

On 5/7/18 9:07 AM, Nayna Jain wrote: The TPM burstcount and status commands are supposed to return very quickly [2][3]. This patch further reduces the TPM poll sleep time to usecs in get_burstcount() and wait_for_tpm_stat() by calling usleep_range() directly. After this change, performance on

Re: [PATCH v3 2/2] tpm: reduce polling time to usecs for even finer granularity

On 5/7/18 9:07 AM, Nayna Jain wrote: The TPM burstcount and status commands are supposed to return very quickly [2][3]. This patch further reduces the TPM poll sleep time to usecs in get_burstcount() and wait_for_tpm_stat() by calling usleep_range() directly. After this change, performance on

Re: [PATCH v3 1/2] tpm: reduce poll sleep time in tpm_transmit()

do { - tpm_msleep(TPM_POLL_SLEEP); + tpm_msleep(TPM_TIMEOUT_POLL); I'm just curious why it was decided to still use tpm_msleep() here instead of usleep_range() which was used in the 2nd patch. Otherwise, Acked-by: Jay Freyensee

Re: [PATCH v3 1/2] tpm: reduce poll sleep time in tpm_transmit()

do { - tpm_msleep(TPM_POLL_SLEEP); + tpm_msleep(TPM_TIMEOUT_POLL); I'm just curious why it was decided to still use tpm_msleep() here instead of usleep_range() which was used in the 2nd patch. Otherwise, Acked-by: Jay Freyensee

Re: [PATCH 4/8] struct page: add field for vm_struct

On 3/15/18 2:38 AM, Igor Stoppa wrote: On 14/03/18 19:43, J Freyensee wrote: On 3/13/18 3:00 PM, Matthew Wilcox wrote: [...] Signed-off-by: Igor Stoppa <igor.sto...@huawei.com> Reviewed-by: Matthew Wilcox <mawil...@microsoft.com> Igor, do you mind sticking these tags

Re: [PATCH 4/8] struct page: add field for vm_struct

On 3/15/18 2:38 AM, Igor Stoppa wrote: On 14/03/18 19:43, J Freyensee wrote: On 3/13/18 3:00 PM, Matthew Wilcox wrote: [...] Signed-off-by: Igor Stoppa Reviewed-by: Matthew Wilcox Igor, do you mind sticking these tags on the files that have spent some time reviewing a revision of your

Re: [PATCH 4/8] struct page: add field for vm_struct

On 3/13/18 3:00 PM, Matthew Wilcox wrote: On Tue, Mar 13, 2018 at 11:45:50PM +0200, Igor Stoppa wrote: When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking

Re: [PATCH 4/8] struct page: add field for vm_struct

On 3/13/18 3:00 PM, Matthew Wilcox wrote: On Tue, Mar 13, 2018 at 11:45:50PM +0200, Igor Stoppa wrote: When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking

Re: [PATCH 5/8] Protectable Memory

+struct pmalloc_data { + struct gen_pool *pool; /* Link back to the associated pool. */ + bool protected; /* Status of the pool: RO or RW. */ + struct kobj_attribute attr_protected; /* Sysfs attribute. */ + struct kobj_attribute attr_avail; /* Sysfs attribute.

Re: [PATCH 5/8] Protectable Memory

+struct pmalloc_data { + struct gen_pool *pool; /* Link back to the associated pool. */ + bool protected; /* Status of the pool: RO or RW. */ + struct kobj_attribute attr_protected; /* Sysfs attribute. */ + struct kobj_attribute attr_avail; /* Sysfs attribute.

Re: [PATCH v3 3/5] tpm: migrate tpm2_probe() to use struct tpm_buf

On 3/5/18 8:56 AM, Jarkko Sakkinen wrote: In order to make struct tpm_buf the first class object for constructing TPM commands, migrate tpm2_probe() to use it. Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm2-cmd.c | 27 +++

Re: [PATCH v3 3/5] tpm: migrate tpm2_probe() to use struct tpm_buf

On 3/5/18 8:56 AM, Jarkko Sakkinen wrote: In order to make struct tpm_buf the first class object for constructing TPM commands, migrate tpm2_probe() to use it. Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm2-cmd.c | 27 +++ 1 file changed, 15

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

On 3/7/18 5:18 AM, Igor Stoppa wrote: On 06/03/18 19:20, J Freyensee wrote: On 2/28/18 12:06 PM, Igor Stoppa wrote: [...] void __init lkdtm_perms_init(void); void lkdtm_WRITE_RO(void); void lkdtm_WRITE_RO_AFTER_INIT(void); +void lkdtm_WRITE_RO_PMALLOC(void); Does this need some

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

On 3/7/18 5:18 AM, Igor Stoppa wrote: On 06/03/18 19:20, J Freyensee wrote: On 2/28/18 12:06 PM, Igor Stoppa wrote: [...] void __init lkdtm_perms_init(void); void lkdtm_WRITE_RO(void); void lkdtm_WRITE_RO_AFTER_INIT(void); +void lkdtm_WRITE_RO_PMALLOC(void); Does this need some

Re: [PATCH 7/7] Documentation for Pmalloc

Minus the comment-fixes Mike Rapoport mentioned, looks good: Reviewed-by: Jay Freyensee On 2/28/18 12:06 PM, Igor Stoppa wrote: Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa ---

Re: [PATCH 7/7] Documentation for Pmalloc

Minus the comment-fixes Mike Rapoport mentioned, looks good: Reviewed-by: Jay Freyensee On 2/28/18 12:06 PM, Igor Stoppa wrote: Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa --- Documentation/core-api/index.rst | 1 +

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

On 2/28/18 12:06 PM, Igor Stoppa wrote: Verify that pmalloc read-only protection is in place: trying to overwrite a protected variable will crash the kernel. Signed-off-by: Igor Stoppa --- drivers/misc/lkdtm.h | 1 + drivers/misc/lkdtm_core.c | 3 +++

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

On 2/28/18 12:06 PM, Igor Stoppa wrote: Verify that pmalloc read-only protection is in place: trying to overwrite a protected variable will crash the kernel. Signed-off-by: Igor Stoppa --- drivers/misc/lkdtm.h | 1 + drivers/misc/lkdtm_core.c | 3 +++ drivers/misc/lkdtm_perms.c

Re: [PATCH 5/7] Pmalloc selftest

Looks good, and a bit more thorough test than last iteration. Reviewed-by: Jay Freyensee On 2/28/18 12:06 PM, Igor Stoppa wrote: Add basic self-test functionality for pmalloc. The testing is introduced as early as possible, right after the main dependency, genalloc,

Re: [PATCH 5/7] Pmalloc selftest

Looks good, and a bit more thorough test than last iteration. Reviewed-by: Jay Freyensee On 2/28/18 12:06 PM, Igor Stoppa wrote: Add basic self-test functionality for pmalloc. The testing is introduced as early as possible, right after the main dependency, genalloc, has passed successfully,

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

On 3/6/18 9:05 AM, J Freyensee wrote:   +#ifdef CONFIG_PROTECTABLE_MEMORY +void lkdtm_WRITE_RO_PMALLOC(void) +{ +    struct gen_pool *pool; +    int *i; + +    pool = pmalloc_create_pool("pool", 0); +    if (unlikely(!pool)) { +    pr_info("Failed preparing pool f

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

On 3/6/18 9:05 AM, J Freyensee wrote:   +#ifdef CONFIG_PROTECTABLE_MEMORY +void lkdtm_WRITE_RO_PMALLOC(void) +{ +    struct gen_pool *pool; +    int *i; + +    pool = pmalloc_create_pool("pool", 0); +    if (unlikely(!pool)) { +    pr_info("Failed preparing pool f

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

+#ifdef CONFIG_PROTECTABLE_MEMORY +void lkdtm_WRITE_RO_PMALLOC(void) +{ + struct gen_pool *pool; + int *i; + + pool = pmalloc_create_pool("pool", 0); + if (unlikely(!pool)) { + pr_info("Failed preparing pool for pmalloc test."); + return; +

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

+#ifdef CONFIG_PROTECTABLE_MEMORY +void lkdtm_WRITE_RO_PMALLOC(void) +{ + struct gen_pool *pool; + int *i; + + pool = pmalloc_create_pool("pool", 0); + if (unlikely(!pool)) { + pr_info("Failed preparing pool for pmalloc test."); + return; +

Re: [PATCH 5/7] Pmalloc selftest

Looks good, Reviewed-by: Jay Freyensee On 2/23/18 6:48 AM, Igor Stoppa wrote: Add basic self-test functionality for pmalloc. The testing is introduced as early as possible, right after the main dependency, genalloc, has passed successfully, so that it can help

Re: [PATCH 5/7] Pmalloc selftest

Looks good, Reviewed-by: Jay Freyensee On 2/23/18 6:48 AM, Igor Stoppa wrote: Add basic self-test functionality for pmalloc. The testing is introduced as early as possible, right after the main dependency, genalloc, has passed successfully, so that it can help diagnosing failures in pmalloc

Re: [PATCH 4/7] Protectable Memory

snip . . . + +config PROTECTABLE_MEMORY +bool +depends on MMU Curious, would you also want to depend on "SECURITY" as well, as this is being advertised as a compliment to __read_only_after_init, per the file header comments, as I'm assuming ro_after_init would be disabled if the

Re: [PATCH 4/7] Protectable Memory

snip . . . + +config PROTECTABLE_MEMORY +bool +depends on MMU Curious, would you also want to depend on "SECURITY" as well, as this is being advertised as a compliment to __read_only_after_init, per the file header comments, as I'm assuming ro_after_init would be disabled if the

Re: [PATCH 3/7] struct page: add field for vm_struct

Reviewed-by: Jay Freyensee On 2/28/18 12:06 PM, Igor Stoppa wrote: When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The

Re: [PATCH 3/7] struct page: add field for vm_struct

Reviewed-by: Jay Freyensee On 2/28/18 12:06 PM, Igor Stoppa wrote: When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The struct page has a "mapping"

Re: [PATCH 2/7] genalloc: selftest

+ +/* + * In case of failure of any of these tests, memory corruption is almost + * guarranteed; allowing the boot to continue means risking to corrupt + * also any filesystem/block device accessed write mode. + * Therefore, BUG_ON() is used, when testing. + */ + + I like the explanation;

Re: [PATCH 2/7] genalloc: selftest

+ +/* + * In case of failure of any of these tests, memory corruption is almost + * guarranteed; allowing the boot to continue means risking to corrupt + * also any filesystem/block device accessed write mode. + * Therefore, BUG_ON() is used, when testing. + */ + + I like the explanation;

Re: [PATCH 1/7] genalloc: track beginning of allocations

. . On 2/28/18 12:06 PM, Igor Stoppa wrote: + +/** + * gen_pool_dma_alloc() - allocate special memory from the pool for DMA usage + * @pool: pool to allocate from + * @size: number of bytes to allocate from the pool + * @dma: dma-view physical address return value. Use NULL if unneeded. + * +

Re: [PATCH 1/7] genalloc: track beginning of allocations

. . On 2/28/18 12:06 PM, Igor Stoppa wrote: + +/** + * gen_pool_dma_alloc() - allocate special memory from the pool for DMA usage + * @pool: pool to allocate from + * @size: number of bytes to allocate from the pool + * @dma: dma-view physical address return value. Use NULL if unneeded. + * +

Re: [PATCH 3/5] tpm: migrate tpm2_probe() to use struct tpm_buf

. . . I'm new to this area of the kernel, but I'm not getting these lines: + rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0, NULL); + tpm_buf_destroy(); if (rc < 0) Why is this if() check not directly after the tpm_transmit_cmd() call that sets rc?  Is it

Re: [PATCH 3/5] tpm: migrate tpm2_probe() to use struct tpm_buf

. . . I'm new to this area of the kernel, but I'm not getting these lines: + rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0, NULL); + tpm_buf_destroy(); if (rc < 0) Why is this if() check not directly after the tpm_transmit_cmd() call that sets rc?  Is it

Re: [PATCH 7/7] Documentation for Pmalloc

[...] On 2/26/18 7:39 AM, Igor Stoppa wrote: On 24/02/18 02:26, J Freyensee wrote: On 2/23/18 6:48 AM, Igor Stoppa wrote: [...] +- Before destroying a pool, all the memory allocated from it must be + released. Is that true?  pmalloc_destroy_pool() has

Re: [PATCH 7/7] Documentation for Pmalloc

[...] On 2/26/18 7:39 AM, Igor Stoppa wrote: On 24/02/18 02:26, J Freyensee wrote: On 2/23/18 6:48 AM, Igor Stoppa wrote: [...] +- Before destroying a pool, all the memory allocated from it must be + released. Is that true?  pmalloc_destroy_pool() has

Re: [PATCH 4/7] Protectable Memory

inlined responses. On 2/26/18 6:28 AM, Igor Stoppa wrote: On 24/02/18 02:10, J Freyensee wrote: On 2/23/18 6:48 AM, Igor Stoppa wrote: [...] +struct gen_pool *pmalloc_create_pool(const char *name, +int min_alloc_order); Same comments as earlier

Re: [PATCH 4/7] Protectable Memory

inlined responses. On 2/26/18 6:28 AM, Igor Stoppa wrote: On 24/02/18 02:10, J Freyensee wrote: On 2/23/18 6:48 AM, Igor Stoppa wrote: [...] +struct gen_pool *pmalloc_create_pool(const char *name, +int min_alloc_order); Same comments as earlier

Re: [PATCH 2/7] genalloc: selftest

On 2/26/18 4:11 AM, Igor Stoppa wrote: On 24/02/18 00:42, J Freyensee wrote: + locations[action->location] = gen_pool_alloc(pool, action->size); + BUG_ON(!locations[action->location]); Again, I'd think it through if you really want to use BUG_ON() or not: https:

Re: [PATCH 2/7] genalloc: selftest

On 2/26/18 4:11 AM, Igor Stoppa wrote: On 24/02/18 00:42, J Freyensee wrote: + locations[action->location] = gen_pool_alloc(pool, action->size); + BUG_ON(!locations[action->location]); Again, I'd think it through if you really want to use BUG_ON() or not: https:

Re: [PATCH 1/7] genalloc: track beginning of allocations

My replies also inlined. On 2/26/18 4:09 AM, Igor Stoppa wrote: Hello, and thanks for the reviews, my replies inlined below. On 24/02/18 00:28, J Freyensee wrote: some code snipping . . . +/** + * get_bitmap_entry() - extracts the specified entry from the bitmap + * @map: pointer to a bitmap

Re: [PATCH 1/7] genalloc: track beginning of allocations

My replies also inlined. On 2/26/18 4:09 AM, Igor Stoppa wrote: Hello, and thanks for the reviews, my replies inlined below. On 24/02/18 00:28, J Freyensee wrote: some code snipping . . . +/** + * get_bitmap_entry() - extracts the specified entry from the bitmap + * @map: pointer to a bitmap

Re: [PATCH 7/7] Documentation for Pmalloc

On 2/23/18 6:48 AM, Igor Stoppa wrote: Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa --- Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 114 + 2 files

Re: [PATCH 7/7] Documentation for Pmalloc

On 2/23/18 6:48 AM, Igor Stoppa wrote: Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa --- Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 114 + 2 files changed, 115

Re: [PATCH 4/7] Protectable Memory

On 2/23/18 6:48 AM, Igor Stoppa wrote: The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications.

Re: [PATCH 4/7] Protectable Memory

On 2/23/18 6:48 AM, Igor Stoppa wrote: The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications.

Re: [PATCH 2/7] genalloc: selftest

+ locations[action->location] = gen_pool_alloc(pool, action->size); + BUG_ON(!locations[action->location]); Again, I'd think it through if you really want to use BUG_ON() or not: https://lwn.net/Articles/13183/ https://lkml.org/lkml/2016/10/4/1 Thanks, Jay

Re: [PATCH 2/7] genalloc: selftest

+ locations[action->location] = gen_pool_alloc(pool, action->size); + BUG_ON(!locations[action->location]); Again, I'd think it through if you really want to use BUG_ON() or not: https://lwn.net/Articles/13183/ https://lkml.org/lkml/2016/10/4/1 Thanks, Jay

Re: [PATCH 1/7] genalloc: track beginning of allocations

some code snipping . . . +/** + * get_bitmap_entry() - extracts the specified entry from the bitmap + * @map: pointer to a bitmap + * @entry_index: the index of the desired entry in the bitmap + * + * Return: The requested bitmap. + */ +static inline unsigned long get_bitmap_entry(unsigned long

Re: [PATCH 1/7] genalloc: track beginning of allocations

some code snipping . . . +/** + * get_bitmap_entry() - extracts the specified entry from the bitmap + * @map: pointer to a bitmap + * @entry_index: the index of the desired entry in the bitmap + * + * Return: The requested bitmap. + */ +static inline unsigned long get_bitmap_entry(unsigned long

Re: [PATCH v3 01/13] mpt3sas: Update MPI Header

Looks like your header has a white space error: Applying: mpt3sas: Update MPI Header .git/rebase-apply/patch:1452: new blank line at EOF. + Also, FYI, this project has a lot of sparse errors that look like existed before your patchset. As your patchset touches a few of the files that have

Re: [PATCH v3 01/13] mpt3sas: Update MPI Header

Looks like your header has a white space error: Applying: mpt3sas: Update MPI Header .git/rebase-apply/patch:1452: new blank line at EOF. + Also, FYI, this project has a lot of sparse errors that look like existed before your patchset. As your patchset touches a few of the files that have

Re: [PATCH v4] add u64 number parser

On Sun, 2016-09-25 at 09:14 -0700, James Smart wrote: > add u64 number parser > > Reverted back to version 2 of the patch.  This adds the interface > using existing logic. Comments from the prior reviewers to move to > kasprintf were rejected by Linus. > > Signed-off-by: James Smart

Re: [PATCH v4] add u64 number parser

On Sun, 2016-09-25 at 09:14 -0700, James Smart wrote: > add u64 number parser > > Reverted back to version 2 of the patch.  This adds the interface > using existing logic. Comments from the prior reviewers to move to > kasprintf were rejected by Linus. > > Signed-off-by: James Smart Acked-by:

Re: [PATCH] lightnvm: add missing \n to end of dev_err message

On Sun, 2016-09-25 at 14:56 -0700, Colin King wrote: > From: Colin Ian King > > Trival fix, dev_err message is missing a \n, so add it. > > Signed-off-by: Colin Ian King >  Reviewed-by: Jay Freyensee

Re: [PATCH] lightnvm: add missing \n to end of dev_err message

On Sun, 2016-09-25 at 14:56 -0700, Colin King wrote: > From: Colin Ian King > > Trival fix, dev_err message is missing a \n, so add it. > > Signed-off-by: Colin Ian King >  Reviewed-by: Jay Freyensee

Re: [PATCH] nvme: add missing \n to end of dev_warn message

On Sun, 2016-09-25 at 15:04 -0700, Colin King wrote: > From: Colin Ian King > > Trival fix, dev_warn message is missing a \n, so add it. > > Signed-off-by: Colin Ian King Reviewed-by: Jay Freyensee

Re: [PATCH] nvme: add missing \n to end of dev_warn message

On Sun, 2016-09-25 at 15:04 -0700, Colin King wrote: > From: Colin Ian King > > Trival fix, dev_warn message is missing a \n, so add it. > > Signed-off-by: Colin Ian King Reviewed-by: Jay Freyensee

Re: [PATCH] nvme-rdma: add missing \n to end of dev_err message

On Sun, 2016-09-25 at 15:01 -0700, Colin King wrote: > From: Colin Ian King > > Trival fix, dev_err message is missing a \n, so add it. Also > break line as it was over 80 chars wide. > > Signed-off-by: Colin Ian King Reviewed-by: Jay

Re: [PATCH] nvme-rdma: add missing \n to end of dev_err message

On Sun, 2016-09-25 at 15:01 -0700, Colin King wrote: > From: Colin Ian King > > Trival fix, dev_err message is missing a \n, so add it. Also > break line as it was over 80 chars wide. > > Signed-off-by: Colin Ian King Reviewed-by: Jay Freyensee > --- >  drivers/nvme/host/rdma.c | 3 ++- >  1

Re: [PATCH v4 0/3] nvme power saving

On Thu, 2016-09-22 at 14:43 -0600, Jens Axboe wrote: > On 09/22/2016 02:11 PM, Andy Lutomirski wrote: > > > > On Thu, Sep 22, 2016 at 7:23 AM, Jens Axboe wrote: > > > > > > > > > On 09/16/2016 12:16 PM, Andy Lutomirski wrote: > > > > > > > > > > > > Hi all- > > > > > > > >

Re: [PATCH v4 0/3] nvme power saving

On Thu, 2016-09-22 at 14:43 -0600, Jens Axboe wrote: > On 09/22/2016 02:11 PM, Andy Lutomirski wrote: > > > > On Thu, Sep 22, 2016 at 7:23 AM, Jens Axboe wrote: > > > > > > > > > On 09/16/2016 12:16 PM, Andy Lutomirski wrote: > > > > > > > > > > > > Hi all- > > > > > > > > Here's v4 of the

Re: [PATCH v4 0/3] nvme power saving

On Fri, 2016-09-16 at 11:16 -0700, Andy Lutomirski wrote: > Hi all- > > Here's v4 of the APST patch set.  The biggest bikesheddable thing (I > think) is the scaling factor.  I currently have it hardcoded so that > we wait 50x the total latency before entering a power saving state. > On my Samsung

Re: [PATCH v4 0/3] nvme power saving

On Fri, 2016-09-16 at 11:16 -0700, Andy Lutomirski wrote: > Hi all- > > Here's v4 of the APST patch set.  The biggest bikesheddable thing (I > think) is the scaling factor.  I currently have it hardcoded so that > we wait 50x the total latency before entering a power saving state. > On my Samsung

Re: [PATCH v4 1/3] nvme/scsi: Remove power management support

On Fri, 2016-09-16 at 11:16 -0700, Andy Lutomirski wrote: > As far as I can tell, there is basically nothing correct about this > code.  It misinterprets npss (off-by-one).  It hardcodes a bunch of > power states, which is nonsense, because they're all just indices > into a table that software

Re: [PATCH v4 1/3] nvme/scsi: Remove power management support

On Fri, 2016-09-16 at 11:16 -0700, Andy Lutomirski wrote: > As far as I can tell, there is basically nothing correct about this > code.  It misinterprets npss (off-by-one).  It hardcodes a bunch of > power states, which is nonsense, because they're all just indices > into a table that software

Re: [PATCH v3 1/3] nvme/scsi: Remove power management support

On Fri, 2016-09-16 at 10:33 +0200, Christoph Hellwig wrote: > On Thu, Sep 15, 2016 at 10:24:19PM -0700, Andy Lutomirski wrote: > > > > As far as I can tell, there is basically nothing correct about this > > code.  It misinterprets npss (off-by-one).  It hardcodes a bunch of > > power states,

Re: [PATCH v3 1/3] nvme/scsi: Remove power management support

On Fri, 2016-09-16 at 10:33 +0200, Christoph Hellwig wrote: > On Thu, Sep 15, 2016 at 10:24:19PM -0700, Andy Lutomirski wrote: > > > > As far as I can tell, there is basically nothing correct about this > > code.  It misinterprets npss (off-by-one).  It hardcodes a bunch of > > power states,

Re: [PATCH v2 3/3] nvme: Enable autonomous power state transitions

On Fri, 2016-09-02 at 14:43 -0700, Andy Lutomirski wrote: > On Fri, Sep 2, 2016 at 2:15 PM, J Freyensee > <james_p_freyen...@linux.intel.com> wrote: > > > > On Tue, 2016-08-30 at 14:59 -0700, Andy Lutomirski wrote: > > > > > > NVME devices can adve

Re: [PATCH v2 3/3] nvme: Enable autonomous power state transitions

On Fri, 2016-09-02 at 14:43 -0700, Andy Lutomirski wrote: > On Fri, Sep 2, 2016 at 2:15 PM, J Freyensee > wrote: > > > > On Tue, 2016-08-30 at 14:59 -0700, Andy Lutomirski wrote: > > > > > > NVME devices can advertise multiple power states.  These states &g

Re: [PATCH v2 3/3] nvme: Enable autonomous power state transitions

On Tue, 2016-08-30 at 14:59 -0700, Andy Lutomirski wrote: > NVME devices can advertise multiple power states.  These states can > be either "operational" (the device is fully functional but possibly > slow) or "non-operational" (the device is asleep until woken up). > Some devices can

Re: [PATCH v2 3/3] nvme: Enable autonomous power state transitions

On Tue, 2016-08-30 at 14:59 -0700, Andy Lutomirski wrote: > NVME devices can advertise multiple power states.  These states can > be either "operational" (the device is fully functional but possibly > slow) or "non-operational" (the device is asleep until woken up). > Some devices can

Re: [PATCH 3/3] nvme: Enable autonomous power state transitions

> > > > > > > > > > > > > > + /* > > > > +  * By default, allow up to 25ms of APST-induced > > > > latency.  This will > > > > +  * have no effect on non-APST supporting controllers > > > > (i.e. > > > > any > > > > +  * controller with APSTA == 0). > > > > +  */ > > > > +  

Re: [PATCH 3/3] nvme: Enable autonomous power state transitions

> > > > > > > > > > > > > > + /* > > > > +  * By default, allow up to 25ms of APST-induced > > > > latency.  This will > > > > +  * have no effect on non-APST supporting controllers > > > > (i.e. > > > > any > > > > +  * controller with APSTA == 0). > > > > +  */ > > > > +  

Re: [PATCH 3/3] nvme: Enable autonomous power state transitions

On Mon, 2016-08-29 at 02:25 -0700, Andy Lutomirski wrote: > NVME devices can advertise multiple power states.  These states can > be either "operational" (the device is fully functional but possibly > slow) or "non-operational" (the device is asleep until woken up). > Some devices can

Re: [PATCH 3/3] nvme: Enable autonomous power state transitions

On Mon, 2016-08-29 at 02:25 -0700, Andy Lutomirski wrote: > NVME devices can advertise multiple power states.  These states can > be either "operational" (the device is fully functional but possibly > slow) or "non-operational" (the device is asleep until woken up). > Some devices can

Re: [PATCH v3 RFC 2/2] nvme: improve performance for virtual NVMe devices

On Mon, 2016-08-15 at 22:41 -0300, Helen Koike wrote: >   > +struct nvme_doorbell_memory { > + __u8opcode; > + __u8flags; > + __u16 command_id; > + __u32 rsvd1[5]; > + __le64 prp1; >

Re: [PATCH v3 RFC 2/2] nvme: improve performance for virtual NVMe devices

On Mon, 2016-08-15 at 22:41 -0300, Helen Koike wrote: >   > +struct nvme_doorbell_memory { > + __u8opcode; > + __u8flags; > + __u16 command_id; > + __u32 rsvd1[5]; > + __le64 prp1; >

Re: [PATCH -next] nvme-rdma: fix the return value of nvme_rdma_reinit_request()

On Tue, 2016-07-12 at 11:06 +, weiyj...@163.com wrote: > From: Wei Yongjun > > PTR_ERR should be applied before its argument is reassigned, > otherwise the > return value will be set to 0, not error code. Another good catch. Reviewed-by: Jay Freyensee

Re: [PATCH -next] nvme-rdma: fix the return value of nvme_rdma_reinit_request()

On Tue, 2016-07-12 at 11:06 +, weiyj...@163.com wrote: > From: Wei Yongjun > > PTR_ERR should be applied before its argument is reassigned, > otherwise the > return value will be set to 0, not error code. Another good catch. Reviewed-by: Jay Freyensee > > Signed-off-by: Wei Yongjun >

Re: [PATCH] nvme-loop: add configfs dependency

On Sun, 2016-07-10 at 14:14 +0200, Christoph Hellwig wrote: > On Thu, Jul 07, 2016 at 08:35:17AM -0600, Jens Axboe wrote: > > Thanks Arnd, applied. > > Actually I think we should replace the select with the depends. In > fact I though I had done that a while ago, but I must have messed it > up.

Re: [PATCH] nvme-loop: add configfs dependency

On Sun, 2016-07-10 at 14:14 +0200, Christoph Hellwig wrote: > On Thu, Jul 07, 2016 at 08:35:17AM -0600, Jens Axboe wrote: > > Thanks Arnd, applied. > > Actually I think we should replace the select with the depends. In > fact I though I had done that a while ago, but I must have messed it > up.

Re: [PATCH -next] nvmet: fix return value check in nvmet_subsys_alloc()

On Wed, 2016-07-06 at 12:02 +, weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function kstrndup() returns NULL pointer > not ERR_PTR(). The IS_ERR() test in the return value check > should be replaced with NULL test. > > Signed-off-by:

Re: [PATCH -next] nvmet: fix return value check in nvmet_subsys_alloc()

On Wed, 2016-07-06 at 12:02 +, weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function kstrndup() returns NULL pointer > not ERR_PTR(). The IS_ERR() test in the return value check > should be replaced with NULL test. > > Signed-off-by: Wei Yongjun Looks good and

Re: [PATCH 5/6] lightnvm: expose device geometry through sysfs

On Wed, 2016-06-29 at 16:51 +0200, Matias Bjørling wrote: > From: "Simon A. F. Lund" > > For a host to access an Open-Channel SSD, it has to know its > geometry, > so that it writes and reads at the appropriate device bounds. > > Currently, the geometry information is kept

Re: [PATCH 5/6] lightnvm: expose device geometry through sysfs

On Wed, 2016-06-29 at 16:51 +0200, Matias Bjørling wrote: > From: "Simon A. F. Lund" > > For a host to access an Open-Channel SSD, it has to know its > geometry, > so that it writes and reads at the appropriate device bounds. > > Currently, the geometry information is kept within the kernel,

Re: [PATCHv1] NVMe: nvme_queue made cache friendly.

On Wed, 2015-05-20 at 16:43 -0400, Parav Pandit wrote: > nvme_queue structure made 64B cache friendly so that majority of the > data elements of the structure during IO and completion path can be > found in typical single 64B cache line size which was previously spanning > beyond single 64B cache

Re: [PATCHv1] NVMe: nvme_queue made cache friendly.

On Wed, 2015-05-20 at 16:43 -0400, Parav Pandit wrote: nvme_queue structure made 64B cache friendly so that majority of the data elements of the structure during IO and completion path can be found in typical single 64B cache line size which was previously spanning beyond single 64B cache line

Re: [PATCH] NVMe: Fix error handling of class_create("nvme")

On Sat, 2015-03-07 at 01:43 +0300, Alexey Khoroshilov wrote: > class_create() returns ERR_PTR on failure, > so IS_ERR() should be used instead of check for NULL. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov > --- >

Re: [PATCH] NVMe: Fix error handling of class_create(nvme)

On Sat, 2015-03-07 at 01:43 +0300, Alexey Khoroshilov wrote: class_create() returns ERR_PTR on failure, so IS_ERR() should be used instead of check for NULL. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru ---