Στις 2019-03-13 00:08, Anup Patel έγραψε:
Currently, we have to boot RISCV64 kernel from a 2MB aligned physical
address and RISCV32 kernel from a 4MB aligned physical address. This
constraint is because initial pagetable setup (i.e. setup_vm()) maps
entire RAM using hugepages (i.e. 2MB for
On Wed, Apr 10, 2019 at 2:12 PM Al Viro wrote:
>
> On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote:
>
> > > I'm unable to find a branch matching the line numbers.
> > >
> > > Given that, on the face of it, the scenario is impossible I'm
> > > seeking clarification on what linux-next to
On Wed, Apr 10, 2019 at 2:07 PM Ian Kent wrote:
>
> On Wed, 2019-04-10 at 19:57 +0800, Ian Kent wrote:
> > On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote:
> > > On Wed, Apr 10, 2019 at 12:35 PM Ian Kent wrote:
> > > >
> > > > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > >
On 04/10/2019 06:00 AM, Ingo Molnar wrote:
> * Waiman Long wrote:
>
>># of Threads Before Patch After Patch
>> ---
>> 21,179 9,436
>> 41,505 8,268
>> 8 721
Em Tue, Mar 19, 2019 at 04:56:53PM +0800, Jin Yao escreveu:
> Add a 'percore' event qualifier, like cpu/event=0,umask=0x3,percore=1/,
> that sums up the event counts for both hardware threads in a core.
>
> We can already do this with --per-core, but it's often useful to do
> this together with
On Wed, Apr 10, 2019 at 12:30:37PM +, Naga Sureshkumar Relli wrote:
> > Yeah, I'm surprised that builds...
> Sorry, I tested with CONFIG_SPI_MEM enabled. It's my bad.
I also see that I'd queued an earlier version for application. I've
lost track of whatever issues there were with that,
Hi,
> -Original Message-
> From: linux-spi-ow...@vger.kernel.org On
> Behalf Of
> Mark Brown
> Sent: Wednesday, April 10, 2019 5:55 PM
> To: YueHaibing
> Cc: Naga Sureshkumar Relli ; vigne...@ti.com; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; Michal Simek
> ;
>
On Wed, Apr 10, 2019 at 12:14:55PM +0200, David Hildenbrand wrote:
> While current node handling is probably terribly broken for memory block
> devices that span several nodes (only possible when added during boot,
> and something like that should be blocked completely), properly put the
> device
Hi Ingo,
Thanks for taking a look (diff at the end).
On Wed, Apr 10, 2019 at 12:58:33PM +0200, Ingo Molnar wrote:
> * Will Deacon wrote:
>
> > + (*) readX(), writeX():
> >
> > + The readX() and writeX() MMIO accessors take a pointer to the
> > peripheral
> > + being accessed as an
The patch
regulator: hi655x: Constify regulators array
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
regulator: s2mpa01: Remove unused define for S2MPA01_REGULATOR_CNT
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator: hi655x: Remove ctrl_mask field from struct hi655x_regulator
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually
The patch
ASoC: stm32: sai: fix master clock management
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
The patch
spi: spi-mem: Fix build error without CONFIG_SPI_MEM
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
regulator: anatop: Remove unneeded fields from struct anatop_regulator
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually
The patch
ASoC: cs43130: fix a NULL pointer dereference
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
On Wed, Apr 10, 2019 at 08:22:29PM +0800, YueHaibing wrote:
> On 2019/4/10 19:57, Naga Sureshkumar Relli wrote:
> > +static inline bool spi_mem_default_supports_op(struct spi_mem *mem,
> > +const struct spi_mem_op *op);
> Here miss a Function body, right?
Yeah, I'm
On 2019/4/10 19:57, Naga Sureshkumar Relli wrote:
> From: YueHaibing
>
> When building with CONFIG_SPI_MEM is not set
> gc warns this:
>
> drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
> spi-zynq-qspi.c:(.text+0x1da): undefined reference to
> `spi_mem_default_supports_op'
>
Hi Guenter,
On 08 April 2019 20:39, Guenter Roeck wrote:
> Subject: [PATCH 11/22] watchdog: da9062_wdt: Use 'dev' instead of
> dereferencing it repeatedly
>
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly. Also replace 'ret = func(); return
Well, Naga Sureshkumar Relli has post new patch based this, Pls ignore this.
On 2019/4/10 20:13, Yue Haibing wrote:
> From: YueHaibing
>
> When building with CONFIG_SPI_MEM is not set
> gc warns this:
>
> drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
>
Hi,
From: Sudeep Holla [sudeep.ho...@arm.com]:
> On Fri, Apr 05, 2019 at 12:42:43PM +0300, Aaro Koskinen wrote:
> > On Fri, Apr 05, 2019 at 08:58:30AM +0530, saiprakash.ran...@codeaurora.org
> > wrote:
> > > There is already a patch sent by Sudeep for this support.
> > >
> > > -
> > >
From: YueHaibing
When building with CONFIG_SPI_MEM is not set
gc warns this:
drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
spi-zynq-qspi.c:(.text+0x1da): undefined reference to
`spi_mem_default_supports_op'
Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI
Commit-ID: 90c1cba2b3b3851c151229f61801919b2904d437
Gitweb: https://git.kernel.org/tip/90c1cba2b3b3851c151229f61801919b2904d437
Author: Bart Van Assche
AuthorDate: Wed, 3 Apr 2019 16:35:52 -0700
Committer: Ingo Molnar
CommitDate: Wed, 10 Apr 2019 13:45:59 +0200
locking/lockdep: Zap
On 08 April 2019 20:39, Guenter Roeck wrote:
> Subject: [PATCH 10/22] watchdog: da9055_wdt: Use 'dev' instead of
> dereferencing it repeatedly
>
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly.
>
> The conversion was done automatically with
Hi Kay,
On Wed, Apr 10, 2019 at 5:43 AM root wrote:
>
> From: Kay-Liu
>
> The imx6-solox's enet clk config would cause CPU hang in a special
> environment.The BUG was accepted by yoctoproject, they will process
> platform related code,only submit dts part here.
>
Hi,
The series adds support of chip packages for STM32MP157 SOC.
Available packages are:
STM32MP_PKG_AA: LFBGA448 (18*18), 176 IOs
STM32MP_PKG_AB: LFBGA354 (16*16), 98 IOs
STM32MP_PKG_AC: TFBGA361 (12*12), 148 IOs
STM32MP_PKG_AD: TFBGA257 (10*10), 98 IOs
As ball-out is different between each
On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote:
> > I'm unable to find a branch matching the line numbers.
> >
> > Given that, on the face of it, the scenario is impossible I'm
> > seeking clarification on what linux-next to look at for the
> > sake of accuracy.
> >
> > So I'm
On 08 April 2019 20:39, Guenter Roeck wrote:
> Subject: [PATCH 09/22] watchdog: da9052_wdt: Use 'dev' instead of
> dereferencing it repeatedly
>
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly.
>
> The conversion was done automatically with
On 4/9/19 11:38 PM, Michal Simek wrote:
On 09. 04. 19 19:23, Guenter Roeck wrote:
Use device managed functions to simplify error handling, reduce
source code size, improve readability, and reduce the likelyhood of bugs.
Other improvements as listed below.
The conversion was done automatically
On Wed, 2019-04-10 at 19:57 +0800, Ian Kent wrote:
> On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote:
> > On Wed, Apr 10, 2019 at 12:35 PM Ian Kent wrote:
> > >
> > > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
> > > > >
On Wed, Apr 10, 2019 at 2:02 PM Dmitry Vyukov wrote:
>
> On Wed, Apr 10, 2019 at 1:57 PM Ian Kent wrote:
> > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > > > > Bisection is inconclusive: the first bad commit could be any of:
> > > > > >
> > > > > > [snip the useless
On Wed, Apr 10, 2019 at 1:57 PM Ian Kent wrote:
> > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > > > Bisection is inconclusive: the first bad commit could be any of:
> > > > >
> > > > > [snip the useless pile]
> > > > >
> > > > > > bisection log:
> > > > > >
> On Wed, Apr 10, 2019 at 11:47:43AM +, Flavio Suligoi wrote:
>
> > You have right about to avoid too many boot messages,
> > but in this case, using an x86 machine and with
> > the spi-pxa2xx in DMA mode, so without the message:
>
> > "no DMA channels available, using PIO",
>
> > there is
On Wed, Apr 10, 2019 at 8:55 AM Fabio Estevam wrote:
> Please check if this patch fixes the problem on your case:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20190410=728e096dd70889c2e80dd4153feee91afb1daf72
Also, just confirmed that this commit r
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
> interactive workloads (referred as main workload) have a lot of spare CPU
>
From: YueHaibing
When building with CONFIG_SPI_MEM is not set
gc warns this:
drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
spi-zynq-qspi.c:(.text+0x1da): undefined reference to
`spi_mem_default_supports_op'
Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI
On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote:
> On Wed, Apr 10, 2019 at 12:35 PM Ian Kent wrote:
> >
> > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
> > > >
> > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot
On Wed, Apr 10, 2019 at 11:47:43AM +, Flavio Suligoi wrote:
> You have right about to avoid too many boot messages,
> but in this case, using an x86 machine and with
> the spi-pxa2xx in DMA mode, so without the message:
> "no DMA channels available, using PIO",
> there is absolutely no
://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20190410=728e096dd70889c2e80dd4153feee91afb1daf72
imx-drm should also be fixed independently of this PWM rename change
in my opinion.
On Wed, Apr 10, 2019 at 12:27:54PM +0200, Thomas Gleixner wrote:
> Struct stack_trace is a sinkhole for input and output parameters which is
> largely pointless for most usage sites. In fact if embedded into other data
> structures it creates indirections and extra storage overhead for no benefit.
Hi Mark,
> On Mon, Apr 08, 2019 at 05:22:44PM +0200, Flavio Suligoi wrote:
> > Add an info message for the PXA2xx device driver start-up,
> > with the indication of the transfer mode used (DMA or GPIO).
> >
> > This info is useful to individuate the timing when
> > the module starts.
>
> Adding
On Thu, Mar 14, 2019 at 10:51:20PM -0500, Kangjie Lu wrote:
> In case create_singlethread_workqueue fails, the fix returns
> -ENOMEM to avoid potential NULL pointer dereference.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant
On Mon, 8 Apr 2019 at 17:05, Jens Axboe wrote:
>
> On 4/8/19 9:04 AM, Johannes Thumshirn wrote:
> > [+Cc Michal ]
> > On Mon, Apr 08, 2019 at 04:54:39PM +0200, Paolo Valente wrote:
> >>
> >>
> >>> Il giorno 8 apr 2019, alle ore 16:49, Johannes Thumshirn
> >>> ha scritto:
> >>>
> >>> On Mon, Apr
* Elena Reshetova wrote:
> 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys
> base:1000 loops in 1.62224s =
> 162.22 nsec / loop
> random_offset (prandom_u32() every syscall): 1000 loops in 1.64660s =
> 166.26 nsec / loop
On Fri, Apr 05, 2019 at 12:42:43PM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Apr 05, 2019 at 08:58:30AM +0530, saiprakash.ran...@codeaurora.org
> wrote:
> > On 2019-04-04 00:21, Aaro Koskinen wrote:
> > >From: Aaro Koskinen
> > >
> > >Add support for warm reset using SYSTEM_RESET2 introduced
On Wed, Apr 10, 2019 at 12:35 PM Ian Kent wrote:
>
> On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
> > >
> > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > Bisection is inconclusive: the first bad commit could be any
Pavel
On 4/8/19 5:10 AM, Pavel Machek wrote:
On Fri 2019-04-05 09:55:39, Dan Murphy wrote:
Add the LM36274 LED specific bindings.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/leds/leds-lm36274.txt | 82 +++
1 file changed, 82 insertions(+)
create mode 100644
Hi Mark,
> -Original Message-
> From: Mark Brown
> Sent: Wednesday, April 10, 2019 4:01 PM
> To: Naga Sureshkumar Relli
> Cc: yuehaib...@huawei.com; vigne...@ti.com; linux-kernel@vger.kernel.org;
> linux-
> s...@vger.kernel.org; Michal Simek ;
> nagasures...@gmail.com
> Subject: Re:
On Wed, Apr 10, 2019 at 03:23:39PM +0530, Vidya Sagar wrote:
> On 4/10/2019 1:44 PM, Liviu Dudau wrote:
> > On Wed, Apr 10, 2019 at 11:40:40AM +0530, Vidya Sagar wrote:
> > > On 4/9/2019 6:56 PM, Bjorn Helgaas wrote:
> > > > On Tue, Apr 09, 2019 at 05:00:53PM +0530, Vidya Sagar wrote:
> > > > > On
On Wed, Apr 10, 2019 at 1:06 PM Thomas Gleixner wrote:
>
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> Signed-off-by: Thomas Gleixner
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: Dmitry Vyukov
> Cc: kasan-...@googlegroups.com
Hi Linus,
Can you please pull the following regression fix for apparmor
Thanks!
- John
The following changes since commit 771acc7e4a6e5dba779cb1a7fd851a164bc81033:
Bluetooth: btusb: request wake pin with NOAUTOEN (2019-04-09 17:38:24 -1000)
are available in the Git repository at:
syzbot has bisected this bug to:
commit 8f840e47f190cbe61a96945c13e9551048d42cef
Author: Xin Long
Date: Thu Apr 14 07:35:33 2016 +
sctp: add the sctp_diag.c file
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1719585b20
start commit: 0072a0c1 Merge tag
This patch adds four new packages support for stm32mp157c die:
STM32MP_PKG_AA: LFBGA448 (18*18), 176 IOs
STM32MP_PKG_AB: LFBGA354 (16*16), 98 IOs
STM32MP_PKG_AC: TFBGA361 (12*12), 148 IOs
STM32MP_PKG_AD: TFBGA257 (10*10), 98 IOs
Signed-off-by: Alexandre Torgue
diff --git
Align pins names with names provided in official stm32mp157 datasheet
available on st.com.
Signed-off-by: Alexandre Torgue
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32mp157.c
b/drivers/pinctrl/stm32/pinctrl-stm32mp157.c
index 374ccc2..320544f 100644
---
A same SoC can be available in several packages. Differences between
packages are only the numbers of available balls. In order not to write
a driver for each new package, same driver (ex: pinctrl-stm32mp157.c) will
be used. This patch introduces the "package" property for each pin. So on a
same
On Wed, Apr 10, 2019 at 1:05 PM Thomas Gleixner wrote:
>
> No architecture terminates the stack trace with ULONG_MAX anymore. Remove
> the cruft.
>
> Signed-off-by: Thomas Gleixner
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: kasan-...@googlegroups.com
> Cc: Dmitry Vyukov
> Cc:
Four packages exist for stm32mp157 die. As ball-out is different between
them, this patch covers those differences by creating dedicated pinctrl
dtsi files. Each dtsi pinctrl package file describes the package ball-out
through gpio-ranges.
stm32mp157a-dk1 / dk2 boards embed a STM32MP_PKG_AC
Add "st,package" entry. Possibles values are:
-STM32MP_PKG_AA for LFBGA448 (18*18) package
-STM32MP_PKG_AB for LFBGA354 (16*16) package
-STM32MP_PKG_AC for TFBGA361 (12*12) package
-STM32MP_PKG_AD for TFBGA257 (10*10) package
Signed-off-by: Alexandre Torgue
diff --git
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 09:18:27PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Apr 02, 2019 at 03:33:16PM -0400, Sasha Levin wrote:
> > > > This patch adds support
On 10-04-19, 16:46, Sibi Sankar wrote:
> On 2019-04-10 16:03, Viresh Kumar wrote:
> > On 28-03-19, 20:58, Sibi Sankar wrote:
> > > Add support to parse and update OPP tables attached to the cpu nodes.
> > >
> > > Signed-off-by: Sibi Sankar
> > > ---
> > > drivers/cpufreq/qcom-cpufreq-hw.c | 29
If CONFIG_RANDOMIZE_KSTACK_OFFSET is selected,
the kernel stack offset is randomized upon each
entry to a system call after fixed location of pt_regs
struct.
This feature is based on the original idea from
the PaX's RANDKSTACK feature:
https://pax.grsecurity.net/docs/randkstack.txt
All the
Resending the patch since the first attempt never made
it to lkml.
changes in v2:
- alloca() is changed to __builtin_alloca() in order
to be compatible with 32 bit versions
Elena Reshetova (1):
x86/entry/64: randomize kernel stack offset upon syscall
arch/Kconfig| 15
Guenter Roeck writes:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic
On 2019-04-10 16:03, Viresh Kumar wrote:
On 28-03-19, 20:58, Sibi Sankar wrote:
Add support to parse and update OPP tables attached to the cpu nodes.
Signed-off-by: Sibi Sankar
---
drivers/cpufreq/qcom-cpufreq-hw.c | 29 +++--
1 file changed, 27 insertions(+), 2
On Thu, Feb 28, 2019 at 09:57:41PM +0800, Pengcheng Li wrote:
> +Required properties:
> +
> +- compatible: should be one of the following:
> + - "hisilicon,hi3660-i2s-1.0"
> +- reg: physical base address of the i2s controller unit and length of
> + memory mapped region.
This binding is
Struct stack_trace is a sinkhole for input and output parameters which is
largely pointless for most usage sites. In fact if embedded into other data
structures it creates indirections and extra storage overhead for no benefit.
Looking at all usage sites makes it clear that they just require an
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
On Thu, Feb 28, 2019 at 09:57:00PM +0800, Pengcheng Li wrote:
> From: Youlin Wang
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
Please don't ignore review comments, people are generally making them
for a reason and
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Will Deacon
---
kernel/locking/lockdep.c | 11 ---
1 file changed, 11 deletions(-)
--- a/kernel/locking/lockdep.c
+++
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,
[..]
I don't think it is caused by a different NAND type, but i have followed
the some test on my
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
While at it remove the pointless loop of clearing the stack array
completely. It's sufficient to clear the last entry as the consumers break
out on the first zeroed entry anyway.
Signed-off-by: Thomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
No architecture terminates the stack trace with ULONG_MAX anymore. As the
code checks the number of entries stored anyway there is no point in
keeping all that ULONG_MAX magic around.
The histogram code zeroes the storage before saving the stack, so if the
trace is shorter than the maximum number
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
Signed-off-by: Thomas Gleixner
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: kasan-...@googlegroups.com
Cc: Dmitry Vyukov
Cc: linux...@kvack.org
---
mm/kasan/common.c |3 ---
1 file changed, 3
No architecture terminates the stack trace with ULONG_MAX anymore. The
consumer terminates on the first zero entry or at the number of entries, so
no functional change.
Remove the cruft.
Signed-off-by: Thomas Gleixner
---
fs/proc/base.c |3 +--
kernel/latencytop.c | 12 ++--
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
The struct stack_trace indirection in the stack depot functions is a truly
pointless excercise which requires horrible code at the callsites.
Provide interfaces based on plain storage arrays.
Signed-off-by: Thomas Gleixner
---
include/linux/stackdepot.h |4 ++
lib/stackdepot.c |
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: Pekka Enberg
Cc: linux...@kvack.org
Cc: David Rientjes
Cc: Christoph Lameter
---
mm/slub.c | 12
1 file changed, 4
On Wed, Apr 10, 2019 at 12:28:22PM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace with an invocation of
> the storage array based interface.
This seems to be missing some context, at least stack_trace_save does
not actually exist in mainline.
Please always
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
Signed-off-by: Thomas Gleixner
---
kernel/backtracetest.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/kernel/backtracetest.c
+++ b/kernel/backtracetest.c
@@ -48,19
Commit-ID: 3966c3feca3fd10b2935caa0b4a08c7dd59469e5
Gitweb: https://git.kernel.org/tip/3966c3feca3fd10b2935caa0b4a08c7dd59469e5
Author: Lendacky, Thomas
AuthorDate: Tue, 2 Apr 2019 15:21:18 +
Committer: Ingo Molnar
CommitDate: Wed, 10 Apr 2019 13:03:18 +0200
x86/perf/amd: Remove
All operations with stack traces are based on struct stack_trace. That's a
horrible construct as the struct is a kitchen sink for input and
output. Quite some usage sites embed it into their own data structures
which creates weird indirections.
There is absolutely no point in doing so. For all
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
The original code in all printing functions is really wrong. It allocates a
storage array on stack which is unused because depot_fetch_stack() does not
store anything in it. It overwrites the entries
Hey Viresh,
Thanks for the review!
On 2019-04-10 15:54, Viresh Kumar wrote:
On 28-03-19, 20:58, Sibi Sankar wrote:
Add and export 'dev_pm_opp_update_voltage' to find and update voltage
of an opp for a given frequency. This will be useful to update the
opps
with voltages read back from
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
Signed-off-by: Thomas Gleixner
Cc: Catalin Marinas
Cc: linux...@kvack.org
---
mm/kmemleak.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
--- a/mm/kmemleak.c
+++
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: Alexey Dobriyan
---
fs/proc/base.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
--- a/fs/proc/base.c
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: Akinobu Mita
---
lib/fault-inject.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
--- a/lib/fault-inject.c
+++
Signed-off-by: Thomas Gleixner
---
kernel/locking/lockdep.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1522,10 +1522,9 @@ static inline int class_equal(struct loc
}
static noinline int
Thanks Keith, this solves my issue.
On a machine where node4 (PMEM) is close to node0 and node1 (1st socket
SNCs), hotplugging that node makes node0 and node1 appear as initiators
to node4 (and node4 as target to them). Same for the other socket. And
perf attributes look good.
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface. This results in less storage space and
indirection.
Signed-off-by: Thomas Gleixner
Cc: dm-de...@redhat.com
Cc: Mike Snitzer
Cc: Alasdair Kergon
---
There should be no trouble to understand dev = pdev->dev.
This can save some space to have more print info or save
some wrapped lines.
Signed-off-by: Viorel Suman
Suggested-by: Nicolin Chen
---
sound/soc/fsl/fsl_audmix.c | 27 +--
1 file changed, 13 insertions(+), 14
The indirection through struct stack_trace is not necessary at all. Use the
storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: Steven Rostedt
---
kernel/trace/trace_events_hist.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
---
Replace the indirection through struct stack_trace by using the storage
array based interfaces and storing the information is a small lockdep
specific data structure.
Signed-off-by: Thomas Gleixner
---
include/linux/lockdep.h |9 +++--
kernel/locking/lockdep.c | 39
No more users of the struct stack_trace based interfaces. Remove them.
Remove the macro stubs for !CONFIG_STACKTRACE as well as they are pointless
because the storage on the call sites is conditional on CONFIG_STACKTRACE
already. No point to be 'smart'.
Signed-off-by: Thomas Gleixner
---
The per cpu stack trace buffer usage pattern is odd at best. The buffer has
place for 512 stack trace entries on 64-bit and 1024 on 32-bit. When
interrupts or exceptions nest after the per cpu buffer was acquired the
stacktrace length is hardcoded to 8 entries. 512/1024 stack trace entries
in
No more users of the struct stack_trace based interfaces.
Signed-off-by: Thomas Gleixner
---
include/linux/stackdepot.h |4
lib/stackdepot.c | 20
2 files changed, 24 deletions(-)
--- a/include/linux/stackdepot.h
+++ b/include/linux/stackdepot.h
@@
601 - 700 of 880 matches
Mail list logo
