On Wed, Mar 13, 2019 at 09:10:04AM -0700, Andrew Morton wrote:
> On Tue, 12 Mar 2019 21:27:06 -0400 Jerome Glisse wrote:
>
> > Andrew you will not be pushing this patchset in 5.1 ?
>
> I'd like to. It sounds like we're converging on a plan.
>
> It would be good to hear more from the driver
On Wed, Mar 13, 2019 at 12:11:30PM -0500, Aditya Pakki wrote:
> hwxmits is allocated via kcalloc and not checked for failure before its
> dereference. The patch fixes this problem similar to rtl8723bs.
>
> Signed-off-by: Aditya Pakki
> ---
> drivers/staging/rtl8188eu/core/rtw_xmit.c | 4
>
On Wed, Mar 13, 2019 at 08:14:29AM -0700, Greg Kroah-Hartman wrote:
> 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
Hi Thierry,
On 13/03/2019 16:34, Thierry Reding wrote:
> On Wed, Mar 13, 2019 at 02:20:41PM +, Marc Zyngier wrote:
[...]
>> Sure, but look at the result:
>>
>> - you remove your gic-pm module
>> - the MMIO mapping disappears
>> - the GIC data structures *are still live*
>> - a driver does a
Hi,
On Tue, Mar 12, 2019 at 11:59:10AM -0700, Angus Ainslie wrote:
> On 2019-03-12 10:59, Guido Günther wrote:
> > Hi,
> > On Mon, Mar 11, 2019 at 04:46:53PM -0700, Angus Ainslie (Purism) wrote:
> > > This is the development kit for the Librem 5. The current level of
> > > support
> > > yields a
On 3/12/19 11:00 PM, Peter Xu wrote:
> On Tue, Mar 12, 2019 at 12:59:34PM -0700, Mike Kravetz wrote:
>> On 3/11/19 2:36 AM, Peter Xu wrote:
>>>
>>> The "kvm" entry is a bit special here only to make sure that existing
>>> users like QEMU/KVM won't break by this newly introduced flag. What
>>> we
Hi Fabio,
Am Mittwoch, den 13.03.2019, 14:36 -0300 schrieb Fabio Estevam:
> Hi Lucas,
>
> > On Wed, Mar 13, 2019 at 2:22 PM Lucas Stach wrote:
>
> > Unfortunately this change causes a regression on systems with MC13xxx
> > regulators. The desc.name field is filled with an uppercase name of the
On Fri, Mar 8, 2019 at 6:15 PM Masahiro Yamada
wrote:
>
> Since commit 3812b8c5c5d5 ("kbuild: make -r/-R effective in top
> Makefile for old Make versions"), make-kpkg is not working.
>
> make-kpkg directly includes the top Makefile of Linux kernel, and
> appends some debian_* targets.
>
>
On Wed, 2019-03-13 at 12:44 -0400, Theodore Ts'o wrote:
> On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> > 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
Phil Auld writes:
> On Mon, Mar 11, 2019 at 04:25:36PM -0400 Phil Auld wrote:
>> On Mon, Mar 11, 2019 at 10:44:25AM -0700 bseg...@google.com wrote:
>> > Letting it spin for 100ms and then only increasing by 6% seems extremely
>> > generous. If we went this route I'd probably say "after looping N
On Wed, Mar 13, 2019 at 2:24 AM Masahiro Yamada
wrote:
>
> From: Riku Voipio
>
> bison/flex is now needed always for building for kconfig. Some build
> dependencies depend on kernel configuration, enable them as needed:
>
> - libelf-dev when UNWINDER_ORC is set
> - libssl-dev for
On Fri, Feb 1, 2019 at 2:26 PM Masahiro Yamada
wrote:
>
> Unless CONFIG_DEBUG_SECTION_MISMATCH is enabled, modpost only shows
> the number of section mismatches.
>
> If you want to know the symbols causing the issue, you need to rebuild
> with CONFIG_DEBUG_SECTION_MISMATCH. It is tedious.
>
> I
On Fri, Mar 8, 2019 at 2:50 PM Masahiro Yamada
wrote:
>
> As commit 423a8155facf ("kbuild: Fix reading of .config in
> link-vmlinux.sh") addressed, some shells fail to perform '.' if
> ${KCONFIG_CONFIG} does not contain a slash at all.
>
> Instead, we can source include/config/auto.conf, which
On Fri, Mar 8, 2019 at 2:31 PM Masahiro Yamada
wrote:
>
> When I was searching for unneeded $(KCONFIG_CONFIG) usages, I noticed
> this strange build dependency.
>
> It can use $(call if_changed,...) in case ZTEXTADDR and ZBSSADDR are
> changed, but even a simpler way is to use the pattern rule in
On Mon, Feb 18, 2019 at 1:54 PM Masahiro Yamada
wrote:
>
> On Fri, Jan 25, 2019 at 4:21 PM Masahiro Yamada
> wrote:
> >
> > Currently, the Kbuild core manipulates header search paths in a crazy
> > way [1].
> >
> > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> > the
Hi RaviChandra,
Many thanks for pushing this upstream. Some more comments below.
On 9/3/19 2:42, RaviChandra Sadineni wrote:
> On chromebooks, power_manager daemon normally shuts down(S5) the device
> when the battery charge falls below 4% threshold. ChromeOS EC then
> normally spends an hour in
On 12/03/2019 17:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.20.16 release.
> There are 171 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 know.
>
> Responses
On 13.03.19 14:31, Morris Ku wrote:
Hi,
> +why isn't that in ./drivers/tty/serial/sunix/ ?
> +
> driver support SUNIX Character Devices,
> serial ports and parallel ports,so we suggest
> that in /drivers/char.
Well, this seems to be a composite device. so it should be actually
different
On 12/03/2019 17:08, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.0.2 release.
> There are 25 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 know.
>
> Responses
Hi Lucas,
On Wed, Mar 13, 2019 at 2:22 PM Lucas Stach wrote:
> Unfortunately this change causes a regression on systems with MC13xxx
> regulators. The desc.name field is filled with an uppercase name of the
> regulator, while the existing DTs (as far as I know) all use lowercase
> node names,
On Mon, Feb 11, 2019 at 10:43 AM Masahiro Yamada
wrote:
>
> Hi Rob,
>
>
> On Fri, Jan 25, 2019 at 12:42 PM Masahiro Yamada
> wrote:
> >
> > Currently, the Kbuild core manipulates header search paths in a crazy
> > way [1].
> >
> > To fix this mess, I want all Makefiles to add explicit
On 12/03/2019 17:07, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.106 release.
> There are 135 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 know.
>
> Responses
On 12/03/2019 17:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.29 release.
> There are 149 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 know.
>
> Responses
On 12/03/2019 17:09, 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 know.
>
> Responses
On Wed, Mar 13, 2019 at 04:20:51PM +, Patrick Bellasi wrote:
> On 13-Mar 15:10, Peter Zijlstra wrote:
> > On Fri, Feb 08, 2019 at 10:05:41AM +, Patrick Bellasi wrote:
> > > +uclamp_idle_value(struct rq *rq, unsigned int clamp_id, unsigned int
> > > clamp_value)
> > > +{
> > > + /*
> > > +
On Fri, Feb 15, 2019 at 11:53 PM Masahiro Yamada
wrote:
>
> It believe it is a bad idea to hardcode a specific compiler prefix
> that may or may not be installed on a user's system. It is annoying
> when testing features that should not require compilers at all.
>
> For example, mrproper,
On Wed, Mar 13, 2019 at 10:21 AM Nick Desaulniers
wrote:
>
> On Wed, Mar 13, 2019 at 8:32 AM Nathan Chancellor
> wrote:
> >
> > 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
On Wed, Mar 13, 2019 at 04:12:29PM +, Patrick Bellasi wrote:
> Yes, the for looks better, but perhaps like that:
>
> unsigned int bucket_id = UCLAMP_BUCKETS;
>
> /*
>* Both min and max clamps are MAX aggregated, thus the topmost
>* bucket with some tasks defines
On Mon, 2019-03-11 at 22:47 +, Valentin Schneider wrote:
> Since the enabling and disabling of IRQs within preempt_schedule_irq()
> is contained in a need_resched() loop, we don't need the outer arch
> code loop.
>
> Signed-off-by: Valentin Schneider
> Cc: Mark Salter
> Cc: Aurelien
On Wed, Mar 13, 2019 at 8:32 AM Nathan Chancellor
wrote:
>
> 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
Hi Rob, hi Mark,
Am Mittwoch, den 05.12.2018, 13:50 -0600 schrieb Rob Herring:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> For instances using of_node_cmp, this has the side effect of now using
>
Michael Kelley writes:
> From: Vitaly Kuznetsov Sent: Wednesday, March 13, 2019
> 7:23 AM
>
>> >> > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
>> >> > index be6e0fb..a887955 100644
>> >> > --- a/drivers/clocksource/Makefile
>> >> > +++
On 13.03.19 15:36, Greg KH wrote:
> Also, usually RFC like patches and series are ignored, I know I almost
> always ignore them because if the author doesn't think they are ready to
> be reviewed, why would I spend time on them compared to other patches
> that their authors think are ready for
When userspace initializes guest vCPUs it may want to zero all supported
MSRs including Hyper-V related ones including HV_X64_MSR_STIMERn_CONFIG/
HV_X64_MSR_STIMERn_COUNT. With commit f3b138c5d89a ("kvm/x86: Update SynIC
timers on guest entry only") we began doing stimer_mark_pending()
hwxmits is allocated via kcalloc and not checked for failure before its
dereference. The patch fixes this problem similar to rtl8723bs.
Signed-off-by: Aditya Pakki
---
drivers/staging/rtl8188eu/core/rtw_xmit.c | 4
1 file changed, 4 insertions(+)
diff --git
The pull request you sent on Tue, 12 Mar 2019 12:58:18 +0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dac0bde43b0b3685390b68c9058bee36d4d5c747
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Wed, 13 Mar 2019 15:51:18 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
> tags/pwm/for-5.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/add8462a60421ca1b03a6864e295d22de532a5e7
Thank you!
--
The pull request you sent on Wed, 13 Mar 2019 01:39:04 +0900:
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
> tags/kconfig-v5.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5453a3df2a5eb49bc24615d4cf0d66b2aae05e5f
Thank you!
--
The pull request you sent on Tue, 12 Mar 2019 10:13:28 -0500:
> git://git.linaro.org/landing-teams/working/fujitsu/integration.git
> tags/mailbox-v5.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3a186d38561d2844072829c6c0811e407c6ec1aa
Thank you!
--
On 13-Mar 15:32, Peter Zijlstra wrote:
> 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
On Wed, Mar 13, 2019 at 5:37 PM Theodore Ts'o wrote:
>
> On Wed, Mar 13, 2019 at 07:43:38AM +0100, Dmitry Vyukov wrote:
> > It would be more useful to accept patches that make syzkaller create
> > better reproducers from these people. Manual work is not scalable. We
> > would need 10 reproducers
pch_alloc_dma_buf allocated tx, rx DMA buffers which can fail. Further,
these buffers are used without a check. The patch checks for these
failures and sends the error upstream.
Signed-off-by: Aditya Pakki
---
drivers/spi/spi-topcliff-pch.c | 15 +--
1 file changed, 13
From: Thomas Gleixner
The worker accounting for CPU bound workers is plugged into the core
scheduler code and the wakeup code. This is not a hard requirement and
can be avoided by keeping track of the state in the workqueue code
itself.
Keep track of the sleeping state in the worker itself and
From: Thomas Gleixner
There is no need for sched_rcu. The undocumented reason why sched_rcu
is used is to avoid a few explicit rcu_read_lock()/unlock() pairs by
the fact that sched_rcu reader side critical sections are also protected
by preempt or irq disabled regions.
Replace
The second patch was posted originally around v3.0-rc. While digging
through the archive it seems that there is nothing wrong with the patch
except for the wording of its description. I reworded that part.
I'm not sure if the first patch ever made it ever to lkml.
Both were in -RT for ages (and
On 13.03.19 17:46, Matthias Brugger wrote:
On 13/03/2019 17:34, Chuanhong Guo wrote:
Hi!
On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger wrote:
On 13/03/2019 13:24, Armando Miraglia wrote:
[...]
Apart from fixing styling issues it would be usefull to see if we can add
support for mt7621
On Wed, 13 Mar 2019 08:51:55 -0700
"Paul E. McKenney" wrote:
> Does this mean that there is a better approach that Joel's suggestion?
> I believe he would end up with something like this:
>
> WARN_ON_ONCE(IS_ENABLED(CONFIG_PROVE_RCU) && !in_irq());
>
> It would be nice if there is
The pull request you sent on Mon, 11 Mar 2019 14:54:47 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> tags/libnvdimm-for-5.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5ea6718b1f1bb58825426e19a21cdba47075a954
Thank you!
--
The pull request you sent on Tue, 12 Mar 2019 16:13:53 +0100:
> git://git.infradead.org/linux-ubifs.git tags/upstream-5.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a840b56ba385059742c2b7f4fd665ec9afb8931e
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Tue, 12 Mar 2019 16:20:52 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/fsdax-for-5.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3bb0f28d84f3d4e3800ae57d6b1a931b3f88c1f8
Thank you!
--
Deet-doot-dot, I am
Two regressions cause Linux to hang on boot when a Comtrol PCI card is present.
If I revert the following two commits, I can boot again and the card operates
without issue:
1302fcf0d03e (refs/bisect/bad) PCI: Configure *all* devices, not just
hot-added ones
1c3c5eab1715 sched/core: Enable
On 13/03/2019 13:34, Dan Carpenter wrote:
> On Wed, Mar 13, 2019 at 01:24:04PM +0100, Armando Miraglia wrote:
>> Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that
>> the
>> file contained style issues. This change attempts to address such style
>> problems.
>>
>
>
On 13/03/2019 17:34, Chuanhong Guo wrote:
> Hi!
> On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger
> wrote:
>>
>>
>>
>> On 13/03/2019 13:24, Armando Miraglia wrote:
>> [...]
>> Apart from fixing styling issues it would be usefull to see if we can add
>> support for mt7621 to
On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> 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
On Wed, Mar 13, 2019 at 04:06:16PM +, Al Viro wrote:
> On Wed, Mar 13, 2019 at 11:16:33AM -0400, Theodore Ts'o wrote:
> > Actually, the original use was for ChromeOS, but the primary
> > assumption is that keying is per user (or profile), and that users are
> > mutually distrustful. So when
On 13.03.19 17:37, Alexander Duyck wrote:
> On Wed, Mar 13, 2019 at 5:18 AM David Hildenbrand wrote:
>>
>> On 13.03.19 12:54, Nitesh Narayan Lal wrote:
>>>
>>> On 3/12/19 5:13 PM, Alexander Duyck wrote:
On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal
wrote:
> On 3/8/19 4:39
On Wed, Mar 13, 2019 at 5:18 AM David Hildenbrand wrote:
>
> On 13.03.19 12:54, Nitesh Narayan Lal wrote:
> >
> > On 3/12/19 5:13 PM, Alexander Duyck wrote:
> >> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal
> >> wrote:
> >>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
> On Fri, Mar 8,
On Wed, Mar 13, 2019 at 07:43:38AM +0100, Dmitry Vyukov wrote:
> It would be more useful to accept patches that make syzkaller create
> better reproducers from these people. Manual work is not scalable. We
> would need 10 reproducers per day for a dozen of OSes (incl some
> private
Hi Greg,
> > I was wondering if you think the below ABI addition looks sane to you?
> I am not the i2c maintainer :)
Peter is the i2c-mux maintainer, so I trust him very much on the I2C
side of things. We just wondered if you'd notice a general flaw when
exposing such an interface to userspace.
The clock parenting was not setup properly when DVFS was enabled. It was
expected that the same clock source was used with and without DVFS which
was not the case.
This patch fixes this issue, allowing to make the cpufreq support work
when the CPU clocks source are not the default ones.
Fixes:
--
Greetings ,
How you doing? Hope you are alright, I sent you message earlier but no
response from you, did you receive my First email to you? I am
expecting your reply as soon as you receive this email massage
(douggros...@gmail.com ),
Best Regards,
Doug Gross
On Wed, Mar 13, 2019 at 02:20:41PM +, Marc Zyngier wrote:
> 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
Hi!
On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger wrote:
>
>
>
> On 13/03/2019 13:24, Armando Miraglia wrote:
> [...]
> Apart from fixing styling issues it would be usefull to see if we can add
> support for mt7621 to drivers/spi/spi-mt65xx.c
It's impossible. They are completely different IPs.
On Wed, Mar 13, 2019 at 04:11:48PM +, Al Viro wrote:
> On Wed, Mar 13, 2019 at 08:01:27AM -0700, Eric Biggers wrote:
>
> > What do you think about this?
>
> That fscrypt might have some very deep flaws. I'll need to RTFS and
> review its model, but what I've seen in this thread so far is
On Wed, Mar 13, 2019 at 08:14:29AM -0700, Greg Kroah-Hartman wrote:
> 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
skb allocated via dev_alloc_skb can fail and return a NULL pointer.
This patch avoids such a scenario and returns, consistent with other
invocations.
Signed-off-by: Aditya Pakki
---
drivers/staging/rtlwifi/rtl8822be/fw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On Wed, Mar 13, 2019 at 03:57:42PM +0100, Arnd Bergmann wrote:
> 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
On 3/12/19 10:32 AM, Ali Saidi wrote:
> + /* Provide space for brk randomization */
> + pad += SZ_32M;
Just curious: Why is the padding in your other patch conditional on the
32-bit vs. 64-bit apps, but here it's always 32M?
Also, did you hit this problem in practice somehow?
Am Mittwoch, 13. März 2019, 17:13:52 CET schrieb James Bottomley:
> > What do you mean by "containment breaches by other tenants"? Note
> > that while the key is added, fscrypt doesn't prevent access to the
> > encrypted files.
>
> You mean it's not multiuser safe? Even if user a owns the key
On 13-Mar 15:10, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:41AM +, Patrick Bellasi wrote:
> > +uclamp_idle_value(struct rq *rq, unsigned int clamp_id, unsigned int
> > clamp_value)
> > +{
> > + /*
> > +* Avoid blocked utilization pushing up the frequency when we go
> > +
On 13/03/2019 10:14, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
When defined as macro, the mm argument is unused and subsequently the
variable passed as mm is considered unused by the compiler. This fixes
a build warning.
Signed-off-by: Bartosz Golaszewski
---
From: Vitaly Kuznetsov Sent: Wednesday, March 13, 2019
7:23 AM
> >> > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> >> > index be6e0fb..a887955 100644
> >> > --- a/drivers/clocksource/Makefile
> >> > +++ b/drivers/clocksource/Makefile
> >> > @@ -83,3 +83,4 @@
On 13-Mar 15:12, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:41AM +, Patrick Bellasi wrote:
> > +static inline void uclamp_idle_reset(struct rq *rq, unsigned int clamp_id,
> > +unsigned int clamp_value)
> > +{
> > + /* Reset max-clamp retention only
I did som more work on my youtube profile, and its getting to be a very
coherent concept. As it states: Let this fair labour construct be the
standardization and way forward for available source.
And we have decided on the name Monys for the online currency this will be
about. Where everyone
phydm.internal is allocated using kzalloc which is used multiple
times without a check for NULL pointer. This patch avoids such a
scenario.
Signed-off-by: Aditya Pakki
---
drivers/staging/rtlwifi/phydm/rtl_phydm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On Wed, 2019-03-13 at 08:51 -0700, Eric Biggers wrote:
> Hi James,
>
> On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> > 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
On 13-Mar 14:40, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:40AM +, Patrick Bellasi wrote:
> > +static inline unsigned int uclamp_bucket_id(unsigned int clamp_value)
> > +{
> > + return clamp_value / UCLAMP_BUCKET_DELTA;
> > +}
> > +
> > +static inline unsigned int
On Wed, Mar 13, 2019 at 08:01:27AM -0700, Eric Biggers wrote:
> What do you think about this?
That fscrypt might have some very deep flaws. I'll need to RTFS and
review its model, but what I've seen in this thread so far is not
promising anything good.
It's not just overlayfs - there are all
On Tue, 12 Mar 2019 21:27:06 -0400 Jerome Glisse wrote:
> Andrew you will not be pushing this patchset in 5.1 ?
I'd like to. It sounds like we're converging on a plan.
It would be good to hear more from the driver developers who will be
consuming these new features - links to patchsets,
On Tue, Mar 12, 2019 at 03:34:04PM -0700, Roman Gushchin wrote:
> @@ -2180,50 +2179,8 @@ static int memcg_hotplug_cpu_dead(unsigned int cpu)
> + for_each_mem_cgroup(memcg)
> + memcg_flush_offline_percpu(memcg, get_cpu_mask(cpu));
cpumask_of(cpu) is the official API function, with
The AP interruptions are assigned on a queue basis and
the GISA structure is handled on a VM basis, so that
we need to add a structure we can retrieve from both side
holding the information we need to handle PQAP/AQIC interception
and setup the GISA.
Since we can not add more information to the
On Wed, Mar 13, 2019 at 11:16:33AM -0400, Theodore Ts'o wrote:
> Actually, the original use was for ChromeOS, but the primary
> assumption is that keying is per user (or profile), and that users are
> mutually distrustful. So when Alice logs out of the system, her keys
> will be invalidated and
We prepare the interception of the PQAP/AQIC instruction for
the case the AQIC facility is enabled in the guest.
We add a callback inside the KVM arch structure for s390 for
a VFIO driver to handle a specific response to the PQAP
instruction with the AQIC command and only this command.
The
On Tue, 12 Mar 2019 20:10:19 -0400 Jerome Glisse wrote:
> > You're correct. We chose to go this way because the HMM code is so
> > large and all-over-the-place that developing it in a standalone tree
> > seemed impractical - better to feed it into mainline piecewise.
> >
> > This decision very
To be able to use the VFIO interface to facilitate the
mediated device memory pinning/unpinning we need to register
a notifier for IOMMU.
While we will start to pin one guest page for the interrupt indicator
byte, this is still ok with ballooning as this page will never be
used by the guest
When a AP device is remove, clear the queue's APID bit in the guest CRYCB.
to be sure that the guest will not access the AP queue anymore.
Then we clear the interruptions and reset the AP device properly.
Signed-off-by: Pierre Morel
---
drivers/s390/crypto/vfio_ap_drv.c | 36
We register the AP PQAP instruction hook during the open
of the mediated device. And unregister it on release.
In the AP PQAP instruction hook, if we receive a demand to
enable IRQs,
- we retrieve the vfio_ap_queue based on the APQN we receive
in REG1,
- we retrieve the page of the guest
AP Queue Interruption Control (AQIC) facility gives
the guest the possibility to control interruption for
the Cryptographic Adjunct Processor queues.
Signed-off-by: Pierre Morel
Reviewed-by: Tony Krowiak
---
arch/s390/tools/gen_facilities.c | 1 +
1 file changed, 1 insertion(+)
diff --git
This patch implement PQAP/AQIC interception in KVM.
To implement this we need to add a new structure, vfio_ap_queue,to be
able to retrieve the mediated device associated with a queue and specific
values needed to register/unregister the interrupt structures:
- APQN: to be able to issue the
When the mediated device is open we setup the relation with KVM unset it
when the mediated device is released.
We ensure KVM is present on opening of the mediated device.
We ensure that KVM survives the mediated device, and establish a direct
link from KVM to the mediated device to simplify the
On Wed, Mar 13, 2019 at 09:11:13AM +1100, Dave Chinner wrote:
> On Tue, Mar 12, 2019 at 03:39:33AM -0700, Ira Weiny wrote:
> > IMHO I don't think that the copy_file_range() is going to carry us through
> > the
> > next wave of user performance requirements. RDMA, while the first, is not
> > the
On Tue, Mar 12, 2019 at 03:34:02PM -0700, Roman Gushchin wrote:
> Flush percpu stats and events data to corresponding before releasing
> percpu memory.
>
> Although per-cpu stats are never exactly precise, dropping them on
> floor regularly may lead to an accumulation of an error. So, it's
>
On 13-Mar 14:52, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:40AM +, Patrick Bellasi wrote:
> > +/*
> > + * When a task is enqueued on a rq, the clamp bucket currently defined by
> > the
> > + * task's uclamp::bucket_id is reference counted on that rq. This also
> > + * immediately
On 13.03.2019 17:37, Jiri Olsa wrote:
> 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
On Wed, Mar 13, 2019 at 11:27:26AM -0400, Steven Rostedt wrote:
> 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
The current implementation does not allow two different devices to use
a common hwspinlock. This patch set proposes to have, as an option, some
hwspinlocks shared between several users.
Below is an example that explain the need for this:
exti: interrupt-controller@5000d000 {
The current implementation does not allow different devices to use a
common hwspinlock. Offer the possibility to use the same hwspinlock by
several users.
If a device registers to the framework with #hwlock-cells = 2, then
the second parameter of the 'hwlocks' DeviceTree property defines
whether
Hi James,
On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> 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
On Mon, 2019-03-11 at 12:47 -0500, Dan Murphy wrote:
> On 3/11/19 12:30 PM, Joe Perches wrote:
> > On Mon, 2019-03-11 at 12:24 -0500, Dan Murphy wrote:
> > > checkpatch takes issue with // in headers.
> > > Unless they have removed that requirement.
[]
> I guess I was referring to this SPDX
> -Original Message-
> From: Hunter, Adrian
> Sent: Wednesday, March 13, 2019 2:57 AM
> To: Ritesh Harjani ; Sowjanya Komatineni
> ; ulf.hans...@linaro.org; robh...@kernel.org;
> mark.rutl...@arm.com; Asutosh Das
> Cc: thierry.red...@gmail.com; Jonathan Hunter ;
> Aniruddha Tvs Rao
401 - 500 of 818 matches
Mail list logo
