Hi Colin,
On Sat, May 25, 2019, at 06:35, Colin King wrote:
> From: Colin Ian King
>
> The assignement to cip_header is redundant as the value never
> read and it is being re-assigned in the if and else paths of
> the following if statement. Clean up the code by removing it.
>
>
On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:
>
> On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
>> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>>
>>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell wrote:
On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>
>
在 2019-05-25 01:33, Eduardo Valentin 写道:
Hey,
On Fri, May 24, 2019 at 10:43:16AM +0800, Wang, Haiyue wrote:
Thanks for interest, the design idea is from:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/i2c-slave-eeprom.c?h=v5.2-rc1
and
On Sat, May 25, 2019 at 10:12:41AM +0800, Gen Zhang wrote:
> On Fri, May 24, 2019 at 04:21:36PM -0700, Randy Dunlap wrote:
> > On 5/22/19 6:17 PM, Gen Zhang wrote:
> > > Hi Andrew,
> > > I am starting submitting patches these days and got some patches
> > > "Reviewed-by" from maintainers. After
On Sat, May 25, 2019 at 12:26:42PM +0800, Mao Wenan wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/staging/kpc2000/kpc_spi/spi_driver.c: In function
> ‘kp_spi_transfer_one_message’:
> drivers/staging/kpc2000/kpc_spi/spi_driver.c:282:9: warning: variable
> ‘status’ set but not
On Fri, May 24, 2019 at 10:30:58PM +0200, Simon Sandström wrote:
> Fixes build errors:
>
> ERROR: "mfd_remove_devices" [kpc2000.ko] undefined!
> ERROR: "uio_unregister_device" [kpc2000.ko] undefined!
> ERROR: "mfd_add_devices" [kpc2000.ko] undefined!
> ERROR: "__uio_register_device" [kpc2000.ko]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 7fbc78e3155a0c464bd832efc07fb3c2355fe9bd
commit: e6f393bc939d566ce3def71232d8013de9aaadde objtool: Fix function
fallthrough detection
date: 11 days ago
config: x86_64-randconfig-b0-05251117 (attached as
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/staging/kpc2000/kpc_spi/spi_driver.c: In function
‘kp_spi_transfer_one_message’:
drivers/staging/kpc2000/kpc_spi/spi_driver.c:282:9: warning: variable
‘status’ set but not used [-Wunused-but-set-variable]
int status = 0;
^~
On Fri, May 24, 2019 at 7:40 PM Frank Rowand wrote:
>
> Hi Saranova,
>
> I'll try to address the other portions of this email that I
> in my previous replies.
>
>
> On 5/24/19 2:53 PM, Saravana Kannan wrote:
> > On Fri, May 24, 2019 at 10:49 AM Frank Rowand
> > wrote:
> >>
> >> On 5/23/19 6:01
On Wed, 22 May 2019, David Howells wrote:
> Fix a pair of accesses that should be using RCU protection.
>
> rcu_dereference_protected() is needed to access task_struct::real_parent.
>
> current_cred() should be used to access current->cred.
>
> Signed-off-by: David Howells
Reviewed-by:
On Wed, 22 May 2019, David Howells wrote:
> Fix some kdoc argument description mismatches reported by sparse and give
> keyring_restrict() a description.
>
> Signed-off-by: David Howells
> cc: Mat Martineau
Reviewed-by: James Morris
--
James Morris
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the
Dear RT Folks,
This is the RT stable review cycle of patch 4.19.37-rt20-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release
4.19.37-rt20-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Steven Rostedt (VMware)"
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 483ad771f201..53614196cb36
4.19.37-rt20-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Corey Minyard
Consider following race:
T0T1 T2
wait_for_completion()
do_wait_for_common()
__prepare_to_swait()
schedule()
4.19.37-rt20-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
Powerpc32/64 does not compile because TIF_SYSCALL_TRACE's bit is higher
than 15 and the assembly instructions don't expect that.
Move TIF_RESTOREALL,
4.19.37-rt20-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
The locallock protects the per-CPU variable tce_page. The function
attempts to allocate memory while tce_page is protected (by disabling
interrupts).
Use
4.19.37-rt20-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
The locks (timeline->lock and rq->lock) need to be taken with disabled
interrupts. This is done in __retire_engine_request() by disabling the
interrupts
4.19.37-rt20-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Julien Grall
Systems which don't provide arch_trigger_cpumask_backtrace() will
invoke showacpu() from a smp_call_function() function which is invoked
with disabled interrupts even
The commit 9092c71bb724 ("mm: use sc->priority for slab shrink targets")
has broken up the relationship between sc->nr_scanned and slab pressure.
The sc->nr_scanned can't double slab pressure anymore. So, it sounds no
sense to still keep sc->nr_scanned inc'ed. Actually, it would prevent
from
Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
and some other vm counters still get inc'ed by one even though a whole
THP (512 pages) gets swapped out.
This doesn't make too much sense to memory reclaim.
On 1/10/19 6:43 AM, Paul Menzel wrote:
> Dear Linux folks,
>
>
> There were some PCI Kconfig changes, which seem to cause problems
> with components depending on PCI. With the attached minimal config,
> running `make olddefconfig` on Linux 4.20 and older caused
> `SATA_AHCI` to be selected. But,
On 5/24/19 6:38 PM, Mahesh Bandewar (महेश बंडेवार) wrote:
On Fri, May 24, 2019 at 2:17 PM Jay Vosburgh wrote:
Jarod Wilson wrote:
Once in a while, with just the right timing, 802.3ad slaves will fail to
properly initialize, winding up in a weird state, with a partner system
mac address of
From: "Steven Rostedt (VMware)"
Some of the flags for ftrace_startup() may be exposed even when
CONFIG_DYNAMIC_FTRACE is not configured in. This is fine as the difference
between dynamic ftrace and static ftrace is done within the internals of
ftrace itself. No need to have use cases fail to
From: "Steven Rostedt (VMware)"
Change the direction of the current->ret_stack shadown stack to move the
same as most normal arch stacks do.
Suggested-by: Peter Zijlstra
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/fgraph.c | 39 ---
1 file
From: "Steven Rostedt (VMware)"
Add an array structure that will eventually allow the function graph tracer
to have up to 16 simultaneous callbacks attached. It's an array of 16
fgraph_ops pointers, that is assigned when one is registered. On entry of a
function the entry of the first item in
From: "Steven Rostedt (VMware)"
Allow for multiple users to attach to function graph tracer at the same
time. Only 16 simultaneous users can attach to the tracer. This is because
there's an array that stores the pointers to the attached fgraph_ops. When a
a function being traced is entered, each
From: "Steven Rostedt (VMware)"
Now that function graph tracing can handle more than one user, allow it to
be enabled in the ftrace instances. Note, the filtering of the functions is
still joined by the top level set_ftrace_filter and friends, as well as the
graph and nograph files.
From: "Steven Rostedt (VMware)"
The use of the task->trace_recursion for the logic used for the
set_graph_funnction was a bit of an abuse of that variable. Now that there
exists global vars that are per stack for registered graph traces, use that
instead.
Signed-off-by: Steven Rostedt (VMware)
From: "Steven Rostedt (VMware)"
In order to make it possible to have multiple callbacks registered with the
function_graph tracer, the retstack needs to be converted from an array of
ftrace_ret_stack structures to an array of longs. This will allow to store
the list of callbacks on the stack for
The background for this is explained in the V1 version found here:
http://lkml.kernel.org/r/20181122012708.491151...@goodmis.org
The TL;DR; is this:
The function graph tracer required a rewrite, mainly because it
can only allow one callback registered at a time. The main motivation
for
From: "Steven Rostedt (VMware)"
Instead of using "ALIGN()", use BUILD_BUG_ON() as the structures should
always be divisible by sizeof(long).
Link:
http://lkml.kernel.org/r/2019052444.gi2...@hirez.programming.kicks-ass.net
Suggested-by: Peter Zijlstra
Signed-off-by: Steven Rostedt
From: "Steven Rostedt (VMware)"
The function pointers ftrace_graph_entry and ftrace_graph_return are no
longer called via the function_graph tracer. Instead, an array structure is
now used that will allow for multiple users of the function_graph
infrastructure. The variables are still used by
From: "Steven Rostedt (VMware)"
Pass the fgraph_ops structure to the function graph callbacks. This will
allow callbacks to add a descriptor to a fgraph_ops private field that wil
be added in the future and use it for the callbacks. This will be useful
when more than one callback can be
From: "Steven Rostedt (VMware)"
The use of the task->trace_recursion for the logic used for the function
graph depth was a bit of an abuse of that variable. Now that there
exists global vars that are per stack for registered graph traces, use that
instead.
Signed-off-by: Steven Rostedt (VMware)
From: "Steven Rostedt (VMware)"
Add a "task variables" array on the tasks shadow ret_stack that is the
size of longs for each possible registered fgraph_ops. That's a total of 16,
taking up 8 * 16 = 128 bytes (out of a page size 4k).
This will allow for fgraph_ops to do specific features on a
From: "Steven Rostedt (VMware)"
Allow for instances to have their own ftrace_ops part of the fgraph_ops that
makes the funtion_graph tracer filter on the set_ftrace_filter file of the
instance and not the top instance.
Signed-off-by: Steven Rostedt (VMware)
---
include/linux/ftrace.h
From: "Steven Rostedt (VMware)"
Added functions that can be called by a fgraph_ops entryfunc and retfunc to
store state between the entry of the function being traced to the exit of
the same function. The fgraph_ops entryfunc() may call fgraph_reserve_data()
to store up to 4 words onto the
From: "Steven Rostedt (VMware)"
The use of the task->trace_recursion for the logic used for the function
graph no-trace was a bit of an abuse of that variable. Now that there exists
global vars that are per stack for registered graph traces, use that instead.
Signed-off-by: Steven Rostedt
From: "Steven Rostedt (VMware)"
Add boot up selftest that passes variables from a function entry to a
function exit, and make sure that they do get passed around. Also test
for some failure cases.
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_selftest.c | 310
Linus,
Tom Zanussi sent me some small fixes and cleanups to the histogram
code and I forgot to incorporate them.
I also added a small clean up patch that was sent to me a while ago
and I just noticed it.
Please pull the latest trace-v5.2-rc1 tree, which can be found at:
On Fri, May 24, 2019 at 12:59 PM Matteo Croce wrote:
>
> This commit adds ibumad to .gitignore which is
> currently ommited from the ignore file.
>
> Signed-off-by: Matteo Croce
Applied. Thanks
On Fri, May 24, 2019 at 4:52 PM Roman Gushchin wrote:
>
> This patchset implements a cgroup bpf auto-detachment functionality:
> bpf programs are detached as soon as possible after removal of the
> cgroup, without waiting for the release of all associated resources.
>
> Patches 2 and 3 are
On 5/24/19 2:00 PM, Yang Shi wrote:
On 5/24/19 1:51 PM, Hillf Danton wrote:
On Fri, 24 May 2019 09:27:02 +0800 Yang Shi wrote:
On 5/23/19 11:51 PM, Hillf Danton wrote:
On Thu, 23 May 2019 10:27:38 +0800 Yang Shi wrote:
@ -1642,14 +1650,14 @@ static unsigned long
On 5/24/19 5:16 PM, Jay Vosburgh wrote:
Jarod Wilson wrote:
Once in a while, with just the right timing, 802.3ad slaves will fail to
properly initialize, winding up in a weird state, with a partner system
mac address of 00:00:00:00:00:00. This started happening after a fix to
properly track
Hi Saranova,
I'll try to address the other portions of this email that I
in my previous replies.
On 5/24/19 2:53 PM, Saravana Kannan wrote:
> On Fri, May 24, 2019 at 10:49 AM Frank Rowand wrote:
>>
>> On 5/23/19 6:01 PM, Saravana Kannan wrote:
>>> Add a generic "depends-on" property that
On Thu, May 23, 2019 at 10:52 PM Greg Kroah-Hartman
wrote:
>
> On Thu, May 23, 2019 at 06:01:11PM -0700, Saravana Kannan wrote:
> > Add a generic "depends-on" property that allows specifying mandatory
> > functional dependencies between devices. Add device-links after the
> > devices are created
On Fri, May 24, 2019 at 04:21:36PM -0700, Randy Dunlap wrote:
> On 5/22/19 6:17 PM, Gen Zhang wrote:
> > Hi Andrew,
> > I am starting submitting patches these days and got some patches
> > "Reviewed-by" from maintainers. After checking the
> > submitting-patches.html, I figured out what
Ugh... mobile app is sending HTML emails. Replying again.
On Fri, May 24, 2019 at 5:25 PM Frank Rowand wrote:
>
> On 5/24/19 5:22 PM, Frank Rowand wrote:
> > On 5/24/19 2:53 PM, Saravana Kannan wrote:
> >> On Fri, May 24, 2019 at 10:49 AM Frank Rowand
> >> wrote:
> >>>
> >>> On 5/23/19 6:01
devm_kmalloc() is used to allocate memory for a driver dev. Comments
above the definition and doc
(https://www.kernel.org/doc/Documentation/driver-model/devres.txt) all
imply that allocated the memory is automatically freed on driver attach,
no matter allocation fail or not. However, I examined
From: John Hubbard
Hi Jason and all,
I've added Jerome's and Ira's Reviewed-by tags. Other than that, this patch
is the same as v1.
==
Earlier cover letter:
IIUC, now that we have the put_user_pages() merged in to
From: John Hubbard
For infiniband code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(), or
put_user_pages*(), instead of put_page()
This is a tiny part of the second step of fixing the problem described
in [1]. The steps are:
1) Provide
On 2019/5/24 下午6:58, Peter Hutterer wrote:
On Fri, May 24, 2019 at 06:43:58PM +0800, Hui Wang wrote:
On 2019/5/24 下午5:37, Peter Hutterer wrote:
On Fri, May 24, 2019 at 03:37:57PM +0800, Hui Wang wrote:
OK, that is sth we need to do. But anyway it is a bit risky to backport
that much code
This patch adds a MAINTAINERS entry for the AD7780 ADC driver.
Signed-off-by: Renato Lui Geh
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 54c8e14fae98..d12685c5b09a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -880,6 +880,15 @@ S:
This patchset converts the old ad7780 device-tree binding to
the new YAML format, and adds an entry to MAINTAINERS.
Renato Lui Geh (2):
dt-bindings: iio: adc: add adi,ad7780.yaml binding
MAINTAINERS: add entry for ad7780 adc driver
.../bindings/iio/adc/adi,ad7780.txt | 48 --
This patch adds a YAML binding for the Analog Devices AD7780/1 and
AD7170/1 analog-to-digital converters.
Signed-off-by: Renato Lui Geh
---
Changes in v2:
- vref-supply to avdd-supply
- remove avdd-supply from required list
- include adc block in an spi block
On Fri, May 24, 2019 at 05:53:02PM -0700, Ruslan Babayev wrote:
> Lookup I2C adapter using the "i2c-bus" device property on ACPI based
> systems similar to how it's done with DT.
>
> An example DSD describing an SFP on an ACPI based system:
>
> Device (SFP0)
> {
> Name (_HID, "PRP0001")
>
What I do in ring=non-supervisor is close all fd's while
checking against an array of exemptions. if /proc is not
mounted I close RLIMIT_NOFILE, if that fails I use a dumb
loop to close everything(slooow). This new system call could
significantly increase the fallback code, but If you use a
range
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the
On Sat, 2019-05-25 at 09:14 +0900, Tetsuo Handa wrote:
> On 2019/05/25 2:17, Linus Torvalds wrote:
> > A config option or two that help syzbot doesn't sound like a bad idea to me.
>
> Thanks for suggestion. I think that #ifdef'ing
>
> static bool suppress_message_printing(int level)
> {
>
On Sat, 2019-05-11 at 02:42:17 UTC, Ravi Bangoria wrote:
> Consider a scenario where user creates two events:
>
> 1st event:
> attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
> attr.branch_sample_type = PERF_SAMPLE_BRANCH_ANY;
> fd = perf_event_open(attr, 0, 1, -1, 0);
>
> This
The pull request you sent on Fri, 24 May 2019 16:11:43 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2409207a73cc8e4aff75ceccf6fe5c3ce4d391bc
Thank you!
--
Deet-doot-dot, I am a bot.
Lookup I2C adapter using the "i2c-bus" device property on ACPI based
systems similar to how it's done with DT.
An example DSD describing an SFP on an ACPI based system:
Device (SFP0)
{
Name (_HID, "PRP0001")
Name (_CRS, ResourceTemplate()
{
GpioIo(Exclusive, PullDefault, 0,
This allows drivers to lookup i2c adapters on ACPI based systems similar to
of_get_i2c_adapter_by_node() with DT based systems.
Signed-off-by: Ruslan Babayev
Cc: xe-linux-exter...@cisco.com
---
drivers/i2c/i2c-core-acpi.c | 3 ++-
include/linux/i2c.h | 6 ++
2 files changed, 8
Hi Jonathan, Alex,
Thanks for the review. Some comments inline.
Thanks,
Renato
On 05/20, Ardelean, Alexandru wrote:
On Sun, 2019-05-19 at 12:32 +0100, Jonathan Cameron wrote:
[External]
On Sat, 18 May 2019 19:41:12 -0300
Renato Lui Geh wrote:
> This patch adds a YAML binding for the
On 5/24/19 5:22 PM, Frank Rowand wrote:
> On 5/24/19 2:53 PM, Saravana Kannan wrote:
>> On Fri, May 24, 2019 at 10:49 AM Frank Rowand wrote:
>>>
>>> On 5/23/19 6:01 PM, Saravana Kannan wrote:
>
> < snip >
>
>>> Another flaw with this method is that existing device trees
>>> will be broken after
On 5/24/19 2:53 PM, Saravana Kannan wrote:
> On Fri, May 24, 2019 at 10:49 AM Frank Rowand wrote:
>>
>> On 5/23/19 6:01 PM, Saravana Kannan wrote:
< snip >
>> Another flaw with this method is that existing device trees
>> will be broken after the kernel is modified, because existing
>> device
Hi Saravana,
On 5/24/19 2:53 PM, Saravana Kannan wrote:
> On Fri, May 24, 2019 at 10:49 AM Frank Rowand wrote:
>>
>> On 5/23/19 6:01 PM, Saravana Kannan wrote:
< snip >
>
> -Saravana
>
There were several different topics in your email. I am going to do
separate replies for different topics
On 2019/05/25 2:17, Linus Torvalds wrote:
> A config option or two that help syzbot doesn't sound like a bad idea to me.
Thanks for suggestion. I think that #ifdef'ing
static bool suppress_message_printing(int level)
{
return (level >= console_loglevel && !ignore_loglevel);
}
is
On 5/24/19 11:21 AM, Saravana Kannan wrote:
> On Fri, May 24, 2019 at 10:56 AM Frank Rowand wrote:
>>
>> Hi Sarvana,
>>
>> I'm not reviewing patches 1-5 in any detail, given my reply to patch 0.
>>
>> But I had already skimmed through this patch before I received the
>> email for patch 0, so I
On 5/24/19 3:44 PM, shuah wrote:
On 5/24/19 3:40 PM, Tejun Heo wrote:
Hello,
All three patches look good to me. Please feel free to add my
acked-by. Shuah, should I route these through cgroup tree or would
the kselftest tree be a better fit?
Thanks.
Tejun, I can take them through
umonitor, umwait, and tpause are a set of user wait instructions.
umonitor arms address monitoring hardware using an address. The
address range is determined by using CPUID.0x5. A store to
an address within the specified address range triggers the
monitoring hardware to wake up the processor
C0.2 state in umwait and tpause instructions can be enabled or disabled
on a processor through IA32_UMWAIT_CONTROL MSR register.
By default, C0.2 is enabled and the user wait instructions result in
lower power consumption with slower wakeup time.
But in real time systems which requrie faster
Today, if an application needs to wait for a very short duration
they have to have spinloops. Spinloops consume more power and continue
to use execution resources that could hurt its thread siblings in a core
with hyperthreads. New instructions umonitor, umwait and tpause allow
a low power
IA32_UMWAIT_CONTROL[31:2] determines the maximum time in TSC-quanta
that processor can stay in C0.1 or C0.2. A zero value means no maximum
time.
Each instruction sets its own deadline in the instruction's implicit
input EDX:EAX value. The instruction wakes up if the time-stamp counter
reaches or
umwait or tpause allows processor to enter a light-weight
power/performance optimized state (C0.1 state) or an improved
power/performance optimized state (C0.2 state) for a period
specified by the instruction or until the system time limit or until
a store to the monitored address range in umwait.
Since two new sysfs interface files are created for umwait control, add
an ABI document entry for the files:
/sys/devices/system/cpu/umwait_control/enable_c0_2
/sys/devices/system/cpu/umwait_control/max_time
Signed-off-by: Fenghua Yu
Reviewed-by: Ashok Raj
---
Hi Jiri,
Looks this has been discussed in the past.
http://lists.infradead.org/pipermail/linux-nvme/2019-April/023234.html
I created a fix for a case but not good enough.
http://lists.infradead.org/pipermail/linux-nvme/2019-April/023277.html
Perhaps people would have better solution.
Dongli
Add a kselftest to cover bpf auto-detachment functionality.
The test creates a cgroup, associates some resources with it,
attaches a couple of bpf programs and deletes the cgroup.
Then it checks that bpf programs are going away in 5 seconds.
Expected output:
$ ./test_cgroup_attach
This patchset implements a cgroup bpf auto-detachment functionality:
bpf programs are detached as soon as possible after removal of the
cgroup, without waiting for the release of all associated resources.
Patches 2 and 3 are required to implement a corresponding kselftest
in patch 4.
v4:
1)
Convert test_cgrp2_attach2 example into a proper test_cgroup_attach
kselftest. It's better because we do run kselftest on a constant
basis, so there are better chances to spot a potential regression.
Also make it slightly less verbose to conform kselftests output style.
Output example:
$
Enable all available cgroup v2 controllers when setting up
the environment for the bpf kselftests. It's required to properly test
the bpf prog auto-detach feature. Also it will generally increase
the code coverage.
Signed-off-by: Roman Gushchin
Acked-by: Yonghong Song
---
On 2019-05-22, Jan Luebbe wrote:
> Commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in
> /proc/PID/stat") stopped reporting eip/esp and commit fd7d56270b52
> ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping")
> reintroduced the feature to fix a regression with userspace core
On Sat, May 25, 2019 at 12:27:40AM +0300, Alexey Dobriyan wrote:
> What about orthogonality of interfaces?
>
> fdmap()
> bulk_close()
>
> Now fdmap() can be reused for lsof/criu and it is only 2 system calls
> for close-everything usecase which is OK because readdir is 4(!) minimum:
> On May 24, 2019, at 3:41 PM, Sean Christopherson
> wrote:
>
>> On Fri, May 24, 2019 at 02:27:34PM -0700, Andy Lutomirski wrote:
>> On Fri, May 24, 2019 at 1:03 PM Sean Christopherson
>> wrote:
>>>
On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> On Fri, May 24,
Oleg,
Any comments on this patchset?
Eric
This is like commit 0ca87bd5baa6 ("ARM: dts: rockchip: Add pin names
for rk3288-veyron-jerry") and commit ca3516b32cd9 ("ARM: dts:
rockchip: Add pin names for rk3288-veyron-minnie") but for 3 more
veyron boards.
A few notes:
- While there is most certainly duplication between all the veyron
On Fri, May 24, 2019 at 10:20:52AM +0800, Kairui Song wrote:
> On Fri, May 24, 2019 at 1:27 AM Josh Poimboeuf wrote:
> >
> > On Fri, May 24, 2019 at 12:41:59AM +0800, Kairui Song wrote:
> > > On Thu, May 23, 2019 at 11:24 PM Josh Poimboeuf
> > > wrote:
> > > >
> > > > On Thu, May 23, 2019 at
On Fri, May 24, 2019 at 03:15:06PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 08, 2019 at 03:20:03PM +0200, Jiri Olsa escreveu:
> > We mark the end of kernel based on the first module,
> > but that could cover some bpf program maps. Reading
> > _etext symbol if it's present to get
On 5/22/19 6:17 PM, Gen Zhang wrote:
> Hi Andrew,
> I am starting submitting patches these days and got some patches
> "Reviewed-by" from maintainers. After checking the
> submitting-patches.html, I figured out what "Reviewed-by" means. But I
> didn't get the guidance on what to do after getting
The pull request you sent on Fri, 24 May 2019 15:19:29 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
> tags/linux-kselftest-5.2-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7f8b40e3dbcd7dbeabe6be8f157376ef0b890e06
Thank you!
--
The pull request you sent on Fri, 24 May 2019 16:01:21 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> tags/devicetree-fixes-for-5.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e7bd3e248bc36451fdbf2a2e3a3c5a23cd0b1f6f
Thank you!
--
This is the same set of patches sent in the merge window as the final
pull except that Martin's read only rework is replaced with a simple
revert of the original change that caused the regression. Everything
else is an obvious fix or small cleanup.
The patch is available here:
Hi Pavel,
I'm having to revert 0db37915d912 ("leds: avoid races with workqueue")
from my 5.2-rc testing tree, because lockdep and other debug options
don't like it: net/mac80211/led.c arranges for led_blink_setup() to be
called at softirq time, and flush_work() is not good for calling then.
Hugh
On Tue, May 7, 2019 at 9:44 AM Aleksa Sarai wrote:
>
> The most obvious syscall to add support for the new LOOKUP_* scoping
> flags would be openat(2) (along with the required execveat(2) change
> included in this series). However, there are a few reasons to not do
> this:
So honestly, this last
Hi!
Could we hold this patch for now?
> From: Pavel Machek
>
> [ Upstream commit 0db37915d912e8dc6588f25da76d3ed36718d92f ]
>
> There are races between "main" thread and workqueue. They manifest
> themselves on Thinkpad X60:
>
> This should result in LED blinking, but it turns it off
> ---
> Subject: Documentation/atomic_t.txt: Clarify pure non-rmw usage
>
> Clarify that pure non-RMW usage of atomic_t is pointless, there is
> nothing 'magical' about atomic_set() / atomic_read().
>
> This is something that seems to confuse people, because I happen upon it
> semi-regularly.
>
Hi,
static analysis with Coverity has detected a potential issue with the
following commit:
commit 1b3fa5cf859bce7094ac18d32f54af8a7148ad51
Author: Esben Haabendal
Date: Thu May 23 14:02:21 2019 +0200
net: ll_temac: Cleanup multicast filter on change
In function temac_set_multicast_list
On Fri, May 24, 2019 at 02:27:34PM -0700, Andy Lutomirski wrote:
> On Fri, May 24, 2019 at 1:03 PM Sean Christopherson
> wrote:
> >
> > On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> > > On Fri, May 24, 2019 at 11:34 AM Xing, Cedric
> > > wrote:
> > > >
> > > > If "initial
On Fri, May 24, 2019 at 2:17 PM Jay Vosburgh wrote:
>
> Jarod Wilson wrote:
>
> >Once in a while, with just the right timing, 802.3ad slaves will fail to
> >properly initialize, winding up in a weird state, with a partner system
> >mac address of 00:00:00:00:00:00. This started happening after a
1 - 100 of 915 matches
Mail list logo
