On 7/10/23 15:32, Mina Almasry wrote:
* TL;DR:
Device memory TCP (devmem TCP) is a proposal for transferring data to and/or
from device memory efficiently, without bouncing the data to a host memory
buffer.
(I'm writing this as someone who might plausibly use this mechanism, but
I don't think
On 7/10/23 15:32, Mina Almasry wrote:
Add an interface for the user to notify the kernel that it is done reading
the NET_RX dmabuf pages returned as cmsg. The kernel will drop the
reference on the NET_RX pages to make them available for re-use.
Signed-off-by: Mina Almasry
---
+
6/xen/setup.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 ++--
include/asm-generic/fixmap.h | 2 +-
6 files changed, 6 insertions(+), 13 deletions(-)
Acked-by: Andy Lutomirski
> On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware)
> wrote:
>
>> On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
>>> On 9/3/19 11:46 PM, Andy Lutomirski wrote:
>>> On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
>>> wrote:
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
>
> On 9/3/19 10:51 PM, Dave Hansen wrote:
> > On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> >> So the question here should really be, can we determine already at mmap
> >> time whether backing memory will be unencrypted and a
On Tue, Sep 3, 2019 at 1:46 PM Thomas Hellström (VMware)
wrote:
>
> On 9/3/19 6:22 PM, Christoph Hellwig wrote:
> > On Tue, Sep 03, 2019 at 04:32:45PM +0200, Thomas Hellström (VMware) wrote:
> >> Is this a layer violation concern, that is, would you be ok with a similar
> >> helper for TTM, or is
ed with PSR and sorry for not replying sooner.
>>>>
>>>> I first saw this patch on that bugzilla entry but only now I stop to
>>>> really think why I have written the code that way.
>>>>
>>>> So some clarity below.
>>>>
ch on that bugzilla entry but only now I stop to
>> really think why I have written the code that way.
>>
>> So some clarity below.
>>
>>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>>> The current PSR code has a two call sites that eac
> On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi wrote:
>
>> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
>>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
>>>> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
>>>>&
ded. This adds
a new function intel_psr_schedule(), which will enable PSR after
the requested time but no sooner.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +++--
drivers/gpu/drm/i915/i915_drv.h | 4 ++-
drivers/gpu/drm/i915/inte
On Mon, Feb 5, 2018 at 9:17 PM, Pandiyan, Dhinakaran
wrote:
>
> On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote:
>> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>> wrote:
>> >
>> >
>> >
>> > On Sun, 2018-02-04 at 21:50 +,
On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
wrote:
>
>
>
> On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
>> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote:
>> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
>> > wrote:
>
On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote:
> On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> wrote:
>>
>> On Fri, 2018-02-02 at 19:18 +0000, Andy Lutomirski wrote:
>>> I updated to 4.15, and the situation is much worse. With
>>> enable_ps
On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
>> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson
>> wrote:
>>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>>>> I got this after a recent suspe
On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
wrote:
>
> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
>> I updated to 4.15, and the situation is much worse. With
>> enable_psr=1, the system survives for several seconds and then the
>> screen stops
On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
>> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson
>> wrote:
>>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>>>> I got this after a recent suspe
On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson wrote:
>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>>> I got this after a recent suspend/resume:
>>>
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Li
On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>> I got this after a recent suspend/resume:
>>
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enume
On Thu, Feb 1, 2018 at 9:53 AM, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-01 17:40:22)
>> *However*, I do see one unfortunate side effect of turning on PSR. It
>> seems that, when I move my cursor a little bit after a few seconds of
>> doing nothing, there see
On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski wrote:
> Hi-
>
> As requested in your blog post, I tested PSR. I see something like
> 2.69W with PSR off and 2.17W with PSR on. Screen blanking,
> suspend/resume, and the contents of the screen all seem okay. This is
> a Del
Hi-
As requested in your blog post, I tested PSR. I see something like
2.69W with PSR off and 2.17W with PSR on. Screen blanking,
suspend/resume, and the contents of the screen all seem okay. This is
a Dell XPS 13 9350, i.e.:
System Information
Manufacturer: Dell Inc.
Product N
My Dell XPS 13 9350 laptop just got a buffer underrun:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A
FIFO underrun
I'm seeing this very occasionally, and they don't come in groups -- I
seem to get one underrun with a black flash and that's it. This is
with just the laptop s
On Sun, Jun 26, 2016 at 10:59 AM, Ilia Mirkin wrote:
> On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski
> wrote:
>> On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote:
>>> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin
>>> wrote:
>>>> On Sun
On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote:
> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin wrote:
>> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote:
>>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin
>>> wrote:
>>>> Do you have mes
I have a Dell XPS 13 9350 (Skylake) and a Dell DA200 adapter. The
latter is a Thunderbolt device that includes an HDMI port and connects
over USB Type C. I believe that it's internally using DP Alternate
Mode.
When I plug it in on 4.7-rc4, I get spew like this:
[ 90.718106] [drm:intel_dp_star
On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin wrote:
> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote:
>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin wrote:
>>> Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2.
>>>
>>
>>
play output in general is unreliable enough that I'm having
trouble telling whether the performance is remotely reasonable.
--Andy
> Cheers,
>
> -ilia
>
> On Sat, May 28, 2016 at 4:51 PM, Andy Lutomirski wrote:
>> I have the signed firmware (I think) and I'm runn
I have the signed firmware (I think) and I'm running a fresh 4.6
kernel. I got an image to show up briefly, rendering the Fedora
sign-in screen at something like one frame per ten seconds. But then
I got all kinds of garbage, and I see:
[ 719.300820] nouveau :09:00.0: disp: outp 04:0006:0f4
On Tue, Mar 29, 2016 at 12:49 AM, Andy Lutomirski
wrote:
> On Tue, Mar 29, 2016 at 12:43 AM, Daniel Vetter
> wrote:
>> On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski
>> wrote:
>>> AFAICT something got rather screwed up in i915 land for 4.5.
>>>
>
On Tue, Mar 29, 2016 at 12:43 AM, Daniel Vetter
wrote:
> On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski
> wrote:
>> AFAICT something got rather screwed up in i915 land for 4.5.
>>
>> $ git log --oneline --grep='Pretend cursor is always on' v4.5
>> d
Hi all-
AFAICT something got rather screwed up in i915 land for 4.5.
$ git log --oneline --grep='Pretend cursor is always on' v4.5
drivers/gpu/drm/i915/
e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
calculations (v2)
$ git log --oneline --grep='Pretend cursor is always on'
On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter wrote:
> On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
>> On Tue, Feb 16, 2016 at 9:12 AM, Andy Lutomirski
>> wrote:
>> > On Tue, Feb 16, 2016 at 8:12 AM, Daniel Vetter wrote:
>> >> On Mon, Fe
On Mon, Feb 22, 2016 at 7:13 PM, Andy Lutomirski wrote:
> On Wed, Feb 17, 2016 at 5:36 PM, Andy Lutomirski
> wrote:
>> On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter wrote:
>>> On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
>>>> On T
On Fri, Mar 11, 2016 at 3:29 PM, Bjorn Helgaas wrote:
> On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
>> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
>> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
>> >> Th
On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
> On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
>> The purpose of this series is to:
>>
>> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
>> messages reported by Linus [1], Andy [2], and others.
>>
>>
On Sun, Jan 10, 2016 at 11:12 AM, Andy Lutomirski
wrote:
> On Sun, Jan 10, 2016 at 10:41 AM, Andy Lutomirski
> wrote:
>> On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone
>> wrote:
>>> Hi,
>>>
>>> On 18 November 2015 at 15:59, Andy Lutomirski
&g
On Tue, Jan 12, 2016 at 6:06 PM, Linus Torvalds
wrote:
> On Tue, Jan 12, 2016 at 4:55 PM, Chris Wilson
> wrote:
>>
>> The double clflush() remains a mystery.
>
> Actually, I think it's explainable.
>
> It's wrong to do the clflush *after* the GPU has done the write, which
> seems to be what you
On Sun, Jan 10, 2016 at 10:41 AM, Andy Lutomirski
wrote:
> On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone wrote:
>> Hi,
>>
>> On 18 November 2015 at 15:59, Andy Lutomirski wrote:
>>> On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä
>>> wrote:
>>>
On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone wrote:
> Hi,
>
> On 18 November 2015 at 15:59, Andy Lutomirski wrote:
>> On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä
>> wrote:
>>> On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
>>>
lt?
No clue, but I don't know much about the underlying architecture.
Can you try clflush_cache_ranging one cacheline less and then manually
doing clflushopt; mb on the last cache line, just to make sure that
the helper is really doing the right thing? You could also try
clflush instead of clflushopt to see if that makes a difference.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
On Thu, Jan 7, 2016 at 2:16 AM, Chris Wilson
wrote:
> On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote:
>> During testing we observed that the last cacheline was not being flushed
>> from a
>>
>> mb()
>> for (addr = addr & -clflush_size; addr < end; addr += clflush_size)
>
[53834.386369] traps: gnome-session-b[2308] general protection
ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
libc-2.22.so[7f10efba1000+1b7000]
[53834.687584] [ cut here ]
[53834.687607] WARNING: CPU: 0 PID: 23730 at
drivers/gpu/drm/i915/i915_gem_context.c:144
i915_gem_context_f
[adding linux-pci]
On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä
wrote:
> On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
>> Typing:
>>
>> # cat /sys/devices/pci:00/:00:02.0/rom
>>
>> Provokes:
>>
>> i915 :00:02.0: In
Typing:
# cat /sys/devices/pci:00/:00:02.0/rom
Provokes:
i915 :00:02.0: Invalid ROM contents
This is on a Dell XPS 13 9350 (Skylake). This is 4.3.0 plus some
wireless-next bits.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
I just started getting X failures that say:
[ 739.208] (EE) RADEON(0): [drm] failed to set drm interface version.
I'm not sure what triggered it.
dmesg says:
[ 740.156499] [drm:drm_stub_open]
[ 740.156502] [drm:drm_open_helper] pid = 2170, minor = 0
[ 740.156541] [drm:drm_ioctl] pid=2170,
On Wed, Dec 10, 2014 at 8:24 PM, Michel Dänzer wrote:
> On 11.12.2014 05:28, Andy Lutomirski wrote:
>> On Wed, Dec 10, 2014 at 1:44 AM, Michel Dänzer
>> wrote:
>>> On 10.12.2014 06:39, Andy Lutomirski wrote:
>>>> On Tue, Dec 9, 2014 at 8:06 AM, Andy Lutomi
On Wed, Dec 10, 2014 at 1:44 AM, Michel Dänzer wrote:
> On 10.12.2014 06:39, Andy Lutomirski wrote:
>> On Tue, Dec 9, 2014 at 8:06 AM, Andy Lutomirski
>> wrote:
>>> On Tue, Dec 9, 2014 at 1:18 AM, Michel Dänzer
>>> wrote:
>>>> On 09.12.2014
On Tue, Dec 9, 2014 at 8:06 AM, Andy Lutomirski wrote:
> On Tue, Dec 9, 2014 at 1:18 AM, Michel Dänzer wrote:
>> On 09.12.2014 09:24, Andy Lutomirski wrote:
>>>
>>> The relevant line from latencytop seems to be:
>>>
>>> 154 2044
On Tue, Dec 9, 2014 at 1:18 AM, Michel Dänzer wrote:
> On 09.12.2014 09:24, Andy Lutomirski wrote:
>>
>> The relevant line from latencytop seems to be:
>>
>> 154 20441402 489139 radeon_fence_default_wait [radeon]
>> fence_wait_timeout ttm_bo_wait [tt
On Wed, Nov 26, 2014 at 7:38 AM, Andy Lutomirski wrote:
> On Tue, Nov 25, 2014 at 10:42 PM, Michel Dänzer
> wrote:
>> On 20.11.2014 09:58, Andy Lutomirski wrote:
>>>
>>> On Wed, Nov 19, 2014 at 4:07 PM, Andy Lutomirski
>>> wrote:
>>>>
&g
On Tue, Nov 25, 2014 at 10:42 PM, Michel Dänzer wrote:
> On 20.11.2014 09:58, Andy Lutomirski wrote:
>>
>> On Wed, Nov 19, 2014 at 4:07 PM, Andy Lutomirski
>> wrote:
>>>
>>> On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer
>>> wrote:
>
On Wed, Nov 19, 2014 at 4:07 PM, Andy Lutomirski wrote:
> On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer
> wrote:
>> On 19.11.2014 09:21, Andy Lutomirski wrote:
>>>
>>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer
>>> wrote:
>>>&
On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer wrote:
> On 19.11.2014 09:21, Andy Lutomirski wrote:
>>
>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer
>> wrote:
>>>
>>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>>
>>>>
On Tue, Nov 18, 2014 at 4:34 PM, Andy Lutomirski wrote:
> On Tue, Nov 18, 2014 at 4:21 PM, Andy Lutomirski
> wrote:
>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer
>> wrote:
>>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>>
>>>> I hav
On Tue, Nov 18, 2014 at 4:21 PM, Andy Lutomirski wrote:
> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer wrote:
>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>
>>> I have a Caicos card, like this:
>>>
>>> [3.077260] [drm] radeon kernel mod
On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer wrote:
> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>
>> I have a Caicos card, like this:
>>
>> [3.077260] [drm] radeon kernel modesetting enabled.
>> [3.077338] checking generic (e000 60
I have a Caicos card, like this:
[3.077260] [drm] radeon kernel modesetting enabled.
[3.077338] checking generic (e000 60) vs hw (e000 1000)
[3.077339] fb: switching to radeondrmfb from EFI VGA
[3.077377] Console: switching to colour dummy device 80x25
[3.078881
On Fri, Nov 14, 2014 at 1:07 PM, Ross Zwisler
wrote:
> On Wed, 2014-11-12 at 19:25 -0800, Andy Lutomirski wrote:
>> On 11/11/2014 10:43 AM, Ross Zwisler wrote:
>> > Add support for the new pcommit instruction. This instruction was
>> > announced in the document &quo
On Nov 13, 2014 3:20 AM, "Borislav Petkov" wrote:
>
> On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote:
> > On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> > > If clwb is available on the system, use it in drm_clflush_virt_range.
> > >
On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> Add support for the new pcommit instruction. This instruction was
> announced in the document "Intel Architecture Instruction Set Extensions
> Programming Reference" with reference number 319433-022.
>
> https://software.intel.com/sites/default/files/
On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> If clwb is available on the system, use it in drm_clflush_virt_range.
> If clwb is not available, fall back to clflushopt if you can.
> If clflushopt is not supported, fall all the way back to clflush.
I don't know exactly what drm_clflush_virt_range (
On Tue, Sep 16, 2014 at 9:45 AM, Bjorn Helgaas wrote:
> On Thu, Mar 27, 2014 at 11:30:37AM -0600, Bjorn Helgaas wrote:
>> On Mon, Mar 24, 2014 at 4:04 PM, Bjorn Helgaas
>> wrote:
>> > On Sat, Mar 22, 2014 at 9:18 AM, Andy Lutomirski
>> > wrote:
>> &g
On Jun 17, 2014 2:48 AM, "Florian Weimer" wrote:
>
> On 04/10/2014 10:37 PM, Andy Lutomirski wrote:
>
>> It occurs to me that, before going nuts with these kinds of flags, it
>> may pay to just try to fix the /proc/self/fd issue for real -- we
>> could jus
On Fri, Apr 11, 2014 at 2:42 PM, David Herrmann
wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski
> wrote:
>> A quick grep of the kernel tree finds exactly zero code paths
>> incrementing i_mmap_writable outside of mmap and fork.
>>
>> Or d
On 04/11/2014 02:31 PM, David Herrmann wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby
> wrote:
>> Exactly. For O_DIRECT, that would be the call to get_user_pages_fast()
>> from dio_refill_pages() in fs/direct-io.c, which is ultimately called
>> from blkdev_direct_IO().
>
> If
On 04/10/2014 05:22 PM, David Herrmann wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby
> wrote:
>> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
>> incrementing the page reference counts when the I/O is submitted,
>> allowing the pages to be modified by D
On Thu, Apr 10, 2014 at 4:16 PM, David Herrmann
wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski
> wrote:
>> /proc/pid/fd is a really weird corner case in which the mode of an
>> inode that doesn't have a name matters. I suspect that almost no one
On Thu, Apr 10, 2014 at 3:57 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:16 PM, Andy Lutomirski
> wrote:
>> Would it make sense for the initial mode on a memfd inode to be 000?
>> Anyone who finds this to be problematic could use fchmod to fix it.
>
On Thu, Apr 10, 2014 at 1:49 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski
> wrote:
>> It occurs to me that, before going nuts with these kinds of flags, it
>> may pay to just try to fix the /proc/self/fd issue for real -- we
On Thu, Apr 10, 2014 at 1:32 PM, Theodore Ts'o wrote:
> On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>>
>> This is the second time in a week that someone has asked for a way to
>> have a struct file (or struct inode or whatever) that can't be r
On 04/08/2014 06:00 AM, Florian Weimer wrote:
> On 03/19/2014 08:06 PM, David Herrmann wrote:
>
>> Unlike existing techniques that provide similar protection, sealing
>> allows
>> file-sharing without any trust-relationship. This is enforced by
>> rejecting seal
>> modifications if you don't own a
On 04/10/2014 07:45 AM, Colin Walters wrote:
> On Thu, Mar 20, 2014 at 11:32 AM, tytso at mit.edu wrote:
>>
>> Looking at your patches, and what files you are modifying, you are
>> enforcing this in the low-level file system.
>
> I would love for this to be implemented in the filesystem level as
>
On 03/20/2014 09:38 AM, tytso at mit.edu wrote:
> On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote:
>> On Thu, Mar 20, 2014 at 4:32 PM, wrote:
>>> Why not make sealing an attribute of the "struct file", and enforce it
>>> at the VFS layer? That way all file system objects would hav
On 04/02/2014 06:38 AM, Konstantin Khlebnikov wrote:
> On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann
> wrote:
>> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
>> that you can pass to mmap(). It explicitly allows sealing and
>> avoids any connection to user-visible
On Tue, Apr 1, 2014 at 3:09 PM, Andy Lutomirski wrote:
> Running:
>
> ./virtme-run --installed-kernel
>
> from this virtme commit:
>
> https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/commit/?id=2b409a086d15b7a878c7d5204b1f44a6564a341f
>
> results in a bun
On Fri, Mar 21, 2014 at 9:37 AM, Bjorn Helgaas wrote:
> On Fri, Mar 21, 2014 at 9:49 AM, Andy Lutomirski
> wrote:
>> On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher
>> wrote:
>>> On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski
>>> wrote:
>>>&
On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher wrote:
> On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski
> wrote:
>> My system works on a 3.13 Fedora kernel. It does not work on a
>> more-or-less identically configured 3.14-rc7+ kernel. The symptom is
>> that the
My system works on a 3.13 Fedora kernel. It does not work on a
more-or-less identically configured 3.14-rc7+ kernel. The symptom is
that the Plymouth password prompt flashes and them the screen goes
blank. Hitting escape brings back the text console, and all is well
until X tries to start. Then
On Fri, Aug 9, 2013 at 11:47 AM, Daniel Vetter wrote:
> On Fri, Aug 9, 2013 at 8:39 PM, Andy Lutomirski wrote:
>> On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter
>> wrote:
>>> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski wrote:
>>>> On Thu, Aug 8, 2013 at
On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter wrote:
> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski wrote:
>> On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter wrote:
>>> The new arch_phys_wc_add/del functions do the right thing both with
>>> and without MTRR suppo
On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter wrote:
> The new arch_phys_wc_add/del functions do the right thing both with
> and without MTRR support in the kernel. So we can drop these
> additional checks.
If any of the new arch_phys_wc_add calls are reachable and if the
driver calls arch_phys_w
On Fri, Aug 9, 2013 at 11:47 AM, Daniel Vetter
wrote:
> On Fri, Aug 9, 2013 at 8:39 PM, Andy Lutomirski
> wrote:
>> On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter
>> wrote:
>>> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski
>>> wrote:
>>>&g
On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter
wrote:
> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski
> wrote:
>> On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter
>> wrote:
>>> The new arch_phys_wc_add/del functions do the right thing both with
>>> and wi
On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter wrote:
> The new arch_phys_wc_add/del functions do the right thing both with
> and without MTRR support in the kernel. So we can drop these
> additional checks.
If any of the new arch_phys_wc_add calls are reachable and if the
driver calls arch_phys_w
On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
wrote:
> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
> MTRR code" contains the following change:
>
> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
> }
> }
>
> +if (mtrr != 3 && mtrr != 1)
> +
On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
wrote:
> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
> MTRR code" contains the following change:
>
> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
> }
> }
>
> +if (mtrr != 3 && mtrr != 1)
> +
On Wed, Jul 10, 2013 at 8:59 AM, Daniel Vetter wrote:
> On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann wrote:
>> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter
>> wrote:
>>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
>>> wrote:
> -#if __OS_HAS_MTRR
> -static inline int drm_core_
On Wed, Jul 10, 2013 at 8:59 AM, Daniel Vetter
wrote:
> On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann
> wrote:
>> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter
>> wrote:
>>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
>>> wrote:
> -#if __OS_HAS_MTRR
> -static inline int drm_c
On 06/24/2013 03:27 PM, David Herrmann wrote:
> + sdrm->fb_map = ioremap(sdrm->fb_base, sdrm->fb_size);
This should probably be ioremap_wc. Otherwise it will be *really* slow
if used in legacy mode and it may cause conflicts with the
pgprot_writecombine mode for mmap.
(Watching boot messages
sion report that you broke old boxes.
>>
>
> Not "just because", but *if* the choice is between breaking old boxes
> and breaking new boxes I'll take the latter.
>
>> Andy Lutomirski just submitted a bunch of patches to clean up the DRM
>> us
On 06/24/2013 03:27 PM, David Herrmann wrote:
> + sdrm->fb_map = ioremap(sdrm->fb_base, sdrm->fb_size);
This should probably be ioremap_wc. Otherwise it will be *really* slow
if used in legacy mode and it may cause conflicts with the
pgprot_writecombine mode for mmap.
(Watching boot messages
sion report that you broke old boxes.
>>
>
> Not "just because", but *if* the choice is between breaking old boxes
> and breaking new boxes I'll take the latter.
>
>> Andy Lutomirski just submitted a bunch of patches to clean up the DRM
>> us
On Thu, Jun 13, 2013 at 2:22 PM, Andy Lutomirski wrote:
> On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse wrote:
>> Andy can you test (without your patch) and see if it helps with your issue :
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-update-lockup-tracking-when-sche
On Thu, Jun 13, 2013 at 2:22 PM, Andy Lutomirski wrote:
> On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse wrote:
>> Andy can you test (without your patch) and see if it helps with your issue :
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-update-lockup-tracking-when-sche
On 06/16/2013 07:57 AM, Daniel Vetter wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things (like the radeon
> re
On 06/16/2013 07:57 AM, Daniel Vetter wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things (like the radeon
> re
On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse wrote:
> On Wed, Jun 12, 2013 at 6:26 AM, Michel Dänzer wrote:
>> On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
>>> If the device is idle for over ten seconds, then the next attempt to do
>>> anything can ra
On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse wrote:
> On Wed, Jun 12, 2013 at 6:26 AM, Michel D?nzer wrote:
>> On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
>>> If the device is idle for over ten seconds, then the next attempt to do
>>> anything can ra
(and corrects
some typos in the description).
My system has been stable for about a week running this code. Without this,
my screen would go blank every now and then and, when it came back, everything
would be remarkably slow (the latter is a separate bug).
Signed-off-by: Andy Lutomirski
---
Thi
(and corrects
some typos in the description).
My system has been stable for about a week running this code. Without this,
my screen would go blank every now and then and, when it came back, everything
would be remarkably slow (the latter is a separate bug).
Signed-off-by: Andy Lutomirski
---
Thi
1 - 100 of 226 matches
Mail list logo
