From 4617721c502b2ddaa4e324e86da4997edf738fa5 Mon Sep 17 00:00:00 2001 From: Steven Rostedt Date: Wed, 2 Sep 2026 09:55:01 -0400 Subject: ftrace: Synchronize the initialization of ftrace_ops There's some internal state that ftrace_ops needs to have set, but since it can be declared outside of the ftrace.c code, it calls ftrace_ops_init() on the ops in every global function. The issue is that if two tasks call it on the same ops at the same time it is possible to have the initialization of one corrupt the initialization of the other call. Create a ops_mutex to use to synchronize every initialization of the ftrace_ops. The mutex is taken within checking the ftrace_ops flag that states it was initializied but the flag is checked again after the mutex has been taken. Checking first outside the mutex allows it to shortcut having to take the mutex. But then the check needs to be done again after the mute is taken in case of races. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902095501.6b59af20@gandalf.local.home Fixes: f04f24fb7e48d ("ftrace, kprobes: Fix a deadlock on ftrace_regex_lock") Reported-by: sashiko-bot@kernel.org Close: https://lore.kernel.org/all/20260829025528.49A831F000E9@smtp.kernel.org/ Signed-off-by: Steven Rostedt --- Documentation/fb/internals.rst | 86 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/fb/internals.rst (limited to 'Documentation/fb/internals.rst') diff --git a/Documentation/fb/internals.rst b/Documentation/fb/internals.rst new file mode 100644 index 000000000..696b50aa7 --- /dev/null +++ b/Documentation/fb/internals.rst @@ -0,0 +1,86 @@ +============================= +Frame Buffer device internals +============================= + +This is a first start for some documentation about frame buffer device +internals. + +Authors: + +- Geert Uytterhoeven , 21 July 1998 +- James Simmons , Nov 26 2002 + +-------------------------------------------------------------------------------- + +Structures used by the frame buffer device API +============================================== + +The following structures play a role in the game of frame buffer devices. They +are defined in . + +1. Outside the kernel (user space) + + - struct fb_fix_screeninfo + + Device independent unchangeable information about a frame buffer device and + a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO + ioctl. + + - struct fb_var_screeninfo + + Device independent changeable information about a frame buffer device and a + specific video mode. This can be obtained using the FBIOGET_VSCREENINFO + ioctl, and updated with the FBIOPUT_VSCREENINFO ioctl. If you want to pan + the screen only, you can use the FBIOPAN_DISPLAY ioctl. + + - struct fb_cmap + + Device independent colormap information. You can get and set the colormap + using the FBIOGETCMAP and FBIOPUTCMAP ioctls. + + +2. Inside the kernel + + - struct fb_info + + Generic information, API and low level information about a specific frame + buffer device instance (slot number, board address, ...). + + - struct `par` + + Device dependent information that uniquely defines the video mode for this + particular piece of hardware. + + +Visuals used by the frame buffer device API +=========================================== + + +Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10) +-------------------------------------------------- +Each pixel is either black or white. + + +Pseudo color (FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR) +--------------------------------------------------------------------- +The whole pixel value is fed through a programmable lookup table that has one +color (including red, green, and blue intensities) for each possible pixel +value, and that color is displayed. + + +True color (FB_VISUAL_TRUECOLOR) +-------------------------------- +The pixel value is broken up into red, green, and blue fields. + + +Direct color (FB_VISUAL_DIRECTCOLOR) +------------------------------------ +The pixel value is broken up into red, green, and blue fields, each of which +are looked up in separate red, green, and blue lookup tables. + + +Grayscale displays +------------------ +Grayscale and static grayscale are special variants of pseudo color and static +pseudo color, where the red, green and blue components are always equal to +each other. -- cgit v1.3.1