On Thursday 01 November 2012 13:52:42 Martin Steigerwald wrote:
...
> The following two main issues led to the discussion about adding
> notification about user inotify watch limit or even having it raised
> automatically via some policy kit mechanism:
>
> 1) Watches are not working recursively. T
Hi,
On 21/10/12 21:03, Tvrtko Ursulin wrote:
On 21/10/12 20:29, Milan Broz wrote:
On 10/21/2012 02:36 PM, Tvrtko Ursulin wrote:
On 21/10/12 13:20, Zdenek Kaspar wrote:
I would say you are still missing some modules.
Kernel says this:
device-mapper: table: 252:1: crypt: Error
On 29/10/12 19:47, Milan Broz wrote:
On 10/29/2012 08:31 PM, Tvrtko Ursulin wrote:
Just tried 3.6.4 and it is still broken. Is there anything else I could
try to debug this?
See response from response from Ondra on dmcrypt list - your kernel config
is perhaps broken.
I don't think
On 29/10/12 20:14, Tvrtko Ursulin wrote:
On 29/10/12 19:47, Milan Broz wrote:
On 10/29/2012 08:31 PM, Tvrtko Ursulin wrote:
Just tried 3.6.4 and it is still broken. Is there anything else I could
try to debug this?
See response from response from Ondra on dmcrypt list - your kernel
config
is
Hi,
On 30/10/12 15:27, Milan Broz wrote:
Fix crypto api for 3.6.4-rt10 (broken only in realtime patchset)
In peterz-srcu-crypto-chain.patch the blocking notifier is changed
to srcu notifier and added initialization to module init fucntion.
Later, in crypto-make-core-static-and-init-scru-early
Hi,
I get a lot of those and was wondering if it is a generic fscache issues
or in some way related to the RT patchset. Perhaps that the two do not
play well together?
Traces typically look like this:
BUG: scheduling while atomic: kworker/u:2/4151/0x0002
Modules linked in: snd_usb_aud
Hi all,
I can't open my LUKS formatted crypto files in 3.6 any more while 3.4
works fine.
Error is:
# cryptsetup --key-file=- luksOpen /luks.file target
Enter passphrase:
device-mapper: reload ioctl on failed: No such file or directory
Failed to setup dm-crypt key mapping for device /dev/lo
Hi,
On 21/10/12 10:53, Milan Broz wrote:
On 10/20/2012 10:44 PM, Tvrtko Ursulin wrote:
But I repeat, even if I load the required modules before hand things do
not work.
I would say you are still missing some modules.
Kernel says this:
device-mapper: table: 252:1: crypt: Error
On 21/10/12 13:20, Zdenek Kaspar wrote:
I would say you are still missing some modules.
Kernel says this:
device-mapper: table: 252:1: crypt: Error allocating crypto tfm
device-mapper: ioctl: error adding target to table
It complains about aes-cbc-essiv:sha256.
It can be missing CBC
On Saturday 10 November 2012 17:53:45 Martin Steigerwald wrote:
> Still fanotify needs root access and thus this would need a daemon running
> as root and some policy kit stuff to access it and in case of mount point
> watches robust and secure code so that each user may only see his/her own
> resu
On Tuesday 13 November 2012 18:40:36 Cyrill Gorcunov wrote:
> On Tue, Nov 13, 2012 at 12:37:23PM +0000, Tvrtko Ursulin wrote:
> >> Which would give about 26K of additional memory if c/r get used here.
> >>
> >> Not a big number i guess?
> >
> > I am p
On Tuesday 13 November 2012 19:28:46 Cyrill Gorcunov wrote:
> On Tue, Nov 13, 2012 at 03:02:22PM +0000, Tvrtko Ursulin wrote:
> > Perhaps there could be a different way, where you could use additional
> > space only when it is actually used at runtime. But as I said, I am not
> &
On Wednesday 14 November 2012 13:38:49 Cyrill Gorcunov wrote:
> On Wed, Nov 14, 2012 at 09:20:51AM +0000, Tvrtko Ursulin wrote:
> > On Tuesday 13 November 2012 19:28:46 Cyrill Gorcunov wrote:
> > > On Tue, Nov 13, 2012 at 03:02:22PM +0000, Tvrtko Ursulin wrote:
> > >
On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
> On Wed, Nov 14, 2012 at 09:50:55AM +0000, Tvrtko Ursulin wrote:
> > > > You could not use a pointer and then allocate your buffers on the
> > > > check
> > > > point operation, freeing on r
On Wednesday 14 November 2012 14:13:41 Pavel Emelyanov wrote:
> On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
> > On Wednesday 14 November 2012 13:58:12 Cyrill Gorcunov wrote:
> >> On Wed, Nov 14, 2012 at 09:50:55AM +0000, Tvrtko Ursulin wrote:
> >>>>> You could
On Wednesday 14 November 2012 14:46:42 Pavel Emelyanov wrote:
> On 11/14/2012 02:38 PM, Tvrtko Ursulin wrote:
> > On Wednesday 14 November 2012 14:13:41 Pavel Emelyanov wrote:
> >> On 11/14/2012 02:08 PM, Tvrtko Ursulin wrote:
> >>> On Wednesday 14 November 2012
On Wednesday 14 November 2012 14:56:00 Pavel Emelyanov wrote:
> >>> How much space does a typical file system need to encode a handle? Am I
> >>> right that for must it is just a few bytes? (I just glanced at the code
> >>> so I might be wrong.) In which case, could the handle buffer be
> >>> alloc
Hi all,
On Thursday 11 April 2013 22:57:08 Theodore Ts'o wrote:
> That's an interesting theory. If the workload is one which is very
> heavy on reads and writes, that could explain the high latency. That
> would explain why those of us who are using primarily SSD's are seeing
> the problems, be
Hi Al, all,
Please have a look at the command sequence below, does it look right to you?
+ M1=testmp1
+ M2=testmp2
+ SM=submount
+ mkdir -p testmp1
+ mkdir -p testmp2
+ mount none -t tmpfs testmp1
+ mkdir -p testmp1/submount
+ mount none -t tmpfs testmp1/submount
+ strace -f -e trace=mount,umoun
Hi,
On Thursday 28 March 2013 11:03:51 Ram Pai wrote:
> I tried these commands on a 3.8.0-rc1+ kernel and did not find the
> problem. Is this on a recent kernel?
I am on Fedora 17 latest, but I've seen this problem with different kernels.
Pretty sure from 3.5 something to 3.8 something. All Fed
On Thursday 28 March 2013 13:05:56 Tvrtko Ursulin wrote:
> Hi,
>
> On Thursday 28 March 2013 11:03:51 Ram Pai wrote:
> > I tried these commands on a 3.8.0-rc1+ kernel and did not find the
> > problem. Is this on a recent kernel?
>
> I am on Fedora 17 latest, but
On Thursday 28 March 2013 23:35:49 Ram Pai wrote:
> On Thu, Mar 28, 2013 at 01:05:56PM +0000, Tvrtko Ursulin wrote:
> > Hi,
> >
> > On Thursday 28 March 2013 11:03:51 Ram Pai wrote:
> > > I tried these commands on a 3.8.0-rc1+ kernel and did not find the
> > &
Hi,
On Thursday 12 Jul 2012 18:46:34 Jörn Engel wrote:
> Console driver similar to netconsole, except it writes to a block
> device. Can be useful in a setup where netconsole, for whatever
> reasons, is impractical.
Perhaps you need to add a word or two about limitations compared to netconsole
On Monday 23 Jul 2012 21:02:30 Jörn Engel wrote:
> On Mon, 23 July 2012 15:33:16 +0100, Tvrtko Ursulin wrote:
> > On Thursday 12 Jul 2012 18:46:34 Jörn Engel wrote:
> > > Console driver similar to netconsole, except it writes to a block
> > > device. Can be useful in a
On Tuesday 24 Jul 2012 15:38:22 Jörn Engel wrote:
> On Tue, 24 July 2012 09:01:16 +0100, Tvrtko Ursulin wrote:
> > On Monday 23 Jul 2012 21:02:30 Jörn Engel wrote:
> > > On Mon, 23 July 2012 15:33:16 +0100, Tvrtko Ursulin wrote:
> > > > On Thursday 12 Jul 2012 18:46:3
On 21/04/2005 12:13:46 linux-kernel-owner wrote:
>Without this patch, Linux provokes emergency disk shutdowns and
>similar nastiness. It was in SuSE kernels for some time, IIRC.
OMG! And I did try to raise that issue 10 months ago, see below:
http://www.ussg.iu.edu/hypermail/linux/kernel/0406.0/
On 21/04/2005 12:38:29 linux-kernel-owner wrote:
>> >Without this patch, Linux provokes emergency disk shutdowns and
>> >similar nastiness. It was in SuSE kernels for some time, IIRC.
>> OMG! And I did try to raise that issue 10 months ago, see below:
>> http://www.ussg.iu.edu/hypermail/linux/kern
On 03/08/2005 17:03:04 linux-kernel-owner wrote:
>Is anyone maintaining the smb filesystem in the Linux kernel?
It probably won't help you much, but I had the same problem few months
ago. There was a bug in smbfs which I tried to discuss with someone, and
after failing to contact the maintainer
[EMAIL PROTECTED] wrote on 28/11/2007 17:39:56:
> On Wed, 28 Nov 2007 16:46:13 +
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Nov 28, 2007 at 08:38:43AM -0800, Casey Schaufler wrote:
> > > Would you like to expound on that, or do you feel your claws
> > > are sharp enough alre
Alan Cox <[EMAIL PROTECTED]> wrote on 28/11/2007 19:50:42:
> > So as there is no question the current code does some ugly things it
is
> > even more true that we would be even more happy to use an official
API.
> > LSM was that and we were happily using it which we won't be able to do
if
> >
Al Viro <[EMAIL PROTECTED]> wrote on 28/11/2007 18:30:40:
> On Wed, Nov 28, 2007 at 01:15:05PM -0500, [EMAIL PROTECTED] wrote:
> > (Note that the concept has interesting implications in the other
> direction as
> > well - rather than stopping you from reading a file that has
> malware, you could
[EMAIL PROTECTED] wrote on 28/11/2007 19:20:26:
> "Tvrtko A. Ursulin" <[EMAIL PROTECTED]> writes:
>
> > We here at Sophos (the fourth largest endpoint security vendor in
> the world)
> > have such a module called Talpa which is a part of our main
> endpoint security
> > product
>
> What is a
[EMAIL PROTECTED] wrote on 22/11/2007 16:28:22:
> [EMAIL PROTECTED] wrote on 22/11/2007 16:34:01:
>
> > On Thursday, 22 of November 2007, Tvrtko A. Ursulin wrote:
> > >
> > > Hi all,
> > >
> > > So as the subject says - pdflush is stuck i D state which means
> > constant load
> > > average of
[EMAIL PROTECTED] wrote on 22/11/2007 16:34:01:
> On Thursday, 22 of November 2007, Tvrtko A. Ursulin wrote:
> >
> > Hi all,
> >
> > So as the subject says - pdflush is stuck i D state which means
> constant load
> > average of at least one:
> >
> > root 151 0.0 0.0 0 0 ?
[Reposted due to incorrect LKML address, sorry reiserfs-devs]
Machine is a P4 with HT enabled. It was sitting around idle over the
weekend and below is what I found this morning. More machine info
available if needed of course.
Oops: [#1]
PREEMPT SMP
Modules linked in: usbserial nvram sn
[Reposted due to wrong LKML address, sorry Al]
Hi,
Looking at linux-2.6.11/fs/namespace.c line 418:
if (mnt == current->fs->rootmnt && !(flags & MNT_DETACH)) {
/*
* Special case for "unmounting" root ...
I wonder is this really a test for root? Couldn't the current->fs->rootmnt
"p
On 14/02/2005 20:39:02 linux-kernel-owner wrote:
>On my Thinkpad T30 with a Radeon Mobility M7 LW, I get interesting
>console video corruption if I start GDM, switch back to text mode,
>then stop it again. X is Xfree86 from Debian/unstable or X.org 6.8.2.
>
>The corruption shows up whenever the co
On 30/03/2005 10:45:55 linux-kernel-owner wrote:
>> The solution is fairly well known. Rather than treating the zillions
of
>> disk seeks during the boot process as random unconnected events, you
>
>Heh, we actually tried that at SuSE and yes, eliminating seeks helps a
>bit, but no, it is not ma
On 30/03/2005 12:50:01 linux-kernel-owner wrote:
>> I'd be interested in the answer as well. I have a driver which does
>> udelay(100), so no 1000 but anyway, and of course I end up having the
X86_64
>> kernel happily crying. I'm moving to a little state-machine to allow
for a
>> multi-pass appr
if (!attr)
goto err_alloc;
Luckily it is the same size so no actual bug, but fix is still valid.
Will merge it once it passes CI, thanks!
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Hi,
On 12/01/2018 17:36, Colin King wrote:
From: Colin Ian King
I believe the sizeof(attr) should be in fact sizeof(*attr), fortunately
the current code works because sizeof(struct attribute **) is the same
as sizeof(struct attribute *) for x86.
Thanks, kbuild also reported it and I just pu
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
of access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in sysfs.
These work in equivalent fashion as the existing perf_event_paranoid
sysctl, which now becomes the
Hi,
On 19/01/2018 16:45, Peter Zijlstra wrote:
On Thu, Jan 18, 2018 at 06:40:07PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
of access control for different PMUs, we start creating per-PMU
perf_event_paranoid
From: Tvrtko Ursulin
If a higher-order allocation fails, the existing abort and cleanup path
would consider all segments allocated so far as 0-order page allocations
and would therefore leak memory.
Fix this by cleaning up using sgl_free_n_order which allows the correct
page order to be passed
From: Tvrtko Ursulin
sg_init_table will clear the allocated block so requesting zeroed memory
from the allocator is redundant.
Signed-off-by: Tvrtko Ursulin
Cc: Bart Van Assche
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Jens Axboe
---
lib/scatterlist.c | 3 +--
1 file changed, 1
From: Tvrtko Ursulin
There are several issues in sgl_alloc_order and accompanying APIs:
1.
sgl_alloc_order explicitly takes a 64-bit length (unsigned long long) but
then rejects it in overflow checking if greater than 4GiB allocation was
requested. This is a consequence of using unsigned int
From: Tvrtko Ursulin
Save some kernel size by moving trivial wrappers to header as static
inline instead of exporting symbols for them.
Signed-off-by: Tvrtko Ursulin
Cc: Bart Van Assche
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Jens Axboe
---
include/linux/scatterlist.h | 38
From: Tvrtko Ursulin
We can derive the order from sg->length and so do not need to pass it in
explicitly. Rename the function to sgl_free_n.
Signed-off-by: Tvrtko Ursulin
Cc: Bart Van Assche
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Jens Axboe
Cc: "Nicholas A. Bellinger"
From: Tvrtko Ursulin
I spotted a few small issues in the recent added SGL code so am sending some
patches to tidy this.
My motivation was looking at sgl_alloc_order to potentially use from the i915
driver, with a small addition to support fall-back to smaller order allocation
if so was
From: Tvrtko Ursulin
No code calls it so remove it.
Signed-off-by: Tvrtko Ursulin
Cc: Bart Van Assche
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Jens Axboe
---
include/linux/scatterlist.h | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/include/linux
On 07/03/18 16:10, Bart Van Assche wrote:
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
sgl_alloc_order explicitly takes a 64-bit length (unsigned long long) but
then rejects it in overflow checking if greater than 4GiB allocation was
requested. This is a consequence of using
On 07/03/18 16:16, Bart Van Assche wrote:
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 9884be50a2c0..e13a759c5c49 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -493,7 +493,7 @@ struct scatterlist *sgl_alloc_order
On 07/03/18 16:19, Bart Van Assche wrote:
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
Save some kernel size by moving trivial wrappers to header as static
inline instead of exporting symbols for them.
Something that you may be unaware of is that the introduction of the sgl
On 07/03/18 16:23, Bart Van Assche wrote:
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
We can derive the order from sg->length and so do not need to pass it in
explicitly. Rename the function to sgl_free_n.
Using get_order() to compute the order looks fine to me but this pa
On 07/03/18 15:35, Andy Shevchenko wrote:
On Wed, Mar 7, 2018 at 2:47 PM, Tvrtko Ursulin wrote:
+ sgl = kmalloc_array(nent, sizeof(struct scatterlist), (gfp & ~GFP_DMA));
The parens now become redundant.
True thanks! I am also not sure that re-using the same gfp_t for
metadat
Hi,
On 07/03/18 18:30, James Bottomley wrote:
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Firstly, I don't see any justifiable benefit to churning this API, so
why bother? but secondly this:
Primarily because I wanted to extend sgl_alloc_order slight
On 07/03/18 18:38, Bart Van Assche wrote:
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
I spotted a few small issues in the recent added SGL code so am sending some
patches to tidy this.
Can you send the fixes as a separate series and keep the rework / behavior
changes
for later
On 08/03/18 15:56, Bart Van Assche wrote:
On Thu, 2018-03-08 at 07:59 +, Tvrtko Ursulin wrote:
However there is a different bug in my patch relating to the last entry
which can have shorter length from the rest. So get_order on the last
entry is incorrect - I have to store the deduced
On 07/03/18 17:06, Tvrtko Ursulin wrote:
On 07/03/18 16:10, Bart Van Assche wrote:
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
sgl_alloc_order explicitly takes a 64-bit length (unsigned long long)
but
then rejects it in overflow checking if greater than 4GiB allocation was
On 13/03/2018 16:19, Arnd Bergmann wrote:
The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:
drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used
uninit
On 13/03/2018 20:10, Arnd Bergmann wrote:
On Tue, Mar 13, 2018 at 6:46 PM, Tvrtko Ursulin
wrote:
On 13/03/2018 16:19, Arnd Bergmann wrote:
The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:
drivers/gpu/drm/i915/i915_pmu.c: I
From: Tvrtko Ursulin
We should not use an explicit width u32 for elem_len but unsinged int to
match the underlying type in struct scatterlist.
Signed-off-by: Tvrtko Ursulin
Cc: Bart Van Assche
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Jens Axboe
---
lib/scatterlist.c | 5 ++---
1
From: Tvrtko Ursulin
It is necessary to ensure types on both sides of the comparison are of the
same width. Otherwise the check overflows sooner than expect due left hand
side being an unsigned long length, and the right hand side unsigned int
number of elements multiplied by element size
From: Tvrtko Ursulin
Mostly same fixes and cleanups I've sent earlier in the year, but with some
patches dropped and some split into smaller ones as per request.
Tvrtko Ursulin (6):
lib/scatterlist: Use natural long for sgl_alloc(_order) length
parameter
lib/scatterlist: Use consi
From: Tvrtko Ursulin
If a higher-order allocation fails, the existing abort and cleanup path
would consider all segments allocated so far as 0-order page allocations
and would therefore leak memory.
Fix this by cleaning up using sgl_free_n_order which allows the correct
page order to be passed
From: Tvrtko Ursulin
None of the callers need unsinged long long (they either pass in an int,
u32, or size_t) so it is not required to burden the 32-bit builds with an
overspecified length parameter.
Signed-off-by: Tvrtko Ursulin
Cc: Bart Van Assche
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
From: Tvrtko Ursulin
sg_init_table will clear the allocated block so requesting zeroed memory
from the allocator is redundant.
Signed-off-by: Tvrtko Ursulin
Cc: Bart Van Assche
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Jens Axboe
---
lib/scatterlist.c | 3 +--
1 file changed, 1
From: Tvrtko Ursulin
There is an incosistency between data types used for order and number of
sg elements in the API.
Fix it so both are always unsigned int which, in the case of number of
elements, matches the underlying struct scatterlist.
Signed-off-by: Tvrtko Ursulin
Cc: Bart Van Assche
On 27/09/2018 21:15, Andi Kleen wrote:
+ mutex_lock(&pmus_lock);
+ list_for_each_entry(pmu, &pmus, entry)
+ pmu->perf_event_paranoid = sysctl_perf_event_paranoid;
+ mutex_unlock(&pmus_lock);
What happens to pmus that got added later?
There is a hunk a bit low
Hi,
On 28/09/2018 11:26, Thomas Gleixner wrote:
Tvrtko,
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own pile of email addresses. CC'ed now.
I accept it was by bad to miss addi
On 28/09/2018 15:02, Thomas Gleixner wrote:
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
On 28/09/2018 11:26, Thomas Gleixner wrote:
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing you
Hi Ravi,
On 03/07/18 11:24, Ravi Bangoria wrote:
Hi Tvrtko,
@@ -199,7 +199,7 @@ static inline void perf_get_data_addr(struct pt_regs *regs,
u64 *addrp)
if (!(mmcra & MMCRA_SAMPLE_ENABLE) || sdar_valid)
*addrp = mfspr(SPRN_SDAR);
- if (perf_paranoid_kernel() && !ca
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in sysfs.
These work in equivalent fashion as the existing perf_event_paranoid
sysctl, which now becomes the
From: Tvrtko Ursulin
To enable per-PMU access controls in a following patch first move all call
sites of perf_paranoid_kernel() to after the event has been created.
Signed-off-by: Tvrtko Ursulin
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
C
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in sysfs.
These work in equivalent fashion as the existing perf_event_paranoid
sysctl, which now becomes the
From: Tvrtko Ursulin
To enable per-PMU access controls in a following patch we need to start
passing in the PMU object pointer to perf_paranoid_* helpers.
This patch only changes the API across the code base without changing the
behaviour.
Signed-off-by: Tvrtko Ursulin
Cc: Thomas Gleixner
Cc
From: Tvrtko Ursulin
Explain behaviour of the new control knob along side the existing perf
event documentation.
Signed-off-by: Tvrtko Ursulin
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jir
On 26/06/18 18:24, Alexey Budankov wrote:
Hi,
On 26.06.2018 18:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
To enable per-PMU access controls in a following patch first move all call
sites of perf_paranoid_kernel() to after the event has been created.
Signed-off-by: Tvrtko Ursulin
Cc
On 26/06/18 18:25, Alexey Budankov wrote:
Hi,
On 26.06.2018 18:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in sysfs.
These
On 27/06/18 10:47, Alexey Budankov wrote:
On 27.06.2018 12:15, Tvrtko Ursulin wrote:
On 26/06/18 18:25, Alexey Budankov wrote:
Hi,
On 26.06.2018 18:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
access control for
Hi,
On 21/12/2018 10:33, Vincent Guittot wrote:
Use the new pm runtime interface to get the accounted suspended time:
pm_runtime_suspended_time().
This new interface helps to simplify and cleanup the code that computes
__I915_SAMPLE_RC6_ESTIMATED and to remove direct access to internals of
PM
On 21/12/2018 13:26, Vincent Guittot wrote:
On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin
wrote:
Hi,
On 21/12/2018 10:33, Vincent Guittot wrote:
Use the new pm runtime interface to get the accounted suspended time:
pm_runtime_suspended_time().
This new interface helps to simplify and
On 22/05/18 10:05, Peter Zijlstra wrote:
On Mon, May 21, 2018 at 10:25:49AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
of access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in
On 22/05/2018 13:32, Peter Zijlstra wrote:
On Tue, May 22, 2018 at 10:29:29AM +0100, Tvrtko Ursulin wrote:
On 22/05/18 10:05, Peter Zijlstra wrote:
On Mon, May 21, 2018 at 10:25:49AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
For situations where sysadmins might want to allow
On 10/12/2020 16:35, Thomas Gleixner wrote:
On Thu, Dec 10 2020 at 10:45, Tvrtko Ursulin wrote:
On 10/12/2020 07:53, Joonas Lahtinen wrote:
I think later in the thread there was a suggestion to replace this with
simple counter increment in IRQ handler.
It was indeed unsafe until recent
On 10/12/2020 17:44, Thomas Gleixner wrote:
On Thu, Dec 10 2020 at 17:09, Tvrtko Ursulin wrote:
On 10/12/2020 16:35, Thomas Gleixner wrote:
I'll send out a series addressing irq_to_desc() (ab)use all over the
place shortly. i915 is in there...
Yep we don't need atomic, my bad. An
either do that or
deal with wrap at PMU read time.
So thanks for dealing with it, some small comments below but overall it
is fine.
Signed-off-by: Thomas Gleixner
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
On 10/12/2020 07:53, Joonas Lahtinen wrote:
+ Tvrtko and Chris for comments
Code seems to be added in:
commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5
Author: Tvrtko Ursulin
Date: Tue Nov 21 18:18:50 2017 +
drm/i915/pmu: Add interrupt count metric
I think later in the thread
On Wed, 2013-12-11 at 18:07 +, Al Viro wrote:
> On Wed, Dec 11, 2013 at 05:59:57PM +0000, Tvrtko Ursulin wrote:
> > On Wed, 2013-12-11 at 17:49 +, Al Viro wrote:
> > > On Wed, Dec 11, 2013 at 05:04:41PM +0000, Tvrtko Ursulin wrote:
> > > > Hi all,
> > &
On Thu, 2013-12-12 at 13:49 +, Al Viro wrote:
> On Thu, Dec 12, 2013 at 01:40:40PM +0000, Tvrtko Ursulin wrote:
>
> > So this is the story... task_mmu.c:show_map_vma() calls seq_path. There
> > we have a d_path call which returns -ENAMETOOLONG and keeps doing so
> >
On Thu, 2013-12-12 at 14:21 +, Al Viro wrote:
> On Thu, Dec 12, 2013 at 01:59:31PM +0000, Tvrtko Ursulin wrote:
>
> > > a) *what* errors other than -ENAMETOOLONG?
> >
> > Is this your way of saying there can't be any other errors from d_path?
>
> Check
Hi all,
It seems that the buffer allocation in seq_read can double in size
indefinitely, at least I've seen that in practice with /proc//smaps
(attempting to double m->size to 4M on a read of 1000 bytes). This
produces an ugly WARN_ON_ONCE, which should perhaps be avoided? (given
that it can be tr
On Wed, 2013-12-11 at 17:04 +, Tvrtko Ursulin wrote:
> Hi all,
>
> It seems that the buffer allocation in seq_read can double in size
> indefinitely, at least I've seen that in practice with /proc//smaps
> (attempting to double m->size to 4M on a read of 1000 bytes).
On Wed, 2013-12-11 at 17:49 +, Al Viro wrote:
> On Wed, Dec 11, 2013 at 05:04:41PM +0000, Tvrtko Ursulin wrote:
> > Hi all,
> >
> > It seems that the buffer allocation in seq_read can double in size
> > indefinitely, at least I've seen that in practice with
On 16/05/16 16:19, Dave Gordon wrote:
The existing for_each_sg_page() iterator is somewhat heavyweight, and is
limiting i915 driver performance in a few benchmarks. So here we
introduce somewhat lighter weight iterators, primarily for use with GEM
objects or other case where we need only deal wi
Hi,
4.1.0-rc2 spews the below warning and disables lockdep for me at boot.
Any ideas?
May 7 11:58:20 skl kernel: [6.066696] futex hash table entries: 1024
(order: 5, 131072 bytes)
May 7 11:58:20 skl kernel: [6.075774] BUG: key 88014973b850 not in
.data!
May 7 11:58:20 skl kerne
On 05/07/2015 05:25 PM, Tejun Heo wrote:
> Hello,
>
> On Thu, May 07, 2015 at 04:05:57PM +0200, Peter Zijlstra wrote:
>> On Thu, May 07, 2015 at 02:54:00PM +0100, Tvrtko Ursulin wrote:
>>>
>>> Hi,
>>>
>>> 4.1.0-rc2 spews the below warning and
On 05/07/2015 06:29 PM, Peter Zijlstra wrote:
On Thu, May 07, 2015 at 07:06:26PM +0200, Peter Zijlstra wrote:
On Thu, May 07, 2015 at 05:29:57PM +0100, Tvrtko Ursulin wrote:
May 7 11:58:20 skl kernel: [6.066696] futex hash table entries: 1024
(order: 5, 131072 bytes)
May 7 11:58:20
react
to signals was the only problem then it is not too severe.
Add something to the commit message about how it was found/reported and
about the severity of impact, etc?
Otherwise,
Reviewed-by: Tvrtko Ursulin
Fixes regression from
commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2]
Author
drm/i915: Optimistically spin for the request completion
Reported-by: Jens Axboe
Link: https://lkml.org/lkml/2015/11/12/621
Cc: Jens Axboe
Cc; "Rogozhkin, Dmitry V"
Cc: Daniel Vetter
Cc: Tvrtko Ursulin
Cc: Eero Tamminen
Cc: "Rantala, Valtteri"
Cc: sta...@kernel.vger.org
---
driver
1 - 100 of 204 matches
Mail list logo
