All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>, jim.cromie@gmail.com
Cc: Constantine Shulyupin <constantine.shulyupin@gmail.com>,
	kernelnewbies@kernelnewbies.org
Subject: Re: unmap memory mapped with devm_ioremap_resource
Date: Fri, 9 Dec 2022 23:52:33 +0100	[thread overview]
Message-ID: <3c1746f3-0768-e47e-23f5-8e6997097f11@fastree3d.com> (raw)
In-Reply-To: <408767.1670618154@turing-police>

Hi,

I checked the kernel source code and, as I wrote, in my opinion, the 
proposed devm_iounmap doesn't seem to release all resources allocated 
with devm_ioremap_resource. Thus, I don't see a point in testing it, and 
I am still looking for the proper solution.

Jim, the original question is more than a week old.

Regards,
Adrian

On 9.12.2022 at 21:35, Valdis Klētnieks wrote:
> On Fri, 09 Dec 2022 12:58:20 -0700, jim.cromie@gmail.com said:
>> On Fri, Dec 9, 2022 at 9:14 AM Adrian Fiergolski <adrian.fiergolski@fastree3d.com> wrote:
>>> Does the community have any other ideas? Or I am wrong, and devm_iounmap is enough?
>> I dunno, but it says you asked ~4 hrs ago.
>> I bet you could just try it and get an answer faster.
>> Do feel free to report back.
> Note that it *is* possible for something to *look* like it works, but it leaves
> dangling pointers or other hidden corruption that takes a while to surface.  I
> once had to troubleshoot a userspace bug that worked fine on one system but
> blew up on another with a different malloc() - some 6 million malloc calls
> after the bug hit.
>
> Fortunately, the vast majority of kernel functions will return an error code if
> anything at all fishy happened, so just checking return codes on *everything* is
> usually good enough...
>

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

  reply	other threads:[~2022-12-09 22:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 17:24 unmap memory mapped with devm_ioremap_resource Adrian Fiergolski
2022-12-02 18:01 ` Constantine Shulyupin
2022-12-06 21:23   ` Adrian Fiergolski
2022-12-09 16:14     ` Adrian Fiergolski
2022-12-09 19:58       ` jim.cromie
2022-12-09 20:35         ` Valdis Klētnieks
2022-12-09 22:52           ` Adrian Fiergolski [this message]
2022-12-10  6:53             ` Constantine Shulyupin

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=3c1746f3-0768-e47e-23f5-8e6997097f11@fastree3d.com \
    --to=adrian.fiergolski@fastree3d.com \
    --cc=constantine.shulyupin@gmail.com \
    --cc=jim.cromie@gmail.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=valdis.kletnieks@vt.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.