[PATCH V2 6/6] cpufreq: Loongson1: Add cpufreq driver for Loongson1B
This patch adds cpufreq driver for Loongson1B which
is capable of changing the CPU frequency dynamically.
Signed-off-by: Kelvin Cheung
---
V2:
Use devm_clk_get() instead of clk_get().
Other minor fixes.
V1:
Add cpufreq driver for Loongson1B.
---
drivers/cpufreq/Kconfig| 10 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/ls1x-cpufreq.c | 229 +
3 files changed, 240 insertions(+)
create mode 100644 drivers/cpufreq/ls1x-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index ffe350f..99464d7 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -250,6 +250,16 @@ config LOONGSON2_CPUFREQ
If in doubt, say N.
+config LOONGSON1_CPUFREQ
+ tristate "Loongson1 CPUFreq Driver"
+ help
+ This option adds a CPUFreq driver for loongson1 processors which
+ support software configurable cpu frequency.
+
+ For details, take a look at .
+
+ If in doubt, say N.
+
endmenu
menu "PowerPC CPU frequency scaling drivers"
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db6d9a2..aca7bd3 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_CRIS_MACH_ARTPEC3) +=
cris-artpec3-cpufreq.o
obj-$(CONFIG_ETRAXFS) += cris-etraxfs-cpufreq.o
obj-$(CONFIG_IA64_ACPI_CPUFREQ)+= ia64-acpi-cpufreq.o
obj-$(CONFIG_LOONGSON2_CPUFREQ)+= loongson2_cpufreq.o
+obj-$(CONFIG_LOONGSON1_CPUFREQ)+= ls1x-cpufreq.o
obj-$(CONFIG_SH_CPU_FREQ) += sh-cpufreq.o
obj-$(CONFIG_SPARC_US2E_CPUFREQ) += sparc-us2e-cpufreq.o
obj-$(CONFIG_SPARC_US3_CPUFREQ)+= sparc-us3-cpufreq.o
diff --git a/drivers/cpufreq/ls1x-cpufreq.c b/drivers/cpufreq/ls1x-cpufreq.c
new file mode 100644
index 000..1941c91
--- /dev/null
+++ b/drivers/cpufreq/ls1x-cpufreq.c
@@ -0,0 +1,229 @@
+/*
+ * CPU Frequency Scaling for Loongson 1 SoC
+ *
+ * Copyright (C) 2014 Zhang, Keguang
+ *
+ * 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
+
+static struct {
+ struct device *dev;
+ struct clk *clk;/* CPU clk */
+ struct clk *mux_clk;/* MUX of CPU clk */
+ struct clk *pll_clk;/* PLL clk */
+ struct clk *osc_clk;/* OSC clk */
+ unsigned int max_freq;
+ unsigned int min_freq;
+} ls1x_cpufreq;
+
+static int ls1x_cpufreq_notifier(struct notifier_block *nb,
+unsigned long val, void *data)
+{
+ if (val == CPUFREQ_POSTCHANGE)
+ current_cpu_data.udelay_val = loops_per_jiffy;
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block ls1x_cpufreq_notifier_block = {
+ .notifier_call = ls1x_cpufreq_notifier
+};
+
+static int ls1x_cpufreq_target(struct cpufreq_policy *policy,
+ unsigned int index)
+{
+ unsigned int old_freq, new_freq;
+
+ old_freq = policy->cur;
+ new_freq = policy->freq_table[index].frequency;
+
+ /*
+* The procedure of reconfiguring CPU clk is as below.
+*
+* - Reparent CPU clk to OSC clk
+* - Reset CPU clock (very important)
+* - Reconfigure CPU DIV
+* - Reparent CPU clk back to CPU DIV clk
+*/
+
+ dev_dbg(ls1x_cpufreq.dev, "%u KHz --> %u KHz\n", old_freq, new_freq);
+ clk_set_parent(policy->clk, ls1x_cpufreq.osc_clk);
+ __raw_writel(__raw_readl(LS1X_CLK_PLL_DIV) | RST_CPU_EN | RST_CPU,
+LS1X_CLK_PLL_DIV);
+ __raw_writel(__raw_readl(LS1X_CLK_PLL_DIV) & ~(RST_CPU_EN | RST_CPU),
+LS1X_CLK_PLL_DIV);
+ clk_set_rate(ls1x_cpufreq.mux_clk, new_freq * 1000);
+ clk_set_parent(policy->clk, ls1x_cpufreq.mux_clk);
+
+ return 0;
+}
+
+static int ls1x_cpufreq_init(struct cpufreq_policy *policy)
+{
+ struct cpufreq_frequency_table *freq_tbl;
+ unsigned int pll_freq, freq;
+ int steps, i, ret;
+
+ pll_freq = clk_get_rate(ls1x_cpufreq.pll_clk) / 1000;
+
+ steps = 1 << DIV_CPU_WIDTH;
+ freq_tbl = kzalloc(sizeof(*freq_tbl) * steps, GFP_KERNEL);
+ if (!freq_tbl) {
+ dev_err(ls1x_cpufreq.dev,
+ "failed to alloc cpufreq_frequency_table\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ for (i = 0; i < (steps - 1); i++) {
+ freq = pll_freq / (i + 1);
+ if ((freq < ls1x_cpufreq.min_freq) ||
+ (freq > ls1x_cpufreq.max_freq))
+ freq_tbl[i].frequency = CPUFREQ_ENTRY_INVALID;
+ else
+ freq_tbl
[PATCH V2 6/6] cpufreq: Loongson1: Add cpufreq driver for Loongson1B
This patch adds cpufreq driver for Loongson1B which
is capable of changing the CPU frequency dynamically.
Signed-off-by: Kelvin Cheung
---
drivers/cpufreq/Kconfig| 10 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/ls1x-cpufreq.c | 229 +
3 files changed, 240 insertions(+)
create mode 100644 drivers/cpufreq/ls1x-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index ffe350f..99464d7 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -250,6 +250,16 @@ config LOONGSON2_CPUFREQ
If in doubt, say N.
+config LOONGSON1_CPUFREQ
+ tristate "Loongson1 CPUFreq Driver"
+ help
+ This option adds a CPUFreq driver for loongson1 processors which
+ support software configurable cpu frequency.
+
+ For details, take a look at .
+
+ If in doubt, say N.
+
endmenu
menu "PowerPC CPU frequency scaling drivers"
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db6d9a2..aca7bd3 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_CRIS_MACH_ARTPEC3) +=
cris-artpec3-cpufreq.o
obj-$(CONFIG_ETRAXFS) += cris-etraxfs-cpufreq.o
obj-$(CONFIG_IA64_ACPI_CPUFREQ)+= ia64-acpi-cpufreq.o
obj-$(CONFIG_LOONGSON2_CPUFREQ)+= loongson2_cpufreq.o
+obj-$(CONFIG_LOONGSON1_CPUFREQ)+= ls1x-cpufreq.o
obj-$(CONFIG_SH_CPU_FREQ) += sh-cpufreq.o
obj-$(CONFIG_SPARC_US2E_CPUFREQ) += sparc-us2e-cpufreq.o
obj-$(CONFIG_SPARC_US3_CPUFREQ)+= sparc-us3-cpufreq.o
diff --git a/drivers/cpufreq/ls1x-cpufreq.c b/drivers/cpufreq/ls1x-cpufreq.c
new file mode 100644
index 000..1941c91
--- /dev/null
+++ b/drivers/cpufreq/ls1x-cpufreq.c
@@ -0,0 +1,229 @@
+/*
+ * CPU Frequency Scaling for Loongson 1 SoC
+ *
+ * Copyright (C) 2014 Zhang, Keguang
+ *
+ * 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
+
+static struct {
+ struct device *dev;
+ struct clk *clk;/* CPU clk */
+ struct clk *mux_clk;/* MUX of CPU clk */
+ struct clk *pll_clk;/* PLL clk */
+ struct clk *osc_clk;/* OSC clk */
+ unsigned int max_freq;
+ unsigned int min_freq;
+} ls1x_cpufreq;
+
+static int ls1x_cpufreq_notifier(struct notifier_block *nb,
+unsigned long val, void *data)
+{
+ if (val == CPUFREQ_POSTCHANGE)
+ current_cpu_data.udelay_val = loops_per_jiffy;
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block ls1x_cpufreq_notifier_block = {
+ .notifier_call = ls1x_cpufreq_notifier
+};
+
+static int ls1x_cpufreq_target(struct cpufreq_policy *policy,
+ unsigned int index)
+{
+ unsigned int old_freq, new_freq;
+
+ old_freq = policy->cur;
+ new_freq = policy->freq_table[index].frequency;
+
+ /*
+* The procedure of reconfiguring CPU clk is as below.
+*
+* - Reparent CPU clk to OSC clk
+* - Reset CPU clock (very important)
+* - Reconfigure CPU DIV
+* - Reparent CPU clk back to CPU DIV clk
+*/
+
+ dev_dbg(ls1x_cpufreq.dev, "%u KHz --> %u KHz\n", old_freq, new_freq);
+ clk_set_parent(policy->clk, ls1x_cpufreq.osc_clk);
+ __raw_writel(__raw_readl(LS1X_CLK_PLL_DIV) | RST_CPU_EN | RST_CPU,
+LS1X_CLK_PLL_DIV);
+ __raw_writel(__raw_readl(LS1X_CLK_PLL_DIV) & ~(RST_CPU_EN | RST_CPU),
+LS1X_CLK_PLL_DIV);
+ clk_set_rate(ls1x_cpufreq.mux_clk, new_freq * 1000);
+ clk_set_parent(policy->clk, ls1x_cpufreq.mux_clk);
+
+ return 0;
+}
+
+static int ls1x_cpufreq_init(struct cpufreq_policy *policy)
+{
+ struct cpufreq_frequency_table *freq_tbl;
+ unsigned int pll_freq, freq;
+ int steps, i, ret;
+
+ pll_freq = clk_get_rate(ls1x_cpufreq.pll_clk) / 1000;
+
+ steps = 1 << DIV_CPU_WIDTH;
+ freq_tbl = kzalloc(sizeof(*freq_tbl) * steps, GFP_KERNEL);
+ if (!freq_tbl) {
+ dev_err(ls1x_cpufreq.dev,
+ "failed to alloc cpufreq_frequency_table\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ for (i = 0; i < (steps - 1); i++) {
+ freq = pll_freq / (i + 1);
+ if ((freq < ls1x_cpufreq.min_freq) ||
+ (freq > ls1x_cpufreq.max_freq))
+ freq_tbl[i].frequency = CPUFREQ_ENTRY_INVALID;
+ else
+ freq_tbl[i].frequency = freq;
+ dev_dbg(ls1x_cpufreq.dev,
+ "cpufreq table: index %d: fre
Re: getaddrinfo slowdown in 3.17.1, due to getifaddrs
On 10/17/14 at 02:34am, Steinar H. Gunderson wrote: > On Fri, Oct 17, 2014 at 02:21:32AM +0200, Steinar H. Gunderson wrote: > > Hi, > > > > We recently upgraded a machine from 3.14.5 to 3.17.1, and a Perl script > > we're > > running to poll SNMP suddenly needed ten times as much time to complete. > > e341694e3eb57fcda9f1adc7bfea42fe080d8d7a looks like it might cause something > like this (it certainly added the synchronize_net() call). Cc-ing people on > that commit; quoting the entire rest of the message for reference. I think the only option at this point is to re-add the nltable lock to netlink_lookup() so we can drop the synchronize_net() until we find a way to RCUify socket destruction. I will cook up a patch today unless somebody can come up with a smarter way to work around needing the synchronize_net(). -- 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 v11 0/3] Add drm driver for Rockchip Socs
Hi Mark, Am Freitag, 17. Oktober 2014, 12:22:53 schrieb Mark yao: > On 2014年10月17日 08:46, Dave Airlie wrote: > > On 17 October 2014 10:40, Mark yao wrote: > >> Hi > >> I think Rockchip drm driver is ready now, can it land? > > > > I probably want to wait until -rc1 though I suppose since its a new > > driver and self contained we might be able to see if Linus is > > interested in squeezing it in. > > > > Can you send me a git pull request for it against drm-next or even 3.17. > > > > Dave. > > Hi, Dave > the git pull request: > > The following changes since commit 4db36870b92cdf5a79615aeabc68efc97df13918: I think this needs a fix. Your commit 4db36870b is the pending iommu driver. Which isn't part of neither the mainline kernel nor the drm tree Dave meant. What Dave meant was to base your patches on top of his "drm-next" branch or the raw 3.17 release. So either base the branch on drm-next from http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next or the 3.17 release tag from Linus Torvalds. Apply your patches on top and create pull from there. I've just checked ... your drm patches apply cleanly against 3.17, so your branch to be pulled should probably look something like https://github.com/mmind/linux-rockchip/commits/tmp/drmtest Heiko > >FROMLIST: iommu/rockchip: rk3288 iommu driver (2014-10-17 10:26:18 +0800) > > are available in the git repository at: > >https://github.com/markyzq/kernel-drm-rockchip.git mydrm > > for you to fetch changes up to 0db2be88bea08ab8afe5e3d13f8a2c9e637a9514: > >dt-bindings: video: Add documentation for rockchip vop (2014-10-17 > 10:27:15 +0800) > > > Mark yao (3): >drm: rockchip: Add basic drm driver >dt-bindings: video: Add for rockchip display subsytem >dt-bindings: video: Add documentation for rockchip vop > > .../devicetree/bindings/video/rockchip-drm.txt | 19 + > .../devicetree/bindings/video/rockchip-vop.txt | 58 + > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/rockchip/Kconfig | 17 + > drivers/gpu/drm/rockchip/Makefile |8 + > drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 449 ++ > drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 54 + > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++ > drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 + > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++ > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 + > drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 293 > drivers/gpu/drm/rockchip/rockchip_drm_gem.h| 54 + > drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1427 > > drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 196 +++ > 16 files changed, 3036 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/video/rockchip-drm.txt > create mode 100644 > Documentation/devicetree/bindings/video/rockchip-vop.txt > create mode 100644 drivers/gpu/drm/rockchip/Kconfig > create mode 100644 drivers/gpu/drm/rockchip/Makefile > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.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 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory
On 10/16/14 16:29, Rafael J. Wysocki wrote:
> [CC list trimmed]
>
> On Thursday, October 16, 2014 11:35:49 AM Hui Zhu wrote:
>> Function shrink_all_memory try to free `nr_to_reclaim' of memory.
>> CMA_AGGRESSIVE_SHRINK function will call this functon to free
>> `nr_to_reclaim' of
>> memory. It need different scan_control with current caller function
>> hibernate_preallocate_memory.
>>
>> If hibernation is true, the caller is hibernate_preallocate_memory.
>> if not, the caller is CMA alloc function.
>>
>> Signed-off-by: Hui Zhu
>> ---
>> include/linux/swap.h| 3 ++-
>> kernel/power/snapshot.c | 2 +-
>> mm/vmscan.c | 19 +--
>> 3 files changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/linux/swap.h b/include/linux/swap.h
>> index 37a585b..9f2cb43 100644
>> --- a/include/linux/swap.h
>> +++ b/include/linux/swap.h
>> @@ -335,7 +335,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct
>> mem_cgroup *mem,
>> gfp_t gfp_mask, bool noswap,
>> struct zone *zone,
>> unsigned long *nr_scanned);
>> -extern unsigned long shrink_all_memory(unsigned long nr_pages);
>> +extern unsigned long shrink_all_memory(unsigned long nr_pages,
>> + bool hibernation);
>> extern int vm_swappiness;
>> extern int remove_mapping(struct address_space *mapping, struct page
>> *page);
>> extern unsigned long vm_total_pages;
>> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
>> index 791a618..a00fc35 100644
>> --- a/kernel/power/snapshot.c
>> +++ b/kernel/power/snapshot.c
>> @@ -1657,7 +1657,7 @@ int hibernate_preallocate_memory(void)
>> * NOTE: If this is not done, performance will be hurt badly in some
>> * test cases.
>> */
>> -shrink_all_memory(saveable - size);
>> +shrink_all_memory(saveable - size, true);
>
> Instead of doing this, can you please define
>
> __shrink_all_memory()
>
> that will take the appropriate struct scan_control as an argument and
> then define two wrappers around that, one for hibernation and one for CMA?
>
> The way you did it opens a field for bugs caused by passing a wrong value
> as the second argument.
Thanks Rafael.
I will update patch according to your comments.
Best,
Hui
>
>>
>> /*
>> * The number of saveable pages in memory was too high, so apply some
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index dcb4707..fdcfa30 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -3404,7 +3404,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum
>> zone_type classzone_idx)
>> wake_up_interruptible(&pgdat->kswapd_wait);
>> }
>>
>> -#ifdef CONFIG_HIBERNATION
>> +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE
>> /*
>>* Try to free `nr_to_reclaim' of memory, system-wide, and return the
>> number of
>>* freed pages.
>> @@ -3413,22 +3413,29 @@ void wakeup_kswapd(struct zone *zone, int order,
>> enum zone_type classzone_idx)
>>* LRU order by reclaiming preferentially
>>* inactive > active > active referenced > active mapped
>>*/
>> -unsigned long shrink_all_memory(unsigned long nr_to_reclaim)
>> +unsigned long shrink_all_memory(unsigned long nr_to_reclaim, bool
>> hibernation)
>> {
>> struct reclaim_state reclaim_state;
>> struct scan_control sc = {
>> .nr_to_reclaim = nr_to_reclaim,
>> -.gfp_mask = GFP_HIGHUSER_MOVABLE,
>> .priority = DEF_PRIORITY,
>> -.may_writepage = 1,
>> .may_unmap = 1,
>> .may_swap = 1,
>> -.hibernation_mode = 1,
>> };
>> struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask);
>> struct task_struct *p = current;
>> unsigned long nr_reclaimed;
>>
>> +if (hibernation) {
>> +sc.hibernation_mode = 1;
>> +sc.may_writepage = 1;
>> +sc.gfp_mask = GFP_HIGHUSER_MOVABLE;
>> +} else {
>> +sc.hibernation_mode = 0;
>> +sc.may_writepage = !laptop_mode;
>> +sc.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM;
>> +}
>> +
>> p->flags |= PF_MEMALLOC;
>> lockdep_set_current_reclaim_state(sc.gfp_mask);
>> reclaim_state.reclaimed_slab = 0;
>> @@ -3442,7 +3449,7 @@ unsigned long shrink_all_memory(unsigned long
>> nr_to_reclaim)
>>
>> return nr_reclaimed;
>> }
>> -#endif /* CONFIG_HIBERNATION */
>> +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */
>>
>> /* It's optimal to keep kswapds on the same CPUs as their memory, but
>> not required for correctness. So if the last cpu in a node goes
>>
>
Re: [PATCH v6 8/8] ARM: mm: allow text and rodata sections to be read-only
Hey Kees
> From: Kees Cook
> To: linux-kernel@vger.kernel.org
> Cc: Kees Cook , Will Deacon ,
> Rabin Vincent , Laura Abbott , Rob
> Herring , Leif Lindholm , Mark
> Salter , Liu hua <
> Subject: [PATCH v6 8/8] ARM: mm: allow text and rodata sections to be
> read-only
> Date: Thu, 18 Sep 2014 12:19:09 -0700
>
> This introduces CONFIG_DEBUG_RODATA, making kernel text and rodata
> read-only. Additionally, this splits rodata from text so that rodata can
> also be NX, which may lead to wasted memory when aligning to SECTION_SIZE.
> The read-only areas are made writable during ftrace updates and kexec.
>
> Signed-off-by: Kees Cook
> Tested-by: Laura Abbott
> Acked-by: Nicolas Pitre
> ---
> arch/arm/include/asm/cacheflush.h | 10
> arch/arm/kernel/ftrace.c | 19
> arch/arm/kernel/machine_kexec.c | 1 +
> arch/arm/kernel/vmlinux.lds.S | 3 +++
> arch/arm/mm/Kconfig | 12 ++
> arch/arm/mm/init.c| 48
> ++-
> 6 files changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/cacheflush.h
> b/arch/arm/include/asm/cacheflush.h
> index 79ecb4f34ffb..9108292edcb5 100644
> --- a/arch/arm/include/asm/cacheflush.h
> +++ b/arch/arm/include/asm/cacheflush.h
> @@ -486,6 +486,16 @@ int set_memory_rw(unsigned long addr, int numpages);
> int set_memory_x(unsigned long addr, int numpages);
> int set_memory_nx(unsigned long addr, int numpages);
>
> +#ifdef CONFIG_DEBUG_RODATA
> +void mark_rodata_ro(void);
> +void set_kernel_text_rw(void);
> +void set_kernel_text_ro(void);
> +#else
> +static inline void set_kernel_text_rw(void) { }
> +static inline void set_kernel_text_ro(void) { }
> +#endif
> +
> void flush_uprobe_xol_access(struct page *page, unsigned long uaddr,
>void *kaddr, unsigned long len);
> +
> #endif
> diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
> index af9a8a927a4e..b8c75e45a950 100644
> --- a/arch/arm/kernel/ftrace.c
> +++ b/arch/arm/kernel/ftrace.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -35,6 +36,22 @@
>
> #define OLD_NOP 0xe1a0 /* mov r0, r0 */
>
> +static int __ftrace_modify_code(void *data)
> +{
> + int *command = data;
> +
> + set_kernel_text_rw();
> + ftrace_modify_all_code(*command);
> + set_kernel_text_ro();
> +
> + return 0;
> +}
> +
> +void arch_ftrace_update_code(int command)
> +{
> + stop_machine(__ftrace_modify_code, &command, NULL);
> +}
> +
> static unsigned long ftrace_nop_replace(struct dyn_ftrace *rec)
> {
> return rec->arch.old_mcount ? OLD_NOP : NOP;
> @@ -73,6 +90,8 @@ int ftrace_arch_code_modify_prepare(void)
> int ftrace_arch_code_modify_post_process(void)
> {
> set_all_modules_text_ro();
> + /* Make sure any TLB misses during machine stop are cleared. */
> + flush_tlb_all();
> return 0;
> }
>
> diff --git a/arch/arm/kernel/machine_kexec.c
> b/arch/arm/kernel/machine_kexec.c
> index 8f75250cbe30..4423a565ef6f 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -164,6 +164,7 @@ void machine_kexec(struct kimage *image)
> reboot_code_buffer = page_address(image->control_code_page);
>
> /* Prepare parameters for reboot_code_buffer*/
> + set_kernel_text_rw();
> kexec_start_address = image->start;
> kexec_indirection_page = page_list;
> kexec_mach_type = machine_arch_type;
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index a3d07ca2bbb4..542e58919bd9 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -120,6 +120,9 @@ SECTIONS
> ARM_CPU_KEEP(PROC_INFO)
> }
>
> +#ifdef CONFIG_DEBUG_RODATA
> + . = ALIGN(1< +#endif
> RO_DATA(PAGE_SIZE)
>
> . = ALIGN(4);
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 7a0756df91a2..c9cd9c5bf1e1 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1017,3 +1017,15 @@ config ARM_KERNMEM_PERMS
> padded to section-size (1MiB) boundaries (because their permissions
> are different and splitting the 1M pages into 4K ones causes TLB
> performance problems), wasting memory.
> +
> +config DEBUG_RODATA
> + bool "Make kernel text and rodata read-only"
> + depends on ARM_KERNMEM_PERMS
> + default y
> + help
> + If this is set, kernel text and rodata will be made read-only. This
> + is to help catch accidental or malicious attempts to change the
> + kernel's executable code. Additionally splits rodata from kernel
> + text so it can be made explicitly non-executable. This creates
> + another section-size padded region, so it can waste more memory
> + space while gaining the read-only protections.
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index e
Re: [RFC v3 PATCH 1/5] of: Add standard property for poweroff capability
Hi Romain, Am Freitag, 17. Oktober 2014, 08:01:31 schrieb PERIER Romain: > Hi all, > > I am just curious but where do you plan to merge this serie ? in > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git ? The single dts patch will be going into my dts branch and the rest will go through Mark's regulator tree. As Mark said, he'll try to apply these again once 3.18-rc1 is released and if it still doesn't apply then, he'll probably ask you to rebase them onto the regulator tree [which will at the time include everything that is in -rc1]. Heiko > 2014-10-15 16:03 GMT+02:00 Mark Brown : > > On Wed, Oct 15, 2014 at 03:56:03PM +0200, Heiko Stübner wrote: > >> Am Mittwoch, 15. Oktober 2014, 15:42:45 schrieb Mark Brown: > >> > I guess I should apply these (except the DTS update) since the first > >> > user that's being added is a regulator driver? > >> > >> I'd think so. > >> In any case, I'll take the "ARM: dts: ..." patch if you take the others. > > > > Sounds like a plan. I just tried applying and got some conflicts but > > I'm guessing that this is due to changes that are landing in the merge > > window so I'll try again once -rc1 is out. -- 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 v3 PATCH 1/5] of: Add standard property for poweroff capability
Hi all, I am just curious but where do you plan to merge this serie ? in git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git ? You have conflicts because I use linux-next as base repository. Thanks for your feebacks (all of you). Romain 2014-10-15 16:03 GMT+02:00 Mark Brown : > On Wed, Oct 15, 2014 at 03:56:03PM +0200, Heiko Stübner wrote: >> Am Mittwoch, 15. Oktober 2014, 15:42:45 schrieb Mark Brown: > >> > I guess I should apply these (except the DTS update) since the first >> > user that's being added is a regulator driver? > >> I'd think so. >> In any case, I'll take the "ARM: dts: ..." patch if you take the others. > > Sounds like a plan. I just tried applying and got some conflicts but > I'm guessing that this is due to changes that are landing in the merge > window so I'll try again once -rc1 is out. -- 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 net] r8152: use cancel_delayed_work for runtime suspend
It would cause dead lock for runtime suspend, when the workqueue
is running and runtime suspend occurs before the workqueue wakes
up the device. The rtl8152_suspend() waits the workqueue to finish
because of calling cancel_delayed_work_sync(). The workqueue waits
the suspend function to finish for waking up the device because of
calling usb_autopm_get_interface().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 864159e..7d4e55a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3200,12 +3200,13 @@ static int rtl8152_suspend(struct usb_interface *intf,
pm_message_t message)
if (netif_running(tp->netdev)) {
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
- cancel_delayed_work_sync(&tp->schedule);
tasklet_disable(&tp->tl);
if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
+ cancel_delayed_work(&tp->schedule);
rtl_stop_rx(tp);
rtl_runtime_suspend_enable(tp, true);
} else {
+ cancel_delayed_work_sync(&tp->schedule);
tp->rtl_ops.down(tp);
}
tasklet_enable(&tp->tl);
--
1.9.3
--
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: [PATCHv2] staging: rtl8188eu: Fix coding style space related ERROR problems
On Fri, Oct 17, 2014 at 01:31:18PM +0800, hejianet wrote: > Hi Greg > Just ping it, coz this is a practising patch for Eudyptula Challenge task 10. > Any comment is welcome, thank you :) > The merge window is open. And anyway, you shouldn't ping people about patches if it has been less than two weeks. regards, dan carpenter -- 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:
Hey Kees
> From: Kees Cook
> To: linux-kernel@vger.kernel.org
> Cc: Kees Cook , Will Deacon ,
> Rabin Vincent , Laura Abbott , Rob
> Herring , Leif Lindholm , Mark
> Salter , Liu hua <
> Subject: [PATCH v6 8/8] ARM: mm: allow text and rodata sections to be
> read-only
> Date: Thu, 18 Sep 2014 12:19:09 -0700
> Message-Id: <1411067949-10913-9-git-send-email-keesc...@chromium.org>
> X-Mailer: git-send-email 1.9.1
> In-Reply-To: <1411067949-10913-1-git-send-email-keesc...@chromium.org>
> References: <1411067949-10913-1-git-send-email-keesc...@chromium.org>
> X-MIMEDefang-Filter: outflux$Revision: 1.316 $
> X-HELO: www.outflux.net
> X-Scanned-By: MIMEDefang 2.73
> Sender: linux-kernel-ow...@vger.kernel.org
> Precedence: bulk
> List-Id:
> X-Mailing-List: linux-kernel@vger.kernel.org
> X-OriginalArrivalTime: 18 Sep 2014 19:23:14.0905 (UTC)
> FILETIME=[FE5B1490:01CFD375]
> X-RcptDomain: telfort.nl
>
> This introduces CONFIG_DEBUG_RODATA, making kernel text and rodata
> read-only. Additionally, this splits rodata from text so that rodata can
> also be NX, which may lead to wasted memory when aligning to SECTION_SIZE.
> The read-only areas are made writable during ftrace updates and kexec.
>
> Signed-off-by: Kees Cook
> Tested-by: Laura Abbott
> Acked-by: Nicolas Pitre
> ---
> arch/arm/include/asm/cacheflush.h | 10
> arch/arm/kernel/ftrace.c | 19
> arch/arm/kernel/machine_kexec.c | 1 +
> arch/arm/kernel/vmlinux.lds.S | 3 +++
> arch/arm/mm/Kconfig | 12 ++
> arch/arm/mm/init.c| 48
> ++-
> 6 files changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/cacheflush.h
> b/arch/arm/include/asm/cacheflush.h
> index 79ecb4f34ffb..9108292edcb5 100644
> --- a/arch/arm/include/asm/cacheflush.h
> +++ b/arch/arm/include/asm/cacheflush.h
> @@ -486,6 +486,16 @@ int set_memory_rw(unsigned long addr, int numpages);
> int set_memory_x(unsigned long addr, int numpages);
> int set_memory_nx(unsigned long addr, int numpages);
>
> +#ifdef CONFIG_DEBUG_RODATA
> +void mark_rodata_ro(void);
> +void set_kernel_text_rw(void);
> +void set_kernel_text_ro(void);
> +#else
> +static inline void set_kernel_text_rw(void) { }
> +static inline void set_kernel_text_ro(void) { }
> +#endif
> +
> void flush_uprobe_xol_access(struct page *page, unsigned long uaddr,
>void *kaddr, unsigned long len);
> +
> #endif
> diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
> index af9a8a927a4e..b8c75e45a950 100644
> --- a/arch/arm/kernel/ftrace.c
> +++ b/arch/arm/kernel/ftrace.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -35,6 +36,22 @@
>
> #define OLD_NOP 0xe1a0 /* mov r0, r0 */
>
> +static int __ftrace_modify_code(void *data)
> +{
> + int *command = data;
> +
> + set_kernel_text_rw();
> + ftrace_modify_all_code(*command);
> + set_kernel_text_ro();
> +
> + return 0;
> +}
> +
> +void arch_ftrace_update_code(int command)
> +{
> + stop_machine(__ftrace_modify_code, &command, NULL);
> +}
> +
> static unsigned long ftrace_nop_replace(struct dyn_ftrace *rec)
> {
> return rec->arch.old_mcount ? OLD_NOP : NOP;
> @@ -73,6 +90,8 @@ int ftrace_arch_code_modify_prepare(void)
> int ftrace_arch_code_modify_post_process(void)
> {
> set_all_modules_text_ro();
> + /* Make sure any TLB misses during machine stop are cleared. */
> + flush_tlb_all();
> return 0;
> }
>
> diff --git a/arch/arm/kernel/machine_kexec.c
> b/arch/arm/kernel/machine_kexec.c
> index 8f75250cbe30..4423a565ef6f 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -164,6 +164,7 @@ void machine_kexec(struct kimage *image)
> reboot_code_buffer = page_address(image->control_code_page);
>
> /* Prepare parameters for reboot_code_buffer*/
> + set_kernel_text_rw();
> kexec_start_address = image->start;
> kexec_indirection_page = page_list;
> kexec_mach_type = machine_arch_type;
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index a3d07ca2bbb4..542e58919bd9 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -120,6 +120,9 @@ SECTIONS
> ARM_CPU_KEEP(PROC_INFO)
> }
>
> +#ifdef CONFIG_DEBUG_RODATA
> + . = ALIGN(1< +#endif
> RO_DATA(PAGE_SIZE)
>
> . = ALIGN(4);
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 7a0756df91a2..c9cd9c5bf1e1 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1017,3 +1017,15 @@ config ARM_KERNMEM_PERMS
> padded to section-size (1MiB) boundaries (because their permissions
> are different and splitting the 1M pages into 4K ones causes TLB
> performance problems), wasting memory.
> +
> +config DEBUG_RODATA
> +
Re: [PATCHv2] staging: rtl8188eu: Fix coding style space related ERROR problems
Hi Greg
Just ping it, coz this is a practising patch for Eudyptula Challenge task 10.
Any comment is welcome, thank you :)
On Tue, 14 Oct 2014 11:28:32 +0800 from hejia...@gmail.com wrote:
> This fixes space related ERROR reports by checkpatch.pl
> Generated by $ git ls-files "drivers/staging/rtl8188eu/*.[ch]" | \
> xargs ./scripts/checkpatch.pl -f --fix-inplace --strict --types=SPACING
> Already checked by text comparasion
> $git diff -w
> and binary comparasion of r8188eu.ko
> $objdiff diff
>
> Signed-off-by: Jia He
> Cc: Greg Kroah-Hartman
> ---
> drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
> drivers/staging/rtl8188eu/core/rtw_ieee80211.c| 16 +-
> drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
> drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 22 +++---
> drivers/staging/rtl8188eu/core/rtw_pwrctrl.c | 2 +-
> drivers/staging/rtl8188eu/core/rtw_recv.c | 12
> drivers/staging/rtl8188eu/core/rtw_security.c | 20 ++---
> drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 2 +-
> drivers/staging/rtl8188eu/core/rtw_xmit.c | 10 +++
> drivers/staging/rtl8188eu/hal/bb_cfg.c| 4 +--
> drivers/staging/rtl8188eu/hal/fw.c| 8 ++---
> drivers/staging/rtl8188eu/hal/mac_cfg.c | 2 +-
> drivers/staging/rtl8188eu/hal/odm.c | 8 ++---
> drivers/staging/rtl8188eu/hal/odm_HWConfig.c | 2 +-
> drivers/staging/rtl8188eu/hal/odm_RTL8188E.c | 2 +-
> drivers/staging/rtl8188eu/hal/phy.c | 2 +-
> drivers/staging/rtl8188eu/hal/rf.c| 4 +--
> drivers/staging/rtl8188eu/hal/rf_cfg.c| 4 +--
> drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 2 +-
> drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c| 2 +-
> drivers/staging/rtl8188eu/hal/usb_halinit.c | 2 +-
> drivers/staging/rtl8188eu/include/ieee80211_ext.h | 20 ++---
> drivers/staging/rtl8188eu/include/odm_debug.h | 2 +-
> drivers/staging/rtl8188eu/include/osdep_service.h | 4 +--
> drivers/staging/rtl8188eu/include/rtw_debug.h | 2 +-
> drivers/staging/rtl8188eu/include/rtw_led.h | 2 +-
> drivers/staging/rtl8188eu/include/rtw_mlme_ext.h | 26
> drivers/staging/rtl8188eu/include/wifi.h | 36
> +++
> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c| 2 +-
> drivers/staging/rtl8188eu/os_dep/os_intfs.c | 2 +-
> drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 4 +--
> drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 2 +-
> 32 files changed, 116 insertions(+), 116 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
> b/drivers/staging/rtl8188eu/core/rtw_cmd.c
> index 9935e66..7b59a10 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
> @@ -638,7 +638,7 @@ u8 rtw_setstakey_cmd(struct adapter *padapter, u8 *psta,
> u8 unicast_key)
> ether_addr_copy(psetstakey_para->addr, sta->hwaddr);
>
> if (check_fwstate(pmlmepriv, WIFI_STATION_STATE))
> - psetstakey_para->algorithm = (unsigned char)
> psecuritypriv->dot11PrivacyAlgrthm;
> + psetstakey_para->algorithm = (unsigned
> char)psecuritypriv->dot11PrivacyAlgrthm;
> else
> GET_ENCRY_ALGO(psecuritypriv, sta, psetstakey_para->algorithm,
> false);
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> index 755d3ef..f2c3ca7 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> @@ -159,7 +159,7 @@ u8 *rtw_set_ie
> return pbuf + len + 2;
> }
>
> -inline u8 *rtw_set_ie_ch_switch (u8 *buf, u32 *buf_len, u8 ch_switch_mode,
> +inline u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
> u8 new_ch, u8 ch_switch_cnt)
> {
> u8 ie_data[3];
> @@ -870,7 +870,7 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
> uint elen,
> if (elen < 4) {
> if (show_errors) {
> DBG_88E("short vendor specific information element
> ignored (len=%lu)\n",
> - (unsigned long) elen);
> + (unsigned long)elen);
> }
> return -1;
> }
> @@ -890,7 +890,7 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
> uint elen,
> case WME_OUI_TYPE: /* this is a Wi-Fi WME info. element */
> if (elen < 5) {
> DBG_88E("short WME information element ignored
> (len=%lu)\n",
> - (unsigned long) elen);
> + (unsigned long)elen);
> return -1;
> }
> switch (pos[4]) {
> @@ -905,7 +905,7 @@ static int rtw_ieee802_11_parse_
Re: [PATCH net-next RFC 1/3] virtio: support for urgent descriptors
On 10/15/2014 01:40 PM, Rusty Russell wrote: > Jason Wang writes: >> Below should be useful for some experiments Jason is doing. >> I thought I'd send it out for early review/feedback. >> >> event idx feature allows us to defer interrupts until >> a specific # of descriptors were used. >> Sometimes it might be useful to get an interrupt after >> a specific descriptor, regardless. >> This adds a descriptor flag for this, and an API >> to create an urgent output descriptor. >> This is still an RFC: >> we'll need a feature bit for drivers to detect this, >> but we've run out of feature bits for virtio 0.X. >> For experimentation purposes, drivers can assume >> this is set, or add a driver-specific feature bit. >> >> Signed-off-by: Michael S. Tsirkin >> Signed-off-by: Jason Wang > The new VRING_DESC_F_URGENT bit is theoretically nicer, but for > networking (which tends to take packets in order) couldn't we just set > the event counter to give us a tx interrupt at the packet we want? > > Cheers, > Rusty. Yes, we could. Recent RFC of enabling tx interrupt use this. -- 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 RFC v2 2/3] virtio_net: bql
On 10/15/2014 10:32 PM, Michael S. Tsirkin wrote:
> Improve tx batching using byte queue limits.
> Should be especially effective for MQ.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/net/virtio_net.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index a9bf178..8dea411 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -219,13 +219,15 @@ static struct page *get_a_page(struct receive_queue
> *rq, gfp_t gfp_mask)
> return p;
> }
>
> -static unsigned int free_old_xmit_skbs(struct send_queue *sq, int budget)
> +static unsigned int free_old_xmit_skbs(struct netdev_queue *txq,
> +struct send_queue *sq, int budget)
> {
> struct sk_buff *skb;
> unsigned int len;
> struct virtnet_info *vi = sq->vq->vdev->priv;
> struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
> unsigned int packets = 0;
> + unsigned int bytes = 0;
>
> while (packets < budget &&
> (skb = virtqueue_get_buf(sq->vq, &len)) != NULL) {
> @@ -233,6 +235,7 @@ static unsigned int free_old_xmit_skbs(struct send_queue
> *sq, int budget)
>
> u64_stats_update_begin(&stats->tx_syncp);
> stats->tx_bytes += skb->len;
> + bytes += skb->len;
> stats->tx_packets++;
> u64_stats_update_end(&stats->tx_syncp);
>
> @@ -240,6 +243,8 @@ static unsigned int free_old_xmit_skbs(struct send_queue
> *sq, int budget)
> packets++;
> }
>
> + netdev_tx_completed_queue(txq, packets, bytes);
> +
> return packets;
> }
>
> @@ -810,7 +815,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int
> budget)
> again:
> __netif_tx_lock(txq, smp_processor_id());
> virtqueue_disable_cb(sq->vq);
> - sent += free_old_xmit_skbs(sq, budget - sent);
> + sent += free_old_xmit_skbs(txq, sq, budget - sent);
>
> if (sent < budget) {
> enable_done = virtqueue_enable_cb_delayed(sq->vq);
> @@ -962,12 +967,13 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
> struct net_device *dev)
> struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
> bool kick = !skb->xmit_more;
> bool stopped;
> + unsigned int bytes = skb->len;
>
> virtqueue_disable_cb(sq->vq);
>
> /* We are going to push one skb.
>* Try to pop one off to free space for it. */
> - free_old_xmit_skbs(sq, 1);
> + free_old_xmit_skbs(txq, sq, 1);
>
> /* Try to transmit */
> err = xmit_skb(sq, skb);
> @@ -983,6 +989,12 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
> struct net_device *dev)
> return NETDEV_TX_OK;
> }
>
> + netdev_tx_sent_queue(txq, bytes);
> +
> + /* Kick early so device can process descriptors in parallel with us. */
> + if (kick)
> + virtqueue_kick(sq->vq);
Haven't figured out how this will help for bql, consider only a
netif_stop_subqueue() may be called during two possible kicks. And since
we don't add any buffer between the two kicks, the send kick is almost
useless.
> +
> /* Apparently nice girls don't return TX_BUSY; stop the queue
>* before it gets out of hand. Naturally, this wastes entries. */
> if (sq->vq->num_free < 2+MAX_SKB_FRAGS) {
> @@ -997,7 +1009,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
> struct net_device *dev)
>
> if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
> /* More just got used, free them then recheck. */
> - free_old_xmit_skbs(sq, qsize);
> + free_old_xmit_skbs(txq, sq, qsize);
> if (stopped && sq->vq->num_free >= 2+MAX_SKB_FRAGS)
> netif_start_subqueue(dev, qnum);
> }
--
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 RFC v2 1/3] virtio_net: enable tx interrupt
On 10/15/2014 10:32 PM, Michael S. Tsirkin wrote:
> On newer hosts that support delayed tx interrupts,
> we probably don't have much to gain from orphaning
> packets early.
>
> Based on patch by Jason Wang.
>
> Note: this might degrade performance for
> hosts without event idx support.
> Should be addressed by the next patch.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/net/virtio_net.c | 137
> ---
> 1 file changed, 94 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 13d0a8b..a9bf178 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -72,6 +72,8 @@ struct send_queue {
>
> /* Name of the send queue: output.$index */
> char name[40];
> +
> + struct napi_struct napi;
> };
>
> /* Internal representation of a receive virtqueue */
> @@ -217,15 +219,37 @@ static struct page *get_a_page(struct receive_queue
> *rq, gfp_t gfp_mask)
> return p;
> }
>
> +static unsigned int free_old_xmit_skbs(struct send_queue *sq, int budget)
> +{
> + struct sk_buff *skb;
> + unsigned int len;
> + struct virtnet_info *vi = sq->vq->vdev->priv;
> + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
> + unsigned int packets = 0;
> +
> + while (packets < budget &&
> +(skb = virtqueue_get_buf(sq->vq, &len)) != NULL) {
> + pr_debug("Sent skb %p\n", skb);
> +
> + u64_stats_update_begin(&stats->tx_syncp);
> + stats->tx_bytes += skb->len;
> + stats->tx_packets++;
> + u64_stats_update_end(&stats->tx_syncp);
> +
> + dev_kfree_skb_any(skb);
> + packets++;
> + }
> +
> + return packets;
> +}
> +
> static void skb_xmit_done(struct virtqueue *vq)
> {
> struct virtnet_info *vi = vq->vdev->priv;
> + struct send_queue *sq = &vi->sq[vq2txq(vq)];
>
> - /* Suppress further interrupts. */
> - virtqueue_disable_cb(vq);
> -
> - /* We were probably waiting for more output buffers. */
> - netif_wake_subqueue(vi->dev, vq2txq(vq));
> + if (napi_schedule_prep(&sq->napi))
> + __napi_schedule(&sq->napi);
> }
>
> static unsigned int mergeable_ctx_to_buf_truesize(unsigned long mrg_ctx)
> @@ -774,6 +798,37 @@ again:
> return received;
> }
>
> +static int virtnet_poll_tx(struct napi_struct *napi, int budget)
> +{
> + struct send_queue *sq =
> + container_of(napi, struct send_queue, napi);
> + struct virtnet_info *vi = sq->vq->vdev->priv;
> + struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
> + unsigned int sent = 0;
> + bool enable_done;
> +
> +again:
> + __netif_tx_lock(txq, smp_processor_id());
> + virtqueue_disable_cb(sq->vq);
> + sent += free_old_xmit_skbs(sq, budget - sent);
> +
> + if (sent < budget) {
> + enable_done = virtqueue_enable_cb_delayed(sq->vq);
> + napi_complete(napi);
> + __netif_tx_unlock(txq);
> + if (unlikely(enable_done) && napi_schedule_prep(napi)) {
I think you mean unlikely(!enable_done) here?
> + virtqueue_disable_cb(sq->vq);
> + __napi_schedule(napi);
> + goto again;
> + }
> + } else {
> + __netif_tx_unlock(txq);
> + }
> +
> + netif_wake_subqueue(vi->dev, vq2txq(sq->vq));
> + return sent;
> +}
> +
> #ifdef CONFIG_NET_RX_BUSY_POLL
> /* must be called with local_bh_disable()d */
> static int virtnet_busy_poll(struct napi_struct *napi)
> @@ -822,30 +877,12 @@ static int virtnet_open(struct net_device *dev)
> if (!try_fill_recv(&vi->rq[i], GFP_KERNEL))
> schedule_delayed_work(&vi->refill, 0);
> virtnet_napi_enable(&vi->rq[i]);
> + napi_enable(&vi->sq[i].napi);
> }
>
> return 0;
> }
>
> -static void free_old_xmit_skbs(struct send_queue *sq)
> -{
> - struct sk_buff *skb;
> - unsigned int len;
> - struct virtnet_info *vi = sq->vq->vdev->priv;
> - struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
> -
> - while ((skb = virtqueue_get_buf(sq->vq, &len)) != NULL) {
> - pr_debug("Sent skb %p\n", skb);
> -
> - u64_stats_update_begin(&stats->tx_syncp);
> - stats->tx_bytes += skb->len;
> - stats->tx_packets++;
> - u64_stats_update_end(&stats->tx_syncp);
> -
> - dev_kfree_skb_any(skb);
> - }
> -}
> -
> static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
> {
> struct skb_vnet_hdr *hdr;
> @@ -911,7 +948,9 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff
> *skb)
> sg_set_buf(sq->sg, hdr, hdr_len);
> num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
> }
> - return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, G
Re: [RFC PATCH net-next 1/6] virtio: make sure used event never go backwards
On 10/15/2014 07:38 PM, Michael S. Tsirkin wrote: > On Wed, Oct 15, 2014 at 06:44:41PM +0800, Jason Wang wrote: >> On 10/15/2014 06:32 PM, Michael S. Tsirkin wrote: >>> On Wed, Oct 15, 2014 at 06:13:19PM +0800, Jason Wang wrote: On 10/15/2014 05:34 PM, Michael S. Tsirkin wrote: > On Wed, Oct 15, 2014 at 03:25:25PM +0800, Jason Wang wrote: >> This patch checks the new event idx to make sure used event idx never >> goes back. This is used to synchronize the calls between >> virtqueue_enable_cb_delayed() and virtqueue_enable_cb(). >> >> Cc: Rusty Russell >> Cc: Michael S. Tsirkin >> Signed-off-by: Jason Wang > the implication being that moving event idx back might cause some race > condition? This will cause race condition when tx interrupt is enabled. Consider the following cases 1) tx napi was scheduled 2) start_xmit() call virtqueue_enable_cb_delayed() and disable cb, [used event is vq->last_used_idx + 3/4 pendg bufs] 3) tx napi enable the callback by virtqueue_enable_cb() [ used event is vq->last_used_idx ] After step 3, used event was moved back, unnecessary tx interrupt was triggered. >>> Well unnecessary interrupts are safe. >> But it that is what we want to reduce. > It's all about correctness. I don't think mixing enable_cb > and enable_cb_delayed makes sense, let's just make > virtio behave correctly if that happens, no need to > optimize for that. Then as you said, need document or add WARN_ON() or BUG() in case both of the two are used. > > >>> With your patch caller of virtqueue_enable_cb will not get an >>> interrupt on the next buffer which is not safe. >>> >>> If you don't want an interrupt on the next buffer, don't >>> call virtqueue_enable_cb. >> So something like this patch should be done in virtio core somewhere >> else. Virtio-net can not do this since it does not have the knowledge of >> event index. > Take a look at my patch - no calls to enable_cb, only > enable_cb_delayed, so we should be fine. > > If yes but please describe the race explicitly. > Is there a bug we need to fix on stable? Looks not, current code does not have such race condition. > Please also explicitly describe a configuration that causes event idx > to go back. > > All this info should go in the commit log. Will do this. >> --- >> drivers/virtio/virtio_ring.c |7 +-- >> 1 files changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c >> index 3b1f89b..1b3929f 100644 >> --- a/drivers/virtio/virtio_ring.c >> +++ b/drivers/virtio/virtio_ring.c >> @@ -559,14 +559,17 @@ unsigned virtqueue_enable_cb_prepare(struct >> virtqueue *_vq) >> u16 last_used_idx; >> >> START_USE(vq); >> - >> +last_used_idx = vq->last_used_idx; >> /* We optimistically turn back on interrupts, then check if >> there was >> * more to do. */ >> /* Depending on the VIRTIO_RING_F_EVENT_IDX feature, we need to >> * either clear the flags bit or point the event index at the >> next >> * entry. Always do both to keep code simple. */ >> vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_INTERRUPT; >> -vring_used_event(&vq->vring) = last_used_idx = >> vq->last_used_idx; >> +/* Make sure used event never go backwards */ > s/go/goes/ > >> +if (!vring_need_event(vring_used_event(&vq->vring), >> + vq->vring.avail->idx, last_used_idx)) >> +vring_used_event(&vq->vring) = last_used_idx; > The result will be that driver will *not* get an interrupt > on the next consumed buffer, which is likely not what driver > intended when it called virtqueue_enable_cb. This will only happen when we want to delay the interrupt for next few consumed buffers (virtqueue_enable_cb_delayed() was called). For the other case, vq->last_used_idx should be ahead of previous used event. Do you see any other case? >>> Call virtqueue_enable_cb_delayed, later call virtqueue_enable_cb. If >>> event index is not updated in virtqueue_enable_cb, driver will not get >>> an interrupt on the next buffer. >> This is just what we want I think. The interrupt was not lost but fired >> after 3/4 pending buffers were consumed. Do you see any real issue on this? > Yes, this violates the API. For example device might never > consume the rest of buffers. Then it should be a bug of device which is out of the control of guest. If not, device might never also consume 3/4 rest of buffers. > > Instead, how about we simply document the requirement that drivers either > always call virtqueue_enable_cb_delayed or virtqueue_enable_cb > but not both? We need call them both when tx interrupt
Re: [PATCH 6/6] cpufreq: Loongson1: Add cpufreq driver for Loongson1B (UPDATED)
On 16 October 2014 23:33, Aaro Koskinen wrote: > Why it's called "ls1x-cpufreq" instead of "loongson1_cpufreq"? This is what Kelvin told me when I asked him the same query: Other drivers of loongson1 are already named *ls1x*, such as clk-ls1x.c and rtc-ls1x.c. So I just keep pace with them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] usb: dwc2: gadget: sparse warning of context imbalance
sparse was giving the following warning:
warning: context imbalance in 's3c_hsotg_ep_enable'
- different lock contexts for basic block
we were returning ENOMEM while still holding the spinlock.
The sparse warning was fixed by releasing the spinlock before return.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/dwc2/gadget.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7b5856f..7f25527 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2561,8 +2561,10 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
hs_ep->fifo_size = val;
break;
}
- if (i == 8)
- return -ENOMEM;
+ if (i == 8) {
+ ret = -ENOMEM;
+ goto error;
+ }
}
/* for non control endpoints, set PID to D0 */
@@ -2579,6 +2581,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
/* enable the endpoint interrupt */
s3c_hsotg_ctrl_epint(hsotg, index, dir_in, 1);
+error:
spin_unlock_irqrestore(&hsotg->lock, flags);
return 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/
[PATCH v3 2/2] usb: dwc2: gadget: modify return statement
modified the function to have a single return statement at the end
instead of multiple return statement in the middle of the function
to improve the readability of the code.
This patch depends on the previous patch of the series.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/dwc2/gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7f25527..e8a8fc7 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2471,7 +2471,8 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
dir_in = (desc->bEndpointAddress & USB_ENDPOINT_DIR_MASK) ? 1 : 0;
if (dir_in != hs_ep->dir_in) {
dev_err(hsotg->dev, "%s: direction mismatch!\n", __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto error1;
}
mps = usb_endpoint_maxp(desc);
@@ -2583,6 +2584,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
error:
spin_unlock_irqrestore(&hsotg->lock, flags);
+error1:
return 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: [patch 4/5] mm: memcontrol: continue cache reclaim from offlined groups
On Thu, 16 Oct 2014 23:02:21 -0400 Johannes Weiner wrote:
> Andrew, could you update the changelog in place to have that paragraph
> read
>
> Since c2931b70a32c ("cgroup: iterate cgroup_subsys_states directly")
> css iterators now also include offlined css, so memcg iterators can be
> changed to include offlined children during reclaim of a group, and
> leftover cache can just stay put.
Done.
--
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 1/2] mm: Update generic gup implementation to handle hugepage directory
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the hugepage directory.
Signed-off-by: Aneesh Kumar K.V
---
Changes from V1:
* Folded arm/arm64 related changes into the patch
* Dropped pgd_huge from generic header
arch/arm/include/asm/pgtable.h | 2 +
arch/arm64/include/asm/pgtable.h | 2 +
include/linux/mm.h | 26 +
mm/gup.c | 113 +++
4 files changed, 84 insertions(+), 59 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 90aa4583b308..46f81fbaa4a5 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -181,6 +181,8 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
/* to find an entry in a kernel page-table-directory */
#define pgd_offset_k(addr) pgd_offset(&init_mm, addr)
+#define pgd_huge(pgd) (0)
+
#define pmd_none(pmd) (!pmd_val(pmd))
#define pmd_present(pmd) (pmd_val(pmd))
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index cefd3e825612..ed8f42497ac4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -464,6 +464,8 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
+#define pgd_huge(pgd) (0)
+
/*
* Encode and decode a swap entry:
* bits 0-1: present (must be zero)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 02d11ee7f19d..f97732412cb4 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1219,6 +1219,32 @@ long get_user_pages(struct task_struct *tsk, struct
mm_struct *mm,
struct vm_area_struct **vmas);
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
+
+#ifdef CONFIG_HAVE_GENERIC_RCU_GUP
+#ifndef is_hugepd
+/*
+ * Some architectures support hugepage directory format that is
+ * required to support different hugetlbfs sizes.
+ */
+typedef struct { unsigned long pd; } hugepd_t;
+#define is_hugepd(hugepd) (0)
+#define __hugepd(x) ((hugepd_t) { (x) })
+static inline int gup_hugepd(hugepd_t hugepd, unsigned long addr,
+unsigned pdshift, unsigned long end,
+int write, struct page **pages, int *nr)
+{
+ return 0;
+}
+#else
+extern int gup_hugepd(hugepd_t hugepd, unsigned long addr,
+ unsigned pdshift, unsigned long end,
+ int write, struct page **pages, int *nr);
+#endif
+extern int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
+ unsigned long sz, unsigned long end, int write,
+ struct page **pages, int *nr);
+#endif
+
struct kvec;
int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
struct page **pages);
diff --git a/mm/gup.c b/mm/gup.c
index cd62c8c90d4a..13c560ef9ddf 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -786,65 +786,31 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
unsigned long end,
}
#endif /* __HAVE_ARCH_PTE_SPECIAL */
-static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
- unsigned long end, int write, struct page **pages, int *nr)
+int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
+unsigned long sz, unsigned long end, int write,
+struct page **pages, int *nr)
{
- struct page *head, *page, *tail;
int refs;
+ unsigned long pte_end;
+ struct page *head, *page, *tail;
- if (write && !pmd_write(orig))
- return 0;
-
- refs = 0;
- head = pmd_page(orig);
- page = head + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
- tail = page;
- do {
- VM_BUG_ON_PAGE(compound_head(page) != head, page);
- pages[*nr] = page;
- (*nr)++;
- page++;
- refs++;
- } while (addr += PAGE_SIZE, addr != end);
- if (!page_cache_add_speculative(head, refs)) {
- *nr -= refs;
+ if (write && !pte_write(orig))
return 0;
- }
- if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
- *nr -= refs;
- while (refs--)
- put_page(head);
+ if (!pte_present(orig))
return 0;
- }
- /*
-* Any tail pages need their mapcount reference taken before we
-* return. (This allows the THP code to bump their ref count when
-* they are split into base pages).
-*/
- while (refs--) {
- if (PageTail(tail))
- get_huge_page_tail(tail);
- tail++;
- }
-
- return 1;
-}
-
-static int gup_huge_pud(pud_t orig, pud_t
[PATCH V2 2/2] arch/powerpc: Switch to generic RCU get_user_pages_fast
This patch switch the ppc arch to use the generic RCU based
gup implementation.
Signed-off-by: Aneesh Kumar K.V
---
Changes from V1:
* added pgd_huge definition back
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/hugetlb.h | 8 +-
arch/powerpc/include/asm/page.h | 3 +-
arch/powerpc/include/asm/pgtable-ppc64.h | 1 -
arch/powerpc/include/asm/pgtable.h | 5 -
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/gup.c| 235 ---
arch/powerpc/mm/hugetlbpage.c| 27 ++--
8 files changed, 21 insertions(+), 261 deletions(-)
delete mode 100644 arch/powerpc/mm/gup.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 88eace4e28c3..7af887dc6aed 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -148,6 +148,7 @@ config PPC
select HAVE_ARCH_AUDITSYSCALL
select ARCH_SUPPORTS_ATOMIC_RMW
select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
+ select HAVE_GENERIC_RCU_GUP
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/hugetlb.h
b/arch/powerpc/include/asm/hugetlb.h
index 623f2971ce0e..7855cce9c969 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -48,7 +48,7 @@ static inline unsigned int hugepd_shift(hugepd_t hpd)
#endif /* CONFIG_PPC_BOOK3S_64 */
-static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned long addr,
+static inline pte_t *hugepte_offset(hugepd_t hpd, unsigned long addr,
unsigned pdshift)
{
/*
@@ -58,9 +58,9 @@ static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned
long addr,
*/
unsigned long idx = 0;
- pte_t *dir = hugepd_page(*hpdp);
+ pte_t *dir = hugepd_page(hpd);
#ifndef CONFIG_PPC_FSL_BOOK3E
- idx = (addr & ((1UL << pdshift) - 1)) >> hugepd_shift(*hpdp);
+ idx = (addr & ((1UL << pdshift) - 1)) >> hugepd_shift(hpd);
#endif
return dir + idx;
@@ -193,7 +193,7 @@ static inline void flush_hugetlb_page(struct vm_area_struct
*vma,
}
#define hugepd_shift(x) 0
-static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned long addr,
+static inline pte_t *hugepte_offset(hugepd_t hpd, unsigned long addr,
unsigned pdshift)
{
return 0;
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 26fe1ae15212..aeca81947dc6 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -379,12 +379,13 @@ static inline int hugepd_ok(hugepd_t hpd)
}
#endif
-#define is_hugepd(pdep) (hugepd_ok(*((hugepd_t *)(pdep
+#define is_hugepd(hpd) (hugepd_ok(hpd))
int pgd_huge(pgd_t pgd);
#else /* CONFIG_HUGETLB_PAGE */
#define is_hugepd(pdep)0
#define pgd_huge(pgd) 0
#endif /* CONFIG_HUGETLB_PAGE */
+#define __hugepd(x) ((hugepd_t) { (x) })
struct page;
extern void clear_user_page(void *page, unsigned long vaddr, struct page *pg);
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index ae153c40ab7c..29c36242cc6a 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -575,6 +575,5 @@ static inline int pmd_move_must_withdraw(struct spinlock
*new_pmd_ptl,
*/
return true;
}
-
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PGTABLE_PPC64_H_ */
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 316f9a5da173..4a67c1ddb91b 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -274,11 +274,6 @@ extern void paging_init(void);
*/
extern void update_mmu_cache(struct vm_area_struct *, unsigned long, pte_t *);
-extern int gup_hugepd(hugepd_t *hugepd, unsigned pdshift, unsigned long addr,
- unsigned long end, int write, struct page **pages, int
*nr);
-
-extern int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
- unsigned long end, int write, struct page **pages, int
*nr);
#ifndef CONFIG_TRANSPARENT_HUGEPAGE
#define pmd_large(pmd) 0
#define has_transparent_hugepage() 0
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 325e861616a1..438dcd3fd0d1 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -6,7 +6,7 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC)
-obj-y := fault.o mem.o pgtable.o gup.o mmap.o \
+obj-y := fault.o mem.o pgtable.o mmap.o \
init_$(CONFIG_WORD_SIZE).o \
pgtable_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_PPC_MMU_NOHASH) += mmu_context_nohash.o tlb_nohash.o \
diff --git a/arch/power
Re: [PATCH] xen: avoid race in p2m handling
On 10/16/2014 05:50 PM, David Vrabel wrote:
On 16/10/14 07:13, Juergen Gross wrote:
When a new p2m leaf is allocated this leaf is linked into the p2m tree
via cmpxchg. Unfortunately the compare value for checking the success
of the update is read after checking for the need of a new leaf. It is
possible that a new leaf has been linked into the tree concurrently
in between. This could lead to a leaked memory page and to the loss of
some p2m entries.
Avoid the race by using the read compare value for checking the need
of a new p2m leaf.
[...]
@@ -579,11 +580,10 @@ static bool alloc_p2m(unsigned long pfn)
}
}
- if (p2m_top[topidx][mididx] == p2m_identity ||
- p2m_top[topidx][mididx] == p2m_missing) {
+ p2m_orig = p2m_top[topidx][mididx];
Do you need to use ACCESS_ONCE() here?
Yes, you are probably right. Should I send a new patch or do you want
to modify it?
Juergen
--
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 v11 0/3] Add drm driver for Rockchip Socs
On 2014年10月17日 08:46, Dave Airlie wrote: On 17 October 2014 10:40, Mark yao wrote: Hi I think Rockchip drm driver is ready now, can it land? I probably want to wait until -rc1 though I suppose since its a new driver and self contained we might be able to see if Linus is interested in squeezing it in. Can you send me a git pull request for it against drm-next or even 3.17. Dave. Hi, Dave the git pull request: The following changes since commit 4db36870b92cdf5a79615aeabc68efc97df13918: FROMLIST: iommu/rockchip: rk3288 iommu driver (2014-10-17 10:26:18 +0800) are available in the git repository at: https://github.com/markyzq/kernel-drm-rockchip.git mydrm for you to fetch changes up to 0db2be88bea08ab8afe5e3d13f8a2c9e637a9514: dt-bindings: video: Add documentation for rockchip vop (2014-10-17 10:27:15 +0800) Mark yao (3): drm: rockchip: Add basic drm driver dt-bindings: video: Add for rockchip display subsytem dt-bindings: video: Add documentation for rockchip vop .../devicetree/bindings/video/rockchip-drm.txt | 19 + .../devicetree/bindings/video/rockchip-vop.txt | 58 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/rockchip/Kconfig | 17 + drivers/gpu/drm/rockchip/Makefile |8 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 449 ++ drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 54 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++ drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 + drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++ drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 293 drivers/gpu/drm/rockchip/rockchip_drm_gem.h| 54 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1427 drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 196 +++ 16 files changed, 3036 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt create mode 100644 drivers/gpu/drm/rockchip/Kconfig create mode 100644 drivers/gpu/drm/rockchip/Makefile create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.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] xen/setup: add paranoid index check and warning
On 10/14/2014 09:28 AM, Martin Kelly wrote: > On Tue, Oct 14, 2014 at 9:09 AM, David Vrabel wrote: >> On 14/10/14 15:04, Martin Kelly wrote: >>> On 10/14/2014 02:22 AM, David Vrabel wrote: On 14/10/14 02:19, Martin Kelly wrote: > In a call to set_phys_range_identity, i-1 is used without checking that > i is non-zero. Although unlikely, a bug in the code before it could > cause the value to be 0, leading to erroneous behavior. This patch adds > a check against 0 value and a corresponding warning. This can only happen if the toolstack supplies a memory map with zero entries. I could see justification for adding a panic at the top of this function in this case, but I can't see the usefulness of this warning. >>> >>> Yes, a panic is probably appropriate. What do you think about the >>> relative merits of panicing in the callers vs. in the >>> sanitize_e820_map function itself (thus to avoid a bunch of similar >>> error checks in the callers)? >> >> For Xen, it should panic immediately after getting the memory map. >> >> You will note that there is fallback code for the case when no memory >> map is provided. But I do not think this should be used in the case >> where the toolstack provided an empty memory map. >> >> David > > Sounds like the flow should be as follows: > 1) Ask Xen for the memory map. > 2) If no memory map is provided, use fallback code. > 3) If the memory map has 0 entries, panic. > > I will revise the patch to do that. > I have sent a revision adding the panic: "[PATCH] x86/xen: panic on bad Xen-provided memory map" -- 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] x86/xen: panic on bad Xen-provided memory map
Panic if Xen provides a memory map with 0 entries. Although this is unlikely, it is better to catch the error at the point of seeing the map than later on as a symptom of some other crash. Signed-off-by: Martin Kelly --- arch/x86/xen/setup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index af72161..29834b3 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -595,6 +595,7 @@ char * __init xen_memory_setup(void) rc = 0; } BUG_ON(rc); + BUG_ON(memmap.nr_entries == 0); /* * Xen won't allow a 1:1 mapping to be created to UNUSABLE -- 2.1.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/
linux-next: Tree for Oct 17
Hi all, Please do not add any material intended for v3.19 to your linux-next included trees until after v3.18-rc1 has been released. Changes since 20141016: The thermal tree still had its build failure for which I reverted a commit. The kvm-arm tree gained a conflict against Linus' tree. The akpm-current tree lost its build failure. Non-merge commits (relative to Linus' tree): 1129 1098 files changed, 32868 insertions(+), 16497 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 225 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (0429fbc0bdc2 Merge branch 'for-3.18-consistent-ops' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (ad684dce87fa ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset") Merging m68k-current/for-linus (24cae7934cf1 m68k: Reformat arch/m68k/mm/hwtest.c) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging powerpc-merge-mpe/for-linus (aeba3731b150 powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change) Merging sparc/master (f4da3628dc7c sparc64: Fix FPU register corruption with AES crypto offload.) Merging net/master (2c6ba4b15b5e netlink: fix description of portid) Merging ipsec/master (b8c203b2d2fc xfrm: Generate queueing routes only from route lookup functions) Merging sound-current/for-linus (c8b00fd2f4c5 ALSA: hda_intel: Add Device IDs for Intel Sunrise Point PCH) Merging pci-current/for-linus (8c33e57e6fb3 Merge branch 'remove-weak-function-declarations' into for-linus) Merging wireless/master (f8adaf0ae978 brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()) Merging driver-core.current/driver-core-linus (5e40d331bd72 Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security) Merging tty.current/tty-linus (9e82bf014195 Linux 3.17-rc5) Merging usb.current/usb-linus (0f33be009b89 Linux 3.17-rc6) Merging usb-gadget-fixes/fixes (0b93a4c838fa usb: dwc3: fix TRB completion when multiple TRBs are started) Merging usb-serial-fixes/usb-linus (dee80ad12d2b USB: cp210x: add support for Seluxit USB dongle) Merging staging.current/staging-linus (80213c03c415 Merge tag 'pci-v3.18-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging char-misc.current/char-misc-linus (9e82bf014195 Linux 3.17-rc5) Merging input-current/for-linus (4dfb15cd5aaa Input: xpad - add Thrustmaster as Xbox 360 controller vendor) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (be34c4ef693f crypto: sha - Handle unaligned input data in generic sha256 and sha512.) Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL dereference in selftest removal code) M
Re: [alsa-devel] [PATCH v2 2/2] ALSA: au88x0: pr_* replaced with dev_*
On Thu, Oct 16, 2014 at 03:45:44PM +0200, Takashi Iwai wrote: > At Thu, 16 Oct 2014 11:04:34 +0800, > Raymond Yau wrote: > > > > since these 2 commits: > > > > > > > > commit e28d713704117bca0820c732210df6075b09f13b > > > > Author: Linus Torvalds > > > > Date: Tue Jun 16 11:02:28 2009 -0700 > > > > > > > > printk: Add KERN_DEFAULT printk log-level > > > > > > > > This adds a KERN_DEFAULT loglevel marker, for when you cannot decide > > > > which loglevel you want, and just want to keep an existing printk > > > > with the default loglevel. > > > > > > > > The difference between having KERN_DEFAULT and having no log-level > > > > marker at all is two-fold: > > > > > > > > - having the log-level marker will now force a new-line if the > > > >previous printout had not added one (perhaps because it forgot, > > > >but perhaps because it expected a continuation) > > > > > > > > - having a log-level marker is required if you are printing out a > > > >message that otherwise itself could perhaps otherwise be mistaken > > > >for a log-level. > > > > > > > > and > > > > > > > > commit 5fd29d6ccbc98884569d6f3105aeca70858b3e0f > > > > Author: Linus Torvalds > > > > Date: Tue Jun 16 10:57:02 2009 -0700 > > > > > > > > printk: clean up handling of log-levels and newlines > > > > > > > > It used to be that we would only look at the log-level in a printk() > > > > after explicit newlines, which can cause annoying problems when the > > > > previous printk() did not end with a '\n'. In that case, the > > log-level > > > > marker would be just printed out in the middle of the line, and be > > > > seen as just noise rather than change the logging level. > > > > > > > > This changes things to always look at the log-level in the first > > > > bytes of the printout. If a log level marker is found, it is always > > > > used as the log-level. Additionally, if no newline existed, one is > > > > added (unless the log-level is the explicit KERN_CONT marker, to > > > > explicitly show that it's a continuation of a previous line). > > > > > > > > > > > > > > > > Do the driver still need two dev_info at startup and shutdown since most > > pci drivers won't print anything to system log when the driver is loaded or > > unloaded ? > > Definitely not needed, but the intention of this patch is to convert > to dev_*(). There are some cleanups, but it's for removing redundant > strings, so it's a bit different from changing the log level of the > original code. You can submit an additional patch to adjust the log > levels more appropriately. > sure , I will submit a separate patch for cleaning up these extra dev_info. thanks sudip > > Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms
From: Tang Yuantian
Freescale introduced new ARM core-based SoCs which support dynamic
frequency switch feature. DFS on new SoCs are compatible with current
PowerPC CoreNet platforms. In order to support those new platforms,
this driver needs to be slightly adjusted. The main changes include:
1. Changed the names of driver and functions in driver.
2. Added two new functions get_cpu_physical_id() and get_bus_freq().
3. Used a new way to get all the CPUs which sharing clock wire.
Signed-off-by: Tang Yuantian
---
drivers/cpufreq/Kconfig.arm| 8 ++
drivers/cpufreq/Kconfig.powerpc| 11 +-
drivers/cpufreq/Makefile | 2 +-
.../{ppc-corenet-cpufreq.c => qoriq-cpufreq.c} | 150 ++---
4 files changed, 114 insertions(+), 57 deletions(-)
rename drivers/cpufreq/{ppc-corenet-cpufreq.c => qoriq-cpufreq.c} (72%)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 83a75dc..1925ae94 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -247,3 +247,11 @@ config ARM_TEGRA_CPUFREQ
default y
help
This adds the CPUFreq driver support for TEGRA SOCs.
+
+config QORIQ_CPUFREQ
+ tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
+ depends on OF && COMMON_CLK
+ select CLK_PPC_CORENET
+ help
+ This adds the CPUFreq driver support for Freescale QorIQ SoCs
+ which are capable of changing the CPU's frequency dynamically.
diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
index 72564b7..3a34248 100644
--- a/drivers/cpufreq/Kconfig.powerpc
+++ b/drivers/cpufreq/Kconfig.powerpc
@@ -23,14 +23,13 @@ config CPU_FREQ_MAPLE
This adds support for frequency switching on Maple 970FX
Evaluation Board and compatible boards (IBM JS2x blades).
-config PPC_CORENET_CPUFREQ
- tristate "CPU frequency scaling driver for Freescale E500MC SoCs"
- depends on PPC_E500MC && OF && COMMON_CLK
+config QORIQ_CPUFREQ
+ tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
+ depends on OF && COMMON_CLK
select CLK_PPC_CORENET
help
- This adds the CPUFreq driver support for Freescale e500mc,
- e5500 and e6500 series SoCs which are capable of changing
- the CPU's frequency dynamically.
+ This adds the CPUFreq driver support for Freescale QorIQ SoCs
+ which are capable of changing the CPU's frequency dynamically.
config CPU_FREQ_PMAC
bool "Support for Apple PowerBooks"
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 40c53dc..0020049 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -84,7 +84,7 @@ obj-$(CONFIG_CPU_FREQ_CBE)+= ppc-cbe-cpufreq.o
ppc-cbe-cpufreq-y += ppc_cbe_cpufreq_pervasive.o
ppc_cbe_cpufreq.o
obj-$(CONFIG_CPU_FREQ_CBE_PMI) += ppc_cbe_cpufreq_pmi.o
obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
-obj-$(CONFIG_PPC_CORENET_CPUFREQ) += ppc-corenet-cpufreq.o
+obj-$(CONFIG_QORIQ_CPUFREQ)+= qoriq-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC)+= pmac32-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC64) += pmac64-cpufreq.o
obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += pasemi-cpufreq.o
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
b/drivers/cpufreq/qoriq-cpufreq.c
similarity index 72%
rename from drivers/cpufreq/ppc-corenet-cpufreq.c
rename to drivers/cpufreq/qoriq-cpufreq.c
index bee5df7..80def0c 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -1,7 +1,7 @@
/*
* Copyright 2013 Freescale Semiconductor, Inc.
*
- * CPU Frequency Scaling driver for Freescale PowerPC corenet SoCs.
+ * CPU Frequency Scaling driver for Freescale QorIQ SoCs.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
/**
* struct cpu_data - per CPU data struct
@@ -69,9 +68,6 @@ static const u32 *fmask;
static DEFINE_PER_CPU(struct cpu_data *, cpu_data);
-/* cpumask in a cluster */
-static DEFINE_PER_CPU(cpumask_var_t, cpu_mask);
-
#ifndef CONFIG_SMP
static inline const struct cpumask *cpu_core_mask(int cpu)
{
@@ -79,6 +75,79 @@ static inline const struct cpumask *cpu_core_mask(int cpu)
}
#endif
+#if defined(CONFIG_PPC_E500MC)
+static int get_cpu_physical_id(int cpu)
+{
+ return get_hard_smp_processor_id(cpu);
+}
+#elif defined(CONFIG_ARM)
+static int get_cpu_physical_id(int cpu)
+{
+ return topology_core_id(cpu);
+}
+#endif
+
+static u32 get_bus_freq(void)
+{
+ struct device_node *soc;
+ u32 sysfreq;
+
+ soc = of_find_node_by_type(NULL, "soc");
+ if (!soc)
+ return 0;
+
+ if (of_property_read_u32(soc, "bus-frequency", &sysfreq))
+
Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
On Thu, Oct 16, 2014 at 4:12 PM, Greg Kroah-Hartman wrote: > On Thu, Oct 16, 2014 at 10:09:04AM -0700, John Stultz wrote: >> On Thu, Oct 16, 2014 at 5:47 AM, Greg Kroah-Hartman >> wrote: >> > From: Greg Kroah-Hartman >> > >> > The Android binder code has been "stable" for many years now. No matter >> >> Well, ignoring the ABI break that landed in the last year. :) > > As no one noticed, it wasn't a "break" :) > >> > This was discussed in the Android miniconf at the Plumbers conference. >> > If anyone has any objections to this, please let me know, otherwise I'm >> > queueing this up for 3.19-rc1 >> >> So my main concerns/thoughts here are: >> >> Who is going to maintain this? Has Arve agreed? > > Do we really need someone to do more work that has been done on it in > the past as an official "maintainer"? I'll be glad to do it, as I doubt > it will require any time at all. Ok. The only caution I have if Arve isn't involved is that we have in the past merged cleanup changes that introduced bugs, and it wasn't until Arve took at look at the new kernel that these were sorted out (see e194fd8a5d8e0a7eeed239a8534460724b62fe2d). So I think if at all possible getting his ack on things would be good. >> Are the Android guys comfortable with the ABI stability rules they'll >> now face? > > Just because something is in staging, doesn't mean you don't have to > follow the same ABI stability rules as the rest of the kernel. If a > change had happened to this code that broke userspace in the past, I > would have reverted it. So this should not be anything different from > what has been happening inthe past. > > And the Android developers said they were happy to see this code move > into the "real" part of the kernel. Alright then. >> Currently in the android space no one but libbinder should use the >> kernel interface. > > That is correct. If you do that, you deserve all of the pain and > suffering and rooted machines you will get. You reference this issue quite a bit, and I have a handwavy sense of the problem, but do you have a more detailed link to the specific issue here? >> Can we enforce that no one use this interface out-side of android (To >> ensure its one of those "if the abi breaks and no one notices..." edge >> cases)? > > This is the kernel, we can not dictate "use", that's the good part of > the GPLv2 :) > > Again, as no one has done this before, I strongly doubt it will happen > in the future. Well, the longer something is in the kernel, the more likely someone will depend on it. >> I'm still hopeful that a libbinder over kdbus will eventually pan out. >> I still see having two core IPC mechanisms (even if the use cases are >> different in style) as a negative, and I worry this might reduce >> motivation to unify things at the lower level. Granted, such work can >> still continue, but the incentives do change. > > Yes, things are going to change in the future, there is work happening > here, and there was a presentation at Plumbers about what is going to be > coming. > > But all of the changes will be in new code. Be it kdbus, or something > else if that doesn't work out. This existing binder.c file will not be > changing at all. This existing ABI, and codebase, is something that we > have to maintain forever for those millions of devices out there in the > real world today. So as there really is nothing left to do on it, it > deserves to be in the main part of the kernel source tree. Well, realistically, those millions of devices out there will almost *never* get a kernel version bump But yes, I'm fine with it going in. I'm just a bit surprised at how quickly thoughts change here. This does raise the question if the same standard could be held to ashmem then? That's a *much* simpler and easier to maintain chunk of code, and is just as isolated, logic wise. And while I think it would be ideal if the unpinning feature could be done more generically, if volatile ranges really doesn't have a future, then its maybe silly to hold ashmem out as well? thanks -john -- 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] arm64: mm: use macro instead of if judgement of ZONE_DMA
Hi Catalin,
I found In current arm64 code, there is no normal zone, only DMA zone.
Number of blocks type Unmovable Reclaimable Movable
Reserve CMA Isolate
Node 0, zoneDMA 142 12 69
1 280
When zone_sizes_init, zone_size[ZONE_NORMAL] is initialized to 0. (it
is 3.10, I didn't try the latest code base)
static void __init zone_sizes_init(unsigned long min, unsigned long max)
{
struct memblock_region *reg;
unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
unsigned long max_dma = min;
memset(zone_size, 0, sizeof(zone_size));
#ifdef CONFIG_ZONE_DMA
/* 4GB maximum for 32-bit only capable devices */
unsigned long max_dma_phys =
(unsigned long)(dma_to_phys(NULL, DMA_BIT_MASK(32)) + 1);
max_dma = max(min, min(max, max_dma_phys >> PAGE_SHIFT));
zone_size[ZONE_DMA] = max_dma - min;
#endif
zone_size[ZONE_NORMAL] = max - max_dma;
Then I just tried to enable ZONE_NORMAL in our platform, and found
this compiling error.
Is this ZONE_DMA cover full memory and ZONE_NORMAL = 0 strategy on
purpose ? We will not use ZONE_NORMAL on arm64 ?
On Fri, Oct 17, 2014 at 1:10 AM, Catalin Marinas
wrote:
> On Thu, Oct 16, 2014 at 10:41:01AM +0100, Yifan Zhang wrote:
>> if disable CONFIG_ZONE_DMA, ZONE_DMA becomes undefined.
>
> I agree that this is the case but can you explain why you need to
> disable ZONE_DMA? It currently is def_bool y, so it cannot be disabled
> unless you hack the Kconfig.
>
> --
> Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/5] mm: memcontrol: continue cache reclaim from offlined groups
On Wed, Oct 15, 2014 at 05:25:55PM +0200, Michal Hocko wrote:
> On Tue 14-10-14 12:20:36, Johannes Weiner wrote:
> > On cgroup deletion, outstanding page cache charges are moved to the
> > parent group so that they're not lost and can be reclaimed during
> > pressure on/inside said parent. But this reparenting is fairly tricky
> > and its synchroneous nature has led to several lock-ups in the past.
> >
> > Since css iterators now also include offlined css, memcg iterators can
> > be changed to include offlined children during reclaim of a group, and
> > leftover cache can just stay put.
>
> I think it would be nice to mention c2931b70a32c (cgroup: iterate
> cgroup_subsys_states directly) here to have a full context about the
> tryget vs tryget_online.
Yes, that commit is probably the most direct dependency.
Andrew, could you update the changelog in place to have that paragraph
read
Since c2931b70a32c ("cgroup: iterate cgroup_subsys_states directly")
css iterators now also include offlined css, so memcg iterators can be
changed to include offlined children during reclaim of a group, and
leftover cache can just stay put.
please? Thanks!
> > There is a slight change of behavior in that charges of deleted groups
> > no longer show up as local charges in the parent. But they are still
> > included in the parent's hierarchical statistics.
>
> Thank you for pulling drain_stock cleanup out. This made the patch so
> much easier to review.
>
> > Signed-off-by: Johannes Weiner
>
> Acked-by: Michal Hocko
Thanks you!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] mmc: sdhci-bcm2835: added quirk and removed udelay in write ops
On 10/14/2014 08:01 PM, Scott Branden wrote: > Added quirk SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 present in controller. > Removed udelay in write ops by using shadow registers for 16 bit > accesses to 32-bit registers (where necessary). > Optimized 32-bit operations when doing 8/16 register accesses. I'm going to assume this is identical to the patch you sent 8/15? So, I'll ignore this copy... -- 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] smaps should deal with huge zero page exactly same as normal zero page
On Fri, Oct 10, 2014 at 07:35:15AM -0700, Dave Hansen wrote: > On 10/10/2014 06:21 AM, Fengwei Yin wrote: > > @@ -787,6 +788,9 @@ check_pfn: > > return NULL; > > } > > > > + if (is_huge_zero_pfn(pfn)) > > + return NULL; > > + > > That looks a lot better. One thing, why not put the is_huge_zero_pfn() > check next to the is_zero_pfn() check? Hi, If no further comment, what's the next step to push this patch merged? :). Thanks a lot. Regards Yin, Fengwei -- 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: + freezer-check-oom-kill-while-being-frozen.patch added to -mm tree
On Thu, Oct 16, 2014 at 3:22 PM, Oleg Nesterov wrote:
> On 10/16, Cong Wang wrote:
>>
>> On Thu, Oct 16, 2014 at 2:35 PM, Oleg Nesterov wrote:
>> >
>> > If a task B is already frozen, it sleeps in D state.
>> >
>> > If OOM selects B as a victim after that, it won't be woken by
>> > SIGKILL, thus it obviously can't call should_thaw_current() and
>> > notice TIF_MEMDIE.
>>
>> I see your point now, it would be more clear if you can just quote
>> the patch instead of changelog.
>>
>> So are you saying the loop in __refrigerator() is useless?
>
> No.
>
>> Since
>> it will always stay in asleep after schedule()?
>
> Not always. But it will stay asleep in this particular case.
Hmm, so we still need to wake it up in oom killer:
if (test_tsk_thread_flag(task, TIF_MEMDIE)) {
if (unlikely(frozen(task)))
wake_up_state(task, TASK_UNINTERRUPTIBLE);
I will update the patch if Michal doesn't.
--
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/
[cpufreq] 48ed83b84da: scaling_governor write error
Hi Viresh,
FYI, our test script is broken by a commit from you:
https://git.linaro.org/people/vireshk/linux cpufreq/governor-fixes
commit 48ed83b84da331d010c5bd10b9d2f72d5308bddd ("cpufreq: Track governor-state
to disallow invalid state requests")
ee46f1592843a04d 48ed83b84da331d010c5bd10b9
--
fail:runs %reproductionfail:runs
| | |
:5 100% 5:5 TOTAL
stderr./lkp/lkp/src/setup/cpufreq_governor:line#:echo:write_error:Invalid_argument
The error messages are:
/lkp/wfg/src/setup/cpufreq_governor: line 9: echo: write error: Device or
resource busy
/lkp/wfg/src/setup/cpufreq_governor: line 9: echo: write error: Device or
resource busy
/lkp/wfg/src/setup/cpufreq_governor: line 9: echo: write error: Device or
resource busy
where the cpufreq_governor script is
#!/bin/bash
scaling_governor=$1
[[ $scaling_governor ]] || exit 0
for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
do
note "echo $scaling_governor > $file"
==> echo $scaling_governor > $file
done
Thanks,
Fengguang
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
Re: [PATCH v5 1/3] iommu/rockchip: rk3288 iommu driver
On Tue, Oct 14, 2014 at 4:02 PM, Daniel Kurtz wrote: > The rk3288 has several iommus. Each iommu belongs to a single master > device. There is one device (ISP) that has two slave iommus, but that > case is not yet supported by this driver. > > At subsys init, the iommu driver registers itself as the iommu driver for > the platform bus. The master devices find their slave iommus using the > "iommus" field in their devicetree description. Since each slave iommu > belongs to exactly one master, their is no additional data needed at probe > to associate a slave with its master. > > An iommu device's power domain, clock and irq are all shared with its > master device, and the master device must be careful to attach from the > iommu only after powering and clocking it (and leave it powered and > clocked before detaching). Because their is no guarantee what the status > of the iommu is at probe, and since the driver does not even know if the > device is powered, we delay requesting its irq until the master device > attaches, at which point we have a guarantee that the device is powered > and clocked and we can reset it and disable its interrupt mask. > > An iommu_domain describes a virtual iova address space. Each iommu_domain > has a corresponding page table that lists the mappings from iova to > physical address. > > For the rk3288 iommu, the page table has two levels: > The Level 1 "directory_table" has 1024 4-byte dte entries. > Each dte points to a level 2 "page_table". > Each level 2 page_table has 1024 4-byte pte entries. > Each pte points to a 4 KiB page of memory. > > An iommu_domain is created when a dma_iommu_mapping is created via > arm_iommu_create_mapping. Master devices can then attach themselves to > this mapping (or attach the mapping to themselves?) by calling > arm_iommu_attach_device(). This in turn instructs the iommu driver to > write the page table's physical address into the slave iommu's "Directory > Table Entry" (DTE) register. > > In fact multiple master devices, each with their own slave iommu device, > can all attach to the same mapping. The iommus for these devices will > share the same iommu_domain and therefore point to the same page table. > Thus, the iommu domain maintains a list of iommu devices which are > attached. This driver relies on the iommu core to ensure that all devices > have detached before destroying a domain. > > Signed-off-by: Daniel Kurtz > Signed-off-by: Simon Xue > Reviewed-by: Grant Grundler > Reviewed-by: Stéphane Marchesin Gentle ping. Any more feedback on the rockchip iommu driver? Thanks, -Daniel > --- > drivers/iommu/Kconfig | 12 + > drivers/iommu/Makefile | 1 + > drivers/iommu/rockchip-iommu.c | 924 > + > 3 files changed, 937 insertions(+) > create mode 100644 drivers/iommu/rockchip-iommu.c > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index dd51122..d0a1261 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -152,6 +152,18 @@ config OMAP_IOMMU_DEBUG > > Say N unless you know you need this. > > +config ROCKCHIP_IOMMU > + bool "Rockchip IOMMU Support" > + depends on ARCH_ROCKCHIP > + select IOMMU_API > + select ARM_DMA_USE_IOMMU > + help > + Support for IOMMUs found on Rockchip rk32xx SOCs. > + These IOMMUs allow virtualization of the address space used by most > + cores within the multimedia subsystem. > + Say Y here if you are using a Rockchip SoC that includes an IOMMU > + device. > + > config TEGRA_IOMMU_GART > bool "Tegra GART IOMMU Support" > depends on ARCH_TEGRA_2x_SOC > diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile > index 16edef7..3e47ef3 100644 > --- a/drivers/iommu/Makefile > +++ b/drivers/iommu/Makefile > @@ -13,6 +13,7 @@ obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o > irq_remapping.o > obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o > obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o > obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o > +obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o > obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o > obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o > obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o > diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c > new file mode 100644 > index 000..08e50fc > --- /dev/null > +++ b/drivers/iommu/rockchip-iommu.c > @@ -0,0 +1,924 @@ > +/* > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/** MMU register offsets */ > +#define RK_MMU_DTE
Re: [RFC/PATCH] gpio/pinctrl: baytrail: move gpio driver from pinctrl to gpio directory
On Thu, Oct 16, 2014 at 11:01:23AM +0300, Mika Westerberg wrote: > On Wed, Oct 15, 2014 at 09:55:42AM -0700, David Cohen wrote: > > Hi Mika, > > > > Thanks for your feedback. See below my reply. > > > > On Wed, Oct 15, 2014 at 10:08:12AM +0300, Mika Westerberg wrote: > > > On Tue, Oct 14, 2014 at 10:45:35AM -0700, David Cohen wrote: > > > > Hi Mathias, > > > > > > > > On Tue, Oct 14, 2014 at 01:35:43PM +0300, Mathias Nyman wrote: > > > > > On 13.10.2014 22:17, David Cohen wrote: > > > > > > Even though GPIO module on Intel Bay Trail is able to control pin > > > > > > functionality, it's unlikely Linux kernel driver will ever support > > > > > > it > > > > > > since BIOS should handle all pin muxing itself. > > > > > > > > > > > > Currently this driver does not register any pinctrl interface and > > > > > > doesn't call any pinctrl interface. It just uses on internal > > > > > > functions > > > > > > the 'struct pinctrl_gpio_range', which is a weak justification to > > > > > > not be > > > > > > under gpio directory. > > > > > > > > > > > > > > > > This discussion was held when gpio-baytrail was first submitted. > > > > > These threads explain the gpio/pinctrl-baytrail history: > > > > > > > > > > http://marc.info/?l=linux-kernel&m=136981432427668&w=2 > > > > > http://marc.info/?l=linux-kernel&m=137113578604763&w=2 > > > > > http://marc.info/?l=linux-kernel&m=137155497023054&w=2 > > > > > > > > Thanks for pointing that out. > > > > > > > > > > > > > > A proper pinctrl driver for baytrail is still not yet ruled out > > > > > > > > Having it inside pinctrl directory is creating some confusion because > > > > ppl expect it to implement the actual pinctrl interface. > > > > > > A typical pinctrl driver can implement both a pinctrl interface and a > > > GPIO interface. So it is not uncommon to look the GPIO drivers under > > > drivers/pinctrl/*. > > > > Agreed :) > > But pinctrl-baytrail has no pinctrl interface, just gpio. > > The hardware is capable of muxing pins etc. it just has not been > implemented because we currently don't have need for anything else. > I have seen that in some of our internal trees the driver is also muxing > alternate functions to the pins (using non-pinctrl interface). So maybe > it will get a full pinctrl support in the future. > > We certainly don't want to move it from pinctrl to gpio and then back. > > > > Furthermore the driver announces that it is a GPIO driver in its Kconfig > > > entry: > > > > > > config PINCTRL_BAYTRAIL > > > bool "Intel Baytrail GPIO pin control" > > > > > > so I don't quite get why this would confuse people. > > > > How come? You just wrote the inconsistence :) > > Well, it says it is a "GPIO pin control" :-) PINCTRL_BAYTRAIL means it implements pinctrl iterface. The text says otherwise. > > > We're enabling PINCTRL_BAYTRAIL to build a gpio only driver. > > > > > > > > We are also planning to add more Intel pinctrl (real) drivers in the > > > future. drivers/pinctrl/intel/* should be the place where people find > > > the pinctrl/GPIO drivers for newer Intel hardware. > > > > I fully agree pinctrl/gpio drivers should stay under drivers/pinctrl. > > But we're talking about a gpio driver. IMHO we should at least mention > > in the driver it lacks pinctrl interface currently but it will come in > > future. > > OK, why not. > > > A side discussion would be why a distro would want to have the pinctrl > > interface on Bay Trail. I'd assume any driver being the consumer of it > > is likely to be wrong. When Linux boots, all pins' functions should be > > already set. > > In an ideal world, yes. However, the reality has shown that BIOS/FW gets > these wrong and we need to work it around in the OS. But we never upstream these workarounds, right? :) That would be useful during internal development while we get a fix from fw developers. Any driver upstreamed for Bay Trail actually using this pinctrl interface is very likely to be wrong. > > Also for devices like MinnowBoard MAX (which has Baytrail SoC), you > actually might want to mux some other function out of certain pins. I fully agree on this one. MinnowBoard MAX is a valid reason to expose pinctrl interface. A TODO comment on Kconfig help text and/or on driver should be enough then. Br, David -- 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 kvm-arm tree with Linus' tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic-v2.c between commit 1f2bb4acc125 ("arm/arm64: KVM:
Fix unaligned access bug on gicv2 access") from Linus' tree and commit
2df36a5dd679 ("arm/arm64: KVM: Fix BE accesses to GICv2 EISR and ELRSR
regs") from the kvm-arm tree.
I fixed it up (since I don't know any better, I just used the kvm-arm
tree version) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH v1 02/10] x86, intel-mid: Remove "weak" from function declarations
Hi Bjorn and Sathya, On Thu, Oct 16, 2014 at 05:42:11PM -0700, sathyanarayanan kuppuswamy wrote: > Hi Bjorn, > > On 10/15/2014 04:26 PM, Bjorn Helgaas wrote: > >[+cc David, Kuppuswamy, x86; sorry, I botched my "stg mail" so you > >weren't included the first time] > > > >On Wed, Oct 15, 2014 at 11:05 AM, Bjorn Helgaas wrote: > >>For the following interfaces: > >> > >> get_penwell_ops() > >> get_cloverview_ops() > >> get_tangier_ops() > >> > >>there is only one implementation, so they do not need to be marked "weak". > >> > >>Remove the "weak" attribute from their declarations. > >> > >>Signed-off-by: Bjorn Helgaas > >>CC: David Cohen > >>CC: Kuppuswamy Sathyanarayanan > >>CC: x...@kernel.org > >>--- > >> arch/x86/platform/intel-mid/intel_mid_weak_decls.h |7 +++ > >> 1 file changed, 3 insertions(+), 4 deletions(-) > >> > >>diff --git a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > >>b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > >>index 46aa25c8ce06..3c1c3866d82b 100644 > >>--- a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > Please remove this file and move the contents to asm/intel-mid.h. I partially agree :) Historically, this file was created because we could not build all intel mid variants at once. So we have to select only one during compilation time, which was fixed already. But we don't need to expose those functions outside intel-mid's directory, which means asm/intel-mid.h isn't the best option IMHO. If you want, I can send a small re-work instead: we get rid of this header file completely and simplify a bit what is exposed by asm/intel-mid.h. Or you can keep this patch and then I send the re-work on top of it. Anyway I'm fine. Br, David > >>+++ b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > >>@@ -10,10 +10,9 @@ > >> */ > >> > >> > >>-/* __attribute__((weak)) makes these declarations overridable */ > >> /* For every CPU addition a new get__ops interface needs > >> * to be added. > >> */ > >>-extern void *get_penwell_ops(void) __attribute__((weak)); > >>-extern void *get_cloverview_ops(void) __attribute__((weak)); > >>-extern void *get_tangier_ops(void) __attribute__((weak)); > >>+extern void *get_penwell_ops(void); > >>+extern void *get_cloverview_ops(void); > >>+extern void *get_tangier_ops(void); > >> > > -- > Sathyanarayanan Kuppuswamy > Android kernel developer > -- 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] spi/rockchip: spi controller must be disabled in tx callback too
Signed-off-by: Addy Ke
---
drivers/spi/spi-rockchip.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 153269b..87bc16f 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -418,8 +418,10 @@ static void rockchip_spi_dma_txcb(void *data)
spin_lock_irqsave(&rs->lock, flags);
rs->state &= ~TXBUSY;
- if (!(rs->state & RXBUSY))
+ if (!(rs->state & RXBUSY)) {
+ spi_enable_chip(rs, 0);
spi_finalize_current_transfer(rs->master);
+ }
spin_unlock_irqrestore(&rs->lock, flags);
}
--
1.8.3.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: [PATCH v3 22/27] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On 2014/10/16 20:13, Sebastian Ott wrote:
> On Wed, 15 Oct 2014, Yijing Wang wrote:
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>>
>> Signed-off-by: Yijing Wang
>> ---
>> Hi Sebastian,
>>I dropped the Acked-by , because this version has a
>> lot changes compared to last. So, I guess you may want to check it again.
>
> I did and I agree with that one too.
Thanks very much!
Thanks!
Yijing.
>
> Regards,
> Sebastian
>
>> ---
>> arch/s390/include/asm/pci.h |9 +
>> arch/s390/pci/pci.c | 12 ++--
>> 2 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
>> index c030900..4d41f08 100644
>> --- a/arch/s390/include/asm/pci.h
>> +++ b/arch/s390/include/asm/pci.h
>> @@ -88,6 +88,8 @@ struct zpci_dev {
>> u32 uid;/* user defined id */
>> u8 util_str[CLP_UTIL_STR_LEN]; /* utility string */
>>
>> +struct msi_chip *msi_chip;
>> +
>> /* IRQ stuff */
>> u64 msi_addr; /* MSI address */
>> struct airq_iv *aibv; /* adapter interrupt bit vector */
>> @@ -121,6 +123,13 @@ struct zpci_dev {
>> struct dentry *debugfs_perf;
>> };
>>
>> +static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
>> +{
>> +struct zpci_dev *zpci = bus->sysdata;
>> +
>> +return zpci->msi_chip;
>> +}
>> +
>> static inline bool zdev_enabled(struct zpci_dev *zdev)
>> {
>> return (zdev->fh & (1UL << 31)) ? true : false;
>> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
>> index 552b990..bf6732f 100644
>> --- a/arch/s390/pci/pci.c
>> +++ b/arch/s390/pci/pci.c
>> @@ -358,7 +358,8 @@ static void zpci_irq_handler(struct airq_struct *airq)
>> }
>> }
>>
>> -int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
>> +static int zpci_setup_msi_irqs(struct msi_chip *chip,
>> +struct pci_dev *pdev, int nvec, int type)
>> {
>> struct zpci_dev *zdev = get_zdev(pdev);
>> unsigned int hwirq, msi_vecs;
>> @@ -434,7 +435,8 @@ out:
>> return rc;
>> }
>>
>> -void arch_teardown_msi_irqs(struct pci_dev *pdev)
>> +static void zpci_teardown_msi_irqs(struct msi_chip *chip,
>> +struct pci_dev *pdev)
>> {
>> struct zpci_dev *zdev = get_zdev(pdev);
>> struct msi_desc *msi;
>> @@ -464,6 +466,11 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev)
>> airq_iv_free_bit(zpci_aisb_iv, zdev->aisb);
>> }
>>
>> +static struct msi_chip zpci_msi_chip = {
>> +.setup_irqs = zpci_setup_msi_irqs,
>> +.teardown_irqs = zpci_teardown_msi_irqs,
>> +};
>> +
>> static void zpci_map_resources(struct zpci_dev *zdev)
>> {
>> struct pci_dev *pdev = zdev->pdev;
>> @@ -749,6 +756,7 @@ static int zpci_scan_bus(struct zpci_dev *zdev)
>> if (ret)
>> return ret;
>>
>> +zdev->msi_chip = &zpci_msi_chip;
>> zdev->bus = pci_scan_root_bus(NULL, ZPCI_BUS_NR, &pci_root_ops,
>>zdev, &resources);
>> if (!zdev->bus) {
>> --
>> 1.7.1
>>
>>
>
>
> .
>
--
Thanks!
Yijing
--
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] dmaengine: pl330: use subsys_initcall
As part of subsystem that many slave drivers depend on, it's more
appropriate for the pl330 DMA driver to be initialized at
subsys_initcall than device_initcall
Signed-off-by: Ray Jui
---
drivers/dma/pl330.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index d5149aa..abb4cae 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2811,7 +2811,17 @@ static struct amba_driver pl330_driver = {
.remove = pl330_remove,
};
-module_amba_driver(pl330_driver);
+static int __init pl330_init(void)
+{
+ return amba_driver_register(&pl330_driver);
+}
+subsys_initcall(pl330_init);
+
+static void __exit pl330_exit(void)
+{
+ amba_driver_unregister(&pl330_driver);
+}
+module_exit(pl330_exit);
MODULE_AUTHOR("Jaswinder Singh ");
MODULE_DESCRIPTION("API Driver for PL330 DMAC");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 02/10] x86, intel-mid: Remove "weak" from function declarations
Hi Bjorn, On 10/15/2014 04:26 PM, Bjorn Helgaas wrote: [+cc David, Kuppuswamy, x86; sorry, I botched my "stg mail" so you weren't included the first time] On Wed, Oct 15, 2014 at 11:05 AM, Bjorn Helgaas wrote: For the following interfaces: get_penwell_ops() get_cloverview_ops() get_tangier_ops() there is only one implementation, so they do not need to be marked "weak". Remove the "weak" attribute from their declarations. Signed-off-by: Bjorn Helgaas CC: David Cohen CC: Kuppuswamy Sathyanarayanan CC: x...@kernel.org --- arch/x86/platform/intel-mid/intel_mid_weak_decls.h |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h index 46aa25c8ce06..3c1c3866d82b 100644 --- a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h Please remove this file and move the contents to asm/intel-mid.h. +++ b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h @@ -10,10 +10,9 @@ */ -/* __attribute__((weak)) makes these declarations overridable */ /* For every CPU addition a new get__ops interface needs * to be added. */ -extern void *get_penwell_ops(void) __attribute__((weak)); -extern void *get_cloverview_ops(void) __attribute__((weak)); -extern void *get_tangier_ops(void) __attribute__((weak)); +extern void *get_penwell_ops(void); +extern void *get_cloverview_ops(void); +extern void *get_tangier_ops(void); -- Sathyanarayanan Kuppuswamy Android kernel developer -- 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 v11 0/3] Add drm driver for Rockchip Socs
On 17 October 2014 10:40, Mark yao wrote: > Hi > I think Rockchip drm driver is ready now, can it land? I probably want to wait until -rc1 though I suppose since its a new driver and self contained we might be able to see if Linus is interested in squeezing it in. Can you send me a git pull request for it against drm-next or even 3.17. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 0/3] Add drm driver for Rockchip Socs
Hi I think Rockchip drm driver is ready now, can it land? Thanks. On 2014年10月08日 18:23, Mark Yao wrote: This a series of patches is a DRM Driver for Rockchip Socs, add support for vop devices. Future patches will add additional encoders/connectors, such as eDP, HDMI. The basic "crtc" for rockchip is a "VOP" - Video Output Processor. the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar Vop devices. Vop devices support iommu mapping, we use dma-mapping API with ARM_DMA_USE_IOMMU. Changes in v2: - add DRM master device node to list all display nodes that comprise the graphics subsystem. - use the component framework to defer main drm driver probe until all VOP devices have been probed. - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by master device and each vop device can shared the drm dma mapping. - use drm_crtc_init_with_planes and drm_universal_plane_init. - remove unnecessary middle layers. - add cursor set, move funcs to rockchip drm crtc. - add vop reset. Changes in v3: - change "crtc->fb" to "crtc->primary-fb" Adviced by Daniel Vetter - init cursor plane with universal api, remove unnecessary cursor set,move Changes in v4: Adviced by David Herrmann - remove drm_platform_*() usage, use register drm device directly. Adviced by Rob Clark - remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset Changes in v5: Adviced by Arnd Bergmann - doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark - fix some incorrect dependencies. Adviced by Boris BREZILLON - fix some mistake and bugs. Adviced by Daniel Vetter - drop all special ioctl and use generic kms ioctl instead. Adviced by Rob Clark - use unlocked api for drm_fb_helper_restore_fbdev_mode. - remove unused rockchip_gem_prime_import_sg_table. Changes in v6: - set gem buffer pitch 64 bytes align, needed by mali gpu. Adviced by Daniel Kurtz - fix some mistake, bugs, remove unused define, more better code style etc. - use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable() at runtime instead of clk_prepare_enable(). - provide a help function from vop for encoder to do mode config, instead of using drm_diaplay_mode private method. - change vop mode_set timing to make it more safely. Changes in v7: - fix memory leakage problem. Changes in v8: - fix iommu crash when use dual crtc. - use frame start interrupt for vsync instead of line flag interrupt, because the win config take affect at frame start time, if we use ling flag interrupt, the address check often failed. Adviced by Daniel Kurtz - fix some bugs, mistake, remove unused function - keep clock and vop disabled when probe end - use drm_plane_helper_check_update to check update_plane if vaild Changes in v9: - fix suspend and resume bug, make iommu attach and detach safely. - fix mail info style. Changes in v10: Adviced by Andrzej Hajda - check drm_dev if it's NULL at PM suspend/resume Adviced by Sean Paul - use drm_fb_helper_prepare to init fb_helper funcs - Optimized code structure and remove some unnecessary Variables. Changes in v11: - fix mistake that use wrong variable at rockchip sys_resume/sys_suspend Mark yao (3): drm: rockchip: Add basic drm driver dt-bindings: video: Add for rockchip display subsytem dt-bindings: video: Add documentation for rockchip vop .../devicetree/bindings/video/rockchip-drm.txt | 19 + .../devicetree/bindings/video/rockchip-vop.txt | 58 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/rockchip/Kconfig | 17 + drivers/gpu/drm/rockchip/Makefile |8 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 449 ++ drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 54 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++ drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 + drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++ drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 293 drivers/gpu/drm/rockchip/rockchip_drm_gem.h| 54 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1427 drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 196 +++ 16 files changed, 3036 insertions(+) -- 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/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo
Acked-by: Marek Vasut
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
getaddrinfo slowdown in 3.17.1, due to getifaddrs
Hi,
We recently upgraded a machine from 3.14.5 to 3.17.1, and a Perl script we're
running to poll SNMP suddenly needed ten times as much time to complete.
ps shows that it keeps being in state D (ie., I/O), and strace with -ttT
shows this curious pattern:
02:11:33.106973 socket(PF_NETLINK, SOCK_RAW, 0) = 42 <0.13>
02:11:33.107013 bind(42, {sa_family=AF_NETLINK, pid=0, groups=}, 12) =
0 <0.10>
02:11:33.107051 getsockname(42, {sa_family=AF_NETLINK, pid=1128,
groups=}, [12]) = 0 <0.08>
02:11:33.107094 sendto(42, "\24\0\0\0\26\0\1\3\265^@T\0\0\0\0\0\0\0\0", 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20 <0.15>
02:11:33.107146 recvmsg(42, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{"L\0\0\0\24\0\2\0\265^@Th\4\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 332 <0.16>
02:11:33.107208 recvmsg(42, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{"H\0\0\0\24\0\2\0\265^@Th\4\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 936 <0.10>
02:11:33.107262 recvmsg(42, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=},
msg_iov(1)=[{"\24\0\0\0\3\0\2\0\265^@Th\4\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20 <0.09>
02:11:33.107313 close(42) = 0 <0.057092>
02:11:33.164529 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 42 <0.80>
Debugging with gdb indicates that this is from getaddrinfo calls, which the
program (for, well, Perl reasons) uses as part of DNS reverse lookups.
getaddrinfo wants to look at the list of interfaces on the system
(__check_pf in glibc), which calls out to netlink via getifaddrs.
Note specifically the call to close(), which takes 57 ms to complete.
This doesn't happen on every single getaddrinfo call, but more like 50% of
them. I've tried on another machine, running 3.16.3, and we don't see
anything like it.
I've distilled it down to this Perl script:
#! /usr/bin/perl
use strict;
use warnings;
use Socket::GetAddrInfo;
for my $i (1..1000) {
my ($err, @res) = Socket::GetAddrInfo::getaddrinfo("127.0.0.1", undef,
{ flags => Socket::GetAddrInfo::AI_NUMERICHOST });
}
On my 3.16.3 machine, this completes in 26 ms. On the 3.17.1 machine:
65 _seconds_! According to the stack, this is what it's doing:
[] wait_rcu_gp+0x48/0x4f
[] synchronize_sched+0x29/0x2b
[] synchronize_net+0x19/0x1b
[] netlink_release+0x25b/0x2b7
[] sock_release+0x1a/0x79
[] sock_close+0xd/0x11
[] __fput+0xdf/0x184
[] fput+0x9/0xb
[] task_work_run+0x7c/0x94
[] do_notify_resume+0x55/0x66
[] int_signal+0x12/0x17
[] 0x
strace indicates it starts off nicely, then goes completely off:
cirkus:~> time strace -e close -ttT perl test.pl
02:20:39.292060 close(3)= 0 <0.41>
02:20:39.292407 close(3)= 0 <0.37>
02:20:39.292660 close(3)= 0 <0.10>
02:20:39.292883 close(3)= 0 <0.09>
02:20:39.293100 close(3)= 0 <0.09>
[some more fast ones...]
02:20:39.311421 close(4)= 0 <0.09>
02:20:39.311927 close(3)= 0 <0.11>
02:20:39.312188 close(3)= 0 <0.072224>
02:20:39.384979 close(3)= 0 <0.059658>
02:20:39.445378 close(3)= 0 <0.048205>
02:20:39.494213 close(3)= 0 <0.060195>
^C
Is there a way to fix this? Somehow I doubt we're the only ones calling
getaddrinfo in this way. :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
--
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: getaddrinfo slowdown in 3.17.1, due to getifaddrs
On Fri, Oct 17, 2014 at 02:21:32AM +0200, Steinar H. Gunderson wrote:
> Hi,
>
> We recently upgraded a machine from 3.14.5 to 3.17.1, and a Perl script we're
> running to poll SNMP suddenly needed ten times as much time to complete.
e341694e3eb57fcda9f1adc7bfea42fe080d8d7a looks like it might cause something
like this (it certainly added the synchronize_net() call). Cc-ing people on
that commit; quoting the entire rest of the message for reference.
> ps shows that it keeps being in state D (ie., I/O), and strace with -ttT
> shows this curious pattern:
>
> 02:11:33.106973 socket(PF_NETLINK, SOCK_RAW, 0) = 42 <0.13>
> 02:11:33.107013 bind(42, {sa_family=AF_NETLINK, pid=0, groups=}, 12)
> = 0 <0.10>
> 02:11:33.107051 getsockname(42, {sa_family=AF_NETLINK, pid=1128,
> groups=}, [12]) = 0 <0.08>
> 02:11:33.107094 sendto(42, "\24\0\0\0\26\0\1\3\265^@T\0\0\0\0\0\0\0\0", 20,
> 0, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20 <0.15>
> 02:11:33.107146 recvmsg(42, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
> groups=},
> msg_iov(1)=[{"L\0\0\0\24\0\2\0\265^@Th\4\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"...,
> 4096}], msg_controllen=0, msg_flags=0}, 0) = 332 <0.16>
> 02:11:33.107208 recvmsg(42, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
> groups=},
> msg_iov(1)=[{"H\0\0\0\24\0\2\0\265^@Th\4\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"...,
> 4096}], msg_controllen=0, msg_flags=0}, 0) = 936 <0.10>
> 02:11:33.107262 recvmsg(42, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
> groups=},
> msg_iov(1)=[{"\24\0\0\0\3\0\2\0\265^@Th\4\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"...,
> 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 <0.09>
> 02:11:33.107313 close(42) = 0 <0.057092>
> 02:11:33.164529 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 42 <0.80>
>
>
> Debugging with gdb indicates that this is from getaddrinfo calls, which the
> program (for, well, Perl reasons) uses as part of DNS reverse lookups.
> getaddrinfo wants to look at the list of interfaces on the system
> (__check_pf in glibc), which calls out to netlink via getifaddrs.
> Note specifically the call to close(), which takes 57 ms to complete.
>
> This doesn't happen on every single getaddrinfo call, but more like 50% of
> them. I've tried on another machine, running 3.16.3, and we don't see
> anything like it.
>
> I've distilled it down to this Perl script:
>
> #! /usr/bin/perl
> use strict;
> use warnings;
> use Socket::GetAddrInfo;
>
> for my $i (1..1000) {
> my ($err, @res) = Socket::GetAddrInfo::getaddrinfo("127.0.0.1", undef,
> { flags => Socket::GetAddrInfo::AI_NUMERICHOST });
> }
>
> On my 3.16.3 machine, this completes in 26 ms. On the 3.17.1 machine:
> 65 _seconds_! According to the stack, this is what it's doing:
>
> [] wait_rcu_gp+0x48/0x4f
> [] synchronize_sched+0x29/0x2b
> [] synchronize_net+0x19/0x1b
> [] netlink_release+0x25b/0x2b7
> [] sock_release+0x1a/0x79
> [] sock_close+0xd/0x11
> [] __fput+0xdf/0x184
> [] fput+0x9/0xb
> [] task_work_run+0x7c/0x94
> [] do_notify_resume+0x55/0x66
> [] int_signal+0x12/0x17
> [] 0x
>
> strace indicates it starts off nicely, then goes completely off:
>
> cirkus:~> time strace -e close -ttT perl test.pl
> 02:20:39.292060 close(3)= 0 <0.41>
> 02:20:39.292407 close(3)= 0 <0.37>
> 02:20:39.292660 close(3)= 0 <0.10>
> 02:20:39.292883 close(3)= 0 <0.09>
> 02:20:39.293100 close(3)= 0 <0.09>
> [some more fast ones...]
> 02:20:39.311421 close(4)= 0 <0.09>
> 02:20:39.311927 close(3)= 0 <0.11>
> 02:20:39.312188 close(3)= 0 <0.072224>
> 02:20:39.384979 close(3)= 0 <0.059658>
> 02:20:39.445378 close(3)= 0 <0.048205>
> 02:20:39.494213 close(3)= 0 <0.060195>
> ^C
>
> Is there a way to fix this? Somehow I doubt we're the only ones calling
> getaddrinfo in this way. :-)
>
> /* Steinar */
--
Homepage: http://www.sesse.net/
--
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] procfs: Fix error handling of proc_register()
I don't see why this should print warnings instead of properly
unrolling allocations and returning an appropriate error. It's actually
leaking resources. WARN kept on EINVAL case but the leak is fixed there
as well.
to: Alexander Viro
to: linux-kernel@vger.kernel.org
cc: linux-fsde...@vger.kernel.org
Signed-off-by: Debabrata Banerjee
---
fs/proc/generic.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 317b726..89b20cc 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -304,6 +304,7 @@ static int proc_register(struct proc_dir_entry * dir,
struct proc_dir_entry * dp
dp->proc_iops = &proc_file_inode_operations;
} else {
WARN_ON(1);
+ proc_free_inum(dp->low_ino);
return -EINVAL;
}
@@ -311,9 +312,13 @@ static int proc_register(struct proc_dir_entry * dir,
struct proc_dir_entry * dp
for (tmp = dir->subdir; tmp; tmp = tmp->next)
if (strcmp(tmp->name, dp->name) == 0) {
- WARN(1, "proc_dir_entry '%s/%s' already registered\n",
- dir->name, dp->name);
- break;
+ spin_unlock(&proc_subdir_lock);
+
+ if (S_ISDIR(dp->mode))
+ dir->nlink--;
+
+ proc_free_inum(dp->low_ino);
+ return -EEXIST;
}
dp->next = dir->subdir;
--
2.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: [PATCH] Fix the x86 specializations of atomic_[set|clear]_mask
On Thu, Oct 16, 2014 at 4:24 PM, Peter Zijlstra wrote: > On Thu, Oct 16, 2014 at 12:49:43PM -0400, Patrick Palka wrote: >> On Oct 16, 2014 4:02 AM, "Peter Zijlstra" wrote: >> > >> > On Wed, Oct 15, 2014 at 04:38:01PM -0400, Patrick Palka wrote: >> > > This patch fixes a number of issues with these specializations: >> > > >> > > 1. The memory operand inside the asm specification is erroneously >> > > declared read-only instead of read-write. >> > > >> > > 2. There is no reason to require the 1st operand of andl/orl to be >> > > inside a register; the 1st operand could also be an immediate operand. >> > > So change its specification from "r" to "ir". >> > > >> > > 3. Since addr is supposed to be an atomic_t *, the memory operand >> > > should be addr->counter and not *addr. >> > > >> > > 4. These specializations should be inline functions instead of macros. >> > > >> > > 5. Finally, the "memory" clobbers are unnecessary, so they should be >> > > removed. (This is in line with the other atomic functions such as >> > > atomic_add and atomic_sub, the likes of which do not have a "memory" >> > > clobber.) >> > >> > No real problem with this, but I'm going to kill off these functions >> > when I get a little time :) >> >> Hmm why's that? > > because they're odd (inconsistent with the rest of the atomic > interfaces) and not implemented by all archs. > > See: https://lkml.org/lkml/2014/2/6/196 > > 3.18 will include up to 4/5 of that series and when I get a spare moment > I need cleanup/post the next arch sweep that will get us that 5/5 thing. > > Cool! Perhaps atomic_inc_short() should be killed off too. It currently has no callers and, despite what its name suggests, it is not even atomic.. -- 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 5/5] x86,perf: Only allow rdpmc if a perf_event is mapped
The current cap_user_rdpmc code seems rather confused to me. On x86, *all* events set cap_user_rdpmc if the global rdpmc control is set. But only x86_pmu events define .event_idx, so amd uncore events won't actually expose their rdpmc index to userspace. Would it make more sense to add a flag PERF_X86_EVENT_RDPMC_PERMITTED that gets set on all events created while rdpmc == 1, to change x86_pmu_event_idx to do something like: if (event->hw.flags & PERF_X86_EVENT_RDPMC_PERMITTED) return event->hw.event_base_rdpmc + 1; else return 0; and to change arch_perf_update_userpage cap_user_rdpmc to match PERF_X86_EVENT_RDPMC_PERMITTED? Then we could ditch the static key and greatly simplify writes to the rdpmc flag by just counting PERF_X86_EVENT_RDPMC_PERMITTED events. This would be a user-visible change on AMD, and I can't test it. On a semi-related note: would this all be nicer if there were vdso function __u64 __vdso_perf_event__read_count(int fd, void *userpage)? This is very easy to do nowadays. If we got *really* fancy, it would be possible to have an rdpmc_safe in the vdso, which has some benefits, although it would be a bit evil and wouldn't work if userspace tracers like pin are in use. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] ARM: EXYNOS: Call regulator core suspend prepare and finish functions
Hi Javier,
On 10/16/2014 07:13 PM, Javier Martinez Canillas wrote:
> The regulator framework has a set of helpers functions to be used when
> the system is entering and leaving from suspend but these are not called
> on Exynos platforms. This means that the .set_suspend_* function handlers
> defined by regulator drivers are not called when the system is suspended.
>
> Suggested-by: Doug Anderson
> Signed-off-by: Javier Martinez Canillas
> ---
> arch/arm/mach-exynos/suspend.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index cc8d237..ee9a8e0 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -443,6 +444,22 @@ static int exynos_suspend_enter(suspend_state_t state)
>
> static int exynos_suspend_prepare(void)
> {
> + int ret;
> +
> + /*
> + * REVISIT: It would be better if struct platform_suspend_ops
> + * .prepare handler get the suspend_state_t as a parameter to
> + * avoid hard-coding the suspend to mem state. It's safe to do
> + * it now only because the suspend_valid_only_mem function is
> + * used as the .valid callback used to check if a given state
> + * is supported by the platform anyways.
> + */
> + ret = regulator_suspend_prepare(PM_SUSPEND_MEM);
> + if (ret) {
> + pr_err("Failed to prepare regulators for system suspend\n");
> + return ret;
> + }
> +
> s3c_pm_check_prepare();
>
> return 0;
> @@ -451,6 +468,7 @@ static int exynos_suspend_prepare(void)
> static void exynos_suspend_finish(void)
> {
> s3c_pm_check_cleanup();
> + regulator_suspend_finish();
> }
>
> static const struct platform_suspend_ops exynos_suspend_ops = {
>
Looks good to me.
Reviewed-by: Chanwoo Choi
Thanks,
Chanwoo Choi
--
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] extcon: Implement OF-based extcon lookup properly
On 10/16/2014 10:11 PM, Marek Szyprowski wrote: > From: Tomasz Figa > > Platform bus is not the only way to have extcon devices, so current > implementation of of_extcon_get_extcon_dev() is broken. Also using > parent device node only to get device name is quite ugly. > > This patch reimplements of_extcon_get_extcon_dev() to do exactly the > same as extcon_get_extcon_dev() but instead of comparing names, compare > node pointers. > > Signed-off-by: Tomasz Figa > [mszyprow: simplified the code] > Signed-off-by: Marek Szyprowski > --- > drivers/extcon/extcon-class.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) Applied it. Thank you. Chanwoo Choi -- 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] Staging: rts5208: rtsx_scsi: Fixed a brace coding style issue
Fixed a coding style issue.
Signed-off-by: Mike Roocroft
---
drivers/staging/rts5208/rtsx_scsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_scsi.c
b/drivers/staging/rts5208/rtsx_scsi.c
index bbbf796..1161082 100644
--- a/drivers/staging/rts5208/rtsx_scsi.c
+++ b/drivers/staging/rts5208/rtsx_scsi.c
@@ -584,9 +584,8 @@ static int start_stop_unit(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
case MAKE_MEDIUM_READY:
case LOAD_MEDIUM:
- if (check_card_ready(chip, lun)) {
+ if (check_card_ready(chip, lun))
return TRANSPORT_GOOD;
- }
set_sense_type(chip, lun, SENSE_TYPE_MEDIA_NOT_PRESENT);
TRACE_RET(chip, TRANSPORT_FAILED);
--
2.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/
[PULL] One modules patch
The following changes since commit 184c3fc3f52fb75800deb76deffb70907d1f76ea: moduleparam: Resolve missing-field-initializer warning (2014-09-11 09:59:25 +0930) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/modules-next-for-linus for you to fetch changes up to d3051b489aa81ca9ba62af366149ef42b8dae97c: modules, lock around setting of MODULE_STATE_UNFORMED (2014-10-15 10:20:09 +1030) A single panic fix for a rare race, stable CC'd. Cheers, Rusty. Prarit Bhargava (1): modules, lock around setting of MODULE_STATE_UNFORMED kernel/module.c | 2 ++ 1 file changed, 2 insertions(+) -- 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:module Fix coding style errors and warnings.
Ionut Alexa writes:
> Fixed codin style errors and warnings. Changes printk with
> print_debug/warn. Changed seq_printf to seq_puts.
>
> Signed-off-by: Ionut Alexa
Hi Ionut,
Please drop the following changes:
> @@ -110,7 +110,7 @@ struct list_head *kdb_modules = &modules; /* kdb needs
> the list of modules */
> #ifdef CONFIG_MODULE_SIG_FORCE
> static bool sig_enforce = true;
> #else
> -static bool sig_enforce = false;
> +static bool sig_enforce; /* by default set to false */
>
> static int param_set_bool_enable_only(const char *val,
> const struct kernel_param *kp)
> @@ -156,15 +156,15 @@ static BLOCKING_NOTIFIER_HEAD(module_notify_list);
>
> /* Bounds of module allocation, for speeding __module_address.
> * Protected by module_mutex. */
> -static unsigned long module_addr_min = -1UL, module_addr_max = 0;
> +static unsigned long module_addr_min = -1UL, module_addr_max; /* addr_max=0
> */
I think the explicit initializers are clearer. Gcc realizes they're
zero and puts them in bss anyway, so there's no size cost.
> -int register_module_notifier(struct notifier_block * nb)
> +int register_module_notifier(struct notifier_block *nb)
> {
> return blocking_notifier_chain_register(&module_notify_list, nb);
> }
> EXPORT_SYMBOL(register_module_notifier);
>
> -int unregister_module_notifier(struct notifier_block * nb)
> +int unregister_module_notifier(struct notifier_block *nb)
> {
> return blocking_notifier_chain_unregister(&module_notify_list, nb);
> }
> @@ -740,8 +740,7 @@ static inline int try_force_unload(unsigned int flags)
> }
> #endif /* CONFIG_MODULE_FORCE_UNLOAD */
>
> -struct stopref
> -{
> +struct stopref {
> struct module *mod;
> int flags;
> int *forced;
These are fine.
> @@ -878,7 +877,7 @@ static inline void print_unload_info(struct seq_file *m,
> struct module *mod)
> seq_printf(m, " %lu ", module_refcount(mod));
>
> /* Always include a trailing , so userspace can differentiate
> - between this and the old multi-field proc format. */
> + * between this and the old multi-field proc format. */
> list_for_each_entry(use, &mod->source_list, source_list) {
> printed_something = 1;
> seq_printf(m, "%s,", use->source->name);
Actually, kernel style for multi-line comments, like it or not, is:
/*
* Always include a trailing , so userspace can differentiate
* between this and the old multi-field proc format.
*/
> @@ -1953,7 +1951,7 @@ static int simplify_symbols(struct module *mod, const
> struct load_info *info)
> /* We compiled with -fno-common. These are not
> supposed to happen. */
> pr_debug("Common symbol: %s\n", name);
> - printk("%s: please compile with -fno-common\n",
> + pr_debug("%s: please compile with -fno-common\n",
> mod->name);
> ret = -ENOEXEC;
> break;
Please change it to pr_warn rather than pr_debug!
> @@ -3022,7 +3020,7 @@ static int do_init_module(struct module *mod)
> ret = do_one_initcall(mod->init);
> if (ret < 0) {
> /* Init routine failed: abort. Try to protect us from
> - buggy refcounters. */
> + * buggy refcounters. */
> mod->state = MODULE_STATE_GOING;
> synchronize_sched();
> module_put(mod);
> @@ -3174,7 +3172,7 @@ out:
Comment style here, too.
> @@ -3816,7 +3814,7 @@ void print_modules(void)
> struct module *mod;
> char buf[8];
>
> - printk(KERN_DEFAULT "Modules linked in:");
> + pr_warn("Modules linked in:");
This is not the same as KERN_DEFAULT; is it correct?
Thanks,
Rusty.
--
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] staging: android: binder: move to the "real" part of the kernel
On Thu, Oct 16, 2014 at 04:18:02PM +0200, Michael Kerrisk (man-pages) wrote: > On Thu, Oct 16, 2014 at 2:47 PM, Greg Kroah-Hartman > wrote: > > From: Greg Kroah-Hartman > > > > The Android binder code has been "stable" for many years now. No matter > > what comes in the future, we are going to have to support this API, so > > might as well move it to the "real" part of the kernel as there's no > > real work that needs to be done to the existing code. > > Where does one find the canonical documentation of the user-space API? There really is only one "canonical" thing, and that is in the libbinder code in the Android userspace repository. And it's not really "documentation" so much as, "a C file that interacts with the ioctls in the binder kernel code" :( Think of this as just a random character driver with some funny ioctls that will never get really documented as there is only one user of it. sorry, 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/
[PULL] More virtio fun
The following changes since commit 7ec62d421bdf29cb31101ae2689f7f3a9906289a: Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs (2014-09-10 14:04:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/virtio-next-for-linus for you to fetch changes up to 1bbc26062754b012656d34103215f7552e02b999: virtio-rng: refactor probe error handling (2014-10-15 10:25:14 +1030) One cc: stable commit, the rest are a series of minor cleanups which have been sitting in MST's tree during my vacation. I changed a function name and made one trivial change, then they spent two days in linux-next. Thanks, Rusty. Michael S. Tsirkin (24): virtio_pci: fix virtio spec compliance on restore virtio: unify config_changed handling virtio-pci: move freeze/restore to virtio core virtio: defer config changed notifications virtio_blk: drop config_enable virtio-blk: drop config_mutex virtio_net: drop config_enable virtio-net: drop config_mutex virtio_net: minor cleanup virtio: add API to enable VQs early virtio_net: enable VQs early virtio_blk: enable VQs early virtio_console: enable VQs early 9p/trans_virtio: enable VQs early virtio_net: fix use after free on allocation failure virtio_scsi: move kick event out from virtscsi_init virtio_blk: enable VQs early on restore virtio_scsi: enable VQs early on restore virtio_console: enable VQs early on restore virtio_net: enable VQs early on restore virtio_scsi: fix race on device removal virtio_balloon: enable VQs early on restore virtio_scsi: drop scan callback virtio-rng: refactor probe error handling Paolo Bonzini (1): virito_scsi: use freezable WQ for events drivers/block/virtio_blk.c | 40 -- drivers/char/hw_random/virtio-rng.c | 15 +++--- drivers/char/virtio_console.c | 4 ++ drivers/misc/mic/card/mic_virtio.c | 6 +-- drivers/net/virtio_net.c| 44 +-- drivers/s390/kvm/kvm_virtio.c | 9 +--- drivers/s390/kvm/virtio_ccw.c | 6 +-- drivers/scsi/virtio_scsi.c | 42 +-- drivers/virtio/virtio.c | 103 drivers/virtio/virtio_balloon.c | 2 + drivers/virtio/virtio_mmio.c| 7 +-- drivers/virtio/virtio_pci.c | 33 ++-- include/linux/virtio.h | 14 + include/linux/virtio_config.h | 17 ++ net/9p/trans_virtio.c | 2 + 15 files changed, 207 insertions(+), 137 deletions(-) -- 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: krealloc in kernel/params.c
Rasmus Villemoes writes:
> On Wed, Oct 15 2014, Rusty Russell wrote:
>
>> Rasmus Villemoes writes:
>> The kzalloc-then-always-krealloc pattern is perhaps overly simplistic,
>> but this code has clearly confused people. It worked on me...
>>
>
> I think kzalloc immediately followed by kreallocing the returned value
> is rather ugly. Other than that:
Indeed, but it's an obvious pattern. "If not initialized, initialize".
>> -num = mk->mp->num;
>> -attrs = mk->mp->grp.attrs;
>> +/* First allocation. */
>> +mk->mp = kzalloc(sizeof(*mk->mp), GFP_KERNEL);
>> +if (!mk->mp)
>> +return -ENOMEM;
>
> free_module_param_attrs does not check mk->mp for being NULL before
> kfree'ing mk->mp->grp.attrs, so this will oops.
Nice catch, folded this in:
diff --git a/kernel/params.c b/kernel/params.c
index 3ebe6c64aa67..ee92e67f2cee 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -650,7 +650,8 @@ static __modinit int add_sysfs_param(struct module_kobject
*mk,
#ifdef CONFIG_MODULES
static void free_module_param_attrs(struct module_kobject *mk)
{
- kfree(mk->mp->grp.attrs);
+ if (mk->mp)
+ kfree(mk->mp->grp.attrs);
kfree(mk->mp);
mk->mp = NULL;
}
Thanks!
Rusty.
--
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 v11 1/5] thermal: rockchip: add driver for thermal
Hi Caesar,
On 16.10.2014 16:31, Caesar Wang wrote:
Thermal is TS-ADC Controller module supports
user-defined mode and automatic mode.
User-defined mode refers,TSADC all the control signals entirely by
software writing to register for direct control.
Automaic mode refers to the module automatically poll TSADC output,
and the results were checked.If you find that the temperature High
in a period of time,an interrupt is generated to the processor
down-measures taken;If the temperature over a period of time High,
the resulting TSHUT gave CRU module,let it reset the entire chip,
or via GPIO give PMIC.
Signed-off-by: zhaoyifeng
Signed-off-by: Caesar Wang
---
drivers/thermal/Kconfig| 9 +
drivers/thermal/Makefile | 1 +
drivers/thermal/rockchip_thermal.c | 688 +
3 files changed, 698 insertions(+)
create mode 100644 drivers/thermal/rockchip_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index ef5587f..5efcf73 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -133,6 +133,15 @@ config SPEAR_THERMAL
Enable this to plug the SPEAr thermal sensor driver into the Linux
thermal framework.
+config ROCKCHIP_THERMAL
+ tristate "Rockchip thermal driver"
+ depends on ARCH_ROCKCHIP
+ help
+ Rockchip thermal driver provides support for Temperature sensor
+ ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
+ trip point. Cpufreq is used as the cooling device and will throttle
+ CPUs when the Temperature crosses the passive trip point.
+
config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 31e232f..21da0a8 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -19,6 +19,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
# platform thermal drivers
obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
+obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
obj-$(CONFIG_RCAR_THERMAL)+= rcar_thermal.o
obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
obj-y += samsung/
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
new file mode 100644
index 000..4ecc649
--- /dev/null
+++ b/drivers/thermal/rockchip_thermal.c
@@ -0,0 +1,688 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * If the temperature over a period of time High,
+ * the resulting TSHUT gave CRU module,let it reset the entire chip,
+ * or via GPIO give PMIC.
+ */
+enum reset_mode {
+ CRU = 0,
+ GPIO,
+};
+
+/**
+ * The system has three Teperture Sensors.
+ * channel0 is reserve,channel1 is for CPU,and
+ * channel channel 2 is for GPU.
+ */
+enum sensor_id {
+ RESERVE = 0,
+ CPU,
+ GPU,
+ SENSOR_ID_END,
+};
+
+struct rockchip_thermal_data {
+ const struct rockchip_tsadc_platform_data *pdata;
+ struct thermal_zone_device *tz[SENSOR_ID_END];
+ struct thermal_cooling_device *cdev;
+ void __iomem *regs;
+
+ unsigned long temp_passive;
+ unsigned long hw_shut_temp;
+ unsigned long alarm_temp;
+ bool irq_enabled;
+ int irq;
+ int reset_mode;
+ int chn;
+
+ struct clk *clk;
+ struct clk *pclk;
+};
+
+struct rockchip_tsadc_platform_data {
+ unsigned long temp_passive;
+ unsigned long hw_shut_temp;
+ int reset_mode;
+
+ void (*irq_handle)(void __iomem *reg);
+ void (*initialize)(int reset_mode, int chn, void __iomem *reg,
+ unsigned long hw_shut_temp);
+ int (*control)(void __iomem *reg, bool on, int chn);
+ int (*code_to_temp)(u32 code);
+ u32 (*temp_to_code)(int temp);
+ void (*set_alarm_temp)(int chn, void __iomem *reg,
+ unsigned long alarm_temp);
+};
+
+/* TSADC V2 Sensor info define: */
+#define TSADCV2_AUTO_CON 0x04
+#define TSADCV2_INT_EN 0x08
+#define TSADCV2_INT_PD 0x0c
+#define TSADCV2_DATA(chn) (0x20 + (chn) * 0x04)
+#define TSADCV2_COMP_INT(chn) (0x30 + (chn) * 0x04)
+#define TSADCV2_COMP_SHUT(chn) (0x40 + (chn) * 0
Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
On Thu, Oct 16, 2014 at 10:09:04AM -0700, John Stultz wrote: > On Thu, Oct 16, 2014 at 5:47 AM, Greg Kroah-Hartman > wrote: > > From: Greg Kroah-Hartman > > > > The Android binder code has been "stable" for many years now. No matter > > Well, ignoring the ABI break that landed in the last year. :) As no one noticed, it wasn't a "break" :) > > This was discussed in the Android miniconf at the Plumbers conference. > > If anyone has any objections to this, please let me know, otherwise I'm > > queueing this up for 3.19-rc1 > > So my main concerns/thoughts here are: > > Who is going to maintain this? Has Arve agreed? Do we really need someone to do more work that has been done on it in the past as an official "maintainer"? I'll be glad to do it, as I doubt it will require any time at all. > Are the Android guys comfortable with the ABI stability rules they'll > now face? Just because something is in staging, doesn't mean you don't have to follow the same ABI stability rules as the rest of the kernel. If a change had happened to this code that broke userspace in the past, I would have reverted it. So this should not be anything different from what has been happening inthe past. And the Android developers said they were happy to see this code move into the "real" part of the kernel. > Currently in the android space no one but libbinder should use the > kernel interface. That is correct. If you do that, you deserve all of the pain and suffering and rooted machines you will get. > Can we enforce that no one use this interface out-side of android (To > ensure its one of those "if the abi breaks and no one notices..." edge > cases)? This is the kernel, we can not dictate "use", that's the good part of the GPLv2 :) Again, as no one has done this before, I strongly doubt it will happen in the future. > I'm still hopeful that a libbinder over kdbus will eventually pan out. > I still see having two core IPC mechanisms (even if the use cases are > different in style) as a negative, and I worry this might reduce > motivation to unify things at the lower level. Granted, such work can > still continue, but the incentives do change. Yes, things are going to change in the future, there is work happening here, and there was a presentation at Plumbers about what is going to be coming. But all of the changes will be in new code. Be it kdbus, or something else if that doesn't work out. This existing binder.c file will not be changing at all. This existing ABI, and codebase, is something that we have to maintain forever for those millions of devices out there in the real world today. So as there really is nothing left to do on it, it deserves to be in the main part of the kernel source tree. 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/
[git pull] Input updates for 3.18-rc0 (part 2)
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive 2nd round of updates for the input subsystem. Mostly simple
bug fixes, although we do have one brand new driver for Microchip AR1021
i2c touchscreen. Also there is change to stop trying to use i8042 active
multiplexing by default (it is still possible to activate it via
i8042.nomux=0 on boxes that implement it).
Changelog:
-
Andreas Bosch (1):
Input: alps - fix v4 button press recognition
Chang Huaixin (1):
Input: xen-kbdfront - free grant table entry in xenkbd_disconnect_backend
Christian Gmeiner (1):
Input: Add Microchip AR1021 i2c touchscreen
Dmitry Torokhov (4):
Input: evdev - fix EVIOCG{type} ioctl
Input: automatically set EV_ABS bit in input_set_abs_params
Input: synaptics - gate forcepad support by DMI check
Input: i8042 - disable active multiplexing by default
Hans de Goede (1):
Input: i8042 - add noloop quirk for Asus X750LN
Jaewon Kim (1):
Input: max77693-haptic - fix state check in imax77693_haptic_disable()
Pramod Gurav (2):
Input: opencores-kbd - switch to using managed resources
Input: adp5588-keys - cancel workqueue in failure path
Richard Leitner (2):
Input: avoid negative input device numbers
Input: serio - avoid negative serio device numbers
Sjoerd Simons (1):
Input: cros_ec_keyb - add of match table
Tommi Rantala (2):
Input: xpad - add USB ID for Thrustmaster Ferrari 458 Racing Wheel
Input: xpad - add Thrustmaster as Xbox 360 controller vendor
Diffstat:
Documentation/kernel-parameters.txt| 2 +-
drivers/input/evdev.c | 13 +-
drivers/input/input.c | 5 +-
drivers/input/joystick/xpad.c | 2 +
drivers/input/keyboard/adp5588-keys.c | 1 +
drivers/input/keyboard/cros_ec_keyb.c | 9 ++
drivers/input/keyboard/opencores-kbd.c | 72 ++---
drivers/input/misc/max77693-haptic.c | 2 +-
drivers/input/misc/xen-kbdfront.c | 4 +-
drivers/input/mouse/alps.c | 4 +-
drivers/input/mouse/synaptics.c| 22 ++-
drivers/input/mouse/synaptics.h| 8 +-
drivers/input/serio/i8042-x86ia64io.h | 287 ++---
drivers/input/serio/i8042.c| 2 +-
drivers/input/serio/serio.c| 4 +-
drivers/input/touchscreen/Kconfig | 12 ++
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/ar1021_i2c.c | 181 +
18 files changed, 280 insertions(+), 351 deletions(-)
create mode 100644 drivers/input/touchscreen/ar1021_i2c.c
--
Dmitry
--
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 v11 1/5] thermal: rockchip: add driver for thermal
Hi Caesar,
On Thu, Oct 16, 2014 at 09:31:37PM +0800, Caesar Wang wrote:
> Thermal is TS-ADC Controller module supports
> user-defined mode and automatic mode.
>
> User-defined mode refers,TSADC all the control signals entirely by
> software writing to register for direct control.
>
> Automaic mode refers to the module automatically poll TSADC output,
> and the results were checked.If you find that the temperature High
> in a period of time,an interrupt is generated to the processor
> down-measures taken;If the temperature over a period of time High,
> the resulting TSHUT gave CRU module,let it reset the entire chip,
> or via GPIO give PMIC.
>
> Signed-off-by: zhaoyifeng
> Signed-off-by: Caesar Wang
> ---
> drivers/thermal/Kconfig| 9 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/rockchip_thermal.c | 688
> +
> 3 files changed, 698 insertions(+)
> create mode 100644 drivers/thermal/rockchip_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index ef5587f..5efcf73 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -133,6 +133,15 @@ config SPEAR_THERMAL
> Enable this to plug the SPEAr thermal sensor driver into the Linux
> thermal framework.
>
> +config ROCKCHIP_THERMAL
> + tristate "Rockchip thermal driver"
> + depends on ARCH_ROCKCHIP
> + help
> + Rockchip thermal driver provides support for Temperature sensor
> + ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
> + trip point. Cpufreq is used as the cooling device and will throttle
> + CPUs when the Temperature crosses the passive trip point.
> +
> config RCAR_THERMAL
> tristate "Renesas R-Car thermal driver"
> depends on ARCH_SHMOBILE || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 31e232f..21da0a8 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -19,6 +19,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
>
> # platform thermal drivers
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> +obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
> obj-y+= samsung/
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c
> new file mode 100644
> index 000..4ecc649
> --- /dev/null
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -0,0 +1,688 @@
> +/*
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * If the temperature over a period of time High,
> + * the resulting TSHUT gave CRU module,let it reset the entire chip,
> + * or via GPIO give PMIC.
> + */
> +enum reset_mode {
> + CRU = 0,
> + GPIO,
> +};
> +
> +/**
> + * The system has three Teperture Sensors.
> + * channel0 is reserve,channel1 is for CPU,and
> + * channel channel 2 is for GPU.
> + */
> +enum sensor_id {
> + RESERVE = 0,
> + CPU,
> + GPU,
> + SENSOR_ID_END,
> +};
> +
> +struct rockchip_thermal_data {
> + const struct rockchip_tsadc_platform_data *pdata;
> + struct thermal_zone_device *tz[SENSOR_ID_END];
> + struct thermal_cooling_device *cdev;
> + void __iomem *regs;
> +
> + unsigned long temp_passive;
> + unsigned long hw_shut_temp;
> + unsigned long alarm_temp;
> + bool irq_enabled;
You set this flag but never check it.
> + int irq;
> + int reset_mode;
> + int chn;
> +
> + struct clk *clk;
> + struct clk *pclk;
> +};
> +
> +struct rockchip_tsadc_platform_data {
> + unsigned long temp_passive;
Why do we need to have passive temperature in chip data? Also I wonder
why we need temperatures to be unsigned longs instead of "normal"
unsigned ints.
> + unsigned long hw_shut_temp;
> + int reset_mode;
> +
> + void (*irq_handle)(void __iomem *reg);
> + void (*initialize)(int reset_mode, int chn, void __iomem *reg,
> +unsigned long hw_shut_temp);
> + int (*control)(void __iomem *reg, bool on, int chn);
> + int (*code_to_temp)(u32 code);
> + u32 (*temp_to_code)(int temp);
> + void (*set_alarm_temp)(int chn, void __iomem *reg,
> +unsigned lo
[GIT PULL] please pull infiniband.git
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus Main set of InfiniBand/RDMA updates for 3.18 merge window: - Large set of iSER initiator improvements - Hardware driver fixes for cxgb4, mlx5 and ocrdma - Small fixes to core midlayer Ariel Nahum (3): IB/iser: Unbind at conn_stop stage IB/iser: Use iser_warn instead of BUG_ON in iser_conn_release IB/iser: Change iscsi_conn_stop log level to info Devesh Sharma (3): RDMA/ocrdma: Add default GID at index 0 RDMA/ocrdma: Convert kernel VA to PA for mmap in user IB/core: Clear AH attr variable to prevent garbage data Eli Cohen (5): IB/mlx5: Clear umr resources after ib_unregister_device IB/mlx5: Improve debug prints in mlx5_ib_reg_user_mr IB/core: Avoid leakage from kernel to user space IB/mlx5: Fix possible array overflow IB/mlx5: Remove duplicate code from mlx5_set_path Hariprasad S (3): RDMA/cxgb4: Take IPv6 into account for best_mtu and set_emss RDMA/cxgb4: Add missing neigh_release in find_route RDMA/cxgb4: Fix ntuple calculation for ipv6 and remove duplicate line Jack Morgenstein (1): IB/core: Fix XRC race condition in ib_uverbs_open_qp Jes Sorensen (3): RDMA/ocrdma: Don't memset() buffers we just allocated with kzalloc() RDMA/ocrdma: The kernel has a perfectly good BIT() macro - use it RDMA/ocrdma: Save the bit environment, spare unncessary parenthesis Li RongQing (1): RDMA/ocrdma: Remove a unused-label warning Or Gerlitz (1): IB/iser: Bump version, add maintainer Roi Dayan (1): IB/iser: Remove unused variables and dead code Roland Dreier (1): Merge branches 'core', 'cxgb4', 'iser', 'mlx5' and 'ocrdma' into for-next Sagi Grimberg (23): IB/iser: Rename ib_conn -> iser_conn IB/iser: Re-introduce ib_conn IB/iser: Extend iser_free_ib_conn_res() IB/iser: Fix DEVICE REMOVAL handling in the absence of iscsi daemon IB/iser: Don't bound release_work completions timeouts IB/iser: Protect tasks cleanup in case IB device was already released IB/iser: Signal iSCSI layer that transport is broken in error completions IB/iser: Centralize iser completion contexts IB/iser: Use internal polling budget to avoid possible live-lock IB/iser: Use single CQ for RX and TX IB/iser: Use beacon to indicate all completions were consumed IB/iser: Optimize completion polling IB/iser: Suppress scsi command send completions IB/iser: Nit - add space after __func__ in iser logging IB/iser: Add/Fix kernel doc style descriptions in iscsi_iser.h IB/iser: Fix/add kernel-doc style description in iscsi_iser.c IB/mlx5: Use enumerations for PI copy mask IB/iser: Remove redundant assignment IB/iser: Set IP_CSUM as default guard type IB/mlx5: Use extended internal signature layout IB/iser: Centralize ib_sig_domain settings Target/iser: Centralize ib_sig_domain setting IB/mlx5, iser, isert: Add Signature API additions Selvin Xavier (1): RDMA/ocrdma: Get vlan tag from ib_qp_attrs Steve Wise (1): RDMA/cxgb4: Make c4iw_wr_log_size_order static Yishai Hadas (1): IB/mlx5: Modify to work with arbitrary page size MAINTAINERS | 1 + drivers/infiniband/core/uverbs_cmd.c | 2 + drivers/infiniband/core/uverbs_main.c| 5 + drivers/infiniband/hw/cxgb4/cm.c | 32 +- drivers/infiniband/hw/cxgb4/device.c | 2 +- drivers/infiniband/hw/mlx5/main.c| 8 +- drivers/infiniband/hw/mlx5/mem.c | 18 +- drivers/infiniband/hw/mlx5/mr.c | 6 +- drivers/infiniband/hw/mlx5/qp.c | 149 +++--- drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 25 +- drivers/infiniband/hw/ocrdma/ocrdma_main.c | 12 + drivers/infiniband/hw/ocrdma/ocrdma_sli.h| 238 +- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 10 +- drivers/infiniband/ulp/iser/iscsi_iser.c | 313 ++--- drivers/infiniband/ulp/iser/iscsi_iser.h | 408 +++- drivers/infiniband/ulp/iser/iser_initiator.c | 198 drivers/infiniband/ulp/iser/iser_memory.c| 99 ++-- drivers/infiniband/ulp/iser/iser_verbs.c | 667 +++ drivers/infiniband/ulp/isert/ib_isert.c | 65 ++- include/linux/mlx5/qp.h | 35 +- include/rdma/ib_verbs.h | 32 +- 21 files changed, 1372 insertions(+), 953 deletions(-) -- 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] clk: rockchip: add npll to source of sclk_gpu
This patch make a common source for uart0 pll src and sclk_gpu,
so that gpu can get its cloc from npll.
Signed-off-by: Kever Yang
---
drivers/clk/rockchip/clk-rk3288.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 504b6c2a..3f839cf 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -174,14 +174,14 @@ PNAME(mux_aclk_cpu_src_p) = { "cpll_aclk_cpu",
"gpll_aclk_cpu" };
PNAME(mux_pll_src_cpll_gpll_p) = { "cpll", "gpll" };
PNAME(mux_pll_src_npll_cpll_gpll_p)= { "npll", "cpll", "gpll" };
PNAME(mux_pll_src_cpll_gpll_npll_p)= { "cpll", "gpll", "npll" };
-PNAME(mux_pll_src_cpll_gpll_usb480m_p) = { "cpll", "gpll", "usb480m" };
+PNAME(mux_pll_src_cpll_gpll_usb480m_p) = { "cpll", "gpll", "usbphy480m_src" };
+PNAME(mux_pll_src_cpll_gll_usb_npll_p) = { "cpll", "gpll", "usbphy480m_src",
"npll" };
PNAME(mux_mmc_src_p) = { "cpll", "gpll", "xin24m", "xin24m" };
PNAME(mux_i2s_pre_p) = { "i2s_src", "i2s_frac", "ext_i2s", "xin12m" };
PNAME(mux_i2s_clkout_p)= { "i2s_pre", "xin12m" };
PNAME(mux_spdif_p) = { "spdif_pre", "spdif_frac", "xin12m" };
PNAME(mux_spdif_8ch_p) = { "spdif_8ch_pre", "spdif_8ch_frac", "xin12m" };
-PNAME(mux_uart0_pll_p) = { "cpll", "gpll", "usbphy_480m_src", "npll" };
PNAME(mux_uart0_p) = { "uart0_src", "uart0_frac", "xin24m" };
PNAME(mux_uart1_p) = { "uart1_src", "uart1_frac", "xin24m" };
PNAME(mux_uart2_p) = { "uart2_src", "uart2_frac", "xin24m" };
@@ -427,7 +427,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
RK3288_CLKSEL_CON(33), 0, 5, DFLAGS,
RK3288_CLKGATE_CON(5), 8, GFLAGS),
- COMPOSITE(SCLK_GPU, "sclk_gpu", mux_pll_src_cpll_gpll_usb480m_p, 0,
+ COMPOSITE(SCLK_GPU, "sclk_gpu", mux_pll_src_cpll_gll_usb_npll_p, 0,
RK3288_CLKSEL_CON(34), 6, 2, MFLAGS, 0, 5, DFLAGS,
RK3288_CLKGATE_CON(5), 7, GFLAGS),
@@ -504,7 +504,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
RK3288_CLKSEL_CON(38), 15, 1, MFLAGS, 8, 5, DFLAGS,
RK3288_CLKGATE_CON(5), 6, GFLAGS),
- COMPOSITE(0, "uart0_src", mux_uart0_pll_p, 0,
+ COMPOSITE(0, "uart0_src", mux_pll_src_cpll_gll_usb_npll_p, 0,
RK3288_CLKSEL_CON(13), 13, 2, MFLAGS, 0, 7, DFLAGS,
RK3288_CLKGATE_CON(1), 8, GFLAGS),
COMPOSITE_FRAC(0, "uart0_frac", "uart0_src", 0,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: + freezer-check-oom-kill-while-being-frozen.patch added to -mm tree
On 10/16, Cong Wang wrote: > > On Thu, Oct 16, 2014 at 2:35 PM, Oleg Nesterov wrote: > > > > If a task B is already frozen, it sleeps in D state. > > > > If OOM selects B as a victim after that, it won't be woken by > > SIGKILL, thus it obviously can't call should_thaw_current() and > > notice TIF_MEMDIE. > > I see your point now, it would be more clear if you can just quote > the patch instead of changelog. > > So are you saying the loop in __refrigerator() is useless? No. > Since > it will always stay in asleep after schedule()? Not always. But it will stay asleep in this particular case. > > Btw, I also do not understand the cgroup_freezing() check in > > should_thaw_current(), but this is another story. > > I hate to repeat the previous discussion. Maybe you can just follow > the link I gave to you? :) May be, but this thread is huge. Will try tomorrow to read it tomorrow, but you know, I hope that someone else from cc list can copy-and-paste the relevant part of this discussion, or give me the link to some specific email. To me the comment should be more clear in any case, but perhaps it is just me who can't understand it immediately. Oleg. -- 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/
splice read/write pipe lock ordering issues (was Re: XFS lockdep with Linux v3.17-5503-g35a9ad8af0bb)
[ Adding Al and linux-fsdevel to the cc list ]
On Thu, Oct 16, 2014 at 07:52:43AM -0400, Josh Boyer wrote:
> Hi All,
>
> Colin reported a lockdep spew with XFS using Linus' tree last week.
> The lockdep report is below. He noted that his application was using
> splice.
That smells like a splice architecture bug. splice write puts the
pipe lock outside the inode locks, but splice read puts the pipes
locks *inside* the inode locks.
The recent commit 8d02076 "(->splice_write() via ->write_iter()")
which went into 3.16 will be what is causing this. It replaced a
long standing splice lock inversion problem (XFS iolock vs i_mutex
http://oss.sgi.com/archives/xfs/2011-08/msg00122.html) by moving
to a ->write_iter call under the pipe_lock.
Only XFS reports this issue because XFS is the only filesystem that
serialises splice reads against truncate, concurrent writes into the
same region, extent manipulation functions via fallocate() (e.g.
hole punch), etc. and it does so via the inode iolock that it takes
in shared (read) mode during xfs_file_splice_read().
> josh
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1152813
>
> [14689.265161] ==
> [14689.265175] [ INFO: possible circular locking dependency detected ]
> [14689.265186] 3.18.0-0.rc0.git2.1.fc22.x86_64 #1 Not tainted
> [14689.265190] ---
> [14689.265199] atomic/1144 is trying to acquire lock:
> [14689.265203] (&sb->s_type->i_mutex_key#13){+.+.+.}, at:
> [] xfs_file_buffered_aio_write.isra.10+0x7a/0x310
> [xfs]
> [14689.265245]
> but task is already holding lock:
> [14689.265249] (&pipe->mutex/1){+.+.+.}, at: []
> pipe_lock+0x1e/0x20
> [14689.265262]
> which lock already depends on the new lock.
>
> [14689.265268]
> the existing dependency chain (in reverse order) is:
> [14689.265287]
> -> #2 (&pipe->mutex/1){+.+.+.}:
> [14689.265296][] lock_acquire+0xa4/0x1d0
> [14689.265303][] mutex_lock_nested+0x85/0x440
> [14689.265310][] pipe_lock+0x1e/0x20
> [14689.265315][] splice_to_pipe+0x2a/0x260
> [14689.265321][]
> __generic_file_splice_read+0x57f/0x620
> [14689.265328][] generic_file_splice_read+0x3b/0x90
> [14689.265334][] xfs_file_splice_read+0xb0/0x1e0
> [xfs]
> [14689.265350][] do_splice_to+0x6c/0x90
> [14689.265356][] SyS_splice+0x6dd/0x800
> [14689.265362][] system_call_fastpath+0x16/0x1b
splice read -> iolock(shared) -> pipe lock.
> [14689.265368]
> -> #1 (&(&ip->i_iolock)->mr_lock){++}:
> [14689.265424][] lock_acquire+0xa4/0x1d0
> [14689.265494][] down_write_nested+0x5e/0xc0
> [14689.265553][] xfs_ilock+0xb9/0x1c0 [xfs]
> [14689.265629][]
> xfs_file_buffered_aio_write.isra.10+0x87/0x310 [xfs]
> [14689.265693][] xfs_file_write_iter+0x8a/0x130
> [xfs]
> [14689.265749][] new_sync_write+0x8e/0xd0
> [14689.265811][] vfs_write+0xba/0x200
> [14689.265862][] SyS_write+0x5c/0xd0
> [14689.265912][] system_call_fastpath+0x16/0x1b
write(2) -> i_mutex -> iolock(exclusive)
> [14689.265963]
> -> #0 (&sb->s_type->i_mutex_key#13){+.+.+.}:
> [14689.266024][] __lock_acquire+0x1b0e/0x1c10
> [14689.266024][] lock_acquire+0xa4/0x1d0
> [14689.266024][] mutex_lock_nested+0x85/0x440
> [14689.266024][]
> xfs_file_buffered_aio_write.isra.10+0x7a/0x310 [xfs]
> [14689.266024][] xfs_file_write_iter+0x8a/0x130
> [xfs]
> [14689.266024][] iter_file_splice_write+0x2ec/0x4b0
> [14689.266024][] SyS_splice+0x381/0x800
> [14689.266024][] system_call_fastpath+0x16/0x1b
splice write -> pipe lock -> i_mutex [ -> iolock(exclusive) ]
This reminds me of the mmap_sem and all the problems we have because
we can't serialise page faults against IO path and data manipulation
functions (e.g. hole punch). We shouldn't be repeating that disaster
is we can avoid it
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.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 RFC] sched: Revert delayed_put_task_struct() and fix use after free
On 10/16, Peter Zijlstra wrote: > > On Wed, Oct 15, 2014 at 05:06:41PM +0200, Oleg Nesterov wrote: > > > > At least the code like > > > > rcu_read_lock(); > > get_task_struct(foreign_rq->curr); > > rcu_read_unlock(); > > > > is certainly wrong. And _probably_ the problem should be fixed here. Perhaps > > we can add try_to_get_task_struct() which does atomic_inc_not_zero() ... > > There is an rcu_read_lock() around it through task_numa_compare(). Yes, and the code above has rcu_read_lock() too. But it doesn't help as Kirill pointed out. Sorry, didn't have time today to read other emails in this thread, will do tomorrow and (probably) send the patch which adds PF_EXITING check. Oleg. -- 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 v11 1/5] thermal: rockchip: add driver for thermal
Hi Caesar,
On Thu, Oct 16, 2014 at 09:31:37PM +0800, Caesar Wang wrote:
> +
> +struct rockchip_tsadc_platform_data {
> + unsigned long temp_passive;
> + unsigned long hw_shut_temp;
> + int reset_mode;
> +
> + void (*irq_handle)(void __iomem *reg);
> + void (*initialize)(int reset_mode, int chn, void __iomem *reg,
> +unsigned long hw_shut_temp);
> + int (*control)(void __iomem *reg, bool on, int chn);
> + int (*code_to_temp)(u32 code);
> + u32 (*temp_to_code)(int temp);
> + void (*set_alarm_temp)(int chn, void __iomem *reg,
> +unsigned long alarm_temp);
> +};
Any time I see platform data and pdata I think about board-specific
parameters that come either from board initialization code, device tree
or ACPI, rather than chipset specific data. Do you think we could rename
rockchip_tsadc_platform_data to rockchip_tsadc_chip? If you agree
please fold the patch below into your next revision.
More to come...
Thanks.
--
Dmitry
rockchip-thermal - rename rockchip_tsadc_platform_data
Signed-off-by: Dmitry Torokhov
---
drivers/thermal/rockchip_thermal.c | 66 --
1 file changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index 4ecc649..6d7472b 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -44,8 +44,24 @@ enum sensor_id {
SENSOR_ID_END,
};
+struct rockchip_tsadc_chip {
+ unsigned long temp_passive;
+ unsigned long hw_shut_temp;
+ enum reset_mode reset_mode;
+
+ void (*irq_handle)(void __iomem *reg);
+ void (*initialize)(enum reset_mode reset_mode, int chn,
+ void __iomem *reg,
+ unsigned long hw_shut_temp);
+ int (*control)(void __iomem *reg, bool on, int chn);
+ int (*code_to_temp)(u32 code);
+ u32 (*temp_to_code)(int temp);
+ void (*set_alarm_temp)(int chn, void __iomem *reg,
+ unsigned long alarm_temp);
+};
+
struct rockchip_thermal_data {
- const struct rockchip_tsadc_platform_data *pdata;
+ const struct rockchip_tsadc_chip *chip;
struct thermal_zone_device *tz[SENSOR_ID_END];
struct thermal_cooling_device *cdev;
void __iomem *regs;
@@ -62,21 +78,6 @@ struct rockchip_thermal_data {
struct clk *pclk;
};
-struct rockchip_tsadc_platform_data {
- unsigned long temp_passive;
- unsigned long hw_shut_temp;
- int reset_mode;
-
- void (*irq_handle)(void __iomem *reg);
- void (*initialize)(int reset_mode, int chn, void __iomem *reg,
- unsigned long hw_shut_temp);
- int (*control)(void __iomem *reg, bool on, int chn);
- int (*code_to_temp)(u32 code);
- u32 (*temp_to_code)(int temp);
- void (*set_alarm_temp)(int chn, void __iomem *reg,
- unsigned long alarm_temp);
-};
-
/* TSADC V2 Sensor info define: */
#define TSADCV2_AUTO_CON 0x04
#define TSADCV2_INT_EN 0x08
@@ -234,7 +235,8 @@ static bool rk_tsadcv2_get_tshut_polarity_high(void __iomem
*regs)
* the channel, and you can set TSHUT output to gpio to reset the whole chip,
* and you can set TSHUT output to cru to reset the whole chip.
*/
-static void rk_tsadcv2_initialize(int reset_mode, int chn, void __iomem *regs,
+static void rk_tsadcv2_initialize(enum reset_mode reset_mode, int chn,
+ void __iomem *regs,
unsigned long hw_shut_temp)
{
u32 shutdown_value;
@@ -279,7 +281,7 @@ static void rk_tsadcv2_alarm_temp(int chn, void __iomem
*regs,
TSADCV2_COMP_INT(chn));
}
-static const struct rockchip_tsadc_platform_data rk3288_tsadc_data = {
+static const struct rockchip_tsadc_chip rk3288_tsadc_data = {
.reset_mode = GPIO, /* default TSHUT via GPIO give PMIC */
.temp_passive = 8,
.hw_shut_temp = 12,
@@ -303,7 +305,7 @@ MODULE_DEVICE_TABLE(of, of_rockchip_thermal_match);
static void rockchip_set_alarm_temp(struct rockchip_thermal_data *data,
int alarm_temp, int chn)
{
- const struct rockchip_tsadc_platform_data *tsadc = data->pdata;
+ const struct rockchip_tsadc_chip *tsadc = data->chip;
data->alarm_temp = alarm_temp;
@@ -352,7 +354,7 @@ static void rockchip_thermal_initialize(struct
rockchip_thermal_data *data)
static void rockchip_thermal_control(struct rockchip_thermal_data *data,
bool on, int chn)
{
- const struct rockchip_tsadc_platform_data *tsadc = data->pdata;
+ const struct rockchip_tsadc_chip *tsadc = data->chip;
if (tsadc->control)
tsadc->control(data->regs, on, chn);
@@ -372,7 +374,7 @@ static void rockch
Re: kernel BUG at fs/ext4/inode.c:2982!
Dave Jones writes:
> On Thu, Oct 16, 2014 at 10:33:46AM -0400, Dave Jones wrote:
>
> > > Try this patch http://www.spinics.net/lists/linux-ext4/msg45683.html
> >
> > I'll give it a try if I can get it reproducing easily, otherwise I cna't
> say
> > either way whether the patch is doing any good.
>
> ok, I managed to reproduce it a few times, and then tried again with
> your patch. I'm not sure if it's related, but I'm now seeing lockups
> in ext4. The process that gets stuck looks like this..
99.99% this one is not related. This is just one more uncovered one
by trinity magics. Looks like I've got what is wrong
lseek SEEK_HOLE/SEEK_DATA try to find block allocated one by one
instead of using ext4_ext_next_allocated_block() COMMIT c8c0df24
Plese look an my test below. I'm too tired for today (especially
after Gone girl the movie). I'll send patch tomorrow.
>
> trinity-c21 R running task13232 9781831 0x1004
> 0001
> 8800c8d333d8 0002 cacaa650
> 880217cf7db8 a929ff8c
> Call Trace:
> [] ? ext4_map_blocks+0x31c/0x560
> [] ? ext4_map_blocks+0x205/0x560
> [] ? ext4_es_find_delayed_extent_range+0x48c/0x4e0
> [] ? ext4_llseek+0x261/0x3f0
> [] ? __fdget_pos+0x49/0x50
> [] ? rcu_read_lock_held+0x6e/0x80
> [] ? SyS_lseek+0x94/0xc0
>
> I've got to run right now, but I'll look into tracing it some more when I get
> back.
>
> Dave
pgptZfI9dDxh9.pgp
Description: PGP signature
/*
* regression test for bug in ext4_seek_data
* (C) Dmitry Monakhov
* original report https://lkml.org/lkml/2014/10/16/620
*/
#define _GNU_SOURCE
#define _LARGEFILE_SOURCE
#define _FILE_OFFSET_BITS 64
#include
#include
#include
#ifndef SEEK_DATA
#define SEEK_DATA 3
#endif
int main(int argc, char **argv)
{
int fd;
loff_t size = 1ULL << 40;
fd = open("test", O_RDWR|O_CREAT, 0777);
ftruncate(fd, size);
size = 1ULL << 39;
/* Next line will likely spin forever :) */
llseek(fd, size, SEEK_DATA);
return 0;
}
Re: [PATCH] kernel/kmod: fix use-after-free of the sub_infostructure
On 10/17, Tetsuo Handa wrote: > > Ah, I see. Here is a draft of an updated patch. Do you mean this part > sub_info->retval = retval; > + /* wait_for_helper() will call umh_complete() if UMH_WAIT_PROC. */ > + if (wait != UMH_WAIT_PROC) > + umh_complete(sub_info); > + if (!retval) > + return 0; > do_exit(0); > } ? Personally I agree, this looks a bit better to me. But this is cosmetic and subjective, I leave this to Martin ;) I also agree that the changelog could mention exec_mmap. Plus a comment about UMH_NO_WAIT && sub_info->complete == NULL. So yes, perhaps v2 makes sense if Martin agrees. > By the way, it seems to me that nothing prevents > > if (info->cleanup) > (*info->cleanup)(info); > > from crashing when info->cleanup points to a function in a loadable kernel > module and the loadable kernel module got unloaded before the worker thread > calls call_usermodehelper_freeinfo(). Just don't do this? I mean, in this case the caller of call_usermodehelper() is obviously buggy? Or I missed your point? Oleg. -- 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 -next 10/10] serial: core: Fix port count when uart_open() errors
A port count mismatch occurs if mutex_lock_interruptible()
exits uart_open() and the port has already been opened. This may
prematurely close a port on an open tty. Since uart_close() is _always_
called if uart_open() fails, the port count must be corrected if errors
occur.
Always increment the port count in uart_open(), regardless of errors;
always decrement the port count in uart_close(). Note that
tty_port_close_start() decrements the port count when uart_open()
was successful.
Signed-off-by: Peter Hurley
---
drivers/tty/serial/serial_core.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 6a3571e..3f02c2b 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1337,8 +1337,16 @@ static void uart_close(struct tty_struct *tty, struct
file *filp)
struct uart_port *uport;
unsigned long flags;
- if (!state)
+ if (!state) {
+ struct uart_driver *drv = tty->driver->driver_state;
+
+ state = drv->state + tty->index;
+ port = &state->port;
+ spin_lock_irq(&port->lock);
+ --port->count;
+ spin_unlock_irq(&port->lock);
return;
+ }
uport = state->uart_port;
port = &state->port;
@@ -1555,6 +1563,10 @@ static int uart_open(struct tty_struct *tty, struct file
*filp)
pr_debug("uart_open(%d) called\n", line);
+ spin_lock_irq(&port->lock);
+ ++port->count;
+ spin_unlock_irq(&port->lock);
+
/*
* We take the semaphore here to guarantee that we won't be re-entered
* while allocating the state structure, or while we request any IRQs
@@ -1567,17 +1579,11 @@ static int uart_open(struct tty_struct *tty, struct
file *filp)
goto end;
}
- port->count++;
if (!state->uart_port || state->uart_port->flags & UPF_DEAD) {
retval = -ENXIO;
- goto err_dec_count;
+ goto err_unlock;
}
- /*
-* Once we set tty->driver_data here, we are guaranteed that
-* uart_close() will decrement the driver module use count.
-* Any failures from here onwards should not touch the count.
-*/
tty->driver_data = state;
state->uart_port->state = state;
state->port.low_latency =
@@ -1598,8 +1604,7 @@ static int uart_open(struct tty_struct *tty, struct file
*filp)
end:
return retval;
-err_dec_count:
- port->count--;
+err_unlock:
mutex_unlock(&port->mutex);
goto end;
}
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] x86: Make Atom PMC driver configurable.
On Thu, Oct 16, 2014 at 07:24:48AM +0200, Ingo Molnar wrote: > > * Dave Jones wrote: > > > The Atom PMC driver is always built-in, regardless of whether > > the kernel being built is going to be run on an Atom (or even Intel) CPU. > > > > Signed-off-by: Dave Jones > > Cc: One Thousand Gnomes > > Cc: aubrey...@linux.intel.com > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index f2327e88e07c..b4dfd96aeea8 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP > > depends on STA2X11 > > > > config PMC_ATOM > > - def_bool y > > + tristate "Intel Atom SOC power management controller driver" > > + default y > > depends on PCI > > > > So what I think should happen is to decouple of the 'must work' > features from the optional debug features in this 'driver': the > Atom SoC power-off quirk should be made unconditional, as long as > the .config is Atom-supported (CPU_SUP_INTEL I guess). > > All the other bits, such as the debugfs interface, should be in a > separately and appropriately named config option, > CONFIG_X86_INTEL_ATOM_PMC_DEBUG=y or so, with 'default n'. > > The file should probably be split up, the quirk moved into one of > the generic quirk files, while pmc_atom.c should have the debugfs > interface. > The quirk isn't really a quirk, though. Maybe a separate poweroff driver would make sense, similar to the other poweroff drivers in drivers/power/reset/. It might also make sense to rework it as mfd client driver and tie it to the lpc_ich driver, to be loaded when the lpc_ich driver is loaded. I don't personally see a problem with making it tristate, as long as a remove function is defined (which is not the case today). This way it would not have to be loaded for non-Atom systems. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 4/5] ARM: dts: add main Thermal info to rk3288
Hi Caesar,
On Thu, Oct 16, 2014 at 09:31:40PM +0800, Caesar Wang wrote:
> This patch is depend on rk3288-thermal.dtsi,or
> it will compile error.
>
> If the temperature over a period of time High,over 120C
> the resulting TSHUT gave CRU module,let it reset
> the entire chip,or via GPIO give PMIC.
>
> Signed-off-by: Caesar Wang
> ---
> arch/arm/boot/dts/rk3288.dtsi | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index cb18bb4..bf34111 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include "skeleton.dtsi"
>
> / {
> @@ -346,6 +347,19 @@
> status = "disabled";
> };
>
> + tsadc: tsadc@ff28 {
> + compatible = "rockchip,rk3288-tsadc";
> + reg = <0xff28 0x100>;
> + interrupts = ;
> + clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
> + clock-names = "tsadc", "apb_pclk";
> + pinctrl-names = "default";
> + pinctrl-0 = <&otp_out>;
> + #thermal-sensor-cells = <1>;
> + hw-shut-temp = <12>;
> + status = "disabled"
It looks like you are missing semicolon here.
> + };
> +
> usb_host0_ehci: usb@ff50 {
> compatible = "generic-ehci";
> reg = <0xff50 0x100>;
> @@ -965,6 +979,12 @@
> };
> };
>
> + tsadc {
> + otp_out: otp-out {
> + rockchip,pins = <0 10 RK_FUNC_1
> &pcfg_pull_none>;
> + };
> + };
> +
> pwm0 {
> pwm0_pin: pwm0-pin {
> rockchip,pins = <7 0 RK_FUNC_1 &pcfg_pull_none>;
> --
> 1.9.1
>
>
--
Dmitry
--
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: + freezer-check-oom-kill-while-being-frozen.patch added to -mm tree
On Thu, Oct 16, 2014 at 2:35 PM, Oleg Nesterov wrote: > > If a task B is already frozen, it sleeps in D state. > > If OOM selects B as a victim after that, it won't be woken by > SIGKILL, thus it obviously can't call should_thaw_current() and > notice TIF_MEMDIE. I see your point now, it would be more clear if you can just quote the patch instead of changelog. So are you saying the loop in __refrigerator() is useless? Since it will always stay in asleep after schedule()? > > Btw, I also do not understand the cgroup_freezing() check in > should_thaw_current(), but this is another story. > I hate to repeat the previous discussion. Maybe you can just follow the link I gave to you? :) 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: arm: JUMP_LABEL and DEBUG_SET_MODULE_RONX should be mutually exclusive?
On Wed, Oct 15, 2014 at 5:36 PM, Russell King - ARM Linux wrote: > On Wed, Oct 15, 2014 at 05:21:29PM -0500, Kees Cook wrote: >> On Wed, Oct 15, 2014 at 5:09 PM, Russell King - ARM Linux >> wrote: >> > On Wed, Oct 15, 2014 at 08:34:17AM -0700, Kees Cook wrote: >> >> On Wed, Oct 15, 2014 at 5:21 AM, Paolo Pisati wrote: >> >> > Hi, >> >> > >> >> > i keep hitting this with BRIDGE=m, JUMP_LABEL=y and >> >> > DEBUG_SET_MODULE_RONX=y: >> >> >> >> I think my RO/NX patch series solves this. I sent a pull request, but >> >> I haven't seen any movement on it. :( >> > >> > Sorry Kees. >> > >> > However, even if I had looked at it, I would /not/ have been able to >> > pull it. It does the absolutely fatal thing for any pull request: >> > >> > The following changes since commit >> > cc31d8f887953e9824c4d9333b15c335ee7d1b65: >> > >> > Merge branches 'fiq' (early part), 'fixes' and 'misc' into for-next >> > (2014-09-2+6 14:40:19 +0100) >> > >> > That commit is on my "for-next" branch. The clue is in the name. :) >> > Just like trying to base commits onto the linux-next tree, trying to >> > base commits on an aggregate branch intended for linux-next usage >> > doesn't work for all the same reasons. >> >> Ah! My mistake; I was trying to figure out which branch would be best >> for you to pull from. What do you prefer I use as the base for the >> pull request? > > I much prefer branches against one of Linus' release points than some > point in someone elses tree - unless, of course, there are dependencies > that need to be solved (which means there should be something in the > pull request explaining that.) > > If it conflicts with something I have in my tree, then that's generally > not a problem unless the conflict is horrid, at which point it can be > discussed. Okay, thanks. I've resent the pull request based off of the v3.17 tag. Thanks! -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: [PATCHv1 7/8] cgroup: cgroup namespace setns support
Quoting Aditya Kali (adityak...@google.com): > On Thu, Oct 16, 2014 at 2:12 PM, Serge E. Hallyn wrote: > > Quoting Aditya Kali (adityak...@google.com): > >> setns on a cgroup namespace is allowed only if > >> * task has CAP_SYS_ADMIN in its current user-namespace and > >> over the user-namespace associated with target cgroupns. > >> * task's current cgroup is descendent of the target cgroupns-root > >> cgroup. > > > > What is the point of this? > > > > If I'm a user logged into > > /lxc/c1/user.slice/user-1000.slice/session-c12.scope and I start > > a container which is in > > /lxc/c1/user.slice/user-1000.slice/session-c12.scope/x1 > > then I will want to be able to enter the container's cgroup. > > The container's cgroup root is under my own (satisfying the > > below condition0 but my cgroup is not a descendent of the > > container's cgroup. > > > This condition is there because we don't want to do implicit cgroup > changes when a process attaches to another cgroupns. cgroupns tries to > preserve the invariant that at any point, your current cgroup is > always under the cgroupns-root of your cgroup namespace. But in your > example, if we allow a process in "session-c12.scope" container to > attach to cgroupns root'ed at "session-c12.scope/x1" container > (without implicitly moving its cgroup), then this invariant won't > hold. Oh, I see. Guess that should be workable. Thanks. -serge -- 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/
[PULL v2] ARM ro-nx tree (next)
Hi, Please pull this series for ro-nx support on ARM for next. Thanks! -Kees The following changes since commit bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9: Linux 3.17 (2014-10-05 12:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/ronx-next for you to fetch changes up to 80d6b0c2eed2a504f6740cd1f5ea76dc50abfc4d: ARM: mm: allow text and rodata sections to be read-only (2014-10-16 14:38:54 -0700) generic fixmaps ARM support for CONFIG_DEBUG_RODATA Doug Anderson (1): arm: kgdb: Handle read-only text / modules Kees Cook (3): arm: fixmap: implement __set_fixmap() ARM: mm: allow non-text sections to be non-executable ARM: mm: allow text and rodata sections to be read-only Mark Salter (1): arm: use generic fixmap.h Nikolay Borisov (1): ARM: kexec: Make .text R/W in machine_kexec Rabin Vincent (1): arm: use fixmap for text patching when text is RO Rob Herring (1): ARM: expand fixmap region to 3MB Documentation/arm/memory.txt | 2 +- arch/arm/include/asm/cacheflush.h | 10 +++ arch/arm/include/asm/fixmap.h | 31 arch/arm/kernel/Makefile | 2 +- arch/arm/kernel/ftrace.c | 19 + arch/arm/kernel/jump_label.c | 2 +- arch/arm/kernel/kgdb.c| 29 arch/arm/kernel/machine_kexec.c | 9 ++- arch/arm/kernel/patch.c | 92 ++- arch/arm/kernel/patch.h | 12 ++- arch/arm/kernel/vmlinux.lds.S | 19 + arch/arm/mm/Kconfig | 21 ++ arch/arm/mm/highmem.c | 15 ++-- arch/arm/mm/init.c| 149 +- arch/arm/mm/mmu.c | 39 +- 15 files changed, 394 insertions(+), 57 deletions(-) -- 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: + freezer-check-oom-kill-while-being-frozen.patch added to -mm tree
On 10/16, Cong Wang wrote: > > On Thu, Oct 16, 2014 at 2:11 PM, Oleg Nesterov wrote: > > > > But also I can't understand why this patch helps. The changelog says: > > > > do_send_sig_info will wake up the thread > > > > why? > > > > This is a question for Michal who rewrites my changelog: > > http://marc.info/?l=linux-kernel&m=140986986423092&w=2 > > :) OK, I hope Michal can answer my question if you do not want to do this ;) So far I think this patch is not right. If a task B is already frozen, it sleeps in D state. If OOM selects B as a victim after that, it won't be woken by SIGKILL, thus it obviously can't call should_thaw_current() and notice TIF_MEMDIE. Btw, I also do not understand the cgroup_freezing() check in should_thaw_current(), but this is another story. Oleg. -- 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/kmod: fix use-after-free of the sub_infostructure
Oleg Nesterov wrote:
> On 10/17, Tetsuo Handa wrote:
> >
> > For both UMH_NO_WAIT and UMH_WAIT_EXEC cases,
> >
> > kernel_thread(call_helper, sub_info, CLONE_VFORK | SIGCHLD)
> >
> > in __call_usermodehelper() waits for do_execve() to succeed or do_exit(),
>
> Well, not really. kernel_thread(CLONE_VFORK) waits for do_exit() or
> exec_mmap(), and exec can fail after that.
Ah, I see. Here is a draft of an updated patch.
Can we rewrite
Martin Schwidefsky wrote:
> for UMH_WAIT_EXEC the call to umh_complete() allows
> call_usermodehelper_exec() to continue which then frees sub_info.
lines?
By the way, it seems to me that nothing prevents
if (info->cleanup)
(*info->cleanup)(info);
>from crashing when info->cleanup points to a function in a loadable kernel
module and the loadable kernel module got unloaded before the worker thread
calls call_usermodehelper_freeinfo().
--
[PATCH] kernel/kmod: fix use-after-free of the sub_info structure
A use-after-free bug was found on the subprocess_info structure allocated
by the user mode helper.
The message log on a s390 system:
-
BUG kmalloc-192 (Not tainted): Poison overwritten
Disabling lock debugging due to kernel taint
INFO: 0x684761f4-0x684761f7. First byte 0xff instead of 0x6b
INFO: Allocated in call_usermodehelper_setup+0x70/0x128 age=71 cpu=2 pid=648
__slab_alloc.isra.47.constprop.56+0x5f6/0x658
kmem_cache_alloc_trace+0x106/0x408
call_usermodehelper_setup+0x70/0x128
call_usermodehelper+0x62/0x90
cgroup_release_agent+0x178/0x1c0
process_one_work+0x36e/0x680
worker_thread+0x2f0/0x4f8
kthread+0x10a/0x120
kernel_thread_starter+0x6/0xc
kernel_thread_starter+0x0/0xc
INFO: Freed in call_usermodehelper_exec+0x110/0x1b8 age=71 cpu=2 pid=648
__slab_free+0x94/0x560
kfree+0x364/0x3e0
call_usermodehelper_exec+0x110/0x1b8
cgroup_release_agent+0x178/0x1c0
process_one_work+0x36e/0x680
worker_thread+0x2f0/0x4f8
kthread+0x10a/0x120
kernel_thread_starter+0x6/0xc
kernel_thread_starter+0x0/0xc
-
Regarding UMH_NO_WAIT, the sub_info structure can be freed by
__call_usermodehelper() before the worker thread returns from
do_execve(), allowing memory corruption when do_execve() failed
after exec_mmap() is called.
Regarding UMH_WAIT_EXEC, the call to umh_complete() allows
call_usermodehelper_exec() to continue which then frees sub_info.
To fix this race, we need to make sure that the call to
call_usermodehelper_freeinfo() in call_usermodehelper_exec() is
always made after the last store to sub_info->retval.
Signed-off-by: Martin Schwidefsky
---
kernel/kmod.c | 66 +
1 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 8637e04..378b47f 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -196,12 +196,33 @@ int __request_module(bool wait, const char *fmt, ...)
EXPORT_SYMBOL(__request_module);
#endif /* CONFIG_MODULES */
+static void call_usermodehelper_freeinfo(struct subprocess_info *info)
+{
+ if (info->cleanup)
+ (*info->cleanup)(info);
+ kfree(info);
+}
+
+static void umh_complete(struct subprocess_info *sub_info)
+{
+ struct completion *comp = xchg(&sub_info->complete, NULL);
+ /*
+* See call_usermodehelper_exec(). If xchg() returns NULL
+* we own sub_info, the caller has gone away.
+*/
+ if (comp)
+ complete(comp);
+ else
+ call_usermodehelper_freeinfo(sub_info);
+}
+
/*
* This is the task which runs the usermode application
*/
static int call_usermodehelper(void *data)
{
struct subprocess_info *sub_info = data;
+ int wait = sub_info->wait & ~UMH_KILLABLE;
struct cred *new;
int retval;
@@ -242,12 +263,13 @@ static int call_usermodehelper(void *data)
retval = do_execve(getname_kernel(sub_info->path),
(const char __user *const __user *)sub_info->argv,
(const char __user *const __user *)sub_info->envp);
- if (!retval)
- return 0;
-
- /* Exec failed? */
fail:
sub_info->retval = retval;
+ /* wait_for_helper() will call umh_complete() if UMH_WAIT_PROC. */
+ if (wait != UMH_WAIT_PROC)
+ umh_complete(sub_info);
+ if (!retval)
+ return 0;
do_exit(0);
}
@@ -258,26 +280,6 @@ static int call_helper(void *data)
return call_usermodehelper(data);
}
-static void call_usermodehelper_freeinfo(struct subprocess_info *info)
-{
- if (info->cleanup)
- (*info->cleanup)(info);
- kfree(info);
-}
-
-static void umh_complete(struct subprocess_info *sub_info)
-{
- struct completion *comp = xchg(&sub_info->complete, NULL);
- /*
-* See call_usermodehelper_exec(). If xchg() returns NULL
-* we own sub_info, the UMH_KILLABLE caller has gone away.
-*/
-
Re: [PATCH v2] lib: string.c: Added a funktion function strzcpy
2014-10-16 23:17 GMT+02:00 Andrew Morton : > On Thu, 16 Oct 2014 23:09:00 +0200 Rickard Strandqvist > wrote: > >> 2014-10-16 0:15 GMT+02:00 Andrew Morton : >> > On Sun, 5 Oct 2014 15:06:17 +0200 Rickard Strandqvist >> > wrote: >> > >> >> Added a function strzcpy which works the same as strncpy, >> >> but guaranteed to produce the trailing null character. >> >> >> >> There are many places in the code where strncpy used although it >> >> must be zero terminated, and switching to strlcpy is not an option >> >> because the string must nonetheless be fyld with zero characters. >> > >> > As I mentioned last time, I think this patch would be better if it came >> > with follow-on patches which convert at least some of those callsites. >> > As it stands, this function has no callers and hence it won't get >> > tested. Plus those follow-on patches will demonstrate the value of >> > this patch and will provide example usages. >> >> >> Hi >> >> Sure I can do that! I have saved some patches just to be able to use >> this new feature. >> But should I submit everything as one patch then? >> Or is there some kind of dependency thing I can use... > > [patch 1/N] lib/string.c: add strzcpy() > [patch 2/N] foo/bar/zot.c: use strzcpy() > [patch 3/N] fooz/barz/zot.c: use strzcpy() > ... > >> I have also e-mailed with Dan about this, he pointed out the same as >> some of my tests indicate that strzcpy maybe just should use strncpy >> and add a null character instead because strncpy is optimized >> depending on the hardware it runs on. >> What do you think about that? > > Sounds like strzcpy() should be used in places where the entire buffer > will be copied out to userspace, or in other situations where we want to > zero it out for security reasons? Hi So that's how you write it, ok I will send them this weekend when I have some more time. Yes it was the safety aspect I was most yelled at when I start swapping strncpy with strlcpy, although much of it was justified! Even Linus was getting into the debate. See more: https://plus.google.com/111049168280159033135/posts/1amLbuhWbh5 Kind regards Rickard Strandqvist -- 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 v6 0/4] pmbus: ltc2978: add regulator support
On Wed, Oct 15, 2014 at 01:55:06PM -0500, at...@opensource.altera.com wrote: > From: Alan Tull > > Each output has individual on/off control. > > New in v6: > * Much cleanup of the bindings document > * s/vout_en/vout/g > > Hopefully this is getting closer. We will still have the potential problem of > repeated node names on boards on boards that have many regulators of the same > kind. If this can be handled in the regulator layer, that might be great. > If we handle it here, whatever we come up with will have to keep the same > name over reboots and be predictable enough to serve as regulator node names > in the DT. I'm open for suggestions here. > > This patchset now uses "regulator: of: Provide simplified DT parsing method" > which are in the next-20141014 tag of linux-next. > Hi Alan, Since the problems we have seen are in the regulator core code and not in your patches, I added the series to -next. I fixed up the 'compatible' example in the devicetree description, so there is no need to resubmit the patches. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
On Thu, Oct 16, 2014 at 2:12 PM, Serge E. Hallyn wrote:
> Quoting Aditya Kali (adityak...@google.com):
>> setns on a cgroup namespace is allowed only if
>> * task has CAP_SYS_ADMIN in its current user-namespace and
>> over the user-namespace associated with target cgroupns.
>> * task's current cgroup is descendent of the target cgroupns-root
>> cgroup.
>
> What is the point of this?
>
> If I'm a user logged into
> /lxc/c1/user.slice/user-1000.slice/session-c12.scope and I start
> a container which is in
> /lxc/c1/user.slice/user-1000.slice/session-c12.scope/x1
> then I will want to be able to enter the container's cgroup.
> The container's cgroup root is under my own (satisfying the
> below condition0 but my cgroup is not a descendent of the
> container's cgroup.
>
This condition is there because we don't want to do implicit cgroup
changes when a process attaches to another cgroupns. cgroupns tries to
preserve the invariant that at any point, your current cgroup is
always under the cgroupns-root of your cgroup namespace. But in your
example, if we allow a process in "session-c12.scope" container to
attach to cgroupns root'ed at "session-c12.scope/x1" container
(without implicitly moving its cgroup), then this invariant won't
hold.
>
>> * target cgroupns-root is same as or deeper than task's current
>> cgroupns-root. This is so that the task cannot escape out of its
>> cgroupns-root. This also ensures that setns() only makes the task
>> get restricted to a deeper cgroup hierarchy.
>>
>> Signed-off-by: Aditya Kali
>> ---
>> kernel/cgroup_namespace.c | 44 ++--
>> 1 file changed, 42 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c
>> index c16604f..c612946 100644
>> --- a/kernel/cgroup_namespace.c
>> +++ b/kernel/cgroup_namespace.c
>> @@ -80,8 +80,48 @@ err_out:
>>
>> static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
>> {
>> - pr_info("setns not supported for cgroup namespace");
>> - return -EINVAL;
>> + struct cgroup_namespace *cgroup_ns = ns;
>> + struct task_struct *task = current;
>> + struct cgroup *cgrp = NULL;
>> + int err = 0;
>> +
>> + if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
>> + !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + /* Prevent cgroup changes for this task. */
>> + threadgroup_lock(task);
>> +
>> + cgrp = get_task_cgroup(task);
>> +
>> + err = -EINVAL;
>> + if (!cgroup_on_dfl(cgrp))
>> + goto out_unlock;
>> +
>> + /* Allow switch only if the task's current cgroup is descendant of the
>> + * target cgroup_ns->root_cgrp.
>> + */
>> + if (!cgroup_is_descendant(cgrp, cgroup_ns->root_cgrp))
>> + goto out_unlock;
>> +
>> + /* Only allow setns to a cgroupns root-ed deeper than task's current
>> + * cgroupns-root. This will make sure that tasks cannot escape their
>> + * cgroupns by attaching to parent cgroupns.
>> + */
>> + if (!cgroup_is_descendant(cgroup_ns->root_cgrp,
>> + task_cgroupns_root(task)))
>> + goto out_unlock;
>> +
>> + err = 0;
>> + get_cgroup_ns(cgroup_ns);
>> + put_cgroup_ns(nsproxy->cgroup_ns);
>> + nsproxy->cgroup_ns = cgroup_ns;
>> +
>> +out_unlock:
>> + threadgroup_unlock(current);
>> + if (cgrp)
>> + cgroup_put(cgrp);
>> + return err;
>> }
>>
>> static void *cgroupns_get(struct task_struct *task)
>> --
>> 2.1.0.rc2.206.gedb03e5
>>
>> --
>> 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/
--
Aditya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf: 3.17 another perf_fuzzer lockup
On Wed, 15 Oct 2014, Vince Weaver wrote: > I can use sysrq to get the stack trace, the one CPU is stuck in a call > to find_get_context(). > > An example backtrace: > > [88200.33] > [88200.33] [] ? cache_alloc+0x130/0x25b > [88200.33] [] ? __call_rcu.constprop.63+0x1bf/0x1cb > [88200.33] [] kfree_call_rcu+0x1a/0x1c > [88200.33] [] put_ctx+0x51/0x55 > [88200.33] [] find_get_context+0x166/0x195 > [88200.33] [] SYSC_perf_event_open+0x47b/0x7f5 > [88200.33] [] SyS_perf_event_open+0xe/0x10 > [88200.33] [] system_call_fastpath+0x16/0x1b > > It looks like the > else if (task->perf_event_ctxp[ctxn]) > err = -EAGAIN; It is indeed stuck there, waiting for task->perf_event_ctxp[1] to get set to zero, which never happens. As far as I can tell it's when a Software event is being opened. Still struggling through the code trying to figure out what's going on. [ 7071.252607] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.259439] VMW: type=1 config=8 [ 7071.262713] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.269506] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.276299] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.283087] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.289879] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.296671] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.303457] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.310248] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7071.317035] VMW: task->perf_event_ctxp[1]=8800cb12ec00, EAGAIN, ref=1 [ 7076.256032] find_get_context: 7246310 callbacks suppressed Vince -- 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: + freezer-check-oom-kill-while-being-frozen.patch added to -mm tree
On Thu, Oct 16, 2014 at 2:11 PM, Oleg Nesterov wrote: > > But also I can't understand why this patch helps. The changelog says: > > do_send_sig_info will wake up the thread > > why? > This is a question for Michal who rewrites my changelog: http://marc.info/?l=linux-kernel&m=140986986423092&w=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: [PATCHv1 7/8] cgroup: cgroup namespace setns support
On Thu, Oct 16, 2014 at 2:12 PM, Serge E. Hallyn wrote:
> Quoting Aditya Kali (adityak...@google.com):
>> setns on a cgroup namespace is allowed only if
>> * task has CAP_SYS_ADMIN in its current user-namespace and
>> over the user-namespace associated with target cgroupns.
>> * task's current cgroup is descendent of the target cgroupns-root
>> cgroup.
>
> What is the point of this?
>
> If I'm a user logged into
> /lxc/c1/user.slice/user-1000.slice/session-c12.scope and I start
> a container which is in
> /lxc/c1/user.slice/user-1000.slice/session-c12.scope/x1
> then I will want to be able to enter the container's cgroup.
> The container's cgroup root is under my own (satisfying the
> below condition0 but my cgroup is not a descendent of the
> container's cgroup.
>
Presumably you need to ask your friendly cgroup manager to stick you
in that cgroup first. Or we need to generally allow tasks to move
themselves deeper in the hierarchy, but that seems like a big change.
--Andy
>
>> * target cgroupns-root is same as or deeper than task's current
>> cgroupns-root. This is so that the task cannot escape out of its
>> cgroupns-root. This also ensures that setns() only makes the task
>> get restricted to a deeper cgroup hierarchy.
>>
>> Signed-off-by: Aditya Kali
>> ---
>> kernel/cgroup_namespace.c | 44 ++--
>> 1 file changed, 42 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c
>> index c16604f..c612946 100644
>> --- a/kernel/cgroup_namespace.c
>> +++ b/kernel/cgroup_namespace.c
>> @@ -80,8 +80,48 @@ err_out:
>>
>> static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
>> {
>> - pr_info("setns not supported for cgroup namespace");
>> - return -EINVAL;
>> + struct cgroup_namespace *cgroup_ns = ns;
>> + struct task_struct *task = current;
>> + struct cgroup *cgrp = NULL;
>> + int err = 0;
>> +
>> + if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
>> + !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + /* Prevent cgroup changes for this task. */
>> + threadgroup_lock(task);
>> +
>> + cgrp = get_task_cgroup(task);
>> +
>> + err = -EINVAL;
>> + if (!cgroup_on_dfl(cgrp))
>> + goto out_unlock;
>> +
>> + /* Allow switch only if the task's current cgroup is descendant of the
>> + * target cgroup_ns->root_cgrp.
>> + */
>> + if (!cgroup_is_descendant(cgrp, cgroup_ns->root_cgrp))
>> + goto out_unlock;
>> +
>> + /* Only allow setns to a cgroupns root-ed deeper than task's current
>> + * cgroupns-root. This will make sure that tasks cannot escape their
>> + * cgroupns by attaching to parent cgroupns.
>> + */
>> + if (!cgroup_is_descendant(cgroup_ns->root_cgrp,
>> + task_cgroupns_root(task)))
>> + goto out_unlock;
>> +
>> + err = 0;
>> + get_cgroup_ns(cgroup_ns);
>> + put_cgroup_ns(nsproxy->cgroup_ns);
>> + nsproxy->cgroup_ns = cgroup_ns;
>> +
>> +out_unlock:
>> + threadgroup_unlock(current);
>> + if (cgrp)
>> + cgroup_put(cgrp);
>> + return err;
>> }
>>
>> static void *cgroupns_get(struct task_struct *task)
>> --
>> 2.1.0.rc2.206.gedb03e5
>>
>> --
>> 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/
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] lib: string.c: Added a funktion function strzcpy
On Thu, 16 Oct 2014 23:09:00 +0200 Rickard Strandqvist wrote: > 2014-10-16 0:15 GMT+02:00 Andrew Morton : > > On Sun, 5 Oct 2014 15:06:17 +0200 Rickard Strandqvist > > wrote: > > > >> Added a function strzcpy which works the same as strncpy, > >> but guaranteed to produce the trailing null character. > >> > >> There are many places in the code where strncpy used although it > >> must be zero terminated, and switching to strlcpy is not an option > >> because the string must nonetheless be fyld with zero characters. > > > > As I mentioned last time, I think this patch would be better if it came > > with follow-on patches which convert at least some of those callsites. > > As it stands, this function has no callers and hence it won't get > > tested. Plus those follow-on patches will demonstrate the value of > > this patch and will provide example usages. > > > Hi > > Sure I can do that! I have saved some patches just to be able to use > this new feature. > But should I submit everything as one patch then? > Or is there some kind of dependency thing I can use... [patch 1/N] lib/string.c: add strzcpy() [patch 2/N] foo/bar/zot.c: use strzcpy() [patch 3/N] fooz/barz/zot.c: use strzcpy() ... > I have also e-mailed with Dan about this, he pointed out the same as > some of my tests indicate that strzcpy maybe just should use strncpy > and add a null character instead because strncpy is optimized > depending on the hardware it runs on. > What do you think about that? Sounds like strzcpy() should be used in places where the entire buffer will be copied out to userspace, or in other situations where we want to zero it out for security reasons? -- 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 v5] char: hw_random: core.c: Changed from using strncat to strlcat
The buf is used to hold the list of hwrng devices registered.
The old code ensures we don't walk off the end of buf as we
fill it, but it's unnecessarily complicated and thus difficult
to maintain. Simplify it by using strlcat.
Signed-off-by: Rickard Strandqvist
Reviewed-by: Jason Cooper
---
drivers/char/hw_random/core.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25..1500cfd 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -281,7 +281,6 @@ static ssize_t hwrng_attr_available_show(struct device *dev,
char *buf)
{
int err;
- ssize_t ret = 0;
struct hwrng *rng;
err = mutex_lock_interruptible(&rng_mutex);
@@ -289,16 +288,13 @@ static ssize_t hwrng_attr_available_show(struct device
*dev,
return -ERESTARTSYS;
buf[0] = '\0';
list_for_each_entry(rng, &rng_list, list) {
- strncat(buf, rng->name, PAGE_SIZE - ret - 1);
- ret += strlen(rng->name);
- strncat(buf, " ", PAGE_SIZE - ret - 1);
- ret++;
+ strlcat(buf, rng->name, PAGE_SIZE);
+ strlcat(buf, " ", PAGE_SIZE);
}
- strncat(buf, "\n", PAGE_SIZE - ret - 1);
- ret++;
+ strlcat(buf, "\n", PAGE_SIZE);
mutex_unlock(&rng_mutex);
- return ret;
+ return strlen(buf);
}
static DEVICE_ATTR(rng_current, S_IRUGO | S_IWUSR,
--
1.7.10.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: + freezer-check-oom-kill-while-being-frozen.patch added to -mm tree
On 10/16, Cong Wang wrote: > > On Thu, Oct 16, 2014 at 1:39 PM, Oleg Nesterov wrote: > >> Fix the issue by checking for TIF_MEMDIE thread flag and get away from the > >> fridge if it is set. oom_scan_process_thread doesn't have to check for > >> the frozen task anymore because do_send_sig_info will wake up the thread > >> and TIF_MEMDIE is already set by that time. > > > > I must have missed something... but __refrigerator() sleeps in > > TASK_UNINTERRUPTIBLE and do_send_sig_info() won't wake it up? > > > > This is exactly what we are trying to fix. Make sure you read the patch > as well before reply? I did read the patch, but I can't understand it. I am sorry about that, and I am asking for your help. I agree that oom_scan_process_thread()->__thaw_task() doesn't really help. But also I can't understand why this patch helps. The changelog says: do_send_sig_info will wake up the thread why? Oleg. -- 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: [PATCHv1 7/8] cgroup: cgroup namespace setns support
Quoting Aditya Kali (adityak...@google.com):
> setns on a cgroup namespace is allowed only if
> * task has CAP_SYS_ADMIN in its current user-namespace and
> over the user-namespace associated with target cgroupns.
> * task's current cgroup is descendent of the target cgroupns-root
> cgroup.
What is the point of this?
If I'm a user logged into
/lxc/c1/user.slice/user-1000.slice/session-c12.scope and I start
a container which is in
/lxc/c1/user.slice/user-1000.slice/session-c12.scope/x1
then I will want to be able to enter the container's cgroup.
The container's cgroup root is under my own (satisfying the
below condition0 but my cgroup is not a descendent of the
container's cgroup.
> * target cgroupns-root is same as or deeper than task's current
> cgroupns-root. This is so that the task cannot escape out of its
> cgroupns-root. This also ensures that setns() only makes the task
> get restricted to a deeper cgroup hierarchy.
>
> Signed-off-by: Aditya Kali
> ---
> kernel/cgroup_namespace.c | 44 ++--
> 1 file changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c
> index c16604f..c612946 100644
> --- a/kernel/cgroup_namespace.c
> +++ b/kernel/cgroup_namespace.c
> @@ -80,8 +80,48 @@ err_out:
>
> static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
> {
> - pr_info("setns not supported for cgroup namespace");
> - return -EINVAL;
> + struct cgroup_namespace *cgroup_ns = ns;
> + struct task_struct *task = current;
> + struct cgroup *cgrp = NULL;
> + int err = 0;
> +
> + if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
> + !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + /* Prevent cgroup changes for this task. */
> + threadgroup_lock(task);
> +
> + cgrp = get_task_cgroup(task);
> +
> + err = -EINVAL;
> + if (!cgroup_on_dfl(cgrp))
> + goto out_unlock;
> +
> + /* Allow switch only if the task's current cgroup is descendant of the
> + * target cgroup_ns->root_cgrp.
> + */
> + if (!cgroup_is_descendant(cgrp, cgroup_ns->root_cgrp))
> + goto out_unlock;
> +
> + /* Only allow setns to a cgroupns root-ed deeper than task's current
> + * cgroupns-root. This will make sure that tasks cannot escape their
> + * cgroupns by attaching to parent cgroupns.
> + */
> + if (!cgroup_is_descendant(cgroup_ns->root_cgrp,
> + task_cgroupns_root(task)))
> + goto out_unlock;
> +
> + err = 0;
> + get_cgroup_ns(cgroup_ns);
> + put_cgroup_ns(nsproxy->cgroup_ns);
> + nsproxy->cgroup_ns = cgroup_ns;
> +
> +out_unlock:
> + threadgroup_unlock(current);
> + if (cgrp)
> + cgroup_put(cgrp);
> + return err;
> }
>
> static void *cgroupns_get(struct task_struct *task)
> --
> 2.1.0.rc2.206.gedb03e5
>
> --
> 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/
--
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] lib: string.c: Added a funktion function strzcpy
2014-10-16 0:15 GMT+02:00 Andrew Morton : > On Sun, 5 Oct 2014 15:06:17 +0200 Rickard Strandqvist > wrote: > >> Added a function strzcpy which works the same as strncpy, >> but guaranteed to produce the trailing null character. >> >> There are many places in the code where strncpy used although it >> must be zero terminated, and switching to strlcpy is not an option >> because the string must nonetheless be fyld with zero characters. > > As I mentioned last time, I think this patch would be better if it came > with follow-on patches which convert at least some of those callsites. > As it stands, this function has no callers and hence it won't get > tested. Plus those follow-on patches will demonstrate the value of > this patch and will provide example usages. Hi Sure I can do that! I have saved some patches just to be able to use this new feature. But should I submit everything as one patch then? Or is there some kind of dependency thing I can use... I have also e-mailed with Dan about this, he pointed out the same as some of my tests indicate that strzcpy maybe just should use strncpy and add a null character instead because strncpy is optimized depending on the hardware it runs on. What do you think about that? Kind regards Rickard Strandqvist -- 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: Machine crashes right *after* ~successful resume
Hello, I have filed a bug now: https://bugzilla.kernel.org/show_bug.cgi?id=86421 We should probably continue the discussion there now? I've added just you to the CC field, not sure who else on this thread is still interested at this point. On 16-10-14 17:36, Yinghai Lu wrote: Can you put "debug ignore_loglevel" in boot command line? So we can compare output from serial console between good one and bad one directly. Did that, will throw the output in the same log dir. Those arguments resulted in very little extra output. :-/ Also did you try to remove r8169 every time before suspend? Did that on this run, no difference either. For full completeness, I reproduced this problem with no modules loaded (done from initramfs) at all, with a kernel with your workaround included, logs are here: http://gaast.net/~wilmer/.lkml/bad3.17-patched-debug-initramfs.txt Wilmer v/d Gaast. -- + .''`. - -- ---+ +- -- --- - --+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---+ +-- - --- -- -+ -- 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 -next 19/27] tty: Remove tty_unhangup() declaration
The tty_unhangup() function is not defined. Signed-off-by: Peter Hurley --- include/linux/tty.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/tty.h b/include/linux/tty.h index a07b4b4..d470a86 100644 --- a/include/linux/tty.h +++ b/include/linux/tty.h @@ -435,7 +435,6 @@ extern int is_ignored(int sig); extern int tty_signal(int sig, struct tty_struct *tty); extern void tty_hangup(struct tty_struct *tty); extern void tty_vhangup(struct tty_struct *tty); -extern void tty_unhangup(struct file *filp); extern int tty_hung_up_p(struct file *filp); extern void do_SAK(struct tty_struct *tty); extern void __do_SAK(struct tty_struct *tty); -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Input: xpad - add Thrustmaster as Xbox 360 controller vendor
On Wed, Oct 15, 2014 at 02:04:36PM +0300, Tommi Rantala wrote:
> Add Thrustmaster as Xbox 360 controller vendor. This is required for
> example to make the GP XID (044f:b326) gamepad work.
>
> Signed-off-by: Tommi Rantala
Applied both, thank you.
> ---
> drivers/input/joystick/xpad.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index cee4fe3..2ed7905 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -293,6 +293,7 @@ static const signed short xpad_abs_triggers[] = {
>
> static struct usb_device_id xpad_table[] = {
> { USB_INTERFACE_INFO('X', 'B', 0) },/* X-Box USB-IF not approved
> class */
> + XPAD_XBOX360_VENDOR(0x044f),/* Thrustmaster X-Box 360
> controllers */
> XPAD_XBOX360_VENDOR(0x045e),/* Microsoft X-Box 360
> controllers */
> XPAD_XBOXONE_VENDOR(0x045e),/* Microsoft X-Box One
> controllers */
> XPAD_XBOX360_VENDOR(0x046d),/* Logitech X-Box 360 style
> controllers */
> --
> 1.9.3
>
--
Dmitry
--
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 -next 20/27] tty: Refactor __tty_hangup to enable lockdep annotation
Refactor __tty_hangup() into:
1. __tty_hangup_common(), the portion requiring the tty lock
2. __tty_hangup(), which performs the pre- and post-lock processing
(TIOCCONS redirect undo) and calls through a function ptr parameter
to lock/hangup/unlock
3. __tty_hangup_standard(), which performs the lock/hangup/unlock
Allows an alternate function to lock/hangup/unlock with the
nested tty lock.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 51 ++-
1 file changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 58015b3..48c1def 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -665,32 +665,17 @@ static int tty_signal_session_leader(struct tty_struct
*tty, int exit_session)
* tasklist_lock to walk task list for hangup event
* ->siglock to protect ->signal/->sighand
*/
-static void __tty_hangup(struct tty_struct *tty, int exit_session)
+static void __tty_hangup_common(struct tty_struct *tty, int exit_session)
{
struct file *cons_filp = NULL;
- struct file *filp, *f = NULL;
+ struct file *filp;
struct tty_file_private *priv;
intclosecount = 0, n;
int refs;
- if (!tty)
+ if (test_bit(TTY_HUPPED, &tty->flags))
return;
-
- spin_lock(&redirect_lock);
- if (redirect && file_tty(redirect) == tty) {
- f = redirect;
- redirect = NULL;
- }
- spin_unlock(&redirect_lock);
-
- tty_lock(tty);
-
- if (test_bit(TTY_HUPPED, &tty->flags)) {
- tty_unlock(tty);
- return;
- }
-
/* inuse_filps is protected by the single tty lock,
this really needs to change if we want to flush the
workqueue with the lock held */
@@ -746,7 +731,31 @@ static void __tty_hangup(struct tty_struct *tty, int
exit_session)
* can't yet guarantee all that.
*/
set_bit(TTY_HUPPED, &tty->flags);
+}
+
+static void __tty_hangup_standard(struct tty_struct* tty, int exit_session)
+{
+ tty_lock(tty);
+ __tty_hangup_common(tty, exit_session);
tty_unlock(tty);
+}
+
+static void __tty_hangup(struct tty_struct *tty, int exit_session,
+void (*hangup)(struct tty_struct *, int))
+{
+ struct file *f = NULL;
+
+ if (!tty)
+ return;
+
+ spin_lock(&redirect_lock);
+ if (redirect && file_tty(redirect) == tty) {
+ f = redirect;
+ redirect = NULL;
+ }
+ spin_unlock(&redirect_lock);
+
+ hangup(tty, exit_session);
if (f)
fput(f);
@@ -757,7 +766,7 @@ static void do_tty_hangup(struct work_struct *work)
struct tty_struct *tty =
container_of(work, struct tty_struct, hangup_work);
- __tty_hangup(tty, 0);
+ __tty_hangup(tty, 0, __tty_hangup_standard);
}
/**
@@ -795,7 +804,7 @@ void tty_vhangup(struct tty_struct *tty)
printk(KERN_DEBUG "%s vhangup...\n", tty_name(tty, buf));
#endif
- __tty_hangup(tty, 0);
+ __tty_hangup(tty, 0, __tty_hangup_standard);
}
EXPORT_SYMBOL(tty_vhangup);
@@ -836,7 +845,7 @@ static void tty_vhangup_session(struct tty_struct *tty)
printk(KERN_DEBUG "%s vhangup session...\n", tty_name(tty, buf));
#endif
- __tty_hangup(tty, 1);
+ __tty_hangup(tty, 1, __tty_hangup_standard);
}
/**
--
2.1.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 -next 22/27] tty: Document hangup call tree
Add at-a-glance call tree for the various hangup methods.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 25e85b0..8effd44 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -664,6 +664,19 @@ static int tty_signal_session_leader(struct tty_struct
*tty, int exit_session)
* termios_rwsem resetting termios data
* tasklist_lock to walk task list for hangup event
* ->siglock to protect ->signal/->sighand
+ *
+ * Call tree:
+ * tty_hangup() => do_tty_hangup() -+
+ * |
+ * tty_vhangup() -+ |
+ * tty_vhangup_self() + |
+ * tty_vhangup_session() -+-+
+ * |
+ * __tty_hangup() -> __tty_hangup_standard() -+
+ * |
+ * tty_vhangup_slave() > __tty_hangup() -> __tty_vhangup_slave() ---+
+ * |
+ *
__tty_hangup_common()
*/
static void __tty_hangup_common(struct tty_struct *tty, int exit_session)
{
--
2.1.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 -next 21/27] pty: Don't drop pty master tty lock to hangup slave
Introduce tty_vhangup_slave(), which takes tty_lock_slave() instead
of tty_lock(), and thus is callable while holding the pty master
tty lock.
Signed-off-by: Peter Hurley
---
drivers/tty/pty.c| 4 +---
drivers/tty/tty_io.c | 20
include/linux/tty.h | 1 +
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index bdb8fd1..09fb513 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -66,9 +66,7 @@ static void pty_close(struct tty_struct *tty, struct file
*filp)
mutex_unlock(&devpts_mutex);
}
#endif
- tty_unlock(tty);
- tty_vhangup(tty->link);
- tty_lock(tty);
+ tty_vhangup_slave(tty->link);
}
}
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 48c1def..25e85b0 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -809,6 +809,26 @@ void tty_vhangup(struct tty_struct *tty)
EXPORT_SYMBOL(tty_vhangup);
+/**
+ * tty_vhangup_slave - process vhangup for pty slave
+ * @tty: pty slave to hangup
+ *
+ * Identical to tty_vhangup(), except can specifically be used
+ * to synchronously hangup a pty slave while holding pty master
+ * tty lock.
+ */
+
+static void __tty_vhangup_slave(struct tty_struct *tty, int exit_session)
+{
+ tty_lock_slave(tty);
+ __tty_hangup_common(tty, 0);
+ tty_unlock_slave(tty);
+}
+
+void tty_vhangup_slave(struct tty_struct *tty)
+{
+ __tty_hangup(tty, 0, __tty_vhangup_slave);
+}
/**
* tty_vhangup_self- process vhangup for own ctty
diff --git a/include/linux/tty.h b/include/linux/tty.h
index d470a86..8a90253 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -435,6 +435,7 @@ extern int is_ignored(int sig);
extern int tty_signal(int sig, struct tty_struct *tty);
extern void tty_hangup(struct tty_struct *tty);
extern void tty_vhangup(struct tty_struct *tty);
+extern void tty_vhangup_slave(struct tty_struct *tty);
extern int tty_hung_up_p(struct file *filp);
extern void do_SAK(struct tty_struct *tty);
extern void __do_SAK(struct tty_struct *tty);
--
2.1.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 -next 10/27] tty: Don't take tty_mutex for tty count changes
Holding tty_mutex is no longer required to serialize changes to
the tty_count or to prevent concurrent opens of closing ttys;
tty_lock() is sufficient.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 55f9931..7b40247 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1805,10 +1805,6 @@ int tty_release(struct inode *inode, struct file *filp)
* each iteration we avoid any problems.
*/
while (1) {
- /* Guard against races with tty->count changes elsewhere and
- opens on /dev/tty */
-
- mutex_lock(&tty_mutex);
tty_lock_pair(tty, o_tty);
tty_closing = tty->count <= 1;
o_tty_closing = o_tty &&
@@ -1844,7 +1840,6 @@ int tty_release(struct inode *inode, struct file *filp)
__func__, tty_name(tty, buf));
}
tty_unlock_pair(tty, o_tty);
- mutex_unlock(&tty_mutex);
schedule_timeout_killable(timeout);
if (timeout < 120 * HZ)
timeout = 2 * timeout + 1;
@@ -1899,7 +1894,6 @@ int tty_release(struct inode *inode, struct file *filp)
read_unlock(&tasklist_lock);
}
- mutex_unlock(&tty_mutex);
tty_unlock_pair(tty, o_tty);
/* At this point, the tty->count == 0 should ensure a dead tty
cannot be re-opened by a racing opener */
--
2.1.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 -next 11/27] tty: Don't release tty locks for wait queue sanity check
Releasing the tty locks while waiting for the tty wait queues to
be empty is no longer necessary nor desirable. Prior to
"tty: Don't take tty_mutex for tty count changes", dropping the
tty locks was necessary to reestablish the correct lock order between
tty_mutex and the tty locks. Dropping the global tty_mutex was necessary;
otherwise new ttys could not have been opened while waiting.
However, without needing the global tty_mutex held, the tty locks for
the releasing tty can now be held through the sleep. The sanity check
is for abnormal conditions caused by kernel bugs, not for recoverable
errors caused by misbehaving userspace; dropping the tty locks only
allows the tty state to get more sideways.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 7b40247..50118ce 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1799,13 +1799,10 @@ int tty_release(struct inode *inode, struct file *filp)
* first, its count will be one, since the master side holds an open.
* Thus this test wouldn't be triggered at the time the slave closes,
* so we do it now.
-*
-* Note that it's possible for the tty to be opened again while we're
-* flushing out waiters. By recalculating the closing flags before
-* each iteration we avoid any problems.
*/
+ tty_lock_pair(tty, o_tty);
+
while (1) {
- tty_lock_pair(tty, o_tty);
tty_closing = tty->count <= 1;
o_tty_closing = o_tty &&
(o_tty->count <= (pty_master ? 1 : 0));
@@ -1839,7 +1836,6 @@ int tty_release(struct inode *inode, struct file *filp)
printk(KERN_WARNING "%s: %s: read/write wait queue
active!\n",
__func__, tty_name(tty, buf));
}
- tty_unlock_pair(tty, o_tty);
schedule_timeout_killable(timeout);
if (timeout < 120 * HZ)
timeout = 2 * timeout + 1;
--
2.1.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/
