* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Jason Gunthorpe @ 2017-04-18 21:03 UTC (permalink / raw)
To: Dan Williams
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <CAPcyv4gScx6A7vG9VEHpNF41GOy1Nxst7QQ3QC3uZ54bWoxbMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 18, 2017 at 12:48:35PM -0700, Dan Williams wrote:
> > Yes, I noticed this problem too and that makes sense. It just means
> > every dma_ops will probably need to be modified to either support p2p
> > pages or fail on them. Though, the only real difficulty there is that it
> > will be a lot of work.
>
> I don't think you need to go touch all dma_ops, I think you can just
> arrange for devices that are going to do dma to get redirected to a
> p2p aware provider of operations that overrides the system default
> dma_ops. I.e. just touch get_dma_ops().
I don't follow, when does get_dma_ops() return a p2p aware provider?
It has no way to know if the DMA is going to involve p2p, get_dma_ops
is called with the device initiating the DMA.
So you'd always return the P2P shim on a system that has registered
P2P memory?
Even so, how does this shim work? dma_ops are not really intended to
be stacked. How would we make unmap work, for instance? What happens
when the underlying iommu dma ops actually natively understands p2p
and doesn't want the shim?
I think this opens an even bigger can of worms..
Lets find a strategy to safely push this into dma_ops.
What about something more incremental like this instead:
- dma_ops will set map_sg_p2p == map_sg when they are updated to
support p2p, otherwise DMA on P2P pages will fail for those ops.
- When all ops support p2p we remove the if and ops->map_sg then
just call map_sg_p2p
- For now the scatterlist maintains a bit when pages are added indicating if
p2p memory might be present in the list.
- Unmap for p2p and non-p2p is the same, the underlying ops driver has
to make it work.
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 0977317c6835c2..505ed7d502053d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -103,6 +103,9 @@ struct dma_map_ops {
int (*map_sg)(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir,
unsigned long attrs);
+ int (*map_sg_p2p)(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs);
void (*unmap_sg)(struct device *dev,
struct scatterlist *sg, int nents,
enum dma_data_direction dir,
@@ -244,7 +247,15 @@ static inline int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
for_each_sg(sg, s, nents, i)
kmemcheck_mark_initialized(sg_virt(s), s->length);
BUG_ON(!valid_dma_direction(dir));
- ents = ops->map_sg(dev, sg, nents, dir, attrs);
+
+ if (sg_has_p2p(sg)) {
+ if (ops->map_sg_p2p)
+ ents = ops->map_sg_p2p(dev, sg, nents, dir, attrs);
+ else
+ return 0;
+ } else
+ ents = ops->map_sg(dev, sg, nents, dir, attrs);
+
BUG_ON(ents < 0);
debug_dma_map_sg(dev, sg, nents, ents, dir);
^ permalink raw reply related
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Logan Gunthorpe @ 2017-04-18 20:48 UTC (permalink / raw)
To: Dan Williams, Jerome Glisse
Cc: Jason Gunthorpe, Benjamin Herrenschmidt, Bjorn Helgaas,
Christoph Hellwig, Sagi Grimberg, James E.J. Bottomley,
Martin K. Petersen, Jens Axboe, Steve Wise, Stephen Bates,
Max Gurtovoy, Keith Busch, linux-pci, linux-scsi, linux-nvme,
linux-rdma, linux-nvdimm, linux-kernel@vger.kernel.org
In-Reply-To: <CAPcyv4hTWbXkdeCEO9O0UM-EPcSjpdHCh7vDpSoNs1kB-Kup3A@mail.gmail.com>
On 18/04/17 02:31 PM, Dan Williams wrote:
> On Tue, Apr 18, 2017 at 1:29 PM, Jerome Glisse <jglisse@redhat.com> wrote:
>>> On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe <logang@deltatee.com>
>>> wrote:
>>>>
>>>>
>>>> On 18/04/17 01:01 PM, Jason Gunthorpe wrote:
>>>>> Ultimately every dma_ops will need special code to support P2P with
>>>>> the special hardware that ops is controlling, so it makes some sense
>>>>> to start by pushing the check down there in the first place. This
>>>>> advice is partially motivated by how dma_map_sg is just a small
>>>>> wrapper around the function pointer call...
>>>>
>>>> Yes, I noticed this problem too and that makes sense. It just means
>>>> every dma_ops will probably need to be modified to either support p2p
>>>> pages or fail on them. Though, the only real difficulty there is that it
>>>> will be a lot of work.
>>>
>>> I don't think you need to go touch all dma_ops, I think you can just
>>> arrange for devices that are going to do dma to get redirected to a
>>> p2p aware provider of operations that overrides the system default
>>> dma_ops. I.e. just touch get_dma_ops().
>>
>> This would not work well for everyone, for instance on GPU we usualy
>> have buffer object with a mix of device memory and regular system
>> memory but call dma sg map once for the list.
>>
>
> ...and that dma_map goes through get_dma_ops(), so I don't see the conflict?
The main conflict is in dma_map_sg which only does get_dma_ops once but
the sg may contain memory of different types.
Logan
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Dan Williams @ 2017-04-18 20:31 UTC (permalink / raw)
To: Jerome Glisse
Cc: Logan Gunthorpe, Jason Gunthorpe, Benjamin Herrenschmidt,
Bjorn Helgaas, Christoph Hellwig, Sagi Grimberg,
James E.J. Bottomley, Martin K. Petersen, Jens Axboe, Steve Wise,
Stephen Bates, Max Gurtovoy, Keith Busch,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-scsi,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, linux-nvdimm,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1565047873.28680036.1492547352121.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Apr 18, 2017 at 1:29 PM, Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
>> wrote:
>> >
>> >
>> > On 18/04/17 01:01 PM, Jason Gunthorpe wrote:
>> >> Ultimately every dma_ops will need special code to support P2P with
>> >> the special hardware that ops is controlling, so it makes some sense
>> >> to start by pushing the check down there in the first place. This
>> >> advice is partially motivated by how dma_map_sg is just a small
>> >> wrapper around the function pointer call...
>> >
>> > Yes, I noticed this problem too and that makes sense. It just means
>> > every dma_ops will probably need to be modified to either support p2p
>> > pages or fail on them. Though, the only real difficulty there is that it
>> > will be a lot of work.
>>
>> I don't think you need to go touch all dma_ops, I think you can just
>> arrange for devices that are going to do dma to get redirected to a
>> p2p aware provider of operations that overrides the system default
>> dma_ops. I.e. just touch get_dma_ops().
>
> This would not work well for everyone, for instance on GPU we usualy
> have buffer object with a mix of device memory and regular system
> memory but call dma sg map once for the list.
>
...and that dma_map goes through get_dma_ops(), so I don't see the conflict?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Jerome Glisse @ 2017-04-18 20:29 UTC (permalink / raw)
To: Dan Williams
Cc: Jens Axboe, Keith Busch, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Gunthorpe,
Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-nvdimm,
Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <CAPcyv4gScx6A7vG9VEHpNF41GOy1Nxst7QQ3QC3uZ54bWoxbMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe <logang@deltatee.com>
> wrote:
> >
> >
> > On 18/04/17 01:01 PM, Jason Gunthorpe wrote:
> >> Ultimately every dma_ops will need special code to support P2P with
> >> the special hardware that ops is controlling, so it makes some sense
> >> to start by pushing the check down there in the first place. This
> >> advice is partially motivated by how dma_map_sg is just a small
> >> wrapper around the function pointer call...
> >
> > Yes, I noticed this problem too and that makes sense. It just means
> > every dma_ops will probably need to be modified to either support p2p
> > pages or fail on them. Though, the only real difficulty there is that it
> > will be a lot of work.
>
> I don't think you need to go touch all dma_ops, I think you can just
> arrange for devices that are going to do dma to get redirected to a
> p2p aware provider of operations that overrides the system default
> dma_ops. I.e. just touch get_dma_ops().
This would not work well for everyone, for instance on GPU we usualy
have buffer object with a mix of device memory and regular system
memory but call dma sg map once for the list.
Cheers,
Jérôme
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Logan Gunthorpe @ 2017-04-18 20:06 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <20170418194845.GA22895-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 18/04/17 01:48 PM, Jason Gunthorpe wrote:
> I think this is why progress on this keeps getting stuck - every
> solution is a lot of work.
Yup! There's also a ton of work just to get the iomem safety issues
addressed. Let alone the dma mapping issues.
> You could try to do a dummy mapping / create a MR early on to detect
> this.
Ok, that could be a workable solution.
> FWIW, I wonder if from a RDMA perspective we have another
> problem.. Should we allow P2P memory to be used with the local DMA
> lkey? There are potential designs around virtualization that would not
> allow that. Should we mandate that P2P memory be in its own MR?
I can't say I understand these issues...
Logan
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Jason Gunthorpe @ 2017-04-18 19:48 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <df1351d8-b86c-2e21-1948-4688ece5dc2b-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Tue, Apr 18, 2017 at 01:35:32PM -0600, Logan Gunthorpe wrote:
> > Ultimately every dma_ops will need special code to support P2P with
> > the special hardware that ops is controlling, so it makes some sense
> > to start by pushing the check down there in the first place. This
> > advice is partially motivated by how dma_map_sg is just a small
> > wrapper around the function pointer call...
>
> Yes, I noticed this problem too and that makes sense. It just means
> every dma_ops will probably need to be modified to either support p2p
> pages or fail on them. Though, the only real difficulty there is that it
> will be a lot of work.
I think this is why progress on this keeps getting stuck - every
solution is a lot of work.
> > Where p2p_same_segment_map_page checks if the two devices are on the
> > 'same switch' and if so returns the address translated to match the
> > bus address programmed into the BAR or fails. We knows this case is
> > required to work by the PCI spec, so it makes sense to use it as the
> > first canned helper.
>
> I've also suggested that this check should probably be done (or perhaps
> duplicated) before we even get to the map stage.
Since the mechanics of the check is essentially unique to every
dma-ops I would not hoist it out of the map function without a really
good reason.
> In the case of nvme-fabrics we'd probably want to let the user know
> when they try to configure it or at least fall back to allocating
> regular memory instead.
You could try to do a dummy mapping / create a MR early on to detect
this.
FWIW, I wonder if from a RDMA perspective we have another
problem.. Should we allow P2P memory to be used with the local DMA
lkey? There are potential designs around virtualization that would not
allow that. Should we mandate that P2P memory be in its own MR?
Jason
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Dan Williams @ 2017-04-18 19:48 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Jens Axboe, Keith Busch, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Gunthorpe,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <df1351d8-b86c-2e21-1948-4688ece5dc2b-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> wrote:
>
>
> On 18/04/17 01:01 PM, Jason Gunthorpe wrote:
>> Ultimately every dma_ops will need special code to support P2P with
>> the special hardware that ops is controlling, so it makes some sense
>> to start by pushing the check down there in the first place. This
>> advice is partially motivated by how dma_map_sg is just a small
>> wrapper around the function pointer call...
>
> Yes, I noticed this problem too and that makes sense. It just means
> every dma_ops will probably need to be modified to either support p2p
> pages or fail on them. Though, the only real difficulty there is that it
> will be a lot of work.
I don't think you need to go touch all dma_ops, I think you can just
arrange for devices that are going to do dma to get redirected to a
p2p aware provider of operations that overrides the system default
dma_ops. I.e. just touch get_dma_ops().
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Logan Gunthorpe @ 2017-04-18 19:35 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <20170418190138.GH7181-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 18/04/17 01:01 PM, Jason Gunthorpe wrote:
> Ultimately every dma_ops will need special code to support P2P with
> the special hardware that ops is controlling, so it makes some sense
> to start by pushing the check down there in the first place. This
> advice is partially motivated by how dma_map_sg is just a small
> wrapper around the function pointer call...
Yes, I noticed this problem too and that makes sense. It just means
every dma_ops will probably need to be modified to either support p2p
pages or fail on them. Though, the only real difficulty there is that it
will be a lot of work.
> Where p2p_same_segment_map_page checks if the two devices are on the
> 'same switch' and if so returns the address translated to match the
> bus address programmed into the BAR or fails. We knows this case is
> required to work by the PCI spec, so it makes sense to use it as the
> first canned helper.
I've also suggested that this check should probably be done (or perhaps
duplicated) before we even get to the map stage. In the case of
nvme-fabrics we'd probably want to let the user know when they try to
configure it or at least fall back to allocating regular memory instead.
It would be a difficult situation to have already copied a block of data
from a NIC to p2p memory only to have it be deemed unmappable on the
NVMe device it's destined for. (Or vice-versa.) This was another issue
p2pmem was attempting to solve.
Logan
^ permalink raw reply
* 车间为什么忙er乱,管理不到位吗?
From: 傅�樟 @ 2017-04-18 19:25 UTC (permalink / raw)
To: linux-nvdimm
[-- Attachment #1: Type: text/plain, Size: 24 bytes --]
Çë ²é ÔÄ ¸½ ¼þ ÄÚ ÈÝ
[-- Attachment #2: Type: text/plain, Size: 178 bytes --]
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Jason Gunthorpe @ 2017-04-18 19:01 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <cce00131-1f28-27b3-40ab-04f8783f1e5a-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Tue, Apr 18, 2017 at 12:30:59PM -0600, Logan Gunthorpe wrote:
> > - The dma ops provider must be able to tell if source memory is bar
> > mapped and recover the pci device backing the mapping.
>
> Do you mean to say that every dma-ops provider needs to be taught about
> p2p backed pages? I was hoping we could have dma_map_* just use special
> p2p dma-ops if it was passed p2p pages (though there are some
> complications to this too).
I think that is how it will end up working out if this is the path..
Ultimately every dma_ops will need special code to support P2P with
the special hardware that ops is controlling, so it makes some sense
to start by pushing the check down there in the first place. This
advice is partially motivated by how dma_map_sg is just a small
wrapper around the function pointer call...
Something like:
foo_dma_map_sg(...)
{
for (every page in sg)
if (page is p2p)
dma_addr[I] = p2p_same_segment_map_page(...);
}
Where p2p_same_segment_map_page checks if the two devices are on the
'same switch' and if so returns the address translated to match the
bus address programmed into the BAR or fails. We knows this case is
required to work by the PCI spec, so it makes sense to use it as the
first canned helper.
This also proves out the basic idea that the dma ops can recover the
pci device and perform an inspection of the traversed fabric path.
>From there every arch would have to expand the implementation to
support a wider range of things. Eg x86 with no iommu and no offset
could allow every address to be used based on a host bridge white
list.
Jason
^ permalink raw reply
* Increase exposure of ml01.01.org with FB Groups Post Reach
From: MATTHEW @ 2017-04-18 18:48 UTC (permalink / raw)
To: linux-nvdimm-y27Ovi1pjclAfugRpC6u6w
[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]
Spam detection software, running on the system "blaine.gmane.org",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: Hello, FB Groups posting !service to reach millions of FB
users: http://www.socialflowgroup.com/detail.php?id=12 Regards MATTHEW Unsubscribe
option is available on the footer of our website [...]
Content analysis details: (13.1 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist
[URIs: socialflowgroup.com]
1.7 URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist
[URIs: socialflowgroup.com]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[198.145.21.10 listed in list.dnswl.org]
1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see <http://www.spamcop.net/bl.shtml?182.16.74.250>]
0.1 URIBL_SBL_A Contains URL's A record listed in the SBL blocklist
[URIs: www.socialflowgroup.com]
1.2 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
[URIs: socialflowgroup.com]
2.8 FSL_HELO_FAKE No description available.
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
0.0 T_HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
domains are different
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(kipemilf56[at]gmail.com)
0.2 FREEMAIL_REPLYTO_END_DIGIT Reply-To freemail username ends in digit
(kipemilf56[at]gmail.com)
-0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5%
[score: 0.0109]
0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
[cf: 100]
1.9 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
above 50%
[cf: 100]
0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/)
1.6 URIBL_SBL Contains an URL's NS IP listed in the SBL blocklist
[URIs: www.socialflowgroup.com]
0.0 T_FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
EnvelopeFrom freemail headers are different
[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Size: 2740 bytes --]
From: "MATTHEW" <kipemilf56-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org>
Subject: Increase exposure of ml01.01.org with FB Groups Post Reach
Date: Tue, 18 Apr 2017 11:48:27 -0700
Message-ID: <C957C1A8.917054EC-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello,
FB Groups posting !service to reach millions of FB users:
http://www.socialflowgroup.com/detail.php?id=12
Regards
MATTHEW
Unsubscribe option is available on the footer of our website
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* 如何dui工资奖金进行避税筹划(含外籍人士)
From: 雷�u小 @ 2017-04-18 18:39 UTC (permalink / raw)
To: linux-nvdimm
企业中高收入者(含外籍人士)的工资奖金避税筹划
Tax Avoidance for Mid & High Income Earners of Salaries and Bonuses Including expatriates
以实用方法和技巧,帮助企业骨干和外籍人士有效避税
举办时间:2017年4月20上海 4月27深圳 7月20上海 7月27深圳
费 用:1800元/人(包括资料费、午餐及上下午茶点等)
课程对象:企业中高收入者
报名咨询电话:0755-61288035 010-51661863 021-31261580
在线咨询 QQ:6983436 报名信箱:6983436@qq.com (报名请回复尾末报名表)
课程背景:
作为纳税人,您每年都要因为支付工资奖金而交纳很大数额的个人所得税和企业所得税。但是,您是否计算过,在您交纳的税额中,有相当大的部分是可以通过有效地避税筹划方法而合法、合理地免除的?
As taxpayers, you need to pay large amount of personal income tax and corporate income tax wages because of salaries and bonuses. But, have you ever thought about that a considerable part of your tax paid can be legally and reasonably avoided through effective tax planning methods.
自新《个人所得税法实施条例》执行以来,大大增加了企业管理、营销和技术骨干及外籍人士等中高收入者的税负!而且,国税总局正在采取更为严厉的政策和措施,以加强对中高收入者的税收征管,并由此直接影响到今年的企业所得税!因此,掌握合理、合法的避税方法及技巧是十分必要的,因为这将大大减轻您的税负,从而有效地避免您个人的经济损失并增加企业的效益!
Since the "law on personal income tax regulations" implementation, greatly increased the high income of enterprise management, marketing and technical backbone and foreign nationals in the tax burden! Moreover, the national tax administration is taking more policies and strict measures, to strengthen tax collection and management of high earners, and thus directly affect the enterprise income tax! Therefore, it is necessary to master skills and avoidance method is reasonable and legitimate, because it will reduce your tax burden, thus effectively avoiding your personal economic loss and increase the efficiency of enterprises!
课程收益:
专家将根据最新的税收征管动向以及个人所得税热点问题进行讨论,帮您建立合法且长期有效的个税避税思路及方案!
Experts will be based on the tax issue the new tax collection and administration of individual income trends and discussions, help you establish legitimate and effective long-term tax avoidance ideas and solutions.
通过30多种实用避税方法,大大减轻贵公司管理、营销和技术骨干及外籍人士等中高收入者的税负!
By the 30 kinds of practical method of tax evasion, high income greatly reduce your company management, marketing and technical backbone and foreign nationals in the tax burden.
专家还将为您提供一系列降低工资费用相关的企业所得税的避税方案,以增加企业的经济效益!
Experts will also provide a series of tax avoidance schemes reduce wage costs related to the enterprise income tax for you, in order to increase the economic efficiency of enterprises.
专家将结合精选案例进行授课,并且现场答疑解惑,解决您工作中的棘手问题!您还有机会与同行就共同的问题进行交流并从中受益!
Experts will teach in combination with case selection, and on-site FAQ, to solve difficult problems in your work! You still have a chance with peers on the common problems in communication and benefit from.
课程大纲:
1. 个人所得税法对中高收入者的影响分析 /Analysis on the effect of 1/0 on individual income tax on high earners
新法法规透析 /New regulations dialysis
税收监管动态透析 /tax regulation dynamic dialysis
新法对工资奖金税收影响分析 /Analysis of the impact of the new law on wage bonus tax ・
2. 中高收入者的避税筹划思路 /In the high income tax planning
纳税人筹划及案例分析 /taxpayer planning and case analysis
税种筹划及案例分析 /taxes and case analysis
征税项目的筹划及案例分析 /Planning and case analysis of ・ of taxable items
减少计税依据的筹划及案例分析 /Planning and case analysis of tax based on reducing
降低适用税率的筹划及案例分析 /Planning and case analysis of the applicable tax rate reduced
选择计税方法的筹划及案例分析 /selection planning and case analysis methods
3. 中高收入者工资薪金的个税避税筹划及案例分析 /Analysis of wages and salaries tax avoidance planning and case of 3/0 in the high income
企业薪资方案的设计 /Design ・ salary scheme
工资费用化项目的选择与实施 /Selection and implementation of ・ salary expense items
工资发放方法的筹划 /payroll for planning
最低工资的税负方案 /minimum wage tax scheme
多处取得工资的避税计划 /many get wage tax plan
年金的避税筹划 /annuity tax planning
福利费的避税筹划 /welfare tax planning
劳务报酬的避税筹 /The remuneration of labor tax planning
工资项目转化,等等 /Wage project transformation, etc.
4. 中高收入者的奖金避税筹划及案例 /In the high income bonus tax planning and case
奖金发放形式的避税筹划 /Planning ・ bonus forms of tax avoidance
奖金最低税负方案的设计 /Design ・ bonus minimum tax scheme
年终一次性奖金的避税筹划 /Planning the yearly lump sum bonus tax
包干奖金的避税筹划 /lump sum bonus tax planning
奖金发放时间的避税筹划,等等 /Planning the bonus tax, etc.
5. 工资费用的企业所得税筹划 /Wage costs of the enterprise income tax planning
为职工支付其他费用的所得税扣除 /Income tax ・ pay for other expenses for employees deduction
工资税前列支方式的所得税筹划 /Income tax planning ・ payroll tax xpenses method
利用工资附加费的企业所得税筹划 /use wage surcharge of enterprise income tax planning
基于降低税负的企业年金方案设计 /designed to reduce the tax burden on enterprise annuity plan
基于降低税负的工薪方案设计等 /reduce the tax burden of working scheme design based on
6. 外籍个人工资奖金所得税避税筹划 /Foreign individuals pay bonuses income tax tax planning
销售和市场业务管理制度 /sales and marketing business management system
外籍个人纳税义务的认定 /foreign individuals that the obligation of tax payment
外籍个人工资最低税负方案的筹划 /foreign individuals pay minimum tax scheme planning
改变住所的税收筹划 /change residence tax planning
出境时间的税收筹划 /Tax planning ・ exit time
外籍个人工资支付地的税收筹划 /foreign individuals pay more tax planning
外籍个人工资来源地的税收筹划 /foreign individuals pay tax planning of the sources
外籍个人收入项目转变的税收筹划 /Transformation of foreign personal income tax planning throughout the project
外籍个人先分配后转让的税收筹划 /Tax planning ・ foreign individuals assign transfer
外籍个人工资福利化的税收筹划 /Tax planning ・ foreign individuals wages and welfare
利用税收优惠政策的税收筹划 /the use of tax preferential policies in tax planning
7. 企业年金在企业薪酬福利体系中的最佳实践 /The best practice of Enterprise annuity in enterprise salary welfare system
新政出台优化员工整体薪酬安排新的机遇 /issued new optimization overall employee compensation arrangements for new opportunities
新政对企业在人才吸引与保留的重要作用 /new enterprises in attracting talent and retain an important role
企业年金与社保的关系、企业年金是否强制建立?建立条件是什么?如何建立?/Relationship, pension and social security ・ enterprises annuity whether forced up? To establish what is the condition? How to set?
企业年金的缴费、成本、计税及提取规则 /enterprise annuity payment, cost, tax and extraction rules
员工离职要求一次性提取年金是否应获支持?/employee turnover requirement extract annuity should be supported?
补缴年金争议是否属劳动争议范畴? /payment of annuity dispute whether it belongs to the category of labor dispute?
擅自停缴企业年金是否合法?修正年金办法是否适用离职员工?
专家介绍
黄丽霞 财务系统规范化专家
中国(深圳)股权研究中心特聘 财务专家
数十家中小企业的长年顾问
多年上市公司财务内控从业经验,参与三川集团上市全过程,熟悉企业资本运作对财务管理要求。多年会计事务所第三方审计从业经验,熟练掌握"会计、税务、海关"等法律法规、进出口退税及节税、内部审计、全面预算管理技,对税务筹划、资产管理、内部风险管控有独到见解。
主讲课程包括《财务系统落地班》 、《老板利润管控》 、《财务总监特训营》、《年度预算管理》 。
财务系统构建管理咨询策划的实战指导经验丰富,经过多年实战锻炼,黄老师在财务,尤其是在企业财务系统规范化落地建设、预算管理,企业内部管理、成本管理,风险管理等领域积累了丰富的经验。将财务管理和经营管理融为一体,教学方法深入浅出、思路严谨,让学员们在轻松的学习氛围中能够深入思考,将所学知识运用到自己的工作中去,为自己和所服务单位增加价值。
咨询服务企业部份展示:罗莱生活科技股份有限公司、上海莱芙生活家纺有限公司、济源海湾实业有限公司、广州唐人街鞋业有限公司、厦门骏利德贸易有限公司、哈尔滨胜塬门窗有限公司、广州市幸福家居贸易有限公司、东莞市石来运转餐饮管理有限公司、三河市盛繁商贸有限公司、河源市全能宝宝儿童潜能开发有限公司、哈尔滨华辕车业二手车有限公司……
《企业中高收入者(含外籍人士)的工资奖金避税筹划》报名回执
(在线报名请下载附件报名回执表填写后发送 至信箱 6983436@qq.com)
单位名称:________________
发票抬头:________________
公司地址:________________
联系人:________电话:________手机:________
职务:________传真:________E-mail:________
参会人数:____人 参会费用: ____元
参加学员名单:
姓名:________职务:________手 机:________E-mail:________
姓名:________职务:________手 机:________E-mail:________
姓名:________职务:________手 机:________E-mail:________
姓名:________职务:________手 机:________E-mail:________
姓名:________职务:________手 机:________E-mail:________
付款方式:□1、现金 □2、转帐
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Dan Williams @ 2017-04-18 18:34 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <20170418180020.GE7181-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Tue, Apr 18, 2017 at 11:00 AM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> On Tue, Apr 18, 2017 at 10:27:47AM -0700, Dan Williams wrote:
>> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we
>> > already have APIs that map BAR memory to user space, and would like to
>> > keep using them. A 'enable P2P for bar' helper function sounds better
>> > to me.
>>
>> ...and I think it's not a helper function as much as asking the bus
>> provider "can these two device dma to each other".
>
> What I mean I could write in a RDMA driver:
>
> /* Allow the memory in BAR 1 to be the target of P2P transactions */
> pci_enable_p2p_bar(dev, 1);
>
> And not require anything else..
>
>> The "helper" is the dma api redirecting through a software-iommu
>> that handles bus address translation differently than it would
>> handle host memory dma mapping.
>
> Not sure, until we see what arches actually need to do here it is hard
> to design common helpers.
>
> Here are a few obvious things that arches will need to implement to
> support this broadly:
>
> - Virtualization might need to do a hypervisor call to get the right
> translation, or consult some hypervisor specific description table.
>
> - Anything using IOMMUs for virtualization will need to setup IOMMU
> permissions to allow the P2P flow, this might require translation to
> an address cookie.
>
> - Fail if the PCI devices are in different domains, or setup hardware to
> do completion bus/device/function translation.
>
> - All platforms can succeed if the PCI devices are under the same
> 'segment', but where segments begin is somewhat platform specific
> knowledge. (this is 'same switch' idea Logan has talked about)
>
> So, we can eventually design helpers for various common scenarios, but
> until we see what arch code actually needs to do it seems
> premature. Much of this seems to involve interaction with some kind of
> hardware, or consulation of some kind of currently platform specific
> data, so I'm not sure what a software-iommu would be doing??
>
> The main thing to agree on is that this code belongs under dma ops and
> that arches have to support struct page mapped BAR addresses in their
> dma ops inputs. Is that resonable?
I think we're saying the same thing by "software-iommu" and "custom
dma_ops", so yes.
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Logan Gunthorpe @ 2017-04-18 18:30 UTC (permalink / raw)
To: Jason Gunthorpe, Benjamin Herrenschmidt
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Steve Wise,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-scsi, linux-nvdimm,
Max Gurtovoy, Christoph Hellwig
In-Reply-To: <20170418164557.GA7181-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 18/04/17 10:45 AM, Jason Gunthorpe wrote:
> From Ben's comments, I would think that the 'first class' support that
> is needed here is simply a function to return the 'struct device'
> backing a CPU address range.
Yes, and Dan's get_dev_pagemap suggestion gets us 90% of the way there.
It's just a disagreement as to what struct device is inside the pagemap.
Care needs to be taken to ensure that struct device doesn't conflict
with hmm and doesn't limit other potential future users of ZONE_DEVICE.
> If there is going to be more core support for this stuff I think it
> will be under the topic of more robustly describing the fabric to the
> core and core helpers to extract data from the description: eg compute
> the path, check if the path crosses translation, etc
Agreed, those helpers would be useful to everyone.
> I think the key agreement to get out of Logan's series is that P2P DMA
> means:
> - The BAR will be backed by struct pages
> - Passing the CPU __iomem address of the BAR to the DMA API is
> valid and, long term, dma ops providers are expected to fail
> or return the right DMA address
Well, yes but we have a _lot_ of work to do to make it safe to pass
around struct pages backed with __iomem. That's where our next focus
will be. I've already taken very initial steps toward this with my
scatterlist map patchset.
> - Mapping BAR memory into userspace and back to the kernel via
> get_user_pages works transparently, and with the DMA API above
Again, we've had a lot of push back for the memory to go to userspace at
all. It does work, but people expect userspace to screw it up in a lot
of ways. Among the people pushing back on that: Christoph Hellwig has
specifically said he wants to see this stay with in-kernel users only
until the apis can be worked out. This is one of the reasons we decided
to go with enabling nvme-fabrics as everything remains in the kernel.
And with that decision we needed a common in-kernel allocation
infrastructure: this is what p2pmem really is at this point.
> - The dma ops provider must be able to tell if source memory is bar
> mapped and recover the pci device backing the mapping.
Do you mean to say that every dma-ops provider needs to be taught about
p2p backed pages? I was hoping we could have dma_map_* just use special
p2p dma-ops if it was passed p2p pages (though there are some
complications to this too).
> At least this is what we'd like in RDMA :)
>
> FWIW, RDMA probably wouldn't want to use a p2mem device either, we
> already have APIs that map BAR memory to user space, and would like to
> keep using them. A 'enable P2P for bar' helper function sounds better
> to me.
Well, in the end that will likely come down to just devm_memremap_pages
with some (presently undecided) struct device that can be used to get
special p2p dma-ops for the bus.
Logan
^ permalink raw reply
* [PATCH] acpi, nfit: fix module unload vs workqueue shutdown race
From: Dan Williams @ 2017-04-18 18:06 UTC (permalink / raw)
To: linux-nvdimm; +Cc: linux-acpi
The workqueue may still be running when the devres callbacks start
firing to deallocate an acpi_nfit_desc instance. Stop and flush the
workqueue before letting any other devres de-allocations proceed.
Reported-by: Linda Knippers <linda.knippers@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
I was able to produce a reliable nfit_test crash failure by running the
tests on hardware *and* disabling all debug messages. That last detail
may be why I have been seeing much less frequent failures. With this
change, in addition to the previous fix [1], I was again able to
complete a successful run.
[1]: https://patchwork.kernel.org/patch/9681861/
drivers/acpi/nfit/core.c | 76 +++++++++++++++++++++++---------------
drivers/acpi/nfit/nfit.h | 1 +
tools/testing/nvdimm/test/nfit.c | 4 ++
3 files changed, 51 insertions(+), 30 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 69c6cc77130c..261eea1d2906 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2604,7 +2604,8 @@ static int acpi_nfit_register_regions(struct acpi_nfit_desc *acpi_desc)
return rc;
}
- queue_work(nfit_wq, &acpi_desc->work);
+ if (!acpi_desc->cancel)
+ queue_work(nfit_wq, &acpi_desc->work);
return 0;
}
@@ -2650,32 +2651,11 @@ static int acpi_nfit_desc_init_scrub_attr(struct acpi_nfit_desc *acpi_desc)
return 0;
}
-static void acpi_nfit_destruct(void *data)
+static void acpi_nfit_unregister(void *data)
{
struct acpi_nfit_desc *acpi_desc = data;
- struct device *bus_dev = to_nvdimm_bus_dev(acpi_desc->nvdimm_bus);
- /*
- * Destruct under acpi_desc_lock so that nfit_handle_mce does not
- * race teardown
- */
- mutex_lock(&acpi_desc_lock);
- acpi_desc->cancel = 1;
- /*
- * Bounce the nvdimm bus lock to make sure any in-flight
- * acpi_nfit_ars_rescan() submissions have had a chance to
- * either submit or see ->cancel set.
- */
- device_lock(bus_dev);
- device_unlock(bus_dev);
-
- flush_workqueue(nfit_wq);
- if (acpi_desc->scrub_count_state)
- sysfs_put(acpi_desc->scrub_count_state);
nvdimm_bus_unregister(acpi_desc->nvdimm_bus);
- acpi_desc->nvdimm_bus = NULL;
- list_del(&acpi_desc->list);
- mutex_unlock(&acpi_desc_lock);
}
int acpi_nfit_init(struct acpi_nfit_desc *acpi_desc, void *data, acpi_size sz)
@@ -2693,7 +2673,7 @@ int acpi_nfit_init(struct acpi_nfit_desc *acpi_desc, void *data, acpi_size sz)
if (!acpi_desc->nvdimm_bus)
return -ENOMEM;
- rc = devm_add_action_or_reset(dev, acpi_nfit_destruct,
+ rc = devm_add_action_or_reset(dev, acpi_nfit_unregister,
acpi_desc);
if (rc)
return rc;
@@ -2787,9 +2767,10 @@ static int acpi_nfit_flush_probe(struct nvdimm_bus_descriptor *nd_desc)
/* bounce the init_mutex to make init_complete valid */
mutex_lock(&acpi_desc->init_mutex);
- mutex_unlock(&acpi_desc->init_mutex);
- if (acpi_desc->init_complete)
+ if (acpi_desc->cancel || acpi_desc->init_complete) {
+ mutex_unlock(&acpi_desc->init_mutex);
return 0;
+ }
/*
* Scrub work could take 10s of seconds, userspace may give up so we
@@ -2798,6 +2779,7 @@ static int acpi_nfit_flush_probe(struct nvdimm_bus_descriptor *nd_desc)
INIT_WORK_ONSTACK(&flush.work, flush_probe);
COMPLETION_INITIALIZER_ONSTACK(flush.cmp);
queue_work(nfit_wq, &flush.work);
+ mutex_unlock(&acpi_desc->init_mutex);
rc = wait_for_completion_interruptible(&flush.cmp);
cancel_work_sync(&flush.work);
@@ -2834,10 +2816,12 @@ int acpi_nfit_ars_rescan(struct acpi_nfit_desc *acpi_desc)
if (work_busy(&acpi_desc->work))
return -EBUSY;
- if (acpi_desc->cancel)
+ mutex_lock(&acpi_desc->init_mutex);
+ if (acpi_desc->cancel) {
+ mutex_unlock(&acpi_desc->init_mutex);
return 0;
+ }
- mutex_lock(&acpi_desc->init_mutex);
list_for_each_entry(nfit_spa, &acpi_desc->spas, list) {
struct acpi_nfit_system_address *spa = nfit_spa->spa;
@@ -2886,6 +2870,35 @@ static void acpi_nfit_put_table(void *table)
acpi_put_table(table);
}
+void acpi_nfit_shutdown(void *data)
+{
+ struct acpi_nfit_desc *acpi_desc = data;
+ struct device *bus_dev = to_nvdimm_bus_dev(acpi_desc->nvdimm_bus);
+
+ /*
+ * Destruct under acpi_desc_lock so that nfit_handle_mce does not
+ * race teardown
+ */
+ mutex_lock(&acpi_desc_lock);
+ list_del(&acpi_desc->list);
+ mutex_unlock(&acpi_desc_lock);
+
+ mutex_lock(&acpi_desc->init_mutex);
+ acpi_desc->cancel = 1;
+ mutex_unlock(&acpi_desc->init_mutex);
+
+ /*
+ * Bounce the nvdimm bus lock to make sure any in-flight
+ * acpi_nfit_ars_rescan() submissions have had a chance to
+ * either submit or see ->cancel set.
+ */
+ device_lock(bus_dev);
+ device_unlock(bus_dev);
+
+ flush_workqueue(nfit_wq);
+}
+EXPORT_SYMBOL_GPL(acpi_nfit_shutdown);
+
static int acpi_nfit_add(struct acpi_device *adev)
{
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
@@ -2933,12 +2946,15 @@ 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));
- return rc;
+
+ if (rc)
+ return rc;
+ return devm_add_action_or_reset(dev, acpi_nfit_shutdown, acpi_desc);
}
static int acpi_nfit_remove(struct acpi_device *adev)
{
- /* see acpi_nfit_destruct */
+ /* see acpi_nfit_unregister */
return 0;
}
diff --git a/drivers/acpi/nfit/nfit.h b/drivers/acpi/nfit/nfit.h
index fac098bfa585..58fb7d68e04a 100644
--- a/drivers/acpi/nfit/nfit.h
+++ b/drivers/acpi/nfit/nfit.h
@@ -239,6 +239,7 @@ static inline struct acpi_nfit_desc *to_acpi_desc(
const u8 *to_nfit_uuid(enum nfit_uuids id);
int acpi_nfit_init(struct acpi_nfit_desc *acpi_desc, void *nfit, acpi_size sz);
+void acpi_nfit_shutdown(void *data);
void __acpi_nfit_notify(struct device *dev, acpi_handle handle, u32 event);
void __acpi_nvdimm_notify(struct device *dev, u32 event);
int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c
index d7fb1b894128..c2187178fb13 100644
--- a/tools/testing/nvdimm/test/nfit.c
+++ b/tools/testing/nvdimm/test/nfit.c
@@ -1851,6 +1851,10 @@ static int nfit_test_probe(struct platform_device *pdev)
if (rc)
return rc;
+ rc = devm_add_action_or_reset(&pdev->dev, acpi_nfit_shutdown, acpi_desc);
+ if (rc)
+ return rc;
+
if (nfit_test->setup != nfit_test0_setup)
return 0;
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply related
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Jason Gunthorpe @ 2017-04-18 18:00 UTC (permalink / raw)
To: Dan Williams
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <CAPcyv4izLa2vw12ysvVfd=ysaMKcASNFm+=CaqDKhnPY9B5OJg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 18, 2017 at 10:27:47AM -0700, Dan Williams wrote:
> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we
> > already have APIs that map BAR memory to user space, and would like to
> > keep using them. A 'enable P2P for bar' helper function sounds better
> > to me.
>
> ...and I think it's not a helper function as much as asking the bus
> provider "can these two device dma to each other".
What I mean I could write in a RDMA driver:
/* Allow the memory in BAR 1 to be the target of P2P transactions */
pci_enable_p2p_bar(dev, 1);
And not require anything else..
> The "helper" is the dma api redirecting through a software-iommu
> that handles bus address translation differently than it would
> handle host memory dma mapping.
Not sure, until we see what arches actually need to do here it is hard
to design common helpers.
Here are a few obvious things that arches will need to implement to
support this broadly:
- Virtualization might need to do a hypervisor call to get the right
translation, or consult some hypervisor specific description table.
- Anything using IOMMUs for virtualization will need to setup IOMMU
permissions to allow the P2P flow, this might require translation to
an address cookie.
- Fail if the PCI devices are in different domains, or setup hardware to
do completion bus/device/function translation.
- All platforms can succeed if the PCI devices are under the same
'segment', but where segments begin is somewhat platform specific
knowledge. (this is 'same switch' idea Logan has talked about)
So, we can eventually design helpers for various common scenarios, but
until we see what arch code actually needs to do it seems
premature. Much of this seems to involve interaction with some kind of
hardware, or consulation of some kind of currently platform specific
data, so I'm not sure what a software-iommu would be doing??
The main thing to agree on is that this code belongs under dma ops and
that arches have to support struct page mapped BAR addresses in their
dma ops inputs. Is that resonable?
Jason
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Dan Williams @ 2017-04-18 17:27 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Benjamin Herrenschmidt,
Steve Wise, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm, Max Gurtovoy, linux-scsi, Christoph Hellwig
In-Reply-To: <20170418164557.GA7181-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Tue, Apr 18, 2017 at 9:45 AM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> On Mon, Apr 17, 2017 at 08:23:16AM +1000, Benjamin Herrenschmidt wrote:
>
>> Thanks :-) There's a reason why I'm insisting on this. We have constant
>> requests for this today. We have hacks in the GPU drivers to do it for
>> GPUs behind a switch, but those are just that, ad-hoc hacks in the
>> drivers. We have similar grossness around the corner with some CAPI
>> NICs trying to DMA to GPUs. I have people trying to use PLX DMA engines
>> to whack nVME devices.
>
> A lot of people feel this way in the RDMA community too. We have had
> vendors shipping out of tree code to enable P2P for RDMA with GPU
> years and years now. :(
>
> Attempts to get things in mainline have always run into the same sort
> of road blocks you've identified in this thread..
>
> FWIW, I read this discussion and it sounds closer to an agreement than
> I've ever seen in the past.
>
> From Ben's comments, I would think that the 'first class' support that
> is needed here is simply a function to return the 'struct device'
> backing a CPU address range.
>
> This is the minimal required information for the arch or IOMMU code
> under the dma ops to figure out the fabric source/dest, compute the
> traffic path, determine if P2P is even possible, what translation
> hardware is crossed, and what DMA address should be used.
>
> If there is going to be more core support for this stuff I think it
> will be under the topic of more robustly describing the fabric to the
> core and core helpers to extract data from the description: eg compute
> the path, check if the path crosses translation, etc
>
> But that isn't really related to P2P, and is probably better left to
> the arch authors to figure out where they need to enhance the existing
> topology data..
>
> I think the key agreement to get out of Logan's series is that P2P DMA
> means:
> - The BAR will be backed by struct pages
> - Passing the CPU __iomem address of the BAR to the DMA API is
> valid and, long term, dma ops providers are expected to fail
> or return the right DMA address
> - Mapping BAR memory into userspace and back to the kernel via
> get_user_pages works transparently, and with the DMA API above
> - The dma ops provider must be able to tell if source memory is bar
> mapped and recover the pci device backing the mapping.
>
> At least this is what we'd like in RDMA :)
>
> FWIW, RDMA probably wouldn't want to use a p2mem device either, we
> already have APIs that map BAR memory to user space, and would like to
> keep using them. A 'enable P2P for bar' helper function sounds better
> to me.
...and I think it's not a helper function as much as asking the bus
provider "can these two device dma to each other". The "helper" is the
dma api redirecting through a software-iommu that handles bus address
translation differently than it would handle host memory dma mapping.
^ permalink raw reply
* Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
From: Jason Gunthorpe @ 2017-04-18 16:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jens Axboe, James E.J. Bottomley, Martin K. Petersen,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Steve Wise,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Jerome Glisse, Bjorn Helgaas, linux-scsi, linux-nvdimm,
Max Gurtovoy, Christoph Hellwig
In-Reply-To: <1492381396.25766.43.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Mon, Apr 17, 2017 at 08:23:16AM +1000, Benjamin Herrenschmidt wrote:
> Thanks :-) There's a reason why I'm insisting on this. We have constant
> requests for this today. We have hacks in the GPU drivers to do it for
> GPUs behind a switch, but those are just that, ad-hoc hacks in the
> drivers. We have similar grossness around the corner with some CAPI
> NICs trying to DMA to GPUs. I have people trying to use PLX DMA engines
> to whack nVME devices.
A lot of people feel this way in the RDMA community too. We have had
vendors shipping out of tree code to enable P2P for RDMA with GPU
years and years now. :(
Attempts to get things in mainline have always run into the same sort
of road blocks you've identified in this thread..
FWIW, I read this discussion and it sounds closer to an agreement than
I've ever seen in the past.
>From Ben's comments, I would think that the 'first class' support that
is needed here is simply a function to return the 'struct device'
backing a CPU address range.
This is the minimal required information for the arch or IOMMU code
under the dma ops to figure out the fabric source/dest, compute the
traffic path, determine if P2P is even possible, what translation
hardware is crossed, and what DMA address should be used.
If there is going to be more core support for this stuff I think it
will be under the topic of more robustly describing the fabric to the
core and core helpers to extract data from the description: eg compute
the path, check if the path crosses translation, etc
But that isn't really related to P2P, and is probably better left to
the arch authors to figure out where they need to enhance the existing
topology data..
I think the key agreement to get out of Logan's series is that P2P DMA
means:
- The BAR will be backed by struct pages
- Passing the CPU __iomem address of the BAR to the DMA API is
valid and, long term, dma ops providers are expected to fail
or return the right DMA address
- Mapping BAR memory into userspace and back to the kernel via
get_user_pages works transparently, and with the DMA API above
- The dma ops provider must be able to tell if source memory is bar
mapped and recover the pci device backing the mapping.
At least this is what we'd like in RDMA :)
FWIW, RDMA probably wouldn't want to use a p2mem device either, we
already have APIs that map BAR memory to user space, and would like to
keep using them. A 'enable P2P for bar' helper function sounds better
to me.
Jason
^ permalink raw reply
* Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'
From: Luck, Tony @ 2017-04-18 16:28 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-nvdimm@lists.01.org, x86@kernel.org,
linux-kernel@vger.kernel.org, Thomas Gleixner
In-Reply-To: <20170413121215.kzflalrar7hpxvjh@pd.tnic>
On Thu, Apr 13, 2017 at 02:12:16PM +0200, Borislav Petkov wrote:
> On Thu, Apr 13, 2017 at 01:31:59PM +0200, Borislav Petkov wrote:
> > @@ -321,18 +321,8 @@ static void __print_mce(struct mce *m)
> >
> > static void print_mce(struct mce *m)
> > {
> > - int ret = 0;
> > -
> > __print_mce(m);
> > -
> > - /*
> > - * Print out human-readable details about the MCE error,
> > - * (if the CPU has an implementation for that)
> > - */
> > - ret = atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, m);
> > - if (ret == NOTIFY_STOP)
> > - return;
> > -
> > + mce_log(m);
>
> Actually, we don't need that call here because do_machine_check()
> already does it.
Yes. Don't add mce_log(m) here. We've already done it.
With this change:
Acked-by: Tony Luck <tony.luck@intel.com>
-Tony
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Returned mail: see transcript for details
From: andreas @ 2017-04-18 16:19 UTC (permalink / raw)
To: linux-nvdimm
The original message was received at Wed, 19 Apr 2017 00:19:16 +0800
from meetr.de [109.132.140.89]
----- The following addresses had permanent fatal errors -----
<linux-nvdimm@lists.01.org>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Returned mail: see transcript for details
From: andreas-nJONrVjOgt4 @ 2017-04-18 16:19 UTC (permalink / raw)
To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw
The original message was received at Wed, 19 Apr 2017 00:19:16 +0800
from meetr.de [109.132.140.89]
----- The following addresses had permanent fatal errors -----
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>
^ permalink raw reply
* Re: [ndctl PATCH] ndctl, check: Add a sigbus handler to detect metadata corruption
From: Verma, Vishal L @ 2017-04-18 16:09 UTC (permalink / raw)
To: jmoyer@redhat.com; +Cc: linux-nvdimm@lists.01.org
In-Reply-To: <x49lgqzqc32.fsf@segfault.boston.devel.redhat.com>
On Mon, 2017-04-17 at 11:37 -0400, Jeff Moyer wrote:
> Vishal Verma <vishal.l.verma@intel.com> writes:
>
> > If we have poison/badblocks in the BTT metadata sections, the mmap-
> > reads
> > happening in the checker will trigger a SIGBUS, and the program
> > will
> > halt abruptly. Add a sigbus handler which notifies the user of
> > this, and
> > prints out a relevant error message:
>
> This isn't much better than just segfaulting. Did you consider
> whether
> it was possible to reconstruct corrupt metadata in any circumstances?
>
The only spot we can actually correct metadata would be for an info
block, if the copy is intact. For any other poison in the map or flog,
I don't think we have any way to recover. Was that (info blocks) what
you meant, or something else?
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
From: Logan Gunthorpe @ 2017-04-18 15:59 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-nvdimm@lists.01.org, Steve Wise,
linux-nvme@lists.infradead.org, target-devel@vger.kernel.org,
Sumit Semwal, devel@driverdev.osuosl.org,
rds-devel@oss.oracle.com, xen-devel, linux-scsi@vger.kernel.org,
Matthew Wilcox, linux-rdma@vger.kernel.org, Christoph Hellwig,
open-iscsi@googlegroups.com, linux-media@vger.kernel.org,
intel-gfx@lists.freedesktop.org, sparmaintainer@unisys.com,
linux-raid@vger.kernel.org, dri-devel@lists.freedesktop.org,
megaraidlinux.pdl@broadcom.com, Jens Axboe, Martin K. Petersen,
Greg Kroah-Hartman, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, David Laight,
linux-crypto@vger.kernel.org, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <20170418155020.GF12001@char.us.oracle.com>
On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote:
> I am not sure if you know, but you can add on each patch the respective
> maintainer via 'CC'. That way you can have certain maintainers CCed only
> on the subsystems they cover. You put it after (or before) your SoB and
> git send-email happilly picks it up.
Yes, but I've seen some maintainers complain when they receive a patch
with no context (ie. cover letter and first patch). So I chose to do it
this way. I expect in this situation, no matter what you do, someone is
going to complain about the approach chosen.
Thanks anyway for the tip.
Logan
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
From: Konrad Rzeszutek Wilk @ 2017-04-18 15:50 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: linux-nvdimm@lists.01.org, Steve Wise,
linux-nvme@lists.infradead.org, target-devel@vger.kernel.org,
Sumit Semwal, devel@driverdev.osuosl.org,
rds-devel@oss.oracle.com, xen-devel, linux-scsi@vger.kernel.org,
Matthew Wilcox, linux-rdma@vger.kernel.org, Christoph Hellwig,
fcoe-devel@open-fcoe.org, open-iscsi@googlegroups.com,
linux-media@vger.kernel.org, Ming Lin,
intel-gfx@lists.freedesktop.org, sparmaintainer@unisys.com,
linux-raid@vger.kernel.org, dri-devel@lists.freedesktop.org,
megaraidlinux.pdl@broadcom.com, Jens Axboe,
linaro-mm-sig@lists.linaro.org, Martin K. Petersen,
Greg Kroah-Hartman, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, David Laight,
linux-crypto@vger.kernel.org, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <7930aa93-6106-e12f-ba76-e2771d4ec2dc@deltatee.com>
On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote:
>
>
> On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote:
> > Interesting that you didn't CC any of the maintainers. Could you
> > do that in the future please?
>
> Please read the cover letter. The distribution list for the patchset
> would have been way too large to cc every maintainer (even as limited as
> it was, I had mailing lists yelling at me). My plan was to get buy in
I am not sure if you know, but you can add on each patch the respective
maintainer via 'CC'. That way you can have certain maintainers CCed only
on the subsystems they cover. You put it after (or before) your SoB and
git send-email happilly picks it up.
It does mean that for every patch you have to run something like this:
$ more add_cc
#!/bin/bash
git diff HEAD^.. > /tmp/a
echo "---"
scripts/get_maintainer.pl --no-l /tmp/a | while read file
do
echo "Cc: $file"
done
Or such.
> for the first patch, get it merged and resend the rest independently to
> their respective maintainers. Of course, though, I'd be open to other
> suggestions.
>
> >>>
> >>> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
> >>> ---
> >>> drivers/block/xen-blkfront.c | 33 +++++++++++++++++++++++++++------
> >>> 1 file changed, 27 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >>> index 5067a0a..7dcf41d 100644
> >>> --- a/drivers/block/xen-blkfront.c
> >>> +++ b/drivers/block/xen-blkfront.c
> >>> @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req, struct blkfront_ring_info *ri
> >>> BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> >>>
> >>> if (setup.need_copy) {
> >>> - setup.bvec_off = sg->offset;
> >>> - setup.bvec_data = kmap_atomic(sg_page(sg));
> >>> + setup.bvec_off = 0;
> >>> + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> >>> + if (IS_ERR(setup.bvec_data)) {
> >>> + /*
> >>> + * This should really never happen unless
> >>> + * the code is changed to use memory that is
> >>> + * not mappable in the sg. Seeing there is a
> >>> + * questionable error path out of here,
> >>> + * we WARN.
> >>> + */
> >>> + WARN(1, "Non-mappable memory used in sg!");
> >>> + return 1;
> >>> + }
> >> ...
> >>
> >> Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
> >> inside sg_map().
>
> Thanks, that's a good suggestion. I'll make the change for v2.
>
> Logan
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function
From: Logan Gunthorpe @ 2017-04-18 15:44 UTC (permalink / raw)
To: Christoph Hellwig, Martin K. Petersen, Sagi Grimberg, Jens Axboe,
Tejun Heo, Greg Kroah-Hartman, Dan Williams, Ross Zwisler,
Matthew Wilcox, Sumit Semwal, Ming Lin, linux-kernel,
linux-crypto, linux-media, dri-devel, linaro-mm-sig, intel-gfx,
linux-raid, linux-mmc, linux-nvme, linux-nvdimm, linux-scsi,
fcoe-devel, open-iscsi, megaraidlinux.pdl, sparmaintainer, devel,
target-devel, netdev, linux-rdma, rds-devel, Steve Wise,
Stephen Bates
In-Reply-To: <20170418064427.r5ewu3p66p2zwdru@phenom.ffwll.local>
On 18/04/17 12:44 AM, Daniel Vetter wrote:
> On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote:
>> This is a single straightforward conversion from kmap to sg_map.
>>
>> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Probably makes sense to merge through some other tree, but please be aware
> of the considerable churn rate in i915 (i.e. make sure your tree is in
> linux-next before you send a pull request for this). Plane B would be to
> get the prep patch in first and then merge the i915 conversion one kernel
> release later.
Yes, as per what I said in my cover letter, I was leaning towards a
"Plan B" style approach.
Logan
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox