Re: [PATCH v3 7/8] perf: Define PMU_TXN_READ interface
On Tue, Jul 21, 2015 at 06:50:45PM -0700, Sukadev Bhattiprolu wrote: > We are trying to use the following interface: > > start_txn(pmu, PERF_PMU_TXN_READ); > > perf_event_read(leader); > list_for_each(sibling, >sibling_list, group_entry) > perf_event_read(sibling) > > pmu->commit_txn(pmu); > > with the idea that the PMU driver would save the type of transaction in > ->start_txn() and use in ->read() and ->commit_txn(). > > But since ->start_txn() and the ->read() operations could happen on different > CPUs (perf_event_read() uses the event->oncpu to schedule a call), the PMU > driver cannot use a per-cpu variable to save the state in ->start_txn(). > or is there better way? I've not woken up yet, and not actually fully read the email, but can you stuff the entire above chunk inside the IPI? I think you could then actually optimize __perf_event_read() as well, because all these events should be on the same context, so no point in calling update_*time*() for every event or so. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50
On 15-07-21 10:20:44, Dmitry Torokhov wrote:
> Hi Stefan,
>
> On Tue, Jul 21, 2015 at 04:43:36PM +0200, Stefan Agner wrote:
> > Hi Dmitry,
> >
> > As the original author of the driver I have some remarks to your review
> >
> > On 2015-07-18 01:42, Dmitry Torokhov wrote:
> > >> +/*
> > >> + * If touch pressure is too low, stop measuring and
> > >> reenable
> > >> + * touch detection
> > >> + */
> > >> +if (val_p < min_pressure || val_p > 2000)
> > >> +break;
> >
> > This is where the modules touch pressure is used to stop the measurement
> > process and switch back to interrupt mode. See my remarks at the end.
> >
> > >> +
> > >> +/*
> > >> + * The pressure may not be enough for the first x and
> > >> the
> > >> + * second y measurement, but, the pressure is ok when
> > >> the
> > >> + * driver is doing the third and fourth measurement. To
> > >> + * take care of this, we drop the first measurement
> > >> always.
> > >> + */
> > >> +if (discard_val_on_start) {
> > >> +discard_val_on_start = false;
> > >> +} else {
> > >> +/*
> > >> + * Report touch position and sleep for
> > >> + * next measurement
> > >> + */
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_X, VF_ADC_MAX - val_x);
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_Y, VF_ADC_MAX - val_y);
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_PRESSURE, val_p);
> > >> +input_report_key(vf50_ts->ts_input, BTN_TOUCH,
> > >> 1);
> > >> +input_sync(vf50_ts->ts_input);
> > >> +}
> > >> +
> > >> +msleep(10);
> > >> +}
> > >> +
> > >> +/* Report no more touch, reenable touch detection */
> > >> +input_report_abs(vf50_ts->ts_input, ABS_PRESSURE, 0);
> > >> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 0);
> > >> +input_sync(vf50_ts->ts_input);
> > >> +
> > >> +vf50_ts_enable_touch_detection(vf50_ts);
> > >> +
> > >> +/* Wait for the pull-up to be stable on high */
> > >> +msleep(10);
> > >> +
> > >> +/* Reenable IRQ to detect touch */
> > >> +enable_irq(vf50_ts->pen_irq);
> > >> +
> > >> +dev_dbg(dev, "Reenabled touch detection interrupt\n");
> > >> +}
> > >> +
> > >> +static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
> > >> +{
> > >> +struct vf50_touch_device *vf50_ts = (struct vf50_touch_device
> > >> *)dev_id;
> > >> +struct device *dev = _ts->pdev->dev;
> > >> +
> > >> +dev_dbg(dev, "Touch detected, start worker thread\n");
> > >> +
> > >> +disable_irq_nosync(irq);
> > >> +
> > >> +/* Disable the touch detection plates */
> > >> +gpiod_set_value(vf50_ts->gpio_ym, 0);
> > >> +
> > >> +/* Let the platform mux to default state in order to mux as ADC
> > >> */
> > >> +pinctrl_pm_select_default_state(dev);
> > >> +
> > >> +queue_work(vf50_ts->ts_workqueue, _ts->ts_work);
> > >
> > > If you convert this to a threaded interrupt you won't need to
> > > disable/reenable interrupt or queue work. You should also be able to use
> > > gpiod_set_value_cansleep() extending the range of ways the controller
> > > could be connected to systems.
> > >
> >
> > I'm not sure if a threaded interrupt is the right thing here. While the
> > pen is on the touchscreen (which can be for several seconds)
> > measurements have to be made in a continuous loop. Is it ok for a
> > threaded interrupt to run that long?
>
> Yes, why not? Threaded interrupt is simply a kernel thread that is woken
> when hard interrupt handler tells it to wake up. Very similar to
> interrupt + work queue, except that the kernel manages interactions
> properly for you. There are several drivers in kernel that do that, for
> example auo-pixcir-ts.c or tsc2007.c
>
> >
> > I'm also not sure if it is really safe to _not_ disable the pen down
> > GPIO interrupt. If we get a interrupt while measuring, we should ignore
> > that interrupt.
>
> The interrupt management core (you'll have to annotate it as
> IRQF_ONESHOT) will make sure it stays masked properly until the threaded
> handler completes so you do not need to disable it explicitly.
(snip)
I tried the IRQ threaded implementation. From your reply, I can see my first
implementation was wrong in the sense that I did not use the IRQF_ONESHOT flag.
The touch response time was not good in this case, however thats to be expected
in this case
[PATCH] acpi-video: Fix brightness keys for Thinkpad X240
Thinkpad X240 laptop has a working acpi_video backlight control but
using the default native backlight control, brightness keys does not work.
This patch force acpi_video use for this laptop by adding an exception in
video_detect_dmi_table.
Signed-off-by: Mathieu OTHACEHE
---
drivers/acpi/video_detect.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 815f75e..c4bc5f2 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -173,6 +173,14 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"),
},
},
+ {
+.callback = video_detect_force_video,
+.ident = "ThinkPad X240",
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X240"),
+ },
+ },
/* The native backlight controls do not work on some older machines */
{
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] soft lockup: kill realtime threads before panic
On Tue, 2015-07-21 at 22:18 -0700, Jörn Engel wrote: > On Wed, Jul 22, 2015 at 06:36:30AM +0200, Mike Galbraith wrote: > > On Tue, 2015-07-21 at 15:07 -0700, Spencer Baugh wrote: > > > > > We have observed cases where the soft lockup detector triggered, but no > > > kernel bug existed. Instead we had a buggy realtime thread that > > > monopolized a cpu. So let's kill the responsible party and not panic > > > the entire system. > > > > If you don't tell the kernel to panic, it won't, and if you don't remove > > its leash (the throttle), your not so tame rt beast won't maul you. > > Not sure if this patch is something for mainline, but those two > alternatives have problems of their own. Not panicking on lockups can > leave a system disabled until some human come around. In many cases > that human will do no better than power-cycle. A panic reduces the > downtime. If a realtime task goes bonkers, the realtime game is over, you're down. > And the realtime throttling gives non-realtime threads some minimum > runtime, but does nothing to help low-priority realtime threads. It > also introduces latencies, often when workloads are high and you would > like any available cpu to get through that rough spot. You can use group scheduling as a debug crutch until the little beasts are housebroken. > I don't think we have a good answer to this problem in the mainline > kernel yet. IMHO, there's no point in trying to make rt warm/fuzzy/cuddly. Just don't stuff a Hells Angel into a super-suit, that gets real ugly ;-) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3] x86/mm/pat: Do a small optimization and fix in reserve_memtype
From: Pan Xinhui
It's more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert. memtype_lock protects all data stored in
rb-tree from multiple access. It's not cool to call kfree, pr_info, etc
with this lock held. So move spin_unlock a little ahead.
If *new* succeed to be stored into the rb-tree, we might hit panic.
Because we access *new* in dprintk "cattr_name(new->type)". Data stored
in the rb-tree might be freed at any possbile time. It's abviously wrong
to access such data without lock held. As new->type might be changed in
rbt_memtype_check_insert, so save new->type to actual_type, then use
actual_type in dprintk.
Signed-off-by: Pan Xinhui
---
change from v2:
update comments.
change from V1:
fix an access of *new* without memtype_lock held.
---
arch/x86/mm/pat.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 188e3e0..894a096 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -538,22 +538,25 @@ int reserve_memtype(u64 start, u64 end, enum
page_cache_mode req_type,
new->type = actual_type;
spin_lock(_lock);
-
err = rbt_memtype_check_insert(new, new_type);
+ /*
+* new->type might be changed in rbt_memtype_check_insert.
+* So save new->type to actual_type as dprintk uses it.
+* We are not allowed to touch new after unlocking memtype_lock.
+*/
+ actual_type = new->type;
+ spin_unlock(_lock);
+
if (err) {
pr_info("x86/PAT: reserve_memtype failed [mem %#010Lx-%#010Lx],
track %s, req %s\n",
start, end - 1,
cattr_name(new->type), cattr_name(req_type));
kfree(new);
- spin_unlock(_lock);
-
return err;
}
- spin_unlock(_lock);
-
dprintk("reserve_memtype added [mem %#010Lx-%#010Lx], track %s, req %s,
ret %s\n",
- start, end - 1, cattr_name(new->type), cattr_name(req_type),
+ start, end - 1, cattr_name(actual_type), cattr_name(req_type),
new_type ? cattr_name(*new_type) : "-");
return err;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] xen-blkfront: rm BUG_ON(info->feature_persistent) in blkif_free
On 07/22/2015 12:43 PM, Bob Liu wrote:
>
> On 07/21/2015 05:25 PM, Roger Pau Monné wrote:
>> El 21/07/15 a les 5.30, Bob Liu ha escrit:
>>> This BUG_ON() in blkif_free() is incorrect, because indirect page can be
>>> added
>>> to list info->indirect_pages in blkif_completion() no matter
>>> feature_persistent
>>> is true or false.
>>>
>>> Signed-off-by: Bob Liu
>>
>> Acked-by: Roger Pau Monné
>>
>> This was probably an oversight from when blkif_completion was changed to
>> check for gnttab_query_foreign_access. It should be backported to stable
>> trees.
>>
>
> Sorry, this patch is buggy and I haven't figure out why.
>
> general protection fault: [#1] SMP
> Modules linked in:
> CPU: 0 PID: 39 Comm: xenwatch Tainted: GW
> 4.1.0-rc3-3-g718cf80-dirty #67
> Hardware name: Xen HVM domU, BIOS 4.5.0-rc 11/23/2014
> task: 880283f4eca0 ti: 880283fb4000 task.ti: 880283fb4000
> RIP: 0010:[] [] blkif_free+0x162/0x5a9
> RSP: 0018:880283fb7c48 EFLAGS: 00010087
> RAX: dead00200200 RBX: 88014140 RCX:
> RDX: dead00100100 RSI: dead00100100 RDI: 88028f418bb8
> RBP: 880283fb7ca8 R08: dead00200200 R09: 0001
> R10: 0001 R11: R12: 8801414481c8
> R13: dead001000e0 R14: 8801414481b8 R15: ea00
> FS: () GS:88028f40() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 01582e08 CR3: 00013345b000 CR4: 001406f0
> Stack:
> 880023aa8420 0286 880283fb7cb7 880023aa8420
> 8800363fe240 81862c50 880283fb7ce8 880023aa8440
> 8187 880023aa8400 88014140 88014148
> Call Trace:
> [] blkfront_remove+0x4c/0xff
> [] xenbus_dev_remove+0x76/0xb0
> [] __device_release_driver+0x84/0xf8
> [] device_release_driver+0x1e/0x2b
> [] bus_remove_device+0x12c/0x141
> [] device_del+0x161/0x1e5
> [] ? xenbus_thread+0x239/0x239
> [] device_unregister+0x43/0x4f
> [] xenbus_dev_changed+0x82/0x17f
> [] ? xenbus_otherend_changed+0xf0/0xff
> [] frontend_changed+0x43/0x48
> [] xenwatch_thread+0xf9/0x127
> [] ? add_wait_queue+0x44/0x44
> [] kthread+0xcd/0xd5
> [] ? alloc_pid+0xe8/0x492
> [] ? kthread_freezable_should_stop+0x48/0x48
> [] ret_from_fork+0x42/0x70
> [] ? kthread_freezable_should_stop+0x48/0x48
> Code: 04 00 4c 8b 28 48 8d 78 e0 49 83 ed 20 eb 3d 48 8b 47 28 48 8b 57 20 48
> be 00 01 10 00 00 00 ad de 49 b8 00 02 20 00 00 00 ad de <48> 89 42 08 48 89
> 10 48 89 77 20 4c 89 47 28 31 f6 e8 26 7d cf
> RIP [] blkif_free+0x162/0x5a9
> RSP
> ---[ end trace 5321d7f1ef8414d0 ]---
>
The right fix should be:
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1124,8 +1124,10 @@ static void blkif_completion(struct blk_shadow *s,
struct blkfront_info *info,
* Add the used indirect page back to the list
of
* available pages for indirect grefs.
*/
- indirect_page =
pfn_to_page(s->indirect_grants[i]->pfn);
- list_add(_page->lru,
>indirect_pages);
+ if (!info->feature_persistent) {
+ indirect_page =
pfn_to_page(s->indirect_grants[i]->pfn);
+ list_add(_page->lru,
>indirect_pages);
+ }
s->indirect_grants[i]->gref = GRANT_INVALID_REF;
list_add_tail(>indirect_grants[i]->node,
>grants);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cgroup: net_cls: fix false-positive "suspicious RCU usage"
From: Konstantin Khlebnikov
Date: Tue, 21 Jul 2015 19:46:29 +0300
> @@ -23,7 +23,8 @@ static inline struct cgroup_cls_state *css_cls_state(struct
> cgroup_subsys_state
>
> struct cgroup_cls_state *task_cls_state(struct task_struct *p)
> {
> - return css_cls_state(task_css(p, net_cls_cgrp_id));
> + return css_cls_state(task_css_check(p, net_cls_cgrp_id,
> +rcu_read_lock_bh_held()));
You've made a serious mess of the indentation here.
First of all, you've changed the correct plain "TAB" before the 'return' line
into a TAB and two SPACE characters.
Secondly, the second line needs to be precisely indented to the exact column
following the openning parenthesis of the task_css_check() call on the
previous line.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] openvswitch: allocate nr_node_ids flow_stats instead of num_possible_nodes
From: Chris J Arges Date: Tue, 21 Jul 2015 12:36:33 -0500 > Some architectures like POWER can have a NUMA node_possible_map that > contains sparse entries. This causes memory corruption with openvswitch > since it allocates flow_cache with a multiple of num_possible_nodes() and > assumes the node variable returned by for_each_node will index into > flow->stats[node]. > > Use nr_node_ids to allocate a maximal sparse array instead of > num_possible_nodes(). > > The crash was noticed after 3af229f2 was applied as it changed the > node_possible_map to match node_online_map on boot. > Fixes: 3af229f2071f5b5cb31664be6109561fbe19c861 > > Signed-off-by: Chris J Arges Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] input: touchscreen: pixcir_i2c_ts: Add support for optional wakeup interrupt
Hi Dmitry, On 07/20/2015 11:54 AM, Dmitry Torokhov wrote: > On Sun, Jul 19, 2015 at 11:09:30PM -0700, Tony Lindgren wrote: >> * Vignesh R [150719 21:53]: >>> @@ -445,6 +443,8 @@ static struct pixcir_ts_platform_data >>> *pixcir_parse_dt(struct device *dev) >>> dev_dbg(dev, "%s: x %d, y %d, gpio %d\n", __func__, >>> pdata->x_max + 1, pdata->y_max + 1, pdata->gpio_attb); >>> >>> + pdata->wakeirq = of_irq_get_byname(dev->of_node, "wakeupirq"); >>> + >>> return pdata; >> >> What about handling -EPROVE_DEFER here? At least pinctrl-single can be >> be a loadable module for the dedicated wakeirqs. > > Right. I think we should only allow -ENODATA to continue and return > error in all other cases. -EINVAL will be returned if "interrupt-names" is not specified. I will make execption for -ENODATA & -EINVAL, and return error in all other cases? > > Also, I think "irq" suffix on name is redundant. Ok, will drop "irq" suffix: + interrupt-names = "tsc", "wakeup"; > > Thanks. > -- Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 22
Hi all, Changes since 20150721: The nfsd tree lost its build failure. The wireless-drivers-next tree gained a build failure so I used the version from next-20150721. The kvms390 tree gained a conflict against the s390 tree. The gpio tree lost its build failure. Non-merge commits (relative to Linus' tree): 3281 3191 files changed, 144170 insertions(+), 54351 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 224 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (9d634c410b07 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (0871b7248113 ARM: fix __virt_to_idmap build error on !MMU) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (bc0195aad0da Linux 4.2-rc2) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging powerpc-merge-benh/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (1e353cddcf81 drivers: net: cpsw: remove tx event processing in rx napi poll) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (6c3d91193d82 ALSA: hda - Add new GPU codec ID 0x10de007d to snd-hda) Merging pci-current/for-linus (c9ddbac9c891 PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition) Merging wireless-drivers/master (df2cd4586f17 Merge tag 'iwlwifi-for-kalle-2015-06-12' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (52721d9d3334 Linux 4.2-rc3) Merging tty.current/tty-linus (52721d9d3334 Linux 4.2-rc3) Merging usb.current/usb-linus (52721d9d3334 Linux 4.2-rc3) Merging usb-gadget-fixes/fixes (b2e2c94b878b usb: gadget: f_midi: fix error recovery path) Merging usb-serial-fixes/usb-linus (09290f419223 USB: pl2303: fix baud-rate divisor calculations) Merging staging.current/staging-linus (52721d9d3334 Linux 4.2-rc3) Merging char-misc.current/char-misc-linus (52721d9d3334 Linux 4.2-rc3) Merging input-current/for-linus (d98399e688f8 Input: elantech - force resolution of 31 u/mm) Merging crypto-current/master (030f4e968741 crypto: nx - Fix reentrancy bugs) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (758556bdc1c8 module: Fix load_module() error path) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix futex_cmp_requeue_pi() error handling) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer use recursive field of task struct) Mer
[patch] workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs
On Tue, 2015-07-21 at 10:55 +0200, Mike Galbraith wrote:
> On Sun, 2015-07-19 at 10:02 +0200, Mike Galbraith wrote:
>
> > Why do we do nothing about these allegedly unbound work items?
>
> My box seems to think the answer is: no reason other than nobody having
> asked the source to please not do that. Guess I'll go ask a NUMA box.
My [128] socket boxen show zero signs of caring, and it's dirt simple,
so it's no longer an experiment. Fly or die little patchlet...
WORK_CPU_UNBOUND work items queued to a bound workqueue always run
locally. This is a good thing normally, but not when the user has
asked us to keep unbound work away from certain CPUs. Round robin
these to wq_unbound_cpumask CPUs instead, as perturbation avoidance
trumps performance.
Signed-off-by: Mike Galbraith
---
kernel/workqueue.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -301,6 +301,9 @@ static bool workqueue_freezing; /* PL:
static cpumask_var_t wq_unbound_cpumask; /* PL: low level cpumask for all
unbound wqs */
+/* CPU where WORK_CPU_UNBOUND work was last round robin scheduled from this
CPU */
+static DEFINE_PER_CPU(unsigned int, wq_unbound_rr_cpu_last);
+
/* the per-cpu worker pools */
static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
cpu_worker_pools);
@@ -1294,6 +1297,24 @@ static bool is_chained_work(struct workq
return worker && worker->current_pwq->wq == wq;
}
+/*
+ * When queueing WORK_CPU_UNBOUND work to a !WQ_UNBOUND queue, round
+ * robin among wq_unbound_cpumask to avoid perturbing sensitive tasks.
+ */
+static unsigned int select_round_robin_cpu(unsigned int cpu)
+{
+ if (cpumask_test_cpu(cpu, wq_unbound_cpumask))
+ return cpu;
+ if (cpumask_empty(wq_unbound_cpumask))
+ return cpu;
+ cpu = __this_cpu_read(wq_unbound_rr_cpu_last);
+ cpu = cpumask_next_and(cpu, wq_unbound_cpumask, cpu_online_mask);
+ if (cpu >= nr_cpu_ids)
+ cpu = 0;
+ __this_cpu_write(wq_unbound_rr_cpu_last, cpu);
+ return cpu;
+}
+
static void __queue_work(int cpu, struct workqueue_struct *wq,
struct work_struct *work)
{
@@ -1322,9 +1343,11 @@ static void __queue_work(int cpu, struct
cpu = raw_smp_processor_id();
/* pwq which will be used unless @work is executing elsewhere */
- if (!(wq->flags & WQ_UNBOUND))
+ if (!(wq->flags & WQ_UNBOUND)) {
+ if (req_cpu == WORK_CPU_UNBOUND)
+ cpu = select_round_robin_cpu(cpu);
pwq = per_cpu_ptr(wq->cpu_pwqs, cpu);
- else
+ } else
pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu));
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 net 0/3] BPF JIT fixes for ARM
From: Nicolas Schichan Date: Tue, 21 Jul 2015 14:14:11 +0200 > These patches are fixing bugs in the ARM JIT and should probably find > their way to a stable kernel. All 60 test_bpf tests in Linux 4.1 release > are now passing OK (was 54 out of 60 before). Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] soft lockup: kill realtime threads before panic
On Wed, Jul 22, 2015 at 06:36:30AM +0200, Mike Galbraith wrote: > On Tue, 2015-07-21 at 15:07 -0700, Spencer Baugh wrote: > > > We have observed cases where the soft lockup detector triggered, but no > > kernel bug existed. Instead we had a buggy realtime thread that > > monopolized a cpu. So let's kill the responsible party and not panic > > the entire system. > > If you don't tell the kernel to panic, it won't, and if you don't remove > its leash (the throttle), your not so tame rt beast won't maul you. Not sure if this patch is something for mainline, but those two alternatives have problems of their own. Not panicking on lockups can leave a system disabled until some human come around. In many cases that human will do no better than power-cycle. A panic reduces the downtime. And the realtime throttling gives non-realtime threads some minimum runtime, but does nothing to help low-priority realtime threads. It also introduces latencies, often when workloads are high and you would like any available cpu to get through that rough spot. I don't think we have a good answer to this problem in the mainline kernel yet. Jörn -- To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt, Kansas City Star, 1918 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux 4.2-rc1 broken Nokia N900
On Wed, Jul 22, 2015 at 04:03:07AM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jul 21, 2015 at 07:17:41PM -0500, Michael Welling wrote:
> > On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
> >
> > This code has my head spinning.
> >
> > I found that the errors do not occur when the driver is built into the
> > kernel.
> >
> > I also found that with the patch below the errors go away.
> >
> > Not sure if it is acceptible but see if it fixes things on your side.
> >
> >
> > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> > index cf8b91b..3164d13 100644
> > --- a/drivers/spi/spi.c
> > +++ b/drivers/spi/spi.c
> > @@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
> > if (!spi->max_speed_hz)
> > spi->max_speed_hz = spi->master->max_speed_hz;
> >
> > - spi_set_cs(spi, false);
> > -
> > if (spi->master->setup)
> > status = spi->master->setup(spi);
> >
> > + spi_set_cs(spi, false);
> > +
> > dev_dbg(>dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max -->
> > %d\n",
> > (int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
> > (spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
>
> mh. maybe a runtime PM issue?
mh?
>
> * external abort on non-linefetch: address cannot be accessed,
>since the module's clocks are disabled
> * built-in works, module not: built-in is probably a little bit
>faster (module must not be loaded from filesystem), so that
>the device has not yet been suspended
> * Before 4.2, omap2_mcspi_set_cs() was called in the setup
>routine, which acquired runtime PM
> * In 4.2, omap2_mcspi_set_cs() seems to be called without a
>prior pm_runtime_get_sync()
> * With your workaround, the device has not yet returned to
>suspend after the runtime PM acquisition in setup()
>
> So I suggest trying the following (compile tested only) patch:
>
It seems you are right.
With this patch the SPI drivers no longer cause data aborts.
I will wait for feedback from Pavel and Pali but it looks like
we have a winner.
> -- Sebastian
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 5867384..f7d9ffd 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct
> spi_device *spi, int enable)
>
> static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
> {
> + struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
> u32 l;
>
> /* The controller handles the inverted chip selects
> @@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
> bool enable)
> enable = !enable;
>
> if (spi->controller_state) {
> + pm_runtime_get_sync(mcspi->dev);
> +
Should the return code should be checked here as with the other
instances of pm_runtime_get_sync?
> l = mcspi_cached_chconf0(spi);
>
> if (enable)
> @@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
> bool enable)
> l |= OMAP2_MCSPI_CHCONF_FORCE;
>
> mcspi_write_chconf0(spi, l);
> +
> + pm_runtime_mark_last_busy(mcspi->dev);
> + pm_runtime_put_autosuspend(mcspi->dev);
> }
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
On Wed, 2015-07-22 at 00:46 -0400, David Long wrote:
> On 06/29/15 23:29, Michael Ellerman wrote:
> > On Wed, 2015-06-17 at 14:30 -0400, David Long wrote:
> >> On 06/16/15 09:17, Rob Herring wrote:
> >>> On Mon, Jun 15, 2015 at 11:42 AM, David Long wrote:
>
> #define REG_OFFSET_NAME(r) \
> {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
> #define REG_OFFSET_END {.name = NULL, .offset = 0}
> >>>
> >>> Can't you also move these? ARM is complicated with the "ARM_"
> >>> prefixing, but the others appear to be the same. Maybe you can remove
> >>> the prefix or redefine the macro for ARM.
> >>
> >> That would mandate that all the architecture-specific pt_regs structures
> >> would have to use a top-level named field for each named register.
> >
> > Why does it mandate that?
> >
> > See eg. powerpc where we use REG_OFFSET_NAME for the top-level named fields
> > and
> > then a different macro for the array elements:
> >
> >#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct
> > pt_regs, r)}
> >#define GPR_OFFSET_NAME(num) \
> > {.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
> >
> >static const struct pt_regs_offset regoffset_table[] = {
> > GPR_OFFSET_NAME(0),
> > GPR_OFFSET_NAME(1),
> > GPR_OFFSET_NAME(2),
> > GPR_OFFSET_NAME(3),
> > ...
> > REG_OFFSET_NAME(nip),
> > REG_OFFSET_NAME(msr),
> >
> >
> > So I don't see why REG_OFFSET_NAME couldn't be common.
> >
>
> Sorry for the delay in responding to this.
>
> OK, so you're saying architectures that don't want this constraint can
> make their own macro. Seems to make this whole exercise slightly less
> useful, but whatever.
Well yeah.
In fact of the 4 arches that use REG_OFFSET_NAME, 2 already have another macro
for specially named registers (powerpc & sh).
> I see three ways to go here:
>
> 1) Leave it as is.
> 2) Force all architectures to use a common definition.
> 3) Provide a common definition that all architectures (except "arm")
> currently using this functionality will use.
>
> I have a v2 patch to implement #3, ready to post. Do we think this is
> the way to go?
Yeah I think it is. How are you making it conditional? Just #ifndef
REG_OFFSET_NAME?
> I don't like #2 because I really don't want to rename all
> uses of the current register fields for arm since this is
> architecture-specific code to begin with and since it affects code in 39
> arm source files.
I guess you're talking about renaming all the ARM_x regs to x. That would
likely cause problems because they're implemented as #defines,
eg. #define r0 uregs[0] would probably confuse your assembler.
The clean thing to do would be to have the in-kernel struct pt_regs have actual
named members, but that would still be an intrusive change.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 7/7] powerpc/powernv: nest pmu cpumask and cpu hotplug support
> +static void nest_change_cpu_context(int old_cpu, int new_cpu)
> +{
> + int i;
> +
> + for (i = 0; per_nest_pmu_arr[i] != NULL; i++)
> + perf_pmu_migrate_context(_nest_pmu_arr[i]->pmu,
> + old_cpu, new_cpu);
From patch 4, I see per_nest_pmu_arr is defined as:
+static struct nest_pmu *per_nest_pmu_arr[P8_NEST_MAX_PMUS];
Therefore, does this loop need to have a check that
i < P8_NEST_MAX_PMUS?
--
Regards,
Daniel
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] block: add a bi_error field to struct bio
On Mon, 20 Jul 2015 15:29:37 +0200 Christoph Hellwig wrote: > Currently we have two different ways to signal an I/O error on a BIO: > > (1) by clearing the BIO_UPTODATE flag > (2) by returning a Linux errno value to the bi_end_io callback > > The first one has the drawback of only communicating a single possible > error (-EIO), and the second one has the drawback of not beeing persistent > when bios are queued up, and are not passed along from child to parent > bio in the ever more popular chaining scenario. Having both mechanisms > available has the additional drawback of utterly confusing driver authors > and introducing bugs where various I/O submitters only deal with one of > them, and the others have to add boilerplate code to deal with both kinds > of error returns. > > So add a new bi_error field to store an errno value directly in struct > bio and remove the existing mechanisms to clean all this up. > > Signed-off-by: Christoph Hellwig > --- Reviewed-by: NeilBrown (umem and md/raid). i.e. these files. > drivers/block/umem.c| 4 +-- > drivers/md/faulty.c | 4 +-- > drivers/md/linear.c | 2 +- > drivers/md/md.c | 18 +-- > drivers/md/multipath.c | 12 +++ > drivers/md/raid0.c | 2 +- > drivers/md/raid1.c | 53 --- > drivers/md/raid10.c | 55 +++- > drivers/md/raid5.c | 52 +++ Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 6/7] powerpc/powernv: generic nest pmu event functions
> +static void p8_nest_read_counter(struct perf_event *event)
> +{
> + uint64_t *addr;
> + u64 data = 0;
You've got a u64 and a uint64_t, and then...
> +
> + addr = (u64 *)event->hw.event_base;
... you cast to event_base to a u64 pointer, which you assign to a
uint64_t pointer.
> + data = __be64_to_cpu(*addr);
And now you dereference the pointer.
Could you just have:
data = __be64_to_cpu(*event->hw.event_base);
> + local64_set(>hw.prev_count, data);
> +}
> +
> +static void p8_nest_perf_event_update(struct perf_event *event)
> +{
> + u64 counter_prev, counter_new, final_count;
> + uint64_t *addr;
> +
> + addr = (uint64_t *)event->hw.event_base;
Here at least the cast type is the same as the type of addr, but again,
why do you need the different types, and why local variable?
> + counter_prev = local64_read(>hw.prev_count);
> + counter_new = __be64_to_cpu(*addr);
> + final_count = counter_new - counter_prev;
> +
> + local64_set(>hw.prev_count, counter_new);
> + local64_add(final_count, >count);
> +}
> +
> +static void p8_nest_event_start(struct perf_event *event, int flags)
> +{
> + event->hw.state = 0;
Should this be an enum or a #define rather than a bare 0? (It may not
need to be, I was just wondering because I don't know what 0 means.)
> + p8_nest_read_counter(event);
> +}
> +
--
Regards,
Daniel
signature.asc
Description: This is a digitally signed message part
Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
On 2015년 07월 22일 11:02, Joonyoung Shim wrote: > On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote: >> Hi, >> >> Today's linux-next (next-20150721) encounters boot failures on Exynos >> Octa (Exynos5422) based boards. The boards hangs. I bisected it to: >> >> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit >> commit d80167b85024982c5f18d0481a5c248100360118 >> Author: Joonyoung Shim >> Date: Thu Jul 2 21:49:39 2015 +0900 >> >> drm/exynos: remove drm_iommu_attach_device_if_possible >> >> Already drm_iommu_attach_device checks whether support iommu internally. >> It should clear channels always regardless iommu support. We didn't know >> because we can detect the problem when iommu is enabled, so we don't >> have to use drm_iommu_attach_device_if_possible and then we can remove >> drm_iommu_attach_device_if_possible and clear_channels function pointer. >> >> Signed-off-by: Joonyoung Shim >> Tested-by: Marek Szyprowski >> Signed-off-by: Inki Dae >> >> :04 04 83379efbf4960f58d680371628ec04387935bd53 >> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers >> >> >> Config: exynos >> Boot log from Odroid XU3-Lite attached. >> >> Any hints or ideas? > > The point that hangs is when accesses fimd register in > fimd_clear_channels function, so i doubt clock setting for fimd. > > It's gone something that hangs after i enable gating for ACLK_200_DISP1 > clock. > > If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it > support. Any ideas? I think bootloader should have enabled ACLK_200_DISP1 clock and also device driver should enable all relevant clocks before the device accesses its own registers. Best way would be that the clock is enabled by common clock framework but it seems there is no anything that the clock framework can do it. So I think what we have to do is to add the clock support to device tree. Other idea? Thanks, Inki Dae > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 7/8] dmaengine: add a driver for Intel integrated DMA 64-bit
On Tue, Jul 21, 2015 at 10:08:28AM +0300, Andy Shevchenko wrote:
> On Tue, Jul 21, 2015 at 7:50 AM, Vinod Koul wrote:
> > On Mon, Jul 20, 2015 at 11:46:28AM +0300, Andy Shevchenko wrote:
> >> >> +static void idma64_chan_init(struct idma64 *idma64, struct idma64_chan
> >> >> *idma64c)
> >> >> +{
> >> >> + u32 cfghi = IDMA64C_CFGH_SRC_PER(1) | IDMA64C_CFGH_DST_PER(0);
> >> >> + u32 cfglo = 0;
> >> >> +
> >> >> + /* Enforce FIFO drain when channel is suspended */
> >> >> + cfglo |= IDMA64C_CFGL_CH_DRAIN;
> >> >> +
> >> >> + /* Set default burst alignment */
> >> >> + cfglo |= IDMA64C_CFGL_DST_BURST_ALIGN |
> >> >> IDMA64C_CFGL_SRC_BURST_ALIGN;
> >> >> +
> >> >> + channel_writel(idma64c, CFG_LO, cfglo);
> >> >> + channel_writel(idma64c, CFG_HI, cfghi);
> >> >> +
> >> >> + /* Enable interrupts */
> >> >> + channel_set_bit(idma64, MASK(XFER), idma64c->mask);
> >> >> + channel_set_bit(idma64, MASK(ERROR), idma64c->mask);
> >> >> +
> >> >> + /*
> >> >> + * Enforce the controller to be turned on.
> >> >> + *
> >> >> + * The iDMA is turned off in ->probe() and looses context during
> >> >> system
> >> >> + * suspend / resume cycle. That's why we have to enable it each
> >> >> time we
> >> >> + * use it.
> >> >> + */
> >> >> + idma64_on(idma64);
> >> > would it be better that you do this in resume and runtime_resume cycle.
> >> > That
> >> > way it need not be called for every channel init
> >>
> >> Mika, I don't remember details here, but this piece came from you. Can
> >> you shed a light?
> >>
> >> My understanding that DMA IP is private to the host controller and has
> >> the same power rail. Thus, there is no need to do separate power
> >> management for it, which makes things more complicated for no profit.
> >> It is also needed for time period from probe till first transfer
> >> (otherwise we have to check the status of DMA anyway and enable it if
> >> required), which currently remains DMA off.
> > so who does runtime management of this power rail and whosoever does that
> > how do they ensure the dma is not active at that time?
>
> The host controller driver knows this and it makes it so.
> Anyway, even if we introduce PM callbacks in this driver how to solve
> the issue to run very first transfer in a neat way?
And how does it know?
In PM callback case, your runtime resume should enable the controller
> >> >> +static size_t idma64_desc_size(struct idma64_desc *desc, unsigned int
> >> >> active)
> >> >> +{
> >> >> + size_t bytes = 0;
> >> >> + unsigned int i;
> >> >> +
> >> >> + for (i = active; i < desc->ndesc; i++)
> >> >> + bytes += desc->hw[i].len;
> >> > it can help for the non active case to have this size stored in desc
> >> > while
> >> > preparing, that gets rid of runtime calculation for that case
> >>
> >> I don't see much improvement, since it's a rare cases, but waste of
> >> memory. If you consider that should be done I can implement it.
> > The users of timing information will invoke this in non sleeping context so
> > it will help in using one more variable, maybe a good trade off. Also if
> > this is a rare case do you have use of this calculation and code?
>
> I have no calculations done, but the residue check is used only in one
> case for now, i.e. in the UART driver (see 8250_dma.c). That code
> serializes requests, so it will not ask for pending descriptor size.
> The case when we start the DMA and immediately ask for residue is
> unlike (when UART RX timeout happens).
>
> >> >> +static int idma64_terminate_all(struct dma_chan *chan)
> >> >> +{
> >> >> + struct idma64_chan *idma64c = to_idma64_chan(chan);
> >> >> + unsigned long flags;
> >> >> + LIST_HEAD(head);
> >> >> +
> >> >> + spin_lock_irqsave(>vchan.lock, flags);
> >> >> + idma64_stop_transfer(idma64c);
> >> > I dont think this is the right method for terminate. Can you check, it
> >> > might be that we have to suspend the channel before terminating an active
> >> > one. For non active case this should be okay
> >>
> >> Do you mean hardware can become into wrong state?
> > Yes at least that was true for 32bit version of this IP
>
> Can you elaborate what exactly is happening? We can do a test then and
> check. For now on we experienced no problems.
While you are doing transfers, try terminating. After that doesnt next
transaction on same channel work well, if not then please try suspending
first before terminating
> >> Only what can actually happen is the data loss which is in DMA FIFO,
> >> but we already know we would like to terminate the transfer we don't
> >> care about any data loss since that.
> > The terminate flow expect you to suspend the channel first and then
> > terminate
>
> Hm... I didn't see anything in the specification. Can you point out
> where it's described?
I dont have specs to point, but we did see this issue on 32bit BYT
iDMA and designer told us to follow this
Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote: > > Or alternatively we could publish the limitations of the channel using > > capabilities so SPI knows I have a dmaengine channel and it can transfer > > max N > > length transfers so would be able to break rather than guessing it or coding > > in DT. Yes it may come from DT but that should be dmaengine driver rather > > than client driver :) > > > > This can be done by dma_get_slave_caps(chan, ) > > > > And we add max_length as one more parameter to existing set > > > > Also all this could be handled in generic SPI-dmaengine layer so that > > individual drivers don't have to code it in > > > > Let me know if this idea is okay, I can push the dmaengine bits... > > It would be ok if there was a fixed limit. However, the limit depends > on SPI slave settings. Presumably for other buses using the dmaengine > the limit would depend on the bus or slave settings as well. I do not > see a sane way of passing this all the way to the dmaengine driver. I don't see why this should be client (SPI) dependent. The max length supported is a dmaengine constraint, typically flowing from max blocks/length it can transfer. Know this limit can allow clients to split transfers. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
On 06/29/15 23:29, Michael Ellerman wrote:
On Wed, 2015-06-17 at 14:30 -0400, David Long wrote:
On 06/16/15 09:17, Rob Herring wrote:
On Mon, Jun 15, 2015 at 11:42 AM, David Long wrote:
#define REG_OFFSET_NAME(r) \
{.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
#define REG_OFFSET_END {.name = NULL, .offset = 0}
Can't you also move these? ARM is complicated with the "ARM_"
prefixing, but the others appear to be the same. Maybe you can remove
the prefix or redefine the macro for ARM.
That would mandate that all the architecture-specific pt_regs structures
would have to use a top-level named field for each named register.
Why does it mandate that?
See eg. powerpc where we use REG_OFFSET_NAME for the top-level named fields and
then a different macro for the array elements:
#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs,
r)}
#define GPR_OFFSET_NAME(num) \
{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
static const struct pt_regs_offset regoffset_table[] = {
GPR_OFFSET_NAME(0),
GPR_OFFSET_NAME(1),
GPR_OFFSET_NAME(2),
GPR_OFFSET_NAME(3),
...
REG_OFFSET_NAME(nip),
REG_OFFSET_NAME(msr),
So I don't see why REG_OFFSET_NAME couldn't be common.
Sorry for the delay in responding to this.
OK, so you're saying architectures that don't want this constraint can
make their own macro. Seems to make this whole exercise slightly less
useful, but whatever.
I see three ways to go here:
1) Leave it as is.
2) Force all architectures to use a common definition.
3) Provide a common definition that all architectures (except "arm")
currently using this functionality will use.
I have a v2 patch to implement #3, ready to post. Do we think this is
the way to go? I don't like #2 because I really don't want to rename all
uses of the current register fields for arm since this is
architecture-specific code to begin with and since it affects code in 39
arm source files.
cheers
Thanks,
-dl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] powerpc/powernv: add event attribute and group to nest pmu
On Thu, 2015-07-16 at 16:43 +0530, Madhavan Srinivasan wrote:
> Add code to create event/format attributes and attribute groups for
> each nest pmu.
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Anton Blanchard
> Cc: Sukadev Bhattiprolu
> Cc: Anshuman Khandual
> Cc: Stephane Eranian
> Signed-off-by: Madhavan Srinivasan
> ---
> arch/powerpc/perf/nest-pmu.c | 65
>
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
> index c4c08e4dee55..f3418bdec1cd 100644
> --- a/arch/powerpc/perf/nest-pmu.c
> +++ b/arch/powerpc/perf/nest-pmu.c
> @@ -13,6 +13,17 @@
> static struct perchip_nest_info p8_nest_perchip_info[P8_NEST_MAX_CHIPS];
> static struct nest_pmu *per_nest_pmu_arr[P8_NEST_MAX_PMUS];
>
> +PMU_FORMAT_ATTR(event, "config:0-20");
> +static struct attribute *p8_nest_format_attrs[] = {
> + _attr_event.attr,
> + NULL,
> +};
> +
> +static struct attribute_group p8_nest_format_group = {
> + .name = "format",
> + .attrs = p8_nest_format_attrs,
> +};
> +
> static int nest_event_info(struct property *pp, char *name,
> struct nest_ima_events *p8_events, int string, u32 val)
> {
> @@ -46,6 +57,56 @@ static int nest_event_info(struct property *pp, char *name,
> return 0;
> }
>
> +/*
> + * Populate event name and string in attribute
> + */
> +static struct attribute *dev_str_attr(const char *name, const char *str)
> +{
> + struct perf_pmu_events_attr *attr;
> +
> + attr = kzalloc(sizeof(*attr), GFP_KERNEL);
> +
> + sysfs_attr_init(>attr.attr);
> +
> + attr->event_str = str;
> + attr->attr.attr.name = name;
> + attr->attr.attr.mode = 0444;
> + attr->attr.show = perf_event_sysfs_show;
> +
> + return >attr.attr;
So I asked you about this before, and you pointed me to
perf_event_sysfs_show. Looking at that in kernel/events/core.c, it looks
like that uses container_of to pull out the perf_pmu_events_attr. So I
guess that is at least mostly correct.
I'm hoping something else uses container_of to pull out attr->attr, so
that they can actually grab the attr->attr.show function pointer, so
that perf_event_sysfs_show actually gets called. Where would that be?
> +}
> +
> +static int update_events_in_group(
> + struct nest_ima_events *p8_events, int idx, struct nest_pmu *pmu)
> +{
> + struct attribute_group *attr_group;
> + struct attribute **attrs;
> + int i;
> +
> + /*
> + * Allocate memory for both event attribute group and for
> + * event attributes array.
> + */
> + attr_group = kzalloc(((sizeof(struct attribute *) * (idx + 1)) +
> + sizeof(*attr_group)), GFP_KERNEL);
> + if (!attr_group)
> + return -ENOMEM;
> +
> + /*
> + * Assign memory for event attribute array
> + */
> + attrs = (struct attribute **)(attr_group + 1);
> + attr_group->name = "events";
> + attr_group->attrs = attrs;
I am super uncomfortable with this block, especially the assignment to
attrs. I *think* you're trying to allocate an attribute group and a set
of attributes, but you've combined the allocation into one big
contiguous chunk, and then you're trying to tease them apart. Is that
necessary? Could it be two allocs, one for the attribute_group and one
for the attribute?
--
Regards,
Daniel
signature.asc
Description: This is a digitally signed message part
[PATCH 16/39 RESEND] perf tests: Add LLVM test for eBPF on-the-fly compiling
Previous patches introduce llvm__compile_bpf() to compile source file to
eBPF object. This patch adds testcase to test it. It also tests libbpf
by opening generated object after applying next patch which introduces
HAVE_LIBBPF_SUPPORT option.
Since llvm__compile_bpf() prints long messages which users who don't
explicitly test llvm doesn't care, this patch set verbose to -1 to
suppress all debug, warning and error message, and hint user use
'perf test -v' to see the full output.
For the same reason, if clang is not found in PATH and there's no [llvm]
section in .perfconfig, skip this test.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Cc: Arnaldo Carvalho de Melo
Link:
http://lkml.kernel.org/n/1436445342-1402-17-git-send-email-wangn...@huawei.com
---
Suppress error message if clang not found.
---
tools/perf/tests/Build | 1 +
tools/perf/tests/builtin-test.c | 4 ++
tools/perf/tests/llvm.c | 98 +
tools/perf/tests/tests.h| 1 +
tools/perf/util/llvm-utils.c| 9
tools/perf/util/llvm-utils.h| 10 +
6 files changed, 123 insertions(+)
create mode 100644 tools/perf/tests/llvm.c
diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index d20d6e6..c1518bd 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -32,6 +32,7 @@ perf-y += sample-parsing.o
perf-y += parse-no-sample-id-all.o
perf-y += kmod-path.o
perf-y += thread-map.o
+perf-y += llvm.o
perf-$(CONFIG_X86) += perf-time-to-tsc.o
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index c1dde73..136cd93 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -175,6 +175,10 @@ static struct test {
.func = test__thread_map,
},
{
+ .desc = "Test LLVM searching and compiling",
+ .func = test__llvm,
+ },
+ {
.func = NULL,
},
};
diff --git a/tools/perf/tests/llvm.c b/tools/perf/tests/llvm.c
new file mode 100644
index 000..a337356
--- /dev/null
+++ b/tools/perf/tests/llvm.c
@@ -0,0 +1,98 @@
+#include
+#include
+#include
+#include
+#include "tests.h"
+#include "debug.h"
+
+static int perf_config_cb(const char *var, const char *val,
+ void *arg __maybe_unused)
+{
+ return perf_default_config(var, val, arg);
+}
+
+/*
+ * Randomly give it a "version" section since we don't really load it
+ * into kernel
+ */
+static const char test_bpf_prog[] =
+ "__attribute__((section(\"do_fork\"), used)) "
+ "int fork(void *ctx) {return 0;} "
+ "char _license[] __attribute__((section(\"license\"), used)) = \"GPL\";"
+ "int _version __attribute__((section(\"version\"), used)) = 0x40100;";
+
+#ifdef HAVE_LIBBPF_SUPPORT
+static int test__bpf_parsing(void *obj_buf, size_t obj_buf_sz)
+{
+ struct bpf_object *obj;
+
+ obj = bpf_object__open_buffer(obj_buf, obj_buf_sz);
+ if (!obj)
+ return -1;
+ bpf_object__close(obj);
+ return 0;
+}
+#else
+static int test__bpf_parsing(void *obj_buf __maybe_unused,
+size_t obj_buf_sz __maybe_unused)
+{
+ fprintf(stderr, " (skip bpf parsing)");
+ return 0;
+}
+#endif
+
+int test__llvm(void)
+{
+ char *tmpl_new, *clang_opt_new;
+ void *obj_buf;
+ size_t obj_buf_sz;
+ int err, old_verbose;
+
+ perf_config(perf_config_cb, NULL);
+
+ /*
+* Skip this test if user's .perfconfig doesn't set [llvm] section
+* and clang is not found in $PATH, and this is not perf test -v
+*/
+ if (verbose == 0 && !llvm_param.user_set_param && llvm__search_clang())
{
+ fprintf(stderr, " (no clang, try 'perf test -v LLVM')");
+ return TEST_SKIP;
+ }
+
+ old_verbose = verbose;
+ /*
+* llvm is verbosity when error. Suppress all error output if
+* not 'perf test -v'.
+*/
+ if (verbose == 0)
+ verbose = -1;
+
+ if (!llvm_param.clang_bpf_cmd_template)
+ return -1;
+
+ if (!llvm_param.clang_opt)
+ llvm_param.clang_opt = strdup("");
+
+ err = asprintf(_new, "echo '%s' | %s", test_bpf_prog,
+ llvm_param.clang_bpf_cmd_template);
+ if (err < 0)
+ return -1;
+ err = asprintf(_opt_new, "-xc %s", llvm_param.clang_opt);
+ if (err < 0)
+ return -1;
+
+ llvm_param.clang_bpf_cmd_template = tmpl_new;
+ llvm_param.clang_opt = clang_opt_new;
+ err = llvm__compile_bpf("-", _buf, _buf_sz);
+
+ verbose = old_verbose;
+ if (err) {
+ if (!verbose)
+
Re: [RFC PATCH 04/21] x86/hweight: Add stack frame dependency for __arch_hweight*()
On Tue, Jul 21, 2015 at 09:39:23PM -0700, Andy Lutomirski wrote: > So your shiny perf profile shows cumulative time in whatever called > them. Sure, this is arguably silly if we're stuck with frame > pointers. You can count 20ish cycles tops for any one of them. At least that was from the last time when comparing POPCNT perf to the __sw_hweight* ones. IOW, POPCNT didn't show any improvement vs those sw versions. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] xen-blkfront: rm BUG_ON(info->feature_persistent) in blkif_free
On 07/21/2015 05:25 PM, Roger Pau Monné wrote: > El 21/07/15 a les 5.30, Bob Liu ha escrit: >> This BUG_ON() in blkif_free() is incorrect, because indirect page can be >> added >> to list info->indirect_pages in blkif_completion() no matter >> feature_persistent >> is true or false. >> >> Signed-off-by: Bob Liu > > Acked-by: Roger Pau Monné > > This was probably an oversight from when blkif_completion was changed to > check for gnttab_query_foreign_access. It should be backported to stable > trees. > Sorry, this patch is buggy and I haven't figure out why. general protection fault: [#1] SMP Modules linked in: CPU: 0 PID: 39 Comm: xenwatch Tainted: GW 4.1.0-rc3-3-g718cf80-dirty #67 Hardware name: Xen HVM domU, BIOS 4.5.0-rc 11/23/2014 task: 880283f4eca0 ti: 880283fb4000 task.ti: 880283fb4000 RIP: 0010:[] [] blkif_free+0x162/0x5a9 RSP: 0018:880283fb7c48 EFLAGS: 00010087 RAX: dead00200200 RBX: 88014140 RCX: RDX: dead00100100 RSI: dead00100100 RDI: 88028f418bb8 RBP: 880283fb7ca8 R08: dead00200200 R09: 0001 R10: 0001 R11: R12: 8801414481c8 R13: dead001000e0 R14: 8801414481b8 R15: ea00 FS: () GS:88028f40() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 01582e08 CR3: 00013345b000 CR4: 001406f0 Stack: 880023aa8420 0286 880283fb7cb7 880023aa8420 8800363fe240 81862c50 880283fb7ce8 880023aa8440 8187 880023aa8400 88014140 88014148 Call Trace: [] blkfront_remove+0x4c/0xff [] xenbus_dev_remove+0x76/0xb0 [] __device_release_driver+0x84/0xf8 [] device_release_driver+0x1e/0x2b [] bus_remove_device+0x12c/0x141 [] device_del+0x161/0x1e5 [] ? xenbus_thread+0x239/0x239 [] device_unregister+0x43/0x4f [] xenbus_dev_changed+0x82/0x17f [] ? xenbus_otherend_changed+0xf0/0xff [] frontend_changed+0x43/0x48 [] xenwatch_thread+0xf9/0x127 [] ? add_wait_queue+0x44/0x44 [] kthread+0xcd/0xd5 [] ? alloc_pid+0xe8/0x492 [] ? kthread_freezable_should_stop+0x48/0x48 [] ret_from_fork+0x42/0x70 [] ? kthread_freezable_should_stop+0x48/0x48 Code: 04 00 4c 8b 28 48 8d 78 e0 49 83 ed 20 eb 3d 48 8b 47 28 48 8b 57 20 48 be 00 01 10 00 00 00 ad de 49 b8 00 02 20 00 00 00 ad de <48> 89 42 08 48 89 10 48 89 77 20 4c 89 47 28 31 f6 e8 26 7d cf RIP [] blkif_free+0x162/0x5a9 RSP ---[ end trace 5321d7f1ef8414d0 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Do not reserve crashkernel high memory if crashkernel low memory reserving failed
On 07/21/15 at 12:22pm, Yinghai Lu wrote: > On Tue, Jul 21, 2015 at 1:58 AM, Baoquan He wrote: > > > Maybe system which don't need low memory is rare, only for testing? > > No, it is not rare. > > All recent intel based systems with iommu support does not need low. > > And those systems get punished by following patch: > > | commit 94fb9334182284e8e7e4bcb9125c25dc33af19d4 > | Author: Joerg Roedel > | Date: Wed Jun 10 17:49:42 2015 +0200 > | > |x86/crash: Allocate enough low memory when crashkernel=high > > that reserve 256M low always. and those 256M get wasted. > > That commit should only be used to workaround some systems that > have partial iommu support. > Since low memory does not need for some machines, how about kexec does not allocate low memory automatically, if cmdline does not specify the option ",low". User shall know well, if they specify the cmdline with option ",high". Thanks Minfei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf test LLVM was: Re: [GIT PULL 00/39] perf tools: filtering events using eBPF programs
Hi Arnaldo, I noticed that you have rebase your perf/ebpf branch to 4.2-rc3. I have also done it in my tree. Please see: https://github.com/WangNan0/linux.git ebpf Also, please recollect patch "perf tests: Add LLVM test for eBPF on-the-fly compiling", which adds verbose control. I'll also post it again. Thank you. On 2015/7/21 19:41, Arnaldo Carvalho de Melo wrote: Em Tue, Jul 21, 2015 at 07:09:12PM +0800, Wangnan (F) escreveu: Hi Arnaldo, Have you recovered from your cold? Much better now, thanks. Could you please repick patch "perf tools: Introduce llvm config options" from my github: https://github.com/WangNan0/linux/commit/f9fb25c518c7e52a47e98c36ce49f51051bbccf4 I made a small change that introduce '-D__KERNEL__' in front of $CLANG_OPTIONS, so samples in 'samples/ebpf' should be compilable with perf now. I'll repost a patch by replying the original one also. Ok, saw that 12/39 repost, will pick it The following changes since commit 101ef9b4f5c70dbfffa0186102c1014bd81a4ec7: bpf tools: Link all bpf objects onto a list (2015-07-13 18:48:17 -0300) are available in the git repository at: https://github.com/WangNan0/linux.git ebpf for you to fetch changes up to 51f169df1d11ea842a808d751f9c620371c55e74: bpf: Introduce function for outputing data to perf event (2015-07-21 10:55:48 +) Thank you. On 2015/7/17 11:48, Arnaldo Carvalho de Melo wrote: On Jul 16, 2015 11:34 PM, "Wangnan (F)" mailto:wangn...@huawei.com>> wrote: On 2015/7/15 19:20, Arnaldo Carvalho de Melo wrote: Em Wed, Jul 15, 2015 at 06:49:40PM +0800, Wangnan (F) escreveu: On 2015/7/14 23:36, Arnaldo Carvalho de Melo wrote: I have the trees cloned and plan to follow these instructions to have this test passing, to then move on to the next patches, but one request, please change the above to produce: 38: Test LLVM searching and compiling :(no clang) Ok run 'perf test -v LLVM' for instructions on having a clang environment The output format you desire is hard to implement, because 'Ok' is printed by the parent process. We have to find a way to allow child process to pass 'run 'perf test -v LLVM' for ...' to parent, then parent can print it after 'Ok'. I change this test as follow: From a quick look: excellent, thanks for improving this, I downloaded llvm and clang, built it, and the test passes, will apply this new patch and continue from there, - Arnaldo Hi Arnaldo, What's the reviewing going on? Was sidetracked with some other stuff and was a bit slow due to a cold, hope to get back to work on ebpf+perf in 8 hours ir so. Thanks, Arnaldo I collected some more patches on my git tree to avoid losting, and will collect more on it. I'll keep this patchset at the bottom so I think you shoud not be affected. Here is the new branch: https://github.com/WangNan0/linux.git ebpf Do you want me to keep the original perf/ebpf-for-acme branch? Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 04/21] x86/hweight: Add stack frame dependency for __arch_hweight*()
On Tue, Jul 21, 2015 at 9:25 PM, Borislav Petkov wrote: > On Tue, Jul 21, 2015 at 05:13:12PM -0700, Andy Lutomirski wrote: >> Enough for oopses, perhaps, but maybe not enough for perf. >> >> It sounds like you want CFI unwinding :) > > What would you want to unwind in those __sw_hweight* almost-trivial, > tail functions? So your shiny perf profile shows cumulative time in whatever called them. Sure, this is arguably silly if we're stuck with frame pointers. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] soft lockup: kill realtime threads before panic
On Tue, 2015-07-21 at 15:07 -0700, Spencer Baugh wrote: > We have observed cases where the soft lockup detector triggered, but no > kernel bug existed. Instead we had a buggy realtime thread that > monopolized a cpu. So let's kill the responsible party and not panic > the entire system. If you don't tell the kernel to panic, it won't, and if you don't remove its leash (the throttle), your not so tame rt beast won't maul you. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 04/21] x86/hweight: Add stack frame dependency for __arch_hweight*()
On Tue, Jul 21, 2015 at 05:13:12PM -0700, Andy Lutomirski wrote: > Enough for oopses, perhaps, but maybe not enough for perf. > > It sounds like you want CFI unwinding :) What would you want to unwind in those __sw_hweight* almost-trivial, tail functions? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel broken on processors without performance counters
On Tue, Jul 21, 2015 at 02:50:25PM -0400, Jason Baron wrote: > hmmm...so this is a case where need to the default the branch > to the out-of-line branch at boot. That is, we can't just enable > the out-of-line branch at boot time, b/c it might be too late at > that point? IE native_sched_clock() gets called very early? Well, even the layout is wrong here. The optimal thing would be to have: NOP rdtsc unlikely: /* read jiffies */ at build time. And then at boot time, patch in the JMP over the NOP on !use_tsc boxes. And RDTSC works always, no matter how early. I'm fairly sure we can do that now with alternatives instead of jump labels. The problem currently is that the 5-byte NOP gets patched in with a JMP so we have an unconditional forwards JMP to the RDTSC. Now I'd put my money on most arches handling NOPs better then unconditional JMPs and this is a hot path... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous
On Tue, Jul 21, 2015 at 7:53 PM, Brian Gerst wrote: > On Tue, Jul 21, 2015 at 10:12 PM, Andy Lutomirski wrote: >> On Tue, Jul 21, 2015 at 7:01 PM, Brian Gerst wrote: >>> On Tue, Jul 21, 2015 at 3:59 PM, Andy Lutomirski wrote: modify_ldt has questionable locking and does not synchronize threads. Improve it: redesign the locking and synchronize all threads' LDTs using an IPI on all modifications. >>> >>> What does this fix? I can see sending an IPI if the LDT is >>> reallocated, but on every update seems unnecessary. >>> >> >> It prevents nastiness in which you're in user mode with an impossible >> CS or SS, resulting in potentially interesting artifacts in >> interrupts, NMIs, etc. > > By impossible, do you mean a partially updated descriptor when the > interrupt occurs? Would making sure that the descriptor is atomically > updated (using set_64bit()) fix that? > I tried to exploit that once and didn't get very far. If I could cause the LDT to be populated one bit at a time, I think I could materialize a call gate out of thin air. The docs are unclear on what, if anything, the memory ordering rules are. I'm more concerned about the case where a segment register caches a value that is no longer in the LDT. If it's DS, ES, FS, or GS, it results in nondeterministic behavior but is otherwise not a big deal. If it's CS or SS, then an interrupt or exception will write a stack frame with the selectors but IRET can fault. If the interrupt is an NMI and certain other conditions are met and your kernel is older than 4.2-rc3, then you should read the CVE-2015-5157 advisory I'll send tomorrow :) Even on 4.2-rc3, the NMI code still struggles a bit if this happens. With this patch, you can never be in user mode with CS or SS selectors that point at the LDT but don't match the LDT. That makes me a lot more comfortable with modify_ldt. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
On Wed, 22 Jul 2015, Michael Schmitz wrote: > Hi Finn, > > I'm afraid I cannot test anything on Atari hardware at present - my > Falcon ate it's IDE disk partition table with all the fun that entails. That doesn't sound good. > Haven't even begun to try and recover that yet. > > If you send a patch I could build a kernel and send that to Christian > for testing (if he's got his Falcon up and running - might be a tad warm > in the attic for that, in fact). Anyone with a suitable Atari, i.e. ATARIHW_PRESENT(TT_CLK), who can boot both TOS and Linux could resolve the question. (Perhaps with an emulator?) Any old kernel binary would do, since atari_scsi should print either "HOSTID=n" or "this_id n" at startup. If n doesn't agree with what TOS says about the host's SCSI ID, then I think a trivial patch is safe enough. Especially if cat /proc/driver/nvram produces a "SCSI host ID : m" that does agree with TOS. Regards, Finn > > Cheers, > > Michael > > > Am 14.07.15 um 20:17 schrieb Finn Thain: > > On Mon, 13 Jul 2015, Andreas Schwab wrote: > > > > > Finn Thain writes: > > > > > > > BTW, I didn't change the SCSI ID location in NVRAM. This code says 16 > > > > whereas atari_scsi says 14. Which one is correct? > > > I think atari_scsi is wrong. The best source I could find > > > (http://www.gratifiant.com/nvram-falcon-t561185) places it after the > > > video mode byte, thus at byte 16. > > Thanks for that. BTW, I googled a phrase from that page and found this one > >http://toshyp.atari.org/en/004009.html > > which may be closer to the source. > > > > I'll send a patch if someone can offer to test such a change to atari_scsi > > (or merely confirm that the SCSI ID setting in TOS does not match this_id > > given in dmesg). > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4 crypto: fix typo
On Thu, Jul 09, 2015 at 10:11:05PM +0200, Laurent Navet wrote: > derivatio -> derivation. > > Signed-off-by: Laurent Navet Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/7] powerpc/powernv: detect supported nest pmus and its events
> static struct perchip_nest_info p8_nest_perchip_info[P8_NEST_MAX_CHIPS];
> +static struct nest_pmu *per_nest_pmu_arr[P8_NEST_MAX_PMUS];
> +
> +static int nest_event_info(struct property *pp, char *name,
> + struct nest_ima_events *p8_events, int string, u32 val)
'int string' is a bit confusing. 'bool is_string' might be clearer, but
I think it would be even better still to have different functions for
string and non-string cases, especially because you only need val in the
non-string case.
That will also allow you to give the functions clearer names. I think
the function is populating the event with info from the dt property (in
the string case) or the val argument (non-string case) - maybe the names
could reflect that somehow?
> +{
> + char *buf;
> +
> +
> +static int nest_pmu_create(struct device_node *dev, int pmu_index)
> +{
> + struct nest_ima_events **p8_events_arr, *p8_events;
> + struct nest_pmu *pmu_ptr;
> + struct property *pp;
> + char *buf, *start;
> + const __be32 *lval;
> + u32 val;
> + int idx = 0, ret;
> +
> + if (!dev)
> + return -EINVAL;
> +
> + /* memory for nest pmus */
> + pmu_ptr = kzalloc(sizeof(struct nest_pmu), GFP_KERNEL);
> + if (!pmu_ptr)
> + return -ENOMEM;
> +
> + /* Needed for hotplug/migration */
> + per_nest_pmu_arr[pmu_index] = pmu_ptr;
> +
> + /* memory for nest pmu events */
> + p8_events_arr = kzalloc((sizeof(struct nest_ima_events) * 64),
> + GFP_KERNEL);
> + if (!p8_events_arr)
> + return -ENOMEM;
> + p8_events = (struct nest_ima_events *)p8_events_arr;
I'm still quite uncomfortable with this.
- Why * 64? Should it be * P8_NEST_MAX_EVENTS_SUPPORTED? Or is it a
different constant?
- p8_events = p8_events_arr[0] would be clearer
> +
> + /*
> + * Loop through each property
> + */
> + for_each_property_of_node(dev, pp) {
> + start = pp->name;
> +
> + if (!strcmp(pp->name, "name")) {
> + if (!pp->value ||
> +(strnlen(pp->value, pp->length) == pp->length) ||
> +(pp->length > P8_NEST_MAX_PMU_NAME_LEN))
> + return -EINVAL;
> +
> + buf = kzalloc(P8_NEST_MAX_PMU_NAME_LEN, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + /* Save the name to register it later */
> + sprintf(buf, "Nest_%s", (char *)pp->value);
> + pmu_ptr->pmu.name = (char *)buf;
> + continue;
> + }
> +
> + /* Skip these, we dont need it */
"don't" instead of "dont".
> + if (!strcmp(pp->name, "phandle") ||
> + !strcmp(pp->name, "device_type") ||
> + !strcmp(pp->name, "linux,phandle"))
> + continue;
> +
> + if (strncmp(pp->name, "unit.", 5) == 0) {
> + /* Skip first few chars in the name */
The whole comment is pretty uninformative, as is the similar comment
below. If you need a comment at all, maybe something along the lines of
"Strip the prefix because "?
> + start += 5;
> + ret = nest_event_info(pp, start, p8_events++, 1, 0);
> + } else if (strncmp(pp->name, "scale.", 6) == 0) {
> + /* Skip first few chars in the name */
> + start += 6;
> + ret = nest_event_info(pp, start, p8_events++, 1, 0);
> + } else {
> + lval = of_get_property(dev, pp->name, NULL);
> + val = (uint32_t)be32_to_cpup(lval);
> +
> + ret = nest_event_info(pp, start, p8_events++, 0, val);
> + }
> +
> + if (ret)
> + return ret;
> +
> + /* book keeping */
> + idx++;
You don't seem to use idx in this function, apart from incrementing it
here...?
> + }
> +
> + return 0;
> +}
--
Regards,
Daniel
signature.asc
Description: This is a digitally signed message part
Re: [PATCH V2] ext4 crypto: exit cleanly if ext4_derive_key_aes() fails
On Thu, Jul 09, 2015 at 10:07:14PM +0200, Laurent Navet wrote: > Return value of ext4_derive_key_aes() is stored but not used. > Add test to exit cleanly if ext4_derive_key_aes() fail. > Also fix coverity CID 1309760. > > Signed-off-by: Laurent Navet Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/10] arch: introduce memremap()
On Tue, Jul 21, 2015 at 4:58 PM, Luis R. Rodriguez wrote:
> On Sun, Jul 19, 2015 at 08:18:23PM -0400, Dan Williams wrote:
>> diff --git a/include/linux/io.h b/include/linux/io.h
>> index 080a4fbf2ba4..2983b6e63970 100644
>> --- a/include/linux/io.h
>> +++ b/include/linux/io.h
>> @@ -192,4 +192,15 @@ static inline int arch_phys_wc_index(int handle)
>> #endif
>> #endif
>>
>> +enum {
>> + MEMREMAP_WB = 1 << 0,
>> + MEMREMAP_WT = 1 << 1,
>> + MEMREMAP_WC = 1 << 2,
>> + MEMREMAP_STRICT = 1 << 3,
>> + MEMREMAP_CACHE = MEMREMAP_WB,
>> +};
>
> A few things:
>
> 1) You'll need MEMREMAP_UC now as well now.
Why? I don't think it fits. If there are any I/O areas (non-memory)
in the range then it simply is not "memory" and should not be using
memremap(). In other words it seems like you really do need to heed
the __iomem annotation in the return value from ioremap_uc().
> 2) as you are doing all this sweep over architectures on this please
> also address the lack of ioremap_*() variant implemention to return
> NULL, ie not supported, because we've decided for now that so long
> as the semantics are not well defined we can't expect architectures
> to get it right unless they are doing the work themselves, and the
> old strategy of just #defin'ing a variant to iorempa_nocache() which
> folks tended to just can lead to issues. In your case since you are
> jumping to the flags implementation this might be knocking two birds
> with one stone.
I'm not going to do a general sweep for this as the expectation that
ioremap silently falls back if a mapping type is not supported is
buried all over the place. That said, new usages and conversions to
memremap() can be strict about this. For now, I'm only handling
ioremap_cache() and ioremap_wt() conversions.
> 3) For the case that architectures have no MMU we currently do a direct
> mapping such as what you try to describe to do with memremap(). I wonder
> if its worth it to then enable that code to just map to memremap(). That
> throws off your usage of CONFIG_ARCH_HAS_MEMREMAP if we want to repurpose
> that implementation for no the MMU case, unless of course you just have a
> __memremap() which does the default basic direct mapping implementation.
Yes, in the next rev of this series I am having it fall back to direct
mappings where it makes sense.
> 4) Since we are all blaming semantics on our woes I'd like to ask for
> some effort on semantics to be well defined. Semantics here sholud cover
> some form of Documentation but also sparse annotation checks and perhaps
> Coccinelle grammar rules for how things should be done. This should not only
> cover general use but also if there are calls which depend on a cache
> type to have been set. If we used sparse annotations it may meen a
> different return type for each cache type. Not sure if we want this.
> If we went with grammar rules I'm looking to for instance have in place
> rules on scripts/coccinelle which would allow developers to use
memremap() explicitly does not want get into arch semantics debates.
The pointer returned from memremap() is a "void *" that can be used as
normal memory. If it is a normal pointer I don't see the role for
sparse annotation.
>
> make coccicheck M=foo/
>
> to find issues. I can perhaps help with this, but we'd need to do a good
> sweep here to not only cover good territory but also get folks to agree
> on things.
>
> 5) This may be related to 4), not sure. There are aligment requirements we
> should probably iron out for architectures. How will we annotate these
> requirements or allow architectures to be pedantic over these requirements?
What requirements beyond PAGE_SIZE alignment would we need to worry about?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mac80211_hwsim: unregister genetlink family properly
During hwsim_init_netlink(), we should call genl_unregister_family()
if failed on netlink_register_notifier() since the genetlink is
already registered.
Signed-off-by: Su Kang Yin
---
drivers/net/wireless/mac80211_hwsim.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 99e873d..16d953e 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3120,8 +3120,10 @@ static int hwsim_init_netlink(void)
goto failure;
rc = netlink_register_notifier(_netlink_notifier);
- if (rc)
+ if (rc) {
+ genl_unregister_family(_genl_family);
goto failure;
+ }
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ftrace-update-tracing_thresh-info
This patch updates the tracing_thresh information in ftrace documentation file(ftrace.txt). Signed-off-by: Umesh Tiwari --- Documentation/trace/ftrace.txt |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index 572ca92..c9b9a7f 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -137,8 +137,13 @@ of ftrace. Here is a list of some of the key files: tracing_thresh: - Some latency tracers will record a trace whenever the - latency is greater than the number in this file. + Function graph,Function profile and some latency tracers + will record a trace whenever the latency is greater than + the number in this file. + + In case of Function profile entries whose average value is + greater than the number in this file will be recorded. + Only active when the file contains a number greater than 0. (in microseconds) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ext4: implement cgroup writeback support
On Tue, Jun 16, 2015 at 06:53:13PM -0400, Tejun Heo wrote: > For ordered and writeback data modes, all data IOs go through > ext4_io_submit. This patch adds cgroup writeback support by invoking > wbc_init_bio() from io_submit_init_bio() and wbc_account_io() in > io_submit_add_bh(). Journal data which is written by jbd2 worker is > left alone by this patch and will always be written out from the root > cgroup. > > ext4_fill_super() is updated to set MS_CGROUPWB when data mode is > either ordered or writeback. In journaled data mode, most IOs become > synchronous through the journal and enabling cgroup writeback support > doesn't make much sense or difference. Journaled data mode is left > alone. > > Lightly tested with sequential data write workload. Behaves as > expected. > > v2: Updated for MS_CGROUPWB -> SB_I_CGROUPWB. > > Signed-off-by: Tejun Heo > Cc: "Theodore Ts'o" > Cc: Andreas Dilger > Cc: linux-e...@vger.kernel.org Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ext4: replace ext4_io_submit->io_op with ->io_wbc
On Tue, Jun 16, 2015 at 06:53:12PM -0400, Tejun Heo wrote: > ext4_io_submit_init() takes the pointer to writeback_control to test > its sync_mode and determine between WRITE and WRITE_SYNC and records > the result in ->io_op. This patch makes it record the pointer > directly and moves the test to ext4_io_submit(). > > This doesn't cause any noticeable differences now but having > writeback_control available throughout IO submission path will be > depended upon by the planned cgroup writeback support. > > Signed-off-by: Tejun Heo > Cc: "Theodore Ts'o" > Cc: Andreas Dilger > Cc: linux-e...@vger.kernel.org Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
Hi Finn, I'm afraid I cannot test anything on Atari hardware at present - my Falcon ate it's IDE disk partition table with all the fun that entails. Haven't even begun to try and recover that yet. If you send a patch I could build a kernel and send that to Christian for testing (if he's got his Falcon up and running - might be a tad warm in the attic for that, in fact). Cheers, Michael Am 14.07.15 um 20:17 schrieb Finn Thain: On Mon, 13 Jul 2015, Andreas Schwab wrote: Finn Thain writes: BTW, I didn't change the SCSI ID location in NVRAM. This code says 16 whereas atari_scsi says 14. Which one is correct? I think atari_scsi is wrong. The best source I could find (http://www.gratifiant.com/nvram-falcon-t561185) places it after the video mode byte, thus at byte 16. Thanks for that. BTW, I googled a phrase from that page and found this one http://toshyp.atari.org/en/004009.html which may be closer to the source. I'll send a patch if someone can offer to test such a change to atari_scsi (or merely confirm that the SCSI ID setting in TOS does not match this_id given in dmesg). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/7] powerpc/powernv: Nest PMU detection and device tree parser
Hi,
> +static struct perchip_nest_info p8_nest_perchip_info[P8_NEST_MAX_CHIPS];
> +
> +static int nest_ima_dt_parser(void)
> +{
> + const __be32 *gcid;
> + const __be64 *chip_ima_reg;
> + const __be64 *chip_ima_size;
> + struct device_node *dev;
> + struct perchip_nest_info *p8ni;
> + int idx;
> +
> + /*
> + * "nest-ima" folder contains two things,
> + * a) per-chip reserved memory region for Nest PMU Counter data
> + * b) Support Nest PMU units and their event files
> + */
> + for_each_node_with_property(dev, "ibm,ima-chip") {
> + gcid = of_get_property(dev, "ibm,chip-id", NULL);
> + chip_ima_reg = of_get_property(dev, "reg", NULL);
> + chip_ima_size = of_get_property(dev, "size", NULL);
> +
> + if ((!gcid) || (!chip_ima_reg) || (!chip_ima_size)) {
> + pr_err("Nest_PMU: device %s missing property\n",
> + dev->full_name);
> + return -ENODEV;
> + }
> +
> + /* chip id to save reserve memory region */
> + idx = (uint32_t)be32_to_cpup(gcid);
So be32_to_cpup returns a __u32. You're casting to a uint32_t and then
assigning to an int.
- Do you need the intermediate cast?
- Should idx be an unsigned type?
> +
> + /*
> + * Using a local variable to make it compact and
> + * easier to read
> + */
We probably don't need this comment. But a better variable name would be
helpful!
> + p8ni = _nest_perchip_info[idx];
> + p8ni->pbase = be64_to_cpup(chip_ima_reg);
> + p8ni->size = be64_to_cpup(chip_ima_size);
> + p8ni->vbase = (uint64_t) phys_to_virt(p8ni->pbase);
> + }
> +
> + return 0;
> +}
> +
> +static int __init nest_pmu_init(void)
> +{
> + int ret = -ENODEV;
> +
> + /*
> + * Lets do this only if we are hypervisor
> + */
> + if (!cur_cpu_spec->oprofile_cpu_type ||
> + !(strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power8") == 0) ||
> + !cpu_has_feature(CPU_FTR_HVMODE))
> + return ret;
> +
I'm still really uncomfortable with doing this via oprofile_cpu_type.
If the kernel is compiled without oprofile support, will that get
populated?
I'm also curious about why we need checking for power8 at all. We
already know we're not going to run on hardware without a nest PMU
because of the device tree check below.
What happens if there's a future generation of chip that supports nest
PMUs?
If it's really important to check versions in this function, maybe you
could put a version property in the ibm,ima-chip node?
> + /*
> + * Nest PMU information is grouped under "nest-ima" node
> + * of the top-level device-tree directory. Detect Nest PMU
> + * by the "ibm,ima-chip" property.
> + */
> + if (!of_find_node_with_property(NULL, "ibm,ima-chip"))
> + return ret;
> +
> + /*
> + * Parse device-tree for Nest PMU information
> + */
> + ret = nest_ima_dt_parser();
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +device_initcall(nest_pmu_init);
--
Regards,
Daniel
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 2/2] watchdog: add wdt shutdown callback to disable wdt if enabled
On 07/21/2015 08:26 PM, Eddie Huang wrote:
From: Greta Zhang
Without .shutdown(), watchdog might reset the system during power off.
For example, if watchdog's timeout is set to 30s, then it is reset to
zero by mtk_wdt_ping(). During power off, no app will ping watchdog,
but watchdog is still running and may trigger reset.
Signed-off-by: Greta Zhang
Signed-off-by: Eddie Huang
---
drivers/watchdog/mtk_wdt.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 5ef3910..c6741a5 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -217,6 +217,14 @@ static int mtk_wdt_probe(struct platform_device *pdev)
return 0;
}
+static void mtk_wdt_shutdown(struct platform_device *pdev)
+{
+ struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
+
+ if (mtk_wdt->started)
watchdog_active() ?
+ mtk_wdt_stop(_wdt->wdt_dev);
+}
+
static int mtk_wdt_remove(struct platform_device *pdev)
{
struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
@@ -266,6 +274,7 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids);
static struct platform_driver mtk_wdt_driver = {
.probe = mtk_wdt_probe,
.remove = mtk_wdt_remove,
+ .shutdown = mtk_wdt_shutdown,
.suspend= mtk_wdt_suspend,
.resume = mtk_wdt_resume,
.driver = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/3] STM trace event: Adding generic buffer interface driver
From: Mathieu Poirier
This patch adds a driver that models itself as an stm_source and
who's sole purpose is to export an interface to the rest of the
kernel. Once the stm and stm_source have been linked via sysfs,
everything that is passed to the interface will endup in the STM
trace engine.
Signed-off-by: Mathieu Poirier
Signed-off-by: Chunyan Zhang
---
drivers/hwtracing/stm/Kconfig | 11
drivers/hwtracing/stm/Makefile | 2 ++
drivers/hwtracing/stm/stm_trace_event.c | 46 +
3 files changed, 59 insertions(+)
create mode 100644 drivers/hwtracing/stm/stm_trace_event.c
diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig
index 583c222..ca3b9a9 100644
--- a/drivers/hwtracing/stm/Kconfig
+++ b/drivers/hwtracing/stm/Kconfig
@@ -23,3 +23,14 @@ config STM_SOURCE_CONSOLE
If you want to send kernel console messages over STM devices,
say Y.
+
+config TRACE_EVENT_STM
+ tristate "Redirect/copy the output from kernel trace event to STM
engine"
+ depends on STM
+ help
+ This option can be used to redirect or copy the output from kernel
trace
+ event to STM engine. Enabling this option will introduce a slight
+ timing effect.
+
+ If you want to send kernel trace event messages over STM devices,
+ say Y.
diff --git a/drivers/hwtracing/stm/Makefile b/drivers/hwtracing/stm/Makefile
index f9312c3..110a75a 100644
--- a/drivers/hwtracing/stm/Makefile
+++ b/drivers/hwtracing/stm/Makefile
@@ -7,3 +7,5 @@ obj-$(CONFIG_STM_DUMMY) += dummy_stm.o
obj-$(CONFIG_STM_SOURCE_CONSOLE) += stm_console.o
stm_console-y := console.o
+
+obj-$(CONFIG_TRACE_EVENT_STM) += stm_trace_event.o
diff --git a/drivers/hwtracing/stm/stm_trace_event.c
b/drivers/hwtracing/stm/stm_trace_event.c
new file mode 100644
index 000..bc77dae
--- /dev/null
+++ b/drivers/hwtracing/stm/stm_trace_event.c
@@ -0,0 +1,46 @@
+/*
+ * Simple kernel driver to link kernel trace event and an STM device
+ * Copyright (c) 2015, Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static struct stm_source_data stm_trace_event_data = {
+ .name = "stm_trace_event",
+ .nr_chans = 1,
+};
+
+void stm_trace_event_write(const char *buf, unsigned len)
+{
+ stm_source_write(_trace_event_data, 0, buf, len);
+}
+
+static int __init stm_trace_event_init(void)
+{
+ return stm_source_register_device(NULL, _trace_event_data);
+}
+
+static void __exit stm_trace_event_exit(void)
+{
+ stm_source_unregister_device(_trace_event_data);
+}
+
+module_init(stm_trace_event_init);
+module_exit(stm_trace_event_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("stm_trace_event driver");
+MODULE_AUTHOR("Mathieu Poirier ");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/3] trace: Add an output of trace event logs to STM
When the trace event happens, the traces would be committed to ring buffer.
This patch will add an output of the traces to an STM at this moment,
of course the precondition is TRACE_EVENT_STM be configured.
Signed-off-by: Chunyan Zhang
---
kernel/trace/trace_events.c | 2 ++
kernel/trace/trace_output.h | 7 +++
2 files changed, 9 insertions(+)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 404a372..35fd171 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -249,6 +249,8 @@ void trace_event_buffer_commit(struct trace_event_buffer
*fbuffer)
event_trigger_unlock_commit(fbuffer->trace_file, fbuffer->buffer,
fbuffer->event, fbuffer->entry,
fbuffer->flags, fbuffer->pc);
+
+ trace_event_stm_log(fbuffer);
}
EXPORT_SYMBOL_GPL(trace_event_buffer_commit);
diff --git a/kernel/trace/trace_output.h b/kernel/trace/trace_output.h
index 4cbfe85..28e25e9 100644
--- a/kernel/trace/trace_output.h
+++ b/kernel/trace/trace_output.h
@@ -41,5 +41,12 @@ extern struct rw_semaphore trace_event_sem;
#define SEQ_PUT_HEX_FIELD(s, x)\
trace_seq_putmem_hex(s, &(x), sizeof(x))
+#ifdef CONFIG_TRACE_EVENT_STM
+extern void stm_trace_event_write(const char *buf, unsigned len);
+extern void trace_event_stm_log(struct trace_event_buffer *buffer);
+#else
+static inline void trace_event_stm_log(struct trace_event_buffer *buffer) {}
+#endif
+
#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] trace: Introduce trace log output function for STM
This patch introduced a new function to print the trace events logs
to STM buffer when the trace event happens.
Signed-off-by: Chunyan Zhang
---
kernel/trace/Makefile | 1 +
kernel/trace/trace_output_stm.c | 22 ++
2 files changed, 23 insertions(+)
create mode 100644 kernel/trace/trace_output_stm.c
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 9b1044e..ac6c195 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -67,4 +67,5 @@ obj-$(CONFIG_UPROBE_EVENT) += trace_uprobe.o
obj-$(CONFIG_TRACEPOINT_BENCHMARK) += trace_benchmark.o
+obj-$(CONFIG_TRACE_EVENT_STM) += trace_output_stm.o
libftrace-y := ftrace.o
diff --git a/kernel/trace/trace_output_stm.c b/kernel/trace/trace_output_stm.c
new file mode 100644
index 000..42d5549
--- /dev/null
+++ b/kernel/trace/trace_output_stm.c
@@ -0,0 +1,22 @@
+#include
+#include "trace_output.h"
+
+void trace_event_stm_log(struct trace_event_buffer *buffer)
+{
+ /* use static because iter can be a bit big for the stack */
+ static struct trace_iterator iter;
+ struct trace_entry *entry = (struct trace_entry *)buffer->entry;
+ struct trace_event *event = NULL;
+
+ iter.ent = entry;
+
+ if (entry)
+ event = ftrace_find_event(entry->type);
+
+ if (event && event->funcs) {
+ event->funcs->trace(, 0, event);
+ stm_trace_event_write(iter.seq.buffer, iter.seq.seq.len);
+ iter.seq.seq.len = 0;
+ }
+}
+EXPORT_SYMBOL_GPL(trace_event_stm_log);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/3] Integration of trace events with System Trace IP blocks
IP blocks allowing a variety of trace sources to log debugging information to a pre-defined area have been introduced on a couple of architecture [1][2]. These system trace blocks (also known as STM) typically follow the MIPI STPv2 protocol [3] and provide a system wide logging facility to any device, running a kernel or not, with access to the block's log entry port(s). Since each trace message has a timestamp is it possible to correlate events happening in the entire system rather than being confined to the logging facility of a single entity. This patch is using a very simple "stm_source" introduced in [2] to duplicate the output of the trace event subsystem to an STM, in this case coresight STM. That way logging information generated by the trace event subsystem and gathered in the coresight sink can be used in conjunction with trace data from other board components, also collected in the same trace sink. This example is using coresight but the same would apply to any architecture wishing to do the same. So, this patch set has to depend on [2] from Alexander Shishkin. Thanks, Chunyan [1]. https://lkml.org/lkml/2015/2/4/729 [2]. https://lkml.org/lkml/2015/7/6/206 [3]. http://mipi.org/specifications/debug#STP Changes from RFC v3: * Update patch 1/3 based on the newest verson of STM patches from Alexander Shishkin * Addressed Steve's comments - Reused trace_raw_output_##call() rather than defined a new similar function. - Moved trace_event_stm_log() into trace_event_buffer_commit() Changes from RFC v2: - Revised some types and variable's name according to the code of v4.2-rc1 - Sorted this patch-set based on the v4.2-rc1 - Splited the patch 2/3 of my last patch-set to make code can be compiled after each patch is applied in order. Changes from RFC v1: - Marked module init/exit functions with __init/__exit key word according to the comments from Paul Bolle Chunyan Zhang (2): trace: Introduce trace log output function for STM trace: Add an output of trace event logs to STM Mathieu Poirier (1): STM trace event: Adding generic buffer interface driver drivers/hwtracing/stm/Kconfig | 11 drivers/hwtracing/stm/Makefile | 2 ++ drivers/hwtracing/stm/stm_trace_event.c | 46 + kernel/trace/Makefile | 1 + kernel/trace/trace_events.c | 2 ++ kernel/trace/trace_output.h | 7 + kernel/trace/trace_output_stm.c | 22 7 files changed, 91 insertions(+) create mode 100644 drivers/hwtracing/stm/stm_trace_event.c create mode 100644 kernel/trace/trace_output_stm.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] watchdog: add wdt suspend/resume support
On 07/21/2015 08:26 PM, Eddie Huang wrote:
From: Greta Zhang
add wdt driver suspend/resume support
Signed-off-by: Greta Zhang
Signed-off-by: Roger Lu
Signed-off-by: Eddie Huang
---
drivers/watchdog/mtk_wdt.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 938b987..5ef3910 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -65,6 +65,7 @@ struct mtk_wdt_dev {
struct watchdog_device wdt_dev;
void __iomem *wdt_base;
struct notifier_block restart_handler;
+ bool started;
Any reason why you can not use watchdog_active() ?
};
static int mtk_reset_handler(struct notifier_block *this, unsigned long mode,
@@ -125,6 +126,8 @@ static int mtk_wdt_stop(struct watchdog_device *wdt_dev)
reg &= ~WDT_MODE_EN;
iowrite32(reg, wdt_base + WDT_MODE);
+ mtk_wdt->started = false;
+
return 0;
}
@@ -135,6 +138,8 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
void __iomem *wdt_base = mtk_wdt->wdt_base;
int ret;
+ mtk_wdt->started = true;
+
ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
if (ret < 0)
return ret;
@@ -174,6 +179,8 @@ static int mtk_wdt_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mtk_wdt);
+ mtk_wdt->started = false;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mtk_wdt->wdt_base = devm_ioremap_resource(>dev, res);
if (IS_ERR(mtk_wdt->wdt_base))
@@ -221,6 +228,35 @@ static int mtk_wdt_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int mtk_wdt_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
+
+ if (mtk_wdt->started) {
+ mtk_wdt_stop(_wdt->wdt_dev);
+ mtk_wdt->started = true;
?
+ }
+
+ return 0;
+}
+
+static int mtk_wdt_resume(struct platform_device *pdev)
+{
+ struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
+
+ if (mtk_wdt->started) {
+ mtk_wdt_start(_wdt->wdt_dev);
+ mtk_wdt_ping(_wdt->wdt_dev);
+ }
+
+ return 0;
+}
+#else
+#definemtk_wdt_suspend NULL
+#definemtk_wdt_resume NULL
+#endif
+
static const struct of_device_id mtk_wdt_dt_ids[] = {
{ .compatible = "mediatek,mt6589-wdt" },
{ /* sentinel */ }
@@ -230,6 +266,8 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids);
static struct platform_driver mtk_wdt_driver = {
.probe = mtk_wdt_probe,
.remove = mtk_wdt_remove,
+ .suspend= mtk_wdt_suspend,
+ .resume = mtk_wdt_resume,
.driver = {
.name = DRV_NAME,
.of_match_table = mtk_wdt_dt_ids,
Typically drivers would use struct dev_pm_ops and
.pm = _wdt_pm_ops,
Any reason for not using the same mechanism ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] watchdog: add wdt suspend/resume support
From: Greta Zhang
add wdt driver suspend/resume support
Signed-off-by: Greta Zhang
Signed-off-by: Roger Lu
Signed-off-by: Eddie Huang
---
drivers/watchdog/mtk_wdt.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 938b987..5ef3910 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -65,6 +65,7 @@ struct mtk_wdt_dev {
struct watchdog_device wdt_dev;
void __iomem *wdt_base;
struct notifier_block restart_handler;
+ bool started;
};
static int mtk_reset_handler(struct notifier_block *this, unsigned long mode,
@@ -125,6 +126,8 @@ static int mtk_wdt_stop(struct watchdog_device *wdt_dev)
reg &= ~WDT_MODE_EN;
iowrite32(reg, wdt_base + WDT_MODE);
+ mtk_wdt->started = false;
+
return 0;
}
@@ -135,6 +138,8 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
void __iomem *wdt_base = mtk_wdt->wdt_base;
int ret;
+ mtk_wdt->started = true;
+
ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
if (ret < 0)
return ret;
@@ -174,6 +179,8 @@ static int mtk_wdt_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mtk_wdt);
+ mtk_wdt->started = false;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mtk_wdt->wdt_base = devm_ioremap_resource(>dev, res);
if (IS_ERR(mtk_wdt->wdt_base))
@@ -221,6 +228,35 @@ static int mtk_wdt_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int mtk_wdt_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
+
+ if (mtk_wdt->started) {
+ mtk_wdt_stop(_wdt->wdt_dev);
+ mtk_wdt->started = true;
+ }
+
+ return 0;
+}
+
+static int mtk_wdt_resume(struct platform_device *pdev)
+{
+ struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
+
+ if (mtk_wdt->started) {
+ mtk_wdt_start(_wdt->wdt_dev);
+ mtk_wdt_ping(_wdt->wdt_dev);
+ }
+
+ return 0;
+}
+#else
+#definemtk_wdt_suspend NULL
+#definemtk_wdt_resume NULL
+#endif
+
static const struct of_device_id mtk_wdt_dt_ids[] = {
{ .compatible = "mediatek,mt6589-wdt" },
{ /* sentinel */ }
@@ -230,6 +266,8 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids);
static struct platform_driver mtk_wdt_driver = {
.probe = mtk_wdt_probe,
.remove = mtk_wdt_remove,
+ .suspend= mtk_wdt_suspend,
+ .resume = mtk_wdt_resume,
.driver = {
.name = DRV_NAME,
.of_match_table = mtk_wdt_dt_ids,
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] watchdog: add wdt shutdown callback to disable wdt if enabled
From: Greta Zhang
Without .shutdown(), watchdog might reset the system during power off.
For example, if watchdog's timeout is set to 30s, then it is reset to
zero by mtk_wdt_ping(). During power off, no app will ping watchdog,
but watchdog is still running and may trigger reset.
Signed-off-by: Greta Zhang
Signed-off-by: Eddie Huang
---
drivers/watchdog/mtk_wdt.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 5ef3910..c6741a5 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -217,6 +217,14 @@ static int mtk_wdt_probe(struct platform_device *pdev)
return 0;
}
+static void mtk_wdt_shutdown(struct platform_device *pdev)
+{
+ struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
+
+ if (mtk_wdt->started)
+ mtk_wdt_stop(_wdt->wdt_dev);
+}
+
static int mtk_wdt_remove(struct platform_device *pdev)
{
struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
@@ -266,6 +274,7 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids);
static struct platform_driver mtk_wdt_driver = {
.probe = mtk_wdt_probe,
.remove = mtk_wdt_remove,
+ .shutdown = mtk_wdt_shutdown,
.suspend= mtk_wdt_suspend,
.resume = mtk_wdt_resume,
.driver = {
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Add Mediatek watchdog suspend resume and shutdown
This series add Mediatek watchdog suspend, resume and shutdown support. These patches are based on v4.2-rc1 Greta Zhang (2): watchdog: add wdt suspend/resume support watchdog: add wdt shutdown callback to disable wdt if enabled drivers/watchdog/mtk_wdt.c | 47 ++ 1 file changed, 47 insertions(+) -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 00/58] 4.0.9-stable review
On Tue, Jul 21, 2015 at 06:14:06PM -0400, Donald Parsons wrote:
> On Tue, 2015-07-21 at 14:10 -0700, Greg Kroah-Hartman wrote:
> > > Andrew Morton (1):
> > > arch/x86/kvm/mmu.c: work around gcc-4.4.4 bug
> > >
> > > which must be it. Added Andrew to cc as he hopefully knows the
> > answer to your question.
> >
> > You can dig through git to find it pretty easily...
> >
> > Anyway, given that the 4.0 release I'm doing at the moment is the last
> > one, and it's end-of-life, this is a bit late and isn't going to
> > matter much. People should be on 4.1 already.
>
> Okay. But just in case. I had to learn about git and do a checkout.
>
> git log v4.1-rc8 arch/x86/kvm/mmu.c shows:
>
> commit 5ec45a192fe6e287f0fc06d5ca4f3bd446d94803
> Author: Andrew Morton
> Date: Wed Jun 10 11:15:02 2015 -0700
>
> arch/x86/kvm/mmu.c: work around gcc-4.4.4 bug
>
> Fix this compile issue with gcc-4.4.4:
>
>arch/x86/kvm/mmu.c: In function 'kvm_mmu_pte_write':
>arch/x86/kvm/mmu.c:4256: error: unknown field 'cr0_wp' specified
> in initializer
>arch/x86/kvm/mmu.c:4257: error: unknown field 'cr4_pae' specified
> in initializer
>arch/x86/kvm/mmu.c:4257: warning: excess elements in union
> initializer
>...
>
> gcc-4.4.4 (at least) has issues when using anonymous unions in
> initializers.
>
> Fixes: edc90b7dc4ceef6 ("KVM: MMU: fix SMAP virtualization")
> Cc: Xiao Guangrong
> Cc: Paolo Bonzini
> Cc: Davidlohr Bueso
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
>
>
> Hopefully commit 5ec45a192fe6e287f0fc06d5ca4f3bd446d94803
> is what you were looking for. If not, very sorry for interrupting you.
Thanks, that's exactly what I needed. I've queued it up, in the
off-chance that there would be another 4.0-stable kernel, but I don't
think there will be. Please move to 4.1 at this point in time.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 4.1.3
I'm announcing the release of the 4.1.3 kernel. All users of the 4.1 kernel series must upgrade. The updated 4.1.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.1.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 Documentation/DMA-API-HOWTO.txt | 29 ++- Documentation/DMA-API.txt | 30 +-- Documentation/devicetree/bindings/spi/spi_pl022.txt |2 Makefile|2 arch/arc/include/asm/atomic.h | 21 ++ arch/arc/include/asm/bitops.h | 19 ++ arch/arc/include/asm/cmpxchg.h | 26 ++- arch/arc/include/asm/spinlock.h | 32 arch/arc/kernel/perf_event.c|1 arch/arm64/kernel/entry.S |1 arch/arm64/kernel/vdso/Makefile |4 arch/arm64/mm/context.c |8 + arch/arm64/mm/init.c|2 arch/s390/hypfs/inode.c | 12 - drivers/acpi/bus.c | 56 +-- drivers/acpi/device_pm.c|1 drivers/acpi/osl.c |6 drivers/acpi/resource.c | 160 drivers/base/regmap/regmap.c|5 drivers/firmware/efi/efi.c |6 drivers/gpio/gpio-crystalcove.c |1 drivers/gpio/gpio-rcar.c| 13 + drivers/iio/accel/kxcjk-1013.c |1 drivers/infiniband/ulp/srp/ib_srp.c | 83 -- drivers/infiniband/ulp/srp/ib_srp.h |2 drivers/input/touchscreen/pixcir_i2c_ts.c |2 drivers/leds/led-class.c|7 drivers/misc/mei/client.c |2 drivers/misc/mei/hw-me.c| 59 ++- drivers/misc/mei/hw-txe.c | 33 ++-- drivers/misc/mei/mei_dev.h | 11 + drivers/mtd/maps/dc21285.c |4 drivers/mtd/mtd_blkdevs.c |5 drivers/of/address.c|2 drivers/pci/Kconfig |4 drivers/pci/bus.c | 10 - drivers/pci/hotplug/pciehp_hpc.c| 52 -- drivers/pci/pci.c | 11 + drivers/pci/probe.c | 12 - drivers/pcmcia/topic.h | 16 ++ drivers/pnp/system.c| 35 +++- drivers/power/power_supply_core.c | 61 ++- drivers/regulator/core.c|2 drivers/regulator/max77686.c|6 drivers/scsi/ipr.h |2 drivers/scsi/scsi_transport_srp.c | 58 --- drivers/spi/spi-orion.c | 25 ++- drivers/spi/spi.c | 11 - drivers/video/fbdev/mxsfb.c | 68 ++-- fs/configfs/mount.c | 10 - fs/debugfs/inode.c | 11 - fs/fuse/inode.c |9 - fs/kernfs/dir.c | 38 fs/kernfs/inode.c |2 fs/libfs.c | 96 fs/namespace.c | 31 +++ fs/proc/generic.c | 23 ++ fs/proc/inode.c |4 fs/proc/internal.h |6 fs/proc/proc_sysctl.c | 37 fs/proc/root.c |9 - fs/pstore/inode.c | 12 - fs/sysfs/dir.c | 34 fs/sysfs/mount.c|5 fs/tracefs/inode.c |6 include/linux/acpi.h| 12 + include/linux/fs.h |4 include/linux/kernfs.h |3 include/linux/kmemleak.h|6 include/linux/pci.h | 18 +- include/linux/power_supply.h|1 include/linux/sysctl.h |3 include/linux/sysfs.h
Re: Linux 4.0.9
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 0f7afb2bb442..aef8cc5a677b 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -25,13 +25,18 @@ physical addresses. These are the addresses in
/proc/iomem. The physical
address is not directly useful to a driver; it must use ioremap() to map
the space and produce a virtual address.
-I/O devices use a third kind of address: a "bus address" or "DMA address".
-If a device has registers at an MMIO address, or if it performs DMA to read
-or write system memory, the addresses used by the device are bus addresses.
-In some systems, bus addresses are identical to CPU physical addresses, but
-in general they are not. IOMMUs and host bridges can produce arbitrary
+I/O devices use a third kind of address: a "bus address". If a device has
+registers at an MMIO address, or if it performs DMA to read or write system
+memory, the addresses used by the device are bus addresses. In some
+systems, bus addresses are identical to CPU physical addresses, but in
+general they are not. IOMMUs and host bridges can produce arbitrary
mappings between physical and bus addresses.
+From a device's point of view, DMA uses the bus address space, but it may
+be restricted to a subset of that space. For example, even if a system
+supports 64-bit addresses for main memory and PCI BARs, it may use an IOMMU
+so devices only need to use 32-bit DMA addresses.
+
Here's a picture and some examples:
CPU CPU Bus
@@ -72,11 +77,11 @@ can use virtual address X to access the buffer, but the
device itself
cannot because DMA doesn't go through the CPU virtual memory system.
In some simple systems, the device can do DMA directly to physical address
-Y. But in many others, there is IOMMU hardware that translates bus
+Y. But in many others, there is IOMMU hardware that translates DMA
addresses to physical addresses, e.g., it translates Z to Y. This is part
of the reason for the DMA API: the driver can give a virtual address X to
an interface like dma_map_single(), which sets up any required IOMMU
-mapping and returns the bus address Z. The driver then tells the device to
+mapping and returns the DMA address Z. The driver then tells the device to
do DMA to Z, and the IOMMU maps it to the buffer at address Y in system
RAM.
@@ -98,7 +103,7 @@ First of all, you should make sure
#include
is in your driver, which provides the definition of dma_addr_t. This type
-can hold any valid DMA or bus address for the platform and should be used
+can hold any valid DMA address for the platform and should be used
everywhere you hold a DMA address returned from the DMA mapping functions.
What memory is DMA'able?
@@ -316,7 +321,7 @@ There are two types of DMA mappings:
Think of "consistent" as "synchronous" or "coherent".
The current default is to return consistent memory in the low 32
- bits of the bus space. However, for future compatibility you should
+ bits of the DMA space. However, for future compatibility you should
set the consistent mask even if this default is fine for your
driver.
@@ -403,7 +408,7 @@ dma_alloc_coherent() returns two values: the virtual
address which you
can use to access it from the CPU and dma_handle which you pass to the
card.
-The CPU virtual address and the DMA bus address are both
+The CPU virtual address and the DMA address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size. This invariant
exists (for example) to guarantee that if you allocate a chunk
@@ -645,8 +650,8 @@ PLEASE NOTE: The 'nents' argument to the dma_unmap_sg call
must be
dma_map_sg call.
Every dma_map_{single,sg}() call should have its dma_unmap_{single,sg}()
-counterpart, because the bus address space is a shared resource and
-you could render the machine unusable by consuming all bus addresses.
+counterpart, because the DMA address space is a shared resource and
+you could render the machine unusable by consuming all DMA addresses.
If you need to use the same streaming DMA region multiple times and touch
the data in between the DMA transfers, the buffer needs to be synced
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 52088408668a..7eba542eff7c 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -18,10 +18,10 @@ Part I - dma_ API
To get the dma_ API, you must #include . This
provides dma_addr_t and the interfaces described below.
-A dma_addr_t can hold any valid DMA or bus address for the platform. It
-can be given to a device to use as a DMA source or target. A CPU cannot
-reference a dma_addr_t directly because there may be translation between
-its physical address space and the bus address space.
+A dma_addr_t can hold any valid DMA address for the platform. It
Re: Linux 4.1.3
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 0f7afb2bb442..aef8cc5a677b 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -25,13 +25,18 @@ physical addresses. These are the addresses in
/proc/iomem. The physical
address is not directly useful to a driver; it must use ioremap() to map
the space and produce a virtual address.
-I/O devices use a third kind of address: a "bus address" or "DMA address".
-If a device has registers at an MMIO address, or if it performs DMA to read
-or write system memory, the addresses used by the device are bus addresses.
-In some systems, bus addresses are identical to CPU physical addresses, but
-in general they are not. IOMMUs and host bridges can produce arbitrary
+I/O devices use a third kind of address: a "bus address". If a device has
+registers at an MMIO address, or if it performs DMA to read or write system
+memory, the addresses used by the device are bus addresses. In some
+systems, bus addresses are identical to CPU physical addresses, but in
+general they are not. IOMMUs and host bridges can produce arbitrary
mappings between physical and bus addresses.
+From a device's point of view, DMA uses the bus address space, but it may
+be restricted to a subset of that space. For example, even if a system
+supports 64-bit addresses for main memory and PCI BARs, it may use an IOMMU
+so devices only need to use 32-bit DMA addresses.
+
Here's a picture and some examples:
CPU CPU Bus
@@ -72,11 +77,11 @@ can use virtual address X to access the buffer, but the
device itself
cannot because DMA doesn't go through the CPU virtual memory system.
In some simple systems, the device can do DMA directly to physical address
-Y. But in many others, there is IOMMU hardware that translates bus
+Y. But in many others, there is IOMMU hardware that translates DMA
addresses to physical addresses, e.g., it translates Z to Y. This is part
of the reason for the DMA API: the driver can give a virtual address X to
an interface like dma_map_single(), which sets up any required IOMMU
-mapping and returns the bus address Z. The driver then tells the device to
+mapping and returns the DMA address Z. The driver then tells the device to
do DMA to Z, and the IOMMU maps it to the buffer at address Y in system
RAM.
@@ -98,7 +103,7 @@ First of all, you should make sure
#include
is in your driver, which provides the definition of dma_addr_t. This type
-can hold any valid DMA or bus address for the platform and should be used
+can hold any valid DMA address for the platform and should be used
everywhere you hold a DMA address returned from the DMA mapping functions.
What memory is DMA'able?
@@ -316,7 +321,7 @@ There are two types of DMA mappings:
Think of "consistent" as "synchronous" or "coherent".
The current default is to return consistent memory in the low 32
- bits of the bus space. However, for future compatibility you should
+ bits of the DMA space. However, for future compatibility you should
set the consistent mask even if this default is fine for your
driver.
@@ -403,7 +408,7 @@ dma_alloc_coherent() returns two values: the virtual
address which you
can use to access it from the CPU and dma_handle which you pass to the
card.
-The CPU virtual address and the DMA bus address are both
+The CPU virtual address and the DMA address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size. This invariant
exists (for example) to guarantee that if you allocate a chunk
@@ -645,8 +650,8 @@ PLEASE NOTE: The 'nents' argument to the dma_unmap_sg call
must be
dma_map_sg call.
Every dma_map_{single,sg}() call should have its dma_unmap_{single,sg}()
-counterpart, because the bus address space is a shared resource and
-you could render the machine unusable by consuming all bus addresses.
+counterpart, because the DMA address space is a shared resource and
+you could render the machine unusable by consuming all DMA addresses.
If you need to use the same streaming DMA region multiple times and touch
the data in between the DMA transfers, the buffer needs to be synced
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 52088408668a..7eba542eff7c 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -18,10 +18,10 @@ Part I - dma_ API
To get the dma_ API, you must #include . This
provides dma_addr_t and the interfaces described below.
-A dma_addr_t can hold any valid DMA or bus address for the platform. It
-can be given to a device to use as a DMA source or target. A CPU cannot
-reference a dma_addr_t directly because there may be translation between
-its physical address space and the bus address space.
+A dma_addr_t can hold any valid DMA address for the platform. It
Linux 4.0.9
-- Note, this is the last 4.0-stable release, it is now end-of-life. Please move to 4.1-stable at this point in time. -- I'm announcing the release of the 4.0.9 kernel. All users of the 4.0 kernel series must upgrade. The updated 4.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.0.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 Documentation/DMA-API-HOWTO.txt | 29 +++--- Documentation/DMA-API.txt | 30 +++--- Documentation/devicetree/bindings/spi/spi_pl022.txt |2 Makefile|2 arch/arc/include/asm/atomic.h | 21 arch/arc/include/asm/bitops.h | 19 +++ arch/arc/include/asm/cmpxchg.h | 26 - arch/arc/include/asm/spinlock.h | 32 ++ arch/arm64/kernel/entry.S |1 arch/arm64/kernel/vdso/Makefile |4 arch/arm64/mm/context.c |8 + arch/arm64/mm/init.c|2 arch/s390/hypfs/inode.c | 12 -- drivers/acpi/bus.c | 56 --- drivers/acpi/device_pm.c|1 drivers/base/regmap/regmap.c|5 - drivers/firmware/efi/efi.c |6 - drivers/gpio/gpio-crystalcove.c |1 drivers/iio/accel/kxcjk-1013.c |1 drivers/infiniband/ulp/isert/ib_isert.c | 18 +++ drivers/infiniband/ulp/srp/ib_srp.c | 83 +++-- drivers/infiniband/ulp/srp/ib_srp.h |2 drivers/input/touchscreen/pixcir_i2c_ts.c |2 drivers/leds/led-class.c|7 - drivers/misc/mei/client.c |2 drivers/misc/mei/hw-me.c| 59 +++- drivers/misc/mei/hw-txe.c | 33 -- drivers/misc/mei/mei_dev.h | 11 ++ drivers/mtd/maps/dc21285.c |4 drivers/mtd/mtd_blkdevs.c |5 + drivers/of/address.c|2 drivers/pci/Kconfig |4 drivers/pci/bus.c | 10 +- drivers/pci/hotplug/pciehp_hpc.c| 52 +++--- drivers/pci/pci.c | 11 ++ drivers/pci/probe.c | 12 +- drivers/pcmcia/topic.h | 16 +++ drivers/regulator/core.c|2 drivers/regulator/max77686.c|6 - drivers/scsi/ipr.h |2 drivers/scsi/scsi_transport_srp.c | 58 +++- drivers/spi/spi-orion.c | 25 - drivers/spi/spi.c | 11 +- drivers/video/fbdev/mxsfb.c | 68 +++--- fs/configfs/mount.c | 10 -- fs/debugfs/inode.c | 11 -- fs/fuse/inode.c |9 - fs/kernfs/dir.c | 38 +++ fs/kernfs/inode.c |2 fs/libfs.c | 96 fs/namespace.c | 31 +- fs/proc/generic.c | 23 fs/proc/inode.c |4 fs/proc/internal.h |6 + fs/proc/proc_sysctl.c | 37 +++ fs/proc/root.c |9 - fs/pstore/inode.c | 12 -- fs/sysfs/dir.c | 34 +++ fs/sysfs/mount.c|5 - include/linux/acpi.h|2 include/linux/fs.h |4 include/linux/kernfs.h |3 include/linux/kmemleak.h|6 - include/linux/pci.h | 18 ++- include/linux/sysctl.h |3 include/linux/sysfs.h | 15 +++ include/linux/types.h | 12 ++ init/main.c |1
[PATCH] ftrace: Calculate the correct dyn_ftrace number to report to the userspace
From: Minfei Huang
Now, ftrace only calculate the dyn_ftrace number in the adding
breakpoint loop, not in adding update and finish update loop.
Calculate the correct dyn_ftrace, once ftrace reports the failure message
to the userspace.
Signed-off-by: Minfei Huang
---
arch/x86/kernel/ftrace.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 8b7b0a5..311bcf3 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -556,6 +556,7 @@ void ftrace_replace_code(int enable)
run_sync();
report = "updating code";
+ count = 0;
for_ftrace_rec_iter(iter) {
rec = ftrace_rec_iter_record(iter);
@@ -563,11 +564,13 @@ void ftrace_replace_code(int enable)
ret = add_update(rec, enable);
if (ret)
goto remove_breakpoints;
+ count++;
}
run_sync();
report = "removing breakpoints";
+ count = 0;
for_ftrace_rec_iter(iter) {
rec = ftrace_rec_iter_record(iter);
@@ -575,6 +578,7 @@ void ftrace_replace_code(int enable)
ret = finish_update(rec, enable);
if (ret)
goto remove_breakpoints;
+ count++;
}
run_sync();
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous
On Tue, Jul 21, 2015 at 10:12 PM, Andy Lutomirski wrote: > On Tue, Jul 21, 2015 at 7:01 PM, Brian Gerst wrote: >> On Tue, Jul 21, 2015 at 3:59 PM, Andy Lutomirski wrote: >>> modify_ldt has questionable locking and does not synchronize >>> threads. Improve it: redesign the locking and synchronize all >>> threads' LDTs using an IPI on all modifications. >> >> What does this fix? I can see sending an IPI if the LDT is >> reallocated, but on every update seems unnecessary. >> > > It prevents nastiness in which you're in user mode with an impossible > CS or SS, resulting in potentially interesting artifacts in > interrupts, NMIs, etc. By impossible, do you mean a partially updated descriptor when the interrupt occurs? Would making sure that the descriptor is atomically updated (using set_64bit()) fix that? -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
On Tue, Jul 21, 2015 at 09:40:29PM -0400, Mike Snitzer wrote: > On Tue, Jul 21 2015 at 9:00pm -0400, > Dave Chinner wrote: > > > On Wed, Jul 22, 2015 at 10:09:23AM +1000, Dave Chinner wrote: > > > On Tue, Jul 21, 2015 at 01:47:53PM -0400, Mike Snitzer wrote: > > > > On Tue, Jul 21 2015 at 11:34am -0400, Eric Sandeen > > > > wrote: > > > > > On 7/20/15 5:36 PM, Dave Chinner wrote: > > > > > The issue we had discussed previously is that there is no agreement > > > > > across block devices about whether ENOSPC is a permanent or temporary > > > > > condition. Asking the admin to tune the fs to each block device's > > > > > behavior sucks, IMHO. > > > > > > > > It does suck, but it beats the alternative of XFS continuing to do > > > > nothing about the problem. > > > > > > Just a comment on that: doing nothing is better than doing the wrong > > > thing and being stuck with it forever. :) > > > > > > > Disucssing more with Vivek, might be that XFS would be best served to > > > > model what dm-thinp has provided with its 'no_space_timeout'. It > > > > defaults to queueing IO for 60 seconds, once the timeout expires the > > > > queued IOs getted errored. If set to 0 dm-thinp will queue IO > > > > indefinitely. > > > > > > Yes, that's exactly what I proposed in the thread I referenced in > > > my previous email, and what got stuck on the bikeshed wall because > > > of these concerns about knob twiddling: > > > > > > http://oss.sgi.com/archives/xfs/2015-02/msg00346.html > > > > > > | e.g. if we need configurable error handling, it needs to be > > > | configurable for different error types, and it needs to be > > > | configurable on a per-mount basis. And it needs to be configurable > > > | at runtime, not just at mount time. That kind of leads to using > > > | sysfs for this. e.g. for each error type we ned to handle different > > > | behaviour for: > > > | > > > | $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/type > > > | [transient] permanent > > > | $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/perm_timeout_seconds > > > | 300 > > > | $ cat > > > | /sys/fs/xfs/vda/meta_write_errors/enospc/perm_max_retry_attempts > > > | 50 > > > | $ cat > > > | /sys/fs/xfs/vda/meta_write_errors/enospc/transient_fail_at_umount > > > | 1 > > > > > > I've rebased this patchset, and I'm cleaning it up now, so in a few > > > days I'll have something for review, likely for the 4.3 merge > > > window > > > > Just thinking a bit more on how to make this simpler to configure, > > is there a simple way for the filesystem to determine the current > > config of the dm thinp volume? i.e. if the dm-thinp volume is > > configured to error out immediately on enospc, then XFS should > > default to doing the same thing. having XFS be able to grab this > > status at mount time and change the default ENOSPC error config from > > transient to permanent on such dm-thinp volumes would go a long way > > to making these configs Just Do The Right Thing on block dev enospc > > errors... > > > > e.g. if dm-thinp is configured to queue for 60s and then fail on > > ENOSPC, we want XFS to fail immediately on ENOSPC in metadata IO. If > > dm-thinp is configured to ENOSPC instantly (i.e. no queueing) then > > we want XFS to retry and use it's default retry maximums before > > failing permanently. > > Yes, that'd be nice. But there isn't a way to easily get the DM thinp > device's config from within the kernel (unless XFS wants to get into the > business of issuing ioctls to DM devices.. unlikely). Not really. > I could be > persuaded to expose a per-device sysfs file to get the status (would > avoid need for ioctl), e.g.: > # cat /sys/block/dm-5/dm/status > (but that doesn't _really_ help in-kernel access, awkward for filesystem > code to be opening sysfs files!) No, not going that way. We have direct access through the bdev we opened, so that's the communications channel we'd need to use. > SO userspace (mkfs.xfs) could easily check the thinp device's setup > using 'dmsetup status ' (output will either contain > 'queue_if_no_space' or 'error_if_no_space'). The DM thinp > 'no_space_timeout' (applicable if queue_if_no_space) is a thinp global > accessed using a module param: > # cat /sys/module/dm_thin_pool/parameters/no_space_timeout > 60 Mkfs is not the right interface - users can change dm-thinp behaviour long after the filesystem was created and so the XFS config needs to be configurable, too. Further, I really don't want to have to add anything to the on-disk format to support error configuration because, well, that drives the level of complexity up a couple or orders of magnitude (mkfs, repair, metadump, db, etc all need to support it), especially when it can be driven easily from userspace after mount with far less constraints and support burden. > I'm open to considering alternative interfaces for getting you the info > you need. I just don't have a great sense for what mechanism you'd like > to use. Do we invent
Re: [PATCH] cpufreq: Avoid double addition/removal of sysfs links
On Wednesday, July 22, 2015 03:56:21 AM Rafael J. Wysocki wrote:
> On Wednesday, July 22, 2015 01:15:01 AM Rafael J. Wysocki wrote:
> > Hi VIresh,
> >
> > On Mon, Jul 20, 2015 at 11:47 AM, Viresh Kumar
> > wrote:
> > > Consider a dual core (0/1) system with two CPUs:
> > > - sharing clock/voltage rails and hence cpufreq-policy
> > > - CPU1 is offline while the cpufreq driver is registered
> > >
> > > - cpufreq_add_dev() is called from subsys callback for CPU0 and we
> > > create the policy for the CPUs and create link for CPU1.
> > > - cpufreq_add_dev() is called from subsys callback for CPU1, we find
> > > that the cpu is offline and we try to create a sysfs link for CPU1.
> >
> > So the problem is that the cpu_is_offline(cpu) check in
> > cpufreq_add_dev() matches two distinct cases: (1) the CPU was not
> > present before and it is just being hot-added and (2) the CPU is
> > initially offline, but present, and this is the first time its device
> > is registered. In the first case we can expect that the CPU will
> > become online shortly (although that is not guaranteed too), but in
> > the second case that very well may not happen.
> >
> > We need to be able to distinguish between those two cases and your
> > patch does that, but I'm not sure if this really is the most
> > straightforward way to do it.
>
> It looks like we need a mask of related CPUs that are present. Or,
> alternatively, a mask of CPUs that would have been related had they
> been present.
>
> That's sort of what your patch is adding, but not quite.
OK, below is my take on this (untested), on top of
https://patchwork.kernel.org/patch/6839031/
We still only create policies for online CPUs which may be confusing in some
cases, but that's because drivers may not be able to handle CPUs that aren't
online.
---
drivers/cpufreq/cpufreq.c | 41 +
include/linux/cpufreq.h |1 +
2 files changed, 26 insertions(+), 16 deletions(-)
Index: linux-pm/include/linux/cpufreq.h
===
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -62,6 +62,7 @@ struct cpufreq_policy {
/* CPUs sharing clock, require sw coordination */
cpumask_var_t cpus; /* Online CPUs only */
cpumask_var_t related_cpus; /* Online + Offline CPUs */
+ cpumask_var_t real_cpus; /* Related and present */
unsigned intshared_type; /* ACPI: ANY or ALL affected CPUs
should set cpufreq */
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -1002,7 +1002,7 @@ static int cpufreq_add_dev_symlink(struc
int ret = 0;
/* Some related CPUs might not be present (physically hotplugged) */
- for_each_cpu_and(j, policy->related_cpus, cpu_present_mask) {
+ for_each_cpu(j, policy->real_cpus) {
if (j == policy->kobj_cpu)
continue;
@@ -1019,7 +1019,7 @@ static void cpufreq_remove_dev_symlink(s
unsigned int j;
/* Some related CPUs might not be present (physically hotplugged) */
- for_each_cpu_and(j, policy->related_cpus, cpu_present_mask) {
+ for_each_cpu(j, policy->real_cpus) {
if (j == policy->kobj_cpu)
continue;
@@ -1157,11 +1157,14 @@ static struct cpufreq_policy *cpufreq_po
if (!zalloc_cpumask_var(>related_cpus, GFP_KERNEL))
goto err_free_cpumask;
+ if (!zalloc_cpumask_var(>real_cpus, GFP_KERNEL))
+ goto err_free_rcpumask;
+
ret = kobject_init_and_add(>kobj, _cpufreq, >kobj,
"cpufreq");
if (ret) {
pr_err("%s: failed to init policy->kobj: %d\n", __func__, ret);
- goto err_free_rcpumask;
+ goto err_free_real_cpus;
}
INIT_LIST_HEAD(>policy_list);
@@ -1178,6 +1181,8 @@ static struct cpufreq_policy *cpufreq_po
return policy;
+err_free_real_cpus:
+ free_cpumask_var(policy->real_cpus);
err_free_rcpumask:
free_cpumask_var(policy->related_cpus);
err_free_cpumask:
@@ -1228,6 +1233,7 @@ static void cpufreq_policy_free(struct c
write_unlock_irqrestore(_driver_lock, flags);
cpufreq_policy_put_kobj(policy, notify);
+ free_cpumask_var(policy->real_cpus);
free_cpumask_var(policy->related_cpus);
free_cpumask_var(policy->cpus);
kfree(policy);
@@ -1252,14 +1258,17 @@ static int cpufreq_add_dev(struct device
pr_debug("adding CPU %u\n", cpu);
- /*
-* Only possible if 'cpu' wasn't physically present earlier and we are
-* here from subsys_interface add callback. A hotplug notifier will
-*
Re: [PATCH V2 2/2 update] kexec: split kexec_load syscall from kexec core code
On 07/22/15 at 10:19am, Dave Young wrote: > --- > > Update per comments from Vivek: > - Moved below functions which are used by kexec_load only to kexec.c > copy_user_segment_list() and kimage_alloc_init() > - add slab.h to kexec.c because kimage_alloc_init will call kfree > - drop unused declaration of kimage_alloc_init in kexec.h > [snip] Andrew, I noticed you have taken the two patches in -mm, could you replace the 2/2 with this update, there's small cleanup per Vivek's comments, detail changes see above. BTW, sorry I forgot to remove the "Re: " before "[PATCH]" prefix. Thanks Dave thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the kvms390 tree with the s390 tree
Hi all,
Today's linux-next merge of the kvms390 tree got a conflict in:
arch/s390/kernel/entry.S
between commit:
2a1a14484b97 ("s390/kernel: lazy restore fpu registers")
3af40983a937 ("s390/kvm: fix interrupt race with HANDLE_SIE_INTERCEPT")
0be8cda612d8 ("s390/kvm: integrate HANDLE_SIE_INTERCEPT into
cleanup_critical")
from the s390 tree and commit:
e983d24d6117 ("KVM: s390: use pid of cpu thread for sampling tagging")
from the kvms390 tree.
I fixed it up (maybe? see below) and can carry the fix as necessary
(no action is required - unless this fix is just wrong).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/s390/kernel/entry.S
index bde6275dd813,0dfa5f4ce755..
--- a/arch/s390/kernel/entry.S
+++ b/arch/s390/kernel/entry.S
@@@ -169,70 -193,6 +169,70 @@@ ENTRY(__switch_to
br %r14
.L__critical_start:
+
+#if IS_ENABLED(CONFIG_KVM)
+/*
+ * sie64a calling convention:
+ * %r2 pointer to sie control block
+ * %r3 guest register save area
+ */
+ENTRY(sie64a)
+ stmg%r6,%r14,__SF_GPRS(%r15)# save kernel registers
+ stg %r2,__SF_EMPTY(%r15)# save control block pointer
+ stg %r3,__SF_EMPTY+8(%r15) # save guest register save area
+ xc __SF_EMPTY+16(16,%r15),__SF_EMPTY+16(%r15) # host id & reason
+ tm __LC_CPU_FLAGS+7,_CIF_FPU # load guest fp/vx registers ?
+ jno .Lsie_load_guest_gprs
+ lg %r12,__LC_THREAD_INFO # load fp/vx regs save area
+ brasl %r14,load_fpu_regs # load guest fp/vx regs
+.Lsie_load_guest_gprs:
+ lmg %r0,%r13,0(%r3) # load guest gprs 0-13
+ lg %r14,__LC_GMAP # get gmap pointer
+ ltgr%r14,%r14
+ jz .Lsie_gmap
+ lctlg %c1,%c1,__GMAP_ASCE(%r14) # load primary asce
+.Lsie_gmap:
+ lg %r14,__SF_EMPTY(%r15) # get control block pointer
+ oi __SIE_PROG0C+3(%r14),1 # we are going into SIE now
+ tm __SIE_PROG20+3(%r14),3 # last exit...
+ jnz .Lsie_skip
+ tm __LC_CPU_FLAGS+7,_CIF_FPU
+ jo .Lsie_skip # exit if fp/vx regs changed
+ tm __LC_MACHINE_FLAGS+6,0x20 # MACHINE_FLAG_LPP
+ jz .Lsie_enter
- .insn s,0xb280,__SF_EMPTY(%r15) # set guest id
++ .insn s,0xb280,__LC_CURRENT_PID # use cpu thread pid
+.Lsie_enter:
+ sie 0(%r14)
+ tm __LC_MACHINE_FLAGS+6,0x20 # MACHINE_FLAG_LPP
+ jz .Lsie_skip
+ .insn s,0xb280,__SF_EMPTY+16(%r15)# set host id
+.Lsie_skip:
+ ni __SIE_PROG0C+3(%r14),0xfe # no longer in SIE
+ lctlg %c1,%c1,__LC_USER_ASCE # load primary asce
+.Lsie_done:
+# some program checks are suppressing. C code (e.g. do_protection_exception)
+# will rewind the PSW by the ILC, which is 4 bytes in case of SIE. Other
+# instructions between sie64a and .Lsie_done should not cause program
+# interrupts. So lets use a nop (47 00 00 00) as a landing pad.
+# See also .Lcleanup_sie
+.Lrewind_pad:
+ nop 0
+ .globl sie_exit
+sie_exit:
+ lg %r14,__SF_EMPTY+8(%r15) # load guest register save area
+ stmg%r0,%r13,0(%r14)# save guest gprs 0-13
+ lmg %r6,%r14,__SF_GPRS(%r15)# restore kernel registers
+ lg %r2,__SF_EMPTY+24(%r15) # return exit reason code
+ br %r14
+.Lsie_fault:
+ lghi%r14,-EFAULT
+ stg %r14,__SF_EMPTY+24(%r15)# set exit reason code
+ j sie_exit
+
+ EX_TABLE(.Lrewind_pad,.Lsie_fault)
+ EX_TABLE(sie_exit,.Lsie_fault)
+#endif
+
/*
* SVC interrupt handler routine. System calls are synchronous events and
* are executed with interrupts enabled.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] regulator: rk808: make better use of the gpiod API
2015-07-21 23:46 GMT+09:00 Uwe Kleine-König : > From: Uwe Kleine-König > > The gpiod functions include variants for managed gpiod resources. Use it > to simplify the remove function. > > As the driver handles a device node without a specification of dvs gpios > just fine, additionally use the variant of gpiod_get exactly for this > use case. This makes error checking more strict. > > As a third benefit this patch makes the driver use the flags parameter > of gpiod_get* which will not be optional any more after 4.2 and so > prevents a build failure when the respective gpiod commit is merged. > > Signed-off-by: Uwe Kleine-König > --- > note the above mentioned gpiod change is already in next, so the driver > fails to build there. > > Changes since (implicit) v1, sent with > Message-Id: 1437461993-14860-1-git-send-email-u.kleine-koe...@pengutronix.de: > > - Assert that of_node_put is called in error path to not leak a reference >and drop now empty remove callback. >Thanks to Krzysztof Kozlowski for catching. > > > Best regards > Uwe > drivers/regulator/rk808-regulator.c | 32 > 1 file changed, 12 insertions(+), 20 deletions(-) Looks good now: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote:
> The cfs_rq's load_avg is composed of runnable_load_avg and blocked_load_avg.
> Before this series, sometimes the runnable_load_avg is used, and sometimes
> the load_avg is used. Completely replacing all uses of runnable_load_avg
> with load_avg may be too big a leap, i.e., the blocked_load_avg is concerned
> to result in overrated load. Therefore, we get runnable_load_avg back.
>
> The new cfs_rq's runnable_load_avg is improved to be updated with all of the
> runnable sched_eneities at the same time, so the one sched_entity updated and
> the others stale problem is solved.
>
> Signed-off-by: Yuyang Du
> ---
> +/* Remove the runnable load generated by se from cfs_rq's runnable load
> average */
> +static inline void
> +dequeue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> +{
> + update_load_avg(se, 1);
> +
I think we need an update_cfs_rq_load_avg() here? Because the
runnable_load_avg may not be up to date when dequeue_entity_load_avg()
is called, right?
> + cfs_rq->runnable_load_avg =
> + max_t(long, cfs_rq->runnable_load_avg - se->avg.load_avg, 0);
> + cfs_rq->runnable_load_sum =
> + max_t(s64, cfs_rq->runnable_load_sum - se->avg.load_sum, 0);
> +}
> +
> /*
> * Task first catches up with cfs_rq, and then subtract
> * itself from the cfs_rq (task must be off the queue now).
> @@ -2982,7 +3015,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, struct
> sched_entity *se, int flags)
>* Update run-time statistics of the 'current'.
>*/
> update_curr(cfs_rq);
> - update_load_avg(se, 1);
> + dequeue_entity_load_avg(cfs_rq, se);
>
> update_stats_dequeue(cfs_rq, se);
> if (flags & DEQUEUE_SLEEP) {
Thanks and Best Regards,
Boqun
signature.asc
Description: PGP signature
Re: [PATCH V2 2/2 update] kexec: split kexec_load syscall from kexec core code
Now there's two kexec load syscall, one is kexec_load another is kexec_file_load, kexec_file_load has been splited as kernel/kexec_file.c. In this patch I split kexec_load syscall code to kernel/kexec.c. And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and use kexec_file_load only, or vice verse. The original requirement is from Tedso, he want kexec kernel signature being checked with CONFIG_KEXEC_VERIFY_SIG enabled. But kexec-tools use kexec_load syscall can bypass the checking. Vivek Goyal proposed to create a common kconfig option so user can compile in only one syscall for loading kexec kernel. KEXEC/KEXEC_FILE selects KEXEC_CORE so that old config files still work. Because there's general code need CONFIG_KEXEC_CORE, so I updated all the architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects KEXEC_CORE in arch Kconfig. Also updated general kernel code with to kexec_load syscall. Signed-off-by: Dave Young --- Update per comments from Vivek: - Moved below functions which are used by kexec_load only to kexec.c copy_user_segment_list() and kimage_alloc_init() - add slab.h to kexec.c because kimage_alloc_init will call kfree - drop unused declaration of kimage_alloc_init in kexec.h arch/Kconfig |3 arch/arm/Kconfig |1 arch/ia64/Kconfig |1 arch/m68k/Kconfig |1 arch/mips/Kconfig |1 arch/powerpc/Kconfig |1 arch/s390/Kconfig |1 arch/sh/Kconfig |1 arch/tile/Kconfig |1 arch/x86/Kconfig |3 arch/x86/boot/header.S|2 arch/x86/include/asm/kdebug.h |2 arch/x86/kernel/Makefile |4 arch/x86/kernel/kvmclock.c|4 arch/x86/kernel/reboot.c |4 arch/x86/kernel/setup.c |2 arch/x86/kernel/vmlinux.lds.S |2 arch/x86/kvm/vmx.c|8 arch/x86/platform/efi/efi.c |4 arch/x86/platform/uv/uv_nmi.c |6 drivers/firmware/efi/Kconfig |2 drivers/pci/pci-driver.c |2 include/linux/kexec.h |6 init/initramfs.c |4 kernel/Makefile |1 kernel/events/core.c |2 kernel/kexec.c| 1496 - kernel/kexec_core.c | 1511 ++ kernel/ksysfs.c |6 kernel/printk/printk.c|2 kernel/reboot.c |2 kernel/sysctl.c |2 32 files changed, 1560 insertions(+), 1528 deletions(-) create mode 100644 kernel/kexec_core.c --- linux.orig/arch/Kconfig +++ linux/arch/Kconfig @@ -2,6 +2,9 @@ # General architecture dependent options # +config KEXEC_CORE + bool + config OPROFILE tristate "OProfile system profiling" depends on PROFILING --- linux.orig/arch/arm/Kconfig +++ linux/arch/arm/Kconfig @@ -2005,6 +2005,7 @@ config KEXEC bool "Kexec system call (EXPERIMENTAL)" depends on (!SMP || PM_SLEEP_SMP) depends on !CPU_V7M + select KEXEC_CORE help kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot --- linux.orig/arch/ia64/Kconfig +++ linux/arch/ia64/Kconfig @@ -518,6 +518,7 @@ source "drivers/sn/Kconfig" config KEXEC bool "kexec system call" depends on !IA64_HP_SIM && (!SMP || HOTPLUG_CPU) + select KEXEC_CORE help kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot --- linux.orig/arch/m68k/Kconfig +++ linux/arch/m68k/Kconfig @@ -95,6 +95,7 @@ config MMU_SUN3 config KEXEC bool "kexec system call" depends on M68KCLASSIC + select KEXEC_CORE help kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot --- linux.orig/arch/mips/Kconfig +++ linux/arch/mips/Kconfig @@ -2592,6 +2592,7 @@ source "kernel/Kconfig.preempt" config KEXEC bool "Kexec system call" + select KEXEC_CORE help kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot --- linux.orig/arch/powerpc/Kconfig +++ linux/arch/powerpc/Kconfig @@ -415,6 +415,7 @@ config PPC64_SUPPORTS_MEMORY_FAILURE config KEXEC bool "kexec system call" depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP)) + select KEXEC_CORE help kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot --- linux.orig/arch/s390/Kconfig +++ linux/arch/s390/Kconfig @@ -48,6 +48,7 @@ config ARCH_SUPPORTS_DEBUG_PAGEALLOC
Linux 3.18.19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm announcing the release of the 3.18.19 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 - Linux 3.18.19 - Bandan Das (1): KVM: nSVM: Check for NRIPS support before updating control field Borislav Petkov (1): x86/boot: Fix overflow warning with 32-bit binutils Chen Gang (1): netfilter: nfnetlink_cthelper: Remove 'const' and '&' to avoid warnings Cornelia Huck (1): KVM: s390: virtio-ccw: don't overwrite config space values David Vrabel (1): x86/xen: allow privcmd hypercalls to be preempted Eric W. Biederman (4): mnt: Refactor the logic for mounting sysfs and proc in a user namespace mnt: Modify fs_fully_visible to deal with locked ro nodev and atime vfs: Remove incorrect debugging WARN in prepend_path vfs: Ignore unlocked mounts in fs_fully_visible Eugene Shatokhin (1): kprobes/x86: Return correct length in __copy_instruction() Fabian Frederick (3): fs/ufs: revert "ufs: fix deadlocks introduced by sb mutex merge" fs/ufs: restore s_lock mutex fs/ufs: restore s_lock mutex_init() Filipe Manana (1): Btrfs: make xattr replace operations atomic Geoff Levand (1): arm64/kvm: Fix assembler compatibility of macros Ian Wilson (1): netfilter: Zero the tuple in nfnl_cthelper_parse_tuple() J. Bruce Fields (1): selinux: fix setting of security labels on NFS Jan Kara (3): fs: Fix S_NOSEC handling ufs: Fix warning from unlock_new_inode() ufs: Fix possible deadlock when looking up directories Jim Snow (1): sb_edac: Fix erroneous bytes->gigabytes conversion Joerg Roedel (1): iommu/amd: Handle large pages correctly in free_pagetable Konrad Rzeszutek Wilk (1): config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected Marc Zyngier (1): arm: KVM: force execution of HCPTR access on VM exit Nicolas Dichtel (1): rtnl: restore notifications for deleted interfaces Nicolas Ferre (1): tty/serial: at91: RS485 mode: 0 is valid for delay_rts_after_send Oleg Nesterov (1): perf: Fix ring_buffer_attach() RCU sync, again Oliver Hartkopp (1): can: fix loss of CAN frames in raw_rcv Pablo Neira Ayuso (2): netfilter: nft_compat: set IP6T_F_PROTO flag if protocol is set netfilter: nf_tables: allow to change chain policy without hook if it exists Palik, Imre (1): perf/x86: Honor the architectural performance monitoring version Peter Hutterer (1): Input: synaptics - add min/max quirk for Lenovo S540 Quentin Casasnovas (1): x86/microcode/intel: Guard against stack overflow in the loader Radim Krčmář (2): KVM: x86: make vapics_in_nmi_mode atomic KVM: x86: properly restore LVT0 Rui Miguel Silva (1): usb: gadget: f_fs: add extra check before unregister_gadget_item Sasha Levin (3): Revert "nfs: take extra reference to fl->fl_file when running a LOCKU operation" Revert "Input: synaptics - add min/max quirk for Lenovo S540" Linux 3.18.19 Sebastien Szymanski (1): ARM: clk-imx6q: refine sata's parent Steven Rostedt (1): tracing: Have filter check for balanced ops Makefile| 2 +- arch/arm/kvm/interrupts.S | 10 +- arch/arm/kvm/interrupts_head.S | 20 +++- arch/arm/mach-imx/clk-imx6q.c | 2 +- arch/arm64/include/asm/kvm_arm.h| 21 ++-- arch/x86/Kconfig| 2 +- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kernel/cpu/microcode/intel_early.c | 2 +- arch/x86/kernel/cpu/perf_event_intel.c | 12 +-- arch/x86/kernel/entry_32.S | 3 + arch/x86/kernel/entry_64.S | 3 + arch/x86/kernel/head_32.S | 13 ++- arch/x86/kernel/kprobes/core.c | 7 +- arch/x86/kvm/i8254.c| 2 +- arch/x86/kvm/lapic.c| 5 +- arch/x86/kvm/svm.c | 8 +- drivers/edac/sb_edac.c | 38 +++ drivers/input/mouse/synaptics.c | 1 + drivers/iommu/amd_iommu.c | 6 ++ drivers/net/can/dev.c | 5 + drivers/net/can/slcan.c | 1 + drivers/net/can/vcan.c | 3 + drivers/s390/kvm/virtio_ccw.c | 11 +- drivers/tty/serial/atmel_serial.c | 7 +- drivers/usb/gadget/function/f_fs.c | 10 +-
Re: [PATCH V2 2/2] kexec: split kexec_load syscall from kexec core code
On 07/21/15 at 09:03am, Vivek Goyal wrote: > On Mon, Jul 20, 2015 at 04:37:15PM +0800, dyo...@redhat.com wrote: > > Now there's two kexec load syscall, one is kexec_load another is > > kexec_file_load, kexec_file_load has been splited as kernel/kexec_file.c. > > In this patch I split kexec_load syscall code to kernel/kexec.c. > > Hi Dave, > > Nice work. Thanks for doing this. I have couple of minor comments. > > - We might have to audit kernel/kexec_core.c. I think there are some > functions in there which are used by only old syscall and not the new > one. All that code should be in kernel/kexec.c. Only the code which is > shared between two syscalls should be in kernel/kexec_core.c. > > For example, I think kimage_alloc_init() is used by old syscall only. > New syscall uses kimage_file_alloc_init(). You are right, actually two functions copy_user_segment_list and kimage_alloc_init are used by kexec.c only Will move them to kexec.c from kexec_core.c, it works well during my testing > > [..] > > --- linux.orig/include/linux/kexec.h > > +++ linux/include/linux/kexec.h > > @@ -16,7 +16,7 @@ > > > > #include > > > > -#ifdef CONFIG_KEXEC > > +#ifdef CONFIG_KEXEC_CORE > > #include > > #include > > #include > > @@ -318,12 +318,18 @@ int crash_shrink_memory(unsigned long ne > > size_t crash_get_memory_size(void); > > void crash_free_reserved_phys_range(unsigned long begin, unsigned long > > end); > > > > -#else /* !CONFIG_KEXEC */ > > +#ifdef CONFIG_KEXEC > > +int kimage_alloc_init(struct kimage **rimage, unsigned long entry, > > +unsigned long nr_segments, > > +struct kexec_segment __user *segments, > > +unsigned long flags); > > +#endif > > I am wondering why this needs to be in kexec.h. Who needs this? Even if > somebody needs this, this should probably be outside of KEXEC_CORE. It was added here in 1st version before adding kexec_internal.h, later I moved most of them to kexec_internal.h, but yes it is not used by any file other than kexec.c, will drop this chunk. Thanks a lot Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous
On Tue, Jul 21, 2015 at 7:04 PM, Boris Ostrovsky
wrote:
>
>
> On 07/21/2015 08:49 PM, Andrew Cooper wrote:
>>
>> On 22/07/2015 01:28, Andy Lutomirski wrote:
>>>
>>> On Tue, Jul 21, 2015 at 5:21 PM, Andrew Cooper
>>> wrote:
On 22/07/2015 01:07, Andy Lutomirski wrote:
>
> On Tue, Jul 21, 2015 at 4:38 PM, Andrew Cooper
> wrote:
>>
>> On 21/07/2015 22:53, Boris Ostrovsky wrote:
>>>
>>> On 07/21/2015 03:59 PM, Andy Lutomirski wrote:
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,44 @@ static inline void load_mm_cr4(struct mm_struct
*mm) {}
#endif
/*
+ * ldt_structs can be allocated, used, and freed, but they are
never
+ * modified while live.
+ */
+struct ldt_struct {
+int size;
+int __pad;/* keep the descriptors naturally aligned. */
+struct desc_struct entries[];
+};
>>>
>>> This breaks Xen which expects LDT to be page-aligned. Not sure why.
>>>
>>> Jan, Andrew?
>>
>> PV guests are not permitted to have writeable mappings to the frames
>> making up the GDT and LDT, so it cannot make unaudited changes to
>> loadable descriptors. In particular, for a 32bit PV guest, it is only
>> the segment limit which protects Xen from the ring1 guest kernel.
>>
>> A lot of this code hasn't been touched in years, and it certainly
>> predates me. The alignment requirement appears to come from the
>> virtual
>> region Xen uses to map the guests GDT and LDT. Strict alignment is
>> required for the GDT so Xen's descriptors starting at 0xe0xx are
>> correct, but the LDT alignment seems to be a side effect of similar
>> codepaths.
>>
>> For an LDT smaller than 8192 entries, I can't see any specific reason
>> for enforcing alignment, other than "that's the way it has always
>> been".
>>
>> However, the guest would still have to relinquish write access to all
>> frames which make up the LDT, which looks to be a bit of an issue
>> given
>> the snippet above.
>
> Does the LDT itself need to be aligned or just the address passed to
> paravirt_alloc_ldt?
The address which Xen receives needs to be aligned.
It looks like xen_alloc_ldt() blindly assumes that the desc_struct *ldt
it is passed is page aligned, and passes it straight through.
>>>
>>> xen_alloc_ldt is just fiddling with protection though, I think. Isn't
>>> it xen_set_ldt that's the meat? We could easily pass xen_alloc_ldt a
>>> pointer to the ldt_struct.
>>
>> So it is. It is the linear_addr in xen_set_ldt() which Xen currently
>> audits to be page aligned.
>>
>> This will allow ldt_struct itself to be page aligned, and for the size
>> field to sit across the base/limit field of what would logically be
>> selector 0x0008 There would be some issues accessing size. To load
>> frames as an LDT, a guest must drop all refs to the page so that its
>> type may be changed from writeable to segdesc. After that, an
>> update_descriptor hypercall can be used to change size, and I believe
>> the guest may subsequently recreate read-only mappings to the frames
>> in
>> question (although frankly it is getting late so you will want to
>> double
>> check all of this).
>>
>> Anyhow, this looks like an issue which should be fixed up with
>> slightly
>> more PVOps, rather than enforcing a Xen view of the world on native
>> Linux.
>>
> I could presumably make the allocation the other way around so the
> size is at the end. I could even use two separate allocations if
> needed.
>
>
> Why not wrap mm_context_t's ldt and size into a struct (just like ldt_struct
> but without __pad) and have a single allocation of ldt?
>
> I.e.
>
> struct ldt_struct {
> int size;
> struct desc_struct *entries;
> }
>
> --- a/arch/x86/include/asm/mmu.h
> +++ b/arch/x86/include/asm/mmu.h
> @@ -9,8 +9,7 @@
>* we put the segment information here.
>*/
> typedef struct {
> -void *ldt;
> -int size;
> +struct ldt_struct ldt;
> #ifdef CONFIG_X86_64
> /* True if mm supports a task running in 32 bit compatibility mode. */
I want the atomic read of both of them. The current code make
interesting assumptions about ordering that may or may not be correct
but are certainly not obviously correct.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous
On Tue, Jul 21, 2015 at 7:01 PM, Brian Gerst wrote: > On Tue, Jul 21, 2015 at 3:59 PM, Andy Lutomirski wrote: >> modify_ldt has questionable locking and does not synchronize >> threads. Improve it: redesign the locking and synchronize all >> threads' LDTs using an IPI on all modifications. > > What does this fix? I can see sending an IPI if the LDT is > reallocated, but on every update seems unnecessary. > It prevents nastiness in which you're in user mode with an impossible CS or SS, resulting in potentially interesting artifacts in interrupts, NMIs, etc. > -- > Brian Gerst -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2.
On 07/13/2015 07:35 PM, Eric Anholt wrote:
> This interrupt controller is the new root interrupt controller with
> the timer, PMU events, and IPIs, and the bcm2835's interrupt
> controller is chained off of it to handle the peripherals.
> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
> +static void bcm2836_arm_irqchip_mask_pmu_irq(struct irq_data *d)
> +{
> + pr_err("%d: mask PMU\n", smp_processor_id());
> + writel(1 << smp_processor_id(), intc.base + LOCAL_PM_ROUTING_CLR);
> +}
> +
> +static void bcm2836_arm_irqchip_unmask_pmu_irq(struct irq_data *d)
> +{
> + pr_err("%d: unmask PMU\n", smp_processor_id());
> + writel(1 << smp_processor_id(), intc.base + LOCAL_PM_ROUTING_SET);
> +}
Are those pr_err() calls left-over debug, or is there some reason it's
an error to call those functions?
Aside from this and the other minor comment, the series,
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] irqchip: bcm2835: If a parent interrupt is registered, chain from it.
On 07/13/2015 07:35 PM, Eric Anholt wrote: > The BCM2836 (Raspberry Pi 2) uses two levels of interrupt handling > with the CPU-local interrupts being the root, so we need to register > ours as chained off of the CPU's local interrupt. Sorry for the slow review; laziness after vacation! > diff --git > a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt > > b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt > +The BCM2836 contains the same interrupt controller with the same > +interrupts, but the per-CPU interrupt controller is the root, and an > +interrupt there indicates that the ARMCTRL has an interrupt to handle. > + > Required properties: > > - compatible : should be "brcm,bcm2835-armctrl-ic" Since there are some differences between the bcm2835 and bcm2836 HW blocks, I'd expect the compatible value to be different for each. In particular... > +Optional properties: > +- interrupt-parent : Specifies the parent interrupt controller when this > + controller is the second level. > +- interrupts : Specifies the interrupt on the parent for this interrupt > + controller to handle. I'd classify that as "additional required properties for brcm,bcm2836-armctrl-ic" ... and with different compatible values for the two chips, you would know when probe() should require vs. reject the property. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous
On 07/21/2015 08:49 PM, Andrew Cooper wrote:
On 22/07/2015 01:28, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 5:21 PM, Andrew Cooper
wrote:
On 22/07/2015 01:07, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 4:38 PM, Andrew Cooper
wrote:
On 21/07/2015 22:53, Boris Ostrovsky wrote:
On 07/21/2015 03:59 PM, Andy Lutomirski wrote:
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,44 @@ static inline void load_mm_cr4(struct mm_struct
*mm) {}
#endif
/*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+int size;
+int __pad;/* keep the descriptors naturally aligned. */
+struct desc_struct entries[];
+};
This breaks Xen which expects LDT to be page-aligned. Not sure why.
Jan, Andrew?
PV guests are not permitted to have writeable mappings to the frames
making up the GDT and LDT, so it cannot make unaudited changes to
loadable descriptors. In particular, for a 32bit PV guest, it is only
the segment limit which protects Xen from the ring1 guest kernel.
A lot of this code hasn't been touched in years, and it certainly
predates me. The alignment requirement appears to come from the virtual
region Xen uses to map the guests GDT and LDT. Strict alignment is
required for the GDT so Xen's descriptors starting at 0xe0xx are
correct, but the LDT alignment seems to be a side effect of similar
codepaths.
For an LDT smaller than 8192 entries, I can't see any specific reason
for enforcing alignment, other than "that's the way it has always been".
However, the guest would still have to relinquish write access to all
frames which make up the LDT, which looks to be a bit of an issue given
the snippet above.
Does the LDT itself need to be aligned or just the address passed to
paravirt_alloc_ldt?
The address which Xen receives needs to be aligned.
It looks like xen_alloc_ldt() blindly assumes that the desc_struct *ldt
it is passed is page aligned, and passes it straight through.
xen_alloc_ldt is just fiddling with protection though, I think. Isn't
it xen_set_ldt that's the meat? We could easily pass xen_alloc_ldt a
pointer to the ldt_struct.
So it is. It is the linear_addr in xen_set_ldt() which Xen currently
audits to be page aligned.
This will allow ldt_struct itself to be page aligned, and for the size
field to sit across the base/limit field of what would logically be
selector 0x0008 There would be some issues accessing size. To load
frames as an LDT, a guest must drop all refs to the page so that its
type may be changed from writeable to segdesc. After that, an
update_descriptor hypercall can be used to change size, and I believe
the guest may subsequently recreate read-only mappings to the frames in
question (although frankly it is getting late so you will want to double
check all of this).
Anyhow, this looks like an issue which should be fixed up with slightly
more PVOps, rather than enforcing a Xen view of the world on native Linux.
I could presumably make the allocation the other way around so the
size is at the end. I could even use two separate allocations if
needed.
Why not wrap mm_context_t's ldt and size into a struct (just like
ldt_struct but without __pad) and have a single allocation of ldt?
I.e.
struct ldt_struct {
int size;
struct desc_struct *entries;
}
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
* we put the segment information here.
*/
typedef struct {
-void *ldt;
-int size;
+struct ldt_struct ldt;
#ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility
mode. */
-boris
I suspect two separate allocations would be the better solution, as it
means that the size field doesn't need to be subject to funny page
permissions.
True. OTOH we never write to the size field after allocating the thing.
Right, but even reading it is going to cause problems if one of the
paravirt ops can't re-establish ro mappings.
~Andrew
___
Xen-devel mailing list
xen-de...@lists.xen.org
http://lists.xen.org/xen-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] drivers/tty: make serial/sn_console.c driver explicitly non-modular
The Kconfig for this option is currently:
config SERIAL_SGI_L1_CONSOLE
bool "SGI Altix L1 serial console support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the orphaned module code, so that when reading the
driver there is no doubt it is builtin-only. We could consider
making it tristate, but the above bool has been there since before
the start of git history, which isn't all that surprising, since
consoles are typically critical to have at early boot. So adding
tristate is really of no value here.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ser...@vger.kernel.org
Signed-off-by: Paul Gortmaker
---
drivers/tty/serial/sn_console.c | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/drivers/tty/serial/sn_console.c b/drivers/tty/serial/sn_console.c
index 33e94e56dcdb..d4692d888e9d 100644
--- a/drivers/tty/serial/sn_console.c
+++ b/drivers/tty/serial/sn_console.c
@@ -42,7 +42,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -659,7 +659,7 @@ static void sn_sal_timer_poll(unsigned long data)
* @port: Our sn_cons_port (which contains the uart port)
*
* So this is used by sn_sal_serial_console_init (early on, before we're
- * registered with serial core). It's also used by sn_sal_module_init
+ * registered with serial core). It's also used by sn_sal_init
* right after we've registered with serial core. The later only happens
* if we didn't already come through here via sn_sal_serial_console_init.
*
@@ -709,7 +709,7 @@ static void __init sn_sal_switch_to_asynch(struct
sn_cons_port *port)
* sn_sal_switch_to_interrupts - Switch to interrupt driven mode
* @port: Our sn_cons_port (which contains the uart port)
*
- * In sn_sal_module_init, after we're registered with serial core and
+ * In sn_sal_init, after we're registered with serial core and
* the port is added, this function is called to switch us to interrupt
* mode. We were previously in asynch/polling mode (using init_timer).
*
@@ -773,7 +773,7 @@ static struct uart_driver sal_console_uart = {
};
/**
- * sn_sal_module_init - When the kernel loads us, get us rolling w/ serial core
+ * sn_sal_init - When the kernel loads us, get us rolling w/ serial core
*
* Before this is called, we've been printing kernel messages in a special
* early mode not making use of the serial core infrastructure. When our
@@ -781,7 +781,7 @@ static struct uart_driver sal_console_uart = {
* core and try to enable interrupt driven mode.
*
*/
-static int __init sn_sal_module_init(void)
+static int __init sn_sal_init(void)
{
int retval;
@@ -811,7 +811,7 @@ static int __init sn_sal_module_init(void)
if (uart_register_driver(_console_uart) < 0) {
printk
- ("ERROR sn_sal_module_init failed uart_register_driver,
line %d\n",
+ ("ERROR sn_sal_init failed uart_register_driver, line %d\n",
__LINE__);
return -ENODEV;
}
@@ -832,33 +832,19 @@ static int __init sn_sal_module_init(void)
/* when this driver is compiled in, the console initialization
* will have already switched us into asynchronous operation
-* before we get here through the module initcalls */
+* before we get here through the initcalls */
if (!sal_console_port.sc_is_asynch) {
sn_sal_switch_to_asynch(_console_port);
}
- /* at this point (module_init) we can try to turn on interrupts */
+ /* at this point (device_init) we can try to turn on interrupts */
if (!IS_RUNNING_ON_SIMULATOR()) {
sn_sal_switch_to_interrupts(_console_port);
}
sn_process_input = 1;
return 0;
}
-
-/**
- * sn_sal_module_exit - When we're unloaded, remove the driver/port
- *
- */
-static void __exit sn_sal_module_exit(void)
-{
- del_timer_sync(_console_port.sc_timer);
- uart_remove_one_port(_console_uart, _console_port.sc_port);
- uart_unregister_driver(_console_uart);
- misc_deregister();
-}
-
-module_init(sn_sal_module_init);
-module_exit(sn_sal_module_exit);
+device_initcall(sn_sal_init);
/**
* puts_raw_fixed - sn_sal_console_write helper for adding \r's as required
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] drivers/tty: make serial/sunhv.c driver explicitly non-modular
The Kconfig for this driver is currently:
config SERIAL_SUNHV
bool "Sun4v Hypervisor Console support"
...meaning that it currently is not being built as a module by
anyone. Lets remove the modular and unused code here, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We don't swap module.h for init.h since this file has init.h already.
We leave some tags like MODULE_LICENSE for documentation purposes, and
for the "git blame" value. Also note that MODULE_DEVICE_TABLE is a
no-op for non-modular code, so we remove that too.
Cc: "David S. Miller"
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: sparcli...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Signed-off-by: Paul Gortmaker
---
drivers/tty/serial/sunhv.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/sunhv.c b/drivers/tty/serial/sunhv.c
index 534754440fa8..064031870ba0 100644
--- a/drivers/tty/serial/sunhv.c
+++ b/drivers/tty/serial/sunhv.c
@@ -3,7 +3,6 @@
* Copyright (C) 2006, 2007 David S. Miller (da...@davemloft.net)
*/
-#include
#include
#include
#include
@@ -621,7 +620,6 @@ static const struct of_device_id hv_match[] = {
},
{},
};
-MODULE_DEVICE_TABLE(of, hv_match);
static struct platform_driver hv_driver = {
.driver = {
@@ -639,16 +637,11 @@ static int __init sunhv_init(void)
return platform_driver_register(_driver);
}
+device_initcall(sunhv_init);
-static void __exit sunhv_exit(void)
-{
- platform_driver_unregister(_driver);
-}
-
-module_init(sunhv_init);
-module_exit(sunhv_exit);
-
+#if 0 /* ...def MODULE ; never supported as such */
MODULE_AUTHOR("David S. Miller");
MODULE_DESCRIPTION("SUN4V Hypervisor console driver");
MODULE_VERSION("2.0");
MODULE_LICENSE("GPL");
+#endif
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux 4.2-rc1 broken Nokia N900
Hi,
On Tue, Jul 21, 2015 at 07:17:41PM -0500, Michael Welling wrote:
> On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
>
> This code has my head spinning.
>
> I found that the errors do not occur when the driver is built into the kernel.
>
> I also found that with the patch below the errors go away.
>
> Not sure if it is acceptible but see if it fixes things on your side.
>
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index cf8b91b..3164d13 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
> if (!spi->max_speed_hz)
> spi->max_speed_hz = spi->master->max_speed_hz;
>
> - spi_set_cs(spi, false);
> -
> if (spi->master->setup)
> status = spi->master->setup(spi);
>
> + spi_set_cs(spi, false);
> +
> dev_dbg(>dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max -->
> %d\n",
> (int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
> (spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
mh. maybe a runtime PM issue?
* external abort on non-linefetch: address cannot be accessed,
since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit
faster (module must not be loaded from filesystem), so that
the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup
routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a
prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to
suspend after the runtime PM acquisition in setup()
So I suggest trying the following (compile tested only) patch:
-- Sebastian
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5867384..f7d9ffd 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct spi_device
*spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
u32 l;
/* The controller handles the inverted chip selects
@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool
enable)
enable = !enable;
if (spi->controller_state) {
+ pm_runtime_get_sync(mcspi->dev);
+
l = mcspi_cached_chconf0(spi);
if (enable)
@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool
enable)
l |= OMAP2_MCSPI_CHCONF_FORCE;
mcspi_write_chconf0(spi, l);
+
+ pm_runtime_mark_last_busy(mcspi->dev);
+ pm_runtime_put_autosuspend(mcspi->dev);
}
}
signature.asc
Description: Digital signature
[PATCH 2/4] drivers/tty: make serial/lantic.c driver explicitly non-modular
The Kconfig for this option is currently:
config SERIAL_LANTIQ
bool "Lantiq serial driver"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity, so that when reading the
driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We delete the MODULE_DESCRIPTION and LICENSE tags since they are
not adding any new information above and beyond what is at the top
of the file. Also note that MODULE_DEVICE_TABLE is a no-op for
non-modular code, so we remove that as well.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ser...@vger.kernel.org
Signed-off-by: Paul Gortmaker
---
drivers/tty/serial/lantiq.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 4ccc0397664c..b88832e8ee82 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -21,7 +21,6 @@
*/
#include
-#include
#include
#include
#include
@@ -740,7 +739,6 @@ static const struct of_device_id ltq_asc_match[] = {
{ .compatible = DRVNAME },
{},
};
-MODULE_DEVICE_TABLE(of, ltq_asc_match);
static struct platform_driver lqasc_driver = {
.driver = {
@@ -764,8 +762,4 @@ init_lqasc(void)
return ret;
}
-
-module_init(init_lqasc);
-
-MODULE_DESCRIPTION("Lantiq serial port driver");
-MODULE_LICENSE("GPL");
+device_initcall(init_lqasc);
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] drivers/tty: make serial/suncore.c driver explicitly non-modular
The Kconfig for this driver is currently:
config SERIAL_SUNCORE
bool
...meaning that it currently is not being built as a module by
anyone. Lets remove the modular and unused code here, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We don't swap module.h for init.h since this file has init.h already.
We leave some tags like MODULE_LICENSE for documentation purposes, and
for the "git blame" value.
Cc: "David S. Miller"
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: sparcli...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Signed-off-by: Paul Gortmaker
---
drivers/tty/serial/suncore.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/suncore.c b/drivers/tty/serial/suncore.c
index 6e4ac8db2d79..127472bd6a7c 100644
--- a/drivers/tty/serial/suncore.c
+++ b/drivers/tty/serial/suncore.c
@@ -10,7 +10,6 @@
* Copyright (C) 2002 David S. Miller (da...@redhat.com)
*/
-#include
#include
#include
#include
@@ -234,14 +233,10 @@ static int __init suncore_init(void)
{
return 0;
}
+device_initcall(suncore_init);
-static void __exit suncore_exit(void)
-{
-}
-
-module_init(suncore_init);
-module_exit(suncore_exit);
-
+#if 0 /* ..def MODULE ; never supported as such */
MODULE_AUTHOR("Eddie C. Dost, David S. Miller");
MODULE_DESCRIPTION("Sun serial common layer");
MODULE_LICENSE("GPL");
+#endif
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] tty/serial: delete orphaned code in non-modules
In the previous merge window, we made changes to allow better
delineation between modular and non-modular code in commit
0fd972a7d91d6e15393c449492a04d94c0b89351 ("module: relocate module_init
from init.h to module.h"). This allows us to now ensure module code
looks modular and non-modular code does not accidentally look modular
without suffering build breakage.
Here we target code that is, by nature of their Kconfig settings, only
available to be built-in, but implicitly presenting itself as being
possibly modular by way of using modular headers, macros, and functions.
The goal here is to remove that illusion of modularity from these
drivers, but in a way that leaves the actual runtime unchanged.
In doing so, we remove code that has never been tested and adds
no value to the tree. And we begin the process of expecting a
level of consistency between the Kconfig of a driver and the code
that the driver uses.
Even though some of these drivers have their origin predating git
history, we change them as well; since the reality is that most linux
drivers are created by copying existing drivers. Given that, our
new code will only be as good as the examples we have in tree.
Build tested for allyesconfig on sparc32, sparc64 and x86-64, on
tty/tty-next (currently v4.2-rc3).
Paul.
---
Cc: "David S. Miller"
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ser...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Paul Gortmaker (4):
drivers/tty: make serial/sn_console.c driver explicitly non-modular
drivers/tty: make serial/lantic.c driver explicitly non-modular
drivers/tty: make serial/suncore.c driver explicitly non-modular
drivers/tty: make serial/sunhv.c driver explicitly non-modular
drivers/tty/serial/lantiq.c | 8 +---
drivers/tty/serial/sn_console.c | 32 +---
drivers/tty/serial/suncore.c| 11 +++
drivers/tty/serial/sunhv.c | 13 +++--
4 files changed, 16 insertions(+), 48 deletions(-)
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote: > Hi, > > Today's linux-next (next-20150721) encounters boot failures on Exynos > Octa (Exynos5422) based boards. The boards hangs. I bisected it to: > > d80167b85024982c5f18d0481a5c248100360118 is the first bad commit > commit d80167b85024982c5f18d0481a5c248100360118 > Author: Joonyoung Shim > Date: Thu Jul 2 21:49:39 2015 +0900 > > drm/exynos: remove drm_iommu_attach_device_if_possible > > Already drm_iommu_attach_device checks whether support iommu internally. > It should clear channels always regardless iommu support. We didn't know > because we can detect the problem when iommu is enabled, so we don't > have to use drm_iommu_attach_device_if_possible and then we can remove > drm_iommu_attach_device_if_possible and clear_channels function pointer. > > Signed-off-by: Joonyoung Shim > Tested-by: Marek Szyprowski > Signed-off-by: Inki Dae > > :04 04 83379efbf4960f58d680371628ec04387935bd53 > da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers > > > Config: exynos > Boot log from Odroid XU3-Lite attached. > > Any hints or ideas? The point that hangs is when accesses fimd register in fimd_clear_channels function, so i doubt clock setting for fimd. It's gone something that hangs after i enable gating for ACLK_200_DISP1 clock. If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it support. Any ideas? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous
On Tue, Jul 21, 2015 at 3:59 PM, Andy Lutomirski wrote: > modify_ldt has questionable locking and does not synchronize > threads. Improve it: redesign the locking and synchronize all > threads' LDTs using an IPI on all modifications. What does this fix? I can see sending an IPI if the LDT is reallocated, but on every update seems unnecessary. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Yama: remove needless CONFIG_SECURITY_YAMA_STACKED
On 7/21/2015 5:06 PM, Kees Cook wrote: > On Tue, Jul 21, 2015 at 5:03 PM, Casey Schaufler > wrote: >> On 7/21/2015 3:41 PM, Kees Cook wrote: >>> On Tue, Jul 21, 2015 at 1:56 PM, Casey Schaufler >>> wrote: On 7/21/2015 1:09 PM, Josh Boyer wrote: > On Tue, Jul 21, 2015 at 3:48 PM, Casey Schaufler > wrote: >> On 7/21/2015 12:09 PM, Kees Cook wrote: >>> Now that minor LSMs can cleanly stack with major LSMs, remove the >>> unneeded >>> config for Yama to be made to explicitly stack. Just selecting the main >>> Yama CONFIG will allow it to work, regardless of the major LSM. Since >>> distros using Yama are already forcing it to stack, this is effectively >>> a no-op change. >> Today I can compile in all LSMs including Yama and pick the one I want. >> If we made your change it would be impossible to build in Yama and not >> use it. I suggest we hold off until after the security summit discussion > This is true, but it's also true regardless of stacking. If Yama had > a CONFIG_SECURITY_YAMA_ENABLED (or whatever bikeshed color), then you > could enable Yama and not use it, yes? It would also allow people to > default it as disabled, but then enable it at runtime via the > ptrace_scope sysctl. The way Kees proposed it you would *always* get Yama stacked with your other module if you compile Yama in. Thus, If I compile in SELinux and Yama I cannot run SELinux without Yama. Today, I can >>> Yama is entirely controllable from sysctl, so you could build it in >>> and set the ptrace_scope setting to 0 at boot. It's already being >>> built into distro kernels this way (via the STACKING config), so this >>> change is effectively no different. >>> compile SELinux and Yama in but run only SELinux. My suggestion is to wait until we can specify the modules to use before we remove the kconfig option that provides that facility today. >>> I'm happy to wait, but I'm still going to send my other 2 "minor" LSMs >>> before LSS. :) Neither of them would be built into a kernel without >>> wanting their functionality, so they'll have the stack "always on" >>> semantics if their CONFIG is selected. >> Fair enough then. I'll withdraw my objection. One question comes >> to mind, and that is how are you planning to order them? I put >> Yama ahead of the "major" modules because that was how it had been >> stacked previously. Let's assume that the capability module stays >> in the first position. Are you planning to put your new modules >> before Yama, before the "major" module(s) or at the end? > It shouldn't matter, IMO. Though perhaps that's a mistake, and we > should make sure all "minor" LSMs go first? As I have it, it'd be in > link order, which is likely not "stable", so perhaps I've just talked > myself out of "it shouldn't matter". I propose that Capabilities go first, Yama 2nd, your new "minor" modules in the order accepted upstream, then the "major" module. It will be set in stone until the ordering options for security= and kconfig are implemented. At that time you'll be able to set 'em up in any order you like. > > -Kees > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] scripts/gdb: add data window feature
2015-07-22 5:04 GMT+08:00 Jan Kiszka : > On 2015-07-16 17:58, Houcheng Lin wrote: >> Add data window feature to show current kernel status >> on separate consoles, including: 1) registers, 2) back >> trace and 3) watch data windows. >> >> The data window would help kernel developer to understand >> current hardware/ kernel status, and on single-stepping, the >> modified fields in the data window would be highlighted. > > I was trying to get an overview of this feature. Unfortunately, it does > not work for me. I type in the commands you describe in the > documentation, but nothing shows up. I suspect there are some hard-coded > assumption about directory layouts etc. that aren't fulfilled here > (out-of-tree build). Sorry for not working. The steps might be run the "lx-dw" command first, then step the kernel in gdb; the kernel status would be dump to files in /tmp. Then you can run lx-dw.sh that creates 3 xterm window to display registers, back trace and watch variables. > > Anyway, let's try to understand what you would like to achieve. This > seems to be some add-on tool for gdb debugging sessions to display > target states continuously in separate terminals. Right? Is this > comparable to gdb's tui mode? > Yes, it is similar feature; dumps the content of register and kernel status into a separate window continuously and highlight the difference. It's snapshot is here: https://www.dropbox.com/s/tl67sxm6474jd8i/dw-screenshot.png?dl=0 > More important, is this specific to the debugging infrastructure we have > in scripts/gdb? Or could I install it (after some modifications, I > guess) in my home directory and use it for any gdb session, not just > with Linux kernels? Is there anything in it that particularly refers to > Linux structures? In that case I would suggest to make it stand-alone > first so that one could easily include it whenever needed, either > explicitly or via ~/.gitinit. This is not under the infrastructure of kernel gdb, however, this feature is needed and specific for kernel debugging. When trace an optimized kernel source, we usually need to trace it in assembly and throught the data window to update the current kernel status. It can be standalone, but I think it may helps a lot when developing kernel and good to be part of kernel gdb scripts. best regards, Houcheng Lin > > Thanks for sharing in any case! > > Jan > -- Best regards, Houcheng Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] Initial support for user namespace owned mounts
On 7/21/2015 1:35 PM, Seth Forshee wrote:
> On Thu, Jul 16, 2015 at 05:59:22PM -0700, Andy Lutomirski wrote:
>> On Thu, Jul 16, 2015 at 5:45 PM, Casey Schaufler
>> wrote:
>>> On 7/16/2015 4:29 PM, Andy Lutomirski wrote:
I really don't see the benefit of making up extra rules that apply to
users outside a userns who try to access specifically a filesystem
with backing store. They wouldn't make sense for filesystems without
backing store.
>>> Sure it would. For Smack, it would be the label a file would be
>>> created with, which would be the label of the process creating
>>> the memory based filesystem. For SELinux the rules are more a
>>> touch more sophisticated, but I'm sure that Paul or Stephen could
>>> come up with how to determine it.
>>>
>>> The point, looping all the way back to the beginning, where we
>>> were talking about just ignoring the labels on the filesystem,
>>> is that if you use the same Smack label on the files in the
>>> filesystem as the backing store file has, we'll all be happy.
>>> If that label isn't something user can write to, he won't be
>>> able to write to the mounted objects, either. If there is no
>>> backing store then use the label of the process creating the
>>> filesystem, which will be the user, which will mean everything
>>> will work hunky dory.
>>>
>>> Yes, there's work involved, but I doubt there's a lot. Getting
>>> the label from the backing store or the creating process is
>>> simple enough.
>>>
> So something like the diff below (untested)?
I think that this is close, and quite good for someone
who isn't very familiar with Smack. It's definitely headed
in the right direction.
> All I'm really doing is setting smk_default as you describe above and
> then using it instead of smk_of_current() in
> smack_inode_alloc_security() and instead of the label from the disk in
> smack_d_instantiate().
Let's say your backing store is a file labeled Rubble.
mount -o smackfsroot=Rubble,smackfsdef=Rubble ...
It is completely reasonable for a process labeled Flintstone to
have rwxa access to a file labeled Rubble.
Smack rule: Flintstone Rubble rwxa
In the case of writing to an existing Rubble file, what you
have looks fine. What's not so great is that if the Flintstone
process creates a file, it should be labeled Flintstone. Your
use of the smk_default, which is going to violate the principle
of least astonishment, and break the Smack policy as well.
Let's make a minor change. Instead of using smackfsroot let's
use smackfstransmute and a slightly different access rule:
mount -o smackfstransmute=Rubble,smackfsdef=Rubble ...
Smack rule: Flintstone Rubble rwxat
Now the only change we have to make to the Smack code is
that we don't want to create any files unless either the
process is labeled Rubble or the rule allowing the creation
has the "t" for transmute access. That should ensure that
everything is labeled Rubble. If it isn't, someone has mucked
with the metadata in a detectable way.
> Since a user currently needs CAP_MAC_ADMIN in
> init_user_ns to store security labels it looks like this should be
> sufficient. I'm not even sure that the inode_alloc_security hook changes
> are needed.
>
> We could allow privileged users in s_user_ns to write security labels to
> disk since they already control the backing store, as long as Smack
> didn't subsequently import them. I didn't do that here.
>
>> So what if Smack used the label of the user creating the filesystem
>> even for filesystems with backing store? IMO this ought to be doable
>> with the LSM hooks -- it certainly seems reasonable for the LSM to be
>> aware of who created a filesystem. In fact, I'd argue that if Smack
>> can't do this with the proposed LSM hooks, then the hooks are
>> insufficient.
> It would be very simple to use the label of the task instead.
>
> Seth
>
> ---
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 32f598db0b0d..4597420ab933 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1486,6 +1486,10 @@ static inline void sb_start_intwrite(struct
> super_block *sb)
> __sb_start_write(sb, SB_FREEZE_FS, true);
> }
>
> +static inline bool sb_in_userns(struct super_block *sb)
> +{
> + return sb->s_user_ns != _user_ns;
> +}
>
> extern bool inode_owner_or_capable(const struct inode *inode);
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index a143328f75eb..591fd19294e7 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -255,6 +255,10 @@ static struct smack_known *smk_fetch(const char *name,
> struct inode *ip,
> char *buffer;
> struct smack_known *skp = NULL;
>
> + /* Should never fetch xattrs from untrusted mounts */
> + if (WARN_ON(sb_in_userns(ip->i_sb)))
> + return ERR_PTR(-EPERM);
> +
Go ahead and fetch it, we'll check to make sure it's viable later.
> if (ip->i_op->getxattr == NULL)
> return
Re: [PATCH v3 7/8] perf: Define PMU_TXN_READ interface
Peter Zijlstra [pet...@infradead.org] wrote:
| On Tue, Jul 14, 2015 at 08:01:54PM -0700, Sukadev Bhattiprolu wrote:
| > +/*
| > + * Use the transaction interface to read the group of events in @leader.
| > + * PMUs like the 24x7 counters in Power, can use this to queue the events
| > + * in the ->read() operation and perform the actual read in ->commit_txn.
| > + *
| > + * Other PMUs can ignore the ->start_txn and ->commit_txn and read each
| > + * PMU directly in the ->read() operation.
| > + */
| > +static int perf_event_read_group(struct perf_event *leader)
| > +{
| > + int ret;
| > + struct perf_event *sub;
| > + struct pmu *pmu;
| > +
| > + pmu = leader->pmu;
| > +
| > + pmu->start_txn(pmu, PERF_PMU_TXN_READ);
| > +
| > + perf_event_read(leader);
|
| There should be a lockdep assert with that list iteration.
|
| > + list_for_each_entry(sub, >sibling_list, group_entry)
| > + perf_event_read(sub);
| > +
| > + ret = pmu->commit_txn(pmu);
Peter,
I have a situation :-)
We are trying to use the following interface:
start_txn(pmu, PERF_PMU_TXN_READ);
perf_event_read(leader);
list_for_each(sibling, >sibling_list, group_entry)
perf_event_read(sibling)
pmu->commit_txn(pmu);
with the idea that the PMU driver would save the type of transaction in
->start_txn() and use in ->read() and ->commit_txn().
But since ->start_txn() and the ->read() operations could happen on different
CPUs (perf_event_read() uses the event->oncpu to schedule a call), the PMU
driver cannot use a per-cpu variable to save the state in ->start_txn().
I tried using a pmu-wide global, but that would also need us to hold a mutex
to serialize access to that global. The problem is ->start_txn() can be
called from an interrupt context for the TXN_ADD transactions (I got the
following backtrace during testing)
mutex_lock_nested+0x504/0x520 (unreliable)
h_24x7_event_start_txn+0x3c/0xd0
group_sched_in+0x70/0x230
ctx_sched_in.isra.63+0x150/0x230
__perf_install_in_context+0x1c8/0x1e0
remote_function+0x7c/0xa0
flush_smp_call_function_queue+0xb0/0x1d0
smp_ipi_demux+0x88/0xf0
icp_hv_ipi_action+0x54/0xc0
handle_irq_event_percpu+0x98/0x2b0
handle_percpu_irq+0x7c/0xc0
generic_handle_irq+0x4c/0x80
__do_irq+0x7c/0x190
call_do_irq+0x14/0x24
do_IRQ+0x8c/0x100
hardware_interrupt_common+0x168/0x180
--- interrupt: 501 at .plpar_hcall_norets+0x14/0x20
Basically stuck trying to save the txn type in ->start_txn() and retrieve in
->read().
Couple of options I can think of are:
- having ->start_txn() return a handle that should then be passed in
with ->read() (yuck) and ->commit_txn().
- serialize the READ transaction for the PMU in perf_event_read_group()
with a new pmu->txn_mutex:
mutex_lock(>txn_mutex);
pmu->start_txn()
list_for_each_entry(sub, >sibling_list, group_entry)
perf_event_read(sub);
ret = pmu->commit_txn(pmu);
mutex_unlock(>txn_mutex);
such serialization would be ok with 24x7 counters (they are system
wide counters anyway) We could maybe skip the mutex for PMUs that
don't implement TXN_READ interface.
or is there better way?
Sukadev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: bcm2835: Add FIQ support
On 07/14/2015 05:48 AM, Noralf Trønnes wrote: > Den 14.07.2015 06:50, skrev Stephen Warren: >> On 07/11/2015 09:26 AM, Noralf Trønnes wrote: >>> Den 11.07.2015 06:09, skrev Stephen Warren: (Sorry for the slow reply; I was on vacation) On 06/18/2015 07:32 AM, Noralf Trønnes wrote: > Den 18.06.2015 04:26, skrev Stephen Warren: >> On 06/12/2015 11:26 AM, Noralf Trønnes wrote: >>> Add a duplicate irq range with an offset on the hwirq's so the >>> driver can detect that enable_fiq() is used. >>> Tested with downstream dwc_otg USB controller driver. >> This basically looks OK, but a few comments/thoughts: >> b) Doesn't the driver need to refuse some operation (handler >> registration, IRQ setup, IRQ enable, ...?) for more than 1 IRQ in the >> FIQ range, since the FIQ control register only allows routing 1 >> IRQ to >> FIQ. > claim_fiq() protects the FIQ. See d) answer below. That assumes the IRQ is "accessed" via the fiq-specific APIs. Since this patch changes the IRQ domain from having n IRQs to having 2*n IRQs, and doesn't do anything special to prevent clients from using IRQs n..2n-1 via the existing IRQ APIs, it's quite possible the a buggy client would. >>> Yes, but doesn't this apply to all irq use, using the wrong one doesn't >>> work. >>> If FIQ's where in more common use, we might have seen a FIQ IRQ flag >>> instead >>> of special FIQ irqs. >>> (From another email): >>> c) The DT binding needs updating to describe the extra IRQs: >>> Documentation/devicetree/bindings/interrupt-controller/brcm,bcm28armctrl-ic.txt >> Ok. > I have seconds thoughts on this: > This patch does not change the DT bindings so I don't see what update > I should make. This patch only adds support for the Linux way of > handling FIQ's through enable_fiq(). It doesn't change how interrupts > are described in the DT. The intention of the patch may not be to expand the set of IRQs available via DT, but it does in practice. I think you need to add a custom of_xlate for the IRQ domain to ensure that only IRQs 0..n-1 can be translated from DT, and not IRQs n..2n-1. If you do that, then I agree that no DT binding update should be required. >>> armctrl_xlate() maps to the same hwirqs as before. This patch adds a >>> new range of hwirqs at the end of the "real" hwirq range. >>> It's not possible to get to these FIQ shadow hwirqs through DT. >> What prevents a DT from (incorrectly) referencing the extra hwirqs? > > armctrl_xlate() has these limits: > > if (WARN_ON(intspec[0] >= NR_BANKS)) > if (WARN_ON(intspec[1] >= IRQS_PER_BANK)) > if (WARN_ON(intspec[0] == 0 && intspec[1] >= NR_IRQS_BANK0)) > > Thus the maximum values allowed are: > intspec[0]: (NR_BANKS - 1) = 2 > intspec[1]: (IRQS_PER_BANK - 1) = 31 > > This gives a maximum hwirq: > *out_hwirq = MAKE_HWIRQ(intspec[0], intspec[1]); > *out_hwirq = (2 << 5) | 31 = 95 > > The FIQ shadow hwirq range starts at 96: > irq = irq_create_mapping(intc.domain, MAKE_HWIRQ(b, i) + NUMBER_IRQS); > > NUMBER_IRQS = MAKE_HWIRQ(NR_BANKS, 0) = 96 Great, thanks for the explanation. That should be fine then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: Drop unnecessary arguments from two functions
From: Rafael J. Wysocki
The second sif argument of __cpufreq_remove_dev_prepare() is
never used by it, so drop it.
The second sif argument of __cpufreq_remove_dev_finish() is only
used for one check that is not necessary if the policy is freed
by cpufreq_remove_dev() itself, so make cpufreq_remove_dev() free
the policy and drop the __cpufreq_remove_dev_finish()'s second
argument too.
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/cpufreq.c | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -1421,8 +1421,7 @@ out_release_rwsem:
return ret;
}
-static int __cpufreq_remove_dev_prepare(struct device *dev,
- struct subsys_interface *sif)
+static int __cpufreq_remove_dev_prepare(struct device *dev)
{
unsigned int cpu = dev->id;
int ret = 0;
@@ -1474,8 +1473,7 @@ static int __cpufreq_remove_dev_prepare(
return ret;
}
-static int __cpufreq_remove_dev_finish(struct device *dev,
- struct subsys_interface *sif)
+static int __cpufreq_remove_dev_finish(struct device *dev)
{
unsigned int cpu = dev->id;
int ret;
@@ -1507,10 +1505,6 @@ static int __cpufreq_remove_dev_finish(s
if (cpufreq_driver->exit)
cpufreq_driver->exit(policy);
- /* Free the policy only if the driver is getting removed. */
- if (sif)
- cpufreq_policy_free(policy, true);
-
return 0;
}
@@ -1522,6 +1516,7 @@ static int __cpufreq_remove_dev_finish(s
static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif)
{
unsigned int cpu = dev->id;
+ struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
int ret;
/*
@@ -1530,7 +1525,6 @@ static int cpufreq_remove_dev(struct dev
* link or free policy here.
*/
if (cpu_is_offline(cpu)) {
- struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
struct cpumask mask;
if (!policy)
@@ -1547,17 +1541,18 @@ static int cpufreq_remove_dev(struct dev
remove_cpu_dev_symlink(policy, cpu);
return 0;
}
+ } else {
+ ret = __cpufreq_remove_dev_prepare(dev);
+ if (!ret)
+ ret = __cpufreq_remove_dev_finish(dev);
- cpufreq_policy_free(policy, true);
- return 0;
+ /* The CPU is online, so the policy cannot be inactive here. */
+ if (ret)
+ return ret;
}
- ret = __cpufreq_remove_dev_prepare(dev, sif);
-
- if (!ret)
- ret = __cpufreq_remove_dev_finish(dev, sif);
-
- return ret;
+ cpufreq_policy_free(policy, true);
+ return 0;
}
static void handle_update(struct work_struct *work)
@@ -2396,11 +2391,11 @@ static int cpufreq_cpu_callback(struct n
break;
case CPU_DOWN_PREPARE:
- __cpufreq_remove_dev_prepare(dev, NULL);
+ __cpufreq_remove_dev_prepare(dev);
break;
case CPU_POST_DEAD:
- __cpufreq_remove_dev_finish(dev, NULL);
+ __cpufreq_remove_dev_finish(dev);
break;
case CPU_DOWN_FAILED:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] e1000e: Move e1000e_disable_aspm_locked() inside CONFIG_PM
On Wed, 2015-07-15 at 03:30 -0700, Jeff Kirsher wrote: > On Tue, 2015-07-14 at 13:54 +1000, Michael Ellerman wrote: > > e1000e_disable_aspm_locked() is only used in __e1000_resume() which is > > inside CONFIG_PM. So when CONFIG_PM=n we get a "defined but not used" > > warning for e1000e_disable_aspm_locked(). > > > > Move it inside the existing CONFIG_PM block to avoid the warning. > > > > Signed-off-by: Michael Ellerman > > --- > > drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > NACK, this is already fixed in my next-queue tree. Raanan submitted a > patch back on July 6th to resolve this issue, see commit id > a75787d2246a93d256061db602f252703559af65 in my dev-queue branch of my > next-queue tree. OK. I take it your next-queue is destined for 4.3, so we'll just have to suck on the warning until then? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
On Tue, Jul 21 2015 at 9:00pm -0400, Dave Chinner wrote: > On Wed, Jul 22, 2015 at 10:09:23AM +1000, Dave Chinner wrote: > > On Tue, Jul 21, 2015 at 01:47:53PM -0400, Mike Snitzer wrote: > > > On Tue, Jul 21 2015 at 11:34am -0400, Eric Sandeen > > > wrote: > > > > On 7/20/15 5:36 PM, Dave Chinner wrote: > > > > The issue we had discussed previously is that there is no agreement > > > > across block devices about whether ENOSPC is a permanent or temporary > > > > condition. Asking the admin to tune the fs to each block device's > > > > behavior sucks, IMHO. > > > > > > It does suck, but it beats the alternative of XFS continuing to do > > > nothing about the problem. > > > > Just a comment on that: doing nothing is better than doing the wrong > > thing and being stuck with it forever. :) > > > > > Disucssing more with Vivek, might be that XFS would be best served to > > > model what dm-thinp has provided with its 'no_space_timeout'. It > > > defaults to queueing IO for 60 seconds, once the timeout expires the > > > queued IOs getted errored. If set to 0 dm-thinp will queue IO > > > indefinitely. > > > > Yes, that's exactly what I proposed in the thread I referenced in > > my previous email, and what got stuck on the bikeshed wall because > > of these concerns about knob twiddling: > > > > http://oss.sgi.com/archives/xfs/2015-02/msg00346.html > > > > | e.g. if we need configurable error handling, it needs to be > > | configurable for different error types, and it needs to be > > | configurable on a per-mount basis. And it needs to be configurable > > | at runtime, not just at mount time. That kind of leads to using > > | sysfs for this. e.g. for each error type we ned to handle different > > | behaviour for: > > | > > | $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/type > > | [transient] permanent > > | $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/perm_timeout_seconds > > | 300 > > | $ cat > > | /sys/fs/xfs/vda/meta_write_errors/enospc/perm_max_retry_attempts > > | 50 > > | $ cat > > | /sys/fs/xfs/vda/meta_write_errors/enospc/transient_fail_at_umount > > | 1 > > > > I've rebased this patchset, and I'm cleaning it up now, so in a few > > days I'll have something for review, likely for the 4.3 merge > > window > > Just thinking a bit more on how to make this simpler to configure, > is there a simple way for the filesystem to determine the current > config of the dm thinp volume? i.e. if the dm-thinp volume is > configured to error out immediately on enospc, then XFS should > default to doing the same thing. having XFS be able to grab this > status at mount time and change the default ENOSPC error config from > transient to permanent on such dm-thinp volumes would go a long way > to making these configs Just Do The Right Thing on block dev enospc > errors... > > e.g. if dm-thinp is configured to queue for 60s and then fail on > ENOSPC, we want XFS to fail immediately on ENOSPC in metadata IO. If > dm-thinp is configured to ENOSPC instantly (i.e. no queueing) then > we want XFS to retry and use it's default retry maximums before > failing permanently. Yes, that'd be nice. But there isn't a way to easily get the DM thinp device's config from within the kernel (unless XFS wants to get into the business of issuing ioctls to DM devices.. unlikely). I could be persuaded to expose a per-device sysfs file to get the status (would avoid need for ioctl), e.g.: # cat /sys/block/dm-5/dm/status (but that doesn't _really_ help in-kernel access, awkward for filesystem code to be opening sysfs files!) SO userspace (mkfs.xfs) could easily check the thinp device's setup using 'dmsetup status ' (output will either contain 'queue_if_no_space' or 'error_if_no_space'). The DM thinp 'no_space_timeout' (applicable if queue_if_no_space) is a thinp global accessed using a module param: # cat /sys/module/dm_thin_pool/parameters/no_space_timeout 60 I'm open to considering alternative interfaces for getting you the info you need. I just don't have a great sense for what mechanism you'd like to use. Do we invent a new block device operations table method that sets values in a 'struct no_space_strategy' passed in to the blockdevice? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] target/iscsi: fix digest computation for chained SGs
On Tue, Jul 21, 2015 at 1:57 AM, Sagi Grimberg wrote: > How were you able to get a chained SG list in the target code? Local hack. So this bug can't be hit in current mainline code, but patch improves the code and removes a hidden booby-trap, so I think it makes sense to apply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] platform/chrome: Don't make CHROME_PLATFORMS depends on X86 || ARM
On Thu, Jun 25, 2015 at 02:20:42AM +0200, Javier Martinez Canillas wrote: > The Chrome platform support depends on X86 || ARM because there are > only Chromebooks using those architectures. But only some drivers > depend on a given architecture, and the ones that do already have > a dependency on their specific Kconfig symbol entries. > > An option is to also make CHROME_PLATFORMS depends on || COMPILE_TEST > but is more future proof to remove the dependency and let the drivers > be built in all architectures if possible to have more build coverage. > > Signed-off-by: Javier Martinez Canillas Acked-by: Olof Johansson -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM
On Thu, Jun 25, 2015 at 10:44:28AM +0200, Javier Martinez Canillas wrote: > Hello Lee, > > On 06/25/2015 10:38 AM, Lee Jones wrote: > > On Thu, 25 Jun 2015, Javier Martinez Canillas wrote: > > > >> A dependency on X86 || ARM for MFD_CROS_EC was added to fix the warning: > >> > >> (MFD_CROS_EC) selects CHROME_PLATFORMS which has unmet direct dependencies > >> (X86 || ARM) > >> > >> This happened because CHROME_PLATFORMS had a dependency on X86 || ARM but > >> that dependency was removed since there isn't a reason why the option can > >> not be selected on other architectures. So now the above warning will not > >> happen and the MFD_CROS_EC dependency can be removed since is not needed. > >> > >> Signed-off-by: Javier Martinez Canillas > >> --- > >> > >> drivers/mfd/Kconfig | 1 - > >> 1 file changed, 1 deletion(-) > > > > Applied for v4.3, thanks. > > > > Thanks a lot. > > Olof, > > Could you please ack patch 1/3 so Lee can pick it through the mfd tree? > Since both patches 1/3 and 2/3 are needed to fix the build warning for > !X86 and !ARM architectures. Yep, done. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM
On Tue, Jul 21, 2015 at 6:13 PM, Paul Gortmaker wrote: > [Re: [PATCH 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM] On 25/06/2015 > (Thu 10:44) Javier Martinez Canillas wrote: > >> Hello Lee, >> >> On 06/25/2015 10:38 AM, Lee Jones wrote: >> > On Thu, 25 Jun 2015, Javier Martinez Canillas wrote: >> > >> >> A dependency on X86 || ARM for MFD_CROS_EC was added to fix the warning: >> >> >> >> (MFD_CROS_EC) selects CHROME_PLATFORMS which has unmet direct >> >> dependencies (X86 || ARM) >> >> >> >> This happened because CHROME_PLATFORMS had a dependency on X86 || ARM but >> >> that dependency was removed since there isn't a reason why the option can >> >> not be selected on other architectures. So now the above warning will not >> >> happen and the MFD_CROS_EC dependency can be removed since is not needed. >> >> >> >> Signed-off-by: Javier Martinez Canillas >> >> --- >> >> >> >> drivers/mfd/Kconfig | 1 - >> >> 1 file changed, 1 deletion(-) >> > >> > Applied for v4.3, thanks. >> > >> >> Thanks a lot. >> >> Olof, >> >> Could you please ack patch 1/3 so Lee can pick it through the mfd tree? >> Since both patches 1/3 and 2/3 are needed to fix the build warning for >> !X86 and !ARM architectures. > > Hi all, > > Wondering if this fell through the cracks. It used to be just a > linux-next issue, but now it is a mainline issue. This _really_ should > be fixed and fed to Linus ASAP. Ideally it should have been fixed before > going to mainline as it was reported in plenty of time ; that is the > whole point of linux-next to fix unanticipated fallout and revise. Yep, agreed. I've been a bit removed from upstream work for the last couple of months (getting back to it now), so I've been bad at following up on this. Acks sent now, Lee, please pick up for 4.2 if you don't mind. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/4] PCI: iproc: Fix ARM64 dependency in Kconfig
Allow Broadcom iProc PCIe core driver to be compiled for ARM64 Signed-off-by: Ray Jui Reviewed-by: Vikram Prakash Reviewed-by: Scott Branden --- drivers/pci/host/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index c132bdd..d2c6144 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -117,7 +117,7 @@ config PCI_VERSATILE config PCIE_IPROC tristate "Broadcom iProc PCIe controller" - depends on OF && ARM + depends on OF && (ARM || ARM64) default n help This enables the iProc PCIe core controller support for Broadcom's -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/4] arm64: Add Broadcom iProc family support
This patch adds support to Broadcom's iProc family of arm64 based SoCs in the arm64 Kconfig and defconfig files Signed-off-by: Ray Jui Reviewed-by: Scott Branden --- arch/arm64/Kconfig |5 + arch/arm64/configs/defconfig |2 ++ 2 files changed, 7 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 318175f..969ef4a 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -162,6 +162,11 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_BCM_IPROC + bool "Broadcom iProc SoC Family" + help + This enables support for Broadcom iProc based SoCs + config ARCH_EXYNOS bool help diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 4e17e7e..c83d51f 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -31,6 +31,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_BCM_IPROC=y CONFIG_ARCH_EXYNOS7=y CONFIG_ARCH_FSL_LS2085A=y CONFIG_ARCH_HISI=y @@ -102,6 +103,7 @@ CONFIG_SERIO_AMBAKMI=y CONFIG_LEGACY_PTY_COUNT=16 CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_DW=y CONFIG_SERIAL_8250_MT6577=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/4] arm64: dts: Add Broadcom North Star 2 support
Add Broadcom NS2 device tree binding document. Also add initial device
tree dtsi for Broadcom North Star 2 (NS2) SoC and board support for NS2
SVK board
Signed-off-by: Jon Mason
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
Documentation/devicetree/bindings/arm/bcm/ns2.txt |9 ++
arch/arm64/boot/dts/Makefile |1 +
arch/arm64/boot/dts/broadcom/Makefile |5 +
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 59 +++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 118 +
5 files changed, 192 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/bcm/ns2.txt
create mode 100644 arch/arm64/boot/dts/broadcom/Makefile
create mode 100644 arch/arm64/boot/dts/broadcom/ns2-svk.dts
create mode 100644 arch/arm64/boot/dts/broadcom/ns2.dtsi
diff --git a/Documentation/devicetree/bindings/arm/bcm/ns2.txt
b/Documentation/devicetree/bindings/arm/bcm/ns2.txt
new file mode 100644
index 000..35f056f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/ns2.txt
@@ -0,0 +1,9 @@
+Broadcom North Star 2 (NS2) device tree bindings
+
+
+Boards with NS2 shall have the following properties:
+
+Required root node property:
+
+NS2 SVK board
+compatible = "brcm,ns2-svk", "brcm,ns2";
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 38913be..9f95941 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,6 +1,7 @@
dts-dirs += amd
dts-dirs += apm
dts-dirs += arm
+dts-dirs += broadcom
dts-dirs += cavium
dts-dirs += exynos
dts-dirs += freescale
diff --git a/arch/arm64/boot/dts/broadcom/Makefile
b/arch/arm64/boot/dts/broadcom/Makefile
new file mode 100644
index 000..e21fe66
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb
+
+always := $(dtb-y)
+subdir-y := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
new file mode 100644
index 000..244baf8
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -0,0 +1,59 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "ns2.dtsi"
+
+/ {
+ model = "Broadcom NS2 SVK";
+ compatible = "brcm,ns2-svk", "brcm,ns2";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x8000 0x 0x4000>;
+ };
+
+ soc: soc {
+ uart3: serial@6613 {
+ status = "ok";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
new file mode 100644
index 000..3c92d92
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -0,0 +1,118 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *
Re: [PATCH] cpufreq: Avoid double addition/removal of sysfs links
On Wednesday, July 22, 2015 01:15:01 AM Rafael J. Wysocki wrote: > Hi VIresh, > > On Mon, Jul 20, 2015 at 11:47 AM, Viresh Kumar > wrote: > > Consider a dual core (0/1) system with two CPUs: > > - sharing clock/voltage rails and hence cpufreq-policy > > - CPU1 is offline while the cpufreq driver is registered > > > > - cpufreq_add_dev() is called from subsys callback for CPU0 and we > > create the policy for the CPUs and create link for CPU1. > > - cpufreq_add_dev() is called from subsys callback for CPU1, we find > > that the cpu is offline and we try to create a sysfs link for CPU1. > > So the problem is that the cpu_is_offline(cpu) check in > cpufreq_add_dev() matches two distinct cases: (1) the CPU was not > present before and it is just being hot-added and (2) the CPU is > initially offline, but present, and this is the first time its device > is registered. In the first case we can expect that the CPU will > become online shortly (although that is not guaranteed too), but in > the second case that very well may not happen. > > We need to be able to distinguish between those two cases and your > patch does that, but I'm not sure if this really is the most > straightforward way to do it. It looks like we need a mask of related CPUs that are present. Or, alternatively, a mask of CPUs that would have been related had they been present. That's sort of what your patch is adding, but not quite. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/4] PCI: iproc: enable arm64 support for iProc PCIe
This patch enables arm64 support to the iProc PCIe driver
Note struct pci_sys_data is arm32 specific and will eventually be
removed. This change is done in such a way that when struct pci_sys_data
is removed from arm32, one only needs to also remove it from
pcie-iproc.h, no other change in the iProc PCIe core driver is needed
In addition, arm64 based PCI driver does not require call to
pci_fixup_irqs, as it implements OF based irq parsing and mapping in
pcibios_add_device
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/pci/host/pcie-iproc.c | 15 ---
drivers/pci/host/pcie-iproc.h |8 ++--
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index d77481e..8a556d5 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -58,11 +58,6 @@
#define SYS_RC_INTX_EN 0x330
#define SYS_RC_INTX_MASK 0xf
-static inline struct iproc_pcie *sys_to_pcie(struct pci_sys_data *sys)
-{
- return sys->private_data;
-}
-
/**
* Note access to the configuration registers are protected at the higher layer
* by 'pci_lock' in drivers/pci/access.c
@@ -71,8 +66,7 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct pci_bus
*bus,
unsigned int devfn,
int where)
{
- struct pci_sys_data *sys = bus->sysdata;
- struct iproc_pcie *pcie = sys_to_pcie(sys);
+ struct iproc_pcie *pcie = bus->sysdata;
unsigned slot = PCI_SLOT(devfn);
unsigned fn = PCI_FUNC(devfn);
unsigned busno = bus->number;
@@ -208,10 +202,7 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct
list_head *res)
iproc_pcie_reset(pcie);
- pcie->sysdata.private_data = pcie;
-
- bus = pci_create_root_bus(pcie->dev, 0, _pcie_ops,
- >sysdata, res);
+ bus = pci_create_root_bus(pcie->dev, 0, _pcie_ops, pcie, res);
if (!bus) {
dev_err(pcie->dev, "unable to create PCI root bus\n");
ret = -ENOMEM;
@@ -229,7 +220,9 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct
list_head *res)
pci_scan_child_bus(bus);
pci_assign_unassigned_bus_resources(bus);
+#ifdef CONFIG_ARM
pci_fixup_irqs(pci_common_swizzle, pcie->map_irq);
+#endif
pci_bus_add_devices(bus);
return 0;
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index ba0a108..0ee9673 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -18,18 +18,22 @@
/**
* iProc PCIe device
+ * @sysdata: Per PCI controller data. This needs to be kept at the beginning of
+ * struct iproc_pcie, to enable support of both ARM32 and ARM64 platforms with
+ * minimal changes in the iProc PCIe core driver
* @dev: pointer to device data structure
* @base: PCIe host controller I/O register base
* @resources: linked list of all PCI resources
- * @sysdata: Per PCI controller data
* @root_bus: pointer to root bus
* @phy: optional PHY device that controls the Serdes
* @irqs: interrupt IDs
*/
struct iproc_pcie {
+#ifdef CONFIG_ARM
+ struct pci_sys_data sysdata;
+#endif
struct device *dev;
void __iomem *base;
- struct pci_sys_data sysdata;
struct pci_bus *root_bus;
struct phy *phy;
int irqs[IPROC_PCIE_MAX_NUM_IRQS];
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/4] Add Broadcom North Star 2 support
This patch series adds Broadcom North Star 2 (NS2) SoC support. NS2 is an ARMv8 based SoC and under the Broadcom iProc family. Sorry for tying this with the Broadcom iProc PCIe driver fixes for ARM64. I have to tie them together because iProc PCIe support is enabled by default when ARCH_BCM_IPROC is enabled. Without the fixes in the iProc PCIe driver, enabling CONFIG_ARCH_BCM_IPROC would break the build for arm64 defconfig. Let me know if there's a better way to handle this. This patch series is generated based on v4.2-rc2 and tested on Broadcom NS2 SVK Code available on GITHUB: https://github.com/Broadcom/arm64-linux.git branch is ns2-core-v4 Changes from V3: - Add more paragraph to the iProc PCIe arm64 support patch commit message to explain the change and anticipated future change in more details Changes from V2: - Drop hardcoded earlycon kernel command line paramter in NS2 SVK dts file because 1) earlycon is a debugging feature that can be enabled in the bootloader and should not be enabled by default in the board dts file and 2) of_earlycon should be used and support should be added to 8250 DW driver Changes from V1: - Took Arnd's advice to tweak the location of struct pci_sys_data within struct iproc_pcie. This helps to get rid of most of the CONFIG_ARM wrap in iProc PCIe core driver - Use stdout-path and alias for serial console in NS2 SVK dts - Add all 4 CPU descriptions in NS2 dtsi - Remove "clock-frequency" property in the armv8 timer node so timer frequency can be determined based on readings from CNTFRQ_EL0 - Remove config flag ARCH_BCM_NS2. Leave only ARCH_BCM_IPROC for all Broadcom arm64 SoCs as advised Ray Jui (4): PCI: iproc: enable arm64 support for iProc PCIe PCI: iproc: Fix ARM64 dependency in Kconfig arm64: Add Broadcom iProc family support arm64: dts: Add Broadcom North Star 2 support Documentation/devicetree/bindings/arm/bcm/ns2.txt |9 ++ arch/arm64/Kconfig|5 + arch/arm64/boot/dts/Makefile |1 + arch/arm64/boot/dts/broadcom/Makefile |5 + arch/arm64/boot/dts/broadcom/ns2-svk.dts | 59 +++ arch/arm64/boot/dts/broadcom/ns2.dtsi | 118 + arch/arm64/configs/defconfig |2 + drivers/pci/host/Kconfig |2 +- drivers/pci/host/pcie-iproc.c | 15 +-- drivers/pci/host/pcie-iproc.h |8 +- 10 files changed, 210 insertions(+), 14 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/ns2.txt create mode 100644 arch/arm64/boot/dts/broadcom/Makefile create mode 100644 arch/arm64/boot/dts/broadcom/ns2-svk.dts create mode 100644 arch/arm64/boot/dts/broadcom/ns2.dtsi -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
