Re: [PATCH 4/5] ARM: tegra: Add host1x, dc and hdmi to Tegra114 device tree
On 28.08.2013 16:18, Thierry Reding wrote: > I think that's not all. I have local patches that also introduce a v2 of > host1x, because the number of syncpoints is different. There may also be > other differences, but Terje might be more qualified to answer that. Tegra4 host1x has an extra channel(totals 9), which caused bitfields in a couple of registers to shift. The registers are mainly used in the debug code to dump the channel FIFO. Same number of sync points as Tegra3, but 12 wait bases. Other changes are minor and driver already deals with them, for example 32-bit versus 16-bit sync point value comparison. Terje -- 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/12] KVM: MMU: introduce pte-list lockless walker
On 08/28/2013 09:36 PM, Gleb Natapov wrote: > On Wed, Aug 28, 2013 at 08:15:36PM +0800, Xiao Guangrong wrote: >> On 08/28/2013 06:49 PM, Gleb Natapov wrote: >>> On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote: On 08/28/2013 05:46 PM, Gleb Natapov wrote: > On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote: >>> Or what if desc is moved to another rmap, but then it >>> is moved back to initial rmap (but another place in the desc list) so >>> the check here will not catch that we need to restart walking? >> >> It is okay. We always add the new desc to the head, then we will walk >> all the entires under this case. >> > Which races another question: What if desc is added in front of the list > behind the point where lockless walker currently is? That case is new spte is being added into the rmap. We need not to care the new sptes since it will set the dirty-bitmap then they can be write-protected next time. >>> OK. >>> > >> Right? > Not sure. While lockless walker works on a desc rmap can be completely > destroyed and recreated again. It can be any order. I think the thing is very similar as include/linux/rculist_nulls.h >>> include/linux/rculist_nulls.h is for implementing hash tables, so they >>> may not care about add/del/lookup race for instance, but may be we are >>> (you are saying above that we are not), so similarity does not prove >>> correctness for our case. >> >> We do not care the "add" and "del" too when lookup the rmap. Under the "add" >> case, it is okay, the reason i have explained above. Under the "del" case, >> the spte becomes unpresent and flush all tlbs immediately, so it is also >> okay. >> >> I always use a stupid way to check the correctness, that is enumerating >> all cases we may meet, in this patch, we may meet these cases: >> >> 1) kvm deletes the desc before we are current on >>that descs have been checked, do not need to care it. >> >> 2) kvm deletes the desc after we are currently on >>Since we always add/del the head desc, we can sure the current desc has >> been >>deleted, then we will meet case 3). >> >> 3) kvm deletes the desc that we are currently on >>3.a): the desc stays in slab cache (do not be reused). >> all spte entires are empty, then the fn() will skip the nonprsent >> spte, >> and desc->more is >> 3.a.1) still pointing to next-desc, then we will continue the lookup >> 3.a.2) or it is the "nulls list", that means we reach the last one, >> then finish the walk. >> >>3.b): the desc is alloc-ed from slab cache and it's being initialized. >> we will see "desc->more == NULL" then restart the walking. It's >> okay. >> >>3.c): the desc is added to rmap or pte_list again. >> 3.c.1): the desc is added to the current rmap again. >> the new desc always acts as the head desc, then we will walk >> all entries, some entries are double checked and not entry >> can be missed. It is okay. >> >> 3.c.2): the desc is added to another rmap or pte_list >> since kvm_set_memory_region() and get_dirty are serial by >> slots-lock. >> so the "nulls" can not be reused during lookup. Then we we >> will >> meet the different "nulls" at the end of walking that will >> cause >> rewalk. >> >> I know check the algorithm like this is really silly, do you have other idea? >> > Not silly, but easy to miss cases. For instance 3.c.3 can be: > the desc is added to another rmap then we move to another desc on the > wrong rmap, this other desc is also deleted and reinserted into > original rmap. Seams like justification from 3.c.1 applies to that to > though. > >>> BTW I do not see >>> rcu_assign_pointer()/rcu_dereference() in your patches which hints on >> >> IIUC, We can not directly use rcu_assign_pointer(), that is something like: >> p = v to assign a pointer to a pointer. But in our case, we need: >>*pte_list = (unsigned long)desc | 1; >>From Documentation/RCU/whatisRCU.txt: > > The updater uses this function to assign a new value to an RCU-protected > pointer. > > This is what we do, no? (assuming slot->arch.rmap[] is what rcu protects here) > The fact that the value is not correct pointer should not matter. > Okay. Will change that code to: + +#define rcu_assign_head_desc(pte_list_p, value)\ + rcu_assign_pointer(*(unsigned long __rcu **)(pte_list_p), (unsigned long *)(value)) + /* * Pte mapping structures: * @@ -1006,14 +1010,7 @@ static int pte_list_add(struct kvm_vcpu *vcpu, u64 *spte, desc->sptes[1] = spte; desc_mark_nulls(pte_list, desc); - /* -* Esure the old spte has been updated into desc, so -* that the another side can not get the
Re: [PATCH 1/3] cpuidle: coupled: disable interrupts after entering safe state
On Saturday 24 August 2013 01:15 AM, Colin Cross wrote:
Calling cpuidle_enter_state is expected to return with interrupts
enabled, but interrupts must be disabled before starting the
ready loop synchronization stage. Call local_irq_disable after
each call to cpuidle_enter_state for the safe state.
CC: sta...@vger.kernel.org
Signed-off-by: Colin Cross
---
drivers/cpuidle/coupled.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 2a297f8..db92bcb 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -460,6 +460,7 @@ int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
}
entered_state = cpuidle_enter_state(dev, drv,
dev->safe_state_index);
+ local_irq_disable();
Colin,
There is still some window where irq remains enabled after exiting safe
state. It may introduce some corner case.
Instead of this can we pass a parameter to cpuidle_enter_state
indicating that irq has to be enabled or not after exit from idle state,
which would be false when entering safe state from coupled idle.
}
/* Read barrier ensures online_count is read after prevent is cleared */
@@ -485,6 +486,7 @@ retry:
entered_state = cpuidle_enter_state(dev, drv,
dev->safe_state_index);
+ local_irq_disable();
}
if (cpuidle_coupled_clear_pokes(dev->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] ARC: Fix __udelay parentheses
On 08/29/2013 12:07 PM, Joe Perches wrote: >> On the topic of multiply vs. divide (which probably is not relevant to topic >> at >> hand though), since ARCompact doesn't have native divide, we end up >> emulating it >> using libgcc routines. That makes it slightly non-deterministic (not a big >> deal) >> and also adds to boot time (which those delays sprinkled all over the place >> in >> crazy device probes and such). Seriously we got hammered by a customer for >> that once. > That argues more for reducing the uses of hard delays > than making the hard delay count calculation simpler. Right, but most often the drivers are written/maintained by non arch people. I'm with you in terms of simplification and I think the following loops = ((u64)usecs * 4295 * HZ * loops_per_jiffy) >> 32; is fairly simple, well commented, and optimal for ARC. -Vineet -- 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] ARC: Add perf support
* Mischa Jonker wrote:
> +/* The "generalized" performance events seem to really be a copy
> + of the available events on x86 processors; the mapping to ARC
> + events is not always possible 1-to-1. Fortunately, there doesn't
> + seem to be an exact definition for these events, so we can cheat
> + a bit where necessary */
> +static const char * const arc_pmu_ev_hw_map[] = {
> + /* cycles not in halted state */
> + [PERF_COUNT_HW_CPU_CYCLES] = "crun",
> + /* reference cycles not in halted state; also "crun" as we don't
> +do Dynamic Voltage/Frequency Scaling (yet) */
> + [PERF_COUNT_HW_REF_CPU_CYCLES] = "crun",
> + /* Unclear what this means, Intel uses 0x013c, which according to
> +their datasheet means "unhalted reference cycles". Don't ask
> +me what the difference is with PERF_COUNT_HW_REF_CPU_CYCLES */
> + [PERF_COUNT_HW_BUS_CYCLES] = "crun",
> + [PERF_COUNT_HW_INSTRUCTIONS] = "iall",
> + [PERF_COUNT_HW_BRANCH_MISSES] = "bpfail",
> + [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = "ijmp",
> + /* ARC can either measure stalls per pipeline stage, or all stalls
> +combined; for now we assign all stalls to STALLED_CYCLES_BACKEND
> +and all pipeline flushes (e.g. caused by mispredicts, etc.) to
> +STALLED_CYCLES_FRONTEND.
> +
> +We could start multiple performance counters and combine everything
> +afterwards, but that makes it complicated, and users can always
> +use PERF_TYPE_RAW.
> +
> +Note that I$ cache misses aren't counted by either of the two! */
Haven't really looked at the patch in detail, just noticed the following
nit, please use the customary (multi-line) comment style:
/*
* Comment .
* .. goes here.
*/
specified in Documentation/CodingStyle.
Thanks,
Ingo
--
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] ARC: Fix __udelay parentheses
On Thu, 2013-08-29 at 06:24 +, Vineet Gupta wrote: > On 08/29/2013 11:31 AM, Joe Perches wrote: > > I think the whole thing is odd and it should simply be > > > > loops = loops_per_jiffy * usecs_to_jiffies(usecs) [] > On the topic of multiply vs. divide (which probably is not relevant to topic > at > hand though), since ARCompact doesn't have native divide, we end up emulating > it > using libgcc routines. That makes it slightly non-deterministic (not a big > deal) > and also adds to boot time (which those delays sprinkled all over the place in > crazy device probes and such). Seriously we got hammered by a customer for > that once. That argues more for reducing the uses of hard delays than making the hard delay count calculation simpler. -- 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: [gcv v3 32/35] arc: Replace __get_cpu_var uses
On 08/29/2013 01:18 AM, Christoph Lameter wrote: > Acked-by: Vineet Gupta > Signed-off-by: Christoph Lameter Applied to for-next. Thx, -Vineet -- 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: Announcement of Linux v3.11-rc7?
On Mon, Aug 26, 2013 at 6:23 PM, Pavel Machek wrote: > Hi! > >> I am reading LKML offline (mostly on ). >> Did you send out an announcement for Linux v3.11-rc7 or am I missing >> sth.? > > I don't think it hit the mailing list. (Either that, or list > unsubscribed me, again). No you aren't.. Even I can't find it on mailing list :) -- 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/4] usb: r8a66597-hcd: use platform_{get,set}_drvdata()
On Thu, Aug 29, 2013 at 10:54:51AM +0800, Libo Chen wrote:
> On 2013/8/28 12:36, Greg KH wrote:
> > On Tue, Aug 27, 2013 at 04:10:22PM +0800, Libo Chen wrote:
> >>
> >> Use the wrapper functions for getting and setting the driver data using
> >> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
> >> so we can directly pass a struct platform_device.
> >>
> >> Signed-off-by: Libo Chen
> >> ---
> >> drivers/usb/host/r8a66597-hcd.c |4 ++--
> >> 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > This patch doesn't apply to my tree :(
>
> Hi Greg,
>
> This patch based on mainline.
> Do you mean this patch got a conflicted in
> "git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git"
>
> I need to rebase on "usb.git"?
Yes, please use the usb-next branch.
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/
Re: [PATCH] ARC: Add read*_relaxed to asm/io.h
On 08/29/2013 12:03 AM, Mischa Jonker wrote: > Some drivers require these, and ARC didn't had them yet. > > Signed-off-by: Mischa Jonker Applied. Thx, -Vineet -- 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] ARC: Fix __udelay parentheses
On 08/29/2013 11:31 AM, Joe Perches wrote: > On Thu, 2013-08-29 at 05:55 +, Vineet Gupta wrote: > >> The intent of writing orig code was to generate only 1 MPYHU insn (32*32 = >> high-part-64) for the whole math, at any optimization level whatsoever. If >> the >> first MPY is overflowing, u r likely spinning for > 10,000 usec (10ms) which >> is 1 >> scheduling tick on ARC - not good - presumably for hardware debug. It would >> be >> better to use a tight loop there and throw it out later. > It's a delay loop. Does it matter whether > or not a multiply or division is used? I know what you mean here. Your suggestion from a different mail, > I think the whole thing is odd and it should simply be > > loops = loops_per_jiffy * usecs_to_jiffies(usecs) This adds an additional MPYHU (ignoring the large limms and check for max jiffies). FWIW, most arches do optimize this routine a bit - so ARC not using a standard kernel API is not that big a sin ;-) On the topic of multiply vs. divide (which probably is not relevant to topic at hand though), since ARCompact doesn't have native divide, we end up emulating it using libgcc routines. That makes it slightly non-deterministic (not a big deal) and also adds to boot time (which those delays sprinkled all over the place in crazy device probes and such). Seriously we got hammered by a customer for that once. -Vineet -- 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] mm/mmap: remove unnecessary assignment
On Thu, 29 Aug 2013, Yanchuan Nian wrote: > From: Yanchuan Nian > > pgoff is not used after the statement "pgoff = vma->vm_pgoff;", > so the assignment is redundant. > > Signed-off-by: Yanchuan Nian Acked-by: David Rientjes -- 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 v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
Hi George, On 08/29/2013 11:21 AM, George Cherian wrote: > Hi Chanwoo, > > Thanks for the review and sorry for all the trivial mistakes. > > On 8/29/2013 7:05 AM, Chanwoo Choi wrote: >> Hi George, >> >> You didn't modify this patchset about my comment on v1 patchset. >> Please pay attention to comment. >> >> On 08/29/2013 02:33 AM, George Cherian wrote: >>> Add a generic USB VBUS/ID detection EXTCON driver. This driver expects >>> the ID/VBUS pin are connected via GPIOs. This driver is tested on >>> DRA7x board were the ID pin is routed via GPIOs. The driver supports >>> both VBUS and ID pin configuration and ID pin only configuration. >>> >>> Signed-off-by: George Cherian >>> --- >>> .../bindings/extcon/extcon-gpio-usbvid.txt | 20 ++ >>> drivers/extcon/Kconfig | 6 + >>> drivers/extcon/Makefile| 1 + >>> drivers/extcon/extcon-gpio-usbvid.c| 286 >>> + >> You should keep following naming stlye. extcon-gpio-usbvid.c is wrong naming >> style. >> - extcon-[device name].c >> - extcon-gpio-usbvid.c -> extcon-dra7xx.c or etc. > Actually dra7xx is the SoC name and the USB VBUS/ID detection is not specific > to SoC. > It uses gpios to detect the VBUS/ID change. So i thought it would be better > to have generic > gpio based VBUS/ID detection rather than making dra7xx specific. Stephen > Warren had this opinion > with patch v1. Would you guarantee that this driver support all of extcon devices using gpio pin? I can't agree. This driver has specific dependency on dra7x SoC. First, vbus_irq_handler() determine USB cable state according to "gpio_usbvid->vbus_gpio" state. If "gpio_usbvid->vbus_gpio" value is VBUS_OFF(0), this patch set USB cable state as 'false' But, it include potential problems. Other extcon device using gpio would set USB cable state as 'true' when gpio state is 1. This way has dependency on specific SoC. Second, gpio_usbvid_set_initial_state() dertermine both "USB-HOST" and "USB" cable state at same time in 'case ID_DETCT' according to 'gpio_usbvid->id_gpio'. But, I think that other extcon devices would not control both "USB-HOST" and "USB" cable state at same time. Other extcon devices would support either "USB-HOST" or "USB" cable. Third, gpio_usbvid_probe() get both gpio_usbvid->id_irq and gpio_usbvid->vbus_irq by using DT helper function. and gpio_usbvid_request_irq() register each interrupt handler(id_irq and vbus_irq) according to DT data. In result, id_irq_handler() would control both "USB-HOST" and "USB" cable state. vbus_irq_handler() would control only "USB" cable state. Two interrupt handler(id_irq_handler()/vbus_irq_handler()) would control "USB" cable state according to each gpio state at same time. Also, It include critical problem. >> >> Also, you should change the file name of extcon-gpio-usbvid.txt. >> >> Finally, You used 'gpio_usbvid' prefix in extcon-gpio-usbvid.c. >> It has caused the confusion that user would think extcon-gpio-usbvid.c driver >> support all of extcon driver using gpio irq pin. So I'd like you to use >> proper prefix including device name. > I meant to support all of extcon driver using gpio for USB VBUS/ID detection. >> >>> 4 files changed, 313 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt >>> create mode 100644 drivers/extcon/extcon-gpio-usbvid.c > [snip] >>> index f1d54a3..8097398 100644 >>> --- a/drivers/extcon/Kconfig >>> +++ b/drivers/extcon/Kconfig >>> @@ -64,4 +64,10 @@ config EXTCON_PALMAS >>> Say Y here to enable support for USB peripheral and USB host >>> detection by palmas usb. >>> +config EXTCON_GPIO_USBVID >>> +tristate "Generic USB VBUS/ID detection using GPIO EXTCON support" >>> +help >>> + Say Y here to enable support for USB VBUS/ID deetction by GPIO. >>> + >>> + >> Remove blank line. > okay >>> endif # MULTISTATE_SWITCH > [snip] >>> diff --git a/drivers/extcon/extcon-gpio-usbvid.c >>> b/drivers/extcon/extcon-gpio-usbvid.c >>> new file mode 100644 >>> index 000..e9bc2a97 >>> --- /dev/null >>> +++ b/drivers/extcon/extcon-gpio-usbvid.c >>> @@ -0,0 +1,286 @@ >>> +/* >>> + * Generic USB VBUS-ID pin detection driver >>> + * >>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License as published by >>> + * the Free Software Foundation; either version 2 of the License, or >>> + * (at your option) any later version. >>> + * >>> + * Author: George Cherian >>> + * >>> + * Based on extcon-palmas.c >>> + * >>> + * Author: Kishon Vijay Abraham I >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR
[patch] mm, memcg: store memcg name for oom kill log consistency
A shared buffer is currently used for the name of the oom memcg and the
memcg of the killed process. There is no serialization of memcg oom
kills, so this buffer can easily be overwritten if there is a concurrent
oom kill in another memcg.
This patch stores the names of the memcgs directly in struct mem_cgroup.
This allows it to be printed anytime during the oom kill without fearing
that it will change or become corrupted. It also ensures that the name
of the memcg that is oom and the memcg of the killed process are the same
even if renamed at the same time.
Signed-off-by: David Rientjes
---
mm/memcontrol.c | 49 +++--
1 file changed, 23 insertions(+), 26 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -83,6 +83,8 @@ static int really_do_swap_account __initdata = 0;
#define do_swap_account0
#endif
+/* First 128 bytes of memcg name should be unique */
+#define MEM_CGROUP_STORE_NAME_LEN 128
static const char * const mem_cgroup_stat_names[] = {
"cache",
@@ -247,6 +249,9 @@ struct mem_cgroup {
/* OOM-Killer disable */
int oom_kill_disable;
+ /* name of memcg for display purposes only */
+ charname[MEM_CGROUP_STORE_NAME_LEN];
+
/* set when res.limit == memsw.limit */
boolmemsw_is_minimum;
@@ -1538,27 +1543,22 @@ static void move_unlock_mem_cgroup(struct mem_cgroup
*memcg,
*/
void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct *p)
{
+ struct mem_cgroup *task_memcg;
+ struct mem_cgroup *iter;
struct cgroup *task_cgrp;
struct cgroup *mem_cgrp;
- /*
-* Need a buffer in BSS, can't rely on allocations. The code relies
-* on the assumption that OOM is serialized for memory controller.
-* If this assumption is broken, revisit this code.
-*/
- static char memcg_name[PATH_MAX];
int ret;
- struct mem_cgroup *iter;
unsigned int i;
if (!p)
return;
rcu_read_lock();
-
- mem_cgrp = memcg->css.cgroup;
+ task_memcg = mem_cgroup_from_task(p);
task_cgrp = task_cgroup(p, mem_cgroup_subsys_id);
+ mem_cgrp = memcg->css.cgroup;
- ret = cgroup_path(task_cgrp, memcg_name, PATH_MAX);
+ ret = cgroup_path(task_cgrp, task_memcg->name,
MEM_CGROUP_STORE_NAME_LEN);
if (ret < 0) {
/*
* Unfortunately, we are unable to convert to a useful name
@@ -1567,24 +1567,20 @@ void mem_cgroup_print_oom_info(struct mem_cgroup
*memcg, struct task_struct *p)
rcu_read_unlock();
goto done;
}
- rcu_read_unlock();
- pr_info("Task in %s killed", memcg_name);
+ if (task_memcg != memcg) {
+ ret = cgroup_path(mem_cgrp, memcg->name,
MEM_CGROUP_STORE_NAME_LEN);
+ if (ret < 0) {
+ rcu_read_unlock();
+ goto done;
+ }
+ } else
+ strncpy(memcg->name, task_memcg->name,
MEM_CGROUP_STORE_NAME_LEN);
- rcu_read_lock();
- ret = cgroup_path(mem_cgrp, memcg_name, PATH_MAX);
- if (ret < 0) {
- rcu_read_unlock();
- goto done;
- }
+ pr_info("Task in %s killed as a result of limit of %s\n",
+ task_memcg->name, memcg->name);
rcu_read_unlock();
-
- /*
-* Continues from above, so we don't need an KERN_ level
-*/
- pr_cont(" as a result of limit of %s\n", memcg_name);
done:
-
pr_info("memory: usage %llukB, limit %llukB, failcnt %llu\n",
res_counter_read_u64(&memcg->res, RES_USAGE) >> 10,
res_counter_read_u64(&memcg->res, RES_LIMIT) >> 10,
@@ -1602,9 +1598,10 @@ done:
pr_info("Memory cgroup stats");
rcu_read_lock();
- ret = cgroup_path(iter->css.cgroup, memcg_name, PATH_MAX);
+ ret = cgroup_path(iter->css.cgroup, iter->name,
+ MEM_CGROUP_STORE_NAME_LEN);
if (!ret)
- pr_cont(" for %s", memcg_name);
+ pr_cont(" for %s", iter->name);
rcu_read_unlock();
pr_cont(":");
--
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] hpet, allow user controlled mmap for user processes
On Fri, Mar 22, 2013 at 09:32:54AM -0400, Prarit Bhargava wrote: > The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET > registers to userspace. The Kconfig help points out that in some cases this > can be a security risk as some systems may erroneously configure the map such > that additional data is exposed to userspace. > > This is a problem for distributions -- some users want the MMAP functionality > but it comes with a significant security risk. In an effort to mitigate this > risk, and due to the low number of users of the MMAP functionality, I've > introduced a kernel parameter, hpet_mmap_enable, that is required in order > to actually have the HPET MMAP exposed. > > [v2]: Clemens suggested modifying the Kconfig help text and making the > default setting configurable. > [v3]: Fixed up Documentation and Kconfig entries, default now "Y" > [v4]: After testing, found that I need to modify CONFIG_HPET_MMAP_DEFAULT > usage > > Signed-off-by: Prarit Bhargava > Cc: Clemens Ladisch > --- > Documentation/kernel-parameters.txt |4 > drivers/char/Kconfig|9 +++-- > drivers/char/hpet.c | 25 +++-- > 3 files changed, 34 insertions(+), 4 deletions(-) It doesn't seem like this patch got picked up and seems like a good idea to me. Clemens, what do you think? Acked-by: Matt Wilson --msw -- 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] ARC: Fix __udelay parentheses
On Thu, 2013-08-29 at 05:55 +, Vineet Gupta wrote: > The intent of writing orig code was to generate only 1 MPYHU insn (32*32 = > high-part-64) for the whole math, at any optimization level whatsoever. If the > first MPY is overflowing, u r likely spinning for > 10,000 usec (10ms) which > is 1 > scheduling tick on ARC - not good - presumably for hardware debug. It would be > better to use a tight loop there and throw it out later. It's a delay loop. Does it matter whether or not a multiply or division is used? -- 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 v4 1/10] mm/hwpoison: fix lose PG_dirty flag for errors on mlocked pages
I did a quick read and the patches look all good to me (except the one just moving code around -- seems pointless, forward declarations are totally fine) Acked-by: Andi Kleen -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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] ARC: Fix __udelay parentheses
On 08/29/2013 12:00 AM, Mischa Jonker wrote: > Make sure that usecs is casted to long long, to ensure that the > (usecs * 4295 * HZ) multiplication is 64 bit. > > Initially, the (usecs * 4295 * HZ) part was done as a 32 bit > multiplication, with the result casted to 64 bit. This led to some bits > falling off. > > Signed-off-by: Mischa Jonker > --- > arch/arc/include/asm/delay.h |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arc/include/asm/delay.h b/arch/arc/include/asm/delay.h > index 442ce5d..8d35fe1 100644 > --- a/arch/arc/include/asm/delay.h > +++ b/arch/arc/include/asm/delay.h > @@ -56,8 +56,8 @@ static inline void __udelay(unsigned long usecs) > /* (long long) cast ensures 64 bit MPY - real or emulated >* HZ * 4295 is pre-evaluated by gcc - hence only 2 mpy ops >*/ > - loops = ((long long)(usecs * 4295 * HZ) * > - (long long)(loops_per_jiffy)) >> 32; > + loops = (((long long) usecs) * 4295 * HZ * > + (long long) loops_per_jiffy) >> 32; > > __delay(loops); > } The intent of writing orig code was to generate only 1 MPYHU insn (32*32 = high-part-64) for the whole math, at any optimization level whatsoever. If the first MPY is overflowing, u r likely spinning for > 10,000 usec (10ms) which is 1 scheduling tick on ARC - not good - presumably for hardware debug. It would be better to use a tight loop there and throw it out later. The API abuse would only be caught for const @usecs case. Maybe we need to add a WARN_ON() there. OTOH, if we really want to fix this, it would be cleaner to rewrite this as loops = ((u64)usecs * 4295 * HZ * loops_per_jiffy) >> 32; Since one factor is upcasted, all are promoted to 64 bit. And we leave the optimizations to whims of gcc. @Joern, I would assume that long long vs u64 (or unsigned long long) doesn't matter in this particular case. -Vineet -- 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] kernel/padata.c: share code between CPU_ONLINE and CPU_DOWN_FAILED, same to CPU_DOWN_PREPARE and CPU_UP_CANCELED
On 08/29/2013 12:42 PM, Herbert Xu wrote: > On Fri, Aug 23, 2013 at 12:44:48PM +0200, Steffen Klassert wrote: >> On Thu, Aug 22, 2013 at 02:43:37PM +0800, Chen Gang wrote: >>> Share code between CPU_ONLINE and CPU_DOWN_FAILED, same to >>> CPU_DOWN_PREPARE and CPU_UP_CANCELED. >>> >>> It will fix 2 bugs: >>> >>> "not check the return value of __padata_remove_cpu() and >>> __padata_add_cpu()". >>> "need add 'break' between CPU_UP_CANCELED and CPU_DOWN_FAILED". >>> >>> >>> Signed-off-by: Chen Gang >> >> This looks ok to me, Herbert can you take this one? >> >> Acked-by: Steffen Klassert > > Patch applied. Thanks! > Thank you too. -- Chen Gang -- 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/1 v1.1] arcmsr: Support Areca new SATA Raid Adapter ARC1214/1224/1264/1284 (Resend renew)
On Thu, 2013-08-29 at 12:55 +0800, 黃清隆 wrote: > Update the patch code. This patch is whitespace damaged. Please send the email to yourself and make sure it applies correctly before resending to the lists. If necessary, read Documentation/email-clients.txt cheers, Joe -- 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 v2] h8300/kernel/timer/timer8.c: add the missing semicolon
Add the missing semicolon to fix the typo issue. The related error: (defconfig for H8S): arch/h8300/kernel/timer/timer8.c: In function 'h8300_timer_setup': arch/h8300/kernel/timer/timer8.c:98:2: error: expected ';' before 'ctrl_outw' Signed-off-by: Chen Gang --- arch/h8300/kernel/timer/timer8.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/h8300/kernel/timer/timer8.c b/arch/h8300/kernel/timer/timer8.c index 505f341..8aac2a7 100644 --- a/arch/h8300/kernel/timer/timer8.c +++ b/arch/h8300/kernel/timer/timer8.c @@ -91,7 +91,7 @@ void __init h8300_timer_setup(void) #if defined(CONFIG_CPU_H8S) /* Timer module enable */ - ctrl_bclr(0, MSTPCRL) + ctrl_bclr(0, MSTPCRL); #endif /* initialize timer */ -- 1.7.7.6 -- 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 v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Wed, 2013-08-28 at 18:40 -0700, Linus Torvalds wrote: > Just FYI: I've merged two preparatory patches in my tree for the whole > lockref thing. Instead of applying your four patches as-is during the > merge window, I ended up writing two patches that introduce the > concept and use it in the dentry code *without* introducing any of the > new semantics yet. > > Waiman, I attributed the patches to you, even if they don't actually > look much like any of the patches you sent out. And because I was > trying very hard to make sure that no actual semantics changed, my > version doesn't have the dget_parent() lockless update code, for > example. I literally just did a search-and-replace of "->d_count" with > "->d_lockref.count" and then I fixed up a few things by hand (undid > one replacement in a comment, and used the helper functions where they > were semantically identical). > > You don't have to rewrite your patches if you don't want to, I'm > planning on cherry-picking the actual code changes during the merge > window. I've somewhat lost track of this, will I need some arch support for powerpc ? Cheers, Ben. -- 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] h8300/kernel/timer/timer8.c: add the missing semicolon
On 08/29/2013 11:51 AM, Chen Gang wrote: > Add the missing semicolon to fix the typo issue. > > The related error: (defconfig for H8S): > > arch/h8300/kernel/timer/timer8.c: In function 'h8300_timer_setup': > arch/h8300/kernel/timer/timer8.c:98:2: error: expected ';' before > 'ctrl_outw' > > Signed-off-by: Chen Gang > --- > arch/h8300/Makefile |2 +- > arch/h8300/kernel/timer/timer8.c |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile > index a556447..d2ba710 100644 > --- a/arch/h8300/Makefile > +++ b/arch/h8300/Makefile > @@ -25,7 +25,7 @@ model-$(CONFIG_RAMKERNEL) := ram > model-$(CONFIG_ROMKERNEL):= rom > MODEL := $(model-y) > > -cflags-$(CONFIG_CPU_H8300H) := -mh > +cflags-$(CONFIG_CPU_H8300H) := -mh -mcpu=h8300h Oh, sorry, it contents some waste things, I should send patch v2. > ldflags-$(CONFIG_CPU_H8300H) := -mh8300helf > cflags-$(CONFIG_CPU_H8S) := -ms > ldflags-$(CONFIG_CPU_H8S):= -mh8300self > diff --git a/arch/h8300/kernel/timer/timer8.c > b/arch/h8300/kernel/timer/timer8.c > index 505f341..8aac2a7 100644 > --- a/arch/h8300/kernel/timer/timer8.c > +++ b/arch/h8300/kernel/timer/timer8.c > @@ -91,7 +91,7 @@ void __init h8300_timer_setup(void) > > #if defined(CONFIG_CPU_H8S) > /* Timer module enable */ > - ctrl_bclr(0, MSTPCRL) > + ctrl_bclr(0, MSTPCRL); > #endif > > /* initialize timer */ > -- Chen Gang -- 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] kernel/padata.c: Register hotcpu notifier after initialization
On Tue, Aug 27, 2013 at 11:30:41AM +0200, Steffen Klassert wrote: > On Fri, Aug 23, 2013 at 01:12:33PM +0200, Richard Weinberger wrote: > > padata_cpu_callback() takes pinst->lock, to avoid taking > > an uninitialized lock, register the notifier after it's > > initialization. > > > > Signed-off-by: Richard Weinberger > > Looks ok, > > Acked-by: Steffen Klassert Also applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] kernel/padata.c: share code between CPU_ONLINE and CPU_DOWN_FAILED, same to CPU_DOWN_PREPARE and CPU_UP_CANCELED
On Fri, Aug 23, 2013 at 12:44:48PM +0200, Steffen Klassert wrote: > On Thu, Aug 22, 2013 at 02:43:37PM +0800, Chen Gang wrote: > > Share code between CPU_ONLINE and CPU_DOWN_FAILED, same to > > CPU_DOWN_PREPARE and CPU_UP_CANCELED. > > > > It will fix 2 bugs: > > > > "not check the return value of __padata_remove_cpu() and > > __padata_add_cpu()". > > "need add 'break' between CPU_UP_CANCELED and CPU_DOWN_FAILED". > > > > > > Signed-off-by: Chen Gang > > This looks ok to me, Herbert can you take this one? > > Acked-by: Steffen Klassert Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] PCI: exynos: add support for MSI
On Thursday, August 29, 2013 12:45 PM, Pratyush Anand wrote: > On Wed, Aug 28, 2013 at 04:17:24PM +0800, Jingoo Han wrote: > > On Friday, August 23, 2013 5:36 PM, Pratyush Anand wrote: > > > On Fri, Aug 23, 2013 at 02:04:20PM +0800, Jingoo Han wrote: > > > > [...] > > > > #define MAX_PCIE_PORT_SUPPORTED 3 > > > static DECLARE_BITMAP(msi_irq_in_use[MAX_PCIE_PORT_SUPPORTED], > > > NUM_MSI_IRQS); > > > static unsigned int *msi_data[MAX_PCIE_PORT_SUPPORTED]; > > > > No, there is no need to do it. > > Without this, we can use 3 RCs by adding a node of 3rd RC to dt file. > > > > Yes, you can use RCs by adding nodes to dt file. But you will need one > msi_irq_in_use and one msi_data per RC (ie per port in this driver), isn't it? Aha, you're right. A few minutes ago, I found the same value of msi_data is used for 2 different RCs. It is my fault. As you mentioned, one msi_data per RC should be used. I will modify it in order to use one msi_data per RC. Thank you for your kind description. :-) Best regards, Jingoo Han -- 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 03/10] crypto: nx - fix limits to sg lists for AES-CBC
On Fri, Aug 23, 2013 at 05:01:07PM -0300, Marcelo Cerri wrote: > This patch updates the nx-aes-cbc implementation to perform several > hyper calls if needed in order to always respect the length limits for > scatter/gather lists. > > Two different limits are considered: > > - "ibm,max-sg-len": maximum number of bytes of each scatter/gather >list. > > - "ibm,max-sync-cop": > - The total number of bytes that a scatter/gather list can hold. > - The maximum number of elements that a scatter/gather list can have. > > Reviewed-by: Joy Latten > Signed-off-by: Marcelo Cerri This patch does not apply against the current cryptodev tree. Please regenerate your pathces. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/3] perf trace: Add option to analyze events in a file versus live - v2
Allows capture of raw_syscall:* events and analyzed at a later
time.
v2: change -i option from inherit to input name for consistency with
other perf commands
Signed-off-by: David Ahern
Cc: Adrian Hunter
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
---
tools/perf/Documentation/perf-trace.txt |4 ++
tools/perf/builtin-trace.c | 98 ++-
2 files changed, 100 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-trace.txt
b/tools/perf/Documentation/perf-trace.txt
index fe19811..daccd2c 100644
--- a/tools/perf/Documentation/perf-trace.txt
+++ b/tools/perf/Documentation/perf-trace.txt
@@ -74,6 +74,10 @@ the thread executes on the designated CPUs. Default is to
monitor all CPUs.
--sched:
Accrue thread runtime and provide a summary at the end of the session.
+-i
+--input
+ Process events from a given perf data file.
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-script[1]
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index b72afc7..a03c777 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -4,6 +4,7 @@
#include "util/debug.h"
#include "util/evlist.h"
#include "util/machine.h"
+#include "util/session.h"
#include "util/thread.h"
#include "util/parse-options.h"
#include "util/strlist.h"
@@ -648,6 +649,36 @@ out_dump:
return 0;
}
+static int trace__process_sample(struct perf_tool *tool,
+union perf_event *event __maybe_unused,
+struct perf_sample *sample,
+struct perf_evsel *evsel,
+struct machine *machine __maybe_unused)
+{
+ struct trace *trace = container_of(tool, struct trace, tool);
+ int err = 0;
+
+ tracepoint_handler handler = evsel->handler.func;
+
+ if (trace->base_time == 0)
+ trace->base_time = sample->time;
+
+ if (handler)
+ handler(trace, evsel, sample);
+
+ return err;
+}
+
+static bool
+perf_session__has_tp(struct perf_session *session, const char *name)
+{
+ struct perf_evsel *evsel;
+
+ evsel = perf_evlist__find_tracepoint_by_name(session->evlist, name);
+
+ return evsel != NULL;
+}
+
static int trace__run(struct trace *trace, int argc, const char **argv)
{
struct perf_evlist *evlist = perf_evlist__new();
@@ -787,6 +818,65 @@ out:
return err;
}
+static int trace__replay(struct trace *trace)
+{
+ const struct perf_evsel_str_handler handlers[] = {
+ { "raw_syscalls:sys_enter", trace__sys_enter, },
+ { "raw_syscalls:sys_exit", trace__sys_exit, },
+ };
+
+ struct perf_session *session;
+ int err = -1;
+
+ trace->tool.sample= trace__process_sample;
+ trace->tool.mmap = perf_event__process_mmap;
+ trace->tool.comm = perf_event__process_comm;
+ trace->tool.exit = perf_event__process_exit;
+ trace->tool.fork = perf_event__process_fork;
+ trace->tool.attr = perf_event__process_attr;
+ trace->tool.tracing_data = perf_event__process_tracing_data;
+ trace->tool.build_id = perf_event__process_build_id;
+
+ trace->tool.ordered_samples = true;
+ trace->tool.ordering_requires_timestamps = true;
+
+ /* add tid to output */
+ trace->multiple_threads = true;
+
+ if (symbol__init() < 0)
+ return -1;
+
+ session = perf_session__new(input_name, O_RDONLY, 0, false,
+ &trace->tool);
+ if (session == NULL)
+ return -ENOMEM;
+
+ err = perf_session__set_tracepoints_handlers(session, handlers);
+ if (err)
+ goto out;
+
+ if (!perf_session__has_tp(session, "raw_syscalls:sys_enter")) {
+ pr_err("Data file does not have raw_syscalls:sys_enter
events\n");
+ goto out;
+ }
+
+ if (!perf_session__has_tp(session, "raw_syscalls:sys_exit")) {
+ pr_err("Data file does not have raw_syscalls:sys_exit
events\n");
+ goto out;
+ }
+
+ setup_pager();
+
+ err = perf_session__process_events(session, &trace->tool);
+ if (err)
+ pr_err("Failed to process events, error %d", err);
+
+out:
+ perf_session__delete(session);
+
+ return err;
+}
+
static size_t trace__fprintf_threads_header(FILE *fp)
{
size_t printed;
@@ -888,6 +978,7 @@ int cmd_trace(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_STRING('e', "expr", &ev_qualifier_str, "expr",
"list of events to trace"),
OPT_STRING('o', "output", &output_name, "file", "output file name"),
+ OPT_STRING('i', "input", &input_name, "file", "Analyze events in file"),
[PATCH 3/3] perf trace: Honor target pid / tid options when analyzing a file
Allows capture of raw_syscall events for all processes or threads in a task
and then analyzing specific ones.
Signed-off-by: David Ahern
Cc: Adrian Hunter
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
---
tools/perf/builtin-trace.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index a03c777..ec0c7b3 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -8,6 +8,7 @@
#include "util/thread.h"
#include "util/parse-options.h"
#include "util/strlist.h"
+#include "util/intlist.h"
#include "util/thread_map.h"
#include
@@ -259,6 +260,8 @@ struct trace {
unsigned long nr_events;
struct strlist *ev_qualifier;
boolnot_ev_qualifier;
+ struct intlist *tid_list;
+ struct intlist *pid_list;
boolsched;
boolmultiple_threads;
double duration_filter;
@@ -649,6 +652,18 @@ out_dump:
return 0;
}
+static bool skip_sample(struct trace *trace, struct perf_sample *sample)
+{
+ if ((trace->pid_list && intlist__find(trace->pid_list, sample->pid)) ||
+ (trace->tid_list && intlist__find(trace->tid_list, sample->tid)))
+ return false;
+
+ if (trace->pid_list || trace->tid_list)
+ return true;
+
+ return false;
+}
+
static int trace__process_sample(struct perf_tool *tool,
union perf_event *event __maybe_unused,
struct perf_sample *sample,
@@ -660,6 +675,9 @@ static int trace__process_sample(struct perf_tool *tool,
tracepoint_handler handler = evsel->handler.func;
+ if (skip_sample(trace, sample))
+ return 0;
+
if (trace->base_time == 0)
trace->base_time = sample->time;
@@ -679,6 +697,27 @@ perf_session__has_tp(struct perf_session *session, const
char *name)
return evsel != NULL;
}
+static int parse_target_str(struct trace *trace)
+{
+ if (trace->opts.target.pid) {
+ trace->pid_list = intlist__new(trace->opts.target.pid);
+ if (trace->pid_list == NULL) {
+ pr_err("Error parsing process id string\n");
+ return -EINVAL;
+ }
+ }
+
+ if (trace->opts.target.tid) {
+ trace->tid_list = intlist__new(trace->opts.target.tid);
+ if (trace->tid_list == NULL) {
+ pr_err("Error parsing thread id string\n");
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
static int trace__run(struct trace *trace, int argc, const char **argv)
{
struct perf_evlist *evlist = perf_evlist__new();
@@ -865,6 +904,10 @@ static int trace__replay(struct trace *trace)
goto out;
}
+ err = parse_target_str(trace);
+ if (err != 0)
+ goto out;
+
setup_pager();
err = perf_session__process_events(session, &trace->tool);
--
1.7.10.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 1/3] perf evlist: Add tracepoint lookup by name
Will be used by upcoming perf-trace replay option.
Signed-off-by: David Ahern
Cc: Adrian Hunter
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
---
tools/perf/util/evlist.c | 15 +++
tools/perf/util/evlist.h |4
2 files changed, 19 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 1f5105a..c0e43ee 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -210,6 +210,21 @@ perf_evlist__find_tracepoint_by_id(struct perf_evlist
*evlist, int id)
return NULL;
}
+struct perf_evsel *
+perf_evlist__find_tracepoint_by_name(struct perf_evlist *evlist,
+const char *name)
+{
+ struct perf_evsel *evsel;
+
+ list_for_each_entry(evsel, &evlist->entries, node) {
+ if ((evsel->attr.type == PERF_TYPE_TRACEPOINT) &&
+ (strcmp(evsel->name, name) == 0))
+ return evsel;
+ }
+
+ return NULL;
+}
+
int perf_evlist__add_newtp(struct perf_evlist *evlist,
const char *sys, const char *name, void *handler)
{
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 327abab..8a509e2 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -71,6 +71,10 @@ int perf_evlist__set_filter(struct perf_evlist *evlist,
const char *filter);
struct perf_evsel *
perf_evlist__find_tracepoint_by_id(struct perf_evlist *evlist, int id);
+struct perf_evsel *
+perf_evlist__find_tracepoint_by_name(struct perf_evlist *evlist,
+const char *name);
+
void perf_evlist__id_add(struct perf_evlist *evlist, struct perf_evsel *evsel,
int cpu, int thread, u64 id);
--
1.7.10.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/3] perf trace enhancements - v2
Arnaldo: A couple of enhancements to perf-trace: ability to analyze events from a file and when processing a file limit the analysis to a given set of pid and tids. David Ahern (3): perf evlist: Add tracepoint lookup by name perf trace: Add option to analyze events in a file versus live - v2 perf trace: Honor target pid / tid options when analyzing a file tools/perf/Documentation/perf-trace.txt |4 + tools/perf/builtin-trace.c | 141 ++- tools/perf/util/evlist.c| 15 tools/perf/util/evlist.h|4 + 4 files changed, 162 insertions(+), 2 deletions(-) -- 1.7.10.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: [Suggestion] h8300: built-in: about "can not find built-in.o" issue.
After the recent several issue fix patches (include this suggestion), The h8300h with defconfig can pass building completely. And next, I will try to build allmodconfig (finish before 2013-08-31). Thanks. On 08/29/2013 12:23 PM, Chen Gang wrote: > Hello Maintainers: > > When build h8300h with defconfig, an 'built-in' issue occurs. I can add > an dummy file and let "obj-y := dummy.o" to fix this issue, I am sure > it is correct, but it seems not 'standard'. > > So welcome any additional suggestions or completions, thanks. > > The related information (with defconfig for h8300h): > > /usr/local/bin/h8300-gchen-elf-ld -mh8300helf -r -o vmlinux.o > arch/h8300/platform/h8300h/generic/crt0_ram.o init/built-in.o --start-group > usr/built-in.o arch/h8300/kernel/built-in.o arch/h8300/mm/built-in.o > arch/h8300/platform/h8300h/built-in.o > arch/h8300/platform/h8300h/generic/built-in.o kernel/built-in.o mm/built-in.o > fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o > block/built-in.o lib/lib.a arch/h8300/lib/lib.a > /usr/local/lib/gcc/h8300-gchen-elf/4.7.4/h8300h/int32/libgcc.a lib/built-in.o > arch/h8300/lib/built-in.o > /usr/local/lib/gcc/h8300-gchen-elf/4.7.4/h8300h/int32/libgcc.a > drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o > --end-group > /usr/local/bin/h8300-gchen-elf-ld: cannot find > arch/h8300/platform/h8300h/generic/built-in.o: No such file or directory > make: *** [vmlinux] Error 1 > > > Thanks. > -- > Chen Gang. > -- Chen Gang -- 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/
[Suggestion] h8300: built-in: about "can not find built-in.o" issue.
Hello Maintainers: When build h8300h with defconfig, an 'built-in' issue occurs. I can add an dummy file and let "obj-y := dummy.o" to fix this issue, I am sure it is correct, but it seems not 'standard'. So welcome any additional suggestions or completions, thanks. The related information (with defconfig for h8300h): /usr/local/bin/h8300-gchen-elf-ld -mh8300helf -r -o vmlinux.o arch/h8300/platform/h8300h/generic/crt0_ram.o init/built-in.o --start-group usr/built-in.o arch/h8300/kernel/built-in.o arch/h8300/mm/built-in.o arch/h8300/platform/h8300h/built-in.o arch/h8300/platform/h8300h/generic/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/h8300/lib/lib.a /usr/local/lib/gcc/h8300-gchen-elf/4.7.4/h8300h/int32/libgcc.a lib/built-in.o arch/h8300/lib/built-in.o /usr/local/lib/gcc/h8300-gchen-elf/4.7.4/h8300h/int32/libgcc.a drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o --end-group /usr/local/bin/h8300-gchen-elf-ld: cannot find arch/h8300/platform/h8300h/generic/built-in.o: No such file or directory make: *** [vmlinux] Error 1 Thanks. -- Chen Gang. -- 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] cpufreq: Don't use smp_processor_id() in preemptible context
On 29 August 2013 02:54, Stephen Boyd wrote: > Workqueues are preemptible even if works are queued on them with > queue_work_on(). Let's use raw_smp_processor_id() here to silence > the warning. > > BUG: using smp_processor_id() in preemptible [] code: kworker/3:2/674 > caller is gov_queue_work+0x28/0xb0 > CPU: 0 PID: 674 Comm: kworker/3:2 Tainted: GW3.10.0 #30 > Workqueue: events od_dbs_timer > [] (unwind_backtrace+0x0/0x11c) from [] > (show_stack+0x10/0x14) > [] (show_stack+0x10/0x14) from [] > (debug_smp_processor_id+0xbc/0xf0) > [] (debug_smp_processor_id+0xbc/0xf0) from [] > (gov_queue_work+0x28/0xb0) > [] (gov_queue_work+0x28/0xb0) from [] > (od_dbs_timer+0x108/0x134) > [] (od_dbs_timer+0x108/0x134) from [] > (process_one_work+0x25c/0x444) > [] (process_one_work+0x25c/0x444) from [] > (worker_thread+0x200/0x344) > [] (worker_thread+0x200/0x344) from [] (kthread+0xa0/0xb0) > [] (kthread+0xa0/0xb0) from [] (ret_from_fork+0x14/0x3c) > > Signed-off-by: Stephen Boyd > --- > drivers/cpufreq/cpufreq_governor.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Acked-by: Viresh Kumar -- 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] arch/h8300/kernel/setup.c: implement default 'screen_info'
Need implement default 'screen_info' just like another architectures (tile, cris, score, sh), or can not pass compiling for defconfig: The related error: drivers/video/console/vgacon.c:820: undefined reference to `screen_info' drivers/video/console/vgacon.c:840: undefined reference to `screen_info' drivers/built-in.o: In function `vgacon_init': drivers/video/console/vgacon.c:589: undefined reference to `screen_info' drivers/built-in.o: In function `vgacon_startup': drivers/video/console/vgacon.c:375: undefined reference to `screen_info' drivers/video/console/vgacon.c:387: undefined reference to `screen_info' drivers/built-in.o:/root/linux-next/drivers/video/console/vgacon.c:388: more undefined references to `screen_info' follow Signed-off-by: Chen Gang --- arch/h8300/kernel/setup.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c index d0b1607..488b94c 100644 --- a/arch/h8300/kernel/setup.c +++ b/arch/h8300/kernel/setup.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include @@ -49,6 +50,10 @@ #define STUBSIZE 0xc000 +#ifdef CONFIG_VT +struct screen_info screen_info; +#endif + unsigned long rom_length; unsigned long memory_start; unsigned long memory_end; -- 1.7.7.6 -- 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] mm/sparse: introduce alloc_usemap_and_memmap
On Wed, Aug 28, 2013 at 7:51 PM, Wanpeng Li wrote: > Hi Yinghai, >>> looks like that is what is your first version did. >>> >>> I updated it a little bit. please check it. >>> >> >>removed more lines. > > Thanks for your great work! > > The fixed patch looks good to me. If this is the last fix and I can > ignore http://marc.info/?l=linux-mm&m=137774271220239&w=2? Yes, you can ignore that. Yinghai -- 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 drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/drm_crtc.c between commit b21e3afe2357 ("drm: use ida to
allocate connector ids") from the drm tree and commit 88cd8b8b1503 ("drm:
add MIPI DSI encoder and connector types") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/drm_crtc.c
index 54b4169,190827d..000
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@@ -186,22 -193,23 +186,23 @@@ struct drm_conn_prop_enum_list
* Connector and encoder types.
*/
static struct drm_conn_prop_enum_list drm_connector_enum_list[] =
-{ { DRM_MODE_CONNECTOR_Unknown, "Unknown", 0 },
- { DRM_MODE_CONNECTOR_VGA, "VGA", 0 },
- { DRM_MODE_CONNECTOR_DVII, "DVI-I", 0 },
- { DRM_MODE_CONNECTOR_DVID, "DVI-D", 0 },
- { DRM_MODE_CONNECTOR_DVIA, "DVI-A", 0 },
- { DRM_MODE_CONNECTOR_Composite, "Composite", 0 },
- { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO", 0 },
- { DRM_MODE_CONNECTOR_LVDS, "LVDS", 0 },
- { DRM_MODE_CONNECTOR_Component, "Component", 0 },
- { DRM_MODE_CONNECTOR_9PinDIN, "DIN", 0 },
- { DRM_MODE_CONNECTOR_DisplayPort, "DP", 0 },
- { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A", 0 },
- { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B", 0 },
- { DRM_MODE_CONNECTOR_TV, "TV", 0 },
- { DRM_MODE_CONNECTOR_eDP, "eDP", 0 },
- { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual", 0},
+{ { DRM_MODE_CONNECTOR_Unknown, "Unknown" },
+ { DRM_MODE_CONNECTOR_VGA, "VGA" },
+ { DRM_MODE_CONNECTOR_DVII, "DVI-I" },
+ { DRM_MODE_CONNECTOR_DVID, "DVI-D" },
+ { DRM_MODE_CONNECTOR_DVIA, "DVI-A" },
+ { DRM_MODE_CONNECTOR_Composite, "Composite" },
+ { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO" },
+ { DRM_MODE_CONNECTOR_LVDS, "LVDS" },
+ { DRM_MODE_CONNECTOR_Component, "Component" },
+ { DRM_MODE_CONNECTOR_9PinDIN, "DIN" },
+ { DRM_MODE_CONNECTOR_DisplayPort, "DP" },
+ { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A" },
+ { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
+ { DRM_MODE_CONNECTOR_TV, "TV" },
+ { DRM_MODE_CONNECTOR_eDP, "eDP" },
+ { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
+ { DRM_MODE_CONNECTOR_DSI, "DSI" },
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@@ -211,24 -219,9 +212,25 @@@
{ DRM_MODE_ENCODER_LVDS, "LVDS" },
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
+ { DRM_MODE_ENCODER_DSI, "DSI" },
};
+void drm_connector_ida_init(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(drm_connector_enum_list); i++)
+ ida_init(&drm_connector_enum_list[i].ida);
+}
+
+void drm_connector_ida_destroy(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(drm_connector_enum_list); i++)
+ ida_destroy(&drm_connector_enum_list[i].ida);
+}
+
const char *drm_get_encoder_name(const struct drm_encoder *encoder)
{
static char buf[32];
pgpqQzSvO9J7C.pgp
Description: PGP signature
[PATCH] h8300: kernel: ptrace: remove redundancy default user_disable_single_step()
For platform h8300h and h8s, user_disable_single_step() is already
defined, it is conflict with the default one in h8300.
The public header already defined the default implementation, so in
h8300, need not define the default one.
The related error (defconfig for h8300h):
LD vmlinux.o
arch/h8300/platform/h8300h/built-in.o: In function `user_disable_single_step':
arch/h8300/platform/h8300h/ptrace_h8300h.c:65: multiple definition of
`user_disable_single_step'
arch/h8300/kernel/built-in.o: arch/h8300/kernel/ptrace.c:39: first defined
here
/usr/local/bin/h8300-gchen-elf-ld: Warning: size of symbol
`_user_disable_single_step' changed from 2 in arch/h8300/kernel/built-in.o to
30 in arch/h8300/platform/h8300h/built-in.o
Signed-off-by: Chen Gang
---
arch/h8300/include/asm/ptrace.h |2 ++
arch/h8300/kernel/ptrace.c |5 -
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/h8300/include/asm/ptrace.h b/arch/h8300/include/asm/ptrace.h
index c1826b9..dd887e9 100644
--- a/arch/h8300/include/asm/ptrace.h
+++ b/arch/h8300/include/asm/ptrace.h
@@ -20,7 +20,9 @@
/* Find the stack offset for a register, relative to thread.esp0. */
#define PT_REG(reg)((long)&((struct pt_regs *)0)->reg)
+#if defined(__H8300H__) || defined(__H8300S__)
#define arch_has_single_step() (1)
+#endif
#define user_mode(regs) (!((regs)->ccr & PS_S))
#define instruction_pointer(regs) ((regs)->pc)
diff --git a/arch/h8300/kernel/ptrace.c b/arch/h8300/kernel/ptrace.c
index 748cf65..82ec3b6 100644
--- a/arch/h8300/kernel/ptrace.c
+++ b/arch/h8300/kernel/ptrace.c
@@ -34,11 +34,6 @@
extern long h8300_get_reg(struct task_struct *task, int regno);
extern int h8300_put_reg(struct task_struct *task, int regno, unsigned long
data);
-
-void user_disable_single_step(struct task_struct *child)
-{
-}
-
/*
* does not yet catch signals sent when the child dies.
* in exit.c or in signal.c.
--
1.7.7.6
--
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] h8300/kernel/timer/timer8.c: add the missing semicolon
Add the missing semicolon to fix the typo issue. The related error: (defconfig for H8S): arch/h8300/kernel/timer/timer8.c: In function 'h8300_timer_setup': arch/h8300/kernel/timer/timer8.c:98:2: error: expected ';' before 'ctrl_outw' Signed-off-by: Chen Gang --- arch/h8300/Makefile |2 +- arch/h8300/kernel/timer/timer8.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile index a556447..d2ba710 100644 --- a/arch/h8300/Makefile +++ b/arch/h8300/Makefile @@ -25,7 +25,7 @@ model-$(CONFIG_RAMKERNEL) := ram model-$(CONFIG_ROMKERNEL) := rom MODEL := $(model-y) -cflags-$(CONFIG_CPU_H8300H):= -mh +cflags-$(CONFIG_CPU_H8300H):= -mh -mcpu=h8300h ldflags-$(CONFIG_CPU_H8300H) := -mh8300helf cflags-$(CONFIG_CPU_H8S) := -ms ldflags-$(CONFIG_CPU_H8S) := -mh8300self diff --git a/arch/h8300/kernel/timer/timer8.c b/arch/h8300/kernel/timer/timer8.c index 505f341..8aac2a7 100644 --- a/arch/h8300/kernel/timer/timer8.c +++ b/arch/h8300/kernel/timer/timer8.c @@ -91,7 +91,7 @@ void __init h8300_timer_setup(void) #if defined(CONFIG_CPU_H8S) /* Timer module enable */ - ctrl_bclr(0, MSTPCRL) + ctrl_bclr(0, MSTPCRL); #endif /* initialize timer */ -- 1.7.7.6 -- 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/9] [RFC v2] safely drop directory dentry on failed revalidate
Ian,
I'm having problems fully understanding what autofs4 is trying to do
with have_submounts().
> On Wed, 2013-08-21 at 06:40 +0100, Al Viro wrote:
> fs/autofs4/dev-ioctl.c:542: err = have_submounts(path.dentry);
This is an ioctl() asking whether we have anything mounted on the autofs
mount. Using have_submounts() and then a separate follow_down() looks
racy. have_submounts() could succeed and then follow_down() could fail.
Or the other way round. Shouldn't the two cases be handled separately
here? If the autofs is a just a simple trigger then use follow_down().
If it's a multi-mount thing, then use have_submounts().
What is the userspace automount daemon using this for? Do we really
need the recursive check for submounts?
> fs/autofs4/root.c:381: if (have_submounts(dentry)) {
Here it explicitly says it's for v5 and for rootless mutli-mount. So
for example:
/mnt/auto/root of an indirect mount
/mnt/auto/foo directory with DCACHE_NEED_AUTOMOUNT
/mnt/auto/foo/bar directory without DCACHE_NEED_AUTOMOUNT
/mnt/auto/foo/bar/baz directory with an automount trigger mounted on it
In this case when d_automount for "foo" is called we don't call the
userspace daemon because things are mounted under foo. If there was no
trigger under baz, then we would try to handle "foo" as an indirect
mount and call userspace.
But it's pretty confusing. Do we really *ever* need to call automount
on "foo" if it was part of a multi-mount thing?
> fs/autofs4/waitq.c:338: if (have_submounts(dentry))
And here we re-validate the thing after taking another autofs4 lock.
Why this double checking?
Thanks,
Miklos
--
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] PCI: exynos: add support for MSI
On Wed, Aug 28, 2013 at 04:17:24PM +0800, Jingoo Han wrote: > On Friday, August 23, 2013 5:36 PM, Pratyush Anand wrote: > > On Fri, Aug 23, 2013 at 02:04:20PM +0800, Jingoo Han wrote: > [...] > > #define MAX_PCIE_PORT_SUPPORTED 3 > > static DECLARE_BITMAP(msi_irq_in_use[MAX_PCIE_PORT_SUPPORTED], > > NUM_MSI_IRQS); > > static unsigned int *msi_data[MAX_PCIE_PORT_SUPPORTED]; > > No, there is no need to do it. > Without this, we can use 3 RCs by adding a node of 3rd RC to dt file. > Yes, you can use RCs by adding nodes to dt file. But you will need one msi_irq_in_use and one msi_data per RC (ie per port in this driver), isn't it? Regards Pratyush -- 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: sht15 kernel driver
Thanks Jerome!
That was just what I needed to know.
The device is now set up and is working well - I will have a go at back
porting now.
Many thanks again for your help!
Chris
On 29/08/13 11:08, Jerome Oufella wrote:
Hi,
I am trying to get a sht75 humidity and temperature sensor working
with the linux kernel module in 3.2.
Is there a code example for application code that you have available?
Many thanks,
Hi Chris,
There was much less support for the sht15 back in 3.2 compared to recent
kernel releases. You may want to backport features and/or fixes to suit
your needs.
You can find a usage example for 3.2 in arch/arm/mach-pxa/stargate2.c
around line 140:
First, create a platform data struct and specify which GPIO lines are
hooked to the data and sck lines of your sht-15:
static struct sht15_platform_data platform_data_sht15 = {
.gpio_data = 100,
.gpio_sck = 98,
};
Then setup a platform device referencing those platform data, that you
will have to register on the platform bus using platform_add_devices()
or equivalent:
static struct platform_device sht15 = {
.name = "sht15",
.id = -1,
.dev = {
.platform_data = &platform_data_sht15,
},
};
...
platform_add_devices(...);
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: [guv v2 08/31] tracing: Replace __get_cpu_var uses
(2013/08/29 4:48), Steven Rostedt wrote:
> On Mon, 26 Aug 2013 20:44:37 +
> Christoph Lameter wrote:
>
>> __get_cpu_var() is used for multiple purposes in the kernel source. One of
>> them is
>> address calculation via the form &__get_cpu_var(x). This calculates the
>> address for
>> the instance of the percpu variable of the current processor based on an
>> offset.
>>
>> Others usage cases are for storing and retrieving data from the current
>> processors percpu area.
>> __get_cpu_var() can be used as an lvalue when writing data or on the right
>> side of an assignment.
>>
>> __get_cpu_var() is defined as :
>>
>>
>> #define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
>>
>>
>>
>> __get_cpu_var() always only does a address determination. However, store and
>> retrieve operations
>> could use a segment prefix (or global register on other platforms) to avoid
>> the address calculation.
>>
>> this_cpu_write() and this_cpu_read() can directly take an offset into a
>> percpu area and use
>> optimized assembly code to read and write per cpu variables.
>>
>>
>> This patch converts __get_cpu_var into either and explicit address
>> calculation using this_cpu_ptr()
>> or into a use of this_cpu operations that use the offset. Thereby address
>> calcualtions are avoided
>> and less registers are used when code is generated.
>>
>> At the end of the patchset all uses of __get_cpu_var have been removed so
>> the macro is removed too.
>>
>> The patchset includes passes over all arches as well. Once these operations
>> are used throughout then
>> specialized macros can be defined in non -x86 arches as well in order to
>> optimize per cpu access by
>> f.e. using a global register that may be set to the per cpu base.
>
> You should limit the width of the change log to 76 characters.
>
> I fixed it for now.
>
>>
>>
>>
>>
>> Transformations done to __get_cpu_var()
>>
>>
>> 1. Determine the address of the percpu instance of the current processor.
>>
>> DEFINE_PER_CPU(int, y);
>> int *x = &__get_cpu_var(y);
>>
>> Converts to
>>
>> int *x = this_cpu_ptr(&y);
>>
>>
>> 2. Same as #1 but this time an array structure is involved.
>>
>> DEFINE_PER_CPU(int, y[20]);
>> int *x = __get_cpu_var(y);
>>
>> Converts to
>>
>> int *x = this_cpu_ptr(y);
>>
>>
>> 3. Retrieve the content of the current processors instance of a per cpu
>> variable.
>>
>> DEFINE_PER_CPU(int, u);
>> int x = __get_cpu_var(y)
>>
>>Converts to
>>
>> int x = __this_cpu_read(y);
>>
>>
>> 4. Retrieve the content of a percpu struct
>>
>> DEFINE_PER_CPU(struct mystruct, y);
>> struct mystruct x = __get_cpu_var(y);
>>
>>Converts to
>>
>> memcpy(this_cpu_ptr(&y), x, sizeof(x));
>>
>>
>> 5. Assignment to a per cpu variable
>>
>> DEFINE_PER_CPU(int, y)
>> __get_cpu_var(y) = x;
>>
>>Converts to
>>
>> this_cpu_write(y, x);
>>
>>
>> 6. Increment/Decrement etc of a per cpu variable
>>
>> DEFINE_PER_CPU(int, y);
>> __get_cpu_var(y)++
>>
>>Converts to
>>
>> this_cpu_inc(y)
>>
>>
>> Signed-off-by: Christoph Lameter
>>
>> Index: linux/include/linux/kprobes.h
>> ===
>> --- linux.orig/include/linux/kprobes.h 2013-08-26 14:25:53.0
>> -0500
>> +++ linux/include/linux/kprobes.h2013-08-26 14:26:29.460993659 -0500
>> @@ -329,7 +329,7 @@ static inline void reset_current_kprobe(
>>
>> static inline struct kprobe_ctlblk *get_kprobe_ctlblk(void)
>> {
>> -return (&__get_cpu_var(kprobe_ctlblk));
>> +return this_cpu_ptr(&kprobe_ctlblk);
>> }
>
> Masami,
>
> Can you give me an Acked-by: for this.
>
Thanks for pinging me ;)
Acked-by: Masami Hiramatsu
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
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] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}
On Wed, Aug 28, 2013 at 6:08 PM, Eric W. Biederman wrote: > Kees Cook writes: > >> On Wed, Aug 28, 2013 at 5:26 PM, Eric W. Biederman >> wrote: >>> Can someome please state what they are worried about in simple language >>> step by step? >>> [...] >>> The closest I saw in the thread was people were worried about ASLR being >>> defeated. All I see are kernel addresses and we don't have much if any >>> runtime or even load time randomization of where code is located in the >>> kernel address map on x86_64. So I don't understand the concern. >> >> I showed the output of "syscall", since that contains user-space >> addresses and shows a leak of ASLR from a privileged process to an >> unprivileged process. >> >> The flaw as I see it is that an unprivileged process opens >> /proc/$priv_pid/syscall and passes it to a setuid process which is >> able to read it, and provides those contents to the unprivileged >> process. >> >> The unprivileged process should not be able to the open the file in >> the first place. > > I see so the complaint is that we don't give read permission but we do > give open permission.Which is a variant of: the permissions used to > open are not the permission used to access the file. > > This does seem to be a legitimate concern. > > I think there are several discussions that have been going on lately > with respect to this class of problems in proc files. > > Given the existence of suid exec we can not in general prevent this > class of bugs with a check at open time. I'm not suggesting removing the read check -- that's certainly needed. > I believe the solution needs to be to enhance the ptrace_may_access > checks to verify that both the creds of the current task and the creds > of the opening process would have allowed the access. As in, DAC perms are insufficient? > We may want to put this check in permission so open fails quickly but > we absolutely need to put this check in at the time we call > ptrace_may_access. -Kees -- Kees Cook Chrome OS Security -- 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 v4 3/3] dma: Add Freescale eDMA engine driver support
> > + } else {
> since you support cyclic, is there a reasonw why you dont support
> pause/resume?
> is it hw issue or planned in future?
[Lu Jingchang]
The HW supports start/stop request from the peripheral dma request, I had
planned to add this in future as requested.
I will add this in the next version patch.
Thanks.
>
> > + return -EINVAL;
> > + }
> > + return 0;
> > +
> > + default:
> > + return -ENXIO;
> > + }
> > +}
> > +
> > +static enum dma_status fsl_edma_tx_status(struct dma_chan *chan,
> > + dma_cookie_t cookie, struct dma_tx_state *txstate)
> > +{
> > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > +
> > + if (fsl_chan->status == DMA_ERROR)
> > + return DMA_ERROR;
> > +
> > + return dma_cookie_status(chan, cookie, txstate);
> this will tell if the DMA is completed or not only.
> You also need to calculate residue for the pending dma
>
> Since you support cyclic this should be done properly...
>
> also you cna take more help from vchan support to make your life
> simpler...
[Lu Jingchang]
Ok, if it is needed, I will add residue calculation in the next version.
Thanks.
>
[...]
> > +static struct dma_async_tx_descriptor *fsl_edma_prep_dma_cyclic(
> > + struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
> > + size_t period_len, enum dma_transfer_direction direction,
> > + unsigned long flags, void *context)
> > +{
> > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > + struct fsl_edma_desc *fsl_desc;
> > + dma_addr_t dma_buf_next;
> > + int sg_len, i;
> > + u32 src_addr, dst_addr, last_sg, nbytes;
> > + u16 soff, doff, iter;
> > +
> > + if (!fsl_chan->fsc.dir == DMA_MEM_TO_DEV &&
> > + !fsl_chan->fsc.dir == DMA_DEV_TO_MEM)
> > + return NULL;
> you are ignoring the direction arg. Also use is_slave_direction() helper
[...]
> > + if (!fsl_chan->fsc.dir == DMA_MEM_TO_DEV &&
> > + !fsl_chan->fsc.dir == DMA_DEV_TO_MEM)
> > + return NULL;
> ditto
[Lu Jingchang]
Thanks. I will call the helper function instead.
[...]
> > +static bool fsl_edma_filter_fn(struct dma_chan *chan, void *fn_param)
> > +{
> > + struct fsl_edma_filter_param *fparam = fn_param;
> > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > +
> > + if (fsl_chan->edmamux->mux_id != fparam->mux_id)
> > + return false;
> > +
> > + fsl_chan->slot_id = fparam->slot_id;
> > + chan->private = fn_param;
> why do you need to use chan->private?
[Lu Jingchang]
The private used here is to store the slot_id information, which must be used
by the DMAMUX in alloc_chan_resources function. Thanks.
> > + return true;
> > +}
> > +
> > +static struct dma_chan *fsl_edma_xlate(struct of_phandle_args
> *dma_spec,
> > + struct of_dma *ofdma)
> > +{
> > + dma_cap_mask_t mask;
> > + struct fsl_edma_filter_param fparam;
> > +
> > + if (dma_spec->args_count != 2)
> > + return NULL;
> > +
> > + fparam.mux_id = dma_spec->args[0];
> > + fparam.slot_id = dma_spec->args[1];
> > +
> > + dma_cap_zero(mask);
> > + dma_cap_set(DMA_SLAVE, mask);
> > + dma_cap_set(DMA_CYCLIC, mask);
> > + return dma_request_channel(mask, fsl_edma_filter_fn, (void
> *)&fparam);
> > +}
> > +
> > +static int fsl_edma_alloc_chan_resources(struct dma_chan *chan)
> > +{
> > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > + struct fsl_edma_filter_param *data = chan->private;
> > + unsigned char val;
> > +
> > + val = EDMAMUX_CHCFG_ENBL | EDMAMUX_CHCFG_SOURCE(data->slot_id);
> okay, so what does the slot_id mean?
>
[Lu Jingchang]
slot_id is the request source id, a peripheral device ID. Each peripheral using
DMA has a ID that can be identified by the DMA engine. the peripheral ID must
be written to the DMAMUX configuration register to route the peripheral to DMA
engine channel. Thanks.
Best Regards,
Jingchang
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [dm-devel] [RFC] dm-lc: plan to go to staging
On Wed, Aug 28, 2013 at 07:05:55PM -0700, Greg KH wrote: > For staging drivers, I need a TODO file that lists > what needs to be done to the code to get it into a mergable state for > the "real" part of the kernel, Two simple requirements before putting your proof-of-concept into staging if you want to work that way: 1) Drop the major version number to 0. Version 1 is reserved for supported modules. 2) Agree a new and meaningful target name with us so you don't have to change it later. "lc" means nothing, I'm afraid. Then in general terms, you should continue to compare your device-mapper target with the existing targets and where there are differences, either change your target to be like something that already exists, or be ready to explain why that can't or shouldn't be done. In particular, the interface and architecture will need substantial changes and working these out should be your highest priority. For example, you write: Be careful, you MUST create all the LVs as the destinations of the dirty blocks on the cache device before this operation. Otherwise, the kernel may crash. I read a statement like that as an indication of an interface or architectural problem. The device-mapper approach is to 'design out' problems, rather than relying on users not doing bad things. Study the existing interfaces used by other targets to understand some approaches that proved successful, then decide which ones come closest to your needs. (Your code also needs many more comments inline to explain what it does and how it works.) The documentation file will eventually need rewriting to follow the same format as the other targets recently added to the kernel. We document the kernel interface rather than any particular userspace tools, which just have the status of convenient examples. Another little thing I noticed: look into using something like __dm_bless_for_disk() for your metadata and clearly segregate your on-disk structures and document the layout. Alasdair -- 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/1] Squashfs: Optimized uncompressed buffer loop
Manish Sharma wrote:
Merged the two for loops. We might get a little gain by overlapping
wait_on_bh and the memcpy operations.
---
fs/squashfs/block.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
index fb50652..5012f98 100644
--- a/fs/squashfs/block.c
+++ b/fs/squashfs/block.c
@@ -169,12 +169,6 @@ int squashfs_read_data(struct super_block *sb, void
**buffer, u64 index,
*/
int i, in, pg_offset = 0;
- for (i = 0; i < b; i++) {
- wait_on_buffer(bh[i]);
- if (!buffer_uptodate(bh[i]))
- goto block_release;
- }
-
for (bytes = length; k < b; k++) {
in = min(bytes, msblk->devblksize - offset);
bytes -= in;
@@ -185,6 +179,9 @@ int squashfs_read_data(struct super_block *sb, void
**buffer, u64 index,
}
avail = min_t(int, in, PAGE_CACHE_SIZE -
pg_offset);
+ wait_on_buffer(bh[k]);
+ if (!buffer_uptodate(bh[k]))
+ goto block_release;
Two points:
1. I understand what you're trying to do here (merging the two loops
is a good thing), but this patch is in the wrong place. It should be
in the outer loop rather than the inner loop.
The outer loop cycles through the buffer heads, one buffer head per
iteration. The inner loop copies the buffer head to the pages, and
this can loop copying the same buffer head to multiple pages in the
case there's not enough bytes in the page (if you want to know why,
it's because we start off copying from an offset in the first buffer
head).
So it's not a good idea to have the wait_on_buffer() in the inner loop,
as we can unnecessarily call it multiple times on the same buffer head.
The wait_on_buffer() should be in the outer loop where we know it will
only be called once per buffer head.
I have checked the fixed patch into the "tmp" branch on my squashfs-next
repository on git.kernel.org here:
https://git.kernel.org/cgit/linux/kernel/git/pkl/squashfs-next.git/commit/?h=tmp&id=5839f00feea122fb773d8520e5cfb16464fb89d5
diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
index fb50652..63a5ab8d 100644
--- a/fs/squashfs/block.c
+++ b/fs/squashfs/block.c
@@ -169,15 +169,12 @@ int squashfs_read_data(struct super_block *sb, void
**buffer, u64 index,
*/
int i, in, pg_offset = 0;
- for (i = 0; i < b; i++) {
- wait_on_buffer(bh[i]);
- if (!buffer_uptodate(bh[i]))
- goto block_release;
- }
-
for (bytes = length; k < b; k++) {
in = min(bytes, msblk->devblksize - offset);
bytes -= in;
+ wait_on_buffer(bh[k]);
+ if (!buffer_uptodate(bh[k]))
+ goto block_release;
while (in) {
if (pg_offset == PAGE_CACHE_SIZE) {
page++;
Please send a revised v2 patch with this fix. Thanks.
2. Your emailer corrupted the patch ... This is a common occurrence with
modern (wysiwyg) emailers. Please see
https://www.kernel.org/doc/Documentation/email-clients.txt
these days it's probably best to use git send-email.
In case you're curious, this is how the emailer corrupted the patch.
Your patch has
$ cat -vt /tmp/1-1-Squashfs-Optimized-uncompressed-buffer-loop.patch
diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
[SNIP]
@@ -169,12 +169,6 @@ int squashfs_read_data(struct super_block *sb, void
**buffer, u64 index,
^I^I */
^I^Iint i, in, pg_offset = 0;
-^I^Ifor (i = 0; i < b; i++) {
-^I^I^Iwait_on_buffer(bh[i]);
-^I^I^Iif (!buffer_uptodate(bh[i]))
-^I^I^I^Igoto block_release;
-^I^I}
-
^I^Ifor (bytes = length; k < b; k++) {
^I^I^Iin = min(bytes, msblk->devblksize - offset);
^I^I^Ibytes -= in;
[SNIP]
This should have been
@@ -169,12 +169,6 @@ int squashfs_read_data(struct super_block *sb, void
**buffer, u64 index,
^I^I */
^I^Iint i, in, pg_offset = 0;
-^I^Ifor (i = 0; i < b; i++) {
-^I^I^Iwait_on_buffer(bh[i]);
-^I^I^Iif (!buffer_uptodate(bh[i]))
-^I^I^I^Igoto block_release;
-^I^I}
-
^I^Ifor (bytes = length; k < b; k++) {
^I^I^Iin = min(bytes, msblk->devblksize - offset);
^I^I^Ibytes -= in;
where should be read as " ", i.e. it has eliminated the leading
space before the tabs.
Phillip
ps Manish, you will have received an earlier version of this email
sent via gmail (where I received the patch email). Unfortunately Google
has forced everyone onto its new compose, and this appears to now send
html, which fsdevel and lkml sensibly rejected.
--
To un
Re: Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support
Dear David : Thanks a lot. please check the patch. thanks again. 2013-08-29 liujunliang_ljl 发件人： David Miller 发送时间： 2013-08-29 05:44:06 收件人： liujunliang_ljl 抄送： horms; joe; romieu; gregkh; netdev; linux-usb; linux-kernel; sunhecheng 主题： Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support From: liujunliang_...@163.com Date: Sat, 24 Aug 2013 19:26:00 +0800 > From: liujl Your proper name is not "liujl", please put something more reasonable here and also in your Signoff. Also, integrate Joe Perches's white space fixes into this patch as part of your resubmission. Thank you.
[PATCH] USB2NET : SR9700 : One Chip USB 1.1 USB2NET SR9700 Device Driver Support
From: Liu Junliang
Signed-off-by: Liu Junliang
---
drivers/net/usb/Kconfig |8 +
drivers/net/usb/Makefile |1 +
drivers/net/usb/sr9700.c | 558 ++
drivers/net/usb/sr9700.h | 172 ++
4 files changed, 739 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/usb/sr9700.c
create mode 100644 drivers/net/usb/sr9700.h
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 287cc62..a94b196 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -272,6 +272,14 @@ config USB_NET_DM9601
This option adds support for Davicom DM9601 based USB 1.1
10/100 Ethernet adapters.
+config USB_NET_SR9700
+ tristate "CoreChip-sz SR9700 based USB 1.1 10/100 ethernet devices"
+ depends on USB_USBNET
+ select CRC32
+ help
+ This option adds support for CoreChip-sz SR9700 based USB 1.1
+ 10/100 Ethernet adapters.
+
config USB_NET_SMSC75XX
tristate "SMSC LAN75XX based USB 2.0 gigabit ethernet devices"
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 9ab5c9d..bba87a2 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o
obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o
obj-$(CONFIG_USB_NET_DM9601) += dm9601.o
+obj-$(CONFIG_USB_NET_SR9700) += sr9700.o
obj-$(CONFIG_USB_NET_SMSC75XX) += smsc75xx.o
obj-$(CONFIG_USB_NET_SMSC95XX) += smsc95xx.o
obj-$(CONFIG_USB_NET_GL620A) += gl620a.o
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
new file mode 100644
index 000..76e11f5
--- /dev/null
+++ b/drivers/net/usb/sr9700.c
@@ -0,0 +1,558 @@
+/*
+ * CoreChip-sz SR9700 one chip USB 1.1 Ethernet Devices
+ *
+ * Author : Liu Junliang
+ *
+ * Based on dm9601.c
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sr9700.h"
+
+static int sr_read(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+ int err;
+
+ err = usbnet_read_cmd(dev, SR_RD_REGS, SR_REQ_RD_REG,
+ 0, reg, data, length);
+ if ((err != length) && (err >= 0))
+ err = -EINVAL;
+ return err;
+}
+
+static int sr_write(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+ int err;
+
+ err = usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
+ 0, reg, data, length);
+ if ((err >= 0) && (err < length))
+ err = -EINVAL;
+ return err;
+}
+
+static int sr_read_reg(struct usbnet *dev, u8 reg, u8 *value)
+{
+ return sr_read(dev, reg, 1, value);
+}
+
+static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value)
+{
+ return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
+ value, reg, NULL, 0);
+}
+
+static void sr_write_async(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+ usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
+ 0, reg, data, length);
+}
+
+static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
+{
+ usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
+ value, reg, NULL, 0);
+}
+
+static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
+{
+ int i, ret;
+
+ ret = 0;
+ for (i = 0; i < SR_SHARE_TIMEOUT; i++) {
+ u8 tmp = 0;
+
+ udelay(1);
+ ret = sr_read_reg(dev, EPCR, &tmp);
+ if (ret < 0)
+ goto out;
+
+ /* ready */
+ if ((tmp & EPCR_ERRE) == 0)
+ break;
+ }
+
+ if (i >= SR_SHARE_TIMEOUT) {
+ netdev_err(dev->net, "%s write timed out!\n",
+ phy ? "phy" : "eeprom");
+ ret = -EIO;
+ goto out;
+ }
+
+out:
+ return ret;
+}
+
+static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg,
+ __le16 *value)
+{
+ int ret;
+
+ mutex_lock(&dev->phy_mutex);
+
+ sr_write_reg(dev, EPAR, phy ? (reg | 0x40) : reg);
+ sr_write_reg(dev, EPCR, phy ? 0xc : 0x4);
+
+ ret = wait_phy_eeprom_ready(dev, phy);
+ if (ret < 0)
+ goto out;
+
+ sr_write_reg(dev, EPCR, 0x0);
+ ret = sr_read(dev, EPDR, 2, value);
+
+ netdev_dbg(dev->net, "read shared %d 0x%02x returned 0x%04x, %d\n",
+ phy, reg, *value, ret);
+
+out:
+ mutex_unlock(&dev->phy_mutex);
+ return ret;
+}
+
+static int sr_share_write_word(struct usbnet *
Re: performance drop after using blkcg
Hello,
I also do these tests and find the same results. IMO, on faster storage with
deep queue depth, if device is asking for more requests,but our workload
can't send enough requests, we have to idle to provide service
differentiation. We'll see performance drop if applications can't drive
enough IO to keep disk busy.Especially for writes, with the effect of disk
cache and deep queue depth, we'll often see performance drop .
So I come up with an approach called Self-adaption blkcg that if the
average total service time for a request is much less,we don' choose to
idle. Otherwise, we choose to idle to wait for the request. The patch is
below. After large tests,the new scheduler can provide service
differentiation in most cases. When the application can't drive enough
requests and the mean total service time is very small, we don't choose to
idle. In most cases, the performance doesn't drop after using blkcg and the
service differentiation is good.
>From 50705c8d4e456d3286e76bed7281796b1e915e0e Mon Sep 17 00:00:00 2001
From: Joeytao
Date: Mon, 26 Aug 2013 15:40:39 +0800
Subject: [PATCH] Self-adaption blkcg
---
block/cfq-iosched.c | 41 ++---
include/linux/iocontext.h |5 +
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 23500ac..79296de 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -288,6 +288,8 @@ struct cfq_data {
unsigned int cfq_group_idle;
unsigned int cfq_latency;
+unsigned int cfq_target_latency;
+unsigned int cfq_write_isolation;
unsigned int cic_index;
struct list_head cic_list;
@@ -589,7 +591,7 @@ cfq_group_slice(struct cfq_data *cfqd, struct cfq_group
*cfqg)
{
struct cfq_rb_root *st = &cfqd->grp_service_tree;
- return cfq_target_latency * cfqg->weight / st->total_weight;
+ return cfqd->cfq_target_latency * cfqg->weight / st->total_weight;
}
static inline unsigned
@@ -2028,6 +2031,14 @@ static void cfq_arm_slice_timer(struct cfq_data
*cfqd)
cic->ttime_mean);
return;
}
+
+ /*
+* added by joeytao,
+* If our average await_time is 0, then don't idle. This is for requests
of
+* write,because if the cache of disk is on, it's no need to wait.
+*/
+ if(!cfqd->cfq_write_isolation && sample_valid(cic->awtime_samples) &&
(cic->awtime_mean==0))
+ return;
/* There are other queues in the group, don't do group idle */
if (group_idle && cfqq->cfqg->nr_cfqq > 1)
@@ -2243,7 +2254,7 @@ new_workload:
* to have higher weight. A more accurate thing would be to
* calculate system wide asnc/sync ratio.
*/
- tmp = cfq_target_latency * cfqg_busy_async_queues(cfqd, cfqg);
+ tmp = cfqd->cfq_target_latency * cfqg_busy_async_queues(cfqd,
cfqg);
tmp = tmp/cfqd->busy_queues;
slice = min_t(unsigned, slice, tmp);
@@ -3228,10 +3239,21 @@ err:
}
static void
+cfq_update_io_awaittime(struct cfq_data *cfqd, struct cfq_io_context *cic)
+{
+ unsigned long elapsed = jiffies - cic->last_end_request;
+ unsigned long awtime = min(elapsed, 2UL * 16);
+
+ cic->awtime_samples = (7*cic->awtime_samples + 256) / 8;
+ cic->awtime_total = (7*cic->awtime_total + 256*awtime) / 8;
+ cic->awtime_mean = (cic->awtime_total + 128) / cic->awtime_samples;
+}
+
+static void
cfq_update_io_thinktime(struct cfq_data *cfqd, struct cfq_io_context *cic)
{
unsigned long elapsed = jiffies - cic->last_end_request;
- unsigned long ttime = min(elapsed, 2UL * cfqd->cfq_slice_idle);
+ unsigned long ttime = min(elapsed, 2UL * 8);
cic->ttime_samples = (7*cic->ttime_samples + 256) / 8;
cic->ttime_total = (7*cic->ttime_total + 256*ttime) / 8;
@@ -3573,6 +3595,7 @@ static void cfq_completed_request(struct request_queue
*q, struct request *rq)
cfqd->rq_in_flight[cfq_cfqq_sync(cfqq)]--;
if (sync) {
+ cfq_update_io_awaittime(cfqd,RQ_CIC(rq)); /* added by joeytao,
2013.8.27*/
RQ_CIC(rq)->last_end_request = now;
if (!time_after(rq->start_time + cfqd->cfq_fifo_expire[1], now))
cfqd->last_delayed_sync = now;
@@ -4075,6 +4098,12 @@ static void *cfq_init_queue(struct request_queue *q)
cfqd->cfq_back_penalty = cfq_back_penalty;
cfqd->cfq_slice[0] = cfq_slice_async;
cfqd->cfq_slice[1] = cfq_slice_sync;
+ cfqd->cfq_target_latency = cfq_target_latency; /* added by joeytao,
2013.8.5 */
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
+ cfqd->cfq_write_isolation = 0; /* added by joeytao, 2013.8.16 */
+#else
+ cfqd->cfq_write_isolation = 1; /* added by joeytao, 2013.8.21 */
+#endif
cfqd->cfq_slice_async_rq = cfq_slice_async_rq;
Possible Bcache Bug
Hi Kent, I have configured Bcache as follows: echo /dev/sda3 > /sys/fs/bcache/register echo /dev/sdb1 > /sys/fs/bcache/register echo 5fd1b675-ea67-4039-82f6-caa325d10559 > /sys/block/bcache0/bcache/attach echo 0 > /sys/block/bcache0/bcache/sequential_cutoff echo 0 > /sys/fs/bcache/5fd1b675-ea67-4039-82f6-caa325d10559/congested_read_threshold_us echo 0 > /sys/fs/bcache/5fd1b675-ea67-4039-82f6-caa325d10559/congested_write_threshold_us echo 0 > /sys/fs/bcache/5fd1b675-ea67-4039-82f6-caa325d10559/synchronous echo writeback > /sys/block/bcache0/bcache/cache_mode echo 0 > /sys/block/bcache0/bcache/writeback_running echo 0 > /sys/block/bcache0/bcache/writeback_metadata in other words for I am trying to get some benchmarking numbers by using ssd only ie not use hdd for anything. by doing the above I expected hdd will never be used and all reads and writes will happen to and from the ssd... How ever to my shock random writes started happening to the HDD even iostat confirmed it avg-cpu: %user %nice %system %iowait %steal %idle 0.000.000.40 16.050.00 83.55 Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda 236.30 0.00 945.20 0 9452 sdb 0.00 0.00 0.00 0 0 bcache0 236.30 0.00 945.20 0 9452 avg-cpu: %user %nice %system %iowait %steal %idle 0.020.000.42 16.080.00 83.48 Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda 226.90 0.00 908.00 0 9080 sdb 0.00 0.00 0.00 0 0 bcache0 226.50 0.00 906.00 0 9060 avg-cpu: %user %nice %system %iowait %steal %idle 0.020.000.37 16.080.00 83.53 Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda 235.40 0.00 941.60 0 9416 sdb 0.00 0.00 0.00 0 0 bcache0 235.40 0.00 941.60 0 9416 avg-cpu: %user %nice %system %iowait %steal %idle 0.020.000.32 16.060.00 83.61 Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda 238.50 0.00 954.00 0 9540 sdb 0.00 0.00 0.00 0 0 bcache0 238.50 0.00 954.00 0 9540 This looks like a possible bug to me. Could you please confirm ? -- 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: 3.10.9: EXT4-fs (sdb1): delayed block allocation failed for inode 163315715 at logical offset 1 with max blocks 2 with error -5
On Wed, Aug 28, 2013 at 7:29 AM, Martin MOKREJŠ wrote:
> Hugh,
> looks you are right person to ask per https://lkml.org/lkml/2012/8/23/9
Sorry, Martin, I'm not at all the right person to help on this, I
haven't a clue.
You've already Cc'ed linux-ext4, right, someone there may have a
suggestion for you.
Good luck!
Hugh
>
> What can I do now with my system? Is it so that for unknown reason
> (misinterpreted ACPI condition?)
> /dev/sdb was stopped by SandyBridge and after an hour when shell redirects of
> valgrind's STDOUT
> and STDERR to a file filled up some kernel buffers (because could not write
> to /mnt/external)
> the ext4 driver choked?
>
> # cat /proc/sys/vm/laptop_mode
> 0
> #
>
> Have app-laptop/laptop-mode-tools-1.63-r2 on Gentoo Linux.
>
> Thank you,
> Martin
>
> Martin MOKREJŠ wrote:
>> Hi,
>> I have been running two instances of valgrind on some application on
>> 3.10.9 kernel
>> with a patch aiming to fix a BOS descriptor memleak (see linux-usb Subject
>> "[RFC v2] usbcore: compare and release one bos descriptor in
>> usb_reset_and_verify_device()"
>> but I hope it is unrelated). I enabled in the kernel some extra checks for
>> kernel
>> sanity in Kernel hacking section (am looking for an answer why something
>> overwrites memory
>> of my python-based application). Hence the valgrind and attempts to fortify
>> kernel a bit
>> more (see attached diff since last known good .config).
>>
>> Below I show when I early in the morning connected the external SATA drive
>> drive
>> and that muich later, kernel suddenly lost ability to read/write the
>> filesystem.
>> I somewhat suspect that laptop-mode-tools (although configured to ignore
>> mouse/keyboard
>> and usb-storage devices) somehow triggered the cause. However, still I would
>> like to see
>> that something happened at the SATA level.
>>
>>
>> Aug 28 04:41:05 vostro kernel: [ 248.268202] ata6: exception Emask 0x10
>> SAct 0x0 SErr 0x400 action 0xe frozen
>> Aug 28 04:41:05 vostro kernel: [ 248.268205] ata6: irq_stat 0x0040,
>> connection status changed
>> Aug 28 04:41:05 vostro kernel: [ 248.268207] ata6: SError: { DevExch }
>> Aug 28 04:41:05 vostro kernel: [ 248.268212] ata6: hard resetting link
>> Aug 28 04:41:06 vostro kernel: [ 249.009819] ata6: SATA link up 3.0 Gbps
>> (SStatus 123 SControl 300)
>> Aug 28 04:41:06 vostro kernel: [ 249.010951] ata6.00: ATA-8:
>> ST3000VX000-1CU166, CV22, max UDMA/133
>> Aug 28 04:41:06 vostro kernel: [ 249.010963] ata6.00: 5860533168 sectors,
>> multi 0: LBA48 NCQ (depth 31/32), AA
>> Aug 28 04:41:06 vostro kernel: [ 249.012058] ata6.00: configured for
>> UDMA/133
>> Aug 28 04:41:06 vostro kernel: [ 249.029823] ata6: EH complete
>> Aug 28 04:41:06 vostro kernel: [ 249.030376] scsi 5:0:0:0: Direct-Access
>> ATA ST3000VX000-1CU1 CV22 PQ: 0 ANSI: 5
>> Aug 28 04:41:06 vostro kernel: [ 249.032304] sd 5:0:0:0: [sdb] 5860533168
>> 512-byte logical blocks: (3.00 TB/2.72 TiB)
>> Aug 28 04:41:06 vostro kernel: [ 249.032306] sd 5:0:0:0: [sdb] 4096-byte
>> physical blocks
>> Aug 28 04:41:06 vostro kernel: [ 249.032623] sd 5:0:0:0: [sdb] Write
>> Protect is off
>> Aug 28 04:41:06 vostro kernel: [ 249.032625] sd 5:0:0:0: [sdb] Mode Sense:
>> 00 3a 00 00
>> Aug 28 04:41:06 vostro kernel: [ 249.032755] sd 5:0:0:0: [sdb] Write cache:
>> enabled, read cache: enabled, doesn't support DPO or FUA
>> Aug 28 04:41:06 vostro kernel: [ 249.033850] sd 5:0:0:0: Attached scsi
>> generic sg2 type 0
>> Aug 28 04:41:06 vostro kernel: [ 249.089816] sdb: sdb1
>> Aug 28 04:41:06 vostro kernel: [ 249.091295] sd 5:0:0:0: [sdb] Attached
>> SCSI disk
>> Aug 28 04:42:51 vostro kernel: [ 354.033592] EXT4-fs (sdb1): mounted
>> filesystem with ordered data mode. Opts: (null)
>> Aug 28 09:46:39 vostro kernel: [18604.328975] ata6: exception Emask 0x10
>> SAct 0x0 SErr 0x409 action 0xe frozen
>> Aug 28 09:46:39 vostro kernel: [18604.328985] ata6: irq_stat 0x00400040,
>> connection status changed
>> Aug 28 09:46:39 vostro kernel: [18604.328992] ata6: SError: { PHYRdyChg
>> 10B8B DevExch }
>> Aug 28 09:46:39 vostro kernel: [18604.329007] ata6: hard resetting link
>> Aug 28 09:46:39 vostro logger: ACPI event unhandled: ac_adapter AC 0080
>>
>> Aug 28 09:46:39 vostro kernel: [18605.089011] ata6: SATA link down (SStatus
>> 0 SControl 300)
>> Aug 28 09:46:40 vostro laptop-mode: Laptop mode
>> Aug 28 09:46:40 vostro laptop-mode: enabled, active
>> Aug 28 09:46:41 vostro logger: ACPI event unhandled: battery BAT0 0080
>> 0001
>> Aug 28 09:46:41 vostro kernel: [18607.033618] ata6: hard resetting link
>> Aug 28 09:46:42 vostro kernel: [18607.336433] EXT4-fs (sdb1): re-mounted.
>> Opts: commit=600
>> Aug 28 09:46:42 vostro kernel: [18607.381792] ata6: SATA link down (SStatus
>> 0 SControl 300)
>> Aug 28 09:46:42 vostro kernel: [18607.381802] ata6: limiting SATA link speed
>> to 1.5 Gbps
>> Aug 28 09:46:44 vostro logger: Device 2-1.2 is blacklisted, skippi
Re: performance drop after using blkcg
Hello,
I also do these tests and find the same results. IMO, on faster storage with
deep queue depth, if device is asking for more requests,but our workload
can't send enough requests, we have to idle to provide service
differentiation. We'll see performance drop if applications can't drive
enough IO to keep disk busy.Especially for writes, with the effect of disk
cache and deep queue depth, we'll often see performance drop .
So I come up with an approach called Self-adaption blkcg that if the
average total service time for a request is much less,we don' choose to
idle. Otherwise, we choose to idle to wait for the request. The patch is
below. After large tests,the new scheduler can provide service
differentiation in most cases. When the application can't drive enough
requests and the mean total service time is very small, we don't choose to
idle. In most cases, the performance doesn't drop after using blkcg and the
service differentiation is good.
>From 50705c8d4e456d3286e76bed7281796b1e915e0e Mon Sep 17 00:00:00 2001
From: Joeytao
Date: Mon, 26 Aug 2013 15:40:39 +0800
Subject: [PATCH] Self-adaption blkcg
---
block/cfq-iosched.c | 41 ++---
include/linux/iocontext.h |5 +
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 23500ac..79296de 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -288,6 +288,8 @@ struct cfq_data {
unsigned int cfq_group_idle;
unsigned int cfq_latency;
+unsigned int cfq_target_latency;
+unsigned int cfq_write_isolation;
unsigned int cic_index;
struct list_head cic_list;
@@ -589,7 +591,7 @@ cfq_group_slice(struct cfq_data *cfqd, struct cfq_group
*cfqg)
{
struct cfq_rb_root *st = &cfqd->grp_service_tree;
- return cfq_target_latency * cfqg->weight / st->total_weight;
+ return cfqd->cfq_target_latency * cfqg->weight / st->total_weight;
}
static inline unsigned
@@ -2028,6 +2031,14 @@ static void cfq_arm_slice_timer(struct cfq_data
*cfqd)
cic->ttime_mean);
return;
}
+
+ /*
+* added by joeytao,
+* If our average await_time is 0, then don't idle. This is for requests
of
+* write,because if the cache of disk is on, it's no need to wait.
+*/
+ if(!cfqd->cfq_write_isolation && sample_valid(cic->awtime_samples) &&
(cic->awtime_mean==0))
+ return;
/* There are other queues in the group, don't do group idle */
if (group_idle && cfqq->cfqg->nr_cfqq > 1)
@@ -2243,7 +2254,7 @@ new_workload:
* to have higher weight. A more accurate thing would be to
* calculate system wide asnc/sync ratio.
*/
- tmp = cfq_target_latency * cfqg_busy_async_queues(cfqd, cfqg);
+ tmp = cfqd->cfq_target_latency * cfqg_busy_async_queues(cfqd,
cfqg);
tmp = tmp/cfqd->busy_queues;
slice = min_t(unsigned, slice, tmp);
@@ -3228,10 +3239,21 @@ err:
}
static void
+cfq_update_io_awaittime(struct cfq_data *cfqd, struct cfq_io_context *cic)
+{
+ unsigned long elapsed = jiffies - cic->last_end_request;
+ unsigned long awtime = min(elapsed, 2UL * 16);
+
+ cic->awtime_samples = (7*cic->awtime_samples + 256) / 8;
+ cic->awtime_total = (7*cic->awtime_total + 256*awtime) / 8;
+ cic->awtime_mean = (cic->awtime_total + 128) / cic->awtime_samples;
+}
+
+static void
cfq_update_io_thinktime(struct cfq_data *cfqd, struct cfq_io_context *cic)
{
unsigned long elapsed = jiffies - cic->last_end_request;
- unsigned long ttime = min(elapsed, 2UL * cfqd->cfq_slice_idle);
+ unsigned long ttime = min(elapsed, 2UL * 8);
cic->ttime_samples = (7*cic->ttime_samples + 256) / 8;
cic->ttime_total = (7*cic->ttime_total + 256*ttime) / 8;
@@ -3573,6 +3595,7 @@ static void cfq_completed_request(struct request_queue
*q, struct request *rq)
cfqd->rq_in_flight[cfq_cfqq_sync(cfqq)]--;
if (sync) {
+ cfq_update_io_awaittime(cfqd,RQ_CIC(rq)); /* added by joeytao,
2013.8.27*/
RQ_CIC(rq)->last_end_request = now;
if (!time_after(rq->start_time + cfqd->cfq_fifo_expire[1], now))
cfqd->last_delayed_sync = now;
@@ -4075,6 +4098,12 @@ static void *cfq_init_queue(struct request_queue *q)
cfqd->cfq_back_penalty = cfq_back_penalty;
cfqd->cfq_slice[0] = cfq_slice_async;
cfqd->cfq_slice[1] = cfq_slice_sync;
+ cfqd->cfq_target_latency = cfq_target_latency; /* added by joeytao,
2013.8.5 */
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
+ cfqd->cfq_write_isolation = 0; /* added by joeytao, 2013.8.16 */
+#else
+ cfqd->cfq_write_isolation = 1; /* added by joeytao, 2013.8.21 */
+#endif
cfqd->cfq_slice_async_rq = cfq_slice_async_rq;
Re: [PATCH 33/35] power: use dev_get_platdata()
On Wed, Aug 28, 2013 at 07:07:14PM -0700, 'Greg Kroah-Hartman' wrote: > On Wed, Aug 28, 2013 at 06:18:49PM -0700, Anton Vorontsov wrote: > > On Wed, Aug 28, 2013 at 11:36:30AM +0300, Dan Carpenter wrote: > > > He doesn't want to take the patch. He's the maintainer so it's his > > > choice. That's the end of the story. > > > > Just to clarify: I don't want to take the patch for a reason, not just > > because of my mood today. Once the patch comes in combination with another > > patch (or a plan) that actually makes use of the wrapper function, then > > I'd happily apply/ack it. > > > > This is the same story as global checkpatch.pl fixes: they are more harm > > than good, and without the actual use of the dev_get_platdata(), the patch > > falls into "global checkpatch.pl fixes" category. > > If you view this as a checkpatch.pl fixup As a standalone patch I view it as a checkpatch.pl fixup. Even the author of the patch seem to agree: | On Thu, Aug 29, 2013 at 11:14:37AM +0900, Jingoo Han wrote: | > This patch is a just cosmetic change. And indeed I am against massive "just cosmetic" changes. These changes not so much burden for me personally (it was actually easier for me to just apply the patch without all the arguing), but for those who actually do real bugfixes/features in the drivers: their local development trees will produce conflicts. Solving the trivial conflicts not a problem either, but irritating (especially realizing that you waste time resolving conflicts because of the "just cosmetic" crap). These days I don't code that much, but I was in that boat resolving "cosmetic" conflicts, and I did not like it. So I'm trying to solve the issue for drivers/power/ developers. Thanks, Anton -- 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: ipc-msg broken again on 3.11-rc7? (was Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ])
On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta wrote: > Hi David, > > On 06/26/2013 04:59 AM, Davidlohr Bueso wrote: >> On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote: >>> On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso >>> wrote: On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote: [...] > I did some more testing with Linux-Testing-Project (release: > ltp-full-20130503) and next-20130624 (Monday) which has still the > issue, here. > > If I revert the mentioned two commits from my local > revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything > is fine. > > I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases. > >root# ./runltp -f ipc > >root# ./runltp -f syscalls These are nice test cases! So I was able to reproduce the issue with LTP and manually running msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock before calling it. The following changes fixes the issue and passes all 'runltp -f syscall' tests, could you give it a try? >>> >>> Cool, that fixes the issues here. >>> >>> Building with fakeroot & make deb-pkg is now OK, again. >>> >>> The syscalls/msgctl08 test-case ran successfully! >> >> Andrew, could you pick this one up? I've made the patch on top of >> 3.10.0-rc7-next-20130625 > > LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I > bisected it, sigh... didn't look at this thread earlier :-( and landed into > this. > > ->8 > 3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit > commit 3dd1f784ed6603d7ab1043e51e6371235edf2313 > Author: Davidlohr Bueso > Date: Mon Jul 8 16:01:17 2013 -0700 > > ipc,msg: shorten critical region in msgsnd > > do_msgsnd() is another function that does too many things with the ipc > object lock acquired. Take it only when needed when actually updating > msq. > ->8 > > If I revert 3dd1f784ed66 and 9ad66ae "ipc: remove unused functions" - the test > passes. I can confirm that linux-next also has the issue (didn't try the > revert > there though). > > 1. arc 3.11-rc7 config attached (UP + PREEMPT) > 2. dmesg prints "msgmni has been set to 479" > 3. LTP output (this is slightly dated source, so prints might vary) > > ->8 > <<>> > tag=msgctl08 stime=1377689180 > cmdline="msgctl08" > contacts="" > analysis=exit > initiation_status="ok" > <<>> > ->8 hung here -- > > > Let me know if you need more data/test help. > Cannot say much to your constellation as I had the issue on x86-64 and Linux-next. But I have just seen a post-v3.11-rc7 IPC-fix in [1]. I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run LTP. Which LTP release do you use? Might be good to attach your kernel-config for followers? - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922 -- 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: [PATCHSET 00/17] perf tools: Introduce new 'ftrace' command (v4)
Hi Jeremy,
On Wed, 28 Aug 2013 10:57:08 -0400, Jeremy Eder wrote:
> On 130813 11:20:52, Namhyung Kim wrote:
>> @@ -579,6 +587,8 @@ out:
>> pthread_cond_signal(&recorder_ready_cond);
>> pthread_mutex_unlock(&recorder_mutex);
>> }
>> +
>> +pr_debug2("done with %ld bytes\n", (long)byte_written);
>> return fra;
>> }
>>
>
> Hmm, I already had hunk #3 in your git tree v4.
Oops, sorry about that.
>
>> @@ -1139,12 +1149,12 @@ retry:
>> return record;
>> }
>>
>> -munmap(fra->map, pevent_get_page_size(ftrace->pevent));
>> -fra->map = NULL;
>> -
>> if (fra->done)
>> return NULL;
>>
>> +munmap(fra->map, pevent_get_page_size(ftrace->pevent));
>> +fra->map = NULL;
>> +
>> fra->offset += pevent_get_page_size(ftrace->pevent);
>> if (fra->offset >= fra->size) {
>> /* EOF */
>
>
> After patching your tree with just the first 2 hunks, I'm able to
> get ftrace-style function graphing out of perf.
>
> # ./perf ftrace record df
> Filesystem 1K-blocks Used Available Use% Mounted on
> ...
>
> # ./perf --no-pager ftrace show | head -20
> overriding event (11) ftrace:funcgraph_entry with new print handler
> overriding event (10) ftrace:funcgraph_exit with new print handler
> 2) 0.686 us | finish_task_switch();
> 2) 0.260 us | finish_wait();
> 2)| mutex_lock() {
> 2) 0.211 us |_cond_resched();
> 2) 1.170 us | }
> 2) 0.319 us | generic_pipe_buf_confirm();
> 2) 0.261 us | generic_pipe_buf_map();
> 2) 0.129 us | generic_pipe_buf_unmap();
> 2) 0.747 us | anon_pipe_buf_release();
> 2) 0.138 us | mutex_unlock();
> 2)| __wake_up_sync_key() {
> 2) 0.279 us |_raw_spin_lock_irqsave();
> 2) 0.135 us |__wake_up_common();
> 2) 0.133 us |__lock_text_start();
> 2) 3.386 us | }
> 2)| kill_fasync() {
> 2)| smp_reschedule_interrupt() {
> 2) 0.130 us |kvm_guest_apic_eoi_write();
>
> Nice.
Glad to see this. :)
>
> Not sure if you intend to move all ftrace functionality over to
> perf ftrace, but the function graph timings is a great start and something
> sorely
> missing.
>
> Do you intend to add -e event support or -l function-specific options ? In
> the real
> world, without filtering on events or functions, I've had systems hang, plus
> performance impact is too great.
>
> A common invocation of ftrace via trace-cmd is:
> # trace-cmd record -p function_graph -e irq:* -l do_IRQ ping -c1
> www.redhat.com
>
> So possible perf equivalent?
> # ./perf ftrace record -e irq:* -e do_IRQ ping -c1 www.redhat.com
Yes I'm considering adding more features in trace-cmd to perf ftrace.
The function filtering is the one in the highest priority. I also want
to add support for other events but it needs bit more thinking.
Thanks,
Namhyung
--
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/4] usb: r8a66597-hcd: use platform_{get,set}_drvdata()
On 2013/8/28 12:36, Greg KH wrote:
> On Tue, Aug 27, 2013 at 04:10:22PM +0800, Libo Chen wrote:
>>
>> Use the wrapper functions for getting and setting the driver data using
>> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
>> so we can directly pass a struct platform_device.
>>
>> Signed-off-by: Libo Chen
>> ---
>> drivers/usb/host/r8a66597-hcd.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> This patch doesn't apply to my tree :(
Hi Greg,
This patch based on mainline.
Do you mean this patch got a conflicted in
"git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git"
I need to rebase on "usb.git"?
>
>
>
--
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 v7 00/10] tracing: trace event triggers (repost)
On Wed, 2013-08-28 at 15:51 -0400, Steven Rostedt wrote: > On Tue, 27 Aug 2013 14:40:12 -0500 > Tom Zanussi wrote: > > > Tom Zanussi (10): > > tracing: Add support for SOFT_DISABLE to syscall events > > tracing: add basic event trigger framework > > tracing: add 'traceon' and 'traceoff' event trigger commands > > tracing: add 'snapshot' event trigger command > > tracing: add 'stacktrace' event trigger command > > tracing: add 'enable_event' and 'disable_event' event trigger > > commands > > tracing: add and use generic set_trigger_filter() implementation > > tracing: update event filters for multibuffer > > tracing: add documentation for trace event triggers > > tracing: make register/unregister_ftrace_command __init > > In your next series, can you please fix the subjects. The lines should > start with a capital letter. You did it correctly on your first patch, > but failed to do it for the others. > > Thanks! > Yeah, will do, and thanks for the review.. Tom > -- Steve > -- 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-kernel,produce hormones and steroids
Dear director, We produce Steroids and intermediates ingredients. Products: APIs DHEA Series Nandrolone Series Testosterone Series Altrenogest Intermediates 4-Androstenedione 1,4-Androstadienedione Altrenogest Intermediate Spirolactone Intermediate Customs Synthesis If you are interested, please contact us for more information. Regards, Jacky Goto pharmaceuticals Co.,Ltd Tel: +86 710 3423122, Fax: +86 710 3423124 Email:produ...@gotopharm.com Msn:zhisheng...@hotmail.com Add: 7-1602 New City of Century, 47th Changhong Road, Xiangyang, Hubei, China, 441002
Re: [PATCH v3 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection
On 8/28/2013 11:24 PM, Sergei Shtylyov wrote:
On 08/28/2013 09:33 PM, George Cherian wrote:
Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.
Signed-off-by: George Cherian
---
arch/arm/boot/dts/dra7-evm.dts | 50
+-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts
b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..8b0738a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
[...]
@@ -33,10 +44,47 @@
};
};
+&i2c1 {
+clock-frequency = <40>;
+
+gpio20: pcf8575@20 {
ePAPR was talking about the node naming, not about labelling. Back
to the drawing board. ;-)
ha. :-/
+compatible = "ti,pcf8575";
+reg = <0x20>;
+n_latch = <0x4000>;
+gpio-controller;
+#gpio-cells = <2>;
+interrupt-parent = <&gpio6>;
+interrupts = <11 2>;
+interrupt-controller;
+#interrupt-cells = <2>;
+};
+
+gpio21: pcf8575@21 {
+compatible = "ti,pcf8575";
+reg = <0x21>;
+n_latch = <0x1408>;
+gpio-controller;
+#gpio-cells = <2>;
+interrupt-parent = <&pcf_20>;
+interrupts = <14 2>;
+interrupt-controller;
+#interrupt-cells = <2>;
+};
+
+};
+
WBR, Sergei
--
-George
--
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 v7 07/10] tracing: add and use generic set_trigger_filter() implementation
On Wed, 2013-08-28 at 12:38 -0400, Steven Rostedt wrote:
> On Tue, 27 Aug 2013 14:40:19 -0500
> Tom Zanussi wrote:
>
> > enum {
> > FILTER_OTHER = 0,
> > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> > index 326ba32..6c701c3 100644
> > --- a/include/trace/ftrace.h
> > +++ b/include/trace/ftrace.h
> > @@ -412,13 +412,15 @@ static inline notrace int ftrace_get_offsets_##call(
> > \
> > * struct ftrace_data_offsets_ __maybe_unused __data_offsets;
> > * struct ring_buffer_event *event;
> > * struct ftrace_raw_ *entry; <-- defined in stage 1
> > + * enum event_trigger_type __tt = ETT_NONE;
> > * struct ring_buffer *buffer;
> > * unsigned long irq_flags;
> > * int __data_size;
> > * int pc;
> > *
> > - * if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
> > - * &ftrace_file->flags))
> > + * if ((ftrace_file->flags & (FTRACE_EVENT_FL_SOFT_DISABLED |
> > + * FTRACE_EVENT_FL_TRIGGER_MODE)) ==
> > + * FTRACE_EVENT_FL_SOFT_DISABLED)
>
> Don't worry too much about 80 character limit here. Move the
> FL_SOFT_DISABLED up.
>
> > * return;
> > *
> > * local_save_flags(irq_flags);
> > @@ -437,9 +439,19 @@ static inline notrace int ftrace_get_offsets_##call(
> > \
> > * { ; } <-- Here we assign the entries by the __field and
> > *__array macros.
> > *
> > - * if (!filter_current_check_discard(buffer, event_call, entry, event))
> > - * trace_nowake_buffer_unlock_commit(buffer,
> > - *event, irq_flags, pc);
> > + * if (test_bit(FTRACE_EVENT_FL_TRIGGER_MODE_BIT,
> > + * &ftrace_file->flags))
> > + * __tt = event_triggers_call(ftrace_file, entry);
> > + *
> > + * if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
> > + * &ftrace_file->flags))
> > + * ring_buffer_discard_commit(buffer, event);
> > + * else if (!filter_current_check_discard(buffer, event_call,
> > + *entry, event))
> > + * trace_buffer_unlock_commit(buffer, event, irq_flags, pc);
> > + *
> > + * if (__tt)
> > + * event_triggers_post_call(ftrace_file, __tt);
> > * }
> > *
> > * static struct trace_event ftrace_event_type_ = {
> > @@ -521,17 +533,15 @@ ftrace_raw_event_##call(void *__data, proto)
> > \
> > struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
> > struct ring_buffer_event *event;\
> > struct ftrace_raw_##call *entry;\
> > + enum event_trigger_type __tt = ETT_NONE;\
> > struct ring_buffer *buffer; \
> > unsigned long irq_flags;\
> > int __data_size;\
> > int pc; \
> > \
> > - if (test_bit(FTRACE_EVENT_FL_TRIGGER_MODE_BIT, \
> > -&ftrace_file->flags)) \
> > - event_triggers_call(ftrace_file); \
> > - \
> > - if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, \
> > -&ftrace_file->flags)) \
> > + if ((ftrace_file->flags & (FTRACE_EVENT_FL_SOFT_DISABLED | \
> > +FTRACE_EVENT_FL_TRIGGER_MODE)) == \
> > + FTRACE_EVENT_FL_SOFT_DISABLED) \
>
> Ditto.
>
> Also, I don't think we need to worry about the flags changing, so we
> should be able to just save it.
>
> unsigned long eflags = ftrace_file_flags;
>
> And then we can also only delay the event triggers if it has a
> condition. What about adding a FTRACE_EVENT_FL_TRIGGER_COND_BIT, and do:
>
> if (!(eflags & FTRACE_EVENT_FL_TRIGGER_COND))
> if (eflags & FTRACE_EVENT_FL_TRIGGER_MODE)
> event_triggers_call(ftrace_file, NULL);
>
> if (eflags & FTRACE_EVENT_FL_SOFT_DISABLED)
> return;
> }
>
I like the additional TRIGGER_COND flag, but as written I think the
above leads to different output in the non-SOFT_DISABLED trigger cases
depending on whether it's set or or not. For instance, stacktrace
triggers invoked when TRIGGER_COND is cleared will print
trace_dump_stack() before the triggering event (above, which falls
through to print the triggering event following the stacktrace if not
SOFT_DISABLED), but if called for the same triggers with TRIGGER_COND
set, the stacktrace will end up following the triggering event
(event_triggers_call()/event_triggers_post_call() not called above, but
following the triggering event print.)
So above I think
[PATCH 2/3 v3] Refactor MSI restore call-chain to drop unnecessary argument
Driver init call graph under baremetal:
driver_init->
msix_capability_init->
msix_program_entries->
msix_mask_irq->
entry->masked = 1
request_irq->
__setup_irq->
irq_startup->
unmask_msi_irq->
msix_mask_irq->
entry->masked = 0
So entry->masked is always updated with newest value and its value could be used
to restore to mask register in device.
But in initial domain (aka priviliged guest), it's different.
Driver init call graph under initial domain:
driver_init->
msix_capability_init->
msix_program_entries->
msix_mask_irq->
entry->masked = 1
request_irq->
__setup_irq->
irq_startup->
__startup_pirq->
EVTCHNOP_bind_pirq hypercall(trap into Xen)
[Xen:]
pirq_guest_bind->
startup_msi_irq->
unmask_msi_irq->
msi_set_mask_bit->
entry->msi_attrib.masked = 0
So entry->msi_attrib.masked in xen side always has newest value. entry->masked
in initial domain is untouched and is 1 after msix_capability_init.
Based on above, it's Xen's duty to restore entry->msi_attrib.masked to device,
but with current code, entry->masked is used and MSI-x interrupt is masked.
Before patch, restore call graph under initial domain:
pci_reset_function->
pci_restore_state->
__pci_restore_msix_state->
arch_restore_msi_irqs->
xen_initdom_restore_msi_irqs->
PHYSDEVOP_restore_msi hypercall (first mask restore)
msix_mask_irq(entry, entry->masked) (second mask restore)
So msix_mask_irq call in initial domain call graph needs to be removed.
Based on this we can move the restore of the mask in default_restore_msi_irqs
which would avoid restoring the invalid mask under Xen. Furthermore this
simplifies the API by making everything related to restoring an MSI be in the
platform specific APIs instead of just parts of it.
After patch, restore call graph under initial domain:
pci_reset_function->
pci_restore_state->
__pci_restore_msix_state->
arch_restore_msi_irqs->
xen_initdom_restore_msi_irqs->
PHYSDEVOP_restore_msi hypercall (first mask restore)
Logic for baremetal is not changed.
Before patch, restore call graph under baremetal:
pci_reset_function->
pci_restore_state->
__pci_restore_msix_state->
arch_restore_msi_irqs->
default_restore_msi_irqs->
msix_mask_irq(entry, entry->masked) (first mask restore)
After patch, restore call graph under baremetal:
pci_reset_function->
pci_restore_state->
__pci_restore_msix_state->
arch_restore_msi_irqs->
default_restore_msi_irqs->
msix_mask_irq(entry, entry->masked) (first mask restore)
The process for MSI code is similiar.
-v3: Update patch description per Konrad suggestion, thanks.
Tested-by: Sucheta Chakraborty
Signed-off-by: Zhenzhong Duan
---
drivers/pci/msi.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 87223ae..922fb49 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -216,6 +216,8 @@ void unmask_msi_irq(struct irq_data *data)
#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
void default_restore_msi_irqs(struct pci_dev *dev, int irq)
{
+ int pos;
+ u16 control;
struct msi_desc *entry;
entry = NULL;
@@ -228,8 +230,19 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
entry = irq_get_msi_desc(irq);
}
- if (entry)
+ if (entry) {
write_msi_msg(irq, &entry->msg);
+ if (dev->msix_enabled) {
+ msix_mask_irq(entry, entry->masked);
+ readl(entry->mask_base);
+ } else {
+ pos = entry->msi_attrib.pos;
+ pci_read_config_word(dev, pos + PCI_MSI_FLAGS,
+&control);
+ msi_mask_irq(entry, msi_capable_mask(control),
+entry->masked);
+ }
+ }
}
#endif
@@ -406,7 +419,6 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
arch_restore_msi_irqs(dev, dev->irq);
pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, &control);
- msi_mask_irq(entry, msi_capable_mask(control), entry->masked);
control &= ~PCI_MSI_FLAGS_QSIZE;
control |= (entry->msi_attrib.multiple << 4) | PCI_MSI_FLAGS_ENABLE;
pci_write_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, control);
@@ -430,7 +442,6 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
list_for_each_entry(entry, &dev->msi_list, list) {
arch_restore_msi_irqs(dev,
linux-next: manual merge of the v4l-dvb tree with Linus' tree
Hi Mauro,
Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-shmobile/board-bockw.c between commit fa3e0cee12fb ("ARM:
shmobile: BOCK-W: fix SDHI0 PFC settings") from Linus' tree and commit
9c43952d0f1e ("[media] ARM: shmobile: BOCK-W: add VIN and ML86V7667
support") from the v4l-dvb tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-shmobile/board-bockw.c
index 3354a85,7d44f66..000
--- a/arch/arm/mach-shmobile/board-bockw.c
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@@ -167,13 -188,17 +188,23 @@@ static const struct pinctrl_map bockw_p
"usb1", "usb1"),
/* SDHI0 */
PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
-"sdhi0", "sdhi0"),
+"sdhi0_data4", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+"sdhi0_ctrl", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+"sdhi0_cd", "sdhi0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+"sdhi0_wp", "sdhi0"),
+ /* VIN0 */
+ PIN_MAP_MUX_GROUP_DEFAULT("r8a7778-vin.0", "pfc-r8a7778",
+ "vin0_clk", "vin0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("r8a7778-vin.0", "pfc-r8a7778",
+ "vin0_data8", "vin0"),
+ /* VIN1 */
+ PIN_MAP_MUX_GROUP_DEFAULT("r8a7778-vin.1", "pfc-r8a7778",
+ "vin1_clk", "vin1"),
+ PIN_MAP_MUX_GROUP_DEFAULT("r8a7778-vin.1", "pfc-r8a7778",
+ "vin1_data8", "vin1"),
};
#define FPGA 0x1820
pgpiaaWvmZztU.pgp
Description: PGP signature
Re: [PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 08/28/2013 08:51 PM, Mark Rutland wrote:
On Wed, Aug 28, 2013 at 07:54:01AM +0100, Hongbo Zhang wrote:
On 08/27/2013 07:35 PM, Mark Rutland wrote:
On Tue, Aug 27, 2013 at 11:42:02AM +0100, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 232 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg :
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg :
+- interrupts:
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4 0x100600 0x4>;
Is that one reg entry where #size-cells=2 and #address-cells=2?
That's what the binding implies (given it only describes a single reg
entry).
if it's two entries, we should make that explicit (both in the binding
and example):
reg = <0x100300 0x4>,
<0x100600 0x4>;
Yes they are two entries, I will change it this way.
Ok. Could you make sure you document what the two reg entries correspond
to? That's not clear from "".
Yes I am sure, we have reg for DMA controller and also reg for each DMA
channel.
these two reg entries are "registers specifier for DMA general status
reg", not "registers specifier for channel"
because this is an 8-channel DMA controller, we have two general status
registers (vs. one status register for 4-chanel DMA controller previously )
+ ranges = <0x0 0x100100 0x500>;
If it is one reg entry then the example ranges property isn't big enough
to contain the parent-bus-address.
They are two reg entries, so the range is big enough.
Ok.
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = <0xe2000 0x1000>;
Re: [PATCH v2 2/4] mm/sparse: introduce alloc_usemap_and_memmap
On Wed, Aug 28, 2013 at 7:34 PM, Yinghai Lu wrote: > On Wed, Aug 28, 2013 at 7:18 PM, Yinghai Lu wrote: >> please change to function pointer to >> void (*alloc_func)(void *data, >> unsigned long pnum_begin, >> unsigned long pnum_end, >> unsigned long map_count, int nodeid) >> >> pnum_begin, pnum_end, map_coun, nodeid, should not be in the struct. > > looks like that is what is your first version did. > > I updated it a little bit. please check it. > removed more lines. Yinghai 0001-sparse_v3.patch Description: Binary data
Re: [PATCH v2 2/4] mm/sparse: introduce alloc_usemap_and_memmap
On Wed, Aug 28, 2013 at 7:18 PM, Yinghai Lu wrote: > please change to function pointer to > void (*alloc_func)(void *data, > unsigned long pnum_begin, > unsigned long pnum_end, > unsigned long map_count, int nodeid) > > pnum_begin, pnum_end, map_coun, nodeid, should not be in the struct. looks like that is what is your first version did. I updated it a little bit. please check it. Thanks Yinghai 0001-sparse_v2.patch Description: Binary data
Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
Hi Chanwoo,
Thanks for the review and sorry for all the trivial mistakes.
On 8/29/2013 7:05 AM, Chanwoo Choi wrote:
Hi George,
You didn't modify this patchset about my comment on v1 patchset.
Please pay attention to comment.
On 08/29/2013 02:33 AM, George Cherian wrote:
Add a generic USB VBUS/ID detection EXTCON driver. This driver expects
the ID/VBUS pin are connected via GPIOs. This driver is tested on
DRA7x board were the ID pin is routed via GPIOs. The driver supports
both VBUS and ID pin configuration and ID pin only configuration.
Signed-off-by: George Cherian
---
.../bindings/extcon/extcon-gpio-usbvid.txt | 20 ++
drivers/extcon/Kconfig | 6 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-gpio-usbvid.c| 286 +
You should keep following naming stlye. extcon-gpio-usbvid.c is wrong naming
style.
- extcon-[device name].c
- extcon-gpio-usbvid.c -> extcon-dra7xx.c or etc.
Actually dra7xx is the SoC name and the USB VBUS/ID detection is not
specific to SoC.
It uses gpios to detect the VBUS/ID change. So i thought it would be
better to have generic
gpio based VBUS/ID detection rather than making dra7xx specific. Stephen
Warren had this opinion
with patch v1.
Also, you should change the file name of extcon-gpio-usbvid.txt.
Finally, You used 'gpio_usbvid' prefix in extcon-gpio-usbvid.c.
It has caused the confusion that user would think extcon-gpio-usbvid.c driver
support all of extcon driver using gpio irq pin. So I'd like you to use
proper prefix including device name.
I meant to support all of extcon driver using gpio for USB VBUS/ID
detection.
4 files changed, 313 insertions(+)
create mode 100644
Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
create mode 100644 drivers/extcon/extcon-gpio-usbvid.c
[snip]
index f1d54a3..8097398 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -64,4 +64,10 @@ config EXTCON_PALMAS
Say Y here to enable support for USB peripheral and USB host
detection by palmas usb.
+config EXTCON_GPIO_USBVID
+ tristate "Generic USB VBUS/ID detection using GPIO EXTCON support"
+ help
+ Say Y here to enable support for USB VBUS/ID deetction by GPIO.
+
+
Remove blank line.
okay
endif # MULTISTATE_SWITCH
[snip]
diff --git a/drivers/extcon/extcon-gpio-usbvid.c
b/drivers/extcon/extcon-gpio-usbvid.c
new file mode 100644
index 000..e9bc2a97
--- /dev/null
+++ b/drivers/extcon/extcon-gpio-usbvid.c
@@ -0,0 +1,286 @@
+/*
+ * Generic USB VBUS-ID pin detection driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: George Cherian
+ *
+ * Based on extcon-palmas.c
+ *
+ * Author: Kishon Vijay Abraham I
+ *
+ * This program is distributed in the hope that 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
kthead.h, freezer.h headerfile is used in this file?
okay
+#include
+#include
+#include
+#include
+#include
+#include
+#include
Order headerfile alphabetically.
okay
+
+struct gpio_usbvid {
+ struct device *dev;
+
+ struct extcon_dev edev;
+
+ /*GPIO pin */
I commented previous your patch about this wrong coding style.
Why did not you fix this coding style?
okay
+ int id_gpio;
+ int vbus_gpio;
+
+ int id_irq;
+ int vbus_irq;
+ int type;
+};
+
+static const char *dra7xx_extcon_cable[] = {
+ [0] = "USB",
+ [1] = "USB-HOST",
+ NULL,
+};
+
+static const int mutually_exclusive[] = {0x3, 0x0};
+
+/* Two types of support are provided.
+ * Systems which has
+ * 1) VBUS and ID pin connected via GPIO
+ * 2) only ID pin connected via GPIO
Remove blank between '2)' and 'only'.
okay
+ * For Case 1 both the gpios should be provided via DT
+ * Always the first GPIO in dt is considered ID pin GPIO
+ */
+
+enum {
+ UNKNOWN = 0,
+ ID_DETECT,
+ VBUS_ID_DETECT,
+};
+
+#define ID_GND 0
+#define ID_FLOAT 1
+#define VBUS_OFF 0
+#define VBUS_ON1
I think you could only use two constant instead of four constant definition.
you mean only ID_GND and VBUS_OFF?
+
+
This blank line isn't necessary.
+static irqreturn_t id_irq_handler(int irq, void *data)
+{
+ struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *) data;
You should delete blank between ')' and 'data' as follwong:
- (struct gpio_usbvid *)data;
okay
+ int id_current;
Re: [PATCH 33/35] power: use dev_get_platdata()
On Thursday, August 29, 2013 11:07 AM, Greg Kroah-Hartman wrote: > On Wed, Aug 28, 2013 at 06:18:49PM -0700, Anton Vorontsov wrote: > > On Wed, Aug 28, 2013 at 11:36:30AM +0300, Dan Carpenter wrote: > > > He doesn't want to take the patch. He's the maintainer so it's his > > > choice. That's the end of the story. > > > > Just to clarify: I don't want to take the patch for a reason, not just > > because of my mood today. Once the patch comes in combination with another > > patch (or a plan) that actually makes use of the wrapper function, then > > I'd happily apply/ack it. > > > > This is the same story as global checkpatch.pl fixes: they are more harm > > than good, and without the actual use of the dev_get_platdata(), the patch > > falls into "global checkpatch.pl fixes" category. > > If you view this as a checkpatch.pl fixup, I'll be glad to take it > through my tree instead, to ease the patch burden on you :) Hi Greg, I agree with you. Thank you for your suggestion. :-) Best regards, Jingoo Han -- 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] mm/sparse: introduce alloc_usemap_and_memmap
On Thu, Aug 22, 2013 at 5:14 AM, Wanpeng Li wrote:
>From f21640b6dc15c76ac10fccada96e6b9fdce5a092 Mon Sep 17 00:00:00 2001
From: Wanpeng Li
Date: Thu, 22 Aug 2013 19:57:54 +0800
Subject: [PATCH] mm/sparse: introduce alloc_usemap_and_memmap fix
Pass function pointer to alloc_usemap_and_memmap() instead of true/false.
Signed-off-by: Wanpeng Li
---
mm/sparse.c | 78 ++---
1 file changed, 44 insertions(+), 34 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 55e5752..22a1a26 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -14,6 +14,14 @@
#include
#include
+struct alloc_info {
+unsigned long **map_map;
+unsigned long pnum_begin;
+unsigned long pnum_end;
+unsigned long map_count;
+int nodeid;
+};
+
/*
* Permanent SPARSEMEM data:
*
@@ -339,13 +347,16 @@ static void __init check_usemap_section_nr(int
nid, unsigned long *usemap)
}
#endif /* CONFIG_MEMORY_HOTREMOVE */
-static void __init sparse_early_usemaps_alloc_node(unsigned long**usemap_map,
- unsigned long pnum_begin,
- unsigned long pnum_end,
- unsigned long usemap_count, int nodeid)
+static void __init sparse_early_usemaps_alloc_node(void *data)
{
void *usemap;
unsigned long pnum;
+struct alloc_info *info = (struct alloc_info *)data;
+unsigned long **usemap_map = info->map_map;
+unsigned long pnum_begin = info->pnum_begin;
+unsigned long pnum_end = info->pnum_end;
+unsigned long usemap_count = info->map_count;
+int nodeid = info->nodeid;
===>
usemap_count and nodeid is only referred one time, you may omit those
two temp variables.
int size = usemap_size();
usemap = sparse_early_usemaps_alloc_pgdat_section(NODE_DATA(nodeid),
@@ -430,23 +441,13 @@ void __init sparse_mem_maps_populate_node(struct
page **map_map,
#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
-static void __init sparse_early_mem_maps_alloc_node(struct page **map_map,
- unsigned long pnum_begin,
- unsigned long pnum_end,
- unsigned long map_count, int nodeid)
+static void __init sparse_early_mem_maps_alloc_node(void *data)
{
-sparse_mem_maps_populate_node(map_map, pnum_begin, pnum_end,
- map_count, nodeid);
+struct alloc_info *info = (struct alloc_info *)data;
+sparse_mem_maps_populate_node((struct page **)info->map_map,
+info->pnum_begin, info->pnum_end, info->map_count, info->nodeid);
}
#else
-
-static void __init sparse_early_mem_maps_alloc_node(struct page **map_map,
-unsigned long pnum_begin,
-unsigned long pnum_end,
-unsigned long map_count, int nodeid)
-{
-}
-
static struct page __init *sparse_early_mem_map_alloc(unsigned long pnum)
{
struct page *map;
@@ -471,14 +472,15 @@ void __attribute__((weak)) __meminit
vmemmap_populate_print_last(void)
/**
* alloc_usemap_and_memmap - memory alloction for pageblock flags and vmemmap
* @map: usemap_map for pageblock flags or mmap_map for vmemmap
- * @use_map: true if memory allocated for pageblock flags, otherwise false
*/
-static void alloc_usemap_and_memmap(unsigned long **map, bool use_map)
+static void alloc_usemap_and_memmap(void (*sparse_early_maps_alloc_node)
+(void *data), void *data)
==> how about changing to :
+static void alloc_map(void (*alloc_fn)(void *), void *data)
{
unsigned long pnum;
unsigned long map_count;
int nodeid_begin = 0;
unsigned long pnum_begin = 0;
+struct alloc_info *info = (struct alloc_info *)data;
for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
struct mem_section *ms;
@@ -503,25 +505,24 @@ static void alloc_usemap_and_memmap(unsigned
long **map, bool use_map)
map_count++;
continue;
}
+
+info->pnum_begin = pnum_begin;
+info->pnum_end = pnum;
+info->map_count = map_count;
+info->nodeid = nodeid_begin;
/* ok, we need to take cake of from pnum_begin to pnum - 1*/
-if (use_map)
-sparse_early_usemaps_alloc_node(map, pnum_begin, pnum,
- map_count, nodeid_begin);
-else
-sparse_early_mem_maps_alloc_node((struct page **)map,
-pnum_begin, pnum, map_count, nodeid_begin);
+sparse_early_maps_alloc_node((void *)info);
/* new start, update count etc*/
nodeid_begin = nodeid;
pnum_begin = pnum;
map_count = 1;
}
/* ok, last chunk */
-if (use_map)
-sparse_early_usemaps_alloc_node(map, pnum_begin,
-NR_MEM_SECTIONS, map_count, nodeid_begin);
-else
-sparse_early_mem_maps_alloc_node((struct page **)map,
-pnum_begin, NR_MEM_SECTIONS, map_count, nodeid_begin);
+info->pnum_begin = pnum_begin;
+info->pnum_end = NR_MEM_SECTIONS;
+in
Re: [PATCH 33/35] power: use dev_get_platdata()
On Thursday, August 29, 2013 10:19 AM, Anton Vorontsov wrote: > On Wed, Aug 28, 2013 at 11:36:30AM +0300, Dan Carpenter wrote: > > He doesn't want to take the patch. He's the maintainer so it's his > > choice. That's the end of the story. > > Just to clarify: I don't want to take the patch for a reason, not just > because of my mood today. Once the patch comes in combination with another > patch (or a plan) that actually makes use of the wrapper function, then > I'd happily apply/ack it. Sorry, I cannot understand. This patch is a just cosmetic change. I cannot understand why you reject it. > > This is the same story as global checkpatch.pl fixes: they are more harm > than good, and without the actual use of the dev_get_platdata(), the patch > falls into "global checkpatch.pl fixes" category. So, what is the harm of the fix using dev_get_platdata() wrapper function? What is "the actual use of the dev_get_platdata()"? Please, give me more detailed description. Best regards, Jingoo Han -- 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] driver core / ACPI: Avoid device hot remove locking issues
On 08/28/2013 09:48 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> device_hotplug_lock is held around the acpi_bus_trim() call in
> acpi_scan_hot_remove() which generally removes devices (it removes
> ACPI device objects at least, but it may also remove "physical"
> device objects through .detach() callbacks of ACPI scan handlers).
> Thus, potentially, device sysfs attributes are removed under that
> lock and to remove those attributes it is necessary to hold the
> s_active references of their directory entries for writing.
>
> On the other hand, the execution of a .show() or .store() callback
> from a sysfs attribute is carried out with that attribute's s_active
> reference held for reading. Consequently, if any device sysfs
> attribute that may be removed from within acpi_scan_hot_remove()
> through acpi_bus_trim() has a .store() or .show() callback which
> acquires device_hotplug_lock, the execution of that callback may
> deadlock with the removal of the attribute. [Unfortunately, the
> "online" device attribute of CPUs and memory blocks is one of them.]
>
> To avoid such deadlocks, make all of the sysfs attribute callbacks
> that need to lock device hotplug, for example store_online(), use
> a special function, lock_device_hotplug_sysfs(), to lock device
> hotplug and return the result of that function immediately if it is
> not zero. This will cause the s_active reference of the directory
> entry in question to be released and the syscall to be restarted
> if device_hotplug_lock cannot be acquired.
>
> [show_online() actually doesn't need to lock device hotplug, but
> it is useful to serialize it with respect to device_offline() and
> device_online() for the same device (in case user space attempts to
> run them concurrently) which can be done with the help of
> device_lock().]
>
> Signed-off-by: Rafael J. Wysocki
> Reported-by: Yasuaki Ishimatsu
> Reported-by: Gu Zheng
Tested-by: Gu Zheng
> ---
> drivers/acpi/sysfs.c |5 -
> drivers/base/core.c| 43 ---
> drivers/base/memory.c |4 +++-
> include/linux/device.h |1 +
> 4 files changed, 36 insertions(+), 17 deletions(-)
>
> Index: linux-pm/drivers/base/core.c
> ===
> --- linux-pm.orig/drivers/base/core.c
> +++ linux-pm/drivers/base/core.c
> @@ -49,6 +49,28 @@ static struct kobject *dev_kobj;
> struct kobject *sysfs_dev_char_kobj;
> struct kobject *sysfs_dev_block_kobj;
>
> +static DEFINE_MUTEX(device_hotplug_lock);
> +
> +void lock_device_hotplug(void)
> +{
> + mutex_lock(&device_hotplug_lock);
> +}
> +
> +void unlock_device_hotplug(void)
> +{
> + mutex_unlock(&device_hotplug_lock);
> +}
> +
> +int lock_device_hotplug_sysfs(void)
> +{
> + if (mutex_trylock(&device_hotplug_lock))
> + return 0;
> +
> + /* Avoid busy looping (5 ms of sleep should do). */
> + msleep(5);
> + return restart_syscall();
> +}
> +
> #ifdef CONFIG_BLOCK
> static inline int device_is_not_partition(struct device *dev)
> {
> @@ -408,9 +430,9 @@ static ssize_t show_online(struct device
> {
> bool val;
>
> - lock_device_hotplug();
> + device_lock(dev);
> val = !dev->offline;
> - unlock_device_hotplug();
> + device_unlock(dev);
> return sprintf(buf, "%u\n", val);
> }
>
> @@ -424,7 +446,10 @@ static ssize_t store_online(struct devic
> if (ret < 0)
> return ret;
>
> - lock_device_hotplug();
> + ret = lock_device_hotplug_sysfs();
> + if (ret)
> + return ret;
> +
> ret = val ? device_online(dev) : device_offline(dev);
> unlock_device_hotplug();
> return ret < 0 ? ret : count;
> @@ -1479,18 +1504,6 @@ EXPORT_SYMBOL_GPL(put_device);
> EXPORT_SYMBOL_GPL(device_create_file);
> EXPORT_SYMBOL_GPL(device_remove_file);
>
> -static DEFINE_MUTEX(device_hotplug_lock);
> -
> -void lock_device_hotplug(void)
> -{
> - mutex_lock(&device_hotplug_lock);
> -}
> -
> -void unlock_device_hotplug(void)
> -{
> - mutex_unlock(&device_hotplug_lock);
> -}
> -
> static int device_check_offline(struct device *dev, void *not_used)
> {
> int ret;
> Index: linux-pm/drivers/base/memory.c
> ===
> --- linux-pm.orig/drivers/base/memory.c
> +++ linux-pm/drivers/base/memory.c
> @@ -351,7 +351,9 @@ store_mem_state(struct device *dev,
>
> mem = container_of(dev, struct memory_block, dev);
>
> - lock_device_hotplug();
> + ret = lock_device_hotplug_sysfs();
> + if (ret)
> + return ret;
>
> if (!strncmp(buf, "online_kernel", min_t(int, count, 13))) {
> offline = false;
> Index: linux-pm/drivers/acpi/sysfs.c
> ===
> --- linux-pm.orig/drivers/acpi/sysfs.c
> +++ linux-pm/drivers/acpi/sysfs.c
> @@ -796,7 +796,10 @@ static ssize_t for
Re: [PATCH 2/2] ACPI / hotplug: Remove containers synchronously
On 08/28/2013 09:51 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The current protocol for handling hot remove of containers is very
> fragile and causes acpi_eject_store() to acquire acpi_scan_lock
> which may deadlock with the removal of the device that it is called
> for (the reason is that device sysfs attributes cannot be removed
> while their callbacks are being executed and ACPI device objects
> are removed under acpi_scan_lock).
>
> The problem is related to the fact that containers are handled by
> acpi_bus_device_eject() in a special way, which is to emit an
> offline uevent instead of just removing the container. Then, user
> space is expected to handle that uevent and use the container's
> "eject" attribute to actually remove it. That is fragile, because
> user space may fail to complete the ejection (for example, by not
> using the container's "eject" attribute at all) leaving the BIOS
> kind of in a limbo. Moreover, if the eject event is not signaled
> for a container itself, but for its parent device object (or
> generally, for an ancestor above it in the ACPI namespace), the
> container will be removed straight away without doing that whole
> dance.
>
> For this reason, modify acpi_bus_device_eject() to remove containers
> synchronously like any other objects (user space will get its uevent
> anyway in case it does some other things in response to it) and
> remove the eject_pending ACPI device flag that is not used any more.
> This way acpi_eject_store() doesn't have a reason to acquire
> acpi_scan_lock any more and one possible deadlock scenario goes
> away (plus the code is simplified a bit).
>
> Signed-off-by: Rafael J. Wysocki
> Reported-by: Gu Zheng
Tested-by: Gu Zheng
> ---
> drivers/acpi/scan.c | 49
> ++--
> include/acpi/acpi_bus.h |3 --
> 2 files changed, 16 insertions(+), 36 deletions(-)
>
> Index: linux-pm/drivers/acpi/scan.c
> ===
> --- linux-pm.orig/drivers/acpi/scan.c
> +++ linux-pm/drivers/acpi/scan.c
> @@ -287,6 +287,7 @@ static void acpi_bus_device_eject(void *
> struct acpi_device *device = NULL;
> struct acpi_scan_handler *handler;
> u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
> + int error;
>
> mutex_lock(&acpi_scan_lock);
>
> @@ -301,17 +302,13 @@ static void acpi_bus_device_eject(void *
> }
> acpi_evaluate_hotplug_ost(handle, ACPI_NOTIFY_EJECT_REQUEST,
> ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
> - if (handler->hotplug.mode == AHM_CONTAINER) {
> - device->flags.eject_pending = true;
> + if (handler->hotplug.mode == AHM_CONTAINER)
> kobject_uevent(&device->dev.kobj, KOBJ_OFFLINE);
> - } else {
> - int error;
>
> - get_device(&device->dev);
> - error = acpi_scan_hot_remove(device);
> - if (error)
> - goto err_out;
> - }
> + get_device(&device->dev);
> + error = acpi_scan_hot_remove(device);
> + if (error)
> + goto err_out;
>
> out:
> mutex_unlock(&acpi_scan_lock);
> @@ -496,7 +493,6 @@ acpi_eject_store(struct device *d, struc
> struct acpi_eject_event *ej_event;
> acpi_object_type not_used;
> acpi_status status;
> - u32 ost_source;
> int ret;
>
> if (!count || buf[0] != '1')
> @@ -510,43 +506,28 @@ acpi_eject_store(struct device *d, struc
> if (ACPI_FAILURE(status) || !acpi_device->flags.ejectable)
> return -ENODEV;
>
> - mutex_lock(&acpi_scan_lock);
> -
> - if (acpi_device->flags.eject_pending) {
> - /* ACPI eject notification event. */
> - ost_source = ACPI_NOTIFY_EJECT_REQUEST;
> - acpi_device->flags.eject_pending = 0;
> - } else {
> - /* Eject initiated by user space. */
> - ost_source = ACPI_OST_EC_OSPM_EJECT;
> - }
> ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
> if (!ej_event) {
> ret = -ENOMEM;
> goto err_out;
> }
> - acpi_evaluate_hotplug_ost(acpi_device->handle, ost_source,
> + acpi_evaluate_hotplug_ost(acpi_device->handle, ACPI_OST_EC_OSPM_EJECT,
> ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
> ej_event->device = acpi_device;
> - ej_event->event = ost_source;
> + ej_event->event = ACPI_OST_EC_OSPM_EJECT;
> get_device(&acpi_device->dev);
> status = acpi_os_hotplug_execute(acpi_bus_hot_remove_device, ej_event);
> - if (ACPI_FAILURE(status)) {
> - put_device(&acpi_device->dev);
> - kfree(ej_event);
> - ret = status == AE_NO_MEMORY ? -ENOMEM : -EAGAIN;
> - goto err_out;
> - }
> - ret = count;
> + if (ACPI_SUCCESS(status))
> + return count;
>
> - out:
> - mutex_unlock(&acpi_sca
Re: [PATCH 33/35] power: use dev_get_platdata()
On Wed, Aug 28, 2013 at 06:18:49PM -0700, Anton Vorontsov wrote: > On Wed, Aug 28, 2013 at 11:36:30AM +0300, Dan Carpenter wrote: > > He doesn't want to take the patch. He's the maintainer so it's his > > choice. That's the end of the story. > > Just to clarify: I don't want to take the patch for a reason, not just > because of my mood today. Once the patch comes in combination with another > patch (or a plan) that actually makes use of the wrapper function, then > I'd happily apply/ack it. > > This is the same story as global checkpatch.pl fixes: they are more harm > than good, and without the actual use of the dev_get_platdata(), the patch > falls into "global checkpatch.pl fixes" category. If you view this as a checkpatch.pl fixup, I'll be glad to take it through my tree instead, to ease the patch burden on you :) 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/
Re: [PATCH 0/2] driver core / ACPI: Avoid device removal locking problems
Hi Rafael, On 08/28/2013 09:45 PM, Rafael J. Wysocki wrote: > Hi All, > > The following two patches are to address possible deadlocks related to > device removal and device sysfs attribute access. In short, some device > sysfs attribute callbacks need to acquire locks that are also held around > device removal and that may lead to deadlocks with s_active draining in > sysfs_deactivate(). > > [1/2] Avoid possible device removal deadlocks related to device_hotplug_lock. > [2/2] Rework the handling of containers by ACPI hotplug (which makes a > possible > device removal deadlock related to acpi_scan_lock go away). > This version is concise and friendly. It works well on latest kernel tree, and all the splat goes away.:) Best regards, Gu > On top of linux-next, for v3.12. > > 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] pinctrl: pinconf-generic: Remove ti prefix in dev_err messages
It does not make sense to show ti prefix in pinconf_generic_dt_subnode_to_map()
dev_err messages.
Signed-off-by: Axel Lin
---
drivers/pinctrl/pinconf-generic.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinconf-generic.c
b/drivers/pinctrl/pinconf-generic.c
index 2c62225..55a0ebe 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -256,8 +256,7 @@ int pinconf_generic_dt_subnode_to_map(struct pinctrl_dev
*pctldev,
if (ret < 0) {
/* EINVAL=missing, which is fine since it's optional */
if (ret != -EINVAL)
- dev_err(dev,
- "could not parse property ti,function\n");
+ dev_err(dev, "could not parse property function\n");
function = NULL;
}
@@ -274,7 +273,7 @@ int pinconf_generic_dt_subnode_to_map(struct pinctrl_dev
*pctldev,
reserve++;
ret = of_property_count_strings(np, "pins");
if (ret < 0) {
- dev_err(dev, "could not parse property ti,pins\n");
+ dev_err(dev, "could not parse property pins\n");
goto exit;
}
reserve *= ret;
--
1.8.1.2
--
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] dm-lc: plan to go to staging
On Thu, Aug 29, 2013 at 10:35:35AM +0900, Akira Hayakawa wrote: > Hi, > > I am happy to see that dm-lc is picked up by LWN. > http://lwn.net/Articles/562938/ > > Now I think I should consider the next step forward. > > > As Joe Thornber said before, what I have to do next are > 1. Get some feedback from 3rd party users. > 2. Reviewed by Mike Snitzer. > As in > http://www.redhat.com/archives/dm-devel/2013-July/msg00137.html > > To achieve the first goal, > I am thinking of going to staging tree > for dm-lc to be widely available to people in community. > > dm-lc is now managed in Github repo as a kernel module > however, getting available in the tree means a lot > to get 3rd party users. > > Does this plan sound nice? > > If so, what is the next step to go to staging? > I have a patch against 3.11-rc7 in linux-next locally. > Sending the patch to Greg is the next step? > And who and what should be included in CC? That's fine with me. For staging drivers, I need a TODO file that lists what needs to be done to the code to get it into a mergable state for the "real" part of the kernel, and an email address to cc: patches on. Also, a MAINTAINERS entry is good as that way the scripts/get_maintainer.pl tool will properly pick up your email address. You should generate the patch against the linux-next tree, as I have lots of new staging drivers in there, ready for 3.12, and if you make a patch against 3.11-rc7, odds are it will not apply properly. If you have any other questions, please let me know. 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/
[PATCH v7 1/4] sg: use rwsem to solve race during exclusive open
A race condition may happen if two threads are both trying to open the same sg
with O_EXCL simultaneously. It's possible that they both find fsds list is
empty and get_exclude(sdp) returns 0, then they both call set_exclude() and
break out from wait_event_interruptible and resume open.
Now use rwsem to protect this process. Exclusive open gets write lock and
others get read lock. The lock will be held until file descriptor is closed.
This also leads 'exclude' only a status rather than a check mark.
Changes from v6:
* remove double if.
Changes from v5:
* remove unused variables
* fix insane code dealing with sg_add_sfp.
Signed-off-by: Vaughan Cao
---
drivers/scsi/sg.c | 79 +--
1 file changed, 41 insertions(+), 38 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index df5e961..4efa9b5 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -170,11 +170,11 @@ typedef struct sg_fd {/* holds the state of a
file descriptor */
typedef struct sg_device { /* holds the state of each scsi generic device */
struct scsi_device *device;
- wait_queue_head_t o_excl_wait; /* queue open() when O_EXCL in use */
int sg_tablesize; /* adapter's max scatter-gather table size */
u32 index; /* device index number */
/* sfds is protected by sg_index_lock */
struct list_head sfds;
+ struct rw_semaphore o_sem; /* exclude open should hold this rwsem
*/
volatile char detached; /* 0->attached, 1->detached pending removal */
/* exclude protected by sg_open_exclusive_lock */
char exclude; /* opened for exclusive access */
@@ -265,7 +265,6 @@ sg_open(struct inode *inode, struct file *filp)
struct request_queue *q;
Sg_device *sdp;
Sg_fd *sfp;
- int res;
int retval;
nonseekable_open(inode, filp);
@@ -294,35 +293,35 @@ sg_open(struct inode *inode, struct file *filp)
goto error_out;
}
- if (flags & O_EXCL) {
- if (O_RDONLY == (flags & O_ACCMODE)) {
- retval = -EPERM; /* Can't lock it with read only access
*/
- goto error_out;
- }
- if (!sfds_list_empty(sdp) && (flags & O_NONBLOCK)) {
- retval = -EBUSY;
- goto error_out;
- }
- res = wait_event_interruptible(sdp->o_excl_wait,
- ((!sfds_list_empty(sdp) ||
get_exclude(sdp)) ? 0 : set_exclude(sdp, 1)));
- if (res) {
- retval = res; /* -ERESTARTSYS because signal hit
process */
- goto error_out;
- }
- } else if (get_exclude(sdp)) { /* some other fd has an exclusive lock
on dev */
- if (flags & O_NONBLOCK) {
- retval = -EBUSY;
- goto error_out;
- }
- res = wait_event_interruptible(sdp->o_excl_wait,
!get_exclude(sdp));
- if (res) {
- retval = res; /* -ERESTARTSYS because signal hit
process */
- goto error_out;
+ if ((flags & O_EXCL) && (O_RDONLY == (flags & O_ACCMODE))) {
+ retval = -EPERM; /* Can't lock it with read only access */
+ goto error_out;
+ }
+ if (flags & O_NONBLOCK) {
+ if (flags & O_EXCL) {
+ if (!down_write_trylock(&sdp->o_sem)) {
+ retval = -EBUSY;
+ goto error_out;
+ }
+ } else {
+ if (!down_read_trylock(&sdp->o_sem)) {
+ retval = -EBUSY;
+ goto error_out;
+ }
}
+ } else {
+ if (flags & O_EXCL)
+ down_write(&sdp->o_sem);
+ else
+ down_read(&sdp->o_sem);
}
+ /* Since write lock is held, no need to check sfd_list */
+ if (flags & O_EXCL)
+ set_exclude(sdp, 1);
+
if (sdp->detached) {
retval = -ENODEV;
- goto error_out;
+ goto sem_out;
}
if (sfds_list_empty(sdp)) { /* no existing opens on this device */
sdp->sgdebug = 0;
@@ -331,17 +330,18 @@ sg_open(struct inode *inode, struct file *filp)
}
if ((sfp = sg_add_sfp(sdp, dev)))
filp->private_data = sfp;
+ /* retval is already provably zero at this point because of the
+* check after retval = scsi_autopm_get_device(sdp->device))
+*/
else {
+ retval = -ENOMEM;
+sem_out:
if (flags & O_EXCL) {
set_exclude(sdp, 0);
[PATCH v7 2/4] sg: no need sg_open_exclusive_lock
Open exclusive check is protected by o_sem, no need sg_open_exclusive_lock.
@exclude is used to record which type of rwsem we are holding.
Signed-off-by: Vaughan Cao
---
drivers/scsi/sg.c | 34 +-
1 file changed, 5 insertions(+), 29 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 4efa9b5..d4af132 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -105,8 +105,6 @@ static int scatter_elem_sz_prev = SG_SCATTER_SZ;
static int sg_add(struct device *, struct class_interface *);
static void sg_remove(struct device *, struct class_interface *);
-static DEFINE_SPINLOCK(sg_open_exclusive_lock);
-
static DEFINE_IDR(sg_index_idr);
static DEFINE_RWLOCK(sg_index_lock); /* Also used to lock
file descriptor list
for device */
@@ -176,7 +174,6 @@ typedef struct sg_device { /* holds the state of each scsi
generic device */
struct list_head sfds;
struct rw_semaphore o_sem; /* exclude open should hold this rwsem
*/
volatile char detached; /* 0->attached, 1->detached pending removal */
- /* exclude protected by sg_open_exclusive_lock */
char exclude; /* opened for exclusive access */
char sgdebug; /* 0->off, 1->sense, 9->dump dev, 10-> all devs
*/
struct gendisk *disk;
@@ -225,27 +222,6 @@ static int sg_allow_access(struct file *filp, unsigned
char *cmd)
return blk_verify_command(cmd, filp->f_mode & FMODE_WRITE);
}
-static int get_exclude(Sg_device *sdp)
-{
- unsigned long flags;
- int ret;
-
- spin_lock_irqsave(&sg_open_exclusive_lock, flags);
- ret = sdp->exclude;
- spin_unlock_irqrestore(&sg_open_exclusive_lock, flags);
- return ret;
-}
-
-static int set_exclude(Sg_device *sdp, char val)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&sg_open_exclusive_lock, flags);
- sdp->exclude = val;
- spin_unlock_irqrestore(&sg_open_exclusive_lock, flags);
- return val;
-}
-
static int sfds_list_empty(Sg_device *sdp)
{
unsigned long flags;
@@ -317,7 +293,7 @@ sg_open(struct inode *inode, struct file *filp)
}
/* Since write lock is held, no need to check sfd_list */
if (flags & O_EXCL)
- set_exclude(sdp, 1);
+ sdp->exclude = 1; /* used by release lock */
if (sdp->detached) {
retval = -ENODEV;
@@ -337,7 +313,7 @@ sg_open(struct inode *inode, struct file *filp)
retval = -ENOMEM;
sem_out:
if (flags & O_EXCL) {
- set_exclude(sdp, 0);/* undo if error */
+ sdp->exclude = 0; /* undo if error */
up_write(&sdp->o_sem);
} else
up_read(&sdp->o_sem);
@@ -364,8 +340,8 @@ sg_release(struct inode *inode, struct file *filp)
return -ENXIO;
SCSI_LOG_TIMEOUT(3, printk("sg_release: %s\n", sdp->disk->disk_name));
- excl = get_exclude(sdp);
- set_exclude(sdp, 0);
+ excl = sdp->exclude;
+ sdp->exclude = 0;
if (excl)
up_write(&sdp->o_sem);
else
@@ -2622,7 +2598,7 @@ static int sg_proc_seq_show_debug(struct seq_file *s,
void *v)
scsidp->lun,
scsidp->host->hostt->emulated);
seq_printf(s, " sg_tablesize=%d excl=%d\n",
- sdp->sg_tablesize, get_exclude(sdp));
+ sdp->sg_tablesize, sdp->exclude);
sg_proc_debug_helper(s, sdp);
}
read_unlock_irqrestore(&sg_index_lock, iflags);
--
1.8.3.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 v7 0/4][SCSI] sg: fix race condition in sg_open
There is a race when open sg with O_EXCL flag. Also a race may happen between sg_open and sg_remove. Changes from v6: * [1/4] remove double if. * [3/4] fix via IS_ERR Changes from v5: Patches based on v3.11-rc7 and passed sg_tst_excl test. * [1/4] * remove unused variables - res,sdp. * fix insane code dealing with sg_add_sfp. * [2/4] resolve conflict with v3.11-rc7. * [3/4] remove sem_out label. * [4/4] add sdp definition. Changes from v4: * [3/4] use ERR_PTR series instead of adding another parameter in sg_add_sfp * [4/4] fix conflict for cherry-pick from v3. Changes from v3: * release o_sem in sg_release(), not in sg_remove_sfp(). * not set exclude with sfd_lock held. Vaughan Cao (4): sg: use rwsem to solve race during exclusive open sg: no need sg_open_exclusive_lock sg: checking sdp->detached isn't protected when open sg: push file descriptor list locking down to per-device locking drivers/scsi/sg.c | 176 +- 1 file changed, 81 insertions(+), 95 deletions(-) -- 1.8.3.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 v7 4/4] sg: push file descriptor list locking down to per-device locking
Push file descriptor list locking down to per-device locking. Let sg_index_lock
only protect device lookup.
sdp->detached is also set and checked with this lock held.
Changes from v4:
* Since I use ERR_PTR and friends in sg_add_sfp, this patch should also be
updated to resolve conflict in cherrry-pick.
Signed-off-by: Vaughan Cao
---
drivers/scsi/sg.c | 62 ++-
1 file changed, 34 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 64df1ab..5cbc4bb 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -106,8 +106,7 @@ static int sg_add(struct device *, struct class_interface
*);
static void sg_remove(struct device *, struct class_interface *);
static DEFINE_IDR(sg_index_idr);
-static DEFINE_RWLOCK(sg_index_lock); /* Also used to lock
- file descriptor list
for device */
+static DEFINE_RWLOCK(sg_index_lock);
static struct class_interface sg_interface = {
.add_dev= sg_add,
@@ -144,8 +143,7 @@ typedef struct sg_request { /* SG_MAX_QUEUE requests
outstanding per file */
} Sg_request;
typedef struct sg_fd { /* holds the state of a file descriptor */
- /* sfd_siblings is protected by sg_index_lock */
- struct list_head sfd_siblings;
+ struct list_head sfd_siblings; /* protected by sfd_lock of device */
struct sg_device *parentdp; /* owning device */
wait_queue_head_t read_wait;/* queue read until command done */
rwlock_t rq_list_lock; /* protect access to list in req_arr */
@@ -170,7 +168,7 @@ typedef struct sg_device { /* holds the state of each scsi
generic device */
struct scsi_device *device;
int sg_tablesize; /* adapter's max scatter-gather table size */
u32 index; /* device index number */
- /* sfds is protected by sg_index_lock */
+ spinlock_t sfd_lock;/* protect file descriptor list for device */
struct list_head sfds;
struct rw_semaphore o_sem; /* exclude open should hold this rwsem
*/
volatile char detached; /* 0->attached, 1->detached pending removal */
@@ -227,9 +225,9 @@ static int sfds_list_empty(Sg_device *sdp)
unsigned long flags;
int ret;
- read_lock_irqsave(&sg_index_lock, flags);
+ spin_lock_irqsave(&sdp->sfd_lock, flags);
ret = list_empty(&sdp->sfds);
- read_unlock_irqrestore(&sg_index_lock, flags);
+ spin_unlock_irqrestore(&sdp->sfd_lock, flags);
return ret;
}
@@ -1393,6 +1391,7 @@ static Sg_device *sg_alloc(struct gendisk *disk, struct
scsi_device *scsidp)
disk->first_minor = k;
sdp->disk = disk;
sdp->device = scsidp;
+ spin_lock_init(&sdp->sfd_lock);
INIT_LIST_HEAD(&sdp->sfds);
init_rwsem(&sdp->o_sem);
sdp->sg_tablesize = queue_max_segments(q);
@@ -1527,11 +1526,13 @@ static void sg_remove(struct device *cl_dev, struct
class_interface *cl_intf)
/* Need a write lock to set sdp->detached. */
write_lock_irqsave(&sg_index_lock, iflags);
+ spin_lock(&sdp->sfd_lock);
sdp->detached = 1;
list_for_each_entry(sfp, &sdp->sfds, sfd_siblings) {
wake_up_interruptible(&sfp->read_wait);
kill_fasync(&sfp->async_qp, SIGPOLL, POLL_HUP);
}
+ spin_unlock(&sdp->sfd_lock);
write_unlock_irqrestore(&sg_index_lock, iflags);
sysfs_remove_link(&scsidp->sdev_gendev.kobj, "generic");
@@ -2056,13 +2057,13 @@ sg_add_sfp(Sg_device * sdp, int dev)
sfp->cmd_q = SG_DEF_COMMAND_Q;
sfp->keep_orphan = SG_DEF_KEEP_ORPHAN;
sfp->parentdp = sdp;
- write_lock_irqsave(&sg_index_lock, iflags);
+ spin_lock_irqsave(&sdp->sfd_lock, iflags);
if (sdp->detached) {
- write_unlock_irqrestore(&sg_index_lock, iflags);
+ spin_unlock_irqrestore(&sdp->sfd_lock, iflags);
return ERR_PTR(-ENODEV);
}
list_add_tail(&sfp->sfd_siblings, &sdp->sfds);
- write_unlock_irqrestore(&sg_index_lock, iflags);
+ spin_unlock_irqrestore(&sdp->sfd_lock, iflags);
SCSI_LOG_TIMEOUT(3, printk("sg_add_sfp: sfp=0x%p\n", sfp));
if (unlikely(sg_big_buff != def_reserved_size))
sg_big_buff = def_reserved_size;
@@ -2109,11 +2110,12 @@ static void sg_remove_sfp_usercontext(struct
work_struct *work)
static void sg_remove_sfp(struct kref *kref)
{
struct sg_fd *sfp = container_of(kref, struct sg_fd, f_ref);
+ struct sg_device *sdp = sfp->parentdp;
unsigned long iflags;
- write_lock_irqsave(&sg_index_lock, iflags);
+ spin_lock_irqsave(&sdp->sfd_lock, iflags);
list_del(&sfp->sfd_siblings);
- write_unlock_irqrestore(&sg_index_lock, iflags);
+ spin_unlock_irqrestore(&sdp->sfd_lock, iflags);
INIT_WORK(&sfp->ew.work, sg_remove_sfp_
[PATCH v7 3/4] sg: checking sdp->detached isn't protected when open
@detached is set under the protection of sg_index_lock. Without getting the
lock, new sfp will be added during sg removal and there is no chance for it
to be picked out. So check with sg_index_lock held in sg_add_sfp().
Changes from v6:
* fix via IS_ERR
Changes from v5:
* remove sem_out label.
Changes from v4:
* use ERR_PTR series instead of adding another parameter in sg_add_sfp
Signed-off-by: Vaughan Cao
---
drivers/scsi/sg.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index d4af132..64df1ab 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -295,23 +295,20 @@ sg_open(struct inode *inode, struct file *filp)
if (flags & O_EXCL)
sdp->exclude = 1; /* used by release lock */
- if (sdp->detached) {
- retval = -ENODEV;
- goto sem_out;
- }
if (sfds_list_empty(sdp)) { /* no existing opens on this device */
sdp->sgdebug = 0;
q = sdp->device->request_queue;
sdp->sg_tablesize = queue_max_segments(q);
}
- if ((sfp = sg_add_sfp(sdp, dev)))
+ sfp = sg_add_sfp(sdp, dev);
+ if (!IS_ERR(sfp))
filp->private_data = sfp;
/* retval is already provably zero at this point because of the
* check after retval = scsi_autopm_get_device(sdp->device))
*/
else {
- retval = -ENOMEM;
-sem_out:
+ retval = PTR_ERR(sfp);
+
if (flags & O_EXCL) {
sdp->exclude = 0; /* undo if error */
up_write(&sdp->o_sem);
@@ -2045,7 +2042,7 @@ sg_add_sfp(Sg_device * sdp, int dev)
sfp = kzalloc(sizeof(*sfp), GFP_ATOMIC | __GFP_NOWARN);
if (!sfp)
- return NULL;
+ return ERR_PTR(-ENOMEM);
init_waitqueue_head(&sfp->read_wait);
rwlock_init(&sfp->rq_list_lock);
@@ -2060,6 +2057,10 @@ sg_add_sfp(Sg_device * sdp, int dev)
sfp->keep_orphan = SG_DEF_KEEP_ORPHAN;
sfp->parentdp = sdp;
write_lock_irqsave(&sg_index_lock, iflags);
+ if (sdp->detached) {
+ write_unlock_irqrestore(&sg_index_lock, iflags);
+ return ERR_PTR(-ENODEV);
+ }
list_add_tail(&sfp->sfd_siblings, &sdp->sfds);
write_unlock_irqrestore(&sg_index_lock, iflags);
SCSI_LOG_TIMEOUT(3, printk("sg_add_sfp: sfp=0x%p\n", sfp));
--
1.8.3.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: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
(2013/08/28 23:42), Steven Rostedt wrote: On Wed, 28 Aug 2013 20:30:17 +0900 Yoshihiro YUNOMAE wrote: (2013/08/27 22:05), Steven Rostedt wrote: On Tue, 27 Aug 2013 19:23:24 +0900 Yoshihiro YUNOMAE wrote: OK, let me check that. Even if the old server will receive "V2", the server will send port numbers instead of "V2" due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Yep, that's exactly what I meant ;-) I tried to implement the feature, but I found that sending just "V2" from the new client is inappropriate. This is because the old server doesn't respond to the client before receiving cpu numbers, page size, and options. So, when the new client sends the first message, it should send "V2\0\00\0", I think. If so, the old server will understand the message as cpus=0, pagesize=, options=0, and then it will send port numbers(actually \0). Note if is zero, the old server will die. Can I implement the first message of the new client as "V2\0\00\0"? If it works for both old and new server with old and new client (and all combinations) I'm fine with it. OK, I'll submit trace-cmd patches as V2 in a few days. Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- 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 00/11] x86, memblock: Allocate memory near kernel image before SRAT parsed.
Hi Wanpeng, On 08/29/2013 09:36 AM, Wanpeng Li wrote: .. Hi tj, Sorry for the trouble. Please refer to the following branch: https://github.com/imtangchen/linux.git movablenode-boot-option Could you post your testcase? So I can test it on x86 and powerpc machines. Sure. Some simple testcases: 1. Boot the kernel without movablenode boot option, check if the memory mapping is initialized as before, high to low. 2. Boot the kernel with movablenode boot option, check if the memory mapping is initialized as before, low to high. 3. With movablenode, check if the memory allocation is from high to low after SRAT is parsed. 4. Check if we can do acpi_initrd_override normally with and without movablenode. And the memory allocation is from low to high, near the end of kernel image. 5. with movablenode, check if crashkernel boot option works normally. (This may consume a lot of memory, but should work normally.) 6. With movablenode, check if relocate_initrd() works normally. (This may consume a lot of memory, but should work normally.) 7. With movablenode, check if kexec could locate the kernel to higher memory. (This may consume hotplug memory if higher memory is hotpluggable, but should work normally.) Please do the above tests with and without the following config options: 1. CONFIG_MOVABLE_NODE 2. CONFIG_ACPI_INITRD_OVERRIDE Thanks for the testing. -- 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] ARC: Fix __udelay parentheses
On Wed, 2013-08-28 at 19:12 +, Mischa Jonker wrote: > Hello Joe, > > > I don't see the loops_per_jiffy initial shift << 32. > > loops_per_jiffy * HZ = loops_per_second > loops_per_jiffy * HZ = 1,000,000 * loops_per_us > loops_per_jiffy * HZ * 4295 = 4,295,000 * loops_per_us > > loops_per_jiffy * HZ * 4294.967296 = 2^32 * loops_per_us > > > > > > - loops = ((long long)(usecs * 4295 * HZ) * > > > > > - (long long)(loops_per_jiffy)) >> 32; > > > > > + loops = (((long long) usecs) * 4295 * HZ * > > > > > + (long long) loops_per_jiffy) >> 32; > > > > > I know that. It's the use of a signed long long vs the unsigned long long > > that I think wrong. > > Yes that is wrong too. > > > > > Why cast a unsigned to a signed? > > I don't know, this was in the original file. The issue that I was trying to > solve, was that usleep didn't sleep long enough, and that is fixed by this > patch. > > Wrt signed/unsigned: would you like me to update this patch or create a > separate one? I think the whole thing is odd and it should simply be loops = loops_per_jiffy * usecs_to_jiffies(usecs); and if it's really necessary to have a u64 delay then __delay should be rewritten to take an one as an argument and this calc should be: u64 loops = (u64)loops_per_jiffy * usecs_to_jiffies(usecs); -- 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: [GIT PULL] Expand keyring capacity and provide support for libkrb5
On Thu, 29 Aug 2013, David Howells wrote: > > Hi James, > > Could you pull these patches into the security tree? 944 files changed, 17114 insertions(+), 9157 deletions(-) How about no? :) > > The patches can be viewed as three sets: > > (1) KEYS: Skip key state checks when checking for possession > > This is a fix for determining the possessed status of keys that have been > invalidated or revoked or that have expired. If nothing else, can you > please pick this and pass it upstream. > > (2) KEYS: Expand the capacity of a keyring > Add a generic associative array implementation > KEYS: Drop the permissions argument from __keyring_search_one() > KEYS: Define a __key_get() wrapper to use rather than atomic_inc() > KEYS: Search for auth-key by name rather than target key ID > KEYS: Introduce a search context structure > KEYS: Consolidate the concept of an 'index key' for key access > KEYS: key_is_dead() should take a const key pointer argument > KEYS: Use bool in make_key_ref() and is_key_possessed() > > Patches to to expand the capacity of a keyring by using an associative > array rather than a flat list and patches to do some preparatory cleanups > for those. > > (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos > caches > KEYS: Implement a big key type that can save to tmpfs > > Patches to add better support for libkrb5 to save its tokens in a kernel > keyring rather than in files. It already has this ability to some > extent, but that has two problems: your tokens get deleted when you log > out (so your cron jobs can't use them) and the capacity of a user type > key is not sufficient for some of the huge Kerberos tickets one can get. > These patches address that. > > If you need the patches basing on your tree instead, that can be done. > > David > --- > The following changes since commit f1d6e17f540af37bb1891480143669ba7636c4cf: > > Merge branch 'akpm' (patches from Andrew Morton) (2013-08-14 10:04:43 -0700) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > tags/keys-krb-support > > for you to fetch changes up to 0f8d966ebc86d7ab9fb7fd074ae589c2d81de08f: > > KEYS: Add per-user_namespace registers for persistent per-UID kerberos > caches (2013-08-28 18:56:14 +0100) > > > (from the branch description for keys-devel local branch) > > clone of "master" > Kerberos ticket persistence support > > > David Howells (12): > KEYS: Skip key state checks when checking for possession > KEYS: Use bool in make_key_ref() and is_key_possessed() > KEYS: key_is_dead() should take a const key pointer argument > KEYS: Consolidate the concept of an 'index key' for key access > KEYS: Introduce a search context structure > KEYS: Search for auth-key by name rather than target key ID > KEYS: Define a __key_get() wrapper to use rather than atomic_inc() > KEYS: Drop the permissions argument from __keyring_search_one() > Add a generic associative array implementation. > KEYS: Expand the capacity of a keyring > KEYS: Implement a big key type that can save to tmpfs > KEYS: Add per-user_namespace registers for persistent per-UID kerberos > caches > > Documentation/assoc_array.txt| 574 + > Documentation/security/keys.txt | 20 +- > include/keys/big_key-type.h | 25 + > include/keys/keyring-type.h | 17 +- > include/linux/assoc_array.h | 92 ++ > include/linux/assoc_array_priv.h | 182 > include/linux/key-type.h |5 + > include/linux/key.h | 49 +- > include/linux/user_namespace.h |6 + > include/uapi/linux/keyctl.h |1 + > kernel/user.c|4 + > kernel/user_namespace.c |4 + > lib/Kconfig | 14 + > lib/Makefile |1 + > lib/assoc_array.c| 1745 > ++ > security/keys/Kconfig| 29 + > security/keys/Makefile |2 + > security/keys/big_key.c | 204 + > security/keys/compat.c |3 + > security/keys/gc.c | 33 +- > security/keys/internal.h | 74 +- > security/keys/key.c | 91 +- > security/keys/keyctl.c |3 + > security/keys/keyring.c | 1481 > security/keys/persistent.c | 169 > security/keys/proc.c | 17 +- > security/keys/process_keys.c | 131 +-- > security/keys/request_key.c | 56 +- > security/keys/request_key_auth.c | 31 +- > security/keys/sysctl.c | 11 + > security/keys/user_def
[PATCH v2] cpuidle: coupled: abort idle if pokes are pending
Joseph Lo reported a lockup on Tegra20 caused
by a race condition in coupled cpuidle. When two or more cpus
enter idle at the same time, the first cpus to arrive may go to the
ready loop without processing pending pokes from the last cpu to
arrive.
This patch adds a check for pending pokes once all cpus have been
synchronized in the ready loop and resets the coupled state and
retries if any cpus failed to handle their pending poke.
Retrying on all cpus may trigger the same issue again, so this patch
also adds a check to ensure that each cpu has received at least one
poke between when it enters the waiting loop and when it moves on to
the ready loop.
Reported-by: Joseph Lo
Tested-by: Stephen Warren
Tested-by: Joseph Lo
Signed-off-by: Colin Cross
---
drivers/cpuidle/coupled.c | 107 +++---
1 file changed, 82 insertions(+), 25 deletions(-)
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 73497da..c72b3bc 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -106,6 +106,7 @@ struct cpuidle_coupled {
cpumask_t coupled_cpus;
int requested_state[NR_CPUS];
atomic_t ready_waiting_counts;
+ atomic_t abort_barrier;
int online_count;
int refcnt;
int prevent;
@@ -122,12 +123,19 @@ static DEFINE_MUTEX(cpuidle_coupled_lock);
static DEFINE_PER_CPU(struct call_single_data, cpuidle_coupled_poke_cb);
/*
- * The cpuidle_coupled_poked_mask mask is used to avoid calling
+ * The cpuidle_coupled_poke_pending mask is used to avoid calling
* __smp_call_function_single with the per cpu call_single_data struct already
* in use. This prevents a deadlock where two cpus are waiting for each others
* call_single_data struct to be available
*/
-static cpumask_t cpuidle_coupled_poked_mask;
+static cpumask_t cpuidle_coupled_poke_pending;
+
+/*
+ * The cpuidle_coupled_poked mask is used to ensure that each cpu has been
poked
+ * once to minimize entering the ready loop with a poke pending, which would
+ * require aborting and retrying.
+ */
+static cpumask_t cpuidle_coupled_poked;
/**
* cpuidle_coupled_parallel_barrier - synchronize all online coupled cpus
@@ -291,10 +299,11 @@ static inline int cpuidle_coupled_get_state(struct
cpuidle_device *dev,
return state;
}
-static void cpuidle_coupled_poked(void *info)
+static void cpuidle_coupled_handle_poke(void *info)
{
int cpu = (unsigned long)info;
- cpumask_clear_cpu(cpu, &cpuidle_coupled_poked_mask);
+ cpumask_set_cpu(cpu, &cpuidle_coupled_poked);
+ cpumask_clear_cpu(cpu, &cpuidle_coupled_poke_pending);
}
/**
@@ -313,7 +322,7 @@ static void cpuidle_coupled_poke(int cpu)
{
struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
- if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
+ if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poke_pending))
__smp_call_function_single(cpu, csd, 0);
}
@@ -340,30 +349,19 @@ static void cpuidle_coupled_poke_others(int this_cpu,
* @coupled: the struct coupled that contains the current cpu
* @next_state: the index in drv->states of the requested state for this cpu
*
- * Updates the requested idle state for the specified cpuidle device,
- * poking all coupled cpus out of idle if necessary to let them see the new
- * state.
+ * Updates the requested idle state for the specified cpuidle device.
+ * Returns the number of waiting cpus.
*/
-static void cpuidle_coupled_set_waiting(int cpu,
+static int cpuidle_coupled_set_waiting(int cpu,
struct cpuidle_coupled *coupled, int next_state)
{
- int w;
-
coupled->requested_state[cpu] = next_state;
/*
-* If this is the last cpu to enter the waiting state, poke
-* all the other cpus out of their waiting state so they can
-* enter a deeper state. This can race with one of the cpus
-* exiting the waiting state due to an interrupt and
-* decrementing waiting_count, see comment below.
-*
* The atomic_inc_return provides a write barrier to order the write
* to requested_state with the later write that increments ready_count.
*/
- w = atomic_inc_return(&coupled->ready_waiting_counts) & WAITING_MASK;
- if (w == coupled->online_count)
- cpuidle_coupled_poke_others(cpu, coupled);
+ return atomic_inc_return(&coupled->ready_waiting_counts) & WAITING_MASK;
}
/**
@@ -418,13 +416,24 @@ static void cpuidle_coupled_set_done(int cpu, struct
cpuidle_coupled *coupled)
static int cpuidle_coupled_clear_pokes(int cpu)
{
local_irq_enable();
- while (cpumask_test_cpu(cpu, &cpuidle_coupled_poked_mask))
+ while (cpumask_test_cpu(cpu, &cpuidle_coupled_poke_pending))
cpu_relax();
local_irq_disable();
return need_resched() ? -EINTR : 0;
}
+static bool cpuidle_
Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount
Just FYI: I've merged two preparatory patches in my tree for the whole lockref thing. Instead of applying your four patches as-is during the merge window, I ended up writing two patches that introduce the concept and use it in the dentry code *without* introducing any of the new semantics yet. Waiman, I attributed the patches to you, even if they don't actually look much like any of the patches you sent out. And because I was trying very hard to make sure that no actual semantics changed, my version doesn't have the dget_parent() lockless update code, for example. I literally just did a search-and-replace of "->d_count" with "->d_lockref.count" and then I fixed up a few things by hand (undid one replacement in a comment, and used the helper functions where they were semantically identical). You don't have to rewrite your patches if you don't want to, I'm planning on cherry-picking the actual code changes during the merge window. Linus -- 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/
[RFC] dm-lc: plan to go to staging
Hi, I am happy to see that dm-lc is picked up by LWN. http://lwn.net/Articles/562938/ Now I think I should consider the next step forward. As Joe Thornber said before, what I have to do next are 1. Get some feedback from 3rd party users. 2. Reviewed by Mike Snitzer. As in http://www.redhat.com/archives/dm-devel/2013-July/msg00137.html To achieve the first goal, I am thinking of going to staging tree for dm-lc to be widely available to people in community. dm-lc is now managed in Github repo as a kernel module however, getting available in the tree means a lot to get 3rd party users. Does this plan sound nice? If so, what is the next step to go to staging? I have a patch against 3.11-rc7 in linux-next locally. Sending the patch to Greg is the next step? And who and what should be included in CC? For your information, there is a precedent that DM target gets in staging tree. That is enhanceio, also a caching target. Any comments will be appreciated. Thanks, Akira -- 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 v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
Hi George,
You didn't modify this patchset about my comment on v1 patchset.
Please pay attention to comment.
On 08/29/2013 02:33 AM, George Cherian wrote:
> Add a generic USB VBUS/ID detection EXTCON driver. This driver expects
> the ID/VBUS pin are connected via GPIOs. This driver is tested on
> DRA7x board were the ID pin is routed via GPIOs. The driver supports
> both VBUS and ID pin configuration and ID pin only configuration.
>
> Signed-off-by: George Cherian
> ---
> .../bindings/extcon/extcon-gpio-usbvid.txt | 20 ++
> drivers/extcon/Kconfig | 6 +
> drivers/extcon/Makefile| 1 +
> drivers/extcon/extcon-gpio-usbvid.c| 286
> +
You should keep following naming stlye. extcon-gpio-usbvid.c is wrong naming
style.
- extcon-[device name].c
- extcon-gpio-usbvid.c -> extcon-dra7xx.c or etc.
Also, you should change the file name of extcon-gpio-usbvid.txt.
Finally, You used 'gpio_usbvid' prefix in extcon-gpio-usbvid.c.
It has caused the confusion that user would think extcon-gpio-usbvid.c driver
support all of extcon driver using gpio irq pin. So I'd like you to use
proper prefix including device name.
> 4 files changed, 313 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
> create mode 100644 drivers/extcon/extcon-gpio-usbvid.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
> b/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
> new file mode 100644
> index 000..eea0741
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio-usbvid.txt
> @@ -0,0 +1,20 @@
> +EXTCON FOR USB VIA GPIO
> +
> +Required Properties:
> + - compatible : Should be "ti,gpio-usb-vid" for USB VBUS-ID detector
> + using gpios or "ti,gpio-usb-id" for USB ID pin detector
> + - gpios : phandle and args ID pin gpio and VBUS gpio.
> +The first gpio used for ID pin detection
> +and the second used for VBUS detection.
> +ID pin gpio is mandatory and VBUS is optional
> +depending on implementation.
> +
> +Please refer to ../gpio/gpio.txt for details of the common GPIO bindings
> +
> +Example:
> +
> + gpio_usbvid_extcon1 {
> + compatible = "ti,gpio-usb-vid";
> + gpios = <&gpio1 1 0>,
> + <&gpio2 2 0>;
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index f1d54a3..8097398 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -64,4 +64,10 @@ config EXTCON_PALMAS
> Say Y here to enable support for USB peripheral and USB host
> detection by palmas usb.
>
> +config EXTCON_GPIO_USBVID
> + tristate "Generic USB VBUS/ID detection using GPIO EXTCON support"
> + help
> + Say Y here to enable support for USB VBUS/ID deetction by GPIO.
> +
> +
Remove blank line.
> endif # MULTISTATE_SWITCH
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index e4fa8ba..0451f698 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> +obj-$(CONFIG_EXTCON_GPIO_USBVID) += extcon-gpio-usbvid.o
> diff --git a/drivers/extcon/extcon-gpio-usbvid.c
> b/drivers/extcon/extcon-gpio-usbvid.c
> new file mode 100644
> index 000..e9bc2a97
> --- /dev/null
> +++ b/drivers/extcon/extcon-gpio-usbvid.c
> @@ -0,0 +1,286 @@
> +/*
> + * Generic USB VBUS-ID pin detection driver
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Author: George Cherian
> + *
> + * Based on extcon-palmas.c
> + *
> + * Author: Kishon Vijay Abraham I
> + *
> + * This program is distributed in the hope that 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
kthead.h, freezer.h headerfile is used in this file?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Order headerfile alphabetically.
> +
> +struct gpio_usbvid {
> + struct device *dev;
> +
> + struct extcon_dev edev;
> +
> + /*GPIO pin */
I commented previous your patch about this wrong coding style.
Why did not you fix this coding style?
> + int id_gpio;
> + int vbus_gpio;
> +
> + int id_irq;
>
[PATCH] of/irq: Provide struct device_node forward-declaration for !OF case
The patch fixes the following warnings:
CC drivers/power/bq24190_charger.o
In file included from drivers/power/bq24190_charger.c:14:0:
include/linux/of_irq.h:82:7: warning: ‘struct device_node’ declared
inside parameter list [enabled by default]
include/linux/of_irq.h:82:7: warning: its scope is only this definition
or declaration, which is probably not what you want [enabled by default]
include/linux/of_irq.h:87:118: warning: ‘struct device_node’ declared
inside parameter list [enabled by default]
Signed-off-by: Anton Vorontsov
---
include/linux/of_irq.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 535cecf..988d5c9 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -78,6 +78,9 @@ extern void of_irq_init(const struct of_device_id *matches);
#endif /* CONFIG_OF_IRQ */
#else /* !CONFIG_OF */
+
+struct device_node;
+
static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
int index)
{
--
1.8.1.4
--
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 net-next 1/1] net: neighbour: Simplify ifdefs around neigh_app_ns()
Joe Perches writes:
> On Wed, 2013-08-28 at 13:09 -0600, Tim Gardner wrote:
>> On 08/28/2013 12:51 PM, Joe Perches wrote:
>> > On Wed, 2013-08-28 at 12:24 -0600, Tim Gardner wrote:
>> >> Drop a couple of ifdef/endif pairs by moving the ifdef
>> >> surrounding neigh_app_ns() to the interior of neigh_app_ns().
>> > []
>> >> This is an admittedly trivial change. I stumbled on it while trying to
>> >> figure
>> >> out why Ubuntu doesn't have CONFIG_ARPD enabled.
>
>> > I'd be more inclined to make neigh_app_ns static inline
>> > in the .h file and remove the EXPORT_SYMBOL
>
>> I thought about that as well, but then you'd have to extern
>> __neigh_notify(), which is currently a static function and large enough
>> to not really be suitable for inlining. Seems like unnecessary churn to me.
>
> Hi Tim.
>
> As is, this makes the call to neight_app_ns
> impossible to optimize away.
>
> Perhaps this:
>
> (this does add a possibly unused neigh_notify as a global symbol)
>
> Rename __neigh_notify to neigh_notify and make public
> Add static inline neigh_app_ns
> Remove #ifdefs around use of neigh_app_ns
Again. Why not just remove CONFIG_ARPD entirely? A config option to
compile out a single line of code seems like a real waste.
Eric
> ---
>
> Compile tested only
>
> include/net/neighbour.h | 10 +-
> net/core/neighbour.c| 15 +++
> net/ipv4/arp.c | 2 --
> net/ipv6/ndisc.c| 2 --
> 4 files changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/include/net/neighbour.h b/include/net/neighbour.h
> index 536501a..a08b0a7 100644
> --- a/include/net/neighbour.h
> +++ b/include/net/neighbour.h
> @@ -249,7 +249,15 @@ static inline struct net *pneigh_net(const struct
> pneigh_entry *pneigh)
> return read_pnet(&pneigh->net);
> }
>
> -void neigh_app_ns(struct neighbour *n);
> +void neigh_notify(struct neighbour *n, int type, int flags);
> +
> +static inline void neigh_app_ns(struct neighbour *n)
> +{
> +#ifdef CONFIG_ARPD
> + neigh_notify(n, RTM_GETNEIGH, NLM_F_REQUEST);
> +#endif
> +}
> +
> void neigh_for_each(struct neigh_table *tbl,
> void (*cb)(struct neighbour *, void *), void *cookie);
> void __neigh_for_each_release(struct neigh_table *tbl,
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 60533db..6ec5f86 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -50,7 +50,6 @@ do {\
> #define PNEIGH_HASHMASK 0xF
>
> static void neigh_timer_handler(unsigned long arg);
> -static void __neigh_notify(struct neighbour *n, int type, int flags);
> static void neigh_update_notify(struct neighbour *neigh);
> static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev);
>
> @@ -103,7 +102,7 @@ static void neigh_cleanup_and_release(struct neighbour
> *neigh)
> if (neigh->parms->neigh_cleanup)
> neigh->parms->neigh_cleanup(neigh);
>
> - __neigh_notify(neigh, RTM_DELNEIGH, 0);
> + neigh_notify(neigh, RTM_DELNEIGH, 0);
> neigh_release(neigh);
> }
>
> @@ -2215,7 +2214,7 @@ nla_put_failure:
> static void neigh_update_notify(struct neighbour *neigh)
> {
> call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
> - __neigh_notify(neigh, RTM_NEWNEIGH, 0);
> + neigh_notify(neigh, RTM_NEWNEIGH, 0);
> }
>
> static int neigh_dump_table(struct neigh_table *tbl, struct sk_buff *skb,
> @@ -2735,7 +2734,7 @@ static inline size_t neigh_nlmsg_size(void)
> + nla_total_size(4); /* NDA_PROBES */
> }
>
> -static void __neigh_notify(struct neighbour *n, int type, int flags)
> +void neigh_notify(struct neighbour *n, int type, int flags)
> {
> struct net *net = dev_net(n->dev);
> struct sk_buff *skb;
> @@ -2759,14 +2758,6 @@ errout:
> rtnl_set_sk_err(net, RTNLGRP_NEIGH, err);
> }
>
> -#ifdef CONFIG_ARPD
> -void neigh_app_ns(struct neighbour *n)
> -{
> - __neigh_notify(n, RTM_GETNEIGH, NLM_F_REQUEST);
> -}
> -EXPORT_SYMBOL(neigh_app_ns);
> -#endif /* CONFIG_ARPD */
> -
> #ifdef CONFIG_SYSCTL
> static int zero;
> static int int_max = INT_MAX;
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index 4429b01..7808093 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -368,9 +368,7 @@ static void arp_solicit(struct neighbour *neigh, struct
> sk_buff *skb)
> } else {
> probes -= neigh->parms->app_probes;
> if (probes < 0) {
> -#ifdef CONFIG_ARPD
> neigh_app_ns(neigh);
> -#endif
> return;
> }
> }
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 04d31c2..d5693ad 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -663,9 +663,7 @@ static void ndisc_solicit(struct neighbour *neigh, struct
> sk_buff *skb)
> }
> ndisc_send_ns(dev, neigh, target, target, saddr);
> } else if ((probes -= neigh->parms->app_pr
Re: [PATCH 00/11] x86, memblock: Allocate memory near kernel image before SRAT parsed.
On 08/28/2013 11:19 PM, Tejun Heo wrote: .. Doesn't apply to -master, -next or tip. Again, can you please include which tree and git commit the patches are against in the patch description? How is one supposed to know on top of which tree you're working? It is in your benefit to make things easier for the prosepct reviewers. Trying to guess and apply the patches to different devel branches and failing isn't productive and frustates your prospect reviewers who would of course have negative pre-perception going into the review and this isn't the first time this issue was raised either. Hi tj, Sorry for the trouble. Please refer to the following branch: https://github.com/imtangchen/linux.git movablenode-boot-option 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 net-next 1/1] net: neighbour: Simplify ifdefs around neigh_app_ns()
On Wed, 2013-08-28 at 13:09 -0600, Tim Gardner wrote:
> On 08/28/2013 12:51 PM, Joe Perches wrote:
> > On Wed, 2013-08-28 at 12:24 -0600, Tim Gardner wrote:
> >> Drop a couple of ifdef/endif pairs by moving the ifdef
> >> surrounding neigh_app_ns() to the interior of neigh_app_ns().
> > []
> >> This is an admittedly trivial change. I stumbled on it while trying to
> >> figure
> >> out why Ubuntu doesn't have CONFIG_ARPD enabled.
> > I'd be more inclined to make neigh_app_ns static inline
> > in the .h file and remove the EXPORT_SYMBOL
> I thought about that as well, but then you'd have to extern
> __neigh_notify(), which is currently a static function and large enough
> to not really be suitable for inlining. Seems like unnecessary churn to me.
Hi Tim.
As is, this makes the call to neight_app_ns
impossible to optimize away.
Perhaps this:
(this does add a possibly unused neigh_notify as a global symbol)
Rename __neigh_notify to neigh_notify and make public
Add static inline neigh_app_ns
Remove #ifdefs around use of neigh_app_ns
---
Compile tested only
include/net/neighbour.h | 10 +-
net/core/neighbour.c| 15 +++
net/ipv4/arp.c | 2 --
net/ipv6/ndisc.c| 2 --
4 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 536501a..a08b0a7 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -249,7 +249,15 @@ static inline struct net *pneigh_net(const struct
pneigh_entry *pneigh)
return read_pnet(&pneigh->net);
}
-void neigh_app_ns(struct neighbour *n);
+void neigh_notify(struct neighbour *n, int type, int flags);
+
+static inline void neigh_app_ns(struct neighbour *n)
+{
+#ifdef CONFIG_ARPD
+ neigh_notify(n, RTM_GETNEIGH, NLM_F_REQUEST);
+#endif
+}
+
void neigh_for_each(struct neigh_table *tbl,
void (*cb)(struct neighbour *, void *), void *cookie);
void __neigh_for_each_release(struct neigh_table *tbl,
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 60533db..6ec5f86 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -50,7 +50,6 @@ do { \
#define PNEIGH_HASHMASK0xF
static void neigh_timer_handler(unsigned long arg);
-static void __neigh_notify(struct neighbour *n, int type, int flags);
static void neigh_update_notify(struct neighbour *neigh);
static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev);
@@ -103,7 +102,7 @@ static void neigh_cleanup_and_release(struct neighbour
*neigh)
if (neigh->parms->neigh_cleanup)
neigh->parms->neigh_cleanup(neigh);
- __neigh_notify(neigh, RTM_DELNEIGH, 0);
+ neigh_notify(neigh, RTM_DELNEIGH, 0);
neigh_release(neigh);
}
@@ -2215,7 +2214,7 @@ nla_put_failure:
static void neigh_update_notify(struct neighbour *neigh)
{
call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
- __neigh_notify(neigh, RTM_NEWNEIGH, 0);
+ neigh_notify(neigh, RTM_NEWNEIGH, 0);
}
static int neigh_dump_table(struct neigh_table *tbl, struct sk_buff *skb,
@@ -2735,7 +2734,7 @@ static inline size_t neigh_nlmsg_size(void)
+ nla_total_size(4); /* NDA_PROBES */
}
-static void __neigh_notify(struct neighbour *n, int type, int flags)
+void neigh_notify(struct neighbour *n, int type, int flags)
{
struct net *net = dev_net(n->dev);
struct sk_buff *skb;
@@ -2759,14 +2758,6 @@ errout:
rtnl_set_sk_err(net, RTNLGRP_NEIGH, err);
}
-#ifdef CONFIG_ARPD
-void neigh_app_ns(struct neighbour *n)
-{
- __neigh_notify(n, RTM_GETNEIGH, NLM_F_REQUEST);
-}
-EXPORT_SYMBOL(neigh_app_ns);
-#endif /* CONFIG_ARPD */
-
#ifdef CONFIG_SYSCTL
static int zero;
static int int_max = INT_MAX;
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 4429b01..7808093 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -368,9 +368,7 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
} else {
probes -= neigh->parms->app_probes;
if (probes < 0) {
-#ifdef CONFIG_ARPD
neigh_app_ns(neigh);
-#endif
return;
}
}
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 04d31c2..d5693ad 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -663,9 +663,7 @@ static void ndisc_solicit(struct neighbour *neigh, struct
sk_buff *skb)
}
ndisc_send_ns(dev, neigh, target, target, saddr);
} else if ((probes -= neigh->parms->app_probes) < 0) {
-#ifdef CONFIG_ARPD
neigh_app_ns(neigh);
-#endif
} else {
addrconf_addr_solict_mult(target, &mcaddr);
ndisc_send_ns(dev, NULL, target, &mcaddr, saddr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
[PATCH] mm/mmap: remove unnecessary assignment
From: Yanchuan Nian
pgoff is not used after the statement "pgoff = vma->vm_pgoff;",
so the assignment is redundant.
Signed-off-by: Yanchuan Nian
---
mm/mmap.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 2664a47..e7d7231 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1508,7 +1508,6 @@ munmap_back:
WARN_ON_ONCE(addr != vma->vm_start);
addr = vma->vm_start;
- pgoff = vma->vm_pgoff;
vm_flags = vma->vm_flags;
} else if (vm_flags & VM_SHARED) {
if (unlikely(vm_flags & (VM_GROWSDOWN|VM_GROWSUP)))
--
1.7.4.4
--
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 33/35] power: use dev_get_platdata()
On Wed, Aug 28, 2013 at 11:36:30AM +0300, Dan Carpenter wrote: > He doesn't want to take the patch. He's the maintainer so it's his > choice. That's the end of the story. Just to clarify: I don't want to take the patch for a reason, not just because of my mood today. Once the patch comes in combination with another patch (or a plan) that actually makes use of the wrapper function, then I'd happily apply/ack it. This is the same story as global checkpatch.pl fixes: they are more harm than good, and without the actual use of the dev_get_platdata(), the patch falls into "global checkpatch.pl fixes" category. Thanks, Anton -- 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: [GIT PULL] at91: soc update for 3.12 #1
Hi Olof, On 08/29/2013 07:58 AM, Olof Johansson wrote: On Mon, Aug 26, 2013 at 05:55:43PM +0200, Nicolas Ferre wrote: Arnd, Olof, Kevin, Here is AT91 SoC updates for 3.12 kernel. It is the first pull-request for this topic and it is based on 3.11-rc5 like your next/soc branch. Thanks, best regards, The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://github.com/at91linux/linux-at91.git tags/at91-soc for you to fetch changes up to 99eb3b40ec42e7fce1fc58429bf9b26c17973c12: ARM: at91: at91_dt_defconfig: enable rm9200 support (2013-08-26 09:58:29 +0200) AT91 SoC update for 3.12 take 1 - enable kernel uncompress information output for SoC where it was missing: at91sam9n12 and sama5d3 - addition of at91rm9200 to the generic at91_dt_defconfig Jean-Christophe PLAGNIOL-VILLARD (1): ARM: at91: at91_dt_defconfig: enable rm9200 support voice (4): ARM: at91: sama5d3: add definition for usart base address ARM: at91: include sama5d3.h into hardware.h ARM: at91: sama5: enable kernel uncompress info output ARM: at91: sam9n12: enable kernel uncompress info output That doesn't look right. Author should probably be "Bo Shen " instead. Can you fixup and respin, please? I don't know why on the patchwork it show my name as voice. So, if get patch from patchwork and apply it will show my name as voice. So, would it be possible to show the name as Bo Shen on patchwork? -Olof Best Regards, Bo Shen -- 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] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}
Kees Cook writes: > On Wed, Aug 28, 2013 at 5:26 PM, Eric W. Biederman > wrote: >> Can someome please state what they are worried about in simple language >> step by step? >> [...] >> The closest I saw in the thread was people were worried about ASLR being >> defeated. All I see are kernel addresses and we don't have much if any >> runtime or even load time randomization of where code is located in the >> kernel address map on x86_64. So I don't understand the concern. > > I showed the output of "syscall", since that contains user-space > addresses and shows a leak of ASLR from a privileged process to an > unprivileged process. > > The flaw as I see it is that an unprivileged process opens > /proc/$priv_pid/syscall and passes it to a setuid process which is > able to read it, and provides those contents to the unprivileged > process. > > The unprivileged process should not be able to the open the file in > the first place. I see so the complaint is that we don't give read permission but we do give open permission.Which is a variant of: the permissions used to open are not the permission used to access the file. This does seem to be a legitimate concern. I think there are several discussions that have been going on lately with respect to this class of problems in proc files. Given the existence of suid exec we can not in general prevent this class of bugs with a check at open time. I believe the solution needs to be to enhance the ptrace_may_access checks to verify that both the creds of the current task and the creds of the opening process would have allowed the access. We may want to put this check in permission so open fails quickly but we absolutely need to put this check in at the time we call ptrace_may_access. Eric -- 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] audit: avoid soft lockup in audit_log_start()
On Wed, 28 Aug 2013 16:08:13 -0700
Andrew Morton wrote:
> On Wed, 28 Aug 2013 18:54:36 -0400 Luiz Capitulino
> wrote:
>
> > > Are you really sure that kauditd is stuck in schedule() and doesn't
> > > come out?
> >
> > No, that's a guess. Inferred from:
> >
> > 1. I tried calling wake_up_interruptible(&kauditd_wait); right
> >before wait_for_auditd(). Nothing changes
> >
> > 2. I added this debug printks:
> >
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 91e53d0..27448ad 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -458,11 +458,14 @@ static int kauditd_thread(void *dummy)
> > set_current_state(TASK_INTERRUPTIBLE);
> > add_wait_queue(&kauditd_wait, &wait);
> >
> > + pr_emerg_ratelimited("*** sleeping\n");
> > +
> > if (!skb_queue_len(&audit_skb_queue)) {
> > try_to_freeze();
> > schedule();
> > }
> >
> > + pr_emerg_ratelimited("*** waking up\n");
> > __set_current_state(TASK_RUNNING);
> > remove_wait_queue(&kauditd_wait, &wait);
> > }
> >
> > I get several pairs of sleeping/waking up strings right before the
> > system begins to shut down. Then it stops (even though we do
> > have SKBs queued)
>
> Well. I assume "*** sleeping" the last thing kauditd prints? If the
> last print is "waking up" then obviously kauditd is stuck somewhere
> else, which makes more sense. A sysrq-T (or echo t >
> /proc/sysrq-trigger) should provide clues.
Yes, "*** sleeping" is the last one.
> I'd remove the "_ratelimited" - you don't want your debug messages to be
> ratelimited (ie: omitted).
I'll try that.
Another interesting info is that the process that triggers the hang
is killall5 and by the time the hang happens auditd is not running
anymore.
--
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] f2fs: optimize gc for better performance
From: Jin Xu
This patch improves the foreground gc efficiency by optimizing the
victim selection policy. With this optimization, the random re-write
performance could increase up to 20%.
For f2fs, foreground gc happens when disk is lack of free spaces,
it selects dirty segments and moves valid blocks around for making
more space available. The gc cost of a segment is determined by the
valid blocks in the segment. The less the valid blocks, the higher
the efficiency. The ideal victim segment is the one that has the
most garbage blocks.
Currently, it searches up to 20 dirty segments for a victim segment.
The selected victim is not likely the best victim for gc when there
are much more dirty segments. Why not searching more dirty segments
for a better victim? The cost of searching dirty segments is
negligible in comparison to moving blocks.
In this patch, it does not search a constant number of dirty segments
anymore, instead it calculates the number based on the total segments,
dirty segments and a threshold. Following is the pseudo formula.
,-- nr_dirty_segments, if total_segments < threshold
(# of search) = |
`-- (nr_dirty_segments * threshold) / total_segments,
Otherwise
The test case is simple. It creates as many files until the disk full.
The size for each file is 32KB. Then it writes as many as 10
records of 4KB size to random offsets of random files in sync mode.
The testing was done on a 2GB partition of a SDHC card. Let's see the
test result of f2fs without and with the patch.
without the patch
created 52023 files of size 32768 bytes in 341 seconds
finished 10 loops in 4204 seconds
(internally, 722 gc were done, 115939 garbage blocks were reclaimed)
with the patch
created 52023 files of size 32768 bytes in 326 seconds
finished 10 loops in 3067 seconds
(internally, 1255 gc were done, 181101 garbage blocks were reclaimed)
It's obvious that, with the patch, f2fs finishes the test in 20+% less
time than without the patch.
Since the performance improvement is related to gc, it might not be so
obvious for other tests that do not trigger gc as often as this one (
This is because f2fs selects dirty segments for SSR use most of the
time when free space is in shortage). The well-known iozone test tool
was not used for benchmarking the patch becuase it seems do not have
a test case that performs random re-write on a full disk.
Signed-off-by: Jin Xu
---
fs/f2fs/gc.c | 27 ++-
fs/f2fs/gc.h |4 +++-
fs/f2fs/segment.h |1 +
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 35f9b1a..4e045e6 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -138,10 +138,12 @@ static void select_policy(struct f2fs_sb_info *sbi, int
gc_type,
if (p->alloc_mode == SSR) {
p->gc_mode = GC_GREEDY;
p->dirty_segmap = dirty_i->dirty_segmap[type];
+ p->dirty_type = type;
p->ofs_unit = 1;
} else {
p->gc_mode = select_gc_type(gc_type);
p->dirty_segmap = dirty_i->dirty_segmap[DIRTY];
+ p->dirty_type = DIRTY;
p->ofs_unit = sbi->segs_per_sec;
}
p->offset = sbi->last_victim[p->gc_mode];
@@ -243,6 +245,8 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
struct victim_sel_policy p;
unsigned int secno, max_cost;
int nsearched = 0;
+ unsigned int max_search = MAX_VICTIM_SEARCH;
+ unsigned int nr_dirty;
p.alloc_mode = alloc_mode;
select_policy(sbi, gc_type, type, &p);
@@ -258,6 +262,27 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
goto got_it;
}
+ nr_dirty = dirty_i->nr_dirty[p.dirty_type];
+ if (p.gc_mode == GC_GREEDY && p.alloc_mode != SSR) {
+ if (TOTAL_SEGS(sbi) <= FULL_VICTIM_SEARCH_THRESH)
+ max_search = nr_dirty; /* search all the dirty segs */
+ else {
+ /*
+* With more dirty segments, garbage blocks are likely
+* more scattered, thus search harder for better
+* victim.
+*/
+ max_search = div_u64 ((nr_dirty *
+ FULL_VICTIM_SEARCH_THRESH), TOTAL_SEGS(sbi));
+ if (max_search < MIN_VICTIM_SEARCH_GREEDY)
+ max_search = MIN_VICTIM_SEARCH_GREEDY;
+ }
+ }
+
+ /* no more than the total dirty segments */
+ if (max_search > nr_dirty)
+ max_search = nr_dirty;
+
while (1) {
unsigned long cost;
unsigned int segno;
@@ -290,7 +315,7 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
if (cost == max_cost)
Weirdness with EFI boot and partition tables...
So I'm trying to debug a problem with my Dell Latitude booting in EFI mode, that looks like a "can't find the initrd", when I stumbled across this: <4>[2.831325] VFS: Cannot open root device "mapper/turing--police-froot" or unknown-block(0,0): error -6 <4>[2.831329] Please append a correct "root=" boot option; here are the available partitions: <4>[2.831338] 0800 488386584 sda driver: sd <4>[2.831344] 0801 305368 sda1 5288e82d-f5e3-4f57-a7f9-e29f87149240 <4>[2.831348] 0802 3150112 sda2 42eb87e8-1e6a-477e-8b66-2255ac98b27d <4>[2.831351] 0803 512000 sda3 6c7a5919-61bc-498e-b26a-9c2aa27e65d1 <4>[2.831355] 0805 293795840 sda5 52e421a3-78df-48ac-877f-9362b50af20f <4>[2.831358] 0806 4100096 sda6 ebaf21a2-a1aa-4685-8788-e962b6aad18c <4>[2.831364] 0b00 1048575 sr0 driver: sr Note the entry for sda6. Boot a Fedora kernel, and: # fdisk -l /dev/sda WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: gpt # Start EndSize TypeName 116072 626807 298.2M Linux filesyste Linux filesystem 2 626808 6927031 3G Microsoft basic Microsoft basic data 3 6928384 7952383500M Linux filesyste Linux filesystem 5 7954432595546111 280.2G Linux LVM Linux LVM 6595546112976773134 181.8G Linux LVM Linux LVM Any ideas why the size discrepancy? (No, this probably not relevant to my original issue - my root is on the LVM on sda5, which is OK, and the problem is the initrd doesn't fire up at all) pgpBQPQq2kywS.pgp Description: PGP signature
