On 16 September 2016 at 07:40, Laura Abbott wrote:
> On 09/15/2016 08:57 AM, Arnd Bergmann wrote:
>>
>> The newly added Hi6220 Ion code fails to build when the ION_OF helpers
>> are not present:
>>
>> drivers/staging/android/ion/hisilicon/hi6220_ion.o: In function
>> `hi6220_ion_remove':
>> hi6220
On 15-09-16, 17:38, Arnd Bergmann wrote:
> When CONFIG_OPTIMIZE_INLINING is set and we are building with
> -Wmaybe-uninitialized
> enabled, we can get a warning for the opp core driver:
>
> drivers/base/power/opp/core.c: In function 'dev_pm_opp_set_rate':
> drivers/base/power/opp/core.c:560:8: wa
On Thu, 2016-09-15 at 19:47 -0500, Eric W. Biederman wrote:
> Ian Kent writes:
>
> > On Wed, 2016-09-14 at 21:08 -0500, Eric W. Biederman wrote:
> > > Ian Kent writes:
> > >
> > > > On Wed, 2016-09-14 at 12:28 -0500, Eric W. Biederman wrote:
> > > > > Ian Kent writes:
> > > > >
> > > > > > If
js1...@gmail.com writes:
> From: Joonsoo Kim
>
> Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that
> important to reserve. When ZONE_MOVABLE is used, this problem would
> theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE
> allocation request which is m
le-card drivers.")
I have used the slave-dma tree from next-20160915 for today.
--
Cheers,
Stephen Rothwell
FYI, we noticed the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit ced89591817caae5d5e1c0c1e76a7f809d004f57 ("fsnotify: convert
notification_mutex to a spinlock")
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+
These can fit in a single line (80 columns), don't split lines
unnecessarily.
Signed-off-by: Viresh Kumar
---
V1->V2: New patch
---
drivers/mfd/wm8994-core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c
index 7ee
The order in which resources were freed in wm8994_device_exit() isn't
correct. The regulators are removed before they are disabled.
Fix it by reordering code a bit, which makes it exact opposite of
wm8994_device_init() as well.
Signed-off-by: Viresh Kumar
Acked-by: Charles Keepax
---
V1->V2:
-
The kernel WARNs and then crashes today if wm8994_device_init() fails
after calling devm_regulator_bulk_get().
That happens because there are multiple devices involved here and the
order in which managed resources are freed isn't correct.
The regulators are added as children of wm8994->dev. Wher
On Thu, Sep 15, 2016 at 7:04 PM, Dan Williams wrote:
> On Thu, Sep 15, 2016 at 6:24 PM, Dave Chinner wrote:
>> On Thu, Sep 15, 2016 at 05:16:42PM -0700, Dan Williams wrote:
>>> On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner wrote:
>>> > On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Williams wrote
kbuild test robot writes:
> url:
> https://github.com/0day-ci/linux/commits/Colin-King/mwifiex-fix-null-pointer-deference-when-adapter-is-null/20160915-231625
> base:
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
> master
> config:
On 09/15/2016 07:14 PM, Stephen Rothwell wrote:
Hi Jens,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/block/nbd.c:884:2: error: unknown field 'map_queue' specified in
initializer
.map_queue = blk_mq_map_queue,
^
/home/sfr/next/n
Hi Greg,
On Thursday 15 September 2016 07:31 PM, Greg KH wrote:
> On Thu, Sep 15, 2016 at 06:26:18PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Greg,
>>
>> Please find the updated PHY pull request for 4.9 based on usb-next. This
>> now fixes the merge conflicts caused because of extcon branch merg
Hi Jason,
Welcome back to mainline development.
I've been looking forward to your comments.
On Thu, Sep 15, 2016 at 08:04:57AM -0500, Jason Wessel wrote:
> On 04/20/2015 08:13 PM, AKASHI Takahiro wrote:
> >Jason,
> >
> >Could you please review my patch below?
> >See also arm64 maintainer's commen
Hi all,
Changes since 20160915:
New tree: kgdb
The kbuild tree still had its build failure and warnings for PowerPC,
for which I applied a couple of patches
The drm-intel tree gained a conflict against Linus' tree.
The drm-msm tree gained a conflict against Linus' tree.
The block t
>> Does this wish influence the handling of suggested changes for the source
>> file "drivers/clk/renesas/clk-mstp.c" anyhow?
>> https://patchwork.kernel.org/patch/9332363/
>
> Yes, please submit a new version of this patch that removes all the memory
> allocation error messages from drivers/clk/
Hi all-
Here's v3 of the APST patch set. The biggest bikesheddable thing (I
think) is the scaling factor. I currently have it hardcoded so that
we wait 50x the total latency before entering a power saving state.
On my Samsung 950, this means we enter state 3 (70mW, 0.5ms entry
latency, 5ms exit
As far as I can tell, there is basically nothing correct about this
code. It misinterprets npss (off-by-one). It hardcodes a bunch of
power states, which is nonsense, because they're all just indices
into a table that software needs to parse. It completely ignores
the distinction between operati
Any user I can imagine that needs a buffer at all will want to pass
a pointer directly. There are no currently callers that use
buffers, so this change is painless, and it will make it much easier
to start using features that use buffers (e.g. APST).
Signed-off-by: Andy Lutomirski
---
drivers/n
NVMe devices can advertise multiple power states. These states can
be either "operational" (the device is fully functional but possibly
slow) or "non-operational" (the device is asleep until woken up).
Some devices can automatically enter a non-operational state when
idle for a specified amount of
Jonathan
On Monday 22 August 2016 12:35 AM, Jonathan Cameron wrote:
> On 11/08/16 07:01, Mugunthan V N wrote:
>> > Current make doesn't have support to pass kernel built directory
>> > to find events.h kernel header file, so adding support for
>> > KBUILD_OUTPUT support to Makefile.
>> >
>> > $ m
On Thu, Sep 15, 2016 at 5:07 PM, Andy Lutomirski wrote:
> On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote:
>> +int get_cpuid_mode(unsigned long adr)
>> +{
>> + unsigned int val;
>> +
>> + if (test_thread_flag(TIF_NOCPUID))
>> + val = ARCH_CPUID_SIGSEGV;
>> + else
>> * Should it usually be determined quicker if a required resource like
>> memory could be acquired before trying the next allocation?
>
> Note that if memory allocation fails in this driver, the system won't
> boot at all.
Thanks for this information.
> So even not checking for allocation f
On Thu, Sep 15, 2016 at 07:04:27PM -0700, Dan Williams wrote:
> On Thu, Sep 15, 2016 at 6:24 PM, Dave Chinner wrote:
> > On Thu, Sep 15, 2016 at 05:16:42PM -0700, Dan Williams wrote:
> >> On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner wrote:
> >> > On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Wil
This is the last bit of the vmap stack pile. Now that thread_info
is non-magical, we can free the thread stack as soon as the task is
dead (without waiting for RCU) and then, if vmapped stacks are in
use, cache the entire stack for reuse on the same cpu.
This seems to be an overall speedup of abo
There are a few places in the kernel that access stack memory
belonging to a different task. Before we can start freeing task
stacks before the task_struct is freed, we need a way for those code
paths to pin the stack.
Signed-off-by: Andy Lutomirski
---
include/linux/sched.h | 16 ++
When I rebased my thread_info changes onto Brian's switch_to()
changes, I carefully checked that I fixed up all the code correctly,
but I missed a comment :(
Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct")
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/entry_64.S | 1 -
1 file
We currently keep every task's stack around until the task_struct
itself is freed. This means that we keep the stack allocation alive
for longer than necessary and that, under load, we free stacks in
big batches whenever RCU drops the last task reference. Neither of
these is good for reuse of cac
This will prevent a crash if get_wchan() runs after the task stack
is freed.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/process.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 0b9ed8
Specifically, pin the stack in save_stack_trace_tsk() and
show_trace_log_lvl().
This will prevent a crash if the target task dies before or while
dumping its stack once we start freeing task stacks early.
Cc: Josh Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack_32.c | 5
From: Oleg Nesterov
get_task_struct(tsk) no longer pins tsk->stack so all users of
to_live_kthread() should do try_get_task_stack/put_task_stack to protect
"struct kthread" which lives on kthread's stack.
TODO: Kill to_live_kthread(), perhaps we can even kill "struct kthread" too,
and rework kth
This will avoid a potential read-after-free if collect_syscall()
(e.g. /proc/PID/syscall) is called on an exiting task.
Reported-by: Jann Horn
Signed-off-by: Andy Lutomirski
---
lib/syscall.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/syscall.c b/li
vmalloc is a bit slow, and pounding vmalloc/vfree will eventually
force a global TLB flush.
To reduce pressure on them, if CONFIG_VMAP_STACK, cache two thread
stacks per cpu. This will let us quickly allocate a hopefully
cache-hot, TLB-hot stack under heavy forking workloads (shell script
style).
Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
for suspend timekeeping"), this driver assumes that the ARM architected
timer keeps running in suspend. This is not the case for some ARM SoCs,
depending on the HW state used for system suspend. Let's not assume that
all SoCs
Hi!
> +if (copy_from_user(&udev->user_dev, buffer,
> + sizeof(struct uleds_user_dev))) {
> +ret = -EFAULT;
> +goto out;
> +}
> +
> +if (!udev->user_dev.name[0]) {
> +ret = -EINVAL;
> +goto out;
> +
On Thu 2016-09-15 10:31:50, David Lechner wrote:
> On 09/15/2016 09:54 AM, Jacek Anaszewski wrote:
> >Hi Pavel,
> >
> >On 09/15/2016 03:08 PM, Pavel Machek wrote:
> >>Hi!
> >>
> +if (copy_from_user(&udev->user_dev, buffer,
> + sizeof(struct uleds_user_dev))) {
> +
Hi,
On Thu, Sep 15, 2016 at 10:51:42PM +0200, Pavel Machek wrote:
> > I was trying to improve GSM call quality, and hit problems in
> > v4.8-rc. Sound only worked for a while, then I tried to kill
> > cmtspeech_ofono_test, and could not, not even with -9 and could not
> > even reboot.
> >
> > I w
On 2016-09-15 18:52:26 [+0200], To Thomas Gleixner wrote:
> The delta patch against 4.6.7-rt12 is appended below and can be found here:
diff --git a/arch/x86/include/asm/preempt.h b/arch/x86/include/asm/preempt.h
index 190af4271b5c..58fd4ff3f53a 100644
--- a/arch/x86/include/asm/preempt.h
+++ b/ar
On Fri, 16 Sep 2016 08:33:50 +1000
Dave Chinner wrote:
> On Thu, Sep 15, 2016 at 09:42:22PM +1000, Nicholas Piggin wrote:
> > On Thu, 15 Sep 2016 20:32:10 +1000
> > Dave Chinner wrote:
> > >
> > > You still haven't described anything about what a per-block flag
> > > design is supposed to loo
From: David Howells
Date: Tue, 13 Sep 2016 23:20:56 +0100
>
> Here's a set of miscellaneous fix patches. There are a couple of points of
> note:
>
> (1) There is one non-fix patch that adjusts the call ref tracking
> tracepoint to make kernel API-held refs on calls more obvious. This
>
From: David Howells
Date: Tue, 13 Sep 2016 23:41:31 +0100
>
> Here is a set of patches that add IPv6 support. They need to be applied on
> top of the just-posted miscellaneous fix patches. They are:
>
> (1) Make autobinding of an unconnected socket work when sendmsg() is
> called to ini
dd_provider_onecell(np, &pmu->genpd_data);
>>> + error = of_genpd_add_provider_onecell(np, &pmu->genpd_data);
>>> + if (error) {
>>> + dev_err(dev, "failed to add provider: %d\n", error);
>>> + goto err_out;
>>> +
Hi!
+The current brightness is found by reading a single byte from the
character
+device. Values are unsigned: 0 to 255. Reading does not block and
always returns
+the most recent brightness value. The device node can also be polled
to notify
+when the brightness value changes.
What is going on t
> "Choose label names which say what the goto does or why the goto exists."
>
> I prefer the "why" over the "what".
Does your opinion indicate also that you would appreciate another adjustment
around the quoted sentence from "Chapter 7: Centralized exiting of functions"
of the document "CodingSty
On Thu, Sep 15, 2016 at 03:45:53PM +0100, Mark Brown wrote:
> On Wed, Sep 14, 2016 at 12:09:49PM +0200, Greg KH wrote:
>
> > I'll send out a follow-up set of "simple" patches that just add the
> > files to the kernel tree, to give people an idea of the code involved.
> > Overall, it's a tiny stand
Hi Matt,
My workstation started instant rebooting with tip. I bisected it to..
efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()
..but seems it's really $subject, as box works fine with the below.
---
drivers/firmware/efi/efi.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/fi
Hi!
+static ssize_t uleds_read(struct file *file, char __user *buffer,
size_t count,
+ loff_t *ppos)
+{
+ struct uleds_device *udev = file->private_data;
+ ssize_t retval;
+
+ if (count == 0)
+ return 0;
+
+ if (count != 1)
+ return -EINVAL;
This is quite anti-social. You are free to return 1 byt
On Thu 2016-09-15 16:54:35, Jacek Anaszewski wrote:
> Hi Pavel,
>
> On 09/15/2016 03:35 PM, Pavel Machek wrote:
> >Hi!
> >
> + if (copy_from_user(&udev->user_dev, buffer,
> +sizeof(struct uleds_user_dev))) {
> + ret = -EFAULT;
> + goto out;
> >>>
On Fri, Sep 16, 2016 at 10:40:23AM +0900, Masahiro Yamada wrote:
> Remove unneeded variables and assignments.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v3:
> - Keep the wrapper function.
> Cleanup of variables and assignments only.
> - Fix intel_engine_init_common() as well
Hi Chris,
2016-09-16 15:15 GMT+09:00 Chris Wilson :
> On Fri, Sep 16, 2016 at 10:40:23AM +0900, Masahiro Yamada wrote:
>> Remove unneeded variables and assignments.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> Changes in v3:
>> - Keep the wrapper function.
>> Cleanup of variables and
Dear Friend,
Your contact details came to me by recommendation, I am interested in investing
in your country and I believe you have the capabilities of providing the needed
assistance, solutions and advise in actualizing this, Let me know if you are
willing to understake this task for me so we
This is a simple set of patches, adding the greybus core and drivers to
the kernel tree.
It breaks the larger git tree submission up into individual files to
make it easier for reviewing.
Any questions or comments, please let us know.
thanks,
greg k-h
This is the Greybus interface control code. It handles the interactions
between the Greybus core and the Greybus interface devices in the
system.
Signed-off-by: Greg Kroah-Hartman
---
drivers/greybus/interface.c | 1316
drivers/greybus/interface.h |
Fix the following compilation error caused due to incomplete merge. This is
observed if CONFIG_EXTCON is not set.
In file included from ./include/linux/mfd/palmas.h:23:0,
from drivers/input/misc/palmas-pwrbutton.c:22:
./include/linux/extcon.h: In function ‘extcon_sync’:
./include/
On Fri, Sep 16, 2016 at 12:19:07PM +0530, Kishon Vijay Abraham I wrote:
> Fix the following compilation error caused due to incomplete merge. This is
> observed if CONFIG_EXTCON is not set.
>
> In file included from ./include/linux/mfd/palmas.h:23:0,
> from drivers/input/misc/palm
On Thu, 15 Sep 2016, Martin Steigerwald wrote:
> Am Mittwoch, 14. September 2016, 14:14:35 CEST schrieb Jani Nikula:
>> On Wed, 14 Sep 2016, Jani Nikula wrote:
>> > On Wed, 14 Sep 2016, Pavel Machek wrote:
>> >> For the "sometimes need xrandr after resume": I don't think I can
>> >> bisect that.
801 - 856 of 856 matches
Mail list logo
