bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Gilad Reti <gilad.reti@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: probe_write_common_error
Date: Wed, 1 Apr 2020 16:28:49 -0700	[thread overview]
Message-ID: <20200401232849.wms6vfuozvis5t2s@ast-mbp> (raw)
In-Reply-To: <CANaYP3GNm-siPt49Z5SSvgcF9YT4oN_enznMkaEFgbBBC9qrDQ@mail.gmail.com>

On Tue, Mar 31, 2020 at 07:16:28PM +0300, Gilad Reti wrote:
> When I try to probe_write_common into a writable location (e.g a
> memory address on a usermode stack) which is not yet mapped or mapped
> as read only to the memory, the function sometimes return a EFAULT
> (bad address) error. This is happening since the pagefault handler was
> disabled and thus this memory location won't be mapped when the
> function tries to write into it, an error will be returned and no data
> will be written.
> Is that behavior intended? Did you want those functions to have as
> less side-effects are possible?

You mean bpf_probe_write_user() helper?
Yes it's a non-faulting helper that will fail if prog is trying to
write into a valid memory that could have been served with minor fault.
The main reason for this is that bpf progs are not allowed to sleep.
We're working on sleepable bpf progs that will be able to do copy_from/to_user
from the context where it is safe to sleep. Like syscall entry.
Could you please share more about your use case, so we can make sure
that it will be covered by upcoming work?

  reply	other threads:[~2020-04-01 23:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 16:16 probe_write_common_error Gilad Reti
2020-04-01 23:28 ` Alexei Starovoitov [this message]
     [not found]   ` <CANaYP3GgpWKpiW-ATQ6UYLwNWJ3EqBKf-6d8Ki4xWXHVBOGvQw@mail.gmail.com>
2020-04-02 15:37     ` probe_write_common_error Alexei Starovoitov
2020-04-02 16:16       ` probe_write_common_error Gilad Reti
2020-04-21 18:54         ` probe_write_common_error John Fastabend

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200401232849.wms6vfuozvis5t2s@ast-mbp \
    --to=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=gilad.reti@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).