＜重要＞【My JCB】ご利用確認のお願い
by MyJCB
JCBのご利用ありがとうございます,
あなたのアカウントに不審な支払いが検出されましたしたので、
あなたの口座が資金の安全のために凍結されたのですが、
すぐにWEBサービスIDとパスワードを再登録して、
制限を解除しなければなりません
変更をご WEBサービスよりお申込みください。
■ 変更をご 方法
▼MyJCBログインはこちら
続けるにはこちらをクリック
お客様のセキュリティは弊社にとって非常に重要なものでございます。
ご理解の程、よろしくお願い申し上げます。
敬具,
■発行者■
JCBカード株式会社
※本メールは送信専用です。
※本メールは「MyJCB」にメールアドレスをご登録いただいた方にお送りしています。
2 months, 2 weeks
[PATCH 0/3] mm, pmem: Force unmap pmem on surprise remove
by Dan Williams
Summary:
A dax_dev can be unbound from its driver at any time. Unbind can not
fail. The driver-core will always trigger ->remove() and the result from
->remove() is ignored. After ->remove() the driver-core proceeds to tear
down context. The filesystem-dax implementation can leave pfns mapped
after ->remove() if it is triggered while the filesystem is mounted.
Security and data-integrity is forfeit if the dax_dev is repurposed for
another security domain (new filesystem or change device modes), or if
the dax_dev is physically replaced. CXL is a hotplug bus that makes
dax_dev physical replace a real world prospect.
All dax_dev pfns must be unmapped at remove. Detect the "remove while
mounted" case and trigger memory_failure() over the entire dax_dev
range.
Details:
The get_user_pages_fast() path expects all synchronization to be handled
by the pattern of checking for pte presence, taking a page reference,
and then validating that the pte was stable over that event. The
gup-fast path for devmap / DAX pages additionally attempts to take/hold
a live reference against the hosting pgmap over the page pin. The
rational for the pgmap reference is to synchronize against a dax-device
unbind / ->remove() event, but that is unnecessary if pte invalidation
is guaranteed in the ->remove() path.
Global dax-device pte invalidation *does* happen when the device is in
raw "device-dax" mode where there is a single shared inode to unmap at
remove, but the filesystem-dax path has a large number of actively
mapped inodes unknown to the driver at ->remove() time. So, that unmap
does not happen today for filesystem-dax. However, as Jason points out,
that unmap / invalidation *needs* to happen not only to cleanup
get_user_pages_fast() semantics, but in a future (see CXL) where dax_dev
->remove() is correlated with actual physical removal / replacement the
implications of allowing a physical pfn to be exchanged without tearing
down old mappings are severe (security and data-integrity).
What is not in this patch set is coordination with the dax_kmem driver
to trigger memory_failure() when the dax_dev is onlined as "System
RAM". The remove_memory() API was built with the assumption that
platform firmware negotiates all removal requests and the OS has a
chance to say "no". This is why dax_kmem today simply leaks
request_region() to burn that physical address space for any other
usage until the next reboot on a manual unbind event if the memory can't
be offlined. However a future to make sure that remove_memory() succeeds
after memory_failure() of the same range seems a better semantic than
permanently burning physical address space.
The topic of remove_memory() failures gets to the question of what
happens to active page references when the inopportune ->remove() event
happens. For transient pins the ->remove() event will wait for for all
pins to be dropped before allowing ->remove() to complete. Since
fileystem-dax forbids longterm pins all those pins are transient.
Device-dax, on the other hand, does allow longterm pins which means that
->remove() will hang unless / until the longterm pin is dropped.
Hopefully an unmap_mapping_range() event is sufficient to get the pin
dropped, but I suspect device-dax might need to trigger memory_failure()
as well to get the longterm pin holder to wake up and get out of the
way (TBD).
Lest we repeat the "longterm-pin-revoke" debate, which highlighted that
RDMA devices do not respond well to having context torn down, keep in
mind that this proposal is to do a best effort recovery of an event that
should not happen (surprise removal) under nominal operation.
---
Dan Williams (3):
mm/memory-failure: Prepare for mass memory_failure()
mm, dax, pmem: Introduce dev_pagemap_failure()
mm/devmap: Remove pgmap accounting in the get_user_pages_fast() path
drivers/dax/super.c | 15 +++++++++++++++
drivers/nvdimm/pmem.c | 10 +++++++++-
drivers/nvdimm/pmem.h | 1 +
include/linux/dax.h | 5 +++++
include/linux/memremap.h | 5 +++++
include/linux/mm.h | 3 +++
mm/gup.c | 38 ++++++++++++++++----------------------
mm/memory-failure.c | 36 +++++++++++++++++++++++-------------
mm/memremap.c | 11 +++++++++++
9 files changed, 88 insertions(+), 36 deletions(-)
2 months, 2 weeks
Do You Need A Loan? We Offer 3.5% Interest Rate.
by Global Financial Services SA.
Greetings,
To Whom It May Concern,
We, the Global Financial Services are offering loans at a very low interest rate of 3.5% per year. We offer Personal loans, Debt Consolidation Loan, Venture Capital, Business Loan, Education Loan, Home Loan or "Loan for any reason and for all citizens and non-citizens with either a good or bad credit history.
Have you been turned down by your bank? Do you have bad credit? Do you have unpaid bills? Are you in debt? Blacklisted? Are you under Debt review? Do you need to set up a business? Worry no more as we are here to offer you a low interest loan.
Our loan ranges from US$2, 000.00 to US$25,000,000.00
Locally our loan ranges from R15, 000.00 to the sum of R25, 000,000.00
If you are interested kindly contact us with your:
1. Full Names
2. Contact Address
3. Occupation
4. Contact Telephone Numbers
5. Type of loan
6. Loan Amount
7. Duration of repayment
Do not hesitate to contact us on the telephone and email address below for further clarification(s) email us at: global.fs.za(a)consultant.com<mailto:global.fs.za@consultant.com>
Contact Michelle Alinda: Via Tel/WhatsApp: +27 71 817 8194.
Warm Regards,
Customer Service
Global Financial Services Pty South Africa.
[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-ani...]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_camp...> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_camp...>
2 months, 2 weeks
