On Wed, 2024-03-27 at 21:11 +, Simon Horman wrote:
>
> I'm seeing some allmodconfig build problems with this applied on top of
> net-next.
> ./include/trace/stages/init.h:30: warning: "TRACE_DEFINE_SYM_FNS" redefined
> ./include/trace/stages/init.h:54: warning: "TRACE_DEFINE_SYM_LIST"
From: Johannes Berg
Use the new __print_sym() in the timer tracing, just to show
how to convert something. This adds ~80 bytes of .text for a
saving of ~1.5K of data in my builds.
Note the format changes from
print fmt: "success=%d dependency=%s", REC->success,
__print
From: Johannes Berg
The way __print_symbolic() works is limited and inefficient
in multiple ways:
- you can only use it with a static list of symbols, but
e.g. the SKB dropreasons are now a dynamic list
- it builds the list in memory _three_ times, so it takes
a lot of memory
From: Johannes Berg
Now that we have drop_reason_lookup(), we can just use it for
drop_monitor as well, rather than exporting the list itself.
Signed-off-by: Johannes Berg
---
include/net/dropreason.h | 4
net/core/drop_monitor.c | 18 +++---
net/core/skbuff.c| 6
From: Johannes Berg
The __print_symbolic() could only ever print the core
drop reasons, since that's the way the infrastructure
works. Now that we have __print_sym() with all the
advantages mentioned in that commit, convert to that
and get all the drop reasons from all subsystems. As
we already
As I mentioned before, it's annoying to see this in dropreason tracing
with trace-cmd:
irq/65-iwlwifi:-401 [000]22.79: kfree_skb:
skbaddr=0x6a89b000 protocol=0 location=ieee80211_rx_handlers_result+0x21a
reason: 0x2
and much nicer to see
irq/65-iwlwifi:-401 [000]
On Wed, 2023-10-04 at 09:22 -0700, Jakub Kicinski wrote:
>
> Potentially naive question - the trace point holds enum skb_drop_reason.
> The user space can get the names from BTF. Can we not teach user space
> to generically look up names of enums in BTF?
I'll note that, unrelated to the
On Thu, 2023-09-21 at 10:51 +0200, Johannes Berg wrote:
>
> - if (!list ||
> - subsys_reason >= list->n_reasons ||
> - !list->reasons[subsys_reason] ||
> - strlen(list->reasons[subsys_reason]) > NET_DM_MAX_REASON_LEN) {
> -
So I was frustrated with not seeing the names of SKB dropreasons
for all but the core reasons, and then while looking into this
all, realized, that the current __print_symbolic() is pretty bad
anyway.
So I came up with a new approach, using a separate declaration
of the symbols, and __print_sym()
From: Johannes Berg
The way __print_symbolic() works is limited and inefficient
in multiple ways:
- you can only use it with a static list of symbols, but
e.g. the SKB dropreasons are now a dynamic list
- it builds the list in memory _three_ times, so it takes
a lot of memory
From: Johannes Berg
Now that we have drop_reason_lookup(), we can just use it for
drop_monitor as well, rather than exporting the list itself.
Signed-off-by: Johannes Berg
---
include/net/dropreason.h | 4
net/core/drop_monitor.c | 18 +++---
net/core/skbuff.c| 6
From: Johannes Berg
Use the new __print_sym() in the timer tracing, just to show
how to convert something. This adds ~80 bytes of .text for a
saving of ~1.5K of data in my builds.
Note the format changes from
print fmt: "success=%d dependency=%s", REC->success,
__print
On Thu, 2023-09-21 at 08:51 +, Johannes Berg wrote:
>
> - Is it correct that we can assume RCU critical section when in
>the lookup function? The SKB code currently does, but I may
>not ever have actually run this code yet.
Well, I could easily answer that myself,
From: Johannes Berg
The __print_symbolic() could only ever print the core
drop reasons, since that's the way the infrastructure
works. Now that we have __print_sym() with all the
advantages mentioned in that commit, convert to that
and get all the drop reasons from all subsystems. As
we already
On Tue, 2023-08-08 at 16:30 +0800, Kuan-Ying Lee wrote:
> Add lx-symbols command to support add specific
> ko module.
I'm not sure how this was supposed to work? It should have updated the
documentation, but more importantly, it shouldn't have broken the
documented usage of this command:
On Mon, 2021-04-19 at 20:44 +, Sasha Levin wrote:
> From: Johannes Berg
>
> [ Upstream commit 04c53de57cb6435738961dace8b1b71d3ecd3c39 ]
>
> With clang-11+, the code is broken due to my kvmalloc() conversion
> (which predated the clang-11 support code) leaving one vmalloc(
On Mon, 2021-04-19 at 11:54 +0200, Gonsolo wrote:
> > Do you use MFP?
>
> I don't think so. I'm running unmodified kernels from Ubuntu PPA and
> don't meddle with WIFI configs.
> How can I find out?
>
> > Could be related to
> >
On Mon, 2021-04-19 at 11:08 +0200, Gon Solo wrote:
>
> [Apr19 10:50] iwlwifi :02:00.0: Queue 10 is active on fifo 1 and stuck
> for 1 ms. SW [40, 93] HW [40, 93] FH TRB=0x0c010a037
> [ +0,001244] iwlwifi :02:00.0: Microcode SW error detected. Restarting
> 0x200.
>
> The rest
On Wed, 2021-04-14 at 12:06 -0300, Ramon Fontes wrote:
> > Advertise 60GHz channels to mac80211.
> Oh.. That was a mistake. Sorry for that.
>
> Anyway, can we indicate 60GHz support even though it is not being
> supported by mac80211 yet?
>
No, that makes no sense. DMG operation is significantly
On Wed, 2021-04-14 at 08:22 +0100, Anton Ivanov wrote:
> On 14/04/2021 06:52, Andrei Vagin wrote:
> > We already have process_vm_readv and process_vm_writev to read and write
> > to a process memory faster than we can do this with ptrace. And now it
> > is time for process_vm_exec that allows
On Mon, 2021-04-12 at 22:06 -0300, Ramon Fontes wrote:
> Advertise 60GHz channels to mac80211.
This is wrong. mac80211 doesn't support 60 GHz operation.
johannes
On Tue, 2021-04-13 at 10:39 +, Grumbach, Emmanuel wrote:
> Hi,
>
> >
> > Hi all,
> >
> > After merging the mac80211-next tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > include/net/cfg80211.h:6643: warning: expecting prototype for
> >
From: Johannes Berg
With clang-11+, the code is broken due to my kvmalloc() conversion
(which predated the clang-11 support code) leaving one vmalloc()
in place. Fix that.
Signed-off-by: Johannes Berg
---
This fixes a clang-11 build issue reported against current
linux-next since the clang-11
On Sat, 2021-04-03 at 15:13 +, Pavel Skripkin wrote:
> genl_family_rcv_msg_attrs_parse() can return NULL
> pointer:
>
> if (!ops->maxattr)
> return NULL;
>
> But this condition doesn't cause an error in
> genl_family_rcv_msg_doit
And I'm almost certain that in fact
unction parameter 'table' description in 'devcd_free_sgtable'
>
> drivers/base/devcoredump.c:225: warning:
> expecting prototype for devcd_read_from_table(). Prototype was for
> devcd_read_from_sgtable() instead
Thanks!
Reviewed-by: Johannes Berg
johannes
On Mon, 2021-03-22 at 15:43 +0100, Geert Uytterhoeven wrote:
> On Mon, Mar 22, 2021 at 3:16 PM Geert Uytterhoeven
> wrote:
> > JFYI, when comparing v5.12-rc4[1] to v5.12-rc3[3], the summaries are:
> > - build errors: +6/-2
>
> > [1]
> >
On Thu, 2021-03-18 at 12:16 +0100, Johannes Berg wrote:
> > Yeah, that's a dilemma. An oft-seen trick is to add more bytes for
> > the future use, e.g. extend to 16 bytes and fill 0 for the remaining.
>
> Yeah, I guess I could stick a reserved[15] there, it's small
Hi Brendan,
> Hey, thanks for doing this! I was looking into this a few weeks ago
> and root caused part of the issue in GCC and in the kernel, but I did
> not have a fix put together.
>
> Anyway, most of the patches make sense to me, but I am not able to
> apply this patch on torvalds/master.
On Thu, 2021-03-18 at 12:11 +0100, Takashi Iwai wrote:
> > That said, we can "fix" this like this, and hope we'll not get this
> > again? And if we do get it again ... well, we keep renaming the structs
> > and add "struct rfkill_event_v3" next time?
>
> Yeah, that's a dilemma. An oft-seen trick
Hi,
> OK, I took a deeper look again, and actually there are two issues in
> systemd-rfkill code:
>
> * It expects 8 bytes returned from read while it reads a struct
> rfkill_event record. If the code is rebuilt with the latest kernel
> headers, it breaks due to the change of rfkill_event.
Hi Takashi,
Oh yay :-(
> we've received a bug report about rfkill change that was introduced in
> 5.11. While the systemd-rfkill expects the same size of both read and
> write, the kernel rfkill write cuts off to the old 8 bytes while read
> gives 9 bytes, hence it leads the error:
>
On Tue, 2021-03-16 at 19:29 +, Abhishek Kumar wrote:
> If BSS instance is not provided in __cfg80211_connect_result then
> a get bss is performed. This can return NULL if the BSS for the
> given SSID is expired due to delayed scheduling of connect result event
> in rdev->event_work. This can
From: Johannes Berg
There's a lot of duplicated code between gcc and clang
implementations, move it over to fs.c to simplify the
code, there's no reason to believe that for small data
like this one would not just implement the simple
convert_to_gcda() function.
Signed-off-by: Johannes Berg
From: Johannes Berg
Use just a single vmalloc() with struct_size() instead of
a separate kmalloc() for the iter struct.
Signed-off-by: Johannes Berg
---
kernel/gcov/fs.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/kernel/gcov/fs.c b/kernel
From: Johannes Berg
Using vmalloc() in gcov is really quite wasteful, many of the
objects allocated are really small (e.g. I've seen 24 bytes.)
Use kvmalloc() to automatically pick the better of kmalloc()
or vmalloc() depending on the size.
Signed-off-by: Johannes Berg
---
kernel/gcov/clang.c
On Fri, 2021-03-12 at 10:55 +0100, Johannes Berg wrote:
> CONFIG_GCOV is fairly useful for ARCH=um (e.g. with kunit, though
> my main use case is a bit different) since it writes coverage data
> directly out like a normal userspace binary. Theoretically, that
> is.
>
> Unfortun
On Fri, 2021-03-12 at 10:55 +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> At least in ARCH=um with CONFIG_GCOV (which writes all the
> coverage data directly out from the userspace binary rather
> than presenting it in debugfs) it's necessary to run all
> the atex
From: Johannes Berg
At least in ARCH=um with CONFIG_GCOV (which writes all the
coverage data directly out from the userspace binary rather
than presenting it in debugfs) it's necessary to run all
the atexit handlers (dtors/fini_array) so that gcov actually
does write out the data.
Add a new
From: Johannes Berg
We already ignore gcno files that are created by the compiler
at build time for -ftest-coverage. However, with ARCH=um it's
possible to select CONFIG_GCOV which actually has the kernel
binary write out gcda files (rather than have them in debugfs
like CONFIG_GCOV_KERNEL does
From: Johannes Berg
It's not always desirable to collect coverage data for the
entire kernel, so split off CONFIG_GCOV_BASE. This option
only enables linking with coverage options, and compiles a
single file (reboot.c) with them as well to force gcov to
be linked into the kernel binary. That way
From: Johannes Berg
At least with current toolchain versions, gcov (as enabled
by CONFIG_GCOV) requires init and exit handlers to run. For
modules, this wasn't done properly, so use the new support
for CONFIG_MODULE_DESTRUCTORS as well as CONFIG_CONSTRUCTORS
to have gcov init and exit called
From: Johannes Berg
The symbol mangle_path conflicts with a gcov symbol which
can break the build of ARCH=um with gcov, and it's also
not very specific and descriptive.
Rename mangle_path() to seq_mangle_path(), and also remove
the export since it's not needed or used by any modules.
Signed
CONFIG_GCOV is fairly useful for ARCH=um (e.g. with kunit, though
my main use case is a bit different) since it writes coverage data
directly out like a normal userspace binary. Theoretically, that
is.
Unfortunately, it's broken in multiple ways today:
1) it doesn't like, due to 'mangle_path'
From: Johannes Berg
With contemporary toolchains, CONFIG_GCOV doesn't work because
gcov now relies on both init and exit handlers, but those are
discarded from the binary. Fix the linker scripts to keep them
instead, so that CONFIG_GCOV can work again.
Note that this does not make it work
On Wed, 2021-03-10 at 16:49 +0800, Yang Li wrote:
> Fix the following coccicheck warning:
> ./arch/um/drivers/hostaudio_kern.c:125:10-14: Unneeded variable: "mask".
> Return "0" on line 131
Word of caution to you:
You've already managed to be in various people's block list due to
sending patches
On Tue, 2021-03-02 at 20:01 +0100, Dmitry Vyukov wrote:
>
> Looking at the reproducer that mostly contains just perf_event_open,
> It may be the old known issue of perf_event_open with some extreme
> parameters bringing down kernel.
> +perf maintainers
> And as far as I remember +Peter had some
On Wed, 2021-02-24 at 10:30 +0800, Hillf Danton wrote:
>
> Add budget for the 80211 softint handler - it's feasible not to try to
> build the giant pyramid in a week.
>
> --- x/net/mac80211/main.c
> +++ y/net/mac80211/main.c
> @@ -224,9 +224,15 @@ static void ieee80211_tasklet_handler(un
> {
>
Hi Jiri,
> I am getting the splat below with Linus' tree as of today (5.11-rc1,
> fe07bfda2fb). I haven't started to look into the code yet, but apparently
> this has been already reported by Heiner here:
>
> https://www.spinics.net/lists/linux-wireless/msg208353.html
>
> so before I
From: Johannes Berg
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware
From: Johannes Berg
If we happen to get multiple messages while IRQS are already
suspended, we still need to handle them, since otherwise the
simulation blocks.
Remove the "prevent nesting" part, time_travel_add_irq_event()
will deal with being called multiple times just fine.
From: Johannes Berg
To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devices, and adds the devices to
the virtual PCI bus in the system.
Since virtio already allows DMA/bus mastering
From: Johannes Berg
Use signals_enabled instead of always jumping through
a function call to read it, there's not much point in
that.
Signed-off-by: Johannes Berg
---
arch/um/include/asm/irqflags.h | 10 +-
arch/um/include/shared/longjmp.h | 14 +++---
arch/um/include/shared
From: Johannes Berg
Add IO memory emulation that uses callbacks for read/write to
the allocated regions. The callbacks can be registered by the
users using logic_iomem_alloc().
To use, an architecture must 'select LOGIC_IOMEM' in Kconfig
and then include into asm/io.h to get
the __raw_read
From: Johannes Berg
The UM virtual PCI devices currently cannot be suspended properly
since the virtio driver already disables VQs well before the PCI
bus's suspend_noirq wants to complete the transition by writing to
PCI config space.
After trying around for a long time with moving the devices
Hi,
Changes since v1:
- fix a memory leak in the PCI code
- fix race in interrupt handling
- fix checks in interrupt handling
- use asm-generic for fb.h and vga.h
- rediff against v5.12-rc1
- export signals_enabled directly
Original description:
In order to simulate some devices and
From: Johannes Berg
This function doesn't exist, remove its declaration.
Signed-off-by: Johannes Berg
---
arch/um/include/shared/kern_util.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/um/include/shared/kern_util.h
b/arch/um/include/shared/kern_util.h
index 2888ec812f6e
From: Johannes Berg
Adjust the kconfig a little to allow disabling NO_IOMEM in UML. To
make an "allyesconfig" with CONFIG_NO_IOMEM=n build, adjust a few
Kconfig things elsewhere and add dummy asm/fb.h and asm/vga.h files.
Signed-off-by: Johannes Berg
---
v2: use asm-generic for fb.h
> @@ -5475,7 +5476,7 @@ noinstr int lock_is_held_type(const struct lockdep_map
> *lock, int read)
> /* avoid false negative lockdep_assert_not_held()
>* and lockdep_assert_held()
>*/
> - return -1;
> + return
On Tue, 2021-02-23 at 16:27 +0100, Johannes Berg wrote:
>
> +void unblock_signals_hard(void)
> +{
> + if (!signals_blocked)
> + return;
> +
> + if (signals_pending && signals_enabled) {
> + /* this is a bit inefficient,
Hi,
> > If anyone has any suggestions on a good example PCI device that already
> > has a driver upstream I'd be interested - I looked for something simple
> > like LED or GPIO but no such thing I could find (that wasn't platform
> > dependent in some way). So far I've only implemented a virtual
On Tue, 2021-02-23 at 16:27 +0100, Johannes Berg wrote:
> In order to simulate some devices and write tests completely
> independent of real PCI devices, we continued the development
> of time-travel and related bits, and are adding PCI support
> here now.
>
>
Hi,
> Can't you just use the asm-generic versions instead?
Hmm, yes, for fb.h and vga.h that should work, since they should never
be used. For vga.h it would be wrong since it assumes the VGA memory is
mapped into the CPU memory, but since it should never run it would still
address the
From: Johannes Berg
To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devices, and adds the devices to
the virtual PCI bus in the system.
Since virtio already allows DMA/bus mastering
From: Johannes Berg
This function doesn't exist, remove its declaration.
Signed-off-by: Johannes Berg
---
arch/um/include/shared/kern_util.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/um/include/shared/kern_util.h
b/arch/um/include/shared/kern_util.h
index 2888ec812f6e
From: Johannes Berg
The UM virtual PCI devices currently cannot be suspended properly
since the virtio driver already disables VQs well before the PCI
bus's suspend_noirq wants to complete the transition by writing to
PCI config space.
After trying around for a long time with moving the devices
From: Johannes Berg
Add IO memory emulation that uses callbacks for read/write to
the allocated regions. The callbacks can be registered by the
users using logic_iomem_alloc().
To use, an architecture must 'select LOGIC_IOMEM' in Kconfig
and then include into asm/io.h to get
the __raw_read
From: Johannes Berg
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware
From: Johannes Berg
If we happen to get multiple messages while IRQS are already
suspended, we still need to handle them, since otherwise the
simulation blocks.
Remove the "prevent nesting" part, time_travel_add_irq_event()
will deal with being called multiple times just fine.
From: Johannes Berg
Adjust the kconfig a little to allow disabling NO_IOMEM in UML. To
make an "allyesconfig" with CONFIG_NO_IOMEM=n build, adjust a few
Kconfig things elsewhere and add dummy asm/fb.h and asm/vga.h files.
Signed-off-by: Johannes Berg
---
arch/um/Kconfig
Hi,
In order to simulate some devices and write tests completely
independent of real PCI devices, we continued the development
of time-travel and related bits, and are adding PCI support
here now.
The way it works is that it communicates with the outside (of
UML) with virtio, which we previously
On Thu, 2020-12-17 at 09:31 +0100, Jan Kiszka wrote:
> On 17.12.20 09:17, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > If we store the relative path, the user might later cd to a
> > different directory, and that would break the automatic symbol
> > res
On Mon, 2021-02-22 at 19:51 +0100, Marc Kleine-Budde wrote:
> On 22.02.2021 17:30:59, Johannes Berg wrote:
> > On Mon, 2021-02-22 at 16:12 +0100, Oleksij Rempel wrote:
> > > This code is trying to clone the skb with optional skb->sk. But this
> > > will fail to clon
On Mon, 2021-02-22 at 16:12 +0100, Oleksij Rempel wrote:
> This code is trying to clone the skb with optional skb->sk. But this
> will fail to clone the skb if socket was closed just after the skb was
> pushed into the networking stack.
Which IMHO is completely fine. If we then still clone the
On Fri, 2021-02-19 at 05:15 +, Srinivasan Raju wrote:
> Hi,
>
> Please find a few responses to the comments , We will fix rest of the
> comments and submit v14 of the patch.
>
> > Also, you *really* need some validation here, rather than blindly
> > trusting that the file is well-formed,
On Thu, 2021-02-18 at 18:31 +0100, Sebastian Andrzej Siewior wrote:
> The recent addition of in_serving_softirq() to kconv.h results in
You typo'ed "kconv.h" pretty consistently ;-)
But yes, that makes sense.
Acked-by: Johannes Berg
johannes
On Mon, 2021-02-15 at 17:04 +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2021 at 02:12:30PM +0100, Johannes Berg wrote:
> > On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
> > > I think something like so will work, but please double check.
> >
>
On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
>
> I think something like so will work, but please double check.
Yeah, that looks better.
> +++ b/include/linux/lockdep.h
> @@ -294,11 +294,15 @@ extern void lock_unpin_lock(struct lockdep_map *lock,
> struct pin_cookie);
>
> #define
Hi,
Thanks for your patience, and thanks for sticking around!
I'm sorry I haven't reviewed this again in a long time, but I was able
to today.
> +PUREILIFI USB DRIVER
Did you mistype "PURELIFI" here, or was that intentional?
> +PUREILIFI USB DRIVER
> +M: Srinivasan Raju
Probably would be
On Fri, 2021-02-12 at 09:42 +0100, Johannes Berg wrote:
> On Tue, 2020-12-15 at 22:53 +0530, Youghandhar Chintala wrote:
> > The right fix would be to pull the entire data path into the host
> > +++ b/net/mac80211/ieee80211_i.h
> > @@ -748,6 +748,8 @@ struct ieee80211_i
On Tue, 2020-12-15 at 22:53 +0530, Youghandhar Chintala wrote:
> The right fix would be to pull the entire data path into the host
> +++ b/net/mac80211/ieee80211_i.h
> @@ -748,6 +748,8 @@ struct ieee80211_if_mesh {
> * back to wireless media and to the local net stack.
> *
On Fri, 2021-02-05 at 13:51 -0800, Abhishek Kumar wrote:
> Since using DELBA frame to APs to re-establish BA session has a
> dependency on APs and also some APs may not honour the DELBA frame.
That's completely out of spec ... Can you say which AP this was?
You could also try sending a BAR that
On Tue, 2020-12-15 at 23:00 +0530, Youghandhar Chintala wrote:
>
> * @WIPHY_FLAG_SUPPORTS_EXT_KEK_KCK: The device supports bigger kek and kck
> keys
> + * @WIPHY_FLAG_STA_DISCONNECT_ON_HW_RESTART: The device needs a trigger to
> + * disconnect STA after target hardware restart. This flag
On Mon, 2021-02-08 at 18:00 +, Sasha Levin wrote:
> From: Johannes Berg
>
> [ Upstream commit 55b6f763d8bcb5546997933105d66d3e6b080e6a ]
>
> On ARCH=um, loading a module doesn't result in its constructors getting
> called, which breaks module gcov since the debug
On Wed, 2021-02-03 at 15:00 +0800, samirweng1979 wrote:
> From: wengjianfeng
>
> change 'iff' to 'if'.
>
> Signed-off-by: wengjianfeng
> ---
> net/wireless/chan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index
On Mon, 2021-02-01 at 14:37 +0200, Mike Rapoport wrote:
> On Mon, Feb 01, 2021 at 01:17:13AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:b01f250d Add linux-next specific files for 20210129
> > git tree: linux-next
> > console output:
On Sun, 2021-01-31 at 21:26 -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:bec4c296 Merge tag 'ecryptfs-5.11-rc6-setxattr-fix' of git..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11991778d0
> kernel
On Thu, 2021-01-28 at 19:56 +0800, samirweng1979 wrote:
> From: wengjianfeng
>
> If the length of hide ssid is zero in scan, don't pass
> it to driver, which doesn't make any sense.
Err, please check again how scanning works. This is quite obviously
intentional.
johannes
the remaining
> > inconsistency.
>
> My problem with Krzysztof's patch[1] is that it adds a new Kconfig
> option for ath9k, is that really necessary? Like Arnd said, we should
> fix drivers to use CONFIG_MAC80211_LEDS instead of having driver
> specific options.
>
> So I would prefer take this Arnd's patch instead and queue it for v5.11.
> But as it modifies mac80211 I'll need an ack from Johannes, what do you
> think?
Sure, that seems fine.
Acked-by: Johannes Berg
johannes
: sendfile() to a pipe.
Fix this by using iter_file_splice_write for the splice_write
method of pipes, as suggested by Christoph.
Cc: sta...@vger.kernel.org
Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
Suggested-by: Christoph Hellwig
Tested-by: Johan
On Mon, 2021-01-25 at 01:52 -0800, syzbot wrote:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at net/wireless/core.c:1336
> cfg80211_register_netdevice+0x235/0x330 net/wireless/core.c:1336
>
Yes, umm. I accidentally *copied* that line a few lines further down
rather than
On Thu, 2021-01-21 at 07:05 +0100, Willy Tarreau wrote:
> I think that most users of splice() on sockets got used to falling back
> to recv/send on splice failure due to various cases not being supported
> historically (UNIX family sockets immediately come to my mind but I seem
> to remember
On Wed, 2021-01-20 at 18:04 +0100, Peter Oberparleiter wrote:
>
> > Tested with a kernel configured with CONFIG_GCOV_KERNEL, without
> > the patch nothing ever appears in /sys/kernel/debug/gcov/ (apart
> > from the reset file), and with it we get the files and they work.
>
> Just to be sure:
From: Johannes Berg
On ARCH=um, loading a module doesn't result in its constructors
getting called, which breaks module gcov since the debugfs files
are never registered. On the other hand, in-kernel constructors
have already been called by the dynamic linker, so we can't call
them again.
Get
On Wed, 2021-01-20 at 17:07 +0100, Peter Oberparleiter wrote:
> Do you expect other users for these new config symbols?
Probably not.
> If not it seems
> to me that the goal of enabling module constructors for UML could also
> be achieved without introducing new config symbols.
Yeah, true.
>
From: Johannes Berg
On ARCH=um, loading a module doesn't result in its constructors
getting called, which breaks module gcov since the debugfs files
are never registered. On the other hand, in-kernel constructors
have already been called by the dynamic linker, so we can't call
them again.
Get
On Mon, 2021-01-18 at 09:53 +0100, Christoph Hellwig wrote:
> On Sat, Jan 16, 2021 at 05:46:33PM +0100, Johannes Berg wrote:
> > > For my case, I attempted to instead implement splice_write and
> > > splice_read in tty_fops; I managed to get splice_write working calling
On Sat, 2021-01-16 at 20:35 +1300, Oliver Giles wrote:
> Commit 36e2c7421f02 (fs: don't allow splice read/write without
> explicit ops) broke my userspace application which talks to an SSL VPN
> by splice()ing between "openssl s_client" and "pppd". The latter
> operates over a pty, and since that
On Thu, 2021-01-14 at 10:34 -0800, Jakub Kicinski wrote:
> On Thu, 14 Jan 2021 10:59:08 -0500 Jon Maloy wrote:
> > On 1/14/21 3:04 AM, Mauro Carvalho Chehab wrote:
> > > A function has a different name between their prototype
> > > and its kernel-doc markup:
> > >
> > > ../net/tipc/link.c:2551:
From: Johannes Berg
If kmemleak is enabled, it uses a kmem cache for its own objects.
These objects are used to hold information kmemleak uses, including
a stack trace. If slub_debug is also turned on, each of them has
*another* stack trace, so the overhead adds up, and on my tests (on
ARCH=um
On Wed, 2021-01-13 at 17:59 +0100, Vlastimil Babka wrote:
> On 1/13/21 5:09 PM, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > If kmemleak is enabled, it uses a kmem cache for its own objects.
> > These objects are used to hold information kmemleak uses,
1 - 100 of 2311 matches
Mail list logo
