From: Paul Gortmaker
Date: Mon, 11 Jul 2016 12:51:01 -0400
> The Kconfig currently controlling compilation of this code is:
>
> init/Kconfig:config BPF_SYSCALL
> init/Kconfig: bool "Enable bpf() system call"
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets
If we get a vmalloc fault while current->active_mm->pgd doesn't
match CR3, we'll crash without this change. I've seen this failure
mode on heavily instrumented kernels with virtually mapped stacks.
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 2 +-
1 file changed, 1 insertion(+), 1
If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with
vmalloc_node.
grsecurity has had a similar feature (called
GRKERNSEC_KSTACKOVERFLOW) for a long time.
Cc: Oleg Nesterov
Signed-off-by: Andy Lutomirski
---
arch/Kconfig| 33 +
arch/ia64/includ
Hi all-
Since the dawn of time, a kernel stack overflow has been a real PITA
to debug, has caused nondeterministic crashes some time after the
actual overflow, and has generally been easy to exploit for root.
With this series, arches can enable HAVE_ARCH_VMAP_STACK. Arches
that enable it (just x
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
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).
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
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 ++
We'll need this cleanup to make the cpu field in thread_info be
optional.
Cc: Jason Wessel
Signed-off-by: Andy Lutomirski
---
include/linux/kdb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/kdb.h b/include/linux/kdb.h
index a19bcf9e762e..410decacff8f 100644
Now that most of the thread_info users have been cleaned up,
this is straightforward.
Most of this code was written by Linus.
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig | 1 +
arch/x86/entry/entry_64.S | 9 +---
arch/x86/include/asm/switch_to.h | 6 +
This will prevent a crash if the target task dies before or while
dumping its stack once we start freeing task stacks early.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/stacktrace.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/sta
If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT,
then thread_info is defined as a single 'u32 flags' and is the first
entry of task_struct. thread_info::task is removed (it serves no
purpose if thread_info is embedded in task_struct), and
thread_info::cpu gets its own slot in task_
We currently show:
task: ti: task.ti:
"
"ti" and "task.ti" are redundant, and neither is actually what we
want to show, which the the base of the thread stack. Change the
display to show the stack pointer explicitly.
Signed-off-by: Andy Lutomirski
---
kernel/printk/printk.c | 5 ++---
1
thread_info is a legacy mess. To prepare for its partial removal,
move addr_limit out.
As an added benefit, this way is simpler.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/checksum_32.h | 3 +--
arch/x86/include/asm/processor.h | 17 ++---
arch/x86/include/asm/threa
From: Linus Torvalds
It was a nice optimization while it lasted, but thread_info is moving
and this optimization will no longer work.
Quoting Linus:
Oh Gods, Andy. That pt_regs_to_thread_info() thing made me want
to do unspeakable acts on a poor innocent wax figure that looked
_exac
From: Linus Torvalds
thread_info may move in the future, so use the accessors.
Andy Lutomirski wrote this changelog message and changed
"task_thread_info(child)->cpu" to "task_cpu(child)".
Message-Id:
Signed-off-by: Andy Lutomirski
---
arch/x86/um/ptrace_32.c | 8
1 file changed, 4
Becuase sched.h and thread_info.h are a tangled mess, I turned
in_compat_syscall into a macro. If we had current_thread_struct()
or similar and we could use it from thread_info.h, then this would
be a bit cleaner.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c| 4 ++--
In general, there's no need for the "restore sigmask" flag to live in
ti->flags. alpha, ia64, microblaze, powerpc, sh, sparc (64-bit only),
tile, and x86 use essentially identical alternative implementations,
placing the flag in ti->status.
Replace those optimized implementations with an equally
It's statically initialized to zero -- no need to dynamically
initialize it to zero as well.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/smpboot.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index fafe8b923cac..0e91dbeca2fd 1006
This allows x86_64 kernels to enable vmapped stacks. There are a
couple of interesting bits.
First, x86 lazily faults in top-level paging entries for the vmalloc
area. This won't work if we get a page fault while trying to access
the stack: the CPU will promote it to a double-fault and we'll die
It serves no purpose -- raw_smp_processor_id() works fine. This
change will be needed to move thread_info off the stack.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/cpu.h | 1 -
arch/x86/include/asm/smp.h | 6 --
arch/x86/kernel/cpu/common.c | 2 +-
3 files changed, 1 insert
thread_info is a legacy mess. To prepare for its partial removal,
move the uaccess control fields out -- they're straightforward.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vsyscall/vsyscall_64.c | 6 +++---
arch/x86/include/asm/processor.h | 3 +++
arch/x86/include/asm/thread_info.
If we overflow the stack, print_context_stack will abort. Detect
this case and rewind back into the valid part of the stack so that
we can trace it.
Reviewed-by: Josh Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack.c | 10 +-
1 file changed, 9 insertions(+), 1 de
If we call do_exit() with a clean stack, we greatly reduce the risk of
recursive oopses due to stack overflow in do_exit, and we allow
do_exit to work even if we OOPS from an IST stack. The latter gives
us a much better chance of surviving long enough after we detect a
stack overflow to write out
[cherry-picked from ef16dd0c2a523d2e3975bb1bea9f5727e3e7146f to
avoid tangling the trees too much.]
The comment suggests that show_stack(NULL, NULL) should backtrace the
current context, but the code doesn't match the comment. If regs are
given, start the "Stack:" hexdump at regs->sp.
Signed-off
If we get a page fault indicating kernel stack overflow, invoke
handle_stack_overflow(). To prevent us from overflowing the stack
again while handling the overflow (because we are likely to have
very little stack space left), call handle_stack_overflow() on the
double-fault stack
Signed-off-by: A
If we overflow the stack into a guard page, we'll recursively fault
when trying to dump the contents of the guard page. Use
probe_kernel_address so we can recover if this happens.
Reviewed-by: Josh Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack_64.c | 12 ++--
1
If we're using CONFIG_VMAP_STACK and we manage to point an sg entry
at the stack, then either the sg page will be in highmem or sg_virt
will return the direct-map alias. In neither case will the existing
check_for_stack() implementation realize that it's a stack page.
Fix it by explicitly checkin
From: Ingo Molnar
So when memory hotplug removes a piece of physical memory from pagetable
mappings, it also frees the underlying PGD entry.
This complicates PGD management, so don't do this. We can keep the
PGD mapped and the PUD table all clear - it's only a single 4K page
per 512 GB of memory
Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
zone. This only makes sense if each kernel stack exists entirely in
one zone, and allowing vmapped stacks could break this assumption.
Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack
allocations in a unit that
On Sun, Jul 10, 2016 at 02:23:27PM +0100, Jonathan Cameron wrote:
> On 03/07/16 22:04, Alison Schofield wrote:
> > IIO driver, perhaps a reference driver, since this sensor is already
> > supported in hwmon/jc42 driver.
> >
> > Driver supports continuous conversion, resolution changes and
> > susp
kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in
init_mm.pgd were to be cleared, callers would need to ensure that
the pgd entry hadn't been propagated to any other pgd.
Its only caller was efi_cleanup_page_tables(), and that, in turn,
was unused, so just delete both functions. This le
We should account for stacks regardless of stack size, and we need
to account in sub-page units if THREAD_SIZE < PAGE_SIZE. Change the
units to kilobytes and Move it into account_kernel_stack().
Fixes: 12580e4b54ba8 ("mm: memcontrol: report kernel stack usage in cgroup2
memory.stat")
Cc: Vladimi
After discovering there are 2 very different 14e4:4365 PCI devices we
made ID tables less generic. Back then we believed there are only 2 such
devices:
1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset
2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset
>From the recent report it appears there
On 07/10, Jorge Ramirez Ortiz wrote:
> On 9 July 2016 at 08:42, Jorge Ramirez
> > um, I retested again this morning and it is all good - I was also a bit
> > surprised when things failed yesterday (it seems one of the wires on my
> > board was loose, sorry).
> >
> > So AFAIC your patch addresses
SMP does ECB crypto on stack buffers. This is complicated and
fragile, and it will not work if the stack is virtually allocated.
Switch to the crypto_cipher interface, which is simpler and safer.
Cc: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: "David S. Miller"
Cc: linux-blueto
This avoids pointless races in which another CPU or task might see a
partially populated global pgd entry. These races should normally
be harmless, but, if another CPU propagates the entry via
vmalloc_fault and then populate_pgd fails (due to memory allocation
failure, for example), this prevents
On 07/01, Andy Gross wrote:
> The patch changes the initcall for SCM to use subsys_initcall
> instead of arch_initcall. This corrects the order so that we don't
> probe defer when trying to get clks which causes issues later when
> the spm driver makes calls to qcom_set_warm_boot_addr().
>
> The
On Mon, Jul 11, 2016 at 10:31:45PM +0200, John Crispin wrote:
> maybe i am missing something here, but i can see the dependencies inside
> the for-next branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git. is
> this not the tree i should base patches on for v4.8 ?
Oh, s
Add the call to of_clk_set_defaults() into the amba probe path so
that devices on the amba bus can use the assigned rates and
parents feature of the common clock framework.
Cc: Michael Turquette
Cc: Jorge Ramirez Ortiz
Signed-off-by: Stephen Boyd
---
drivers/amba/bus.c | 5 +
1 file change
On Mon, Jul 11, 2016 at 06:06:48AM +0900, James Bottomley wrote:
> On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote:
> > Andrew Vagin writes:
> >
> > > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote:
> > > > "W. Trevor King" writes:
> > > >
> > > > > On Thu, Jul 07,
On Mon, Jul 11, 2016 at 02:29:39PM +0200, John Crispin wrote:
> +static const struct of_device_id mt6323_of_match[] = {
> + { .compatible = "mediatek,mt6323-regulator", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, mt6323_of_match);
This may have been answered last time but
On Sun, 10 Jul 2016 01:17:05 +0800 cheng...@emindsoft.com.cn wrote:
> For a pure output parameter:
>
> - When callee fails, the caller should not assume the output parameter
>is still valid.
>
> - And callee should not assume the pure output parameter must be
>provided by caller -- cal
On Mon, 11 Jul 2016 21:31:04 +0200
Ingo Molnar wrote:
>
> * Jacob Pan wrote:
>
> > On Mon, 11 Jul 2016 07:59:19 -0700
> > "Chen, Yu C" wrote:
> >
> > > Currently it is in your x86/timer tree:
> > >
> > > commit fc273eeef314cdaf0ac992b400d126f8184a4d1c
> > > Author: Len Brown
> > > Date:
The Makefile for building this is "acpi-y" and so it is not built
as a module. Hence including module.h and everything that comes
with it just for the no-op MODULE_LICENSE is rather heavy handed.
The license info is found at the top of the file, so we just remove
the MODULE_LICENSE and the includ
On 11/07/2016 at 10:23:51 +0200, Uwe Kleine-König wrote :
> Hello,
>
> On Mon, Jul 11, 2016 at 06:12:08PM +1000, Stephen Rothwell wrote:
> > After merging the rtc tree, today's linux-next build (x86 64_allmodconfig)
> > produced this warning:
> >
> > drivers/rtc/rtc-isl12057.c: In function 'isl12
On Mon, Jul 11, 2016 at 09:47:34AM -0700, Doug Anderson wrote:
> Hi,
>
> On Sun, Jul 10, 2016 at 11:56 PM, Stephen Rothwell
> wrote:
> > Hi Thierry,
> >
> > Today's linux-next merge of the pwm tree got a conflict in:
> >
> > drivers/regulator/pwm-regulator.c
> >
> > between commit:
> >
> > 8
VLAN and MQ control was doing DMA from the stack. Fix it.
Cc: Michael S. Tsirkin
Cc: "net...@vger.kernel.org"
Signed-off-by: Andy Lutomirski
---
I tested VLAN addition and removal with CONFIG_VMAP_STACK=y,
CONFIG_DEBUG_SG=y and it got rid of the warnings I saw. I haven't
tested the MQ part b
Quoting Maxime Ripard (2016-07-11 13:34:47)
> The code had a typo and got the wrong offset for the hardcoded divider, fix
> that.
>
> Signed-off-by: Maxime Ripard
> Reported-by: Jean-Francois Moine
> Reported-by: Chen-Yu Tsai
Applied.
Regards,
Mike
> ---
> drivers/clk/sunxi-ng/ccu-sun8i-h3.
Quoting Maxime Ripard (2016-07-11 13:34:48)
> The Kconfig symbol for the sun8i SoC family was mistyped. Fix that.
>
> Signed-off-by: Maxime Ripard
Applied.
Regards,
Mike
> ---
> drivers/clk/sunxi-ng/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/
The newly added mtk-vcodec driver produces a number of warnings in an ARM
allmodconfig build, mainly since it assumes that dma_addr_t is 32-bit wide:
mtk-vcodec/venc/venc_vp8_if.c: In function 'vp8_enc_alloc_work_buf':
mtk-vcodec/venc/venc_vp8_if.c:212:191: error: cast to pointer from integer of
On Mon, Jul 11, 2016 at 11:30:59PM +0200, Thierry Reding wrote:
> On Mon, Jul 11, 2016 at 09:47:34AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Sun, Jul 10, 2016 at 11:56 PM, Stephen Rothwell
> > wrote:
> > > Hi Thierry,
> > >
> > > Today's linux-next merge of the pwm tree got a conflict in:
A cleanup patch introduced a harmless warning about now unused local variables:
drivers/rtc/rtc-isl12057.c: In function 'isl12057_rtc_read_alarm':
drivers/rtc/rtc-isl12057.c:249:26: error: unused variable 'alarm_secs'
[-Werror=unused-variable]
unsigned long rtc_secs, alarm_secs;
The newly added zynqmp_dma driver produces a warning on 32-bit architectures
when dma_addr_t is 64-bit wide:
drivers/dma/xilinx/zynqmp_dma.c: In function 'zynqmp_dma_config_sg_ll_desc':
drivers/dma/xilinx/zynqmp_dma.c:321:9: error: cast from pointer to integer of
different size [-Werror=pointer-t
A recent commit added barry support to this driver, but that causes
a link failure when CONFIG_POWER_SUPPLY is not set:
drivers/hid/built-in.o: In function `hidpp_battery_get_property':
:(.text+0x1a834): undefined reference to `power_supply_get_drvdata'
drivers/hid/built-in.o: In function `hidpp_r
The voltage ranges listed in the RPM SMD regulator driver
aren't correct. This series makes the voltage range tables
match what the hardware supports. That fixes a problem
where pm8941 l24 fails to be set at 3.075V when the hardware
really supports it.
Stephen Boyd (3):
regulator: qcom_smd: Fix
When CONFIG_PM is not set, we get a warning about an unused function:
drivers/gpu/drm/exynos/exynos_drm_gsc.c:1219:12: error: 'gsc_clk_ctrl' defined
but not used [-Werror=unused-function]
static int gsc_clk_ctrl(struct gsc_context *ctx, bool enable)
^~~~
This removes the two
The voltage ranges listed here are wrong. The correct ranges can
be seen in the "native" spmi regulator driver
qcom_spmi-regulator.c at pldo_ranges[], ftsmps_ranges[] and
boost_ranges[] for the pldo, ftsmps, and boost type regulators.
Port these ranges over to the RPM SMD regulator driver so that w
The pm8x41_hfsmps ranges overlap. The first range is from 375000
to 1562500:
375000 + (95 * 12500) == 1562500
and the second range starts at 155. Interestingly, the second
range ends at the correct value when it's set to be the
appropriate start value, 1575000:
1575000 + ((158 - 96) * 2500
The voltage ranges listed here are wrong. The pma8084 pldo
supports three different overlapping voltage ranges with
differing step sizes and the pma8084 ftsmps supports two. These
ranges can be seen in the "native" spmi regulator driver
(qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
r
> David,
>
> Did you have any more thoughts about this? I'm happy to make some other
> adjustments to the patch, if you have some recommendations.
Hi,
I just wanted to share that the maintenance BIOSes released for the Dell
platforms with Type-C this past week enables the MAC address pass
thr
On Fri, 2016-07-08 at 12:37 +0100, Suzuki K Poulose wrote:
> On systems with mismatched i/d cache min line sizes, we need to use
> the smallest size possible across all CPUs. This will be done by fetching
> the system wide safe value from CPU feature infrastructure.
> However the some special users
+++ Miroslav Benes [11/07/16 16:03 +0200]:
On Mon, 27 Jun 2016, Torsten Duwe wrote:
diff --git a/arch/arm64/include/asm/livepatch.h
b/arch/arm64/include/asm/livepatch.h
new file mode 100644
index 000..6b9a3d1
--- /dev/null
+++ b/arch/arm64/include/asm/livepatch.h
@@ -0,0 +1,37 @@
+/*
+ * l
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
On 10 July 2016 at 20:10, Peter Chen wrote:
> On Thu, Jul 07, 2016 at 03:21:01PM -0700, Stephen Boyd wrote:
>> @@ -418,6 +427,17 @@ static inline bool ci_otg_is_fsm_mode(struct ci_hdrc
>> *ci)
>> #endif
>> }
>>
>> +#if IS_ENABLED(CONFIG_USB_CHIPIDEA_ULPI)
>> +int ci_ulpi_init(struct ci_hdrc *ci
On 10 July 2016 at 21:43, Peter Chen wrote:
> On Thu, Jul 07, 2016 at 03:21:06PM -0700, Stephen Boyd wrote:
>> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
>> b/drivers/usb/chipidea/ci_hdrc_msm.c
>> index 7e870a253f55..7708bee3ff3e 100644
>> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
>> +++ b/dr
From:
Date: Mon, 11 Jul 2016 21:54:07 +
> Please let me know what else can be done for this patch to make it
> acceptable so we can have parity for Linux.
Just resubmit it and I'll apply it, I'm so tired of hearing about this...
The Kconfig currently controlling compilation of these files are:
drivers/acpi/Kconfig:menuconfig PMIC_OPREGION
drivers/acpi/Kconfig: bool "PMIC (Power Management Integrated Circuit)
operation region support"
drivers/acpi/Kconfig:config BXT_WC_PMIC_OPREGION
drivers/acpi/Kconfig: bool "ACPI o
On 10 July 2016 at 22:32, Peter Chen wrote:
> On Thu, Jul 07, 2016 at 03:21:09PM -0700, Stephen Boyd wrote:
>> @@ -40,11 +43,38 @@ struct ci_hdrc_msm {
>> struct clk *iface_clk;
>> struct clk *fs_clk;
>> struct ci_hdrc_platform_data pdata;
>> + struct reset_controller_dev rcd
Topi Miettinen writes:
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
>
> Currently, there is no way to know which capabilities are
Quoting Wan Zongshun (2016-07-10 00:27:24)
> diff --git a/drivers/clk/nuc900/clk-apll.c b/drivers/clk/nuc900/clk-apll.c
> new file mode 100644
> index 000..a05aec7
> --- /dev/null
> +++ b/drivers/clk/nuc900/clk-apll.c
> @@ -0,0 +1,168 @@
> +/*
> + * Copyright 2016 Wan Zongshun
> + *
> + * The
PowerVM seems to only ever provide a single hotplug slot per PHB.
The under lying slot hotplug registration code assumed multiple slots,
but the actual implementation is broken for multiple slots. This went
unnoticed for years due to the nature of PowerVM as mentioned
previously. Under qemu/kvm the
The Kconfig for this file is:
drivers/acpi/Kconfig:config ACPI_PCI_SLOT
drivers/acpi/Kconfig: bool "PCI slot detection driver"
...and so it is not built as a module. Hence including module.h
and everything that comes with it just for the no-op MODULE_LICENSE
and friends is rather heavy handed.
On Wed, 29 Jun 2016 13:42:12 +0800 "Hillf Danton"
wrote:
> To avoid excessive reclaim, we give up rebalancing for high order
> allocations right after reclaiming enough pages.
hm. What are the observed runtime effects of this change? Any testing
results?
Quoting Franklin S Cooper Jr (2016-05-03 08:56:47)
> Add tblck to the pwm nodes. This insures that the ehrpwm driver has access
s/tblck/tbclk/
I see you have acks already. What tree should this patch go through?
Regards,
Mike
> to the time-based clk.
>
> Do not remove similar entries for ehrpw
Hi,
This series fix the recent seccomp update for the User-mode Linux architecture
(32-bit and 64-bit) since commit 26703c636c1f3272b39bd0f6d04d2e970984f1b6
(close the hole where ptrace can change a syscall out from under seccomp).
Regards,
Mickaël Salaün (3):
um/ptrace: Fix the syscall_trace_
Keep the same semantic as before the commit 26703c636c1f: deallocate
audit context and fake a proper syscall exit.
This fix a kernel panic triggered by the seccomp_bpf test:
> [ RUN ] global.ERRNO_valid
> BUG: failure at kernel/auditsc.c:1504/__audit_syscall_entry()!
> Kernel panic - not sync
Hi Sergey and Jan,
On 12-07-16, 00:44, Sergey Senozhatsky wrote:
> right. apart from cases when the existing console_unlock() behaviour can
> simply "block" a process to flush the log_buf to slow serial consoles
> (regardless the process execution context) and make the system less
> responsive, I
T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=05 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3490 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlc
Hi Dmitry,
> T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=05 Dev#= 5 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=13d3 ProdID=3490 Rev=00.01
> C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I: If#= 1 A
On Mon, Jul 11, 2016 at 02:50:08PM -0700, Stephen Boyd wrote:
> The voltage ranges listed here are wrong. The pma8084 pldo
> supports three different overlapping voltage ranges with
> differing step sizes and the pma8084 ftsmps supports two. These
> ranges can be seen in the "native" spmi regulator
Fix misspelled error message and existing checkpatch errors in the
error message conditional.
WARNING: suspect code indent for conditional statements (8, 24)
if (ctx->state != MFCINST_HEAD_PARSED &&
[...]
+ mfc_err("Can not get crop information\n");
Signed-off-by: Shuah Khan
On Monday, July 11, 2016 03:35:01 PM Viresh Kumar wrote:
> Hi Sergey and Jan,
>
> On 12-07-16, 00:44, Sergey Senozhatsky wrote:
> > right. apart from cases when the existing console_unlock() behaviour can
> > simply "block" a process to flush the log_buf to slow serial consoles
> > (regardless the
On Mon, Jul 11, 2016 at 02:50:09PM -0700, Stephen Boyd wrote:
> The pm8x41_hfsmps ranges overlap. The first range is from 375000
> to 1562500:
>
> 375000 + (95 * 12500) == 1562500
>
> and the second range starts at 155. Interestingly, the second
> range ends at the correct value when it's se
On 9 July 2016 at 08:30, Markus Mayer wrote:
> On 9 July 2016 at 05:04, Luis de Bethencourt wrote:
>> On 08/07/16 23:43, Markus Mayer wrote:
>>> Add a collection of generic functions to convert strings to lowercase
>>> or uppercase.
>>>
>>> Changing the case of a string (with or without copying i
On 12-07-16, 00:44, Rafael J. Wysocki wrote:
> On Monday, July 11, 2016 03:35:01 PM Viresh Kumar wrote:
> > Hi Sergey and Jan,
> >
> > On 12-07-16, 00:44, Sergey Senozhatsky wrote:
> > > right. apart from cases when the existing console_unlock() behaviour can
> > > simply "block" a process to flus
On Mon, Jul 11, 2016 at 02:50:07PM -0700, Stephen Boyd wrote:
> The voltage ranges listed here are wrong. The correct ranges can
> be seen in the "native" spmi regulator driver
> qcom_spmi-regulator.c at pldo_ranges[], ftsmps_ranges[] and
> boost_ranges[] for the pldo, ftsmps, and boost type regula
On Jul 10, 2016, at 9:03 PM, Al Viro wrote:
> On Mon, Jul 11, 2016 at 02:01:13AM +0100, Al Viro wrote:
>> On Sun, Jul 10, 2016 at 07:14:18PM +0100, James Simmons wrote:
>>
>>> [ 111.210818] [] kiblnd_send+0x51d/0x9e0 [ko2iblnd]
>>
>> Mea culpa - in kiblnd_send() this
>>if (payload_kio
On Thu, 30 Jun 2016, Joonsoo Kim wrote:
> We need to find a root cause of this problem, first.
>
> I guess that this problem would happen when isolate_freepages_block()
> early stop due to watermark check (if your patch is applied to your
> kernel). If scanner meets, cached pfn will be reset and
befs_read_datastream() is used to read the inode from the disk, off is
meant to provide the offset of the data in the buffer head. But the only
function using this argument already knows the starting offset of the node,
so this argument isn't needed.
Signed-off-by: Luis de Bethencourt
---
Hi,
I
Fixing a grammatical error in the documentation.
Signed-off-by: Luis de Bethencourt
---
Hi,
Since befs_bt_read_node() calls befs_read_datastream(), and was touched
in the first commit of the series I decided to send a fix for the
grammatical error I had noticed there a while ago.
Thanks for all
The only place the values of free_node_ptr and max_size are read is in
befs_dump_index_entry(), which both times it is called, it is passed the on
disk superblock. Removing assignment of unused values.
Signed-off-by: Luis de Bethencourt
---
Hi,
Noticed this when reading befs' btree code.
Thanks
On Sat, Jul 09, 2016 at 08:19:15PM +0200, Mickaël Salaün wrote:
> Fixes: a1db74209483 ("module: replace copy_module_from_fd with kernel
> version")
It's not a "fix", it's a "cleanup remaining bits"
On Mon, Jul 11, 2016 at 02:22:09PM +0200, Jean Delvare wrote:
> Hi Viresh,
>
> On Wed, 6 Jul 2016 13:55:40 -0700, Viresh Kumar wrote:
> > On 06-07-16, 19:12, Jean Delvare wrote:
> > > Well well... I don't like this patch at all to be honest.
> >
> > Sure, I didn't like it much as well. I just wan
On Mon, Jul 11, 2016 at 10:07:31AM +, Nava kishore Manne wrote:
> Ping!!
>
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you a
On Thu, Jul 07, 2016 at 09:42:32AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 07, 2016 at 11:20:36AM +1200, Campbell Steven wrote:
>
> > > commit 8974189222159154c55f24ddad33e3613960521a
> > > Author: Peter Zijlstra
> > > Date: Thu Jun 16 10:50:40 2016 +0200
>
> > Since these early reports fro
Update the syscall number after earch PTRACE_SETREGS on ORIG_*AX.
This is needed to get the potentially altered syscall number in the
seccomp filters after RET_TRACE.
This fix four seccomp_bpf tests:
> [ RUN ] TRACE_syscall.skip_after_RET_TRACE
> seccomp_bpf.c:1560:TRACE_syscall.skip_after_R
Hi Paulo,
On Mon, 11 Jul 2016 16:07:39 -0300 Paulo Flabiano Smorigo
wrote:
>
> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
> index 2280539..813ffcc 100644
> --- a/drivers/crypto/vmx/aesp8-ppc.pl
> +++ b/drivers/crypto/vmx/aesp8-ppc.pl
> @@ -1,4 +1,11 @@
> -#!/u
Thank you very much, Mark!
In linux-nvdimm list, Dan Williams posted patch series which introduced
nvdimm_flush() and nvdimm_has_flush()
which assumes ARS(Asynchronous DRAM Refresh) feature or using Flush Hint in
NFIT to get persistency.
And.. arch_wmb_pmem() has been killed in the patch.
Wit
On 06/29/2016 12:49 PM, Markus Mayer wrote:
> From: Florian Fainelli
>
> Add an ARCH_BRCMSTB Kconfig symbol which allows us not to update the
> dependencies for all STB-related drivers. Select BRCMSTB_L2_IRQ and
> GENERIC_IRQ_CHIP which are required for proper functioning.
>
> Signed-off-by: Dou
601 - 700 of 830 matches
Mail list logo
