Abi dev #1
Open
Abi dev #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This patch provides one common file (rdma_user_ioctl.h) for all RDMA UAPI IOCTLs. issue: 776663 Change-Id: I4334851ed65b9b0a07a6120c267f2040c4d8d0d2 Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Move legacy MAD IOCTL declarations to rdma_user_ioctl.h file. issue: 776663 Change-Id: Ib3462a406225c0f24f35f4e56ad46b907bce91a4 Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Move hfi1 ioctl definitions to a new header which can be included by both the hfi1 and qib drivers to avoid a duplicate enum definition as shown in this build error for qib: CC [M] drivers/infiniband/hw/qib/qib_sysfs.o In file included from ./include/uapi/rdma/rdma_user_ioctl.h:39:0, from include/uapi/rdma/ib_user_mad.h:38, from include/rdma/ib_mad.h:43, from include/rdma/ib_pma.h:38, from drivers/infiniband/hw/qib/qib_mad.h:37, from drivers/infiniband/hw/qib/qib_init.c:49: ./include/uapi/rdma/hfi/hfi1_user.h:370:2: error: redeclaration of enumerator ‘ur_rcvhdrtail’ ur_rcvhdrtail = 0, Move hfi1 structures to separate file to avoid this failure. The actual move of the ioctl definitions comes in a follow on patch. issue: 776663 Change-Id: I3f8fa164dd6c8abf9687b402368e93bc35d1d1c8 Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Move HFI1 IOCTL declarations to rdma_user_ioctl.h file. issue: 776663 Change-Id: I843e12a21638e5b7c7e54a5ecb29a4542dc9b5c4 Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Rename RDMA magic number to better describe IOCTLs. issue: 776663 Change-Id: I8e1650fd239a886fe7af25177588d7c881e75826 Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
MAD and HFI1 have different naming convention, this patch simplifies and unifies their defines and names. As part of cleanup, the HFI1 _NUM() macro and command indexes were removed. It has a potential to break applications which use these defines directly, while shouldn't. issue: 776663 Change-Id: Ic630a68af25f7b676f02ad0651e079ee9fbf2e1b Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
The current code creates an IDR per type. Since types are currently common for all vendors and known in advance, this was good enough. However, the proposed ioctl based infrastructure allows each vendor to declare only some of the common types and declare its own specific types. Thus, we decided to implement IDR to be per device and refactor it to use a new file. issue: 776663 Change-Id: I5c267a875b52af5fb1a8a95ac2b7f829cd26f6dd Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com>
The new ioctl infrastructure supports driver specific objects. Each such object type has a free function, allocation size and an order of destruction. This information is embedded in the same table describing the various action allowed on the object, similarly to object oriented programming. When a ucontext is created, a new list is created in this ib_ucontext. This list contains all objects created under this ib_ucontext. When a ib_ucontext is destroyed, we traverse this list several time destroying the various objects by the order mentioned in the object type description. If few object types have the same destruction order, they are destroyed in an order opposite to their creation order. Adding an object is done in two parts. First, an object is allocated and added to IDR/fd table. Then, the command's handlers (in downstream patches) could work on this object and fill in its required details. After a successful command, ib_uverbs_uobject_enable is called and this user objects becomes ucontext visible. Removing an uboject is done by calling ib_uverbs_uobject_remove. We should make sure IDR (per-device) and list (per-ucontext) could be accessed concurrently without corrupting them. issue: 776663 Change-Id: I264f705951d646a47629ff22f7ec58e60e59e2c4 Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
The completion channel we use in verbs infrastructure is FD based. Previously, we had a separate way to manage this object. Since we strive for a single way to manage any kind of object in this infrastructure, we conceptually treat all objects as subclasses of ib_uobject. This commit adds the necessary mechanism to support FD based objects like their IDR counterparts. issue: 776663 Change-Id: I15754b3906e0028953ff900e4699a3e2f670c081 Signed-off-by: Matan Barak <matanb@mellanox.com>
When a ucontext is created, we need to initialize the list of objects. This list consists of every user object that is associated with this ucontext. The possible elements in this list are either a file descriptor or an object which is represented by an IDR. Every such an object, has a release function (which is called upon object destruction) and a number associated to its release order. When a ucontext is destroyed, the list is traversed while holding a lock. This lock is necessary since a user might try to close a FD file [s]he created and exists in this list. issue: 776663 Change-Id: I1908eea0be4dceeeb416e907ea84f42afe925ed5 Signed-off-by: Matan Barak <matanb@mellanox.com>
In order to initialize and destroy types in a generic way, we need to provide information about the allocation size, release function and order. This is done through a macro based DSL (domain specific language). This patch adds macros to initialize a type and a type group. When we transform the write based commands to use this new locking and allocation schema, we use these types declarations. issue: 776663 Change-Id: Ib697d47f9a092a14a2fbd8e11b687373c1dbf794 Signed-off-by: Matan Barak <matanb@mellanox.com>
This patch declares all the required information for creating and destroying all common IB types. The refactored infrastructure treats types in a more object oriented way. Each type encapsulates all the required information for its creation and destruction. This patch is required in order to transform all currently uverbs_cmd verbs to initialize and destroy objects using the refactored infrastructure. These types are used in downstream patches. issue: 776663 Change-Id: I14549676492e311a72f584b288458d48057b56a1 Signed-off-by: Matan Barak <matanb@mellanox.com>
The new infrastructure introduced a new locking and objects scheme.
We rewrite the current uverbs_cmd handlers to use them. The new
infrastructure needs a types definition in order to figure out how
to allocate/free resources, which is defined in upstream patches.
This patch refactores the following things:
(*) Instead of having a list per type, we use the ucontext's list
(*) The locking semantics are changed:
Two commands might try to lock the same object. If this object
is locked for exclusive object, any concurrent access will get
-EBUSY. This makes the user serialize access.
(*) The completion channel FD is created by using the infrastructure.
It's release function and release context are serialized by the
infrastructure.
(*) The live flag is no longer required.
(*) User may need to assign the user_handle explicitly.
issue: 776663
Change-Id: Ia23b60d018766b248823ef1445fefd56132ad471
Signed-off-by: Matan Barak <matanb@mellanox.com>
The new IOCTL based infrastructure either commits or rollbacks all objects of the command as one transaction. In order to do that, we introduce a notion of dealing with a collection of objects that are related to a specific action. issue: 776663 Change-Id: I25a534718663f2e7056fcd5ddfbdc68524f39d61 Signed-off-by: Matan Barak <matanb@mellanox.com>
In downstream patches, We use a parsing tree to parse and validate commands. In order to create such a parsing tree, we add the necessary types to store the parsed data in a more accessible way and to describe the actions and attributes themselves. issue: 776663 Change-Id: I2db6685ec327b18a6a9d34dc460c34c04c1cfbb1 Signed-off-by: Matan Barak <matanb@mellanox.com>
In this proposed ioctl interface, processing the command starts from
properties of the command and fetching the appropriate user objects
before calling the handler.
Parsing and validation is done according to a specifier declared by
the driver's code. In the driver, all supported types are declared.
These types are separated to different type groups, each could be
declared in a different place (for example, common types and driver
specific types).
For each type we list all supported actions. Similarly to types,
actions are separated to actions groups too. Each group is declared
separately. This could be used in order to add actions to an existing
type.
Each action has a specifies a handler, which could be either a
standard command or a driver specific command.
Along with the handler, a group of attributes is specified as well.
This group lists all supported attributes and is used for automatic
fetching and validation of the command, response and its related
objects.
When a group of elements is used, the high bits of the elements ids
are used in order to calculate the group index. Then, these high bits
are masked out in order to have a zero based namespace for every
group. This is mandatory for compact representation and O(1) array
access.
A group of attributes is actually an array of attributes. Each
attribute has a type (PTR_IN, PTR_OUT, IDR, FD and FLAG) and a length.
Attributes could be validated through some attributes, like:
(*) Minimum size / Exact size
(*) Fops for FD
(*) Object type for IDR
(*) Mask for FLAG
If an IDR/fd attribute is specified, the kernel also states the object
type and the required access (NEW, WRITE, READ or DESTROY).
All uobject/fd management is done automatically by the infrastructure,
meaning - the infrastructure will fail concurrent commands that at
least one of them requires concurrent access (WRITE/DESTROY),
synchronize actions with device removals (dissociate context events)
and take care of reference counting (increase/decrease) for concurrent
actions invocation. The reference counts on the actual kernel objects
shall be handled by the handlers.
types
+--------+
| |
| | actions +--------+
| | group action action_spec +-----+ |len |
+--------+ +------+[d]+-------+ +----------------+[d]+------------+ |attr1+-> |type |
| type +> |action+-> | spec +-> + attr_groups +-> |common_chain+--> +-----+ |idr_type|
+--------+ +------+ |handler| | | +------------+ |attr2| |access |
| | | | +-------+ +----------------+ |vendor chain| +-----+ +--------+
| | | | +------------+
| | +------+
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+--------+
[d] = distribute ids to groups using the high order bits
The right types table is also chosen by using the high bits from
uverbs_types_groups.
Once validation and object fetching (or creation) completed, we call
the handler:
int (*handler)(struct ib_device *ib_dev, struct ib_ucontext *ucontext,
struct uverbs_attr_array *ctx, size_t num);
Where ctx is an array of uverbs_attr_array. Each element in this array
is an array of attributes which corresponds to one group of attributes.
For example, in the usually used case:
ctx core
+----------------------------+ +------------+
| core: uverbs_attr_array +---> | valid |
+----------------------------+ | cmd_attr |
| driver: uverbs_attr_array | +------------+
|----------------------------+--+ | valid |
| | cmd_attr |
| +------------+
| | valid |
| | obj_attr |
| +------------+
|
| vendor
| +------------+
+> | valid |
| cmd_attr |
+------------+
| valid |
| cmd_attr |
+------------+
| valid |
| obj_attr |
+------------+
Ctx array's indices corresponds to the attributes groups order. The indices
of core and driver corresponds to the attributes name spaces of each
group. Thus, we could think of the following as one object:
1. Set of attribute specification (with their attribute IDs)
2. Attribute group which owns (1) specifications
3. A function which could handle this attributes which the handler
could call
4. The allocation descriptor of this type uverbs_type_alloc_action.
Upon success of a handler invocation, reference count of uobjects and
use count will be a updated automatically according to the
specification.
issue: 776663
Change-Id: I5ccefa8bb88a6ccdd05086958d2d15ff788af95a
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
This patch adds macros for declaring action groups, actions,
attribute groups and attributes. These definitions are later
used by downstream patches to declare some of the common types.
In addition, we add some helper inline functions to copy_{from,to}
user-space buffers and check if an attribute is valid.
issue: 776663
Change-Id: Ie16969d617f5907bd82237755e2ace1492bead21
Signed-off-by: Matan Barak <matanb@mellanox.com>
This adds the DEVICE type. This type support creating the context all objects are created from. Moreover, it supports executing actions which are related to the device itself, such as QUERY_DEVICE. The only related object to this type is a singleton (per file instance) context. issue: 776663 Change-Id: I8e41f635883e48e58e11cd78ac28800857fccf16 Signed-off-by: Matan Barak <matanb@mellanox.com>
We add the common (core) code for init context, query device,
reg_mr, create_cq, create_qp, modify_qp create_comp_channel and
init_pd.
This includes the following parts:
* Macros for defining commands and validators
* For each command
* type declarations
- destruction order
- free function
- uverbs action group
* actions
* handlers
* attributes
Drivers could use the these attributes, actions or types when they
want to alter or add a new type. They could use the uverbs handler
directly in the action (or just wrap it in the driver's custom code).
Currently we use ib_udata to pass vendor specific information to the
driver. This should probably be refactored in the future.
issue: 776663
Change-Id: I7dcac3c920e1f15379b84caa6cefbef99f57dc44
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
In order to have a more robust query system, we propose having a parse tree that is unique for a device and represents only the features this particular device support. This is done by having a root specification tree per feature. Before a device registers itself as an IB device, it merges all these trees into one parsing tree. This parsing tree is used to parse all user-space commands. A user-space application could read this parse tree. This tree represents which types, actions and attributes are supported for this device. This is based on the idea of Jason Gunthorpe <jgunthorpe@obsidianresearch.com> issue: 776663 Change-Id: I2c80cbe59c69d4be39b4ad65eb7d5132ad6c0fea Signed-off-by: Matan Barak <matanb@mellanox.com>
This patch simply tells all drivers to use the uverb objects declared by the common layer. issue: 776663 Change-Id: I2972e1184af5ef33fe4ffd7db8b79f6d088b71d3 Signed-off-by: Matan Barak <matanb@mellanox.com>
Instead of supporting a generic unknown size of the uhw (driver specific uhw_in and uhw_out) parameters via the common attributes, declare the sizes specific to each driver in a driver specific tree. When we initialize the parsing tree, this tree is merged with the common parsing tree, creating this driver specific tree. This tree could add driver specific types, actions and other attributes as well. We propose creating way of passing the merged parsing tree to the user-space. By that, a user-space could query which features are supported by the driver. issue: 776663 Change-Id: I36125b694c1f51d23616f3080aeddfd70ca70998 Signed-off-by: Matan Barak <matanb@mellanox.com>
In order to allow compatibility header, allow passing ib_uverbs_ioctl_hdr and ib_uverbs_attr from kernel space. issue: 776663 Change-Id: Id3192c42880334979b40bc9269966776a810f047 Signed-off-by: Matan Barak <matanb@mellanox.com>
Implement write->ioctl compatibility layer for ib_uverbs_get_context by translating the headers to ioctl headers and invoke the ioctl parser. issue: 776663 Change-Id: Ic8533dd80d30681b7faeaa1cb91da385d8ad6560 Signed-off-by: Matan Barak <matanb@mellanox.com>
matanb10
pushed a commit
that referenced
this pull request
Mar 15, 2017
When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same time another core try to attach new UDC, which will cause deadlock as below scenario. Thus we should release ffs lock before issuing unregister_gadget_item(). [ 52.642225] c1 ====================================================== [ 52.642228] c1 [ INFO: possible circular locking dependency detected ] [ 52.642236] c1 4.4.6+ #1 Tainted: G W O [ 52.642241] c1 ------------------------------------------------------- [ 52.642245] c1 usb ffs open/2808 is trying to acquire lock: [ 52.642270] c0 (udc_lock){+.+.+.}, at: [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8 [ 52.642272] c1 but task is already holding lock: [ 52.642283] c0 (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>] ffs_data_clear+0x30/0x140 [ 52.642285] c1 which lock already depends on the new lock. [ 52.642287] c1 the existing dependency chain (in reverse order) is: [ 52.642295] c0 -> #1 (ffs_lock){+.+.+.}: [ 52.642307] c0 [<ffffffc00012340c>] __lock_acquire+0x20f0/0x2238 [ 52.642314] c0 [<ffffffc000123b54>] lock_acquire+0xe4/0x298 [ 52.642322] c0 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc [ 52.642328] c0 [<ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8 [ 52.642334] c0 [<ffffffc000654004>] usb_add_function+0x84/0x184 [ 52.642340] c0 [<ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c [ 52.642346] c0 [<ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c [ 52.642352] c0 [<ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8 [ 52.642358] c0 [<ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128 [ 52.642369] c0 [<ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c [ 52.642376] c0 [<ffffffc00023c054>] vfs_write+0xb8/0x214 [ 52.642381] c0 [<ffffffc00023cad4>] SyS_write+0x54/0xb0 [ 52.642388] c0 [<ffffffc000085ff0>] el0_svc_naked+0x24/0x28 [ 52.642395] c0 -> #0 (udc_lock){+.+.+.}: [ 52.642401] c0 [<ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4 [ 52.642407] c0 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238 [ 52.642412] c0 [<ffffffc000123b54>] lock_acquire+0xe4/0x298 [ 52.642420] c0 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc [ 52.642427] c0 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8 [ 52.642432] c0 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44 [ 52.642439] c0 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140 [ 52.642444] c0 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c [ 52.642450] c0 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c [ 52.642454] c0 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c [ 52.642460] c0 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4 [ 52.642466] c0 [<ffffffc00023dd9c>] ____fput+0x20/0x2c [ 52.642473] c0 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8 [ 52.642482] c0 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c [ 52.642487] c0 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0 [ 52.642494] c0 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c [ 52.642501] c0 [<ffffffc00008a8f0>] do_signal+0x154/0x518 [ 52.642507] c0 [<ffffffc00008af00>] do_notify_resume+0x70/0x78 [ 52.642512] c0 [<ffffffc000085ee8>] work_pending+0x1c/0x20 [ 52.642514] c1 other info that might help us debug this: [ 52.642517] c1 Possible unsafe locking scenario: [ 52.642518] c1 CPU0 CPU1 [ 52.642520] c1 ---- ---- [ 52.642525] c0 lock(ffs_lock); [ 52.642529] c0 lock(udc_lock); [ 52.642533] c0 lock(ffs_lock); [ 52.642537] c0 lock(udc_lock); [ 52.642539] c1 *** DEADLOCK *** [ 52.642543] c1 1 lock held by usb ffs open/2808: [ 52.642555] c0 #0: (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>] ffs_data_clear+0x30/0x140 [ 52.642557] c1 stack backtrace: [ 52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G [ 52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT) [ 52.642568] c1 Call trace: [ 52.642573] c1 [<ffffffc00008b430>] dump_backtrace+0x0/0x170 [ 52.642577] c1 [<ffffffc00008b5c0>] show_stack+0x20/0x28 [ 52.642583] c1 [<ffffffc000422694>] dump_stack+0xa8/0xe0 [ 52.642587] c1 [<ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4 [ 52.642591] c1 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238 [ 52.642595] c1 [<ffffffc000123b54>] lock_acquire+0xe4/0x298 [ 52.642599] c1 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc [ 52.642604] c1 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8 [ 52.642608] c1 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44 [ 52.642613] c1 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140 [ 52.642618] c1 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c [ 52.642621] c1 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c [ 52.642625] c1 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c [ 52.642629] c1 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4 [ 52.642633] c1 [<ffffffc00023dd9c>] ____fput+0x20/0x2c [ 52.642636] c1 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8 [ 52.642640] c1 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c [ 52.642644] c1 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0 [ 52.642647] c1 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c [ 52.642651] c1 [<ffffffc00008a8f0>] do_signal+0x154/0x518 [ 52.642656] c1 [<ffffffc00008af00>] do_notify_resume+0x70/0x78 [ 52.642659] c1 [<ffffffc000085ee8>] work_pending+0x1c/0x20 Acked-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
matanb10
pushed a commit
that referenced
this pull request
Mar 15, 2017
This fixes a regression which was introduced by commit f1bddbb, by reverting a small fragment of commit 855ed04. If the following conditions were met, usb_gadget_probe_driver() returned 0, although the call was unsuccessful: 1. A particular UDC was specified by thge gadget driver (using member "udc_name" of struct usb_gadget_driver). 2. The UDC with this name is available. 3. Another gadget driver is already bound to this gadget. 4. The gadget driver has the "match_existing_only" flag set. In this case, the return code variable "ret" is set to 0, the return code of a strcmp() call (to check for the second condition). This also fixes an oops which could occur in the following scenario: 1. Two usb gadget instances were configured using configfs. 2. The first gadget configuration was bound to a UDC (using the configfs attribute "UDC"). 3. It was tried to bind the second gadget configuration to the same UDC in the same way. This operation was then wrongly reported as being successful. 4. The second gadget configuration's "UDC" attribute is cleared, to unbind the (not really bound) second gadget configuration from the UDC. <BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff94f5e5e9>] __list_del_entry+0x29/0xc0 PGD 41b4c5067 PUD 41a598067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: cdc_acm usb_f_fs usb_f_serial usb_f_acm u_serial libcomposite configfs dummy_hcd bnep intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm snd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd snd_hda_codec_realtek snd_hda_codec_generic serio_raw uvcvideo videobuf2_vmalloc btusb snd_usb_audio snd_hda_intel videobuf2_memops btrtl snd_hda_codec snd_hda_core snd_usbmidi_lib btbcm videobuf2_v4l2 btintel snd_hwdep videobuf2_core snd_seq_midi bluetooth snd_seq_midi_event videodev xpad efi_pstore snd_pcm_oss rfkill joydev media crc16 ff_memless snd_mixer_oss snd_rawmidi nls_ascii snd_pcm snd_seq snd_seq_device nls_cp437 mei_me snd_timer vfat sg udc_core lpc_ich fat efivars mfd_core mei snd soundcore battery nuvoton_cir rc_core evdev intel_smartconnect ie31200_edac edac_core shpchp tpm_tis tpm_tis_core tpm parport_pc ppdev lp parport efivarfs autofs4 btrfs xor raid6_pq hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid uas usb_storage sr_mod cdrom sd_mod ahci libahci nouveau i915 crc32c_intel i2c_algo_bit psmouse ttm xhci_pci libata scsi_mod ehci_pci drm_kms_helper xhci_hcd ehci_hcd r8169 mii usbcore drm nvme nvme_core fjes button [last unloaded: net2280] CPU: 5 PID: 829 Comm: bash Not tainted 4.9.0-rc7 #1 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extreme3, BIOS P1.50 07/11/2013 task: ffff880419ce4040 task.stack: ffffc90002ed4000 RIP: 0010:[<ffffffff94f5e5e9>] [<ffffffff94f5e5e9>] __list_del_entry+0x29/0xc0 RSP: 0018:ffffc90002ed7d68 EFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff88041787ec30 RCX: dead000000000200 RDX: 0000000000000000 RSI: ffff880417482002 RDI: ffff88041787ec30 RBP: ffffc90002ed7d68 R08: 0000000000000000 R09: 0000000000000010 R10: 0000000000000000 R11: ffff880419ce4040 R12: ffff88041787eb68 R13: ffff88041787eaa8 R14: ffff88041560a2c0 R15: 0000000000000001 FS: 00007fe4e49b8700(0000) GS:ffff88042f340000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000041b4c4000 CR4: 00000000001406e0 Stack: ffffc90002ed7d80 ffffffff94f5e68d ffffffffc0ae5ef0 ffffc90002ed7da0 ffffffffc0ae22aa ffff88041787e800 ffff88041787e800 ffffc90002ed7dc0 ffffffffc0d7a727 ffffffff952273fa ffff88041aba5760 ffffc90002ed7df8 Call Trace: [<ffffffff94f5e68d>] list_del+0xd/0x30 [<ffffffffc0ae22aa>] usb_gadget_unregister_driver+0xaa/0xc0 [udc_core] [<ffffffffc0d7a727>] unregister_gadget+0x27/0x60 [libcomposite] [<ffffffff952273fa>] ? mutex_lock+0x1a/0x30 [<ffffffffc0d7a9b8>] gadget_dev_desc_UDC_store+0x88/0xe0 [libcomposite] [<ffffffffc0af8aa0>] configfs_write_file+0xa0/0x100 [configfs] [<ffffffff94e10d27>] __vfs_write+0x37/0x160 [<ffffffff94e31430>] ? __fd_install+0x30/0xd0 [<ffffffff95229dae>] ? _raw_spin_unlock+0xe/0x10 [<ffffffff94e11458>] vfs_write+0xb8/0x1b0 [<ffffffff94e128f8>] SyS_write+0x58/0xc0 [<ffffffff94e31594>] ? __close_fd+0x94/0xc0 [<ffffffff9522a0fb>] entry_SYSCALL_64_fastpath+0x1e/0xad Code: 66 90 55 48 8b 07 48 b9 00 01 00 00 00 00 ad de 48 8b 57 08 48 89 e5 48 39 c8 74 29 48 b9 00 02 00 00 00 00 ad de 48 39 ca 74 3a <4c> 8b 02 4c 39 c7 75 52 4c 8b 40 08 4c 39 c7 75 66 48 89 50 08 RIP [<ffffffff94f5e5e9>] __list_del_entry+0x29/0xc0 RSP <ffffc90002ed7d68> CR2: 0000000000000000 ---[ end trace 99fc090ab3ff6cbc ]--- Fixes: f1bddbb ("usb: gadget: Fix binding to UDC via configfs interface") Signed-off-by: Felix Hädicke <felixhaedicke@web.de> Tested-by: Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
matanb10
pushed a commit
that referenced
this pull request
Mar 15, 2017
__skb_flow_dissect can be called with a skb or a data packet, either can be NULL. All calls seems to have been moved to __skb_header_pointer except the pptp handling which is still calling skb_header_pointer. skb_header_pointer will use skb->data and thus: [ 109.556866] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [ 109.557102] IP: [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.557263] PGD 0 [ 109.557338] [ 109.557484] Oops: 0000 [#1] SMP [ 109.557562] Modules linked in: chaoskey [ 109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 torvalds#79 [ 109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015 [ 109.557957] task: ffff94085c27bc00 task.stack: ffffb745c0068000 [ 109.558041] RIP: 0010:[<ffffffff88dc02f8>] [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.558203] RSP: 0018:ffff94087fc83d40 EFLAGS: 00010206 [ 109.558286] RAX: 0000000000000130 RBX: ffffffff8975bf80 RCX: ffff94084fab6800 [ 109.558373] RDX: 0000000000000010 RSI: 000000000000000c RDI: 0000000000000000 [ 109.558460] RBP: 0000000000000b88 R08: 0000000000000000 R09: 0000000000000022 [ 109.558547] R10: 0000000000000008 R11: ffff94087fc83e04 R12: 0000000000000000 [ 109.558763] R13: ffff94084fab6800 R14: ffff94087fc83e04 R15: 000000000000002f [ 109.558979] FS: 0000000000000000(0000) GS:ffff94087fc80000(0000) knlGS:0000000000000000 [ 109.559326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 109.559539] CR2: 0000000000000080 CR3: 0000000281809000 CR4: 00000000001026e0 [ 109.559753] Stack: [ 109.559957] 000000000000000c ffff94084fab6822 0000000000000001 ffff94085c2b5fc0 [ 109.560578] 0000000000000001 0000000000002000 0000000000000000 0000000000000000 [ 109.561200] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 109.561820] Call Trace: [ 109.562027] <IRQ> [ 109.562108] [<ffffffff88dfb4fa>] ? eth_get_headlen+0x7a/0xf0 [ 109.562522] [<ffffffff88c5a35a>] ? igb_poll+0x96a/0xe80 [ 109.562737] [<ffffffff88dc912b>] ? net_rx_action+0x20b/0x350 [ 109.562953] [<ffffffff88546d68>] ? __do_softirq+0xe8/0x280 [ 109.563169] [<ffffffff8854704a>] ? irq_exit+0xaa/0xb0 [ 109.563382] [<ffffffff8847229b>] ? do_IRQ+0x4b/0xc0 [ 109.563597] [<ffffffff8902d4ff>] ? common_interrupt+0x7f/0x7f [ 109.563810] <EOI> [ 109.563890] [<ffffffff88d57530>] ? cpuidle_enter_state+0x130/0x2c0 [ 109.564304] [<ffffffff88d57520>] ? cpuidle_enter_state+0x120/0x2c0 [ 109.564520] [<ffffffff8857eacf>] ? cpu_startup_entry+0x19f/0x1f0 [ 109.564737] [<ffffffff8848d55a>] ? start_secondary+0x12a/0x140 [ 109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00 00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2 04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84 24 84 [ 109.569959] RIP [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.570245] RSP <ffff94087fc83d40> [ 109.570453] CR2: 0000000000000080 Fixes: ab10dcc ("rps: Inspect PPTP encapsulated by GRE to get flow hash") Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
matanb10
pushed a commit
that referenced
this pull request
Mar 29, 2017
After srp_process_rsp() returns there is a short time during which the scsi_host_find_tag() call will return a pointer to the SCSI command that is being completed. If during that time a duplicate response is received, avoid that the following call stack appears: BUG: unable to handle kernel NULL pointer dereference at (null) IP: srp_recv_done+0x450/0x6b0 [ib_srp] Oops: 0000 [#1] SMP CPU: 10 PID: 0 Comm: swapper/10 Not tainted 4.10.0-rc7-dbg+ #1 Call Trace: <IRQ> __ib_process_cq+0x4b/0xd0 [ib_core] ib_poll_handler+0x1d/0x70 [ib_core] irq_poll_softirq+0xba/0x120 __do_softirq+0xba/0x4c0 irq_exit+0xbe/0xd0 smp_apic_timer_interrupt+0x38/0x50 apic_timer_interrupt+0x90/0xa0 </IRQ> RIP: srp_recv_done+0x450/0x6b0 [ib_srp] RSP: ffff88046f483e20 Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Cc: Israel Rukshin <israelr@mellanox.com> Cc: Max Gurtovoy <maxg@mellanox.com> Cc: Laurence Oberman <loberman@redhat.com> Cc: Steve Feeley <Steve.Feeley@sandisk.com> Cc: <stable@vger.kernel.org> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.