On Wed 13-03-19 08:35:33, Kees Cook wrote:
> On Wed, Mar 13, 2019 at 7:35 AM Jan Kara wrote:
> > On Tue 12-03-19 23:26:22, Kees Cook wrote:
> > > On Mon, Mar 11, 2019 at 1:42 PM syzbot
> > > wrote:
> > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ee410b20
> > > > [...]
> >
The patch
regulator: wm831x-isink: Convert to use
regulator_set/get_current_limit_regmap
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
The patch
ASoC: stm32: i2s: change trigger traces
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 to
The patch
ASoC: davinci-mcasp: Fix clang warning without CONFIG_PM
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)
The patch
regulator: wm831x ldo: Fix notifier mutex lock warning
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
The patch
regulator: wm8350: Convert to use regulator_set/get_current_limit_regmap
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
regulator: wm8350: Select maximum current in specific range
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
The patch
ASoC: ams-delta: remove duplicate 'const'
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 to
The patch
regulator: wm831x isink: Fix notifier mutex lock warning
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
The patch
regulator: max14577: Get rid of match_init_data/match_of_node functions
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
regulator: ltc3676: Fix notifier mutex lock warning
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
The patch
regulator: da9063: Fix notifier mutex lock warning
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
The patch
regulator: wm831x: Fix notifier mutex lock warning
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
The patch
regulator: pv88060: Fix notifier mutex lock warning
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
The patch
regulator: da9211: Fix notifier mutex lock warning
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
The patch
regulator: pv88090: Fix notifier mutex lock warning
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
The patch
regulator: da9055: Fix notifier mutex lock warning
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
The patch
regulator: gpio: Constify regulator_ops
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) and
The patch
spi: work around clang bug in SPI_BPW_RANGE_MASK()
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 sent
The patch
spi: spi-fsl-qspi: use devm_spi_register_controller
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: ab3100: Remove ab3100_regulators_remove function
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
The patch
regulator: gpio: Convert to devm_regulator_register
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
The patch
regulator: ltc3589: Fix notifier mutex lock warning
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
The patch
regulator: da9062: Fix notifier mutex lock warning
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
The patch
regulator: palmas: Remove *rdev[PALMAS_NUM_REGS] from struct palmas_pmic
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
In some is25lp256, the DWORD1 of JEDEC Basic Flash Parameter Header
is 0xfff920e5. So the DWORD1[18:17] Address Bytes bits are 0b00,
means that 3-Byte only addressing. But the device size is larger
than 16MB, nor->addr_width must be 4 to access the whole address.
An error should be returned when
The patch
regulator: wm8400: Fix trivial typo
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) and sent to
The patch
regulator: wm8400: Get rid of wm8400_block_read/wm8400_set_bits functions
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
regulator: pv88080: Fix notifier mutex lock warning
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
The patch
regulator: lp8755: Fix notifier mutex lock warning
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
The patch
regulator: wm831x-isink: Select maximum current in specific range
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: da903x: don't build with clang
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) and
The patch
ASoC: axi-i2s: let both capture and playback be optional
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)
The patch
ASoC: axi-i2s: make both "rx" and "tx" optional
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
ASoC: ti: remove compat dma probing
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 to Linus
The patch
ASoC: stm32: i2s: improve channel capabilities handling
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)
The patch
ASoC: qcom: add i2c dependency for SND_SOC_SDM845
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
The patch
ASoC: ti: fix davinci_mcasp_probe dependencies
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
ASoC: stm32: i2s: use default dai name
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 to Linus
The patch
ASoC: samsung: odroid: Fix clock configuration for 44100 sample rate
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
On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote:
> So before we talk about how to make things work from a technical
> perspective, we should consider what the use case happens to be, and
> what are the security requirements. *Why* are we trying to use the
> combination of overlayfs and
On Wed, Mar 13, 2019 at 7:35 AM Jan Kara wrote:
> On Tue 12-03-19 23:26:22, Kees Cook wrote:
> > On Mon, Mar 11, 2019 at 1:42 PM syzbot
> > wrote:
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ee410b20
> > > [...]
> > > [ cut here ]
> > > Bad or
On 13.03.2019 17:36, Jiri Olsa wrote:
> On Tue, Mar 12, 2019 at 08:30:13AM +0300, Alexey Budankov wrote:
>
> SNIP
>
>> -
>> -md->prev = head;
>> -perf_mmap__consume(md);
>> -
>> -rc = push(to, >aio.cblocks[idx], md->aio.data[idx], size0 + size,
>> *off);
>> -if (!rc) {
>> -
On Wed, Mar 13, 2019 at 02:48:49PM +0100, Arnd Bergmann wrote:
> On Wed, Mar 13, 2019 at 2:44 PM Nathan Chancellor
> wrote:
> > On Wed, Mar 13, 2019 at 09:13:11AM +0100, Rasmus Villemoes wrote:
> > > Wouldn't it be better to just define bcmp as an alias for memcmp? They
> > > seem to have
On Wed, Mar 13, 2019 at 03:26:39PM +0800, huang ying wrote:
> >
> >
> > commit: fde872682e175743e0c3ef939c89e3c6008a1529 ("ext4: force inode writes
> > when nfsd calls commit_metadata()")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> It appears that this is a
Am Mittwoch, 13. März 2019, 16:16:33 CET schrieb Theodore Ts'o:
> So before we talk about how to make things work from a technical
> perspective, we should consider what the use case happens to be, and
> what are the security requirements. *Why* are we trying to use the
> combination of overlayfs
On Wed, Mar 13, 2019 at 04:26:54PM +0200, Amir Goldstein wrote:
> On Wed, Mar 13, 2019 at 3:34 PM Richard Weinberger wrote:
> >
> > Am Mittwoch, 13. März 2019, 14:24:47 CET schrieb Miklos Szeredi:
> > > > The use case is that you can delete these files if the DAC/MAC
> > > > permissions allow
On 13-Mar 15:06, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:40AM +, Patrick Bellasi wrote:
> > +static void __init init_uclamp(void)
> > +{
> > + unsigned int clamp_id;
> > + int cpu;
> > +
> > + for_each_possible_cpu(cpu)
> > + memset(_rq(cpu)->uclamp, 0,
On Wed, 13 Mar 2019 11:09:48 -0400
Joel Fernandes wrote:
> AFAICS, lockdep does not specifically track when we enter an interrupt, but
> rather only tracks when interrupts are enabled/disabled.
It does:
#define __irq_enter() \
do {
From: Thor Thayer
Stratix10 Double Bit Error Address was always read from
SDRAM Address register instead of each device's Address
register.
To determine which device had the DBE, cycle through
the EDAC devices comparing the DBE value to the db_irq
value. Once found, report the DBE Address from
On 13-Mar 15:09, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:40AM +, Patrick Bellasi wrote:
> > +static inline unsigned int uclamp_none(int clamp_id)
> > +{
> > + if (clamp_id == UCLAMP_MIN)
> > + return 0;
> > + return SCHED_CAPACITY_SCALE;
> > +}
> > +
> > +static
On Thu, 14 Mar 2019 00:04:02 +0900
Masami Hiramatsu wrote:
> > > strlcpy(buf, event, slash - event + 1);
> > > + if (!is_good_name(buf)) {
> > > + pr_info("Group name must follow the rule of C
> > > identifier\n");
> >
> > What do you mean by "C identifier"?
On Wed, Mar 13, 2019 at 07:04:06AM +, Peter Rosin wrote:
> Hi Greg,
>
> I was wondering if you think the below ABI addition looks sane to you?
I am not the i2c maintainer :)
> Or, should I ask someone else for a tag?
It's the middle of the merge window. None of us can do much other than
On Wed, Mar 13, 2019 at 04:26:54PM +0200, Amir Goldstein wrote:
> AFAIK, this feature was born to tailor Android's file based encryption.
> https://source.android.com/security/encryption#file-based
> It is meant to protect data at rest and what happens when user enters
> the screen lock password
On 12-Mar 13:52, Dietmar Eggemann wrote:
> On 2/8/19 11:05 AM, Patrick Bellasi wrote:
>
> [...]
>
> > +config UCLAMP_BUCKETS_COUNT
> > + int "Number of supported utilization clamp buckets"
> > + range 5 20
> > + default 5
> > + depends on UCLAMP_TASK
> > + help
> > + Defines the
On Wed, Mar 13, 2019 at 07:44:34AM -0700, Guenter Roeck wrote:
> On Tue, Mar 12, 2019 at 10:09:18AM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.163 release.
> > There are 96 patches in this series, all will be posted as a response
> > to this one.
If this is not too late and if there is still place available, I would
like to attend the MM track and propose a topic about using the XArray
to replace the VMA's RB tree and list.
Using the XArray in place of the VMA's tree and list seems to be a first
step to the long way of
On Tue, Mar 12, 2019 at 08:20:34AM -0700, Paul E. McKenney wrote:
[snip]
>
> >Could we be more explicit in the code that this function can only
> > be called from an interrupt, and also we change the code comment to be more
> > clear about it (like the following diff)?
>
> That would
With extremely short cfs_period_us setting on a parent task group with a large
number of children the for loop in sched_cfs_period_timer can run until the
watchdog fires. There is no guarantee that the call to hrtimer_forward_now()
will ever return 0. The large number of children can make
Devicetree binding reviews have a lot of repeated review comments. Much
of the guidelines aren't written down. This list of do's and don't's is
by no means an exhaustive guide for how to write bindings, but at least
the "rules" are written down in some form.
Signed-off-by: Rob Herring
---
On 13.03.2019 17:37, Jiri Olsa wrote:
> On Tue, Mar 12, 2019 at 08:23:42AM +0300, Alexey Budankov wrote:
>>
>> Implemented functions are based on Zstd streaming compression API.
>> The functions are used in runtime to compress data that come from
>> mmaped kernel buffer. zstd_init(), zstd_fini()
On Wed, 13 Mar 2019 09:23:55 -0400
Steven Rostedt wrote:
> On Wed, 13 Mar 2019 21:28:12 +0900
> Masami Hiramatsu wrote:
>
> > Check event and group naming rule at parsing it instead
> > of allocating probes.
> >
> > Signed-off-by: Masami Hiramatsu
> > ---
> > kernel/trace/trace_kprobe.c |
On Mon, Mar 11, 2019 at 11:46:28AM +0800, Hsin-Hsiung Wang wrote:
> +static const u32 vefuse_voltages[] = {
> + 170, 180, 190,
> +};
This and a bunch of the other regulators look like they're just linear
ranges and could use the linear range helpers.
> +static const u32
Hi Miklos,
On Wed, Mar 13, 2019 at 02:24:47PM +0100, Miklos Szeredi wrote:
> On Wed, Mar 13, 2019 at 2:00 PM Richard Weinberger wrote:
> >
> > Am Mittwoch, 13. März 2019, 13:58:11 CET schrieb Miklos Szeredi:
> > > On Wed, Mar 13, 2019 at 1:47 PM Richard Weinberger wrote:
> > > >
> > > > Am
On 13.03.2019 17:36, Jiri Olsa wrote:
> On Tue, Mar 12, 2019 at 08:12:23AM +0300, Alexey Budankov wrote:
>
> SNIP
>
>> record__aio_mmap_read_sync(rec);
>>
>> if (forks) {
>> @@ -1815,6 +1863,7 @@ static struct record record = {
>> .uses_mmap = true,
>>
On 13.03.2019 17:37, Jiri Olsa wrote:
> On Thu, Feb 28, 2019 at 11:35:24AM +0300, Alexey Budankov wrote:
>>
>> The patch set implements runtime trace compression (-z option) in
>> record mode and trace auto decompression in report and inject modes.
>> Streaming Zstandard (Zstd) API (zstd) is
On Wed, Mar 13, 2019 at 3:36 PM Mark Rutland wrote:
> On Wed, Mar 13, 2019 at 10:18:44AM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 11, 2019 at 03:20:04PM +0100, Arnd Bergmann wrote:
> > > On Mon, Mar 11, 2019 at 3:00 PM Qian Cai wrote:
>
> I think that using s64 consistently (with any
On 13/03/2019 16:38, gre...@linuxfoundation.org wrote:
On Wed, Mar 13, 2019 at 02:12:30PM +, Dmitry Kasatkin wrote:
From: Sasha Levin
Sent: Tuesday, March 12, 2019 1:16 AM
To: Dmitry Kasatkin
Cc: Al Viro; yuehaibing; linux-kernel@vger.kernel.org;
linux-fsde...@vger.kernel.org;
This v3 corrects grammar and ensures it is ccied to the right
maintainer
Jules Irenge (2):
staging: rtl8192e: add SPDX GPL-2.0 license identifier
staging: rtl8192e: remove boilerplate license text
drivers/staging/rtl8192e/dot11d.c | 9 +
1 file changed, 1 insertion(+), 8
Add the SPDX GPL-2.0 license identifier to fix checkpatch.pl warning
Issue found by checkpatch.pl warning:
"WARNING: Missing or malformed SPDX-License-Identifier tag in line 1"
Signed-off-by: Jules Irenge
---
drivers/staging/rtl8192e/dot11d.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Remove boilerplate license text.
Signed-off-by: Jules Irenge
---
drivers/staging/rtl8192e/dot11d.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/rtl8192e/dot11d.c
b/drivers/staging/rtl8192e/dot11d.c
index 6d57abedaa34..82c11caeee7a 100644
---
Hi All,
Please ignore this patch, rev1.0 will not be production.
Thanks,
Zhiqiang
> -Original Message-
> From: Z.q. Hou
> Sent: 2019年3月11日 17:34
> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
On Wed, 13 Mar 2019 23:37:39 +0900
Masami Hiramatsu wrote:
> > So now 'p1:..." will error out and not just be ignored?
>
> Yes, I think it is better to tell user "your command has a
> meaningless option, maybe you made a mistake" than ignore that.
>
OK, just making sure. Hope nobody
Hi All,
Please ignore this patch, rev1.0 will not be production.
Thanks,
Zhiqiang
> -Original Message-
> From: Z.q. Hou
> Sent: 2019年3月11日 17:33
> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
Hi Linus,
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
tags/pwm/for-5.1-rc1
for you to fetch
Hi Bjorn,
Thanks a lot for your comments!
> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 2019年3月12日 21:35
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
Hi,
(I added Juri in cc)
On Tue, 12 Mar 2019 10:03:12 +0800
"chengjian (D)" wrote:
[...]
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 31c050a0d0ce..d73cb033a06d 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -252,7 +252,6 @@ static void
On Tue, Mar 12, 2019 at 10:09:18AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.163 release.
> There are 96 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Wed, Mar 13, 2019 at 02:12:30PM +, Dmitry Kasatkin wrote:
>
>
>
>
>
>
> From: Sasha Levin
> Sent: Tuesday, March 12, 2019 1:16 AM
> To: Dmitry Kasatkin
> Cc: Al Viro; yuehaibing; linux-kernel@vger.kernel.org;
> linux-fsde...@vger.kernel.org; keesc...@chromium.org;
On Wed, 13 Mar 2019 09:20:51 -0400
Steven Rostedt wrote:
> On Wed, 13 Mar 2019 21:27:42 +0900
> Masami Hiramatsu wrote:
>
> > Check maxactive on kprobe error case, because maxactive
> > is only for kretprobe, not for kprobe. Also, maxactive
> > should not be 0, it should be at least 1.
> >
>
On Thu, Feb 28, 2019 at 11:35:24AM +0300, Alexey Budankov wrote:
>
> The patch set implements runtime trace compression (-z option) in
> record mode and trace auto decompression in report and inject modes.
> Streaming Zstandard (Zstd) API (zstd) is used for compression and
> decompression of
On Tue, Mar 12, 2019 at 08:36:18AM +0300, Alexey Budankov wrote:
SBIP
> +#ifdef HAVE_ZSTD_SUPPORT
> +static int perf_session__process_compressed_event(struct perf_session
> *session,
> + union perf_event *event, u64
> file_offset)
> +{
> + void *src;
> +
On Thu, Feb 28, 2019 at 11:35:24AM +0300, Alexey Budankov wrote:
>
> The patch set implements runtime trace compression (-z option) in
> record mode and trace auto decompression in report and inject modes.
> Streaming Zstandard (Zstd) API (zstd) is used for compression and
> decompression of
On Tue, Mar 12, 2019 at 08:30:13AM +0300, Alexey Budankov wrote:
>
> Compression is implemented using the functions from zstd.c. As the memory
> to operate on the compression uses mmap->aio.data[] buffers. If Zstd
> streaming compression API fails for some reason the data to be compressed
> are
On Tue, Mar 12, 2019 at 08:23:42AM +0300, Alexey Budankov wrote:
>
> Implemented functions are based on Zstd streaming compression API.
> The functions are used in runtime to compress data that come from
> mmaped kernel buffer. zstd_init(), zstd_fini() are used for
> initialization and
On Tue, Mar 12, 2019 at 08:12:23AM +0300, Alexey Budankov wrote:
SNIP
> record__aio_mmap_read_sync(rec);
>
> if (forks) {
> @@ -1815,6 +1863,7 @@ static struct record record = {
> .uses_mmap = true,
> .default_per_cpu = true,
>
On Wed, Mar 13, 2019 at 07:59:53AM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 12.03.19 17:33, Greg KH wrote:
> > On Tue, Mar 12, 2019 at 03:57:33PM +0100, Enrico Weigelt, metux IT consult
> > wrote:
> >> ---
> >> drivers/tty/serial/8250/8250_bcm2835aux.c | 12
> >> 1 file
On Tue, Mar 12, 2019 at 08:30:13AM +0300, Alexey Budankov wrote:
SNIP
> -
> - md->prev = head;
> - perf_mmap__consume(md);
> -
> - rc = push(to, >aio.cblocks[idx], md->aio.data[idx], size0 + size,
> *off);
> - if (!rc) {
> - *off += size0 + size;
> - } else {
> -
On Wed, Mar 13, 2019 at 10:18:44AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 11, 2019 at 03:20:04PM +0100, Arnd Bergmann wrote:
> > On Mon, Mar 11, 2019 at 3:00 PM Qian Cai wrote:
> > >
> > > On Mon, 2019-03-11 at 12:21 +, Jason Gunthorpe wrote:
> > > > On Sun, Mar 10, 2019 at 08:58:15PM
On Tue 12-03-19 23:26:22, Kees Cook wrote:
> On Mon, Mar 11, 2019 at 1:42 PM syzbot
> wrote:
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ee410b20
> > [...]
> > [ cut here ]
> > Bad or missing usercopy whitelist? Kernel memory exposure attempt
On Fri, Feb 08, 2019 at 10:05:42AM +, Patrick Bellasi wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 45460e7a3eee..447261cd23ba 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -584,14 +584,32 @@ struct sched_dl_entity {
> * Utilization
The commit f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded
memory to zones until online") introduced move_pfn_range_to_zone() which
calls memmap_init_zone() during onlining a memory block.
memmap_init_zone() will reset pagetype flags and makes migrate type to
be MOVABLE.
However, in
On Mon, Mar 11, 2019 at 12:30 AM Jiri Olsa wrote:
>
> hi,
> this patchset adds the --dir option to record command (and all
> the other record command that overload cmd_record) that allows
> the data to be stored in directory with multiple data files.
>
> It's next step for multiple threads
This patchset replaces the register offsets for am335x with macro defines.
The values are extraced from the "AM335x SitaraTM Processors Technical
Reference Manual".
Updated AM33XX_IOPAD to take three instead of two parameters, to make
future changes to #pinctrl-cells easier.
Christina Quast (2):
The values are extraced from the "AM335x SitaraTM Processors Technical
Reference Manual", Section 9.3.1 CONTROL_MODULE Registers, based on the
file autogenerated by TI PinMux.
Signed-off-by: Christina Quast
---
include/dt-bindings/pinctrl/am335x.h | 236 +++
1 file
On Wed, Mar 13, 2019 at 3:34 PM Richard Weinberger wrote:
>
> Am Mittwoch, 13. März 2019, 14:24:47 CET schrieb Miklos Szeredi:
> > > The use case is that you can delete these files if the DAC/MAC
> > > permissions allow it.
> > > Just like on NTFS. If a user encrypts files, the admin cannot read
On Wed, Mar 13, 2019 at 02:46:55PM +0100, Arnd Bergmann wrote:
> It would be tempting to use scripts/atomic/* to generate more of
> the code in a consistent way, but that is likely to be even more
> work and more error-prone at the start.
Those scripts can't do actual implementations, which is
Michael Kelley writes:
> From: Vitaly Kuznetsov Sent: Wednesday, March 13, 2019
> 1:28 AM
>>
>> > Clockevents code for Hyper-V synthetic timers is currently mixed
>> > in with other Hyper-V code. Move the code to a Hyper-V specific
>> > driver in the "clocksource" directory. Update the VMbus
On Wed, Mar 13, 2019 at 02:46:55PM +0100, Arnd Bergmann wrote:
> I thiunk it needs an '__attribute__((aligned(8)))' annotation at least on
> x86-32,
I _hate_ that s64 isn't already natively aligned.
Anyway, yes, unaligned atomics are a _bad_ idea if they work at all.
On 13/03/2019 13:50, Sameer Pujar wrote:
>
> On 3/13/2019 4:52 PM, Marc Zyngier wrote:
>> First things first:
>>
>> - Where is the cover letter?
>> - This series should be flagged as v2, as it not the same as the one you
>> sent last week.
> I had the dilemma whether to name this series as v2 or
501 - 600 of 818 matches
Mail list logo
