Delivery problem, parcel USPS #666115153

2017-04-03 Thread USPS Priority Parcels 
Hello,

Your item has arrived at the USPS Post Office at  Mon, 03 Apr 2017 21:47:22
-0700, but the courier was unable to deliver parcel to you. 
Review the document that is attached to this e-mail!

Thank you for your time.
Koral Entress -  USPS Delivery Agent.


___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Message could not be delivered

2017-04-03 Thread Bounced mail 
The original message was received at Tue, 4 Apr 2017 12:41:40 +0800
from lists.01.org [67.198.96.41]

- The following addresses had permanent fatal errors -


- Transcript of session follows -
  while talking to lists.01.org.:
>>> MAIL From:"Bounced mail" 
<<< 501 "Bounced mail" ... Refused



___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

New status of your USPS delivery code: 570651465

2017-04-03 Thread USPS Parcels Delivery 
Hello,

USPS courier was unable to contact you for your parcel delivery. 
Postal label is enclosed to this e-mail. Please check the attachment!

Yours sincerely.
Prudence Mcmahen -  USPS Senior Support Manager.


___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

2017-04-03 Thread Dan Williams 
On Mon, Apr 3, 2017 at 4:12 PM, Logan Gunthorpe  wrote:
>
>
> On 03/04/17 04:47 PM, Dan Williams wrote:
>> I wouldn't necessarily conflate supporting pfn_t in the scatterlist
>> with the stalled stuct-page-less DMA effor. A pfn_t_to_page()
>> conversion will still work and be required. However you're right, the
>> minute we use pfn_t for this we're into the realm of special case
>> drivers that understand scatterlists with special "I/O-pfn_t" entries.
>
> Well yes, it would certainly be possible to convert the scatterlist code
> from page_link to pfn_t. (The only slightly tricky thing is that
> scatterlist uses extra chaining bits and pfn_t uses extra flag bits so
> they'd have to be harmonized somehow). But if we aren't moving toward
> struct-page-less DMA, I fail to see the point of the conversion.
>
> I'll definitely need IO scatterlists of some form or another and I like
> pfn_t but right now it just seems like extra work with unclear benefit.
> (Though, if someone told me that I can't use a third bit in the
> page_link field then maybe that would be a good reason to move to pfn_t.)
>
>> However, maybe that's what we want? I think peer-to-peer DMA is not a
>> general purpose feature unless/until we get it standardized in PCI. So
>> maybe drivers with special case scatterlist support is exactly what we
>> want for now.
>
> Well, I think this should be completely independent from PCI code. I see
> no reason why we can't have infrastructure for DMA on iomem from any
> bus. Largely all the work I've done in this area is completely agnostic
> to the bus in use. (Except for any kind of white/black list when it is
> used.)

The completely agnostic part is where I get worried, but I shouldn't
say anymore until I actually read the patch.The worry is cases where
this agnostic enabling allows unsuspecting code paths to do the wrong
thing. Like bypass iomem safety.

> The "special case scatterlist" is essentially what I'm proposing in the
> patch I sent upthread, it just stores the flag in the page_link instead
> of in a pfn_t.

Makes sense. The suggestion of pfn_t was to try to get more type
safety throughout the stack. So that, again, unsuspecting code paths
that get an I/O pfn aren't able to do things like page_address() or
kmap() without failing.

I'll stop commenting now and set aside some time to go read the patches.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

2017-04-03 Thread Logan Gunthorpe 


On 03/04/17 04:47 PM, Dan Williams wrote:
> I wouldn't necessarily conflate supporting pfn_t in the scatterlist
> with the stalled stuct-page-less DMA effor. A pfn_t_to_page()
> conversion will still work and be required. However you're right, the
> minute we use pfn_t for this we're into the realm of special case
> drivers that understand scatterlists with special "I/O-pfn_t" entries.

Well yes, it would certainly be possible to convert the scatterlist code
from page_link to pfn_t. (The only slightly tricky thing is that
scatterlist uses extra chaining bits and pfn_t uses extra flag bits so
they'd have to be harmonized somehow). But if we aren't moving toward
struct-page-less DMA, I fail to see the point of the conversion.

I'll definitely need IO scatterlists of some form or another and I like
pfn_t but right now it just seems like extra work with unclear benefit.
(Though, if someone told me that I can't use a third bit in the
page_link field then maybe that would be a good reason to move to pfn_t.)

> However, maybe that's what we want? I think peer-to-peer DMA is not a
> general purpose feature unless/until we get it standardized in PCI. So
> maybe drivers with special case scatterlist support is exactly what we
> want for now.

Well, I think this should be completely independent from PCI code. I see
no reason why we can't have infrastructure for DMA on iomem from any
bus. Largely all the work I've done in this area is completely agnostic
to the bus in use. (Except for any kind of white/black list when it is
used.)

The "special case scatterlist" is essentially what I'm proposing in the
patch I sent upthread, it just stores the flag in the page_link instead
of in a pfn_t.

Logan
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

2017-04-03 Thread Dan Williams 
On Mon, Apr 3, 2017 at 3:10 PM, Logan Gunthorpe  wrote:
>
>
> On 03/04/17 03:44 PM, Dan Williams wrote:
>> On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe  wrote:
>>> Hi Christoph,
>>>
>>> What are your thoughts on an approach like the following untested
>>> draft patch.
>>>
>>> The patch (if fleshed out) makes it so iomem can be used in an sgl
>>> and WARN_ONs will occur in places where drivers attempt to access
>>> iomem directly through the sgl.
>>>
>>> I'd also probably create a p2pmem_alloc_sgl helper function so driver
>>> writers wouldn't have to mess with sg_set_iomem_page.
>>>
>>> With all that in place, it should be relatively safe for drivers to
>>> implement p2pmem even though we'd still technically be violating the
>>> __iomem boundary in some places.
>>
>> Just reacting to this mail, I still haven't had a chance to take a
>> look at the rest of the series.
>>
>> The pfn_t type was invented to carry extra type and page lookup
>> information about the memory behind a given pfn. At first glance that
>> seems a more natural place to carry an indication that this is an
>> "I/O" pfn.
>
> I agree... But what are the plans for pfn_t? Is anyone working on using
> it in the scatterlist code? Currently it's not there yet and given the
> assertion that we will continue to be using struct page for DMA is that
> a direction we'd want to go?
>

I wouldn't necessarily conflate supporting pfn_t in the scatterlist
with the stalled stuct-page-less DMA effor. A pfn_t_to_page()
conversion will still work and be required. However you're right, the
minute we use pfn_t for this we're into the realm of special case
drivers that understand scatterlists with special "I/O-pfn_t" entries.
However, maybe that's what we want? I think peer-to-peer DMA is not a
general purpose feature unless/until we get it standardized in PCI. So
maybe drivers with special case scatterlist support is exactly what we
want for now.

Thoughts?
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

2017-04-03 Thread Logan Gunthorpe 
Hi Christoph,

What are your thoughts on an approach like the following untested
draft patch.

The patch (if fleshed out) makes it so iomem can be used in an sgl
and WARN_ONs will occur in places where drivers attempt to access
iomem directly through the sgl.

I'd also probably create a p2pmem_alloc_sgl helper function so driver
writers wouldn't have to mess with sg_set_iomem_page.

With all that in place, it should be relatively safe for drivers to
implement p2pmem even though we'd still technically be violating the
__iomem boundary in some places.

Logan


commit b435a154a4ec4f82766f6ab838092c3c5a9388ac
Author: Logan Gunthorpe 
Date:   Wed Feb 8 12:44:52 2017 -0700

scatterlist: Add support for iomem pages

This patch steals another bit from the page_link field to indicate the
sg points to iomem. In sg_copy_buffer we use this flag to select
between memcpy and iomemcpy. Other sg_miter users will get an WARN_ON
unless they indicate they support iomemory by setting the
SG_MITER_IOMEM flag.

Also added are sg_kmap functions which would replace a common pattern
of kmap(sg_page(sg)). These new functions then also warn if the caller
tries to map io memory. Another option may be to automatically copy
the iomem to a new page and return that transparently to the driver.

Another coccinelle patch would then be done to convert kmap(sg_page(sg))
instances to the appropriate sg_kmap calls.

Signed-off-by: Logan Gunthorpe 

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 0007b79..bd690a2c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -37,6 +37,9 @@

 #include 

+/* Avoid the highmem.h macro from aliasing our ops->kunmap_atomic */
+#undef kunmap_atomic
+
 static inline int is_dma_buf_file(struct file *);

 struct dma_buf_list {
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index cb3c8fe..7608da0 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 struct scatterlist {
@@ -53,6 +54,9 @@ struct sg_table {
  *
  * If bit 1 is set, then this sg entry is the last element in a list.
  *
+ * We also use bit 2 to indicate whether the page_link points to an
+ * iomem page or not.
+ *
  * See sg_next().
  *
  */
@@ -64,10 +68,17 @@ struct sg_table {
  * a valid sg entry, or whether it points to the start of a new
scatterlist.
  * Those low bits are there for everyone! (thanks mason :-)
  */
-#define sg_is_chain(sg)((sg)->page_link & 0x01)
-#define sg_is_last(sg) ((sg)->page_link & 0x02)
+#define PAGE_LINK_MASK 0x7
+#define PAGE_LINK_CHAIN0x1
+#define PAGE_LINK_LAST 0x2
+#define PAGE_LINK_IOMEM0x4
+
+#define sg_is_chain(sg)((sg)->page_link & PAGE_LINK_CHAIN)
+#define sg_is_last(sg) ((sg)->page_link & PAGE_LINK_LAST)
 #define sg_chain_ptr(sg)   \
-   ((struct scatterlist *) ((sg)->page_link & ~0x03))
+   ((struct scatterlist *) ((sg)->page_link & ~(PAGE_LINK_CHAIN | \
+PAGE_LINK_LAST)))
+#define sg_is_iomem(sg)((sg)->page_link & PAGE_LINK_IOMEM)

 /**
  * sg_assign_page - Assign a given page to an SG entry
@@ -81,13 +92,13 @@ struct sg_table {
  **/
 static inline void sg_assign_page(struct scatterlist *sg, struct page
*page)
 {
-   unsigned long page_link = sg->page_link & 0x3;
+   unsigned long page_link = sg->page_link & PAGE_LINK_MASK;

/*
 * In order for the low bit stealing approach to work, pages
-* must be aligned at a 32-bit boundary as a minimum.
+* must be aligned at a 64-bit boundary as a minimum.
 */
-   BUG_ON((unsigned long) page & 0x03);
+   BUG_ON((unsigned long) page & PAGE_LINK_MASK);
 #ifdef CONFIG_DEBUG_SG
BUG_ON(sg->sg_magic != SG_MAGIC);
BUG_ON(sg_is_chain(sg));
@@ -117,13 +128,56 @@ static inline void sg_set_page(struct scatterlist
*sg, struct page *page,
sg->length = len;
 }

+/**
+ * sg_set_page - Set sg entry to point at given iomem page
+ * @sg: SG entry
+ * @page:   The page
+ * @len:Length of data
+ * @offset: Offset into page
+ *
+ * Description:
+ *   Same as sg_set_page but used when the page is a ZONE_DEVICE page that
+ *   points to IO memory.
+ *
+ **/
+static inline void sg_set_iomem_page(struct scatterlist *sg, struct
page *page,
+unsigned int len, unsigned int offset)
+{
+   sg_set_page(sg, page, len, offset);
+   sg->page_link |= PAGE_LINK_IOMEM;
+}
+
 static inline struct page *sg_page(struct scatterlist *sg)
 {
 #ifdef CONFIG_DEBUG_SG
BUG_ON(sg->sg_magic != SG_MAGIC);
BUG_ON(sg_is_chain(sg));
 #endif
-   return (struct page *)((sg)->page_link & ~0x3);
+   return (struct page *)((sg)->page_link &

Re: [PATCH] acpi, nfit: fix acpi_get_table leak

2017-04-03 Thread Dan Williams 
On Mon, Apr 3, 2017 at 12:00 PM, Ross Zwisler
 wrote:
> On Sat, Apr 01, 2017 at 12:25:20PM -0700, Dan Williams wrote:
>> Calls to acpi_get_table() must be paired with acpi_put_table() to undo
>> the mapping established by acpi_tb_acquire_table().
>>
>> Cc: 
>> Fixes: 6b11d1d67713 ("ACPI / osl: Remove 
>> acpi_get_table_with_size()/early_acpi_os_unmap_memory() users")
>> Cc: Lv Zheng 
>> Reported-by: Ross Zwisler 
>> Signed-off-by: Dan Williams 
>> ---
>>  drivers/acpi/nfit/core.c |9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
>> index c8ea9d698cd0..6acfea69f061 100644
>> --- a/drivers/acpi/nfit/core.c
>> +++ b/drivers/acpi/nfit/core.c
>> @@ -2818,6 +2818,11 @@ void acpi_nfit_desc_init(struct acpi_nfit_desc 
>> *acpi_desc, struct device *dev)
>>  }
>>  EXPORT_SYMBOL_GPL(acpi_nfit_desc_init);
>>
>> +static void acpi_nfit_put_table(void *table)
>> +{
>> + acpi_put_table(table);
>> +}
>> +
>>  static int acpi_nfit_add(struct acpi_device *adev)
>>  {
>>   struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
>> @@ -2834,6 +2839,10 @@ static int acpi_nfit_add(struct acpi_device *adev)
>>   dev_dbg(dev, "failed to find NFIT at startup\n");
>>   return 0;
>>   }
>> +
>> + rc = devm_add_action_or_reset(dev, acpi_nfit_put_table, tbl);
>> + if (rc)
>> + return rc;
>>   sz = tbl->length;
>>
>>   acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);
>
> I've been looking at this this as well, and I think it might be better to just
> drop the reference immediately in acpi_nfit_add() after we're done processing
> the tables?
>
> Anyway, here's the patch I was working on, but I think either works.
>
> -- 8< --
> From 4819cd889b08c3c17f8f9fcf895a083f21fa0898 Mon Sep 17 00:00:00 2001
> From: Ross Zwisler 
> Date: Mon, 3 Apr 2017 11:53:32 -0600
> Subject: [PATCH] nfit: release reference on ACPI nfit table
>
> Currently acpi_nfit_add() grabs a reference to the ACPI NFIT table
> structures via acpi_get_table(), but never releases it with
> acpi_put_table().  This means that the refcount protecting the ioremap for
> the NFIT table never decrements, so the ioremap can never be undone.  The
> ioremap happens via this path:
>
> acpi_get_table()
>   acpi_tb_get_table()
> acpi_tb_validate_table()
>   acpi_tb_acquire_table()
> acpi_os_map_memory()
>
> In practice this fix is correct but won't have a usable visible impact
> because the ACPI sysfs code (acpi_table_attr_init() et al.), which
> populates /sys/firmware/acpi/tables/NFIT, also keeps a table reference, so
> the NFIT table memory will always remain mapped.
>
> We drop the refcount at the end of acpi_nfit_add() instead of waiting till
> driver unload and doing it via acpi_nfit_remove() or something akin to
> acpi_nfit_destruct() called via the devm_ interface.  This is because
> during acpi_nfit_add() we never actually keep any references to the
> original ACPI tables.  We either copy individual elements out, or we make
> whole copies of tables in functions like add_spa(), add memdev(), etc.
>
> Signed-off-by: Ross Zwisler 
> ---
>  drivers/acpi/nfit/core.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 662036b..ad0dfd6 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -2833,8 +2833,10 @@ static int acpi_nfit_add(struct acpi_device *adev)
> sz = tbl->length;
>
> acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);
> -   if (!acpi_desc)
> -   return -ENOMEM;
> +   if (!acpi_desc) {
> +   rc = -ENOMEM;
> +   goto out;
> +   }
> acpi_nfit_desc_init(acpi_desc, >dev);
>
> /* Save the acpi header for exporting the revision via sysfs */
> @@ -2857,6 +2859,8 @@ static int acpi_nfit_add(struct acpi_device *adev)
> rc = acpi_nfit_init(acpi_desc, (void *) tbl
> + sizeof(struct acpi_table_nfit),
> sz - sizeof(struct acpi_table_nfit));
> +out:
> +   acpi_put_table(tbl);
> return rc;
>  }

Hi Ross, thanks for this. I'll add your note about this fix not making
a difference in practice to my devm_add_action_or_reset() version and
drop -stable. I don't want to maintain gotos in the init path if at
all possible.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] acpi, nfit: fix acpi_get_table leak

2017-04-03 Thread Ross Zwisler 
On Sat, Apr 01, 2017 at 12:25:20PM -0700, Dan Williams wrote:
> Calls to acpi_get_table() must be paired with acpi_put_table() to undo
> the mapping established by acpi_tb_acquire_table().
> 
> Cc: 
> Fixes: 6b11d1d67713 ("ACPI / osl: Remove 
> acpi_get_table_with_size()/early_acpi_os_unmap_memory() users")
> Cc: Lv Zheng 
> Reported-by: Ross Zwisler 
> Signed-off-by: Dan Williams 
> ---
>  drivers/acpi/nfit/core.c |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index c8ea9d698cd0..6acfea69f061 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -2818,6 +2818,11 @@ void acpi_nfit_desc_init(struct acpi_nfit_desc 
> *acpi_desc, struct device *dev)
>  }
>  EXPORT_SYMBOL_GPL(acpi_nfit_desc_init);
>  
> +static void acpi_nfit_put_table(void *table)
> +{
> + acpi_put_table(table);
> +}
> +
>  static int acpi_nfit_add(struct acpi_device *adev)
>  {
>   struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
> @@ -2834,6 +2839,10 @@ static int acpi_nfit_add(struct acpi_device *adev)
>   dev_dbg(dev, "failed to find NFIT at startup\n");
>   return 0;
>   }
> +
> + rc = devm_add_action_or_reset(dev, acpi_nfit_put_table, tbl);
> + if (rc)
> + return rc;
>   sz = tbl->length;
>  
>   acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);

I've been looking at this this as well, and I think it might be better to just
drop the reference immediately in acpi_nfit_add() after we're done processing
the tables?  

Anyway, here's the patch I was working on, but I think either works.

-- 8< --
>From 4819cd889b08c3c17f8f9fcf895a083f21fa0898 Mon Sep 17 00:00:00 2001
From: Ross Zwisler 
Date: Mon, 3 Apr 2017 11:53:32 -0600
Subject: [PATCH] nfit: release reference on ACPI nfit table

Currently acpi_nfit_add() grabs a reference to the ACPI NFIT table
structures via acpi_get_table(), but never releases it with
acpi_put_table().  This means that the refcount protecting the ioremap for
the NFIT table never decrements, so the ioremap can never be undone.  The
ioremap happens via this path:

acpi_get_table()
  acpi_tb_get_table()
acpi_tb_validate_table()
  acpi_tb_acquire_table()
acpi_os_map_memory()

In practice this fix is correct but won't have a usable visible impact
because the ACPI sysfs code (acpi_table_attr_init() et al.), which
populates /sys/firmware/acpi/tables/NFIT, also keeps a table reference, so
the NFIT table memory will always remain mapped.

We drop the refcount at the end of acpi_nfit_add() instead of waiting till
driver unload and doing it via acpi_nfit_remove() or something akin to
acpi_nfit_destruct() called via the devm_ interface.  This is because
during acpi_nfit_add() we never actually keep any references to the
original ACPI tables.  We either copy individual elements out, or we make
whole copies of tables in functions like add_spa(), add memdev(), etc.

Signed-off-by: Ross Zwisler 
---
 drivers/acpi/nfit/core.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 662036b..ad0dfd6 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2833,8 +2833,10 @@ static int acpi_nfit_add(struct acpi_device *adev)
sz = tbl->length;
 
acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);
-   if (!acpi_desc)
-   return -ENOMEM;
+   if (!acpi_desc) {
+   rc = -ENOMEM;
+   goto out;
+   }
acpi_nfit_desc_init(acpi_desc, >dev);
 
/* Save the acpi header for exporting the revision via sysfs */
@@ -2857,6 +2859,8 @@ static int acpi_nfit_add(struct acpi_device *adev)
rc = acpi_nfit_init(acpi_desc, (void *) tbl
+ sizeof(struct acpi_table_nfit),
sz - sizeof(struct acpi_table_nfit));
+out:
+   acpi_put_table(tbl);
return rc;
 }
 
-- 
2.9.3
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm