Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add a method to CStr to get &str out of it #532

Closed
foxhlchen opened this issue Oct 25, 2021 · 4 comments · Fixed by #533
Closed

Add a method to CStr to get &str out of it #532

foxhlchen opened this issue Oct 25, 2021 · 4 comments · Fixed by #533
Labels
• lib Related to the `rust/` library.

Comments

@foxhlchen
Copy link

Currently, when you want to print the content of a CStr, you need to first call .as_bytes() and pass it to core::str::from_utf8 to get &str then use it in pr_*! macros, It's quite inconvenient.

We can add a helper method to CStr to get &str out of it.

As discussed by @wedsonaf in Zulip, appropriate naming is important, some namings are not good:

as_str implies it's free which is not true.

to_str isn't suitable because it's fallible

implementing TryFrom/TryInto or/and as_str_unchecked (core::str::from_utf8_unchecked) may be a good one.
@bjorn3
Copy link
Member

bjorn3 commented Oct 25, 2021

std::ffi::CStr has a method fn to_str(&self) -> Result<&str, Utf8Error>.

@ojeda ojeda added prio: normal • lib Related to the `rust/` library. labels Oct 25, 2021
@mdaverde mdaverde mentioned this issue Oct 26, 2021
Merged
@ojeda
Copy link
Member

ojeda commented Oct 26, 2021 •
edited
Loading

then use it in pr_*! macros, It's quite inconvenient.

Could we implement Display for CStr/BStr? (in addition to these methods, which are useful)

@bjorn3
Copy link
Member

bjorn3 commented Oct 26, 2021

Yes, but you will have to replace non-utf-8 bytes when passing it to the formatter.

@ojeda
Copy link
Member

ojeda commented Oct 26, 2021

+1, we should avoid panicking if we find invalid UTF-8.

@ojeda ojeda mentioned this issue Oct 26, 2021
Closed
ojeda pushed a commit that referenced this issue Jan 20, 2024
@Tropicao @linusw
pinctrl: at91-pio4: use dedicated lock class for IRQ
1469417 
Trying to suspend to RAM on SAMA5D27 EVK leads to the following lockdep
warning:

 ============================================
 WARNING: possible recursive locking detected
 6.7.0-rc5-wt+ #532 Not tainted
 --------------------------------------------
 sh/92 is trying to acquire lock:
 c3cf306c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100

 but task is already holding lock:
 c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&irq_desc_lock_class);
   lock(&irq_desc_lock_class);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 6 locks held by sh/92:
  #0: c3aa0258 (sb_writers#6){.+.+}-{0:0}, at: ksys_write+0xd8/0x178
  #1: c4c2df44 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x138/0x284
  #2: c32684a0 (kn->active){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x148/0x284
  #3: c232b6d4 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x13c/0x4e8
  #4: c387b088 (&dev->mutex){....}-{3:3}, at: __device_suspend+0x1e8/0x91c
  #5: c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100

 stack backtrace:
 CPU: 0 PID: 92 Comm: sh Not tainted 6.7.0-rc5-wt+ #532
 Hardware name: Atmel SAMA5
  unwind_backtrace from show_stack+0x18/0x1c
  show_stack from dump_stack_lvl+0x34/0x48
  dump_stack_lvl from __lock_acquire+0x19ec/0x3a0c
  __lock_acquire from lock_acquire.part.0+0x124/0x2d0
  lock_acquire.part.0 from _raw_spin_lock_irqsave+0x5c/0x78
  _raw_spin_lock_irqsave from __irq_get_desc_lock+0xe8/0x100
  __irq_get_desc_lock from irq_set_irq_wake+0xa8/0x204
  irq_set_irq_wake from atmel_gpio_irq_set_wake+0x58/0xb4
  atmel_gpio_irq_set_wake from irq_set_irq_wake+0x100/0x204
  irq_set_irq_wake from gpio_keys_suspend+0xec/0x2b8
  gpio_keys_suspend from dpm_run_callback+0xe4/0x248
  dpm_run_callback from __device_suspend+0x234/0x91c
  __device_suspend from dpm_suspend+0x224/0x43c
  dpm_suspend from dpm_suspend_start+0x9c/0xa8
  dpm_suspend_start from suspend_devices_and_enter+0x1e0/0xa84
  suspend_devices_and_enter from pm_suspend+0x460/0x4e8
  pm_suspend from state_store+0x78/0xe4
  state_store from kernfs_fop_write_iter+0x1a0/0x284
  kernfs_fop_write_iter from vfs_write+0x38c/0x6f4
  vfs_write from ksys_write+0xd8/0x178
  ksys_write from ret_fast_syscall+0x0/0x1c
 Exception stack(0xc52b3fa8 to 0xc52b3ff0)
 3fa0:                   00000004 005a0ae8 00000001 005a0ae8 00000004 00000001
 3fc0: 00000004 005a0ae8 00000001 00000004 00000004 b6c616c0 00000020 0059d190
 3fe0: 00000004 b6c61678 aec5a041 aebf1a26

This warning is raised because pinctrl-at91-pio4 uses chained IRQ. Whenever
a wake up source configures an IRQ through irq_set_irq_wake, it will
lock the corresponding IRQ desc, and then call irq_set_irq_wake on "parent"
IRQ which will do the same on its own IRQ desc, but since those two locks
share the same class, lockdep reports this as an issue.

Fix lockdep false positive by setting a different class for parent and
children IRQ

Fixes: 7761808 ("pinctrl: introduce driver for Atmel PIO4 controller")
Signed-off-by: Alexis Lothoré <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
• lib Related to the `rust/` library.
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

rust: add to_str and as_str_unchecked to CStr mdaverde/linux
3 participants
@ojeda @foxhlchen @bjorn3