The pull request you sent on Fri, 30 Nov 2018 07:29:06 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1ec63573b2db363848abb313cc75eb29e9abc1b3
Thank you!
--
Deet-doot-dot, I am
The pull request you sent on Fri, 30 Nov 2018 07:21:02 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8d9f412d51b84eafd2253a82120e218ddc53e721
Thank you!
--
Deet-doot-dot, I am
The pull request you sent on Fri, 30 Nov 2018 07:29:06 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1ec63573b2db363848abb313cc75eb29e9abc1b3
Thank you!
--
Deet-doot-dot, I am
The pull request you sent on Fri, 30 Nov 2018 17:06:23 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
> tags/char-misc-4.20-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b6839ef26e549de68c10359d45163b0cfb031183
Thank you!
--
On Fri, Nov 30, 2018 at 12:28 PM Steven Rostedt wrote:
>
> On Fri, 30 Nov 2018 12:18:33 -0800
> Andy Lutomirski wrote:
>
> > Or we could replace that IPI with x86's bona fide serialize-all-cpus
> > primitive and then we can just retry instead of emulating. It's a
> > piece of cake -- we just
On Fri, Nov 30, 2018 at 12:28 PM Steven Rostedt wrote:
>
> On Fri, 30 Nov 2018 12:18:33 -0800
> Andy Lutomirski wrote:
>
> > Or we could replace that IPI with x86's bona fide serialize-all-cpus
> > primitive and then we can just retry instead of emulating. It's a
> > piece of cake -- we just
On Fri, Nov 30, 2018 at 02:41:11PM -0500, Steven Rostedt wrote:
> Since the code has been greatly modified since that comment was added,
> I would say the comment is simply out of date.
>
> Just nuke the comment, and that will be an accurate change with or
> without CoC.
Thanks, will do.
On Fri, Nov 30, 2018 at 02:41:11PM -0500, Steven Rostedt wrote:
> Since the code has been greatly modified since that comment was added,
> I would say the comment is simply out of date.
>
> Just nuke the comment, and that will be an accurate change with or
> without CoC.
Thanks, will do.
On Fri, Nov 30, 2018 at 08:44:24PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/30/18 8:27 PM, Jarkko Sakkinen wrote:
> > In order to comply with the CoC, replace with a hug.
> >
> > -/* master list of VME vectors -- don't fuck with this */
> > +/* master list of VME vectors -- don't hug
On Fri, Nov 30, 2018 at 08:44:24PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/30/18 8:27 PM, Jarkko Sakkinen wrote:
> > In order to comply with the CoC, replace with a hug.
> >
> > -/* master list of VME vectors -- don't fuck with this */
> > +/* master list of VME vectors -- don't hug
On Fri, Nov 30 2018 at 01:25 -0700, Ulf Hansson wrote:
On Thu, 29 Nov 2018 at 23:31, Lina Iyer wrote:
Hi Ulf,
On Thu, Nov 29 2018 at 10:50 -0700, Ulf Hansson wrote:
>When the hierarchical CPU topology is used and when a CPU has been put
>offline (hotplug), that same CPU prevents its PM
On Fri, Nov 30, 2018 at 08:39:06PM +0100, Boris Brezillon wrote:
> On Fri, 30 Nov 2018 11:27:18 -0800
> Jarkko Sakkinen wrote:
>
> > In order to comply with the CoC, replace with a hug.
> >
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > drivers/mtd/mtd_blkdevs.c | 2 +-
> > 1 file
On Fri, Nov 30 2018 at 01:25 -0700, Ulf Hansson wrote:
On Thu, 29 Nov 2018 at 23:31, Lina Iyer wrote:
Hi Ulf,
On Thu, Nov 29 2018 at 10:50 -0700, Ulf Hansson wrote:
>When the hierarchical CPU topology is used and when a CPU has been put
>offline (hotplug), that same CPU prevents its PM
On Fri, Nov 30, 2018 at 08:39:06PM +0100, Boris Brezillon wrote:
> On Fri, 30 Nov 2018 11:27:18 -0800
> Jarkko Sakkinen wrote:
>
> > In order to comply with the CoC, replace with a hug.
> >
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > drivers/mtd/mtd_blkdevs.c | 2 +-
> > 1 file
From: Sven Van Asbroeck
Support multiple address ranges per child node on imx-weim.
While we're at it, insert some code which guards against common config
conflicts.
v2:
corrected acme@... in commit message example
Sven Van Asbroeck (2):
bus: imx-weim: support multiple address ranges
From: Sven Van Asbroeck
Ensure that timing values for the child node are applied to
all chip selects in the child's address ranges.
Note that this does not support multiple timing settings per
child; this can be added in the future if required.
Example:
{
acme@0,0 {
From: Sven Van Asbroeck
Support multiple address ranges per child node on imx-weim.
While we're at it, insert some code which guards against common config
conflicts.
v2:
corrected acme@... in commit message example
Sven Van Asbroeck (2):
bus: imx-weim: support multiple address ranges
From: Sven Van Asbroeck
Ensure that timing values for the child node are applied to
all chip selects in the child's address ranges.
Note that this does not support multiple timing settings per
child; this can be added in the future if required.
Example:
{
acme@0,0 {
From: Sven Van Asbroeck
When adding weim child devices, there is a risk that the developer will
(by mistake) specify more than one timing setting for the same chip select.
The driver cannot support such a configuration.
In case of conflict, this patch will print a warning to the log,
and will
From: Sven Van Asbroeck
When adding weim child devices, there is a risk that the developer will
(by mistake) specify more than one timing setting for the same chip select.
The driver cannot support such a configuration.
In case of conflict, this patch will print a warning to the log,
and will
[ Cleared out the Cc list to something more reasonable ]
On Fri, 30 Nov 2018 20:45:57 +
Abuse wrote:
> On Friday, 30 November 2018 20:42:28 GMT David Miller wrote:
> > From: Abuse
> > Date: Fri, 30 Nov 2018 20:39:01 +
> >
> > > I assume I will now be barred.
> >
> > Perhaps, but
[ Cleared out the Cc list to something more reasonable ]
On Fri, 30 Nov 2018 20:45:57 +
Abuse wrote:
> On Friday, 30 November 2018 20:42:28 GMT David Miller wrote:
> > From: Abuse
> > Date: Fri, 30 Nov 2018 20:39:01 +
> >
> > > I assume I will now be barred.
> >
> > Perhaps, but
> -Original Message-
> From: Arnd Bergmann
> Sent: vendredi 30 novembre 2018 15:33
> To: Loic PALLARDY
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; Benjamin Gaignard
> ; Suman Anna
> Subject: Re: [PATCH
> -Original Message-
> From: Arnd Bergmann
> Sent: vendredi 30 novembre 2018 15:33
> To: Loic PALLARDY
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; Benjamin Gaignard
> ; Suman Anna
> Subject: Re: [PATCH
On Fri, Nov 30, 2018 at 11:48:24AM -0800, Kees Cook wrote:
> Better yet, since it's only 17 files, how about doing context-specific
> changes? "This API is terrible"
I think we should only use "good" with selected operators like !, ++, --
E.g. "This API is !good++"
Suggested-by: George Orwell
On Fri, Nov 30, 2018 at 11:48:24AM -0800, Kees Cook wrote:
> Better yet, since it's only 17 files, how about doing context-specific
> changes? "This API is terrible"
I think we should only use "good" with selected operators like !, ++, --
E.g. "This API is !good++"
Suggested-by: George Orwell
On Mon, Nov 5, 2018 at 10:01 PM Liu Jingqi wrote:
>
> Direct stores instructions MOVDIRI and MOVDIR64B will be available in
> Tremont and other future x86 processors,
> and need to be exposed to guest VM.
It seems like KVM's emulator should be able to complete these
instructions to emulated MMIO
On Mon, Nov 5, 2018 at 10:01 PM Liu Jingqi wrote:
>
> Direct stores instructions MOVDIRI and MOVDIR64B will be available in
> Tremont and other future x86 processors,
> and need to be exposed to guest VM.
It seems like KVM's emulator should be able to complete these
instructions to emulated MMIO
On Fri, Nov 30, 2018 at 8:06 AM Greg KH wrote:
>
> It resolves an issue with the data alignment in 'struct devres' for the
> ARC platform. The full details are in the commit changelog, but the
> short summary is the change is a single line:
>
> - unsigned long long data[]; /*
On Fri, Nov 30, 2018 at 8:06 AM Greg KH wrote:
>
> It resolves an issue with the data alignment in 'struct devres' for the
> ARC platform. The full details are in the commit changelog, but the
> short summary is the change is a single line:
>
> - unsigned long long data[]; /*
On Fri, Nov 30, 2018 at 05:14:41AM -0500, Sasha Levin wrote:
> On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote:
> > On Fri, Nov 30, 2018 at 09:40:19AM +1100, Dave Chinner wrote:
> > > I stopped my tests at 5 billion ops yesterday (i.e. 20 billion ops
> > > aggregate) to focus on testing
On Fri, Nov 30, 2018 at 05:14:41AM -0500, Sasha Levin wrote:
> On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote:
> > On Fri, Nov 30, 2018 at 09:40:19AM +1100, Dave Chinner wrote:
> > > I stopped my tests at 5 billion ops yesterday (i.e. 20 billion ops
> > > aggregate) to focus on testing
This adds a GitLab CI config file running the DT unittest in a usermode
Linux build. The corresponding CI job can be found here:
https://gitlab.com/robherring/linux-dt-unittest/pipelines
This CI job can be duplicated by others by creating a kernel repo on a
GitLab instance and configuring GitLab
This adds a GitLab CI config file running the DT unittest in a usermode
Linux build. The corresponding CI job can be found here:
https://gitlab.com/robherring/linux-dt-unittest/pipelines
This CI job can be duplicated by others by creating a kernel repo on a
GitLab instance and configuring GitLab
On Fri, 30 Nov 2018 12:18:33 -0800
Andy Lutomirski wrote:
> Or we could replace that IPI with x86's bona fide serialize-all-cpus
> primitive and then we can just retry instead of emulating. It's a
> piece of cake -- we just trigger an SMI :) /me runs away.
I must have fallen on my head one
On Fri, 30 Nov 2018 12:18:33 -0800
Andy Lutomirski wrote:
> Or we could replace that IPI with x86's bona fide serialize-all-cpus
> primitive and then we can just retry instead of emulating. It's a
> piece of cake -- we just trigger an SMI :) /me runs away.
I must have fallen on my head one
On Tue, Nov 27, 2018 at 09:59:36PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> ... instead of issuing it per CPU and flooding dmesg unnecessarily.
>
> Signed-off-by: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Ingo Molnar
> Cc: Ricardo Neri
> Cc: Thomas Gleixner
This make
On Tue, Nov 27, 2018 at 09:59:36PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> ... instead of issuing it per CPU and flooding dmesg unnecessarily.
>
> Signed-off-by: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Ingo Molnar
> Cc: Ricardo Neri
> Cc: Thomas Gleixner
This make
Guenter had some minor changes to patch #2, which I've done in this
version.
Eric Anholt (5):
dt-bindings: soc: Add a new binding for the BCM2835 PM node.
bcm2835-pm: Move bcm2835-watchdog's DT probe to an MFD.
soc: bcm: bcm2835-pm: Add support for power domains under a new
binding.
This provides a free software alternative to raspberrypi-power.c's
firmware calls to manage power domains. It also exposes a reset line,
where previously the vc4 driver had to try to force power off the
domain in order to trigger a reset.
Signed-off-by: Eric Anholt
---
drivers/mfd/bcm2835-pm.c
This binding supersedes the bcm2835-pm-wdt binding which only covered
enough to provide a watchdog, but the HW block is actually mostly
about power domains.
Signed-off-by: Eric Anholt
---
.../bindings/soc/bcm/brcm,bcm2835-pm.txt | 42 +++
1 file changed, 42 insertions(+)
The GRAFX domain only contains V3D, and this driver should be the only
accessor of V3D (firmware usage gets disabled when V3D is in the DT),
so we can safely make Linux control the GRAFX and GRAFX_V3D power
domains.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
On 11/30, Chao Yu wrote:
> On 2018/11/30 10:35, Sheng Yong wrote:
> > Hi, Jaegeuk and Chao,
> >
> > On 2018/11/29 1:48, Jaegeuk Kim wrote:
> >> On 11/28, Chao Yu wrote:
> >>> On 2018/11/28 16:10, Jaegeuk Kim wrote:
> On 11/28, Chao Yu wrote:
> > Hi Jaeguek,
> >
> > On 2018/11/28
Guenter had some minor changes to patch #2, which I've done in this
version.
Eric Anholt (5):
dt-bindings: soc: Add a new binding for the BCM2835 PM node.
bcm2835-pm: Move bcm2835-watchdog's DT probe to an MFD.
soc: bcm: bcm2835-pm: Add support for power domains under a new
binding.
This provides a free software alternative to raspberrypi-power.c's
firmware calls to manage power domains. It also exposes a reset line,
where previously the vc4 driver had to try to force power off the
domain in order to trigger a reset.
Signed-off-by: Eric Anholt
---
drivers/mfd/bcm2835-pm.c
This binding supersedes the bcm2835-pm-wdt binding which only covered
enough to provide a watchdog, but the HW block is actually mostly
about power domains.
Signed-off-by: Eric Anholt
---
.../bindings/soc/bcm/brcm,bcm2835-pm.txt | 42 +++
1 file changed, 42 insertions(+)
The GRAFX domain only contains V3D, and this driver should be the only
accessor of V3D (firmware usage gets disabled when V3D is in the DT),
so we can safely make Linux control the GRAFX and GRAFX_V3D power
domains.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
On 11/30, Chao Yu wrote:
> On 2018/11/30 10:35, Sheng Yong wrote:
> > Hi, Jaegeuk and Chao,
> >
> > On 2018/11/29 1:48, Jaegeuk Kim wrote:
> >> On 11/28, Chao Yu wrote:
> >>> On 2018/11/28 16:10, Jaegeuk Kim wrote:
> On 11/28, Chao Yu wrote:
> > Hi Jaeguek,
> >
> > On 2018/11/28
The PM block that the wdt driver was binding to actually has multiple
features we want to expose (power domains, reset, watchdog). Move the
DT attachment to a MFD driver and make WDT probe against MFD.
Signed-off-by: Eric Anholt
---
v3: don't reset bcm2835_power_off_wdt on remove, drop pm
It was covering part of the PM block's range, up to the WDT regs. To
support the rest of the PM block's functionality, we need the full
register range plus the AXI Async Bridge regs for PM sequencing.
This doesn't convert any of the consumers over to the new binding yet,
since we will need to be
The PM block that the wdt driver was binding to actually has multiple
features we want to expose (power domains, reset, watchdog). Move the
DT attachment to a MFD driver and make WDT probe against MFD.
Signed-off-by: Eric Anholt
---
v3: don't reset bcm2835_power_off_wdt on remove, drop pm
It was covering part of the PM block's range, up to the WDT regs. To
support the rest of the PM block's functionality, we need the full
register range plus the AXI Async Bridge regs for PM sequencing.
This doesn't convert any of the consumers over to the new binding yet,
since we will need to be
On Fri, Nov 30, 2018 at 11:51 AM Linus Torvalds
wrote:
>
> On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote:
> >
> > AFAICT, all the other proposed options seem to have major issues.
>
> I still absolutely detest this patch, and in fact it got worse from
> the test of the config variable.
>
On Fri, Nov 30, 2018 at 11:51 AM Linus Torvalds
wrote:
>
> On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote:
> >
> > AFAICT, all the other proposed options seem to have major issues.
>
> I still absolutely detest this patch, and in fact it got worse from
> the test of the config variable.
>
Em Fri, Nov 30, 2018 at 03:09:44PM -0500, Steven Rostedt escreveu:
> On Fri, 30 Nov 2018 16:18:56 -0300
> Arnaldo Carvalho de Melo wrote:
>
> > Em Fri, Nov 30, 2018 at 10:44:10AM -0500, Steven Rostedt escreveu:
> > > From: Tzvetomir Stoyanov
> > >
> > > In order to make libtraceevent into a
Hi Kalle,
Have you had a chance to check out these patches yet?
--
Kyle Roeschley
Software Engineer
National Instruments
Em Fri, Nov 30, 2018 at 03:09:44PM -0500, Steven Rostedt escreveu:
> On Fri, 30 Nov 2018 16:18:56 -0300
> Arnaldo Carvalho de Melo wrote:
>
> > Em Fri, Nov 30, 2018 at 10:44:10AM -0500, Steven Rostedt escreveu:
> > > From: Tzvetomir Stoyanov
> > >
> > > In order to make libtraceevent into a
Hi Kalle,
Have you had a chance to check out these patches yet?
--
Kyle Roeschley
Software Engineer
National Instruments
The linux-mips.org infrastructure has been unreliable recently & nobody
with sufficient access to fix it is around to do so. As a result we're
moving away from it, and part of this is migrating our mailing list to
kernel.org.
Replace all instances of linux-m...@linux-mips.org in MAINTAINERS with
The linux-mips.org infrastructure has been unreliable recently & nobody
with sufficient access to fix it is around to do so. As a result we're
moving away from it, and part of this is migrating our mailing list to
kernel.org.
Replace all instances of linux-m...@linux-mips.org in MAINTAINERS with
On Fri, 30 Nov 2018 16:18:56 -0300
Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 30, 2018 at 10:44:10AM -0500, Steven Rostedt escreveu:
> > From: Tzvetomir Stoyanov
> >
> > In order to make libtraceevent into a proper library, its API
> > should be straightforward. This patch hides few API
On Fri, 30 Nov 2018 16:18:56 -0300
Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 30, 2018 at 10:44:10AM -0500, Steven Rostedt escreveu:
> > From: Tzvetomir Stoyanov
> >
> > In order to make libtraceevent into a proper library, its API
> > should be straightforward. This patch hides few API
On Fri, Nov 30, 2018 at 11:08 AM wrote:
>
> From: Sven Van Asbroeck
>
> When adding weim child devices, there is a risk that the developer will
> (by mistake) specify more than one timing setting for the same chip select.
>
> The driver cannot support such a configuration.
>
> In case of
On Fri, Nov 30, 2018 at 11:08 AM wrote:
>
> From: Sven Van Asbroeck
>
> When adding weim child devices, there is a risk that the developer will
> (by mistake) specify more than one timing setting for the same chip select.
>
> The driver cannot support such a configuration.
>
> In case of
If we drop the mmap_sem we have to redo the vma lookup which requires
redoing the fault handler. Chances are we will just come back to the
same page, so save this page in our vmf->cached_page and reuse it in the
next loop through the fault handler.
Signed-off-by: Josef Bacik
---
mm/filemap.c |
If we drop the mmap_sem we have to redo the vma lookup which requires
redoing the fault handler. Chances are we will just come back to the
same page, so save this page in our vmf->cached_page and reuse it in the
next loop through the fault handler.
Signed-off-by: Josef Bacik
---
mm/filemap.c |
Currently we only drop the mmap_sem if there is contention on the page
lock. The idea is that we issue readahead and then go to lock the page
while it is under IO and we want to not hold the mmap_sem during the IO.
The problem with this is the assumption that the readahead does
anything. In the
We want to be able to cache the result of a previous loop of a page
fault in the case that we use VM_FAULT_RETRY, so introduce
handle_mm_fault_cacheable that will take a struct vm_fault directly, add
a ->cached_page field to vm_fault, and add helpers to init/cleanup the
struct vm_fault.
I've
If we do not have a page at filemap_fault time we'll do this weird
forced page_cache_read thing to populate the page, and then drop it
again and loop around and find it. This makes for 2 ways we can read a
page in filemap_fault, and it's not really needed. Instead add a
FGP_FOR_MMAP flag so that
Currently we only drop the mmap_sem if there is contention on the page
lock. The idea is that we issue readahead and then go to lock the page
while it is under IO and we want to not hold the mmap_sem during the IO.
The problem with this is the assumption that the readahead does
anything. In the
We want to be able to cache the result of a previous loop of a page
fault in the case that we use VM_FAULT_RETRY, so introduce
handle_mm_fault_cacheable that will take a struct vm_fault directly, add
a ->cached_page field to vm_fault, and add helpers to init/cleanup the
struct vm_fault.
I've
If we do not have a page at filemap_fault time we'll do this weird
forced page_cache_read thing to populate the page, and then drop it
again and loop around and find it. This makes for 2 ways we can read a
page in filemap_fault, and it's not really needed. Instead add a
FGP_FOR_MMAP flag so that
(reducing CC, as per later advice)
On Fri, Nov 30, 2018 at 8:40 PM Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> wrote:
> >
> > In order to comply with the CoC, replace with a hug.
>
> Heh. I support the replacement of the stronger language, but I find
> "hug",
On Fri, Nov 30, 2018 at 11:27:10AM -0800, Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> Signed-off-by: Jarkko Sakkinen
Since v17 of the SGX patch set, my cover letters get cut for some
reason. I receive them myself but they don't appear on kernel
lists.
v3->v4:
- dropped the ->page_mkwrite portion of these patches, we don't actually see
issues with mkwrite in production, and I kept running into corner cases where
I missed something important. I want to wait on that part until I have a real
reason to do the work so I can have a solid test
(reducing CC, as per later advice)
On Fri, Nov 30, 2018 at 8:40 PM Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> wrote:
> >
> > In order to comply with the CoC, replace with a hug.
>
> Heh. I support the replacement of the stronger language, but I find
> "hug",
On Fri, Nov 30, 2018 at 11:27:10AM -0800, Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> Signed-off-by: Jarkko Sakkinen
Since v17 of the SGX patch set, my cover letters get cut for some
reason. I receive them myself but they don't appear on kernel
lists.
v3->v4:
- dropped the ->page_mkwrite portion of these patches, we don't actually see
issues with mkwrite in production, and I kept running into corner cases where
I missed something important. I want to wait on that part until I have a real
reason to do the work so I can have a solid test
On Fri, 30 Nov 2018 14:37:36 -0500
Steven Rostedt wrote:
> What branch are you applying it against? Just to make sure I'm testing
> the same thing you are.
Nevermind, I just downloaded your repo.
BTW, should I be basing these patches off of your repo or tip/perf/core?
-- Steve
On Fri, 30 Nov 2018 14:37:36 -0500
Steven Rostedt wrote:
> What branch are you applying it against? Just to make sure I'm testing
> the same thing you are.
Nevermind, I just downloaded your repo.
BTW, should I be basing these patches off of your repo or tip/perf/core?
-- Steve
Em Fri, Nov 30, 2018 at 02:37:36PM -0500, Steven Rostedt escreveu:
> On Fri, 30 Nov 2018 16:18:56 -0300
> Arnaldo Carvalho de Melo wrote:
>
> > Em Fri, Nov 30, 2018 at 10:44:10AM -0500, Steven Rostedt escreveu:
> > > From: Tzvetomir Stoyanov
> > >
> > > In order to make libtraceevent into a
On Fri, Nov 30, 2018 at 04:32:40AM -0500, Huijin Park wrote:
> From: "huijin.park"
>
> This patch changes the 'sectors' type to an u64.
> In 32 bit system, the 'sectors' can accumulate up to about 2TiB.
> If a 32 bit system makes i/o over 2TiB while running,
> the 'sectors' will overflow.
> As a
Em Fri, Nov 30, 2018 at 02:37:36PM -0500, Steven Rostedt escreveu:
> On Fri, 30 Nov 2018 16:18:56 -0300
> Arnaldo Carvalho de Melo wrote:
>
> > Em Fri, Nov 30, 2018 at 10:44:10AM -0500, Steven Rostedt escreveu:
> > > From: Tzvetomir Stoyanov
> > >
> > > In order to make libtraceevent into a
On Fri, Nov 30, 2018 at 04:32:40AM -0500, Huijin Park wrote:
> From: "huijin.park"
>
> This patch changes the 'sectors' type to an u64.
> In 32 bit system, the 'sectors' can accumulate up to about 2TiB.
> If a 32 bit system makes i/o over 2TiB while running,
> the 'sectors' will overflow.
> As a
On Fri, 30 Nov 2018, Jonathan Corbet wrote:
> > Since the code has been greatly modified since that comment was added,
> > I would say the comment is simply out of date.
> >
> > Just nuke the comment, and that will be an accurate change with or
> > without CoC.
>
> For both patches, actually,
On Fri, 30 Nov 2018, Jonathan Corbet wrote:
> > Since the code has been greatly modified since that comment was added,
> > I would say the comment is simply out of date.
> >
> > Just nuke the comment, and that will be an accurate change with or
> > without CoC.
>
> For both patches, actually,
[resend with CCs dropped so it'll actually get delivered to lkml...]
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
>
> In order to comply with the CoC, replace with a hug.
Heh. I support the replacement of the stronger language, but I find
"hug", "hugged", and "hugging" to be
[resend with CCs dropped so it'll actually get delivered to lkml...]
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
>
> In order to comply with the CoC, replace with a hug.
Heh. I support the replacement of the stronger language, but I find
"hug", "hugged", and "hugging" to be
On Fri, 30 Nov 2018 14:41:11 -0500
Steven Rostedt wrote:
> > - * Wirzenius wrote this portably, Torvalds fucked it up :-)
> > + * Wirzenius wrote this portably, Torvalds hugged it up :-)
>
> Since the code has been greatly modified since that comment was added,
> I would say the comment is
On Fri, 30 Nov 2018 14:41:11 -0500
Steven Rostedt wrote:
> > - * Wirzenius wrote this portably, Torvalds fucked it up :-)
> > + * Wirzenius wrote this portably, Torvalds hugged it up :-)
>
> Since the code has been greatly modified since that comment was added,
> I would say the comment is
On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote:
>
> AFAICT, all the other proposed options seem to have major issues.
I still absolutely detest this patch, and in fact it got worse from
the test of the config variable.
Honestly, the entry code being legible and simple is more important
On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote:
>
> AFAICT, all the other proposed options seem to have major issues.
I still absolutely detest this patch, and in fact it got worse from
the test of the config variable.
Honestly, the entry code being legible and simple is more important
On Fri, Nov 30, 2018 at 11:41:49AM -0800, Jarkko Sakkinen wrote:
> Even after looking at the spec the last field does not make sense as the
> event after digests and digests are not in union. It is just not right.
>
> The comment does not fix that.
You should remove the last field and rename the
On Fri, Nov 30, 2018 at 11:41:49AM -0800, Jarkko Sakkinen wrote:
> Even after looking at the spec the last field does not make sense as the
> event after digests and digests are not in union. It is just not right.
>
> The comment does not fix that.
You should remove the last field and rename the
On 11/30/18 8:27 PM, Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> -/* master list of VME vectors -- don't fuck with this */
> +/* master list of VME vectors -- don't hug with this */
Never in my dreams would I have expected that the dystopia predicted
in
On 11/30/18 8:27 PM, Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> -/* master list of VME vectors -- don't fuck with this */
> +/* master list of VME vectors -- don't hug with this */
Never in my dreams would I have expected that the dystopia predicted
in
On Thu, Nov 29, 2018 at 01:04:40PM +0100, Roberto Sassu wrote:
> > > > + struct tpm2_digest digests[0];
> > > > struct tcg_event_field event;
> > > > } __packed;
> > > > --
> > > > 2.17.1
> > > >
> > >
> > > NAK for the same reason as last time.
> >
> > I added this comment to
On Thu, Nov 29, 2018 at 01:04:40PM +0100, Roberto Sassu wrote:
> > > > + struct tpm2_digest digests[0];
> > > > struct tcg_event_field event;
> > > > } __packed;
> > > > --
> > > > 2.17.1
> > > >
> > >
> > > NAK for the same reason as last time.
> >
> > I added this comment to
On Fri, 30 Nov 2018 11:27:23 -0800
Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> lib/vsprintf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index
On Fri, 30 Nov 2018 11:27:23 -0800
Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> lib/vsprintf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index
301 - 400 of 1382 matches
Mail list logo
