English and it magic-number.rsts were updated when these were removed;
the zh translations weren't
This equalises these lists to be the same across all translations
Automated:
grep MAGIC Documentation/translations/process/zh_TW/magic-number.rst |
while read -r mag _; do git grep -wF "$mag" | grep -vq \
'^Documentation.*magic-number.rst:' || sed -i "/^$mag/d" \
./Documentation/{,translations/{zh_CN,zh_TW,it_IT}/}process/magic-number.rst
; done
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Link: https://lore.kernel.org/r/5d9fa062178c45822a600a723f6f71fdb92011f3.1663280877.git.nabijaczleweli@nabijaczleweli.xyz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The last user was removed in 5.1 in
commit 08300f4402 ("a.out: remove core dumping support")
but this is part of the UAPI headers, so this may want to either wait
until a.out is removed entirely, or be removed from the magic number doc
and silently remain in the header
A cursory glance on DCS didn't show any user code actually using this
value
Found with
grep MAGIC Documentation/process/magic-number.rst | while read -r mag _;
do git grep -wF "$mag" | grep -ve '^Documentation.*magic-number.rst:' \
-qe ':#define '"$mag" || git grep -wF "$mag" | while IFS=: read -r f _;
do sed -i '/\b'"$mag"'\b/d' "$f"; done ; done
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Link: https://lore.kernel.org/r/9cbea062df7125ef43e2e0b2a67ede6ad1c5f27e.1663280877.git.nabijaczleweli@nabijaczleweli.xyz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The entire file blames back to the start of git
(minus whitespace from the RST translation and a typo fix):
* there are changelog comments for March 1994 through to Linux 2.5.74
* struct tty_ldisc is two pointers nowadays, so naturally no magic
* GDA_MAGIC is defined but unused, and it's been this way
since start-of-git
* M3_CARD_MAGIC isn't defined, because
commit d56b9b9c46 ("[PATCH] The scheduled removal of some OSS
drivers") removed the entire driver in 2006
* CS_CARD_MAGIC likewise since
commit b5d425c97f ("more scheduled OSS driver removal") in 2007
* KMALLOC_MAGIC and VMALLOC_MAGIC were removed in
commit e38e0cfa48 ("[ALSA] Remove kmalloc wrappers"),
six months after start of git
* SLAB_C_MAGIC has never even appeared in git
(removed in 2.4.0-test3pre6)
magic-number.rst is a low-value historial relic at best and
misleading cruft at worst, so start with cleaning out ones that only
appear therein
Automated:
grep MAGIC Documentation/process/magic-number.rst | while read -r mag _;
do git grep -wF "$mag" | grep -vq '^Documentation.*magic-number.rst:' ||
sed -i "/^$mag/d" \
Documentation/{,translations/{zh_CN,zh_TW,it_IT}/}process/magic-number.rst
done
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Link: https://lore.kernel.org/r/8389a7b85b5c660c6891b1740b5dacc53491a41b.1663280877.git.nabijaczleweli@nabijaczleweli.xyz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In following scenario(diagram), when one thread X running dev_coredumpm()
adds devcd device to the framework which sends uevent notification to
userspace and another thread Y reads this uevent and call to
devcd_data_write() which eventually try to delete the queued timer that
is not initialized/queued yet.
So, debug object reports some warning and in the meantime, timer is
initialized and queued from X path. and from Y path, it gets reinitialized
again and timer->entry.pprev=NULL and try_to_grab_pending() stucks.
To fix this, introduce mutex and a boolean flag to serialize the behaviour.
cpu0(X) cpu1(Y)
dev_coredump() uevent sent to user space
device_add() ======================> user space process Y reads the
uevents writes to devcd fd
which results into writes to
devcd_data_write()
mod_delayed_work()
try_to_grab_pending()
del_timer()
debug_assert_init()
INIT_DELAYED_WORK()
schedule_delayed_work()
debug_object_fixup()
timer_fixup_assert_init()
timer_setup()
do_init_timer()
/*
Above call reinitializes
the timer to
timer->entry.pprev=NULL
and this will be checked
later in timer_pending() call.
*/
timer_pending()
!hlist_unhashed_lockless(&timer->entry)
!h->pprev
/*
del_timer() checks h->pprev and finds
it to be NULL due to which
try_to_grab_pending() stucks.
*/
Link: https://lore.kernel.org/lkml/2e1f81e2-428c-f11f-ce92-eb11048cb271@quicinc.com/
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/1663073424-13663-1-git-send-email-quic_mojha@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Users may have explicitly configured their debugfs permissions; we
shouldn't overwrite those just because a second mount appeared.
Only clobber if the options were provided at mount time.
Existing behavior:
## Pre-existing status: debugfs is 0755.
# chmod 755 /sys/kernel/debug/
# stat -c '%A' /sys/kernel/debug/
drwxr-xr-x
## New mount sets kernel-default permissions:
# mount -t debugfs none /mnt/foo
# stat -c '%A' /mnt/foo
drwx------
## Unexpected: the original mount changed permissions:
# stat -c '%A' /sys/kernel/debug
drwx------
New behavior:
## Pre-existing status: debugfs is 0755.
# chmod 755 /sys/kernel/debug/
# stat -c '%A' /sys/kernel/debug/
drwxr-xr-x
## New mount inherits existing permissions:
# mount -t debugfs none /mnt/foo
# stat -c '%A' /mnt/foo
drwxr-xr-x
## Expected: old mount is unchanged:
# stat -c '%A' /sys/kernel/debug
drwxr-xr-x
Full test cases are being submitted to LTP.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20220912163042.v3.1.Icbd40fce59f55ad74b80e5d435ea233579348a78@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This merges the driver core changes in 6.0-rc7 into driver-core-next as
they are needed here as well for testing.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Both bLedOn and BlinkingLedState in struct led_priv store the same
information.
The boolean bLedOn stores the curent led state while BlinkingLedState
stores the next led state to be set during blinking, which is the inverse
of the current led state. (The led is either off or blinking, it's never
continuously on.)
This patch removes BlinkingLedState and uses bLedOn instead.
The LED_BLINK_WPS_STOP case in blink_work checked for
pLed->BlinkingLedState != RTW_LED_ON. This is true if the next led
blinking state is ON, i.e. if the led has just been switched off by
blink_work, i.e. if (!pLed->bLedOn).
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20220918175700.215170-5-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the bLedNoLinkBlinkInProgress state variable. Its sole purpose is
to block subsequent requests for "no link" blinking when this blinking
pattern is already active.
It's perfectly safe to restart "no link" blinking. We can remove
bLedNoLinkBlinkInProgress and the many places where it's updated.
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20220918175700.215170-4-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In _rtw_init_xmit_priv(), there are several error paths for allocation
failures just jump to the `exit` section. However, there is no action
will be performed, so the allocated resources are not properly released,
which leads to various memory leaks.
To properly release them, this patch unifies the error handling code and
several error handling paths are added.
According to the allocation sequence, if the validation fails, it will
jump to its corresponding error tag to release the resources.
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150
Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
Link: https://lore.kernel.org/r/tencent_DB57E4F270F4539485C32B05FDAF8394310A@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The functions _rtw_init_recv_priv(), _rtw_free_recv_priv() and
rtw_recv_entry() are defined in rtw_recv.c. Move their prototypes from
recv_osdep.h to rtw_recv.h.
Move the last two remaining prototypes netdev_open() and netdev_close()
from recv_osdep.h to osdep_intf.h. That is a more appropriate place and
we can remove recv_osdep.h.
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20220911174933.3784-4-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocated
in failure, then `pcmdpriv->cmd_allocated_buf` will not be properly
released. Besides, considering there are only two error paths and the
first one can directly return, we do not need to implicitly jump to the
`exit` tag to execute the error handling code.
So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the error
path to release the resource and simplified the return logic of
rtw_init_cmd_priv(). As there is no proper device to test with, no
runtime testing was performed.
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150
Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
Link: https://lore.kernel.org/r/tencent_1B6AAE10471D4556788892F8FF3E4812F306@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In some initialization functions of this driver, memory is allocated with
'i' acting as an index variable and increasing from 0. The commit in
"Fixes" introduces some clean-up codes in case of allocation failure,
which free memory in reverse order with 'i' decreasing to 0. However,
there are some problems:
- The case i=0 is left out. Thus memory is leaked.
- In case memory allocation fails right from the start, the memory
freeing loops will start with i=-1 and invalid memory locations will
be accessed.
One of these loops has been fixed in commit c8ff915358 ("staging:
vt6655: fix potential memory leak"). Fix the remaining erroneous loops.
Link: https://lore.kernel.org/linux-staging/Yx9H1zSpxmNqx6Xc@kadam/
Fixes: 5341ee0adb ("staging: vt6655: check for memory allocation failures")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Signed-off-by: Nam Cao <namcaov@gmail.com>
Link: https://lore.kernel.org/r/20220912170429.29852-1-namcaov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
