Hello,
I became interested in an use case where I want to pass customised data from the
boot command-line to other user processes. I have read the available
documentation in the way that kernel modules provide such a means to get
additional parameters recorded.
I have got the understanding that a
> Why can't you use /proc/cmdline?
Thanks for your suggestion.
> (see parse_proc_cmdline())
How do you think about reasons like the following?
1. I would prefer to avoid the repeated parsing of boot command-line parameters
because the reuse of the kernel infrastructure should be better here.
> You can do all parsing in user space too.
Is it questionable when a custom prefix of a boot command-line parameter can not
be mapped to a kernel module?
> But I'm sure it will not get merged.
Thanks for your feedback.
> All you need is a dummy module with a few module_param()s.
My ideas we
> In the systemd case we have to ensure that we never ever merge a module named
> "systemd".
Interesting ...
> We have all kinds of strange modules/drivers. Usually you don't have to think
> whether your module is a "ordinary" driver or not...
Would it become useful to move "drivers" which do
Hello,
Two ways are mentioned in the Makefile for the Linux kernel 2.6.31.1 to specify
output
diretories. The description of the environment variable "KBUILD_OUTPUT" is
missing from
the file "README".
I am trying to generate all executable files for the current stable kernel
release on my
open
> Aren't you supposed to use O= as described by "make help"?
I expect that both ways should work. I find it easier to use the environment
variable
"KBUILD_OUTPUT" because the command line parameter does not need to be repeated
on each
make invocation.
Anyway - How do you think about my followin
> So here you do not have a .config file in the directory:
> /usr/src/obj/linux/2.6.23.1/x86_64/adjusted
> So you are told to create one using some of the available methods.
The README contains the following description.
"...
"make oldconfig" Default all questions based on the contents
>> Aren't you supposed to use O= as described by "make help"?
>
> I expect that both ways should work. I find it easier to use the environment
> variable
> "KBUILD_OUTPUT" because the command line parameter does not need to be
> repeated on each
> make invocation.
A wording correction:
I expect
> You did it in your output directory I assume.
No.
> kbuild complains that the source directory is not clean - which
> is what you need to clean up.
I am looking for the real reasons for the occuring error messages. Let us look
at another
test example ...
Sonne:~ # ls -ld /usr/src/linux
lrwx
> From the above we can see that two make's are running in parallel here
> where only one should run.
Is this a problem here? - I can omit the parameter "-j".
> I have seen this before but only in cases where you specified several targets
> on the make commandline - which you do not do in the ma
> .config should be copied to the output directory.
This copy will usually happen by a command like "make
O=/usr/src/obj/linux/2.6.23.1/x86_64/adjusted silentoldconfig". It seems that
something
runs unusual on my openSUSE 10.3 system when an extra output directory was
specified.
Regards,
Markus
>> Which files are not clean in my situation after the command "make mrproper"
>> was executed
>> at the beginning?
> If you look at the top-level Makefile you will see:
>
> @echo ' Using $(srctree) as source for kernel'
> $(Q)if [ -f $(srctree)/.config -o -d $(srctree)/include/c
Hello,
I get the following output from the command "make install" after the source
files were
successfully compiled for my personal configuration.
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map
2.6.23.1-default; fi
sh /usr/src/linux-2.6.23.1/arch/i386/boot/install.s
> Perhaps your personal configuration is missing the
> modules SUSE 10.3 requires. I'd use one of their rpms anyway.
I have assumed that my Linux distribution is clean enough to try out a current
kernel.
Would you like to recommend anything to get rid from these warnings about
unresolved
depende
> If you really have to roll your own kernel (often this is not the case-YMMV),
> I suggest you enable dm-snapshot and sd_mod.
I intentionally omitted the configuration option "DM_SNAPSHOT" because it is
marked as
"EXPERIMENTAL".
Snapshot target:
"Allow volume managers to take writable snapshots
Hello,
I get the following output from the command "head -n 7 /var/log/boot.msg".
Inspecting /boot/System.map-2.6.23.1-default
Loaded 27483 symbols from /boot/System.map-2.6.23.1-default.
Symbols match kernel version 2.6.23.
No module symbols loaded - kernel modules not enabled.
klogd 1.4.1, log
> This message is added by klogd, and it is independent of CONFIG_KALLSYMS.
> (Since I do have KALLSYMS=y while also getting that message. I suppose
> it is because CONFIG_DEBUG_INFO=n)
I could not find the message text in my kernel source directory so far. I had
also no luck
with a cross referen
> Like I said, klogd. This seems to be outside the scope of LKML.
Which function instructs the kernel log daemon to record the notice at the
beginning of
the boot process?
http://chuck.netbsd.sk/source/xref/sysklogd-1.4.1rh/klogd.c
Is the message sent by a printk() call?
Where is the text "Inspe
> Like I said, no. This is done by klogd.
Now I have found the notice "Inspecting" in the function "CheckMapVersion".
http://chuck.netbsd.sk/source/xref/sysklogd-1.4.1rh/ksym.c
I am interested to look at a source file that contains the dicussed error
message. Does
anybody know a development pack
> syslogd...src.rpm in your distribution.
I'm sorry - I can not select a -devel package for klogd, syslogd and syslog-ng
in my YaST2
GUI so far. Would you like to suggest any additional installation source?
Regards,
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
From: Markus Elfring
Date: Wed, 21 Sep 2016 13:31:45 +0200
The local variable "map" will be set to an appropriate pointer a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
1 file
From: Markus Elfring
Date: Fri, 29 Dec 2023 09:28:09 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Improve three size determinations
Improve error handling in virtio_fs_get_tree()
fs/fuse/virtio_fs.c | 19
From: Markus Elfring
Date: Fri, 29 Dec 2023 08:42:04 +0100
Replace the specification of data structures by pointer dereferences
as the parameter for the operator “sizeof” to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was
From: Markus Elfring
Date: Fri, 29 Dec 2023 09:15:07 +0100
The kfree() function was called in two cases by
the virtio_fs_get_tree() function during error handling
even if the passed variable contained a null pointer.
This issue was detected by using the Coccinelle software.
* Thus use another
>> The kfree() function was called in two cases by
>> the virtio_fs_get_tree() function during error handling
>> even if the passed variable contained a null pointer.
>
> So what? kfree(NULL) is perfectly acceptable.
I suggest to reconsider the usefulness of such a special function call.
> Are
>>> So what? kfree(NULL) is perfectly acceptable.
>>
>> I suggest to reconsider the usefulness of such a special function call.
>
> Can you be more explicit in your suggestion?
I hope that the change acceptance can grow for the presented transformation.
Are you looking for an improved patch descr
> Do you consider more clarity in your argumentation?
It is probably clear that the function call “kfree(NULL)” does not perform
data processing which is really useful for the caller.
Such a call is kept in some cases because programmers did not like to invest
development resources for its avoidan
>> It is probably clear that the function call “kfree(NULL)” does not perform
>> data processing which is really useful for the caller.
>> Such a call is kept in some cases because programmers did not like to invest
>> development resources for its avoidance.
>
> on the contrary, it is extremely us
> Automatically cleaned up pointers need to be initialized before exiting
> their scope. In this case, they need to be initialized to NULL before
> any return statement.
* May we expect that compilers should report that affected variables
were only declared here instead of appropriately defined
>>> Automatically cleaned up pointers need to be initialized before exiting
>>> their scope. In this case, they need to be initialized to NULL before
>>> any return statement.
>>
>> * May we expect that compilers should report that affected variables
>> were only declared here instead of appropr
…
> To fix it, we hold rcu lock as lookuping ftrace record, and call
> synchronize_rcu() before freeing any ftrace pages.
I suggest to convert this description into an imperative wording.
Regards,
Markus
…
> Therefore, the program should jump to the fail label instead of the out
> label. This commit fixes this bug.
>
> Signed-off-by: LuMingYin <11570291+yin-lum...@user.noreply.gitee.com>
Please improve your patch attempt considerably.
See also:
https://kernelnewbies.org/FirstKernelPatch
Are th
…
>
> If traceprobe_parse_probe_arg_body() fails to allocate 'parg->fmt', it
> jumps to 'out' instead of 'fail' by mistake. In the result, in this
> case the 'tmp' buffer is not freed and leaks its memory.
>
> Fix it by jumping to 'fail' in that case.
>
…
How do you think about anoth
I suggest to append parentheses to the function name in the summary phrase.
> If traceprobe_parse_probe_arg_body() fails to allocate 'parg->fmt', it
> jumps to 'out' instead of 'fail' by mistake. In the result, in this
> case the 'tmp' buffer is not freed and leaks its memory.
>
> Fix it by jumpi
> … by mistake.In the result,
…
I propose once more to start the second sentence of this change description
on a subsequent line.
> ---
> kernel/trace/trace_probe.c | 2 +-
…
Unfortunately, you overlooked to add patch version descriptions behind the
ma
…
> > it jumps to the label 'out' instead of 'fail' by mistake.In the result,
…
>
> Looks good to me.
* Do you care for a typo in this change description?
* Would you like to read any improved (patch) version descriptions (or
changelogs)?
Regards,
Markus
> When the condition ei->is_free holds,we return NULL directly to
> avoid update_events_attr to use NULL point about ei.
* Please avoid typos in the summary phrase and the commit message.
* Would you like to use an imperative wording for an improved change
description?
https://git.kernel.org/
…
> This commit introduce a read only interface of livepatch
Please improve the changelog with an imperative wording.
…
> find out which function is successfully called. Any testing process can make
> sure they
> have successfully cover all the patched function that changed with the help
> of
Please add a version identifier to the message subject.
…
> If the patched function have bug, it may cause serious result
> such as kernel crash.
Wording suggestion:
If the patched function has a bug, it might cause serious side effects
like a kernel crash.
> This is a kobject attribute
> The SY7802 is a current-regulated charge pump which can regulate two
> current levels for Flash and Torch modes.
>
> It is a high-current synchronous boost converter with 2-channel high
> side current sources. Each channel is able to deliver 900mA current.
Would you like to improve such a change
>> Would you become interested to apply a statement like
>> “guard(mutex)(&chip->mutex);”?
>> https://elixir.bootlin.com/linux/v6.10-rc3/source/include/linux/mutex.h#L196
>
> This does not look like real improvement for code this trivial.
Various source code places can be updated also according t
>> Various source code places can be updated also according to referenced
>> programming interfaces.
>> https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L8
>>
>> Will corresponding collateral evolution become better supported?
>
> Plesae stop this. cleanup.h might be a nice
…
> useless.
because …?
> Fix this issue by removing unneeded check.
Another wording suggestion:
Thus remove a redundant check.
…
> +++ b/drivers/remoteproc/remoteproc_elf_helpers.h
> @@ -107,7 +107,7 @@ static inline unsigned int elf_strtbl_add(const char
> *name, void *ehdr, u8
From: Markus Elfring
Date: Sun, 14 Jul 2024 13:13:15 +0200
Single characters should be put into a sequence.
Thus use the corresponding function “seq_putc”.
This issue was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
kernel/module/procfs.c | 4 ++--
1 file
From: Markus Elfring
Date: Sun, 14 Jul 2024 13:43:06 +0200
Subject: [PATCH] module: tracking: Extend format string of a seq_printf() call
in unloaded_tainted_modules_seq_show()
* Move the specification of a single line break from a seq_puts() call
into the format string of a previous
From: Markus Elfring
Date: Sun, 14 Jul 2024 15:40:34 +0200
Single characters should be put into a sequence.
Thus use the corresponding function “seq_putc”.
This issue was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
kernel/trace/trace_events_hist.c | 26
> Inject fault while probing of-fpga-region, if kasprintf() fails in
> module_add_driver(), the second sysfs_remove_link() in exit path will cause
> null-ptr-deref as below because kernfs_name_hash() will call strlen() with
> NULL driver_name.
…
How do you think about to use the term “null pointer
a direct function call within
a later condition check.
This issue was detected by using the Coccinelle software.
Fixes: d1c6e08e7503649e4a4f3f9e700e2c05300b6379 ("libnvdimm/labels: Add uuid
helpers")
Signed-off-by: Markus Elfring
---
drivers/nvdimm/pfn_devs.c | 3 +--
1 file
>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “nd_pfn_validate”.
>>
>> Thus avoid the risk for undefined behaviour by replacing the usage of
>> the local variable “parent_uuid” by a direct function call
> FYI - I'm a tiny bit taken aback that in response to me applying,
> and providing feedback, on your patch,
This will probably trigger collateral evolution, won't it?
> you respond with 2 links for me to follow
I offered another bit of background information according to your enquiry.
> and
> Change from v4:
…
I suggest to omit the cover letter for a single patch.
Will any patch series evolve for your proposed changes?
Regards,
Markus
> The thought was to put descriptions unsuitable for commit header in the cover
> letter.
How do you think about to put additional information below triple dashes
(or even into improved change descriptions)?
See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docume
>> How do you think about to put additional information below triple dashes
>> (or even into improved change descriptions)?
>>
>> See also:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.4#n686
>
> Markus,
>
> Please go a
>> Would you insist on the usage of cover letters also for single patches?
>
> I would neither insist on it, nor prohibit it.
It seems that you can tolerate an extra message here.
> It simply does not make enough difference.
Can it occasionally be a bit nicer to receive all relevant information
> +++ b/arch/arm/mach-hisi/hotplug.c
> @@ -173,11 +173,15 @@ static bool hix5hd2_hotplug_init(void)
…
> + ctrl_base = of_iomap(np, 0);
> + of_node_put(np);
> + if (!ctrl_base)
> + return false;
> +
> + return true;
> }
>
> void hix5hd2_set_cpu(int cpu, bool enable)
W
> The call to of_get_cpu_node returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
I would prefer a wording like the following.
A reference counter was incremented for a CPU node by a call of
the function “of_get_cpu_node”.
Thus decreme
> @@ -86,6 +86,7 @@ static int cbe_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> if (!cbe_get_cpu_pmd_regs(policy->cpu) ||
> !cbe_get_cpu_mic_tm_regs(policy->cpu)) {
> pr_info("invalid CBE regs pointers for cpufreq\n");
> + of_node_put(cpu);
>
> @@ -132,6 +132,7 @@ static int __init armada_8k_cpufreq_init(void)
> of_node_put(node);
> return -ENODEV;
> }
> + of_node_put(node);
>
> nb_cpus = num_possible_cpus();
> freq_tables = kcalloc(nb_cpus, sizeof(*freq_tables), GFP_KERNEL);
Would anot
> @@ -132,6 +132,7 @@ static int __init armada_8k_cpufreq_init(void)
> of_node_put(node);
> return -ENODEV;
> }
> + of_node_put(node);
>
> nb_cpus = num_possible_cpus();
> freq_tables = kcalloc(nb_cpus, sizeof(*freq_tables), GFP_KERNEL);
Would anot
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cpufreq/armada-8k-cpufreq.c?id=05d08e2995cbe6efdb993482ee0d38a77040861a#n137
>
> Thank you for your comments.
> Adding a null pointer check here is indeed safer.
I wonder then why such a return value check was omit
> and also do some cleanup:
Would it be safer to integrate this source code adjustment
by another update step?
Regards,
Markus
> @@ -210,7 +210,7 @@ static int __init maple_cpufreq_init(void)
>*/
> valp = of_get_property(cpunode, "clock-frequency", NULL);
> if (!valp)
> - return -ENODEV;
> + goto bail_noprops;
> max_freq = (*valp)/1000;
> maple_cpu_freqs[0].frequency
> To fix these possible bugs, index is checked before being used.
How do you think about a wording variant like the following?
Thus check the index before using it further.
Would you like to add the tag “Fixes” to the commit message?
Regards,
Markus
Please avoid typos in the patch subject.
> To fix this possible bug, sfr->buf_size is assigned to a local variable,
> and then this variable is checked before being used.
How do you think about a wording variant like the following?
Thus assign the data structure member “buf_size” to a local v
> This fixes it by checking sk->sk_shutdown(suggested by Stefano) after
> lock_sock since sk->sk_shutdown is set to SHUTDOWN_MASK under the
> protection of lock_sock_nested.
How do you think about a wording variant like the following?
Thus check the data structure member “sk_shutdown” (suggeste
> Change the maximum allowed line length to 100 from 80.
>
> Miscellanea:
>
> o to avoid unnecessary whitespace changes in files,
> checkpatch will no longer emit a warning about line length
> when scanning files unless --strict is also used
> o Add a bit to coding-style about alignment to open
> ---
> v5: sorry, MIME type in the previous commit message
>
> net/vmw_vsock/virtio_transport_common.c | 8
Is it helpful to keep the patch version information complete here?
(Will another fine-tuning follow for the proposed change?)
Regards,
Markus
> To fix this possible bug, data[0] is assigned to a local variable, which
> replaces the use of data[0].
How do you think about a wording variant like the following?
Thus assign the first element of the data array to a local variable
so that it can be used as an array index together with the
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.
* How do you think about to replace the word “pairing” by “corresponding”?
* Will it be helpful to a
> When gk20a_clk_ctor() returns an error code, pointer "clk"
> should be released.
Such an information is reasonable.
> It's the same when gm20b_clk_new() returns from elsewhere following this call.
I suggest to reconsider the interpretation of the software situation once more.
Can it be that t
> It's possible that we expect an usable clk pointer, though I could not find
> the exact usage yet.
I am curious if another developer would like to add helpful background
information.
> For security, I will release this pointer only on error paths in this
> function.
Do you tend to release o
> I just found that clk is referenced by pclk in this function. When clk is
> freed,
> pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not release
> clk
> in this function and there is no bug here.
Can there be a need to release a clock object after a failed gk20a_clk_ctor()
c
> If gk20a_clk_ctor() never returns such an error code,
> we may need not to release this clock object.
Would you like to achieve complete exception handling
also for this function implementation?
Regards,
Markus
> In this case, maybe we should check the return value of
> gk20a_clk_ctor() and release clk if it returns -ENOMEM.
All error situations (including failed memory allocations) can matter here.
> And many other functions also have the same issue
> (e.g. gm20b_clk_new_speedo0).
I recommend to incr
> When devm_regmap_init_i2c() returns an error code, a pairing
> runtime PM usage counter decrement is needed to keep the
> counter balanced.
How do you think about to replace the word “pairing” by “corresponding”?
> For error paths after ak8974_set_power(),
> ak8974_detect() and ak8974_reset(),
> pm_runtime_get_sync() increments the runtime PM usage counter even
> it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
How do you think about a wording variant like the following?
Change description:
The PM runtime usag
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
How do you think about a wording variant like the following?
Change description:
The PM runtime
> Match GFP_USER allocations with memdup_user.cocci rule.
Can this software extension help also for the clarification of the topic
“Safer source code analysis by "memdup_user.cocci"”?
https://github.com/coccinelle/coccinelle/issues/78
Regards,
Markus
> Add vmemdup_user() transformations to the memdup_user.cocci rule.
> Commit 50fd2f298bef ("new primitive: vmemdup_user()") introduced
> vmemdup_user(). The function uses kvmalloc with GPF_USER flag.
Such a software evolution is also interesting.
> +@depends on patch@
> +- to = \(kvmalloc\|kv
> Unfortunately, the Coccinelle software does not like the following
> SmPL code variant so far.
>
> to =
> (
> - \( kmalloc \| kzalloc \)
> + memdup_user
> |
> - \( kvmalloc \| kvzalloc \)
> + vmemdup_user
> )
> (
> - size, \( GFP_KERNEL \| GFP_USE
> +@rv depends on !patch@
> +expression from,to,size;
> +position p;
> +statement S1,S2;
> +@@
> +
> +* to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> + if (to==NULL || ...) S1
> + if (copy_from_user(to, from, size) != 0)
> + S2
How does the SmPL asterisk functionality fi
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a corresponding decrement is
> needed on the error handling path to keep the counter balanced.
>
> Fix this by adding the missed function call.
How do you think about a wording variant like
> Even in failed case of pm_runtime_get_sync, the usage_count
> is incremented. In order to keep the usage_count with correct
> value call pm_runtime_put_autosuspend.
* I find the word “usage_count” questionable in this change description.
* Will the tag “Fixes” become relevant for the commit mes
> Even in failed case of pm_runtime_get_sync, the usage_count
> is incremented. In order to keep the usage_count with correct
> value call appropriate put.
* I suggest to adjust the word “usage_count” in this change description.
* Would you like to add the tag “Fixes” to the commit message?
Rega
> Uninterruptible context is not needed in the driver and causes lockdep
> warning because of mutex taken in of_alias_get_id().
Was a spin lock taken?
> Convert the lock to mutex to avoid the issue.
Would you like to add the tag “Fixes” to the commit message?
Regards,
Markus
> sysnames should be freed after refcnt being decreased to zero in
> afs_put_sysnames().
* I suggest to use the wording “reference counter”.
* Where did you notice a “memory leak” here?
> Besides, it would be better set net->sysnames
> to 'NULL' after net->sysnames being released if afs_put_sys
> Fix some potential memory leaks in error handling branches while
> iterating xattr entries.
Such information is useful.
> For example, function ubifs_tnc_remove_ino()
> forgets to free pxent if it exists. Similar problems also exist in
> ubifs_purge_xattrs(), ubifs_add_orphan() and ubifs_jnl_w
> Optimize the error handling to free the resources correctly when
> failed to allocate an iommu group.
* I would not categorise the desired completion of exception handling
as a software optimisation.
* Would you like to add the tag “Fixes” to the commit message?
* I suggest to avoid the spec
>> I suggest to avoid the specification of duplicate function calls
>> (also for the desired exception handling).
>> Will it be helpful to add a few jump targets?
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=3d77e6a8804abcc0504
> sysnames should be freed after refcnt being decreased to zero in
> afs_put_sysnames().
How do you think about a wording variant like the following?
Release the sysnames object after its reference counter was decreased
to zero.
Will it matter to mention the size of the data structure "af
> Perhaps something like:
>
> Fix afs_put_sysnames() to actually free the specified afs_sysnames
> object after its reference count has been decreased to zero and its
> contents have been released.
* How do you think about to omit the word "Fix" because of the provided tag?
* Is
Hello,
I have accidentally taken another look at the implementation of
the function “afs_net_init”.
I noticed that the statement “net->live = false;” was specified three times
for exception handling at the end.
https://elixir.bootlin.com/linux/v5.7/source/fs/afs/main.c#L127
https://git.kernel.org/
> It will call devm_request_irq() after platform_get_irq() function
> in many drivers, sometimes, it is not right of the error handling
> for these two functions in some drivers. so provide this function
> to simplify the driver.
I suggest to improve also this change description.
How do you think
…
> The refcount leaks issues occur in two error handling paths.
Can it be nicer to use the term “reference count” for the commit message?
> Fix the issue by …
I suggest to replace this wording by the tag “Fixes”.
…
> +++ b/drivers/atm/atmtcp.c
> @@ -433,9 +433,15 @@ static int atmtcp_remove
> if of_find_device_by_node() succeed, sba_probe() doesn't have a
> corresponding put_device(). …
Wording adjustment:
If a of_find_device_by_node() call succeeded, sba_probe() did not
contain a corresponding put_device() call. …
Regards,
Markus
…
> The refcount leak issues take place in two error handling paths.
Can an other wording be a bit nicer for the commit message?
> Fix the issue by …
I suggest to replace this wording by the tag “Fixes”.
Regards,
Markus
> The driver initialization should be end immediately after found
> the platform_get_irq() function return an error.
I suggest to improve also this change description.
How do you think about a wording variant like the following?
Return an error code after a call of the function “platform_get_i
> The driver initialization should be end immediately after found
> the platform_get_irq() function return an error.
I recommend to improve also this change description.
How do you think about a wording variant like the following?
Return an error code after a call of the function “platform_get
Hello,
I find that identifiers like the following do not fit to the expected naming
convention of the C language standard.
- _ALPHA_BUG_H
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/alpha/include/asm/bug.h?id=acadbfb90a54673d6c8b05aa4e93218433890411#n1
- __BARRIER_H
From: Markus Elfring
Date: Fri, 6 Sep 2019 18:05:21 +0200
Simplify this function implementation by using a known function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dca/dca-sysfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions
1 - 100 of 4093 matches
Mail list logo
