linux-toradex.git/drivers/base/core.c, branch v4.0-rc1

device: Change dev_ logging functions to return void

2015-01-26T23:57:59+00:00

No caller or macro uses the return value so make all
the functions return void.

Compiled x86 allyesconfig and defconfig w/o CONFIG_PRINTK

Signed-off-by: Joe Perches 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2014-12-15T00:10:09+00:00

Pull driver core update from Greg KH:
 "Here's the set of driver core patches for 3.19-rc1.

  They are dominated by the removal of the .owner field in platform
  drivers.  They touch a lot of files, but they are "simple" changes,
  just removing a line in a structure.

  Other than that, a few minor driver core and debugfs changes.  There
  are some ath9k patches coming in through this tree that have been
  acked by the wireless maintainers as they relied on the debugfs
  changes.

  Everything has been in linux-next for a while"

* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
  Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
  fs: debugfs: add forward declaration for struct device type
  firmware class: Deletion of an unnecessary check before the function call "vunmap"
  firmware loader: fix hung task warning dump
  devcoredump: provide a one-way disable function
  device: Add dev__once variants
  ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
  ath: use seq_file api for ath9k debugfs files
  debugfs: add helper function to create device related seq_file
  drivers/base: cacheinfo: remove noisy error boot message
  Revert "core: platform: add warning if driver has no owner"
  drivers: base: support cpu cache information interface to userspace via sysfs
  drivers: base: add cpu_device_create to support per-cpu devices
  topology: replace custom attribute macros with standard DEVICE_ATTR*
  cpumask: factor out show_cpumap into separate helper function
  driver core: Fix unbalanced device reference in drivers_probe
  driver core: fix race with userland in device_add()
  sysfs/kernfs: make read requests on pre-alloc files use the buffer.
  sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
  fs: sysfs: return EGBIG on write if offset is larger than file size
  ...

driver core: fix race with userland in device_add()

2014-11-07T19:14:57+00:00

bus_add_device() should be called before devtmpfs_create_node(), so when
userland application opens device from devtmpfs, it wouldn't get ENODEV
from kernel, because device_add() wasn't completed.

Signed-off-by: Sergey Klyaus 
Signed-off-by: Greg Kroah-Hartman

sysfs: driver core: Fix glue dir race condition by gdp_mutex

2014-11-07T16:17:43+00:00

There is a race condition when removing glue directory.
It can be reproduced in following test:

path 1: Add first child device
device_add()
    get_device_parent()
            /*find parent from glue_dirs.list*/
            list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
                    if (k->parent == parent_kobj) {
                            kobj = kobject_get(k);
                            break;
                    }
            ....
            class_dir_create_and_add()

path2: Remove last child device under glue dir
device_del()
    cleanup_device_parent()
            cleanup_glue_dir()
                    kobject_put(glue_dir);

If path2 has been called cleanup_glue_dir(), but not
call kobject_put(glue_dir), the glue dir is still
in parent's kset list. Meanwhile, path1 find the glue
dir from the glue_dirs.list. Path2 may release glue dir
before path1 call kobject_get(). So kernel will report
the warning and bug_on.

This is a "classic" problem we have of a kref in a list
that can be found while the last instance could be removed
at the same time.

This patch reuse gdp_mutex to fix this race condition.

The following calltrace is captured in kernel 3.4, but
the latest kernel still has this bug.

