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, 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 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, 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 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
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
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
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
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
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 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
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 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 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
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 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
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 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 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 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 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
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
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
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
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 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
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 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 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
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, 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. ;-)
--
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
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.
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
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 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
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 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
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
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
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
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
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 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.
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
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 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
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
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 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:
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 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
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 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
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 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
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 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.
>
>
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: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
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 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
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 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 asc7621 to ReST format, in order to allow it to
be parsed by Sphinx.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/hwmon/asc7621 | 146 ++--
1 file changed, 88 insertions(+), 58 deletions(-)
diff --git a/Documentation/hwmon/asc7621
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
Convert dme1737 and vt1211 to ReST format, in order to allow
them to be parsed by Sphinx.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/hwmon/dme1737 | 88 ++---
Documentation/hwmon/vt1211 | 84 +--
2 files changed, 114
Convert ibmpowernv to ReST format, in order to allow it to
be parsed by Sphinx.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/hwmon/ibmpowernv | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv
index
Convert w83791d to ReST format, in order to allow it to
be parsed by Sphinx.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/hwmon/w83791d | 123 +---
1 file changed, 71 insertions(+), 52 deletions(-)
diff --git a/Documentation/hwmon/w83791d
From: Jérôme Glisse
CIFS can leak pages reference gotten through GUP (get_user_pages*()
through iov_iter_get_pages()). This happen if cifs_send_async_read()
or cifs_write_from_iter() calls fail from within __cifs_readv() and
__cifs_writev() respectively. This patch move page unreference to
On 4/10/2019 10:53 AM, Stephen Boyd wrote:
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
Hurph, I was still looking at v2.. I suppose I'll go stare at this
verison, I don't think you said there were many changes, right?
This version seems to still suffer that HANDOFF issue I found on v2.
On Wed, Apr 10, 2019 at 02:42:21PM -0400, Waiman Long wrote:
> Because of writer lock
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Wednesday, April 10, 2019 12:26 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
> Subject: Re: [PATCH
Adding more Cc and stable (i thought this was 5.1 addition). Note that
without this patch on arch/kernel where PAGE_SIZE != 4096 userspace
could read random memory through a zram block device (thought userspace
probably would have no control on the address being read).
On Mon, Apr 08, 2019 at
Hi Morten,
> On Apr 10, 2019, at 4:59 AM, Morten Rasmussen
> wrote:
>
> Hi,
>
> On Mon, Apr 08, 2019 at 02:45:32PM -0700, Song Liu wrote:
>> Servers running latency sensitive workload usually aren't fully loaded for
>> various reasons including disaster readiness. The machines running our
On Wed, Apr 10, 2019 at 8:11 AM Al Viro wrote:
>
> Both are in vfs.git#fixes. Which way should that go - directly or
> via linux-security.git?
Just do it directly. I doubt you can trigger them for securityfs and
apparmourfs, since normal users have no way to remove any files from
them, so the
On Wed, Apr 10, 2019 at 02:22:21PM -0400, Liang, Kan wrote:
> > > That is, are there really bits we want to mask in there?
> >
> > For instruction event, right, we don't need mask it.
> > I will change it.
> >
>
> Actually, we have to mask some bits here, e.g. ARCH_PERFMON_EVENTSEL_INT,
>
On Wed, Apr 10, 2019 at 09:49:54AM +0300, Dan Carpenter wrote:
> On Tue, Apr 09, 2019 at 11:16:17AM -0500, Madhumitha Prabakaran wrote:
> > diff --git a/drivers/staging/rtl8723bs/include/drv_types.h
> > b/drivers/staging/rtl8723bs/include/drv_types.h
> > index bafb2c30e7fb..b0623c936940 100644
>
On Wed, Apr 10, 2019 at 7:44 AM Brian Norris wrote:
>
> I think our key difference here is in how much we trust the device:
> knowing the quality of the firmware running on some of these devices,
> I wouldn't totally trust that they get it right.
No.
You claim that IRQ_NOAUTOEN makes any
Hi Dave,
I wonder if you can take this.
Thanks
--
Gustavo
On 1/8/19 10:13 AM, Gustavo A. R. Silva wrote:
> 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
On Wed, Apr 10, 2019 at 11:46:24AM -0700, Joe Perches wrote:
> 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
>
The pull request you sent on Wed, 10 Apr 2019 18:46:23 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/582549e3fbe137eb6ce9be591aca25ca36b4
Thank you!
--
Deet-doot-dot, I am a
On Wed, Apr 10, 2019 at 1:47 AM Yue Haibing wrote:
>
> From: YueHaibing
>
> When building with CONFIG_GPIOLIB is not set
> gcc warns this:
>
> drivers/iio/adc/ti-ads7950.c:75:19: error: field chip has incomplete type
> struct gpio_chip chip;
>^~~~
>
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
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:
501 - 600 of 880 matches
Mail list logo
