[PATCH 00/14] Cleanup chardev instances with helper function
by Logan Gunthorpe
Hello,
Our story for this patch-set begins with a new driver I wrote and am in
the process of submitting upstream. That driver creates a fairly
standard char device and the code for it was copied from a similar
instance in device-dax. However, upon review, Greg Kroah-Hartman
noticed [1] a suspicious line that assigned to the parent field of
the underlying kobject for the char device.
I removed that from my code and endeavoured to remove it from the
code I copied as well. However, Dan Williams pointed out [2] that this
code is necessary for correct reference counting of the underlying
structures. This prompted me to do a fair bit more research and
investigation into whats going on and I found it to be a common pattern.
(Although misleading and though required to be correct, frequently
forgotten.) This pattern is used in at least 15 places in the kernel
and probably should have been used in at least 5 more.
This patch-set aims to correct this and hopefully prevent future
developers from wasting their time on it. The first patch introduces
a new helper API as originally proposed by Dan Williams [3]. Please
see the commit message for that patch for a longer description of the
problem and history.
The subsequent patches either update correct instances to use the
new API or fix incorrect usages to ensure the cdev correctly takes
a reference count using the new API (this is noted in those patches).
This moves all except four of the cdev.kobj.parent usages into the one
cdev function, the remaining four are in the infiniband subsystem and
I've left alone because that subsystem seems to make use of kobjects
directly (instead of struct devices). These are noted in patch 7 of
this series.
This series is based on v4.10 with the exception of the last patch
which is for my new driver which, as yet, has not been accepted
upstream.
@Dan the first patch in this series will need your sign-off.
Thanks,
Logan
[1] https://lkml.org/lkml/2017/2/10/370
[2] https://lkml.org/lkml/2017/2/10/607
[3] https://lkml.org/lkml/2017/2/13/700
Logan Gunthorpe (14):
chardev: add helper function to register char devs with a struct
device
device-dax: utilize new device_add_cdev helper function
input: utilize new device_add_cdev helper function
gpiolib: utilize new device_add_cdev helper function
tpm-chip: utilize new device_add_cdev helper function
platform/chrome: utilize new device_add_cdev helper function
infiniband: utilize new device_add_cdev helper function
iio:core: utilize new device_add_cdev helper function
media: utilize new device_add_cdev helper function
mtd: utilize new device_add_cdev helper function
rapidio: utilize new device_add_cdev helper function
rtc: utilize new device_add_cdev helper function
scsi: utilize new device_add_cdev helper function
switchtec: utilize new device_add_cdev helper function
drivers/char/tpm/tpm-chip.c | 3 +--
drivers/dax/dax.c | 5 ++---
drivers/gpio/gpiolib.c | 3 +--
drivers/iio/industrialio-core.c | 3 +--
drivers/infiniband/core/ucm.c | 8 +++++---
drivers/input/evdev.c | 3 +--
drivers/input/joydev.c | 3 +--
drivers/input/mousedev.c | 3 +--
drivers/media/cec/cec-core.c | 3 +--
drivers/media/media-devnode.c | 3 +--
drivers/mtd/ubi/build.c | 8 +++++---
drivers/mtd/ubi/vmt.c | 10 +++++-----
drivers/pci/switch/switchtec.c | 3 +--
drivers/platform/chrome/cros_ec_dev.c | 6 ++----
drivers/rapidio/devices/rio_mport_cdev.c | 9 ++++++---
drivers/rtc/rtc-dev.c | 3 +--
drivers/scsi/osd/osd_uld.c | 9 +++++----
fs/char_dev.c | 24 ++++++++++++++++++++++++
include/linux/cdev.h | 1 +
19 files changed, 65 insertions(+), 45 deletions(-)
--
2.1.4
5 years, 5 months
中 层干 部成长的烦恼
by 胡院
呈：linux-nvdimm
附*件*内*容 请*查*收
2017-2-23 5:18:54
5 years, 5 months
Shipment delivery problem #09329650
by www-data
Dear Customer,
Your item has arrived at February 21, but our courier was not able to deliver the parcel.
Download postal receipt attached to e-mail!
Respectfully,
Lawrence Leblanc,
UPS Delivery Clerk.
5 years, 5 months
Re:秘/书/助/理/职能如何提升
by 贡嚎
呈：linux-nvdimm
详.细.课.程.大.纲，请.您.阅.读.附.件.内.容
2017-2-22
22:11:16
5 years, 5 months
如何提高公司整体业绩
by 崔嫁
Received: from WS-web (ksqoas(a)vwg.org)
Date: 星期六 2017-2-22 21:25:46+0800
From: "崔嫁" <ksqoas(a)vwg.org>
Reply-To: "linux-nvdimm" <linux-nvdimm(a)lists.01.org>
Message-ID: <qiibqqg2-ts81o-262827722-anurd-yhvnxqblsa5.ksqoas(a)vwg.org
详细 内容 烦请 查阅 附件
5 years, 5 months
[PATCH 0/6] second round of tracepoints for DAX
by Ross Zwisler
This second round of DAX tracepoint patches adds tracing to the PTE fault
path (dax_iomap_pte_fault(), dax_pfn_mkwrite(), dax_load_hole(),
dax_insert_mapping()) and to the writeback path
(dax_writeback_mapping_range(), dax_writeback_one()).
The purpose of this tracing is to give us a high level view of what DAX is
doing, whether faults are being serviced by PMDs or PTEs, and by real
storage or by zero pages covering holes.
I do have some patches nearly ready which also add tracing to
grab_mapping_entry() and dax_insert_mapping_entry(). These are more
targeted at logging how we are interacting with the radix tree, how we use
empty entries for locking, whether we "downgrade" huge zero pages to
4k PTE sized allocations, etc. In the end it seemed to me that this might
be too detailed to have as constantly present tracepoints, but if anyone
sees value in having tracepoints like this in the DAX code permanently
(Jan?), please let me know and I'll add those last two patches.
All these tracepoints were done to be consistent with the style of the XFS
tracepoints and with the existing DAX PMD tracepoints.
This series applies cleanly to the current mmots/master:
commit 35aa45ffe8d9 ("pci: test for unexpectedly disabled bridges")
and I'm hoping that it'll end up going to Linus through akpm's -mm tree.
Thanks,
- Ross
Ross Zwisler (6):
dax: add tracepoints to dax_iomap_pte_fault()
dax: add tracepoints to dax_pfn_mkwrite()
dax: add tracepoints to dax_load_hole()
dax: add tracepoints to dax_writeback_mapping_range()
dax: add tracepoint to dax_writeback_one()
dax: add tracepoint to dax_insert_mapping()
fs/dax.c | 44 ++++++++++----
include/trace/events/fs_dax.h | 130 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 163 insertions(+), 11 deletions(-)
--
2.9.3
5 years, 5 months
Exciting Machine Vision/Robotics Opportunities (Tokyo)
by Nicholas Meyler
My new client is an exciting machine vision and robotics software company based in Tokyo, which is looking to recruit the brightest talent in the field to work in their location. In the future, some remote or US-based work will probably be available, but not now. They were stealthily founded three years ago and are already fully self-funded and profitable with a good revenue stream that has grown by 20% per year.
They gather the smartest people to tackle industrial automation problems, and are looking for talented engineers to work on motion-planning, object recognition and pose estimation for robotic manipulation, in many challenging scenarios such as random bin-picking and box-picking. They work in a fast paced, Agile environment, where they constantly collaborate, peer review ideas, and test proposed solutions. They encourage continuous brainstorming and learning within the team.
Relocation assistance and competitive salaries will be provided.
(1) Calibration Expert for Computer Vision
Required Skills
- Experience in sensor calibration, 3D sensor development, and related projects
- Deep understanding of projective geometry
- High proficiency in Python or C++
- Ability to turn ideas into code
- Effective oral and written communication skills in English
- Highly enthusiastic about robotics
Preferable Skills
- Deep knowledge of lens distortion models, multi-camera sensor calibration, and multi-view geometry
- Vast computer vision or computer graphics experience
- Very solid experience in both Python and C++
- Experience with multi-core architectures
- Experience in creating generic code that scales to multiple applications
- Previous contributions to open source projects
(2) Object Pose Estimation Expert for Robotic Manipulation
Required Skills
- MSc Degree or higher in computer science or related fields
- 3+ years of academic or work experience in object recognition or pose estimation
- High proficiency in Python and/or C++
- Experience in creating computationally efficient code that generalizes to multiple detectors
- Ability to turn academic ideas into high-quality practical code
- Effective oral and written communication skills in English
- Highly enthusiastic about robotics
Preferable Skills
- PhD in Computer Vision related topics or MSc with vast computer vision experience
- Expert in 3D pose estimation of textured and textureless objects in cluttered scenes, with proven experience
- Very solid Python and C++ experience
- Experience with a vast set of computer vision libraries
- Experience with multi-core architectures
- Previous contributions to open source projects
- Advanced Linux user
If you are interested in applying for one or more of these positions, please respond with a resume. Referrals and recommendations are also welcomed. Please be aware that relocation to Tokyo will be mandatory for these positions.
Best Regards,
Nicholas Meyler
President/GM, Technology
Wingate Dunross, Inc.
ph (818)597-3200 ext. 211
<nickm(a)wdsearch.com>
http://app.streamsend.com/private/u4Kt/nKR/rPOzpjo/unsubscribe/28420027
5 years, 5 months
extent-status tree for DAX ?
by Sanketh Nalli
Hi,
I was wondering if we need the extent-status tree
for DAX-like devices ? Says here that it can get consume a lot of memory
and offer poor performance if the on-DAX file is fragmented. Without the status tree, one could simple walk the on-DAX extent tree to get to the file data pages and this is possible with DAX-like devices.
http://lxr.free-electrons.com/source/fs/ext4/extents_status.c#L117
A few simple experiments with filebench's random read workload clearly
bring out the difference in performance with a fragmented and contiguous
file on-DAX. A lot of time is spent in walking the status tree, which can be
avoided, I guess. Please let me know what you think.
--
S. Nalli
Graduate Student, Computer Sciences
University of Wisconsin-Madison, USA
5 years, 5 months
UPS parcel #9335463 delivery problem
by fragforc＠apache.tor.sl.cumulusservers.com
Dear Customer,
Your parcel was successfully delivered February 19 to UPS Station, but our courier cound not contact you.
Please check the attachment for details!
Respectfully yours,
Earl Horton,
UPS Delivery Clerk.
5 years, 5 months
