Re: [PATCH 0/4] x86/insn: perf tools: Add a few new x86 instructions
On Tue, Sep 01, 2015 at 04:57:16PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 01, 2015 at 03:16:52PM +0300, Adrian Hunter escreveu: > > On 01/09/15 11:54, Ingo Molnar wrote: > > > > > > * Adrian Hunter wrote: > > > > > >> Hi > > >> > > >> perf tools has a copy of the x86 instruction decoder for decoding > > >> Intel PT. [...] > > > > > > So that's the arch/x86/lib/insn.c instruction length decoder that the > > > kernel uses > > > for kprobes et al - and the two versions already forked slightly: > > > > > > -#include "inat.h" > > > -#include "insn.h" > > > +#include > > > +#include > > > > > > it would be nice to add a diff check to the perf build, and (non-fatally) > > > warn > > > during the build if the two versions depart from each other? > > > > I had a go and came up with this. Arnaldo, Jiri any comments? > > So, I was going to try and merge this series, can you please collect the > Acks by Masami and Jiri and resubmit? > > I'd say no need to stop this just to get a build function to use with > this, the test below should do the trick _for this specific instance_ > and then, after we get this, you should use it as the initial usecase > for adding the build function, d'accord? > > Jiri, are you ok with this? sure, np you can use my ack jirka > > - Arnaldo > > > diff --git a/tools/perf/util/intel-pt-decoder/Build > > b/tools/perf/util/intel-pt-decoder/Build > > index 240730d682c1..1b8a32de8504 100644 > > --- a/tools/perf/util/intel-pt-decoder/Build > > +++ b/tools/perf/util/intel-pt-decoder/Build > > @@ -6,6 +6,17 @@ inat_tables_maps = util/intel-pt-decoder/x86-opcode-map.txt > > $(OUTPUT)util/intel-pt-decoder/inat-tables.c: $(inat_tables_script) > > $(inat_tables_maps) > > @$(call echo-cmd,gen)$(AWK) -f $(inat_tables_script) > > $(inat_tables_maps) > $@ || rm -f $@ > > > > -$(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: > > util/intel-pt-decoder/inat.c $(OUTPUT)util/intel-pt-decoder/inat-tables.c > > +$(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: > > util/intel-pt-decoder/intel-pt-insn-decoder.c util/intel-pt-decoder/inat.c > > $(OUTPUT)util/intel-pt-decoder/inat-tables.c > > + @test -d ../../arch/x86 && (( \ > > + diff -B -I'^#include' util/intel-pt-decoder/insn.c > > ../../arch/x86/lib/insn.c >/dev/null && \ > > + diff -B -I'^#include' util/intel-pt-decoder/inat.c > > ../../arch/x86/lib/inat.c >/dev/null && \ > > + diff -B util/intel-pt-decoder/x86-opcode-map.txt > > ../../arch/x86/lib/x86-opcode-map.txt >/dev/null && \ > > + diff -B util/intel-pt-decoder/gen-insn-attr-x86.awk > > ../../arch/x86/tools/gen-insn-attr-x86.awk >/dev/null && \ > > + diff -B -I'^#include' util/intel-pt-decoder/insn.h > > ../../arch/x86/include/asm/insn.h >/dev/null && \ > > + diff -B -I'^#include' util/intel-pt-decoder/inat.h > > ../../arch/x86/include/asm/inat.h >/dev/null && \ > > + diff -B -I'^#include' util/intel-pt-decoder/inat_types.h > > ../../arch/x86/include/asm/inat_types.h >/dev/null) \ > > + || echo "Warning: Intel PT: x86 instruction decoder differs from > > kernel" >&2 ) > > + $(call rule_mkdir) > > + $(call if_changed_dep,cc_o_c) > > > > CFLAGS_intel-pt-insn-decoder.o += -I$(OUTPUT)util/intel-pt-decoder > > -Wno-override-init > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf tools: Don't set leader if parser doesn't collect an evsel
> From: Wang Nan [mailto:wangn...@huawei.com]
>
> Similar to patch 'perf tools: Don't set cmdline_group_boundary if no
> evsel is collected', in case when parser collects no evsel (at this
> point it shouldn't happen), parse_events__set_leader() is not safe.
>
> This patch checks list_empty becore calling __perf_evlist__set_leader()
> for safty reason.
>
> Signed-off-by: Wang Nan
> Cc: Arnaldo Carvalho de Melo
> Cc: Alexei Starovoitov
> Cc: Jiri Olsa
> Cc: Masami Hiramatsu
> Cc: Namhyung Kim
> Cc: Zefan Li
> Cc: pi3or...@163.com
> ---
>
> I'd like to queue this patch into my next pull request. Since it is not
> a real bug, it may be dropped.
>
> ---
> tools/perf/util/parse-events.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index f2c0317..836d226 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -793,6 +793,9 @@ void parse_events__set_leader(char *name, struct
> list_head *list)
> {
> struct perf_evsel *leader;
>
> + if (list_empty(list))
Would we need to warn/debug something here?
Thank you,
> + return;
> +
> __perf_evlist__set_leader(list);
> leader = list_entry(list->next, struct perf_evsel, node);
> leader->group_name = name ? strdup(name) : NULL;
> --
> 1.8.3.4
Re: [GIT PULL] Ext3 removal, quota & udf fixes
On 09/01/15 20:30, Albino B Neto wrote: 2015-08-31 23:53 GMT-03:00 Theodore Ts'o : Yes, you can go back to ext3-only. In fact, we do *not* automatically upgrade the file system to use ext4-specific features. So it's not just a "you can use ext4 instead" issue. Can you do that *without* then forcing an upgrade forever on that partition? I'm not sure the ext4 people are really even willing to guarantee that kind of backwards compatibility. Actually, we do guarantee this. It's considered poor form to automatically change the superblock to add new file system features in a way that would break the ability for the user to roll back to an older kernel. This isn't just for ext3->ext4, but for new ext4 features such as metadata checksumming. The user has to explicitly enable the feature using "tune2fs -O new_feature /dev/sdXX". Yeah! 2015-09-01 16:39 GMT-03:00 Austin S Hemmelgarn : NO, it is not logical. A vast majority of Android smartphones in the wild use ext2, as do a very significant portion of embedded systems that don't have room for the few hundred kilobytes of extra code that the ext4 driver has in comparison to ext2. Ext2 portion embedded and Ext3 many machines. So basically the game plan is gutting ext3 because code-dupe with ext4, but keep ext2 because ext4 is too big for embedded to outright replace ext2? Hmm...are there any embedded systems out there that use ext3 and can fit its code ext3 but not ext4? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 07/31] perf probe: Attach trace_probe_event with perf_probe_event
On 2015/9/2 12:32, Namhyung Kim wrote:
Hi,
On Sat, Aug 29, 2015 at 04:21:41AM +, Wang Nan wrote:
This patch drops struct __event_package structure. Instead, it adds
trace_probe_event into 'struct perf_probe_event'.
trace_probe_event information gives further patches a chance to access
actual probe points and actual arguments. Using them, bpf_loader will
be able to attach one bpf program to different probing points of a
inline functions (which has multiple probing points) and glob
functions. Moreover, by reading arguments information, bpf code for
reading those arguments can be generated.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Cc: Arnaldo Carvalho de Melo
Link:
http://lkml.kernel.org/n/1436445342-1402-22-git-send-email-wangn...@huawei.com
---
[SNIP]
+int add_perf_probe_events(struct perf_probe_event *pevs, int npevs,
+ bool cleanup)
+{
+ int i, ret;
ret = init_symbol_maps(pevs->uprobes);
- if (ret < 0) {
- free(pkgs);
+ if (ret < 0)
return ret;
- }
/* Loop 1: convert all events */
for (i = 0; i < npevs; i++) {
- pkgs[i].pev = [i];
/* Init kprobe blacklist if needed */
- if (!pkgs[i].pev->uprobes)
+ if (pevs[i].uprobes)
Missing '!'.
It's my fault. Already fixed in my local tree.
Thank you for your review!
Thanks,
Namhyung
kprobe_blacklist__init();
/* Convert with or without debuginfo */
- ret = convert_to_probe_trace_events(pkgs[i].pev,
-[i].tevs);
- if (ret < 0)
+ ret = convert_to_probe_trace_events([i], [i].tevs);
+ if (ret < 0) {
+ cleanup = true;
goto end;
- pkgs[i].ntevs = ret;
+ }
+ pevs[i].ntevs = ret;
}
/* This just release blacklist only if allocated */
kprobe_blacklist__release();
/* Loop 2: add all events */
for (i = 0; i < npevs; i++) {
- ret = __add_probe_trace_events(pkgs[i].pev, pkgs[i].tevs,
- pkgs[i].ntevs,
+ ret = __add_probe_trace_events([i], pevs[i].tevs,
+ pevs[i].ntevs,
probe_conf.force_add);
if (ret < 0)
break;
}
end:
/* Loop 3: cleanup and free trace events */
- for (i = 0; i < npevs; i++) {
- for (j = 0; j < pkgs[i].ntevs; j++)
- clear_probe_trace_event([i].tevs[j]);
- zfree([i].tevs);
- }
- free(pkgs);
+ for (i = 0; cleanup && (i < npevs); i++)
+ cleanup_perf_probe_event([i]);
exit_symbol_maps();
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 15/16] mtd: mtdcore: fix initcall level
Am 01.09.2015 um 23:19 schrieb Brian Norris: Hi Alexander, No judgment here for the rest of this series, but for this patch: On Wed, Aug 26, 2015 at 02:28:27PM +0200, Alexander Holler wrote: The mtd-core has to be initialized before other dependent mtd-drivers, otherwise a crash might occur. Currently mtd_init() is called in the initcall-level device, which is the same level where most mtd-drivers will end up. By luck this seemed to have been called most of the time before other mtd-drivers without having been explicitly enforced. I can't really speak for the original authors, but it does not appear to be entirely "by luck." Link order was one of the de facto ways to get this ordering (though it's not really a great one), and mtdcore was always linked first within the drivers/mtd/ directory structure. But that's just background, I think this is worth fixing anyway. It could, for instance, become a problem if drivers are located outside drivers/mtd/; I see random board files in arch/ that register with MTD, and I'm actually not sure how they have never tripped on this. I've already found at least a half a dozen other drivers with the same problem through my shuffling of the drivers which all end up in the standard initcall level device. I'm aware that this is based on the link order, which itself is based on linker behaviour (and maybe other things like make or other build tools). I'm just calling it luck, because this is nowhere explicitly stated, at least I've never seen such a statement, neither in any source, nor somewhere in Documentation. So I've choosen the term "by luck" in order to provoke a bit (or to stimulate a discussion about that widespread problem). But if mtd_init() is not called before a dependent driver, a null-pointer exception might occur (e.g. because the mtd device class isn't registered). To fix this, mtd-init() is moved to the initcall-level fs (right before the standard initcall level device). Is there a good reason we shouldn't just make this a subsys_initcall()? That would match the naming better, and it mirrors what, e.g., block/genhd uses. It would also allow flexibility if there are other current/future use cases that might need to sit between the subsystem and the drivers. No real reason here. The names for the initcall levels seem to be outdated since a long time anyway, and I think just speaking about the numbers 1-7 (or 0-14) would be better anyways. The only reason why I've used the fs (sync) level is because I was too lazy to check out if mtdcore might depend on something else in any other level. Therefor I've used the one most close to were it was before. Also I've an idea about how to fix that in general for all drivers (by using the same algorithm I've now introduced just for DT-based drivers with a device description). Wouldn't be that hard to use that for all drivers, but as I've written in a follow up to the introductory mail, one step after another. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] security: smack: Add support automatic Smack labeling
On 9/1/2015 1:01 AM, jonghwa3@samsung.com wrote:
> On 2015년 08월 31일 22:59, Lukasz Pawelczyk wrote:
>> On pon, 2015-08-31 at 15:13 +0900, jonghwa3@samsung.com wrote:
>>> A rule is defined for a process, 'process A', in smack rule table.
>>>
>>> ...
>>> Process Adevice::Aarwx-
>>> ...
>>>
>>> The object 'device::A' will be used to a device node that 'process A'
>>> will access.
>>> However when the target device node is created it's labeled with
>>> default label
>>> which is inherited from any of filesystem, ancestor, or creating
>>> process.
>>> Let's say the default object label for devtmpfs is '_' which allows
>>> only read and
>>> write access. So we need the specific labeling by the authorized
>>> process as like
>>> udevd for the devtmpfs.
>>>
>>> In normal, smack label and access control follow the sequences,
>>>
>>> 1. Kernel module driver loaded
>>> 2. New device node is created (/dev/aaa , '_')
>>> 3. Udevd gets uevent and appies udev rule (/dev/aaa, 'device::A')
>>> 4. 'Process A' accesses the device node ('Process A' --->
>>> 'device::A', MAY_WRITE)
>>> 5. Access is permitted.
>>>
>>> However, when labeling isn't done in proper time, result will be
>>> different,
>>>
>>> 1. Kernel module driver loaded
>>> 2. New device node is created (/dev/aaa , '_')
>>> 3. 'Process A' accesses the device node ('Process A' ---> '_',
>>> MAY_WRITE)
>>> 4. Access is prohibited
>>>
>>> Can this situation be handled in current Smack subsystem?
>>> If so, could you give me an idea how to handle it.
>> This doesn't seem to be a Smack problem. This isn't even a kernel
>> problem. It's userspace race. You should wait for a proper udev event
>> that notifies after all udev rules are applied.
>>
>> I think there are 2 udev events. One that notifies that a device has
>> been added. Second that notifies where all the rules for the device has
>> been applied. You need to use the second one.
>>
>>
>>
> Yes you're right, it's not a problem of neither Smack nor kernel. However it
> will
> help to resolve the problem if there is a proper way to label handled by
> kernel
> at least for files created by kernel.(e.g. device node)
>
> I'm not sure whether there is a uevent for completion of applying rule.
> (I couldn't catch any of such uevent with udevadm.)
> However even there is, I think kernel side labeling has obvious advantages.
>
> The every new files need proper labeling before working under Smack.
> The files created by user application can be labeled by the same process at
> once.
> So it doesn't need to consider delayed labeling before access.
> However, the files created by kernel has to wait user space's control to be
> used.
> The timing of user space's labeling is not precised. It can be delayed
> indefinitely.
> Yes it's userspace race, but if kernel help it, It can prevent such issues.
>
> My proposal might be not quite fancy. (It could degrade system's performance
> severely as like Casey pointed out) But I'd like to ask whether this attempt
> is
> useless.
The problem is that you're fixing the problem in the wrong place.
I see that there is an issue, but there are several ways you could
address it in udev. You could change udev so that instead of creating
the device and changing it's Smack label you could create the device
with a "-not-yet" suffix, change it's Smack label, then rename it to
the proper name. There are other approaches as well.
> Do you think that is just userspace's affair and couldn't be solved with
> kernel's help?
It *can* be fixed with the kernel's help, but it shouldn't.
> I gently ask your comments.
>
> Thanks,
> Jonghwa
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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: linux-next: build failure after merge of the rcu tree
On Wed, Sep 02, 2015 at 01:58:00PM +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> On Tue, 1 Sep 2015 00:49:46 -0700 "Paul E. McKenney"
> wrote:
> >
> > On Tue, Sep 01, 2015 at 01:50:06PM +1000, Stephen Rothwell wrote:
> > >
> > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko]
> > > undefined!
> > > ERROR: "percpu_down_write" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "percpu_up_write" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "percpu_down_read" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "percpu_up_read" [kernel/locking/locktorture.ko] undefined!
> > > ERROR: "__percpu_init_rwsem" [kernel/locking/locktorture.ko] undefined!
> > >
> > > Caused by commits
> > >
> > > 04be76a9b067 ("locktorture: Support rtmutex torturing")
> > > 40b2996f9b32 ("locktorture: Add torture tests for percpu_rwsem")
> > >
> > > and maybe more.
> > >
> > > I have used the rcu tree from next-20150831 for today.
> >
> > It is looking like I will be deferring these to v4.4, apologies for
> > the hassle!
>
> This still fails to build but now I only get the error about
> sched_setscheduler_nocheck.
OK, now I actually have deferred these to v4.4.
Davidlohr, the error is due to sched_setscheduler_nocheck() not being
exported, so that Stephen gets this failure when building modules.
This is 04be76a9b067 (locktorture: Support rtmutex torturing) in -rcu.
Thoughts?
Thanx, 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: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 01, 2015 at 10:03:27PM -0700, Andy Lutomirski wrote: > On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker wrote: > > On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote: > >> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote: > >> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote: > >> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote: > >> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: > >> >> >> Hi all- > >> >> >> > >> >> >> Linux has a handful of weird features that are only supported for > >> >> >> backwards compatibility. The big one is the x86_64 vsyscall page, > >> >> >> but > >> >> >> uselib probably belongs on the list, too, and we might end up with > >> >> >> more at some point. > >> >> >> > >> >> >> I'd like to add a way that new programs can turn these features off. > >> >> >> In particular, I want the vsyscall page to be completely gone from > >> >> >> the > >> >> >> perspective of any new enough program. This is straightforward if we > >> >> >> add a system call to ask for the vsyscall page to be disabled, but > >> >> >> I'm > >> >> >> wondering if we can come up with a non-syscall way to do it. > >> >> >> > >> >> >> I think that the ideal behavior would be that anything linked against > >> >> >> a sufficiently new libc would be detected, but I don't see a good way > >> >> >> to do that using existing toolchain features. > >> >> >> > >> >> >> Ideas? We could add a new phdr for this, but then we'd need to play > >> >> >> linker script games, and I'm not sure that could be done in a clean, > >> >> >> extensible way. > >> >> > > >> >> > Is there a practical problem you're trying to solve? My understanding > >> >> > is that the vsyscall nonsense is fully emulated now and that the ways > >> >> > it could be used as an attack vector have been mitigated. > >> >> > >> >> They've been mostly mitigated, but not fully. See: > >> >> > >> >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html > >> > > >> > That looks like it would be mitigated by not having any mapping there > >> > at all and having the kernel just catch the page fault and emulate > >> > rather than filling it with trapping opcodes for the kernel to catch. > >> > > >> > >> Oddly, that causes a compatibility problem. There's a program called > >> pin that does dynamic instrumentation and actually expects to be able > >> to read the targets of calls. The way that Linux handles this now is > > > > Um, do people seriously need to do this dynamic instrumentation on > > ancient obsolete binaries? This sounds to me like confused > > requirements. > > Unclear. They certainly did, and I got a bug report, the first time > around. That was a couple years ago. > > I suppose we could have a sysctl that you need to set to enable that > use case. OTOH, I think that, as long as we have a way to distinguish > new and old binaries, it's not that much harder to twiddle vsyscall > readability per process than it is to twiddle vsyscall executability > per process. But we don't have a (reasonable) way to distinguish new and old binaries, at least not at the right point in history. If we're adding a new header or whatnot, only bleeding-edge binaries will benefit from it. All existing binaries from the past N years that don't need the vsyscall nonsense will still get it unnecessarily, and still be subject to the risks. This has me wondering if there's any point in trying to solve the problem on the granularity of individual programs. Users running all-new binaries (that would benefit from a header flag) can just remove vsyscall support entirely from their kernels. Users with a mix binaries of various ages will likely still have the vsyscall risk in most programs, _including_ many newer binaries that have no use for vsyscall but lack the new header. BTW, since the only calls to vsyscall are from glibc, it seems to me that the only ways vsyscall can be needed are: 1. The user is running old glibc, in which case all dynamic-linked programs need it. 2. The user is running old static-linked glibc binaries. Almost nobody does this. During the era of vsyscall, static linking was all but deprecated. 3. The user is running old binaries using a custom library path with old glibc in it. This is almost certainly just a bogus setup since glibc's symbol versioning is supposed to make old binaries run fine with a newer libc.so. None of these seem to be use cases that we should be engineering complex solutions for. For case 1, the solution wouldn't help anyway since all programs need vsyscall. For cases 2 and 3, if the user wants to harden their system so that newer binaries are not affected by vsyscall, they should just remove vsyscall and fix their old binaries/libraries. In case 2, in particular, you can assume the ability to re-link with an updated glibc; otherwise, there's an LGPL violation going on. Rich -- To unsubscribe from this list:
Re: [PATCH] dax, pmem: add support for msync
On Tue, Sep 01, 2015 at 09:19:45PM -0600, Ross Zwisler wrote: > On Wed, Sep 02, 2015 at 08:21:20AM +1000, Dave Chinner wrote: > > Which means applications that should "just work" without > > modification on DAX are now subtly broken and don't actually > > guarantee data is safe after a crash. That's a pretty nasty > > landmine, and goes against *everything* we've claimed about using > > DAX with existing applications. > > > > That's wrong, and needs fixing. > > I agree that we need to fix fsync as well, and that the fsync solution could > be used to implement msync if we choose to go that route. I think we might > want to consider keeping the msync and fsync implementations separate, though, > for two reasons. > > 1) The current msync implementation is much more efficient than what will be > needed for fsync. Fsync will need to call into the filesystem, traverse all > the blocks, get kernel virtual addresses from those and then call > wb_cache_pmem() on those kernel addresses. I think this is a necessary evil > for fsync since you don't have a VMA, but for msync we do and we can just > flush using the user addresses without any fs lookups. Yet you're ignoring the fact that flushing the entire range of the relevant VMAs may not be very efficient. It may be a very large mapping with only a few pages that need flushing from the cache, but you still iterate the mappings flushing GB ranges from the cache at a time. We don't need struct pages to track page dirty state. We already have a method for doing this that does not rely on having a struct page and can be used for efficient lookup of exact dirty ranges. i.e the per-page dirty tag that is kept in the mapping radix tree. It's fine grained, and extremely efficient in terms of lookups to find dirty pages. Indeed, the mapping tree tags were specifically designed to avoid this "fsync doesn't know what range to flush" problem for normal files. That same problem still exists here for msync - these patches are just hitting it with a goddamn massive hammer "because it is easy" rather than attempting to do the flushing efficiently. > 2) I believe that the near-term fsync code will rely on struct pages for > PMEM, which I believe are possible but optional as of Dan's last patch set: > > https://lkml.org/lkml/2015/8/25/841 > > I believe that this means that if we don't have struct pages for PMEM (becuase > ZONE_DEVICE et al. are turned off) fsync won't work. I'd be nice not to lose > msync as well. I don't think this is an either-or situation. If we use struct pages for PMEM, then fsync will work without modification as DAX will need to use struct pages and hence we can insert them in the mapping radix tree directly and use the normal set/clear_page_dirty() calls to track dirty state. It will give us fine grained flush capability and we won't want msync() to be using the big hammer if we can avoid it. If we make the existing pfn-based DAX code track dirty pages via mapping radix tree tags right now, then we allow fsync to work by reusing most of the infrastructure we already have. That means DAX and fsync will work exactly the same regardless of how we index/reference PMEM in future and we won't have to come back and fix it all up again. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] irqchip/gicv3-its: comfort build warnings
There are some warnings in gicv3-its. It looks like they are set in its_lpi_alloc_chunks(), but in fact, both of them(lpi_base/nr_lpis) still have some chances as unset variables. Anyway to comfort gcc if it's not a issue. drivers/irqchip/irq-gic-v3-its.c: In function ‘its_msi_prepare’: drivers/irqchip/irq-gic-v3-its.c:1148:26: warning: ‘lpi_base’ may be used uninitialized in this function [-Wmaybe-uninitialized] dev->event_map.lpi_base = lpi_base; ^ drivers/irqchip/irq-gic-v3-its.c:1116:6: note: ‘lpi_base’ was declared here int lpi_base; ^ drivers/irqchip/irq-gic-v3-its.c:1149:25: warning: ‘nr_lpis’ may be used uninitialized in this function [-Wmaybe-uninitialized] dev->event_map.nr_lpis = nr_lpis; ^ drivers/irqchip/irq-gic-v3-its.c:1117:6: note: ‘nr_lpis’ was declared here int nr_lpis; ^ Signed-off-by: Alex Shi Cc: Marc Zyngier Cc: Jason Cooper --- drivers/irqchip/irq-gic-v3-its.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 26b55c5..0f0af18 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1113,8 +1113,8 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, unsigned long flags; u16 *col_map = NULL; void *itt; - int lpi_base; - int nr_lpis; + int lpi_base = 0; + int nr_lpis = 0; int nr_ites; int sz; -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev wrote: > 19.08.2015 18:46, Andy Lutomirski пишет: >> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev wrote: Incidentally, I tried implementing the sigaction flag approach. I think it's no good. When we return from a signal, there's no concept of sigaction -- it's just sigreturn. Sigreturn can't look up the sigaction flags -- what if the signal handler calls sigaction itself. >>> How about the SA_hyz flag that does the following: >>> - Saves SS into sigcontext >>> - Forces SS to USER_DS on signal delivery >>> - Sets the uc_flags flag for sigreturn() to take care of the rest. >>> You'll have both the control on every bit of action, and a simple >>> detection logic: if SA_hyz didn't set the uc flag - it didn't work. >>> You can even employ your lar heuristic here for the case when the >>> aforementioned SA_hyz is not set. But please, please not when it is >>> set! In fact, I wonder if you had in mind exactly that: using the >>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood. >>> Just please don't add it when it is set. >> >> Hmm, interesting. Maybe that would work for everything. How's this >> to make it concrete? >> >> Add a sigaction flag SA_RESTORE_SS. >> >> On signal delivery, always save SS into sigcontext->ss. if >> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS >> and set UC_RESTORE_SS. If SA_RESTORE_SS is clear, then leave HW SS >> alone (i.e. preserve the old behavior). > Either that, or employ the lar heuristic for the "not set" case > (I think its not needed). > >> On signal return, if UC_RESTORE_SS is set, then restore >> sigcontext->ss. If not, then set SS to __USER_DS (as old kernels >> did). >> >> This should change nothing at all (except the initial value of >> sigcontext->ss / __pad0) on old kernels. > Agreed. > Let me throw out one more possibility, just for completeness: We don't add any SA_xyz flags. On signal delivery, we use the LAR heuristic. We always fill in sigcontext->ss, and we set a new UC_SIGCONTEXT_SS flag to indicate that we support the new behavior. On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and SS is invalid. In the latter case, we replace the saved ss with __USER_DS. This should work for old DOSEMU. It's a bit gross, but it has the nice benefit that everyone (even things that aren't DOSEMU) gain the ability to catch signals thrown from bogus SS contexts, which probably improves debugability. It's also nice to not have the SA flag. This is a big problematic for my sigreturn_64 test, but I can deal with that. We could optionally have another UC_RESTORE_EXACT_SS flag that you can set that means "no, really, restore the saved SS". --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker wrote: > On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote: >> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote: >> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote: >> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote: >> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: >> >> >> Hi all- >> >> >> >> >> >> Linux has a handful of weird features that are only supported for >> >> >> backwards compatibility. The big one is the x86_64 vsyscall page, but >> >> >> uselib probably belongs on the list, too, and we might end up with >> >> >> more at some point. >> >> >> >> >> >> I'd like to add a way that new programs can turn these features off. >> >> >> In particular, I want the vsyscall page to be completely gone from the >> >> >> perspective of any new enough program. This is straightforward if we >> >> >> add a system call to ask for the vsyscall page to be disabled, but I'm >> >> >> wondering if we can come up with a non-syscall way to do it. >> >> >> >> >> >> I think that the ideal behavior would be that anything linked against >> >> >> a sufficiently new libc would be detected, but I don't see a good way >> >> >> to do that using existing toolchain features. >> >> >> >> >> >> Ideas? We could add a new phdr for this, but then we'd need to play >> >> >> linker script games, and I'm not sure that could be done in a clean, >> >> >> extensible way. >> >> > >> >> > Is there a practical problem you're trying to solve? My understanding >> >> > is that the vsyscall nonsense is fully emulated now and that the ways >> >> > it could be used as an attack vector have been mitigated. >> >> >> >> They've been mostly mitigated, but not fully. See: >> >> >> >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html >> > >> > That looks like it would be mitigated by not having any mapping there >> > at all and having the kernel just catch the page fault and emulate >> > rather than filling it with trapping opcodes for the kernel to catch. >> > >> >> Oddly, that causes a compatibility problem. There's a program called >> pin that does dynamic instrumentation and actually expects to be able >> to read the targets of calls. The way that Linux handles this now is > > Um, do people seriously need to do this dynamic instrumentation on > ancient obsolete binaries? This sounds to me like confused > requirements. Unclear. They certainly did, and I got a bug report, the first time around. That was a couple years ago. I suppose we could have a sysctl that you need to set to enable that use case. OTOH, I think that, as long as we have a way to distinguish new and old binaries, it's not that much harder to twiddle vsyscall readability per process than it is to twiddle vsyscall executability per process. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] mmc: dw_mmc: dt-binding: Add tuning related things
Hi, Heiko. On 09/01/2015 03:24 AM, Heiko Stuebner wrote: > From: Alexandru M Stan > > Add ciu_drv, ciu_sample clocks and default-sample-phase. This will later > be used by tuning code. As i know, ciu_drv and ciu_sample clocks are generated with "ciu" clock. But in these patch-set, ciu_drv and ciu_sample are controlled by clock framework. It's a little strange. Are there ciu_drv and ciu_sample clock on Rockchip? Best Regards, Jaehoon Chung > > We do not touch ciu_drive (and by extension define default-drive-phase). > Drive phase is mostly used to define minimum hold times, while one could > write some code to determine what phase meets the minimum hold time > (ex 10 degrees) this will not work with the current clock phase framework > (which floors angles, so we'll get 0 deg, and there's no way to know what > resolution the floors happen at). We assume that the default drive angles > set by the hardware are good enough. > > Signed-off-by: Alexandru M Stan > Signed-off-by: Heiko Stuebner > --- > Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 14 > ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt > b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt > index 346c609..5edadc2 100644 > --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt > +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt > @@ -42,11 +42,13 @@ Optional properties: > * clocks: from common clock binding: handle to biu and ciu clocks for the >bus interface unit clock and the card interface unit clock. > > -* clock-names: from common clock binding: Shall be "biu" and "ciu". > - If the biu clock is missing we'll simply skip enabling it. If the > - ciu clock is missing we'll just assume that the clock is running at > +* clock-names: from common clock binding: Shall be "biu", "ciu", "ciu_drv" > and > + "ciu_sample". If the biu clock is missing we'll simply skip enabling it. > + If the ciu clock is missing we'll just assume that the clock is running at >clock-frequency. It is an error to omit both the ciu clock and the > - clock-frequency. > + clock-frequency. "ciu_drv" and "ciu_sample" are used to control the clock > + phases, "ciu_sample" is required for tuning high speed modes (if no other > + custom tuning method is defined). > > * clock-frequency: should be the frequency (in Hz) of the ciu clock. If this >is specified and the ciu clock is specified then we'll try to set the ciu > @@ -75,6 +77,10 @@ Optional properties: > * vmmc-supply: The phandle to the regulator to use for vmmc. If this is >specified we'll defer probe until we can find this regulator. > > +* default-sample-phase: The default phase to set ciu_sample at probing, low > + speeds or in case where all phases work at tuning time. If not specified > + 0 deg will be used. > + > Aliases: > > - All the MSHC controller nodes should be represented in the aliases node > using > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote: > On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote: > > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote: > >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote: > >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: > >> >> Hi all- > >> >> > >> >> Linux has a handful of weird features that are only supported for > >> >> backwards compatibility. The big one is the x86_64 vsyscall page, but > >> >> uselib probably belongs on the list, too, and we might end up with > >> >> more at some point. > >> >> > >> >> I'd like to add a way that new programs can turn these features off. > >> >> In particular, I want the vsyscall page to be completely gone from the > >> >> perspective of any new enough program. This is straightforward if we > >> >> add a system call to ask for the vsyscall page to be disabled, but I'm > >> >> wondering if we can come up with a non-syscall way to do it. > >> >> > >> >> I think that the ideal behavior would be that anything linked against > >> >> a sufficiently new libc would be detected, but I don't see a good way > >> >> to do that using existing toolchain features. > >> >> > >> >> Ideas? We could add a new phdr for this, but then we'd need to play > >> >> linker script games, and I'm not sure that could be done in a clean, > >> >> extensible way. > >> > > >> > Is there a practical problem you're trying to solve? My understanding > >> > is that the vsyscall nonsense is fully emulated now and that the ways > >> > it could be used as an attack vector have been mitigated. > >> > >> They've been mostly mitigated, but not fully. See: > >> > >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html > > > > That looks like it would be mitigated by not having any mapping there > > at all and having the kernel just catch the page fault and emulate > > rather than filling it with trapping opcodes for the kernel to catch. > > > > Oddly, that causes a compatibility problem. There's a program called > pin that does dynamic instrumentation and actually expects to be able > to read the targets of calls. The way that Linux handles this now is Um, do people seriously need to do this dynamic instrumentation on ancient obsolete binaries? This sounds to me like confused requirements. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On Tue, 2015-09-01 at 22:57 -0500, Zhao Qiang-B45475 wrote: > On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote: > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Wednesday, September 02, 2015 11:09 AM > > To: Zhao Qiang-B45475 > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li > > Yang-Leo-R58472; pau...@samba.org > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > bytes-alignment to genalloc > > > > On Tue, 2015-09-01 at 22:05 -0500, Zhao Qiang-B45475 wrote: > > > On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote: > > > > > > > -Original Message- > > > > From: Wood Scott-B07421 > > > > Sent: Wednesday, September 02, 2015 10:33 AM > > > > To: Zhao Qiang-B45475 > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; > > > > Li Yang-Leo-R58472; pau...@samba.org > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > > > bytes-alignment to genalloc > > > > > > > > On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote: > > > > > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote: > > > > > > -Original Message- > > > > > > From: Wood Scott-B07421 > > > > > > Sent: Wednesday, September 02, 2015 10:18 AM > > > > > > To: Zhao Qiang-B45475 > > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061; > > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation > > > > > > with bytes-alignment to genalloc > > > > > > > > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote: > > > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote: > > > > > > > > -Original Message- > > > > > > > > From: Wood Scott-B07421 > > > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM > > > > > > > > To: Zhao Qiang-B45475 > > > > > > > > Cc: linux-kernel@vger.kernel.org; > > > > > > > > linuxppc-...@lists.ozlabs.org; lau...@codeaurora.org; Xie > > > > > > > > Xiaobo-R63061; b...@kernel.crashing.org; Li Yang-Leo-R58472; > > > > > > > > pau...@samba.org > > > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support > > > > > > > > memory-allocation with bytes-alignment to genalloc > > > > > > > > > > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote: > > > > > > > > > Bytes alignment is required to manage some special RAM, so > > > > > > > > > add gen_pool_first_fit_align to genalloc, meanwhile add > > > > > > > > > gen_pool_alloc_data to pass data to > > > > > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a > > > > > > > > > wrapper) > > > > > > > > > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > > > > > --- > > > > > > > > > Changes for v6: > > > > > > > > > - patches set v6 include a new patch because of using > > > > > > > > > - genalloc to manage QE MURAM, patch 0001 is the new > > > > > > > > > - patch, adding bytes alignment for allocation for > > use. > > > > > > > > > Changes for v7: > > > > > > > > > - cpm muram also need to use genalloc to manage, it > > has > > > > > > > > > a function to reserve a specific region of muram, > > > > > > > > > add offset to genpool_data for start addr to be > > > > allocated. > > > > > > > > > > > > > > > > This seems to be describing more than just the changes in > > > > > > > > this > > > > patch. > > > > > > > > What does also handling cpm have to do with this patch? Are > > > > > > > > you adding support for reserving a specific region in this > > > > > > > > patch? I don't see it, and in any case it should go in a > > different patch. > > > > > > > > > > > > > > Yes, I added. The code below can support the function. > > > > > > > offset_bit = (alignment->offset + (1UL << order) - 1) >> > > > > order; > > > > > > > return bitmap_find_next_zero_area(map, size, start + > > > > > > > offset_bit, > > > > > > nr, > > > > > > > align_mask); > > > > > > > > > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate > > > > > > > muram from a Specific offset. So I add the code and add offset > > > > > > > to > > > > struct data. > > > > > > > > > > > > I thought the offset was related to the previous discussion of > > > > > > checking for allocation failure. Are you using it to implement > > > > > > alloc_fixed()? If so, please don't. Besides the awkward > > > > > > implementation (what does it logically have to do with > > > > > > gen_pool_first_fit_align?), it does not appear to be correct - > > > > > > - what happens with multiple chunks? What happens if part of > > > > > > the region the caller is trying to reserve is already taken? > > > > > > Implement a
Re: [PATCH 07/31] perf probe: Attach trace_probe_event with perf_probe_event
Hi,
On Sat, Aug 29, 2015 at 04:21:41AM +, Wang Nan wrote:
> This patch drops struct __event_package structure. Instead, it adds
> trace_probe_event into 'struct perf_probe_event'.
>
> trace_probe_event information gives further patches a chance to access
> actual probe points and actual arguments. Using them, bpf_loader will
> be able to attach one bpf program to different probing points of a
> inline functions (which has multiple probing points) and glob
> functions. Moreover, by reading arguments information, bpf code for
> reading those arguments can be generated.
>
> Signed-off-by: Wang Nan
> Cc: Alexei Starovoitov
> Cc: Brendan Gregg
> Cc: Daniel Borkmann
> Cc: David Ahern
> Cc: He Kuang
> Cc: Jiri Olsa
> Cc: Kaixu Xia
> Cc: Masami Hiramatsu
> Cc: Namhyung Kim
> Cc: Paul Mackerras
> Cc: Peter Zijlstra
> Cc: Zefan Li
> Cc: pi3or...@163.com
> Cc: Arnaldo Carvalho de Melo
> Link:
> http://lkml.kernel.org/n/1436445342-1402-22-git-send-email-wangn...@huawei.com
> ---
[SNIP]
> +int add_perf_probe_events(struct perf_probe_event *pevs, int npevs,
> + bool cleanup)
> +{
> + int i, ret;
>
> ret = init_symbol_maps(pevs->uprobes);
> - if (ret < 0) {
> - free(pkgs);
> + if (ret < 0)
> return ret;
> - }
>
> /* Loop 1: convert all events */
> for (i = 0; i < npevs; i++) {
> - pkgs[i].pev = [i];
> /* Init kprobe blacklist if needed */
> - if (!pkgs[i].pev->uprobes)
> + if (pevs[i].uprobes)
Missing '!'.
Thanks,
Namhyung
> kprobe_blacklist__init();
> /* Convert with or without debuginfo */
> - ret = convert_to_probe_trace_events(pkgs[i].pev,
> - [i].tevs);
> - if (ret < 0)
> + ret = convert_to_probe_trace_events([i], [i].tevs);
> + if (ret < 0) {
> + cleanup = true;
> goto end;
> - pkgs[i].ntevs = ret;
> + }
> + pevs[i].ntevs = ret;
> }
> /* This just release blacklist only if allocated */
> kprobe_blacklist__release();
>
> /* Loop 2: add all events */
> for (i = 0; i < npevs; i++) {
> - ret = __add_probe_trace_events(pkgs[i].pev, pkgs[i].tevs,
> -pkgs[i].ntevs,
> + ret = __add_probe_trace_events([i], pevs[i].tevs,
> +pevs[i].ntevs,
> probe_conf.force_add);
> if (ret < 0)
> break;
> }
> end:
> /* Loop 3: cleanup and free trace events */
> - for (i = 0; i < npevs; i++) {
> - for (j = 0; j < pkgs[i].ntevs; j++)
> - clear_probe_trace_event([i].tevs[j]);
> - zfree([i].tevs);
> - }
> - free(pkgs);
> + for (i = 0; cleanup && (i < npevs); i++)
> + cleanup_perf_probe_event([i]);
> exit_symbol_maps();
>
> return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote: > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote: >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote: >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: >> >> Hi all- >> >> >> >> Linux has a handful of weird features that are only supported for >> >> backwards compatibility. The big one is the x86_64 vsyscall page, but >> >> uselib probably belongs on the list, too, and we might end up with >> >> more at some point. >> >> >> >> I'd like to add a way that new programs can turn these features off. >> >> In particular, I want the vsyscall page to be completely gone from the >> >> perspective of any new enough program. This is straightforward if we >> >> add a system call to ask for the vsyscall page to be disabled, but I'm >> >> wondering if we can come up with a non-syscall way to do it. >> >> >> >> I think that the ideal behavior would be that anything linked against >> >> a sufficiently new libc would be detected, but I don't see a good way >> >> to do that using existing toolchain features. >> >> >> >> Ideas? We could add a new phdr for this, but then we'd need to play >> >> linker script games, and I'm not sure that could be done in a clean, >> >> extensible way. >> > >> > Is there a practical problem you're trying to solve? My understanding >> > is that the vsyscall nonsense is fully emulated now and that the ways >> > it could be used as an attack vector have been mitigated. >> >> They've been mostly mitigated, but not fully. See: >> >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html > > That looks like it would be mitigated by not having any mapping there > at all and having the kernel just catch the page fault and emulate > rather than filling it with trapping opcodes for the kernel to catch. > Oddly, that causes a compatibility problem. There's a program called pin that does dynamic instrumentation and actually expects to be able to read the targets of calls. The way that Linux handles this now is to put a literal mov $NR, %rax; syscall; ret sequence at the syscall address but to mark the whole page NX so that any attempt to call it traps. The trap gets fixed up if the call looks valid (properly aligned, etc) and the process gets SIGSEGV if not. This caught me by surprise when I implemented vsyscall emulation the first time. >> I'm also waiting for someone to find an exploit that uses one of the >> vsyscalls as a ROP gadget. > > This sounds more plausible. gettimeofday actually writes to memory > pointed to by its arguments. The others look benign. > >> > If this is not the case, I have what sounds like an elegant solution, >> > if it works: presumably affected versions of glibc that used this used >> > it for all syscalls, so if the process has made any normal syscalls >> > before using the vsyscall addresses, you can assume it's a bug/attack >> > and and just raise SIGSEGV. If there are corner cases this doesn't >> > cover, maybe the approach can still be adapted to work; it's cleaner >> > than introducing header cruft, IMO. >> >> Unfortunately, I don't think this will work. It's never been possible >> to use the vsyscalls for anything other than gettimeofday, time, or >> getcpu, so I doubt we can detect affected glibc versions that way. > > I thought the idea of the old vsyscall was that you always call it > rather than using a syscall instruction and it decides whether it can > do it in userspace or needs to make a real syscall. But if it was only > called from certain places, then yes, I think you're right that my > approach doesn't work. No, it's actually just three separate functions, one for each of gettimeofday, time, and getcpu. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm64: dts: add dts files for Hisilicon Hip05-D02 Development Board
Hi，Marc：
Can you check this, I am not sure whether the GIC_CPU_MASK_SIMPLE(xx) is used
for gic-v3, maybe we should remove it, thanks.
Ding
On 2015/8/31 21:44, Ding Tianhong wrote:
> On 2015/8/31 21:12, Leo Yan wrote:
>> On Sat, Aug 29, 2015 at 04:52:41PM +0800, Ding Tianhong wrote:
>>> Add initial dtsi file to support Hisilicon Hip05-D02 Board with
>>> support of CPUs in four clusters and each cluster has quard Cortex-A57.
>>>
>>> Also add dts file to support Hip05-D02 development board.
>>>
>>> Signed-off-by: Ding Tianhong
>>> Signed-off-by: Kefeng Wang
>>> ---
>>> arch/arm64/boot/dts/hisilicon/Makefile | 2 +-
>>> arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 36
>>> arch/arm64/boot/dts/hisilicon/hip05.dtsi| 271
>>>
>>> 3 files changed, 308 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm64/boot/dts/hisilicon/hip05-d02.dts
>>> create mode 100644 arch/arm64/boot/dts/hisilicon/hip05.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/hisilicon/Makefile
>>> b/arch/arm64/boot/dts/hisilicon/Makefile
>>> index fa81a6e..cd158b8 100644
>>> --- a/arch/arm64/boot/dts/hisilicon/Makefile
>>> +++ b/arch/arm64/boot/dts/hisilicon/Makefile
>>> @@ -1,4 +1,4 @@
>>> -dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
>>> +dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb hip05-d02.dtb
>>>
>>> always := $(dtb-y)
>>> subdir-y := $(dts-dirs)
>>> diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
>>> b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
>>> new file mode 100644
>>> index 000..ae34e25
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
>>> @@ -0,0 +1,36 @@
>>> +/**
>>> + * dts file for Hisilicon D02 Development Board
>>> + *
>>> + * Copyright (C) 2014,2015 Hisilicon Ltd.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * publishhed by the Free Software Foundation.
>>> + *
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "hip05.dtsi"
>>> +
>>> +/ {
>>> + model = "Hisilicon Hip05 D02 Development Board";
>>> + compatible = "hisilicon,hip05-d02";
>>> +
>>> + memory@ {
>>> + device_type = "memory";
>>> + reg = <0x0 0x 0x0 0x8000>;
>>> + };
>>> +
>>> + aliases {
>>> + serial0 =
>>> + };
>>> +
>>> + chosen {
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +};
>>> +
>>> + {
>>> + status = "ok";
>>> +};
>>> diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
>>> b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
>>> new file mode 100644
>>> index 000..da12d94
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
>>> @@ -0,0 +1,271 @@
>>> +/**
>>> + * dts file for Hisilicon D02 Development Board
>>> + *
>>> + * Copyright (C) 2014,2015 Hisilicon Ltd.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * publishhed by the Free Software Foundation.
>>> + *
>>> + */
>>> +
>>> +#include
>>> +
>>> +/ {
>>> + compatible = "hisilicon,hip05-d02";
>>> + interrupt-parent = <>;
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> +
>>> + psci {
>>> + compatible = "arm,psci-0.2";
>>> + method = "smc";
>>> + };
>>> +
>>> + cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + cpu-map {
>>> + cluster0 {
>>> + core0 {
>>> + cpu = <>;
>>> + };
>>> + core1 {
>>> + cpu = <>;
>>> + };
>>> + core2 {
>>> + cpu = <>;
>>> + };
>>> + core3 {
>>> + cpu = <>;
>>> + };
>>> + };
>>> + cluster1 {
>>> + core0 {
>>> + cpu = <>;
>>> + };
>>> + core1 {
>>> + cpu = <>;
>>> + };
>>> + core2 {
>>> + cpu = <>;
>>> + };
>>> + core3 {
>>> + cpu = <>;
>>> + };
>>> + };
>>> + cluster2 {
>>> + core0 {
>>> + cpu = <>;
>>> + };
>>> + core1 {
>>> + cpu = <>;
>>> + };
>>> + core2 {
>>> +
Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote: > On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote: > > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: > >> Hi all- > >> > >> Linux has a handful of weird features that are only supported for > >> backwards compatibility. The big one is the x86_64 vsyscall page, but > >> uselib probably belongs on the list, too, and we might end up with > >> more at some point. > >> > >> I'd like to add a way that new programs can turn these features off. > >> In particular, I want the vsyscall page to be completely gone from the > >> perspective of any new enough program. This is straightforward if we > >> add a system call to ask for the vsyscall page to be disabled, but I'm > >> wondering if we can come up with a non-syscall way to do it. > >> > >> I think that the ideal behavior would be that anything linked against > >> a sufficiently new libc would be detected, but I don't see a good way > >> to do that using existing toolchain features. > >> > >> Ideas? We could add a new phdr for this, but then we'd need to play > >> linker script games, and I'm not sure that could be done in a clean, > >> extensible way. > > > > Is there a practical problem you're trying to solve? My understanding > > is that the vsyscall nonsense is fully emulated now and that the ways > > it could be used as an attack vector have been mitigated. > > They've been mostly mitigated, but not fully. See: > > http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html That looks like it would be mitigated by not having any mapping there at all and having the kernel just catch the page fault and emulate rather than filling it with trapping opcodes for the kernel to catch. > I'm also waiting for someone to find an exploit that uses one of the > vsyscalls as a ROP gadget. This sounds more plausible. gettimeofday actually writes to memory pointed to by its arguments. The others look benign. > > If this is not the case, I have what sounds like an elegant solution, > > if it works: presumably affected versions of glibc that used this used > > it for all syscalls, so if the process has made any normal syscalls > > before using the vsyscall addresses, you can assume it's a bug/attack > > and and just raise SIGSEGV. If there are corner cases this doesn't > > cover, maybe the approach can still be adapted to work; it's cleaner > > than introducing header cruft, IMO. > > Unfortunately, I don't think this will work. It's never been possible > to use the vsyscalls for anything other than gettimeofday, time, or > getcpu, so I doubt we can detect affected glibc versions that way. I thought the idea of the old vsyscall was that you always call it rather than using a syscall instruction and it decides whether it can do it in userspace or needs to make a real syscall. But if it was only called from certain places, then yes, I think you're right that my approach doesn't work. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/5] Support for Open-Channel SSDs
On 08/07/2015 10:29 PM, Matias Bjørling wrote: These patches implement support for Open-Channel SSDs. Applies against axboe's linux-block/for-4.3/drivers and can be found in the lkml_v7 branch at https://github.com/OpenChannelSSD/linux Any feedback is greatly appreciated. Hi Matias, After a reading of your code, that's a great idea. I tried it with null_nvm and qemu-nvm. I have two questions here. (1), Why we name it lightnvm? IIUC, this framework can work for other flashes not only NVMe protocol. (2), There are gc and bm, but where is the wear leveling? In hardware? Thanx Yang Changes since v6: - Multipage support (Javier Gonzalez) - General code cleanups - Fixed memleak on register failure Changes since v5: Feedback from Christoph Hellwig. - Created new null_nvm from null_blk to register itself as a lightnvm device. - Changed the interface of register/unregister to only take disk_name. The gendisk alloc in nvme is kept. Most instantiations will involve the device gendisk, therefore wait with refactoring to a later time. - Renamed global parameters in core.c and rrpc.c Changes since v4: - Remove gendisk->nvm dependency - Remove device driver rq private field dependency. - Update submission and completion. The flow is now Target -> Block Manager -> Device Driver, replacing callbacks in device driver. - Abstracted out the block manager into its own module. Other block managers can now be implemented. For example to support fully host-based SSDs. - No longer exposes the device driver gendisk to user-space. - Management is moved into /sys/modules/lnvm/parameters/configure_debug Changes since v3: - Remove dependency on REQ_NVM_GC - Refactor nvme integration to use nvme_submit_sync_cmd for internal commands. - Fix race condition bug on multiple threads on RRPC target. - Rename sysfs entry under the block device from nvm to lightnvm. The configuration is found in /sys/block/*/lightnvm/ Changes since v2: Feedback from Paul Bolle: - Fix license to GPLv2, documentation, compilation. Feedback from Keith Busch: - nvme: Move lightnvm out and into nvme-lightnvm.c. - nvme: Set controller css on lightnvm command set. - nvme: Remove OACS. Feedback from Christoph Hellwig: - lightnvm: Move out of block layer into /drivers/lightnvm/core.c - lightnvm: refactor request->phys_sector into device drivers. - lightnvm: refactor prep/unprep into device drivers. - lightnvm: move nvm_dev from request_queue to gendisk. New - Bad block table support (From Javier). - Update maintainers file. Changes since v1: - Splitted LightNVM into two parts. A get/put interface for flash blocks and the respective targets that implement flash translation layer logic. - Updated the patches according to the LightNVM specification changes. - Added interface to add/remove targets for a block device. Thanks to Jens Axboe, Christoph Hellwig, Keith Busch, Paul Bolle, Javier Gonzalez and Jesper Madsen for discussions and contributions. Matias Bjørling (5): lightnvm: Support for Open-Channel SSDs lightnvm: Hybrid Open-Channel SSD RRPC target lightnvm: Hybrid Open-Channel SSD block manager null_nvm: Lightnvm test driver nvme: LightNVM support MAINTAINERS |8 + drivers/Kconfig |2 + drivers/Makefile |5 + drivers/block/Makefile|2 +- drivers/block/nvme-core.c | 23 +- drivers/block/nvme-lightnvm.c | 568 ++ drivers/lightnvm/Kconfig | 36 ++ drivers/lightnvm/Makefile |8 + drivers/lightnvm/bm_hb.c | 366 drivers/lightnvm/bm_hb.h | 46 ++ drivers/lightnvm/core.c | 591 +++ drivers/lightnvm/null_nvm.c | 481 +++ drivers/lightnvm/rrpc.c | 1296 + drivers/lightnvm/rrpc.h | 236 include/linux/lightnvm.h | 334 +++ include/linux/nvme.h |6 + include/uapi/linux/nvme.h |3 + 17 files changed, 4007 insertions(+), 4 deletions(-) create mode 100644 drivers/block/nvme-lightnvm.c create mode 100644 drivers/lightnvm/Kconfig create mode 100644 drivers/lightnvm/Makefile create mode 100644 drivers/lightnvm/bm_hb.c create mode 100644 drivers/lightnvm/bm_hb.h create mode 100644 drivers/lightnvm/core.c create mode 100644 drivers/lightnvm/null_nvm.c create mode 100644 drivers/lightnvm/rrpc.c create mode 100644 drivers/lightnvm/rrpc.h create mode 100644 include/linux/lightnvm.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the rcu tree
Hi Paul,
On Tue, 1 Sep 2015 00:49:46 -0700 "Paul E. McKenney"
wrote:
>
> On Tue, Sep 01, 2015 at 01:50:06PM +1000, Stephen Rothwell wrote:
> >
> > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > ERROR: "sched_setscheduler_nocheck" [kernel/locking/locktorture.ko]
> > undefined!
> > ERROR: "percpu_down_write" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "percpu_up_write" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "percpu_down_read" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "percpu_up_read" [kernel/locking/locktorture.ko] undefined!
> > ERROR: "__percpu_init_rwsem" [kernel/locking/locktorture.ko] undefined!
> >
> > Caused by commits
> >
> > 04be76a9b067 ("locktorture: Support rtmutex torturing")
> > 40b2996f9b32 ("locktorture: Add torture tests for percpu_rwsem")
> >
> > and maybe more.
> >
> > I have used the rcu tree from next-20150831 for today.
>
> It is looking like I will be deferring these to v4.4, apologies for
> the hassle!
This still fails to build but now I only get the error about
sched_setscheduler_nocheck.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote: > -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, September 02, 2015 11:09 AM > To: Zhao Qiang-B45475 > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li > Yang-Leo-R58472; pau...@samba.org > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > bytes-alignment to genalloc > > On Tue, 2015-09-01 at 22:05 -0500, Zhao Qiang-B45475 wrote: > > On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote: > > > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Wednesday, September 02, 2015 10:33 AM > > > To: Zhao Qiang-B45475 > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; > > > Li Yang-Leo-R58472; pau...@samba.org > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > > bytes-alignment to genalloc > > > > > > On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote: > > > > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote: > > > > > -Original Message- > > > > > From: Wood Scott-B07421 > > > > > Sent: Wednesday, September 02, 2015 10:18 AM > > > > > To: Zhao Qiang-B45475 > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061; > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation > > > > > with bytes-alignment to genalloc > > > > > > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote: > > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote: > > > > > > > -Original Message- > > > > > > > From: Wood Scott-B07421 > > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM > > > > > > > To: Zhao Qiang-B45475 > > > > > > > Cc: linux-kernel@vger.kernel.org; > > > > > > > linuxppc-...@lists.ozlabs.org; lau...@codeaurora.org; Xie > > > > > > > Xiaobo-R63061; b...@kernel.crashing.org; Li Yang-Leo-R58472; > > > > > > > pau...@samba.org > > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support > > > > > > > memory-allocation with bytes-alignment to genalloc > > > > > > > > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote: > > > > > > > > Bytes alignment is required to manage some special RAM, so > > > > > > > > add gen_pool_first_fit_align to genalloc, meanwhile add > > > > > > > > gen_pool_alloc_data to pass data to > > > > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a > > > > > > > > wrapper) > > > > > > > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > > > > --- > > > > > > > > Changes for v6: > > > > > > > > - patches set v6 include a new patch because of using > > > > > > > > - genalloc to manage QE MURAM, patch 0001 is the new > > > > > > > > - patch, adding bytes alignment for allocation for > use. > > > > > > > > Changes for v7: > > > > > > > > - cpm muram also need to use genalloc to manage, it > has > > > > > > > > a function to reserve a specific region of muram, > > > > > > > > add offset to genpool_data for start addr to be > > > allocated. > > > > > > > > > > > > > > This seems to be describing more than just the changes in > > > > > > > this > > > patch. > > > > > > > What does also handling cpm have to do with this patch? Are > > > > > > > you adding support for reserving a specific region in this > > > > > > > patch? I don't see it, and in any case it should go in a > different patch. > > > > > > > > > > > > Yes, I added. The code below can support the function. > > > > > > offset_bit = (alignment->offset + (1UL << order) - 1) >> > > > order; > > > > > > return bitmap_find_next_zero_area(map, size, start + > > > > > > offset_bit, > > > > > nr, > > > > > > align_mask); > > > > > > > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate > > > > > > muram from a Specific offset. So I add the code and add offset > > > > > > to > > > struct data. > > > > > > > > > > I thought the offset was related to the previous discussion of > > > > > checking for allocation failure. Are you using it to implement > > > > > alloc_fixed()? If so, please don't. Besides the awkward > > > > > implementation (what does it logically have to do with > > > > > gen_pool_first_fit_align?), it does not appear to be correct - > > > > > - what happens with multiple chunks? What happens if part of > > > > > the region the caller is trying to reserve is already taken? > > > > > Implement a proper function to reserve a fixed genalloc region. > > > > > > > > This offset is totally different with the workaround OFFSET! > > > > > > There's a reason why we write changelogs that describe what the > > > patch is doing, and avoid combining logically distinct
Re: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs
On 08/07/2015 10:29 PM, Matias Bjørling wrote: Open-channel SSDs are devices that share responsibilities with the host in order to implement and maintain features that typical SSDs keep strictly in firmware. These include (i) the Flash Translation Layer (FTL), (ii) bad block management, and (iii) hardware units such as the flash controller, the interface controller, and large amounts of flash chips. In this way, Open-channels SSDs exposes direct access to their physical flash storage, while keeping a subset of the internal features of SSDs. LightNVM is a specification that gives support to Open-channel SSDs LightNVM allows the host to manage data placement, garbage collection, and parallelism. Device specific responsibilities such as bad block management, FTL extensions to support atomic IOs, or metadata persistence are still handled by the device. The implementation of LightNVM consists of two parts: core and (multiple) targets. The core implements functionality shared across targets. This is initialization, teardown and statistics. The targets implement the interface that exposes physical flash to user-space applications. Examples of such targets include key-value store, object-store, as well as traditional block devices, which can be application-specific. Contributions in this patch from: Javier Gonzalez Jesper Madsen Signed-off-by: Matias Bjørling --- MAINTAINERS | 8 + drivers/Kconfig | 2 + drivers/Makefile | 5 + drivers/lightnvm/Kconfig | 16 ++ drivers/lightnvm/Makefile | 5 + drivers/lightnvm/core.c | 590 ++ include/linux/lightnvm.h | 335 ++ 7 files changed, 961 insertions(+) create mode 100644 drivers/lightnvm/Kconfig create mode 100644 drivers/lightnvm/Makefile create mode 100644 drivers/lightnvm/core.c create mode 100644 include/linux/lightnvm.h diff --git a/MAINTAINERS b/MAINTAINERS index 2d3d55c..d149104 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6162,6 +6162,14 @@ S: Supported F:drivers/nvdimm/pmem.c F:include/linux/pmem.h +LIGHTNVM PLATFORM SUPPORT +M: Matias Bjorling +W: http://github/OpenChannelSSD +S: Maintained +F: drivers/lightnvm/ +F: include/linux/lightnvm.h +F: include/uapi/linux/lightnvm.h + LINUX FOR IBM pSERIES (RS/6000) M:Paul Mackerras W:http://www.ibm.com/linux/ltc/projects/ppc diff --git a/drivers/Kconfig b/drivers/Kconfig index 6e973b8..3992902 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -42,6 +42,8 @@ source "drivers/net/Kconfig" source "drivers/isdn/Kconfig" +source "drivers/lightnvm/Kconfig" + # input before char - char/joystick depends on it. As does USB. source "drivers/input/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index b64b49f..75978ab 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -63,6 +63,10 @@ obj-$(CONFIG_FB_I810) += video/fbdev/i810/ obj-$(CONFIG_FB_INTEL) += video/fbdev/intelfb/ obj-$(CONFIG_PARPORT) += parport/ + +# lightnvm/ comes before block to initialize bm before usage +obj-$(CONFIG_NVM) += lightnvm/ + obj-y += base/ block/ misc/ mfd/ nfc/ obj-$(CONFIG_LIBNVDIMM) += nvdimm/ obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/ @@ -165,3 +169,4 @@ obj-$(CONFIG_RAS) += ras/ obj-$(CONFIG_THUNDERBOLT) += thunderbolt/ obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/ obj-$(CONFIG_ANDROID) += android/ + diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig new file mode 100644 index 000..1f8412c --- /dev/null +++ b/drivers/lightnvm/Kconfig @@ -0,0 +1,16 @@ +# +# Open-Channel SSD NVM configuration +# + +menuconfig NVM + bool "Open-Channel SSD target support" + depends on BLOCK + help + Say Y here to get to enable Open-channel SSDs. + + Open-Channel SSDs implement a set of extension to SSDs, that + exposes direct access to the underlying non-volatile memory. + + If you say N, all options in this submenu will be skipped and disabled + only do this if you know what you are doing. + diff --git a/drivers/lightnvm/Makefile b/drivers/lightnvm/Makefile new file mode 100644 index 000..38185e9 --- /dev/null +++ b/drivers/lightnvm/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for Open-Channel SSDs. +# + +obj-$(CONFIG_NVM) := core.o diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c new file mode 100644 index 000..6499922 --- /dev/null +++ b/drivers/lightnvm/core.c @@ -0,0 +1,590 @@ +/* + * Copyright (C) 2015 IT University of Copenhagen + * Initial release: Matias Bjorling + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + * + * This program is distributed in
Re: commit 3c2e7f7de3 (KVM use NPT page attributes) causes boot failures
On 2015.09.02 at 06:31 +0800, Xiao Guangrong wrote: > > > On 09/01/2015 09:56 PM, Markus Trippelsdorf wrote: > > On 2015.09.01 at 21:00 +0800, Xiao Guangrong wrote: > >> > >> Did it trigger the BUG()/BUG_ON() in mtrr2protval()/fallback_mtrr_type()? > >> If yes, could you please print the actual value out? > > > > It is the BUG() in fallback_mtrr_type(). I changed it to a printk and > > it prints 1 for the value of mtrr. > > > > MTRR_TYPE_WRCOMB 1 > > > > Then I suspect pat is not enabled in your box, could you please check > CONFIG_X86_PAT is selected in your .config file, pat is shown in > /proc/cpuid, "nopat" kernel parameter is used, and dmesg | grep PAT. No. PAT is of course enabled and booting is successful sometimes even with the BUG() in allback_mtrr_type(). I suspect a setup (timing) issue. markus@x4 linux % cat .config | grep X86_PAT CONFIG_X86_PAT=y markus@x4 linux % dmesg | grep PAT [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT markus@x4 linux % cat /proc/cpuinfo| grep pat flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save vmmcall ... -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Firmware Signing
On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote: > On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez wrote: > > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: > >> > > eBPF/seccomp > > > > OK I knew nothing about this but I just looked into it, here are my notes: > > > > * old BPF - how far do we want to go? This goes so far as to parsing > > user passed void __user *arg data through ioctls which typically > > gets copy_from_user()'d and eventually gets BPF_PROG_RUN(). > > > > * eBPF: > > seccomp() & prctl_set_seccomp() > > | > > V > > do_seccomp() > > | > > V > > seccomp_set_mode_filter() > > | > > V > > seccomp_prepare_user_filter() > > | > > V > > bpf_prog_create_from_user() (seccomp) \ > > bpf_prog_create() > bpf_prepare_filter() > > sk_attach_filter()/ > > > > All approaches come from user passed data, nothing fd based. > > > > For both old BPF and eBPF then: > > > > If we wanted to be paranoid I suppose the Machine Owner Key (MOK) > > Paul had mentioned up could be used to vet for passed filters, or > > a new interface to enable fd based filters. This really would limit > > the dynamic nature of these features though. > > > > eBPF / secccomp would not be the only place in the kernel that would > > have > > issues with user passed data, we have tons of places the same applies so > > implicating the old BPF / eBPF / seccomp approaches can easily implicate > > many other areas of the kernel, that's pretty huge but from the looks of > > it below you seem to enable that to be a possibility for us to consider. > > At the time (LSS 2014?) I argued that seccomp policies come from > binaries, which are already being measured. And that policies only > further restrict a process, so there seems to be to be little risk in > continuing to leave them unmeasured. What do you mean by "measured"? Who is doing the measurement? Could someone detect a change in measurement? Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote: > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: >> Hi all- >> >> Linux has a handful of weird features that are only supported for >> backwards compatibility. The big one is the x86_64 vsyscall page, but >> uselib probably belongs on the list, too, and we might end up with >> more at some point. >> >> I'd like to add a way that new programs can turn these features off. >> In particular, I want the vsyscall page to be completely gone from the >> perspective of any new enough program. This is straightforward if we >> add a system call to ask for the vsyscall page to be disabled, but I'm >> wondering if we can come up with a non-syscall way to do it. >> >> I think that the ideal behavior would be that anything linked against >> a sufficiently new libc would be detected, but I don't see a good way >> to do that using existing toolchain features. >> >> Ideas? We could add a new phdr for this, but then we'd need to play >> linker script games, and I'm not sure that could be done in a clean, >> extensible way. > > Is there a practical problem you're trying to solve? My understanding > is that the vsyscall nonsense is fully emulated now and that the ways > it could be used as an attack vector have been mitigated. They've been mostly mitigated, but not fully. See: http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html I'm also waiting for someone to find an exploit that uses one of the vsyscalls as a ROP gadget. > > If this is not the case, I have what sounds like an elegant solution, > if it works: presumably affected versions of glibc that used this used > it for all syscalls, so if the process has made any normal syscalls > before using the vsyscall addresses, you can assume it's a bug/attack > and and just raise SIGSEGV. If there are corner cases this doesn't > cover, maybe the approach can still be adapted to work; it's cleaner > than introducing header cruft, IMO. Unfortunately, I don't think this will work. It's never been possible to use the vsyscalls for anything other than gettimeofday, time, or getcpu, so I doubt we can detect affected glibc versions that way. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Firmware Signing
On Wed, 2015-09-02 at 02:09 +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote:
> > On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez wrote:
> > As long as the LSM know what kind of file it's loading, and has access
> > to the fd (and for IMA, the blob loaded from that fd), that should be
> > everything it needs. IMA has the name and blob, loadpin has the fd,
> > and a future signature-checking LSM could be able to look up signature
> > type from the load type, and split the key off (or fetch the key file)
> > itself.
I assume "and for IMA, the blob loaded from that fd" is referring to
the file signature stored in the xattr.
> OK great, I think that instead of passing the actual routine name we should
> instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> then have each case well documented. Each LSM then could add its own
> documetnation for this and can switch on it. If we went with a name we'd have
> to to use something like __func__ and then parse that, its not clear if we
> need
> to get that specific.
Agreed. IMA already defines an enumeration.
/* IMA policy related functions */
enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Ext3 removal, quota & udf fixes
2015-08-31 23:53 GMT-03:00 Theodore Ts'o : > Yes, you can go back to ext3-only. In fact, we do *not* automatically > upgrade the file system to use ext4-specific features. > >> So it's not just a "you can use ext4 instead" issue. Can you do that >> *without* then forcing an upgrade forever on that partition? I'm not >> sure the ext4 people are really even willing to guarantee that kind of >> backwards compatibility. > > Actually, we do guarantee this. It's considered poor form to > automatically change the superblock to add new file system features in > a way that would break the ability for the user to roll back to an > older kernel. This isn't just for ext3->ext4, but for new ext4 > features such as metadata checksumming. The user has to explicitly > enable the feature using "tune2fs -O new_feature /dev/sdXX". Yeah! 2015-09-01 16:39 GMT-03:00 Austin S Hemmelgarn : > NO, it is not logical. A vast majority of Android smartphones in the wild > use ext2, as do a very significant portion of embedded systems that don't > have room for the few hundred kilobytes of extra code that the ext4 driver > has in comparison to ext2. Ext2 portion embedded and Ext3 many machines. -- Albino B Neto www.bino.us "Debian. Freedom to code. Code to freedom!" faw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node
ping... this boot failure has now landed in mainline On Thu, Aug 27, 2015 at 1:51 PM, Kevin Hilman wrote: > On Wed, Jul 29, 2015 at 5:11 PM, NeilBrown wrote: >> Now that twl4030_bci_probe can safely return -EPROBE_DEFER, >> do so when devm_usb_get_phy_by_node returns that error. >> >> Signed-off-by: NeilBrown > > This patch has hit linux-next in the form of coommit 3fc3895e4fe1 > (twl4030_charger: correctly handle -EPROBE_DEFER from > devm_usb_get_phy_by_node) and kernelci.org found a regression on > omap3-beagle-xm[1]. Bisecting[2] this boot failure pointed at this > commit, and I verified that reverting it on top of next-20150827 gets > the board booting again. I haven't debugged any further. > > Kevin > > [1] > http://storage.kernelci.org/next/next-20150827/arm-omap2plus_defconfig/lab-khilman/boot-omap3-beagle-xm.html > [2] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/88/console -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dax, pmem: add support for msync
On Wed, Sep 02, 2015 at 08:21:20AM +1000, Dave Chinner wrote: > Which means applications that should "just work" without > modification on DAX are now subtly broken and don't actually > guarantee data is safe after a crash. That's a pretty nasty > landmine, and goes against *everything* we've claimed about using > DAX with existing applications. > > That's wrong, and needs fixing. I agree that we need to fix fsync as well, and that the fsync solution could be used to implement msync if we choose to go that route. I think we might want to consider keeping the msync and fsync implementations separate, though, for two reasons. 1) The current msync implementation is much more efficient than what will be needed for fsync. Fsync will need to call into the filesystem, traverse all the blocks, get kernel virtual addresses from those and then call wb_cache_pmem() on those kernel addresses. I think this is a necessary evil for fsync since you don't have a VMA, but for msync we do and we can just flush using the user addresses without any fs lookups. 2) I believe that the near-term fsync code will rely on struct pages for PMEM, which I believe are possible but optional as of Dan's last patch set: https://lkml.org/lkml/2015/8/25/841 I believe that this means that if we don't have struct pages for PMEM (becuase ZONE_DEVICE et al. are turned off) fsync won't work. I'd be nice not to lose msync as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On Tue, 2015-09-01 at 22:05 -0500, Zhao Qiang-B45475 wrote: > On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote: > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Wednesday, September 02, 2015 10:33 AM > > To: Zhao Qiang-B45475 > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li > > Yang-Leo-R58472; pau...@samba.org > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > bytes-alignment to genalloc > > > > On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote: > > > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote: > > > > -Original Message- > > > > From: Wood Scott-B07421 > > > > Sent: Wednesday, September 02, 2015 10:18 AM > > > > To: Zhao Qiang-B45475 > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; > > > > Li Yang-Leo-R58472; pau...@samba.org > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > > > bytes-alignment to genalloc > > > > > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote: > > > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote: > > > > > > -Original Message- > > > > > > From: Wood Scott-B07421 > > > > > > Sent: Wednesday, September 02, 2015 8:30 AM > > > > > > To: Zhao Qiang-B45475 > > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061; > > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org > > > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation > > > > > > with bytes-alignment to genalloc > > > > > > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote: > > > > > > > Bytes alignment is required to manage some special RAM, so add > > > > > > > gen_pool_first_fit_align to genalloc, meanwhile add > > > > > > > gen_pool_alloc_data to pass data to > > > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper) > > > > > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > > > --- > > > > > > > Changes for v6: > > > > > > > - patches set v6 include a new patch because of using > > > > > > > - genalloc to manage QE MURAM, patch 0001 is the new > > > > > > > - patch, adding bytes alignment for allocation for use. > > > > > > > Changes for v7: > > > > > > > - cpm muram also need to use genalloc to manage, it has > > > > > > > a function to reserve a specific region of muram, > > > > > > > add offset to genpool_data for start addr to be > > allocated. > > > > > > > > > > > > This seems to be describing more than just the changes in this > > patch. > > > > > > What does also handling cpm have to do with this patch? Are you > > > > > > adding support for reserving a specific region in this patch? I > > > > > > don't see it, and in any case it should go in a different patch. > > > > > > > > > > Yes, I added. The code below can support the function. > > > > > offset_bit = (alignment->offset + (1UL << order) - 1) >> > > order; > > > > > return bitmap_find_next_zero_area(map, size, start + > > > > > offset_bit, > > > > nr, > > > > > align_mask); > > > > > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate > > > > > muram from a Specific offset. So I add the code and add offset to > > struct data. > > > > > > > > I thought the offset was related to the previous discussion of > > > > checking for allocation failure. Are you using it to implement > > > > alloc_fixed()? If so, please don't. Besides the awkward > > > > implementation (what does it logically have to do with > > > > gen_pool_first_fit_align?), it does not appear to be correct - > > > > - what happens with multiple chunks? What happens if part of the > > > > region the caller is trying to reserve is already taken? Implement > > > > a proper function to reserve a fixed genalloc region. > > > > > > This offset is totally different with the workaround OFFSET! > > > > There's a reason why we write changelogs that describe what the patch is > > doing, and avoid combining logically distinct changes in the same patch. > > > > > This offset is the offset of the muram. > > > > The offset of the muram relative to what? Or do you mean the offset into > > muram? > > Yes, the offset into muram. > > > > > > CPM need to allocate block from a specific offset due to hardware > > > restriction. > > > So I must handle this offset in genalloc. > > > > Again, if you need to be able to mark a specific range reserved, add a > > function that does that properly. Don't try to hack it in the way you > > did. > > Add a function? Do you mean add a new alloc function or new algo? > If you mean new algo, CPM use both align algo and new algo, set > Different algos in different
Re: Linux Firmware Signing
On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez wrote: > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: >> > > eBPF/seccomp > > OK I knew nothing about this but I just looked into it, here are my notes: > > * old BPF - how far do we want to go? This goes so far as to parsing > user passed void __user *arg data through ioctls which typically > gets copy_from_user()'d and eventually gets BPF_PROG_RUN(). > > * eBPF: > seccomp() & prctl_set_seccomp() > | > V > do_seccomp() > | > V > seccomp_set_mode_filter() > | > V > seccomp_prepare_user_filter() > | > V > bpf_prog_create_from_user() (seccomp) \ > bpf_prog_create() > bpf_prepare_filter() > sk_attach_filter()/ > > All approaches come from user passed data, nothing fd based. > > For both old BPF and eBPF then: > > If we wanted to be paranoid I suppose the Machine Owner Key (MOK) > Paul had mentioned up could be used to vet for passed filters, or > a new interface to enable fd based filters. This really would limit > the dynamic nature of these features though. > > eBPF / secccomp would not be the only place in the kernel that would have > issues with user passed data, we have tons of places the same applies so > implicating the old BPF / eBPF / seccomp approaches can easily implicate > many other areas of the kernel, that's pretty huge but from the looks of > it below you seem to enable that to be a possibility for us to consider. At the time (LSS 2014?) I argued that seccomp policies come from binaries, which are already being measured. And that policies only further restrict a process, so there seems to be to be little risk in continuing to leave them unmeasured. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 10:33 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
>
> On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > Bytes alignment is required to manage some special RAM, so add
> > > > > > gen_pool_first_fit_align to genalloc, meanwhile add
> > > > > > gen_pool_alloc_data to pass data to
> > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)
> > > > > >
> > > > > > Signed-off-by: Zhao Qiang
> > > > > > ---
> > > > > > Changes for v6:
> > > > > > - patches set v6 include a new patch because of using
> > > > > > - genalloc to manage QE MURAM, patch 0001 is the new
> > > > > > - patch, adding bytes alignment for allocation for use.
> > > > > > Changes for v7:
> > > > > > - cpm muram also need to use genalloc to manage, it has
> > > > > > a function to reserve a specific region of muram,
> > > > > > add offset to genpool_data for start addr to be
> allocated.
> > > > >
> > > > > This seems to be describing more than just the changes in this
> patch.
> > > > > What does also handling cpm have to do with this patch? Are you
> > > > > adding support for reserving a specific region in this patch? I
> > > > > don't see it, and in any case it should go in a different patch.
> > > >
> > > > Yes, I added. The code below can support the function.
> > > > offset_bit = (alignment->offset + (1UL << order) - 1) >>
> order;
> > > > return bitmap_find_next_zero_area(map, size, start +
> > > > offset_bit,
> > > nr,
> > > > align_mask);
> > > >
> > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > muram from a Specific offset. So I add the code and add offset to
> struct data.
> > >
> > > I thought the offset was related to the previous discussion of
> > > checking for allocation failure. Are you using it to implement
> > > alloc_fixed()? If so, please don't. Besides the awkward
> > > implementation (what does it logically have to do with
> > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > - what happens with multiple chunks? What happens if part of the
> > > region the caller is trying to reserve is already taken? Implement
> > > a proper function to reserve a fixed genalloc region.
> >
> > This offset is totally different with the workaround OFFSET!
>
> There's a reason why we write changelogs that describe what the patch is
> doing, and avoid combining logically distinct changes in the same patch.
>
> > This offset is the offset of the muram.
>
> The offset of the muram relative to what? Or do you mean the offset into
> muram?
Yes, the offset into muram.
>
> > CPM need to allocate block from a specific offset due to hardware
> > restriction.
> > So I must handle this offset in genalloc.
>
> Again, if you need to be able to mark a specific range reserved, add a
> function that does that properly. Don't try to hack it in the way you
> did.
Add a function? Do you mean add a new alloc function or new algo?
If you mean new algo, CPM use both align algo and new algo, set
Different algos in different muram_alloc func?
>
> -Scott
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] perf tools: Don't set leader if parser doesn't collect an evsel
On 2015/9/2 10:53, Wang Nan wrote:
Similar to patch 'perf tools: Don't set cmdline_group_boundary if no
evsel is collected', in case when parser collects no evsel (at this
point it shouldn't happen), parse_events__set_leader() is not safe.
This patch checks list_empty becore calling __perf_evlist__set_leader()
for safty reason.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Alexei Starovoitov
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
---
I'd like to queue this patch into my next pull request. Since it is not
a real bug, it may be dropped.
I think merging this into patch 2/31 should be better. If we decide to
drop then
only one patch should be considered.
---
tools/perf/util/parse-events.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index f2c0317..836d226 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -793,6 +793,9 @@ void parse_events__set_leader(char *name, struct list_head
*list)
{
struct perf_evsel *leader;
+ if (list_empty(list))
+ return;
+
__perf_evlist__set_leader(list);
leader = list_entry(list->next, struct perf_evsel, node);
leader->group_name = name ? strdup(name) : NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: Hi6220: separately build stub clock driver
The previous code, kernel builds Hi6220's common clock driver and stub clock driver together. Stub clock driver has introduced the dependency with CONFIG_MAILBOX, so kernel will not build Hi6220's common clock driver due ARM64's defconfig have not enabled CONFIG_MAILBOX by default. So separately build stub clock driver and common clock driver for Hi6220; and only let stub clock driver has the dependency with CONFIG_MAILBOX. Signed-off-by: Leo Yan --- drivers/clk/hisilicon/Kconfig | 8 +++- drivers/clk/hisilicon/Makefile | 3 ++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig index 2c16807..e434854 100644 --- a/drivers/clk/hisilicon/Kconfig +++ b/drivers/clk/hisilicon/Kconfig @@ -1,6 +1,12 @@ config COMMON_CLK_HI6220 bool "Hi6220 Clock Driver" - depends on (ARCH_HISI || COMPILE_TEST) && MAILBOX + depends on ARCH_HISI || COMPILE_TEST default ARCH_HISI help Build the Hisilicon Hi6220 clock driver based on the common clock framework. + +config STUB_CLK_HI6220 + bool "Hi6220 Stub Clock Driver" + depends on COMMON_CLK_HI6220 && MAILBOX + help + Build the Hisilicon Hi6220 stub clock driver. diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile index 4a1001a..74dba31 100644 --- a/drivers/clk/hisilicon/Makefile +++ b/drivers/clk/hisilicon/Makefile @@ -7,4 +7,5 @@ obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o -obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o clk-hi6220-stub.o +obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o +obj-$(CONFIG_STUB_CLK_HI6220) += clk-hi6220-stub.o -- 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] perf tools: Don't set leader if parser doesn't collect an evsel
Similar to patch 'perf tools: Don't set cmdline_group_boundary if no
evsel is collected', in case when parser collects no evsel (at this
point it shouldn't happen), parse_events__set_leader() is not safe.
This patch checks list_empty becore calling __perf_evlist__set_leader()
for safty reason.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Alexei Starovoitov
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
---
I'd like to queue this patch into my next pull request. Since it is not
a real bug, it may be dropped.
---
tools/perf/util/parse-events.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index f2c0317..836d226 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -793,6 +793,9 @@ void parse_events__set_leader(char *name, struct list_head
*list)
{
struct perf_evsel *leader;
+ if (list_empty(list))
+ return;
+
__perf_evlist__set_leader(list);
leader = list_entry(list->next, struct perf_evsel, node);
leader->group_name = name ? strdup(name) : NULL;
--
1.8.3.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: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: > Hi all- > > Linux has a handful of weird features that are only supported for > backwards compatibility. The big one is the x86_64 vsyscall page, but > uselib probably belongs on the list, too, and we might end up with > more at some point. > > I'd like to add a way that new programs can turn these features off. > In particular, I want the vsyscall page to be completely gone from the > perspective of any new enough program. This is straightforward if we > add a system call to ask for the vsyscall page to be disabled, but I'm > wondering if we can come up with a non-syscall way to do it. > > I think that the ideal behavior would be that anything linked against > a sufficiently new libc would be detected, but I don't see a good way > to do that using existing toolchain features. > > Ideas? We could add a new phdr for this, but then we'd need to play > linker script games, and I'm not sure that could be done in a clean, > extensible way. Is there a practical problem you're trying to solve? My understanding is that the vsyscall nonsense is fully emulated now and that the ways it could be used as an attack vector have been mitigated. If this is not the case, I have what sounds like an elegant solution, if it works: presumably affected versions of glibc that used this used it for all syscalls, so if the process has made any normal syscalls before using the vsyscall addresses, you can assume it's a bug/attack and and just raise SIGSEGV. If there are corner cases this doesn't cover, maybe the approach can still be adapted to work; it's cleaner than introducing header cruft, IMO. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/4] of: overlay: global sysfs enable attribute
On Fri, Jun 12, 2015 at 2:38 PM, Pantelis Antoniou
wrote:
> A throw once master enable switch to protect against any
> further overlay applications if the administrator desires so.
>
> Signed-off-by: Pantelis Antoniou
I had some questioning whether we want more states than just on/off
like "only add sub-trees", but I've convinced myself it is better to
keep the kill switch simple. So I'm okay with patches 1 and 2 (and the
relevant part of 4 if you want to split it). I think #3 needs to be
part of how we expect userspace to interact with overlays.
Please respin and I will queue at least the kill switch for 4.4 unless
there are further comments.
Rob
> ---
> drivers/of/overlay.c | 43 ++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index f17f5ef..37ec858 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include "of_private.h"
>
> @@ -55,8 +56,12 @@ struct of_overlay {
> struct kobject kobj;
> };
>
> +/* master enable switch; once set to 0 can't be re-enabled */
> +static atomic_t ov_enable = ATOMIC_INIT(1);
> +
> static int of_overlay_apply_one(struct of_overlay *ov,
> struct device_node *target, const struct device_node
> *overlay);
> +static int overlay_removal_is_ok(struct of_overlay *ov);
>
> static int of_overlay_apply_single_property(struct of_overlay *ov,
> struct device_node *target, struct property *prop)
> @@ -339,6 +344,35 @@ void of_overlay_release(struct kobject *kobj)
> kfree(ov);
> }
>
> +static ssize_t enable_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(_enable));
> +}
> +
> +static ssize_t enable_store(struct kobject *kobj,
> + struct kobj_attribute *attr, const char *buf, size_t count)
> +{
> + int ret;
> + bool new_enable;
> +
> + ret = strtobool(buf, _enable);
> + if (ret != 0)
> + return ret;
> + /* if we've disabled it, no going back */
> + if (atomic_read(_enable) == 0)
> + return -EPERM;
> + atomic_set(_enable, (int)new_enable);
> + return count;
> +}
> +
> +static struct kobj_attribute enable_attr = __ATTR_RW(enable);
> +
> +static const struct attribute *overlay_global_attrs[] = {
> + _attr.attr,
> + NULL
> +};
> +
> static struct kobj_type of_overlay_ktype = {
> .release = of_overlay_release,
> };
> @@ -360,6 +394,10 @@ int of_overlay_create(struct device_node *tree)
> struct of_overlay *ov;
> int err, id;
>
> + /* administratively disabled */
> + if (!atomic_read(_enable))
> + return -EPERM;
> +
> /* allocate the overlay structure */
> ov = kzalloc(sizeof(*ov), GFP_KERNEL);
> if (ov == NULL)
> @@ -596,5 +634,8 @@ int of_overlay_init(void)
> if (!ov_kset)
> return -ENOMEM;
>
> - return 0;
> + rc = sysfs_create_files(_kset->kobj, overlay_global_attrs);
> + WARN(rc, "%s: error adding global attributes\n", __func__);
> +
> + return rc;
> }
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [lkp] [x86/build] b2c51106c75: -18.1% will-it-scale.per_process_ops
On Wed, 2015-08-05 at 10:38 +0200, Ingo Molnar wrote:
> * kernel test robot wrote:
>
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/asm
> > commit b2c51106c7581866c37ffc77c5d739f3d4b7cbc9 ("x86/build: Fix detection
> > of GCC -mpreferred-stack-boundary support")
>
> Does the performance regression go away reproducibly if you do:
>
>git revert b2c51106c7581866c37ffc77c5d739f3d4b7cbc9
>
> ?
Sorry for reply so late!
Revert the commit will restore part of the performance, as below.
parent commit: f2a50f8b7da45ff2de93a71393e715a2ab9f3b68
the commit:b2c51106c7581866c37ffc77c5d739f3d4b7cbc9
revert commit: 987d12601a4a82cc2f2151b1be704723eb84cb9d
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/test:
wsm/will-it-scale/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/readseek2
commit:
f2a50f8b7da45ff2de93a71393e715a2ab9f3b68
b2c51106c7581866c37ffc77c5d739f3d4b7cbc9
987d12601a4a82cc2f2151b1be704723eb84cb9d
f2a50f8b7da45ff2 b2c51106c7581866c37ffc77c5 987d12601a4a82cc2f2151b1be
-- --
%stddev %change %stddev %change %stddev
\ |\ |\
879002 ± 0% -18.1% 720270 ± 7% -3.6% 847011 ± 2%
will-it-scale.per_process_ops
0.02 ± 0% +34.5% 0.02 ± 7% +5.6% 0.02 ± 2%
will-it-scale.scalability
11144 ± 0% +0.1% 11156 ± 0% +10.6% 12320 ± 0%
will-it-scale.time.minor_page_faults
769.30 ± 0% -0.9% 762.15 ± 0% +1.1% 777.42 ± 0%
will-it-scale.time.system_time
26153173 ± 0% +7.0% 27977076 ± 0% +3.5% 27078124 ± 0%
will-it-scale.time.voluntary_context_switches
2964 ± 2% +1.4% 3004 ± 1% -51.9% 1426 ± 2%
proc-vmstat.pgactivate
0.06 ± 27%+154.5% 0.14 ± 44%+122.7% 0.12 ± 24%
turbostat.CPU%c3
370683 ± 0% +6.2% 393491 ± 0% +2.4% 379575 ± 0%
vmstat.system.cs
11144 ± 0% +0.1% 11156 ± 0% +10.6% 12320 ± 0%
time.minor_page_faults
15.70 ± 2% +14.5% 17.98 ± 0% +1.5% 15.94 ± 1%
time.user_time
830343 ± 56% -54.0% 382128 ± 39% -22.3% 645308 ± 65%
cpuidle.C1E-NHM.time
788.25 ± 14% -21.7% 617.25 ± 16% -12.3% 691.00 ± 3%
cpuidle.C1E-NHM.usage
2489132 ± 20% +79.3%4464147 ± 33% +78.4%4440574 ± 21%
cpuidle.C3-NHM.time
1082762 ±162%-100.0% 0.00 ± -1%+189.3%3132030 ±110%
latency_stats.avg.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
102189 ± 2% -2.1% 100087 ± 5% -32.9% 68568 ± 2%
latency_stats.hits.pipe_wait.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
1082762 ±162%-100.0% 0.00 ± -1%+289.6%4217977 ±109%
latency_stats.max.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
1082762 ±162%-100.0% 0.00 ± -1%+478.5%6264061 ±110%
latency_stats.sum.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
5.10 ± 2% -8.0% 4.69 ± 1% +13.0% 5.76 ± 1%
perf-profile.cpu-cycles.__kernel_text_address.print_context_stack.dump_trace.save_stack_trace_tsk.__account_scheduler_latency
2.58 ± 8% +19.5% 3.09 ± 3% -1.8% 2.54 ± 11%
perf-profile.cpu-cycles._raw_spin_lock_irqsave.finish_wait.__wait_on_bit_lock.__lock_page.find_lock_entry
7.02 ± 3% +9.2% 7.67 ± 2% +7.1% 7.52 ± 3%
perf-profile.cpu-cycles._raw_spin_lock_irqsave.prepare_to_wait_exclusive.__wait_on_bit_lock.__lock_page.find_lock_entry
3.07 ± 2% +14.8% 3.53 ± 3% -1.4% 3.03 ± 5%
perf-profile.cpu-cycles.finish_wait.__wait_on_bit_lock.__lock_page.find_lock_entry.shmem_getpage_gfp
3.05 ± 5% -8.4% 2.79 ± 4% -5.2% 2.90 ± 5%
perf-profile.cpu-cycles.hrtimer_start_range_ns.tick_nohz_stop_sched_tick.__tick_nohz_idle_enter.tick_nohz_idle_enter.cpu_startup_entry
0.89 ± 5% -7.6% 0.82 ± 3% +16.3% 1.03 ± 5%
perf-profile.cpu-cycles.is_ftrace_trampoline.__kernel_text_address.print_context_stack.dump_trace.save_stack_trace_tsk
0.98 ± 3% -25.1% 0.74 ± 7% -16.8% 0.82 ± 2%
linux-next: manual merge of the device-mapper tree with the block tree
Hi all,
Today's linux-next merge of the device-mapper tree got a conflict in:
drivers/md/dm-cache-target.c
between commit:
4246a0b63bd8 ("block: add a bi_error field to struct bio")
from the block tree and commit:
cc7da0ba9c96 ("dm cache: fix use after freeing migrations")
from the device-mapper tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/md/dm-cache-target.c
index 7245071778db,f9d9cc6a094b..
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@@ -1358,9 -1352,10 +1352,10 @@@ static void issue_discard(struct dm_cac
b = to_dblock(from_dblock(b) + 1);
}
- bio_endio(bio, 0);
+ bio_endio(bio);
- cell_defer(mg->cache, mg->new_ocell, false);
+ cell_defer(cache, mg->new_ocell, false);
free_migration(mg);
+ wake_worker(cache);
}
static void issue_copy_or_discard(struct dm_cache_migration *mg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/4] of: overlay: add per overlay sysfs attributes
On Fri, Jun 12, 2015 at 2:38 PM, Pantelis Antoniou
wrote:
> The two default overlay attributes are:
>
> * A targets sysfs attribute listing the targets of the installed
> overlay. The targets list the path on the kernel's device tree
> where each overlay fragment is applied to
>
> * A per overlay can_remove sysfs attribute that reports whether
> the overlay can be removed or not due to another overlapping overlay.
What will a user do with this information? Can this just be debugfs?
Don't we already have the targets in the overlay itself? If we are
going to provide some overlay info, shouldn't we provide all of it
(i.e. the FDT). For example, what do we do on a kexec?
Rob
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/of/overlay.c | 53
>
> 1 file changed, 53 insertions(+)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 37ec858..747568f 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -373,8 +373,61 @@ static const struct attribute *overlay_global_attrs[] = {
> NULL
> };
>
> +static ssize_t can_remove_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct of_overlay *ov = kobj_to_overlay(kobj);
> +
> + return snprintf(buf, PAGE_SIZE, "%d\n", overlay_removal_is_ok(ov));
> +}
> +
> +static ssize_t targets_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct of_overlay *ov = kobj_to_overlay(kobj);
> + struct of_overlay_info *ovinfo;
> + char *s, *e;
> + ssize_t ret;
> + int i, len;
> +
> + s = buf;
> + e = buf + PAGE_SIZE;
> +
> + mutex_lock(_mutex);
> +
> + /* targets */
> + for (i = 0; i < ov->count; i++) {
> + ovinfo = >ovinfo_tab[i];
> +
> + len = snprintf(s, e - s, "%s\n",
> + of_node_full_name(ovinfo->target));
> + if (len == 0) {
> + ret = -ENOSPC;
> + goto err;
> + }
> + s += len;
> + }
> +
> + /* the buffer is zero terminated */
> + ret = s - buf;
> +err:
> + mutex_unlock(_mutex);
> + return ret;
> +}
> +
> +static struct kobj_attribute can_remove_attr = __ATTR_RO(can_remove);
> +static struct kobj_attribute targets_attr = __ATTR_RO(targets);
> +
> +static struct attribute *overlay_attrs[] = {
> + _remove_attr.attr,
> + _attr.attr,
> + NULL
> +};
> +
> static struct kobj_type of_overlay_ktype = {
> .release = of_overlay_release,
> + .sysfs_ops = _sysfs_ops, /* default kobj sysfs ops */
> + .default_attrs = overlay_attrs,
> };
>
> static struct kset *ov_kset;
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote: > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote: > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Wednesday, September 02, 2015 10:18 AM > > To: Zhao Qiang-B45475 > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li > > Yang-Leo-R58472; pau...@samba.org > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > bytes-alignment to genalloc > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote: > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote: > > > > -Original Message- > > > > From: Wood Scott-B07421 > > > > Sent: Wednesday, September 02, 2015 8:30 AM > > > > To: Zhao Qiang-B45475 > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; > > > > Li Yang-Leo-R58472; pau...@samba.org > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > > > bytes-alignment to genalloc > > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote: > > > > > Bytes alignment is required to manage some special RAM, so add > > > > > gen_pool_first_fit_align to genalloc, meanwhile add > > > > > gen_pool_alloc_data to pass data to > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper) > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > --- > > > > > Changes for v6: > > > > > - patches set v6 include a new patch because of using > > > > > - genalloc to manage QE MURAM, patch 0001 is the new > > > > > - patch, adding bytes alignment for allocation for use. > > > > > Changes for v7: > > > > > - cpm muram also need to use genalloc to manage, it has > > > > > a function to reserve a specific region of muram, > > > > > add offset to genpool_data for start addr to be allocated. > > > > > > > > This seems to be describing more than just the changes in this patch. > > > > What does also handling cpm have to do with this patch? Are you > > > > adding support for reserving a specific region in this patch? I > > > > don't see it, and in any case it should go in a different patch. > > > > > > Yes, I added. The code below can support the function. > > > offset_bit = (alignment->offset + (1UL << order) - 1) >> order; > > > return bitmap_find_next_zero_area(map, size, start + offset_bit, > > nr, > > > align_mask); > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate muram > > > from a Specific offset. So I add the code and add offset to struct data. > > > > I thought the offset was related to the previous discussion of checking > > for allocation failure. Are you using it to implement alloc_fixed()? If > > so, please don't. Besides the awkward implementation (what does it > > logically have to do with gen_pool_first_fit_align?), it does not appear > > to be correct - > > - what happens with multiple chunks? What happens if part of the region > > the caller is trying to reserve is already taken? Implement a proper > > function to reserve a fixed genalloc region. > > This offset is totally different with the workaround OFFSET! There's a reason why we write changelogs that describe what the patch is doing, and avoid combining logically distinct changes in the same patch. > This offset is the offset of the muram. The offset of the muram relative to what? Or do you mean the offset into muram? > CPM need to allocate block from a specific offset due to hardware > restriction. > So I must handle this offset in genalloc. Again, if you need to be able to mark a specific range reserved, add a function that does that properly. Don't try to hack it in the way you did. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/5] sched: add two functions for att(det)aching a task to(from) a cfs_rq
On Tue, Sep 01, 2015 at 05:03:43PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 01, 2015 at 09:28:49AM +0900, Byungchul Park wrote:
>
> > check the condition "!(flags & DEQUEUE_SLEEP)" for doing normalizing in
> > dequeue_entity(). i think you have to keep my original comment, or
> > modify your comment to something like below.
> >
> > before - If it's !queued, sleeping tasks have a normalized vruntime,
> > after - If it's !queued, sleeping tasks have a non-normalize vruntime,
> >
> > but.. i think it would be better that you keep my original comment..
>
> The comment we can talk about later, but I think the condition:
>
> > > - if (p->state == TASK_RUNNING)
> > > + if (!p->se.on_rq)
>
> is important now. Both are broken in different ways.
>
> p->state == TASK_RUNNING
>
> is broken in this scenario:
>
> CPU0CPU1
>
> set_current_state(TASK_UNINTERRUPTIBLE);
here, the target task has not been dequeued yet (the task will be
dequeued within schedule()). so, queued is true when sched_move_task()
is called. sched_move_task()->dequeue_task(flag=0) will normalize as
we expect. that is anyway no problem. however, i also think the
condition here can make us confused, too.
i think "p->state == TASK_RUNNING" condition can work anyway, which
already exists in original code. the condition is only for checking
if the task is being migrated or in sleep. how about this appoach
below to make code more readable?
>
> sched_move_task()
> task_move_group_fair()
> vruntime_normalized() ==
> true
> if (!cond)
> schedule();
> __set_current_state(TASK_RUNNING);
>
>
> Now the proposed replacement:
>
> !p->se.on_rq
>
> is equally broken, because (as you point out) clearing it isn't
> conditional on DEQUEUE_SLEEP.
>
i think we must take a task's on_rq into account instead of se's on_rq,
because current code set se's on_rq to 0 even when migrating a task. but
task's on_rq would be set to TASK_ON_RQ_MIGRATING when migrating the
task. there it would be ok if we use task's on_rq to check if it has
a normailzed vruntime or not like below.
---
>From 9545e34c2f6fd195f18d3111b5c1d1b03600cdcd Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Wed, 2 Sep 2015 10:59:58 +0900
Subject: [PATCH] sched: make vruntime_normalized() cleaner
in both TASK_ON_RQ_QUEUED case and TASK_ON_RQ_MIGRATING case, the
target task have a normalized vruntime by dequeue_entity(.flags=0).
so we don't need to check this separately with a different condition
statement.
Signed-off-by: Byungchul Park
---
kernel/sched/fair.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 53d0e30..dfe8754 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7920,14 +7920,14 @@ prio_changed_fair(struct rq *rq, struct task_struct *p,
int oldprio)
static inline bool vruntime_normalized(struct task_struct *p)
{
- int queued = task_on_rq_queued(p);
struct sched_entity *se = >se;
/*
-* If it's queued, then the dequeue_entity(.flags=0) will already
-* have normalized the vruntime.
+* In both TASK_ON_RQ_QUEUED case and TASK_ON_RQ_MIGRATING case,
+* the dequeue_entity(.flags=0) will already have normalized the
+* vruntime.
*/
- if (queued)
+ if (p->on_rq)
return true;
/*
@@ -7942,14 +7942,6 @@ static inline bool vruntime_normalized(struct
task_struct *p)
if (!se->sum_exec_runtime || p->state == TASK_WAKING)
return true;
- /*
-* If it's !queued, then only when the task is sleeping it has a
-* non-normalized vruntime, that is, when the task is being migrated
-* it has a normailized vruntime.
-*/
- if (p->state == TASK_RUNNING)
- return true;
-
return false;
}
--
1.7.9.5
>
> And the problem with tracking the vruntime state is that while it helps
> detach_task_cfs_rq(), attach_task_cfs_rq() is still left wondering what
> it should return to.
>
> So we do indeed need something to determine, based on the current state,
> if vruntime should be normalized.
>
> /me ponders moar
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
On Wed, 2015-09-02 at 10:31AM, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 10:31 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> muram
>
> On Tue, 2015-09-01 at 21:22 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 8:34AM +0800, Wood Scott-B07421 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 8:34 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to
> > > manage muram
> > >
> > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > >
> > > > -int cpm_muram_init(void)
> > > > -{
> > > > - struct device_node *np;
> > > > - struct resource r;
> > > > - u32 zero[OF_MAX_ADDR_CELLS] = {};
> > > > - resource_size_t max = 0;
> > > > - int i = 0;
> > > > - int ret = 0;
> > > > -
> > > > - if (muram_pbase)
> > > > - return 0;
> > > > -
> > > > - spin_lock_init(_muram_lock);
> > > > - /* initialize the info header */
> > > > - rh_init(_muram_info, 1,
> > > > - sizeof(cpm_boot_muram_rh_block) /
> > > > - sizeof(cpm_boot_muram_rh_block[0]),
> > > > - cpm_boot_muram_rh_block);
> > > > -
> > > > - np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-
> data");
> > > > - if (!np) {
> > > > - /* try legacy bindings */
> > > > - np = of_find_node_by_name(NULL, "data-only");
> > > > - if (!np) {
> > > > - printk(KERN_ERR "Cannot find CPM muram data
> > > node");
> > > > - ret = -ENODEV;
> > > > - goto out;
> > > > - }
> > > > - }
> > > > -
> > > > - muram_pbase = of_translate_address(np, zero);
> > > > - if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
> > > > - printk(KERN_ERR "Cannot translate zero through CPM
> muram
> > > node");
> > > > - ret = -ENODEV;
> > > > - goto out;
> > > > - }
> > >
> > > Did you pass -M -C to git format-patch?
> >
> >
> > Yes!
>
> Then maybe it's the qe/cpm rename churn, or similar, that prevented it
> from being identified as a move?
Maybe
>
> -Scott
-Zhao
[PATCH] ahci: added a new driver for supporting Freescale AHCI sata
From: Tang Yuantian
Currently Freescale QorIQ series SATA is supported by ahci_platform
driver. Some SoC specific settings have been put in uboot. So whether
SATA works or not heavily depends on uboot.
This patch will add a new driver to support QorIQ sata which removes
the dependency on any other boot loader.
Freescale QorIQ series sata, like ls1021a ls2085a ls1043a, is
compatible with serial ATA 3.0 and AHCI 1.3 specification.
Signed-off-by: Yuantian Tang
---
drivers/ata/Kconfig | 9 ++
drivers/ata/Makefile| 1 +
drivers/ata/ahci_platform.c | 1 -
drivers/ata/ahci_qoriq.c| 308
4 files changed, 318 insertions(+), 1 deletion(-)
create mode 100644 drivers/ata/ahci_qoriq.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 15e40ee..6aaa3f8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -175,6 +175,15 @@ config AHCI_XGENE
help
This option enables support for APM X-Gene SoC SATA host controller.
+config AHCI_QORIQ
+ tristate "Freescale QorIQ AHCI SATA support"
+ depends on OF
+ help
+ This option enables support for the Freescale QorIQ AHCI SoC's
+ onboard AHCI SATA.
+
+ If unsure, say N.
+
config SATA_FSL
tristate "Freescale 3.0Gbps SATA support"
depends on FSL_SOC
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index af70919..af45eff 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o libahci.o
libahci_platform.o
obj-$(CONFIG_AHCI_ST) += ahci_st.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_TEGRA) += ahci_tegra.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_XGENE) += ahci_xgene.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_QORIQ) += ahci_qoriq.o libahci.o libahci_platform.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 1befb11..04975b8 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -76,7 +76,6 @@ static const struct of_device_id ahci_of_match[] = {
{ .compatible = "ibm,476gtr-ahci", },
{ .compatible = "snps,dwc-ahci", },
{ .compatible = "hisilicon,hisi-ahci", },
- { .compatible = "fsl,qoriq-ahci", },
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
new file mode 100644
index 000..943b783
--- /dev/null
+++ b/drivers/ata/ahci_qoriq.c
@@ -0,0 +1,308 @@
+/*
+ * Freescale QorIQ AHCI SATA platform driver
+ *
+ * Copyright 2015 Freescale, Inc.
+ * Tang Yuantian
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ahci.h"
+
+#define DRV_NAME "ahci-qoriq"
+
+#define AHCI_PORT_PHY_1_CFG0xa003fffe
+#define AHCI_PORT_PHY_2_CFG0x28183411
+#define AHCI_PORT_PHY_3_CFG0x0e081004
+#define AHCI_PORT_PHY_4_CFG0x00480811
+#define AHCI_PORT_PHY_5_CFG0x192c96a4
+#define AHCI_PORT_TRANS_CFG0x0825
+
+#define SATA_ECC_REG_ADDR 0x20220520
+#define SATA_ECC_DISABLE 0x0002
+
+enum ahci_qoriq_type {
+ AHCI_LS1021A,
+ AHCI_LS1043A,
+ AHCI_LS2085A,
+};
+
+struct ahci_qoriq_priv {
+ struct ccsr_ahci *reg_base;
+ enum ahci_qoriq_type type;
+ void __iomem *ecc_addr;
+};
+
+/* AHCI (sata) register map */
+struct ccsr_ahci {
+ u32 res1[0xa4/4]; /* 0x0 - 0xa4 */
+ u32 pcfg; /* port config */
+ u32 ppcfg; /* port phy1 config */
+ u32 pp2c; /* port phy2 config */
+ u32 pp3c; /* port phy3 config */
+ u32 pp4c; /* port phy4 config */
+ u32 pp5c; /* port phy5 config */
+ u32 paxic; /* port AXI config */
+ u32 axicc; /* AXI cache control */
+ u32 axipc; /* AXI PROT control */
+ u32 ptc;/* port Trans Config */
+ u32 pts;/* port Trans Status */
+ u32 plc;/* port link config */
+ u32 plc1; /* port link config1 */
+ u32 plc2; /* port link config2 */
+ u32 pls;/* port link status */
+ u32 pls1; /* port link status1 */
+ u32 pcmdc; /* port CMD config */
+ u32 ppcs; /* port phy control status */
+ u32 pberr; /* port 0/1 BIST error */
+ u32 cmds; /* port 0/1 CMD status error */
+};
+
+static const struct of_device_id ahci_qoriq_of_match[] = {
+ { .compatible = "fsl,ls1021a-ahci", .data = (void *)AHCI_LS1021A},
+ { .compatible = "fsl,ls1043a-ahci", .data = (void
Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
On Tue, 2015-09-01 at 21:22 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-02 at 8:34AM +0800, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 8:34 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> > Yang-Leo-R58472; pau...@samba.org
> > Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> > muram
> >
> > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> >
> > > -int cpm_muram_init(void)
> > > -{
> > > - struct device_node *np;
> > > - struct resource r;
> > > - u32 zero[OF_MAX_ADDR_CELLS] = {};
> > > - resource_size_t max = 0;
> > > - int i = 0;
> > > - int ret = 0;
> > > -
> > > - if (muram_pbase)
> > > - return 0;
> > > -
> > > - spin_lock_init(_muram_lock);
> > > - /* initialize the info header */
> > > - rh_init(_muram_info, 1,
> > > - sizeof(cpm_boot_muram_rh_block) /
> > > - sizeof(cpm_boot_muram_rh_block[0]),
> > > - cpm_boot_muram_rh_block);
> > > -
> > > - np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
> > > - if (!np) {
> > > - /* try legacy bindings */
> > > - np = of_find_node_by_name(NULL, "data-only");
> > > - if (!np) {
> > > - printk(KERN_ERR "Cannot find CPM muram data
> > node");
> > > - ret = -ENODEV;
> > > - goto out;
> > > - }
> > > - }
> > > -
> > > - muram_pbase = of_translate_address(np, zero);
> > > - if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
> > > - printk(KERN_ERR "Cannot translate zero through CPM muram
> > node");
> > > - ret = -ENODEV;
> > > - goto out;
> > > - }
> >
> > Did you pass -M -C to git format-patch?
>
>
> Yes!
Then maybe it's the qe/cpm rename churn, or similar, that prevented it from
being identified as a move?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 10:18 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
>
> On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > Bytes alignment is required to manage some special RAM, so add
> > > > gen_pool_first_fit_align to genalloc, meanwhile add
> > > > gen_pool_alloc_data to pass data to
> > > > gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)
> > > >
> > > > Signed-off-by: Zhao Qiang
> > > > ---
> > > > Changes for v6:
> > > > - patches set v6 include a new patch because of using
> > > > - genalloc to manage QE MURAM, patch 0001 is the new
> > > > - patch, adding bytes alignment for allocation for use.
> > > > Changes for v7:
> > > > - cpm muram also need to use genalloc to manage, it has
> > > > a function to reserve a specific region of muram,
> > > > add offset to genpool_data for start addr to be allocated.
> > >
> > > This seems to be describing more than just the changes in this patch.
> > > What does also handling cpm have to do with this patch? Are you
> > > adding support for reserving a specific region in this patch? I
> > > don't see it, and in any case it should go in a different patch.
> >
> > Yes, I added. The code below can support the function.
> > offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
> > return bitmap_find_next_zero_area(map, size, start + offset_bit,
> nr,
> > align_mask);
> >
> > CPM has an function cpm_muram_alloc_fixed, needing to allocate muram
> > from a Specific offset. So I add the code and add offset to struct data.
>
> I thought the offset was related to the previous discussion of checking
> for allocation failure. Are you using it to implement alloc_fixed()? If
> so, please don't. Besides the awkward implementation (what does it
> logically have to do with gen_pool_first_fit_align?), it does not appear
> to be correct -
> - what happens with multiple chunks? What happens if part of the region
> the caller is trying to reserve is already taken? Implement a proper
> function to reserve a fixed genalloc region.
This offset is totally different with the workaround OFFSET!
This offset is the offset of the muram.
CPM need to allocate block from a specific offset due to hardware restriction.
So I must handle this offset in genalloc.
>
> > This patch is the first patch of this patch set, so I explain what
> > changes about Set v7 and why I add support for reserving a specific
> > region in this patch.
>
> If you want to provide commentary that covers the entire patchset, use a
> cover letter.
>
> > > > +/*
> > > > + * gen_pool data descriptor for gen_pool_first_fit_align.
> > > > + */
> > > > +struct genpool_data_align {
> > > > + int align; /* alignment by bytes for starting
> > > address */
> > > > + unsigned long offset; /* the offset of allocation start
> addr*/
> > > > +};
> > >
> > > The offset belongs on the caller side, not here.
> >
> > So, how do I pass offset to gen_pool_alloc_data or pool->algo?
>
> You don't.
>
> -Scott
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] genirq: Remove the second parameter from handle_irq_event_percpu
On 2015/9/2 10:24, Huang Shijie wrote:
> Actually, we always use the first irq action of the @desc->action chain,
> this patch remove the second parameter from handle_irq_event_percpu() which
> makes the code more tidy.
>
> Signed-off-by: Huang Shijie
Reviewed-by: Jiang Liu
> ---
> kernel/irq/chip.c | 2 +-
> kernel/irq/handle.c| 7 +++
> kernel/irq/internals.h | 2 +-
> 3 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 6e40a95..27e4833 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -680,7 +680,7 @@ handle_percpu_irq(unsigned int irq, struct irq_desc *desc)
> if (chip->irq_ack)
> chip->irq_ack(>irq_data);
>
> - handle_irq_event_percpu(desc, desc->action);
> + handle_irq_event_percpu(desc);
>
> if (chip->irq_eoi)
> chip->irq_eoi(>irq_data);
> diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
> index b6eeea8..bc2f892 100644
> --- a/kernel/irq/handle.c
> +++ b/kernel/irq/handle.c
> @@ -130,11 +130,11 @@ void __irq_wake_thread(struct irq_desc *desc, struct
> irqaction *action)
> wake_up_process(action->thread);
> }
>
> -irqreturn_t
> -handle_irq_event_percpu(struct irq_desc *desc, struct irqaction *action)
> +irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
> {
> irqreturn_t retval = IRQ_NONE;
> unsigned int flags = 0, irq = desc->irq_data.irq;
> + struct irqaction *action = desc->action;
>
> do {
> irqreturn_t res;
> @@ -182,14 +182,13 @@ handle_irq_event_percpu(struct irq_desc *desc, struct
> irqaction *action)
>
> irqreturn_t handle_irq_event(struct irq_desc *desc)
> {
> - struct irqaction *action = desc->action;
> irqreturn_t ret;
>
> desc->istate &= ~IRQS_PENDING;
> irqd_set(>irq_data, IRQD_IRQ_INPROGRESS);
> raw_spin_unlock(>lock);
>
> - ret = handle_irq_event_percpu(desc, action);
> + ret = handle_irq_event_percpu(desc);
>
> raw_spin_lock(>lock);
> irqd_clear(>irq_data, IRQD_IRQ_INPROGRESS);
> diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
> index eee4b38..1be888c 100644
> --- a/kernel/irq/internals.h
> +++ b/kernel/irq/internals.h
> @@ -81,7 +81,7 @@ extern void irq_mark_irq(unsigned int irq);
>
> extern void init_kstat_irqs(struct irq_desc *desc, int node, int nr);
>
> -irqreturn_t handle_irq_event_percpu(struct irq_desc *desc, struct irqaction
> *action);
> +irqreturn_t handle_irq_event_percpu(struct irq_desc *desc);
> irqreturn_t handle_irq_event(struct irq_desc *desc);
>
> /* Resending of interrupts :*/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] genirq: Remove the second parameter from handle_irq_event_percpu
Actually, we always use the first irq action of the @desc->action chain,
this patch remove the second parameter from handle_irq_event_percpu() which
makes the code more tidy.
Signed-off-by: Huang Shijie
---
kernel/irq/chip.c | 2 +-
kernel/irq/handle.c| 7 +++
kernel/irq/internals.h | 2 +-
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6e40a95..27e4833 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -680,7 +680,7 @@ handle_percpu_irq(unsigned int irq, struct irq_desc *desc)
if (chip->irq_ack)
chip->irq_ack(>irq_data);
- handle_irq_event_percpu(desc, desc->action);
+ handle_irq_event_percpu(desc);
if (chip->irq_eoi)
chip->irq_eoi(>irq_data);
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index b6eeea8..bc2f892 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -130,11 +130,11 @@ void __irq_wake_thread(struct irq_desc *desc, struct
irqaction *action)
wake_up_process(action->thread);
}
-irqreturn_t
-handle_irq_event_percpu(struct irq_desc *desc, struct irqaction *action)
+irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
{
irqreturn_t retval = IRQ_NONE;
unsigned int flags = 0, irq = desc->irq_data.irq;
+ struct irqaction *action = desc->action;
do {
irqreturn_t res;
@@ -182,14 +182,13 @@ handle_irq_event_percpu(struct irq_desc *desc, struct
irqaction *action)
irqreturn_t handle_irq_event(struct irq_desc *desc)
{
- struct irqaction *action = desc->action;
irqreturn_t ret;
desc->istate &= ~IRQS_PENDING;
irqd_set(>irq_data, IRQD_IRQ_INPROGRESS);
raw_spin_unlock(>lock);
- ret = handle_irq_event_percpu(desc, action);
+ ret = handle_irq_event_percpu(desc);
raw_spin_lock(>lock);
irqd_clear(>irq_data, IRQD_IRQ_INPROGRESS);
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index eee4b38..1be888c 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -81,7 +81,7 @@ extern void irq_mark_irq(unsigned int irq);
extern void init_kstat_irqs(struct irq_desc *desc, int node, int nr);
-irqreturn_t handle_irq_event_percpu(struct irq_desc *desc, struct irqaction
*action);
+irqreturn_t handle_irq_event_percpu(struct irq_desc *desc);
irqreturn_t handle_irq_event(struct irq_desc *desc);
/* Resending of interrupts :*/
--
2.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: [Intel-wired-lan] [PATCH 1/1] ixgbe: use kzalloc for allocating one thing
-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Maninder Singh Sent: Thursday, June 18, 2015 9:08 PM To: Kirsher, Jeffrey T ; Brandeburg, Jesse ; Nelson, Shannon ; Wyborny, Carolyn ; Skidmore, Donald C ; Vick, Matthew ; Ronciak, John ; Williams, Mitch A ; intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org Cc: Maninder Singh ; panka...@samsung.com Subject: [Intel-wired-lan] [PATCH 1/1] ixgbe: use kzalloc for allocating one thing Use kzalloc rather than kcalloc(1.. The semantic patch that makes this change is as follows: // @@ @@ - kcalloc(1, + kzalloc( ...) // and removing checkpatch below CHECK: CHECK: Prefer kzalloc(sizeof(*fwd_adapter)...) over kzalloc(sizeof(struct ixgbe_fwd_adapter)...) Signed-off-by: Maninder Singh Reviewed-by: Vaneet Narang --- Tested-By: Krishneil Singh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Sep 1, 2015 6:12 PM, "Ian Lance Taylor" wrote: > > On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote: > > > > Linux has a handful of weird features that are only supported for > > backwards compatibility. The big one is the x86_64 vsyscall page, but > > uselib probably belongs on the list, too, and we might end up with > > more at some point. > > > > I'd like to add a way that new programs can turn these features off. > > In particular, I want the vsyscall page to be completely gone from the > > perspective of any new enough program. This is straightforward if we > > add a system call to ask for the vsyscall page to be disabled, but I'm > > wondering if we can come up with a non-syscall way to do it. > > > > I think that the ideal behavior would be that anything linked against > > a sufficiently new libc would be detected, but I don't see a good way > > to do that using existing toolchain features. > > > > Ideas? We could add a new phdr for this, but then we'd need to play > > linker script games, and I'm not sure that could be done in a clean, > > extensible way. > > What sets up the vsyscall page, and what information does it have > before doing so? > > I'm guessing it's the kernel that sets it up, and that all it can see > at that point is the program headers. Currently it's global and nothing thinks about it per-process at all. The kernel can do whatever it likes going forward, subject to backwards compatibility. Doing something at ELF load time is probably the right approach. > > We could pass information using an appropriate note section. My > recollection is that the linkers will turn an SHF_ALLOC note section > into a PT_NOTE program header. Oh, interesting. I'll check that. Glibc and competitors could add notes to their statically-linked bits. The unpleasant case is a new dynamic binary linked against an old libc, but that might be irrelevant in practice. After all, I think that a lot of libc competitors never supported the vsyscall page at all, and even glibc isn't really backwards compatible that way. We could also require that both the binary and interpreter have the note, which would more or less solve the backwards compatibility issue. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage muram
On Wed, 2015-09-02 at 8:34AM +0800, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 8:34 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH V7 2/3] qe_common: add qe_muram_ functions to manage
> muram
>
> On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
>
> > -int cpm_muram_init(void)
> > -{
> > - struct device_node *np;
> > - struct resource r;
> > - u32 zero[OF_MAX_ADDR_CELLS] = {};
> > - resource_size_t max = 0;
> > - int i = 0;
> > - int ret = 0;
> > -
> > - if (muram_pbase)
> > - return 0;
> > -
> > - spin_lock_init(_muram_lock);
> > - /* initialize the info header */
> > - rh_init(_muram_info, 1,
> > - sizeof(cpm_boot_muram_rh_block) /
> > - sizeof(cpm_boot_muram_rh_block[0]),
> > - cpm_boot_muram_rh_block);
> > -
> > - np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
> > - if (!np) {
> > - /* try legacy bindings */
> > - np = of_find_node_by_name(NULL, "data-only");
> > - if (!np) {
> > - printk(KERN_ERR "Cannot find CPM muram data
> node");
> > - ret = -ENODEV;
> > - goto out;
> > - }
> > - }
> > -
> > - muram_pbase = of_translate_address(np, zero);
> > - if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
> > - printk(KERN_ERR "Cannot translate zero through CPM muram
> node");
> > - ret = -ENODEV;
> > - goto out;
> > - }
>
> Did you pass -M -C to git format-patch?
Yes!
>
> -Scott
-Zhao
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote: > > On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski wrote: > > Hi all- > > > > Linux has a handful of weird features that are only supported for > > backwards compatibility. The big one is the x86_64 vsyscall page, but > > uselib probably belongs on the list, too, and we might end up with > > more at some point. > > > > I'd like to add a way that new programs can turn these features off. > > In particular, I want the vsyscall page to be completely gone from the > > perspective of any new enough program. This is straightforward if we > > add a system call to ask for the vsyscall page to be disabled, but I'm > > wondering if we can come up with a non-syscall way to do it. > > > > I think that the ideal behavior would be that anything linked against > > a sufficiently new libc would be detected, but I don't see a good way > > to do that using existing toolchain features. > > > > Ideas? We could add a new phdr for this, but then we'd need to play > > linker script games, and I'm not sure that could be done in a clean, > > extensible way. > > > The vsyscall page is mapped in the fixmap region, which is shared > between all processes. You can't turn it off for an individual > process. Why not? We already emulate all attempts to execute it, and that's trivial to turn of per process. Project Zero pointed out that read access is a problem, too, but we can flip the U/S bit in the pgd once we evict pvclock from the fixmap. And we definitely need to evict pvclock from the fixmap regardless. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 8:30 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> > Yang-Leo-R58472; pau...@samba.org
> > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > bytes-alignment to genalloc
> >
> > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > Bytes alignment is required to manage some special RAM, so add
> > > gen_pool_first_fit_align to genalloc, meanwhile add
> > > gen_pool_alloc_data to pass data to gen_pool_first_fit_align(modify
> > > gen_pool_alloc as a wrapper)
> > >
> > > Signed-off-by: Zhao Qiang
> > > ---
> > > Changes for v6:
> > > - patches set v6 include a new patch because of using
> > > - genalloc to manage QE MURAM, patch 0001 is the new
> > > - patch, adding bytes alignment for allocation for use.
> > > Changes for v7:
> > > - cpm muram also need to use genalloc to manage, it has
> > > a function to reserve a specific region of muram,
> > > add offset to genpool_data for start addr to be allocated.
> >
> > This seems to be describing more than just the changes in this patch.
> > What does also handling cpm have to do with this patch? Are you adding
> > support for reserving a specific region in this patch? I don't see it,
> > and in any case it should go in a different patch.
>
> Yes, I added. The code below can support the function.
> offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
> return bitmap_find_next_zero_area(map, size, start + offset_bit, nr,
> align_mask);
>
> CPM has an function cpm_muram_alloc_fixed, needing to allocate muram from a
> Specific offset. So I add the code and add offset to struct data.
I thought the offset was related to the previous discussion of checking for
allocation failure. Are you using it to implement alloc_fixed()? If so,
please don't. Besides the awkward implementation (what does it logically
have to do with gen_pool_first_fit_align?), it does not appear to be correct -
- what happens with multiple chunks? What happens if part of the region the
caller is trying to reserve is already taken? Implement a proper function to
reserve a fixed genalloc region.
> This patch is the first patch of this patch set, so I explain what changes
> about
> Set v7 and why I add support for reserving a specific region in this patch.
If you want to provide commentary that covers the entire patchset, use a
cover letter.
> > > +/*
> > > + * gen_pool data descriptor for gen_pool_first_fit_align.
> > > + */
> > > +struct genpool_data_align {
> > > + int align; /* alignment by bytes for starting
> > address */
> > > + unsigned long offset; /* the offset of allocation start addr*/
> > > +};
> >
> > The offset belongs on the caller side, not here.
>
> So, how do I pass offset to gen_pool_alloc_data or pool->algo?
You don't.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with the xfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/xfs/xfs_aops.c
between commit:
c9eb256eda44 ("xfs: return errors from partial I/O failures to files")
from the xfs tree and commit:
4246a0b63bd8 ("block: add a bi_error field to struct bio")
from the block tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/xfs/xfs_aops.c
index c8637073ef25,c77499bcbd7a..
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@@ -354,8 -355,7 +353,8 @@@ xfs_end_bio
{
xfs_ioend_t *ioend = bio->bi_private;
- if (!ioend->io_error && !test_bit(BIO_UPTODATE, >bi_flags))
- ioend->io_error = error;
- ioend->io_error = bio->bi_error;
++ if (!ioend->io_error)
++ ioend->io_error = bio->bi_error;
/* Toss bio and pass work off to an xfsdatad thread */
bio->bi_private = NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/16] Add Analogix Core Display Port Driver
Hi Heiko, 在 09/02/2015 05:47 AM, Heiko Stuebner 写道: Hi Yakir, Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang: The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with "analogix" which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", both of them works rightlly. it looks like during the rebase something did go wrong and I found some issues I mentioned in the replies to individual patches. I did prepare a branch based on mainline [0] with both the old and the new edp driver - rk3288_veyron_defconfig build both drivers into the image. While the old driver still works, I wasn't able to make the new one work yet ... the drm core does find the connector, but not that anything is connected to it. I'll try to dig deeper tomorrow, but maybe you'll see anything interesting before then. Many thanks for your comment and debug, I would rebase on your "edp-with-veyron" branch and fix the broken, make sure v6 would work rightly at least in your side and my side. - Yakir Heiko [0] https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] alpha: Define ioremap_uc and ioremap_wc
On Fri, Jul 31, 2015 at 07:32:39PM -0700, Guenter Roeck wrote:
> Commit 3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole
> with strong UC") introduces calls to ioremap_wc and ioremap_uc. This
> causes build failures with alpha:allmodconfig. Map the missing functions
> to ioremap_nocache.
>
> Fixes: 3cc2dac5be3f ("drivers/video/fbdev/atyfb:
> Replace MTRR UC hole with strong UC")
> Cc: Paul Gortmaker
> Cc: Luis R. Rodriguez
> Signed-off-by: Guenter Roeck
ping ... alpha:allmodconfig now fails to build in mainline due to this
problem.
Guenter
> ---
> arch/alpha/include/asm/io.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
> index f05bdb4b1cb9..7edfe6bf0ee6 100644
> --- a/arch/alpha/include/asm/io.h
> +++ b/arch/alpha/include/asm/io.h
> @@ -299,6 +299,9 @@ static inline void __iomem * ioremap_nocache(unsigned
> long offset,
> return ioremap(offset, size);
> }
>
> +#define ioremap_wc ioremap_nocache
> +#define ioremap_uc ioremap_nocache
> +
> static inline void iounmap(volatile void __iomem *addr)
> {
> IO_CONCAT(__IO_PREFIX,iounmap)(addr);
> --
> 2.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/
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 8:30 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
>
> On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > Bytes alignment is required to manage some special RAM, so add
> > gen_pool_first_fit_align to genalloc, meanwhile add
> > gen_pool_alloc_data to pass data to gen_pool_first_fit_align(modify
> > gen_pool_alloc as a wrapper)
> >
> > Signed-off-by: Zhao Qiang
> > ---
> > Changes for v6:
> > - patches set v6 include a new patch because of using
> > - genalloc to manage QE MURAM, patch 0001 is the new
> > - patch, adding bytes alignment for allocation for use.
> > Changes for v7:
> > - cpm muram also need to use genalloc to manage, it has
> > a function to reserve a specific region of muram,
> > add offset to genpool_data for start addr to be allocated.
>
> This seems to be describing more than just the changes in this patch.
> What does also handling cpm have to do with this patch? Are you adding
> support for reserving a specific region in this patch? I don't see it,
> and in any case it should go in a different patch.
Yes, I added. The code below can support the function.
offset_bit = (alignment->offset + (1UL << order) - 1) >> order;
return bitmap_find_next_zero_area(map, size, start + offset_bit, nr,
align_mask);
CPM has an function cpm_muram_alloc_fixed, needing to allocate muram from a
Specific offset. So I add the code and add offset to struct data.
This patch is the first patch of this patch set, so I explain what changes about
Set v7 and why I add support for reserving a specific region in this patch.
If you really think a different patch needed, I can add a new patch to handle
it.
>
> > +/*
> > + * gen_pool data descriptor for gen_pool_first_fit_align.
> > + */
> > +struct genpool_data_align {
> > + int align; /* alignment by bytes for starting
> address */
> > + unsigned long offset; /* the offset of allocation start addr*/
> > +};
>
> The offset belongs on the caller side, not here.
So, how do I pass offset to gen_pool_alloc_data or pool->algo?
>
> -Scott
Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting
Hi Heiko,
在 09/02/2015 05:00 AM, Heiko Stuebner 写道:
Hi Yakir,
Am Dienstag, 1. September 2015, 14:01:48 schrieb Yakir Yang:
From: Mark Yao
Add bpc and color mode setting in rockchip_drm_vop driver, so
connector could try to use the edid drm_display_info to config
vop output mode.
Signed-off-by: Mark Yao
Signed-off-by: Yakir Yang
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 46
+++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |
2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 --
4 files changed, 68 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c index cebff9e..efea045
100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -11,11 +11,6 @@
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
-#include
-#include
-#include
-#include
-#include
#include
#include
@@ -27,6 +22,13 @@
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+
#include
#include "rockchip_drm_drv.h"
@@ -125,20 +127,44 @@ static void rockchip_dp_drm_encoder_mode_set(struct
drm_encoder *encoder, /* do nothing */
}
+static drm_connector *rockchip_dp_get_connector(struct rockchip_dp_device
missing a "struct" -> static struct drm_connector
What the hell mistake I make in v5 :-(
Thanks a lot, I would fix this as soon as possible
*dp) +{
+ struct drm_connector *connector;
+ struct drm_device *drm_dev = dp->drm_dev;
+
+ drm_for_each_connector(connector, drm_dev) {
+ if (connector->encoder != >encoder)
+ return connector;
+ }
+
+ return NULL;
+}
+
static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
{
struct rockchip_dp_device *dp = encoder_to_dp(encoder);
+ struct drm_connector *connector;
+ int ret = 0;
u32 val;
- int ret;
- ret = rockchip_drm_crtc_mode_config(encoder->crtc,
- DRM_MODE_CONNECTOR_eDP,
- ROCKCHIP_OUT_MODE_);
- if (ret < 0) {
+ connector = rockchip_dp_get_connector(dp);
+ if (!connector) {
+ DRM_ERROR("Failed to get connector by encoder[%p]\n", encoder);
+ return;
+ }
+
+ if (connector->display_info.color_formats | DRM_COLOR_FORMAT_RGB444)
+ ret = rockchip_drm_crtc_mode_config(
+ encoder->crtc, DRM_MODE_CONNECTOR_eDP,
+ connector->display_info.bpc, DRM_COLOR_FORMAT_RGB444);
+ if (!ret) {
dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
return;
}
+ connector->display_info.bpc = ret;
+ connector->display_info.color_formats = DRM_COLOR_FORMAT_RGB444;
+
ret = rockchip_drm_encoder_get_mux_id(dp->dev->of_node, encoder);
if (ret < 0)
return;
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c index 80d6fc8..428a3c1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct
drm_encoder *encoder) static void dw_hdmi_rockchip_encoder_prepare(struct
drm_encoder *encoder) {
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
+ 10, DRM_COLOR_FORMAT_RGB444);
}
static struct drm_encoder_helper_funcs
dw_hdmi_rockchip_encoder_helper_funcs = { diff --git
a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h index dc4e5f0..ef1d7fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device
*dev, int pipe); int rockchip_drm_encoder_get_mux_id(struct device_node
*node,
struct drm_encoder *encoder);
int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int
connector_type, - int out_mode);
+ int bpc, int color);
int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct device *dev);
void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 34b78e7..5d7f9b6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++
Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads
On Tue, Sep 01, 2015 at 04:51:24PM +0200, Thomas Graf wrote: > > 1. The current in-kernel self-test > 2. bind_netlink.c: https://github.com/tgraf/rhashtable Thanks, I will try to reproduce this. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5] clk: Hi6220: add stub clock driver
Hi Kevin, On Tue, Sep 01, 2015 at 05:28:03PM -0700, Kevin Hilman wrote: > On Sun, Aug 2, 2015 at 6:13 PM, Leo Yan wrote: > > On Hi6220, there have some clocks which can use mailbox channel to send > > messages to power controller to change frequency; this includes CPU, GPU > > and DDR clocks. > > > > For dynamic frequency scaling, firstly need write the frequency value to > > SRAM region, and then send message to mailbox to trigger power controller > > to handle this requirement. This driver will use syscon APIs to pass SRAM > > memory region and use common mailbox APIs for channels accessing. > > > > This init driver will support cpu frequency change firstly. > > > > Signed-off-by: Leo Yan > > The kernelci.org build/boot bot detected boot failures in > linux-next[1], and the failure was bisected down to this patch (landed > in linux-next as commit c1628a2c416da947f5afac615d53189250fa49cb. > > I verifed that reverting this commit on top of next-20150901 gets the > hikey booting again. Thanks for reporting. This issue has been confirmed at my side, it's caused by the patch have added dependency with MAILBOX, will fix this issue and send patch. Thanks, Leo Yan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski wrote: > Hi all- > > Linux has a handful of weird features that are only supported for > backwards compatibility. The big one is the x86_64 vsyscall page, but > uselib probably belongs on the list, too, and we might end up with > more at some point. > > I'd like to add a way that new programs can turn these features off. > In particular, I want the vsyscall page to be completely gone from the > perspective of any new enough program. This is straightforward if we > add a system call to ask for the vsyscall page to be disabled, but I'm > wondering if we can come up with a non-syscall way to do it. > > I think that the ideal behavior would be that anything linked against > a sufficiently new libc would be detected, but I don't see a good way > to do that using existing toolchain features. > > Ideas? We could add a new phdr for this, but then we'd need to play > linker script games, and I'm not sure that could be done in a clean, > extensible way. The vsyscall page is mapped in the fixmap region, which is shared between all processes. You can't turn it off for an individual process. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 08/16] drm: rockchip/dp: add rockchip platform dp driver
Hi Heiko,
在 09/02/2015 05:00 AM, Heiko Stuebner 写道:
Hi Yakir,
Am Dienstag, 1. September 2015, 14:01:28 schrieb Yakir Yang:
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
---
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.
Changes in v3:
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
core driver which name to "dp", and leave "pclk_edp" to rockchip dp
platform driver which name to "pclk".
- Take Heiko suggest, add devicetree binding document.
- Take Heiko suggest, remove "rockchip,panel" DT property, take use of
remote point to get panel node.
- Add the new function point analogix_dp_platdata.get_modes init.
Changes in v2:
- Take Heiko suggest, get panel node with remote-endpoint method,
and create devicetree binding for driver.
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
leave those clock to rockchip dp phy driver.
.../bindings/video/analogix_dp-rockchip.txt| 74
drivers/gpu/drm/rockchip/Kconfig | 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 389
+ 4 files changed, 473 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt create
mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
diff --git
a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt new file
mode 100644
index 000..502483e
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
@@ -0,0 +1,74 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+ Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+ dp-controller: dp@ff97 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <_phy>;
+ phy-names = "dp";
+
+ rockchip,grf = <>;
+ resets = < 111>;
+ reset-names = "dp";
+
+ status = "disabled";
+
+ ports {
#address-cells = <1>;
#size-cells = <0>;
Done,
+ edp_in: port {
edp_in: port@0
reg = <0>;
Done,
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <_in_edp>
+ };
+ };
+ };
+ };
+
diff --git a/drivers/gpu/drm/rockchip/Kconfig
b/drivers/gpu/drm/rockchip/Kconfig index 35215f6..c2ba945 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
for the Synopsys DesignWare HDMI driver. If you want to
enable HDMI on RK3288 based SoC, you should selet this
option.
+
Re: [PATCH v4 0/3] KVM: Dynamic Halt-Polling
On Tue, Sep 1, 2015 at 5:29 PM, Wanpeng Li wrote: > On 9/2/15 7:24 AM, David Matlack wrote: >> >> On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li wrote: >>> >>> Why this can happen? >> >> Ah, probably because I'm missing 9c8fd1ba220 (KVM: x86: optimize delivery >> of TSC deadline timer interrupt). I don't think the edge case exists in >> the latest kernel. > > > Yeah, hope we both(include Peter Kieser) can test against latest kvm tree to > avoid confusing. The reason to introduce the adaptive halt-polling toggle is > to handle the "edge case" as you mentioned above. So I think we can make > more efforts improve v4 instead. I will improve v4 to handle short halt > today. ;-) That's fine. It's just easier to convey my ideas with a patch. FYI the other reason for the toggle patch was to add the timer for kvm_vcpu_block, which I think is the only way to get dynamic halt-polling right. Feel free to work on top of v4! > >>> >>> Did you test your patch against a windows guest? >> >> I have not. I tested against a 250HZ linux guest to check how it performs >> against a ticking guest. Presumably, windows should be the same, but at a >> higher tick rate. Do you have a test for Windows? > > > I just test the idle vCPUs usage. > > > V4 for windows 10: > > +-++---+ > | | | > | > | w/o halt-poll | w/ halt-poll | dynamic(v4) halt-poll > | > +-++---+ > | | | > | > |~2.1%|~3.0% | ~2.4% > | > +-++---+ I'm not seeing the same results with v4. With a 250HZ ticking guest I see 15% c0 with halt_poll_ns=200 and 1.27% with halt_poll_ns=0. Are you running one vcpu per pcpu? (The reason for the overhead: the new tracepoint shows each vcpu is alternating between 0 and 500 us.) > > V4 for linux guest: > > +-++---+ > | || | > | w/o halt-poll | w/ halt-poll | dynamic halt-poll | > +-++---+ > | || | > |~0.9%|~1.8% | ~1.2% | > +-++---+ > > > Regards, > Wanpeng Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/16] phy: Add driver for rockchip Display Port PHY
Hi Heiko,
在 09/02/2015 04:58 AM, Heiko Stuebner 写道:
Hi Yakir,
small nit more below
Am Dienstag, 1. September 2015, 18:51:16 schrieb Heiko Stuebner:
Am Dienstag, 1. September 2015, 14:04:15 schrieb Yakir Yang:
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "sclk_dp" "sclk_dp_24m"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: phy@ff770274 {
edp_phy: edp-phy {
+ compatilble = "rockchip,rk3288-dp-phy";
typo: compatible
Aha, thanks.
- Yakir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
Heiko,
在 09/02/2015 04:46 AM, Heiko Stuebner 写道:
Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
Split the dp core driver from exynos directory to bridge
directory, and rename the core driver to analogix_dp_*,
leave the platform code to analogix_dp-exynos.
Signed-off-by: Yakir Yang
[...]
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c similarity index 50%
rename from drivers/gpu/drm/exynos/exynos_dp_core.c
rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bed0252..7d62f22 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
[...]
connector->polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(dp->drm_dev, connector,
-_dp_connector_funcs,
+_dp_connector_funcs,
DRM_MODE_CONNECTOR_eDP);
if (ret) {
DRM_ERROR("Failed to initialize connector with drm\n");
return ret;
}
- drm_connector_helper_add(connector, _dp_connector_helper_funcs);
+ drm_connector_helper_add(connector,
+_dp_connector_helper_funcs);
drm_connector_register(connector);
this should only run on exynos, as we're doing all our connector registration
in the core driver after all components are bound, so I guess something like
the following is needed:
if (dp->plat_data && dp->plat_data->dev_type == EXYNOS_DP)
drm_connector_register(connector);
Oh, good catch, thanks
drm_mode_connector_attach_encoder(connector, encoder);
[...]
@@ -1301,7 +1239,10 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data) if (IS_ERR(dp->reg_base))
return PTR_ERR(dp->reg_base);
- dp->hpd_gpio = of_get_named_gpio(dev->of_node, "samsung,hpd-gpio", 0);
+ dp->hpd_gpio = of_get_named_gpio(dev->of_node, "hpd-gpios", 0);
+ if (gpio_is_valid(dp->hpd_gpio))
this should be !gpio_is_valid ... i.e. only check the old property if the new
one is _not_ valid
Oh, much appreciate ;)
- Yakir
+ dp->hpd_gpio = of_get_named_gpio(dev->of_node,
+"samsung,hpd-gpio", 0);
if (gpio_is_valid(dp->hpd_gpio)) {
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.19.y-ckt stable] Linux 3.19.8-ckt6
I am announcing the release of the Linux 3.19.8-ckt6 kernel. The updated 3.19.y-ckt tree can be found at: git://kernel.ubuntu.com/ubuntu/linux.git linux-3.19.y and can be browsed at: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y The diff from v3.19.8-ckt5 is posted as a follow-up to this email. The 3.19.y-ckt extended stable tree is maintained by the Canonical Kernel Team. For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable -Kamal -- Makefile | 2 +- arch/arm/boot/dts/imx35.dtsi | 8 +- arch/arm/mach-omap2/omap_hwmod.c | 24 +- arch/arm64/kernel/efi.c | 4 +- arch/avr32/mach-at32ap/clock.c| 20 +- arch/tile/kernel/setup.c | 2 +- arch/x86/boot/compressed/eboot.c | 4 + arch/x86/mm/mmap.c| 7 + arch/x86/mm/mpx.c | 20 +- arch/x86/mm/tlb.c | 2 +- arch/x86/platform/efi/efi.c | 5 + arch/x86/xen/enlighten.c | 40 ++ block/bio.c | 15 +- block/blk-cgroup.c| 6 +- drivers/ata/libata-core.c | 21 +- drivers/ata/libata-pmp.c | 7 + drivers/ata/libata-scsi.c | 3 +- drivers/dma/pl330.c | 1 + drivers/firmware/efi/cper.c | 15 +- drivers/firmware/efi/efi.c| 5 + drivers/gpu/drm/drm_crtc.c| 5 +- drivers/gpu/drm/i915/i915_drv.h | 17 +- drivers/gpu/drm/i915/i915_gem_tiling.c| 5 +- drivers/gpu/drm/i915/intel_uncore.c | 26 +- drivers/gpu/drm/nouveau/nv04_fbcon.c | 2 +- drivers/gpu/drm/radeon/radeon_combios.c | 7 +- drivers/hid/hid-cp2112.c | 2 + drivers/iio/adc/vf610_adc.c | 2 +- drivers/input/touchscreen/usbtouchscreen.c| 3 + drivers/iommu/intel-iommu.c | 8 +- drivers/isdn/gigaset/ser-gigaset.c| 11 +- drivers/md/md.c | 2 +- drivers/md/raid1.c| 2 +- drivers/md/raid10.c | 5 +- drivers/misc/mei/main.c | 2 +- drivers/mmc/card/block.c | 2 + drivers/mmc/host/omap_hsmmc.c | 8 +- drivers/mmc/host/sdhci-esdhc.h| 2 +- drivers/mmc/host/sdhci-pxav3.c| 1 + drivers/mmc/host/sdhci.c | 7 +- drivers/net/bonding/bond_main.c | 14 +- drivers/net/can/spi/mcp251x.c | 13 +- drivers/net/ethernet/marvell/mvneta.c | 22 +- drivers/net/ethernet/mellanox/mlx4/eq.c | 4 +- drivers/net/ethernet/sun/niu.c| 4 +- drivers/net/ipvlan/ipvlan.h | 5 + drivers/net/ipvlan/ipvlan_core.c | 2 +- drivers/net/wireless/iwlwifi/mvm/tx.c | 2 +- drivers/net/xen-netback/netback.c | 6 +- drivers/phy/phy-berlin-usb.c | 4 +- drivers/pinctrl/freescale/pinctrl-imx1-core.c | 3 +- drivers/regulator/s2mps11.c | 14 +- drivers/scsi/ipr.c| 28 +- drivers/scsi/ipr.h| 1 + drivers/scsi/qla2xxx/qla_dbg.c| 6 +- drivers/scsi/qla2xxx/qla_def.h| 12 + drivers/scsi/qla2xxx/qla_init.c | 186 +-- drivers/scsi/qla2xxx/qla_iocb.c | 3 + drivers/scsi/qla2xxx/qla_os.c | 11 +- drivers/scsi/qla2xxx/qla_target.c | 752 +++--- drivers/scsi/qla2xxx/qla_target.h | 69 ++- drivers/scsi/qla2xxx/tcm_qla2xxx.c| 23 +- drivers/scsi/scsi_error.c | 2 +- drivers/scsi/scsi_lib.c | 6 +- drivers/spi/spi-imx.c | 5 +- drivers/target/iscsi/iscsi_target.c | 148 ++--- drivers/target/iscsi/iscsi_target_core.h | 8 + drivers/target/iscsi/iscsi_target_erl0.c | 13 +- drivers/target/iscsi/iscsi_target_login.c | 84 ++- drivers/target/iscsi/iscsi_target_login.h | 3 +- drivers/target/iscsi/iscsi_target_nego.c | 34 +- drivers/tty/serial/serial_core.c | 3 +- drivers/usb/core/hcd.c| 7 +- drivers/usb/core/hub.c| 2 +- drivers/usb/core/usb.h| 1 + drivers/usb/dwc3/ep0.c| 4 + drivers/usb/gadget/udc/mv_udc_core.c | 2 +- drivers/usb/host/ohci-q.c | 7 +- drivers/usb/host/xhci-hub.c | 22 +- drivers/usb/host/xhci-mem.c | 2 +-
RE: Re: [PATCH 28/31] perf probe: Init symbol as kprobe
> From: Arnaldo Carvalho de Melo [mailto:a...@redhat.com]
>
> Em Sat, Aug 29, 2015 at 04:22:02AM +, Wang Nan escreveu:
> > Before this patch, add_perf_probe_events() init symbol maps only for
> > uprobe if the first 'struct perf_probe_event' passed to it is a uprobe
> > event. This is a trick because 'perf probe''s command line syntax
> > constrains the first elements of the probe_event arrays must be kprobes
> > if there is one kprobe there.
> >
> > However, with the incoming BPF uprobe support, that constrain is not
> > hold since 'perf record' will also probe on k/u probes through BPF
> > object, and is possible to pass an array with kprobe but the first
> > element is uprobe.
> >
> > This patch init symbol maps for kprobes even if all of events are
> > uprobes, because the extra cost should be small enough.
>
> Masami, are you Ok with this one?
Yeah, looks OK for me ! :)
Acked-by: Masami Hiramatsu
Thanks!
>
> - Arnaldo
>
> > Signed-off-by: Wang Nan
> > Cc: Alexei Starovoitov
> > Cc: Brendan Gregg
> > Cc: Daniel Borkmann
> > Cc: David Ahern
> > Cc: He Kuang
> > Cc: Jiri Olsa
> > Cc: Kaixu Xia
> > Cc: Masami Hiramatsu
> > Cc: Namhyung Kim
> > Cc: Paul Mackerras
> > Cc: Peter Zijlstra
> > Cc: Zefan Li
> > Cc: pi3or...@163.com
> > Cc: Arnaldo Carvalho de Melo
> > Link:
> > http://lkml.kernel.org/n/1436445342-1402-39-git-send-email-wangn...@huawei.com
> > ---
> > tools/perf/util/probe-event.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> > index e720913..b94a8d7 100644
> > --- a/tools/perf/util/probe-event.c
> > +++ b/tools/perf/util/probe-event.c
> > @@ -2789,7 +2789,7 @@ int add_perf_probe_events(struct perf_probe_event
> > *pevs, int npevs,
> > {
> > int i, ret;
> >
> > - ret = init_symbol_maps(pevs->uprobes);
> > + ret = init_symbol_maps(false);
> > if (ret < 0)
> > return ret;
> >
> > --
> > 2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] ARM: dts: Split audio configuration to separate exynos5422-odroidxu3-audio
The Odroid XU4 board does not have audio codec so before adding DTS for
new board split the audio codec to separate DTSI file. Include the audio codec
DTSI in Odroid XU3 and XU3-Lite boards.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. New patch (refactor).
---
arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 61 ++
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 47 -
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts| 1 +
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 1 +
4 files changed, 63 insertions(+), 47 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
new file mode 100644
index ..9493923ec652
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
@@ -0,0 +1,61 @@
+/*
+ * Hardkernel Odroid XU3 Audio Codec device tree source
+ *
+ * Copyright (c) 2015 Krzysztof Kozlowski
+ * Copyright (c) 2014 Collabora Ltd.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+ sound: sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,name = "Odroid-XU3";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Speakers", "Speakers";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "Headphone Jack", "MICBIAS",
+ "IN1", "Headphone Jack",
+ "Speakers", "SPKL",
+ "Speakers", "SPKR";
+
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <_codec>;
+
+ simple-audio-card,cpu {
+ sound-dai = < 0>;
+ system-clock-frequency = <1920>;
+ };
+
+ link0_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ clocks = < CLK_I2S_CDCLK>;
+ };
+ };
+};
+
+_5 {
+ status = "okay";
+ max98090: max98090@10 {
+ compatible = "maxim,max98090";
+ reg = <0x10>;
+ interrupt-parent = <>;
+ interrupts = <2 0>;
+ clocks = < CLK_I2S_CDCLK>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index dd8bc86d9de4..987c15d8ebe5 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -80,36 +80,6 @@
};
};
- sound: sound {
- compatible = "simple-audio-card";
-
- simple-audio-card,name = "Odroid-XU3";
- simple-audio-card,widgets =
- "Headphone", "Headphone Jack",
- "Speakers", "Speakers";
- simple-audio-card,routing =
- "Headphone Jack", "HPL",
- "Headphone Jack", "HPR",
- "Headphone Jack", "MICBIAS",
- "IN1", "Headphone Jack",
- "Speakers", "SPKL",
- "Speakers", "SPKR";
-
- simple-audio-card,format = "i2s";
- simple-audio-card,bitclock-master = <_codec>;
- simple-audio-card,frame-master = <_codec>;
-
- simple-audio-card,cpu {
- sound-dai = < 0>;
- system-clock-frequency = <1920>;
- };
-
- link0_codec: simple-audio-card,codec {
- sound-dai = <>;
- clocks = < CLK_I2S_CDCLK>;
- };
- };
-
fan0: pwm-fan {
compatible = "pwm-fan";
pwms = < 0 20972 0>;
@@ -376,19 +346,6 @@
};
};
-_5 {
- status = "okay";
- max98090: max98090@10 {
- compatible = "maxim,max98090";
- reg = <0x10>;
- interrupt-parent = <>;
- interrupts = <2 0>;
- clocks = < CLK_I2S_CDCLK>;
- clock-names = "mclk";
- #sound-dai-cells = <0>;
- };
-};
-
_2 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
@@ -400,10 +357,6 @@
};
};
- {
- status = "okay";
-};
-
[PATCH v2 2/2] ARM: dts: Add exynos5422-odroidxu4 board
Add Hardkernel Odroid XU4 board Device Tree sources. The board differs
from Odroid XU3 and XU3-Lite by:
1. No green and red leds (except standard red power led).
2. No audio codec.
3. Two USB3 ports in host mode (no micro USB3 connector for OTG).
4. Realtek RTL8153-CG gigabit network adapter (instead of SMSC9514).
5. Additional connector with IO ports (I2S_0, I2C_5).
6. No DisplayPort (like XU3-Lite).
7. No TI INA231 power measurement sensors (like XU3-Lite).
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. hsi2c_5 and is20 are disabled on Odroid XU4 (after moving these nodes
to the audio DTSI).
2. Update Samsung's copyright date for XU4 DTS.
I did not add Javier's reviewed-by tag because of splitting audio codec
to separate patch (1/2).
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 51 +-
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts| 51 ++
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 51 ++
arch/arm/boot/dts/exynos5422-odroidxu4.dts | 48
5 files changed, 152 insertions(+), 50 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d2eaab..3d27fe34647f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -123,6 +123,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5420-smdk5420.dtb \
exynos5422-odroidxu3.dtb \
exynos5422-odroidxu3-lite.dtb \
+ exynos5422-odroidxu4.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 987c15d8ebe5..a83d569baea8 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -46,40 +46,6 @@
reset-gpios = < 0 1>;
};
- pwmleds {
- compatible = "pwm-leds";
-
- greenled {
- label = "green:mmc0";
- pwms = < 1 200 0>;
- pwm-names = "pwm1";
- /*
-* Green LED is much brighter than the others
-* so limit its max brightness
-*/
- max_brightness = <127>;
- linux,default-trigger = "mmc0";
- };
-
- blueled {
- label = "blue:heartbeat";
- pwms = < 2 200 0>;
- pwm-names = "pwm2";
- max_brightness = <255>;
- linux,default-trigger = "heartbeat";
- };
- };
-
- gpioleds {
- compatible = "gpio-leds";
- redled {
- label = "red:microSD";
- gpios = < 3 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- linux,default-trigger = "mmc1";
- };
- };
-
fan0: pwm-fan {
compatible = "pwm-fan";
pwms = < 0 20972 0>;
@@ -417,19 +383,6 @@
};
};
- {
- /*
-* PWM 0 -- fan
-* PWM 1 -- Green LED
-* PWM 2 -- Blue LED
-* PWM 3 -- on MIPI connector for backlight
-*/
- pinctrl-0 = <_out _out _out _out>;
- pinctrl-names = "default";
- samsung,pwm-outputs = <0>;
- status = "okay";
-};
-
_cpu0 {
vtmu-supply = <_reg>;
status = "okay";
@@ -465,9 +418,7 @@
dr_mode = "host";
};
-_dwc3_1 {
- dr_mode = "otg";
-};
+/* usbdrd_dwc3_1 mode customized in each board */
_0 {
vdd33-supply = <_reg>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
index 9c0cea99c996..379cd61178ee 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
@@ -18,4 +18,55 @@
/ {
model = "Hardkernel Odroid XU3 Lite";
compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800",
"samsung,exynos5";
+
+ pwmleds {
+ compatible = "pwm-leds";
+
+ greenled {
+ label = "green:mmc0";
+ pwms = < 1 200 0>;
+ pwm-names = "pwm1";
+ /*
+* Green LED is much brighter than the others
+* so limit its max brightness
+*/
+ max_brightness = <127>;
+ linux,default-trigger = "mmc0";
+ };
+
+ blueled {
+ label = "blue:heartbeat";
+ pwms = < 2
Re: [PATCH 28/31] perf probe: Init symbol as kprobe
On 2015/9/2 4:11, Arnaldo Carvalho de Melo wrote:
Em Sat, Aug 29, 2015 at 04:22:02AM +, Wang Nan escreveu:
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first 'struct perf_probe_event' passed to it is a uprobe
event. This is a trick because 'perf probe''s command line syntax
constrains the first elements of the probe_event arrays must be kprobes
if there is one kprobe there.
However, with the incoming BPF uprobe support, that constrain is not
hold since 'perf record' will also probe on k/u probes through BPF
object, and is possible to pass an array with kprobe but the first
element is uprobe.
This patch init symbol maps for kprobes even if all of events are
uprobes, because the extra cost should be small enough.
Masami, are you Ok with this one?
I think he would be okay with it because it is his idea :)
Please refer to: http://lkml.kernel.org/n/558e5f42.1060...@hitachi.com
Thank you.
- Arnaldo
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Cc: Arnaldo Carvalho de Melo
Link:
http://lkml.kernel.org/n/1436445342-1402-39-git-send-email-wangn...@huawei.com
---
tools/perf/util/probe-event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index e720913..b94a8d7 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2789,7 +2789,7 @@ int add_perf_probe_events(struct perf_probe_event *pevs,
int npevs,
{
int i, ret;
- ret = init_symbol_maps(pevs->uprobes);
+ ret = init_symbol_maps(false);
if (ret < 0)
return ret;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote:
> On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel wrote:
> > Does this mean a built-in driver can not get firmware from initramfs or
> > built in the kernel early. Seems a bit too aggressive. The problem stated in
> > this thread is when the firmware is not on initramfs but only on the rootfs.
>
> Yes, strictly speaking, user mode request can't be handled with defer probe
> during booting because we don't know how the user helper handles the
> request,
FWIW I have a strategy in mind to help us compartamentalize the user mode
helper only to the dell-rbu driver, and as such phase out that code eventually
completely. Its part of the goals I have with the extensible firmware API I've
been proposing.
> that said even checking if the firmware exists in current path doesn't
> make sense for user mode request.
>
> So the patch should have used defer proble for direct load only
> during booting.
What exact guarantees would we be giving to callers if they follow up on probe
with -EDEFER_PROBE ? I'd much prefer to try to avoid such uses in init / probe
(note that unless you're using async probe since we batch both so it doesn't
really
matter where you place your code) all together and then for the few remaining
stragglers understand the requirements and provide an interface that lets them
claim their requirements and try to meets them.
A grammatical hunt for drivers who call fw API on init / probe can be
completed, although I know the hunt needs a bit more fine tuning it surely can
be completed. If we don't have many callers the compexity added for only a
few callers with rather loose criteria seems rather unnecessary, specially if
we can change the drivers and make these driver sthe exception rather than
a norm.
Then as for drivers *needing* the fw at probe why not have a proper interface
that does guarantee they get the requirements they ask for first ? For instance
a new probe type specified by the driver could enable the core to wait for say
an event and then tirgger a probe, kind of how we ended up defining the async
probe type preference:
static struct some_bus_driver some_driver = {
.probe = some_probe,
.id_table = some_id,
.driver = {
.name = DEVICE_NAME,
.pm = _pm_ops,
.probe_type = PROBE_PREFER_POST_FOO,
},
};
Then we just don't try just hoping for completion but rather can do something
about the criteria passed.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.13.y-ckt 03/60] libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Aleksei Mamlin
commit 08c85d2a599d967ede38a847f5594447b6100642 upstream.
Enabling AA on HP 250GB SATA disk VB0250EAVER causes errors:
[3.788362] ata3.00: failed to enable AA (error_mask=0x1)
[3.789243] ata3.00: failed to enable AA (error_mask=0x1)
Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.
tj: Collected FPDMA_AA entries and updated comment.
Signed-off-by: Aleksei Mamlin
Signed-off-by: Tejun Heo
Signed-off-by: Kamal Mostafa
---
drivers/ata/libata-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 1efa300..684f02d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4173,9 +4173,10 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
{ "ST3320[68]13AS", "SD1[5-9]", ATA_HORKAGE_NONCQ |
ATA_HORKAGE_FIRMWARE_WARN },
- /* Seagate Momentus SpinPoint M8 seem to have FPMDA_AA issues */
+ /* drives which fail FPDMA_AA activation (some may freeze afterwards) */
{ "ST1000LM024 HN-M101MBB", "2AR10001", ATA_HORKAGE_BROKEN_FPDMA_AA },
{ "ST1000LM024 HN-M101MBB", "2BA30001", ATA_HORKAGE_BROKEN_FPDMA_AA },
+ { "VB0250EAVER","HPG7", ATA_HORKAGE_BROKEN_FPDMA_AA },
/* Blacklist entries taken from Silicon Image 3124/3132
Windows driver .inf file - also several Linux problem reports */
--
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 3.13.y-ckt 02/60] ata: pmp: add quirk for Marvell 4140 SATA PMP
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Lior Amsalem
commit 945b47441d83d2392ac9f984e0267ad521f24268 upstream.
This commit adds the necessary quirk to make the Marvell 4140 SATA PMP
work properly. This PMP doesn't like SRST on port number 4 (the host
port) so this commit marks this port as not supporting SRST.
Signed-off-by: Lior Amsalem
Reviewed-by: Nadav Haklai
Signed-off-by: Thomas Petazzoni
Signed-off-by: Tejun Heo
Signed-off-by: Kamal Mostafa
---
drivers/ata/libata-pmp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/libata-pmp.c b/drivers/ata/libata-pmp.c
index 7ccc084..85aa761 100644
--- a/drivers/ata/libata-pmp.c
+++ b/drivers/ata/libata-pmp.c
@@ -460,6 +460,13 @@ static void sata_pmp_quirks(struct ata_port *ap)
ATA_LFLAG_NO_SRST |
ATA_LFLAG_ASSUME_ATA;
}
+ } else if (vendor == 0x11ab && devid == 0x4140) {
+ /* Marvell 4140 quirks */
+ ata_for_each_link(link, ap, EDGE) {
+ /* port 4 is for SEMB device and it doesn't like SRST */
+ if (link->pmp == 4)
+ link->flags |= ATA_LFLAG_DISABLED;
+ }
}
}
--
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 3.13.y-ckt 04/60] libata: add ATA_HORKAGE_NOTRIM
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Arne Fitzenreiter
commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 upstream.
Some devices lose data on TRIM whether queued or not. This patch adds
a horkage to disable TRIM.
tj: Collapsed unnecessary if() nesting.
Signed-off-by: Arne Fitzenreiter
Signed-off-by: Tejun Heo
[ luis: backported to 3.16:
- dropped changes to show_ata_dev_trim
- adjusted context ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
drivers/ata/libata-scsi.c | 3 ++-
include/linux/libata.h| 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index ef8567d..6fecf0b 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2510,7 +2510,8 @@ static unsigned int ata_scsiop_read_cap(struct
ata_scsi_args *args, u8 *rbuf)
rbuf[14] = (lowest_aligned >> 8) & 0x3f;
rbuf[15] = lowest_aligned;
- if (ata_id_has_trim(args->id)) {
+ if (ata_id_has_trim(args->id) &&
+ !(dev->horkage & ATA_HORKAGE_NOTRIM)) {
rbuf[14] |= 0x80; /* TPE */
if (ata_id_has_zero_after_trim(args->id))
diff --git a/include/linux/libata.h b/include/linux/libata.h
index fa413ee..8c58412 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -429,6 +429,8 @@ enum {
ATA_HORKAGE_NO_NCQ_TRIM = (1 << 19),/* don't use queued TRIM */
ATA_HORKAGE_NOLPM = (1 << 20),/* don't use LPM */
ATA_HORKAGE_WD_BROKEN_LPM = (1 << 21), /* some WDs have broken LPM */
+ ATA_HORKAGE_NOTRIM = (1 << 24),/* don't use TRIM */
+
/* DMA mask for user DMA control: User visible values; DO NOT
renumber */
--
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 3.13.y-ckt 01/60] md: use kzalloc() when bitmap is disabled
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let me know. -- From: Benjamin Randazzo commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream. In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a mdu_bitmap_file_t called "file". 5769 file = kmalloc(sizeof(*file), GFP_NOIO); 5770 if (!file) 5771 return -ENOMEM; This structure is copied to user space at the end of the function. 5786 if (err == 0 && 5787 copy_to_user(arg, file, sizeof(*file))) 5788 err = -EFAULT But if bitmap is disabled only the first byte of "file" is initialized with zero, so it's possible to read some bytes (up to 4095) of kernel space memory from user space. This is an information leak. 5775 /* bitmap disabled, zero the first byte and copy out */ 5776 if (!mddev->bitmap_info.file) 5777 file->pathname[0] = '\0'; Signed-off-by: Benjamin Randazzo Signed-off-by: NeilBrown Reference: CVE-2015-5697 Signed-off-by: Kamal Mostafa --- drivers/md/md.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 2ee29a7..8cccbdf 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -5633,7 +5633,7 @@ static int get_bitmap_file(struct mddev * mddev, void __user * arg) char *ptr, *buf = NULL; int err = -ENOMEM; - file = kmalloc(sizeof(*file), GFP_NOIO); + file = kzalloc(sizeof(*file), GFP_NOIO); if (!file) goto out; -- 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 3.13.y-ckt 05/60] libata: force disable trim for SuperSSpeed S238
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Arne Fitzenreiter
commit cda57b1b05cf7b8b99ab4b732bea0b05b6c015cc upstream.
This device loses blocks, often the partition table area, on trim.
Disable TRIM.
http://pcengines.ch/msata16a.htm
Signed-off-by: Arne Fitzenreiter
Signed-off-by: Tejun Heo
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
drivers/ata/libata-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 684f02d..0dd99e7 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4230,6 +4230,9 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
{ "Micron_M550*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
{ "Crucial_CT*M550SSD*",NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
+ /* devices that don't properly handle TRIM commands */
+ { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, },
+
/*
* Some WD SATA-I drives spin up and down erratically when the link
* is put into the slumber mode. We don't have full list of the
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm/slab_common: add SLAB_NO_MERGE flag for use when creating slabs
On Tue, Sep 01, 2015 at 01:51:29PM -0400, Mike Snitzer wrote:
> The slab aliasing/merging by default transition went unnoticed (at least
> to the DM subsystem). Add a new SLAB_NO_MERGE flag that allows
> individual slabs to be created without slab merging. This beats forcing
> all slabs to be created in this fashion by specifying sl[au]b_nomerge on
> the kernel commandline.
I didn't realise that this merging had also been applied to SLAB - I
thought it was just SLUB that did this. Indeed, one of the prime
reasons for using SLAB over SLUB was that it didn't merge caches and
so still gave excellent visibility of runtime slab memory usage on
production systems.
I had no idea that commit 12220de ("mm/slab: support slab merge")
had made SLAB do this as well as it was not cc'd to any of the
people/subsystems that maintain code that uses slab caches. IMNSHO
the commit message gives pretty flimsy justification for such a
change, especially considering we need to deal with slab caches that
individually grow to contain hundreds of millions of objects.
> DM has historically taken care to have separate named slabs that each
> devices' mempool_t are backed by. These separate slabs are useful --
> even if only to aid inspection of DM's memory use (via /proc/slabinfo)
> on production systems.
Yup, that's one of the reasons XFS has 17 separate slab caches. The
other main reason is that slab separation also helps keep memory
corruption and use-after free issues contained; if you have a
problem with the objects from one slab cache, the isolation of the
slab makes it less likely that the problem propagates to other
subsystems. Hence failures also tend to be isolated to the code that
has the leak/corruption problem, making them easier to triage and
debug on production systems...
> I stumbled onto slab merging as a side-effect of a leak in dm-cache
> being attributed to 'kmalloc-96' rather than the expected
> 'dm_bio_prison_cell' named slab. Moving forward DM will disable slab
> merging for all of DM's slabs by using SLAB_NO_MERGE.
Seems like a fine idea to me. I can apply it to various slabs in XFS
once it's merged
Acked-by: Dave Chinner
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 09/60] ALSA: hda - Add new GPU codec ID 0x10de007d to snd-hda
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Aaron Plattner
commit 6c3d91193d829bf58a35a10650415b05a736ca6c upstream.
Vendor ID 0x10de007d is used by a yet-to-be-named GPU chip.
This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: Aaron Plattner
Signed-off-by: Takashi Iwai
Signed-off-by: Kamal Mostafa
---
sound/pci/hda/patch_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 0c1be26..09a4c80 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -3345,6 +3345,7 @@ static const struct hda_codec_preset
snd_hda_preset_hdmi[] = {
{ .id = 0x10de0070, .name = "GPU 70 HDMI/DP", .patch = patch_nvhdmi },
{ .id = 0x10de0071, .name = "GPU 71 HDMI/DP", .patch = patch_nvhdmi },
{ .id = 0x10de0072, .name = "GPU 72 HDMI/DP", .patch = patch_nvhdmi },
+{ .id = 0x10de007d, .name = "GPU 7d HDMI/DP", .patch = patch_nvhdmi },
{ .id = 0x10de8001, .name = "MCP73 HDMI", .patch = patch_nvhdmi_2ch },
{ .id = 0x11069f80, .name = "VX900 HDMI/DP", .patch = patch_via_hdmi },
{ .id = 0x11069f81, .name = "VX900 HDMI/DP", .patch = patch_via_hdmi },
@@ -3402,6 +3403,7 @@ MODULE_ALIAS("snd-hda-codec-id:10de0067");
MODULE_ALIAS("snd-hda-codec-id:10de0070");
MODULE_ALIAS("snd-hda-codec-id:10de0071");
MODULE_ALIAS("snd-hda-codec-id:10de0072");
+MODULE_ALIAS("snd-hda-codec-id:10de007d");
MODULE_ALIAS("snd-hda-codec-id:10de8001");
MODULE_ALIAS("snd-hda-codec-id:11069f80");
MODULE_ALIAS("snd-hda-codec-id:11069f81");
--
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 3.13.y-ckt 10/60] md/raid10: always set reshape_safe when initializing reshape_position.
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: NeilBrown
commit 299b0685e31c9f3dcc2d58ee3beca761a40b44b3 upstream.
'reshape_position' tracks where in the reshape we have reached.
'reshape_safe' tracks where in the reshape we have safely recorded
in the metadata.
These are compared to determine when to update the metadata.
So it is important that reshape_safe is initialised properly.
Currently it isn't. When starting a reshape from the beginning
it usually has the correct value by luck. But when reducing the
number of devices in a RAID10, it has the wrong value and this leads
to the metadata not being updated correctly.
This can lead to corruption if the reshape is not allowed to complete.
This patch is suitable for any -stable kernel which supports RAID10
reshape, which is 3.5 and later.
Fixes: 3ea7daa5d7fd ("md/raid10: add reshape support")
Signed-off-by: NeilBrown
Signed-off-by: Kamal Mostafa
---
drivers/md/raid10.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 1b707ad..b8215a3 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3597,6 +3597,7 @@ static struct r10conf *setup_conf(struct mddev *mddev)
/* far_copies must be 1 */
conf->prev.stride = conf->dev_sectors;
}
+ conf->reshape_safe = conf->reshape_progress;
spin_lock_init(>device_lock);
INIT_LIST_HEAD(>retry_list);
@@ -3804,7 +3805,6 @@ static int run(struct mddev *mddev)
}
conf->offset_diff = min_offset_diff;
- conf->reshape_safe = conf->reshape_progress;
clear_bit(MD_RECOVERY_SYNC, >recovery);
clear_bit(MD_RECOVERY_CHECK, >recovery);
set_bit(MD_RECOVERY_RESHAPE, >recovery);
@@ -4149,6 +4149,7 @@ static int raid10_start_reshape(struct mddev *mddev)
conf->reshape_progress = size;
} else
conf->reshape_progress = 0;
+ conf->reshape_safe = conf->reshape_progress;
spin_unlock_irq(>device_lock);
if (mddev->delta_disks && mddev->bitmap) {
@@ -4215,6 +4216,7 @@ abort:
rdev->new_data_offset = rdev->data_offset;
smp_wmb();
conf->reshape_progress = MaxSector;
+ conf->reshape_safe = MaxSector;
mddev->reshape_position = MaxSector;
spin_unlock_irq(>device_lock);
return ret;
@@ -4566,6 +4568,7 @@ static void end_reshape(struct r10conf *conf)
md_finish_reshape(conf->mddev);
smp_wmb();
conf->reshape_progress = MaxSector;
+ conf->reshape_safe = MaxSector;
spin_unlock_irq(>device_lock);
/* read-ahead size must cover two whole stripes, which is
--
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 3.13.y-ckt 07/60] libata: Do not blacklist M510DC
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: "Martin K. Petersen"
commit 9051bd393cf25e76dfb45409792719a854661500 upstream.
A new Micron drive was just announced, once again recycling the first
part of the model string. Add an underscore to the M510/M550 pattern to
avoid picking up the new DC drive.
Signed-off-by: Martin K. Petersen
Signed-off-by: Tejun Heo
[ kamal: backport to 3.13-stable: context ]
Signed-off-by: Kamal Mostafa
---
drivers/ata/libata-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 83c95c1..0b4f2f5 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4227,7 +4227,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
{ "Crucial_CT???M500SSD*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
- { "Micron_M550*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
+ { "Micron_M550_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
{ "Crucial_CT*M550SSD*",NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
/* devices that don't properly handle TRIM commands */
--
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 3.13.y-ckt 08/60] mac80211: clear subdir_stations when removing debugfs
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let me know. -- From: Tom Hughes commit 4479004e6409087d1b4986881dc98c6c15dffb28 upstream. If we don't do this, and we then fail to recreate the debugfs directory during a mode change, then we will fail later trying to add stations to this now bogus directory: BUG: unable to handle kernel NULL pointer dereference at 006c IP: [] mutex_lock+0x12/0x30 Call Trace: [] start_creating+0x44/0xc0 [] debugfs_create_dir+0x13/0xf0 [] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211] Signed-off-by: Tom Hughes Signed-off-by: Johannes Berg Signed-off-by: Kamal Mostafa --- net/mac80211/debugfs_netdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c index cae3d14..a6119a2 100644 --- a/net/mac80211/debugfs_netdev.c +++ b/net/mac80211/debugfs_netdev.c @@ -705,6 +705,7 @@ void ieee80211_debugfs_remove_netdev(struct ieee80211_sub_if_data *sdata) debugfs_remove_recursive(sdata->vif.debugfs_dir); sdata->vif.debugfs_dir = NULL; + sdata->debugfs.subdir_stations = NULL; } void ieee80211_debugfs_rename_netdev(struct ieee80211_sub_if_data *sdata) -- 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 3.13.y-ckt 16/60] xhci: prevent bus_suspend if SS port resuming in phase 1
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Zhuang Jin Can
commit fac4271d1126c45ceaceb7f4a336317b771eb121 upstream.
When the link is just waken, it's in Resume state, and driver sets PLS to
U0. This refers to Phase 1. Phase 2 refers to when the link has completed
the transition from Resume state to U0.
With the fix of xhci: report U3 when link is in resume state, it also
exposes an issue that usb3 roothub and controller can suspend right
after phase 1, and this causes a hard hang in controller.
To fix the issue, we need to prevent usb3 bus suspend if any port is
resuming in phase 1.
[merge separate USB2 and USB3 port resume checking to one -Mathias]
Signed-off-by: Zhuang Jin Can
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
drivers/usb/host/xhci-hub.c | 6 +++---
drivers/usb/host/xhci-ring.c | 3 +++
drivers/usb/host/xhci.h | 1 +
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index d2d82de..672e0b1 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1121,10 +1121,10 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
spin_lock_irqsave(>lock, flags);
if (hcd->self.root_hub->do_remote_wakeup) {
- if (bus_state->resuming_ports) {
+ if (bus_state->resuming_ports ||/* USB2 */
+ bus_state->port_remote_wakeup) {/* USB3 */
spin_unlock_irqrestore(>lock, flags);
- xhci_dbg(xhci, "suspend failed because "
- "a port is resuming\n");
+ xhci_dbg(xhci, "suspend failed because a port is
resuming\n");
return -EBUSY;
}
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d328d16..3f1276c 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1757,6 +1757,9 @@ static void handle_port_status(struct xhci_hcd *xhci,
usb_hcd_resume_root_hub(hcd);
}
+ if (hcd->speed == HCD_USB3 && (temp & PORT_PLS_MASK) == XDEV_INACTIVE)
+ bus_state->port_remote_wakeup &= ~(1 << faked_port_index);
+
if ((temp & PORT_PLC) && (temp & PORT_PLS_MASK) == XDEV_RESUME) {
xhci_dbg(xhci, "port resume event for port %d\n", port_id);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 5b77371..d053de1 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -285,6 +285,7 @@ struct xhci_op_regs {
#define XDEV_U0(0x0 << 5)
#define XDEV_U2(0x2 << 5)
#define XDEV_U3(0x3 << 5)
+#define XDEV_INACTIVE (0x6 << 5)
#define XDEV_RESUME(0xf << 5)
/* true: port has power (see HCC_PPC) */
#define PORT_POWER (1 << 9)
--
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: can't apply frequency offsets above 1000ppm.
On Wed, Sep 2, 2015 at 2:03 AM, John Stultz wrote: > On Tue, Sep 1, 2015 at 5:36 PM, Nuno Gonçalves wrote: >> On Tue, Sep 1, 2015 at 9:25 PM, Thomas Gleixner wrote: >>> On Tue, 1 Sep 2015, Nuno Gonçalves wrote: >>> There is a regression on the clock system since v3.16-rc5-111-g4396e05 [1], >>> [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4396e058c52e167729729cf64ea3dfa229637086 >>> >>> That commit has absolutely nothing to do with NTP. I fear your bisect >>> went down the wrong road somewhere. >> >> You are right. It is v3.16-rc5-114-gdc49159: >> >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dc491596f6394382fbc74ad331156207d619fa0a >> >> I've triple checked it this time. Not sure where I did the mistake to >> get it wrong by 3 commits. > > This commit is much more believable (though surprising as that change > was found to greatly improve results for most uses). > > Can you provide any more details about how the problem is reproduced > (kernel config, what userland images are you using, etc)? I've got a > BBB myself so I can try to see whats going on. > > thanks > -john I'm using a clean Debian image: https://rcn-ee.com/rootfs/bb.org/testing/2015-08-31/console/bone-debian-8.1-console-armhf-2015-08-31-2gb.img.xz And just installing chrony from the feeds. With any kernel from 3.17 you'll have wrong estimates at chronyc sourcestats. Miroslav did some tests at a beaglebone I set for him, according to my initial post. Miroslav also dismissed this being related to nohz after some tests. Thanks, Nuno -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.13.y-ckt 12/60] usb: dwc3: Reset the transfer resource index on SET_INTERFACE
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let me know. -- From: John Youn commit aebda618718157a69c0dc0adb978d69bc2b8723c upstream. This fixes an issue introduced in commit b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would only use DEPSTARTCFG once per SetConfig. The trick is that we should use one DEPSTARTCFG per SetConfig *OR* SetInterface. SetInterface was completely missed from the original patch. This problem became aparent after commit 76e838c9f776 (usb: dwc3: gadget: return error if command sent to DEPCMD register fails) added checking of the return status of device endpoint commands. 'Set Endpoint Transfer Resource' command was caught failing occasionally. This is because the Transfer Resource Index was not getting reset during a SET_INTERFACE request. Finally, to fix the issue, was we have to do is make sure that our start_config_issued flag gets reset whenever we receive a SetInterface request. To verify the problem (and its fix), all we have to do is run test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'. Tested-by: Huang Rui Tested-by: Subbaraya Sundeep Bhatta Fixes: b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs) Signed-off-by: John Youn Signed-off-by: Felipe Balbi [ luis: backported to 3.16: - replaced dwc3_trace() by dev_vdbg() ] Signed-off-by: Luis Henriques Signed-off-by: Kamal Mostafa --- drivers/usb/dwc3/ep0.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index 0985ff7..bcefce0 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -707,6 +707,10 @@ static int dwc3_ep0_std_request(struct dwc3 *dwc, struct usb_ctrlrequest *ctrl) dev_vdbg(dwc->dev, "USB_REQ_SET_ISOCH_DELAY\n"); ret = dwc3_ep0_set_isoch_delay(dwc, ctrl); break; + case USB_REQ_SET_INTERFACE: + dev_vdbg(dwc->dev, "USB_REQ_SET_INTERFACE"); + dwc->start_config_issued = false; + /* Fall through */ default: dev_vdbg(dwc->dev, "Forwarding to gadget driver\n"); ret = dwc3_ep0_delegate_req(dwc, ctrl); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel:kexec - Fix for typo in comment in function sanity_check_segment_list().
Hi Shailendra, On Sat, May 23, 2015 at 10:38:57AM +0530, Shailendra Verma wrote: > > Signed-off-by: Shailendra Verma Reviewed-by: Simon Horman I believe if you repost this with Andrew Morton cced then there is a good chance of it progressing into a kernel release. > --- > kernel/kexec.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/kexec.c b/kernel/kexec.c > index 7a36fdc..50dffdb 100644 > --- a/kernel/kexec.c > +++ b/kernel/kexec.c > @@ -189,7 +189,7 @@ static int sanity_check_segment_list(struct kimage *image) > } > > /* Verify our destination addresses do not overlap. > - * If we alloed overlapping destination addresses > + * If we allowed overlapping destination addresses >* through very weird things can happen with no >* easy explanation as one segment stops on another. >*/ > -- > 1.7.9.5 > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.13.y-ckt 13/60] usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let me know. -- From: AMAN DEEP commit 3496810663922617d4b706ef2780c279252ddd6a upstream. virt_dev->num_cached_rings counts on freed ring and is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring is added into cache and then num_rings_cache is incremented as below: virt_dev->ring_cache[rings_cached] = virt_dev->eps[ep_index].ring; virt_dev->num_rings_cached++; here, free ring pointer is added to a current index and then index is incremented. So current index always points to empty location in the ring cache. For getting available free ring, current index should be decremented first and then corresponding ring buffer value should be taken from ring cache. But In function xhci_endpoint_init(), the num_rings_cached index is accessed before decrement. virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; virt_dev->num_rings_cached--; This is bug in manipulating the index of ring cache. And it should be as below: virt_dev->num_rings_cached--; virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; Signed-off-by: Aman Deep Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Kamal Mostafa --- drivers/usb/host/xhci-mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 06d0d1e..146923a 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1331,10 +1331,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci, /* Attempt to use the ring cache */ if (virt_dev->num_rings_cached == 0) return -ENOMEM; + virt_dev->num_rings_cached--; virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; - virt_dev->num_rings_cached--; xhci_reinit_cached_ring(xhci, virt_dev->eps[ep_index].new_ring, 1, type); } -- 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 3.13.y-ckt 06/60] libata: increase the timeout when setting transfer mode
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Mikulas Patocka
commit d531be2ca2f27cca5f041b6a140504999144a617 upstream.
I have a ST4000DM000 disk. If Linux is booted while the disk is spun down,
the command that sets transfer mode causes the disk to spin up. The
spin-up takes longer than the default 5s timeout, so the command fails and
timeout is reported.
Fix this by increasing the timeout to 15s, which is enough for the disk to
spin up.
Signed-off-by: Mikulas Patocka
Signed-off-by: Tejun Heo
Signed-off-by: Kamal Mostafa
---
drivers/ata/libata-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 0dd99e7..83c95c1 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4537,7 +4537,8 @@ static unsigned int ata_dev_set_xfermode(struct
ata_device *dev)
else /* In the ancient relic department - skip all of this */
return 0;
- err_mask = ata_exec_internal(dev, , NULL, DMA_NONE, NULL, 0, 0);
+ /* On some disks, this command causes spin-up, so we need longer
timeout */
+ err_mask = ata_exec_internal(dev, , NULL, DMA_NONE, NULL, 0, 15000);
DPRINTK("EXIT, err_mask=%x\n", err_mask);
return err_mask;
--
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 3.13.y-ckt 15/60] xhci: report U3 when link is in resume state
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Zhuang Jin Can
commit 243292a2ad3dc365849b820a64868927168894ac upstream.
xhci_hub_report_usb3_link_state() returns pls as U0 when the link
is in resume state, and this causes usb core to think the link is in
U0 while actually it's in resume state. When usb core transfers
control request on the link, it fails with TRB error as the link
is not ready for transfer.
To fix the issue, report U3 when the link is in resume state, thus
usb core knows the link it's not ready for transfer.
Signed-off-by: Zhuang Jin Can
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
drivers/usb/host/xhci-hub.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 9b69daf..d2d82de 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -480,10 +480,13 @@ static void xhci_hub_report_usb3_link_state(struct
xhci_hcd *xhci,
u32 pls = status_reg & PORT_PLS_MASK;
/* resume state is a xHCI internal state.
-* Do not report it to usb core.
+* Do not report it to usb core, instead, pretend to be U3,
+* thus usb core knows it's not ready for transfer
*/
- if (pls == XDEV_RESUME)
+ if (pls == XDEV_RESUME) {
+ *status |= USB_SS_PORT_LS_U3;
return;
+ }
/* When the CAS bit is set then warm reset
* should be performed on port
--
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: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote: > > Linux has a handful of weird features that are only supported for > backwards compatibility. The big one is the x86_64 vsyscall page, but > uselib probably belongs on the list, too, and we might end up with > more at some point. > > I'd like to add a way that new programs can turn these features off. > In particular, I want the vsyscall page to be completely gone from the > perspective of any new enough program. This is straightforward if we > add a system call to ask for the vsyscall page to be disabled, but I'm > wondering if we can come up with a non-syscall way to do it. > > I think that the ideal behavior would be that anything linked against > a sufficiently new libc would be detected, but I don't see a good way > to do that using existing toolchain features. > > Ideas? We could add a new phdr for this, but then we'd need to play > linker script games, and I'm not sure that could be done in a clean, > extensible way. What sets up the vsyscall page, and what information does it have before doing so? I'm guessing it's the kernel that sets it up, and that all it can see at that point is the program headers. We could pass information using an appropriate note section. My recollection is that the linkers will turn an SHF_ALLOC note section into a PT_NOTE program header. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.13.y-ckt 19/60] usb-storage: ignore ZTE MF 823 card reader in mode 0x1225
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let me know. -- From: Oliver Neukum commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 upstream. This device automatically switches itself to another mode (0x1405) unless the specific access pattern of Windows is followed in its initial mode. That makes a dirty unmount of the internal storage devices inevitable if they are mounted. So the card reader of such a device should be ignored, lest an unclean removal become inevitable. This replaces an earlier patch that ignored all LUNs of this device. That patch was overly broad. Signed-off-by: Oliver Neukum Reviewed-by: Lars Melin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Kamal Mostafa --- drivers/usb/storage/unusual_devs.h | 12 1 file changed, 12 insertions(+) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index 3e5fa2e..ccd7058 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -2046,6 +2046,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0200, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NO_READ_DISC_INFO ), +/* Reported by Oliver Neukum + * This device morphes spontaneously into another device if the access + * pattern of Windows isn't followed. Thus writable media would be dirty + * if the initial instance is used. So the device is limited to its + * virtual CD. + * And yes, the concept that BCD goes up to 9 is not heeded */ +UNUSUAL_DEV( 0x19d2, 0x1225, 0x, 0x, + "ZTE,Incorporated", + "ZTE WCDMA Technologies MSM", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_SINGLE_LUN ), + /* Reported by Sven Geggus * This encrypted pen drive returns bogus data for the initial READ(10). */ -- 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 3.13.y-ckt 17/60] xhci: do not report PLC when link is in internal resume state
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Zhuang Jin Can
commit aca3a0489ac019b58cf32794d5362bb284cb9b94 upstream.
Port link change with port in resume state should not be
reported to usbcore, as this is an internal state to be
handled by xhci driver. Reporting PLC to usbcore may
cause usbcore clearing PLC first and port change event irq
won't be generated.
Signed-off-by: Zhuang Jin Can
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
drivers/usb/host/xhci-hub.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 672e0b1..50d8413 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -587,7 +587,14 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd,
status |= USB_PORT_STAT_C_RESET << 16;
/* USB3.0 only */
if (hcd->speed == HCD_USB3) {
- if ((raw_port_status & PORT_PLC))
+ /* Port link change with port in resume state should not be
+* reported to usbcore, as this is an internal state to be
+* handled by xhci driver. Reporting PLC to usbcore may
+* cause usbcore clearing PLC first and port change event
+* irq won't be generated.
+*/
+ if ((raw_port_status & PORT_PLC) &&
+ (raw_port_status & PORT_PLS_MASK) != XDEV_RESUME)
status |= USB_PORT_STAT_C_LINK_STATE << 16;
if ((raw_port_status & PORT_WRC))
status |= USB_PORT_STAT_C_BH_RESET << 16;
--
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: wake_up_process implied memory barrier clarification
On Tue, Sep 01, 2015 at 06:39:23PM +0200, Oleg Nesterov wrote:
> On 09/01, Boqun Feng wrote:
> >
> > On Tue, Sep 01, 2015 at 11:59:23AM +0200, Oleg Nesterov wrote:
> > >
> > > And just in case, wake_up() differs in a sense that it doesn't even need
> > > that STORE-LOAD barrier in try_to_wake_up(), we can rely on
> > > wait_queue_head_t->lock. Assuming that wake_up() pairs with the "normal"
> > > wait_event()-like code.
>
> Looks like, you have missed this part of my previous email. See below.
I guess I need to think through this, though I haven't found any problem
in wake_up() if we remove the STORE-LOAD barrier in try_to_wake_up().
And I know that in wake_up(), try_to_wake_up() will be called with
holding wait_queue_head_t->lock, however, only part of wait_event()
holds the same lock, I can't figure out why the barrier is not needed
because of the lock.. I will read the code carefully to see whether I
miss something.
>
> > I think maybe I have a misunderstanding of barrier pairing.
>
> Or me. I can only say how it is supposed to work.
>
> > think that a barrier pairing can only happen:
>
> Well, no. See for example https://lkml.org/lkml/2014/7/16/310
This helps a lot, so does the LWN article it references:
https://lwn.net/Articles/573436/
The barrier pairing here is scenario 10 in that article. I'm sure that
is my misunderstanding of barrier pairing now, thank you!
> Or, say, the comment in completion_done().
>
> And please do not assume I can answer authoritatively the questions
> in this area. Fortunately we have paulmck/peterz in CC, they can
> correct me.
>
Your explanation and references help a lot, now I understand how the
barrier works in try_to_wake_up() ;-)
> Plus I didn't sleep today, not sure I can understand you correctly
> and/or answer your question ;)
>
> > One example of #2 pairing is the following sequence of events:
> >
> > Initially X = 0, Y = 0
> >
> > CPU 1 CPU 2
> > ===
> > WRITE_ONCE(Y, 1);
> > smp_mb();
> > r1 = READ_ONCE(X); // r1 == 0
> > WRITE_ONCE(X, 1);
> > smp_mb();
> > r2 = READ_ONCE(Y);
> >
> >
> > { assert(!(r1 == 0 && r2 == 0)); // means if r1 == 0 then r2 == 1}
> >
> > If CPU 1 _fails_ to read the value of X written by CPU 1, r2 is
> > guaranteed to 1, which means assert(!(r1 == 0 && r2 == 0)) afterwards
> > wouldn't be triggered in any case.
> >
> > And this is actually the case of wake_up/wait, assuming that
> > prepare_to_wait() is called on CPU 1 and wake_up() is called on CPU 2,
>
> See above, wake_up/wait_event are fine in any case because they use
> the same lock.
>
I think I wanted to say wake_up_proccess() here, which calls
try_to_wake_up() directly, sorry about that mistake..
> But as for try_to_wake_up() you are right, we rely on STORE-MB-LOAD.
> Now let me quote another previous email,
>
> So in fact try_to_wake_up() needs mb() before it does
>
> if (!(p->state & state))
> goto out;
>
> But mb() is heavy, we can use wmb() instead, but only in this particular
> case: before spin_lock(), which guarantees that LOAD(p->state) can't
> leak
> out of the critical section. And since spin_lock() itself is the STORE,
> this guarantees that STORE(CONDITION) can't leak _into_ the critical
> section
> and thus it can't be reordered with LOAD(p->state).
>
This also helps a lot, thank you ;-)
> And I think that smp_mb__before_spinlock() + spin_lock() should pair
> correctly with mb(). If not - we should redefine it.
>
> > X is the condition and Y is the task state,
>
> Yes,
>
> > and replace smp_mb() with really necessary barriers, right?
>
> Sorry, can't understand this part...
>
I just want to be accurate by saying that, because the barrier in
try_to_wake_up() is not a smp_mb(), is a smp_mb__before_spinlock() +
spin_lock().
Regards,
Boqun
signature.asc
Description: PGP signature
[PATCH 3.13.y-ckt 11/60] drm: Stop resetting connector state to unknown
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Daniel Vetter
commit 5677d67ae3949f09f57357241b88222d49b8c782 upstream.
It's causing piles of issues since we've stopped forcing full detect
cycles in the sysfs interfaces with
commit c484f02d0f02fbbfc6decc945a69aae011041a27
Author: Chris Wilson
Date: Fri Mar 6 12:36:42 2015 +
drm: Lighten sysfs connector 'status'
The original justification for this was that the hpd handlers could
use the unknown state as a hint to force a full detection. But current
i915 code isn't doing that any more, and no one else really uses reset
on resume. So instead just keep the old state around.
References:
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641
Cc: Rui Matos
Cc: Julien Wajsberg
Cc: kuddel.m...@gmx.de
Cc: Lennart Poettering
Acked-by: Rob Clark
Tested-by: Rui Tiago Cação Matos
Signed-off-by: Daniel Vetter
Signed-off-by: Kamal Mostafa
---
drivers/gpu/drm/drm_crtc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 944ff1e..87591bb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3730,12 +3730,9 @@ void drm_mode_config_reset(struct drm_device *dev)
if (encoder->funcs->reset)
encoder->funcs->reset(encoder);
- list_for_each_entry(connector, >mode_config.connector_list, head) {
- connector->status = connector_status_unknown;
-
+ list_for_each_entry(connector, >mode_config.connector_list, head)
if (connector->funcs->reset)
connector->funcs->reset(connector);
- }
}
EXPORT_SYMBOL(drm_mode_config_reset);
--
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 3.13.y-ckt 18/60] USB: OHCI: Fix race between ED unlink and URB submission
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Alan Stern
commit 7d8021c967648accd1b78e5e1ddaad655cd2c61f upstream.
This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
don't lose track of EDs when a controller dies"). The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called. The user-visible consequence is that the driver
occasionally crashes or locks up when an URB is submitted while
another URB for the same endpoint is being unlinked.
This patch moves the ED state change later, to the right place. The
drawback is that now we may unnecessarily execute some instructions
multiple times when a controller dies. Since controllers dying is an
exceptional occurrence, a little wasted time won't matter.
Signed-off-by: Alan Stern
Reported-by: Heiko Przybyl
Tested-by: Heiko Przybyl
Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e
Signed-off-by: Greg Kroah-Hartman
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
drivers/usb/host/ohci-q.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-q.c b/drivers/usb/host/ohci-q.c
index 4e9f6a4..810bfb1 100644
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -929,10 +929,6 @@ rescan_all:
int completed, modified;
__hc32 *prev;
- /* Is this ED already invisible to the hardware? */
- if (ed->state == ED_IDLE)
- goto ed_idle;
-
/* only take off EDs that the HC isn't using, accounting for
* frame counter wraps and EDs with partially retired TDs
*/
@@ -963,14 +959,12 @@ skip_ed:
}
/* ED's now officially unlinked, hc doesn't see */
- ed->state = ED_IDLE;
if (quirk_zfmicro(ohci) && ed->type == PIPE_INTERRUPT)
ohci->eds_scheduled--;
ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
ed->hwNextED = 0;
wmb();
ed->hwINFO &= ~cpu_to_hc32(ohci, ED_SKIP | ED_DEQUEUE);
-ed_idle:
/* reentrancy: if we drop the schedule lock, someone might
* have modified this list. normally it's just prepending
@@ -1041,6 +1035,7 @@ rescan_this:
if (list_empty(>td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
+ ed->state = ED_IDLE;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
--
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 3.13.y-ckt 21/60] tile: use free_bootmem_late() for initrd
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Chris Metcalf
commit 3f81d2447b37ac697b3c600039f2c6b628c06e21 upstream.
We were previously using free_bootmem() and just getting lucky
that nothing too bad happened.
Signed-off-by: Chris Metcalf
Signed-off-by: Kamal Mostafa
---
arch/tile/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/tile/kernel/setup.c b/arch/tile/kernel/setup.c
index 74c9172..bdb3ecf 100644
--- a/arch/tile/kernel/setup.c
+++ b/arch/tile/kernel/setup.c
@@ -1146,7 +1146,7 @@ static void __init load_hv_initrd(void)
void __init free_initrd_mem(unsigned long begin, unsigned long end)
{
- free_bootmem(__pa(begin), end - begin);
+ free_bootmem_late(__pa(begin), end - begin);
}
static int __init setup_initrd(char *str)
--
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 3.13.y-ckt 24/60] mmc: omap_hsmmc: Fix DTO and DCRC handling
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Kishon Vijay Abraham I
commit 408806f740497c5d71f9c305b3d6aad260ff186d upstream.
DTO/DCRC errors were not being informed to the mmc core since
commit ae4bf788ee9b ("mmc: omap_hsmmc: consolidate error report handling of
HSMMC IRQ"). This commit made sure 'end_trans' is never set on DTO/DCRC
errors. This is because after this commit 'host->data' is checked after
it has been cleared to NULL by omap_hsmmc_dma_cleanup().
Because 'end_trans' is never set, omap_hsmmc_xfer_done() is never invoked
making core layer not to be aware of DTO/DCRC errors. Because of this
any command invoked after DTO/DCRC error leads to a hang.
Fix this by checking for 'host->data' before it is actually cleared.
Fixes: ae4bf788ee9b ("mmc: omap_hsmmc: consolidate error report handling of
HSMMC IRQ")
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Vignesh R
Tested-by: Andreas Fenkart
Signed-off-by: Ulf Hansson
Signed-off-by: Kamal Mostafa
---
drivers/mmc/host/omap_hsmmc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..99bd1d1 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1024,15 +1024,15 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
if (status & (CTO_EN | CCRC_EN))
end_cmd = 1;
+ if (host->data || host->response_busy) {
+ end_trans = !end_cmd;
+ host->response_busy = 0;
+ }
if (status & (CTO_EN | DTO_EN))
hsmmc_command_incomplete(host, -ETIMEDOUT, end_cmd);
else if (status & (CCRC_EN | DCRC_EN))
hsmmc_command_incomplete(host, -EILSEQ, end_cmd);
- if (host->data || host->response_busy) {
- end_trans = !end_cmd;
- host->response_busy = 0;
- }
}
OMAP_HSMMC_WRITE(host->base, STAT, status);
--
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 3.13.y-ckt 20/60] blkcg: fix gendisk reference leak in blkg_conf_prep()
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: Tejun Heo
commit 5f6c2d2b7dbb541c1e922538c49fa04c494ae3d7 upstream.
When a blkcg configuration is targeted to a partition rather than a
whole device, blkg_conf_prep fails with -EINVAL; unfortunately, it
forgets to put the gendisk ref in that case. Fix it.
Signed-off-by: Tejun Heo
Signed-off-by: Jens Axboe
Signed-off-by: Kamal Mostafa
---
block/blk-cgroup.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index d8f80e7..a717585 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -703,8 +703,12 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct
blkcg_policy *pol,
return -EINVAL;
disk = get_gendisk(MKDEV(major, minor), );
- if (!disk || part)
+ if (!disk)
return -EINVAL;
+ if (part) {
+ put_disk(disk);
+ return -EINVAL;
+ }
rcu_read_lock();
spin_lock_irq(disk->queue->queue_lock);
--
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 3.13.y-ckt 22/60] Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let me know. -- From: Bernhard Bender commit 968491709e5b1aaf429428814fff3d932fa90b60 upstream. This patch fixes a problem in the usbtouchscreen driver for DMC TSC-30 touch screen. Due to a missing delay between the RESET and SET_RATE commands, the touch screen may become unresponsive during system startup or driver loading. According to the DMC documentation, a delay is needed after the RESET command to allow the chip to complete its internal initialization. As this delay is not guaranteed, we had a system where the touch screen occasionally did not send any touch data. There was no other indication of the problem. The patch fixes the problem by adding a 150ms delay between the RESET and SET_RATE commands. Suggested-by: Jakob Mustafa Signed-off-by: Bernhard Bender Signed-off-by: Dmitry Torokhov Signed-off-by: Kamal Mostafa --- drivers/input/touchscreen/usbtouchscreen.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c index 5f87bed..20aef5d 100644 --- a/drivers/input/touchscreen/usbtouchscreen.c +++ b/drivers/input/touchscreen/usbtouchscreen.c @@ -626,6 +626,9 @@ static int dmc_tsc10_init(struct usbtouch_usb *usbtouch) goto err_out; } + /* TSC-25 data sheet specifies a delay after the RESET command */ + msleep(150); + /* set coordinate output rate */ buf[0] = buf[1] = 0xFF; ret = usb_control_msg(dev, usb_rcvctrlpipe (dev, 0), -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 23/60] md/raid1: fix test for 'was read error from last working device'.
3.13.11-ckt26 -stable review patch. If anyone has any objections, please let
me know.
--
From: NeilBrown
commit 34cab6f42003cb06f48f86a86652984dec338ae9 upstream.
When we get a read error from the last working device, we don't
try to repair it, and don't fail the device. We simple report a
read error to the caller.
However the current test for 'is this the last working device' is
wrong.
When there is only one fully working device, it assumes that a
non-faulty device is that device. However a spare which is rebuilding
would be non-faulty but so not the only working device.
So change the test from "!Faulty" to "In_sync". If ->degraded says
there is only one fully working device and this device is in_sync,
this must be the one.
This bug has existed since we allowed read_balance to read from
a recovering spare in v3.0
Reported-and-tested-by: Alexander Lyakas
Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
Signed-off-by: NeilBrown
Signed-off-by: Kamal Mostafa
---
drivers/md/raid1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 53457ee..d08e98e 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -337,7 +337,7 @@ static void raid1_end_read_request(struct bio *bio, int
error)
spin_lock_irqsave(>device_lock, flags);
if (r1_bio->mddev->degraded == conf->raid_disks ||
(r1_bio->mddev->degraded == conf->raid_disks-1 &&
-!test_bit(Faulty, >mirrors[mirror].rdev->flags)))
+test_bit(In_sync, >mirrors[mirror].rdev->flags)))
uptodate = 1;
spin_unlock_irqrestore(>device_lock, flags);
}
--
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/