-----------------------------------------------------
<4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
<4>[ 3965.441474] Hardware name: Romley
<4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
...
<4>[ 3965.441605] Call Trace:
<4>[ 3965.441611]  [] warn_slowpath_common+0x7a/0xb0
<4>[ 3965.441615]  [] warn_slowpath_null+0x15/0x20
<4>[ 3965.441618]  [] kobject_get+0x33/0x40
<4>[ 3965.441624]  [] get_device_parent.isra.11+0x135/0x1f0
<4>[ 3965.441627]  [] device_add+0xd4/0x6d0
<4>[ 3965.441631]  [] ? dev_set_name+0x3c/0x40
....
<2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
<4>[ 3965.441915] invalid opcode: 0000 [#1] SMP
...
<4>[ 3965.686743]  [] sysfs_create_group+0xe/0x10
<4>[ 3965.686748]  [] blk_trace_init_sysfs+0x14/0x20
<4>[ 3965.686753]  [] blk_register_queue+0x3b/0x120
<4>[ 3965.686756]  [] add_disk+0x1cc/0x490
....
-------------------------------------------------------

Signed-off-by: Yijing Wang 
Signed-off-by: Weng Meiling 
Cc:  #3.4+
Signed-off-by: Greg Kroah-Hartman

Merge tag 'iommu-updates-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2014-10-15T05:23:49+00:00

Pull IOMMU updates from Joerg Roedel:
 "This pull-request includes:

   - change in the IOMMU-API to convert the former iommu_domain_capable
     function to just iommu_capable

   - various fixes in handling RMRR ranges for the VT-d driver (one fix
     requires a device driver core change which was acked by Greg KH)

   - the AMD IOMMU driver now assigns and deassigns complete alias
     groups to fix issues with devices using the wrong PCI request-id

   - MMU-401 support for the ARM SMMU driver

   - multi-master IOMMU group support for the ARM SMMU driver

   - various other small fixes all over the place"

* tag 'iommu-updates-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (41 commits)
  iommu/vt-d: Work around broken RMRR firmware entries
  iommu/vt-d: Store bus information in RMRR PCI device path
  iommu/vt-d: Only remove domain when device is removed
  driver core: Add BUS_NOTIFY_REMOVED_DEVICE event
  iommu/amd: Fix devid mapping for ivrs_ioapic override
  iommu/irq_remapping: Fix the regression of hpet irq remapping
  iommu: Fix bus notifier breakage
  iommu/amd: Split init_iommu_group() from iommu_init_device()
  iommu: Rework iommu_group_get_for_pci_dev()
  iommu: Make of_device_id array const
  amd_iommu: do not dereference a NULL pointer address.
  iommu/omap: Remove omap_iommu unused owner field
  iommu: Remove iommu_domain_has_cap() API function
  IB/usnic: Convert to use new iommu_capable() API function
  vfio: Convert to use new iommu_capable() API function
  kvm: iommu: Convert to use new iommu_capable() API function
  iommu/tegra: Convert to iommu_capable() API function
  iommu/msm: Convert to iommu_capable() API function
  iommu/vt-d: Convert to iommu_capable() API function
  iommu/fsl: Convert to iommu_capable() API function
  ...

driver core: Add BUS_NOTIFY_REMOVED_DEVICE event

2014-10-02T09:14:34+00:00

This event closes an important gap in the bus notifiers.
There is already the BUS_NOTIFY_DEL_DEVICE event, but that
is sent when the device is still bound to its device driver.

This is too early for the IOMMU code to destroy any mappings
for the device, as they might still be in use by the driver.

The new BUS_NOTIFY_REMOVED_DEVICE event introduced with this
patch closes this gap as it is sent when the device is
already unbound from its device driver and almost completly
removed from the driver core.

With this event the IOMMU code can safely destroy any
mappings and other data structures when a device is removed.

Signed-off-by: Joerg Roedel 
Acked-by: Greg Kroah-Hartman 
Tested-by: Jerry Hoemann

drivers/base: Fix length checks in create_syslog_header()/dev_vprintk_emit()

2014-09-24T05:55:15+00:00

snprintf() returns the number of bytes that could have been written
(excluding the null), not the actual number of bytes written.  Given a
long enough subsystem or device name, these functions will advance
beyond the end of the on-stack buffer in dev_vprintk_exit(), resulting
in an information leak or stack corruption.  I don't know whether such
a long name is currently possible.

In case snprintf() returns a value >= the buffer size, do not add
structured logging information.  Also WARN if this happens, so we can
fix the driver or increase the buffer size.

Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()

2014-04-16T18:56:33+00:00

All device_schedule_callback_owner() users are converted to use
device_remove_file_self().  Remove now unused
{sysfs|device}_schedule_callback_owner().

Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

Revert "sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()"

2014-03-26T03:54:57+00:00

This reverts commit d1ba277e79889085a2faec3b68b91ce89c63f888.

As reported by Stephen, this patch breaks linux-next as a ppc patch
suddenly (after 2 years) started using this old api call.  So revert it
for now, it will go away in 3.15-rc2 when we can change the PPC call to
the new api.

Reported-by: Stephen Rothwell 
Cc: Tejun Heo 
Cc: Stewart Smith 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

Revert "driver core: synchronize device shutdown"

2014-03-09T06:08:29+00:00

This reverts commit 401097ea4b89846d66ac78f7f108d49c2e922d9c.  The
original changelog said:

    A patch series to make .shutdown execute asynchronously.  Some drivers's
    shutdown can take a lot of time.  The patches can help save some shutdown
    time.  The patches use Arjan's async API.

    This patch:

    synchronize all tasks submitted by .shutdown

However, I'm not able to find any evidence that any other patches from
this series were applied, nor am I able to find any async tasks that are
scheduled in a .shutdown context.

On the other hand, we see occasional hangs on shutdown that appear to be
caused by the async_synchronize_full() in device_shutdown() waiting
forever for the async probing in sd if a SCSI disk shows up at just the
wrong time — the system starts the probe, but begins shutting down and
tears down too much of the SCSI driver to finish the probe.

If we had any async shutdown tasks, I guess the right fix would be to
create a "shutdown" async domain and have device_shutdown() only wait
for that domain.  But since there apparently are no async shutdown
tasks, we can just revert the waiting.

Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman