Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/21/14, 11:08 AM, Devin Heitmueller wrote: Sorry, I'm not convinced by that. If the device has to be controlled exclusively, the right position is the open/close. Otherwise, the program cannot know when it becomes inaccessible out of sudden during its operation. I can say that I've definitely seen cases where if you configure a device as the "default" capture device in PulseAudio, then pulse will continue to capture from it even if you're not actively capturing the audio from pulse. I only spotted this because I had a USB analyzer on the device and was dumbfounded when the ISOC packets kept arriving even after I had closed VLC. this seems like a feature, not a bug. PulseAudio starts streaming before clients push any data and likewise keeps sources active even after for some time after clients stop recording. Closing VLC in your example doesn't immediately close the ALSA device. look for module-suspend-on-idle in your default.pa config file. I also agree that the open/close of the alsa device is the only way to control exclusion. -Pierre -- 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] perf tool: add hists__init for perf diff
Em Wed, Oct 22, 2014 at 03:02:41PM -0400, kan.li...@intel.com escreveu:
> From: Kan Liang
>
> perf diff also uses hists/hist_entries, hists__init() should be called
> before creating any evsels.
Thanks, this one merits perf/urgent :-\
- Arnaldo
> Signed-off-by: Kan Liang
> ---
> tools/perf/builtin-diff.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 8c5c11c..25114c9 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -1142,6 +1142,11 @@ static int data_init(int argc, const char **argv)
>
> int cmd_diff(int argc, const char **argv, const char *prefix __maybe_unused)
> {
> + int ret = hists__init();
> +
> + if (ret < 0)
> + return ret;
> +
> perf_config(perf_default_config, NULL);
>
> argc = parse_options(argc, argv, options, diff_usage, 0);
> --
> 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: localed stuck in recent 3.18 git in copy_net_ns?
On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney
wrote:
> On Wed, Oct 22, 2014 at 01:25:37PM -0500, Eric W. Biederman wrote:
>> "Paul E. McKenney" writes:
>>
>> > On Wed, Oct 22, 2014 at 12:53:24PM -0500, Eric W. Biederman wrote:
>> >> Cong Wang writes:
>> >>
>> >> > (Adding Paul and Eric in Cc)
>> >> >
>> >> >
>> >> > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer
>> >> > wrote:
>> >> >>
>> >> >> Someone else is seeing this when they try and modprobe ppp_generic:
>> >> >>
>> >> >> [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120
>> >> >> seconds.
>> >> >> [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1
>> >> >> [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> >> >> disables this message.
>> >> >> [ 240.599583] kworker/u16:5 D 8802202db480 12400 100 2
>> >> >> 0x
>> >> >> [ 240.599744] Workqueue: netns cleanup_net
>> >> >> [ 240.599823] 8802202eb9e8 0096 8802202db480
>> >> >> 001d5f00
>> >> >> [ 240.600066] 8802202ebfd8 001d5f00 8800368c3480
>> >> >> 8802202db480
>> >> >> [ 240.600228] 81ee2690 7fff 81ee2698
>> >> >> 81ee2690
>> >> >> [ 240.600386] Call Trace:
>> >> >> [ 240.600445] [] schedule+0x29/0x70
>> >> >> [ 240.600541] [] schedule_timeout+0x26c/0x410
>> >> >> [ 240.600651] [] ? retint_restore_args+0x13/0x13
>> >> >> [ 240.600765] [] ? _raw_spin_unlock_irq+0x34/0x50
>> >> >> [ 240.600879] [] wait_for_completion+0x10c/0x150
>> >> >> [ 240.601025] [] ? wake_up_state+0x20/0x20
>> >> >> [ 240.601133] [] _rcu_barrier+0x159/0x200
>> >> >> [ 240.601237] [] rcu_barrier+0x15/0x20
>> >> >> [ 240.601335] [] netdev_run_todo+0x6f/0x310
>> >> >> [ 240.601442] [] ?
>> >> >> rollback_registered_many+0x265/0x2e0
>> >> >> [ 240.601564] [] rtnl_unlock+0xe/0x10
>> >> >> [ 240.601660] []
>> >> >> default_device_exit_batch+0x156/0x180
>> >> >> [ 240.601781] [] ? abort_exclusive_wait+0xb0/0xb0
>> >> >> [ 240.601895] [] ops_exit_list.isra.1+0x53/0x60
>> >> >> [ 240.602028] [] cleanup_net+0x100/0x1f0
>> >> >> [ 240.602131] [] process_one_work+0x218/0x850
>> >> >> [ 240.602241] [] ? process_one_work+0x17f/0x850
>> >> >> [ 240.602350] [] ? worker_thread+0xe7/0x4a0
>> >> >> [ 240.602454] [] worker_thread+0x6b/0x4a0
>> >> >> [ 240.602555] [] ? process_one_work+0x850/0x850
>> >> >> [ 240.602665] [] kthread+0x10b/0x130
>> >> >> [ 240.602762] [] ? sched_clock+0x9/0x10
>> >> >> [ 240.602862] [] ?
>> >> >> kthread_create_on_node+0x250/0x250
>> >> >> [ 240.603004] [] ret_from_fork+0x7c/0xb0
>> >> >> [ 240.603106] [] ?
>> >> >> kthread_create_on_node+0x250/0x250
>> >> >> [ 240.603224] 4 locks held by kworker/u16:5/100:
>> >> >> [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: []
>> >> >> process_one_work+0x17f/0x850
>> >> >> [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at:
>> >> >> [] process_one_work+0x17f/0x850
>> >> >> [ 240.603691] #2: (net_mutex){+.+.+.}, at: []
>> >> >> cleanup_net+0x8c/0x1f0
>> >> >> [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at:
>> >> >> [] _rcu_barrier+0x35/0x200
>> >> >> [ 240.604211] INFO: task modprobe:1387 blocked for more than 120
>> >> >> seconds.
>> >> >> [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1
>> >> >> [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> >> >> disables this message.
>> >> >> [ 240.604570] modprobeD 8800cb4f1a40 13112 1387 1386
>> >> >> 0x0080
>> >> >> [ 240.604719] 8800cafbbbe8 0096 8800cb4f1a40
>> >> >> 001d5f00
>> >> >> [ 240.604878] 8800cafbbfd8 001d5f00 88022328
>> >> >> 8800cb4f1a40
>> >> >> [ 240.605068] 8800cb4f1a40 81f8fb48 0246
>> >> >> 8800cb4f1a40
>> >> >> [ 240.605228] Call Trace:
>> >> >> [ 240.605283] []
>> >> >> schedule_preempt_disabled+0x31/0x80
>> >> >> [ 240.605400] [] mutex_lock_nested+0x183/0x440
>> >> >> [ 240.605510] [] ? register_pernet_subsys+0x1f/0x50
>> >> >> [ 240.605626] [] ? register_pernet_subsys+0x1f/0x50
>> >> >> [ 240.605757] [] ? 0xa0701000
>> >> >> [ 240.605854] [] register_pernet_subsys+0x1f/0x50
>> >> >> [ 240.606005] [] br_init+0x48/0xd3 [bridge]
>> >> >> [ 240.606112] [] do_one_initcall+0xd8/0x210
>> >> >> [ 240.606224] [] load_module+0x20c2/0x2870
>> >> >> [ 240.606327] [] ? store_uevent+0x70/0x70
>> >> >> [ 240.606433] [] ?
>> >> >> lock_release_non_nested+0x3c6/0x3d0
>> >> >> [ 240.606557] [] SyS_init_module+0xe7/0x140
>> >> >> [ 240.606664] [] system_call_fastpath+0x12/0x17
>> >> >> [ 240.606773] 1 lock held by modprobe/1387:
>> >> >> [ 240.606845] #0: (net_mutex){+.+.+.}, at: []
>> >> >> register_pernet_subsys+0x1f/0x50
>> >> >> [ 240.607114] INFO: task modprobe:1466 blocked for more than 120
>> >> >> seconds.
>> >> >> [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1
>> >>
Re: [PATCH] net: fs_enet: set back promiscuity mode after restart
From: Christophe Leroy Date: Wed, 22 Oct 2014 09:05:47 +0200 (CEST) > After interface restart (eg: after link disconnection/reconnection), the > bridge > function doesn't work anymore. This is due to the promiscuous mode being > cleared > by the restart. > > The mac-fcc already includes code to set the promiscuous mode back during the > restart. > This patch adds the same handling to mac-fec and mac-scc. > > Tested with bridge function on MPC885 with FEC. > > Reported-by: Germain Montoies > Signed-off-by: Christophe Leroy Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] drivers: net: xgene: Rewrite loop in xgene_enet_ecc_init()
From: Geert Uytterhoeven
Date: Wed, 22 Oct 2014 09:39:41 +0200
> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function
> ‘xgene_enet_ecc_init’:
> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: ‘data’ may be
> used uninitialized in this function
>
> Depending on the arbitrary value on the stack, the loop may terminate
> too early, and cause a bogus -ENODEV failure.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v2: Rewrite the loop instead of pre-initializing data.
I hate to be a pest, but like the other patch of your's I think
a do { } while() works best here because the intent is clearly
to run the loop at least once, right?
[tip:x86/urgent] x86, apic: Handle a bad TSC more gracefully
Commit-ID: b47dcbdc5161d3d5756f430191e2840d9b855492
Gitweb: http://git.kernel.org/tip/b47dcbdc5161d3d5756f430191e2840d9b855492
Author: Andy Lutomirski
AuthorDate: Wed, 15 Oct 2014 10:12:07 -0700
Committer: Thomas Gleixner
CommitDate: Wed, 22 Oct 2014 21:31:46 +0200
x86, apic: Handle a bad TSC more gracefully
If the TSC is unusable or disabled, then this patch fixes:
- Confusion while trying to clear old APIC interrupts.
- Division by zero and incorrect programming of the TSC deadline
timer.
This fixes boot if the CPU has a TSC deadline timer but a missing or
broken TSC. The failure to boot can be observed with qemu using
-cpu qemu64,-tsc,+tsc-deadline
This also happens to me in nested KVM for unknown reasons.
With this patch, I can boot cleanly (although without a TSC).
Signed-off-by: Andy Lutomirski
Cc: Bandan Das
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/e2fa274e498c33988efac0ba8b7e3120f7f92d78.1413393027.git.l...@amacapital.net
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c | 4 ++--
arch/x86/kernel/tsc.c | 5 -
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 6776027..24b5894 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1297,7 +1297,7 @@ void setup_local_APIC(void)
unsigned int value, queued;
int i, j, acked = 0;
unsigned long long tsc = 0, ntsc;
- long long max_loops = cpu_khz;
+ long long max_loops = cpu_khz ? cpu_khz : 100;
if (cpu_has_tsc)
rdtscll(tsc);
@@ -1383,7 +1383,7 @@ void setup_local_APIC(void)
break;
}
if (queued) {
- if (cpu_has_tsc) {
+ if (cpu_has_tsc && cpu_khz) {
rdtscll(ntsc);
max_loops = (cpu_khz << 10) - (ntsc - tsc);
} else
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index b6025f9..b7e50bb 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1166,14 +1166,17 @@ void __init tsc_init(void)
x86_init.timers.tsc_pre_init();
- if (!cpu_has_tsc)
+ if (!cpu_has_tsc) {
+ setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
return;
+ }
tsc_khz = x86_platform.calibrate_tsc();
cpu_khz = tsc_khz;
if (!tsc_khz) {
mark_tsc_unstable("could not calculate TSC khz");
+ setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
return;
}
--
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] hyperv: Fix the total_data_buflen in send path
total_data_buflen is used by netvsc_send() to decide if a packet can be put into send buffer. It should also include the size of RNDIS message before the Ethernet frame. Otherwise, a messge with total size bigger than send_section_size may be copied into the send buffer, and cause data corruption. [Request to include this patch to the Stable branches] Signed-off-by: Haiyang Zhang Reviewed-by: K. Y. Srinivasan --- drivers/net/hyperv/netvsc_drv.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 9e17d1a..78ec33f 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -550,6 +550,7 @@ do_lso: do_send: /* Start filling in the page buffers with the rndis hdr */ rndis_msg->msg_len += rndis_msg_size; + packet->total_data_buflen = rndis_msg->msg_len; packet->page_buf_cnt = init_page_array(rndis_msg, rndis_msg_size, skb, &packet->page_buf[0]); -- 1.7.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: [PATCHv1 7/8] cgroup: cgroup namespace setns support
Hello, On Wed, Oct 22, 2014 at 11:37:55AM -0700, Aditya Kali wrote: ... > Actually, there is no right answer here. Our options are: > * show relative path > -- this will break userspace as /proc//cgroup does not show > relative paths today. This is also very ambiguous (is it relative to > cgroupns-root or relative to /proc/cgroup file reader's cgroup?). Let's go with this w/o pinning. The only necessary feature for cgroupns is making the /proc/*/cgroups relative to its own root. It's not like containers can avoid trusting its outside world anyway and playing tricks with things like this tend to lead to weird surprises down the road. If userland messes up, userland messes up. Thanks. -- tejun -- 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] kbuild: Fix output of make kernelrelease
Dne 22.10.2014 v 16:19 Steven Rostedt napsal(a):
>
> Commit 7ff525712acf "kbuild: fake the "Entering directory ..." message
> more simply" changed the output of "make kernelrelease" such that the
> kernel release version was not the last line printed. This broke various
> tools that would find the kernel release with "make kernelrelease | tail -1".
The cleaner and recommended (see recent make help) way is to use make -s:
$ make O=build -s kernelrelease
3.18.0-rc1+
no further processing is needed.
> One of those tools that broke was ktest.pl which resides in the kernel.
Can you please apply this patch?
Thanks,
Michal
>From c660b235e25eee053337e0e6c952e87f39839c63 Mon Sep 17 00:00:00 2001
From: Michal Marek
Date: Wed, 22 Oct 2014 21:25:39 +0200
Subject: [PATCH] ktest: Use make -s kernelrelease
The previous tail -1 broke with commit 7ff525712acf ("kbuild: fake the
"Entering directory ..." message more simply")
Reported-by: Steven Rostedt
Signed-off-by: Michal Marek
---
tools/testing/ktest/ktest.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index bf13981..60fe020 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -2005,7 +2005,7 @@ sub get_version {
# get the release name
return if ($have_version);
doprint "$make kernelrelease ... ";
-$version = `$make kernelrelease | tail -1`;
+$version = `$make -s kernelrelease`;
chomp($version);
doprint "$version\n";
$have_version = 1;
--
1.9.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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
> this seems like a feature, not a bug. PulseAudio starts streaming before > clients push any data and likewise keeps sources active even after for some > time after clients stop recording. Closing VLC in your example doesn't > immediately close the ALSA device. look for module-suspend-on-idle in your > default.pa config file. The ALSA userland emulation in PulseAudio is supposed to faithfully emulate the behavior of the ALSA kernel ABI... except when it doesn't, then it's not a bug but rather a feature. :-) > I also agree that the open/close of the alsa device is the only way to > control exclusion. I was also a proponent that we should have fairly coarse locking done at open/close for the various device nodes (ALSA/V4L/DVB). The challenge here is that we have a large installed based of existing applications that rely on kernel behavior that isn't formally specified in any specification. Hence we're forced to try to come up with a solution that minimizes the risk of ABI breakage. If we were doing this from scratch then we could lay down some hard/fast rules about things apps aren't supposed to do and how apps are supposed to respond to those exception cases. Unfortunately we don't have that luxury here. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: introduce probe_slab_address?
On 10/22, David Miller wrote:
>
> From: Oleg Nesterov
> Date: Wed, 22 Oct 2014 20:14:12 +0200
>
> > So perhaps something like this makes sense?
> >
> > If some arch has problems with D-cache aliasing (because the freed page
> > can be already mapped by user-space or vmalloc'ed), it can redefine this
> > helper.
> >
> > Do you think we can use it to access rq->curr? (although let me repeat
> > that I won't really argue with SLAB_DESTROY_BY_RCU).
>
> Do we really need this?
Sorry, I was not clear. let me first explain why do we want this helper,
(although we can avoid it if we make task_struct_cachep SLAB_DESTROY_BY_RCU).
To simplify the discussion, lets ignore the actuall problem we are
trying to solve. Suppose that we want a trivial function, say,
int pid_of_curr_task_on_cpu(int cpu)
{
struct rq *rq = cpu_rq(cpu);
int pid;
rcu_read_lock();
pid = rq->curr->pid;
rcu_read_unlock();
}
and we do not really care if it returns the wrong/random result.
The problem is that rcu_read_lock() can not help (unless we add
SLAB_DESTROY_BY_RCU), rq->curr is not protected by RCU. So rq->curr can
be freed. Again, we do not care, but CONFIG_DEBUG_PAGEALLOC can ummap
this page.
So we can use ifdef(CONFIG_DEBUG_PAGEALLOC) but it would be better to
have a helper to hide this ugliness, and (at least) slub can use it too.
Now the question: is this LOAD is safe in case when this (freed) page
already has another mapping? This is black magic to me, I do not know.
And Peter has some concerns.
And, say, copy_from_user_page() on sparc does
flush_cache_page();
memcpy();
flush_ptrace_access();
Again, I simply do not know if this is relevant or not, probably this
is because "illegal alias" was created by kmap() which can use the
same vaddr to access different pages.
> We fully initialize and read from the area using the same virtual
> address, there is no possiblity for corruption from SLAB's
> perspective.
>
> It's when you store at vaddr X then read at vaddr Y and expect to see
> what you wrote at X that you have problems.
>
> That is very much not what is happening here.
>
> The lifetime is contained to SLAB's usage at one single virtual
> address.
OK, so iiuc this should be safe.
Thanks!
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 2/4] mm: introduce mm_forbids_zeropage function
On Wed, 22 Oct 2014 12:22:23 -0700 Andrew Morton wrote: > On Wed, 22 Oct 2014 13:09:28 +0200 Dominik Dingel > wrote: > > > Add a new function stub to allow architectures to disable for > > an mm_structthe backing of non-present, anonymous pages with > > read-only empty zero pages. > > > > ... > > > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -56,6 +56,10 @@ extern int sysctl_legacy_va_layout; > > #define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x), 0)) > > #endif > > > > +#ifndef mm_forbids_zeropage > > +#define mm_forbids_zeropage(X) (0) > > +#endif > > Can we document this please? What it does, why it does it. We should > also specify precisely which arch header file is responsible for > defining mm_forbids_zeropage. > I will add a comment like: /* * To prevent common memory management code establishing * a zero page mapping on a read fault. * This function should be implemented within . * s390 does this to prevent multiplexing of hardware bits * related to the physical page in case of virtualization. */ Okay? > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org > -- 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] mm: introduce mm_forbids_zeropage function
On Wed, 22 Oct 2014 21:45:52 +0200 Dominik Dingel wrote: > > > +#ifndef mm_forbids_zeropage > > > +#define mm_forbids_zeropage(X) (0) > > > +#endif > > > > Can we document this please? What it does, why it does it. We should > > also specify precisely which arch header file is responsible for > > defining mm_forbids_zeropage. > > > > I will add a comment like: > > /* > * To prevent common memory management code establishing > * a zero page mapping on a read fault. > * This function should be implemented within . s/function should be implemented/macro should be defined/ > * s390 does this to prevent multiplexing of hardware bits > * related to the physical page in case of virtualization. > */ > > Okay? Looks great, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] drivers: net: xgene: Rewrite loop in xgene_enet_ecc_init()
On Wed, Oct 22, 2014 at 9:34 PM, David Miller wrote:
> From: Geert Uytterhoeven
> Date: Wed, 22 Oct 2014 09:39:41 +0200
>
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function
>> ‘xgene_enet_ecc_init’:
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: ‘data’ may
>> be used uninitialized in this function
>>
>> Depending on the arbitrary value on the stack, the loop may terminate
>> too early, and cause a bogus -ENODEV failure.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> v2: Rewrite the loop instead of pre-initializing data.
>
> I hate to be a pest, but like the other patch of your's I think
> a do { } while() works best here because the intent is clearly
> to run the loop at least once, right?
I wanted to avoid checking for "data != ~0U" twice: once to abort the loop,
and once to check if a timeout happened.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Translating mmap2 ids into socket info?
On Wed, Oct 22, 2014 at 02:42:26PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 22, 2014 at 06:45:10PM +0200, Peter Zijlstra escreveu: > > On Wed, Oct 22, 2014 at 12:20:26PM -0400, Don Zickus wrote: > > > Our cache-to-cache tool noticed the slowdown but we couldn't understand > > > why because we had falsely assumed the memory was allocated on the local > > > node but instead it was on the remote node. > > > But in general, you can never say for user memory, since that has the > > process page table mapping in between, the user virtual address is > > unrelated to backing (and can change frequently and without > > notification). > > > Therefore the mmap(2) information is useless for this, it only concerns > > user memory. > > So what you are saying is that it is difficult to have some sort of > mechanism that an mmap moved from one node to another, when that > happens, i.e. a new tracepoint for that? Node is per page, not per mapping. Every single page in a mmap can have a different node (assuming enough nodes etc..), and it can change at relatively high frequency. -- 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: Translating mmap2 ids into socket info?
On Wed, Oct 22, 2014 at 03:15:53PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 22, 2014 at 02:42:26PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Wed, Oct 22, 2014 at 06:45:10PM +0200, Peter Zijlstra escreveu: > > > On Wed, Oct 22, 2014 at 12:20:26PM -0400, Don Zickus wrote: > > > > Our cache-to-cache tool noticed the slowdown but we couldn't understand > > > > why because we had falsely assumed the memory was allocated on the local > > > > node but instead it was on the remote node. > > > > But in general, you can never say for user memory, since that has the > > > process page table mapping in between, the user virtual address is > > > unrelated to backing (and can change frequently and without > > > notification). > > > > Therefore the mmap(2) information is useless for this, it only concerns > > > user memory. > > > So what you are saying is that it is difficult to have some sort of > > mechanism that an mmap moved from one node to another, when that > > happens, i.e. a new tracepoint for that? > > Humm, so, after reading a bit more, I see that we can figure out which > ranges are in which NUMA nodes (like shown in dmesg), and we have the > phys addr, so is this just a matter of perf tooling complement the > information the kernel provides on mmap2 (and the hardware provides on > those events)? We explicitly do not expose the phys address of user space pages. So nope. -- 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 2/3] fpga manager: framework core
From: Alan Tull Supports standard ops for low level FPGA drivers. Various manufacturors' FPGAs can be supported by adding low level drivers. Each driver needs to register its ops using fpga_mgr_register(). Exports methods of doing operations to program FPGAs. These should be sufficient for individual drivers to request FPGA programming directly if desired. Adds a sysfs interface. The sysfs interface can be compiled out where desired in production builds. Resume is supported by calling low level driver's resume function, then reloading the firmware image. The following are exported as GPL: * fpga_mgr_reset Reset the FGPA. * fpga_mgr_write Write a image (in buffer) to the FPGA. * fpga_mgr_firmware_write Request firmware by file name and write it to the FPGA. * fpga_mgr_name Get name of FPGA manager. * fpga_mgr_state Get a state of framework as a string. * fpga_mgr_register and fpga_mgr_remove Register/unregister low level fpga manager driver. The following sysfs files are created: * /sys/class/fpga_manager//name Name of low level driver. * /sys/class/fpga_manager//firmware Name of FPGA image file to load using firmware class. $ echo image.rbf > /sys/class/fpga_manager//firmware read: read back name of image file previous loaded $ cat /sys/class/fpga_manager//firmware * /sys/class/fpga_manager//reset reset the FPGA $ echo 1 > /sys/class/fpga_manager//reset * /sys/class/fpga_manager//state State of fpga framework state machine Signed-off-by: Alan Tull --- v2: s/mangager/manager/ check for invalid request_nr add fpga reset interface rework the state code remove FPGA_MGR_FAIL flag add _ERR states to fpga manager states enum low level state op now returns a state enum value initialize framework state from driver state op remove unused fpga read stuff merge sysfs.c into fpga-mgr.c move suspend/resume from bus.c to fpga-mgr.c --- drivers/Kconfig |2 + drivers/Makefile |1 + drivers/fpga/Kconfig | 21 ++ drivers/fpga/Makefile| 10 + drivers/fpga/fpga-mgr.c | 528 ++ include/linux/fpga-mgr.h | 115 ++ 6 files changed, 677 insertions(+) create mode 100644 drivers/fpga/Kconfig create mode 100644 drivers/fpga/Makefile create mode 100644 drivers/fpga/fpga-mgr.c create mode 100644 include/linux/fpga-mgr.h diff --git a/drivers/Kconfig b/drivers/Kconfig index 622fa26..fc45fee 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -34,6 +34,8 @@ source "drivers/message/fusion/Kconfig" source "drivers/firewire/Kconfig" +source "drivers/fpga/Kconfig" + source "drivers/message/i2o/Kconfig" source "drivers/macintosh/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index ebee555..637b9f0 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -49,6 +49,7 @@ obj-$(CONFIG_RESET_CONTROLLER)+= reset/ # default. obj-y += tty/ obj-y += char/ +obj-$(CONFIG_FPGA) += fpga/ # gpu/ comes after char for AGP vs DRM startup obj-y += gpu/ diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig new file mode 100644 index 000..e775b17 --- /dev/null +++ b/drivers/fpga/Kconfig @@ -0,0 +1,21 @@ +# +# FPGA framework configuration +# + +menu "FPGA devices" + +config FPGA + tristate "FPGA Framework" + help + Say Y here if you want support for configuring FPGAs from the + kernel. The FPGA framework adds a FPGA manager class and FPGA + manager drivers. + +config FPGA_MGR_SYSFS + bool "FPGA Manager SysFS Interface" + depends on FPGA + depends on SYSFS + help + FPGA Manager SysFS interface. + +endmenu diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile new file mode 100644 index 000..c8a676f --- /dev/null +++ b/drivers/fpga/Makefile @@ -0,0 +1,10 @@ +# +# Makefile for the fpga framework and fpga manager drivers. +# + +fpga-mgr-core-y += fpga-mgr.o + +# Core FPGA Manager Framework +obj-$(CONFIG_FPGA) += fpga-mgr-core.o + +# FPGA Manager Drivers diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c new file mode 100644 index 000..0c7236a --- /dev/null +++ b/drivers/fpga/fpga-mgr.c @@ -0,0 +1,528 @@ +/* + * FPGA Manager Core + * + * Copyright (C) 2013-2014 Altera Corporation + * + * With code from the mailing list: + * Copyright (C) 2013 Xilinx, Inc. + * + * 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. + * + * You should have received a
[PATCH v2 0/3] FPGA Framework with DT and sysfs support
From: Alan Tull Followup to "Yet another stab at a fpga framework" (https://lkml.org/lkml/2014/8/1/517) One of the problems with writing this framework has been the wide variety of use cases. My perspective has mostly been for a fpga bolted to a SoC. Having said that, I really hope this can be useful for as many uses as possible, while still being integrated into the kernel in a way that is Linux-like. Three basic methods of programming a FPGA are supported: * Load firmware using sysfs (see patch 0002 header for example) * Load firmware using Device Tree overlay (see patch 0003) * The core fpga-mgr.c exports enough functions for any driver to use to get the FPGA programmed. If someone needs another interface, the core functions should give enough functionality to make that possible. If the fpga is programmed using firmware, resume is supported. Big looming problem in firmware class for us here is that FPGA image files can easily be 10's to 100's of megabytes. If we have FPGA's that are chained, the image file for several FPGA's is concatenated. So then you can multiply that. High level changes from previous version: * I went ahead and put the sysfs interface into the core although I think it could just as well be separate. * Rework the state/status stuff to stop the programming steps. In the event of error, the state machine is left at a state with '_ERR' in its name. state is available in sysfs, including these error states. * Added ability to reset the FPGA from sysfs. If people like this, let me know. If not it may not be needed as that should happen in the normal programming steps. bus.c adds support for programming from Device Tree overlays. That code was tested from Pantelis' branch; the rest of this was tested on for-next. Alan Alan Tull (3): fpga manager: add sysfs interface document fpga manager: framework core fpga manager: bus driver Documentation/ABI/testing/sysfs-class-fpga-manager | 38 ++ drivers/Kconfig|2 + drivers/Makefile |1 + drivers/fpga/Kconfig | 28 + drivers/fpga/Makefile | 11 + drivers/fpga/bus.c | 124 + drivers/fpga/fpga-mgr.c| 551 include/linux/fpga-mgr.h | 117 + 8 files changed, 872 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-manager create mode 100644 drivers/fpga/Kconfig create mode 100644 drivers/fpga/Makefile create mode 100644 drivers/fpga/bus.c create mode 100644 drivers/fpga/fpga-mgr.c create mode 100644 include/linux/fpga-mgr.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] fpga manager: bus driver
From: Alan Tull
Support programming the fpga from device tree overlays.
This patch adds one exported function to the core
(fpga-mgr.c): of_fpga_mgr_dev_lookup
Get pointer to fpga manager struct given a phandle.
This code is dependent on Pantelis Antoniou's current work
on Device Tree overlays, a method of dynamically altering
the kernel's live Device Tree. The rest of the patchset was
tested with recent for-next, but this 'bus driver' patch was
tested with Pantelis's and Grant Likely's stuff that is in git
(his git repo https://github.com/pantoniou/linux-beagle-track-mainline
v3.17-rc2-115-gbc778b8 == dt-ng/bbb) plus some dtc fixups
for compiling overlays.
Here's a simple example. Start with:
* the altera-gpio driver built in to the kernel but not in the
device tree.
* raw fpga image at /lib/firmware/soc_system.rbf
* Load appropriate device tree overlay in configfs by doing
$ mkdir /config/device-tree/overlays/1
$ echo socfpga_overlay.dtbo > /config/device-tree/overlays/1/path
* This results in the FPGA getting programmed and the altera
gpio driver getting probed.
* To remove/clear FPGA image by putting the FPGA in reset,
remove device tree overlay by doing:
$ rmdir /config/device-tree/overlays/1
Device tree overlay looks like this:
/dts-v1/;
/plugin/;
/ {
fragment@0 {
target-path="/soc";
__overlay__ {
#address-cells = <1>;
#size-cells = <1>;
bridge@0xff20 {
compatible = "fpga-mgr-bus", "simple-bus";
reg = <0xff20 0x20>;
clocks = <0x2 0x2>;
clock-names = "h2f_lw_axi_clock",
"f2h_sdram0_clock";
#address-cells = <0x2>;
#size-cells = <0x1>;
ranges = <0x1 0x10040 0xff210040 0x20>;
fpgamgr = <&hps_0_fpgamgr>;
fpga-firmware = "soc_system.rbf";
gpio@0x100010040 {
compatible = "altr,pio-14.0",
"altr,pio-1.0";
reg = <0x1 0x10040 0x20>;
clocks = <0x2>;
altr,gpio-bank-width = <0x4>;
resetvalue = <0x0>;
#gpio-cells = <0x2>;
gpio-controller;
linux,phandle = <0x2d>;
};
};
};
};
};
Signed-off-by: Alan Tull
v2: simplify of_fpga_mgr_dev_lookup to return NULL on failure
move suspend/resume to fpga-mgr.c core
support 'rmdir' to remove overlay
---
drivers/fpga/Kconfig |7 +++
drivers/fpga/Makefile|1 +
drivers/fpga/bus.c | 124 ++
drivers/fpga/fpga-mgr.c | 23 +
include/linux/fpga-mgr.h |2 +
5 files changed, 157 insertions(+)
create mode 100644 drivers/fpga/bus.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index e775b17..2bd6c83 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -18,4 +18,11 @@ config FPGA_MGR_SYSFS
help
FPGA Manager SysFS interface.
+config FPGA_MGR_BUS
+ bool "FPGA Manager Bus"
+ depends on FPGA
+ help
+ FPGA Manager Bus interface. Allows loading FPGA images
+ from Device Tree or from other drivers.
+
endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index c8a676f..e39911f 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,5 +6,6 @@ fpga-mgr-core-y += fpga-mgr.o
# Core FPGA Manager Framework
obj-$(CONFIG_FPGA) += fpga-mgr-core.o
+obj-$(CONFIG_FPGA_MGR_BUS) += bus.o
# FPGA Manager Drivers
diff --git a/drivers/fpga/bus.c b/drivers/fpga/bus.c
new file mode 100644
index 000..999346e
--- /dev/null
+++ b/drivers/fpga/bus.c
@@ -0,0 +1,124 @@
+/*
+ * FPGA Manager Bus Driver
+ *
+ * Copyright (C) 2013-2014 Altera Corporation
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see
[PATCH v2 1/3] fpga manager: add sysfs interface document
From: Alan Tull Add documentation for new fpga manager sysfs interface. Signed-off-by: Alan Tull --- Documentation/ABI/testing/sysfs-class-fpga-manager | 38 1 file changed, 38 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-manager diff --git a/Documentation/ABI/testing/sysfs-class-fpga-manager b/Documentation/ABI/testing/sysfs-class-fpga-manager new file mode 100644 index 000..eb600f2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-fpga-manager @@ -0,0 +1,38 @@ +What: /sys/class/fpga_manager//name +Date: October 2014 +KernelVersion: 3.18 +Contact: Alan Tull +Description: Name of low level driver. + +What: /sys/class/fpga_manager//firmware +Date: October 2014 +KernelVersion: 3.18 +Contact: Alan Tull +Description: Name of the FPGA image file to load using firmware class. + +What: /sys/class/fpga_manager//reset +Date: October 2014 +KernelVersion: 3.18 +Contact: Alan Tull +Description: Write 1 to reset the FPGA + +What: /sys/class/fpga_manager//state +Date: October 2014 +KernelVersion: 3.18 +Contact: Alan Tull +Description: Read state of fpga framework state machine as a string. + Valid states may vary by manufacturer; superset is: + * unknown = can't determine state + * power_off = FPGA power is off + * power_up = FPGA reports power is up + * reset = FPGA held in reset state + * firmware_request = firmware class request in progress + * firmware_request_err = firmware request failed + * write_init= FPGA being prepared for programming + * write_init_err= Error while preparing FPGA for + programming + * write = FPGA ready to receive image data + * write_err = Error while programming + * write_complete= Doing post programming steps + * write_complete_err= Error while doing post programming + * operating = FPGA is programmed and operating -- 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 v2 2/2] fs: proc: Include cma info in proc/meminfo
On Wed, 22 Oct 2014 19:36:35 +0530 Pintu Kumar wrote: > This patch include CMA info (CMATotal, CMAFree) in /proc/meminfo. > Currently, in a CMA enabled system, if somebody wants to know the > total CMA size declared, there is no way to tell, other than the dmesg > or /var/log/messages logs. > With this patch we are showing the CMA info as part of meminfo, so that > it can be determined at any point of time. > This will be populated only when CMA is enabled. Fair enough. We should be pretty careful about what we put in meminfo - it's the top-level, most-important procfs file and I expect that quite a lot of userspace reads it with some frequency. We don't want to clutter it up. /proc/vmstat is a suitable place for the less important info which is more kernel developer oriented. But CMATotal and CMAFree do pass the "should be in meminfo" test, IMO. -- 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: Translating mmap2 ids into socket info?
On Wed, Oct 22, 2014 at 02:09:35PM -0400, Joe Mario wrote: > >Yes, kernel memory is directly addresses, you basically have a static > >address->node mapping, it never changes. > > For kernel addresses, is there a reason not to have it available in perf, > especially when that knowledge is important to understanding a numa-related > slowdown? Dunno why that isn't exposed in sysfs. > In our case, when we booted with one configuration, AIM ran fine. When we > booted another way, AIM's performance dropped 50%. It was all due to the > dentry > lock being located on a different (now remote) numa node. > > We used your dmesg approach to track down the home node in an attempt to > understand > what was different between the two boots. But the problem would have been > obvious > if perf simply listed the home node info. Or if you'd used more counters that track the node interconnect traffic ;-) There are a few simple ones that count local/remote type things (offcore), but using the uncore counters you can track way more. -- 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 5/7] sched: cfs: cpu frequency scaling arch functions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/22/2014 02:07 AM, Mike Turquette wrote: > arch_eval_cpu_freq and arch_scale_cpu_freq are added to allow the > scheduler to evaluate if cpu frequency should change and to invoke > that change from a safe context. > > They are weakly defined arch functions that do nothing by default. > A CPUfreq governor could use these functions to implement a > frequency scaling policy based on updates to per-task statistics or > updates to per-cpu utilization. > > As discussed at Linux Plumbers Conference 2014, the goal will be > to focus on a single cpu frequency scaling policy that works for > everyone. That may mean that the weak arch functions definitions > can be removed entirely and a single policy implements that logic > for all architectures. On virtual machines, we probably want to use both frequency and steal time to calculate the factor. - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUSA5XAAoJEM553pKExN6DeRYH/jeXImjO2/WZFp82Yv6ukMxI r8/kzrLMA+NS1XXCWYIcOiBqReEabkZZmypt21Tdnpkvi4GbZPpG0PEApSvOfqWE w71J87cpMGV/e4uLcBDcvgHJX8RBQLO/ZqDcMm+zcSoeJ3G3NMK2YlZp3Uf8xqcB tE2VGW7o2yEqNJL1fqYb++3upQmc10vIFqxVIJfP+TqZRyaVP+5kBqOMDTWb5qCV qZjBKe1jDX5sLLGfY0ddAeuUH1iEJBIUMCcr027ezcqRp4YoqIrHRInHmNxEs5Az 9PN8N0yGgqhvkcCfXG7He+tQBHECOnjyQlrM/2K8Cw11RziwDkC/yYIp3DPgjxc= =f/8V -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] pinctrl: add driver for Amlogic Meson SoCs
On Tue, Oct 21, 2014 at 03:39:25PM +0200, Linus Walleij wrote:
> On Tue, Oct 7, 2014 at 11:32 PM, Beniamino Galvani
> wrote:
>
> Sorry for a quick and brief review, but should be enough for you to proceed
> to iterate the patch.
>
> > This is a driver for the pinmux and GPIO controller available in
> > Amlogic Meson SoCs. At the moment it only supports Meson8 devices,
> > however other SoC families like Meson6 and Meson8b (the Cortex-A5
> > variant) appears to be similar, with just different sets of banks and
> > registers.
> >
> > GPIO interrupts are not supported at the moment due to lack of
> > documentation.
> >
> > Signed-off-by: Beniamino Galvani
>
> > arch/arm/mach-meson/Kconfig| 3 +
>
> Please don't mix up driver submission with platform enablement.
> Put this Kconfig fragment in a separate patch.
Ok, will do.
>
> > +++ b/drivers/pinctrl/meson/pinctrl-meson.c
> (...)
>
> > +static void meson_domain_set_bit(struct meson_domain *domain,
> > +void __iomem *addr, unsigned int bit,
> > +unsigned int value)
> > +{
> > + unsigned long flags;
> > + unsigned int data;
> > +
> > + spin_lock_irqsave(&domain->lock, flags);
> > + data = readl(addr);
> > +
> > + if (value)
> > + data |= BIT(bit);
> > + else
> > + data &= ~BIT(bit);
> > +
> > + writel(data, addr);
> > + spin_unlock_irqrestore(&domain->lock, flags);
> > +}
>
> Looks like you are re-implementing mmio regmap. Take a look at
> devm_regmap_init_mmio() from
I missed that, thanks.
> > +static int meson_get_pin_reg_and_bit(struct meson_domain *domain,
> > +unsigned pin, int reg_type,
> > +unsigned int *reg_num, unsigned int
> > *bit)
> > +{
> > + struct meson_bank *bank;
> > + int i, found = 0;
>
> bool found;
>
> > +
> > + for (i = 0; i < domain->data->num_banks; i++) {
> > + bank = &domain->data->banks[i];
> > + if (pin >= bank->first && pin <= bank->last) {
> > + found = 1;
> > + break;
> > + }
> > + }
> > +
> > + if (!found)
> > + return 1;
>
> Can't you return a negative errorcode like everyone else?
Sure.
>
> > +
> > + *reg_num = bank->regs[reg_type].reg;
> > + *bit = bank->regs[reg_type].bit + pin - bank->first;
> > +
> > + return 0;
> > +}
>
> This function is weird and could use some kerneldoc explanation
> to what it does I think.
Ok.
>
> > +static int meson_pmx_request_gpio(struct pinctrl_dev *pcdev,
> > + struct pinctrl_gpio_range *range,
> > + unsigned offset)
> > +{
> > + struct meson_pinctrl *pc = pinctrl_dev_get_drvdata(pcdev);
> > +
> > + meson_pmx_disable_other_groups(pc, offset, -1);
>
> Passing the argument -1 is usually a bit ambiguous.
>
> > +
> > + return 0;
> > +}
>
> > +static inline struct meson_domain *to_meson_domain(struct gpio_chip *chip)
> > +{
> > + return container_of(chip, struct meson_domain, chip);
> > +}
>
> I have a very vague idea what a "meson domain" is, can this be explained
> in some good place? Like in the struct meson_domain with
> kerneldoc...
Yes, below there is an explanation.
>
> > +static int meson_gpio_get(struct gpio_chip *chip, unsigned gpio)
> > +{
> > + struct meson_domain *domain = to_meson_domain(chip);
> > + void __iomem *addr;
> > + unsigned int bit;
> > +
> > + if (meson_gpio_calc_reg_and_bit(domain, chip->base + gpio, REG_IN,
> > + &addr, &bit))
> > + return 0;
> > +
> > + return (readl(addr) >> bit) & 1;
>
> Do it like this:
>
> return !!(readl(addr) & BIT(bit));
>
> > +static int meson_gpio_of_xlate(struct gpio_chip *chip,
> > + const struct of_phandle_args *gpiospec,
> > + u32 *flags)
> > +{
> > + unsigned gpio = gpiospec->args[0];
> > +
> > + if (gpio < chip->base || gpio >= chip->base + chip->ngpio)
> > + return -EINVAL;
> > +
> > + if (flags)
> > + *flags = gpiospec->args[1];
> > +
> > + return gpio - chip->base;
> > +}
>
> Why is this necessary? We want to get rid of all use of
> chip->base so introducing new users is not nice.
The driver instantiates one pinctrl device with 136 pins and two
gpio_chips, one with 120 gpios and the other with 16 (for more
details, see below). The macros for pins in the header file use a
single range from 0 to 135 that matches the order of pins in the
pinctrl device:
/* First gpio-chip */
#define GPIOX_0 0
[...]
#define BOOT_18 119
/* Second gpio-chip */
#define GPIOAO_0120
[...]
#define G
Re: introduce probe_slab_address?
From: Oleg Nesterov Date: Wed, 22 Oct 2014 21:42:28 +0200 > Now the question: is this LOAD is safe in case when this (freed) page > already has another mapping? This is black magic to me, I do not know. > And Peter has some concerns. It is immatieral, because you can read garbage and it's "don't care" in this context. And later if it is used again at this virtual address, it will be initialized with stores at that virtual address first. So no problem. > And, say, copy_from_user_page() on sparc does > > flush_cache_page(); > memcpy(); > flush_ptrace_access(); In this case, as I tried to explain, it matters because the physical address is being accessed from two virtual address at the same time "for the same usage". That's what distinguishes this from the SLAB and RCU cases you cite. Illegal aliases only matter within a specific usage of a piece of memory. So if a page is mapped into userspace, and we touch the kernel side PAGE_OFFSET alias mapping of it, we can have problems. And that is what is happening in the ptrace case above. But if we are using the page later in SLAB, the previous userspace mapping will not cause problems wrt. aliasing. It cannot, because once SLAB gets the page it will initialize it at the new virtual address. -- 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] drivers: net: xgene: Rewrite loop in xgene_enet_ecc_init()
From: Geert Uytterhoeven
Date: Wed, 22 Oct 2014 21:50:06 +0200
> On Wed, Oct 22, 2014 at 9:34 PM, David Miller wrote:
>> From: Geert Uytterhoeven
>> Date: Wed, 22 Oct 2014 09:39:41 +0200
>>
>>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function
>>> ‘xgene_enet_ecc_init’:
>>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: ‘data’ may
>>> be used uninitialized in this function
>>>
>>> Depending on the arbitrary value on the stack, the loop may terminate
>>> too early, and cause a bogus -ENODEV failure.
>>>
>>> Signed-off-by: Geert Uytterhoeven
>>> ---
>>> v2: Rewrite the loop instead of pre-initializing data.
>>
>> I hate to be a pest, but like the other patch of your's I think
>> a do { } while() works best here because the intent is clearly
>> to run the loop at least once, right?
>
> I wanted to avoid checking for "data != ~0U" twice: once to abort the loop,
> and once to check if a timeout happened.
Hmmm:
do {
usleep_range(...);
data = ...();
if (data == ~0)
return 0;
} while (++i < 10);
netdev_err(...);
return -ENODEV;
Why would you have to check data twice?
N§²ζμrΈyϊθΨb²X¬ΆΗ§vΨ^)ήΊ{.nΗ+·₯{±κηzX§Ά‘ά¨}©²Ζ
zΪ&j:+v¨Ύ«κηzZ+Κ+zf£’·h§~Ϋi�ϋΰzΉ �w₯’Έ?¨θΪ&’)ί’fω^jΗ«y§m
α@A«aΆΪ�
0Άμh�εi
Re: [PATCH] mm, hugetlb: correct bit shift in hstate_sizelog
On Wed, 22 Oct 2014 14:50:22 -0400 Sasha Levin wrote:
> On 10/22/2014 02:44 PM, Andrew Morton wrote:
> > On Wed, 22 Oct 2014 09:42:46 +0400 Andrey Ryabinin
> > wrote:
> >
> >> > On 10/21/2014 10:15 PM, Sasha Levin wrote:
> >>> > > hstate_sizelog() would shift left an int rather than long, triggering
> >>> > > undefined behaviour and passing an incorrect value when the requested
> >>> > > page size was more than 4GB, thus breaking >4GB pages.
> >> >
> >>> > >
> >>> > > Signed-off-by: Sasha Levin
> >>> > > ---
> >>> > > include/linux/hugetlb.h |3 ++-
> >>> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> >>> > >
> >>> > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> >>> > > index 65e12a2..57e0dfd 100644
> >>> > > --- a/include/linux/hugetlb.h
> >>> > > +++ b/include/linux/hugetlb.h
> >>> > > @@ -312,7 +312,8 @@ static inline struct hstate *hstate_sizelog(int
> >>> > > page_size_log)
> >>> > > {
> >>> > > if (!page_size_log)
> >>> > > return &default_hstate;
> >>> > > - return size_to_hstate(1 << page_size_log);
> >>> > > +
> >>> > > + return size_to_hstate(1UL << page_size_log);
> >> >
> >> > That still could be undefined on 32-bits. Either use 1ULL or reduce
> >> > SHM_HUGE_MASK on 32bits.
> >> >
> > But
> >
> > struct hstate *size_to_hstate(unsigned long size)
>
> True, but "(1 << page_size_log)" produces an integer rather than long because
> "1"
> is an int and not long.
My point is that there's no point in using 1ULL because
size_to_hstate() will truncate it anyway.
--
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: [PATCHv5 man-pages 3/3] execveat.2: initial man page for execveat(2)
On Wed, Oct 22, 2014 at 6:55 PM, Eric W. Biederman wrote: > David Drysdale writes: >> +.TH EXECVEAT 2 2014-04-02 "Linux" "Linux Programmer's Manual" >> +.SH NAME >> +execveat \- execute program relative to a directory file descriptor >> +.SH SYNOPSIS >> +.B #include >> +.sp >> +.BI "int execve(int " fd ", const char *" pathname "," > ^^ That needs to be execveat Ah yes, so it does -- thanks for spotting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] PM / clock_ops: Add pm_clk_add_clk()
On Wed, Oct 22, 2014 at 10:02:41PM +0300, Grygorii Strashko wrote:
> On 10/22/2014 08:38 PM, Dmitry Torokhov wrote:
> >On Mon, Oct 20, 2014 at 03:56:02PM +0300, Grygorii Strashko wrote:
> >>From: Geert Uytterhoeven
> >>
> >>The existing pm_clk_add() allows to pass a clock by con_id. However,
> >>when referring to a specific clock from DT, no con_id is available.
> >>
> >>Add pm_clk_add_clk(), which allows to specify the struct clk * directly.
> >>
> >>Reviewed-by: Kevin Hilman
> >>Signed-off-by: Geert Uytterhoeven
> >>Signed-off-by: Grygorii Strashko
> >>---
> >>
> >> Pay attantion pls, that there is another series of patches
> >> which have been posted already and which depends from this patch
> >>"[PATCH v4 0/3] ARM: rk3288 : Add PM Domain support"
> >>https://lkml.org/lkml/2014/10/20/105
> >>
> >> drivers/base/power/clock_ops.c | 41
> >> +++--
> >> include/linux/pm_clock.h | 8
> >> 2 files changed, 39 insertions(+), 10 deletions(-)
> >>
> >>diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
> >>index 7836930..f14b767 100644
> >>--- a/drivers/base/power/clock_ops.c
> >>+++ b/drivers/base/power/clock_ops.c
> >>@@ -53,7 +53,8 @@ static inline int __pm_clk_enable(struct device *dev,
> >>struct clk *clk)
> >> */
> >> static void pm_clk_acquire(struct device *dev, struct pm_clock_entry *ce)
> >> {
> >>- ce->clk = clk_get(dev, ce->con_id);
> >>+ if (!ce->clk)
> >>+ ce->clk = clk_get(dev, ce->con_id);
> >>if (IS_ERR(ce->clk)) {
> >>ce->status = PCE_STATUS_ERROR;
> >>} else {
> >>@@ -63,15 +64,8 @@ static void pm_clk_acquire(struct device *dev, struct
> >>pm_clock_entry *ce)
> >>}
> >> }
> >>
> >>-/**
> >>- * pm_clk_add - Start using a device clock for power management.
> >>- * @dev: Device whose clock is going to be used for power management.
> >>- * @con_id: Connection ID of the clock.
> >>- *
> >>- * Add the clock represented by @con_id to the list of clocks used for
> >>- * the power management of @dev.
> >>- */
> >>-int pm_clk_add(struct device *dev, const char *con_id)
> >>+static int __pm_clk_add(struct device *dev, const char *con_id,
> >>+ struct clk *clk)
> >> {
> >>struct pm_subsys_data *psd = dev_to_psd(dev);
> >>struct pm_clock_entry *ce;
> >>@@ -93,6 +87,8 @@ int pm_clk_add(struct device *dev, const char *con_id)
> >>kfree(ce);
> >>return -ENOMEM;
> >>}
> >>+ } else {
> >>+ ce->clk = clk;
> >>}
> >>
> >>pm_clk_acquire(dev, ce);
> >>@@ -104,6 +100,31 @@ int pm_clk_add(struct device *dev, const char *con_id)
> >> }
> >>
> >> /**
> >>+ * pm_clk_add - Start using a device clock for power management.
> >>+ * @dev: Device whose clock is going to be used for power management.
> >>+ * @con_id: Connection ID of the clock.
> >>+ *
> >>+ * Add the clock represented by @con_id to the list of clocks used for
> >>+ * the power management of @dev.
> >>+ */
> >>+int pm_clk_add(struct device *dev, const char *con_id)
> >>+{
> >>+ return __pm_clk_add(dev, con_id, NULL);
> >
> >Bikeshedding: why do we need __pm_clk_add() and not simply have
> >"canonical" pm_clk_add_clk() and then do:
> >
> >int pm_clk_add(struct device *dev, const char *con_id)
> >{
> > struct clk *clk;
> >
> > clk = clk_get(dev, con_id);
> > ...
> > return pm_clk_add_clk(dev, clk);
> >}
>
> Hm. I did fast look at code and:
> 1) agree - there is a lot of thing which can be optimized ;)
> 2) in my strong opinion, this patch is the fastest and simplest
> way to introduce new API (take a look on pm_clock_entry->con_id
> management code) and It is exactly what we need as of now.
Yeah, I guess. We are lucky we do not crash when we are tryign to print
NULL strings (see pm_clk_acquire).
BTW, what is the point of doing pm_clk_add(dev, NULL)? We add clock
entry with status PCE_STATUS_ERROR and then have to handle it
everywhere? Can we just return -EINVAL if someone triies to pass NULL
ass con_id?
Thanks.
--
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 4/4] fs: Remove i_devices list head
Noone uses i_devices anymore. Remove it (thus saving two pointers in
every inode).
Signed-off-by: Jan Kara
---
fs/inode.c | 1 -
include/linux/fs.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 26753ba7b6d6..cb7acd45dce5 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -366,7 +366,6 @@ void inode_init_once(struct inode *inode)
{
memset(inode, 0, sizeof(*inode));
INIT_HLIST_NODE(&inode->i_hash);
- INIT_LIST_HEAD(&inode->i_devices);
INIT_LIST_HEAD(&inode->i_wb_list);
INIT_LIST_HEAD(&inode->i_lru);
address_space_init_once(&inode->i_data);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index d7fd7959a933..8c4f5678e75e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -595,7 +595,6 @@ struct inode {
#ifdef CONFIG_QUOTA
struct dquot*i_dquot[MAXQUOTAS];
#endif
- struct list_headi_devices;
union {
struct pipe_inode_info *i_pipe;
struct block_device *i_bdev;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4 v2] fs: Remove i_devices from struct inode
Hello, this patch set removes use of i_devices from block and character device code and thus we can remove the list head from struct inode thus saving two pointers in it. Since v1 I have split the patches and properly handled character devices (I broke them last time as Christoph pointed out). Honza -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] chardev: Don't use i_devices inode field
Now that character device can be freed only after all inodes referencing
it through i_cdev are gone, we can remove all the tracking of inodes
pointing to a character device.
Signed-off-by: Jan Kara
---
fs/char_dev.c| 22 +-
include/linux/cdev.h | 1 -
2 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index 21c210dbdba1..08a1404f590b 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -390,7 +390,6 @@ static int chrdev_open(struct inode *inode, struct file
*filp)
if (!p) {
/* Use reference from kobj_lookup for i_cdev ref */
inode->i_cdev = p = new;
- list_add(&inode->i_devices, &p->list);
new = NULL;
}
}
@@ -425,7 +424,6 @@ void cd_forget(struct inode *inode)
struct cdev *cdev;
spin_lock(&cdev_lock);
- list_del_init(&inode->i_devices);
cdev = inode->i_cdev;
inode->i_cdev = NULL;
spin_unlock(&cdev_lock);
@@ -433,18 +431,6 @@ void cd_forget(struct inode *inode)
cdev_put(cdev);
}
-static void cdev_purge(struct cdev *cdev)
-{
- spin_lock(&cdev_lock);
- while (!list_empty(&cdev->list)) {
- struct inode *inode;
- inode = container_of(cdev->list.next, struct inode, i_devices);
- list_del_init(&inode->i_devices);
- inode->i_cdev = NULL;
- }
- spin_unlock(&cdev_lock);
-}
-
/*
* Dummy default file-operations: the only thing this does
* is contain the open that then fills in the correct operations
@@ -515,10 +501,8 @@ void cdev_del(struct cdev *p)
static void cdev_default_release(struct kobject *kobj)
{
- struct cdev *p = container_of(kobj, struct cdev, kobj);
struct kobject *parent = kobj->parent;
- cdev_purge(p);
kobject_put(parent);
}
@@ -527,7 +511,6 @@ static void cdev_dynamic_release(struct kobject *kobj)
struct cdev *p = container_of(kobj, struct cdev, kobj);
struct kobject *parent = kobj->parent;
- cdev_purge(p);
kfree(p);
kobject_put(parent);
}
@@ -548,10 +531,8 @@ static struct kobj_type ktype_cdev_dynamic = {
struct cdev *cdev_alloc(void)
{
struct cdev *p = kzalloc(sizeof(struct cdev), GFP_KERNEL);
- if (p) {
- INIT_LIST_HEAD(&p->list);
+ if (p)
kobject_init(&p->kobj, &ktype_cdev_dynamic);
- }
return p;
}
@@ -566,7 +547,6 @@ struct cdev *cdev_alloc(void)
void cdev_init(struct cdev *cdev, const struct file_operations *fops)
{
memset(cdev, 0, sizeof *cdev);
- INIT_LIST_HEAD(&cdev->list);
kobject_init(&cdev->kobj, &ktype_cdev_default);
cdev->ops = fops;
}
diff --git a/include/linux/cdev.h b/include/linux/cdev.h
index fb4591977b03..fe00138b5106 100644
--- a/include/linux/cdev.h
+++ b/include/linux/cdev.h
@@ -13,7 +13,6 @@ struct cdev {
struct kobject kobj;
struct module *owner;
const struct file_operations *ops;
- struct list_head list;
dev_t dev;
unsigned int count;
};
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] chardev: Increment cdev reference count when i_cdev references it
Currently i_cdev reference to a character device isn't accounted in the
reference count of the character device. This then requires us to track
all references through a list of all inodes referencing a character
device which is somewhat clumsy and requires list_head in each inode in
the system.
So make i_cdev a reference like any other.
Signed-off-by: Jan Kara
---
fs/char_dev.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index f77f7702fabe..21c210dbdba1 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -388,12 +388,13 @@ static int chrdev_open(struct inode *inode, struct file
*filp)
we dropped the lock. */
p = inode->i_cdev;
if (!p) {
+ /* Use reference from kobj_lookup for i_cdev ref */
inode->i_cdev = p = new;
list_add(&inode->i_devices, &p->list);
new = NULL;
- } else if (!cdev_get(p))
- ret = -ENXIO;
- } else if (!cdev_get(p))
+ }
+ }
+ if (!cdev_get(p))
ret = -ENXIO;
spin_unlock(&cdev_lock);
cdev_put(new);
@@ -421,10 +422,15 @@ static int chrdev_open(struct inode *inode, struct file
*filp)
void cd_forget(struct inode *inode)
{
+ struct cdev *cdev;
+
spin_lock(&cdev_lock);
list_del_init(&inode->i_devices);
+ cdev = inode->i_cdev;
inode->i_cdev = NULL;
spin_unlock(&cdev_lock);
+ if (cdev)
+ cdev_put(cdev);
}
static void cdev_purge(struct cdev *cdev)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] blockdev: Don't use i_devices inode field
Block devices use i_devices inode field to track all inodes that
reference a particular block device (through i_bdev field) so that this
reference can be removed when block device inode is being evicted from
memory. However we get a reference to the block device (in fact an inode
holding the block device structure) when setting up i_bdev in
bd_acquire() and we drop the reference only in bd_forget() when clearing
i_bdev. Thus inode holding block device structure can be evicted only
after all inodes referencing it are evicted and the whole excercise with
i_devices is pointless. Remove the i_devices handling.
Signed-off-by: Jan Kara
---
fs/block_dev.c | 17 +++--
include/linux/fs.h | 1 -
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index cc9d4114cda0..493cd69df9a6 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -458,7 +458,6 @@ static void init_once(void *foo)
memset(bdev, 0, sizeof(*bdev));
mutex_init(&bdev->bd_mutex);
- INIT_LIST_HEAD(&bdev->bd_inodes);
INIT_LIST_HEAD(&bdev->bd_list);
#ifdef CONFIG_SYSFS
INIT_LIST_HEAD(&bdev->bd_holder_disks);
@@ -468,24 +467,14 @@ static void init_once(void *foo)
mutex_init(&bdev->bd_fsfreeze_mutex);
}
-static inline void __bd_forget(struct inode *inode)
-{
- list_del_init(&inode->i_devices);
- inode->i_bdev = NULL;
- inode->i_mapping = &inode->i_data;
-}
-
static void bdev_evict_inode(struct inode *inode)
{
struct block_device *bdev = &BDEV_I(inode)->bdev;
- struct list_head *p;
+
truncate_inode_pages_final(&inode->i_data);
invalidate_inode_buffers(inode); /* is it needed here? */
clear_inode(inode);
spin_lock(&bdev_lock);
- while ( (p = bdev->bd_inodes.next) != &bdev->bd_inodes ) {
- __bd_forget(list_entry(p, struct inode, i_devices));
- }
list_del_init(&bdev->bd_list);
spin_unlock(&bdev_lock);
}
@@ -645,7 +634,6 @@ static struct block_device *bd_acquire(struct inode *inode)
ihold(bdev->bd_inode);
inode->i_bdev = bdev;
inode->i_mapping = bdev->bd_inode->i_mapping;
- list_add(&inode->i_devices, &bdev->bd_inodes);
}
spin_unlock(&bdev_lock);
}
@@ -666,7 +654,8 @@ void bd_forget(struct inode *inode)
spin_lock(&bdev_lock);
if (!sb_is_blkdev_sb(inode->i_sb))
bdev = inode->i_bdev;
- __bd_forget(inode);
+ inode->i_bdev = NULL;
+ inode->i_mapping = &inode->i_data;
spin_unlock(&bdev_lock);
if (bdev)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index a957d4366c24..d7fd7959a933 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -413,7 +413,6 @@ struct block_device {
struct inode * bd_inode; /* will die */
struct super_block *bd_super;
struct mutexbd_mutex; /* open/close mutex */
- struct list_headbd_inodes;
void * bd_claiming;
void * bd_holder;
int bd_holders;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/53] dmaengine: Create a generic dma_slave_caps callback
Hi Maxime,
On Thursday 16 October 2014 18:24:53 Maxime Ripard wrote:
> On Thu, Oct 16, 2014 at 07:15:40PM +0300, Laurent Pinchart wrote:
> > On Thursday 16 October 2014 12:17:05 Maxime Ripard wrote:
> > > dma_slave_caps is very important to the generic layers that might
> > > interact with dmaengine, such as ASoC. Unfortunately, it has been added
> > > as yet another dma_device callback, and most of the existing drivers
> > > haven't implemented it, reducing its reliability.
> > >
> > > Introduce a generic behaviour and a flag to trigger it. In case this
> > > flag hasn't been set, fall back to the old mechanism.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > >
> > > include/linux/dmaengine.h | 25 +
> > > 1 file changed, 21 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > > index 4d0294ec3567..85afd71df2e7 100644
> > > --- a/include/linux/dmaengine.h
> > > +++ b/include/linux/dmaengine.h
> > > @@ -643,6 +643,8 @@ struct dma_device {
> > >
> > > int dev_id;
> > > struct device *dev;
> > >
> > > + bool generic_slave_caps;
> > > +
> > >
> > > int (*device_alloc_chan_resources)(struct dma_chan *chan);
> > > void (*device_free_chan_resources)(struct dma_chan *chan);
> > >
> > > @@ -772,17 +774,32 @@ static inline struct dma_async_tx_descriptor
> > > *dmaengine_prep_interleaved_dma(
> > >
> > > static inline int dma_get_slave_caps(struct dma_chan *chan, struct
> > >
> > > dma_slave_caps *caps) {
> >
> > This is getting too big for an inline function, it should be moved to
> > drivers/dma/dmaengine.c.
>
> I agree, but I wanted to do that in another patch set. This one is
> just getting bigger and bigger, and this is not really the point of
> this serie.
If both get merged in the same kernel version I would be fine with this.
> > > + struct dma_device *device;
> > > +
> > >
> > > if (!chan || !caps)
> > > return -EINVAL;
> > >
> > > + device = chan->device;
> > > +
> > >
> > > /* check if the channel supports slave transactions */
> > >
> > > - if (!test_bit(DMA_SLAVE, chan->device->cap_mask.bits))
> > > + if (!test_bit(DMA_SLAVE, device->cap_mask.bits))
> > > + return -ENXIO;
> > > +
> > > + if (device->device_slave_caps)
> > > + return device->device_slave_caps(chan, caps);
> > > +
> > > + /*
> > > + * Check whether it reports it uses the generic slave
> > > + * capabilities, if not, that means it doesn't support any
> > > + * kind of slave capabilities reporting.
> > > + */
> > > + if (device->generic_slave_caps)
> > > return -ENXIO;
> >
> > Couldn't we replace that check with if (device->device_control) and get
> > rid of the generic_slave_caps field ? Drivers converted to the new API
> > would then get slave caps support for free.
>
> Not really. Drivers might have converted to the splitted device_control (and
> actually all of them are), while they don't define the values needed to
> implement properly the generic slave caps retrieval (and the vast majority
> of them doesn't).
Indeed, my bad.
How about testing those fields then ? You could consider that the driver wants
the generic slave caps implementation if device->directions is set to a non-
zero value for instance.
--
Regards,
Laurent Pinchart
--
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] Documentation: dmaengine: Add a documentation for the dma controller API
Hi Maxime, On Friday 17 October 2014 13:23:56 Maxime Ripard wrote: > Hi Laurent, > > Just getting back on something... > > On Mon, Oct 06, 2014 at 03:09:48PM +0300, Laurent Pinchart wrote: > > > + * device_prep_dma_* > > > + - These functions are matching the capabilities you registered > > > + previously. > > > + - These functions all take the buffer or the scatterlist relevant > > > + for the transfer being prepared, and should create a hardware > > > + descriptor or a list of descriptors from it > > > + - These functions can be called from an interrupt context > > > + - Any allocation you might do should be using the GFP_NOWAIT > > > + flag, in order not to potentially sleep, but without depleting > > > + the emergency pool either. > > > > You could add "Drivers should try to preallocate the data structures they > > require to prepare a transfer." > > Isn't that obvious? > > I mean, if we're in this function, we're already preparing a > transfer... And I would expect any programmer that followed CS101 to > be able to allocate the memory it needs :) I meant that memory should be pre-allocated earlier (at probe time or channel alloc time for instance) to avoid putting pressure on the nowait memory pool. > The rest of the issues have been fixed, thanks! > Maxime -- Regards, Laurent Pinchart -- 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: introduce probe_slab_address?
On 10/22, David Miller wrote: > > From: Oleg Nesterov > Date: Wed, 22 Oct 2014 21:42:28 +0200 > > > Now the question: is this LOAD is safe in case when this (freed) page > > already has another mapping? This is black magic to me, I do not know. > > And Peter has some concerns. > > It is immatieral, because you can read garbage and it's "don't care" > in this context. > > And later if it is used again at this virtual address, it will be > initialized with stores at that virtual address first. > > So no problem. Great, thanks. > > And, say, copy_from_user_page() on sparc does > > > > flush_cache_page(); > > memcpy(); > > flush_ptrace_access(); > > In this case, as I tried to explain, it matters because the physical > address is being accessed from two virtual address at the same time > "for the same usage". > > That's what distinguishes this from the SLAB and RCU cases you cite. Yes, this was my (vague) understanding, but thanks for another explanation anyway. 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] mm, hugetlb: correct bit shift in hstate_sizelog
2014-10-23 0:13 GMT+04:00 Andrew Morton :
> On Wed, 22 Oct 2014 14:50:22 -0400 Sasha Levin wrote:
>
>> On 10/22/2014 02:44 PM, Andrew Morton wrote:
>> > On Wed, 22 Oct 2014 09:42:46 +0400 Andrey Ryabinin
>> > wrote:
>> >
>> >> > On 10/21/2014 10:15 PM, Sasha Levin wrote:
>> >>> > > hstate_sizelog() would shift left an int rather than long, triggering
>> >>> > > undefined behaviour and passing an incorrect value when the requested
>> >>> > > page size was more than 4GB, thus breaking >4GB pages.
>> >> >
>> >>> > >
>> >>> > > Signed-off-by: Sasha Levin
>> >>> > > ---
>> >>> > > include/linux/hugetlb.h |3 ++-
>> >>> > > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >>> > >
>> >>> > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> >>> > > index 65e12a2..57e0dfd 100644
>> >>> > > --- a/include/linux/hugetlb.h
>> >>> > > +++ b/include/linux/hugetlb.h
>> >>> > > @@ -312,7 +312,8 @@ static inline struct hstate *hstate_sizelog(int
>> >>> > > page_size_log)
>> >>> > > {
>> >>> > > if (!page_size_log)
>> >>> > > return &default_hstate;
>> >>> > > - return size_to_hstate(1 << page_size_log);
>> >>> > > +
>> >>> > > + return size_to_hstate(1UL << page_size_log);
>> >> >
>> >> > That still could be undefined on 32-bits. Either use 1ULL or reduce
>> >> > SHM_HUGE_MASK on 32bits.
>> >> >
>> > But
>> >
>> > struct hstate *size_to_hstate(unsigned long size)
>>
>> True, but "(1 << page_size_log)" produces an integer rather than long
>> because "1"
>> is an int and not long.
>
> My point is that there's no point in using 1ULL because
> size_to_hstate() will truncate it anyway.
>
There is a point to use 1ULL
On 32-bit with size >= 32
(1UL << size) - undefined, so size_to_hstate() will truncate it to
undefined as well. E.g. It definitely won't be zero on x86.
While (1ULL << size) - is defined and size_to_hstate() will truncate it to zero.
--
Best regards,
Andrey Ryabinin
--
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: [PATCHv5 7/7] usb: dwc2: Update Kconfig to support dual-role
On Tue, 2014-10-21 at 15:47 -0500, Dinh Nguyen wrote: > On 10/20/2014 02:42 PM, Paul Bolle wrote: > > (Side note: drivers/usb/dwc2/Kconfig is sourced (in drivers/usb/Kconfig) > > even if USB is _not_ set. But USB_DCW2 still depends on USB. Why is > > that?) > > Because USB is for Host-Side support. DWC2 driver should only get built > for when USB is enabled. I think you're getting USB and USB_SUPPORT > mixed up. No, I don't think I did. Because in drivers/usb/Kconfig we see if USB [...] endif [...] source "drivers/usb/dwc2/Kconfig" [...] > In addition, thanks to your comment, I realized that DWC2 should also be > available to build when USB_GADGET is enabled. A patch has been sent: > > http://marc.info/?l=linux-usb&m=141392377124818&w=2 I haven't checked, but doesn't this mean USB_DWC2 could just depend on USB_SUPPORT? Paul Bolle -- 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/5] sched: idle: cpuidle: Check the latency req before idle
On Mon, 20 Oct 2014, Daniel Lezcano wrote:
> When the pmqos latency requirement is set to zero that means "poll in all the
> cases".
>
> That is correctly implemented on x86 but not on the other archs.
>
> As how is written the code, if the latency request is zero, the governor will
> return zero, so corresponding, for x86, to the poll function, but for the
> others arch the default idle function. For example, on ARM this is wait-for-
> interrupt with a latency of '1', so violating the constraint.
>
> In order to fix that, do the latency requirement check *before* calling the
> cpuidle framework in order to jump to the poll function without entering
> cpuidle. That has several benefits:
>
> 1. It clarifies and unifies the code
> 2. It fixes x86 vs other archs behavior
> 3. Factors out the call to the same function
> 4. Prevent to enter the cpuidle framework with its expensive cost in
> calculation
>
> As the latency_req is needed in all the cases, change the select API to take
> the latency_req as parameter in case it is not equal to zero.
>
> As a positive side effect, it introduces the latency constraint specified
> externally, so one more step to the cpuidle/scheduler integration.
>
> Signed-off-by: Daniel Lezcano
Acked-by: Nicolas Pitre
> ---
> drivers/cpuidle/cpuidle.c | 5 +++--
> drivers/cpuidle/governors/ladder.c | 9 +
> drivers/cpuidle/governors/menu.c | 8 ++--
> include/linux/cpuidle.h| 7 ---
> kernel/sched/idle.c| 18 ++
> 5 files changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index ee9df5e..372c36f 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -158,7 +158,8 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
> struct cpuidle_driver *drv,
> *
> * Returns the index of the idle state.
> */
> -int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
> +int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
> +int latency_req)
> {
> if (off || !initialized)
> return -ENODEV;
> @@ -169,7 +170,7 @@ int cpuidle_select(struct cpuidle_driver *drv, struct
> cpuidle_device *dev)
> if (unlikely(use_deepest_state))
> return cpuidle_find_deepest_state(drv, dev);
>
> - return cpuidle_curr_governor->select(drv, dev);
> + return cpuidle_curr_governor->select(drv, dev, latency_req);
> }
>
> /**
> diff --git a/drivers/cpuidle/governors/ladder.c
> b/drivers/cpuidle/governors/ladder.c
> index 044ee0d..18f0da9 100644
> --- a/drivers/cpuidle/governors/ladder.c
> +++ b/drivers/cpuidle/governors/ladder.c
> @@ -64,18 +64,11 @@ static inline void ladder_do_selection(struct
> ladder_device *ldev,
> * @dev: the CPU
> */
> static int ladder_select_state(struct cpuidle_driver *drv,
> - struct cpuidle_device *dev)
> +struct cpuidle_device *dev, int latency_req)
> {
> struct ladder_device *ldev = &__get_cpu_var(ladder_devices);
> struct ladder_device_state *last_state;
> int last_residency, last_idx = ldev->last_state_idx;
> - int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
> -
> - /* Special case when user has set very strict latency requirement */
> - if (unlikely(latency_req == 0)) {
> - ladder_do_selection(ldev, last_idx, 0);
> - return 0;
> - }
>
> last_state = &ldev->states[last_idx];
>
> diff --git a/drivers/cpuidle/governors/menu.c
> b/drivers/cpuidle/governors/menu.c
> index 34db2fb..96f8fb0 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -287,10 +287,10 @@ again:
> * @drv: cpuidle driver containing state data
> * @dev: the CPU
> */
> -static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device
> *dev)
> +static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device
> *dev,
> +int latency_req)
> {
> struct menu_device *data = &__get_cpu_var(menu_devices);
> - int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
> int i;
> unsigned int interactivity_req;
> unsigned long nr_iowaiters, cpu_load;
> @@ -302,10 +302,6 @@ static int menu_select(struct cpuidle_driver *drv,
> struct cpuidle_device *dev)
>
> data->last_state_idx = CPUIDLE_DRIVER_STATE_START - 1;
>
> - /* Special case when user has set very strict latency requirement */
> - if (unlikely(latency_req == 0))
> - return 0;
> -
> /* determine the expected residency time, round up */
> data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length());
>
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 25e0df6..fb465c1 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -122,7 +122,7 @@ struct
Re: [Ocfs2-devel] [PATCH 2/2] ocfs2: Fix d_splice_alias() return code checking
Am 21.10.2014 um 01:12 schrieb Andrew Morton: > On Sun, 19 Oct 2014 12:39:44 +0200 Richard Weinberger wrote: > >> d_splice_alias() can return a valid dentry, NULL or an ERR_PTR. >> Currently the code checks not for ERR_PTR and my oops in >> ocfs2_dentry_attach_lock(). > > It's unclear what the second sentence is trying to tell us. The patch > fixes an oops? If so, a copy of the trace would be useful, as would an > explanation of why it occurred. If not, I'm all confused. ocfs2_dentry_attach_lock() derefs the dentry pointer. If d_splice_alias() returns ERR_PTR(-EIO) it will oops. Thanks, //richard -- 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] kbuild: Fix output of make kernelrelease
On Wed, 22 Oct 2014 21:44:08 +0200 Michal Marek wrote: > Dne 22.10.2014 v 16:19 Steven Rostedt napsal(a): > > > > Commit 7ff525712acf "kbuild: fake the "Entering directory ..." message > > more simply" changed the output of "make kernelrelease" such that the > > kernel release version was not the last line printed. This broke various > > tools that would find the kernel release with "make kernelrelease | tail > > -1". > > The cleaner and recommended (see recent make help) way is to use make -s: > > $ make O=build -s kernelrelease > 3.18.0-rc1+ Hmm, I see the help index was recently updated to include that. Does this work with older kernels too? That's very important. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] sched: idle: Get the next timer event and pass it the cpuidle framework
On Mon, 20 Oct 2014, Daniel Lezcano wrote: > Following the logic of the previous patch, retrieve from the idle task the > expected timer sleep duration and pass it to the cpuidle framework. > > Take the opportunity to remove the unused headers in the menu.c file. > > This patch does not change the current behavior. > > Signed-off-by: Daniel Lezcano One minor nit below. > @@ -211,6 +212,12 @@ static void cpu_idle_loop(void) > latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY); > > /* > + * The next timer event in us > + */ This 3-line comment is redundant. The code is obvious enough on its own. > + next_timer_event = ktime_to_us( > + tick_nohz_get_sleep_length()); I'd suggest this form for better readability: next_timer_event = ktime_to_us(tick_nohz_get_sleep_length()); Other than that... Acked-by: Nicolas Pitre > + > + /* >* In poll mode we reenable interrupts and spin. >* >* If the latency req is zero, we don't want to > @@ -227,7 +234,8 @@ static void cpu_idle_loop(void) > tick_check_broadcast_expired()) > cpu_idle_poll(); > else > - cpuidle_idle_call(latency_req); > + cpuidle_idle_call(latency_req, > + next_timer_event); > > arch_cpu_idle_exit(); > } > -- > 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: A desktop environment[1] kernel wishlist
On 21.10.2014 15:11, Sergey wrote: Hey everyone, I'm glad we're having some discussion on this, because we have almost exactly the same kernel wishlist internally for elementary OS / Pantheon DE. I believe I can further elaborate on the VFS monitoring part. We need a file monitoring facility that's scalable (unlike inotify) and can provide a decent level of detail (unlike fanotify). In particular, we need to be able to detect file/directory creation, renaming and removal events, as well as close_write event. And, in an ideal world, all of that without requiring root permissions. When I read your wish, I guess adding the capability to watch mounts with inotify would satisfy your needs. Would you agree? Best regards Heinrich Schuchardt This can be almost accomplished by combining output of fanotify with that of a custom LSM module that just reports events to userspace (e.g. rlocate uses such a thing). There are two problems with this: first, it's a hideous hack, and second, it doesn't detect deletions. This is a big deal because without it we're stuck with always presenting the user with the filesystem. If you've seen library-based music players like Rhythmbox or Banshee, you know that they group and sort all your music by artist and album, but not by directory and file name, and that you can efficiently search all that metadata. We're trying to get the same thing into more applications, but the absence of VFS features described above is blocking us. Even after moving all the database management to a single daemon that does all the monitoring and very rarely has to rescan anything, the system either slows to a crawl (inotify) or the database gets out of date quickly (fanotify+LSM). In case I didn't make myself clear, a more detailed writeup on the design can be found here: http://tiny.cc/tearing-up-files Regarding the other items, AFAIK the kernel implements mechanism, not policy, so instead of "zswap selectively enabled by default" we just want "stable reliable zswap". We had to give up on zram previously (in pre-3.10 days) because of kernel regressions leading to panics when zram was enabled. And we don't have the "Power management" part on our list because we haven't really delved in that yet. But our lists are identical in all the other areas, so that's not "just GNOME". PS: I'm not subscribed to LKML either, so please CC me. Cheers! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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: Translating mmap2 ids into socket info?
On Wed, Oct 22, 2014 at 10:02:19PM +0200, Peter Zijlstra wrote: > On Wed, Oct 22, 2014 at 02:09:35PM -0400, Joe Mario wrote: > > >Yes, kernel memory is directly addresses, you basically have a static > > >address->node mapping, it never changes. > > > > For kernel addresses, is there a reason not to have it available in perf, > > especially when that knowledge is important to understanding a numa-related > > slowdown? > > Dunno why that isn't exposed in sysfs. > > > In our case, when we booted with one configuration, AIM ran fine. When we > > booted another way, AIM's performance dropped 50%. It was all due to the > > dentry > > lock being located on a different (now remote) numa node. > > > > We used your dmesg approach to track down the home node in an attempt to > > understand > > what was different between the two boots. But the problem would have been > > obvious > > if perf simply listed the home node info. > > Or if you'd used more counters that track the node interconnect traffic > ;-) There are a few simple ones that count local/remote type things > (offcore), but using the uncore counters you can track way more. Ha! I have been telling myself for a year I would try to learn more about those offcore/uncore counters. Is there documentation for how to access the uncore stuff? Do I have to long hand it with 'perf record -e uncore_qpi_1// foo'? Cheers, Don -- 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] mm: memcontrol: fix missed end-writeback page accounting
On Wed, 22 Oct 2014 14:29:28 -0400 Johannes Weiner wrote:
> 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API") changed page
> migration to uncharge the old page right away. The page is locked,
> unmapped, truncated, and off the LRU, but it could race with writeback
> ending, which then doesn't unaccount the page properly:
>
> test_clear_page_writeback() migration
> acquire pc->mem_cgroup->move_lock
>wait_on_page_writeback()
> TestClearPageWriteback()
>mem_cgroup_migrate()
> clear PCG_USED
> if (PageCgroupUsed(pc))
> decrease memcg pages under writeback
> release pc->mem_cgroup->move_lock
>
> The per-page statistics interface is heavily optimized to avoid a
> function call and a lookup_page_cgroup() in the file unmap fast path,
> which means it doesn't verify whether a page is still charged before
> clearing PageWriteback() and it has to do it in the stat update later.
>
> Rework it so that it looks up the page's memcg once at the beginning
> of the transaction and then uses it throughout. The charge will be
> verified before clearing PageWriteback() and migration can't uncharge
> the page as long as that is still set. The RCU lock will protect the
> memcg past uncharge.
>
> As far as losing the optimization goes, the following test results are
> from a microbenchmark that maps, faults, and unmaps a 4GB sparse file
> three times in a nested fashion, so that there are two negative passes
> that don't account but still go through the new transaction overhead.
> There is no actual difference:
>
> old: 33.195102545 seconds time elapsed ( +- 0.01% )
> new: 33.199231369 seconds time elapsed ( +- 0.03% )
>
> The time spent in page_remove_rmap()'s callees still adds up to the
> same, but the time spent in the function itself seems reduced:
>
> # Children Self CommandShared Object Symbol
> old: 0.12% 0.11% filemapstress [kernel.kallsyms] [k]
> page_remove_rmap
> new: 0.12% 0.08% filemapstress [kernel.kallsyms] [k]
> page_remove_rmap
>
> ...
>
> @@ -2132,26 +2126,32 @@ cleanup:
> * account and taking the move_lock in the slowpath.
> */
>
> -void __mem_cgroup_begin_update_page_stat(struct page *page,
> - bool *locked, unsigned long *flags)
> +struct mem_cgroup *mem_cgroup_begin_page_stat(struct page *page,
> + bool *locked,
> + unsigned long *flags)
It would be useful to document the args here (especially `locked').
Also the new rcu_read_locking protocol is worth a mention: that it
exists, what it does, why it persists as long as it does.
> {
> struct mem_cgroup *memcg;
> struct page_cgroup *pc;
>
> + rcu_read_lock();
> +
> + if (mem_cgroup_disabled())
> + return NULL;
> +
> pc = lookup_page_cgroup(page);
> again:
> memcg = pc->mem_cgroup;
> if (unlikely(!memcg || !PageCgroupUsed(pc)))
> - return;
> + return NULL;
> /*
>* If this memory cgroup is not under account moving, we don't
>* need to take move_lock_mem_cgroup(). Because we already hold
>* rcu_read_lock(), any calls to move_account will be delayed until
>* rcu_read_unlock().
>*/
> - VM_BUG_ON(!rcu_read_lock_held());
> + *locked = false;
> if (atomic_read(&memcg->moving_account) <= 0)
> - return;
> + return memcg;
>
> move_lock_mem_cgroup(memcg, flags);
> if (memcg != pc->mem_cgroup || !PageCgroupUsed(pc)) {
> @@ -2159,36 +2159,26 @@ again:
> goto again;
> }
> *locked = true;
> +
> + return memcg;
> }
>
>
> ...
>
> @@ -1061,9 +1062,10 @@ void page_add_file_rmap(struct page *page)
> */
> void page_remove_rmap(struct page *page)
> {
> + struct mem_cgroup *uninitialized_var(memcg);
> bool anon = PageAnon(page);
> - bool locked;
> unsigned long flags;
> + bool locked;
>
> /*
>* The anon case has no mem_cgroup page_stat to update; but may
> @@ -1071,7 +1073,7 @@ void page_remove_rmap(struct page *page)
>* we hold the lock against page_stat move: so avoid it on anon.
>*/
> if (!anon)
> - mem_cgroup_begin_update_page_stat(page, &locked, &flags);
> + memcg = mem_cgroup_begin_page_stat(page, &locked, &flags);
>
> /* page still mapped by someone else? */
> if (!atomic_add_negative(-1, &page->_mapcount))
> @@ -1096,8 +1098,7 @@ void page_remove_rmap(struct page *page)
> -hpage_nr_pages(page));
> } else {
> __dec_zone_page_state(page, NR_FILE_MAPPED);
> - mem_cgroup_dec_page_stat(page, MEM_CGROUP_STAT_FILE_MAPPED);
> - mem_cgroup_end
Re: unaligned accesses in SLAB etc.
From: David Miller
Date: Mon, 20 Oct 2014 14:57:46 -0400 (EDT)
> Just an update, I have an environment where I can perfectly reproduce
> this. I have a gcc-4.9 SVN built that compiles kernels which crash
> the same way it does for you.
>
> I'll let you know when I make more progress.
Whilst I don't have access to my reproducer machine until tomorrow in
order to test this myself, I wanted to toss this patch your way so you
could get a head start on me.
The issue is not that gcc-4.9 miscompiles anything, the issue is that
we had an existing bug that is exposed by gcc-4.9 simply allocating
registers in a different order.
per_cpu_patch() is the function that matters. I verified this by
pulling that function out of setup_64.c and into it's own separate
foo.c file, and only building that source file with gcc-4.9
I poured over the assembler several times over the course of a day or
so, and I'm pretty sure the generated code is fine. I even extracted
the assembler into a userland test-case and stepped through it for
the code paths that Ultra-III systems trigger.
What happens is that the inner-most registers are corrupted by the
first one of the TLB misses triggered by this code patching. These
TLB misses are serviced by the firmware because we are still using the
firmware's trap table this early on, and if the code path in the
firmware to service that TLB miss is deep enough we get a register
spill.
This is the top-most of the initial kernel stack's call chain, the
per_cpu_patch() function is invoked right from head_64.S.
What we've traditionally done is save away the firmware's stack
pointer, and jump onto that stack when we make firmware calls. But
there is absolutely no reason to do that, and it means that by doing
so we have always risked modifying registers erroneously at that
boundary at the top of the initial kernel stack.
So let's get rid of the CIF stack, and just call into the firwmare
using the normal kernel stack.
diff --git a/arch/sparc/include/asm/oplib_64.h
b/arch/sparc/include/asm/oplib_64.h
index f346824..741f24a 100644
--- a/arch/sparc/include/asm/oplib_64.h
+++ b/arch/sparc/include/asm/oplib_64.h
@@ -62,7 +62,7 @@ struct linux_mem_p1275 {
/* You must call prom_init() before using any of the library services,
* preferably as early as possible. Pass it the romvec pointer.
*/
-void prom_init(void *cif_handler, void *cif_stack);
+void prom_init(void *cif_handler);
/* Boot argument acquisition, returns the boot command line string. */
char *prom_getbootargs(void);
diff --git a/arch/sparc/kernel/head_64.S b/arch/sparc/kernel/head_64.S
index 4fdeb80..b8d67c5 100644
--- a/arch/sparc/kernel/head_64.S
+++ b/arch/sparc/kernel/head_64.S
@@ -672,14 +672,12 @@ tlb_fixup_done:
sethi %hi(init_thread_union), %g6
or %g6, %lo(init_thread_union), %g6
ldx [%g6 + TI_TASK], %g4
- mov %sp, %l6
wr %g0, ASI_P, %asi
mov 1, %g1
sllx%g1, THREAD_SHIFT, %g1
sub %g1, (STACKFRAME_SZ + STACK_BIAS), %g1
add %g6, %g1, %sp
- mov 0, %fp
/* Set per-cpu pointer initially to zero, this makes
* the boot-cpu use the in-kernel-image per-cpu areas
@@ -706,7 +704,6 @@ tlb_fixup_done:
nop
#endif
- mov %l6, %o1! OpenPROM stack
callprom_init
mov%l7, %o0! OpenPROM cif handler
diff --git a/arch/sparc/prom/cif.S b/arch/sparc/prom/cif.S
index 9c86b4b..8050f38 100644
--- a/arch/sparc/prom/cif.S
+++ b/arch/sparc/prom/cif.S
@@ -11,11 +11,10 @@
.text
.globl prom_cif_direct
prom_cif_direct:
+ save%sp, -192, %sp
sethi %hi(p1275buf), %o1
or %o1, %lo(p1275buf), %o1
- ldx [%o1 + 0x0010], %o2 ! prom_cif_stack
- save%o2, -192, %sp
- ldx [%i1 + 0x0008], %l2 ! prom_cif_handler
+ ldx [%o1 + 0x0008], %l2 ! prom_cif_handler
mov %g4, %l0
mov %g5, %l1
mov %g6, %l3
diff --git a/arch/sparc/prom/init_64.c b/arch/sparc/prom/init_64.c
index d95db75..110b0d7 100644
--- a/arch/sparc/prom/init_64.c
+++ b/arch/sparc/prom/init_64.c
@@ -26,13 +26,13 @@ phandle prom_chosen_node;
* It gets passed the pointer to the PROM vector.
*/
-extern void prom_cif_init(void *, void *);
+extern void prom_cif_init(void *);
-void __init prom_init(void *cif_handler, void *cif_stack)
+void __init prom_init(void *cif_handler)
{
phandle node;
- prom_cif_init(cif_handler, cif_stack);
+ prom_cif_init(cif_handler);
prom_chosen_node = prom_finddevice(prom_chosen_path);
if (!prom_chosen_node || (s32)prom_chosen_node == -1)
diff --git a/arch/sparc/prom/p1275.c b/arch/sparc/prom/p1275.c
index b2340f0..545d8bb 100644
--- a/arch/sparc/prom/p1275.c
+++ b/arch/sparc/prom/p1275.c
@@ -20,7 +20,6 @@
struct {
long prom_callback; /* 0x00 */
Re: [PATCH 3/5] cpuidle: idle: menu: Don't reflect when a state selection failed
On Mon, 20 Oct 2014, Daniel Lezcano wrote:
> In the current code, the check to reflect or not the outcoming state is done
> against the idle state which has been choose and its value.
s/choose/chosen/
> Instead of doing a check in each of the reflect functions, just don't call
> reflect
> if something went wrong in the idle path.
>
> Signed-off-by: Daniel Lezcano
Acked-by: Nicolas Pitre
> ---
> drivers/cpuidle/governors/ladder.c | 3 +--
> drivers/cpuidle/governors/menu.c | 4 +---
> kernel/sched/idle.c| 3 ++-
> 3 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpuidle/governors/ladder.c
> b/drivers/cpuidle/governors/ladder.c
> index fb396d6..c0b36a8 100644
> --- a/drivers/cpuidle/governors/ladder.c
> +++ b/drivers/cpuidle/governors/ladder.c
> @@ -165,8 +165,7 @@ static int ladder_enable_device(struct cpuidle_driver
> *drv,
> static void ladder_reflect(struct cpuidle_device *dev, int index)
> {
> struct ladder_device *ldev = &__get_cpu_var(ladder_devices);
> - if (index > 0)
> - ldev->last_state_idx = index;
> + ldev->last_state_idx = index;
> }
>
> static struct cpuidle_governor ladder_governor = {
> diff --git a/drivers/cpuidle/governors/menu.c
> b/drivers/cpuidle/governors/menu.c
> index a17515f..3907301 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -365,9 +365,7 @@ static int menu_select(struct cpuidle_driver *drv, struct
> cpuidle_device *dev,
> static void menu_reflect(struct cpuidle_device *dev, int index)
> {
> struct menu_device *data = &__get_cpu_var(menu_devices);
> - data->last_state_idx = index;
> - if (index >= 0)
> - data->needs_update = 1;
> + data->needs_update = 1;
> }
>
> /**
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index f439161..9ac7322 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -162,7 +162,8 @@ use_default:
> /*
>* Give the governor an opportunity to reflect on the outcome
>*/
> - cpuidle_reflect(dev, entered_state);
> + if (entered_state >= 0)
> + cpuidle_reflect(dev, entered_state);
>
> exit_idle:
> __current_set_polling();
> --
> 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: [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x)
On Wednesday 22 October 2014 16:59:14 Lorenzo Pieralisi wrote:
> On Wed, Oct 01, 2014 at 10:38:45AM +0100, Arnd Bergmann wrote:
>
> [...]
>
> > The arm32 implementations of pci_domain_nr/pci_proc_domain can probably be
> > removed if we change the arm32 pcibios_init_hw function to call the new
> > interfaces that set the domain number.
>
> I wished, but it is a bit more complicated than I thought unfortunately,
> mostly because some drivers, eg cns3xxx set the domain numbers
> statically in pci_sys_data and this sets a chain of dependency that is
> not easy to untangle. I think cns3xxx is the only legacy driver that "uses"
> the domain number (in pci_sys_data) in a way that clashes with the
> generic domain_nr implementation, I need to give it more thought.
Just had a look at that driver, shouldn't be too hard to change, see below.
Signed-off-by: Arnd Bergmann
diff --git a/arch/arm/mach-cns3xxx/pcie.c b/arch/arm/mach-cns3xxx/pcie.c
index 45d6bd09e6ef..aa4b9d7c52fd 100644
--- a/arch/arm/mach-cns3xxx/pcie.c
+++ b/arch/arm/mach-cns3xxx/pcie.c
@@ -30,18 +30,15 @@ struct cns3xxx_pcie {
unsigned int irqs[2];
struct resource res_io;
struct resource res_mem;
- struct hw_pci hw_pci;
-
+ int port;
bool linked;
};
-static struct cns3xxx_pcie cns3xxx_pcie[]; /* forward decl. */
-
static struct cns3xxx_pcie *sysdata_to_cnspci(void *sysdata)
{
struct pci_sys_data *root = sysdata;
- return &cns3xxx_pcie[root->domain];
+ return root->private_data;
}
static struct cns3xxx_pcie *pdev_to_cnspci(const struct pci_dev *dev)
@@ -192,13 +189,7 @@ static struct cns3xxx_pcie cns3xxx_pcie[] = {
.flags = IORESOURCE_MEM,
},
.irqs = { IRQ_CNS3XXX_PCIE0_RC, IRQ_CNS3XXX_PCIE0_DEVICE, },
- .hw_pci = {
- .domain = 0,
- .nr_controllers = 1,
- .ops = &cns3xxx_pcie_ops,
- .setup = cns3xxx_pci_setup,
- .map_irq = cns3xxx_pcie_map_irq,
- },
+ .port = 0,
},
[1] = {
.host_regs = (void __iomem *)CNS3XXX_PCIE1_HOST_BASE_VIRT,
@@ -217,19 +208,13 @@ static struct cns3xxx_pcie cns3xxx_pcie[] = {
.flags = IORESOURCE_MEM,
},
.irqs = { IRQ_CNS3XXX_PCIE1_RC, IRQ_CNS3XXX_PCIE1_DEVICE, },
- .hw_pci = {
- .domain = 1,
- .nr_controllers = 1,
- .ops = &cns3xxx_pcie_ops,
- .setup = cns3xxx_pci_setup,
- .map_irq = cns3xxx_pcie_map_irq,
- },
+ .port = 1,
},
};
static void __init cns3xxx_pcie_check_link(struct cns3xxx_pcie *cnspci)
{
- int port = cnspci->hw_pci.domain;
+ int port = cnspci->port;
u32 reg;
unsigned long time;
@@ -260,9 +245,10 @@ static void __init cns3xxx_pcie_check_link(struct
cns3xxx_pcie *cnspci)
static void __init cns3xxx_pcie_hw_init(struct cns3xxx_pcie *cnspci)
{
- int port = cnspci->hw_pci.domain;
+ int port = cnspci->port;
struct pci_sys_data sd = {
.domain = port,
+ .private_data = cnspci,
};
struct pci_bus bus = {
.number = 0,
@@ -323,6 +309,14 @@ static int cns3xxx_pcie_abort_handler(unsigned long addr,
unsigned int fsr,
void __init cns3xxx_pcie_init_late(void)
{
int i;
+ void *private_data;
+ struct hw_pci hw_pci = {
+ .nr_controllers = 1,
+ .ops = &cns3xxx_pcie_ops,
+ .setup = cns3xxx_pci_setup,
+ .map_irq = cns3xxx_pcie_map_irq,
+ .private_data = &private_data,
+ };
pcibios_min_io = 0;
pcibios_min_mem = 0;
@@ -335,7 +329,9 @@ void __init cns3xxx_pcie_init_late(void)
cns3xxx_pwr_soft_rst(0x1 << PM_SOFT_RST_REG_OFFST_PCIE(i));
cns3xxx_pcie_check_link(&cns3xxx_pcie[i]);
cns3xxx_pcie_hw_init(&cns3xxx_pcie[i]);
- pci_common_init(&cns3xxx_pcie[i].hw_pci);
+ hw_pci->domain = i;
+ private_data = &cns3xxx_pcie[i];
+ pci_common_init(&hw_pci);
}
pci_assign_unassigned_resources();
--
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: [PATCHv5 2/7] usb: dwc2: Move gadget probe function into platform code
> From: Bartlomiej Zolnierkiewicz [mailto:b.zolnier...@samsung.com] > Sent: Wednesday, October 22, 2014 4:16 AM > > On Monday, October 20, 2014 01:52:01 PM dingu...@opensource.altera.com wrote: > > From: Dinh Nguyen > > > > This patch will aggregate the probing of gadget/hcd driver into platform.c. > > The gadget probe funtion is converted into gadget_init that is now only > > responsible for gadget only initialization. All the gadget resources is now > > handled by platform.c > > > > Since the host workqueue will not get initialized if the driver is > > configured > > for peripheral mode only. Thus we need to check for wq_otg before calling > > queue_work(). > > > > Also, we move spin_lock_init to common location for both host and gadget > > that > > is either in platform.c or pci.c. > > > > We also ove suspend/resume code to common platform code, and update it to > > use > > the new PM API (struct dev_pm_ops). > > > > Lastly, move the "samsung,s3c6400-hsotg" binding into dwc2_of_match_table. > > This patch seems to break bisectability. It moves all the gadget probing > to platform.c but Kconfig/Makefile are not updated (platform.c will be > compiled only for CONFIG_USB_DWC2_PLATFORM=y which in turn depends on > CONFIG_USB_DWC2_HOST). IMO patch #7 should be merged into this one (#2). It doesn't break the compile, I already tested it. It does break the operation of the driver until patch #7 is applied, but I think that's OK in the middle of a patch series. I think it's a bit much to expect the driver to keep working at each step of a patch series like this. -- Paul -- 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: lockdep splat in CPU hotplug
On Wed, 22 Oct 2014, Paul E. McKenney wrote: > rcu: More on deadlock between CPU hotplug and expedited grace periods > > Commit dd56af42bd82 (rcu: Eliminate deadlock between CPU hotplug and > expedited grace periods) was incomplete. Although it did eliminate > deadlocks involving synchronize_sched_expedited()'s acquisition of > cpu_hotplug.lock via get_online_cpus(), it did nothing about the similar > deadlock involving acquisition of this same lock via put_online_cpus(). > This deadlock became apparent with testing involving hibernation. > > This commit therefore changes put_online_cpus() acquisition of this lock > to be conditional, and increments a new cpu_hotplug.puts_pending field > in case of acquisition failure. Then cpu_hotplug_begin() checks for this > new field being non-zero, and applies any changes to cpu_hotplug.refcount. > Yes, this works. FWIW, please feel free to add Reported-and-tested-by: Jiri Kosina once merging it. Why lockdep produced such an incomplete stacktrace still remains unexplained. Thanks, -- Jiri Kosina SUSE Labs -- 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 3/4] OOM, PM: OOM killed task shouldn't escape PM suspend
On Wednesday, October 22, 2014 04:22:26 PM Michal Hocko wrote: > On Wed 22-10-14 16:39:12, Rafael J. Wysocki wrote: > > On Tuesday, October 21, 2014 04:29:39 PM Michal Hocko wrote: > > > On Tue 21-10-14 16:41:07, Rafael J. Wysocki wrote: > > > > On Tuesday, October 21, 2014 04:11:59 PM Michal Hocko wrote: > > > [...] > > > > > OK, incremental diff on top. I will post the complete patch if you are > > > > > happier with this change > > > > > > > > Yes, I am. > > > --- > > > From 9ab46fe539cded8e7b6425b2cd23ba9184002fde Mon Sep 17 00:00:00 2001 > > > From: Michal Hocko > > > Date: Mon, 20 Oct 2014 18:12:32 +0200 > > > Subject: [PATCH -v2] OOM, PM: OOM killed task shouldn't escape PM suspend > > > > > > PM freezer relies on having all tasks frozen by the time devices are > > > getting frozen so that no task will touch them while they are getting > > > frozen. But OOM killer is allowed to kill an already frozen task in > > > order to handle OOM situtation. In order to protect from late wake ups > > > OOM killer is disabled after all tasks are frozen. This, however, still > > > keeps a window open when a killed task didn't manage to die by the time > > > freeze_processes finishes. > > > > > > Reduce the race window by checking all tasks after OOM killer has been > > > disabled. This is still not race free completely unfortunately because > > > oom_killer_disable cannot stop an already ongoing OOM killer so a task > > > might still wake up from the fridge and get killed without > > > freeze_processes noticing. Full synchronization of OOM and freezer is, > > > however, too heavy weight for this highly unlikely case. > > > > > > Introduce and check oom_kills counter which gets incremented early when > > > the allocator enters __alloc_pages_may_oom path and only check all the > > > tasks if the counter changes during the freezing attempt. The counter > > > is updated so early to reduce the race window since allocator checked > > > oom_killer_disabled which is set by PM-freezing code. A false positive > > > will push the PM-freezer into a slow path but that is not a big deal. > > > > > > Changes since v1 > > > - push the re-check loop out of freeze_processes into > > > check_frozen_processes and invert the condition to make the code more > > > readable as per Rafael > > > > I've applied that along with the rest of the series, but what about the > > following cleanup patch on top of it? > > Sure, looks good to me. I'll apply it then, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 3/7] ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC
From: Jonathan Richardson This defconfig is utilized so a customer or developer can understand what kernel drivers are utilized by the Cygnus SoC. It also enables debug configs which should be disabled if optimal performance is desired. Tested-by: Jonathan Richardson Reviewed-by: JD (Jiandong) Zheng Signed-off-by: Scott Branden --- arch/arm/configs/bcm_cygnus_defconfig | 237 + 1 file changed, 237 insertions(+) create mode 100644 arch/arm/configs/bcm_cygnus_defconfig diff --git a/arch/arm/configs/bcm_cygnus_defconfig b/arch/arm/configs/bcm_cygnus_defconfig new file mode 100644 index 000..9ad77a8 --- /dev/null +++ b/arch/arm/configs/bcm_cygnus_defconfig @@ -0,0 +1,237 @@ +CONFIG_KERNEL_XZ=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_FHANDLE=y +CONFIG_IRQ_DOMAIN_DEBUG=y +CONFIG_NO_HZ_IDLE=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=19 +CONFIG_CGROUPS=y +CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_DEVICE=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_RESOURCE_COUNTERS=y +CONFIG_CGROUP_SCHED=y +CONFIG_BLK_CGROUP=y +CONFIG_NAMESPACES=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_EMBEDDED=y +CONFIG_PERF_EVENTS=y +# CONFIG_COMPAT_BRK is not set +CONFIG_JUMP_LABEL=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y +CONFIG_ARCH_BCM=y +CONFIG_ARCH_BCM_CYGNUS=y +CONFIG_ARM_THUMBEE=y +CONFIG_PCI=y +CONFIG_PCI_DEBUG=y +CONFIG_PREEMPT=y +CONFIG_AEABI=y +CONFIG_HIGHMEM=y +# CONFIG_COMPACTION is not set +# CONFIG_ATAGS is not set +CONFIG_ZBOOT_ROM_TEXT=0x0 +CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_ARM_APPENDED_DTB=y +CONFIG_CPU_IDLE=y +CONFIG_VFP=y +CONFIG_NEON=y +# CONFIG_SUSPEND is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_MROUTE=y +CONFIG_IP_MROUTE_MULTIPLE_TABLES=y +CONFIG_SYN_COOKIES=y +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET_XFRM_MODE_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_BEET is not set +# CONFIG_INET_LRO is not set +# CONFIG_INET_DIAG is not set +CONFIG_TCP_CONG_ADVANCED=y +# CONFIG_TCP_CONG_BIC is not set +# CONFIG_TCP_CONG_WESTWOOD is not set +# CONFIG_TCP_CONG_HTCP is not set +CONFIG_IPV6=y +# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET6_XFRM_MODE_TUNNEL is not set +# CONFIG_INET6_XFRM_MODE_BEET is not set +# CONFIG_IPV6_SIT is not set +CONFIG_IPV6_MULTIPLE_TABLES=y +CONFIG_IPV6_SUBTREES=y +CONFIG_IPV6_MROUTE=y +CONFIG_NETFILTER=y +# CONFIG_BRIDGE_NETFILTER is not set +CONFIG_NF_CONNTRACK=y +# CONFIG_NF_CONNTRACK_PROCFS is not set +CONFIG_NF_CONNTRACK_FTP=y +CONFIG_NF_CONNTRACK_IPV4=y +CONFIG_IP_NF_IPTABLES=y +CONFIG_IP_NF_FILTER=y +CONFIG_IP_NF_TARGET_REJECT=y +CONFIG_IP_NF_NAT=y +CONFIG_IP_NF_TARGET_MASQUERADE=y +CONFIG_IP_NF_TARGET_REDIRECT=y +CONFIG_IP_NF_MANGLE=y +CONFIG_IP_NF_RAW=y +CONFIG_NF_CONNTRACK_IPV6=y +CONFIG_IP6_NF_IPTABLES=y +CONFIG_IP6_NF_MATCH_AH=y +CONFIG_IP6_NF_MATCH_EUI64=y +CONFIG_IP6_NF_MATCH_FRAG=y +CONFIG_IP6_NF_MATCH_OPTS=y +CONFIG_IP6_NF_MATCH_IPV6HEADER=y +CONFIG_IP6_NF_MATCH_MH=y +CONFIG_IP6_NF_MATCH_RT=y +CONFIG_IP6_NF_FILTER=y +CONFIG_IP6_NF_TARGET_REJECT=y +CONFIG_IP6_NF_MANGLE=y +CONFIG_IP6_NF_RAW=y +CONFIG_BRIDGE=y +# CONFIG_BRIDGE_IGMP_SNOOPING is not set +CONFIG_VLAN_8021Q=y +CONFIG_NET_SCHED=y +CONFIG_NET_SCH_FQ_CODEL=y +CONFIG_CFG80211=y +# CONFIG_CFG80211_DEFAULT_PS is not set +CONFIG_CFG80211_WEXT=y +CONFIG_RFKILL=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_FIRMWARE_IN_KERNEL is not set +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_NAND=y +CONFIG_MTD_UBI=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y +CONFIG_BLK_DEV_SR=y +CONFIG_NETDEVICES=y +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_PHYLIB=y +CONFIG_BROADCOM_PHY=y +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=y +# CONFIG_KEYBOARD_ATKBD is not set +# CONFIG_INPUT_MOUSE is not set +CONFIG_INPUT_TOUCHSCREEN=y +# CONFIG_SERIO is not set +# CONFIG_LEGACY_PTYS is not set +CONFIG_SERIAL_8250=y +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=2 +CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +CONFIG_SERIAL_8250_DW=y +CONFIG_SERIAL_OF_PLATFORM=y +# CONFIG_HW_RANDOM is not set +CONFIG_I2C_CHARDEV=y +# CONFIG_I2C_HELPER_AUTO is not set +CONFIG_I2C_SMBUS=y +CONFIG_SPI=y +CONFIG_SPI_PL022=y
[PATCH v7 2/7] dt-bindings: Document Broadcom Cygnus SoC and clocks
From: Jonathan Richardson
Reviewed-by: Arun Parameswaran
Tested-by: Jonathan Richardson
Reviewed-by: JD (Jiandong) Zheng
Reviewed-by: Ray Jui
Signed-off-by: Scott Branden
---
.../devicetree/bindings/arm/bcm/cygnus.txt | 31 ++
.../devicetree/bindings/clock/bcm-cygnus-clock.txt | 34
2 files changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/bcm/cygnus.txt
create mode 100644 Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
diff --git a/Documentation/devicetree/bindings/arm/bcm/cygnus.txt
b/Documentation/devicetree/bindings/arm/bcm/cygnus.txt
new file mode 100644
index 000..4c77169
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/cygnus.txt
@@ -0,0 +1,31 @@
+Broadcom Cygnus device tree bindings
+
+
+
+Boards with Cygnus SoCs shall have the following properties:
+
+Required root node property:
+
+BCM11300
+compatible = "brcm,bcm11300", "brcm,cygnus";
+
+BCM11320
+compatible = "brcm,bcm11320", "brcm,cygnus";
+
+BCM11350
+compatible = "brcm,bcm11350", "brcm,cygnus";
+
+BCM11360
+compatible = "brcm,bcm11360", "brcm,cygnus";
+
+BCM58300
+compatible = "brcm,bcm58300", "brcm,cygnus";
+
+BCM58302
+compatible = "brcm,bcm58302", "brcm,cygnus";
+
+BCM58303
+compatible = "brcm,bcm58303", "brcm,cygnus";
+
+BCM58305
+compatible = "brcm,bcm58305", "brcm,cygnus";
diff --git a/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
b/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
new file mode 100644
index 000..00d26ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
@@ -0,0 +1,34 @@
+Broadcom Cygnus Clocks
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Currently various "fixed" clocks are declared for peripheral drivers that use
+the common clock framework to reference their core clocks. Proper support of
+these clocks will be added later
+
+Device tree example:
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <1>;
+ clock-frequency = <2500>;
+ };
+
+ apb_clk: apb_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <10>;
+ };
+
+ periph_clk: periph_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5>;
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 4/7] ARM: dts: Enable Broadcom Cygnus SoC
DT files to enable cygnus consisting on reference designs
and cygnus core configuration.
Reviewed-by: Ray Jui
Reviewed-by: Arun Parameswaran
Tested-by: Jonathan Richardson
Reviewed-by: JD (Jiandong) Zheng
Signed-off-by: Scott Branden
---
arch/arm/boot/dts/Makefile |4 ++
arch/arm/boot/dts/bcm-cygnus-clock.dtsi | 73 +
arch/arm/boot/dts/bcm-cygnus.dtsi | 109 +++
arch/arm/boot/dts/bcm911360_entphn.dts | 22 +++
arch/arm/boot/dts/bcm911360k.dts| 22 +++
arch/arm/boot/dts/bcm958300k.dts| 22 +++
6 files changed, 252 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm-cygnus-clock.dtsi
create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts
create mode 100644 arch/arm/boot/dts/bcm911360k.dts
create mode 100644 arch/arm/boot/dts/bcm958300k.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7c80af9..a6b734a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -54,6 +54,10 @@ dtb-$(CONFIG_ARCH_AT91) += at91-sama5d4ek.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
+ bcm911360_entphn.dtb \
+ bcm911360k.dtb \
+ bcm958300k.dtb
dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
dtb-$(CONFIG_ARCH_BCM_63XX) += bcm963138dvt.dtb
dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \
diff --git a/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
new file mode 100644
index 000..d06172b
--- /dev/null
+++ b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
@@ -0,0 +1,73 @@
+/*
+ * Copyright 2014 Broadcom Corporation. All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <1>;
+ clock-frequency = <2500>;
+ };
+
+ apb_clk: apb_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <10>;
+ };
+
+ periph_clk: periph_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5>;
+ };
+
+ sdio_clk: lcpll_ch2 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2>;
+ };
+
+ axi81_clk: axi81_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+
+ keypad_clk: keypad_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <31806>;
+ };
+
+ adc_clk: adc_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1562500>;
+ };
+
+ pwm_clk: pwm_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100>;
+ };
+
+ lcd_clk: mipipll_ch1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+};
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
new file mode 100644
index 000..a377ab2
--- /dev/null
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -0,0 +1,109 @@
+/*
+ * Copyright 2014 Broadcom Corporation. All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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 "skeleton.dtsi"
+
+/ {
+ compatible = "brcm,cygnus";
+ model = "Broadcom Cygnus SoC";
+ interrupt-parent = <&gic>;
+
+ aliases
[PATCH v7 0/7] Add initial support for Broadcom Cygnus SoC
This patchset contains initial support for Broadcom's Cygnus SoC based on our iProc architecture. Initial support is minimal and includes just the mach platform code, clock driver, and a basic device tree configuration. Peripheral drivers will be submitted soon, as will device tree configurations for other Cygnus board variants. Changes from v6: - Additional patch added for cleanup of other areas of mach-bcm/Kconfig discovered during Cygnus submission review to: - removed one level of menu for ARCH_BCM_MOBILE in mach-bcm-Kconfig based on feedback from Arnd - added comment sections to Kconfig to identify SoC architecture groupings Changes from v5: - removed one level of menu used in mach-bcm/Kconfig - changed MAINTAINERS to use N: to support all files associated with iproc and cygnus going forward - updated bcm_cygnus_defconfig to remove some DEBUG options that greatly hamper performance Changes from v4: - simple clock tree used. reworked clock driver will be submitted later - fixed MAINTAINERS patchset error - removed DEBUG_UART_8250 Kconfig.debug legacy support - made ARCH_BCM_IPROC a silent Kconfig option - removed multi_v7_defconfig as it is not needed at this time, can support in future patchset but does not seem optimal configs for our current usage. Changes from v3: - restart functionality removed. Will be added in a different patchset in drivers/power - removed NEON init sequence. Will be moved to bootloader - cleaned up Kconfigs for ARCH_BCM_CYGNUS by removing unnecessary selects - consolidated ARCH_BCM_IPROC with select from ARCH_BCM_CYGNUS and ARCH_BCM5301X - removed bcm911360_entphn binding - added documentation for SoCs currently supported in Cygnus family Changes from v2: - rebased to 3.17 kernel Changes from v1: - Address code review comments as per previous responses. - Copyright headers updated to remove Broadcom URL. - mach platform code still contains hard coded addresses. These address are the same for all Cygnus variants. Could you please provide guidance on where they should go if you would still like them changed. There does not seem to be a reason to change them to device tree as they do not change. Jonathan Richardson (3): ARM: cygnus: Initial support for Broadcom Cygnus SoC dt-bindings: Document Broadcom Cygnus SoC and clocks ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC Scott Branden (4): ARM: dts: Enable Broadcom Cygnus SoC MAINTAINERS: Entry for Cygnus/iproc arm architecture ARM: mach-bcm: Consolidate currently supported IPROC SoCs ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig .../devicetree/bindings/arm/bcm/cygnus.txt | 31 +++ .../devicetree/bindings/clock/bcm-cygnus-clock.txt | 34 +++ MAINTAINERS| 14 ++ arch/arm/boot/dts/Makefile |4 + arch/arm/boot/dts/bcm-cygnus-clock.dtsi| 73 ++ arch/arm/boot/dts/bcm-cygnus.dtsi | 109 + arch/arm/boot/dts/bcm911360_entphn.dts | 22 ++ arch/arm/boot/dts/bcm911360k.dts | 22 ++ arch/arm/boot/dts/bcm958300k.dts | 22 ++ arch/arm/configs/bcm_cygnus_defconfig | 237 arch/arm/configs/bcm_defconfig |3 +- arch/arm/configs/multi_v7_defconfig|3 +- arch/arm/mach-bcm/Kconfig | 93 +--- arch/arm/mach-bcm/Makefile |3 + arch/arm/mach-bcm/bcm_cygnus.c | 26 +++ 15 files changed, 658 insertions(+), 38 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/cygnus.txt create mode 100644 Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt create mode 100644 arch/arm/boot/dts/bcm-cygnus-clock.dtsi create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts create mode 100644 arch/arm/boot/dts/bcm911360k.dts create mode 100644 arch/arm/boot/dts/bcm958300k.dts create mode 100644 arch/arm/configs/bcm_cygnus_defconfig create mode 100644 arch/arm/mach-bcm/bcm_cygnus.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 6/7] ARM: mach-bcm: Consolidate currently supported IPROC SoCs
Move ARCH_BCM_5301X subarch under ARCH_IPROC architecture. Additional IPROC chipsets that share a lot of commonality should be added under ARCH_IPROC as well. Signed-off-by: Scott Branden --- arch/arm/mach-bcm/Kconfig | 37 - 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index 73d95c2..6e79696 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -35,6 +35,22 @@ config ARCH_BCM_CYGNUS BCM11300, BCM11320, BCM11350, BCM11360, BCM58300, BCM58302, BCM58303, BCM58305. +config ARCH_BCM_5301X + bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7 + select ARCH_BCM_IPROC + help + Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores. + + This is a network SoC line mostly used in home routers and + wifi access points, it's internal name is Northstar. + This inclused the following SoC: BCM53010, BCM53011, BCM53012, + BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707, + BCM4708 and BCM4709. + + Do not confuse this with the BCM4760 which is a totally + different SoC or with the older BCM47XX and BCM53XX based + network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx + config ARCH_BCM_MOBILE bool "Broadcom Mobile SoC Support" if ARCH_MULTI_V7 select ARCH_REQUIRE_GPIOLIB @@ -110,27 +126,6 @@ config ARCH_BCM2835 This enables support for the Broadcom BCM2835 SoC. This SoC is used in the Raspberry Pi and Roku 2 devices. -config ARCH_BCM_5301X - bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7 - select ARM_GIC - select CACHE_L2X0 - select HAVE_ARM_SCU if SMP - select HAVE_ARM_TWD if SMP - select ARM_GLOBAL_TIMER - select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK - help - Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores. - - This is a network SoC line mostly used in home routers and - wifi access points, it's internal name is Northstar. - This inclused the following SoC: BCM53010, BCM53011, BCM53012, - BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707, - BCM4708 and BCM4709. - - Do not confuse this with the BCM4760 which is a totally - different SoC or with the older BCM47XX and BCM53XX based - network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx - config ARCH_BCM_63XX bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7 depends on MMU -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 7/7] ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig
remove menu "Broadcom Mobile SoC Selection" This requires: - selecting ARCH_BCM_MOBILE based on SoC selections - fixup bcm_defconfig to work with new menu levels. Signed-off-by: Scott Branden --- arch/arm/configs/bcm_defconfig |3 ++- arch/arm/configs/multi_v7_defconfig |3 ++- arch/arm/mach-bcm/Kconfig | 26 ++ 3 files changed, 14 insertions(+), 18 deletions(-) diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig index bc614f4..83a87e4 100644 --- a/arch/arm/configs/bcm_defconfig +++ b/arch/arm/configs/bcm_defconfig @@ -25,7 +25,8 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_BCM=y -CONFIG_ARCH_BCM_MOBILE=y +CONFIG_ARCH_BCM_21664=y +CONFIG_ARCH_BCM_281XX=y CONFIG_ARM_THUMBEE=y CONFIG_SMP=y CONFIG_PREEMPT=y diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 491b7d5..e8f79fd 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -17,7 +17,8 @@ CONFIG_MACH_ARMADA_38X=y CONFIG_MACH_ARMADA_XP=y CONFIG_MACH_DOVE=y CONFIG_ARCH_BCM=y -CONFIG_ARCH_BCM_MOBILE=y +CONFIG_ARCH_BCM_21664=y +CONFIG_ARCH_BCM_281XX=y CONFIG_ARCH_BCM_5301X=y CONFIG_ARCH_BRCMSTB=y CONFIG_ARCH_BERLIN=y diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index 6e79696..cceb69f 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -51,8 +51,10 @@ config ARCH_BCM_5301X different SoC or with the older BCM47XX and BCM53XX based network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx +comment "KONA architected SoCs" + config ARCH_BCM_MOBILE - bool "Broadcom Mobile SoC Support" if ARCH_MULTI_V7 + bool select ARCH_REQUIRE_GPIOLIB select ARM_ERRATA_754322 select ARM_ERRATA_775420 @@ -61,16 +63,13 @@ config ARCH_BCM_MOBILE select TICK_ONESHOT select HAVE_ARM_ARCH_TIMER select PINCTRL + select ARCH_BCM_MOBILE_SMP if SMP help This enables support for systems based on Broadcom mobile SoCs. -if ARCH_BCM_MOBILE - -menu "Broadcom Mobile SoC Selection" - config ARCH_BCM_281XX bool "Broadcom BCM281XX SoC family" - default y + select ARCH_BCM_MOBILE select HAVE_SMP help Enable support for the BCM281XX family, which includes @@ -79,7 +78,7 @@ config ARCH_BCM_281XX config ARCH_BCM_21664 bool "Broadcom BCM21664 SoC family" - default y + select ARCH_BCM_MOBILE select HAVE_SMP help Enable support for the BCM21664 family, which includes @@ -87,19 +86,18 @@ config ARCH_BCM_21664 config ARCH_BCM_MOBILE_L2_CACHE bool "Broadcom mobile SoC level 2 cache support" - depends on (ARCH_BCM_281XX || ARCH_BCM_21664) + depends on ARCH_BCM_MOBILE default y select CACHE_L2X0 select ARCH_BCM_MOBILE_SMC config ARCH_BCM_MOBILE_SMC bool - depends on ARCH_BCM_281XX || ARCH_BCM_21664 + depends on ARCH_BCM_MOBILE config ARCH_BCM_MOBILE_SMP - bool "Broadcom mobile SoC SMP support" - depends on (ARCH_BCM_281XX || ARCH_BCM_21664) && SMP - default y + bool + depends on ARCH_BCM_MOBILE select HAVE_ARM_SCU select ARM_ERRATA_764369 help @@ -107,10 +105,6 @@ config ARCH_BCM_MOBILE_SMP Provided as an option so SMP support for SoCs of this type can be disabled for an SMP-enabled kernel. -endmenu - -endif - comment "Other Architectures" config ARCH_BCM2835 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 5/7] MAINTAINERS: Entry for Cygnus/iproc arm architecture
Acked-by: Jonathan Richardson Signed-off-by: Scott Branden --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b0f17d5..dfe255f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2125,6 +2125,20 @@ L: linux-s...@vger.kernel.org S: Supported F: drivers/scsi/bnx2i/ +BROADCOM CYGNUS/IPROC ARM ARCHITECTURE +M: Ray Jui +M: Scott Branden +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: bcm-kernel-feedback-l...@broadcom.com +T: git git://git.github.com/brcm/linux.git +S: Maintained +N: iproc +N: cygnus +N: bcm9113* +N: bcm9583* +N: bcm583* +N: bcm113* + BROADCOM KONA GPIO DRIVER M: Ray Jui L: bcm-kernel-feedback-l...@broadcom.com -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/7] ARM: cygnus: Initial support for Broadcom Cygnus SoC
From: Jonathan Richardson
Adds initial support for the Cygnus SoC based on Broadcom’s iProc series.
Reviewed-by: Ray Jui
Reviewed-by: Desmond Liu
Reviewed-by: JD (Jiandong) Zheng
Tested-by: Jonathan Richardson
Signed-off-by: Scott Branden
---
arch/arm/mach-bcm/Kconfig | 32
arch/arm/mach-bcm/Makefile |3 +++
arch/arm/mach-bcm/bcm_cygnus.c | 26 ++
3 files changed, 61 insertions(+)
create mode 100644 arch/arm/mach-bcm/bcm_cygnus.c
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 2abad74..73d95c2 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -5,6 +5,36 @@ menuconfig ARCH_BCM
if ARCH_BCM
+comment "IPROC architected SoCs"
+
+config ARCH_BCM_IPROC
+ bool
+ select ARM_GIC
+ select CACHE_L2X0
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if SMP
+ select ARM_GLOBAL_TIMER
+
+ select CLKSRC_MMIO
+ select ARCH_REQUIRE_GPIOLIB
+ select ARM_AMBA
+ select PINCTRL
+ help
+ This enables support for systems based on Broadcom IPROC architected
SoCs.
+ The IPROC complex contains one or more ARM CPUs along with common
+ core periperals. Application specific SoCs are created by adding a
+ uArchitecture containing peripherals outside of the IPROC complex.
+ Currently supported SoCs are Cygnus.
+
+config ARCH_BCM_CYGNUS
+ bool "Broadcom Cygnus Support" if ARCH_MULTI_V7
+ select ARCH_BCM_IPROC
+ help
+ Enable support for the Cygnus family,
+ which includes the following variants:
+ BCM11300, BCM11320, BCM11350, BCM11360,
+ BCM58300, BCM58302, BCM58303, BCM58305.
+
config ARCH_BCM_MOBILE
bool "Broadcom Mobile SoC Support" if ARCH_MULTI_V7
select ARCH_REQUIRE_GPIOLIB
@@ -65,6 +95,8 @@ endmenu
endif
+comment "Other Architectures"
+
config ARCH_BCM2835
bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 300ae4b..34d45ba 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -10,6 +10,9 @@
# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
+# Cygnus
+obj-$(CONFIG_ARCH_BCM_CYGNUS) += bcm_cygnus.o
+
# BCM281XX
obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o
diff --git a/arch/arm/mach-bcm/bcm_cygnus.c b/arch/arm/mach-bcm/bcm_cygnus.c
new file mode 100644
index 000..41b4933
--- /dev/null
+++ b/arch/arm/mach-bcm/bcm_cygnus.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright 2014 Broadcom Corporation. All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+
+static const char const *bcm_cygnus_dt_compat[] = {
+ "brcm,cygnus",
+ NULL,
+};
+
+DT_MACHINE_START(BCM_CYGNUS_DT, "Broadcom Cygnus SoC")
+ .l2c_aux_val= 0,
+ .l2c_aux_mask = ~0,
+ .dt_compat = bcm_cygnus_dt_compat,
+MACHINE_END
--
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 v2 0/12] perf/x86: implement HT leak workaround for SNB/IVB/HSW
On Wed, Oct 22, 2014 at 11:12 AM, Peter Zijlstra wrote: > On Tue, Oct 21, 2014 at 03:08:32PM +0200, Stephane Eranian wrote: >> On Tue, Oct 21, 2014 at 3:03 PM, Peter Zijlstra wrote: >> > On Tue, Oct 21, 2014 at 02:28:06PM +0200, Stephane Eranian wrote: >> >> Peter, >> >> >> >> On Tue, Oct 21, 2014 at 1:25 PM, Peter Zijlstra >> >> wrote: >> >> > >> >> > >> >> > lkml.kernel.org/r/CABPqkBRbst4sgpgE5O_VXt-CSC0VD=ap2kwa0e3uy64tw7d...@mail.gmail.com >> >> > >> >> > I missed that 3 lines if they were in here. >> >> > >> >> I did not put them in there because there is another problem. >> >> If you partition the generic counters 2 and 2, then some CPUs will not >> >> be able to measure some events. >> >> Unfortunately, there is no way to partition the 4 counters such that >> >> all the events can be measured by >> >> each CPU. Some events or precise sampling requires counter 2 for >> >> instance (like prec_dist). >> >> That's why I did not put this fix in. >> > >> > Ah, I wasn't thinking about a hard partition, just a limit on the number >> > of exclusive counters any one CPU can claim such as to not starve. Or is >> > that what you were talking about? I feel not being able to starve >> > another CPU is more important than a better utilization bound for >> > counter scheduling. >> >> So you're saying, just limit number of used counters to 2 regardless >> of which one they are. > > used as in marked exclusive and forced empty on the other side. > >> So sometimes, this will avoid the problem aforementioned and sometimes >> not. We can try that. > > How will this sometimes not avoid the starvation issue? Here is a simple case: Limiting each HT to only 2 counters, can be any, 2 out of 4 possible. HT0: you measure a MEM* in ctr2, it is started first, and it keeps running HT1: you measure PREC_DIST with PEBS (it requires ctr2) HT0 is measuring a corrupting event on ctr2, this prevents ctr2 on HT1 from being used. HT1 is starved, it cannot measure PREC_DIST Yes you have a quota of 2 out of 4 counters. The quota dynamic or static can help mitigate the starvation. The only way to eliminate it is to force multiplexing even though you are using fewer counters than actually avail. -- 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 05/59] dmaengine: Make channel allocation callbacks optional
Hi Maxime,
Thank you for the patch.
On Wednesday 22 October 2014 17:43:19 Maxime Ripard wrote:
> Nowadays, some drivers don't have anything in there channel allocation
> callbacks anymore.
>
> Remove the BUG_ON if those callbacks aren't implemented, in order to allow
> drivers to not implement them.
>
> Signed-off-by: Maxime Ripard
Acked-by: Laurent Pinchart
> ---
> drivers/dma/dmaengine.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 72f10e2f5c32..9b2cd74b8f2e 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -235,9 +235,11 @@ static int dma_chan_get(struct dma_chan *chan)
> return -ENODEV;
>
> /* allocate upon first client reference */
> - ret = chan->device->device_alloc_chan_resources(chan);
> - if (ret < 0)
> - goto err_out;
> + if (chan->device->device_alloc_chan_resources) {
> + ret = chan->device->device_alloc_chan_resources(chan);
> + if (ret < 0)
> + goto err_out;
> + }
>
> if (!dma_has_cap(DMA_PRIVATE, chan->device->cap_mask))
> balance_ref_count(chan);
> @@ -259,11 +261,15 @@ err_out:
> */
> static void dma_chan_put(struct dma_chan *chan)
> {
> + /* This channel is not in use, bail out */
> if (!chan->client_count)
> - return; /* this channel failed alloc_chan_resources */
> + return;
> +
> chan->client_count--;
> module_put(dma_chan_to_owner(chan));
> - if (chan->client_count == 0)
> +
> + /* This channel is not in use anymore, free it */
> + if (!chan->client_count && chan->device->device_free_chan_resources)
> chan->device->device_free_chan_resources(chan);
> }
>
> @@ -819,8 +825,6 @@ int dma_async_device_register(struct dma_device *device)
> BUG_ON(dma_has_cap(DMA_INTERLEAVE, device->cap_mask) &&
> !device->device_prep_interleaved_dma);
>
> - BUG_ON(!device->device_alloc_chan_resources);
> - BUG_ON(!device->device_free_chan_resources);
> BUG_ON(!device->device_tx_status);
> BUG_ON(!device->device_issue_pending);
> BUG_ON(!device->dev);
--
Regards,
Laurent Pinchart
--
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 11/59] dmaengine: Move slave caps to dma_device
Hi Maxime,
Thank you for the patch.
On Wednesday 22 October 2014 17:43:25 Maxime Ripard wrote:
> The previous code was relying on the fact that the slave_caps were to be
> defined on a per channel basis.
>
> However, this proved to be a bit overkill, since every driver filling these
> so far were hardcoding it, disregarding which channel was actually given.
>
> Add these capabilities to the dma_device structure, so that drivers can just
> provide them at probe time, and be done with it.
>
> Signed-off-by: Maxime Ripard
Acked-by: Laurent Pinchart
> ---
> include/linux/dmaengine.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 6b74d9d8977e..98f8163dfbac 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -593,6 +593,14 @@ struct dma_tx_state {
> * @fill_align: alignment shift for memset operations
> * @dev_id: unique device ID
> * @dev: struct device reference for dma mapping api
> + * @src_addr_widths: bit mask of src addr widths the device supports
> + * @dst_addr_widths: bit mask of dst addr widths the device supports
> + * @directions: bit mask of slave direction the device supports since
> + * the enum dma_transfer_direction is not defined as bits for
> + * each type of direction, the dma controller should fill (1 <<
> + * ) and same should be checked by controller as well
> + * @residue_granularity: granularity of the transfer residue reported
> + * by tx_status
> * @device_alloc_chan_resources: allocate resources and return the
> * number of allocated descriptors
> * @device_free_chan_resources: release DMA channel's resources
> @@ -643,6 +651,10 @@ struct dma_device {
> struct device *dev;
>
> bool generic_slave_caps;
> + u32 src_addr_widths;
> + u32 dst_addr_widths;
> + u32 directions;
> + enum dma_residue_granularity residue_granularity;
>
> int (*device_alloc_chan_resources)(struct dma_chan *chan);
> void (*device_free_chan_resources)(struct dma_chan *chan);
> @@ -807,6 +819,11 @@ static inline int dma_get_slave_caps(struct dma_chan
> *chan, struct dma_slave_cap if (device->generic_slave_caps)
> return -ENXIO;
>
> + caps->src_addr_widths = device->src_addr_widths;
> + caps->dst_addr_widths = device->dst_addr_widths;
> + caps->directions = device->directions;
> + caps->residue_granularity = device->residue_granularity;
> +
> caps->cmd_pause = !!device->device_pause;
> caps->cmd_terminate = !!device->device_terminate_all;
--
Regards,
Laurent Pinchart
--
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 09/59] dmaengine: Remove the need to declare device_control
Hi Maxime, Thank you for the patch. On Wednesday 22 October 2014 17:43:23 Maxime Ripard wrote: > In order to migrate the drivers without triggering a BUG_ON for the > converted drivers, which would cause bisectability issues, we need to > remove that check before removing the device_control function entirely. > > Signed-off-by: Maxime Ripard Acked-by: Laurent Pinchart > --- > drivers/dma/dmaengine.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c > index 9b2cd74b8f2e..98e9431f85ec 100644 > --- a/drivers/dma/dmaengine.c > +++ b/drivers/dma/dmaengine.c > @@ -820,8 +820,6 @@ int dma_async_device_register(struct dma_device *device) > !device->device_prep_dma_sg); > BUG_ON(dma_has_cap(DMA_CYCLIC, device->cap_mask) && > !device->device_prep_dma_cyclic); > - BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) && > - !device->device_control); > BUG_ON(dma_has_cap(DMA_INTERLEAVE, device->cap_mask) && > !device->device_prep_interleaved_dma); -- Regards, Laurent Pinchart -- 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] perf diff: Add missing hists__init() call at tool start
From: Kan Liang
It also uses hists/hist_entries, hists__init() should be called before
creating any evsels.
Otherwise no extra space will be allocated per perf_evsel nor this space
will be initialized when allocating a new perf_evsel instance, resulting
in reads/writes to non allocated space, oops. Fix it.
Signed-off-by: Kan Liang
Link:
http://lkml.kernel.org/r/1414004561-22096-1-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-diff.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 8c5c11ca8c53..25114c9a6801 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -1142,6 +1142,11 @@ static int data_init(int argc, const char **argv)
int cmd_diff(int argc, const char **argv, const char *prefix __maybe_unused)
{
+ int ret = hists__init();
+
+ if (ret < 0)
+ return ret;
+
perf_config(perf_default_config, NULL);
argc = parse_options(argc, argv, options, diff_usage, 0);
--
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/
[GIT PULL 0/1] perf/urgent fix
Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit 3b10ea7f922b538ba5dcb3d979a6b6b4d07daae2: Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2014-10-18 09:04:02 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo for you to fetch changes up to 9ab1f50876dbb8b962db058259be7aae920d4c25: perf diff: Add missing hists__init() call at tool start (2014-10-22 16:31:06 -0300) perf/urgent fix: * Fix 'perf diff' initialization, calling the recently added hists__init() function so that extra space is allocated per perf_evsel for the hists storage that it also uses, just like report and top. (Kan Liang) Signed-off-by: Arnaldo Carvalho de Melo Kan Liang (1): perf diff: Add missing hists__init() call at tool start tools/perf/builtin-diff.c | 5 + 1 file changed, 5 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: lockdep splat in CPU hotplug
On Wed, Oct 22, 2014 at 10:57:25PM +0200, Jiri Kosina wrote: > On Wed, 22 Oct 2014, Paul E. McKenney wrote: > > > rcu: More on deadlock between CPU hotplug and expedited grace periods > > > > Commit dd56af42bd82 (rcu: Eliminate deadlock between CPU hotplug and > > expedited grace periods) was incomplete. Although it did eliminate > > deadlocks involving synchronize_sched_expedited()'s acquisition of > > cpu_hotplug.lock via get_online_cpus(), it did nothing about the similar > > deadlock involving acquisition of this same lock via put_online_cpus(). > > This deadlock became apparent with testing involving hibernation. > > > > This commit therefore changes put_online_cpus() acquisition of this lock > > to be conditional, and increments a new cpu_hotplug.puts_pending field > > in case of acquisition failure. Then cpu_hotplug_begin() checks for this > > new field being non-zero, and applies any changes to cpu_hotplug.refcount. > > > > Yes, this works. FWIW, please feel free to add > > Reported-and-tested-by: Jiri Kosina > > once merging it. Done, and thank you for both the bug report and the testing! > Why lockdep produced such an incomplete stacktrace still remains > unexplained. On that, I must defer to people more familiar with stack frames. Thanx, Paul > Thanks, > > -- > Jiri Kosina > SUSE Labs > -- 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] x86/efi for v3.18-rc2
Hi Linus,
This patchset falls under the "maintainers that grovel" clause in the
v3.18-rc1 announcement. We had intended to push it late in the merge
window since we got it into the -tip tree relatively late.
Many of these are relatively simple things, but there are a couple of
key bits, especially Ard's and Matt's patches as listed below.
-hpa
The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb:
Linux 3.17-rc7 (2014-09-28 14:29:07 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-efi-for-linus
for you to fetch changes up to 75b128573b275d5a5a7210b98c4b8cb3b39c12e7:
Merge branch 'next' into efi-next-merge (2014-10-03 22:15:56 +0100)
Andre Müller (1):
x86/efi: Adding efi_printks on memory allocationa and pci.reads
Ard Biesheuvel (2):
efi: Implement mandatory locking for UEFI Runtime Services
efi: rtc-efi: Export platform:rtc-efi as module alias
Dave Young (6):
efi: Move noefi early param code out of x86 arch code
lib: Add a generic cmdline parse function parse_option_str
efi: Add kernel param efi=noruntime
arm64/efi: uefi_init error handling fix
arm64/efi: Do not enter virtual mode if booting with efi=noruntime or
noefi
x86/efi: Clear EFI_RUNTIME_SERVICES if failing to enter virtual mode
Josh Triplett (1):
efi-bgrt: Add error handling; inform the user when ignoring the BGRT
Laszlo Ersek (5):
efi: Add macro for EFI_MEMORY_UCE memory attribute
efi: Introduce efi_md_typeattr_format()
x86: efi: Format EFI memory type & attrs with efi_md_typeattr_format()
ia64: efi: Format EFI memory type & attrs with efi_md_typeattr_format()
arm64: efi: Format EFI memory type & attrs with efi_md_typeattr_format()
Mark Rustad (1):
efi: Resolve some shadow warnings
Mathias Krause (4):
x86/efi: Remove unused efi_call* macros
x86/efi: Unexport add_efi_memmap variable
x86/efi: Update comment regarding required phys mapped EFI services
x86/efi: Mark initialization code as such
Matt Fleming (5):
efi: Add efi= parameter parsing to the EFI boot stub
efi: Provide a non-blocking SetVariable() operation
efi: Delete the in_nmi() conditional runtime locking
rtc: Disable EFI rtc for x86
Merge branch 'next' into efi-next-merge
Documentation/kernel-parameters.txt| 8 +-
arch/arm64/kernel/efi.c| 44 +++
arch/ia64/kernel/efi.c | 6 +-
arch/x86/boot/compressed/eboot.c | 32 +++--
arch/x86/include/asm/efi.h | 31 ++---
arch/x86/platform/efi/efi-bgrt.c | 36 +-
arch/x86/platform/efi/efi.c| 52
arch/x86/platform/efi/efi_32.c | 12 +-
arch/x86/platform/efi/efi_64.c | 6 +-
arch/x86/platform/efi/efi_stub_32.S| 4 +-
drivers/firmware/efi/efi.c | 79
drivers/firmware/efi/libstub/arm-stub.c| 4 +
drivers/firmware/efi/libstub/efi-stub-helper.c | 62 +-
drivers/firmware/efi/runtime-wrappers.c| 164 +++--
drivers/firmware/efi/vars.c| 61 +++--
drivers/rtc/Kconfig| 2 +-
drivers/rtc/rtc-efi.c | 1 +
include/linux/efi.h| 17 +++
include/linux/kernel.h | 1 +
lib/cmdline.c | 29 +
20 files changed, 528 insertions(+), 123 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 10d51c2..b5e55aa 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -992,10 +992,14 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Format: {"off" | "on" | "skip[mbr]"}
efi=[EFI]
- Format: { "old_map" }
+ Format: { "old_map", "nochunk", "noruntime" }
old_map [X86-64]: switch to the old ioremap-based EFI
runtime services mapping. 32-bit still uses this one by
default.
+ nochunk: disable reading files in "chunks" in the EFI
+ boot stub, as chunking can cause problems with some
+ firmware implementations.
+ noruntime : disable EFI runtime services support
efi_no_storage_paranoia [EFI; X86]
Using this parameter you can use more than 50% of
@@ -2166,7 +2170,7 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
nodsp [SH] Disable hardware DSP at boot time.
- noefi
RE: [PATCH] usb: serial: Fix indentation style issue
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Greg KH
> Sent: Wednesday, October 22, 2014 7:19 AM
>
> On Wed, Oct 22, 2014 at 11:51:12AM +0200, Johan Hovold wrote:
> > On Sat, Oct 11, 2014 at 07:20:49AM -0700, Greg Kroah-Hartman wrote:
> > > On Sat, Oct 11, 2014 at 03:49:43PM +0200, Philip Munksgaard wrote:
> > > > Fix a style issue
> > > >
> > > > Signed-off-by: Philip Munksgaard
> > > > ---
> > > > drivers/usb/serial/option.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> > > > index d1a3f60..d88998d 100644
> > > > --- a/drivers/usb/serial/option.c
> > > > +++ b/drivers/usb/serial/option.c
> > > > @@ -1616,7 +1616,7 @@ static const struct usb_device_id option_ids[] = {
> > > > { USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) },
> > > > { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
> > > > .driver_info = (kernel_ulong_t)&four_g_w14_blacklist
> > > > - },
> > > > + },
> > >
> > > Why not fix the same 'space' issue on the line before this at the same
> > > time?
> >
> > And what about the remaining white-space issues in this file? Do we
> > really want to go down this path?
>
> No, we don't, if you want to have patches be able to apply properly to
> older kernels, as you point out.
git-apply --ignore-whitespace ?
--
Paul
--
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: Touch processing on host CPU
On Fri, Oct 17, 2014 at 10:17 AM, Dmitry Torokhov wrote: > Hi Nick, > > On Fri, Oct 17, 2014 at 11:42:10AM +0100, Nick Dyer wrote: >> Hi- >> >> I'm trying to find out which subsystem maintainer I should be talking to - >> apologies if I'm addressing the wrong people. >> >> There is a model for doing touch processing where the touch controller >> becomes a much simpler device which sends out raw acquisitions (over SPI >> at up to 1Mbps + protocol overheads). All touch processing is then done in >> user space by the host CPU. An example of this is NVIDIA DirectTouch - see: >> http://blogs.nvidia.com/blog/2012/02/24/industry-adopts-nvidia-directtouch/ >> >> In the spirit of "upstream first", I'm trying to figure out how to get a >> driver accepted. Obviously it's not an input device in the normal sense. Is >> it acceptable just to send the raw touch data out via a char device? Is >> there another subsystem which is a good match (eg IIO)? Does the protocol >> (there is ancillary/control data as well) need to be documented? > > I'd really think *long* and *hard* about this. Even if you will have the > touch process open source you have 2 options: route it back into the > kernel through uinput, thus adding latency (which might be OK, need to > measure and decide), or go back about 10 years where we had > device-specific drivers in XFree86 and re-create them again, and also do > the same for Wayland, Chrome, Android, etc. > > If you will have touch processing in a binary blob, you'll also be going > to ages "Works with Ubuntu 12.04 on x86_32!" (and nothing else), or > "Android 5.1.2 on Tegra Blah (build 78912KT)" (and nothing else). I think we have some interest on the Chrome OS team. We've often had issues on touch devices with centroiding problems like split/merge, and have thought it might be nice to have lower level access to be able to actually solve these problems, rather than just complain to the touch vendor. Historically, however, raw touch heatmaps have not been available, making this idea unfeasible. Maybe this is starting to change with the push from Nvidia! I would agree with Dmitry that we would want a consistent unified interface that could work with different touch vendors. I am assuming that Nick's model is roughly 60-120 frames/sec, where each frame is NxMx16bits. Pixels would generally be ~4mm on a side for touch sensors today, but they may get significantly smaller if stylus becomes popular. Nick, is that roughly what you have in mind? Also, touch sensors generally have a baseline image that is subtracted from each recorded raw image to form the delta image (ie, raw - baseline = delta). Nick, do you envision sending raw or delta up to userspace? I would assume delta, b/c I think the touch controller will need to compute delta internally to see if there's a touch. It would be quite wasteful to invoke the kernel/userspace on an image with no touches. That said, there may be some situations (ie, factory validation) where getting raw images is preferred. Also, what about self-cap scan? I know some controllers will do self-cap when there's just one finger. I'm guessing the data for such a frame would be (N+M)x16bits. In order to support X, Wayland, Android, etc, I would assume that parsed frames would be injected back into the kernel in a format similar (identical?) to MT-B. As far as the availability of an open-source user-space driver to convert heat-map into MT-B, maybe I'm overly optimistic, but I would guess we could start with something simple like center-of-mass, and the community will help make it more robust. Sorry I have more questions than suggestions. Hopefully Nick can shed more light on what type of interface he would like. -andrew > > Thanks. > > -- > Dmitry > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] PM / clock_ops: Add pm_clk_add_clk()
On Wed, Oct 22, 2014 at 01:14:09PM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 22, 2014 at 10:02:41PM +0300, Grygorii Strashko wrote:
> > On 10/22/2014 08:38 PM, Dmitry Torokhov wrote:
> > >On Mon, Oct 20, 2014 at 03:56:02PM +0300, Grygorii Strashko wrote:
> > >>From: Geert Uytterhoeven
> > >>
> > >>The existing pm_clk_add() allows to pass a clock by con_id. However,
> > >>when referring to a specific clock from DT, no con_id is available.
> > >>
> > >>Add pm_clk_add_clk(), which allows to specify the struct clk * directly.
> > >>
> > >>Reviewed-by: Kevin Hilman
> > >>Signed-off-by: Geert Uytterhoeven
> > >>Signed-off-by: Grygorii Strashko
> > >>---
> > >>
> > >> Pay attantion pls, that there is another series of patches
> > >> which have been posted already and which depends from this patch
> > >>"[PATCH v4 0/3] ARM: rk3288 : Add PM Domain support"
> > >>https://lkml.org/lkml/2014/10/20/105
> > >>
> > >> drivers/base/power/clock_ops.c | 41
> > >> +++--
> > >> include/linux/pm_clock.h | 8
> > >> 2 files changed, 39 insertions(+), 10 deletions(-)
> > >>
> > >>diff --git a/drivers/base/power/clock_ops.c
> > >>b/drivers/base/power/clock_ops.c
> > >>index 7836930..f14b767 100644
> > >>--- a/drivers/base/power/clock_ops.c
> > >>+++ b/drivers/base/power/clock_ops.c
> > >>@@ -53,7 +53,8 @@ static inline int __pm_clk_enable(struct device *dev,
> > >>struct clk *clk)
> > >> */
> > >> static void pm_clk_acquire(struct device *dev, struct pm_clock_entry
> > >> *ce)
> > >> {
> > >>- ce->clk = clk_get(dev, ce->con_id);
> > >>+ if (!ce->clk)
> > >>+ ce->clk = clk_get(dev, ce->con_id);
> > >> if (IS_ERR(ce->clk)) {
> > >> ce->status = PCE_STATUS_ERROR;
> > >> } else {
> > >>@@ -63,15 +64,8 @@ static void pm_clk_acquire(struct device *dev, struct
> > >>pm_clock_entry *ce)
> > >> }
> > >> }
> > >>
> > >>-/**
> > >>- * pm_clk_add - Start using a device clock for power management.
> > >>- * @dev: Device whose clock is going to be used for power management.
> > >>- * @con_id: Connection ID of the clock.
> > >>- *
> > >>- * Add the clock represented by @con_id to the list of clocks used for
> > >>- * the power management of @dev.
> > >>- */
> > >>-int pm_clk_add(struct device *dev, const char *con_id)
> > >>+static int __pm_clk_add(struct device *dev, const char *con_id,
> > >>+ struct clk *clk)
> > >> {
> > >> struct pm_subsys_data *psd = dev_to_psd(dev);
> > >> struct pm_clock_entry *ce;
> > >>@@ -93,6 +87,8 @@ int pm_clk_add(struct device *dev, const char *con_id)
> > >> kfree(ce);
> > >> return -ENOMEM;
> > >> }
> > >>+ } else {
> > >>+ ce->clk = clk;
Shouldn't this be
ce->clk = __clk_get(clk);
to account for clk_put() in __pm_clk_remove()?
> > >> }
> > >>
> > >> pm_clk_acquire(dev, ce);
> > >>@@ -104,6 +100,31 @@ int pm_clk_add(struct device *dev, const char
> > >>*con_id)
> > >> }
> > >>
> > >> /**
> > >>+ * pm_clk_add - Start using a device clock for power management.
> > >>+ * @dev: Device whose clock is going to be used for power management.
> > >>+ * @con_id: Connection ID of the clock.
> > >>+ *
> > >>+ * Add the clock represented by @con_id to the list of clocks used for
> > >>+ * the power management of @dev.
> > >>+ */
> > >>+int pm_clk_add(struct device *dev, const char *con_id)
> > >>+{
> > >>+ return __pm_clk_add(dev, con_id, NULL);
> > >
> > >Bikeshedding: why do we need __pm_clk_add() and not simply have
> > >"canonical" pm_clk_add_clk() and then do:
> > >
> > >int pm_clk_add(struct device *dev, const char *con_id)
> > >{
> > > struct clk *clk;
> > >
> > > clk = clk_get(dev, con_id);
> > > ...
> > > return pm_clk_add_clk(dev, clk);
> > >}
> >
> > Hm. I did fast look at code and:
> > 1) agree - there is a lot of thing which can be optimized ;)
> > 2) in my strong opinion, this patch is the fastest and simplest
> > way to introduce new API (take a look on pm_clock_entry->con_id
> > management code) and It is exactly what we need as of now.
>
> Yeah, I guess. We are lucky we do not crash when we are tryign to print
> NULL strings (see pm_clk_acquire).
>
> BTW, what is the point of doing pm_clk_add(dev, NULL)? We add clock
> entry with status PCE_STATUS_ERROR and then have to handle it
> everywhere? Can we just return -EINVAL if someone triies to pass NULL
> ass con_id?
Umm, no, ignore me here, I misread clk_get(dev, NULL) - it won't return
error. Still, do why do we need to keep clock entry if clk_get() fails
for some reason?
Thanks.
--
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 v3 58/59] dmaengine: Add a warning for drivers not using the generic slave caps retrieval
Hi Maxime, Thank you for the patch. On Wednesday 22 October 2014 17:44:12 Maxime Ripard wrote: > For the slave caps retrieval to be really useful, most drivers need to > implement it. > > Hence, we need to be slightly more aggressive, and trigger a warning at > registration time for drivers that don't fill their caps infos in order to > encourage them to implement it. > > Signed-off-by: Maxime Ripard > --- > drivers/dma/dmaengine.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c > index 98e9431f85ec..4e18981b16bd 100644 > --- a/drivers/dma/dmaengine.c > +++ b/drivers/dma/dmaengine.c > @@ -827,6 +827,9 @@ int dma_async_device_register(struct dma_device *device) > BUG_ON(!device->device_issue_pending); > BUG_ON(!device->dev); > > + WARN(dma_has_cap(DMA_SLAVE, device->cap_mask) && > !device->generic_slave_caps, > + "this driver doesn't support generic slave capabilities > reporting\n"); > + This might be slightly too aggressive. I agree with your previous comment on all DMA engine drivers returning the same capabilities for all channels, but it might not be true anymore in the future, in which case drivers will need to implement a custom slave caps function. We could delay support for that to when it's needed though. > /* note: this only matters in the >* CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH=n case >*/ -- Regards, Laurent Pinchart -- 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 59/59] dmaengine: Remove device_control and device_slave_caps
Hi Maxime,
Thank you for the patch.
On Wednesday 22 October 2014 17:44:13 Maxime Ripard wrote:
> Now that device_control has been split into several functions, and
> device_slave_caps rendered useless, we can safely remove them.
>
> Signed-off-by: Maxime Ripard
Assuming you haven't forgotten any caller of dmaengine_device_control,
Acked-by: Laurent Pinchart
> ---
> include/linux/dmaengine.h | 52 ++--
> 1 file changed, 6 insertions(+), 46 deletions(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 98f8163dfbac..c157857a40e0 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -189,25 +189,6 @@ enum dma_ctrl_flags {
> };
>
> /**
> - * enum dma_ctrl_cmd - DMA operations that can optionally be exercised
> - * on a running channel.
> - * @DMA_TERMINATE_ALL: terminate all ongoing transfers
> - * @DMA_PAUSE: pause ongoing transfers
> - * @DMA_RESUME: resume paused transfer
> - * @DMA_SLAVE_CONFIG: this command is only implemented by DMA controllers
> - * that need to runtime reconfigure the slave channels (as opposed to
> passing - * configuration data in statically from the platform). An
> additional - * argument of struct dma_slave_config must be passed in with
> this - * command.
> - */
> -enum dma_ctrl_cmd {
> - DMA_TERMINATE_ALL,
> - DMA_PAUSE,
> - DMA_RESUME,
> - DMA_SLAVE_CONFIG,
> -};
> -
> -/**
> * enum sum_check_bits - bit position of pq_check_flags
> */
> enum sum_check_bits {
> @@ -336,9 +317,8 @@ enum dma_slave_buswidth {
> * This struct is passed in as configuration data to a DMA engine
> * in order to set up a certain channel for DMA transport at runtime.
> * The DMA device/engine has to provide support for an additional
> - * command in the channel config interface, DMA_SLAVE_CONFIG
> - * and this struct will then be passed in as an argument to the
> - * DMA engine device_control() function.
> + * callback in the dma_device structure, device_config and this struct
> + * will then be passed in as an argument to the function.
> *
> * The rationale for adding configuration information to this struct is as
> * follows: if it is likely that more than one DMA slave controllers in
> @@ -617,8 +597,6 @@ struct dma_tx_state {
> * @device_prep_interleaved_dma: Transfer expression in a generic way.
> * @device_config: Pushes a new configuration to a channel, return 0 or an
> error * code
> - * @device_control: manipulate all pending operations on a channel, returns
> - * zero or error code
> * @device_pause: Pauses any transfer happening on a channel. Returns
> * 0 or an error code
> * @device_resume: Resumes any transfer on a channel previously
> @@ -630,7 +608,6 @@ struct dma_tx_state {
> * struct with auxiliary transfer status information, otherwise the call
> * will just return a simple status code
> * @device_issue_pending: push pending transactions to hardware
> - * @device_slave_caps: return the slave channel capabilities
> */
> struct dma_device {
>
> @@ -698,8 +675,6 @@ struct dma_device {
>
> int (*device_config)(struct dma_chan *chan,
>struct dma_slave_config *config);
> - int (*device_control)(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> - unsigned long arg);
> int (*device_pause)(struct dma_chan *chan);
> int (*device_resume)(struct dma_chan *chan);
> int (*device_terminate_all)(struct dma_chan *chan);
> @@ -708,27 +683,15 @@ struct dma_device {
> dma_cookie_t cookie,
> struct dma_tx_state *txstate);
> void (*device_issue_pending)(struct dma_chan *chan);
> - int (*device_slave_caps)(struct dma_chan *chan, struct dma_slave_caps
> *caps); };
>
> -static inline int dmaengine_device_control(struct dma_chan *chan,
> -enum dma_ctrl_cmd cmd,
> -unsigned long arg)
> -{
> - if (chan->device->device_control)
> - return chan->device->device_control(chan, cmd, arg);
> -
> - return -ENOSYS;
> -}
> -
> static inline int dmaengine_slave_config(struct dma_chan *chan,
> struct dma_slave_config *config)
> {
> if (chan->device->device_config)
> return chan->device->device_config(chan, config);
>
> - return dmaengine_device_control(chan, DMA_SLAVE_CONFIG,
> - (unsigned long)config);
> + return -ENOSYS;
> }
>
> static inline bool is_slave_direction(enum dma_transfer_direction
> direction) @@ -808,9 +771,6 @@ static inline int dma_get_slave_caps(struct
> dma_chan *chan, struct dma_slave_cap if (!test_bit(DMA_SLAVE,
> device->cap_mask.bits))
> return -ENXIO;
>
> - if (device->device_slave_caps)
> - return device->device_slave_caps(chan, caps);
> -
> /
[PATCH v2] staging: rtl8712: Remove redundant cast
struct firmware::data has type const u8*, as does *ppmappedfw, so the cast to u8* is unnecessary and slightly confusing. Signed-off-by: Rasmus Villemoes --- drivers/staging/rtl8712/hal_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/hal_init.c b/drivers/staging/rtl8712/hal_init.c index 1d6ade0..83f9341 100644 --- a/drivers/staging/rtl8712/hal_init.c +++ b/drivers/staging/rtl8712/hal_init.c @@ -86,7 +86,7 @@ static u32 rtl871x_open_fw(struct _adapter *padapter, const u8 **ppmappedfw) (int)padapter->fw->size); return 0; } - *ppmappedfw = (u8 *)((*praw)->data); + *ppmappedfw = (*praw)->data; return (*praw)->size; } -- 2.0.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/
[PATCH v5 3/4] fuse: Restrict allow_other to the superblock's namespace or a descendant
Unprivileged users are normally restricted from mounting with the
allow_other option by system policy, but this could be bypassed
for a mount done with user namespace root permissions. In such
cases allow_other should not allow users outside the userns
to access the mount as doing so would give the unprivileged user
the ability to manipulate processes it would otherwise be unable
to manipulate. Therefore access with allow_other should be
restricted to users in the userns as the superblock or a
descendant of that namespace.
Cc: Eric W. Biederman
Cc: Serge H. Hallyn
Cc: Andy Lutomirski
Signed-off-by: Seth Forshee
---
fs/fuse/dir.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 123db1e06c78..b23ec5c1ff18 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1091,8 +1091,14 @@ int fuse_allow_current_process(struct fuse_conn *fc)
{
const struct cred *cred;
- if (fc->flags & FUSE_ALLOW_OTHER)
- return 1;
+ if (fc->flags & FUSE_ALLOW_OTHER) {
+ struct user_namespace *ns;
+ for (ns = current_user_ns(); ns; ns = ns->parent) {
+ if (ns == fc->user_ns)
+ return 1;
+ }
+ return 0;
+ }
cred = current_cred();
if (uid_eq(cred->euid, fc->user_id) &&
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/4] fuse: Support fuse filesystems outside of init_user_ns
Update fuse to translate uids and gids to/from the user namspace
of the process servicing requests on /dev/fuse. Any ids which do
not map into the namespace will result in errors. inodes will
also be marked bad when unmappable ids are received from
userspace.
Due to security concerns the namespace used should be fixed,
otherwise a user might be able to gain elevated privileges or
influence processes that the user would otherwise be unable to
manipulate. Thus the namespace of the mounting process is used
for all translations, and this namespace is required to be the
same as the one in use when /dev/fuse was opened.
Cc: Eric W. Biederman
Cc: Serge H. Hallyn
Cc: Andy Lutomirski
Signed-off-by: Seth Forshee
---
fs/fuse/dev.c| 4 +--
fs/fuse/dir.c| 81
fs/fuse/fuse_i.h | 12 ++---
fs/fuse/inode.c | 73 +++---
4 files changed, 121 insertions(+), 49 deletions(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 839caebd34f1..03c8785ed731 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -127,8 +127,8 @@ static void __fuse_put_request(struct fuse_req *req)
static void fuse_req_init_context(struct fuse_conn *fc, struct fuse_req *req)
{
- req->in.h.uid = from_kuid_munged(&init_user_ns, current_fsuid());
- req->in.h.gid = from_kgid_munged(&init_user_ns, current_fsgid());
+ req->in.h.uid = from_kuid_munged(fc->user_ns, current_fsuid());
+ req->in.h.gid = from_kgid_munged(fc->user_ns, current_fsgid());
req->in.h.pid = pid_nr_ns(task_pid(current), fc->pid_ns);
}
diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index de1d84af9f7c..123db1e06c78 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -253,9 +253,12 @@ static int fuse_dentry_revalidate(struct dentry *entry,
unsigned int flags)
if (err || (outarg.attr.mode ^ inode->i_mode) & S_IFMT)
goto invalid;
- fuse_change_attributes(inode, &outarg.attr,
- entry_attr_timeout(&outarg),
- attr_version);
+ err = fuse_change_attributes(inode, &outarg.attr,
+entry_attr_timeout(&outarg),
+attr_version);
+ if (err)
+ goto invalid;
+
fuse_change_entry_timeout(entry, &outarg);
} else if (inode) {
fi = get_fuse_inode(inode);
@@ -340,8 +343,9 @@ int fuse_lookup_name(struct super_block *sb, u64 nodeid,
struct qstr *name,
*inode = fuse_iget(sb, outarg->nodeid, outarg->generation,
&outarg->attr, entry_attr_timeout(outarg),
attr_version);
- err = -ENOMEM;
- if (!*inode) {
+ if (IS_ERR(*inode)) {
+ err = PTR_ERR(*inode);
+ *inode = NULL;
fuse_queue_forget(fc, forget, outarg->nodeid, 1);
goto out;
}
@@ -473,11 +477,11 @@ static int fuse_create_open(struct inode *dir, struct
dentry *entry,
ff->open_flags = outopen.open_flags;
inode = fuse_iget(dir->i_sb, outentry.nodeid, outentry.generation,
&outentry.attr, entry_attr_timeout(&outentry), 0);
- if (!inode) {
+ if (IS_ERR(inode)) {
flags &= ~(O_CREAT | O_EXCL | O_TRUNC);
fuse_sync_release(ff, flags);
fuse_queue_forget(fc, forget, outentry.nodeid, 1);
- err = -ENOMEM;
+ err = PTR_ERR(inode);
goto out_err;
}
kfree(forget);
@@ -588,9 +592,9 @@ static int create_new_entry(struct fuse_conn *fc, struct
fuse_req *req,
inode = fuse_iget(dir->i_sb, outarg.nodeid, outarg.generation,
&outarg.attr, entry_attr_timeout(&outarg), 0);
- if (!inode) {
+ if (IS_ERR(inode)) {
fuse_queue_forget(fc, forget, outarg.nodeid, 1);
- return -ENOMEM;
+ return PTR_ERR(inode);
}
kfree(forget);
@@ -905,8 +909,8 @@ static void fuse_fillattr(struct inode *inode, struct
fuse_attr *attr,
stat->ino = attr->ino;
stat->mode = (inode->i_mode & S_IFMT) | (attr->mode & 0);
stat->nlink = attr->nlink;
- stat->uid = make_kuid(&init_user_ns, attr->uid);
- stat->gid = make_kgid(&init_user_ns, attr->gid);
+ stat->uid = inode->i_uid;
+ stat->gid = inode->i_gid;
stat->rdev = inode->i_rdev;
stat->atime.tv_sec = attr->atime;
stat->atime.tv_nsec = attr->atimensec;
@@ -969,10 +973,10 @@ static int fuse_do_getattr(struct inode *inode, struct
kstat *stat,
make_bad_inode(inode);
err = -EIO;
} else {
- fuse_change_attributes(inode, &outarg.attr,
-
[PATCH v5 4/4] fuse: Allow user namespace mounts
Cc: Eric W. Biederman
Cc: Serge H. Hallyn
Cc: Andy Lutomirski
Signed-off-by: Seth Forshee
---
fs/fuse/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index b88b5a780228..7d0e73e36e7b 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -1201,7 +1201,7 @@ static void fuse_kill_sb_anon(struct super_block *sb)
static struct file_system_type fuse_fs_type = {
.owner = THIS_MODULE,
.name = "fuse",
- .fs_flags = FS_HAS_SUBTYPE,
+ .fs_flags = FS_HAS_SUBTYPE | FS_USERNS_MOUNT,
.mount = fuse_mount,
.kill_sb= fuse_kill_sb_anon,
};
@@ -1233,7 +1233,7 @@ static struct file_system_type fuseblk_fs_type = {
.name = "fuseblk",
.mount = fuse_mount_blk,
.kill_sb= fuse_kill_sb_blk,
- .fs_flags = FS_REQUIRES_DEV | FS_HAS_SUBTYPE,
+ .fs_flags = FS_REQUIRES_DEV | FS_HAS_SUBTYPE | FS_USERNS_MOUNT,
};
MODULE_ALIAS_FS("fuseblk");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/4] fuse: Add support for pid namespaces
If the userspace process servicing fuse requests is running in
a pid namespace then pids passed via the fuse fd need to be
translated relative to that namespace. Capture the pid namespace
in use when the filesystem is mounted and use this for pid
translation.
File locking changes based on previous work done by Eric
Biederman.
Cc: Eric W. Biederman
Cc: Serge H. Hallyn
Cc: Andy Lutomirski
Signed-off-by: Seth Forshee
---
fs/fuse/dev.c| 9 +
fs/fuse/file.c | 38 +++---
fs/fuse/fuse_i.h | 4
fs/fuse/inode.c | 4
4 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index ca887314aba9..839caebd34f1 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
MODULE_ALIAS_MISCDEV(FUSE_MINOR);
MODULE_ALIAS("devname:fuse");
@@ -124,11 +125,11 @@ static void __fuse_put_request(struct fuse_req *req)
atomic_dec(&req->count);
}
-static void fuse_req_init_context(struct fuse_req *req)
+static void fuse_req_init_context(struct fuse_conn *fc, struct fuse_req *req)
{
req->in.h.uid = from_kuid_munged(&init_user_ns, current_fsuid());
req->in.h.gid = from_kgid_munged(&init_user_ns, current_fsgid());
- req->in.h.pid = current->pid;
+ req->in.h.pid = pid_nr_ns(task_pid(current), fc->pid_ns);
}
static bool fuse_block_alloc(struct fuse_conn *fc, bool for_background)
@@ -168,7 +169,7 @@ static struct fuse_req *__fuse_get_req(struct fuse_conn
*fc, unsigned npages,
goto out;
}
- fuse_req_init_context(req);
+ fuse_req_init_context(fc, req);
req->waiting = 1;
req->background = for_background;
return req;
@@ -257,7 +258,7 @@ struct fuse_req *fuse_get_req_nofail_nopages(struct
fuse_conn *fc,
if (!req)
req = get_reserved_req(fc, file);
- fuse_req_init_context(req);
+ fuse_req_init_context(fc, req);
req->waiting = 1;
req->background = 0;
return req;
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index caa8d95b24e8..cb0e40ecc362 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2131,7 +2131,8 @@ static int fuse_direct_mmap(struct file *file, struct
vm_area_struct *vma)
return generic_file_mmap(file, vma);
}
-static int convert_fuse_file_lock(const struct fuse_file_lock *ffl,
+static int convert_fuse_file_lock(struct fuse_conn *fc,
+ const struct fuse_file_lock *ffl,
struct file_lock *fl)
{
switch (ffl->type) {
@@ -2146,7 +2147,11 @@ static int convert_fuse_file_lock(const struct
fuse_file_lock *ffl,
fl->fl_start = ffl->start;
fl->fl_end = ffl->end;
- fl->fl_pid = ffl->pid;
+ rcu_read_lock();
+ fl->fl_pid = pid_vnr(find_pid_ns(ffl->pid, fc->pid_ns));
+ rcu_read_unlock();
+ if (ffl->pid != 0 && fl->fl_pid == 0)
+ return -EIO;
break;
default:
@@ -2156,9 +2161,9 @@ static int convert_fuse_file_lock(const struct
fuse_file_lock *ffl,
return 0;
}
-static void fuse_lk_fill(struct fuse_req *req, struct file *file,
-const struct file_lock *fl, int opcode, pid_t pid,
-int flock)
+static int fuse_lk_fill(struct fuse_req *req, struct file *file,
+const struct file_lock *fl, int opcode,
+struct pid *pid, int flock)
{
struct inode *inode = file_inode(file);
struct fuse_conn *fc = get_fuse_conn(inode);
@@ -2170,7 +2175,9 @@ static void fuse_lk_fill(struct fuse_req *req, struct
file *file,
arg->lk.start = fl->fl_start;
arg->lk.end = fl->fl_end;
arg->lk.type = fl->fl_type;
- arg->lk.pid = pid;
+ arg->lk.pid = pid_nr_ns(pid, fc->pid_ns);
+ if (pid && arg->lk.pid == 0)
+ return -EOVERFLOW;
if (flock)
arg->lk_flags |= FUSE_LK_FLOCK;
req->in.h.opcode = opcode;
@@ -2178,6 +2185,8 @@ static void fuse_lk_fill(struct fuse_req *req, struct
file *file,
req->in.numargs = 1;
req->in.args[0].size = sizeof(*arg);
req->in.args[0].value = arg;
+
+ return 0;
}
static int fuse_getlk(struct file *file, struct file_lock *fl)
@@ -2192,16 +2201,19 @@ static int fuse_getlk(struct file *file, struct
file_lock *fl)
if (IS_ERR(req))
return PTR_ERR(req);
- fuse_lk_fill(req, file, fl, FUSE_GETLK, 0, 0);
+ err = fuse_lk_fill(req, file, fl, FUSE_GETLK, NULL, 0);
+ if (err)
+ goto out;
req->out.numargs = 1;
req->out.args[0].size = sizeof(outarg);
req->out.args[0].value = &outarg;
fuse_request_send(fc, req);
err = req->out.h.error;
- fuse_put_request(fc, req);
if (!err)
-
[PATCH v5 0/4] fuse: Add support for mounts from pid/user namespaces
Here's another update to the patches to enable userns mounts in fuse. The changes this time around center on xattrs and allow_other. I'm considering the following patch to be a prerequisite for this series: http://lkml.kernel.org/g/252a4d87d99fc2b5fe4411c838f65b312c4e13cd.1413330857.git.l...@amacapital.net With this patch I'm dropping the xattr restrictions from the v4 patches. This leaves the situation with xattrs unchanged in init_user_ns. A fuse userns mount could still supply xattrs which the user would normally be unable to set, but since the mount will be inaccessible outside of that userns or its descendants those xattrs will never be seen by the host. I'm also in agreement with Andy that some decision regarding this patch should be made before merging the fuse userns support as well: http://lkml.kernel.org/g/2686c32f00b14148379e8cfee9c028c794d4aa1a.1407974494.git.l...@amacapital.net Changes since v4: - Drop patch to restrict xattrs - Update allow_other to restrict based on userns of current rather than uid/gid Thanks, Seth Seth Forshee (4): fuse: Add support for pid namespaces fuse: Support fuse filesystems outside of init_user_ns fuse: Restrict allow_other to the superblock's namespace or a descendant fuse: Allow user namespace mounts fs/fuse/dev.c| 13 fs/fuse/dir.c| 91 +--- fs/fuse/file.c | 38 --- fs/fuse/fuse_i.h | 16 +++--- fs/fuse/inode.c | 81 ++--- 5 files changed, 171 insertions(+), 68 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: [PATCH v3 04/59] dmaengine: Rework dma_chan_get
Hi Maxime,
Thank you for the patch.
On Wednesday 22 October 2014 17:43:18 Maxime Ripard wrote:
> dma_chan_get uses a rather interesting error handling and code path.
>
> Change it to something more usual in the kernel.
>
> Signed-off-by: Maxime Ripard
Acked-by: Laurent Pinchart
> ---
> drivers/dma/dmaengine.c | 36 +++-
> 1 file changed, 19 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 24bfaf0b92ba..72f10e2f5c32 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -222,31 +222,33 @@ static void balance_ref_count(struct dma_chan *chan)
> */
> static int dma_chan_get(struct dma_chan *chan)
> {
> - int err = -ENODEV;
> struct module *owner = dma_chan_to_owner(chan);
> + int ret;
>
> + /* The channel is already in use, update client count */
> if (chan->client_count) {
> __module_get(owner);
> - err = 0;
> - } else if (try_module_get(owner))
> - err = 0;
> + goto out;
> + }
>
> - if (err == 0)
> - chan->client_count++;
> + if (!try_module_get(owner))
> + return -ENODEV;
>
> /* allocate upon first client reference */
> - if (chan->client_count == 1 && err == 0) {
> - int desc_cnt = chan->device->device_alloc_chan_resources(chan);
> -
> - if (desc_cnt < 0) {
> - err = desc_cnt;
> - chan->client_count = 0;
> - module_put(owner);
> - } else if (!dma_has_cap(DMA_PRIVATE, chan->device->cap_mask))
> - balance_ref_count(chan);
> - }
> + ret = chan->device->device_alloc_chan_resources(chan);
> + if (ret < 0)
> + goto err_out;
>
> - return err;
> + if (!dma_has_cap(DMA_PRIVATE, chan->device->cap_mask))
> + balance_ref_count(chan);
> +
> +out:
> + chan->client_count++;
> + return 0;
> +
> +err_out:
> + module_put(owner);
> + return ret;
> }
>
> /**
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping.
Hi Marcel,
I'm not quite clear on what the objective is here, so I apologize for
some questions that probably seem silly.
On Mon, Oct 20, 2014 at 8:04 AM, Marcel Apfelbaum wrote:
> Scanning a lot of devices during boot requires a lot of time.
I think what takes a lot of time is the .probe() method for some
drivers, right? I first thought you meant that it took a long time
for the PCI core to enumerate a lot of devices, but you're not
changing anything there.
If the intent is to reduce boot time, I don't think this is a general
solution. Drivers should be able to schedule asynchronous things in
their .probe() methods if necessary.
> On other scenarios there is a need to bind a driver to a specific slot.
A short example here would be good. Are you talking about something
like binding a NIC driver to one device while leaving others unbound
for use by guests?
> Binding devices to pci-stub driver does not work,
> as it will not differentiate between devices of the
> same type.
I assume you mean booting with "pci-stub.ids=$VENDOR:$DEVICE" will
make pci-stub bind to *all* matching devices, and you only want it to
bind to some. Maybe pci-stub could be extended to pay attention to
PCI bus addresses in addition to vendor/device IDs.
> Using some start scripts is error prone.
>
> The solution leverages driver_override functionality introduced by
>
> commit: 782a985d7af26db39e86070d28f987cad21313c0
> Author: Alex Williamson
> Date: Tue May 20 08:53:21 2014 -0600
>
> PCI: Introduce new device binding path using pci_dev.driver_override
>
> In order to bind PCI slots to specific drivers use:
> pci=driver[:xx:xx.x]=foo,driver[:xx:xx.x]=bar,...
If/when you address Alex's comments about other bus types, can you
also update the changelog to use the canonical commit reference
format, i.e., 782a985d7af2 ("PCI: Introduce new device binding path
using pci_dev.driver_override") in this case?
PCI bus numbers are mutable, e.g., they can change with hotplug or
other configuration changes. But I don't have any better suggestion,
so I guess all we can do is be aware of this.
Speaking of hotplug, this is only a boot-time kernel parameter, with
no opportunity to use this, e.g., to add slot/driver pairs, after
boot. Do you not need that because of Alex's driver_override thing?
How can we integrate this all together into a coherent whole? I'm a
little confused as to how this would all be documented in a form
usable by end-users.
Bjorn
--
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 22/47] power/reset: restart-poweroff: Register with kernel poweroff handler
Hi, On Mon, Oct 20, 2014 at 09:12:38PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Register as poweroff handler of last resort since the driver > does not really power off the system but executes a restart. > > Drop remove function since it is no longer needed. > > Cc: Sebastian Reichel > Cc: Dmitry Eremin-Solenikov > Cc: David Woodhouse > Acked-by: Andrew Lunn > Signed-off-by: Guenter Roeck Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2 23/47] power/reset: gpio-poweroff: Register with kernel poweroff handler
Hi, On Mon, Oct 20, 2014 at 09:12:39PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Register with low priority to reflect that the original code > only sets pm_power_off if it was not already set. > > Other changes: > > Drop note that there can not be an additional instance of this driver. > The original reason no longer applies, it should be obvious that there > can only be one instance of the driver if static variables are used to > reflect its state, and support for multiple instances can now be added > easily if needed by avoiding static variables. > > Do not create an error message if another poweroff handler has already > been registered. This is perfectly normal and acceptable. > > Drop remove function since it is no longer needed. > > Cc: Sebastian Reichel > Cc: Dmitry Eremin-Solenikov > Cc: David Woodhouse > Acked-by: Andrew Lunn > Signed-off-by: Guenter Roeck Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2 25/47] power/reset: qnap-poweroff: Register with kernel poweroff handler
Hi, On Mon, Oct 20, 2014 at 09:12:41PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Register with default priority to reflect that the original > code generates an error if another poweroff handler has already been > registered when the driver is loaded. > > Drop remove function since it is no longer needed. > > Cc: Sebastian Reichel > Cc: Dmitry Eremin-Solenikov > Cc: David Woodhouse > Acked-by: Andrew Lunn > Signed-off-by: Guenter Roeck Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2 24/47] power/reset: as3722-poweroff: Register with kernel poweroff handler
Hi, On Mon, Oct 20, 2014 at 09:12:40PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Register with low priority to reflect that the original code > only sets pm_power_off if it was not already set. > > Drop remove function since it is no longer needed. > > Cc: Sebastian Reichel > Cc: Dmitry Eremin-Solenikov > Cc: David Woodhouse > Signed-off-by: Guenter Roeck Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2 26/47] power/reset: msm-poweroff: Register with kernel poweroff handler
Hi, On Mon, Oct 20, 2014 at 09:12:42PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Select fallback priority since the code does not really poweroff > the system but resets it instead. > > Signed-off-by: Guenter Roeck Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2 27/47] power/reset: vexpress-poweroff: Register with kernel poweroff handler
Hi, On Mon, Oct 20, 2014 at 09:12:43PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Select default priority to reflect that the original code sets > pm_power_off unconditionally. > > Signed-off-by: Guenter Roeck Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
introduce task_rcu_dereference?
On 10/22, Kirill Tkhai wrote:
>
> Unlocked access to dst_rq->curr in task_numa_compare() is racy.
> If curr task is exiting this may be a reason of use-after-free:
Thanks.
And as you pointed out, there are other examples of unlocked
foreign_rq->curr usage.
So, Kirill, Peter, do you think that the patch below can help? Can
we change task_numa_group() and ->select_task_rq() to do nothing if
rq_curr_rcu_safe() returns NULL? It seems we can...
task_numa_compare() can use it too, we can make another patch on
top of this one.
- Obviously just for the early review. Lacks the changelog
and the comments (at least).
- Once again, I won't insist on probe_slab_address(). We can
add SDBR and change task_rcu_dereference() to simply read
->sighand.
- Also, I won't argue if you think that we do not need a
generic helper. In this case we can move this logic into
rq_curr_rcu_safe() and it will be a bit simpler.
- OTOH, I am not sure we need rq_curr_rcu_safe(). The callers
can just use task_rcu_dereference() and check IS_ERR_OR_NULL,
I guess retry doesn't buy too much in this case.
Or do you think we need something else?
Oleg.
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 857ba40..0ba420e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2300,6 +2300,7 @@ extern void block_all_signals(int (*notifier)(void
*priv), void *priv,
sigset_t *mask);
extern void unblock_all_signals(void);
extern void release_task(struct task_struct * p);
+extern struct task_struct *task_rcu_dereference(struct task_struct **ptask);
extern int send_sig_info(int, struct siginfo *, struct task_struct *);
extern int force_sigsegv(int, struct task_struct *);
extern int force_sig_info(int, struct siginfo *, struct task_struct *);
diff --git a/kernel/exit.c b/kernel/exit.c
index 32c58f7..4aa00c7 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -213,6 +213,37 @@ repeat:
goto repeat;
}
+struct task_struct *task_rcu_dereference(struct task_struct **ptask)
+{
+ struct task_struct *task;
+ struct sighand_struct *sighand;
+
+ task = rcu_dereference(*ptask);
+ if (!task)
+ return NULL;
+
+ /* If it fails the check below must fail too */
+ probe_slab_address(&task->sighand, sighand);
+ /*
+* Pairs with atomic_dec_and_test() in put_task_struct(task).
+* If we have read the freed/reused memory, we must see that
+* the pointer was updated. The caller might want to retry in
+* this case.
+*/
+ smp_rmb();
+ if (unlikely(task != ACCESS_ONCE(*ptask)))
+ return ERR_PTR(-EAGAIN);
+
+ /*
+* release_task(task) was already called; potentially before
+* the caller took rcu_read_lock() and in this case it can be
+* freed before rcu_read_unlock().
+*/
+ if (!sighand)
+ return ERR_PTR(-EINVAL);
+ return task;
+}
+
/*
* This checks not only the pgrp, but falls back on the pid if no
* satisfactory pgrp is found. I dunno - gdb doesn't work correctly
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 579712f..249c0c1 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -655,6 +655,18 @@ DECLARE_PER_CPU(struct rq, runqueues);
#define cpu_curr(cpu) (cpu_rq(cpu)->curr)
#define raw_rq() (&__raw_get_cpu_var(runqueues))
+static inline struct task_struct *rq_curr_rcu_safe(struct rq *rq)
+{
+ for (;;) {
+ struct task_struct *curr = task_rcu_dereference(&rq->curr);
+ /* NULL is not possible */
+ if (likely(!IS_ERR(curr)))
+ return curr;
+ if (PTR_ERR(curr) != -EAGAIN)
+ return NULL;
+ }
+}
+
static inline u64 rq_clock(struct rq *rq)
{
return rq->clock;
--
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 29/47] power/reset: ltc2952-poweroff: Register with kernel poweroff handler
Hi, On Mon, Oct 20, 2014 at 09:12:45PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Register with low priority to reflect that the original code > sets pm_power_off only if it was not already set. > > Signed-off-by: Guenter Roeck Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2 28/47] power/reset: at91-poweroff: Register with kernel poweroff handler
Hi, On Mon, Oct 20, 2014 at 09:12:44PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Select default priority to reflect that the original code sets > pm_power_off unconditionally. > > Signed-off-by: Guenter Roeck Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface
On Wed, 22 Oct 2014, Eric Paris wrote: > That's really serious. Looking now. Indeed its serious. And it's even more serious as this masterpiece of assembly wreckage was pulled in via your tree w/o having an acked-by one of the x86 maintainers. > On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote: > > commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a > > Author: Richard Guy Briggs > > Date: Tue Mar 4 10:38:06 2014 -0500 > > audit: x86: drop arch from __audit_syscall_entry() interface > > > > According to our QA, their i386 machine doesn't boot anymore. I tried > > to write my own revert for the patch, asked QA to test, and they > > confirmed it "solves" the problem. diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index 0d0c9d4ab6d5..f9e3fabc8716 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -449,12 +449,11 @@ sysenter_audit: jnz syscall_trace_entry addl $4,%esp CFI_ADJUST_CFA_OFFSET -4 - /* %esi already in 8(%esp) 6th arg: 4th syscall arg */ - /* %edx already in 4(%esp) 5th arg: 3rd syscall arg */ - /* %ecx already in 0(%esp) 4th arg: 2nd syscall arg */ - movl %ebx,%ecx /* 3rd arg: 1st syscall arg */ - movl %eax,%edx /* 2nd arg: syscall number */ - movl $AUDIT_ARCH_I386,%eax /* 1st arg: audit arch */ + movl %esi,4(%esp) /* 5th arg: 4th syscall arg */ + movl %edx,(%esp)/* 4th arg: 3rd syscall arg */ Bilndly overwriting the stack which holds the syscall arguments is really a brilliant way to ensure security. Thanks, tglx -- 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: Regression: audit: x86: drop arch from __audit_syscall_entry() interface
On Wed, 2014-10-22 at 23:36 +0200, Thomas Gleixner wrote: > On Wed, 22 Oct 2014, Eric Paris wrote: > > > That's really serious. Looking now. > > Indeed its serious. And it's even more serious as this masterpiece of > assembly wreckage was pulled in via your tree w/o having an acked-by > one of the x86 maintainers. > > > On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote: > > > commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a > > > Author: Richard Guy Briggs > > > Date: Tue Mar 4 10:38:06 2014 -0500 > > > audit: x86: drop arch from __audit_syscall_entry() interface > > > > > > According to our QA, their i386 machine doesn't boot anymore. I tried > > > to write my own revert for the patch, asked QA to test, and they > > > confirmed it "solves" the problem. > > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S > index 0d0c9d4ab6d5..f9e3fabc8716 100644 > --- a/arch/x86/kernel/entry_32.S > +++ b/arch/x86/kernel/entry_32.S > @@ -449,12 +449,11 @@ sysenter_audit: > jnz syscall_trace_entry > addl $4,%esp > CFI_ADJUST_CFA_OFFSET -4 > - /* %esi already in 8(%esp) 6th arg: 4th syscall arg */ > - /* %edx already in 4(%esp) 5th arg: 3rd syscall arg */ > - /* %ecx already in 0(%esp) 4th arg: 2nd syscall arg */ > - movl %ebx,%ecx /* 3rd arg: 1st syscall arg */ > - movl %eax,%edx /* 2nd arg: syscall number */ > - movl $AUDIT_ARCH_I386,%eax /* 1st arg: audit arch */ > + movl %esi,4(%esp) /* 5th arg: 4th syscall arg */ > + movl %edx,(%esp)/* 4th arg: 3rd syscall arg */ > > Bilndly overwriting the stack which holds the syscall arguments is > really a brilliant way to ensure security. It was sent, numerous times, to the x86 list for reviews, and lived in -next for 2 complete devel cycles without a complaint. I'm trying to get an i386 system to test a fix. But yes, it's total crap. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: serial: Fix indentation style issue
On Wed, Oct 22, 2014 at 09:14:14PM +, Paul Zimmerman wrote:
> > From: linux-usb-ow...@vger.kernel.org
> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Greg KH
> > Sent: Wednesday, October 22, 2014 7:19 AM
> >
> > On Wed, Oct 22, 2014 at 11:51:12AM +0200, Johan Hovold wrote:
> > > On Sat, Oct 11, 2014 at 07:20:49AM -0700, Greg Kroah-Hartman wrote:
> > > > On Sat, Oct 11, 2014 at 03:49:43PM +0200, Philip Munksgaard wrote:
> > > > > Fix a style issue
> > > > >
> > > > > Signed-off-by: Philip Munksgaard
> > > > > ---
> > > > > drivers/usb/serial/option.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> > > > > index d1a3f60..d88998d 100644
> > > > > --- a/drivers/usb/serial/option.c
> > > > > +++ b/drivers/usb/serial/option.c
> > > > > @@ -1616,7 +1616,7 @@ static const struct usb_device_id option_ids[]
> > > > > = {
> > > > > { USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) },
> > > > > { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
> > > > > .driver_info = (kernel_ulong_t)&four_g_w14_blacklist
> > > > > - },
> > > > > + },
> > > >
> > > > Why not fix the same 'space' issue on the line before this at the same
> > > > time?
> > >
> > > And what about the remaining white-space issues in this file? Do we
> > > really want to go down this path?
> >
> > No, we don't, if you want to have patches be able to apply properly to
> > older kernels, as you point out.
>
> git-apply --ignore-whitespace ?
Doesn't work with my code-flow for handling stable patches, 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/
[PATCH v2] media: davinci: vpbe: add support for VIDIOC_CREATE_BUFS
this patch adds support for vidioc_create_bufs. Along side
remove unneeded member numbuffers.
Signed-off-by: Lad, Prabhakar
---
Changes for v2:
a: return -EINVAL in queue_setup() callback if sizeimage is
less then current format size.
b: removed unneeded member numbuffers.
drivers/media/platform/davinci/vpbe_display.c | 10 +++---
include/media/davinci/vpbe_display.h | 2 --
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 3b60749..78b9ffe 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -244,12 +244,15 @@ vpbe_buffer_queue_setup(struct vb2_queue *vq, const
struct v4l2_format *fmt,
v4l2_dbg(1, debug, &vpbe_dev->v4l2_dev, "vpbe_buffer_setup\n");
+ if (fmt && fmt->fmt.pix.sizeimage < layer->pix_fmt.sizeimage)
+ return -EINVAL;
+
/* Store number of buffers allocated in numbuffer member */
- if (*nbuffers < VPBE_DEFAULT_NUM_BUFS)
- *nbuffers = layer->numbuffers = VPBE_DEFAULT_NUM_BUFS;
+ if (vq->num_buffers + *nbuffers < VPBE_DEFAULT_NUM_BUFS)
+ *nbuffers = VPBE_DEFAULT_NUM_BUFS - vq->num_buffers;
*nplanes = 1;
- sizes[0] = layer->pix_fmt.sizeimage;
+ sizes[0] = fmt ? fmt->fmt.pix.sizeimage : layer->pix_fmt.sizeimage;
alloc_ctxs[0] = layer->alloc_ctx;
return 0;
@@ -1241,6 +1244,7 @@ static const struct v4l2_ioctl_ops vpbe_ioctl_ops = {
.vidioc_try_fmt_vid_out = vpbe_display_try_fmt,
.vidioc_reqbufs = vb2_ioctl_reqbufs,
+ .vidioc_create_bufs = vb2_ioctl_create_bufs,
.vidioc_querybuf = vb2_ioctl_querybuf,
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf= vb2_ioctl_dqbuf,
diff --git a/include/media/davinci/vpbe_display.h
b/include/media/davinci/vpbe_display.h
index 163a02b..fa0247a 100644
--- a/include/media/davinci/vpbe_display.h
+++ b/include/media/davinci/vpbe_display.h
@@ -70,8 +70,6 @@ struct vpbe_disp_buffer {
/* vpbe display object structure */
struct vpbe_layer {
- /* number of buffers in fbuffers */
- unsigned int numbuffers;
/* Pointer to the vpbe_display */
struct vpbe_display *disp_dev;
/* Pointer pointing to current v4l2_buffer */
--
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: Regression: audit: x86: drop arch from __audit_syscall_entry() interface
On 10/22/2014 02:38 PM, Eric Paris wrote: > > It was sent, numerous times, to the x86 list for reviews, and lived in > -next for 2 complete devel cycles without a complaint. I'm trying to > get an i386 system to test a fix. But yes, it's total crap. > You don't need an i386 system -- you can install an i386 distro on an x86-64 system, or in KVM. -hpa -- 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: Regression: audit: x86: drop arch from __audit_syscall_entry() interface
On Wed, 2014-10-22 at 14:43 -0700, H. Peter Anvin wrote: > On 10/22/2014 02:38 PM, Eric Paris wrote: > > > > It was sent, numerous times, to the x86 list for reviews, and lived in > > -next for 2 complete devel cycles without a complaint. I'm trying to > > get an i386 system to test a fix. But yes, it's total crap. > > > > You don't need an i386 system -- you can install an i386 distro on an > x86-64 system, or in KVM. I'm currently building on i386 on KVM. That's what I meant by "get" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/4] fuse: Support fuse filesystems outside of init_user_ns
On Wed, Oct 22, 2014 at 2:24 PM, Seth Forshee
wrote:
> Update fuse to translate uids and gids to/from the user namspace
> of the process servicing requests on /dev/fuse. Any ids which do
> not map into the namespace will result in errors. inodes will
> also be marked bad when unmappable ids are received from
> userspace.
>
> Due to security concerns the namespace used should be fixed,
> otherwise a user might be able to gain elevated privileges or
> influence processes that the user would otherwise be unable to
> manipulate. Thus the namespace of the mounting process is used
> for all translations, and this namespace is required to be the
> same as the one in use when /dev/fuse was opened.
Looks generally sensible to me. I'm not familiar enough with this
code to really review it, though.
>
> Cc: Eric W. Biederman
> Cc: Serge H. Hallyn
> Cc: Andy Lutomirski
> Signed-off-by: Seth Forshee
> ---
> fs/fuse/dev.c| 4 +--
> fs/fuse/dir.c| 81
>
> fs/fuse/fuse_i.h | 12 ++---
> fs/fuse/inode.c | 73 +++---
> 4 files changed, 121 insertions(+), 49 deletions(-)
>
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 839caebd34f1..03c8785ed731 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -127,8 +127,8 @@ static void __fuse_put_request(struct fuse_req *req)
>
> static void fuse_req_init_context(struct fuse_conn *fc, struct fuse_req *req)
> {
> - req->in.h.uid = from_kuid_munged(&init_user_ns, current_fsuid());
> - req->in.h.gid = from_kgid_munged(&init_user_ns, current_fsgid());
> + req->in.h.uid = from_kuid_munged(fc->user_ns, current_fsuid());
> + req->in.h.gid = from_kgid_munged(fc->user_ns, current_fsgid());
> req->in.h.pid = pid_nr_ns(task_pid(current), fc->pid_ns);
> }
>
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index de1d84af9f7c..123db1e06c78 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -253,9 +253,12 @@ static int fuse_dentry_revalidate(struct dentry *entry,
> unsigned int flags)
> if (err || (outarg.attr.mode ^ inode->i_mode) & S_IFMT)
> goto invalid;
>
> - fuse_change_attributes(inode, &outarg.attr,
> - entry_attr_timeout(&outarg),
> - attr_version);
> + err = fuse_change_attributes(inode, &outarg.attr,
> +entry_attr_timeout(&outarg),
> +attr_version);
> + if (err)
> + goto invalid;
> +
> fuse_change_entry_timeout(entry, &outarg);
> } else if (inode) {
> fi = get_fuse_inode(inode);
> @@ -340,8 +343,9 @@ int fuse_lookup_name(struct super_block *sb, u64 nodeid,
> struct qstr *name,
> *inode = fuse_iget(sb, outarg->nodeid, outarg->generation,
>&outarg->attr, entry_attr_timeout(outarg),
>attr_version);
> - err = -ENOMEM;
> - if (!*inode) {
> + if (IS_ERR(*inode)) {
> + err = PTR_ERR(*inode);
> + *inode = NULL;
> fuse_queue_forget(fc, forget, outarg->nodeid, 1);
> goto out;
> }
> @@ -473,11 +477,11 @@ static int fuse_create_open(struct inode *dir, struct
> dentry *entry,
> ff->open_flags = outopen.open_flags;
> inode = fuse_iget(dir->i_sb, outentry.nodeid, outentry.generation,
> &outentry.attr, entry_attr_timeout(&outentry), 0);
> - if (!inode) {
> + if (IS_ERR(inode)) {
> flags &= ~(O_CREAT | O_EXCL | O_TRUNC);
> fuse_sync_release(ff, flags);
> fuse_queue_forget(fc, forget, outentry.nodeid, 1);
> - err = -ENOMEM;
> + err = PTR_ERR(inode);
> goto out_err;
> }
> kfree(forget);
> @@ -588,9 +592,9 @@ static int create_new_entry(struct fuse_conn *fc, struct
> fuse_req *req,
>
> inode = fuse_iget(dir->i_sb, outarg.nodeid, outarg.generation,
> &outarg.attr, entry_attr_timeout(&outarg), 0);
> - if (!inode) {
> + if (IS_ERR(inode)) {
> fuse_queue_forget(fc, forget, outarg.nodeid, 1);
> - return -ENOMEM;
> + return PTR_ERR(inode);
> }
> kfree(forget);
>
> @@ -905,8 +909,8 @@ static void fuse_fillattr(struct inode *inode, struct
> fuse_attr *attr,
> stat->ino = attr->ino;
> stat->mode = (inode->i_mode & S_IFMT) | (attr->mode & 0);
> stat->nlink = attr->nlink;
> - stat->uid = make_kuid(&init_user_ns, attr->uid);
> - stat->gid = make_kgid(&init_user_ns, attr->gid);
> + stat->uid = inode->i_uid;
> + stat->gid = inode->i_gid;
> stat->rdev = inode->i_rdev;
> stat
Re: [PATCH 10/15] media: davinci: vpbe: add support for VIDIOC_CREATE_BUFS
Hi Hans, On Wed, Oct 22, 2014 at 12:26 PM, Hans Verkuil wrote: > Hi Prabhakar, > > This patch series looks good, except for this one. > > If you add create_bufs support, then you should also update queue_setup. > > If the fmt argument to queue_setup is non-NULL, then check that the > fmt.pix.sizeimage field is >= the current format's sizeimage. If not, > return -EINVAL. > > This prevents userspace from creating additional buffers that are smaller > than > the minimum required size. > > I'm just skipping this patch and queuing all the others for 3.19. Just post > an > updated version for this one and I'll pick it up later. > I fixed it and posted the patch. To avoid conflicts I have rebased the patch on for-v3.19a branch of your tree. Thanks, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/4] fuse: Restrict allow_other to the superblock's namespace or a descendant
On Wed, Oct 22, 2014 at 2:24 PM, Seth Forshee
wrote:
> Unprivileged users are normally restricted from mounting with the
> allow_other option by system policy, but this could be bypassed
> for a mount done with user namespace root permissions. In such
> cases allow_other should not allow users outside the userns
> to access the mount as doing so would give the unprivileged user
> the ability to manipulate processes it would otherwise be unable
> to manipulate. Therefore access with allow_other should be
> restricted to users in the userns as the superblock or a
> descendant of that namespace.
Looks good to me.
Reviewed-by: Andy Lutomirski
>
> Cc: Eric W. Biederman
> Cc: Serge H. Hallyn
> Cc: Andy Lutomirski
> Signed-off-by: Seth Forshee
> ---
> fs/fuse/dir.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index 123db1e06c78..b23ec5c1ff18 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -1091,8 +1091,14 @@ int fuse_allow_current_process(struct fuse_conn *fc)
> {
> const struct cred *cred;
>
> - if (fc->flags & FUSE_ALLOW_OTHER)
> - return 1;
> + if (fc->flags & FUSE_ALLOW_OTHER) {
> + struct user_namespace *ns;
> + for (ns = current_user_ns(); ns; ns = ns->parent) {
> + if (ns == fc->user_ns)
> + return 1;
> + }
> + return 0;
> + }
>
> cred = current_cred();
> if (uid_eq(cred->euid, fc->user_id) &&
> --
> 1.9.1
>
--
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 v5 4/4] fuse: Allow user namespace mounts
On Wed, Oct 22, 2014 at 2:24 PM, Seth Forshee
wrote:
> Cc: Eric W. Biederman
> Cc: Serge H. Hallyn
> Cc: Andy Lutomirski
> Signed-off-by: Seth Forshee
> ---
> fs/fuse/inode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index b88b5a780228..7d0e73e36e7b 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -1201,7 +1201,7 @@ static void fuse_kill_sb_anon(struct super_block *sb)
> static struct file_system_type fuse_fs_type = {
> .owner = THIS_MODULE,
> .name = "fuse",
> - .fs_flags = FS_HAS_SUBTYPE,
> + .fs_flags = FS_HAS_SUBTYPE | FS_USERNS_MOUNT,
> .mount = fuse_mount,
> .kill_sb= fuse_kill_sb_anon,
> };
> @@ -1233,7 +1233,7 @@ static struct file_system_type fuseblk_fs_type = {
> .name = "fuseblk",
> .mount = fuse_mount_blk,
> .kill_sb= fuse_kill_sb_blk,
> - .fs_flags = FS_REQUIRES_DEV | FS_HAS_SUBTYPE,
> + .fs_flags = FS_REQUIRES_DEV | FS_HAS_SUBTYPE | FS_USERNS_MOUNT,
> };
> MODULE_ALIAS_FS("fuseblk");
>
> --
> 1.9.1
>
This is mostly a sign of my ignorance, but how does this actually end
up working? I assume that the mounter opens /dev/fuse and then passes
the fd to the mount call. Which userns is captured? The opener of
/dev/fuse or the mounter of the fs?
--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/
