In a process context kernel_read returns -EINTR, how to proceed?

[Lev Olshvang]

Hi All,

I use kernel_read to read  file in chunks of 4K size in a process context
On several files, like libc, libm,  I got -EINTR error.

Then I repeated the attempt limited number of times but still on every read 
attempt I got -EINTR

I do not understand who may interrupt such a small read, I suppose these 
libraries are already mapped in other processes so no real I/O should be done.

In a user space it is recommended to repeat syscall, what is the proper course 
of action in kernel.
As I stated, this code is not in a kernel thread or atomic context, it is in a 
process context so a tried  before next attempt yield() but to no success.

Waiting for your advises.
Thx,
Lev


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: In a process context kernel_read returns -EINTR, how to proceed?

[valdis . kletnieks]

On Thu, 20 Dec 2018 13:33:09 +0300, Lev Olshvang said:
> I use kernel_read to read  file in chunks of 4K size in a process context
> On several files, like libc, libm,  I got -EINTR error.

What are you trying to accomplish?  This is not a recommended way to do things.

> I do not understand who may interrupt such a small read, I suppose these
> libraries are already mapped in other processes so no real I/O should be done.

That should be a hint

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to detect slab memory leak

[Mulyadi Santosa]

On Wed, Dec 19, 2018 at 6:58 PM Naruto Nguyen 
wrote:

> Hi Harsh and Mulyadi,
>
> Thanks a lot  for your reply.
>
> Just another question, in the slabtop output, I see that we have
> kmalloc-64 and kmalloc-96 cache, when these caches increase their
> size, is it calculated in the "cache" of the "free" command or in
> "used".


If the cache is used for page cache related operations, then AFAIK it is
calculated in cache. If not, say for mmap non file backed operation, then
it is calculated in overall used.


> Is it reclaimable?


AFAIK yes, as long as it is not locked after being allocated.


> and count in SReclaimable or SUnreclaim of
> cat /proc/meminfo? I know some cache like dentry or inode cache will
> be calculated in "cache" of free command output and SReclaimable of
> cat /proc/meminfo and can be freed by "echo 3 >
> /proc/sys/vm/drop_caches" but not sure if it the same situation for
> kmalloc-64 and kmalloc-96 cache.
>
> Thanks again,
> Brs,
> Bao
>
> On Tue, 18 Dec 2018 at 15:31, Harsh Jain  wrote:
> >
> > You can try kernel config option "CONFIG_DEBUG_KMEMLEAK".
> >
> >
> > https://www.kernel.org/doc/html/v4.10/dev-tools/kmemleak.html
> >
> > On Tue, Dec 18, 2018 at 1:14 PM Mulyadi Santosa
> >  wrote:
> > >
> > >
> > >
> > > On Sun, Dec 16, 2018 at 1:25 PM Naruto Nguyen <
> narutonguyen2...@gmail.com> wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> When using slabtop to display the cache size growing, I see that
> > >> kmalloc-1024 and kmalloc-256 are increasing about 200MB after 1 hour.
> > >> Is there any way to detect which kernel components cause this slab
> > >> increase?
> > >>
> > >> Thanks a lot,
> > >> Brs,
> > >> Naruto
> > >>
> > >
> > > Hello Naruto
> > >
> > > I think you can do it by instrumenting call to kmalloc(). These days,
> eBPF is the hot stuff to try for this matter. See if it fits yours too.
> > >
> > > regards,
> > >
> > > Mulyadi
> > >
> > >>
> > >> ___
> > >> Kernelnewbies mailing list
> > >> Kernelnewbies@kernelnewbies.org
> > >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> > >
> > >
> > >
> > > --
> > > regards,
> > >
> > > Mulyadi Santosa
> > > Freelance Linux trainer and consultant
> > >
> > > blog: the-hydra.blogspot.com
> > > training: mulyaditraining.blogspot.com
> > > ___
> > > Kernelnewbies mailing list
> > > Kernelnewbies@kernelnewbies.org
> > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies