It's safe to call regulator_unregister() with NULL, thus remove the NULL test
before regulator_unregister() calls.
Signed-off-by: Axel Lin
Cc: Robert Jarzmik
Cc: Haojian Zhuang
Cc: Wolfram Sang
Cc: Sangbeom Kim
Cc: Cyril Chemparathy
---
drivers/regulator/max1586.c|3 +--
On 04/27/2013 04:24 AM, shawn wilson wrote:
> On Fri, Apr 26, 2013 at 8:22 PM, Junio C Hamano wrote:
>
>> * There was no good way to ask "I have a random string that came from
>>outside world. I want to turn it into a 40-hex object name while
>>making sure such an object exists". A new
>
>
> I did vary HZ from 300 to 1000 HZ, I tried the 3 three different
> preemption models.
>
> With all these combinations, I still have the problem.
>
Actually, I may have observed more failure with 1000 HZ and
CONFIG_PREEMPT=y (low-latency desktop)
Also make sure that High resolution
I would like to add support to this driver for platform devices as found
on VIA's APC8750 board. At the moment, I have a standalone platform
version that works fine, but wanted to ask a few questions before
sending a patch to merge this code into one driver.
The current driver is for PCI
They are the base values in load balance, update them with rq runnable
load average, then the load balance will consider runnable load avg
naturally.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 4 ++--
kernel/sched/fair.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff
To get the latest runnable info, we need do this cpuload update after
task_tick.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e0c003a..0fedeed 100644
--- a/kernel/sched/core.c
Except using runnable load average in background, move_tasks is also
the key functions in load balance. We need consider the runnable load
average in it in order to the apple to apple load comparison.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 11 ++-
1 file changed, 10
effective_load calculates the load change as seen from the
root_task_group. It needs to engage the runnable average
of changed task.
Thanks for Morten Rasmussen's reminder of this.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 27 ---
1 file changed, 20
We need initialize the se.avg.{decay_count, load_avg_contrib} for a
new forked task.
Otherwise random values of above variables cause mess when do new task
enqueue:
enqueue_task_fair
enqueue_entity
enqueue_entity_load_avg
and make forking balancing imbalance since
This patchset bases on tip/sched/core.
The patchset remove the burst wakeup detection which had worked fine on 3.8
kernel, since the aim7 is very imbalance. But rwsem write lock stealing
enabled in 3.9 kernel. aim7 imbalance disappeared. So the burst wakeup
care doesn't needed.
It was tested
Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then
we can use runnable load variables.
Signed-off-by: Alex Shi
---
include/linux/sched.h | 7 +--
kernel/sched/core.c | 7 +--
kernel/sched/fair.c | 13 ++---
kernel/sched/sched.h | 9 +
4 files
>
>
> Also other factors to consider it is are you doing the test on a very
> loaded system? What is your platform?
>
> I have tested it positively on 32 bit, 64 bits build on Atom N450
>
> i7 first and second generation system.
>
> I did vary HZ from 300 to 1000 HZ, I tried the 3 three
Hello,
Just wanted to let everyone know that CONFIG_X86_INTEL_PSTATE wreaks
havoc with the CPU frequency subsystem in the Linux kernel.
With this option enabled:
1) All governors except performance and powersave are gone, ondemand
userspace, conservative
2) scaling_cur_freq is gone, thus user
> 2) tst-cputimer1.c only have CLOCK_PROCESS_CPUTIME_ID test and
> don't have any utime, stime tests.
>
Sorry, I should take a couple minutes break before pressing send to be
sure that I have said everything :-)
CLOCK_PROCESS_CPUTIME_ID is user space name for kernel space
CPUCLOCK_SCHED clock.
On Fri, 2013-04-26 at 22:15 -0400, KOSAKI Motohiro wrote:
> On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
> wrote:
> > On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
> >> > I need to add that I can only confirm that to be true with
> >> > sum_exec_runtime.
> >> >
> >> > To affirm
Hi Suman,
>> On 26 April 2013 03:59, Suman Anna wrote:
>>> On 04/25/2013 12:20 AM, Jassi Brar wrote:
>> I never said no-buffering and I never said buffering should be in
>> controller drivers. In fact I don't remember ever objecting to how
>> buffering is done in TI's framework.
>> A controller
Add thread group delta to cpu timer sample when computing a timer expiration.
This is mandatory to make sure that the posix cpu timer does not fire too
soon relative to the process cpu clock which do include the task group delta.
test case to validate the patch is glibc-2.17/rt/tst-cputimer1.c
Forbids the cputimer to drift ahead of its process clock by
blocking its update when a tick occurs while a autoreaping task
is currently in do_exit() between the call to release_task() and
its final call to schedule().
Any task stats update after having called release_task() will
be lost
Modify CFS API to be able to fetch separately a thread group cputime and its
tasks delta. This is needed by the third part of this patch.
Note that the new function group_delta_exec() is not absolutely required as
you could get the group delta by calling the modified task_sched_runtime().
It is used to set disallowed large page on the specified level, can be
used in later patch
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/x86.c | 53 ++-
1 files changed, 35 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/x86.c
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
become worse if guest uses more memory or vcpus. It is not good for
scalability.
Now, kvm_mmu_zap_all is only called in the path of mmu_notifier->release,
at that time, vcpu has stopped that means no new page will be create, we
can use lock-break technique to avoid potential soft lockup
(Note: at this time, the mmu-lock still has contention between ->release
and other
This function is used to reset the large page info of all guest pages
which will be used in later patch
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/x86.c | 25 +
arch/x86/kvm/x86.h |2 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git
Replace kvm_mmu_zap_all by kvm_mmu_invalid_all_pages except on
the path of mmu_notifier->release() which will be fixed in
the later patch
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/x86.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c
It is the responsibility of kvm_mmu_zap_all that keeps the
consistent of mmu and tlbs. And it is also unnecessary after
zap all mmio sptes since no mmio spte exists on root shadow
page and it can not be cached into tlb
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/x86.c |5 +
1 files
This patchset is based on current 'queue' branch on kvm tree.
Changlog:
V4:
1): drop unmapping invalid rmap out of mmu-lock and use lock-break technique
instead. Thanks to Gleb's comments.
2): needn't handle invalid-gen pages specially due to page table always
switched by
Add pm_ops_ptr() macro that allows the .pm entry in the driver structures
to be assigned without having an #define xxx NULL for the case that PM is
not enabled.
Signed-off-by: Jingoo Han
---
include/linux/pm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
From: Wei WANG
To fix the compile error when CONFIG_PM_RUNTIME is not enabled,
move the declaration of us out of CONFIG_REALTEK_AUTOPM macro in rts51x_chip.
drivers/usb/storage/realtek_cr.c: In function 'realtek_cr_destructor':
drivers/usb/storage/realtek_cr.c:942:11: error: 'struct
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
>
> OK,.. Ingo said that pipe-test was the original motivation for
> wake_affine() and since that's currently broken to pieces due to
> select_idle_sibling() is there still a benefit to having it at all?
>
> Can anybody find any significant
On Fri, Apr 26, 2013 at 09:53:56PM -0400, Rik van Riel wrote:
> On 04/26/2013 07:44 PM, Pierre-Loup A. Griffais wrote:
> >I initially observed this between kernels 3.2 and 3.5: on 3.2, copying a
> >180M shared object on the same ext4 filesystem takes 0.6s. On 3.5, it
> >takes between two and three
On Fri, Apr 26, 2013 at 8:22 PM, Junio C Hamano wrote:
> * There was no good way to ask "I have a random string that came from
>outside world. I want to turn it into a 40-hex object name while
>making sure such an object exists". A new peeling suffix ^{object}
>can be used for that
This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction
in x86 JIT.
Signed-off-by: Xi Wang
Cc: Daniel Borkmann
Cc: Heiko Carstens
Cc: Will Drewry
Cc: Eric Dumazet
Cc: Russell King
Cc: David Laight
Cc: "David S. Miller"
Cc: Andrew Morton
Cc: Nicolas Schichan
---
This patch implements the seccomp BPF_S_ANC_SECCOMP_LD_W instruction
in ARM JIT.
Signed-off-by: Xi Wang
Cc: Daniel Borkmann
Cc: Heiko Carstens
Cc: Will Drewry
Cc: Eric Dumazet
Cc: Russell King
Cc: David Laight
Cc: "David S. Miller"
Cc: Andrew Morton
Cc: Nicolas Schichan
---
Currently, bpf_jit_compile() and bpf_jit_free() take an sk_filter,
which seccomp filters cannot reuse.
Change bpf_jit_compile() to take a pointer to BPF instructions and
an instruction length, and to return a JITted function.
Change bpf_jit_free() to take a JITted function.
Add JIT calls for
The first patch refactors bpf_jit_compile()/bpf_jit_free() to provide
a unified interface for both packet and seccomp filters.
The next two patches implement JIT for seccomp filters on x86 and ARM,
respectively.
Thanks to Heiko Carstens for testing the build on s390 and Eric Dumazet
for the
On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
wrote:
> On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
>> > I need to add that I can only confirm that to be true with
>> > sum_exec_runtime.
>> >
>> > To affirm it to be true for stime and utime would require more
>> > investigation.
It has been reported that there is a new version (different USB rev)
of the Logitech DFGT in the 'wild'.
This patch allows the kernel to recognise this wheel and send it the
command to enter native mode.
Reported-by: "Denis Jovic"
Signed-off-by: Simon Wood
---
drivers/hid/hid-lg4ff.c | 2 ++
On 2013/4/27 9:57, Yinghai Lu wrote:
> On Fri, Apr 26, 2013 at 6:51 PM, Yijing Wang wrote:
>> I think it's cool! Now we enable bridge in various places, this is a
>> headache.
>>
>> hi, yinghai, in this patch, enable bridges depend on the driver call
>> pci_enable_device() explicitly.
>> I was
On Fri, Apr 26, 2013 at 6:51 PM, Yijing Wang wrote:
> I think it's cool! Now we enable bridge in various places, this is a headache.
>
> hi, yinghai, in this patch, enable bridges depend on the driver call
> pci_enable_device() explicitly.
> I was a little worried If there has some devices don't
On 04/26/2013 07:44 PM, Pierre-Loup A. Griffais wrote:
I initially observed this between kernels 3.2 and 3.5: on 3.2, copying a
180M shared object on the same ext4 filesystem takes 0.6s. On 3.5, it
takes between two and three minutes. It looks like a similar throughput
regression happens on any
I think it's cool! Now we enable bridge in various places, this is a headache.
hi, yinghai, in this patch, enable bridges depend on the driver call
pci_enable_device() explicitly.
I was a little worried If there has some devices don't have some drivers bound,
but used by system.
like ioapic,
On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
> > I need to add that I can only confirm that to be true with
> > sum_exec_runtime.
> >
> > To affirm it to be true for stime and utime would require more
> > investigation. I didn't look them at all. I was only concerned with
> >
On 27/04/13 09:04, the mail apparently from Suman Anna included:
Hi Suman -
Even though both the scenarios look very similar, I believe there are
some slight differences. All the devices belonging to a controller may
not be of the same type (meaning, intended towards the same remote or be
used
Hi Linus,
On Friday 26 April 2013 10:49:12 Linus Walleij wrote:
> On Fri, Apr 26, 2013 at 1:15 AM, Laurent Pinchart wrote:
> > On Thursday 25 April 2013 23:39:18 Linus Walleij wrote:
> >> On Tue, Apr 23, 2013 at 3:33 PM, Laurent Pinchart wrote:
> >> > Could you clarify the exact scope of the two
Hi Jassi,
On 04/25/2013 10:46 PM, Jassi Brar wrote:
> Hi Suman,
>
> On 26 April 2013 03:59, Suman Anna wrote:
>> On 04/25/2013 12:20 AM, Jassi Brar wrote:
>> tranmitting right away. OK, I thought you didn't want buffering, if that
>> is not the case, then the buffering should be within the main
Current we enable bridges after bus scan and assign resources.
and it is spreaded a lot of places.
We can move it to where pci device is enabled, and need
to go up to root bus and enable bridge one by one down to pci
dev.
So that will delay enable bridge late as needed bassis,
also kill one
On Sat, Apr 27, 2013 at 11:00 AM, Dave Airlie wrote:
> On Sat, Apr 27, 2013 at 10:37 AM, Andy Lutomirski wrote:
>> On Wed, Apr 24, 2013 at 12:33 PM, Andy Lutomirski
>> wrote:
>>> For an upcoming (and, sadly, NDA'd [1]) project, I may need to use
>>> write-through memory. I'd like to gauge how
On Sat, Apr 27, 2013 at 10:37 AM, Andy Lutomirski wrote:
> On Wed, Apr 24, 2013 at 12:33 PM, Andy Lutomirski wrote:
>> For an upcoming (and, sadly, NDA'd [1]) project, I may need to use
>> write-through memory. I'd like to gauge how unpleasant this will be.
>>
>> AFAICT, modern CPUs allow the
On Wed, Apr 24, 2013 at 12:33 PM, Andy Lutomirski wrote:
> For an upcoming (and, sadly, NDA'd [1]) project, I may need to use
> write-through memory. I'd like to gauge how unpleasant this will be.
>
> AFAICT, modern CPUs allow the WT type to be set using MTRR or a PAT
> entry. Sadly, MTRRs are
A release candidate preview Git v1.8.3-rc0 is now available for
testing at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
f0b0b415f0c693865895c1918859b12c4a7d5b17 git-1.8.3.rc0.tar.gz
On Fri, Apr 26, 2013 at 5:08 PM, Randy Dunlap wrote:
> On 04/26/13 16:39, Olof Johansson wrote:
>> This is primarily useful when there's a driver that doesn't claim clocks
>> properly, but the bootloader does. It's not expected to be used in normal
>> cases, but for bringup and debug it's very
The latest maintenance release Git v1.8.2.2 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
47a86a0a4f92998f21ada77be146676ecfd2e4af git-1.8.2.2.tar.gz
On Wed, Apr 17, 2013 at 04:26:18PM -0700, Stephen Boyd wrote:
> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
> architected timers causes a slew of "using smp_processor_id() in
> preemptible" warnings:
>
> BUG: using smp_processor_id() in preemptible [] code: sh/111
>
On 04/27/2013 12:51 AM, Alan Stern wrote:
On Fri, 26 Apr 2013, ZhenHua wrote:
There is a function wait_for_HP() in uhci-hub.c. In this
patch, it is used in suspend_rh(), I think this can be a
solution. And I have tested this patch, it can fix the bug.
I think there is another patch needed.
On Sat, Apr 20, 2013 at 03:19:43PM +0200, Linus Walleij wrote:
> ARM SoC folks:
>
> On Sat, Apr 20, 2013 at 3:08 PM, Linus Walleij
> wrote:
>
> > The Nomadik clocksource driver has had a bad define making it
> > impossible to use it for sched_clock() for a while. Fix this
> > and also enable
On 04/26/13 16:39, Olof Johansson wrote:
> This is primarily useful when there's a driver that doesn't claim clocks
> properly, but the bootloader does. It's not expected to be used in normal
> cases, but for bringup and debug it's very useful to have the option to
> not gate unclaimed clocks that
I initially observed this between kernels 3.2 and 3.5: on 3.2, copying a
180M shared object on the same ext4 filesystem takes 0.6s. On 3.5, it
takes between two and three minutes. It looks like a similar throughput
regression happens on any machine running an i386 PAE kernel with high
amounts
This is primarily useful when there's a driver that doesn't claim clocks
properly, but the bootloader does. It's not expected to be used in normal
cases, but for bringup and debug it's very useful to have the option to
not gate unclaimed clocks that are still on.
Signed-off-by: Olof Johansson
Please stop top-posting.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sat, Apr 27, 2013 at 12:04 AM, Tejun Heo wrote:
> On Fri, Apr 26, 2013 at 11:07:44PM +0200, Sedat Dilek wrote:
>> > The second argument %rsi is zero, which got transferred to %r13 and
>> > then offset deref on it trapped.
>> >
>> > The second argument is @wq and the oopsing code is the
Hello. I am creating a DTS file for an ARM (Qualcomm MSM) target which
supports LPAE, meaning that the target is capable of addressing memory
beyond the standard 4GB boundary. To account for the fact that the
memory node can contain reg addresses that exceed 32 bits, I am setting
Regards to all:
I have been playing heavily with NTP recently and have encountered several
problems which prevent its complete usage. I am not sure at this time
whether this latest problem (which appears to have security implications) is
in the kernel or coming from user space via ntpd.
Please
2013/4/26 Frederic Weisbecker :
> On Fri, Apr 26, 2013 at 08:39:56AM -0700, Paul E. McKenney wrote:
>> > config VIRT_CPU_ACCOUNTING_GEN
>> > bool "Full dynticks CPU time accounting"
>> > - depends on HAVE_CONTEXT_TRACKING && 64BIT
>> > + depends on HAVE_CONTEXT_TRACKING && 64BIT &&
On Fri, 2013-04-26 at 17:46 -0400, Peter Klausler wrote:
> Tune flow table lookup in net/openvswitch, replacing a call to
> the slow-but-safe memcmp() in lib/string.c with a key comparator
> routine that presumes most comparisons will succeed. Besides
> avoiding an early-exit test on each
On Wed, 24 Apr 2013 10:31:57 -0400 Alexandre Bounine
wrote:
> Rework to implement RapidIO enumeration/discovery method selection
> combined with ability to use enumeration/discovery as a kernel module.
>
> This patch adds ability to introduce new RapidIO enumeration/discovery methods
> using
> How well was this
> patch-set tested on non-Haswell hardware, which makes up 99.99% of our
> installed base?
I tested on a couple systems now and then: usually Haswell, IvyBridge,
sometimes also Westmere and Atom. I don't retest every iteration,
as you know most of the changes you're
On 04/25, Thomas Gleixner wrote:
> Provide a simple sysfs interface for the clockevent devices. Show the
> current active clockevent device.
>
Neat. Does this do anything about clockevents that aren't in use
for the tick devices or broadcast device?
> Index: tip/kernel/time/clockevents.c
>
On Wed, Mar 27, 2013 at 3:46 PM, Bjorn Helgaas wrote:
> On Wed, Mar 27, 2013 at 3:18 PM, Joseph A. Millikan
> wrote:
>>
>> We use Mint 11 32-bit and we've noticed with any kernel beyond 3.6.11, the
>> Ethernet port stops responding to pings after 15 minutes and samba clients
>> cease to receive
On 04/27/2013 12:18 AM, Xi Wang wrote:
Thanks for CCing. One way to clean up this would be to refactor the
bpf jit interface as:
bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen);
void bpf_jit_free(bpf_func_t bpf_func);
Then both packet and seccomp filters can
[+cc Dave]
I don't maintain this file, regardless of what scripts/get_maintainer.pl says :)
On Fri, Apr 26, 2013 at 4:08 PM, Seoras Macdonald wrote:
> Fixed some warnings generated by checkpatch and
> adjusted some comment blocks to match the coding style.
>
> Signed-off-by: Seoras Macdonald
>
Dear RT Folks,
I'm pleased to announce the 3.8.9-rt4 release.
changes since v3.8.9-rt4:
- the quilt queue can be imported into git without hiccup
- a giant/ huge/ big pile of cpsw patches has been added. If you have an
ARM AM33xx (beagle bone for instance) then your network should work.
I
Thanks for CCing. One way to clean up this would be to refactor the
bpf jit interface as:
bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen);
void bpf_jit_free(bpf_func_t bpf_func);
Then both packet and seccomp filters can share the unified interface.
Also, we don't
On Fri, Apr 26, 2013 at 03:15:10PM -0700, H. Peter Anvin wrote:
> That really makes it harder to figure out what the heck the register
> content may mean...
So we need a goddam script to massage oopses now, if kaslr is enabled.
:-(
--
Regards/Gruss,
Boris.
Sent from a fat crate under my
From: "Yann E. MORIN"
This reverts commit 422c809f03f043d0950d8362214818e956a9daee.
It causes more harm than it solves issues.
Reported-by: Sedat Dilek
Reported-by: Arnd Bergmann
Signed-off-by: "Yann E. MORIN"
Tested-by: Sedat Dilek
Cc: Sedat Dilek
Cc: Arnd Bergmann
Cc: Michal Marek
Cc:
From: "Yann E. MORIN"
Michal,
Please pull this to revert:
422c809: fix randomising choice entries in presence of KCONFIG_ALLCONFIG
It causes more harm that it fixes issues, and I couldn't find a proper
fix for now. To avoid breakage so close to the opening of the merge
window, it makes
On Fri, Apr 26, 2013 at 03:03:07PM -0700, Kevin Hilman wrote:
> Hi Greg,
>
> Sourav Poddar writes:
>
> > Move "uart_console" definition to serial core header file, so that it can be
> > used by serial drivers.
> > Get rid of the uart_console defintion from mpc52xx_uart driver.
> >
> > Cc:
On 04/26/2013 03:13 PM, Borislav Petkov wrote:
> On Fri, Apr 26, 2013 at 12:03:25PM -0700, Kees Cook wrote:
>> When the system panics, include the kernel offset in the report to assist
>> in debugging.
>>
>> Signed-off-by: Kees Cook
>> ---
>> arch/x86/kernel/setup.c | 24
On 04/26/2013 02:47 PM, H. Peter Anvin wrote:
> On 04/26/2013 12:03 PM, Kees Cook wrote:
>> +
>> +static inline void cpuid(u32 id, u32 *a, u32 *b, u32 *c, u32 *d)
>> +{
>> +/* Handle x86_32 PIC using ebx. */
>> +asm volatile("movl %%ebx, %%edi \n\t"
>> + "cpuid
On Fri, 26 Apr 2013, Greg Kroah-Hartman wrote:
> > It's your subsystem, if you want to release a kernel with a known-broken
> > config, that's your call.
>
> As you point out, it's been "known broken" since 3.7, no rush now to fix
> it, especially so late in the merge window. :)
>
It's "known
On Fri, Apr 26, 2013 at 12:03:25PM -0700, Kees Cook wrote:
> When the system panics, include the kernel offset in the report to assist
> in debugging.
>
> Signed-off-by: Kees Cook
> ---
> arch/x86/kernel/setup.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git
Fixed some warnings generated by checkpatch and
adjusted some comment blocks to match the coding style.
Signed-off-by: Seoras Macdonald
---
drivers/gpu/vga/vgaarb.c | 67 +++---
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git
On Fri, Apr 26, 2013 at 02:05:37PM +0200, Arnd Bergmann wrote:
> On Thursday 25 April 2013 00:29:53 Yann E. MORIN wrote:
> > From: "Yann E. MORIN"
> >
> > Currently, randconfig does randomise choice entries, unless
> > KCONFIG_ALLCONFIG
> > is specified.
> >
> > For example, given those two
On Fri, Apr 26, 2013 at 11:07:44PM +0200, Sedat Dilek wrote:
> > The second argument %rsi is zero, which got transferred to %r13 and
> > then offset deref on it trapped.
> >
> > The second argument is @wq and the oopsing code is the wq->flags deref
> > in the following if condition.
> >
> >
On 04/26/2013 02:51 PM, Yinghai Lu wrote:
> On Fri, Apr 26, 2013 at 12:03 PM, Kees Cook wrote:
>> This chooses the largest contiguous RAM region for the KASLR offset
>> to live in.
>>
>> Signed-off-by: Kees Cook
>> ---
>> v2:
>> - make sure to exclude e820 regions outside the 32-bit memory
Michal, Sedat, All,
On Fri, Apr 26, 2013 at 01:13:33PM +0200, Michal Marek wrote:
> On 26.4.2013 13:08, Michal Marek wrote:
> > On 26.4.2013 12:49, Sedat Dilek wrote:
> >> With reverting all kbuild-next commits I was able to build again.
> >>
> >> Revert "kconfig: implement
On 04/26/2013 10:09 PM, Andrew Morton wrote:
On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann wrote:
On 04/26/2013 09:26 PM, Andrew Morton wrote:
On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann wrote:
On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
@@ -858,7 +858,7 @@
On Fri, Apr 26, 2013 at 2:51 PM, Yinghai Lu wrote:
> On Fri, Apr 26, 2013 at 12:03 PM, Kees Cook wrote:
>> This chooses the largest contiguous RAM region for the KASLR offset
>> to live in.
>>
>> Signed-off-by: Kees Cook
>> ---
>> v2:
>> - make sure to exclude e820 regions outside the 32-bit
On Fri, Apr 26, 2013 at 02:50:56PM -0700, David Rientjes wrote:
> On Fri, 26 Apr 2013, Greg Kroah-Hartman wrote:
>
> > I think you mean "3.9" in your subject: right?
> >
>
> It's your subsystem, if you want to release a kernel with a known-broken
> config, that's your call.
As you point out,
Tune flow table lookup in net/openvswitch, replacing a call to
the slow-but-safe memcmp() in lib/string.c with a key comparator
routine that presumes most comparisons will succeed. Besides
avoiding an early-exit test on each iteration, it also compares
keys 4 or 8 bytes at a time on architectures
On Fri, Apr 26, 2013 at 12:03 PM, Kees Cook wrote:
> This chooses the largest contiguous RAM region for the KASLR offset
> to live in.
>
> Signed-off-by: Kees Cook
> ---
> v2:
> - make sure to exclude e820 regions outside the 32-bit memory range.
Do you need to execlude range that is used for
On Fri, 26 Apr 2013, Greg Kroah-Hartman wrote:
> I think you mean "3.9" in your subject: right?
>
It's your subsystem, if you want to release a kernel with a known-broken
config, that's your call.
> On Fri, Apr 26, 2013 at 01:25:01PM -0700, David Rientjes wrote:
> > Fixes link error when
On 04/26/2013 12:03 PM, Kees Cook wrote:
> +
> +static unsigned long get_random_long(void)
> +{
> + if (has_cpuflag(X86_FEATURE_RDRAND)) {
> + unsigned long random;
> +
> + debug_putstr("KASLR using RDRAND...\n");
> + if (rdrand())
> +
On 04/26/2013 12:03 PM, Kees Cook wrote:
> This allows decompress_kernel to return a new location for the kernel to
> be relocated to. With CONFIG_RANDOMIZE_BASE, the choose_kernel_location
> routine will select a new location to decompress the kernel, and is
> presently a no-op. The logic for
On 04/26/2013 12:03 PM, Kees Cook wrote:
> +
> +static inline void cpuid(u32 id, u32 *a, u32 *b, u32 *c, u32 *d)
> +{
> + /* Handle x86_32 PIC using ebx. */
> + asm volatile("movl %%ebx, %%edi \n\t"
> + "cpuid \n\t"
> + "xchgl %%edi, %%ebx\n\t"
It seems we made a mistake when creating dw_apb_timer_of.c:
picoxcell sched_clock had parts that were not related to
dw_apb_timer, yet we moved them to dw_apb_timer_of, and tried to
use them on socfpga.
This results in system where user/system time is not measured
properly, as demonstrated by
Hi!
> On Fri, Apr 26, 2013 at 02:14:34PM +0200, Pavel Machek wrote:
> > diff --git a/arch/arm/mach-picoxcell/common.c
> > b/arch/arm/mach-picoxcell/common.c
> > index 70b441a..22759f5 100644
> > --- a/arch/arm/mach-picoxcell/common.c
> > +++ b/arch/arm/mach-picoxcell/common.c
> > @@ -84,11
On Wed, Mar 6, 2013 at 5:17 PM, Bjorn Helgaas wrote:
> On Tue, Feb 26, 2013 at 12:14 PM, Artem S. Tashkinov
> wrote:
>> Feb 27, 2013 12:47:01 AM, Bjorn Helgaas wrote:
>> On Mon, Feb 25, 2013 at 11:35 PM, Artem S. Tashkinov wrote:
Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote:
>
On Fri, Apr 26, 2013 at 8:22 PM, Tejun Heo wrote:
> On Fri, Apr 26, 2013 at 07:40:20PM +0200, Sedat Dilek wrote:
>> Oops, NULL-pointer-deref [ __queue_work() ]
>>
>> [ 25.974932] BUG: unable to handle kernel NULL pointer dereference
>> at 0100
>> [ 25.974944] IP: []
On Fri, Apr 26, 2013 at 1:53 PM, Bjorn Helgaas wrote:
>
> You can't be serious. This is a disgusting mess. Checking a list
> pointer for LIST_POISON1? As far as I'm concerned, this is a waste of
> my time.
Well, then need to hold the bus ref, and check bus->devices list instead.
On Fri, Apr 26, 2013 at 01:24:38PM -0700, Andrew Morton wrote:
> > As far as I can tell the only real improvement would be to add a %p
> > format string to vsnprintf, but adding a global extension would obviously be
> > inappropriate for this. It'd be really nice to have a mechanism for
> > adding
1 - 100 of 1144 matches
Mail list logo
