Re: [perf] perf probe fails sometimes on 4.9
Dear Masami, Now I am stuck again with 'perf test' failure on 4.9 # perf --version perf version 4.9.20- # perf test 16: Try 'import perf' in python, checking link problems : FAILED! 37.2: Test BPF prologue generation : FAILED! If you have any clue about these failure please hep me. Here are the verbose output: - 1) # perf test python -v 16: Try 'import perf' in python, checking link problems : --- start --- test child forked, pid 24562 Traceback (most recent call last): File "", line 1, in ImportError: No module named perf test child finished with -1 end Try 'import perf' in python, checking link problems: FAILED! -- 2) # perf test BPF -v --- . bpf: config 'func=null_lseek file->f_mode offset orig' is ok Looking at the vmlinux_path (8 entries long) symsrc__init: cannot get elf header. Failed to find the path for kernel: Invalid ELF file bpf_probe: failed to convert perf probe eventsFailed to add events selected by BPF test child finished with -1 end Test BPF filter subtest 1: FAILED! --- Thanks, Pintu On Wed, Jan 31, 2018 at 9:01 AM, Masami Hiramatsu wrote: > On Tue, 30 Jan 2018 19:20:36 +0530 > Pintu Kumar wrote: > >> On Tue, Jan 30, 2018 at 11:13 AM, Masami Hiramatsu >> wrote: >> > >> > On Mon, 29 Jan 2018 22:00:52 +0530 >> > Pintu Kumar wrote: >> > >> > > Dear Masami, >> > > >> > > Thank you so much for your reply. >> > > Please find some of my answers inline. >> > > >> > > >> > > On Mon, Jan 29, 2018 at 7:47 PM, Masami Hiramatsu >> > > wrote: >> > > > On Mon, 29 Jan 2018 13:40:34 +0530 >> > > > Pintu Kumar wrote: >> > > > >> > > >> Hi All, >> > > >> >> > > >> 'perf probe' is failing sometimes on 4.9.20 with AMD-64. >> > > >> # perf probe --add schedule >> > > >> schedule is out of .text, skip it. >> > > >> Error: Failed to add events. >> > > >> >> > > >> If any one have come across this problem please let me know the cause. >> > > > >> > > > Hi Pintu, >> > > > >> > > > Could you run it with --vv? >> > > > >> > > Ok, I will send verbose output by tomorrow. >> > > >> > > >> >> > > >> Note: I don't have CONFIG_DEBUG_INFO enabled in kernel. Is this the >> > > >> problem? >> > > > >> > > > Without it, you can not probe source-level probe nor trace local >> > > > variable. >> > > > >> > > >> > > Currently I am facing problem in enabling DEBUG_INFO in our kernel 4.9.20 >> > > However, I will try to manually include "-g" option during compilation. >> > > >> > > >> However, I manually copied the vmlinux file to /boot/ directory, but >> > > >> still it does not work. >> > > > >> > > > That doesn't work. >> > > > CONFIG_DEBUG_INFO option enables gcc to compile kernel with extra >> > > > debuginfo. >> > > > Without that option, debuginfo is not generated with vmlinux. >> > > > >> > > >> >> > > >> I checked upstream patches until 4.15 but could not find any clue. >> > > >> Please let me know if there is any fixes available for this. >> > > > >> > > > Could you also ensure that you run perf by root user? >> > > > >> > > >> > > Yes I am running with root user. >> > > >> > > My concern is sometimes it works but sometimes it fails. >> > >> > What I thought was that your kernel enables kptr_strict(but maybe not.) >> > Can you also try to find "schedule" and "_etext" functions in >> > /proc/kallsyms? >> > >> >> Yes these functions are present in kallsyms. >> >> # cat /proc/kallsyms | grep -w schedule ; cat /proc/kallsyms | grep -w _etext >> 829328e0 T schedule >> 8293e751 T _etext >> >> >> > > I still needs to figure out, in which condition it works and which >> > > condition it fails. >> > >> > Yeah, it is important. >> > >> > > Usually I noticed that in fresh reboot case it works. >> > >> > So, after a while, it doesn't work again? If so, it sounds like a daemon >> > process changes settings in background. >> > >> >> Fortunately or unfortunately, now it is passing every time. >> Still not sure about the cause. >> If it fails again, I will collect info with -v and report again. >> Any specific info that I need to check when it fails ? > > OK, if you hit it again, please run perf-probe with -vvv option > (-v is enough usually, if it is unknown bug, -vvv will be better) > > Thank you, > > >> >> Thank You, >> Pintu >> >> >> > Thank you, >> > >> > > >> > > >> > > > Thank you, >> > > > >> > > > >> > > >> >> > > >> >> > > >> Thank You! >> > > >> Regards, >> > > >> Pintu >> > > >> >> > > >> >> > > >> On Thu, Jan 25, 2018 at 7:09 PM, Pintu Kumar >> > > >> wrote: >> > > >> > Hi, >> > > >> > >> > > >> > ** Changed the subject now, since these issues are related to >> > > >> > general >> > > >> > perf commands. >> > > >> > >> >
Re: Mark dma buffer readonly
On Thu, 01 Feb 2018 00:15:03 +0530, Rohan Puri said: > See basic difference between mutex and spinlock is, the former puts the > thread waiting on the lock to sleep and later does a busy wait. > Since the nth bit is set every X ms, I think sleeping and waking up would > turn out to be costly operations/overhead so no mutex. Spinlock would be > good enough here. Depends on the value of X and the amount of contention. It's quite possible to lock up an entire CPU or even more for a considerable amount of ms out of every X using a spinlock. pgpDnKBVDw6Jt.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mark dma buffer readonly
On 31-Jan-2018 11:36 PM, "Saket Sinha" wrote:
>
>> However, I am using this in kthreads and I want to protect it without
>> using mutex/spilock.
>> Apart from protecting it with spinlock or mutex, is their anyway to
>> mark this dma buffer as read-only so that other threads(after
>> concerned thread has accessed it) cannot access the dma buffer.
>
> Basic locking theory states that if one section of code is already using
one
> type of locking primitive, and you want a lock on the resource, you need
to
> use the same type of lock, and the same instance.
>
I just love this above sentence, well put in a general sense, Valdis.
> In other words, you need to use a spinlock on dma_spin_lock as well, or
> things *will* fail (and when it's a DMA controller in question, the
failure will
> almost certainly be spectacular). So using a mutex is probably out of
> the question.
>
> Have you considered restructuring your code so a spinlock is usable?
>
Thanks Valdis for the prompt reply.
I would go ahead and check if spinlock could work instead of mutex
which I am currently using.
However, let me also explain the context how I am using mutex by below
pseudo code-
MUTEX_INIT(dma_lock);
void dummy_worker_thread()
{
...
mutex_lock(&dma_lock)
CHECK_BIT(hw_register, nth_bit);
mutex_unlock(&dma_lock);
}
Lets suppose the nth_bit is set in hw_register every X ms.
Do you think spinlock will be more advantageous here than mutex ?
See basic difference between mutex and spinlock is, the former puts the
thread waiting on the lock to sleep and later does a busy wait.
Since the nth bit is set every X ms, I think sleeping and waking up would
turn out to be costly operations/overhead so no mutex. Spinlock would be
good enough here.
Note: I am on ARMv8 SMP system using kernel version 4.4 .
Regards,
Saket Sinha
Regards,
Saket Sinha
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
- Rohan
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mark dma buffer readonly
>
>> However, I am using this in kthreads and I want to protect it without
>> using mutex/spilock.
>> Apart from protecting it with spinlock or mutex, is their anyway to
>> mark this dma buffer as read-only so that other threads(after
>> concerned thread has accessed it) cannot access the dma buffer.
>
> Basic locking theory states that if one section of code is already using one
> type of locking primitive, and you want a lock on the resource, you need to
> use the same type of lock, and the same instance.
>
> In other words, you need to use a spinlock on dma_spin_lock as well, or
> things *will* fail (and when it's a DMA controller in question, the failure
> will
> almost certainly be spectacular). So using a mutex is probably out of
> the question.
>
> Have you considered restructuring your code so a spinlock is usable?
>
Thanks Valdis for the prompt reply.
I would go ahead and check if spinlock could work instead of mutex
which I am currently using.
However, let me also explain the context how I am using mutex by below
pseudo code-
MUTEX_INIT(dma_lock);
void dummy_worker_thread()
{
...
mutex_lock(&dma_lock)
CHECK_BIT(hw_register, nth_bit);
mutex_unlock(&dma_lock);
}
Lets suppose the nth_bit is set in hw_register every X ms.
Do you think spinlock will be more advantageous here than mutex ?
Note: I am on ARMv8 SMP system using kernel version 4.4 .
Regards,
Saket Sinha
Regards,
Saket Sinha
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Mark dma buffer readonly
On Wed, 31 Jan 2018 19:49:29 +0530, Saket Sinha said: > As per ldd3 , Chapter 15 - "The DMA controller is a shared resource, > and confusion could arise if more than one > processor attempts to program it simultaneously. For that reason, the > controller is protected by a spinlock, called dma_spin_lock. Drivers > should not manipulate the > lock directly;" Yes, that way lies great pain and confusion. > However, I am using this in kthreads and I want to protect it without > using mutex/spilock. > Apart from protecting it with spinlock or mutex, is their anyway to > mark this dma buffer as read-only so that other threads(after > concerned thread has accessed it) cannot access the dma buffer. Basic locking theory states that if one section of code is already using one type of locking primitive, and you want a lock on the resource, you need to use the same type of lock, and the same instance. In other words, you need to use a spinlock on dma_spin_lock as well, or things *will* fail (and when it's a DMA controller in question, the failure will almost certainly be spectacular). So using a mutex is probably out of the question. Have you considered restructuring your code so a spinlock is usable? pgpZf505DKQrp.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Mark dma buffer readonly
Hi,
This is regarding dma memory usage in my kernel driver on arm64 processor.
I have a structure in my kernel driver as shown below-
struct dummy_dc_dmabuf {
struct dma_buf *buf;
struct dma_buf_attachment *attach;
struct sg_table *sgt;
};
For this I am able to get memory allocated like below
void pin_window(struct dummy_dmabuf **dum_buf, int fd, struct device *dev)
{
struct dummy_dmabuf *dum_dmabuf;
dma_addr_t dma_addr;
dum_dmabuf = kzalloc(sizeof(*dum_dmabuf), GFP_KERNEL);
if (!dum_dmabuf)
return -ENOMEM;
dum_dmabuf->buf = dma_buf_get(fd);
dum_dmabuf->attach = dma_buf_attach(dum_dmabuf->buf, dev->parent);
dum_dmabuf->sgt = dma_buf_map_attachment(dum_dmabuf->attach,
DMA_TO_DEVICE);
*dum_buf = dum_dmabuf;
}
As per ldd3 , Chapter 15 - "The DMA controller is a shared resource,
and confusion could arise if more than one
processor attempts to program it simultaneously. For that reason, the
controller is protected by a spinlock, called dma_spin_lock. Drivers
should not manipulate the
lock directly;"
However, I am using this in kthreads and I want to protect it without
using mutex/spilock.
Apart from protecting it with spinlock or mutex, is their anyway to
mark this dma buffer as read-only so that other threads(after
concerned thread has accessed it) cannot access the dma buffer.
Regards,
Saket Sinha
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
