While doing some code auditing for -Woverride_init, I spotted some questionable
code
commit 502e84e2382d92654a2ecbc52cdbdb5a11cdcec7
Author: Felix Fietkau
Date: Wed Mar 24 02:30:54 2021 +0100
net: ethernet: mtk_eth_soc: add flow offloading support
In drivers/net/ethernet/mediatek/mtk_ppe
This commit:
commit 8de000cf0265eaa4f63aff9f2c7a3876d2dda9b6
Author: Yong Wu
Date: Fri Mar 26 11:23:36 2021 +0800
iommu/mediatek-v1: Allow building as module
changes drivers/iommu/Kcconfig
config MTK_IOMMU_V1
- bool "MTK IOMMU Version 1 (M4U gen1) Support"
+ tristate "MediaT
On Thu, 18 Mar 2021 11:41:29 -, David Laight said:
> That gcc bug just implies you need a space after "xxx".
> That is easily fixable in the sources.
It's not quite that simple.
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27,
from
/usr/li
On Thu, 18 Mar 2021 18:07:28 +0900, Masahiro Yamada said:
> We can require GCC 6+ for building GCC plugins.
> + depends on CC_IS_GCC && GCC_VERSION >= 6
I'd be OK with that personally, but the question is whether
any gcc 4.9 or 5.x users are using plugins. That's a bit above
my pay gr
On Wed, 17 Mar 2021 22:52:56 -0700, Kees Cook said:
> On Mon, Mar 08, 2021 at 03:40:21AM -0500, Valdis KlÄtnieks wrote:
> > It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
> > due to a gcc bug fixed in gcc6, throw errors during the build.
> > The relevant gcc bug is https://gcc
On Mon, 15 Mar 2021 19:23:00 -, Christoph Hellwig said:
> On Mon, Mar 15, 2021 at 11:14:34AM +, Catalin Marinas wrote:
> > We do similar initialisation in arch/arm64/kernel/sys32.c and
> > arch/arm64/kernel/traps.c for example. It's a pretty common pattern
> > throughout the kernel.
> >
>
Building arch/arm64/kernel/sys.o with W=1 throws over 300 warnings:
/usr/src/linux-next/arch/arm64/kernel/sys.c:56:40: warning: initialized field
overwritten [-Woverride-init]
56 | #define __SYSCALL(nr, sym) [nr] = __arm64_##sym,
|^~~~
/us
sparse throws 27 complaints of the form:
CHECK /usr/src/linux-next/drivers/gpu/drm/msm/msm_perf.c
/usr/src/linux-next/drivers/gpu/drm/msm/msm_perf.c: note: in included file
(through /usr/src/linux-next/drivers/gpu/drm/msm/msm_gpu.h):
/usr/src/linux-next/include/linux/adreno-smmu-priv.h:36:33:
On Fri, 12 Mar 2021 09:01:36 +, David Howells said:
> Possibly I can add something like:
>
> clean-files := signing_key.pem x509.genkey
>
> inside the
>
> ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
> ...
> endif
Would that remove them on a 'make clean', or
On Thu, 11 Mar 2021 12:04:19 +, David Howells said:
> EXTRACT_CERTS /usr/src/linux-next/"certs/signing_key.pem"
>
> but I don't know why. There are some odd quotes in your line also which may
> be related to the problem. The relevant config line looks the same:
>
> CONFIG_MODUL
On Thu, 11 Mar 2021 10:49:14 +, David Howells said:
> I wonder... Can you grab branch keys-cve-2020-26541-branch from:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
>
> and try that? If that breaks, can you try dropping the top four commits?
[/usr/src/linux
On Thu, 11 Mar 2021 09:34:01 +, David Howells said:
> Valdis KlÄtnieks wrote:
>
> > What i *expected* was that multiple builds with different O= would each
> > generate themselves a unique signing key and put it in their own O=
> > directory
> > and stay out of each other's way.
>
> Hmmm...
So, I tried doing a 'make O=... allmodconfig', with a setup where the uid of
the build process had write permission to the O= directory, but intentionally
did *not* have write permission to the source tree (so they couldn't mess up
the tree - I got tired of having to repeatedly do 'make mrproper' b
It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
due to a gcc bug fixed in gcc6, throw errors during the build.
The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
Version the option based on what gcc we're using.
Signed-off-by: Valdis Kletnieks
Fixes: 2
On Wed, 03 Mar 2021 07:51:06 +0100, Heiner Kallweit said:
> > # Firmware loader
> > CONFIG_EXTRA_FIRMWARE="rtl_nic/rtl8106e-1.fw"
> > CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
> >
> This is wrong, simply remove it.
> > But then I take a closer look at drivers/net/ethernet/realtek/r8169_main.c
>
So my kernel build died..
UPD drivers/base/firmware_loader/builtin/rtl_nic/rtl8106e-1.fw.gen.S
make[4]: *** No rule to make target '/lib/firmware/rtl_nic/rtl8106e-1.fw',
needed by 'drivers/base/firmware_loader/builtin/rtl_nic/rtl8106e-1.fw.gen.o'.
Stop.
make[3]: *** [scripts/Makefile.buil
On Tue, 16 Feb 2021 13:36:22 +0100, "Jason A. Donenfeld" said:
> Another anecdote: 5.11.0, 64 gigs of ram. If I run QEMU/KVM for a VM
> with 16 gigs at the same time as a VMware VM with 16 gigs of ram,
> kcompact goes wild and both VMs get really slow. The key here is running
> KVM at the same tim
On Sun, 14 Feb 2021 04:00:31 +0800, kernel test robot said:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: dcc0b49040c70ad827a7f3d58a21b01fdb14e749
> commit: 67a5a68013056cbcf0a647e36cb6f4622fb6a470 gcc-plugins: fix gcc 11
> indigestion with plugi
On Mon, 25 Jan 2021 19:54:38 +0100, Tibor Bana said:
> I don't know if it still actual, but I am strugling with this problem right
> now and searching the internet for solutions. I read the thread and saw that
> you are strugling to reproduce the problem, and I can reproduce it almost
> every
> d
Correct the spelling of Nagle's name in a comment.
Signed-off-by: Valdis Kletnieks
diff --git a/drivers/target/iscsi/iscsi_target_login.c
b/drivers/target/iscsi/iscsi_target_login.c
index 893d1b406c29..1a9c50401bdb 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscs
It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
due to a gcc bug fixed in gcc6, throw errors during the build.
The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
Version the option based on what gcc we're using.
Signed-off-by: Valdis Kletnieks
Fixes: 2
On Wed, 13 Jan 2021 11:08:36 -0600, Josh Poimboeuf said:
> The first patch has already been merged into Linus' tree, so this
> probably should be an incremental fix on top, with a Fixes: tag.
Gaah. v3 in a moment. :)
pgpsvMPHiYHXD.pgp
Description: PGP signature
Fedora Rawhide has started including gcc 11,and the g++ compiler
throws a wobbly when it hits scripts/gcc-plugins:
HOSTCXX scripts/gcc-plugins/latent_entropy_plugin.so
In file included from /usr/include/c++/11/type_traits:35,
from
/usr/lib/gcc/x86_64-redhat-linux/11/plugin/incl
On Mon, 11 Jan 2021 11:48:32 -0800, Kees Cook said:
> On Mon, Jan 11, 2021 at 07:37:19AM -0600, Josh Poimboeuf wrote:
> > I think putting the flag in a variable (based on call cc-ifversion)
> > should be easy enough, then we can put this little saga behind us and
> > pretend it never happened :-)
On Mon, 11 Jan 2021 05:56:59 -0500, I said:
> > It's probably related. I'm just having a hard time understanding why 4.9
> > and 5.4
> > whine about the lack of a space, while 8.3 and 11 didn't complain...
So after more digging, at least some clarity has surfaced.
It looks like it's not a kerne
On Mon, 11 Jan 2021 10:47:23 +0100, Geert Uytterhoeven said:
> I guess this is the cause of the new "warning: invalid suffix on
> literal; C++11 requires a space between literal and string macro
> [-Wliteral-suffix]" with gcc 4.9 or 5.4?
Well, we fixed a #error, and picked up a warning. That's p
On Sun, 03 Jan 2021 10:20:11 -0800, Stephen Hemminger said:
> You can use a qdisc that is a module, it just has to be available when device
> is loaded. Typically that means putting it in initramfs.
Apparently, that's not *quite* true regarding the default qdisc, because I
hit this situation (copy
Consider the following own goal I just discovered I scored:
[~] zgrep -i fq_codel /proc/config.gz
CONFIG_NET_SCH_FQ_CODEL=m
CONFIG_DEFAULT_FQ_CODEL=y
CONFIG_DEFAULT_NET_SCH="fq_codel"
Obviously, fq_codel didn't get set as the default, because that happens
before the module gets loaded (which may
Fedora Rawhide has started including gcc 11,and the g++ compiler
throws a wobbly when it hits scripts/gcc-plugins:
HOSTCXX scripts/gcc-plugins/latent_entropy_plugin.so
In file included from /usr/include/c++/11/type_traits:35,
from
/usr/lib/gcc/x86_64-redhat-linux/11/plugin/incl
commit 2df573d2ca4c1ce6ea33cb7849222f771e759211
Author: Andrey Konovalov
Date: Tue Nov 24 16:45:08 2020 +1100
kasan: shadow declarations only for software modes
introduces a build failure when it removed an include for linux/pgtable.h
It actually only needs linux/linkage.h
Test builds on
On Thu, 26 Nov 2020 14:14:29 +, Russell King - ARM Linux admin said:
> The real answer is for asm/kasan.h to include linux/linkage.h
Looking deeper, there's 7 different arch/../asm/kasan.h - are we better off
patching all 7, or having include/linux/kasan.h include it just before
the include
On Thu, 26 Nov 2020 14:14:29 +, Russell King - ARM Linux admin said:
> The real answer is for asm/kasan.h to include linux/linkage.h
OK... I'll cook up the patch.
pgpDijjojCGIl.pgp
Description: PGP signature
Seems something is giving it indigestion regarding asmlinkage...
CC arch/arm/mm/kasan_init.o
In file included from ./include/linux/kasan.h:15,
from arch/arm/mm/kasan_init.c:11:
./arch/arm/include/asm/kasan.h:26:11: error: expected ';' before 'void'
asmlinkage void kasan_ea
commit d6d51a96c7d63b7450860a3037f2d62388286a52
Author: Linus Walleij
Date: Sun Oct 25 23:52:08 2020 +0100
ARM: 9014/2: Replace string mem* functions for KASan
I'm trying to figure out why this has 3 Tested-By: tags but blows up for fairly
obvious
reasons on ARM.
CC arch/arm/b
On Tue, 03 Nov 2020 07:52:19 +0800, Shawn Guo said:
> It's a driver problem which is being addressed by Dong's patch[1].
>
> Shawn
>
> [1]
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201030153733.30160-1-aisheng.d...@nxp.com/
OK, We'll fix it that way then.
On Mon, 02 Nov 2020 09:15:20 -0800, Randy Dunlap said:
> also
> Reported-by: kernel test robot
>
> However, this driver does not directly use .
Just my luck - I looked at 3 or 4 other things that include of_platform.h
and they all *did* include module.h.
> platform_device.h #includes , which is
commit 77d8f3068c63ee0983f0b5ba3207d3f7cce11be4 (HEAD)
Author: Dong Aisheng
Date: Wed Jul 29 16:00:10 2020 +0800
clk: imx: scu: add two cells binding support
This missed a #include, which results in some nasty errors when
built as a module
CC [M] drivers/clk/imx/clk-scu.o
In file inclu
On Fri, 23 Oct 2020 12:30:06 -0400, Paolo Bonzini said:
> The SPTE format will be common to both the shadow and the TDP MMU.
>
> Extract code that implements the format to a separate module, as a
> first step towards adding the TDP MMU and putting mmu.c on a diet.
>
> Signed-off-by: Paolo Bonzini
On Fri, 25 Sep 2020 10:26:27 -0700, Joe Perches said:
> And the generic individual maintainer apply rate for
> each specific patch is always less than 50%.
>
> For instance the patches that converted the comma uses
> in if/do/while statements to use braces and semicolons
> from a month ago:
> 29 p
On Fri, 21 Aug 2020 18:08:08 -0700, Joe Perches said:
> (forwarding on to kernel-janitors/mentees and kernelnewbies)
>
> Just fyi for anyone that cares:
>
> A janitorial task for someone might be to use Julia's coccinelle
> script below to convert the existing instances of commas that
> separate st
On Wed, 19 Aug 2020 12:42:54 +0200, Greg KH said:
> Look up Spectre and Meltdown for many many examples of what happened and
> what went wrong with chip designs and how we had to fix these things in
> the kernel a few years ago.
And I'm sure that nobody sane thinks we're done with security holes
c
On Wed, 19 Aug 2020 09:00:22 +0200, Sebastian Andrzej Siewior said:
> On 2020-08-18 17:56:49 [-0700], Guenter Roeck wrote:
> > Nice catch. FWIW, there is no obvious reason why this would need to be
> > atomic.
> > The calling code does not set a lock, meaning there can be two (or more)
> > callers
On Mon, 10 Aug 2020 07:10:32 -0700, Guenter Roeck said:
> > ERROR: modpost: "__bad_udelay"
> > [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
> >
>
> I don't think that is new. If anything, it is surprising that builds don't
> fail more
> widely because of it. AFAICS it was
commit 859247d39fb008ea812e8f0c398a58a20c12899e
Author: Ahmed S. Darwish
Date: Mon Jul 20 17:55:14 2020 +0200
seqlock: lockdep assert non-preemptibility on seqcount_t write
breaks an arm allmodconfig build. 'git revert -n' and the build continues on.
CC arch/arm/kernel/asm-offsets
On Mon, 22 Jun 2020 14:10:13 +0900, Masahiro Yamada said:
> > This patch introduces a new build flag 'K=1' which controls whether
> > kerneldoc
> > warnings should be issued, separating them from the compiler warnings that
> > W=
> > controls.
> I do not understand why this change is needed.
>
This patch introduces a new build flag 'K=1' which controls whether kerneldoc
warnings should be issued, separating them from the compiler warnings that W=
controls.
Signed-off-by: Valdis Kletnieks
diff --git a/Makefile b/Makefile
index 29abe44ada91..b1c0f9484a66 100644
--- a/Makefile
+++ b/Make
After this commit, a 'make allmodconfig' fails due to a missing export.
commit 5f2430fb40c74db85764c8a472ecd6849025dd3f
Author: Sibi Sankar
Date: Sat Jun 6 03:03:31 2020 +0530
cpufreq: qcom: Update the bandwidth levels on frequency change
ERROR: modpost: "dev_pm_opp_adjust_voltage"
[drive
On Tue, 26 May 2020 18:11:04 +0200, Peter Zijlstra said:
> The recent commit: 90b5363acd47 ("sched: Clean up scheduler_ipi()")
> got smp_call_function_single_async() subtly wrong. Even though it will
> return -EBUSY when trying to re-use a csd, that condition is not
> atomic and still requires exte
On Thu, 28 May 2020 21:48:18 -0700, Randy Dunlap said:
> > ERROR: modpost: "__aeabi_uldivmod" [kernel/rcu/refperf.ko] undefined!
Gaah. And the reason I didn't spot Paul's post while grepping my linux-kernel
mailbox is because *that* thread had a different undefined reference:
> > > > > > m68k-l
commit 9088b449814f788d24f35a5840b6b2c2a23cd32a
Author: Paul E. McKenney
Date: Mon May 25 17:22:24 2020 -0700
refperf: Provide module parameter to specify number of experiments
changes this line of code (line 389)
- reader_tasks[exp].result_avg = 1000 * process_durations(exp
On Tue, 26 May 2020 21:16:18 -0700, Nathan Chancellor said:
> Additionally, I see a failure with clang due to the use of Bps_to_icc,
> which does a straight division by 1000, which is treated as an integer
> literal, with avg_bw as the dividend, which is a u64.
>
> Below is the "hack" in my tree.
On Wed, 27 May 2020 17:08:57 -0500, Eric W. Biederman said:
> Is there an easy to build-test configuration that includes
> binfmt_elf_fdpic?
I tripped over it with a 'make ARM=arch allmodconfig', but any
config that includes CONFIG_BINFMT_ELF_FDPIC should suffice.
I haven't checked the 'depends'
On Sun, 24 May 2020 15:20:25 -0700, Nathan Chancellor said:
> arm-linux-gnueabi-ld: drivers/power/reset/vexpress-poweroff.o: in function
> `vexpress_reset_probe':
> vexpress-poweroff.c:(.text+0x36c): undefined reference to
> `devm_regmap_init_vexpress_config'
The part I can't figure out is that
Eric: looks like you missed one?
commit b8a61c9e7b4a0fec493d191429e9653d66a79ccc
Author: Eric W. Biederman
Date: Thu May 14 15:17:40 2020 -0500
exec: Generic execfd support
CHECK fs/binfmt_elf_fdpic.c
fs/binfmt_elf_fdpic.c:591:34: error: undefined identifier 'BINPRM_FLAGS_EXECFD'
C
On Tue, 19 May 2020 10:57:53 +0800, Qii Wang said:
> (10 * (sample_cnt + 1)) / clk_src value is a 32-bit, (10
> * (sample_cnt + 1)) will over 32-bit if sample_cnt is 7.
>
> I think 10 and clk_src is too big, maybe I can reduce then with
> be divided all by 1000.
Yes, it's
commit 8a226e2c71: remoteproc: wcss: add support for rpmsg communication
throws a compile error:
CC [M] drivers/remoteproc/qcom_q6v5_wcss.o
drivers/remoteproc/qcom_q6v5_wcss.c: In function 'q6v5_wcss_probe':
drivers/remoteproc/qcom_q6v5_wcss.c:563:2: error: too few arguments to function
'qco
On Mon, 18 May 2020 12:44:49 -0400, Mike Snitzer said:
> Unless I'm missing something it was fixed up with this commit last
> wednesday (13th):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.8&id=81a3a1453ec4e5da081e1395732801a600feb352
That says:
a
On Sat, 16 May 2020 18:05:07 +0530, Subhashini Rao Beerisetty said:
> In the first attempt when I run that test case I landed into âgeneral
> protection fault: [#1] SMP" .. Next I rebooted and ran the same
> test , but now it resulted the âOops: 0002 [#1] SMP".
And the 0002 is telling yo
Am seeing a build error in next-0514. -0420 built OK.
building a 'make allmodconfig' on a RPi4 in 32-bit mode.
MODPOST 7575 modules
ERROR: modpost: "__aeabi_uldivmod" [drivers/md/dm-zoned.ko] undefined!
objdump and 'make drivers/md/dm-zoned-target.s' tells
me that the problem is in function dm
A recent commit started warning for deprecated makefile variables.
Turns out there was an in-tree user, so update it.
Signed-off-by: Valdis Kletnieks
diff --git a/samples/watch_queue/Makefile b/samples/watch_queue/Makefile
index eec00dd0a8df..8511fb6c53d2 100644
--- a/samples/watch_queue/Makefil
So I did a 'make allmodconfig' and then a 'make' on an RPi4 ARM box, and it
decided that CONFIG_SPARSEMEM=n was OK (so an include of linux/mmzone.h doesn't
define some needed values).
The offending code in resource.c is wrapped in a #ifdef CONFIG_DEVICE_PRIVATE,
which throws a whinge during 'make
On Sat, 09 May 2020 12:45:22 +0900, Masahiro Yamada said:
> > LD [U] net/bpfilter/bpfilter_umh
> > /usr/bin/ld: cannot find -lc
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [scripts/Makefile.userprogs:36: net/bpfilter/bpfilter_umh]
> > Error 1
> > make[1]: *** [scripts/Makef
It's not intuitively obvious that bpfilter_umh is a statically linked binary.
Mention the toolchain requirement in the Kconfig help, so people
have an easier time figuring out what's needed.
Signed-off-by: Valdis Kletnieks
diff --git a/net/bpfilter/Kconfig b/net/bpfilter/Kconfig
index fed9290e3b
My kernel build came to a screeching halt with:
CHECK net/bpfilter/bpfilter_kern.c
CC [M] net/bpfilter/bpfilter_kern.o
CC [U] net/bpfilter/main.o
LD [U] net/bpfilter/bpfilter_umh
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make[2]: *** [scripts/Makefile.use
On Wed, 16 Oct 2019 16:33:17 -0400, Sasha Levin said:
> It looks like the reason this wasn't made public along with the exFAT
> spec is that TexFAT is pretty much dead - it's old, there are no users
> we are aware of, and digging it out of it's grave to make it public is
> actually quite the heada
On Wed, 16 Oct 2019 10:31:13 -0400, Sasha Levin said:
> On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Roh�r wrote:
> >Now one month passed, so do you have some information when missing parts
> >of documentation like TexFAT would be released to public?
>
> Sure, I'll see if I can get an approval t
The majority of them were totally backwards. Change the logic
so that if DELAYED_SYNC *isn't* in the config, we actually flush to disk
before flagging the file system as clean.
That leaves two calls in the DELAYED_SYNC case. More detailed
analysis is needed to make sure that's what's really need
On Wed, 02 Oct 2019 20:47:03 +0530, Saiyam Doshi said:
> fs_sync() is wrapper to bdev_sync(). When fs_sync is called with
> non-zero argument, bdev_sync gets called.
>
> Most instances of fs_sync is called with false and very few with
> true. Refactor this and makes direct call to bdev_sync() where
We've seen several incorrect patches for fs_sync() calls in the exfat driver.
Add code to the TODO that explains this isn't just a delete code and refactor,
but that actual analysis of when the filesystem should be flushed to disk
needs to be done.
Signed-off-by: Valdis Kletnieks
---
diff --git
We're missing a depends in the Kconfig, which can lead to trying to
build without the required headers being present..
HOSTCC samples/watch_queue/watch_test
samples/watch_queue/watch_test.c:23:10: fatal error: linux/watch_queue.h: No
such file or directory
23 | #include
| ^~
The copyright notices as I got them said "GPLv2 or later", which I
screwed up when putting in the SPDX tags. Fix them to match the
license I got the code under.
Signed-off-by: Valdis Kletnieks
---
diff --git a/drivers/staging/exfat/Makefile b/drivers/staging/exfat/Makefile
index 84944dfbae28..6
On Thu, 19 Sep 2019 05:31:21 +0900, Ju Hyung Park said:
> We should probably ask Valdis on what happened there.
>
> Even the old exFAT v1.2.24 from Galaxy S7 is using "either version 2
> of the License, or (at your option) any later version".
> You can go check it yourself by searching "G930F" fro
On Tue, 17 Sep 2019 12:02:01 +0900, "Namjae Jeon" said:
> We are excited to see this happening and would like to state that we
> appreciate time and
> effort which people put into upstreaming exfat. Thank you!
The hard part - getting Microsoft to OK merging an exfat driver - is done.
All we need
On Tue, 10 Sep 2019 16:09:35 +0300, Dan Carpenter said:
> On Tue, Sep 10, 2019 at 01:58:35PM +0100, Colin Ian King wrote:
> > On 10/09/2019 13:44, Dan Carpenter wrote:
> > > On Fri, Aug 30, 2019 at 07:38:00PM +0100, Colin Ian King wrote:
> > >> Hi,
> > >>
> > >> Static analysis on exfat with Coveri
On Sun, 08 Sep 2019 17:35:36 -, Valentin Vidic said:
> sbi parameter not used inside the function so remove it.
> Also cleanup unused variables generated by this change.
Tread carefully with this sort of patch - there's still a lot of places in the
code
where we have matching pairs of exfat_f
On Sun, 08 Sep 2019 16:10:14 -, Valentin Vidic said:
> Not used in the exfat-fuse implementation and spec defines
> this position should hold the value for CreateUtcOffset.
In that case, rather than removing it, shouldn't we be *adding*
code to properly set it instead?
pgp9KZVl0RIgO.pgp
Desc
On Sat, 07 Sep 2019 09:14:49 -0700, Theodore Dubois said:
Reading what it actually says rather than what I thought it said.. :)
Events come in two flavors: counting and sampled. A counting event is
one that is used for counting the aggregate number of events that
occu
On Sat, 07 Sep 2019 09:14:49 -0700, Theodore Dubois said:
> If Iâm reading this right, this is a sampling event which overflows 4000
> times a second. But perf then does a poll call which wakes up on this FD with
> POLLIN after 1.637 seconds, instead of 0.00025 seconds.
No, it *takes a sample*
If the list of structures we expect to be const is empty (due to file
permissions,
or the file being empty, etc), we get odd complaints about structures:
[/usr/src/linux-next] scripts/checkpatch.pl -f
drivers/staging/netlogic/platform_net.h
No structs that should be const will be found - file
'
The following commit has been merged into the perf/core branch of tip:
Commit-ID: d9f3b450f206332b7ef3d78b5a85b6c20ad00fd2
Gitweb:
https://git.kernel.org/tip/d9f3b450f206332b7ef3d78b5a85b6c20ad00fd2
Author:Valdis Klētnieks
AuthorDate:Thu, 08 Aug 2019 13:44:02 -04:00
On Mon, 02 Sep 2019 17:25:24 +0200, Greg Kroah-Hartman said:
> I dug up my old discussion with the current vfat maintainer and he said
> something to the affect of, "leave the existing code alone, make a new
> filesystem, I don't want anything to do with exfat".
>
> And I don't blame them, vfat is
On Mon, 02 Sep 2019 08:43:29 +1000, Dave Chinner said:
> I don't know the details of the exfat spec or the code to know what
> the best approach is. I've worked fairly closely with Christoph for
> more than a decade - you need to think about what he says rather
> than /how he says it/ because ther
On Sun, 01 Sep 2019 11:07:21 +1000, Dave Chinner said:
> Totally irrelevant to the issue at hand. You can easily co-ordinate
> out of tree contributions through a github tree, or a tree on
> kernel.org, etc.
Well.. I'm not personally wedded to the staging tree. I'm just interested in
getting a dr
On Sat, 31 Aug 2019 17:24:47 +0300, Andy Shevchenko said:
> Side note:
>
> % git shortlog -n --no-merges -- fs/ext4 | grep '^[^ ]'
>
> kinda faster and groups by name.
Thanks... I rarely do statistical analyses of this sort of thing, so 'git
shortlog' isn't on my list of most-used git subcommands
On Sat, 31 Aug 2019 07:54:10 +1000, Dave Chinner said:
> The correct place for new filesystem review is where all the
> experienced filesystem developers hang out - that's linux-fsdevel,
> not the driver staging tree.
So far everything's been cc'ed to linux-fsdevel, which has been spending
more t
On Fri, 30 Aug 2019 19:15:23 +0100, Colin King said:
> From: Colin Ian King
>
> The goto after a return is never executed, so it is redundant and can
> be removed.
>
> Addresses-Coverity: ("Structurally dead code")
> Signed-off-by: Colin Ian King
Good catch
> - if (dentry < -1) {
> +
On Fri, 30 Aug 2019 23:46:16 -0700, Christoph Hellwig said:
> Since when did Linux kernel submissions become "show me a better patch"
> to reject something obviously bad?
Well, do you even have a *suggestion* for a better idea? Other than "just rip
it out"? Keeping in mind that:
> As I said th
On Fri, 30 Aug 2019 09:45:03 -0700, Christoph Hellwig said:
> On Fri, Aug 30, 2019 at 12:42:39PM -0400, Valdis KlÄtnieks wrote:
> > Concerns have been raised about the exfat driver accidentally mounting
> > fat/vfat file systems. Add an extra configure option to help prevent that.
>
> Just remove
On Fri, 30 Aug 2019 09:52:15 -0700, Randy Dunlap said:
> on x86_64:
> when CONFIG_VFAT_FS is not set/enabled:
>
> ../drivers/staging/exfat/exfat_super.c:46:41: error:
> �CONFIG_FAT_DEFAULT_IOCHARSET� undeclared here (not in a function); did you
> mean �CONFIG_EXFAT_DEFAULT_IOCHARSET�?
Thanks.
Concerns have been raised about the exfat driver accidentally mounting
fat/vfat file systems. Add an extra configure option to help prevent that.
Suggested-by: Christoph Hellwig
Signed-off-by: Valdis Kletnieks
diff --git a/drivers/staging/exfat/Kconfig b/drivers/staging/exfat/Kconfig
index 78b
On Thu, 29 Aug 2019 22:56:31 +0200, Pali Roh�r said:
> I'm not really sure if this exfat implementation is fully suitable for
> mainline linux kernel.
>
> In my opinion, proper way should be to implement exFAT support into
> existing fs/fat/ code instead of replacing whole vfat/msdosfs by this
> n
On Thu, 29 Aug 2019 14:14:35 +0200, Pali Roh�r said:
> On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> > The full specification of the filesystem can be found at:
> > https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
>
> This is not truth. This specificati
On Wed, 28 Aug 2019 14:51:00 -0500, Josh Poimboeuf said:
> > The real question then becomes - should the Makefile sanitize CFLAGS or just
> > append to whatever the user supplied as it does currently? The rest of the
> > tree
> > sanitizes CFLAG, because I don't get deluged in -Wsign-compare warn
On Wed, 28 Aug 2019 10:10:04 -0500, Josh Poimboeuf said:
> But I don't see how those warnings could get enabled: -Wsign-compare
> -Wunused-parameter.
>
> Can you "make clean" and do "make V=1 tools/objtool" to show the actual
> flags?
And that tells me those warnings in fact don't get specificall
On Wed, 28 Aug 2019 08:34:20 -0500, Dinh Nguyen said:
> > Does this DTRT for both old and new U-Boots? My naive reading of
> > this patch
>
> What is a DTRT?
Do The Right Thing, sorry...
> > says on an old U-Boot, we end up attempting to bring it out of
> > reset even though they had already bee
OK. I'm mystified. next-20190806 built fine. -0818 and -0826 died a
glorious death indeed. All 3 were build using the same Fedora Rawhide 9.1.1
compiler (installed on July 30). 'git log -- tools/objtool' comes up empty.
Local hack-around was to remove the -Werror from tools/objtool/Makefile
A
On Mon, 26 Aug 2019 10:42:52 -0500, Dinh Nguyen said:
> The primecell controller on some SoCs, i.e. SoCFPGA, is held in reset by
> default. Until recently, the DMA controller was brought out of reset by the
> bootloader(i.e. U-Boot). But a recent change in U-Boot, the peripherals
> that are not use
On Thu, 08 Aug 2019 22:32:38 +0200, Thomas Gleixner said:
> Care to resend the last few with fixed subject lines, so I don't have to
> clean them up?
Will do that later this evening...
> The right thing to do is to have a cpu_offline callback which clears the
> umwait MSR. That covers also the f
On Thu, 08 Aug 2019 22:04:03 +0200, Thomas Gleixner said:
> I really appreciate your work, but can you please refrain from using file
> names as prefixes?
OK, will do so going forward..
> > We get a warning when building with W=1:
>
> Please avoid 'We/I' in changelogs.
OK..
> > CC arch/
When building withW=1, we get a warning..
CC arch/x86/kernel/cpu/common.o
arch/x86/kernel/cpu/common.c:1952:6: warning: no previous prototype for
'arch_smt_update' [-Wmissing-prototypes]
1952 | void arch_smt_update(void)
| ^~~
Provide the proper #include so the pro
1 - 100 of 147 matches
Mail list logo
