Re: [PATCH] net: sched: fix a use-after-free error on chain on the error exit path
Fri, May 19, 2017 at 07:17:59PM CEST, xiyou.wangc...@gmail.com wrote:
>On Thu, May 18, 2017 at 7:07 AM, Colin King wrote:
>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>> index 4020b8d932a1..82ebdc3fcb2e 100644
>> --- a/net/sched/cls_api.c
>> +++ b/net/sched/cls_api.c
>> @@ -511,6 +511,7 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct
>> nlmsghdr *n,
>> if (n->nlmsg_type == RTM_DELTFILTER && prio == 0) {
>> tfilter_notify_chain(net, skb, n, chain, RTM_DELTFILTER);
>> tcf_chain_destroy(chain);
>
>
>Jiri, how does this work...? An action could hold a refcnt to a filter
>chain, but here you destroy a whole chain without respecting
>the refcnt???
Correct. I missed this. Will fix, thanks.
>
>
>> + chain = NULL;
>> err = 0;
>> goto errout;
>
>Colin, not your fault, I think we may miss something more serious
>when reviewing Jiri's patchset. ;)
>
>Thanks.
[v2 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM
XHCI specification 1.1 does not require xHCI 1.0 compliant controllers
to always enable hardware USB2 LPM.
However, the current xHCI driver always enable it by setting HLE=1 when
seeing HLC=1. This makes certain xHCI controllers that have broken USB2
HW LPM fail to work as there is no way to disable this feature.
This patch adds support to control disabling USB2 Hardware LPM via
DT/ACPI attribute.
Signed-off-by: Tung Nguyen
Signed-off-by: Thang Q. Nguyen
---
Changes since v1:
- Update DT/ACPI attribute and corresponding codes from HLE to LPM to
be consistent with other attribute names.
---
Documentation/devicetree/bindings/usb/usb-xhci.txt |1 +
drivers/usb/host/xhci-plat.c |3 +++
drivers/usb/host/xhci.c|7 ++-
drivers/usb/host/xhci.h|1 +
4 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 2d80b60..96f1ac0 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -26,6 +26,7 @@ Required properties:
Optional properties:
- clocks: reference to a clock
+ - usb2-lpm-disable: disable USB2 LPM for hardware does not support it
- usb3-lpm-capable: determines if platform is USB3 LPM capable
- quirk-broken-port-ped: set if the controller has broken port disable
mechanism
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 7c2a9e7..950eaf0 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -267,6 +267,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto disable_clk;
}
+ if (device_property_read_bool(&pdev->dev, "usb2-lpm-disable"))
+ xhci->quirks |= XHCI_USB2_LPM_DISABLE;
+
if (device_property_read_bool(sysdev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2d13102..47d51d4 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4055,6 +4055,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
unsigned long flags;
int hird, exit_latency;
int ret;
+ int usb2_lpm_disable = 0;
if (hcd->speed >= HCD_USB3 || !xhci->hw_lpm_support ||
!udev->lpm_capable)
@@ -4079,7 +4080,11 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd
*hcd,
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);
- if (enable) {
+ /* Check for optional disable USB2 LPM if XHCI 1.0 */
+ if ((xhci->quirks & XHCI_USB2_LPM_DISABLE) && (xhci->hci_version ==
0x100))
+ usb2_lpm_disable = 1;
+
+ if (enable && !usb2_lpm_disable) {
/* Host supports BESL timeout instead of HIRD */
if (udev->usb2_hw_lpm_besl_capable) {
/* if device doesn't have a preferred BESL value use a
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 73a28a9..cfb9f5d 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1819,6 +1819,7 @@ struct xhci_hcd {
/* For controller with a broken Port Disable implementation */
#define XHCI_BROKEN_PORT_PED (1 << 25)
#define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
+#define XHCI_USB2_LPM_DISABLE (1 << 27)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
--
1.7.1
Re: Widespread crashes in -next, bisected to 'mm: drop HASH_ADAPT'
On Fri 19-05-17 09:46:23, Guenter Roeck wrote: > Hi, > > my qemu tests of next-20170519 show the following results: > total: 122 pass: 30 fail: 92 > > I won't bother listing all of the failures; they are available at > http://kerneltests.org/builders. I bisected one (openrisc, because > it gives me some console output before dying). It points to > 'mm: drop HASH_ADAPT' as the culprit. Bisect log is attached. > > A quick glance suggests that 64 bit kernels pass and 32 bit kernels fail. > 32-bit x86 images fail and should provide an easy test case. Hmm, this is quite unexpected as the patch is not supposed to change things much. It just removes the flag and perform the new hash scaling automatically for all requeusts which do not have any high limit. Some of those didn't have HASH_ADAPT before but that shouldn't change the picture much. The only thing that I can imagine is that what formerly failed for early memblock allocations is now suceeding and that depletes the early memory. Do you have any serial console from the boot? -- Michal Hocko SUSE Labs
Re: [PATCH BUGFIX] block, bfq: access and cache blkg data only when safe
> Il giorno 19 mag 2017, alle ore 16:54, Tejun Heo ha scritto: > > Hello, Paolo. > > On Fri, May 19, 2017 at 10:39:08AM +0200, Paolo Valente wrote: >> Operations on blkg objects in blk-cgroup are protected with the >> request_queue lock, which is no more the lock that protects >> I/O-scheduler operations in blk-mq. The latter are now protected with >> finer-grained per-scheduler-instance locks. As a consequence, if blkg >> and blkg-related objects are accessed in a blk-mq I/O scheduler, it is >> possible to have races, unless proper care is taken for these >> accesses. BFQ does access these objects, and does incur these races. >> >> This commit addresses this issue without introducing further locks, by >> exploiting the following facts. Destroy operations on a blkg invoke, >> as a first step, hooks of the scheduler associated with the blkg. And >> these hooks are executed with bfqd->lock held for BFQ. As a >> consequence, for any blkg associated with the request queue an >> instance of BFQ is attached to, we are guaranteed that such a blkg is >> not destroyed and that all the pointers it contains are consistent, >> (only) while that instance is holding its bfqd->lock. A blkg_lookup >> performed with bfqd->lock held then returns a fully consistent blkg, >> which remains consistent until this lock is held. >> >> In view of these facts, this commit caches any needed blkg data (only) >> when it (safely) detects a parent-blkg change for an internal entity, >> and, to cache these data safely, it gets the new blkg, through a >> blkg_lookup, and copies data while keeping the bfqd->lock held. As of >> now, BFQ needs to cache only the path of the blkg, which is used in >> the bfq_log_* functions. >> >> This commit also removes or updates some stale comments on locking >> issues related to blk-cgroup operations. > > For a quick fix, this is fine but I think it'd be much better to > update blkcg core so that we protect lookups with rcu and refcnt the > blkg with percpu refs so that we can use blkcg correctly for all > purposes with blk-mq. There's no reason to hold up the immediate fix > for that but it'd be nice to at least note what we should be doing in > the longer term in a comment. > Ok. I have started thinking of a blk-cgroup-wide solution, but, Tejun and Jens, the more I think about it, the more I see a more structural bug :( The bug seems to affect CFQ too, even if CFQ still uses the request_queue lock. Hoping that the bug is only in my mind, here is first my understanding of how the data structures related to the bug are performed, and, second, why handling them this way apparently leads to the bug. For a given instance of [B|C]FQ (i.e., of BFQ or CFQ), a [b|c]fq_group (descriptor of a group in [B|C]FQ) is created on the creation of each blkg associated with the same request queue that instance of [B|C]FQ is attached to. The schedulable entities that belong to this blkg (only queues in CFQ, or both queues and generic entities in BFQ), are then associated with this [b|c]fq_group on the arrival on new I/O requests for them: these entities contain a pointer to a [b|c]fq_group, and the pointer is assigned the address of this new [b|c]fq_group. The functions where the association occurs are bfq_get_rq_private for BFQ and cfq_set_request for CFQ. Both hooks are executed before the hook for actually enqueueing the request. Any access to group information is performed through this [b|c]fq_group field. The associated blkg is accessed through the policy_data pointer in the bfq_group (the policy data in its turn contains a pointer to the blkg) Consider a process or a group that is moved from a given source group to a different group, or simply removed from a group (although I didn't yet succeed in just removing a process from a group :) ). The pointer to the [b|c]fq_group contained in the schedulable entity belonging to the source group *is not* updated, in BFQ, if the entity is idle, and *is not* updated *unconditionally* in CFQ. The update will happen in bfq_get_rq_private or cfq_set_request, on the arrival of a new request. But, if the move happens right after the arrival of a request, then all the scheduler functions executed until a new request arrives for that entity will see a stale [b|c]fq_group. Much worse, if also a blkcg_deactivate_policy or a blkg_destroy are executed right after the move, then both the policy data pointed by the [b|c]fq_group and the [b|c]fq_group itself may be deallocated. So, all the functions of the scheduler invoked before next request arrival may use dangling references! The symptom reported by BFQ users has been actually the dereference of dangling bfq_group or policy data pointers in a request_insert What do you think, have I been mistaken in some step? Thanks, Paolo > Thanks. > > -- > tejun
Re: [PATCH] mm: clarify why we want kmalloc before falling backto vmallock
On Fri 19-05-17 17:46:58, John Hubbard wrote: > On 05/17/2017 01:09 AM, Michal Hocko wrote: > >From: Michal Hocko > > > >While converting drm_[cm]alloc* helpers to kvmalloc* variants Chris > >Wilson has wondered why we want to try kmalloc before vmalloc fallback > >even for larger allocations requests. Let's clarify that one larger > >physically contiguous block is less likely to fragment memory than many > >scattered pages which can prevent more large blocks from being created. > > > >Suggested-by: Chris Wilson > >Signed-off-by: Michal Hocko > >--- > > mm/util.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > >diff --git a/mm/util.c b/mm/util.c > >index 464df3489903..87499f8119f2 100644 > >--- a/mm/util.c > >+++ b/mm/util.c > >@@ -357,7 +357,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node) > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > /* > >- * Make sure that larger requests are not too disruptive - no OOM > >+ * We want to attempt a large physically contiguous block first because > >+ * it is less likely to fragment multiple larger blocks and therefore > >+ * contribute to a long term fragmentation less than vmalloc fallback. > >+ * However make sure that larger requests are not too disruptive - no > >OOM > > * killer and no allocation failure warnings as we have a fallback > > */ > > Thanks for adding this, it's great to have. Here's a slightly polished > version of your words, if you like: > > /* >* We want to attempt a large physically contiguous block first because >* it is less likely to fragment multiple larger blocks. This approach >* therefore contributes less to long term fragmentation than a vmalloc >* fallback would. However, make sure that larger requests are not too >* disruptive: no OOM killer and no allocation failure warnings, as we >* have a fallback. >*/ Looks ok to me. -- Michal Hocko SUSE Labs
[PATCH] modpost: abort if a module name is too long
From: Wanlong Gao
Module name has a limited length, but currently the build system
allows the build finishing even if the module name is too long.
CC
/root/kprobe_example/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.mod.o
/root/kprobe_example/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.mod.c:9:2:
warning: initializer-string for array of chars is too long [enabled by default]
.name = KBUILD_MODNAME,
^
but it's merely a warning.
This patch adds the check of the module name length in modpost and stops
the build properly.
Signed-off-by: Wanlong Gao
Signed-off-by: Xie XiuQi
---
scripts/mod/modpost.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 30d752a..db11c57 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -2166,6 +2166,17 @@ static int add_versions(struct buffer *b, struct module
*mod)
{
struct symbol *s, *exp;
int err = 0;
+ const char *mod_name;
+
+ mod_name = strrchr(mod->name, '/');
+ if (mod_name == NULL)
+ mod_name = mod->name;
+ else
+ mod_name++;
+ if (strlen(mod_name) >= MODULE_NAME_LEN) {
+ merror("module name is too long [%s.ko]\n", mod->name);
+ return 1;
+ }
for (s = mod->unres; s; s = s->next) {
exp = find_symbol(s->name);
--
1.8.3.1
[PATCH v2] Use ctlr directly in rdac_failover_get()
rdac_failover_get references struct rdac_controller as
ctlr->ms_sdev->handler_data->ctlr for no apparent reason. Besides being
inefficient this also introduces a null-pointer dereference as
send_mode_select() sets ctlr->ms_sdev to NULL before calling
rdac_failover_get():
[ 18.432550] device-mapper: multipath service-time: version 0.3.0 loaded
[ 18.436124] BUG: unable to handle kernel NULL pointer dereference at
0790
[ 18.436129] IP: send_mode_select+0xca/0x560
[ 18.436129] PGD 0
[ 18.436130] P4D 0
[ 18.436130]
[ 18.436132] Oops: [#1] SMP
[ 18.436133] Modules linked in: dm_service_time sd_mod dm_multipath amdkfd
amd_iommu_v2 radeon(+) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect
sysimgblt fb_sys_fops ttm qla2xxx drm serio_raw scsi_transport_fc bnx2 i2c_core
dm_mirror dm_region_hash dm_log dm_mod
[ 18.436143] CPU: 4 PID: 443 Comm: kworker/u16:2 Not tainted
4.12.0-rc1.1.el7.test.x86_64 #1
[ 18.436144] Hardware name: IBM BladeCenter LS22 -[79013SG]-/Server Blade,
BIOS -[L8E164AUS-1.07]- 05/25/2011
[ 18.436145] Workqueue: kmpath_rdacd send_mode_select
[ 18.436146] task: 880225116a40 task.stack: c90002bd8000
[ 18.436148] RIP: 0010:send_mode_select+0xca/0x560
[ 18.436148] RSP: 0018:c90002bdbda8 EFLAGS: 00010246
[ 18.436149] RAX: RBX: c90002bdbe08 RCX: 88017ef04a80
[ 18.436150] RDX: c90002bdbe08 RSI: 88017ef04a80 RDI: 8802248e4388
[ 18.436151] RBP: c90002bdbe48 R08: R09: 81c104c0
[ 18.436151] R10: 01ff R11: 035a R12: c90002bdbdd8
[ 18.436152] R13: 8802248e4390 R14: 880225152800 R15: 8802248e4400
[ 18.436153] FS: () GS:880227d0()
knlGS:
[ 18.436154] CS: 0010 DS: ES: CR0: 80050033
[ 18.436154] CR2: 0790 CR3: 00042535b000 CR4: 06e0
[ 18.436155] Call Trace:
[ 18.436159] ? rdac_activate+0x14e/0x150
[ 18.436161] ? refcount_dec_and_test+0x11/0x20
[ 18.436162] ? kobject_put+0x1c/0x50
[ 18.436165] ? scsi_dh_activate+0x6f/0xd0
[ 18.436168] process_one_work+0x149/0x360
[ 18.436170] worker_thread+0x4d/0x3c0
[ 18.436172] kthread+0x109/0x140
[ 18.436173] ? rescuer_thread+0x380/0x380
[ 18.436174] ? kthread_park+0x60/0x60
[ 18.436176] ret_from_fork+0x2c/0x40
[ 18.436177] Code: 49 c7 46 20 00 00 00 00 4c 89 ef c6 07 00 0f 1f 40 00 45
31 ed c7 45 b0 05 00 00 00 44 89 6d b4 4d 89 f5 4c 8b 75 a8 49 8b 45 20 <48> 8b
b0 90 07 00 00 48 8b 56 10 8b 42 10 48 8d 7a 28 85 c0 0f
[ 18.436192] RIP: send_mode_select+0xca/0x560 RSP: c90002bdbda8
[ 18.436192] CR2: 0790
[ 18.436198] ---[ end trace 40f3e4dca1ffabdd ]---
[ 18.436199] Kernel panic - not syncing: Fatal exception
[ 18.436222] Kernel Offset: disabled
[-- MARK -- Thu May 18 11:45:00 2017]
Fixes: 3278255 scsi_dh_rdac: switch to scsi_execute_req_flags()
Cc: sta...@vger.kernel.org
Signed-off-by: Artem Savkov
---
drivers/scsi/device_handler/scsi_dh_rdac.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/device_handler/scsi_dh_rdac.c
b/drivers/scsi/device_handler/scsi_dh_rdac.c
index 3cbab87..2ceff58 100644
--- a/drivers/scsi/device_handler/scsi_dh_rdac.c
+++ b/drivers/scsi/device_handler/scsi_dh_rdac.c
@@ -265,18 +265,16 @@ static unsigned int rdac_failover_get(struct
rdac_controller *ctlr,
struct list_head *list,
unsigned char *cdb)
{
- struct scsi_device *sdev = ctlr->ms_sdev;
- struct rdac_dh_data *h = sdev->handler_data;
struct rdac_mode_common *common;
unsigned data_size;
struct rdac_queue_data *qdata;
u8 *lun_table;
- if (h->ctlr->use_ms10) {
+ if (ctlr->use_ms10) {
struct rdac_pg_expanded *rdac_pg;
data_size = sizeof(struct rdac_pg_expanded);
- rdac_pg = &h->ctlr->mode_select.expanded;
+ rdac_pg = &ctlr->mode_select.expanded;
memset(rdac_pg, 0, data_size);
common = &rdac_pg->common;
rdac_pg->page_code = RDAC_PAGE_CODE_REDUNDANT_CONTROLLER + 0x40;
@@ -288,7 +286,7 @@ static unsigned int rdac_failover_get(struct
rdac_controller *ctlr,
struct rdac_pg_legacy *rdac_pg;
data_size = sizeof(struct rdac_pg_legacy);
- rdac_pg = &h->ctlr->mode_select.legacy;
+ rdac_pg = &ctlr->mode_select.legacy;
memset(rdac_pg, 0, data_size);
common = &rdac_pg->common;
rdac_pg->page_code = RDAC_PAGE_CODE_REDUNDANT_CONTROLLER;
@@ -304,7 +302,7 @@ static unsigned int rdac_failover_get(struct
rdac_controller *ctlr,
}
/* Prepare the command. */
- if (h->ctlr->use_ms10) {
+ if (ctlr->use_ms10) {
cdb[0] = MODE_SELECT_10;
Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade
On Fri, May 19, 2017 at 05:54:37PM +, mario.limoncie...@dell.com wrote: > > > > It happens occasionally when you reboot the machine when a device is > > connected but seems to be dependent on the BIOS version. Since it is the > > BIOS who is supposed to enumerated these devices, I suspect that it is > > either problem in BIOS or our PCI enumeration code does something wrong. > > > > I'm fairly certain it's an issue somewhere with Linux PCI enumeration. I > took > the exact same HW and switched it out the SSD to one w/ Win10 1607. > I set the dock and cable to "always allow" in TBT settings applet. > > I don't reproduce any problems with enumeration with the dock plugged in > on cold boot. All the devices hanging off the bridge show up properly. You mean in Windows you don't reproduce the problem, right? Even when you reboot the machine with devices connected. I tried on Intel Skull Canyon NUC so that I disabled the thunderbolt driver and after reboot (warm) I can see the PCI scan error about bus being partially hidden behind a bridge. When this happens PCIe ports of the thunderbolt device/host seem to be unconfigured and Linux then decides to reconfigure them which leads to the problem. When it works we get ACPI hotplug event to the PCIe root port and the PCIe upstream/downstream ports are properly configured by the BIOS. I guess Windows does something differently here than what we do when PCI devices are enumerated. > > > [7.428542] pci_bus :02: Allocating resources > > > [7.428544] pcieport :02:02.0: can't claim BAR 14 [mem 0xd9f0- > > 0xd9ff]: no compatible bridge window > > > [7.451018] Bluetooth: RFCOMM TTY layer initialized > > > [7.451022] Bluetooth: RFCOMM socket layer initialized > > > [7.451026] Bluetooth: RFCOMM ver 1.11 > > > [ 11.958457] wlp58s0: authenticate with 50:6a:03:a7:1c:27 > > > [ 11.969167] wlp58s0: send auth to 50:6a:03:a7:1c:27 (try 1/3) > > > [ 11.975768] wlp58s0: authenticated > > > [ 11.976386] wlp58s0: associate with 50:6a:03:a7:1c:27 (try 1/3) > > > [ 11.984817] wlp58s0: RX AssocResp from 50:6a:03:a7:1c:27 (capab=0x1411 > > status=0 aid=2) > > > [ 12.001864] wlp58s0: associated > > > [ 12.001913] IPv6: ADDRCONF(NETDEV_CHANGE): wlp58s0: link becomes ready > > > [ 27.616672] thunderbolt :03:00.0: timeout reading config space 2 > > > from 0x5 > > > [ 27.616674] thunderbolt :03:00.0: 301: cannot find > > TB_VSEC_CAP_PLUG_EVENTS aborting > > > > > > If I then unplug the cable and plug it back in the dock does show up and > > > authorize > > properly, but is a traceback > > > along the way. > > > --- > > > [ 1653.226296] pcieport :02:02.0: Refused to change power state, > > > currently > > in D3 > > > [ 1653.729116] thunderbolt :03:00.0: stopping RX ring 0 > > > [ 1653.729130] thunderbolt :03:00.0: disabling interrupt at register > > > 0x38200 > > bit 12 (0x -> 0xefff) > > > [ 1653.729159] thunderbolt :03:00.0: stopping TX ring 0 > > > [ 1653.729168] thunderbolt :03:00.0: disabling interrupt at register > > > 0x38200 > > bit 0 (0x -> 0xfffe) > > > [ 1653.729195] thunderbolt :03:00.0: control channel stopped > > > [ 1653.729362] thunderbolt :03:00.0: freeing RX ring 0 > > > [ 1653.729381] thunderbolt :03:00.0: freeing TX ring 0 > > > [ 1653.729407] thunderbolt :03:00.0: shutdown > > > [ 1653.753091] pcieport :02:00.0: Refused to change power state, > > > currently > > in D3 > > > [ 1653.756383] pci_bus :03: busn_res: [bus 03] is released > > > [ 1653.756676] pci_bus :04: busn_res: [bus 04] is released > > > [ 1653.757479] pci_bus :02: busn_res: [bus 02-05] is released > > > [ 1660.846964] ACPI Error: [SPRT] Namespace lookup failure, > > AE_ALREADY_EXISTS (20170303/dswload2-330) > > > [ 1660.846979] ACPI Exception: AE_ALREADY_EXISTS, During name > > lookup/catalog (20170303/psobject-241) > > > [ 1660.846985] ACPI Error: Method parse/execution failed [\_GPE._E42] > > > (Node > > 8ba73016b488), AE_ALREADY_EXISTS (20170303/psparse-543) > > > [ 1660.846996] ACPI Error: Method parse/execution failed [\_GPE._E42] > > > (Node > > 8ba73016b488), AE_ALREADY_EXISTS (20170303/psparse-543) > > > [ 1660.847009] ACPI Exception: AE_ALREADY_EXISTS, while evaluating GPE > > method [_E42] (20170303/evgpe-646) > > > [ 1660.893399] pci :01:00.0: [8086:1576] type 01 class 0x060400 > > > [ 1660.893529] pci :01:00.0: supports D1 D2 > > > [ 1660.893530] pci :01:00.0: PME# supported from D0 D1 D2 D3hot D3cold > > > [ 1660.893625] pci :01:00.0: System wakeup disabled by ACPI > > > [ 1660.893776] pci :02:00.0: [8086:1576] type 01 class 0x060400 > > > [ 1660.894047] pci :02:00.0: supports D1 D2 > > > [ 1660.894049] pci :02:00.0: PME# supported from D0 D1 D2 D3hot D3cold > > > [ 1660.894178] pci :02:01.0: [8086:1576] type 01 class 0x060400 > > > [ 1660.894320] pci :02:01.0: supports D1 D2 > > > [ 1660.894321]
RE: work queue of scsi fc transports should be serialized
On Fri, 2017-05-19 at 09:36 +, Dashi DS1 Cao wrote:
> It seems there is a race of multiple "fc_starget_delete" of the same
> rport, thus of the same SCSI host. The race leads to the race of
> scsi_remove_target and it cannot be prevented by the code snippet
> alone, even of the most recent
> version:
> spin_lock_irqsave(shost->host_lock, flags);
> list_for_each_entry(starget, &shost->__targets, siblings) {
> if (starget->state == STARGET_DEL ||
> starget->state == STARGET_REMOVE)
> continue;
> If there is a possibility that the starget is under deletion(state ==
> STARGET_DEL), it should be possible that list_next_entry(starget,
> siblings) could cause a read access violation.
>Hello Dashi,
>Something else must be going on. From scsi_remove_target():
>restart:
> spin_lock_irqsave(shost->host_lock, flags);
> list_for_each_entry(starget, &shost->__targets, siblings) {
> if (starget->state == STARGET_DEL ||
> starget->state == STARGET_REMOVE)
> continue;
> if (starget->dev.parent == dev || &starget->dev == dev) {
> kref_get(&starget->reap_ref);
> starget->state = STARGET_REMOVE;
> spin_unlock_irqrestore(shost->host_lock, flags);
> __scsi_remove_target(starget);
> scsi_target_reap(starget);
> goto restart;
> }
> }
> spin_unlock_irqrestore(shost->host_lock, flags);
>In other words, before scsi_remove_target() decides to call
>__scsi_remove_target(), it changes the target state into STARGET_REMOVE while
>holding the host lock.
>This means that scsi_remove_target() won't call __scsi_remove_target() twice
>and also that it won't invoke list_next_entry(starget, siblings) after starget
>has been
>freed.
>Bart.
In the crashes of Suse 12 sp1, the root cause is the deletion of a list node
without holding the lock:
spin_lock_irqsave(shost->host_lock, flags);
list_for_each_entry_safe(starget, tmp, &shost->__targets, siblings) {
if (starget->state == STARGET_DEL)
continue;
if (starget->dev.parent == dev || &starget->dev == dev) {
/* assuming new targets arrive at the end */
kref_get(&starget->reap_ref);
spin_unlock_irqrestore(shost->host_lock, flags);
__scsi_remove_target(starget);
list_move_tail(&starget->siblings, &reap_list); --this
deletion from shost->__targets list is done without the lock.
spin_lock_irqsave(shost->host_lock, flags);
}
}
spin_unlock_irqrestore(shost->host_lock, flags);
A better solution is as follows, without introducing more states:
restart:
spin_lock_irqsave(shost->host_lock, flags);
list_for_each_entry_safe(starget, tmp, &shost->__targets, siblings) {
if (starget->dev.parent == dev || &starget->dev == dev) {
/* assuming new targets arrive at the end */
kref_get(&starget->reap_ref);
list_move_tail(&starget->siblings, &reap_list);
spin_unlock_irqrestore(shost->host_lock, flags);
__scsi_remove_target(starget);
goto restart;
}
}
spin_unlock_irqrestore(shost->host_lock, flags);
list_for_each_entry_safe(starget, tmp, &reap_list, siblings)
scsi_target_reap(starget);
Another place that should be modified is the scsi_transport_fc.c:
From:
if (rport->scsi_target_id != -1)
fc_starget_delete(&rport->stgt_delete_work);
To:
if (rport->scsi_target_id != -1) {
fc_flush_work(shost);
BUG_ON(ACCESS_ONCE(rport->scsi_target_id) != -1);
}
Regards,
Dashi Cao
Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration
On Fri, May 19, 2017 at 12:13:26PM -0500, Christoph Lameter wrote: > On Fri, 19 May 2017, Marcelo Tosatti wrote: > > > Use-case: realtime application on an isolated core which for some reason > > updates vmstatistics. > > Ok that is already only happening every 2 seconds by default and that > interval is configurable via the vmstat_interval proc setting. > > > > Just a measurement of vmstat_worker. Pointless. > > > > Shouldnt the focus be on general scenarios rather than particular > > usecases, so that the solution covers a wider range of usecases? > > Yes indeed and as far as I can tell the wider usecases are covered. Not > sure that there is anything required here. > > > The situation as i see is as follows: > > > > Your point of view is: an "isolated CPU" with a set of applications > > cannot update vm statistics, otherwise they pay the vmstat_update cost: > > > > kworker/5:1-245 [005] 1.. 673.454295: workqueue_execute_start: > > work struct a0cf6e493e20: function vmstat_update > > kworker/5:1-245 [005] 1.. 673.454305: workqueue_execute_end: > > work struct a0cf6e493e20 > > > > Thats 10us for example. > > Well with a decent cpu that is 3 usec and it occurs infrequently on the > order of once per multiple seconds. > > > So if want to customize a realtime setup whose code updates vmstatistic, > > you are dead. You have to avoid any systemcall which possibly updates > > vmstatistics (now and in the future kernel versions). > > You are already dead because you allow IPIs and other kernel processing > which creates far more overhead. Still fail to see the point. > > > The point is that these vmstat updates are rare. From > > http://www.7-cpu.com/cpu/Haswell.html: > > > > RAM Latency = 36 cycles + 57 ns (3.4 GHz i7-4770) > > RAM Latency = 62 cycles + 100 ns (3.6 GHz E5-2699 dual) > > > > Lets round to 100ns = 0.1us. > > That depends on the kernel functionality used. > > > You need 100 vmstat updates (all misses to RAM, the worst possible case) > > to have equivalent amount of time of the batching version. > > The batching version occurs every couple of seconds if at all. > > > But thats not the point. The point is the 10us interruption > > to execution of the realtime app (which can either mean > > your current deadline requirements are not met, or that > > another application with lowest latency requirement can't > > be used). > > Ok then you need to get rid of the IPIs and the other stuff that you have > going on with the OS first I think. I'll measure the cost of all IPIs in the system to confirm vmstat_update's costs is larger than the cost of any IPI. > > So why are you against integrating this simple, isolated patch which > > does not affect how current logic works? > > Frankly the argument does not make sense. Vmstat updates occur very > infrequently (probably even less than you IPIs and the other OS stuff that > also causes additional latencies that you seem to be willing to tolerate). > > And you can configure the interval of vmstat updates freely Set > the vmstat_interval to 60 seconds instead of 2 for a try? Is that rare > enough? Not rare enough. Never is rare enough.
Re: [PATCH] firmware: google: memconsole: Prevent overrun attack on coreboot console
On Fri, May 19, 2017 at 02:44:38PM -0700, Julius Werner wrote: > The recent coreboot memory console update (firmware: google: memconsole: > Adapt to new coreboot ring buffer format) introduced a small security > issue in the driver: The new driver implementation parses the memory > console structure again on every access. This is intentional so that > additional lines added concurrently by runtime firmware can be read out. > > However, if an attacker can write to the structure, they could increase > the size value to a point where the driver would read potentially > sensitive memory areas from outside the original console buffer during > the next access. This can be done through /dev/mem, since the console > buffer usually resides in firmware-reserved memory that is not covered > by STRICT_DEVMEM. > > This patch resolves that problem by reading the buffer's size value only > once during boot (where we can still trust the structure). Other parts > of the structure can still be modified at runtime, but the driver's > bounds checks make sure that it will never read outside the buffer. > > Signed-off-by: Julius Werner Care to provide a "Fixes: SHA" type line here saying what commit this fixes the issue for, to allow people to know what is going on. thanks, greg k-h
Re: [PATCH 2/2] ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0
On Fri, May 19, 2017 at 06:51:44PM +0200, Enric Balletbo i Serra wrote:
> We don't need to bitbang these pins anymore, instead we muxed these
> pins as SPI, after this change, done in commit 6c69f726, we introduced
> the following error:
>
> pinctrl-single 44e10800.pinmux: pin PIN85 already requested \
> by 44e10800.pinmux; cannot claim for 4803.spi
> pinctrl-single 44e10800.pinmux: pin-85 (4803.spi) status -22
>
> Fixes: 6c69f726 ("ARM: dts: am335x-sl50: Enable SPI0 interface and Flash
> Memory")
> Signed-off-by: Enric Balletbo i Serra
> ---
> arch/arm/boot/dts/am335x-sl50.dts | 4
> 1 file changed, 4 deletions(-)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH 1/2] ARM: dts: am335x-sl50: Fix card detect pin for mmc1
On Fri, May 19, 2017 at 06:51:43PM +0200, Enric Balletbo i Serra wrote:
> The second version of the hardware moved the card detect pin from gpio0_6
> to gpio1_9, as we won't support the first hardware version fix the pinmux
> configuration of this pin.
>
> Fixes: 8584d4fc ("ARM: dts: am335x-sl50: Add Toby-Churchill SL50 board
> support.")
> Signed-off-by: Enric Balletbo i Serra
> ---
> arch/arm/boot/dts/am335x-sl50.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [kernel-hardening] [PATCH 1/1] Sealable memory support
On Fri, May 19, 2017 at 01:38:11PM +0300, Igor Stoppa wrote: > Dynamically allocated variables can be made read only, > after they have been initialized, provided that they reside in memory > pages devoid of any RW data. > > The implementation supplies means to create independent pools of memory, > which can be individually created, sealed/unsealed and destroyed. > > A global pool is made available for those kernel modules that do not > need to manage an independent pool. > > Signed-off-by: Igor Stoppa > --- > mm/Makefile | 2 +- > mm/smalloc.c | 200 > +++ > mm/smalloc.h | 61 ++ > 3 files changed, 262 insertions(+), 1 deletion(-) > create mode 100644 mm/smalloc.c > create mode 100644 mm/smalloc.h This is really nice, do you have a follow-on patch showing how any of the kernel can be changed to use this new subsystem? Without that, it might be hard to get this approved (we don't like adding new apis without users.) thanks, greg k-h
Re: [PATCH v2] printk: Use the main logbuf in NMI when logbuf_lock is available
On (05/19/17 15:02), Petr Mladek wrote: > > [..] > > > > > the problem is that > > > > > > `PRINTK_NMI_CONTEXT_MASK || PRINTK_NMI_DEFERRED_CONTEXT_MASK' is 0x01 > > > > d'oh... forgot to copy-paste this... > > Grrr, thanks a lot for chasing this down and I am sorry for the troubles. no worries :) > I have rebased both for-4.13 and for-next branches in printk.git > with this fix. I wanted to get rid of this bug in linux-next > ASAP. Please, let me know if you would prefer to handle > this another way in the future. we are cool ;) thanks. -ss
RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade
On Fri, May 19 2017, 07:35 PM, mario.limoncie...@dell.com wrote:
> Here's my setup:
> System: I'm using is an XPS 9350 (Has Alpine Ridge). It's got NVM 16.0. BIOS
> 1.4.13 TBT Device: Dell TB16 (which has AR in the cable and in dock - both
> NVM 16.0).
>
Is it BIOS assist or native enumeration?
> I created a udev rule that will automatically authorize the dock and cable.
> #dell cable
> ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0",
> ATTR{vendor}=="0xd4", ATTR{device}=="0xb051", ATTR{authorized}="1"
> #dell dock
> ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0",
> ATTR{vendor}=="0xd4", ATTR{device}=="0xb054", ATTR{authorized}="1"
>
Note that the udev rule should authorize the cable first and then the dock.
> If I boot the system with the dock connected the cable shows up and authorizes
> but the dock doesn't.
I assume it works in Linux with SL0, right?
[PATCH 1/1] pcmcia: remove left-over %Z format
Commit 5b5e0928f742 ("lib/vsprintf.c: remove %Z support") removed some
usages of format %Z but forgot "%.2Zx". This makes clang 4.0 reports a
-Wformat-extra-args warning because it does not know about %Z.
Replace %Z with %z.
Cc: sta...@vger.kernel.org # v4.11+
Signed-off-by: Nicolas Iooss
---
drivers/char/pcmcia/cm4040_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c
index d4dbd8d8e524..382c864814d9 100644
--- a/drivers/char/pcmcia/cm4040_cs.c
+++ b/drivers/char/pcmcia/cm4040_cs.c
@@ -374,7 +374,7 @@ static ssize_t cm4040_write(struct file *filp, const char
__user *buf,
rc = write_sync_reg(SCR_HOST_TO_READER_START, dev);
if (rc <= 0) {
- DEBUGP(5, dev, "write_sync_reg c=%.2Zx\n", rc);
+ DEBUGP(5, dev, "write_sync_reg c=%.2zx\n", rc);
DEBUGP(2, dev, "<- cm4040_write (failed)\n");
if (rc == -ERESTARTSYS)
return rc;
@@ -387,7 +387,7 @@ static ssize_t cm4040_write(struct file *filp, const char
__user *buf,
for (i = 0; i < bytes_to_write; i++) {
rc = wait_for_bulk_out_ready(dev);
if (rc <= 0) {
- DEBUGP(5, dev, "wait_for_bulk_out_ready rc=%.2Zx\n",
+ DEBUGP(5, dev, "wait_for_bulk_out_ready rc=%.2zx\n",
rc);
DEBUGP(2, dev, "<- cm4040_write (failed)\n");
if (rc == -ERESTARTSYS)
@@ -403,7 +403,7 @@ static ssize_t cm4040_write(struct file *filp, const char
__user *buf,
rc = write_sync_reg(SCR_HOST_TO_READER_DONE, dev);
if (rc <= 0) {
- DEBUGP(5, dev, "write_sync_reg c=%.2Zx\n", rc);
+ DEBUGP(5, dev, "write_sync_reg c=%.2zx\n", rc);
DEBUGP(2, dev, "<- cm4040_write (failed)\n");
if (rc == -ERESTARTSYS)
return rc;
--
2.12.2
[PATCH 1/1] printk: add __printf attributes to internal functions
When compiling with -Wsuggest-attribute=format, gcc complains that some
functions in kernel/printk/printk_safe.c transmit their argument to
printf-like functions without having a printf attribute. Silence these
warnings by adding relevant __printf attributes.
Signed-off-by: Nicolas Iooss
---
kernel/printk/printk_safe.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 033e50a7d706..2e27a31941f4 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -80,8 +80,8 @@ static void queue_flush_work(struct printk_safe_seq_buf *s)
* happen, printk_safe_log_store() will notice the buffer->len mismatch
* and repeat the write.
*/
-static int printk_safe_log_store(struct printk_safe_seq_buf *s,
-const char *fmt, va_list args)
+static __printf(2, 0) int printk_safe_log_store(struct printk_safe_seq_buf *s,
+ const char *fmt, va_list args)
{
int add;
size_t len;
@@ -299,7 +299,7 @@ void printk_safe_flush_on_panic(void)
* one writer running. But the buffer might get flushed from another
* CPU, so we need to be careful.
*/
-static int vprintk_nmi(const char *fmt, va_list args)
+static __printf(1, 0) int vprintk_nmi(const char *fmt, va_list args)
{
struct printk_safe_seq_buf *s = this_cpu_ptr(&nmi_print_seq);
@@ -330,7 +330,7 @@ static int vprintk_nmi(const char *fmt, va_list args)
* into itself. It uses a per-CPU buffer to store the message, just like
* NMI.
*/
-static int vprintk_safe(const char *fmt, va_list args)
+static __printf(1, 0) int vprintk_safe(const char *fmt, va_list args)
{
struct printk_safe_seq_buf *s = this_cpu_ptr(&safe_print_seq);
--
2.12.2
Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"
Hi, On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > Looks like you running your patched kernel? > That's right. > > > >>> CONFIG_RMI4_CORE=m > >>> CONFIG_RMI4_I2C=m > >>> CONFIG_RMI4_SPI=m > >>> # CONFIG_RMI4_SMB is not set > > > > This is your issue I believe. > > Indeed, enabling that configuration solves that issue. > > However, I think it is quite unintuitive that a module (psmouse) chooses > a default mode which requires another driver which is not necessarily > included; though it would probably be not a very clean solution to > explicitly check that as well. > > Is this behaviour, that one module requires another without > communicating that clearly, wanted? > I can see 3 solutions: 1. Have PS2_SMBUS depending on RMI_SMBUS (and ELAN_I2C, and others when required) 2. Have PS2_SMBUS selecting RMI_SMBUS (and the others when time comes) 3. Changing the default value of synaptics_intertouch to SYNAPTICS_INTERTOUCH_OFF when RMI_SMBUS is not set Solution 3. might be interesting because it doesn't prevent users to compile the module on the side and is Synaptics only. Dmitry, any comments? Cheers, Benjamin > Thanks, > Pascal > >
RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform
>-Original Message- >From: Cheng, Collins >Sent: Saturday, May 20, 2017 12:53 AM >To: Alexander Duyck; Alex Williamson >Cc: Bjorn Helgaas; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; >Deucher, Alexander; Zytaruk, Kelly; Yinghai Lu >Subject: RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV >incapable platform > >Hi Alex, > >Yes, I hope kernel can disable SR-IOV and related VF resource allocation if the >system BIOS is not SR-IOV capable. > >Adding the parameter "pci=nosriov" sounds a doable solution, but it would need >user to add this parameter manually, right? I think an automatic detection >would >be better. My patch is trying to auto detect and bypass VF resource allocation. > > >-Collins Cheng > Collins, be careful about this. I don't think that this is what we want. If you add "pci=nosriov" then you are globally disabling SRIOV for all devices. This is not the solution that we are looking for. Remember that there are 3 types of SBIOS; "not SR-IOV capable", "SR-IOV capable but does not support large resources", "Complete SR-IOV support". The problem is that we are trying to find a fix for "broken" SBIOS that does support SR-IOV but does not support the full SR-IOV capabilities that devices with large resources require. Thanks, Kelly > >-Original Message- >From: Alexander Duyck [mailto:alexander.du...@gmail.com] >Sent: Friday, May 19, 2017 11:44 PM >To: Alex Williamson >Cc: Cheng, Collins ; Bjorn Helgaas >; linux-...@vger.kernel.org; linux- >ker...@vger.kernel.org; Deucher, Alexander ; >Zytaruk, Kelly ; Yinghai Lu >Subject: Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV >incapable platform > >On Mon, May 15, 2017 at 10:53 AM, Alex Williamson > wrote: >> On Mon, 15 May 2017 08:19:28 + >> "Cheng, Collins" wrote: >> >>> Hi Williamson, >>> >>> We cannot assume BIOS supports SR-IOV, actually only newer server >motherboard BIOS supports SR-IOV. Normal desktop motherboard BIOS or older >server motherboard BIOS doesn't support SR-IOV. This issue would happen if an >user plugs our AMD SR-IOV capable GPU card to a normal desktop motherboard. >> >> Servers should be supporting SR-IOV for a long time now. What really >> is there to a BIOS supporting SR-IOV anyway, it's simply reserving >> sufficient bus number and MMIO resources such that we can enable the >> VFs. This process isn't exclusively reserved for the BIOS. Some >> platforms may choose to only initialize boot devices, leaving the rest >> for the OS to program. The initial proposal here to disable SR-IOV if >> not programmed at OS hand-off disables even the possibility of the OS >> reallocating resources for this device. > >There are differences between supporting SR-IOV and supporting SR-IOV on >devices with massive resources. I know I have seen NICs that will keep a system >from completing POST if SR-IOV is enabled, and MMIO beyond 4G is not. My >guess would be that the issues being seen are probably that they disable >SR-IOV in >the BIOS in such a setup and end up running into issues when they try to boot >into >the Linux kernel as it goes through and tries to allocate resources for SR-IOV >even >though it was disabled in the BIOS. > >It might make sense to add a kernel parameter something like a "pci=nosriov" >that would allow for disabling SR-IOV and related resource allocation if that >is >what we are talking about. That way you could plug in these types of devices >into >a system with a legacy bios or that doesn't wan to allocate addresses above 32b >for MMIO, and this parameter would be all that is needed to disable SR-IOV so >you could plug in a NIC that has SR-IOV associated with it. > >>> I agree that failure to allocate VF resources should leave the device in no >worse condition than before it tried. I hope kernel could allocate PF device >resource before allocating VF device resource, and keep PF device resource >valid >and functional if failed to allocate VF device resource. >>> >>> I will send out dmesg log lspci info tomorrow. Thanks. >> >> Thanks, >> Alex >> >>> -Original Message- >>> From: Alex Williamson [mailto:alex.william...@redhat.com] >>> Sent: Friday, May 12, 2017 10:43 PM >>> To: Cheng, Collins >>> Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; >>> linux-kernel@vger.kernel.org; Deucher, Alexander >>> ; Zytaruk, Kelly ; >>> Yinghai Lu >>> Subject: Re: [PATCH] PCI: Make SR-IOV capable GPU working on the >>> SR-IOV incapable platform >>> >>> On Fri, 12 May 2017 04:51:43 + >>> "Cheng, Collins" wrote: >>> >>> > Hi Williamson, >>> > >>> > I verified the patch is working for both AMD SR-IOV GPU and Intel SR-IOV >NIC. I don't think it is redundant to check the VF BAR valid before call >sriov_init(), >it is safe and saving boot time, also there is no a better method to know if >system >BIOS has correctly initialized the SR-IOV capability or not. >>> >>> It also masks an underlying bug and creates a maintenance issue that we >>> wo
Re: [PATCH] lpfc: nvmet_fc: fix format string
On Fri, 2017-05-19 at 10:04 +0200, Arnd Bergmann wrote: > The lpfc_nvmeio_data() tracing helper always takes a format string and > three additional arguments. No it doesn't. It takes a format and arguments. I don't disagree with the patch, just the characterization of the lpfc_mvmeio_data call in the commit message. > The latest caller has a format string with > only two integer arguments, causing this harmless warning: > > drivers/scsi/lpfc/lpfc_nvmet.c: In function 'lpfc_nvmet_xmt_fcp_release': > drivers/scsi/lpfc/lpfc_nvmet.c:802:25: error: too many arguments for format > [-Werror=format-extra-args] > lpfc_nvmeio_data(phba, "NVMET FCP FREE: xri x%x ste %d\n", ctxp->oxid, > > We could add a dummy argument here, but it seems reasonable to print > the 'abort' flag as the third argument.
RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform
Hi Kelly, This issue also happens in "not SR-IOV capable" SBIOS. It seems some "not SR-IOV capable" SBIOS will directly report error in system BIOS boot stage and doesn't boot to OS. But other "not SR-IOV capable" SBIOS would not report error and boot to Linux. -Collins Cheng -Original Message- From: Zytaruk, Kelly Sent: Saturday, May 20, 2017 6:28 PM To: Cheng, Collins ; Alexander Duyck ; Alex Williamson Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher, Alexander ; Yinghai Lu Subject: RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform >-Original Message- >From: Cheng, Collins >Sent: Saturday, May 20, 2017 12:53 AM >To: Alexander Duyck; Alex Williamson >Cc: Bjorn Helgaas; linux-...@vger.kernel.org; >linux-kernel@vger.kernel.org; Deucher, Alexander; Zytaruk, Kelly; >Yinghai Lu >Subject: RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV >incapable platform > >Hi Alex, > >Yes, I hope kernel can disable SR-IOV and related VF resource >allocation if the system BIOS is not SR-IOV capable. > >Adding the parameter "pci=nosriov" sounds a doable solution, but it >would need user to add this parameter manually, right? I think an >automatic detection would be better. My patch is trying to auto detect and >bypass VF resource allocation. > > >-Collins Cheng > Collins, be careful about this. I don't think that this is what we want. If you add "pci=nosriov" then you are globally disabling SRIOV for all devices. This is not the solution that we are looking for. Remember that there are 3 types of SBIOS; "not SR-IOV capable", "SR-IOV capable but does not support large resources", "Complete SR-IOV support". The problem is that we are trying to find a fix for "broken" SBIOS that does support SR-IOV but does not support the full SR-IOV capabilities that devices with large resources require. Thanks, Kelly > >-Original Message- >From: Alexander Duyck [mailto:alexander.du...@gmail.com] >Sent: Friday, May 19, 2017 11:44 PM >To: Alex Williamson >Cc: Cheng, Collins ; Bjorn Helgaas >; linux-...@vger.kernel.org; linux- >ker...@vger.kernel.org; Deucher, Alexander ; >Zytaruk, Kelly ; Yinghai Lu >Subject: Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV >incapable platform > >On Mon, May 15, 2017 at 10:53 AM, Alex Williamson > wrote: >> On Mon, 15 May 2017 08:19:28 + >> "Cheng, Collins" wrote: >> >>> Hi Williamson, >>> >>> We cannot assume BIOS supports SR-IOV, actually only newer server >motherboard BIOS supports SR-IOV. Normal desktop motherboard BIOS or >older server motherboard BIOS doesn't support SR-IOV. This issue would >happen if an user plugs our AMD SR-IOV capable GPU card to a normal desktop >motherboard. >> >> Servers should be supporting SR-IOV for a long time now. What really >> is there to a BIOS supporting SR-IOV anyway, it's simply reserving >> sufficient bus number and MMIO resources such that we can enable the >> VFs. This process isn't exclusively reserved for the BIOS. Some >> platforms may choose to only initialize boot devices, leaving the >> rest for the OS to program. The initial proposal here to disable >> SR-IOV if not programmed at OS hand-off disables even the possibility >> of the OS reallocating resources for this device. > >There are differences between supporting SR-IOV and supporting SR-IOV >on devices with massive resources. I know I have seen NICs that will >keep a system from completing POST if SR-IOV is enabled, and MMIO >beyond 4G is not. My guess would be that the issues being seen are >probably that they disable SR-IOV in the BIOS in such a setup and end >up running into issues when they try to boot into the Linux kernel as >it goes through and tries to allocate resources for SR-IOV even though it was >disabled in the BIOS. > >It might make sense to add a kernel parameter something like a "pci=nosriov" >that would allow for disabling SR-IOV and related resource allocation >if that is what we are talking about. That way you could plug in these >types of devices into a system with a legacy bios or that doesn't wan >to allocate addresses above 32b for MMIO, and this parameter would be >all that is needed to disable SR-IOV so you could plug in a NIC that has >SR-IOV associated with it. > >>> I agree that failure to allocate VF resources should leave the >>> device in no >worse condition than before it tried. I hope kernel could allocate PF >device resource before allocating VF device resource, and keep PF >device resource valid and functional if failed to allocate VF device resource. >>> >>> I will send out dmesg log lspci info tomorrow. Thanks. >> >> Thanks, >> Alex >> >>> -Original Message- >>> From: Alex Williamson [mailto:alex.william...@redhat.com] >>> Sent: Friday, May 12, 2017 10:43 PM >>> To: Cheng, Collins >>> Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; >>> linux-kernel@vger.kernel.org; De
Re: [GIT PULL] KVM fixes for v4.12-rc2
On 20/05/17 00:21, Linus Torvalds wrote: > So I noticed that my diffstat didn't match either the KVM or the Xen pull. > > The *reason* seems to be that both Radim and Juergen have enabled the > "patience" diff, because if I add "--patience" to the diff line, I get > the same numbers you guys report. > > On Fri, May 19, 2017 at 11:43 AM, Radim Krčmář wrote: >> >> 28 files changed, 297 insertions(+), 125 deletions(-) > > Without "--patience" (the default) I get: > > 28 files changed, 292 insertions(+), 120 deletions(-) > > which is close, but not the exact same thing. > > So I don't mind people using the patience version of the diffing code, > but on the whole it's a loss as often as it is a win, so I'm wondering > _why_ you do this? Is there some other project that has started > suggesting using the patience diff (either with a command line option > or by just doing > > git config diff.algorithm patience > > anyway, it's not a big deal, I'm just curious.. In my case it was a patch which was much easier to review using the patience diff. I just didn't switch back afterwards (what I did now). Juergen
[PATCH] slub/memcg: Cure the brainless abuse of sysfs attributes
memcg_propagate_slab_attrs() abuses the sysfs attribute file functions to propagate settings from the root kmem_cache to a newly created kmem_cache. It does that with: attr->show(root, buf); attr->store(new, buf, strlen(bug); Aside of being a lazy and absurd hackery this is broken because it does not check the return value of the show() function. Some of the show() functions return 0 w/o touching the buffer. That means in such a case the store function is called with the stale content of the previous show(). That causes nonsense like invoking kmem_cache_shrink() on a newly created kmem_cache. In the worst case it would cause handing in an uninitialized buffer. This should be rewritten proper by adding a propagate() callback to those slub_attributes which must be propagated and avoid that insane conversion to and from ASCII, but that's too large for a hot fix. Check at least the return value of the show() function, so calling store() with stale content is prevented. Reported-by: Steven Rostedt Signed-off-by: Thomas Gleixner Cc: sta...@vger.kernel.org --- mm/slub.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/mm/slub.c +++ b/mm/slub.c @@ -5512,6 +5512,7 @@ static void memcg_propagate_slab_attrs(s char mbuf[64]; char *buf; struct slab_attribute *attr = to_slab_attr(slab_attrs[i]); + ssize_t len; if (!attr || !attr->store || !attr->show) continue; @@ -5536,8 +5537,9 @@ static void memcg_propagate_slab_attrs(s buf = buffer; } - attr->show(root_cache, buf); - attr->store(s, buf, strlen(buf)); + len = attr->show(root_cache, buf); + if (len > 0) + attr->store(s, buf, len); } if (buffer)
[PATCH 2/2] pcmcia: nsp_cs: add __printf attribute to logging functions
Adding __printf attributes helps to detect errors in printf format
strings at build time.
Signed-off-by: Nicolas Iooss
---
drivers/scsi/pcmcia/nsp_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/pcmcia/nsp_cs.c b/drivers/scsi/pcmcia/nsp_cs.c
index 5fb6eefc6541..33b982be9763 100644
--- a/drivers/scsi/pcmcia/nsp_cs.c
+++ b/drivers/scsi/pcmcia/nsp_cs.c
@@ -136,7 +136,8 @@ static inline void nsp_inc_resid(struct scsi_cmnd *SCpnt,
int residInc)
scsi_set_resid(SCpnt, scsi_get_resid(SCpnt) + residInc);
}
-static void nsp_cs_message(const char *func, int line, char *type, char *fmt,
...)
+static __printf(4, 5)
+void nsp_cs_message(const char *func, int line, char *type, const char *fmt,
...)
{
va_list args;
char buf[NSP_DEBUG_BUF_LEN];
@@ -153,7 +154,8 @@ static void nsp_cs_message(const char *func, int line, char
*type, char *fmt, ..
}
#ifdef NSP_DEBUG
-static void nsp_cs_dmessage(const char *func, int line, int mask, char *fmt,
...)
+static __printf(4, 5)
+void nsp_cs_dmessage(const char *func, int line, int mask, const char *fmt,
...)
{
va_list args;
char buf[NSP_DEBUG_BUF_LEN];
--
2.12.2
[PATCH 1/2] scsi: nsp32: add __printf attribute to logging functions
nsp32_message() and nsp32_dmessage() use printf format strings in order
to format a message. Adding __printf attributes helps to detect errors
in such format strings at build time, like:
drivers/scsi/nsp32.c:3314:23: error: format '%ld' expects argument
of type 'long int', but argument 6 has type 'pm_message_t {aka
struct pm_message}' [-Werror=format=]
nsp32_msg(KERN_INFO,
"pci-suspend: pdev=0x%p, state=%ld, slot=%s, host=0x%p",
pdev, state, pci_name(pdev), host);
Fix all format string errors which were reported by gcc.
Signed-off-by: Nicolas Iooss
---
drivers/scsi/nsp32.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
index 53c84771f0e8..0689b0564fbf 100644
--- a/drivers/scsi/nsp32.c
+++ b/drivers/scsi/nsp32.c
@@ -257,9 +257,11 @@ staticvoid nsp32_prom_set (nsp32_hw_data *,
int, int);
staticint nsp32_prom_get (nsp32_hw_data *, int);
/* debug/warning/info message */
-static void nsp32_message (const char *, int, char *, char *, ...);
+static __printf(4, 5)
+void nsp32_message (const char *, int, char *, const char *, ...);
#ifdef NSP32_DEBUG
-static void nsp32_dmessage(const char *, int, int,char *, ...);
+static __printf(4, 5)
+void nsp32_dmessage(const char *, int, int,const char *, ...);
#endif
/*
@@ -321,7 +323,8 @@ static struct scsi_host_template nsp32_template = {
#define NSP32_DEBUG_BUF_LEN100
-static void nsp32_message(const char *func, int line, char *type, char *fmt,
...)
+static __printf(4, 5)
+void nsp32_message(const char *func, int line, char *type, const char *fmt,
...)
{
va_list args;
char buf[NSP32_DEBUG_BUF_LEN];
@@ -338,7 +341,8 @@ static void nsp32_message(const char *func, int line, char
*type, char *fmt, ...
}
#ifdef NSP32_DEBUG
-static void nsp32_dmessage(const char *func, int line, int mask, char *fmt,
...)
+static __printf(4, 5)
+void nsp32_dmessage(const char *func, int line, int mask, const char *fmt, ...)
{
va_list args;
char buf[NSP32_DEBUG_BUF_LEN];
@@ -697,7 +701,7 @@ static int nsp32_selection_autoscsi(struct scsi_cmnd *SCpnt)
nsp32_write1(base, ACK_WIDTH, data->cur_target->ackwidth);
nsp32_dbg(NSP32_DEBUG_AUTOSCSI,
- "syncreg=0x%x, ackwidth=0x%x, sgtpaddr=0x%x, id=0x%x",
+ "syncreg=0x%x, ackwidth=0x%x, sgtpaddr=0x%lx, id=0x%x",
nsp32_read1(base, SYNC_REG), nsp32_read1(base, ACK_WIDTH),
nsp32_read4(base, SGT_ADR), nsp32_read1(base,
SCSI_OUT_LATCH_TARGET_ID));
nsp32_dbg(NSP32_DEBUG_AUTOSCSI, "msgout_len=%d, msgout=0x%x",
@@ -888,11 +892,11 @@ static int nsp32_setup_sg_table(struct scsi_cmnd *SCpnt)
if (le32_to_cpu(sgt[i].len) > 0x1) {
nsp32_msg(KERN_ERR,
- "can't transfer over 64KB at a time,
size=0x%lx", le32_to_cpu(sgt[i].len));
+ "can't transfer over 64KB at a time,
size=0x%x", le32_to_cpu(sgt[i].len));
return FALSE;
}
nsp32_dbg(NSP32_DEBUG_SGLIST,
- "num 0x%x : addr 0x%lx len 0x%lx",
+ "num 0x%x : addr 0x%x len 0x%x",
i,
le32_to_cpu(sgt[i].addr),
le32_to_cpu(sgt[i].len ));
@@ -915,7 +919,7 @@ static int nsp32_queuecommand_lck(struct scsi_cmnd *SCpnt,
void (*done)(struct s
nsp32_dbg(NSP32_DEBUG_QUEUECOMMAND,
"enter. target: 0x%x LUN: 0x%llx cmnd: 0x%x cmndlen: 0x%x "
- "use_sg: 0x%x reqbuf: 0x%lx reqlen: 0x%x",
+ "use_sg: 0x%x reqbuf: %p reqlen: 0x%x",
SCpnt->device->id, SCpnt->device->lun, SCpnt->cmnd[0],
SCpnt->cmd_len,
scsi_sg_count(SCpnt), scsi_sglist(SCpnt),
scsi_bufflen(SCpnt));
@@ -2742,7 +2746,7 @@ static int nsp32_detect(struct pci_dev *pdev)
res = request_region(host->io_port, host->n_io_port, "nsp32");
if (res == NULL) {
nsp32_msg(KERN_ERR,
- "I/O region 0x%lx+0x%lx is already used",
+ "I/O region 0x%x+0x%x is already used",
data->BaseAddress, data->NumAddress);
goto free_irq;
}
@@ -2853,7 +2857,7 @@ static int nsp32_eh_bus_reset(struct scsi_cmnd *SCpnt)
spin_lock_irq(SCpnt->device->host->host_lock);
nsp32_msg(KERN_INFO, "Bus Reset");
- nsp32_dbg(NSP32_DEBUG_BUSRESET, "SCpnt=0x%x", SCpnt);
+ nsp32_dbg(NSP32_DEBUG_BUSRESET, "SCpnt=%p", SCpnt);
nsp32_write2(base, IRQ_CONTROL, IRQ_CONTROL_ALL_IRQ_MASK);
nsp32_do_bus_reset(data);
@@ -2912,7 +2916,7 @@ static int nsp32_eh_host_reset
[PATCH 1/1] genksyms: add printf format attribute to error_with_pos()
When compiling with -Wsuggest-attribute=format in HOSTCFLAGS, gcc
complains that error_with_pos() may be declared with a printf format
attribute:
scripts/genksyms/genksyms.c:726:3: warning: function might be
possible candidate for ‘gnu_printf’ format attribute
[-Wsuggest-attribute=format]
vfprintf(stderr, fmt, args);
^~~~
This would allow catching printf-format errors at compile time in
callers to error_with_pos(). Add this attribute.
Signed-off-by: Nicolas Iooss
---
I am sending this to the maintainers listed in section "KERNEL BUILD +
files below scripts/ (unless maintained elsewhere)" even though it does
not list scripts/genksyms/. Should this directory be added in
MAINTAINERS?
scripts/genksyms/genksyms.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/genksyms/genksyms.h b/scripts/genksyms/genksyms.h
index 3bffdcaaa274..b724a0290c75 100644
--- a/scripts/genksyms/genksyms.h
+++ b/scripts/genksyms/genksyms.h
@@ -75,7 +75,7 @@ struct string_list *copy_list_range(struct string_list *start,
int yylex(void);
int yyparse(void);
-void error_with_pos(const char *, ...);
+void error_with_pos(const char *, ...) __attribute__ ((format(printf, 1, 2)));
/*--*/
#define xmalloc(size) ({ void *__ptr = malloc(size); \
--
2.12.2
Re: [PATCH 1/2] scsi: nsp32: add __printf attribute to logging functions
On Sat, 2017-05-20 at 13:16 +0200, Nicolas Iooss wrote:
> nsp32_message() and nsp32_dmessage() use printf format strings in order
> to format a message. Adding __printf attributes helps to detect errors
> in such format strings at build time, like:
>
> drivers/scsi/nsp32.c:3314:23: error: format '%ld' expects argument
> of type 'long int', but argument 6 has type 'pm_message_t {aka
> struct pm_message}' [-Werror=format=]
> nsp32_msg(KERN_INFO,
> "pci-suspend: pdev=0x%p, state=%ld, slot=%s, host=0x%p",
> pdev, state, pci_name(pdev), host);
>
> Fix all format string errors which were reported by gcc.
[]
> diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
[]
> @@ -321,7 +323,8 @@ static struct scsi_host_template nsp32_template = {
>
> #define NSP32_DEBUG_BUF_LEN 100
>
> -static void nsp32_message(const char *func, int line, char *type, char *fmt,
> ...)
> +static __printf(4, 5)
> +void nsp32_message(const char *func, int line, char *type, const char *fmt,
> ...)
> {
> va_list args;
> char buf[NSP32_DEBUG_BUF_LEN];
These could also use vsprintf extension %pV instead of
vsnprintf to a
temporary buffer and then using "%s, "
etc...
Does anyone actually have or use these cards any longer?
Re: [PATCH v2 0/3] Cleanup evergreen/si IRQ handling code
Am 20.05.2017 um 01:48 schrieb Lyude: This is the first part of me going through and cleaning up the IRQ handling code for radeon, since after taking a look at it the other day while trying to debug something I realized basically all of the code was copy pasted everywhere, and quite difficult to actually read through. Will come up with something for r600 and cik once I've got the chipsets on hand to test with. Lyude (3): drm/radeon: Cleanup display interrupt handling for evergreen, si drm/radeon: Cleanup HDMI audio interrupt handling for evergreen drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si I don't have time to do a line by line review, but what I saw looked very good to me. So the whole seres is Acked-by: Christian König . BTW: You don't want to take a look at the other hw generations as well? Regards, Christian. drivers/gpu/drm/radeon/evergreen.c | 943 ++-- drivers/gpu/drm/radeon/radeon.h | 27 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 35 ++ drivers/gpu/drm/radeon/si.c | 655 +- 4 files changed, 344 insertions(+), 1316 deletions(-)
[PATCH v2 0/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system
This is v2 post. This patchset is trying to fix a bug that SGI UV system casually hang during boot with KASLR enabled. The root cause is that mm KASLR adapts size of the direct mapping section only based on the system RAM size. Then later when map SGI UV MMIOH region into the direct mapping during rest_init() invocation, it might go beyond of the directing mapping section and step into VMALLOC or VMEMMAP area, then BUG_ON triggered. The fix is adding a helper function is_early_uv_system to check UV system earlier, then call the helper function in kernel_randomize_memory() to check if it's a SGI UV system, if yes, we keep the size of direct mapping section to be 64TB just as nokslr. With this fix, SGI UV system can have 64TB direct mapping size always, and the starting address of direct mapping/vmalloc/vmemmap and the padding between them can still be randomized to enhance the system security. v1->v2: 1. Mike suggested making is_early_uv_system() an inline function and be put in include/asm/uv/uv.h so that they can adjust them easier in the future. 2. Split the v1 code into uv part and mm KASLR part as Mike suggested. Baoquan He (2): x86/UV: Introduce a helper function to check UV system at earlier stage x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system arch/x86/include/asm/uv/uv.h | 6 ++ arch/x86/mm/kaslr.c | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) -- 2.5.5
[PATCH v2 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage
The SGI BIOS adds UVsystab, and only systems running SGI BIOS
(and now HPE Hawks2) will have UVsystab. And UVsystab is detected in
efi_init() which is at very early stage. So introduce a new helper
function is_early_uv_system() for later usage.
Signed-off-by: Baoquan He
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: "tra...@sgi.com"
Cc: Mike Travis
Cc: Frank Ramsay
---
arch/x86/include/asm/uv/uv.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
index 6686820..159f698 100644
--- a/arch/x86/include/asm/uv/uv.h
+++ b/arch/x86/include/asm/uv/uv.h
@@ -19,6 +19,11 @@ extern const struct cpumask *uv_flush_tlb_others(const
struct cpumask *cpumask,
unsigned long start,
unsigned long end,
unsigned int cpu);
+#include
+static inline int is_early_uv_system(void)
+{
+ return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}
#else /* X86_UV */
@@ -31,6 +36,7 @@ static inline const struct cpumask *
uv_flush_tlb_others(const struct cpumask *cpumask, struct mm_struct *mm,
unsigned long start, unsigned long end, unsigned int cpu)
{ return cpumask; }
+static inline int is_early_uv_system(void) { return 0; }
#endif /* X86_UV */
--
2.5.5
[PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system
On SGI UV system, kernel casually hang with kaslr enabled. The back trace is: kernel BUG at arch/x86/mm/init_64.c:311! invalid opcode: [#1] SMP [...] RIP: 0010:__init_extra_mapping+0x188/0x196 [...] Call Trace: init_extra_mapping_uc+0x13/0x15 map_high+0x67/0x75 map_mmioh_high_uv3+0x20a/0x219 uv_system_init_hub+0x12d9/0x1496 uv_system_init+0x27/0x29 native_smp_prepare_cpus+0x28d/0x2d8 kernel_init_freeable+0xdd/0x253 ? rest_init+0x80/0x80 kernel_init+0xe/0x110 ret_from_fork+0x2c/0x40 The root cause is that SGI UV system needs map its MMIOH region to direct mapping section and the mapping happens in rest_init(). However mm KASLR is done in kernel_randomize_memory() which is much earlier than MMIOH mapping of SGI UV and doesn't count in the MMIOH regions. When kaslr disabled, there are 64TB space for system RAM to do direct mapping. Both system RAM and SGI UV MMIOH region share this 64TB space. With kaslr enabled, mm KASLR only reserves the actual size of system RAM plus 10TB for direct mapping usage. Then later MMIOH mapping of SGI UV could go beyond the upper bound of direct mapping section to step into VMALLOC or VMEMMAP area. Then the BUG_ON() in __init_extra_mapping() will be triggered. E.g on the SGI UV3 machine where this bug is reported , there are two MMIOH regions: [1.519001] UV: Map MMIOH0_HI 0xffc - 0x1000 [1.523001] UV: Map MMIOH1_HI 0x1000 - 0x2000 They are [16TB-16G, 16TB) and [16TB, 32TB). On this machine, 512G ram are spread out to 1TB regions. Then above two SGI MMIOH regions also will be mapped into the direct mapping section. To fix it, we need check if it's SGI UV system by calling is_early_uv_system() in kernel_randomize_memory(). If yes, do not adapt the size of the direct mapping section. Do it now. Signed-off-by: Baoquan He Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Thomas Garnier Cc: Kees Cook Cc: Andrew Morton Cc: Masahiro Yamada --- arch/x86/mm/kaslr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c index aed2064..20b0456 100644 --- a/arch/x86/mm/kaslr.c +++ b/arch/x86/mm/kaslr.c @@ -27,6 +27,7 @@ #include #include #include +#include #include "mm_internal.h" @@ -123,7 +124,7 @@ void __init kernel_randomize_memory(void) CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING; /* Adapt phyiscal memory region size based on available memory */ - if (memory_tb < kaslr_regions[0].size_tb) + if (memory_tb < kaslr_regions[0].size_tb && !is_early_uv_system()) kaslr_regions[0].size_tb = memory_tb; /* Calculate entropy available between regions */ -- 2.5.5
Re: [PATCH v5 2/2] tpm: vtpm_proxy: Implement request_locality function.
On Mon, May 15, 2017 at 12:51:45PM -0400, Stefan Berger wrote:
> Implement the request_locality function. To set the locality on the
> backend we define vendor-specific TPM 1.2 and TPM 2 ordinals and send
> a command to the backend to set the locality for the next commands.
>
> To avoid recursing into requesting the locality, we set the
> TPM_TRASNMIT_RAW flag when calling tpm_trasnmit_cmd. To avoid recursing
> into TPM 2 space related commands, we set the space parameter to NULL.
>
> Signed-off-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 1 +
> drivers/char/tpm/tpm_vtpm_proxy.c | 36
> include/uapi/linux/vtpm_proxy.h | 4
> 3 files changed, 41 insertions(+)
>
> diff --git a/drivers/char/tpm/tpm-interface.c
> b/drivers/char/tpm/tpm-interface.c
> index 2eacda2..876d45f 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -537,6 +537,7 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct
> tpm_space *space,
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(tpm_transmit_cmd);
>
> #define TPM_DIGEST_SIZE 20
> #define TPM_RET_CODE_IDX 6
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c
> b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 751059d..66024bf 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -371,6 +371,41 @@ static bool vtpm_proxy_tpm_req_canceled(struct tpm_chip
> *chip, u8 status)
> return ret;
> }
>
> +static int vtpm_proxy_request_locality(struct tpm_chip *chip, int locality)
> +{
> + struct tpm_buf buf;
> + int rc;
> + const struct tpm_output_header *header;
> +
> + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> + rc = tpm_buf_init(&buf, TPM2_ST_SESSIONS,
> + TPM2_CC_SET_LOCALITY);
> + else
> + rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND,
> + TPM_ORD_SET_LOCALITY);
> + if (rc)
> + return rc;
> + tpm_buf_append_u8(&buf, locality);
> +
> + rc = tpm_transmit_cmd(chip, NULL, buf.data, tpm_buf_length(&buf), 0,
> + TPM_TRANSMIT_UNLOCKED | TPM_TRANSMIT_RAW,
> + "attempting to set locality");
> + if (rc < 0) {
> + locality = rc;
> + goto out;
> + }
> +
> + header = (const struct tpm_output_header *)buf.data;
> + rc = be32_to_cpu(header->return_code);
> + if (rc)
> + locality = -1;
> +
> +out:
> + tpm_buf_destroy(&buf);
> +
> + return locality;
> +}
> +
This looks good.
> static const struct tpm_class_ops vtpm_proxy_tpm_ops = {
> .flags = TPM_OPS_AUTO_STARTUP,
> .recv = vtpm_proxy_tpm_op_recv,
> @@ -380,6 +415,7 @@ static const struct tpm_class_ops vtpm_proxy_tpm_ops = {
> .req_complete_mask = VTPM_PROXY_REQ_COMPLETE_FLAG,
> .req_complete_val = VTPM_PROXY_REQ_COMPLETE_FLAG,
> .req_canceled = vtpm_proxy_tpm_req_canceled,
> + .request_locality = vtpm_proxy_request_locality,
> };
>
> /*
> diff --git a/include/uapi/linux/vtpm_proxy.h b/include/uapi/linux/vtpm_proxy.h
> index a69e991..58ac73c 100644
> --- a/include/uapi/linux/vtpm_proxy.h
> +++ b/include/uapi/linux/vtpm_proxy.h
> @@ -46,4 +46,8 @@ struct vtpm_proxy_new_dev {
>
> #define VTPM_PROXY_IOC_NEW_DEV _IOWR(0xa1, 0x00, struct
> vtpm_proxy_new_dev)
>
> +/* vendor specific commands to set locality */
> +#define TPM2_CC_SET_LOCALITY 0x20001000
> +#define TPM_ORD_SET_LOCALITY 0x20001000
> +
Maybe we should just have VTPM_CC_SET_LOCALITY? No reason to have TPM
version specific constant names. I wonder what would be the best range
for these CCs. Maybe 0xF0 would be better?
These are not changes that require a new patch set version but we they
need to be discussed before merging these changes.
> #endif /* _UAPI_LINUX_VTPM_PROXY_H */
> --
> 2.4.3
>
/Jarkko
Re: [PATCH v4 2/2] tpm: vtpm_proxy: Implement request_locality function.
On Mon, May 15, 2017 at 11:56:51AM -0400, Stefan Berger wrote:
> On 05/15/2017 08:41 AM, Jarkko Sakkinen wrote:
> > On Wed, May 10, 2017 at 07:54:22PM -0400, Stefan Berger wrote:
> > > Implement the request_locality function. To set the locality on the
> > > backend we define vendor-specific TPM 1.2 and TPM 2 ordinals and send
> > > a command to the backend to set the locality for the next commands.
> > >
> > > Signed-off-by: Stefan Berger
> > > ---
> > > drivers/char/tpm/tpm.h| 1 +
> > > drivers/char/tpm/tpm_vtpm_proxy.c | 34
> > > ++
> > > include/uapi/linux/vtpm_proxy.h | 5 +
> > > 3 files changed, 40 insertions(+)
> > >
> > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > > index 4b4c8de..10f0467 100644
> > > --- a/drivers/char/tpm/tpm.h
> > > +++ b/drivers/char/tpm/tpm.h
> > > @@ -527,6 +527,7 @@ enum tpm_transmit_flags {
> > > TPM_TRANSMIT_UNLOCKED = BIT(0),
> > > };
> > > +ssize_t tpm_transfer(struct tpm_chip *chip, u8 *buf, u32 count, size_t
> > > bufsiz);
> > > ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
> > >u8 *buf, size_t bufsiz, unsigned int flags);
> > > ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
> > > diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c
> > > b/drivers/char/tpm/tpm_vtpm_proxy.c
> > > index 751059d..374c4ff 100644
> > > --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> > > +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> > > @@ -371,6 +371,39 @@ static bool vtpm_proxy_tpm_req_canceled(struct
> > > tpm_chip *chip, u8 status)
> > > return ret;
> > > }
> > > +static int vtpm_proxy_request_locality(struct tpm_chip *chip, int
> > > locality)
> > > +{
> > > + struct tpm_buf buf;
> > > + int rc;
> > > + const struct tpm_output_header *header;
> > > +
> > > + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > > + rc = tpm_buf_init(&buf, TPM2_ST_SESSIONS,
> > > + TPM2_CC_SET_LOCALITY);
> > > + else
> > > + rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND,
> > > + TPM_ORD_SET_LOCALITY);
> > > + if (rc)
> > > + return rc;
> > > + tpm_buf_append_u8(&buf, locality);
> > > +
> > > + rc = tpm_transfer(chip, buf.data, tpm_buf_length(&buf), PAGE_SIZE);
> > > + if (rc < 0) {
> > > + locality = rc;
> > > + goto out;
> > > + }
> > > +
> > > + header = (const struct tpm_output_header *)buf.data;
> > > + rc = be32_to_cpu(header->return_code);
> > > + if (rc)
> > > + locality = -1;
> > > +
> > > +out:
> > > + tpm_buf_destroy(&buf);
> > > +
> > > + return locality;
> > > +}
> > > +
> > > static const struct tpm_class_ops vtpm_proxy_tpm_ops = {
> > > .flags = TPM_OPS_AUTO_STARTUP,
> > > .recv = vtpm_proxy_tpm_op_recv,
> > > @@ -380,6 +413,7 @@ static const struct tpm_class_ops vtpm_proxy_tpm_ops
> > > = {
> > > .req_complete_mask = VTPM_PROXY_REQ_COMPLETE_FLAG,
> > > .req_complete_val = VTPM_PROXY_REQ_COMPLETE_FLAG,
> > > .req_canceled = vtpm_proxy_tpm_req_canceled,
> > > + .request_locality = vtpm_proxy_request_locality,
> > > };
> > > /*
> > > diff --git a/include/uapi/linux/vtpm_proxy.h
> > > b/include/uapi/linux/vtpm_proxy.h
> > > index a69e991..6b91c2c 100644
> > > --- a/include/uapi/linux/vtpm_proxy.h
> > > +++ b/include/uapi/linux/vtpm_proxy.h
> > > @@ -46,4 +46,9 @@ struct vtpm_proxy_new_dev {
> > > #define VTPM_PROXY_IOC_NEW_DEV _IOWR(0xa1, 0x00, struct
> > > vtpm_proxy_new_dev)
> > > +/* vendor specific commands to set locality */
> > > +#define TPM2_CC_SET_LOCALITY 0x20001000
> > > +#define TPM_ORD_SET_LOCALITY 0x20001000
> > > +
> > > +
> > > #endif /* _UAPI_LINUX_VTPM_PROXY_H */
> > > --
> > > 2.4.3
> > This is a question.
> >
> > Did you have some kind of big idea with 0x20? I was just thinking
> > that one way to do this would to allocate starting from 0x.
>
> Not quite. Per TPM 1.2 and TPM 2 specs we should operate here with Vendor
> specific commands and they are identified by bit 29.
>
> Check section 17 'Ordinals':
> https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
>
> Check section 8.9 TPMA_CC:
> https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf
>
> If anything was the 'big idea' then it was the offset '0x1000' :-)
>
>Stefan
Maybe we should use have concept of driver specific commands? You could
in theory use vtpm to proxy a real chip and this would cause a potential
regression as vendor specific code might collide.
/Jarkko
Re: [PATCH v2 1/5] tpm: introduce tpm_pcr_algorithms()
On Mon, May 15, 2017 at 03:18:41PM +0200, Roberto Sassu wrote:
>
>
> On 5/15/2017 12:36 PM, Jarkko Sakkinen wrote:
> > On Fri, May 05, 2017 at 04:21:48PM +0200, Roberto Sassu wrote:
> > > This function allows TPM users to know which algorithms the TPM supports.
> > > It stores the algorithms in a static array of 'enum tpm2_algorithms',
> > > allocated by the caller. If the array is not large enough, the function
> > > returns an error. Otherwise, it returns the number of algorithms written
> > > to the array. If the TPM version is 1.2, the function writes TPM2_ALG_SHA1
> > > to first element of the array.
> > >
> > > Writing the algorithm also for TPM 1.2 has the advantage that callers
> > > can use the API, tpm_pcr_algorithms() and tpm_pcr_extend(), regardless
> > > of the TPM version.
> > >
> > > A minor change added to this patch was to make available the size of
> > > the active_banks array, member of the tpm_chip structure, outside
> > > the TPM driver. The array size (TPM_ACTIVE_BANKS_MAX) has been exported
> > > to include/linux/tpm.h.
> > >
> > > With this information, callers of tpm_pcr_algorithms() can provide
> > > a static array with enough room for all the algorithms, instead
> > > of receiving the pointer of a dynamic array that they have to free later.
> > >
> > > Signed-off-by: Roberto Sassu
> > > ---
> > > v2
> > >
> > > - tpm_pcr_algorithms() returns supported algorithms also for TPM 1.2
> > >
> > > drivers/char/tpm/tpm-interface.c | 46
> > >
> > > drivers/char/tpm/tpm.h | 13 +---
> > > include/linux/tpm.h | 19 +
> > > 3 files changed, 66 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm-interface.c
> > > b/drivers/char/tpm/tpm-interface.c
> > > index 4ed08ab..b90de3d 100644
> > > --- a/drivers/char/tpm/tpm-interface.c
> > > +++ b/drivers/char/tpm/tpm-interface.c
> > > @@ -911,6 +911,52 @@ int tpm_pcr_extend(u32 chip_num, int pcr_idx, const
> > > u8 *hash)
> > > EXPORT_SYMBOL_GPL(tpm_pcr_extend);
> > >
> > > /**
> > > + * tpm_pcr_algorithms - get TPM IDs of active PCR banks algorithms
> >
> > The grammar is incorrect here I believe. Should rather be
> >
> > "algorithms of the active PCR banks"
> >
> > And there is no such thing as "TPM ID".
> >
> > > + * @chip_num:tpm idx # or ANY
> > > + * @count: # of items in algorithms
> > > + * @algorithms: array of TPM IDs
> > > + *
> > > + * Returns < 0 on error, and the number of active PCR banks on success.
> > > + *
> > > + * TPM 1.2 has always one SHA1 bank.
> > > + */
> > > +int tpm_pcr_algorithms(u32 chip_num, int count,
> > > +enum tpm2_algorithms *algorithms)
> >unsigned int
> >
> > In addition the function name is not too greatg,
> >
> > Your syntax for return value is not correct. In addition after
> > describing the return value there should not be anything. You should
> > study
> >
> > https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt
> >
> > Better name for the function would be tpm_get_pcr_algorithms().
> >
> > > +{
> > > + struct tpm_chip *chip;
> > > + int i;
> > > +
> > > + if (count <= 0 || algorithms == NULL)
> > > + return -EINVAL;
> >
> > Is there a legal case where caller would pass these values? Now it
> > looks like that there is.
> >
> > 'count' should unsigned int and zero should be a legal value for
> > count.
>
> I wanted to avoid that a negative value returned by tpm_pcr_algorithms()
> is passed to tpm_pcr_extend() as unsigned int.
Why would you pass a negative value? I'm sorry but I have to admit tht I'm
seriously not computing your argument.
> > That said I think the whole design is wrong as you could calculate
> > array for algs only one time and pass a const reference to it on
> > request.
>
> Ok. If I understood it correctly, you are saying to pass a const
> reference of chip->active_banks. Then, I should also:
>
> - add a new field (e.g. active_banks_num) in the tpm_chip structure
> to store the number of algorithms supported by the TPM (unless,
> I should determine it every time tpm_pcr_algorithms() is called)
> - initialize chip->active_banks and chip->active_banks_num
> respectively to TPM2_ALG_SHA1 and 1 in tpm1_auto_startup()
>
> Roberto
Something along those lines.
Doing precalcuation makes the code more stable as you can only fall to
an error conditio when the driver is initialized.
/Jarkko
Linux 3.18.54
I'm announcing the release of the 3.18.54 kernel. All users of the 3.18 kernel series must upgrade. The updated 3.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm64/kernel/perf_event.c| 21 +- arch/arm64/kernel/sys.c |2 arch/x86/boot/boot.h |2 arch/x86/um/ptrace_64.c |2 drivers/hid/hid-core.c|3 drivers/infiniband/hw/mlx4/main.c |1 drivers/infiniband/ulp/ipoib/ipoib_fs.c |3 drivers/infiniband/ulp/ipoib/ipoib_main.c | 44 - drivers/infiniband/ulp/ipoib/ipoib_vlan.c |3 drivers/md/dm-era-target.c|8 drivers/md/raid1.c|2 drivers/net/ppp/ppp_generic.c |5 drivers/net/usb/cdc_ncm.c | 20 -- drivers/scsi/sg.c |8 drivers/staging/comedi/drivers/jr3_pci.c | 13 - drivers/staging/gdm724x/gdm_mux.c |3 drivers/staging/vt6656/usbpipe.c | 31 +++ drivers/target/target_core_file.c |3 drivers/tty/serial/omap-serial.c |9 - drivers/usb/core/driver.c |3 drivers/usb/core/file.c |9 - drivers/usb/core/hub.c|6 drivers/usb/host/xhci-mem.c |2 drivers/usb/misc/legousbtower.c | 37 +++- drivers/usb/misc/usbtest.c|1 drivers/usb/serial/ftdi_sio.c |1 drivers/usb/serial/ftdi_sio_ids.h |6 fs/block_dev.c| 11 - fs/ceph/xattr.c |3 fs/cifs/cifs_unicode.c|6 fs/cifs/cifs_unicode.h|5 fs/cifs/cifssmb.c |3 fs/cifs/smb2pdu.c | 14 + fs/ext4/ext4_jbd2.c |6 fs/xattr.c|2 kernel/events/core.c | 264 +++--- kernel/padata.c |2 kernel/sched/core.c |3 lib/asn1_decoder.c| 21 +- net/bluetooth/hci_sock.c |3 net/sctp/ipv6.c | 16 + net/unix/af_unix.c|7 sound/core/seq/seq_queue.c|2 sound/core/timer.c| 35 ++- 45 files changed, 481 insertions(+), 172 deletions(-) Ajay Kaher (1): USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously Andrey Ryabinin (1): fs/block_dev: always invalidate cleancache in invalidate_bdev() Ashish Kalra (1): x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup Bart Van Assche (1): target/fileio: Fix zero-length READ and WRITE handling Benjamin Tissoires (1): HID: core: prevent out-of-bound readings Björn Jacke (2): CIFS: fix mapping of SFM_SPACE and SFM_PERIOD CIFS: add misssing SFM mapping for doublequote Bjørn Mork (1): cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind Calvin Owens (1): sg: Fix double-free when drives detach during SG_IO David Howells (2): ASN.1: Fix non-match detection failure on data overrun KEYS: Fix ASN.1 indefinite length object parsing Eric Dumazet (2): ipv6: sctp: add rcu protection around np->opt ipv6: sctp: fix lockdep splat in sctp_v6_get_dst() Greg Kroah-Hartman (1): Linux 3.18.54 Guenter Roeck (1): usb: hub: Do not attempt to autosuspend disconnected devices Gustavo A. R. Silva (1): usb: misc: add missing continue in switch Ian Abbott (2): staging: comedi: jr3_pci: fix possible null pointer dereference staging: comedi: jr3_pci: cope with jiffies wraparound Jack Morgenstein (1): IB/mlx4: Fix ib device initialization error flow Jann Horn (1): sched: panic on corrupted stack end Jason A. Donenfeld (1): padata: free correct variable Johan Hovold (3): staging: gdm724x: gdm_mux: fix use-after-free on module unload serial: omap: fix runtime-pm handling on unbind serial: omap: suspend device on probe errors Kangjie Lu (3): ALSA: timer: Fix leak in SNDRV_TIMER_IOCTL_PARAMS ALSA: timer: Fix leak in events via snd_timer_user_ccallback ALSA: timer: Fix leak in events via snd_timer_user_tinterrupt Luis Henriques (1): ceph: fix memory leak in __ceph_setxattr() Lukas Czerner (1): ext4: fix potential use after free in __ext4_journal_stop Maksim Salau (1): usb: misc: legousbtowe
Re: Linux 3.18.54
diff --git a/Makefile b/Makefile
index 274ec43fc6ba..f44ed53ab175 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 18
-SUBLEVEL = 53
+SUBLEVEL = 54
EXTRAVERSION =
NAME = Diseased Newt
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index aa29ecb4f800..78a5894b1621 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -316,22 +316,31 @@ out:
}
static int
-validate_event(struct pmu_hw_events *hw_events,
- struct perf_event *event)
+validate_event(struct pmu *pmu, struct pmu_hw_events *hw_events,
+ struct perf_event *event)
{
- struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
+ struct arm_pmu *armpmu;
struct hw_perf_event fake_event = event->hw;
struct pmu *leader_pmu = event->group_leader->pmu;
if (is_software_event(event))
return 1;
+ /*
+* Reject groups spanning multiple HW PMUs (e.g. CPU + CCI). The
+* core perf code won't check that the pmu->ctx == leader->ctx
+* until after pmu->event_init(event).
+*/
+ if (event->pmu != pmu)
+ return 0;
+
if (event->pmu != leader_pmu || event->state < PERF_EVENT_STATE_OFF)
return 1;
if (event->state == PERF_EVENT_STATE_OFF && !event->attr.enable_on_exec)
return 1;
+ armpmu = to_arm_pmu(event->pmu);
return armpmu->get_event_idx(hw_events, &fake_event) >= 0;
}
@@ -349,15 +358,15 @@ validate_group(struct perf_event *event)
memset(fake_used_mask, 0, sizeof(fake_used_mask));
fake_pmu.used_mask = fake_used_mask;
- if (!validate_event(&fake_pmu, leader))
+ if (!validate_event(event->pmu, &fake_pmu, leader))
return -EINVAL;
list_for_each_entry(sibling, &leader->sibling_list, group_entry) {
- if (!validate_event(&fake_pmu, sibling))
+ if (!validate_event(event->pmu, &fake_pmu, sibling))
return -EINVAL;
}
- if (!validate_event(&fake_pmu, event))
+ if (!validate_event(event->pmu, &fake_pmu, event))
return -EINVAL;
return 0;
diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
index 3fa98ff14f0e..df20b7918854 100644
--- a/arch/arm64/kernel/sys.c
+++ b/arch/arm64/kernel/sys.c
@@ -50,7 +50,7 @@ asmlinkage long sys_mmap(unsigned long addr, unsigned long
len,
* The sys_call_table array must be 4K aligned to be accessible from
* kernel/entry.S.
*/
-void *sys_call_table[__NR_syscalls] __aligned(4096) = {
+void * const sys_call_table[__NR_syscalls] __aligned(4096) = {
[0 ... __NR_syscalls - 1] = sys_ni_syscall,
#include
};
diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index bd49ec61255c..f673f92596fa 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -16,7 +16,7 @@
#ifndef BOOT_BOOT_H
#define BOOT_BOOT_H
-#define STACK_SIZE 512 /* Minimum number of bytes for stack */
+#define STACK_SIZE 1024/* Minimum number of bytes for stack */
#ifndef __ASSEMBLY__
diff --git a/arch/x86/um/ptrace_64.c b/arch/x86/um/ptrace_64.c
index 3b52bf0b418a..b0d25e6ef464 100644
--- a/arch/x86/um/ptrace_64.c
+++ b/arch/x86/um/ptrace_64.c
@@ -120,7 +120,7 @@ int poke_user(struct task_struct *child, long addr, long
data)
else if ((addr >= offsetof(struct user, u_debugreg[0])) &&
(addr <= offsetof(struct user, u_debugreg[7]))) {
addr -= offsetof(struct user, u_debugreg[0]);
- addr = addr >> 2;
+ addr = addr >> 3;
if ((addr == 4) || (addr == 5))
return -EIO;
child->thread.arch.debugregs[addr] = data;
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 19a3a12f3257..34dda44cb910 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1213,6 +1213,7 @@ static void hid_input_field(struct hid_device *hid,
struct hid_field *field,
/* Ignore report if ErrorRollOver */
if (!(field->flags & HID_MAIN_ITEM_VARIABLE) &&
value[n] >= min && value[n] <= max &&
+ value[n] - min < field->maxusage &&
field->usage[value[n] - min].hid == HID_UP_KEYBOARD + 1)
goto exit;
}
@@ -1225,11 +1226,13 @@ static void hid_input_field(struct hid_device *hid,
struct hid_field *field,
}
if (field->value[n] >= min && field->value[n] <= max
+ && field->value[n] - min < field->maxusage
&& field->usage[field->value[n] - min].hid
&& search(value, field->value[n], count))
hid_process_event(hid, field,
&field->usage[field->value[n] - min], 0, interrupt);
if (value[n] >= min && value[n] <=
Re: Linux 4.4.69
diff --git a/Makefile b/Makefile
index e6c7990497e7..dc5df61ea4be 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 68
+SUBLEVEL = 69
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index a9b3b905e661..443db0c43d7c 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -208,9 +208,10 @@ int kvm_psci_version(struct kvm_vcpu *vcpu)
static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
{
- int ret = 1;
+ struct kvm *kvm = vcpu->kvm;
unsigned long psci_fn = vcpu_get_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
+ int ret = 1;
switch (psci_fn) {
case PSCI_0_2_FN_PSCI_VERSION:
@@ -230,7 +231,9 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
break;
case PSCI_0_2_FN_CPU_ON:
case PSCI_0_2_FN64_CPU_ON:
+ mutex_lock(&kvm->lock);
val = kvm_psci_vcpu_on(vcpu);
+ mutex_unlock(&kvm->lock);
break;
case PSCI_0_2_FN_AFFINITY_INFO:
case PSCI_0_2_FN64_AFFINITY_INFO:
@@ -279,6 +282,7 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
{
+ struct kvm *kvm = vcpu->kvm;
unsigned long psci_fn = vcpu_get_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
@@ -288,7 +292,9 @@ static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
val = PSCI_RET_SUCCESS;
break;
case KVM_PSCI_FN_CPU_ON:
+ mutex_lock(&kvm->lock);
val = kvm_psci_vcpu_on(vcpu);
+ mutex_unlock(&kvm->lock);
break;
default:
val = PSCI_RET_NOT_SUPPORTED;
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index d2650e84faf2..c2489f62c4fb 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1054,8 +1054,8 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu,
{
struct sys_reg_params params;
u32 hsr = kvm_vcpu_get_hsr(vcpu);
- int Rt = (hsr >> 5) & 0xf;
- int Rt2 = (hsr >> 10) & 0xf;
+ int Rt = (hsr >> 5) & 0x1f;
+ int Rt2 = (hsr >> 10) & 0x1f;
params.is_aarch32 = true;
params.is_32bit = false;
@@ -1106,7 +1106,7 @@ static int kvm_handle_cp_32(struct kvm_vcpu *vcpu,
{
struct sys_reg_params params;
u32 hsr = kvm_vcpu_get_hsr(vcpu);
- int Rt = (hsr >> 5) & 0xf;
+ int Rt = (hsr >> 5) & 0x1f;
params.is_aarch32 = true;
params.is_32bit = true;
diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index 9011a88353de..ed1e9206f830 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -16,7 +16,7 @@
#ifndef BOOT_BOOT_H
#define BOOT_BOOT_H
-#define STACK_SIZE 512 /* Minimum number of bytes for stack */
+#define STACK_SIZE 1024/* Minimum number of bytes for stack */
#ifndef __ASSEMBLY__
diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h
index bd8ce6bcdfc9..6503526d7b24 100644
--- a/arch/x86/include/asm/pmem.h
+++ b/arch/x86/include/asm/pmem.h
@@ -122,7 +122,7 @@ static inline size_t arch_copy_from_iter_pmem(void __pmem
*addr, size_t bytes,
if (bytes < 8) {
if (!IS_ALIGNED(dest, 4) || (bytes != 4))
- __arch_wb_cache_pmem(addr, 1);
+ __arch_wb_cache_pmem(addr, bytes);
} else {
if (!IS_ALIGNED(dest, 8)) {
dest = ALIGN(dest,
boot_cpu_data.x86_clflush_size);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e75095fa414e..281899da19d4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2960,6 +2960,12 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_events(struct
kvm_vcpu *vcpu,
| KVM_VCPUEVENT_VALID_SMM))
return -EINVAL;
+ /* INITs are latched while in SMM */
+ if (events->flags & KVM_VCPUEVENT_VALID_SMM &&
+ (events->smi.smm || events->smi.pending) &&
+ vcpu->arch.mp_state == KVM_MP_STATE_INIT_RECEIVED)
+ return -EINVAL;
+
process_nmi(vcpu);
vcpu->arch.exception.pending = events->exception.injected;
vcpu->arch.exception.nr = events->exception.nr;
@@ -6993,6 +6999,12 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu
*vcpu,
mp_state->mp_state != KVM_MP_STATE_RUNNABLE)
return -EINVAL;
+ /* INITs are latched while in SMM */
+ if ((is_smm(vcpu) || vcpu->arch.smi_pending) &&
+ (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED ||
+mp_state->mp_state == KVM_MP_STATE_INIT_RECEIVED))
+ return -EINVAL;
+
if (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED) {
vcpu->arch.mp_state = KVM_MP_STATE_INIT_RECEIVED;
set_bit(KVM_API
Linux 4.4.69
I'm announcing the release of the 4.4.69 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/kvm/psci.c |8 arch/arm64/kvm/sys_regs.c |6 arch/x86/boot/boot.h |2 arch/x86/include/asm/pmem.h |2 arch/x86/kvm/x86.c| 12 + arch/x86/um/ptrace_64.c |2 arch/x86/xen/mmu.c|7 block/blk-integrity.c |3 crypto/algif_aead.c | 157 +- drivers/Makefile |1 drivers/bluetooth/hci_bcm.c |5 drivers/bluetooth/hci_intel.c | 13 + drivers/char/ipmi/ipmi_ssif.c |4 drivers/infiniband/core/sysfs.c |2 drivers/infiniband/hw/mlx4/main.c |1 drivers/infiniband/hw/mlx4/mcg.c |3 drivers/infiniband/ulp/ipoib/ipoib_fs.c |3 drivers/infiniband/ulp/ipoib/ipoib_main.c | 44 - drivers/infiniband/ulp/ipoib/ipoib_vlan.c |3 drivers/md/dm-era-target.c|8 drivers/net/wireless/ath/ath10k/mac.c |7 drivers/net/wireless/ath/ath9k/htc_drv_main.c |7 drivers/net/wireless/ath/ath9k/main.c |8 drivers/net/wireless/ath/carl9170/main.c |8 drivers/net/wireless/ath/wcn36xx/main.c |8 drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c |8 drivers/net/wireless/cw1200/sta.c |4 drivers/net/wireless/cw1200/sta.h |4 drivers/net/wireless/iwlegacy/4965-mac.c |8 drivers/net/wireless/iwlegacy/4965.h |4 drivers/net/wireless/iwlwifi/dvm/mac80211.c |9 - drivers/net/wireless/iwlwifi/mvm/mac80211.c |9 - drivers/net/wireless/mac80211_hwsim.c |8 drivers/net/wireless/mediatek/mt7601u/main.c |8 drivers/net/wireless/mwl8k.c | 10 - drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c |6 drivers/net/wireless/realtek/rtlwifi/core.c |8 drivers/net/wireless/rsi/rsi_91x_mac80211.c | 19 -- drivers/net/wireless/rt2x00/rt2800lib.c |7 drivers/net/wireless/rt2x00/rt2800lib.h |4 drivers/net/wireless/ti/wl18xx/event.c| 28 +++ drivers/net/wireless/ti/wl18xx/event.h|1 drivers/net/wireless/ti/wl18xx/main.c |3 drivers/net/wireless/ti/wlcore/acx.c |5 drivers/net/wireless/ti/wlcore/acx.h |3 drivers/net/wireless/ti/wlcore/main.c | 14 + drivers/staging/comedi/drivers/jr3_pci.c | 13 - drivers/staging/gdm724x/gdm_mux.c |4 drivers/staging/vt6656/usbpipe.c | 31 +++ drivers/target/iscsi/iscsi_target.c |1 drivers/target/iscsi/iscsi_target_configfs.c | 30 --- drivers/target/iscsi/iscsi_target_login.c |1 drivers/target/iscsi/iscsi_target_tpg.c | 10 - drivers/target/iscsi/iscsi_target_tpg.h |2 drivers/target/target_core_file.c |3 drivers/target/target_core_sbc.c |5 drivers/target/target_core_tpg.c | 152 + drivers/target/target_core_transport.c|4 drivers/tty/pty.c |7 drivers/tty/serial/omap-serial.c |9 - drivers/tty/serial/samsung.c |9 - drivers/usb/core/driver.c | 21 ++ drivers/usb/core/file.c |9 - drivers/usb/core/hub.c| 11 + drivers/usb/host/xhci-mem.c |2 drivers/usb/misc/usbtest.c|1 drivers/usb/serial/ftdi_sio.c |1 drivers/usb/serial/ftdi_sio_ids.h |6 drivers/vfio/vfio_iommu_type1.c | 102 --- fs/block_dev.c| 11 - fs/ceph/xattr.c
Linux 4.9.29
I'm announcing the release of the 4.9.29 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/kvm/psci.c |8 + arch/arm64/include/asm/kvm_emulate.h |6 + arch/arm64/kvm/sys_regs.c|8 - arch/powerpc/kernel/nvram_64.c |1 arch/x86/boot/boot.h |2 arch/x86/events/intel/rapl.c |2 arch/x86/include/asm/pmem.h |2 arch/x86/kvm/x86.c | 12 ++ arch/x86/um/ptrace_64.c |2 arch/x86/xen/mmu.c |7 - block/blk-integrity.c|3 crypto/algif_aead.c | 157 +-- drivers/Makefile |1 drivers/bluetooth/hci_bcm.c |5 drivers/bluetooth/hci_intel.c| 13 ++ drivers/char/ipmi/ipmi_ssif.c|4 drivers/crypto/ccp/ccp-dev-v3.c | 120 drivers/crypto/ccp/ccp-dev-v5.c | 114 +++ drivers/crypto/ccp/ccp-dev.h |8 - drivers/crypto/ccp/ccp-pci.c |2 drivers/dax/dax.c| 15 +- drivers/infiniband/core/sysfs.c |2 drivers/infiniband/core/verbs.c |8 + drivers/infiniband/hw/hfi1/ruc.c | 26 ++-- drivers/infiniband/hw/hfi1/verbs.c |4 drivers/infiniband/hw/hfi1/verbs.h |6 - drivers/infiniband/hw/mlx4/main.c|1 drivers/infiniband/hw/mlx4/mcg.c |3 drivers/infiniband/ulp/ipoib/ipoib_fs.c |3 drivers/infiniband/ulp/ipoib/ipoib_main.c| 44 ++- drivers/infiniband/ulp/ipoib/ipoib_vlan.c|3 drivers/md/dm-era-target.c |8 - drivers/md/dm-rq.c |6 - drivers/md/dm-thin.c |1 drivers/nvdimm/pfn_devs.c|6 - drivers/nvdimm/pmem.c| 37 -- drivers/nvdimm/region_devs.c | 11 + drivers/staging/comedi/drivers/jr3_pci.c | 13 +- drivers/staging/gdm724x/gdm_mux.c|3 drivers/staging/vt6656/usbpipe.c | 31 - drivers/target/iscsi/iscsi_target.c |1 drivers/target/iscsi/iscsi_target_configfs.c |1 drivers/target/iscsi/iscsi_target_login.c|1 drivers/target/target_core_file.c|3 drivers/target/target_core_sbc.c |5 drivers/tty/pty.c|7 - drivers/tty/serial/omap-serial.c |9 + drivers/tty/serial/samsung.c |9 - drivers/usb/class/cdc-wdm.c | 103 - drivers/usb/core/driver.c| 21 +++ drivers/usb/core/file.c |9 + drivers/usb/core/hub.c | 11 + drivers/usb/gadget/Kconfig |1 drivers/usb/host/xhci-mem.c | 13 ++ drivers/usb/host/xhci-pci.c |3 drivers/usb/host/xhci.h |1 drivers/usb/misc/usbtest.c |1 drivers/usb/serial/ftdi_sio.c|1 drivers/usb/serial/ftdi_sio_ids.h|6 + drivers/vfio/vfio_iommu_type1.c | 102 +++-- fs/block_dev.c | 11 - fs/ceph/xattr.c |3 fs/cifs/cifs_unicode.c |6 + fs/cifs/cifs_unicode.h |5 fs/cifs/cifsfs.c | 15 ++ fs/cifs/cifsglob.h |1 fs/cifs/cifssmb.c|3 fs/cifs/connect.c| 14 +- fs/cifs/ioctl.c |4 fs/cifs/misc.c |2 fs/cifs/smb2misc.c |5 fs/cifs/smb2ops.c|1 fs/cifs/smb2pdu.c| 14 +- fs/crypto/policy.c | 87 +++--- fs/ext4/inode.c |5 fs/orangefs/inode.c |3 fs/orangefs/namei.c |2 fs/orangefs/xattr.c | 26 +--- fs/pstore/platform.c | 10 + fs/xattr.c |2 kernel/padata.c
Linux 4.10.17
-- Note, this is the LAST 4.10.y kernel to be released, it is now end-of-life. You must move to the 4.11.y kernel series now. -- I'm announcing the release of the 4.10.17 kernel. All users of the 4.10 kernel series must upgrade. The updated 4.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.10.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/kvm/psci.c |8 + arch/arm64/include/asm/kvm_emulate.h |6 + arch/arm64/kvm/sys_regs.c|8 - arch/powerpc/kernel/nvram_64.c |1 arch/x86/boot/boot.h |2 arch/x86/events/intel/rapl.c |2 arch/x86/include/asm/pmem.h |2 arch/x86/kvm/x86.c | 12 ++ arch/x86/um/ptrace_64.c |2 arch/x86/xen/mmu.c |7 - block/blk-integrity.c|3 crypto/algif_aead.c | 157 +-- drivers/Makefile |1 drivers/bluetooth/hci_bcm.c |5 drivers/bluetooth/hci_intel.c| 13 ++ drivers/char/ipmi/ipmi_ssif.c|4 drivers/crypto/ccp/ccp-dev-v3.c | 120 drivers/crypto/ccp/ccp-dev-v5.c | 114 +++ drivers/crypto/ccp/ccp-dev.h |8 - drivers/crypto/ccp/ccp-pci.c |2 drivers/crypto/s5p-sss.c |5 drivers/dax/dax.c| 55 +++-- drivers/infiniband/core/sysfs.c |2 drivers/infiniband/core/verbs.c |8 + drivers/infiniband/hw/hfi1/ruc.c | 26 ++-- drivers/infiniband/hw/hfi1/verbs.c |4 drivers/infiniband/hw/hfi1/verbs.h |6 - drivers/infiniband/hw/mlx4/main.c|1 drivers/infiniband/hw/mlx4/mcg.c |3 drivers/infiniband/ulp/ipoib/ipoib_fs.c |3 drivers/infiniband/ulp/ipoib/ipoib_main.c| 44 ++- drivers/infiniband/ulp/ipoib/ipoib_vlan.c|3 drivers/md/dm-crypt.c|8 + drivers/md/dm-era-target.c |8 - drivers/md/dm-rq.c |6 - drivers/md/dm-thin.c |1 drivers/md/raid1.c |2 drivers/nvdimm/btt_devs.c|2 drivers/nvdimm/claim.c | 23 ++- drivers/nvdimm/dax_devs.c|2 drivers/nvdimm/pfn_devs.c|8 - drivers/nvdimm/pmem.c| 37 -- drivers/nvdimm/region_devs.c | 11 + drivers/staging/comedi/drivers/jr3_pci.c | 13 +- drivers/staging/gdm724x/gdm_mux.c|3 drivers/staging/vt6656/usbpipe.c | 31 - drivers/staging/wilc1000/linux_wlan.c|3 drivers/target/iscsi/iscsi_target.c |1 drivers/target/iscsi/iscsi_target_configfs.c |1 drivers/target/iscsi/iscsi_target_login.c|1 drivers/target/target_core_file.c|3 drivers/target/target_core_sbc.c |5 drivers/tty/pty.c|7 - drivers/tty/serial/omap-serial.c |9 + drivers/tty/serial/samsung.c |9 - drivers/usb/class/cdc-wdm.c | 103 - drivers/usb/core/driver.c| 21 +++ drivers/usb/core/file.c |9 + drivers/usb/core/hub.c | 11 + drivers/usb/gadget/Kconfig |1 drivers/usb/host/xhci-mem.c | 13 ++ drivers/usb/host/xhci-pci.c |3 drivers/usb/host/xhci.h |1 drivers/usb/misc/usbtest.c |1 drivers/usb/serial/ftdi_sio.c|1 drivers/usb/serial/ftdi_sio_ids.h|6 + drivers/vfio/vfio_iommu_type1.c | 110 -- fs/block_dev.c | 11 - fs/ceph/xattr.c |3 fs/cifs/cifs_unicode.c |6 + fs/cifs/cifs_unicode.h |5 fs/cifs/cifsfs.c | 15 ++ fs/cifs/cifsglob.h |1 fs/cifs/cifssmb.c|3 fs/cifs/connect.c| 14 +- fs/cifs/ioctl.c |4 fs/cifs/misc.c |2 fs/cifs/smb2misc.c
Re: Linux 4.9.29
diff --git a/Makefile b/Makefile
index 9460a63087b8..c12e501a18b8 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 28
+SUBLEVEL = 29
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index c2b131527a64..a08d7a93aebb 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -208,9 +208,10 @@ int kvm_psci_version(struct kvm_vcpu *vcpu)
static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
{
- int ret = 1;
+ struct kvm *kvm = vcpu->kvm;
unsigned long psci_fn = vcpu_get_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
+ int ret = 1;
switch (psci_fn) {
case PSCI_0_2_FN_PSCI_VERSION:
@@ -230,7 +231,9 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
break;
case PSCI_0_2_FN_CPU_ON:
case PSCI_0_2_FN64_CPU_ON:
+ mutex_lock(&kvm->lock);
val = kvm_psci_vcpu_on(vcpu);
+ mutex_unlock(&kvm->lock);
break;
case PSCI_0_2_FN_AFFINITY_INFO:
case PSCI_0_2_FN64_AFFINITY_INFO:
@@ -279,6 +282,7 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
{
+ struct kvm *kvm = vcpu->kvm;
unsigned long psci_fn = vcpu_get_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
@@ -288,7 +292,9 @@ static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
val = PSCI_RET_SUCCESS;
break;
case KVM_PSCI_FN_CPU_ON:
+ mutex_lock(&kvm->lock);
val = kvm_psci_vcpu_on(vcpu);
+ mutex_unlock(&kvm->lock);
break;
default:
val = PSCI_RET_NOT_SUPPORTED;
diff --git a/arch/arm64/include/asm/kvm_emulate.h
b/arch/arm64/include/asm/kvm_emulate.h
index f5ea0ba70f07..fe39e6841326 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -240,6 +240,12 @@ static inline u8 kvm_vcpu_trap_get_fault_type(const struct
kvm_vcpu *vcpu)
return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC_TYPE;
}
+static inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
+{
+ u32 esr = kvm_vcpu_get_hsr(vcpu);
+ return (esr & ESR_ELx_SYS64_ISS_RT_MASK) >> ESR_ELx_SYS64_ISS_RT_SHIFT;
+}
+
static inline unsigned long kvm_vcpu_get_mpidr_aff(struct kvm_vcpu *vcpu)
{
return vcpu_sys_reg(vcpu, MPIDR_EL1) & MPIDR_HWID_BITMASK;
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 87e7e6608cd8..7cee552ce0bf 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1573,8 +1573,8 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu,
{
struct sys_reg_params params;
u32 hsr = kvm_vcpu_get_hsr(vcpu);
- int Rt = (hsr >> 5) & 0xf;
- int Rt2 = (hsr >> 10) & 0xf;
+ int Rt = kvm_vcpu_sys_get_rt(vcpu);
+ int Rt2 = (hsr >> 10) & 0x1f;
params.is_aarch32 = true;
params.is_32bit = false;
@@ -1625,7 +1625,7 @@ static int kvm_handle_cp_32(struct kvm_vcpu *vcpu,
{
struct sys_reg_params params;
u32 hsr = kvm_vcpu_get_hsr(vcpu);
- int Rt = (hsr >> 5) & 0xf;
+ int Rt = kvm_vcpu_sys_get_rt(vcpu);
params.is_aarch32 = true;
params.is_32bit = true;
@@ -1740,7 +1740,7 @@ int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct
kvm_run *run)
{
struct sys_reg_params params;
unsigned long esr = kvm_vcpu_get_hsr(vcpu);
- int Rt = (esr >> 5) & 0x1f;
+ int Rt = kvm_vcpu_sys_get_rt(vcpu);
int ret;
trace_kvm_handle_sys_reg(esr);
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index 34d2c595de23..73622673eee3 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -561,6 +561,7 @@ static ssize_t nvram_pstore_read(u64 *id, enum
pstore_type_id *type,
static struct pstore_info nvram_pstore_info = {
.owner = THIS_MODULE,
.name = "nvram",
+ .flags = PSTORE_FLAGS_DMESG,
.open = nvram_pstore_open,
.read = nvram_pstore_read,
.write = nvram_pstore_write,
diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index e5612f3e3b57..d7ac721a8a96 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -16,7 +16,7 @@
#ifndef BOOT_BOOT_H
#define BOOT_BOOT_H
-#define STACK_SIZE 512 /* Minimum number of bytes for stack */
+#define STACK_SIZE 1024/* Minimum number of bytes for stack */
#ifndef __ASSEMBLY__
diff --git a/arch/x86/events/intel/rapl.c b/arch/x86/events/intel/rapl.c
index 0a535cea8ff3..8b902b67342a 100644
--- a/arch/x86/events/intel/rapl.c
+++ b/arch/x86/events/intel/rapl.c
@@ -759,7 +759,7 @@ static const struct x86_cpu_id rapl_cpu_match[] __initconst
= {
X86_RAPL_MODEL_MATCH(INTEL_FAM6_BROADWELL_CORE, hsw_rapl_init),
X86_RAPL_MODEL_MATCH(INTEL_FAM6_BROADWELL_GT3E, hsw_rapl_init),
-
Re: Linux 4.10.17
diff --git a/Makefile b/Makefile
index e3e60e71fa78..2e8b04bd180e 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 10
-SUBLEVEL = 16
+SUBLEVEL = 17
EXTRAVERSION =
NAME = Fearless Coyote
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index c2b131527a64..a08d7a93aebb 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -208,9 +208,10 @@ int kvm_psci_version(struct kvm_vcpu *vcpu)
static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
{
- int ret = 1;
+ struct kvm *kvm = vcpu->kvm;
unsigned long psci_fn = vcpu_get_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
+ int ret = 1;
switch (psci_fn) {
case PSCI_0_2_FN_PSCI_VERSION:
@@ -230,7 +231,9 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
break;
case PSCI_0_2_FN_CPU_ON:
case PSCI_0_2_FN64_CPU_ON:
+ mutex_lock(&kvm->lock);
val = kvm_psci_vcpu_on(vcpu);
+ mutex_unlock(&kvm->lock);
break;
case PSCI_0_2_FN_AFFINITY_INFO:
case PSCI_0_2_FN64_AFFINITY_INFO:
@@ -279,6 +282,7 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
{
+ struct kvm *kvm = vcpu->kvm;
unsigned long psci_fn = vcpu_get_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
@@ -288,7 +292,9 @@ static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
val = PSCI_RET_SUCCESS;
break;
case KVM_PSCI_FN_CPU_ON:
+ mutex_lock(&kvm->lock);
val = kvm_psci_vcpu_on(vcpu);
+ mutex_unlock(&kvm->lock);
break;
default:
val = PSCI_RET_NOT_SUPPORTED;
diff --git a/arch/arm64/include/asm/kvm_emulate.h
b/arch/arm64/include/asm/kvm_emulate.h
index f5ea0ba70f07..fe39e6841326 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -240,6 +240,12 @@ static inline u8 kvm_vcpu_trap_get_fault_type(const struct
kvm_vcpu *vcpu)
return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC_TYPE;
}
+static inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
+{
+ u32 esr = kvm_vcpu_get_hsr(vcpu);
+ return (esr & ESR_ELx_SYS64_ISS_RT_MASK) >> ESR_ELx_SYS64_ISS_RT_SHIFT;
+}
+
static inline unsigned long kvm_vcpu_get_mpidr_aff(struct kvm_vcpu *vcpu)
{
return vcpu_sys_reg(vcpu, MPIDR_EL1) & MPIDR_HWID_BITMASK;
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 87e7e6608cd8..7cee552ce0bf 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1573,8 +1573,8 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu,
{
struct sys_reg_params params;
u32 hsr = kvm_vcpu_get_hsr(vcpu);
- int Rt = (hsr >> 5) & 0xf;
- int Rt2 = (hsr >> 10) & 0xf;
+ int Rt = kvm_vcpu_sys_get_rt(vcpu);
+ int Rt2 = (hsr >> 10) & 0x1f;
params.is_aarch32 = true;
params.is_32bit = false;
@@ -1625,7 +1625,7 @@ static int kvm_handle_cp_32(struct kvm_vcpu *vcpu,
{
struct sys_reg_params params;
u32 hsr = kvm_vcpu_get_hsr(vcpu);
- int Rt = (hsr >> 5) & 0xf;
+ int Rt = kvm_vcpu_sys_get_rt(vcpu);
params.is_aarch32 = true;
params.is_32bit = true;
@@ -1740,7 +1740,7 @@ int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct
kvm_run *run)
{
struct sys_reg_params params;
unsigned long esr = kvm_vcpu_get_hsr(vcpu);
- int Rt = (esr >> 5) & 0x1f;
+ int Rt = kvm_vcpu_sys_get_rt(vcpu);
int ret;
trace_kvm_handle_sys_reg(esr);
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index d5e2b8309939..021db31b40ba 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -561,6 +561,7 @@ static ssize_t nvram_pstore_read(u64 *id, enum
pstore_type_id *type,
static struct pstore_info nvram_pstore_info = {
.owner = THIS_MODULE,
.name = "nvram",
+ .flags = PSTORE_FLAGS_DMESG,
.open = nvram_pstore_open,
.read = nvram_pstore_read,
.write = nvram_pstore_write,
diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index e5612f3e3b57..d7ac721a8a96 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -16,7 +16,7 @@
#ifndef BOOT_BOOT_H
#define BOOT_BOOT_H
-#define STACK_SIZE 512 /* Minimum number of bytes for stack */
+#define STACK_SIZE 1024/* Minimum number of bytes for stack */
#ifndef __ASSEMBLY__
diff --git a/arch/x86/events/intel/rapl.c b/arch/x86/events/intel/rapl.c
index 22ef4f72cf32..d7176ea4812c 100644
--- a/arch/x86/events/intel/rapl.c
+++ b/arch/x86/events/intel/rapl.c
@@ -761,7 +761,7 @@ static const struct x86_cpu_id rapl_cpu_match[] __initconst
= {
X86_RAPL_MODEL_MATCH(INTEL_FAM6_BROADWELL_CORE, hsw_rapl_init),
X86_RAPL_MODEL_MATCH(INTEL_FAM6_BROADWELL_GT3E, hsw_rapl_init),
-
Linux 4.11.2
I'm announcing the release of the 4.11.2 kernel. All users of the 4.11 kernel series must upgrade. The updated 4.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.11.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/kvm/psci.c |8 + arch/arm64/include/asm/kvm_emulate.h |6 + arch/arm64/kvm/sys_regs.c|8 - arch/powerpc/kernel/nvram_64.c |1 arch/x86/boot/boot.h |2 arch/x86/events/intel/rapl.c |2 arch/x86/include/asm/pmem.h |2 arch/x86/kvm/lapic.c | 22 ++- arch/x86/kvm/x86.c | 53 + arch/x86/um/ptrace_64.c |2 arch/x86/xen/mmu.c |7 - block/blk-integrity.c|3 crypto/algif_aead.c | 157 +-- drivers/Makefile |1 drivers/ata/libata-scsi.c|8 + drivers/bluetooth/hci_bcm.c |5 drivers/bluetooth/hci_intel.c| 13 ++ drivers/char/ipmi/ipmi_ssif.c|4 drivers/crypto/ccp/ccp-dev-v3.c | 120 drivers/crypto/ccp/ccp-dev-v5.c | 114 +++ drivers/crypto/ccp/ccp-dev.h |8 - drivers/crypto/ccp/ccp-pci.c |2 drivers/crypto/s5p-sss.c |5 drivers/dax/dax.c| 55 +++-- drivers/infiniband/core/device.c | 33 +++-- drivers/infiniband/core/sysfs.c |2 drivers/infiniband/core/verbs.c |8 + drivers/infiniband/hw/hfi1/ruc.c | 26 ++-- drivers/infiniband/hw/hfi1/verbs.c |4 drivers/infiniband/hw/hfi1/verbs.h |6 - drivers/infiniband/hw/mlx4/main.c|1 drivers/infiniband/hw/mlx4/mcg.c |3 drivers/infiniband/ulp/ipoib/ipoib_fs.c |3 drivers/infiniband/ulp/ipoib/ipoib_main.c| 44 ++- drivers/infiniband/ulp/ipoib/ipoib_vlan.c|3 drivers/md/dm-crypt.c|8 + drivers/md/dm-era-target.c |8 - drivers/md/dm-rq.c |6 - drivers/md/dm-thin.c |1 drivers/md/raid1.c |2 drivers/nvdimm/btt_devs.c|2 drivers/nvdimm/claim.c | 23 ++- drivers/nvdimm/dax_devs.c|2 drivers/nvdimm/pfn_devs.c|8 - drivers/nvdimm/pmem.c| 37 -- drivers/nvdimm/region_devs.c | 11 + drivers/staging/comedi/drivers/jr3_pci.c | 13 +- drivers/staging/gdm724x/gdm_mux.c|3 drivers/staging/media/lirc/lirc_sir.c| 20 +-- drivers/staging/vt6656/usbpipe.c | 31 - drivers/staging/wilc1000/linux_wlan.c|3 drivers/target/iscsi/iscsi_target.c |1 drivers/target/iscsi/iscsi_target_configfs.c |1 drivers/target/iscsi/iscsi_target_login.c|1 drivers/target/target_core_file.c|3 drivers/target/target_core_sbc.c |5 drivers/tty/pty.c|7 - drivers/tty/serial/amba-pl011.c | 31 +++-- drivers/tty/serial/omap-serial.c |9 + drivers/tty/serial/samsung.c | 39 -- drivers/usb/class/cdc-wdm.c | 103 - drivers/usb/core/driver.c| 21 +++ drivers/usb/core/file.c |9 + drivers/usb/core/hub.c | 11 + drivers/usb/gadget/Kconfig |1 drivers/usb/host/xhci-mem.c | 13 ++ drivers/usb/host/xhci-pci.c |3 drivers/usb/host/xhci.h |1 drivers/usb/misc/usbtest.c |1 drivers/usb/serial/ftdi_sio.c|1 drivers/usb/serial/ftdi_sio_ids.h|6 + drivers/vfio/vfio_iommu_type1.c | 110 -- fs/block_dev.c | 11 - fs/ceph/xattr.c |3 fs/cifs/cifs_unicode.c |6 + fs/cifs/cifs_unicode.h |5 fs/cifs/cifsfs.c | 15 ++ fs/cifs/cifsglob.h |1 fs/cifs/cifssmb.c|3 fs/cifs/connect.c| 14 +- fs/cifs
[PATCH] input: move gpio mouse to managed api
Signed-off-by: Bram Vlerick
---
drivers/input/mouse/gpio_mouse.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/input/mouse/gpio_mouse.c b/drivers/input/mouse/gpio_mouse.c
index ced07391304b..2fc8ddaf0175 100644
--- a/drivers/input/mouse/gpio_mouse.c
+++ b/drivers/input/mouse/gpio_mouse.c
@@ -93,7 +93,7 @@ static int gpio_mouse_probe(struct platform_device *pdev)
}
}
- input_poll = input_allocate_polled_device();
+ input_poll = devm_input_allocate_polled_device(&pdev->dev);
if (!input_poll) {
dev_err(&pdev->dev, "not enough memory for input device\n");
error = -ENOMEM;
@@ -124,7 +124,7 @@ static int gpio_mouse_probe(struct platform_device *pdev)
error = input_register_polled_device(input_poll);
if (error) {
dev_err(&pdev->dev, "could not register input device\n");
- goto out_free_polldev;
+ goto out_free_gpios;
}
dev_dbg(&pdev->dev, "%d ms scan time, buttons: %s%s%s\n",
@@ -135,9 +135,6 @@ static int gpio_mouse_probe(struct platform_device *pdev)
return 0;
- out_free_polldev:
- input_free_polled_device(input_poll);
-
out_free_gpios:
while (--i >= 0) {
pin = pdata->pins[i];
@@ -155,7 +152,6 @@ static int gpio_mouse_remove(struct platform_device *pdev)
int pin, i;
input_unregister_polled_device(input);
- input_free_polled_device(input);
for (i = 0; i < GPIO_MOUSE_PIN_MAX; i++) {
pin = pdata->pins[i];
--
2.12.2
Re: [PATCH v2 00/18] ARM64: meson: DT cleanups
Hi Kevin, Am 18.05.2017 um 00:34 schrieb Kevin Hilman: > Andreas Färber writes: >> Am 15.05.2017 um 10:16 schrieb Neil Armstrong: >>> It's not perfect, but now it's done, live with it, this has already been >>> discussed. >> >> No. >> >> Copy&pasting your comment N times does not make it any more valid. My >> files, my rules - I insist on vega-s95, gxbb and gx, which you guys >> refactored out from my gxbb, to be tidy. > > hmm, "my files, my rules, ... my gxbb" > > Very interesting perspective, but sorry, these do not belong to you. > They belong to the kernel community. You can insist if you like, but we > do not make decisions just because someone says "mine". Again, the > confrontaional tone is not helpful to the dialogue. We can certainly argue who started which tone here. From my perspective I kindly asked Jerome to fix his node order on IRC, he said okay, but neither he nor any of you ever sent such patches. (This was back when we had an actual mismerge.) Weeks later I grudgingly sent the v1 cleanup series myself, but instead of thanking me for doing "your" work, I was greeted with unfriendly opposition and - yes, frustratingly is a word here - put my efforts elsewhere. Neil's actions - who is neither author nor maintainer here - of copying an opinionated personal and partially wrong statement into a dozen neutral patches was highly offensive to me and further escalated things. Stating his opinion, which he is welcome to do, once would has sufficed. Also what this "my" is about - and that should give you thought - is that you guys added nodes to the Vega .dtsi file without adding any BayLibre or other copyright. To someone downloading a tarball without git history, that makes it look as if _I_ misordered those nodes in the file that carries my name. So I would kindly suggest that you add your copyright when making non-trivial additions. Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH] slub/memcg: Cure the brainless abuse of sysfs attributes
On Sat, May 20, 2017 at 12:52:03PM +0200, Thomas Gleixner wrote: > This should be rewritten proper by adding a propagate() callback to those > slub_attributes which must be propagated and avoid that insane conversion > to and from ASCII Exactly.. >, but that's too large for a hot fix. What made this such a hot fix? Looks like this crap has been in for quite a while.
Re: [PATCH v2 1/5] tpm: introduce tpm_pcr_algorithms()
On Wed, May 17, 2017 at 10:42:35AM +0200, Roberto Sassu wrote:
> On 5/15/2017 3:18 PM, Roberto Sassu wrote:
> >
> >
> > On 5/15/2017 12:36 PM, Jarkko Sakkinen wrote:
> > > On Fri, May 05, 2017 at 04:21:48PM +0200, Roberto Sassu wrote:
> > > > This function allows TPM users to know which algorithms the TPM
> > > > supports.
> > > > It stores the algorithms in a static array of 'enum tpm2_algorithms',
> > > > allocated by the caller. If the array is not large enough, the function
> > > > returns an error. Otherwise, it returns the number of algorithms written
> > > > to the array. If the TPM version is 1.2, the function writes
> > > > TPM2_ALG_SHA1
> > > > to first element of the array.
> > > >
> > > > Writing the algorithm also for TPM 1.2 has the advantage that callers
> > > > can use the API, tpm_pcr_algorithms() and tpm_pcr_extend(), regardless
> > > > of the TPM version.
> > > >
> > > > A minor change added to this patch was to make available the size of
> > > > the active_banks array, member of the tpm_chip structure, outside
> > > > the TPM driver. The array size (TPM_ACTIVE_BANKS_MAX) has been exported
> > > > to include/linux/tpm.h.
> > > >
> > > > With this information, callers of tpm_pcr_algorithms() can provide
> > > > a static array with enough room for all the algorithms, instead
> > > > of receiving the pointer of a dynamic array that they have to free
> > > > later.
> > > >
> > > > Signed-off-by: Roberto Sassu
> > > > ---
> > > > v2
> > > >
> > > > - tpm_pcr_algorithms() returns supported algorithms also for TPM 1.2
> > > >
> > > > drivers/char/tpm/tpm-interface.c | 46
> > > >
> > > > drivers/char/tpm/tpm.h | 13 +---
> > > > include/linux/tpm.h | 19 +
> > > > 3 files changed, 66 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/drivers/char/tpm/tpm-interface.c
> > > > b/drivers/char/tpm/tpm-interface.c
> > > > index 4ed08ab..b90de3d 100644
> > > > --- a/drivers/char/tpm/tpm-interface.c
> > > > +++ b/drivers/char/tpm/tpm-interface.c
> > > > @@ -911,6 +911,52 @@ int tpm_pcr_extend(u32 chip_num, int pcr_idx,
> > > > const u8 *hash)
> > > > EXPORT_SYMBOL_GPL(tpm_pcr_extend);
> > > >
> > > > /**
> > > > + * tpm_pcr_algorithms - get TPM IDs of active PCR banks algorithms
> > >
> > > The grammar is incorrect here I believe. Should rather be
> > >
> > > "algorithms of the active PCR banks"
> > >
> > > And there is no such thing as "TPM ID".
> > >
> > > > + * @chip_num:tpm idx # or ANY
> > > > + * @count:# of items in algorithms
> > > > + * @algorithms:array of TPM IDs
> > > > + *
> > > > + * Returns < 0 on error, and the number of active PCR banks on success.
> > > > + *
> > > > + * TPM 1.2 has always one SHA1 bank.
> > > > + */
> > > > +int tpm_pcr_algorithms(u32 chip_num, int count,
> > > > + enum tpm2_algorithms *algorithms)
> > >unsigned int
> > >
> > > In addition the function name is not too greatg,
> > >
> > > Your syntax for return value is not correct. In addition after
> > > describing the return value there should not be anything. You should
> > > study
> > >
> > > https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt
> > >
> > > Better name for the function would be tpm_get_pcr_algorithms().
> > >
> > > > +{
> > > > +struct tpm_chip *chip;
> > > > +int i;
> > > > +
> > > > +if (count <= 0 || algorithms == NULL)
> > > > +return -EINVAL;
> > >
> > > Is there a legal case where caller would pass these values? Now it
> > > looks like that there is.
> > >
> > > 'count' should unsigned int and zero should be a legal value for
> > > count.
> >
> > I wanted to avoid that a negative value returned by tpm_pcr_algorithms()
> > is passed to tpm_pcr_extend() as unsigned int.
> >
> >
> > > That said I think the whole design is wrong as you could calculate
> > > array for algs only one time and pass a const reference to it on
> > > request.
> >
> > Ok. If I understood it correctly, you are saying to pass a const
> > reference of chip->active_banks. Then, I should also:
>
> This is not a viable option. chip could be freed and the reference
> becomes invalid, without increasing the reference count.
>
> Did you think about something different?
>
> Thanks
>
> Roberto
Two alternatives come in mind.
1. add tpm_put to linclude/linux/tpm.h
2. take put_ops away from the implementation
3. add documentation that tpm_put needs to be called
or acceptable alternative would memcpy in the implementation
In any case, you should probably drop completely 'count' and have
function for getting the number of active banks.
/Jarkko
PCI irq affinity fix for 4.12
Hi Bjorn, Steve found a case where the !CONFIG_PCI_MSI stub for pci_alloc_irq_vectors did the wrong thing when used with the newly converted xhci driver. While the PCI code has been wrong since day 1 the fact that a newly converted drivers triggers it makes it a regression in this cycle.
[PATCH] PCI/msi: fix the pci_alloc_irq_vectors_affinity stub
We need to return an error for any call that asks for MSI / MSI-X
vectors only, so that non-trivial fallback logic can work properly.
Signed-off-by: Christoph Hellwig
Reported-by: Steven Rostedt
Fixes: aff17164 ("PCI: Provide sensible IRQ vector alloc/free routines")
---
include/linux/pci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 33c2b0b77429..5a7fd3b6a7b9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1342,7 +1342,7 @@ pci_alloc_irq_vectors_affinity(struct pci_dev *dev,
unsigned int min_vecs,
unsigned int max_vecs, unsigned int flags,
const struct irq_affinity *aff_desc)
{
- if (min_vecs > 1)
+ if (min_vecs > 1 || !(flags & PCI_IRQ_LEGACY))
return -EINVAL;
return 1;
}
--
2.11.0
Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto()
On Mon, May 15, 2017 at 04:22:22PM +0200, Roberto Sassu wrote: > On 5/15/2017 1:16 PM, Jarkko Sakkinen wrote: > > On Fri, May 05, 2017 at 04:21:49PM +0200, Roberto Sassu wrote: > > > tpm_pcr_algorithms() returns to its callers the IDs of the hash algorithms > > > supported by the TPM. This patch introduces tpm_pcr_algo_to_crypto(), > > > so that the callers can use the crypto subsystem to calculate the digest > > > to be passed to tpm_pcr_extend(). > > > > > > tpm_pcr_algo_from_crypto(), implemented for completeness, is instead used > > > > What do you mean by completeness? Please, never add unused stuff. > > > > > by tpm2_seal_trusted() to perform the opposite conversion. > > > > > > Signed-off-by: Roberto Sassu > > > --- > > > v2 > > > > > > - fixed return values of tpm2_pcr_algo_to_crypto() and > > > tpm2_pcr_algo_from_crypto() if TPM support is disabled in the kernel > > > > Change Log only to the cover letter. > > > > > drivers/char/tpm/tpm-interface.c | 51 > > > > > > drivers/char/tpm/tpm2-cmd.c | 42 + > > > include/linux/tpm.h | 13 ++ > > > 3 files changed, 75 insertions(+), 31 deletions(-) > > > > This commit is just deadly wrong in so many ways. > > > > I would suggest to make extend always just take crypto ID in so you > > don't have to add these bizarre conversion functions. > > The reason of this choice (as I explained in the cover letter) > is that TPM users might want to produce an event log with > the TCG format (which includes the TPM algorithm ID). Also, > TPM IDs should be preferred because, with them, TPM users > can calculate a digest directly with the TPM. > > Taking crypto IDs means relying on the fact that there > is always a mapping between TPM IDs and crypto IDs. > Otherwise, tpm_pcr_algorithms() cannot return the algorithms > to its callers and PCRs cannot be extended. If TPM IDs are used, > TPM users have two alternatives: calculate the digest with > the TPM, or pass a SHA1 digest to tpm_pcr_extend(), so that > it can be padded to extend remanining PCR banks. > > However, this second option will work only when the TPM driver > determines the size of an algorithm without relying on the crypto > subsystem. At the moment, if a TPM ID is not mapped to a crypto ID, > tpm2_pcr_extend() ignores the digest. > > Roberto What if tpm_pcr_algorithms would convert TPM IDs to crypto IDs? Externally other subsystems would have to then deal with only crypto IDs. That would favor "memcpy" (or it would become a for loop) for 1/5. /Jarkko
[PATCH kernel.org] 4.10 is now end-of-life
Properly mark 4.10 as being EOL on the website.
Signed-off-by: Greg Kroah-Hartman
diff --git a/pelicanconf.py b/pelicanconf.py
index d0ec28210bc9..dbfe46b637bb 100644
--- a/pelicanconf.py
+++ b/pelicanconf.py
@@ -26,7 +26,7 @@ sys.path.append('./')
from plugins import releases
LONGTERM_KERNELS = ('4.9', '4.4', '4.1', '3.18', '3.16', '3.14', '3.12',
'3.10', '3.4', '3.2')
-EOL_KERNELS = ('3.12', '3.14', '3.18', '3.19', '4.0', '4.2', '4.3', '4.5',
'4.6', '4.7', '4.8')
+EOL_KERNELS = ('3.12', '3.14', '3.18', '3.19', '4.0', '4.2', '4.3', '4.5',
'4.6', '4.7', '4.8', '4.10')
if 'GIT_REPOS' in os.environ.keys():
GIT_REPOS = os.environ['GIT_REPOS']
[PATCH v2 0/5] Add support for the STM32F4 CRC32
This patch series add hardware CRC32 ("Ethernet") calculation support
for STMicroelectronics STM32F429.
Polynomial and key setting are not supported, key is fixed as 0x4C11DB7
and poly is 0x.
Module is tested on STM32F429-disco board with crypto testmgr using
cases within the key 0x.
Cosar Dindar (5):
crypto : stm32 - Add STM32F4 CRC32 support
dt-bindings : Document the STM32F4 CRC32 binding
ARM: dts: stm32: enable CRC32 on stm32429-disco board
ARM: dts: stm32: enable CRC32 on stm32429i-eval board
ARM: dts: stm32: Add CRC support to stm32f429
.../devicetree/bindings/crypto/st,stm32-crc.txt| 4 +-
arch/arm/boot/dts/stm32429i-eval.dts | 4 ++
arch/arm/boot/dts/stm32f429-disco.dts | 4 ++
arch/arm/boot/dts/stm32f429.dtsi | 7 +++
drivers/crypto/stm32/stm32_crc32.c | 68 ++
5 files changed, 75 insertions(+), 12 deletions(-)
--
2.7.4
[PATCH v2 1/5] crypto : stm32 - Add STM32F4 CRC32 support
This patch adds CRC (CRC32 Crypto) support for STM32F4 series.
As an hardware limitation polynomial and key setting are not supported.
They are fixed as 0x4C11DB7 (poly) and 0x (key).
CRC32C Castagnoli algorithm is not used.
Signed-off-by: Cosar Dindar
---
drivers/crypto/stm32/stm32_crc32.c | 68 --
1 file changed, 58 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/stm32/stm32_crc32.c
b/drivers/crypto/stm32/stm32_crc32.c
index ec83b1e..12fbd98 100644
--- a/drivers/crypto/stm32/stm32_crc32.c
+++ b/drivers/crypto/stm32/stm32_crc32.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -39,6 +40,9 @@ struct stm32_crc {
struct clk *clk;
u8 pending_data[sizeof(u32)];
size_t nb_pending_bytes;
+ bool key_support;
+ bool poly_support;
+ bool reverse_support;
};
struct stm32_crc_list {
@@ -106,13 +110,31 @@ static int stm32_crc_init(struct shash_desc *desc)
}
spin_unlock_bh(&crc_list.lock);
- /* Reset, set key, poly and configure in bit reverse mode */
- writel(bitrev32(mctx->key), ctx->crc->regs + CRC_INIT);
- writel(bitrev32(mctx->poly), ctx->crc->regs + CRC_POL);
- writel(CRC_CR_RESET | CRC_CR_REVERSE, ctx->crc->regs + CRC_CR);
+ /* set key */
+ if (ctx->crc->key_support) {
+ writel(bitrev32(mctx->key), ctx->crc->regs + CRC_INIT);
+ } else if (mctx->key != CRC_INIT_DEFAULT) {
+ dev_err(ctx->crc->dev, "Unsupported key value! Should be:
0x%x\n",
+ CRC_INIT_DEFAULT);
+ return -EINVAL;
+ }
+
+ /* set poly */
+ if (ctx->crc->poly_support)
+ writel(bitrev32(mctx->poly), ctx->crc->regs + CRC_POL);
+
+ /* reset and configure in bit reverse mode if supported */
+ if (ctx->crc->reverse_support)
+ writel(CRC_CR_RESET | CRC_CR_REVERSE, ctx->crc->regs + CRC_CR);
+ else
+ writel(CRC_CR_RESET, ctx->crc->regs + CRC_CR);
+
+ /* store partial result */
+ if (!ctx->crc->reverse_support)
+ ctx->partial = bitrev32(readl(crc->regs + CRC_DR));
+ else
+ ctx->partial = readl(ctx->crc->regs + CRC_DR);
- /* Store partial result */
- ctx->partial = readl(ctx->crc->regs + CRC_DR);
ctx->crc->nb_pending_bytes = 0;
return 0;
@@ -135,7 +157,12 @@ static int stm32_crc_update(struct shash_desc *desc, const
u8 *d8,
if (crc->nb_pending_bytes == sizeof(u32)) {
/* Process completed pending data */
- writel(*(u32 *)crc->pending_data, crc->regs + CRC_DR);
+ if (!ctx->crc->reverse_support)
+ writel(bitrev32(*(u32 *)crc->pending_data),
+ crc->regs + CRC_DR);
+ else
+ writel(*(u32 *)crc->pending_data,
+ crc->regs + CRC_DR);
crc->nb_pending_bytes = 0;
}
}
@@ -143,10 +170,16 @@ static int stm32_crc_update(struct shash_desc *desc,
const u8 *d8,
d32 = (u32 *)d8;
for (i = 0; i < length >> 2; i++)
/* Process 32 bits data */
- writel(*(d32++), crc->regs + CRC_DR);
+ if (!ctx->crc->reverse_support)
+ writel(bitrev32(*(d32++)), crc->regs + CRC_DR);
+ else
+ writel(*(d32++), crc->regs + CRC_DR);
/* Store partial result */
- ctx->partial = readl(crc->regs + CRC_DR);
+ if (!ctx->crc->reverse_support)
+ ctx->partial = bitrev32(readl(crc->regs + CRC_DR));
+ else
+ ctx->partial = readl(crc->regs + CRC_DR);
/* Check for pending data (non 32 bits) */
length &= 3;
@@ -243,6 +276,7 @@ static int stm32_crc_probe(struct platform_device *pdev)
struct stm32_crc *crc;
struct resource *res;
int ret;
+ int algs_size;
crc = devm_kzalloc(dev, sizeof(*crc), GFP_KERNEL);
if (!crc)
@@ -269,13 +303,26 @@ static int stm32_crc_probe(struct platform_device *pdev)
return ret;
}
+ /* set key, poly and reverse support if device is of F7 series */
+ if (of_device_is_compatible(crc->dev->of_node, "st,stm32f7-crc")) {
+ crc->key_support = true;
+ crc->poly_support = true;
+ crc->reverse_support = true;
+ }
+
platform_set_drvdata(pdev, crc);
spin_lock(&crc_list.lock);
list_add(&crc->list, &crc_list.dev_list);
spin_unlock(&crc_list.lock);
- ret = crypto_register_shashes(algs, ARRAY_SIZE(algs));
+ /* For F4 series only CRC32 algorithm will be used */
+ if (of_d
[PATCH v2 2/5] dt-bindings : Document the STM32F4 CRC32 binding
Add device tree binding for STM32F4.
Signed-off-by: Cosar Dindar
---
Documentation/devicetree/bindings/crypto/st,stm32-crc.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
b/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
index 3ba92a5..7b30f1e 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
@@ -1,7 +1,7 @@
* STMicroelectronics STM32 CRC
Required properties:
-- compatible: Should be "st,stm32f7-crc".
+- compatible: Can be either "st,stm32f7-crc" or "st,srm32f4-crc".
- reg: The address and length of the peripheral registers space
- clocks: The input clock of the CRC instance
@@ -10,7 +10,7 @@ Optional properties: none
Example:
crc: crc@40023000 {
- compatible = "st,stm32f7-crc";
+ compatible = "st,stm32f7-crc", "st,stm32f4-crc";
reg = <0x40023000 0x400>;
clocks = <&rcc 0 12>;
};
--
2.7.4
[PATCH v2 4/5] ARM: dts: stm32: enable CRC32 on stm32429i-eval board
Enable the CRC32 crypto on stm32429i-eval board.
Signed-off-by: Cosar Dindar
---
arch/arm/boot/dts/stm32429i-eval.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index b633114..360fb19 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -141,6 +141,10 @@
clock-frequency = <2500>;
};
+&crc {
+ status = "okay";
+};
+
&i2c1 {
pinctrl-0 = <&i2c1_pins>;
pinctrl-names = "default";
--
2.7.4
[PATCH v2 5/5] ARM: dts: stm32: Add CRC support to stm32f429
Add CRC32 Crypto support to stm32f429.
Signed-off-by: Cosar Dindar
---
arch/arm/boot/dts/stm32f429.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index b2a2b5c..18343de 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -766,6 +766,13 @@
};
};
+ crc: crc@40023000 {
+ compatible = "st,stm32f4-crc";
+ reg = <0x40023000 0x400>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(CRC)>;
+ status = "disabled";
+ };
+
rcc: rcc@40023810 {
#reset-cells = <1>;
#clock-cells = <2>;
--
2.7.4
[PATCH v2 3/5] ARM: dts: stm32: enable CRC32 on stm32429-disco board
Enable the CRC32 crypto on stm32429-disco board.
Signed-off-by: Cosar Dindar
---
arch/arm/boot/dts/stm32f429-disco.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
b/arch/arm/boot/dts/stm32f429-disco.dts
index 191fa50..ae47cde 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -102,6 +102,10 @@
clock-frequency = <800>;
};
+&crc {
+ status = "okay";
+};
+
&rtc {
assigned-clocks = <&rcc 1 CLK_RTC>;
assigned-clock-parents = <&rcc 1 CLK_LSI>;
--
2.7.4
[GIT PULL REQUEST] watchdog - v4.12-rc1 Fixes
Hi Linus,
Please pull from 'master' branch of
git://www.linux-watchdog.org/linux-watchdog.git
It will fix:
* orion_wdt compile-test dependencies
* sama5d4_wdt: WDDIS handling and a race confition
* pcwd_usb: fix NULL-deref at probe
* cadence_wdt: fix timeout setting
* wdt_pci: fix build error if SOFTWARE_REBOOT is defined
* iTCO_wdt: all versions count down twice
* zx2967: remove redundant dev_err call in zx2967_wdt_probe()
* bcm281xx: Fix use of uninitialized spinlock
This will update the following files:
Documentation/watchdog/watchdog-parameters.txt |2
drivers/watchdog/Kconfig |2
drivers/watchdog/bcm_kona_wdt.c|3
drivers/watchdog/cadence_wdt.c |2
drivers/watchdog/iTCO_wdt.c| 22 +++
drivers/watchdog/pcwd_usb.c|3
drivers/watchdog/sama5d4_wdt.c | 77 ++---
drivers/watchdog/wdt_pci.c |2
drivers/watchdog/zx2967_wdt.c |4 -
9 files changed, 77 insertions(+), 40 deletions(-)
with these Changes:
commit fedf266f9955d9a019643cde199a2fd9a0259f6f
Author: Eric Anholt
Date: Thu Apr 27 18:02:32 2017 -0700
watchdog: bcm281xx: Fix use of uninitialized spinlock.
The bcm_kona_wdt_set_resolution_reg() call takes the spinlock, so
initialize it earlier. Fixes a warning at boot with lock debugging
enabled.
Fixes: 6adb730dc208 ("watchdog: bcm281xx: Watchdog Driver")
Signed-off-by: Eric Anholt
Reviewed-by: Florian Fainelli
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
commit 07441a7dd11f6855bcf55fbbfc6abba42258b2c6
Author: Wei Yongjun
Date: Tue Apr 25 16:17:33 2017 +
watchdog: zx2967: remove redundant dev_err call in zx2967_wdt_probe()
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
commit 1fccb73011ea8a5fa0c6d357c33fa29c695139ea
Author: Paolo Bonzini
Date: Wed Apr 5 13:41:15 2017 +0200
iTCO_wdt: all versions count down twice
The ICH9 is listed as having TCO v2, and indeed the behavior in the
datasheet corresponds to v2 (for example the NO_REBOOT flag is
accessible via the 16KiB-aligned Root Complex Base Address).
However, the TCO counts twice just like in v1; the documentation
of the SECOND_TO_STS bit says: "ICH9 sets this bit to 1 to indicate
that the TIMEOUT bit had been (or is currently) set and a second
timeout occurred before the TCO_RLD register was written. If this
bit is set and the NO_REBOOT config bit is 0, then the ICH9 will
reboot the system after the second timeout. The same can be found
in the BayTrail (Atom E3800) datasheet, and even HOWTOs around
the Internet say that it will reboot after _twice_ the specified
heartbeat.
I did not find the Apollo Lake datasheet, but because v4/v5 has
a SECOND_TO_STS bit just like the previous version I'm enabling
this for Apollo Lake as well.
Cc: linux-watch...@vger.kernel.org
Reviewed-by: Andy Shevchenko
Signed-off-by: Paolo Bonzini
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
commit 455a9a60b6d4afb293b0e63ec75cc8e82912a767
Author: Shile Zhang
Date: Mon Apr 10 22:39:33 2017 +0800
watchdog: wdt_pci: fix build error if define SOFTWARE_REBOOT
To fix following build error when SOFTWARE_REBOOT is defined:
CC [M] driver/watchdog/wdt_pci.o
driver/watchdog/wdt_pci.c: In function 'wdtpci_interrupt':
driver/watchdog/wdt_pci.c:335:3: error: too many arguments to function
'emergency_restart'
emergency_restart(NULL);
^
In file included from driver/watchdog/wdt_pci.c:51:0:
include/linux/reboot.h:80:13: note: declared here
extern void emergency_restart(void);
^
Signed-off-by: Shile Zhang
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
commit 0ddad77b90cb52075b5a9498f0621e3e265cc19f
Author: Tomas Melin
Date: Mon Mar 20 09:29:31 2017 +0200
watchdog: cadence_wdt: fix timeout setting
wdt_timeout must not be initialized to CDNS_WDT_DEFAULT_TIMEOUT in
order to allow the value to be overriddden by a device tree setting.
This way, the default timeout value will be used only in case module_param
has not been set, or device tree timeout-sec has not been defined.
Signed-off-by: Tomas Melin
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
commit 46c319b848268dab3f0e7c4a5b6e9146d3bca8a4
Author: Johan Hovold
Date: Mon Mar 13 13:49:4
[GIT PULL] Char/Misc driver fixes for 4.12-rc2
The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/char-misc-4.12-rc2 for you to fetch changes up to 9434cec130a941e8a0698d598dfa5499dbdeb949: firmware: Google VPD: Fix memory allocation error handling (2017-05-18 17:01:46 +0200) Char/Misc driver fixes for 4.12-rc2 Here are 5 small bugfixes for reported issues with 4.12-rc1 and earlier kernels. Nothing huge here, just a lp, mem, vpd, and uio driver fix, along with a Kconfig fixup for one of the misc drivers. All of these have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Christophe JAILLET (1): firmware: Google VPD: Fix memory allocation error handling Julius Werner (1): drivers: char: mem: Check for address space wraparound with mmap() Suman Anna (1): uio: fix incorrect memory leak cleanup Tobias Regnery (1): misc: pci_endpoint_test: select CRC32 Willy Tarreau (1): char: lp: fix possible integer overflow in lp_setup() drivers/char/lp.c | 6 +- drivers/char/mem.c| 5 + drivers/firmware/google/vpd.c | 21 +++-- drivers/misc/Kconfig | 1 + drivers/uio/uio.c | 8 5 files changed, 30 insertions(+), 11 deletions(-)
[GIT PULL] USB driver fixes for 4.12-rc2
The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.12-rc2 for you to fetch changes up to b51e0ceed1f93a1eda3cbee328a396a188ec79e3: Merge tag 'usb-serial-4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus (2017-05-19 10:10:07 +0200) USB fixes for 4.12-rc2 Here are a number of small USB fixes for 4.12-rc2 Most of them come from Johan, in his valiant quest to fix up all drivers that could be affected by "malicious" USB devices. There's also some fixes for more "obscure" drivers to handle some of the vmalloc stack fallout (which for USB drivers, was always the case, but very few people actually ran those systems...) Other than that, the normal set of xhci and gadget and musb driver fixes as well. All have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Alan Stern (2): USB: ene_usb6250: fix DMA to the stack USB: xhci: fix lock-inversion problem Andrey Korolyov (1): USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs Anthony Mallet (1): USB: serial: ftdi_sio: fix setting latency for unprivileged users Anton Bondarenko (1): usb: core: fix potential memory leak in error path during hcd creation Bjørn Mork (1): USB: serial: qcserial: add more Lenovo EM74xx device IDs Bogdan Mirea (1): usb: gadget: gserial: check if console kthread exists Chris Brandt (2): usb: r8a66597-hcd: decrease timeout usb: r8a66597-hcd: select a different endpoint on timeout Daniele Palmas (1): usb: serial: option: add Telit ME910 support Greg Kroah-Hartman (2): Merge tag 'fixes-for-v4.12-rc2' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'usb-serial-4.12-rc2' of git://git.kernel.org/.../johan/usb-serial into usb-linus Heikki Krogerus (1): usb: dwc3: pci: add Intel Cannonlake PCI IDs Jiri Slaby (1): sisusb_con: fix coccinelle warning Johan Hovold (14): USB: serial: ir-usb: fix big-endian baud-rate debug printk USB: serial: mct_u232: fix big-endian baud-rate handling USB: serial: io_ti: fix div-by-zero in set_termios uwb: fix device quirk on big-endian hosts USB: chaoskey: fix Alea quirk on big-endian hosts USB: iowarrior: fix info ioctl on big-endian hosts USB: ehci-platform: fix companion-device leak USB: core: of: document reference taken by companion helper USB: gadget: dummy_hcd: fix hub-descriptor removable fields USB: usbip: fix nonconforming hub descriptor USB: hub: fix SS hub-descriptor handling USB: hub: fix non-SS hub-descriptor handling USB: hub: fix SS max number of ports USB: host: xhci: use max-port define Maksim Salau (1): usb: misc: legousbtower: Fix memory leak Markus Heiser (1): doc-rst: fixed kernel-doc directives in usb/typec.rst Mathias Nyman (3): usb: xhci: trace URB before giving it back instead of after xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton xhci: Fix command ring stop regression in 4.11 Matthias Lange (1): xhci: remove GFP_DMA flag from allocation Pan Bian (1): usb: dwc3: keystone: check return value Peter Chen (2): usb: host: xhci-mem: allocate zeroed Scratchpad Buffer usb: host: xhci-ring: don't need to clear interrupt pending for MSI enabled hcd Peter Ujfalusi (1): usb: musb: tusb6010_omap: Do not reset the other direction's packet size Roger Quadros (1): usb: dwc3: gadget: Fix ISO transfer performance Thinh Nguyen (1): usb: dwc3: gadget: Prevent losing events in event cache Thomas Petazzoni (1): usb: host: xhci-plat: propagate return value of platform_get_irq() Tony Lindgren (1): usb: musb: Fix trying to suspend while active for OTG configurations Vamsi Krishna Samavedam (1): USB: core: replace %p with %pK William Wu (1): usb: gadget: f_fs: avoid out of bounds access on comp_desc Documentation/usb/typec.rst | 6 +-- drivers/usb/core/devio.c| 14 ++--- drivers/usb/core/hcd.c | 5 +- drivers/usb/core/hub.c | 27 +++--- drivers/usb/core/of.c | 3 ++ drivers/usb/core/urb.c | 2 +- drivers/usb/dwc3/dwc3-keystone.c| 4 ++ drivers/usb/dwc3/dwc3-pci.c | 4 ++ drivers/usb/dwc3/gadget.c | 21 +++- drivers/usb/gadget/function/f_fs.c | 10 ++-- drivers/usb/gadget/function/u_serial.c | 2 +- drivers/usb/gadget/udc/dummy_hcd.c | 6 +-- drivers/usb/host/ehci-platform.c| 4 +- drivers/usb/host/r8a66597-hcd.c | 6 ++- drivers/usb
[GIT PULL] Staging driver fixes for 4.12-rc2
The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.12-rc2 for you to fetch changes up to 66ea5974b36b73129bbdc129847ec73cecb3f14d: MAINTAINERS: greybus-dev list is members-only (2017-05-18 15:32:29 +0200) Staging driver fixes for 4.12-rc2 Here are a number of staging driver fixes for 4.12-rc2 Most of them are typec driver fixes found by reviewers and users of the code. There are also some removals of files no longer needed in the tree due to the ion driver rewrite in 4.12-rc1, as well as some wifi driver fixes. And to round it out, a MAINTAINERS file update. All have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Arnd Bergmann (1): staging: fsl-dpaa2/eth: add ETHERNET dependency Gilad Ben-Yossef (1): staging: MAINTAINERS: add GBY as ccree maintainer Guenter Roeck (4): staging: typec: tcpm: Drop duplicate PD messages staging: typec: tcpm: Set correct flags in PD request messages staging: typec: tcpm: Respond to Discover Identity commands staging: typec: tcpm: Fix Port Power Role field in PS_RDY messages Guru Das Srinagesh (1): staging: typec: Fix sparse warnings about incorrect types Ian Chard (1): staging: ccree: remove extraneous spin_unlock_bh() in error handler Ian W MORRISON (1): staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c Javier Martinez Canillas (1): staging: typec: fusb302: Fix module autoload Malcolm Priestley (4): staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out memory. staging: rtl8192e: fix 2 byte alignment of register BSSIDR. staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD. staging: rtl8192e: GetTs Fix invalid TID 7 warning. Olivier Leveque (1): staging: typec: tcpci: declare private structure as static Phil Elwell (1): staging: vc04_services: Fix bulk cache maintenance Randy Dunlap (1): MAINTAINERS: greybus-dev list is members-only Rui Miguel Silva (3): staging: typec: fusb302: do not free gpio from managed resource staging: typec: fusb302: reset i2c_busy state in error staging: typec: fusb302: refactor resume retry mechanism Yisheng Xie (1): staging/android/ion: remove useless document file Yueyao Zhu (1): staging: typec: fusb302: Fix chip->vbus_present init value .../devicetree/bindings/staging/ion/hi6220-ion.txt | 31 MAINTAINERS| 11 ++- drivers/staging/android/ion/devicetree.txt | 51 - drivers/staging/ccree/ssi_request_mgr.c| 1 - drivers/staging/fsl-dpaa2/Kconfig | 1 + drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 24 +++--- drivers/staging/rtl8192e/rtl819x_TSProc.c | 15 +--- drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 - drivers/staging/typec/fusb302/fusb302.c| 86 +++--- drivers/staging/typec/pd.h | 10 +++ drivers/staging/typec/pd_vdo.h | 4 +- drivers/staging/typec/tcpci.c | 2 +- drivers/staging/typec/tcpm.c | 77 ++- drivers/staging/typec/tcpm.h | 3 + .../interface/vchiq_arm/vchiq_2835_arm.c | 31 +--- 15 files changed, 183 insertions(+), 165 deletions(-) delete mode 100644 Documentation/devicetree/bindings/staging/ion/hi6220-ion.txt delete mode 100644 drivers/staging/android/ion/devicetree.txt
Re: [PATCH v2 00/18] ARM64: meson: DT cleanups
Am 15.05.2017 um 22:24 schrieb Martin Blumenstingl: > On Mon, May 15, 2017 at 9:10 PM, Andreas Färber wrote: >> Hi Neil, >> >> Am 15.05.2017 um 10:16 schrieb Neil Armstrong: >>> Hi Andreas, >>> >>> On 05/13/2017 04:33 PM, Andreas Färber wrote: Hello Kevin, This series fixes several cosmetic issues, on top of your for-next branch. Patches 3-6 rename a node, the rest should all be non-functional changes. >>> >>> These are OK. >>> PLEASE STOP merging random new nodes at the bottom of DT files! Just like it's a convention to sort new nodes by unit address, it has been a convention to sort by-label nodes by their label. As discussed here and elsewhere, this helps avoid merge conflicts and makes nodes easy to find. I don't care whether we order A0 before A or after, but adding new HDMI or CVBS nodes at the very bottom is totally out of alphabetical order. Since my v1 you really should've known that... >>> >>> It's not perfect, but now it's done, live with it, this has already been >>> discussed. >> >> No. >> >> Copy&pasting your comment N times does not make it any more valid. My >> files, my rules - I insist on vega-s95, gxbb and gx, which you guys >> refactored out from my gxbb, to be tidy. >> >>> Please try to refactor boards DTS with their parent reference design instead >>> like it was done with the P212 and what I did with the Wetek Hub and Play2. >> >> Negative, that means any additions and changes for the reference boards >> will slip through into boards that you do not test. >> >> We've already seen how "well" that works with R-Box Pro having inherited >> a broken U-Boot network configuration due to internal vs. external PHY. > could you please share your vision how we can a) keep the amount of > duplicate .dts code low while b) avoiding "accidental" changes? maybe > there's a better way (compared to what we have now) which I've not > thought of yet The reason for aligning all exynos5250 .dts files was to be able to use diff -u to compare files for differences. Obviously the board compatible will always show up, but by ordering alphabetically and by inheriting some common order for the other nodes without particular convention only the actual changes show up. That's why I had started the voluntary work of also cleaning up boards that I do not have access to. You had already adopted alphabetical order for Vim, thanks for that. Basically we have two different concepts here: One is physical reuse, e.g., the boards all use the same S905 chip from Amlogic, so we can safely inherit meson-gxbb.dtsi. The other is design reuse. Rather than reusing the same physical board, they are different boards based on a common template but they may contain variations. Thus there is no guarantee that everything in the original template is in each derived board. The difficulty for us here is that for most TV boxes no schematics are available to decide whether there are any differences compared to Amlogic's P/Q reference boards. So we would only find out when something breaks. For example, continuing my work on the NanoPi K2 I have found several minor variations of how power supplies are called and which GPIO is being used, compared to Odroid-C2 or Vega. Therefore the usual solution is that contributors of individual board trees also need to maintain them long-term, as opposed to expecting BayLibre to do that and magically getting everything for free. Specifically, I added the vega-s95 and am adding the nanopi-k2, so once you add serdev and Bluetooth nodes for your Vim, we will have to manually adopt those for other boards. If we don't notice or don't do our additions, the boards will continue to boot as before but just not get any new cool features. On the other hand, if some driver change gets performed, all in-tree files need to be updated, which provides some more motivation for vendors and users to participate in mainline development. Similarly, Khadas Vim shouldn't have been merged with the "bcrmf" typo. >>> >>> Well, this is why we have 7 rc releases after the merge window... >> >> If Kevin is the maintainer, then he needs to carefully review patches. >> It is not my job to review all patches when BayLibre gets paid for it! > please stop these accusations, Being the Amlogic maintainer is not an "accusation". https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts?id=e15d2774b8c096f116bf7192b37e8652da71369e carries his Signed-off-by, that's for a fact. Also FTR I found it a really weird assumption that ugly naming should be noticed during RC testing. Therefore my point that this is about review, not testing. Fact is also that BayLibre people appear to be working on Amlogic stuff during the week and with few exceptions unlike you and me are rather silent the weekend, which is when I get to look into these platforms. So whatever their formula of payment may be (I don't ca
Re: Widespread crashes in -next, bisected to 'mm: drop HASH_ADAPT'
On 05/20/2017 12:26 AM, Michal Hocko wrote: On Fri 19-05-17 09:46:23, Guenter Roeck wrote: Hi, my qemu tests of next-20170519 show the following results: total: 122 pass: 30 fail: 92 I won't bother listing all of the failures; they are available at http://kerneltests.org/builders. I bisected one (openrisc, because it gives me some console output before dying). It points to 'mm: drop HASH_ADAPT' as the culprit. Bisect log is attached. A quick glance suggests that 64 bit kernels pass and 32 bit kernels fail. 32-bit x86 images fail and should provide an easy test case. Hmm, this is quite unexpected as the patch is not supposed to change things much. It just removes the flag and perform the new hash scaling It may well be that the problem is introduced with an earlier patch and just enabled by this one. automatically for all requeusts which do not have any high limit. Some of those didn't have HASH_ADAPT before but that shouldn't change the picture much. The only thing that I can imagine is that what formerly failed for early memblock allocations is now suceeding and that depletes the early memory. Do you have any serial console from the boot? They are all the same. Either nothing or the following. Picking a couple: metag: Linux version 4.12.0-rc1-next-20170519 (gro...@jupiter.roeck-us.net) (gcc version 4.2.4 (IMG-1.4.0.300)) #1 Fri May 19 00:50:50 PDT 2017 LNKGET/SET go through cache but CONFIG_METAG_LNKGET_AROUND_CACHE=y DA present console [ttyDA1] enabled OF: fdt: Machine model: toumaz,tz1090 Machine name: Generic Meta Node 0: start_pfn = 0xb, low = 0xbfff7 Zone ranges: Normal [mem 0xb000-0xbfff6fff] Movable zone start for each node Early memory node ranges node 0: [mem 0xb000-0xbfff6fff] Initmem setup node 0 [mem 0xb000-0xbfff6fff] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65015 Kernel command line: rdinit=/sbin/init doreboot PID hash table entries: 1024 (order: 0, 4096 bytes) crisv32: Linux version 4.12.0-rc1-next-20170519 (gro...@desktop.roeck-us.net) (gcc version 4.9.2 (Buildroot 2015.02-rc1-5-gb13bd8e-dirty) ) #1 Fri May 19 00:52:55 PDT 2017 bootconsole [early0] enabled Setting up paging and the MMU. Linux/CRISv32 port on ETRAX FS (C) 2003, 2004 Axis Communications AB Built 1 zonelists in Zone order, mobility grouping on. Total pages: 4080 Kernel command line: console=ttyS0,115200,N,8 rdinit=/sbin/init PID hash table entries: 128 (order: -4, 512 bytes) powerpc:mpc8548cds: Memory CAM mapping: 256 Mb, residual: 0Mb Linux version 4.12.0-rc1-next-20170519 (gro...@jupiter.roeck-us.net) (gcc version 4.8.1 (GCC) ) #1 Fri May 19 01:17:29 PDT 2017 Found initrd at 0xc400:0xc4200c00 Using MPC85xx CDS machine description bootconsole [udbg0] enabled - phys_mem_size = 0x1000 dcache_bsize = 0x20 icache_bsize = 0x20 cpu_features = 0x12100460 possible= 0x12100460 always = 0x0010 cpu_user_features = 0x84e08000 0x0800 mmu_features = 0x00020010 - mpc85xx_cds_setup_arch() Could not find FPGA node. Zone ranges: DMA [mem 0x-0x0fff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x-0x0fff] Initmem setup node 0 [mem 0x-0x0fff] MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: rdinit=/sbin/init console=ttyS0 console=tty doreboot PID hash table entries: 1024 (order: 0, 4096 bytes) Guenter
Re: [PATCH] slub/memcg: Cure the brainless abuse of sysfs attributes
On Sat, 20 May 2017 06:16:45 -0700 Christoph Hellwig wrote: > On Sat, May 20, 2017 at 12:52:03PM +0200, Thomas Gleixner wrote: > > This should be rewritten proper by adding a propagate() callback to those > > slub_attributes which must be propagated and avoid that insane conversion > > to and from ASCII > > Exactly.. > > >, but that's too large for a hot fix. > > What made this such a hot fix? Looks like this crap has been in > for quite a while. It can cause a deadlock with get_online_cpus() that has been uncovered by recent cpu hotplug and lockdep changes that Thomas and Peter have been doing. [ 102.567308] Possible unsafe locking scenario: [ 102.567308] [ 102.574846]CPU0CPU1 [ 102.580148] [ 102.585421] lock(cpu_hotplug.lock); [ 102.589808]lock(slab_mutex); [ 102.596166]lock(cpu_hotplug.lock); [ 102.603028] lock(slab_mutex); [ 102.606846] [ 102.606846] *** DEADLOCK *** -- Steve
RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform
Collins, Okay, good to know. Is there a common solution that can handle all cases? Thanks, Kelly >-Original Message- >From: Cheng, Collins >Sent: Saturday, May 20, 2017 6:38 AM >To: Zytaruk, Kelly; Alexander Duyck; Alex Williamson >Cc: Bjorn Helgaas; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; >Deucher, Alexander; Yinghai Lu >Subject: RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV >incapable platform > >Hi Kelly, > >This issue also happens in "not SR-IOV capable" SBIOS. It seems some "not >SR-IOV >capable" SBIOS will directly report error in system BIOS boot stage and doesn't >boot to OS. But other "not SR-IOV capable" SBIOS would not report error and >boot to Linux. > >-Collins Cheng > > >-Original Message- >From: Zytaruk, Kelly >Sent: Saturday, May 20, 2017 6:28 PM >To: Cheng, Collins ; Alexander Duyck >; Alex Williamson >Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; linux- >ker...@vger.kernel.org; Deucher, Alexander ; >Yinghai Lu >Subject: RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV >incapable platform > > > >>-Original Message- >>From: Cheng, Collins >>Sent: Saturday, May 20, 2017 12:53 AM >>To: Alexander Duyck; Alex Williamson >>Cc: Bjorn Helgaas; linux-...@vger.kernel.org; >>linux-kernel@vger.kernel.org; Deucher, Alexander; Zytaruk, Kelly; >>Yinghai Lu >>Subject: RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV >>incapable platform >> >>Hi Alex, >> >>Yes, I hope kernel can disable SR-IOV and related VF resource >>allocation if the system BIOS is not SR-IOV capable. >> >>Adding the parameter "pci=nosriov" sounds a doable solution, but it >>would need user to add this parameter manually, right? I think an >>automatic detection would be better. My patch is trying to auto detect and >bypass VF resource allocation. >> >> >>-Collins Cheng >> > >Collins, be careful about this. I don't think that this is what we want. If >you add >"pci=nosriov" then you are globally disabling SRIOV for all devices. This is >not the >solution that we are looking for. >Remember that there are 3 types of SBIOS; "not SR-IOV capable", "SR-IOV >capable but does not support large resources", "Complete SR-IOV support". > >The problem is that we are trying to find a fix for "broken" SBIOS that does >support SR-IOV but does not support the full SR-IOV capabilities that devices >with >large resources require. > >Thanks, >Kelly > >> >>-Original Message- >>From: Alexander Duyck [mailto:alexander.du...@gmail.com] >>Sent: Friday, May 19, 2017 11:44 PM >>To: Alex Williamson >>Cc: Cheng, Collins ; Bjorn Helgaas >>; linux-...@vger.kernel.org; linux- >>ker...@vger.kernel.org; Deucher, Alexander ; >>Zytaruk, Kelly ; Yinghai Lu >>Subject: Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV >>incapable platform >> >>On Mon, May 15, 2017 at 10:53 AM, Alex Williamson >> wrote: >>> On Mon, 15 May 2017 08:19:28 + >>> "Cheng, Collins" wrote: >>> Hi Williamson, We cannot assume BIOS supports SR-IOV, actually only newer server >>motherboard BIOS supports SR-IOV. Normal desktop motherboard BIOS or >>older server motherboard BIOS doesn't support SR-IOV. This issue would >>happen if an user plugs our AMD SR-IOV capable GPU card to a normal desktop >motherboard. >>> >>> Servers should be supporting SR-IOV for a long time now. What really >>> is there to a BIOS supporting SR-IOV anyway, it's simply reserving >>> sufficient bus number and MMIO resources such that we can enable the >>> VFs. This process isn't exclusively reserved for the BIOS. Some >>> platforms may choose to only initialize boot devices, leaving the >>> rest for the OS to program. The initial proposal here to disable >>> SR-IOV if not programmed at OS hand-off disables even the possibility >>> of the OS reallocating resources for this device. >> >>There are differences between supporting SR-IOV and supporting SR-IOV >>on devices with massive resources. I know I have seen NICs that will >>keep a system from completing POST if SR-IOV is enabled, and MMIO >>beyond 4G is not. My guess would be that the issues being seen are >>probably that they disable SR-IOV in the BIOS in such a setup and end >>up running into issues when they try to boot into the Linux kernel as >>it goes through and tries to allocate resources for SR-IOV even though it was >disabled in the BIOS. >> >>It might make sense to add a kernel parameter something like a "pci=nosriov" >>that would allow for disabling SR-IOV and related resource allocation >>if that is what we are talking about. That way you could plug in these >>types of devices into a system with a legacy bios or that doesn't wan >>to allocate addresses above 32b for MMIO, and this parameter would be >>all that is needed to disable SR-IOV so you could plug in a NIC that has >>SR-IOV >associated with it. >> I agree that failure to allocate VF resources should leave the device in no >>worse condition than before it t
[PATCH 0/2] vhost/scsi: Adjustments for five function implementations
From: Markus Elfring Date: Sat, 20 May 2017 16:25:04 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Improve a size determination in four functions Delete error messages for failed memory allocations in five functions drivers/vhost/scsi.c | 33 +++-- 1 file changed, 11 insertions(+), 22 deletions(-) -- 2.13.0
[PATCH 1/2] vhost/scsi: Improve a size determination in four functions
From: Markus Elfring
Date: Sat, 20 May 2017 13:48:44 +0200
Replace the specification of four data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/vhost/scsi.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index fd6c8b66f06f..650533916c19 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -597,8 +597,7 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq, struct
vhost_scsi_tpg *tpg,
sg = cmd->tvc_sgl;
prot_sg = cmd->tvc_prot_sgl;
pages = cmd->tvc_upages;
- memset(cmd, 0, sizeof(struct vhost_scsi_cmd));
-
+ memset(cmd, 0, sizeof(*cmd));
cmd->tvc_sgl = sg;
cmd->tvc_prot_sgl = prot_sg;
cmd->tvc_upages = pages;
@@ -1757,5 +1756,5 @@ static int vhost_scsi_make_nexus(struct vhost_scsi_tpg
*tpg,
return -EEXIST;
}
- tv_nexus = kzalloc(sizeof(struct vhost_scsi_nexus), GFP_KERNEL);
+ tv_nexus = kzalloc(sizeof(*tv_nexus), GFP_KERNEL);
if (!tv_nexus) {
@@ -1958,5 +1957,5 @@ vhost_scsi_make_tpg(struct se_wwn *wwn,
if (kstrtou16(name + 5, 10, &tpgt) || tpgt >= VHOST_SCSI_MAX_TARGET)
return ERR_PTR(-EINVAL);
- tpg = kzalloc(sizeof(struct vhost_scsi_tpg), GFP_KERNEL);
+ tpg = kzalloc(sizeof(*tpg), GFP_KERNEL);
if (!tpg) {
@@ -2012,5 +2011,5 @@ vhost_scsi_make_tport(struct target_fabric_configfs *tf,
/* if (vhost_scsi_parse_wwn(name, &wwpn, 1) < 0)
return ERR_PTR(-EINVAL); */
- tport = kzalloc(sizeof(struct vhost_scsi_tport), GFP_KERNEL);
+ tport = kzalloc(sizeof(*tport), GFP_KERNEL);
if (!tport) {
--
2.13.0
[PATCH 2/2] vhost/scsi: Delete error messages for failed memory allocations in five functions
From: Markus Elfring
Date: Sat, 20 May 2017 15:50:30 +0200
Omit seven extra messages for memory allocation failures in these functions.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
drivers/vhost/scsi.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 650533916c19..49d07950e2e5 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -417,5 +417,4 @@ vhost_scsi_allocate_evt(struct vhost_scsi *vs,
if (!evt) {
- vq_err(vq, "Failed to allocate vhost_scsi_evt\n");
vs->vs_events_missed = true;
return NULL;
}
@@ -1722,21 +1721,15 @@ static int vhost_scsi_nexus_cb(struct se_portal_group
*se_tpg,
- if (!tv_cmd->tvc_sgl) {
- pr_err("Unable to allocate tv_cmd->tvc_sgl\n");
+ if (!tv_cmd->tvc_sgl)
goto out;
- }
tv_cmd->tvc_upages = kzalloc(sizeof(struct page *) *
VHOST_SCSI_PREALLOC_UPAGES, GFP_KERNEL);
- if (!tv_cmd->tvc_upages) {
- pr_err("Unable to allocate tv_cmd->tvc_upages\n");
+ if (!tv_cmd->tvc_upages)
goto out;
- }
tv_cmd->tvc_prot_sgl = kzalloc(sizeof(struct scatterlist) *
VHOST_SCSI_PREALLOC_PROT_SGLS, GFP_KERNEL);
- if (!tv_cmd->tvc_prot_sgl) {
- pr_err("Unable to allocate tv_cmd->tvc_prot_sgl\n");
+ if (!tv_cmd->tvc_prot_sgl)
goto out;
- }
}
return 0;
out:
@@ -1760,6 +1753,5 @@ static int vhost_scsi_make_nexus(struct vhost_scsi_tpg
*tpg,
if (!tv_nexus) {
mutex_unlock(&tpg->tv_tpg_mutex);
- pr_err("Unable to allocate struct vhost_scsi_nexus\n");
return -ENOMEM;
}
/*
@@ -1961,7 +1953,6 @@ vhost_scsi_make_tpg(struct se_wwn *wwn,
- if (!tpg) {
- pr_err("Unable to allocate struct vhost_scsi_tpg");
+ if (!tpg)
return ERR_PTR(-ENOMEM);
- }
+
mutex_init(&tpg->tv_tpg_mutex);
INIT_LIST_HEAD(&tpg->tv_tpg_list);
tpg->tport = tport;
@@ -2015,7 +2006,6 @@ vhost_scsi_make_tport(struct target_fabric_configfs *tf,
- if (!tport) {
- pr_err("Unable to allocate struct vhost_scsi_tport");
+ if (!tport)
return ERR_PTR(-ENOMEM);
- }
+
tport->tport_wwpn = wwpn;
/*
* Determine the emulated Protocol Identifier and Target Port Name
--
2.13.0
CHIPPro NAND issue with 4.12 rc1
Hi All,
I'm trying to boot a CHIPPro with the stock 4.12 rc1 kernel. If I make
no modifications to the sun5i-gr8-chip-pro.dtb the kernel boots but
can't find the root partition.
So I added the partitions to the dts file
diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
index c55b11a..0e61e6b 100644
--- a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
+++ b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
@@ -146,6 +146,32 @@
reg = <0>;
allwinner,rb = <0>;
nand-ecc-mode = "hw";
+nand-on-flash-bbt;
+
+spl@0 {
+ label = "SPL";
+ reg = /bits/ 64 <0x0 0x40>;
+};
+
+spl-backup@40 {
+ label = "SPL.backup";
+ reg = /bits/ 64 <0x40 0x40>;
+};
+
+u-boot@80 {
+ label = "U-Boot";
+ reg = /bits/ 64 <0x80 0x40>;
+};
+
+env@c0 {
+ label = "env";
+ reg = /bits/ 64 <0xc0 0x40>;
+};
+
+rootfs@100 {
+ label = "rootfs";
+ reg = /bits/ 64 <0x100 0x1f00>;
+};
};
};
and now the kernel finds the partition but it times out trying to mount
it. It seems to be something in the dts files because if I use the
ntc-gr8-crumb.dts from the ntc 4.4.30 kernel then the system boots all
the way to userland.
[7.13] ubi0: scanning is finished
[7.15] ubi0: attached mtd4 (name "rootfs", size 496 MiB)
[7.16] ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 258048
bytes
[7.17] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size
1024
[7.18] ubi0: VID header offset: 1024 (aligned 1024), data
offset: 4096
[7.19] ubi0: good PEBs: 1977, bad PEBs: 7, corrupted PEBs: 0
[7.20] ubi0: user volume: 1, internal volumes: 1, max. volumes
count: 128
[7.21] ubi0: max/mean erase counter: 3/1, WL threshold: 4096,
image sequence number: 177407
[7.22] ubi0: available PEBs: 1, total reserved PEBs: 1976, PEBs
reserved for bad PEB handling: 33
[7.24] hctosys: unable to open rtc device (rtc0)
[7.25] vcc3v0: disabling
[7.25] ALSA device list:
[7.26] #0: sun4i-codec
[7.26] ubi0: background thread "ubi_bgt0d" started, PID 53
[8.32] sunxi_nand 1c03000.nand: wait interrupt timedout
[9.32] sunxi_nand 1c03000.nand: wait interrupt timedout
[ 10.33] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 11.34] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 12.35] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 13.36] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 14.37] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 14.38] ubi0 warning: ubi_io_read: error -110 while reading 4096
bytes from PEB 1034:4096, read only 0 bytes, retry
[ 15.39] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 16.40] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 17.41] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 18.42] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 19.43] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 20.44] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 21.44] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 22.45] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 23.46] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 23.47] ubi0 warning: ubi_io_read: error -110 while reading 4096
bytes from PEB 1034:4096, read only 0 bytes, retry
[ 24.48] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 25.49] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 26.50] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 27.51] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 28.51] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 29.52] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 30.53] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 31.54] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 32.54] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 32.55] ubi0 warning: ubi_io_read: error -110 while reading 4096
bytes from PEB 1034:4096, read only 0 bytes, retry
[ 32.55] ubi0 warning: ubi_io_read: error -110 while reading 4096
bytes from PEB 1034:4096, read only 0 bytes, retry
[ 33.56] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 34.57] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 35.58] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 36.59] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 37.60] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
[ 38.60] sunxi_nand 1c03000.nand: wait for empty
Re: CHIPPro NAND issue with 4.12 rc1
Le Sat, 20 May 2017 08:49:04 -0600,
Angus Ainslie a écrit :
> Hi All,
>
> I'm trying to boot a CHIPPro with the stock 4.12 rc1 kernel. If I make
> no modifications to the sun5i-gr8-chip-pro.dtb the kernel boots but
> can't find the root partition.
>
> So I added the partitions to the dts file
>
> diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
> b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
> index c55b11a..0e61e6b 100644
> --- a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
> +++ b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
> @@ -146,6 +146,32 @@
> reg = <0>;
> allwinner,rb = <0>;
> nand-ecc-mode = "hw";
> +nand-on-flash-bbt;
> +
> +spl@0 {
> + label = "SPL";
> + reg = /bits/ 64 <0x0 0x40>;
> +};
> +
> +spl-backup@40 {
> + label = "SPL.backup";
> + reg = /bits/ 64 <0x40 0x40>;
> +};
> +
> +u-boot@80 {
> + label = "U-Boot";
> + reg = /bits/ 64 <0x80 0x40>;
> +};
> +
> +env@c0 {
> + label = "env";
> + reg = /bits/ 64 <0xc0 0x40>;
> +};
> +
> +rootfs@100 {
> + label = "rootfs";
> + reg = /bits/ 64 <0x100 0x1f00>;
> +};
> };
> };
>
> and now the kernel finds the partition but it times out trying to mount
> it. It seems to be something in the dts files because if I use the
> ntc-gr8-crumb.dts from the ntc 4.4.30 kernel then the system boots all
> the way to userland.
Hm, that's weird. Just changing the dtb makes it work? Did you try to
dump both dtbs and figure out what else changes?
Also, I wonder how the NAND is correctly detected without this patch
[1].
>
> [7.13] ubi0: scanning is finished
> [7.15] ubi0: attached mtd4 (name "rootfs", size 496 MiB)
> [7.16] ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 258048
> bytes
> [7.17] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size
> 1024
> [7.18] ubi0: VID header offset: 1024 (aligned 1024), data
> offset: 4096
> [7.19] ubi0: good PEBs: 1977, bad PEBs: 7, corrupted PEBs: 0
> [7.20] ubi0: user volume: 1, internal volumes: 1, max. volumes
> count: 128
> [7.21] ubi0: max/mean erase counter: 3/1, WL threshold: 4096,
> image sequence number: 177407
> [7.22] ubi0: available PEBs: 1, total reserved PEBs: 1976, PEBs
> reserved for bad PEB handling: 33
UBI attach works...
> [7.24] hctosys: unable to open rtc device (rtc0)
> [7.25] vcc3v0: disabling
> [7.25] ALSA device list:
> [7.26] #0: sun4i-codec
> [7.26] ubi0: background thread "ubi_bgt0d" started, PID 53
> [8.32] sunxi_nand 1c03000.nand: wait interrupt timedout
> [9.32] sunxi_nand 1c03000.nand: wait interrupt timedout
> [ 10.33] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 11.34] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 12.35] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 13.36] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 14.37] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 14.38] ubi0 warning: ubi_io_read: error -110 while reading 4096
> bytes from PEB 1034:4096, read only 0 bytes, retry
And suddenly you get timeouts. That's really weird.
[1]https://github.com/NextThingCo/linux/commit/5ebc35ce1223ef14ace9479d5f97d0fce979e550
Re: [PATCH v2 00/18] ARM64: meson: DT cleanups
Hi Kevin, Am 17.05.2017 um 23:46 schrieb Kevin Hilman: > Andreas Färber writes: >> This series fixes several cosmetic issues, on top of your for-next branch. >> >> Patches 3-6 rename a node, the rest should all be non-functional changes. >> >> PLEASE STOP merging random new nodes at the bottom of DT files! >> Just like it's a convention to sort new nodes by unit address, it has been >> a convention to sort by-label nodes by their label. As discussed here and >> elsewhere, this helps avoid merge conflicts and makes nodes easy to find. >> I don't care whether we order A0 before A or after, but adding new HDMI >> or CVBS nodes at the very bottom is totally out of alphabetical order. >> Since my v1 you really should've known that... > > Your tone is a bit tiresome and frankly makes me hesitate before > reviewing the patches. If you expect cordial dialogue and producitve > collaboration, please dial the accusations back a notch. I have sketched the history in another reply, maybe you understand the sentiments better now. I was annoyed to see that contributions by several people made the problem worse than it was originally. I.e., my v1 fix and now v2 grew more invasive because the issue did not get contained, not just not fixed. Rebasing this branch was no fun. [snip] I will continue to point things out in review or hindsight where I can, but as explained to Martin, this is not something I can continuously do in the pace that BayLibre's nice driver contributions have led to. As for the question of ownership, there should be no doubt that I not only factually contributed meson-gxbb DT files but also figured out how to get any kernel to boot on S905 with the old vendor U-Boot and fixed serial output and added earlycon. That was before BayLibre stepped in. So from my perspective all your contributions are based on my pioneering S905 work (and my work in turn reused Carlo's S805 meson_uart etc.), and I will not react well when some BayLibre employee not initially involved with those efforts (Neil) now tells me to shut up and pretends as if he makes the rules now just because his colleague stepped up as maintainer. The ordering rules I applied here are not my invention but things I picked on from previous reviews. You yourself had stated that I could resend the patches and explain why - Russell and I already gave some reasons, and there were no responses, which I took as no opposition and was frankly surprised about the renewed level of opposition. More generally, if a fix makes sense on its own and has no dependencies, then I personally prefer it getting applied after reviews. If there's a rule/reason for requiring full-series resends in Linux, it hasn't been explained to me yet. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
[PATCH] pinctrl: single: use of_device_get_match_data() to get soc data
Use of_device_get_match_data() instead of of_match_device().
It allows us to remove the forward declaration of pcs_of_match.
Signed-off-by: Masahiro Yamada
---
drivers/pinctrl/pinctrl-single.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 9c267dc..b8b3d93 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1270,8 +1270,6 @@ static void pcs_free_resources(struct pcs_device *pcs)
#endif
}
-static const struct of_device_id pcs_of_match[];
-
static int pcs_add_gpio_func(struct device_node *node, struct pcs_device *pcs)
{
const char *propname = "pinctrl-single,gpio-range";
@@ -1637,15 +1635,14 @@ static int pcs_quirk_missing_pinctrl_cells(struct
pcs_device *pcs,
static int pcs_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- const struct of_device_id *match;
struct pcs_pdata *pdata;
struct resource *res;
struct pcs_device *pcs;
const struct pcs_soc_data *soc;
int ret;
- match = of_match_device(pcs_of_match, &pdev->dev);
- if (!match)
+ soc = of_device_get_match_data(&pdev->dev);
+ if (WARN_ON(!soc))
return -EINVAL;
pcs = devm_kzalloc(&pdev->dev, sizeof(*pcs), GFP_KERNEL);
@@ -1658,7 +1655,6 @@ static int pcs_probe(struct platform_device *pdev)
raw_spin_lock_init(&pcs->lock);
mutex_init(&pcs->mutex);
INIT_LIST_HEAD(&pcs->gpiofuncs);
- soc = match->data;
pcs->flags = soc->flags;
memcpy(&pcs->socdata, soc, sizeof(*soc));
--
2.7.4
Re: [PATCH] iio: light: isl29018: Only declare ACPI table when ACPI is enabled
On 19/05/17 22:57, Guenter Roeck wrote:
On Fri, May 19, 2017 at 2:28 PM, Matthias Kaehlcke wrote:
This fixes the following warning when building with clang:
drivers/iio/light/isl29018.c:808:36: error: variable
'isl29018_acpi_match' is not needed and will not be emitted
[-Werror,-Wunneeded-internal-declaration]
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Guenter Roeck
I wondered if we would be slightly neater if we went with
__maybe_unused markings but realised I didn't really care enough
to make you respin the patch ;) So if anyone else has strong
feelings on the two options, shout out now.
Applied to the togreg branch of iio.git and pushed out as testing.
Thanks,
Jonathan
---
drivers/iio/light/isl29018.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iio/light/isl29018.c b/drivers/iio/light/isl29018.c
index 917dd8b43e72..61f5924b472d 100644
--- a/drivers/iio/light/isl29018.c
+++ b/drivers/iio/light/isl29018.c
@@ -807,6 +807,7 @@ static SIMPLE_DEV_PM_OPS(isl29018_pm_ops, isl29018_suspend,
isl29018_resume);
#define ISL29018_PM_OPS NULL
#endif
+#ifdef CONFIG_ACPI
static const struct acpi_device_id isl29018_acpi_match[] = {
{"ISL29018", isl29018},
{"ISL29023", isl29023},
@@ -814,6 +815,7 @@ static const struct acpi_device_id isl29018_acpi_match[] = {
{},
};
MODULE_DEVICE_TABLE(acpi, isl29018_acpi_match);
+#endif
static const struct i2c_device_id isl29018_id[] = {
{"isl29018", isl29018},
--
2.13.0.303.g4ebf302169-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] i2c: i2c-tiny-usb: fix buffer not being DMA capable
Hi,
ping?
This fixes a regression making the driver effectively useless.
-- Sebastian
On Fri, May 05, 2017 at 11:06:50AM +0200, Sebastian Reichel wrote:
> Since v4.9 i2c-tiny-usb generates the below call trace
> and longer works, since it can't communicate with the
> USB device. The reason is, that since v4.9 the USB
> stack checks, that the buffer it should transfer is DMA
> capable. This was a requirement since v2.2 days, but it
> usually worked nevertheless.
>
> [ 17.504959] [ cut here ]
> [ 17.505488] WARNING: CPU: 0 PID: 93 at drivers/usb/core/hcd.c:1587
> usb_hcd_map_urb_for_dma+0x37c/0x570
> [ 17.506545] transfer buffer not dma capable
> [ 17.507022] Modules linked in:
> [ 17.507370] CPU: 0 PID: 93 Comm: i2cdetect Not tainted 4.11.0-rc8+ #10
> [ 17.508103] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 17.509039] Call Trace:
> [ 17.509320] ? dump_stack+0x5c/0x78
> [ 17.509714] ? __warn+0xbe/0xe0
> [ 17.510073] ? warn_slowpath_fmt+0x5a/0x80
> [ 17.510532] ? nommu_map_sg+0xb0/0xb0
> [ 17.510949] ? usb_hcd_map_urb_for_dma+0x37c/0x570
> [ 17.511482] ? usb_hcd_submit_urb+0x336/0xab0
> [ 17.511976] ? wait_for_completion_timeout+0x12f/0x1a0
> [ 17.512549] ? wait_for_completion_timeout+0x65/0x1a0
> [ 17.513125] ? usb_start_wait_urb+0x65/0x160
> [ 17.513604] ? usb_control_msg+0xdc/0x130
> [ 17.514061] ? usb_xfer+0xa4/0x2a0
> [ 17.514445] ? __i2c_transfer+0x108/0x3c0
> [ 17.514899] ? i2c_transfer+0x57/0xb0
> [ 17.515310] ? i2c_smbus_xfer_emulated+0x12f/0x590
> [ 17.515851] ? _raw_spin_unlock_irqrestore+0x11/0x20
> [ 17.516408] ? i2c_smbus_xfer+0x125/0x330
> [ 17.516876] ? i2c_smbus_xfer+0x125/0x330
> [ 17.517329] ? i2cdev_ioctl_smbus+0x1c1/0x2b0
> [ 17.517824] ? i2cdev_ioctl+0x75/0x1c0
> [ 17.518248] ? do_vfs_ioctl+0x9f/0x600
> [ 17.518671] ? vfs_write+0x144/0x190
> [ 17.519078] ? SyS_ioctl+0x74/0x80
> [ 17.519463] ? entry_SYSCALL_64_fastpath+0x1e/0xad
> [ 17.519959] ---[ end trace d047c04982f5ac50 ]---
>
> Cc:
> Signed-off-by: Sebastian Reichel
> ---
> Changes since PATCHv1:
> - update patch description, drop # v4.9+ from stable cc
> - add missing checks for kmemdup/kmalloc
> ---
> drivers/i2c/busses/i2c-tiny-usb.c | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tiny-usb.c
> b/drivers/i2c/busses/i2c-tiny-usb.c
> index 0ed77eeff31e..a2e3dd715380 100644
> --- a/drivers/i2c/busses/i2c-tiny-usb.c
> +++ b/drivers/i2c/busses/i2c-tiny-usb.c
> @@ -178,22 +178,39 @@ static int usb_read(struct i2c_adapter *adapter, int
> cmd,
> int value, int index, void *data, int len)
> {
> struct i2c_tiny_usb *dev = (struct i2c_tiny_usb *)adapter->algo_data;
> + void *dmadata = kmalloc(len, GFP_KERNEL);
> + int ret;
> +
> + if (!dmadata)
> + return -ENOMEM;
>
> /* do control transfer */
> - return usb_control_msg(dev->usb_dev, usb_rcvctrlpipe(dev->usb_dev, 0),
> + ret = usb_control_msg(dev->usb_dev, usb_rcvctrlpipe(dev->usb_dev, 0),
> cmd, USB_TYPE_VENDOR | USB_RECIP_INTERFACE |
> -USB_DIR_IN, value, index, data, len, 2000);
> +USB_DIR_IN, value, index, dmadata, len, 2000);
> +
> + memcpy(data, dmadata, len);
> + kfree(dmadata);
> + return ret;
> }
>
> static int usb_write(struct i2c_adapter *adapter, int cmd,
>int value, int index, void *data, int len)
> {
> struct i2c_tiny_usb *dev = (struct i2c_tiny_usb *)adapter->algo_data;
> + void *dmadata = kmemdup(data, len, GFP_KERNEL);
> + int ret;
> +
> + if (!dmadata)
> + return -ENOMEM;
>
> /* do control transfer */
> - return usb_control_msg(dev->usb_dev, usb_sndctrlpipe(dev->usb_dev, 0),
> + ret = usb_control_msg(dev->usb_dev, usb_sndctrlpipe(dev->usb_dev, 0),
> cmd, USB_TYPE_VENDOR | USB_RECIP_INTERFACE,
> -value, index, data, len, 2000);
> +value, index, dmadata, len, 2000);
> +
> + kfree(dmadata);
> + return ret;
> }
>
> static void i2c_tiny_usb_free(struct i2c_tiny_usb *dev)
> --
> 2.11.0
>
signature.asc
Description: PGP signature
Re: [PATCH 7/7] DWARF: add the config option
On Fri, May 19, 2017 at 10:23:53PM -0700, Andy Lutomirski wrote:
> On Fri, May 19, 2017 at 2:35 PM, Josh Poimboeuf wrote:
> > On Fri, May 19, 2017 at 04:29:13PM -0500, Josh Poimboeuf wrote:
> >> > How are you handling control flow?
> >>
> >> Control flow of what?
> >>
> >> > > Here's the struct in its current state:
> >> > >
> >> > > #define UNDWARF_REG_UNDEFINED 0
> >> > > #define UNDWARF_REG_CFA 1
> >> > > #define UNDWARF_REG_SP 2
> >> > > #define UNDWARF_REG_FP 3
> >> > > #define UNDWARF_REG_SP_INDIRECT 4
> >> > > #define UNDWARF_REG_FP_INDIRECT 5
> >> > > #define UNDWARF_REG_R10 6
> >> > > #define UNDWARF_REG_DI 7
> >> > > #define UNDWARF_REG_DX 8
> >> > >
> >> >
> >> > Why only those registers? Also, if you have the option I would really
> >> > suggest using the actual x86 register numbers (ax, ex, dx, bx, sp, bp,
> >> > si, di, r8-r15 in that order.)
> >>
> >> Those are the only registers which are ever needed as the base for
> >> finding the previous stack frame. 99% of the time it's sp or bp, the
> >> other registers are needed for aligned stacks and entry code.
> >>
> >> Using the actual register numbers isn't an option because I don't need
> >> them all and they need to fit in a small number of bits.
> >>
> >> This construct might be useful for other arches, which is why I called
> >> it "FP" instead of "BP". But then I ruined that with the last 3 :-)
> >
> > BTW, here's the link to the unwinder code if you're interested:
> >
> >
> > https://github.com/jpoimboe/linux/blob/undwarf/arch/x86/kernel/unwind_undwarf.c
>
> At the risk of potentially overcomplicating matters, here's a
> suggestion. As far as I know, all (or most all?) unwinders
> effectively do the following in a loop:
>
> 1. Look up the IP to figure out how to unwind from that IP.
> 2. Use the results of that lookup to compute the previous frame state.
>
> The results of step 1 could perhaps be expressed like this:
>
> struct reg_formula {
> unsigned int source_reg :4;
> long offset;
> bool dereference; /* true: *(reg + offset); false: (reg + offset) */
> /* For DWARF, I think this can be considerably more complicated, but
> I doubt it's useful. */
> };
>
> struct unwind_step {
> u16 available_regs; /* mask of the caller frame regs that we are
> able to recover */
> struct reg_formula[16];
> };
Ok, so I assume you mean we would need to have an in-kernel DWARF reader
which reads .eh_frame and converts it to the above, which is called for
every step of the unwind phase.
> The CFA computation is just reg_formula[UNWIND_REG_SP] (or that plus
> or minus sizeof(unsigned long) or whatever -- I can never remember
> exactly what CFA refers to.) For a frame pointer-based unwinder, the
> entire unwind_step is a foregone conclusion independent of IP: SP = BP
> + 8 (or whatever), BP = *(BP + whatever), all other regs unknown.
>
> Could it make sense to actually structure the code this way? I can
> see a few advantages. It would make the actual meat of the unwind
> loop totally independent of the unwinding algorithm in use,
Yes, this part of it is an interesting idea, separating the debuginfo
reading step from the unwinding step. And for people who don't want to
carry around megs of DWARF data, get_dwarf_step() could just be a fake
lookup which always returns the frame pointer version.
> it would
> make the meat be dead simple (and thus easy to verify for
> non-crashiness), and I think it just might open the door for a real
> in-kernel DWARF unwinder that Linus would be okay with. Specifically,
> write a function like:
>
> bool get_dwarf_step(struct unwind_step *step, unsigned long ip);
If we keep the frame pointer encoding thing for non-DWARF kernels then
we may also need to pass in bp as well.
Or maybe we could force frame pointer users to at least have DWARF data
for the entry code. Then even frame pointer kernels could detect entry
regs and we could get rid of that nasty frame pointer encoding thing.
> Put this function in its own file and make it buildable as kernel code
> or as user code. Write a test case that runs it on every single
> address on the kernel image (in user mode!) with address-sanitizer
> enabled (or in Valgrind or both) and make sure that (a) it doesn't
> blow up and (b) that the results are credible (e.g. by comparing to
> objtool output). Heck, you could even fuzz-test it where the fuzzer
> is allowed to corrupt the actual DWARF data. You could do the same
> thing with whatever crazy super-compacted undwarf scheme someone comes
> up with down the road, too.
I think your proposal can be separated into two ideas, which can each be
considered on their own merit:
1) Put .eh_frame in the kernel, along with an in-kernel DWARF unwinder.
Manage the complexity of the unwinder by validating the output of the
complex part of the algorithm in
Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts
On Fri, 19 May 2017 20:21:54 -0600 Sam Povilus wrote: > The number of xilinx ps uart should be set by a kernel parameter instead of > using a #define. This allows the user to set the number of xilinx ps uart > using only kconfig and not modifying kernel source. > > The ps uart is used in Xilnx Zynq chips usually in quantities maxing at > two, but there may be other chips that use more in the future or that I > don't know about. If it maxes at two then just set it to two. If in in future it maxes at lots then when it's going to happen change the code to do dynamic allocation and test it versus actual hardware. Otherwise you break some of the basic ideas of having one kernel for many systems. Alan
Re: [PATCH] iio: adc: Add support for TI ADC1x8s102
On 19/05/17 17:01, Mark Brown wrote: On Thu, Apr 27, 2017 at 07:01:07AM +0100, Jonathan Cameron wrote: Somewhat of a pain to basically use a random value as the default going forward. Presumably this isn't the first ever ACPI table to need to tell use about a reference voltage... Mark, seen anything similar? I see https://www.kernel.org/doc/Documentation/arm64/arm-acpi.txt suggests that mapping to regulators isn't expected to ever happen... There's multiple different camps trying to use ACPI for very different things. There's the server people on both x86 and ARM who want to use standard ACPI and nothing but with the power management all hidden in the AML but there's also the embedded x86 people who have the same needs as DT platforms but find themselves unable to use DT so have to map all the DT support into ACPI. This has been accepted in areas that clearly don't overlap with areas where there are existing ACPI bindings for things, power management is one area where there are clear bindings though. Thanks Mark, Just to clarify what do we do here, where a regulator is providing a reference voltage and there appears to be no information on it in ACPI? Right now we are just going with a fixed value that matches the board someone has, but that's hardly sustainable. Jonathan
Re: [PATCHv2] watchdog: core: add option to avoid early handling of watchdog
Hi, On Tue, May 16, 2017 at 12:08:32AM +0200, Rasmus Villemoes wrote: > On Sun, May 14 2017, Guenter Roeck wrote: > > > On 05/12/2017 05:05 AM, Sebastian Reichel wrote: > >> On some systems its desirable to have watchdog reboot the system > >> when it does not come up fast enough. This adds a kernel parameter > >> to disable the auto-update of watchdog before userspace takes over > >> and a kernel option to set the default. The info messages were > >> added to shorten error searching on misconfigured systems. > >> > >> Signed-off-by: Sebastian Reichel > > > > Minor nitpicks below (which I fixed up in my watchdog-next branch). > > Otherwise > > Guenter, Sebastian, can I pursuade you to take a (second) look at the > patches [1] I sent 4 months ago that implement the same thing, except > that they also give a .config and a boot-cmdline way to define what > "fast enough" means - which is necessary in many cases where it's simply > not realistic to have userspace up-and-running before the dog is hungry. > > [1] https://lkml.org/lkml/2017/1/9/408 > > I'm of course happy to rebase and retest those on top of current master, > but the implementation and semantics should be reviewable as-is. I wasn't aware of your work. For the hardware I work with at Collabora my patch is enough, since "fast enough" is defined by correct watchdog configuration (done by the bootloader). I guess something like your patch is required for systems, which do not reach userspace in < 60 seconds (minus some safety margin). This is not needed by us. OTOH your patches should also work for our use case. -- Sebastian signature.asc Description: PGP signature
Re: linux-next: stats (Was: Linux 4.12-rc1)
Hi Stephen, On Tue, May 16, 2017 at 07:32:09AM +1000, Stephen Rothwell wrote: > On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel wrote: > > On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote: > > > There are also 288 commits in next-20170502 that didn't make it into > > > v4.12-rc1. > > > > > > [...] > > > > > > Top ten commiters: > > > > > > 66 s...@canb.auug.org.au > > > 47 paul...@linux.vnet.ibm.com > > > 34 t...@linutronix.de > > > 23 li...@roeck-us.net > > > 14 alexandre.bell...@free-electrons.com > > > 11 p...@axentia.se > > > 9 quwen...@cn.fujitsu.com > > > 8 o...@lixom.net > > > 7 s...@kernel.org > > > 5 mathieu.poir...@linaro.org > > > > Did you compile the list today? I started adding content for 4.13 > > after Linus tagged v4.12-rc1 and my power-supply for-next branch > > curently has exactly 7 patches. > > As I said above these are commits that were in linux-next on May 2nd > but were not in v4.12-rc1 oh, I missed that. > 99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support > ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support > a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods > 7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery > documentation > fb38342a5ae6 power: supply: core: add power_supply_battery_info and API > bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units > ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding > > There can be various reasons that they didn't make it in and, in fact, > these are not in yesterday's linux-next either. Thanks, I forgot about those when I wrote my mail. The patch author asked me to drop them for 4.12 due to some problems. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH 1/4] iio: hi8435: add raw access
On 19/05/17 15:47, Nikita Yushchenko wrote:
With current event-only driver, it is not possible for user space
application to know current senses if they don't change since
application starts.
Address that by adding raw access to channels.
Signed-off-by: Nikita Yushchenko
Ideally I'd like Vladimir's ack on these, but I am going to guess
that he is fine with this and rely on him shouting if not ;)
Applied to the togreg branch of iio.git and pushed out as testing.
Thanks,
Jonathan
---
drivers/iio/adc/hi8435.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/iio/adc/hi8435.c b/drivers/iio/adc/hi8435.c
index 678e8c7ea763..cb8e6342eddf 100644
--- a/drivers/iio/adc/hi8435.c
+++ b/drivers/iio/adc/hi8435.c
@@ -105,6 +105,26 @@ static int hi8435_writew(struct hi8435_priv *priv, u8 reg,
u16 val)
return spi_write(priv->spi, priv->reg_buffer, 3);
}
+static int hi8435_read_raw(struct iio_dev *idev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct hi8435_priv *priv = iio_priv(idev);
+ u32 tmp;
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = hi8435_readl(priv, HI8435_SO31_0_REG, &tmp);
+ if (ret < 0)
+ return ret;
+ *val = !!(tmp & BIT(chan->channel));
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
static int hi8435_read_event_config(struct iio_dev *idev,
const struct iio_chan_spec *chan,
enum iio_event_type type,
@@ -333,6 +353,7 @@ static const struct iio_chan_spec_ext_info
hi8435_ext_info[] = {
.type = IIO_VOLTAGE,\
.indexed = 1, \
.channel = num, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.event_spec = hi8435_events,\
.num_event_specs = ARRAY_SIZE(hi8435_events), \
.ext_info = hi8435_ext_info,\
@@ -376,6 +397,7 @@ static const struct iio_chan_spec hi8435_channels[] = {
static const struct iio_info hi8435_info = {
.driver_module = THIS_MODULE,
+ .read_raw = hi8435_read_raw,
.read_event_config = &hi8435_read_event_config,
.write_event_config = hi8435_write_event_config,
.read_event_value = &hi8435_read_event_value,
Re: [PATCH 2/4] iio: hi8435: avoid garbage event at first enable
On 19/05/17 15:48, Nikita Yushchenko wrote:
Currently, driver generates events for channels if new reading differs
from previous one. This "previous value" is initialized to zero, which
results into event if value is constant-one.
Fix that by initializing "previous value" by reading at event enable
time.
This provides reliable sequence for userspace:
- enable event,
- AFTER THAT read current value,
- AFTER THAT each event will correspond to change.
Signed-off-by: Nikita Yushchenko
I'm hoping there aren't any userspace apps out there relying on this
'unusual' behaviour. *cross fingers*
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
---
drivers/iio/adc/hi8435.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/hi8435.c b/drivers/iio/adc/hi8435.c
index cb8e6342eddf..45a92e3e8f2b 100644
--- a/drivers/iio/adc/hi8435.c
+++ b/drivers/iio/adc/hi8435.c
@@ -141,10 +141,21 @@ static int hi8435_write_event_config(struct iio_dev *idev,
enum iio_event_direction dir, int state)
{
struct hi8435_priv *priv = iio_priv(idev);
+ int ret;
+ u32 tmp;
+
+ if (state) {
+ ret = hi8435_readl(priv, HI8435_SO31_0_REG, &tmp);
+ if (ret < 0)
+ return ret;
+ if (tmp & BIT(chan->channel))
+ priv->event_prev_val |= BIT(chan->channel);
+ else
+ priv->event_prev_val &= ~BIT(chan->channel);
- priv->event_scan_mask &= ~BIT(chan->channel);
- if (state)
priv->event_scan_mask |= BIT(chan->channel);
+ } else
+ priv->event_scan_mask &= ~BIT(chan->channel);
return 0;
}
Re: [PATCH 3/4] iio: hi8435: make in_voltage_sensing_mode_available visible
On 19/05/17 15:48, Nikita Yushchenko wrote:
Possible values of sensing_mode are encoded with strings and actual
atrings used are not obvious.
strings
Provide a hint by enabling in_voltage_sensing_mode_available attribute.
Signed-off-by: Nikita Yushchenko
Applied to the togreg branch of iio.git and pushed out as testing.
Thanks,
Jonathan
---
drivers/iio/adc/hi8435.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/adc/hi8435.c b/drivers/iio/adc/hi8435.c
index 45a92e3e8f2b..d09cb6ff8044 100644
--- a/drivers/iio/adc/hi8435.c
+++ b/drivers/iio/adc/hi8435.c
@@ -356,6 +356,7 @@ static const struct iio_enum hi8435_sensing_mode = {
static const struct iio_chan_spec_ext_info hi8435_ext_info[] = {
IIO_ENUM("sensing_mode", IIO_SEPARATE, &hi8435_sensing_mode),
+ IIO_ENUM_AVAILABLE("sensing_mode", &hi8435_sensing_mode),
{},
};
Re: [PATCH 4/4] iio: hi8435: cleanup reset gpio
On 19/05/17 15:48, Nikita Yushchenko wrote:
Reset GPIO is active low.
Currently driver uses gpiod_set_value(1) to clean reset, which depends
on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.
This fixes driver to use _raw version of gpiod_set_value() to enforce
active-low semantics despite of what's written in device tree. Allowing
device tree to override that only opens possibility for errors and does
not add any value.
Additionally, use _cansleep version to make things work with i2c-gpio
and other sleeping gpio drivers.
Signed-off-by: Nikita Yushchenko
Hopefully we don't have any 'interesting' wiring schemes out there
that actually have a not gate on that wire.
Your argument seems sound to me so applied to the togreg branch
of iio.git and pushed out as testing for the autobuilders to play with
it.
Again, input from Vladimir would be particularly welcome!
Jonathan
---
drivers/iio/adc/hi8435.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/hi8435.c b/drivers/iio/adc/hi8435.c
index d09cb6ff8044..ab59969b7c49 100644
--- a/drivers/iio/adc/hi8435.c
+++ b/drivers/iio/adc/hi8435.c
@@ -476,13 +476,15 @@ static int hi8435_probe(struct spi_device *spi)
priv->spi = spi;
reset_gpio = devm_gpiod_get(&spi->dev, NULL, GPIOD_OUT_LOW);
- if (IS_ERR(reset_gpio)) {
- /* chip s/w reset if h/w reset failed */
+ if (!IS_ERR(reset_gpio)) {
+ /* need >=100ns low pulse to reset chip */
+ gpiod_set_raw_value_cansleep(reset_gpio, 0);
+ udelay(1);
+ gpiod_set_raw_value_cansleep(reset_gpio, 1);
+ } else {
+ /* s/w reset chip if h/w reset is not available */
hi8435_writeb(priv, HI8435_CTRL_REG, HI8435_CTRL_SRST);
hi8435_writeb(priv, HI8435_CTRL_REG, 0);
- } else {
- udelay(5);
- gpiod_set_value(reset_gpio, 1);
}
spi_set_drvdata(spi, idev);
Re: Widespread crashes in -next, bisected to 'mm: drop HASH_ADAPT'
The problem is due to 32-bit integer overflow in:
ADAPT_SCALE_BASE and adapt
In dcache_init_early() that is causing the problem. It was not enabled
before 'mm: drop HASH_ADAPT' but is enabled now, and it should follow
right after: "PID hash table entries: 1024 (order: 0, 4096 bytes)"
main()
pidhash_init();
vfs_caches_init_early();
dcache_init_early()
alloc_large_system_hash("Dentry cache", ...)
for (adapt = ADAPT_SCALE_NPAGES; adapt < numentries;
adapt <<= ADAPT_SCALE_SHIFT)
numentries is very small, so it should be always smaller than adapt,
and algorithm should not kick in, but 32-bit causes adapt to be smaller
than numentries.
I will send out an updated "mm: Adaptive hash table scaling", with "mm:
drop HASH_ADAPT" integrated.
Pasha
On 05/20/2017 10:21 AM, Guenter Roeck wrote:
On 05/20/2017 12:26 AM, Michal Hocko wrote:
On Fri 19-05-17 09:46:23, Guenter Roeck wrote:
Hi,
my qemu tests of next-20170519 show the following results:
total: 122 pass: 30 fail: 92
I won't bother listing all of the failures; they are available at
http://kerneltests.org/builders. I bisected one (openrisc, because
it gives me some console output before dying). It points to
'mm: drop HASH_ADAPT' as the culprit. Bisect log is attached.
A quick glance suggests that 64 bit kernels pass and 32 bit kernels
fail.
32-bit x86 images fail and should provide an easy test case.
Hmm, this is quite unexpected as the patch is not supposed to change
things much. It just removes the flag and perform the new hash scaling
It may well be that the problem is introduced with an earlier patch and
just
enabled by this one.
automatically for all requeusts which do not have any high limit.
Some of those didn't have HASH_ADAPT before but that shouldn't change
the picture much. The only thing that I can imagine is that what
formerly failed for early memblock allocations is now suceeding and that
depletes the early memory. Do you have any serial console from the boot?
They are all the same. Either nothing or the following. Picking a couple:
metag:
Linux version 4.12.0-rc1-next-20170519 (gro...@jupiter.roeck-us.net)
(gcc version 4.2.4 (IMG-1.4.0.300)) #1 Fri May 19 00:50:50 PDT 2017
LNKGET/SET go through cache but CONFIG_METAG_LNKGET_AROUND_CACHE=y
DA present
console [ttyDA1] enabled
OF: fdt: Machine model: toumaz,tz1090
Machine name: Generic Meta
Node 0: start_pfn = 0xb, low = 0xbfff7
Zone ranges:
Normal [mem 0xb000-0xbfff6fff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0xb000-0xbfff6fff]
Initmem setup node 0 [mem 0xb000-0xbfff6fff]
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65015
Kernel command line: rdinit=/sbin/init doreboot
PID hash table entries: 1024 (order: 0, 4096 bytes)
crisv32:
Linux version 4.12.0-rc1-next-20170519 (gro...@desktop.roeck-us.net)
(gcc version 4.9.2 (Buildroot 2015.02-rc1-5-gb13bd8e-dirty) ) #1 Fri
May 19 00:52:55 PDT 2017
bootconsole [early0] enabled
Setting up paging and the MMU.
Linux/CRISv32 port on ETRAX FS (C) 2003, 2004 Axis Communications AB
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 4080
Kernel command line: console=ttyS0,115200,N,8 rdinit=/sbin/init
PID hash table entries: 128 (order: -4, 512 bytes)
powerpc:mpc8548cds:
Memory CAM mapping: 256 Mb, residual: 0Mb
Linux version 4.12.0-rc1-next-20170519 (gro...@jupiter.roeck-us.net)
(gcc version 4.8.1 (GCC) ) #1 Fri May 19 01:17:29 PDT 2017
Found initrd at 0xc400:0xc4200c00
Using MPC85xx CDS machine description
bootconsole [udbg0] enabled
-
phys_mem_size = 0x1000
dcache_bsize = 0x20
icache_bsize = 0x20
cpu_features = 0x12100460
possible= 0x12100460
always = 0x0010
cpu_user_features = 0x84e08000 0x0800
mmu_features = 0x00020010
-
mpc85xx_cds_setup_arch()
Could not find FPGA node.
Zone ranges:
DMA [mem 0x-0x0fff]
Normal empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x-0x0fff]
Initmem setup node 0 [mem 0x-0x0fff]
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: rdinit=/sbin/init console=ttyS0 console=tty doreboot
PID hash table entries: 1024 (order: 0, 4096 bytes)
Guenter
Re: [PATCH] rcu: mark debug_lockdep_rcu_enabled() as pure
On Fri, May 19, 2017 at 10:03:59AM +0300, Konstantin Khlebnikov wrote:
> This allows to get rid of unneeded invocations.
>
> Function debug_lockdep_rcu_enabled() becomes really hot if several
> debug options are enabled together with CONFIG_PROVE_RCU.
>
> Hottest path ends with:
> debug_lockdep_rcu_enabled
> is_ftrace_trampoline
> __kernel_text_address
>
> Here debug_lockdep_rcu_enabled() is called from condition
> (debug_lockdep_rcu_enabled() && !__warned && (c)) inside macro
> do_for_each_ftrace_op(), where "c" is false.
>
> With this patch "netperf -H localhost" shows boost from 2400 to 2500.
>
> Signed-off-by: Konstantin Khlebnikov
Nice performance increase!
The gcc documentation says that __attribute__((pure)) functions are
supposed to have return values that depend only at the function's
arguments and the values of global variables. However, it also says:
Interesting non-pure functions are functions with infinite loops
or those depending on volatile memory or other system resource,
that may change between two consecutive calls (such as feof in
a multithreading environment).
This is OK for current->lockdep_recursion because this variable is changed
only by the current task (I think so, anyway).
It is sort of OK for debug_locks. This could be set to zero at any time
by any other task, but if we have a race condition that very rarely causes
two lockdep splats instead of just one, so what? (But I am sure that
some of the people on CC will correct me if I am wrong here.)
It should be OK for rcu_scheduler_active because the transition from
RCU_SCHEDULER_INACTIVE to RCU_SCHEDULER_INIT happens before the first
context switch, and the various barrier() calls, implied as well as
explicit, should keep things straight.
But I don't totally trust my analysis. Could you please get someone
more gcc-savvy to review this and give their ack/review? Given that,
I will queue it.
Thanx, Paul
> ---
> include/linux/rcupdate.h |2 +-
> kernel/rcu/update.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index e1e5d002fdb9..9ecb3cb715bd 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -472,7 +472,7 @@ extern struct lockdep_map rcu_lock_map;
> extern struct lockdep_map rcu_bh_lock_map;
> extern struct lockdep_map rcu_sched_lock_map;
> extern struct lockdep_map rcu_callback_map;
> -int debug_lockdep_rcu_enabled(void);
> +int __pure debug_lockdep_rcu_enabled(void);
>
> int rcu_read_lock_held(void);
> int rcu_read_lock_bh_held(void);
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index 273e869ca21d..a0c30abefdcd 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -292,7 +292,7 @@ struct lockdep_map rcu_callback_map =
> STATIC_LOCKDEP_MAP_INIT("rcu_callback", &rcu_callback_key);
> EXPORT_SYMBOL_GPL(rcu_callback_map);
>
> -int notrace debug_lockdep_rcu_enabled(void)
> +int __pure notrace debug_lockdep_rcu_enabled(void)
> {
> return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE && debug_locks &&
> current->lockdep_recursion == 0;
>
[PATCH] extcon: qcom-spmi-misc: add dependency on ARCH_QCOM
Depend on the architecture the device actuall is in, also add dep on the compile test to ensure continued coverage. Signed-off-by: Peter Robinson --- drivers/extcon/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index 32f2dc8e4702..6d50071f07d5 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -115,6 +115,7 @@ config EXTCON_PALMAS config EXTCON_QCOM_SPMI_MISC tristate "Qualcomm USB extcon support" + depends on ARCH_QCOM || COMPILE_TEST help Say Y here to enable SPMI PMIC based USB cable detection support on Qualcomm PMICs such as PM8941. -- 2.13.0
[PATCH RFC] perf/callchain: fixup charset file header
Non-UTF-8 characters are a problem for some terminals and also make greping harder than necessary - this only switches the copyright sign to the common (C). Reported-by: Markus Kreidl Signed-off-by: Nicholas Mc Guire --- Found by checkpatch --strict: CHECK: Invalid UTF-8, patch and commit message should be encoded in UTF-8 #7: FILE: kernel/events/callchain.c:7: + * Copyright � 2009 Paul Mackerras, IBM Corp. Before I start generating sets of patches that fix encoding issues I would like to know if that is going to be accepted at all - the background is that it causes quite a bit of trouble when automating tools if these encoding problems make using simple tools hard (e.g. grep) and thus make automation a lot more complicated that necessary. It seems to me that the codingstyle does not mandate UTF-8 but there are a few places where it is "suggested" like in: Documentation/process/email-clients.rst This really should not have any impact on the code but patch was compile-tested with x86_64_defconfig (implies CONFIG_PERF_EVENTS) (issues two sparse warnings - not related though) Patch is against 4.12-rc1 (localversion-next is next-20170519) kernel/events/callchain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c index 1b2be63..357f488 100644 --- a/kernel/events/callchain.c +++ b/kernel/events/callchain.c @@ -4,7 +4,7 @@ * Copyright (C) 2008 Thomas Gleixner * Copyright (C) 2008-2011 Red Hat, Inc., Ingo Molnar * Copyright (C) 2008-2011 Red Hat, Inc., Peter Zijlstra - * Copyright � 2009 Paul Mackerras, IBM Corp. + * Copyright (C) 2009 Paul Mackerras, IBM Corp. * * For licensing details see kernel-base/COPYING */ -- 2.1.4
Re: [REGRESSION] Failed network caused by: xhci: switch to pci_alloc_irq_vectors
On Fri, May 19, 2017 at 5:46 AM, Christoph Hellwig wrote:
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 33c2b0b77429..5a7fd3b6a7b9 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1342,7 +1342,7 @@ pci_alloc_irq_vectors_affinity(struct pci_dev *dev,
> unsigned int min_vecs,
>unsigned int max_vecs, unsigned int flags,
>const struct irq_affinity *aff_desc)
> {
> - if (min_vecs > 1)
> + if (min_vecs > 1 || !(flags & PCI_IRQ_LEGACY))
> return -EINVAL;
> return 1;
> }
Side note: why is it doing that " > 1" check, when any value _other_
than 1 is wrong?
Also, to match the non-MSI implementation, wouldn't it be nicer to
just write it that same way (and also verify "dev->irq"):
if (flags & PCI_IRQ_LEGACY) {
if (min_vecs == 1 && dev->irq)
return 1;
}
return -ENOSPC;
(the exact error value probably doesn't matter in practice, but the
CONFIG_MSI case returns ENOSPC by default and that's what
Documentation/PCI/MSI-HOWTO.txt says too).
Hmm?
Linus
[PATCH] staging: vt6655: add spaces around '%' operator
Fix checkpatch issue by adding spaces around the '%' operator
Signed-off-by: Marko Stankovic
---
drivers/staging/vt6655/card.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c
index 5463cf869d1b..f5db2b3d9045 100644
--- a/drivers/staging/vt6655/card.c
+++ b/drivers/staging/vt6655/card.c
@@ -913,7 +913,7 @@ u64 CARDqGetTSFOffset(unsigned char byRxRate, u64 qwTSF1,
u64 qwTSF2)
{
unsigned short wRxBcnTSFOffst;
- wRxBcnTSFOffst = cwRXBCNTSFOff[byRxRate%MAX_RATE];
+ wRxBcnTSFOffst = cwRXBCNTSFOff[byRxRate % MAX_RATE];
qwTSF2 += (u64)wRxBcnTSFOffst;
--
2.11.0
Re: [REGRESSION] Failed network caused by: xhci: switch to pci_alloc_irq_vectors
On Sat, May 20, 2017 at 09:49:56AM -0700, Linus Torvalds wrote:
> Side note: why is it doing that " > 1" check, when any value _other_
> than 1 is wrong?
It's the same effect, so either one is fine with me.
> Also, to match the non-MSI implementation, wouldn't it be nicer to
> just write it that same way (and also verify "dev->irq"):
>
> if (flags & PCI_IRQ_LEGACY) {
> if (min_vecs == 1 && dev->irq)
> return 1;
> }
> return -ENOSPC;
>
> (the exact error value probably doesn't matter in practice, but the
> CONFIG_MSI case returns ENOSPC by default and that's what
> Documentation/PCI/MSI-HOWTO.txt says too).
Sure. Just sent the previous version to Bjorn so that he could maybe
make it for -rc2, but I'll respin it.
[PATCH v2] PCI/msi: fix the pci_alloc_irq_vectors_affinity stub
We need to return an error for any call that asks for MSI / MSI-X
vectors only, so that non-trivial fallback logic can work properly.
Also valid dev->irq and use the "correct" errno value based on feedback
from Linus.
Signed-off-by: Christoph Hellwig
Reported-by: Steven Rostedt
Fixes: aff17164 ("PCI: Provide sensible IRQ vector alloc/free routines")
---
Changes from V1:
- use == comparism
- return -ENOSPC
- verify dev->irq
include/linux/pci.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 33c2b0b77429..fc2e832d7b9c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1342,9 +1342,9 @@ pci_alloc_irq_vectors_affinity(struct pci_dev *dev,
unsigned int min_vecs,
unsigned int max_vecs, unsigned int flags,
const struct irq_affinity *aff_desc)
{
- if (min_vecs > 1)
- return -EINVAL;
- return 1;
+ if ((flags & PCI_IRQ_LEGACY) && min_vecs == 1 && dev->irq)
+ return 1;
+ return -ENOSPC;
}
static inline void pci_free_irq_vectors(struct pci_dev *dev)
--
2.11.0
[PATCH] usb: mtu3: cleanup with list_first_entry_or_null()
The combo of list_empty() and list_first_entry() can be replaced with
list_first_entry_or_null().
Signed-off-by: Masahiro Yamada
---
drivers/usb/mtu3/mtu3.h | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index aa6fd6a..7b6dc23 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -356,12 +356,8 @@ static inline struct mtu3_ep *to_mtu3_ep(struct usb_ep *ep)
static inline struct mtu3_request *next_request(struct mtu3_ep *mep)
{
- struct list_head *queue = &mep->req_list;
-
- if (list_empty(queue))
- return NULL;
-
- return list_first_entry(queue, struct mtu3_request, list);
+ return list_first_entry_or_null(&mep->req_list, struct mtu3_request,
+ list);
}
static inline void mtu3_writel(void __iomem *base, u32 offset, u32 data)
--
2.7.4
[v4 1/1] mm: Adaptive hash table scaling
Allow hash tables to scale with memory but at slower pace, when HASH_ADAPT
is provided every time memory quadruples the sizes of hash tables will only
double instead of quadrupling as well. This algorithm starts working only
when memory size reaches a certain point, currently set to 64G.
This is example of dentry hash table size, before and after four various
memory configurations:
MEMORYSCALEHASH_SIZE
oldnewold new
8G 13 13 8M 8M
16G 13 13 16M 16M
32G 13 13 32M 32M
64G 13 13 64M 64M
128G 13 14128M 64M
256G 13 14256M128M
512G 13 15512M128M
1024G 13 15 1024M256M
2048G 13 16 2048M256M
4096G 13 16 4096M512M
8192G 13 17 8192M512M
16384G 13 17 16384M 1024M
32768G 13 18 32768M 1024M
65536G 13 18 65536M 2048M
Signed-off-by: Pavel Tatashin
---
mm/page_alloc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8afa63e81e73..15bba5c325a5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7169,6 +7169,17 @@ static unsigned long __init
arch_reserved_kernel_pages(void)
#endif
/*
+ * Adaptive scale is meant to reduce sizes of hash tables on large memory
+ * machines. As memory size is increased the scale is also increased but at
+ * slower pace. Starting from ADAPT_SCALE_BASE (64G), every time memory
+ * quadruples the scale is increased by one, which means the size of hash table
+ * only doubles, instead of quadrupling as well.
+ */
+#define ADAPT_SCALE_BASE (64ull << 30)
+#define ADAPT_SCALE_SHIFT 2
+#define ADAPT_SCALE_NPAGES (ADAPT_SCALE_BASE >> PAGE_SHIFT)
+
+/*
* allocate a large system hash table from bootmem
* - it is assumed that the hash table must contain an exact power-of-2
* quantity of entries
@@ -7199,6 +7210,14 @@ void *__init alloc_large_system_hash(const char
*tablename,
if (PAGE_SHIFT < 20)
numentries = round_up(numentries, (1<<20)/PAGE_SIZE);
+ if (!high_limit) {
+ unsigned long long adapt;
+
+ for (adapt = ADAPT_SCALE_NPAGES; adapt < numentries;
+adapt <<= ADAPT_SCALE_SHIFT)
+ scale++;
+ }
+
/* limit to 1 bucket per 2^scale bytes of low memory */
if (scale > PAGE_SHIFT)
numentries >>= (scale - PAGE_SHIFT);
--
2.13.0
[v4 0/1] mm: Adaptive hash table scaling
Changes from v3 - v4: - Fixed an issue with 32-bit overflow (adapt is ull now instead ul) - Added changes suggested by Michal Hocko: use high_limit instead of a new flag to determine that we should use this new scaling. Pavel Tatashin (1): mm: Adaptive hash table scaling mm/page_alloc.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.13.0
Re: [PATCH-RFT 2/2] pinctrl: samsung: Split Exynos drivers per ARMv7 and ARMv8
On Tue, May 16, 2017 at 10:06 PM, Krzysztof Kozlowski wrote: > Exynos pinctrl drivers contain pretty big per-SoC data structures. The > pinctrl-exynos object file contained code and data for both ARMv7 and > ARMv8 SoCs thus it grew big. There will not be a shared image between > ARMv7 and ARMv8 so there is no need to combine all of this into one > driver. > > Splitting the data allows to make it more granular (e.g. code related to > ARMv8 Exynos is self-contained), slightly speed up the compilation and > reduce the effective size of compiled kernel. > > The common data structures and functions reside still in existing > pinctrl-exynos.c. Only the SoC-specific parts were moved out to new > files. Except marking few functions non-static and adding them to > header, there were no functional changes in the code. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Linus Walleij I guess I will get this from you with a pull request? Yours, Linus Walleij
Re: [PATCH-RFT 2/2] pinctrl: samsung: Split Exynos drivers per ARMv7 and ARMv8
On Sat, May 20, 2017 at 07:12:13PM +0200, Linus Walleij wrote: > On Tue, May 16, 2017 at 10:06 PM, Krzysztof Kozlowski wrote: > > > Exynos pinctrl drivers contain pretty big per-SoC data structures. The > > pinctrl-exynos object file contained code and data for both ARMv7 and > > ARMv8 SoCs thus it grew big. There will not be a shared image between > > ARMv7 and ARMv8 so there is no need to combine all of this into one > > driver. > > > > Splitting the data allows to make it more granular (e.g. code related to > > ARMv8 Exynos is self-contained), slightly speed up the compilation and > > reduce the effective size of compiled kernel. > > > > The common data structures and functions reside still in existing > > pinctrl-exynos.c. Only the SoC-specific parts were moved out to new > > files. Except marking few functions non-static and adding them to > > header, there were no functional changes in the code. > > > > Signed-off-by: Krzysztof Kozlowski > > Acked-by: Linus Walleij > I guess I will get this from you with a pull request? Yes, I'll send it to you with pull request. Best regards, Krzysztof
Re: [PATCH 7/7] DWARF: add the config option
On Sat, May 20, 2017 at 11:20:34AM -0500, Josh Poimboeuf wrote: >But then, if we're going that far, why not just have objtool reformat >the data into something much simpler? It already has the knowledge >to do so. Then we don't have to jump through all those hoops to >justify jumping through more hoops in the kernel (i.e., having a >complex DWARF state machine). With a simple debuginfo format, the >kernel unwinder is simple enough that we don't need to validate its >functionality in a simulator. I should clarify that it doesn't have to be objtool which does this. It could instead be a simple DWARF-to-undwarf conversion tool which runs during the vmlinux linking stage. Anyway we're both proposing simplifying the DWARF data into an easier-to-parse format. I think the question is whether we want that simplification process to happen in the kernel (in the middle of a kernel unwind operation), or at build time. -- Josh
Re: [PATCH] drm/stm: add COMPILE_TEST to Kconfig (fwd)
Hi Philippe,
2017-05-19 21:17 GMT+09:00 Philippe CORNU :
>
>
> On 05/19/2017 09:49 AM, Julia Lawall wrote:
>> On line 466, the preceeding comment suggests that the second constant
>> should start with VS rather than HS again.
>>
>> julia
>>
>> -- Forwarded message --
>> Date: Fri, 19 May 2017 15:45:39 +0800
>> From: kbuild test robot
>> To: kbu...@01.org
>> Cc: Julia Lawall
>> Subject: Re: [PATCH] drm/stm: add COMPILE_TEST to Kconfig
>>
>> CC: kbuild-...@01.org
>> In-Reply-To:
>> <1495082711-10535-1-git-send-email-yamada.masah...@socionext.com>
>> TO: Masahiro Yamada
>> CC: dri-de...@lists.freedesktop.org, Daniel Vetter
>> , linux-kernel@vger.kernel.org, Masahiro Yamada
>> , Yannick Fertre ,
>> Philippe Cornu , David Airlie
>> CC: linux-kernel@vger.kernel.org, Masahiro Yamada
>> , Yannick Fertre ,
>> Philippe Cornu , David Airlie
>>
>> Hi Masahiro,
>>
>> [auto build test WARNING on drm/drm-next]
>> [cannot apply to v4.12-rc1 next-20170518]
>> [if your patch is applied to the wrong git tree, please drop us a note to
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Masahiro-Yamada/drm-stm-add-COMPILE_TEST-to-Kconfig/20170519-131342
>> base: git://people.freedesktop.org/~airlied/linux.git drm-next
>> :: branch date: 3 hours ago
>> :: commit date: 3 hours ago
>>
drivers/gpu/drm/stm/ltdc.c:466:7-15: duplicated argument to & or |
>>
>> git remote add linux-review https://github.com/0day-ci/linux
>> git remote update linux-review
>> git checkout c669a25d907f95d3e13f1dae9812642330b4aa28
>> vim +466 drivers/gpu/drm/stm/ltdc.c
>>
>> b759012c Yannick Fertre 2017-04-14 450 accum_vbp = vsync +
>> vm.vback_porch;
>> b759012c Yannick Fertre 2017-04-14 451 accum_act_w = accum_hbp +
>> vm.hactive;
>> b759012c Yannick Fertre 2017-04-14 452 accum_act_h = accum_vbp +
>> vm.vactive;
>> b759012c Yannick Fertre 2017-04-14 453 total_width = accum_act_w +
>> vm.hfront_porch;
>> b759012c Yannick Fertre 2017-04-14 454 total_height = accum_act_h +
>> vm.vfront_porch;
>> b759012c Yannick Fertre 2017-04-14 455
>> b759012c Yannick Fertre 2017-04-14 456 clk_disable(ldev->pixel_clk);
>> b759012c Yannick Fertre 2017-04-14 457
>> b759012c Yannick Fertre 2017-04-14 458 if
>> (clk_set_rate(ldev->pixel_clk, rate) < 0) {
>> b759012c Yannick Fertre 2017-04-14 459 DRM_ERROR("Cannot set
>> rate (%dHz) for pixel clk\n", rate);
>> b759012c Yannick Fertre 2017-04-14 460 return;
>> b759012c Yannick Fertre 2017-04-14 461 }
>> b759012c Yannick Fertre 2017-04-14 462
>> b759012c Yannick Fertre 2017-04-14 463 clk_enable(ldev->pixel_clk);
>> b759012c Yannick Fertre 2017-04-14 464
>> b759012c Yannick Fertre 2017-04-14 465 /* Configures the HS, VS, DE
>> and PC polarities. */
>> b759012c Yannick Fertre 2017-04-14 @466 val = HSPOL_AL | HSPOL_AL |
>> DEPOL_AL | PCPOL_IPC;
>
> Thanks Julia for your comments.
> Masahiro, may I ask you please to propose a patch (simply rename the 2nd
> HSPOL_AL to VSPOL_AL at line 466.) as the issue is revealed by your
> patch named "drm/stm: add COMPILE_TEST to Kconfig".
> Many thanks,
> Philippe
I added COMPILE_TEST, but my objective was to
easily test my ccflags-y cleanup works for Kbuild.
The change will not affect the behavior
(because both HSPOL_AL and HSPO_AL are defined as 0),
but I think it should be fixed by a person who is familiar with this driver.
--
Best Regards
Masahiro Yamada
Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"
On Sat, May 20, 2017 at 11:59:50AM +0200, Benjamin Tissoires wrote: > Hi, > > On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > > Looks like you running your patched kernel? > > That's right. > > > > > > >>> CONFIG_RMI4_CORE=m > > >>> CONFIG_RMI4_I2C=m > > >>> CONFIG_RMI4_SPI=m > > >>> # CONFIG_RMI4_SMB is not set > > > > > > This is your issue I believe. > > > > Indeed, enabling that configuration solves that issue. > > > > However, I think it is quite unintuitive that a module (psmouse) chooses > > a default mode which requires another driver which is not necessarily > > included; though it would probably be not a very clean solution to > > explicitly check that as well. > > > > Is this behaviour, that one module requires another without > > communicating that clearly, wanted? > > > > I can see 3 solutions: > 1. Have PS2_SMBUS depending on RMI_SMBUS (and ELAN_I2C, and others when >required) > 2. Have PS2_SMBUS selecting RMI_SMBUS (and the others when time comes) > 3. Changing the default value of synaptics_intertouch to >SYNAPTICS_INTERTOUCH_OFF when RMI_SMBUS is not set > > Solution 3. might be interesting because it doesn't prevent users to > compile the module on the side and is Synaptics only. > > Dmitry, any comments? I like #3. We might also want to stick a warning into synaptics.c when we see a device that has intertouch, but RMI_SMBUS is disabled, so we could nudge users to switch over to RMI. Thanks. -- Dmitry
