On Wed, Apr 10, 2019 at 8:46 PM Kees Cook wrote:
>
> On Mon, Apr 8, 2019 at 3:09 PM Matteo Croce wrote:
> >
> > Use the shared variables for range check, instead of declaring a local one
> > in every source file.
>
> I was expecting this to be a tree-wide change for all the cases found
> by
Convert menf21bmc to ReST format, in order to allow it to
be parsed by Sphinx.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/hwmon/menf21bmc | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/hwmon/menf21bmc b/Documentation/hwmon/menf21bmc
index
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Thanks and Best Regards,
Daniel Murray
On Wed, Apr 10, 2019 at 03:08:21PM -0400, Joel Fernandes (Google) wrote:
> For the purposes of hardening modules by adding sections to
> ro_after_init sections, prepare for addition of new ro_after_init
> entries which we do in future patches. Create a table to which new
> entries could be added
Since commit title ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
modules"), modules that call DEFINE_{STATIC,}SRCU will have a new array
of srcu_struct pointers which is used by srcu code to initialize and
clean up these structures.
There is no reason for this array of pointers to be
For the purposes of hardening modules by adding sections to
ro_after_init sections, prepare for addition of new ro_after_init
entries which we do in future patches. Create a table to which new
entries could be added later. This makes it less error prone and reduce
code duplication.
Cc:
This series hardens the tracepoints in modules by making the array of
pointers referring to the tracepoints as read-only. This array is needed
during module unloading to verify that the tracepoint is quiescent.
There is no reason for the array to be to be writable after init, and
can cause
On Wed, Apr 10, 2019 at 6:14 PM Steven Rostedt wrote:
> On Wed, 10 Apr 2019 18:03:57 +0200 Martin Schwidefsky
> wrote:
>
> > > --- a/arch/s390/include/asm/ftrace.h
> > > +++ b/arch/s390/include/asm/ftrace.h
> > > @@ -13,7 +13,12 @@
> > >
> > > #ifndef __ASSEMBLY__
> > >
> > > +#ifdef
On Tue, Apr 09, 2019 at 05:32:07PM -0500, Thor Thayer wrote:
> I have ACKs on patches 1 & 3. Patch 2 has a Reviewed-by from Rob Herring
> which was sufficient in the past.
Sorry about that - I missed those because I looked only at the diffstat
and decided this series is not for me :)
Anyway, all
On Wed, Apr 10, 2019 at 6:26 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Mon, Apr 8, 2019 at 2:27 PM Arnd Bergmann wrote:
> >
> > clang does not support 31 bit object files on s390, so skip
> > the 32-bit vdso here, and only build it when using gcc to compile
> > the kernel.
>
>
From: Kan Liang
The patch series intends to add Tremont support for Linux perf.
The patch series is on top of Icelake V5 patch series (with Peter's cleanup
patch).
https://lkml.org/lkml/2019/4/8/630
PATCH 1: A fix for Icelake V5 patch series (with Peter's cleanup patch).
It can be
From: Kan Liang
Add perf core PMU support for Intel Tremont CPU.
The init code is based on Goldmont plus.
The generic purpose counter 0 and fixed counter 0 have less skid.
Force :ppp events on generic purpose counter 0.
Force instruction:ppp on generic purpose counter 0 and fixed counter 0.
From: Kan Liang
Some bits must be masked before checking X86_CONFIG(.event=0xc0), e.g.
ARCH_PERFMON_EVENTSEL_INT, ARCH_PERFMON_EVENTSEL_USR and
ARCH_PERFMON_EVENTSEL_OS. Those bits will be set in hw_config().
Otherwise the condition will never be met.
Other fields, e.g the INV, ANY, E, or CMASK
On Wed, Apr 10, 2019 at 5:59 PM Martin Schwidefsky
wrote:
> On Tue, 9 Apr 2019 11:54:30 +0200 Harald Freudenberger
> wrote:
> > On 08.04.19 23:26, Arnd Bergmann wrote:
> > > }
> > Thanks Arnd, but as Nathan already wrote, I'd prefer to have the
> > variable initialized with 0
On Wed, Apr 10, 2019 at 3:55 PM Martin Schwidefsky
wrote:
>
> On Mon, 8 Apr 2019 23:26:25 +0200
> Arnd Bergmann wrote:
>
> > diff --git a/arch/s390/include/asm/processor.h
> > b/arch/s390/include/asm/processor.h
> > index 700c650ffd4f..84c59c99668a 100644
> > ---
On 4/10/19 1:29 AM, xiaojiangfeng wrote:
> The type of variable l in early_init_dt_scan_chosen is
> int, there is no need to convert to int.
>
> Signed-off-by: xiaojiangfeng
> ---
> drivers/of/fdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/watchdog/machzwd.c: In function ‘zf_set_timer’:
./arch/x86/include/asm/io.h:355:14: warning: this statement may fall through
On Fri, Mar 29, 2019 at 1:49 AM Andrey Smirnov wrote:
>
> Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
> clock to determine if it needs to configure the IP block as operating
> at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
> clocks as
On Wed, 2019-04-10 at 09:27 -0700, Guenter Roeck wrote:
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
>
On Mon, Apr 8, 2019 at 3:09 PM Matteo Croce wrote:
>
> Use the shared variables for range check, instead of declaring a local one
> in every source file.
I was expecting this to be a tree-wide change for all the cases found
by patch 1's "git grep".
Slight change to the grep for higher accuracy:
Hi Linus,
Second rc pull request
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:
Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus
for you to fetch
On Fri, Apr 05, 2019 at 03:21:05PM -0400, Waiman Long wrote:
> Because of writer lock stealing, it is possible that a constant
> stream of incoming writers will cause a waiting writer or reader to
> wait indefinitely leading to lock starvation.
>
> The mutex code has a lock handoff mechanism to
This patch modifies rwsem_spin_on_owner() to return four possible
values to better reflect the state of lock holder which enables us to
make a better decision of what to do next.
In the special case that there is no active lock and the handoff bit
is set, optimistic spinning has to be stopped.
The owner field in the rw_semaphore structure is used primarily for
optimistic spinning. However, identifying the rwsem owner can also be
helpful in debugging as well as tracing locking related issues when
analyzing crash dump. The owner field may also store state information
that can be important
Because of writer lock stealing, it is possible that a constant
stream of incoming writers will cause a waiting writer or reader to
wait indefinitely leading to lock starvation.
The mutex code has a lock handoff mechanism to prevent lock starvation.
This patch implements a similar lock handoff
This patch enables readers to optimistically spin on a
rwsem when it is owned by a writer instead of going to sleep
directly. The rwsem_can_spin_on_owner() function is extracted
out of rwsem_optimistic_spin() and is called directly by
__rwsem_down_read_failed_common() and
With separate count and owner, there are timing windows where the two
values are inconsistent. That can cause problem when trying to figure
out the exact state of the rwsem. For instance, a RT task will stop
optimistic spinning if the lock is acquired by a writer but the owner
field isn't set yet.
The upper bits of the count field is used as reader count. When
sufficient number of active readers are present, the most significant
bit will be set and the count becomes negative. If the number of active
readers keep on piling up, we may eventually overflow the reader counts.
This is not likely
With the commit 59aabfc7e959 ("locking/rwsem: Reduce spinlock contention
in wakeup after up_read()/up_write()"), the rwsem_wake() forgoes doing
a wakeup if the wait_lock cannot be directly acquired and an optimistic
spinning locker is present. This can help performance by avoiding
spinning on the
On 64-bit architectures, each rwsem writer will have its unique lock
word for acquiring the lock. Right now, the writer code recomputes the
lock word every time it tries to acquire the lock. This is a waste of
time. The lock word is now cached and reused when it is needed.
On 32-bit
When the front of the wait queue is a reader, other readers
immediately following the first reader will also be woken up at the
same time. However, if there is a writer in between. Those readers
behind the writer will not be woken up.
Because of optimistic spinning, the lock acquisition order is
Before combining owner and count, we are adding two new helpers for
accessing the owner value in the rwsem.
1) struct task_struct *rwsem_get_owner(struct rw_semaphore *sem)
2) bool is_rwsem_reader_owned(struct rw_semaphore *sem)
Signed-off-by: Waiman Long
---
kernel/locking/rwsem-xadd.c | 15
An RT task can do optimistic spinning only if the lock holder is
actually running. If the state of the lock holder isn't known, there
is a possibility that high priority of the RT task may block forward
progress of the lock holder if it happens to reside on the same CPU.
This will lead to
When the rwsem is owned by reader, writers stop optimistic spinning
simply because there is no easy way to figure out if all the readers
are actively running or not. However, there are scenarios where
the readers are unlikely to sleep and optimistic spinning can help
performance.
This patch
v3:
- Add 2 more patches in front to fix build and testing issues found.
Patch 1 can actually be merged on top of the patch "locking/rwsem:
Enhance DEBUG_RWSEMS_WARN_ON() macro" in part 1.
- Change the handoff patch (now patch 4) to set handoff bit immediately
after wakeup for RT
The current way of using various reader, writer and waiting biases
in the rwsem code are confusing and hard to understand. I have to
reread the rwsem count guide in the rwsem-xadd.c file from time to
time to remind myself how this whole thing works. It also makes the
rwsem code harder to be
Disable the DEBUG_RWSEMS check when locking selftest is running with
debug_locks_silent flag set.
Signed-off-by: Waiman Long
---
kernel/locking/rwsem.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
index
On Tue, Mar 19, 2019 at 01:47:29PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> As per PCI firmware specification v3.2 ECN
> (https://members.pcisig.com/wg/PCI-SIG/document/12614), when firmware
> owns Downstream Port Containment (DPC), its
On 2019-04-10 17:45, Doug Anderson wrote:
> Hi,
>
> On Fri, Mar 29, 2019 at 2:55 PM Douglas Anderson
> wrote:
>> It appears that there is a typo in the rk3288 TRM. For
>> GRF_SOC_CON0[7] it says that 0 means "vepu" and 1 means "vdpu". It's
>> the other way around.
>>
>> How do I know? Here's
On Fri, 05 Apr 2019, Waiman Long wrote:
With the commit 59aabfc7e959 ("locking/rwsem: Reduce spinlock contention
in wakeup after up_read()/up_write()"), the rwsem_wake() forgoes doing
a wakeup if the wait_lock cannot be directly acquired and an optimistic
spinning locker is present. This can
Johan,
On 4/4/19 2:24 AM, Johan Hovold wrote:
> On Thu, Apr 04, 2019 at 08:09:51AM +0100, Rui Miguel Silva wrote:
>> Hi Gustavo,
>> Thanks a lot for the patch.
>>
>> On Wed 03 Apr 2019 at 21:58, Gustavo A. R. Silva wrote:
>>> Make use of the struct_size() helper instead of an open-coded
>>>
On Wed, Apr 10, 2019 at 12:33 AM Alexandre Ghiti wrote:
>
> On 04/10/2019 08:59 AM, Christoph Hellwig wrote:
> > On Thu, Apr 04, 2019 at 01:51:25AM -0400, Alexandre Ghiti wrote:
> >> - fix the case where stack randomization should not be taken into
> >>account.
> > Hmm. This sounds a bit
Some veyron devices have a Bluetooth controller connected on UART0.
The UART needs to operate at a high speed, however setting the clock
rate at initialization has no practical effect. During initialization
user space adjusts the UART baudrate multiple times, which ends up
changing the SCLK rate.
Hi Johan,
On 4/4/19 1:57 AM, Johan Hovold wrote:
>
> This patch looks good, but I noticed a bug here in the current code,
> which should be fixed before applying this clean up.
>
> sizeof(req) should have been sizeof(*req) above.
>
Good catch.
>> - sizeof(struct
On Wed, 10 Apr 2019 11:21:23 -0700
Kees Cook wrote:
> On Wed, Apr 10, 2019 at 10:48 AM Joel Fernandes
> wrote:
> > Thanks, if you are Ok with it, I will add your Reviewed-by tag as well.
>
> With those fixes, absolutely. :) Thanks!
>
I'll wait for v2 before adding my reviewed-by. ;-)
--
From: Colin Ian King
Currently if mask is neither CHAN_INFO_RAW or CHAN_INFO_SCALE then
then an uninitialized error return 'ret' is returned. Fix this by
adding a default case that ensures -EINVAL is returned for this
specific case.
Addresses-Coverity: ("Uninitialized scalar variable")
On Wed, Apr 10, 2019 at 11:50:52AM -0400, Joe Lawrence wrote:
>
> [ ... snip ... ]
>
> diff --git a/scripts/livepatch/klp-convert.c b/scripts/livepatch/klp-convert.c
> new file mode 100644
> index ..62bd26941081
> --- /dev/null
> +++ b/scripts/livepatch/klp-convert.c
>
> [ ... snip
On 4/8/2019 11:45 AM, Liang, Kan wrote:
On 4/8/2019 11:06 AM, Peter Zijlstra wrote:
On Tue, Apr 02, 2019 at 12:45:05PM -0700, kan.li...@linux.intel.com
wrote:
+static struct event_constraint *
+icl_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
+ struct perf_event
On Wed, Apr 10, 2019 at 10:48 AM Joel Fernandes wrote:
> Thanks, if you are Ok with it, I will add your Reviewed-by tag as well.
With those fixes, absolutely. :) Thanks!
--
Kees Cook
On Wed, Apr 10, 2019 at 11:50:53AM -0400, Joe Lawrence wrote:
> From: Josh Poimboeuf
>
> Define macros KLP_MODULE_RELOC and KLP_SYMPOS in
> include/linux/livepatch.h to improve user-friendliness of the
> livepatch annotation process.
>
> Signed-off-by: Josh Poimboeuf
> Signed-off-by: Joao
From: Maciej Żenczykowski
Memory: 509108K/542612K available (3835K kernel code, 919K rwdata, 1028K
rodata, 129K init, 211K bss, 33504K reserved, 0K cma-reserved)
NR_IRQS: 15
clocksource: timer: mask: 0x max_cycles: 0x1cd42e205,
max_idle_ns: 881590404426 ns
[ cut
On Tue, Mar 26, 2019 at 01:45:52AM +, Al Viro wrote:
> On Mon, Mar 25, 2019 at 11:37:32PM +, Al Viro wrote:
>
> > For debugfs it's clearly "use default ->evict_inode(), have explicit
> > ->destroy_inode() using free_inode_nonrcu()" - there we have nothing
> > else done in ->evict_inode()
From: Maciej Żenczykowski
Memory: 509108K/542612K available (3835K kernel code, 919K rwdata, 1028K
rodata, 129K init, 211K bss, 33504K reserved, 0K cma-reserved)
NR_IRQS: 15
clocksource: timer: mask: 0x max_cycles: 0x1cd42e205,
max_idle_ns: 881590404426 ns
[ cut
On Wed, Apr 10, 2019 at 09:18:50AM +0800, Huang Shijie wrote:
> On Tue, Apr 09, 2019 at 01:23:16PM -0700, Ira Weiny wrote:
> > On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> > > On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > > > On Mon, Apr 08, 2019 at
Hi,
On 4/9/19 4:25 AM, Andy Shevchenko wrote:
Since we have a proper fix for intel_pmc_ipc driver for resource management,
get rid of unneeded commit in the intel_punit_ipc driver.
This reverts commit 6cc8cbbc8868033f279b63e98b26b75eaa0006ab.
Reviewed-by: Kuppuswamy Sathyanarayanan
Hi,
On 4/9/19 4:25 AM, Andy Shevchenko wrote:
The intel_pmc_ipc driver has a placeholder for all possible resources
that may have been provided by ACPI. Since there are few optional ones,
the driver still uses them and binds to wrong ranges in resource tree:
# grep intel_punit_ipc
- On Apr 10, 2019, at 1:57 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Wed, Apr 10, 2019 at 11:47:40AM -0400, Mathieu Desnoyers wrote:
>> - On Apr 10, 2019, at 2:54 AM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Tue, Apr 09, 2019 at 04:43:42PM -0400, Mathieu Desnoyers
On Wed, Apr 10, 2019 at 09:20:36AM +0800, Huang Shijie wrote:
> On Tue, Apr 09, 2019 at 02:55:31PM +, Weiny, Ira wrote:
> > > On Tue, Apr 09, 2019 at 11:04:18AM +0800, Huang Shijie wrote:
> > > > On Mon, Apr 08, 2019 at 07:49:29PM -0700, Matthew Wilcox wrote:
> > > > > On Tue, Apr 09, 2019 at
On Thu, Apr 11, 2019 at 03:34:43AM +1000, James Morris wrote:
> On Fri, 15 Mar 2019, Kangjie Lu wrote:
>
> > securityfs_create_file may fail. The fix checks its status and
> > returns the error code upstream if it fails.
> >
> > Signed-off-by: Kangjie Lu
> >
>
> Applied to
>
On Wed, Apr 10, 2019 at 8:13 AM Chunfeng Yun wrote:
>
> Use devm_clk_get_optional() to get optional clock
>
> Cc: Martin Blumenstingl
> Signed-off-by: Chunfeng Yun
> Acked-by: Martin Blumenstingl
now also:
Tested-by: Martin Blumenstingl
(on my Khadas VIM by manually adjusting meson-gxl.dtsi
On Wed, Apr 10, 2019 at 11:47:40AM -0400, Mathieu Desnoyers wrote:
> - On Apr 10, 2019, at 2:54 AM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Tue, Apr 09, 2019 at 04:43:42PM -0400, Mathieu Desnoyers wrote:
> >> +/*
> >> + * RSEQ_SIG is used with the following privileged
On 4/10/19 6:59 AM, Andy Shevchenko wrote:
On Tue, Apr 09, 2019 at 08:39:39PM +0300, Andy Shevchenko wrote:
On Tue, Apr 09, 2019 at 10:07:35AM -0700, sathyanarayanan kuppuswamy wrote:
On 4/9/19 4:25 AM, Andy Shevchenko wrote:
Use BIT() and BIT_MASK() macros for definitions.
Looks good to
Hi Liang,
On Wed, Apr 10, 2019 at 1:08 PM Liang Yang wrote:
>
> Hi Martin,
>
> On 2019/4/5 12:30, Martin Blumenstingl wrote:
> > Hi Liang,
> >
> > On Fri, Mar 29, 2019 at 8:44 AM Liang Yang wrote:
> >>
> >> Hi Martin,
> >>
> >> On 2019/3/29 2:03, Martin Blumenstingl wrote:
> >>> Hi Liang,
> >>
On 04/10/2019 01:31 PM, Davidlohr Bueso wrote:
> On Wed, 10 Apr 2019, Bueso wrote:
>
>> On Wed, 10 Apr 2019, Waiman Long wrote:
>>> 2) I want to avoid the extreme case that there are more than 32k
>>> readers
>>> in the wait queue and make the count overflow.
>>
>> But in this case the readers are
On 04/10/2019 01:22 PM, Davidlohr Bueso wrote:
> On Wed, 10 Apr 2019, Waiman Long wrote:
>> There are 2 major reasons why there is a limit.
>>
>> 1) It will be unfair to the task that needs to spend so much of its own
>> CPU time to wake up too many readers.
>
> This has never been a problem
On Wed, Apr 10, 2019 at 10:57 PM Maxime Ripard
wrote:
>
> On Tue, Apr 09, 2019 at 01:25:58PM -0400, Yangtao Li wrote:
> > Allwinner Process Voltage Scaling Tables defines the voltage and
> > frequency value based on the speedbin blown in the efuse combination.
> > The sunxi-cpufreq-nvmem driver
On Wed, Apr 10, 2019 at 09:26:44AM -0700, Kees Cook wrote:
> On Tue, Apr 9, 2019 at 6:14 PM Joel Fernandes (Google)
> wrote:
> >
> > For the purposes of hardening modules by adding sections to
> > ro_after_init sections, prepare for addition of new ro_after_init
> > entries which we do in future
Hi Joe,
On Wed, Apr 10, 2019 at 09:52:09AM -0700, Joe Perches wrote:
> On Wed, 2019-04-10 at 09:28 -0700, Guenter Roeck wrote:
> > Introduce local variable 'struct device *dev' and use it instead of
> > dereferencing it repeatedly. Also, there is no call to dev_get_drvdata()
> > or
On Wed, Apr 10, 2019 at 11:24 AM Viresh Kumar wrote:
>
> On 09-04-19, 13:25, Yangtao Li wrote:
> > +static const struct sunxi_cpufreq_soc_data sun50i_h6_data = {
> > + .efuse_xlate = sun50i_efuse_xlate,
> > + .nvmem_mask = 0x7,
> > + .nvmem_shift = 5,
> > +};
> > +
> > +static const
On Tue, Apr 9, 2019 at 8:43 PM Linus Torvalds
wrote:
> Either it's edge-triggered and you'll get one possibly spurious
> interrupt for an old issue, or it's level-triggered and setting up the
> hw should bring the irq line inactive and you'll be ok.
I think our key difference here is in how much
On Tue, Apr 09, 2019 at 04:40:03PM -0400 Joel Savitz wrote:
> If a process is limited by taskset (i.e. cpuset) to only be allowed to
> run on cpu N, and then cpu N is offlined via hotplug, the process will
> be assigned the current value of its cpuset cgroup's effective_cpus field
> in a call to
As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
tests, we need to ensure that the H1 chip is properly setting
some GPIO lines. The h1_gpio attribute exposes the state
of the lines:
- ENTRY_TO_FACT_MODE in BIT(0)
- SPI_CHROME_SEL in BIT(1)
There are two reasons that I am exposing
Add sunxi nvmem based CPU scaling driver, refers to qcom-cpufreq-kryo.
Yangtao Li (2):
cpufreq: Add sunxi nvmem based CPU scaling driver
dt-bindings: cpufreq: Document allwinner,cpu-operating-points-v2
.../bindings/opp/sunxi-nvmem-cpufreq.txt | 168 +
MAINTAINERS
For some SoCs, the CPU frequency subset and voltage value of each OPP
varies based on the silicon variant in use. The sunxi-cpufreq-nvmem
driver reads the efuse value from the SoC to provide the OPP framework
with required information.
Signed-off-by: Yangtao Li
---
MAINTAINERS
Allwinner Process Voltage Scaling Tables defines the voltage and
frequency value based on the speedbin blown in the efuse combination.
The sunxi-cpufreq-nvmem driver reads the efuse value from the SoC to
provide the OPP framework with required information.
This is used to determine the voltage and
On Wed, Apr 10, 2019 at 12:04:32PM -0400, Sasha Levin wrote:
> On Wed, Apr 10, 2019 at 02:29:27PM +0300, Jarkko Sakkinen wrote:
> > On Sat, Apr 06, 2019 at 11:30:47AM -0400, Sasha Levin wrote:
> > > On Wed, Apr 03, 2019 at 09:27:28PM +0300, Jarkko Sakkinen wrote:
> > > > On Wed, Apr 03, 2019 at
On Wed, 27 Mar 2019, Mukesh Ojha wrote:
> Sparse complains yama_task_prctl can be static. Fix it by making
> it static.
>
> Signed-off-by: Mukesh Ojha
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
next-general
--
James Morris
On Fri, 15 Mar 2019, Kangjie Lu wrote:
> securityfs_create_file may fail. The fix checks its status and
> returns the error code upstream if it fails.
>
> Signed-off-by: Kangjie Lu
>
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
next-general
> ---
>
On Wed, 10 Apr 2019, Bueso wrote:
On Wed, 10 Apr 2019, Waiman Long wrote:
2) I want to avoid the extreme case that there are more than 32k readers
in the wait queue and make the count overflow.
But in this case the readers are already on the queue.
Never mind this.
But the limit could
On Wed, Apr 10, 2019 at 12:55 AM Yue Haibing wrote:
>
> From: YueHaibing
>
> If CONFIG_TEST_KMOD is set to M, while CONFIG_BLOCK is not set,
> XFS and BTRFS can not be compiled successly.
>
> Reported-by: Hulk Robot
> Fixes: d9c6a72d6fa2 ("kmod: add test driver to stress test the module
On Wed, 27 Mar 2019, Jann Horn wrote:
> The current code can perform concurrent updates and reads on
> user->session_keyring and user->uid_keyring. Add a comment to
> struct user_struct to document the nontrivial locking semantics, and use
> READ_ONCE() for unlocked readers and
On Wed, 27 Mar 2019, Jann Horn wrote:
> sparse complains that a bunch of places in kernel/cred.c access
> cred->session_keyring without the RCU helpers required by the __rcu
> annotation.
>
> cred->session_keyring is written in the following places:
>
> - prepare_kernel_cred() [in a new cred
On Wed, 27 Mar 2019, Jann Horn wrote:
> sparse complains that Yama defines functions and a variable as non-static
> even though they don't exist in any header. Fix it by making them static.
>
> Signed-off-by: Jann Horn
Applied to
On Wed, Apr 10, 2019 at 04:58:12PM +, Ghannam, Yazen wrote:
> Yes, unused banks in the middle are counted in the MCG_CAP[Count] value.
Good.
> Okay, so you're saying the sysfs access should fail if a bank is
> disabled. Is that correct?
Well, think about it. If a bank is not operational for
On Wed, 10 Apr 2019, Waiman Long wrote:
There are 2 major reasons why there is a limit.
1) It will be unfair to the task that needs to spend so much of its own
CPU time to wake up too many readers.
This has never been a problem before.
2) I want to avoid the extreme case that there are more
On Tue, 09 Apr 2019 23:09:03 PDT (-0700), a...@brainfault.org wrote:
On Tue, Apr 9, 2019 at 10:14 PM Palmer Dabbelt wrote:
On Tue, 12 Mar 2019 15:08:12 PDT (-0700), Anup Patel wrote:
> This patch adds rv32_defconfig for 32bit systems. The only
> difference between rv32_defconfig and defconfig
On 10/04/19 16:57, Sean Christopherson wrote:
> On Wed, Apr 10, 2019 at 12:55:53PM +, David Laight wrote:
>> From: Paolo Bonzini
>>> Sent: 10 April 2019 10:55
>>>
>>> This check will soon be done on every nested vmentry and vmexit,
>>> "parallelize" it using bitwise operations.
>>>
>>>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
On 04/10/2019 12:50 PM, Davidlohr Bueso wrote:
> On Fri, 05 Apr 2019, Waiman Long wrote:
>
>> When the front of the wait queue is a reader, other readers
>> immediately following the first reader will also be woken up at the
>> same time. However, if there is a writer in between. Those readers
>>
On Wed, 10 Apr 2019 18:18:43 +0200
Miquel Raynal wrote:
> Hi YueHaibing,
>
> YueHaibing wrote on Wed, 10 Apr 2019 23:03:24
> +0800:
>
> > On 2019/4/10 22:29, Boris Brezillon wrote:
> > > On Wed, 10 Apr 2019 22:22:16 +0800
> > > YueHaibing wrote:
> > >
> > >> On 2019/4/10 21:58, Boris
On Thu, Apr 04, 2019 at 10:02:07AM +0800, YueHaibing wrote:
> On 2019/4/3 23:36, Jordan Crouse wrote:
> > On Wed, Apr 03, 2019 at 02:48:11PM +0800, Yue Haibing wrote:
> >> From: YueHaibing
> >>
> >> When building CONFIG_DEBUG_FS is not set
> >> gcc warn this:
> >>
> >>
Hi Tony,
can you ask for an acked-by before pulling a patch in your tree?
On 04/04/2019 16:17, Tony Lindgren wrote:
> * Ladislav Michl [190327 08:12]:
>> Hello Nathan,
>>
>> On Tue, Mar 26, 2019 at 10:01:27PM -0700, Nathan Chancellor wrote:
>>> Commit 008258d995a6
On Wed, Apr 10, 2019 at 11:19 AM Sasha Levin wrote:
>
> On Tue, Apr 09, 2019 at 04:18:29PM -0500, Rob Herring wrote:
> >On Tue, Apr 9, 2019 at 1:50 PM Sasha Levin wrote:
> >>
> >> The parameters are similar to the ones used by IBM's vTPM and the
> >> various I2C tpm drivers.
> >
> >Bindings
> -Original Message-
> From: Borislav Petkov
> Sent: Wednesday, April 10, 2019 11:41 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
> Subject: Re: [PATCH RESEND 2/5] x86/MCE: Handle MCA controls in a per_cpu
Quoting Jeffrey Hugo (2019-04-08 14:46:11)
> On 4/4/2019 3:53 PM, Stephen Boyd wrote:
> > In some circumstances drivers register clks early and don't have access
> > to a struct device because the device model isn't initialized yet. Add
> > an API to let drivers register clks associated with a
On Wed, 10 Apr 2019 12:46:12 -0400
"Michael S. Tsirkin" wrote:
> On Wed, Apr 10, 2019 at 04:31:39PM +0200, Cornelia Huck wrote:
> > On Wed, 10 Apr 2019 10:03:01 -0400 (EDT)
> > Pankaj Gupta wrote:
> >
> > > >
> > > > On Wed, Apr 10, 2019 at 09:38:22AM +0530, Pankaj Gupta wrote:
> > > >
On Wed, Apr 10, 2019 at 06:36:15PM +0200, Borislav Petkov wrote:
> Well, this is going in the wrong direction. The proper thing to do would
> be to have:
>
> rdpkru()
> wrpkru()
>
> which only do the inline asm with the respective opcodes. Just like
> rdtsc(), clflush(), etc.
IOW, like this:
On Wed, 2019-04-10 at 09:28 -0700, Guenter Roeck wrote:
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly. Also, there is no call to dev_get_drvdata()
> or platform_get_drvdata() in the driver, so drop the unnecessary
> call to
On Thu, Mar 21, 2019 at 03:29:19PM +0530, Kishon Vijay Abraham I wrote:
> This series tries to address the comments discussed in [1] w.r.t
> removing Keystone specific callbacks defined in dw_pcie_host_ops.
>
> This series also tries to cleanup the Keystone interrupt handling
> part.
>
> Changes
On Fri, 05 Apr 2019, Waiman Long wrote:
When the front of the wait queue is a reader, other readers
immediately following the first reader will also be woken up at the
same time. However, if there is a writer in between. Those readers
behind the writer will not be woken up.
Because of
301 - 400 of 880 matches
Mail list logo