On Tue, Nov 03 2015, James Bottomley
wrote:
> From: James Bottomley
>
> It was noticed that we lose precision in the final calculation for some
> inputs. The most egregious example is size=3000 blk_size=1900 in units of 10
> should yield 5.70 MB but in fact yields 3.00 MB (oops). This is becau
On Tue, Nov 3, 2015 at 5:09 PM, Pavel Machek wrote:
> Hi!
>
>> >> >4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But
>> >> >my monitor is native 1920x1080, so that mode looks pretty ugly on
>> >> >screen. If I go to 1920x1080, I see colored horizontal lines (often
>> >> >black)
On Nov 3, 2015, at 8:16 AM, Andreas Gruenbacher wrote:
>
> POSIX ACLs and richacls are both objects allocated by kmalloc() with a
> reference count which are freed by kfree_rcu(). An inode can either
> cache an access and a default POSIX ACL, or a richacl (richacls do not
> have default acls).
While working on a paravirt cpuidle driver for KVM guests, I
noticed a number of small logic errors in the menu governor
code.
These patches should get rid of some artifacts that can break
the logic in the menu governor under certain corner cases, and
make idle state selection work better on CPUs
From: Rik van Riel
The cpuidle state tables contain the maximum exit latency for each
cpuidle state. On x86, that is the exit latency for when the entire
package goes into that same idle state.
However, a lot of the time we only go into the core idle state,
not the package idle state. This means
From: Rik van Riel
The cpuidle menu governor has a forced cut-off for polling at 5us,
in order to deal with firmware that gives the OS bad information
on cpuidle states, leading to the system spending way too much time
in polling.
However, at least one x86 CPU family (Atom) has chips that have
a
From: Rik van Riel
The menu governor carefully figures out how much time we typically
sleep for an estimated sleep interval, or whether there is a repeating
pattern going on, and corrects that estimate for the CPU load.
Then it proceeds to ignore that information when determining whether
or not
On 11/03/2015 05:05 PM, Rafael J. Wysocki wrote:
> On 10/28/2015 11:46 PM, r...@redhat.com wrote:
>> While working on a paravirt cpuidle driver for KVM guests, I
>> noticed a number of small logic errors in the menu governor
>> code.
>>
>> These patches should get rid of some artifacts that can bre
On Tue, Nov 03, 2015 at 11:19:44AM -0800, Kees Cook wrote:
> On Tue, Nov 3, 2015 at 10:10 AM, Daniel Cashman wrote:
> > From: dcashman
> >
> > arm: arch_mmap_rnd() uses a hard-code value of 8 to generate the
> > random offset for the mmap base address. This value represents a
> > compromise betw
> -Original Message-
> From: J. German Rivera [mailto:german.riv...@freescale.com]
> Sent: Friday, October 30, 2015 3:05 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; devicet...@vger.kernel.org;
> linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: Sharma Bhu
On Tue, Nov 3, 2015 at 1:41 AM, Rasmus Villemoes
wrote:
>
> I'm sure I've missed something, hence the RFC. But if not, there's
> probably also a few memsets which become redundant. And the
> __set_close_on_exec part should probably be its own patch...
The patch looks fine to me. I'm not sure the
On Tue, Nov 03, 2015 at 10:40:29PM +0100, Richard Weinberger wrote:
> On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila
> wrote:
> > LKL (Linux Kernel Library) is aiming to allow reusing the Linux kernel code
> > as extensively as possible with minimal effort and reduced maintenance
> > overhead.
>
On Tue, Nov 3, 2015 at 11:01 AM, Ross Zwisler
wrote:
> On Sun, Nov 01, 2015 at 11:29:58PM -0500, Dan Williams wrote:
>> The DAX implementation needs to protect new calls to ->direct_access()
>> and usage of its return value against unbind of the underlying block
>> device. Use blk_queue_enter()/b
On Tue, 2015-11-03 at 23:13 +0100, Rasmus Villemoes wrote:
> On Tue, Nov 03 2015, James Bottomley
> wrote:
>
> > From: James Bottomley
> >
> > It was noticed that we lose precision in the final calculation for some
> > inputs. The most egregious example is size=3000 blk_size=1900 in units of
Hello, Jeff.
On Tue, Nov 03, 2015 at 12:55:04PM -0500, Jeff Layton wrote:
> > Ok, I built a kernel with that patch reverted and that seems to fix the
> > problem.
> >
> > Looking at the patch, I guess the main difference is that we're no
> > longer using add_timer for unbound workqueue tasks. Tha
On Tue, Nov 03, 2015 at 09:41:17AM -0600, Michael Welling wrote:
> On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> > On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
> > wrote:
> > > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> > >> On Mon, Nov 02, 2015 at 09:19
On 11/03/2015 02:11 PM, Jarod Wilson wrote:
Alexander Duyck wrote:
On 11/03/2015 12:36 PM, Jarod Wilson wrote:
With moving netdev_sync_lower_features() after the .ndo_set_features
calls, I neglected to verify that devices added *after* a flag had been
disabled on an upper device were properly a
Hi!
> >> >> >Any ideas?
> >> >>
> >> >> Alex probably knows more about this, but it sounds like problems with
> >> >> switching the memory clocks on 3D load.
> >> >
> >> >> Try to disable power management completely with radeon.dpm=0 on the
> >> >> kernel
> >> >> command line or nailing the hard
On 11/3/2015 11:35 PM, Rik van Riel wrote:
On 11/03/2015 05:05 PM, Rafael J. Wysocki wrote:
On 10/28/2015 11:46 PM, r...@redhat.com wrote:
While working on a paravirt cpuidle driver for KVM guests, I
noticed a number of small logic errors in the menu governor
code.
These patches should get rid
Hi Linus,
On 03.11.2015 22:01, Linus Torvalds wrote:
> On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller wrote:
>>
>> please pull some patches for the parisc architecture for kernel v4.3 from:
>
> So no way was I going to pull that for 4.3,
Yes, since you didn't pulled I assumed you saw some kind o
On Tue, Nov 3, 2015 at 12:20 PM, Dave Chinner wrote:
> On Mon, Nov 02, 2015 at 11:35:04PM -0800, Dan Williams wrote:
>> On Mon, Nov 2, 2015 at 4:32 PM, Dave Chinner wrote:
[..]
>> Only in the mmap path:
>
> which means blkdev_direct_IO() is now always going to go down the
> dax_do_io() path for a
On Tue, Nov 3, 2015 at 11:40 PM, Richard Weinberger
wrote:
Hi Richard,
> On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila
> wrote:
>> LKL (Linux Kernel Library) is aiming to allow reusing the Linux kernel code
>> as extensively as possible with minimal effort and reduced maintenance
>> overhead
On Tue, Nov 03, 2015 at 02:59:13PM -0800, Dmitry Torokhov wrote:
> On Tue, Nov 03, 2015 at 09:41:17AM -0600, Michael Welling wrote:
> > On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> > > On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
> > > wrote:
> > > > On Mon, Nov 02, 2015 at 02
From: James Bottomley
It was noticed that we lose precision in the final calculation for some
inputs. The most egregious example is size=3000 blk_size=1900 in units of 10
should yield 5.70 MB but in fact yields 3.00 MB (oops). This is because the
current algorithm doesn't correctly account for a
On Tue, Nov 03 2015, Linus Torvalds wrote:
> On Tue, Nov 3, 2015 at 1:41 AM, Rasmus Villemoes
> wrote:
>>
>> I'm sure I've missed something, hence the RFC. But if not, there's
>> probably also a few memsets which become redundant. And the
>> __set_close_on_exec part should probably be its own pa
On 11/03/2015 11:19 AM, Kees Cook wrote:
> Do you have patches for x86 and arm64?
I was holding off on those until I could gauge upstream reception. If
desired, I could put those together and add them as [PATCH 3/4] and
[PATCH 4/4].
Thank You,
Dan
--
To unsubscribe from this list: send the line
Hi!
> >> Unfortunately, it can't be applied as is because we had a similar
> >> patch which was reverted because it regressed a bunch of other
> >> systems. The actual pll limits probably need to be tweaked.
> >
> > Any ideas how to tweak the pll limits?
>
> Adjust the the algorithm in radeon_co
Hello Oleg, everyone,
I have noticed something, which may be considered a race in the
interaction of ptrace and pseudoterminal interfaces. Basically, what
happens is this:
- we have two processes: A and B. B has the slave end of the pty open,
A has the master. A is tracing B.
- B writes some data
On Tue, Nov 3, 2015 at 2:39 PM, Russell King - ARM Linux
wrote:
> On Tue, Nov 03, 2015 at 11:19:44AM -0800, Kees Cook wrote:
>> On Tue, Nov 3, 2015 at 10:10 AM, Daniel Cashman wrote:
>> > From: dcashman
>> >
>> > arm: arch_mmap_rnd() uses a hard-code value of 8 to generate the
>> > random offset
On Tue, Nov 3, 2015 at 3:14 PM, Daniel Cashman wrote:
> On 11/03/2015 11:19 AM, Kees Cook wrote:
>> Do you have patches for x86 and arm64?
>
> I was holding off on those until I could gauge upstream reception. If
> desired, I could put those together and add them as [PATCH 3/4] and
> [PATCH 4/4].
On Tue, 3 Nov 2015 10:20:38 -0800, Kees Cook wrote:
> On Mon, Nov 2, 2015 at 4:39 PM, Dirk Steinmetz
> wrote:
> > In order to hardlink to a sgid-executable, it is sufficient to be the
> > file's owner. When hardlinking within an unprivileged user namespace, the
> > users of that namespace could th
At Tue, 3 Nov 2015 22:45:45 +,
Richard W.M. Jones wrote:
> > > * cptofs/cpfromfs - a tool that copies files to/from a filesystem image
> >
> > Seeing forward to have a libguestfs port. :-)
>
> Thanks - I was keeping an eye on libos (and on the NetBSD rump kernel
> stuff before), ready to in
On Wed, Nov 4, 2015 at 12:45 AM, Richard W.M. Jones wrote:
> On Tue, Nov 03, 2015 at 10:40:29PM +0100, Richard Weinberger wrote:
>> On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila
>> wrote:
>> > LKL (Linux Kernel Library) is aiming to allow reusing the Linux kernel code
>> > as extensively as po
On Tue, Nov 3, 2015 at 3:03 PM, Helge Deller wrote:
>
> Sadly it's nowhere clearly documented how big the L1 cacheline of parisc
> really is.
Wow.
Particularly that "it might actually be 16 bytes" from the thread
according to John David Anglin. I didn't expect anybody to really have
that small
On Tue, Nov 03 2015, James Bottomley
wrote:
> On Tue, 2015-11-03 at 23:13 +0100, Rasmus Villemoes wrote:
>> On Tue, Nov 03 2015, James Bottomley
>> wrote:
>>
>> > From: James Bottomley
>> >
>> > It was noticed that we lose precision in the final calculation for some
>> > inputs. The most eg
On Tue, Nov 3, 2015 at 3:21 PM, Dirk Steinmetz
wrote:
> On Tue, 3 Nov 2015 10:20:38 -0800, Kees Cook wrote:
>> On Mon, Nov 2, 2015 at 4:39 PM, Dirk Steinmetz
>> wrote:
>> > In order to hardlink to a sgid-executable, it is sufficient to be the
>> > file's owner. When hardlinking within an unprivil
At Tue, 3 Nov 2015 22:20:35 +0200,
Octavian Purdila wrote:
>
> This patch introduces the host operations that define the interface
> between the LKL and the host. These operations must be provided either
> by a host library or by the application itself.
(snip)
> +struct lkl_host_operations {
> +
On Tue, Nov 03, 2015 at 05:11:56PM -0600, Michael Welling wrote:
> On Tue, Nov 03, 2015 at 02:59:13PM -0800, Dmitry Torokhov wrote:
> > On Tue, Nov 03, 2015 at 09:41:17AM -0600, Michael Welling wrote:
> > > On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> > > > On Tue, Nov 3, 2015 at
On Tue, 3 Nov 2015, Catalin Marinas wrote:
> (cc'ing Jonsoo and Christoph; summary: slab failure with L1_CACHE_BYTES
> of 128 and sizeof(kmem_cache_node) of 152)
Hmmm... Yes that would mean use the 196 sized kmalloc array which is not a
power of two slab. But the code looks fine to me.
> If I re
Reviewed-by: Kees Cook
Signed-off-by: Andy Lutomirski
---
Changes from v2: Add a note about arg3 == 0 in CLEAR_ALL.
man2/prctl.2| 13 +
man7/capabilities.7 | 40 ++--
2 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/man2/prc
On Wed, 2015-11-04 at 00:26 +0100, Rasmus Villemoes wrote:
> On Tue, Nov 03 2015, James Bottomley
> wrote:
>
> > On Tue, 2015-11-03 at 23:13 +0100, Rasmus Villemoes wrote:
> >> On Tue, Nov 03 2015, James Bottomley
> >> wrote:
> >>
> >> > From: James Bottomley
> >> >
> >> > It was noticed tha
On Tue, Nov 3, 2015 at 1:48 PM, Laura Abbott wrote:
>
> Hi,
>
> Based on a recent discussion[1] there is interest in having set_memory_* work
> on kernel memory for security and other use cases. This patch adds the
> ability for that to happen behind a kernel option. If this is welcome enough,
> t
On Tue, Nov 03, 2015 at 11:33:11AM -0800, Petri Gynther wrote:
> On Tue, Nov 3, 2015 at 6:56 AM, Arnd Bergmann wrote:
> > The input_configured callback was recently changed to return
> > an 'int', but the newly added driver uses the old API:
> >
> > drivers/hid/hid-gfrm.c:151:22: warning: initiali
On Tue, Nov 3, 2015 at 1:23 AM, Mark Brown wrote:
> Since we need to read voltages of parents as part of setting supply
> voltages we need to be able to do get_voltage() internally without
> taking locks so reorganize the locking to take locks on the full tree on
> entry rather than as we recurse
On Nov 3, 2015, at 3:43 PM, Guy Harris wrote:
> To which particular PA-RISC processor are you referring? It might not be the
> same on all processors.
Chapter 3 "Addressing and Access Control" of PA-RISC 2.0 Architecture:
http://h21007.www2.hp.com/portal/download/files/unprot/parisc
On 2015-11-03, at 6:43 PM, Guy Harris wrote:
>
> On Nov 3, 2015, at 3:03 PM, Helge Deller wrote:
>
>> Sadly it's nowhere clearly documented how big the L1 cacheline of parisc
>> really is.
>
> To which particular PA-RISC processor are you referring? It might not be the
> same on all process
On 2015-11-03, at 6:25 PM, Linus Torvalds wrote:
> But if it's actually possible that the pa-risc L1 line size is really
> just 16 bytes, I guess that objection to the patch goes away. My
> automatic reaction was "that's not real, it's some odd workaround",
> but if it is actually real...
See pag
On Tue, Nov 3, 2015 at 1:16 AM, Ingo Molnar wrote:
>
> - More gradual enhancements to atomic ops: new atomic*_read_ctrl() ops,
> synchronize atomic_{read,set}() ordering requirements between
> architectures,
> add atomic_long_t bitops. (Peter Zijlstra)
>From another thread: those new "
On Nov 3, 2015, at 3:03 PM, Helge Deller wrote:
> Sadly it's nowhere clearly documented how big the L1 cacheline of parisc
> really is.
To which particular PA-RISC processor are you referring? It might not be the
same on all processors.
If openpa.net is to be believed, then:
The 7100LC has
>Yeah. That is often the fastest way to fix all the checkpatch warnings.
>
>Checkpatch warnings are pretty mechanical. Just send like 100 patches
>at a time until everything is fixed. Don't overthink. Say your patch
>breaks the alignment then you have to fix that, but otherwise only fix
>one th
On Tue, Nov 3, 2015 at 3:54 PM, Linus Torvalds
wrote:
> On Tue, Nov 3, 2015 at 1:16 AM, Ingo Molnar wrote:
>>
>> - More gradual enhancements to atomic ops: new atomic*_read_ctrl() ops,
>> synchronize atomic_{read,set}() ordering requirements between
>> architectures,
>> add atomic_long
On Tue, 3 Nov 2015 10:10:03 -0800 Daniel Cashman wrote:
> ASLR currently only uses 8 bits to generate the random offset for the
> mmap base address on 32 bit architectures. This value was chosen to
> prevent a poorly chosen value from dividing the address space in such
> a way as to prevent larg
Hi Linus,
This is the core block pull request for 4.4. I've got a few more topic
branches this time around, some of them will layer on top of the
core+drivers changes and will come in a separate round. So not a huge
chunk of changes in this round. This pull request contains:
- Enable blk-mq page
Hello, Jeff.
Can you please verify whether the following patch fixes the issue?
Thanks.
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 84190f0..566a282 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -970,12 +970,21 @@ EXPORT_SYMBOL(add_timer);
*/
void add_timer_on
On 11/3/2015 5:10 AM, Andy Shevchenko wrote:
On Mon, Nov 2, 2015 at 8:07 AM, Sinan Kaya wrote:
This patch adds support for hidma engine. The driver
consists of two logical blocks. The DMA engine interface
and the low-level interface. The hardware only supports
memcpy/memset and this driver on
Hi Linus,
On top of the core block bits, here are the block driver changes for
4.4. This pull request contains:
- NVMe:
- Refactor and moving of code to prepare for proper target
support. From Christoph and Jay.
- 32-bit nvme warning fix from Arnd.
- Error init
Hi Linus,
First of the topic branches, these are on top of core+drivers. This
first one adds support for lightnvm, and adds support to NVMe as well.
This is pretty exciting, in that it enables new and interesting use
cases for compatible flash devices. There's a LWN writeup about an
earlier postin
Hi Linus,
Next topic branch is the integrity branch. This is the joint work of Dan
and Martin, cleaning up and improving the support for block data
integrity.
Please pull!
git://git.kernel.dk/linux-block.git for-4.4/integrity
Hi Linus,
Last topic branch for now, this is support at the block level for
persistent reservations. This branch adds support at the core, as well
as for sd and NVMe.
Please pull!
git://git.kernel.dk/linux-block.git for-4.4/reservations
--
>On Fri, Oct 23, 2015 at 03:59:14PM -0400, James Simmons wrote:
>> diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
>> b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
>> index 635a93c..d6d70d8 100644
>> --- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
>> +++ b/drivers/staging/lustre/lustre/
Move RX-related IRQ handling into a helper function.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 50 +-
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_
start_tx must start transmitting characters. Regardless of the state of
the circular buffer, always enable the transmitter hardware.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/
Ignore RX-related interrupts if RX is not enabled.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index 149868cc003c
When shutting down the UART, clear the interrupt status register.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index 5edd1efca015..738df6bb2646 10
Hi,
I recently found my system locking up under some conditions. I dug
through the code a bit and the result is this collections of various
changes. Some of it may not be required and has just been created out of
half-baked theories and re-reading the documentation. The actual failing
scenarios se
The startup function is supposed to initialize the UART for receiving.
Hence, don't enable the TX part. Also, protect HW accesses with the port
lock.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
Non-functional, formatting changes to ease reading the code.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index 00
Instead of disabling the IRQ, use the spin lock to serialize accesses to
the HW. This protects the driver from interference of non-IRQ callbacks
with each other and makes the driver more consistent in its
serialization method.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c
The RX path in the interrupt handler released a lock unnecessarily.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index b189e600d4ab..544ea13e2e93
Shutting down the UART port can happen while console operations are in
progress. Holding the port lock serializes these operations and avoids
the UART HW to be disabled in the middle of console prints.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 6 ++
1 file chang
On 11/03/2015 06:01 AM, Linus Walleij wrote:
On Mon, Nov 2, 2015 at 11:14 PM, Andrew Duggan wrote:
I have been continuing to work on the synaptics-rmi4 driver and was just
trying to figure out what the next step should be. I recently uploaded my
changes here https://github.com/aduggan/linux.
Release of iproute2 for Linux 4.3
Update to iproute2 utility to support new features in Linux 4.3.
There are the usual array of small fixes to output and formatting.
Phil Sutter has done a lot of work on manual pages and getting Redhat
patches merged.
Source:
http://www.kernel.org/pub/linux/uti
On 11/03/2015 05:42 PM, Dave Young wrote:
On 10/28/15 at 04:00pm, Lu Baolu wrote:
This patch series adds support for early printk through USB3 debug port.
USB3 debug port is described in xHCI specification as an optional extended
capability.
The first patch adds a file in debugfs, through whi
On Sun, Nov 01, 2015 at 07:30:30PM -0700, Azael Avalos wrote:
> Commit 23f8f4326a15 ("toshiba_acpi: Fix hotkeys registration on some
> toshiba models") fixed an issue on some laptops regarding hotkeys
> registration, however, if failed to address the initialization of the
> hotkey_event_type variab
On 11/3/2015 5:22 AM, Andy Shevchenko wrote:
On Mon, Nov 2, 2015 at 8:07 AM, Sinan Kaya wrote:
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design. The management
driver is executed i
Hi Igal,
[auto build test ERROR on net/master]
[also ERROR on: v4.3 next-20151103]
url:
https://github.com/0day-ci/linux/commits/igal-liberman-freescale-com/Freescale-DPAA-FMan/20151103-003323
base: https://github.com/0day-ci/linux
igal-liberman-freescale-com/Freescale-DPAA-FMan/20151103
Hi Brain,
On 11/03/2015 12:38 PM, Brian Norris wrote:
Hi Yakir,
On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.
Reviewed-by: Heiko Stuebner
Signed-off-by: Yakir Ya
Andrew Morton writes:
> On Tue, 3 Nov 2015 10:10:03 -0800 Daniel Cashman
> wrote:
>
>> ASLR currently only uses 8 bits to generate the random offset for the
>> mmap base address on 32 bit architectures. This value was chosen to
>> prevent a poorly chosen value from dividing the address space i
Hi Soren,
[auto build test WARNING on v4.3-rc7]
[also WARNING on: next-20151103]
url:
https://github.com/0day-ci/linux/commits/Soren-Brinkmann/tty-xuartps-Beautify-read-modify-writes/20151104-082546
base: https://github.com/0day-ci/linux
Soren-Brinkmann/tty-xuartps-Beautify-read-modify
On 11/04/2015 03:44 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:39PM +0800, Bob Liu wrote:
>> Preparatory patch for multiple hardware queues (rings). The number of
>> rings is unconditionally set to 1, larger number will be enabled in next
>> patch so as to make every single p
On 11/3/2015 7:42 AM, Arnd Bergmann wrote:
You have a distinct "compatible" string for qemu, right? It sounds like
this is not the same device if the dependencies are different, and
you could just have two ways to probe the same device.
No, it is the same dma channel object that gets probed by
On 11/04/2015 04:09 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:40PM +0800, Bob Liu wrote:
>> The per device io_lock became a coarser grained lock after multi-queues/rings
>> was introduced, this patch introduced a fine-grained ring_lock for each ring.
>
> s/was introduced/wa
On 11/04/2015 04:40 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:41PM +0800, Bob Liu wrote:
>> The number of hardware queues for xen/blkfront is set by parameter
>> 'max_queues'(default 4), while the max value xen/blkback supported is
>> notified
>> through xenstore("multi-que
Currently tracing_init_dentry() returns -ENODEV when debugfs is not
initialized, which causes tracefs not populated with tracing files and
directories, so we will get an empty directory even after we manually
mount tracefs.
We can make tracing_init_dentry() return NULL as long as tracefs
is initia
Hi Yakir,
On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
> On 11/03/2015 12:38 PM, Brian Norris wrote:
> >On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> >(FYI, I came across this by inspection when comparing Heiko's
> >'somewhat-stable' branch [1] with this series. The
Currently, the trace_options parameter is only applied in
tracer_alloc_buffers() when global_trace.current_trace is nop_trace,
so a tracer specific option will not be applied even when the specific
tracer is also enabled from kernel command line. For example, the
'func_stack_trace' option can't be
On Mon, Nov 02, 2015 at 09:22:40AM +0800, Boqun Feng wrote:
> > On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
> > > To summerize:
> > >
> > > patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
> > > powerpc patches for powerpc next, patch 2(unmodified) sent as t
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent overwrite
of the contents since MADV_FREE syscall is called for THP page.
This patch adds pmd_mkclean for THP page MADV_FREE support.
Signed-off-by: Minchan Kim
---
arch/arm/include/asm/pgtable-3level.h | 1 +
1 file changed, 1 inse
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent overwrite
of the contents since MADV_FREE syscall is called for THP page.
This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.
Signed-off-by: Minchan Kim
Signed-off-by: Andrew Morton
---
arch/x86/include/asm/pg
The MADV_FREE patchset changes page reclaim to simply free a clean
anonymous page with no dirty ptes, instead of swapping it out; but
KSM uses clean write-protected ptes to reference the stable ksm page.
So be sure to mark that page dirty, so it's never mistakenly discarded.
[hughd: adjusted comme
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent overwrite
of the contents since MADV_FREE syscall is called for THP page.
This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.
Signed-off-by: Minchan Kim
Signed-off-by: Andrew Morton
---
arch/powerpc/include/as
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent overwrite
of the contents since MADV_FREE syscall is called for THP page.
This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.
Signed-off-by: Minchan Kim
Signed-off-by: Andrew Morton
---
arch/sparc/include/asm/
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent overwrite
of the contents since MADV_FREE syscall is called for THP page.
This patch adds pmd_mkclean for THP page MADV_FREE support.
Signed-off-by: Minchan Kim
---
arch/arm64/include/asm/pgtable.h | 1 +
1 file changed, 1 insertion
We don't need to split THP page when MADV_FREE syscall is called.
It could be done when VM decide to free it in reclaim path when
memory pressure is heavy so we could avoid unnecessary THP split.
For that, this patch changes two things
1. __split_huge_page_map
It does pte_mkdirty to subpages onl
When I test below piece of code with 12 processes(ie, 512M * 12 = 6G
consume) on my (3G ram + 12 cpu + 8G swap, the madvise_free is siginficat
slower (ie, 2x times) than madvise_dontneed.
loop = 5;
mmap(512M);
while (loop--) {
memset(512M);
madvise(MADV_FREE or MADV_DONTNEED);
}
T
On Tue, 03 Nov 2015 18:40:31 -0600 ebied...@xmission.com (Eric W. Biederman)
wrote:
> Andrew Morton writes:
>
> > On Tue, 3 Nov 2015 10:10:03 -0800 Daniel Cashman
> > wrote:
> >
> >> ASLR currently only uses 8 bits to generate the random offset for the
> >> mmap base address on 32 bit archit
On Tue, Nov 03, 2015 at 10:33:01AM +0100, Patrick Boettcher wrote:
> Hi all,
>
> Sorry for posting out-of-thread, but I don't have the original mail and
> thus cannot reply.
>
> If refer to this thread:
>
> https://lkml.org/lkml/2014/7/15/975
>
> where you guys started to review and prepare thi
Most architectures use asm-generic, but alpha, mips, parisc, xtensa
need their own definitions.
This patch defines MADV_FREE for them so it should fix build break
for their architectures.
Maybe, I should split and feed piecies to arch maintainers but
included here for mmotm convenience.
Cc: Mich
MADV_FREE is on linux-next so long time. The reason was two, I think.
1. MADV_FREE code on reclaim path was really mess.
2. Andrew really want to see voice of userland people who want to use
the syscall.
A few month ago, Daniel Micay(jemalloc active contributor) requested me
to make progress
Basically, MADV_FREE relies on dirty bit in page table entry to decide
whether VM allows to discard the page or not. IOW, if page table entry
includes marked dirty bit, VM shouldn't discard the page.
However, as a example, if swap-in by read fault happens, page table entry
doesn't have dirty bit
701 - 800 of 906 matches
Mail list logo
