From: 'Dominique Martinet'
> Sent: 10 December 2020 12:22
>
> Vincenzo Frascino wrote on Thu, Dec 10, 2020:
> > On 12/9/20 10:03 PM, David Laight wrote:
> >> Why bother with awk?
>
> I wanted to keep the patch minimal, I'm not opposed to rewriting
From: Xie He
> Sent: 10 December 2020 10:17
>
> On Thu, Dec 10, 2020 at 1:14 AM David Laight wrote:
> >
> > > To me, LLC1 and LLC2 are to Ethernet what UDP and TCP are to IP
> > > networks. I think we can use LLC1 and LLC2 wherever UDP and TCP can be
> > &g
From: Joe Perches
> Sent: 10 December 2020 05:26
>
> On Wed, 2020-12-09 at 19:13 +0100, Thomas Gleixner wrote:
> > Joe,
>
> Hi Thomas.
>
> > the below made it through my filters for some reason so I actually
> > looked and immediately wondered why checkpatch.pl did not identify this
> > as pure
From: Xie He
> Sent: 09 December 2020 22:54
>
> On Wed, Dec 9, 2020 at 1:21 PM David Laight wrote:
> >
> > I always wondered about running Class 2 transport directly over LLC2
> > (rather than Class 4 over LLC1).
> > But the only LLC2 user was netbios - and mic
From: Dominique Martinet
> Sent: 09 December 2020 17:43
>
> I've suggested either just reverting this (I'll keep my local
> workaround) or going through /bin/sh which is always safe like the
> following patch -- leaving this to maintainers.
>
> Thanks!
> -
> From d53ef3b4c55aa2ea5f9ae887b3e1a
From: Xie He
> Sent: 09 December 2020 03:34
>
> According to the X.25 documentation, there was a plan to implement
> X.25-over-802.2-LLC. It never finished but left various code stubs in the
> X.25 code. At this time it is unlikely that it would ever finish so it
> may be better to remove those co
From: Pavel Begunkov
> Sent: 09 December 2020 02:20
>
> The block layer spends quite a while in blkdev_direct_IO() to copy and
> initialise bio's bvec. However, if we've already got a bvec in the input
> iterator it might be reused in some cases, i.e. when new
> ITER_BVEC_FLAG_FIXED flag is set. S
From: Waiman Long
> Sent: 08 December 2020 15:34
>
> On 12/8/20 4:12 AM, David Laight wrote:
> > From: Waiman Long
> >> Sent: 07 December 2020 19:02
> > ...
> >>> How much more difficult would it be to also add a timeout option?
> >>> I looked
From: Peter Zijlstra
> Sent: 08 December 2020 12:32
>
> On Tue, Dec 08, 2020 at 09:12:36AM +0000, David Laight wrote:
> > From: Waiman Long
> > > Sent: 07 December 2020 19:02
> > ...
> > > > How much more difficult would it be to also add a timeout opt
From: Waiman Long
> Sent: 07 December 2020 19:02
...
> > How much more difficult would it be to also add a timeout option?
> > I looked at adding one to the mutex code - and fell into a big pile
> > of replicated code.
> >
> > ISTM that one the initial locked exchange (and spin) fails a few
> > ext
From: Waiman Long
> Sent: 07 December 2020 15:34
>
> On 12/7/20 4:02 AM, Peter Zijlstra wrote:
> > On Thu, Dec 03, 2020 at 08:59:13PM -0500, Waiman Long wrote:
> >> On 12/3/20 3:11 PM, Eric W. Biederman wrote:
> >>> +static inline int __down_read_interruptible(struct rw_semaphore *sem)
> >>> +{
>
From: John Ogness
> Sent: 07 December 2020 10:04
>
> On 2020-12-07, Peter Zijlstra wrote:
> >> Yes, and it is read-only access. Perhaps atomic64_t is the wrong thing
> >> to use here. We could use a seqcount_latch and a shadow variable so that
> >> if a writer has been preempted, we can use the p
From: Steven Rostedt
> Sent: 07 December 2020 15:10
>
> On Sat, 05 Dec 2020 15:04:31 -0800
> James Bottomley wrote:
>
> > Well, I think the pattern
> >
> > if (strstarts(option, )) {
> >...
> >option += strlen();
> >
> > is a bad one because one day may get updated but not > string>.
From: Topi Miettinen
> Sent: 04 December 2020 10:58
>
> On 4.12.2020 1.15, David Laight wrote:
> > From: Mike Rapoport
> >> Sent: 03 December 2020 06:58
> >>
> >> On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
> >>> On 1.12.20
From: Mike Rapoport
> Sent: 03 December 2020 06:58
>
> On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
> > On 1.12.2020 23.45, Topi Miettinen wrote:
> > > Memory mappings inside kernel allocated with vmalloc() are in
> > > predictable order and packed tightly toward the low address
From: Peter Zijlstra
> Sent: 30 November 2020 11:27
>
> Just like 64bit pte_t, have a low/high split in pmd_t.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/sh/include/asm/pgtable-3level.h | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> --- a/arch/sh/include/a
> And actually, the same applies on BE, but the other way around. So we
> should mark __xl as an output register as well, as __xl will assume
> the right value depending on the endianness.
Why not use "+r" to indicate than an 'output' parameter is also
used as an input.
Rather cleaner than specif
From: Andrew Cooper
> Sent: 26 November 2020 23:52
>
> On 26/11/2020 19:15, Andy Lutomirski wrote:
> > On Thu, Nov 26, 2020 at 11:07 AM Lukas Bulwahn
> > wrote:
> >> On Thu, Nov 26, 2020 at 6:16 PM Andrew Cooper
> >> wrote:
> >>> On 26/11/2020 11:54, Lukas Bulwahn wrote:
> Commit 1e5de182
From: Jiri Kosina
> Sent: 25 November 2020 13:04
> On Fri, 20 Nov 2020, Gustavo A. R. Silva wrote:
>
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a goto statement instead of letting the code fall
> > through to the next case.
> >
> > Link:
From: Artem Labazov
> Sent: 24 November 2020 19:48
>
> The table for Unicode upcase conversion requires an order-5 allocation,
> which may fail on a highly-fragmented system:
ISTM that is the wrong way to do the case conversion.
It is also why having to do it is bloody stupid.
David
-
R
From: David Laight
> Sent: 20 November 2020 15:39
>
> From: Thomas Zimmermann
> > Sent: 20 November 2020 13:42
> ...
> > I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> > Some candidates are
> >
> >8e3784dfef8a ("d
From: Russell King
> Sent: 24 November 2020 15:17
...
> That said, _if_ the PHY has a way to read the resolved state rather
> than reading the advertisement registers, that is what should be
> used (as I said previously) rather than trying to decode the
> advertisement registers ourselves. That is
From: Ard Biesheuvel
> Sent: 24 November 2020 15:02
> On Tue, 24 Nov 2020 at 15:58, David Laight wrote:
> >
> > From: Ard Biesheuvel
> > > Sent: 24 November 2020 14:24
> > >
> > > On Tue, 24 Nov 2020 at 15:22, David Laight
> > > wrote:
&g
From: Ard Biesheuvel
> Sent: 24 November 2020 14:24
>
> On Tue, 24 Nov 2020 at 15:22, David Laight wrote:
> >
> > I've just updated to the head of Linus's tree (5.10-rc5) and got the
> > following
> > 'splat' during shutdown.
> &g
From: Ard Biesheuvel
> Sent: 24 November 2020 14:24
>
> On Tue, 24 Nov 2020 at 15:22, David Laight wrote:
> >
> > I've just updated to the head of Linus's tree (5.10-rc5) and got the
> > following
> > 'splat' during shutdown.
> >
>
I've just updated to the head of Linus's tree (5.10-rc5) and got the following
'splat' during shutdown.
Userspace is Ubuntu 20.04.
rc4 rebooted fine.
I'll try to bisect - but it isn't quick.
David
[ 49.612436] kernel BUG at mm/slub.c:304!
[ 49.616407] invalid opcode: [#1] SMP
From: Arnd Bergmann
> Sent: 24 November 2020 11:57
>
> On Tue, Nov 24, 2020 at 12:51 PM Christoph Hellwig wrote:
> > On Tue, Nov 24, 2020 at 12:08:40PM +0100, Jann Horn wrote:
> > > > Since commit acaab7335bd6 ("lib/zlib: remove outdated and incorrect
> > > > pre-increment optimization"), get_una
From: Martin Schiller
> Sent: 24 November 2020 09:36
>
> 1. DTE interface changes immediately to LAPB_STATE_1 and start sending
>SABM(E).
>
> 2. DCE interface sends N2-times DM and changes to LAPB_STATE_1
>afterwards if there is no response in the meantime.
Seems reasonable.
It is 35 yea
From: Chao Yu
> Sent: 24 November 2020 03:12
>
> On 2020/11/24 1:05, David Laight wrote:
> > From: Sahitya Tummala
> >> Sent: 23 November 2020 05:29
> >>
> >> Use rwsem to ensure serialization of the callers and to avoid
> >> starvation of high
From: Sahitya Tummala
> Sent: 23 November 2020 05:29
>
> Use rwsem to ensure serialization of the callers and to avoid
> starvation of high priority tasks, when the system is under
> heavy IO workload.
I can't see any read lock requests.
So why the change?
David
-
Registered Address La
From: David Howells
> Sent: 21 November 2020 14:14
>
> Switch to using a table of operations. In a future patch the individual
> methods will be split up by type. For the moment, however, the ops tables
> just jump directly to the old functions - which are now static. Inline
> wrappers are prov
et, and branch
> _anywhere_, and the attack vectors can poison the BTB (branch target
> buffer), so our mitigation for that is that every single indirect
> branch isn't predicted at all (using "retpoline").
>
> So a conditional branch takes zero cycles when predic
From: David Howells
> Sent: 22 November 2020 13:33
>
> Linus Torvalds wrote:
>
> > - I worry a bit about the indirect call overhead and spectre v2.
>
> I don't know enough about how spectre v2 works to say if this would be a
> problem for the ops-table approach, but wouldn't it also affect the
From: Davidlohr Bueso
> Sent: 20 November 2020 21:38
>
> On Fri, 20 Nov 2020, David Laight wrote:
> >I got massive performance improvements from changing a driver
> >we have to use mutex instead of the old semaphores (the driver
> >was written a long time ago).
> >
From: Johan Hovold
> Sent: 20 November 2020 12:50
>
> On Fri, Nov 20, 2020 at 07:25:03PM +0800, tiantao (H) wrote:
> > 在 2020/11/20 16:23, Johan Hovold 写道:
> > > On Thu, Nov 19, 2020 at 05:01:29PM +0800, Tian Tao wrote:
> > >> The code has been in a irq-disabled context since it is hard IRQ. There
From: Waiman Long
> Sent: 20 November 2020 17:04
>
> On 11/20/20 8:11 AM, David Laight wrote:
> > From: Waiman Long
> >> Sent: 19 November 2020 18:40
> > ...
> >> My own testing also show not too much performance difference when
> >> removing re
From: Thomas Zimmermann
> Sent: 20 November 2020 13:42
...
> I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> Some candidates are
>
>8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
> plane's color format")
Ok, that one fixes the screen colours (etc).
So
From: Andrew Morton
> Sent: 20 November 2020 01:36
...
> Could you please send along a reworked [0/n] cover letter? Explain in
> your own words, without requiring that readers go off and read web
> pages
>
> - What problem the patchset solves
> - How it solves it
> - The value of the patchset (to
From: Pavel Begunkov
> Sent: 19 November 2020 23:25
>
> The block layer spends quite a while in iov_iter_npages(), but for the
> bvec case the number of pages is already known and stored in
> iter->nr_segs, so it can be returned immediately as an optimisation
>
> Perf for an io_uring benchmark wit
From: Waiman Long
> Sent: 19 November 2020 18:40
...
> My own testing also show not too much performance difference when
> removing reader spinning except in the lightly loaded cases.
I'm confused.
I got massive performance improvements from changing a driver
we have to use mutex instead of the o
From: Thomas Zimmermann
> Sent: 20 November 2020 12:30
>
> Am 20.11.20 um 12:45 schrieb David Laight:
> > From: Thomas Zimmermann
> >> Sent: 20 November 2020 11:27
> > ...
> >>>> You can use drm-tip for testing, where many of the DRM patches
From: Thomas Zimmermann
> Sent: 20 November 2020 11:27
...
> >> You can use drm-tip for testing, where many of the DRM patches go through.
> >>
> >> https://cgit.freedesktop.org/drm/drm-tip/
> >>
> >> It's fairly up-to-date.
> >
> > Any idea of tags either side of the 5.10 merge?
>
> The final
From: Thomas Zimmermann
> Sent: 20 November 2020 10:14
...
> > Is there any way to bisect through the parts of the
> > drm merge patch into v5.10-rc1 ?
> >
> > That ought to be quicker (and less error prone) than
> > the bisect builds I was doing.
> >
> > Note that the stack 'splat' is due to a lat
> Hi David
>
> Am 18.11.20 um 23:01 schrieb David Laight:
...
> Did you try Daniel's suggestion of testing with the direct parent commit?
(I was on holiday yesterday and didn't want to spend a sunny
afternoon doing bisects.)
I've just done that and it is bad.
Is ther
> > The Windows code is not completely loaded at initialization time. It
> > also has dynamic libraries loaded later. yes, wine knows the memory
> > regions, but there is no guarantee there is a small number of segments
> > or that the full picture is known at any given moment.
>
> Yes, I didn't
From: Segher Boessenkool
> Sent: 19 November 2020 16:35
...
> I just meant "valid C language code as defined by the standards". Many
> people want all UB to just go away, while that is *impossible* to do for
> many compilers: for example where different architectures or different
> ABIs have contr
From: Dave Airlie
> Sent: 19 November 2020 01:16
>
> On Thu, 19 Nov 2020 at 08:25, Dave Airlie wrote:
> >
> > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter wrote:
> > >
> > > On Wed, Nov 18, 2020 at 11:01 PM David Laight
> > > wrote:
> >
From: Thomas Zimmermann
> Sent: 18 November 2020 19:37
>
> Hi
>
> Am 18.11.20 um 19:10 schrieb Linus Torvalds:
> > On Wed, Nov 18, 2020 at 4:12 AM David Laight
> > wrote:
> >>
> >> I've got the 'splat' below during boot.
> >
From: Linus Torvalds
> Sent: 18 November 2020 18:11
>
> On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote:
> >
> > I've got the 'splat' below during boot.
> > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics.
> > User space is Ubun
From: Mathieu Desnoyers
> Sent: 18 November 2020 16:01
...
> > If it is already done elsewhere in the kernel, then I will call this
> > precedence, and keep the original version.
>
> It works for me. Bonus points if you can document in a comment that this
> trick depends on the cdecl calling conve
From: Arnd Bergmann
> Sent: 18 November 2020 15:38
>
> On Wed, Nov 18, 2020 at 4:10 PM Willem de Bruijn
> wrote:
> > On Wed, Nov 18, 2020 at 10:00 AM Matthew Wilcox wrote:
> > >
> > > On Wed, Nov 18, 2020 at 09:46:15AM -0500, Willem de Bruijn wrote:
> > > > -static inline struct timespec64 ep_se
From: Alexandre Chartre
> Sent: 18 November 2020 10:30
...
> Correct, this RFC is not changing the overhead. However, it is a step forward
> for being able to execute some selected syscalls or interrupt handlers without
> switching to the kernel page-table. The next step would be to identify and ad
From: Linus Torvalds
> Sent: 16 November 2020 00:59
>
> All looks good, and nothing makes me go "uhhuh, 5.10 looks iffy". So
> go test, let's get this all solid and calmed down, and this will
> hopefully be one of those regular boring releases even if it's
> certainly not been on the smaller side.
From: Alexandre Chartre
> Sent: 18 November 2020 07:42
>
>
> On 11/17/20 10:26 PM, Borislav Petkov wrote:
> > On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
> >> Some benchmarks are available, in particular from phoronix:
> >
> > What I was expecting was benchmarks *you* have
From: Kuniyuki Iwashima
> Sent: 17 November 2020 09:40
>
> The SO_REUSEPORT option allows sockets to listen on the same port and to
> accept connections evenly. However, there is a defect in the current
> implementation. When a SYN packet is received, the connection is tied to a
> listening socket
From: Alexandre Chartre
> Sent: 16 November 2020 18:10
>
> On 11/16/20 5:57 PM, Andy Lutomirski wrote:
> > On Mon, Nov 16, 2020 at 6:47 AM Alexandre Chartre
> > wrote:
> >>
> >> When entering the kernel from userland, use the per-task PTI stack
> >> instead of the per-cpu trampoline stack. Like t
From: Willem de Bruijn
> Sent: 16 November 2020 17:01
>
> On Mon, Nov 16, 2020 at 11:19 AM Matthew Wilcox wrote:
> >
> > On Mon, Nov 16, 2020 at 11:10:01AM -0500, Willem de Bruijn wrote:
> > > diff --git a/include/uapi/linux/eventpoll.h
> > > b/include/uapi/linux/eventpoll.h
> > > index 8a3432d0
From: Martin Schiller
> Sent: 16 November 2020 13:55
> Extended struct x25_neigh and x25_subscrip_struct to configure following
> params through SIOCX25SSUBSCRIP:
> o mode (DTE/DCE)
> o number of channels
> o facilities (packet size, window size)
> o timer T20
>
> Based on this configurati
From: Corentin Labbe
> Sent: 16 November 2020 13:54
>
> The optimized cipher function need length multiple of 4 bytes.
> But it get sometimes odd length.
> This is due to SG data could be stored with an offset.
>
> So the fix is to check also if the offset is aligned with 4 bytes.
> Fixes: 6298e9
From: Linus Torvalds
> Sent: 14 November 2020 18:02
>
> On Sat, Nov 14, 2020 at 7:53 AM David Laight wrote:
> >
> > The change e419b4cc585680940bc42f8ca8a071d6023fb1bb added
> > asm code for load_unaligned_zeropad().
> >
> > However it doesn't look ri
The change e419b4cc585680940bc42f8ca8a071d6023fb1bb added
asm code for load_unaligned_zeropad().
However it doesn't look right for 64bit.
It masks the address with ~3 not ~7 so the second
access could still cross a page boundary and fault.
David
-
Registered Address Lakeside, Bramley Roa
From: Yicong Yang
> Sent: 13 November 2020 09:56
> The attr->set() receive a value of u64, but simple_strtoll() is used
> for doing the conversion. It will lead to the error cast if user inputs
> a negative value.
>
> Use kstrtoull() instead of simple_strtoll() to convert a string got
> from the u
From: xiakaixu1...@gmail.com
> Sent: 13 November 2020 09:21
> From: Kaixu Xia
>
> The value of the variable status must be one of the 0, -EIO and -EILSEQ, so
> the switch cases -ENODATA and default are unreached. Remove them.
>
> Reported-by: Tosk Robot
> Signed-off-by: Kaixu Xia
> ---
> dri
From: Nathan Chancellor
> Sent: 12 November 2020 21:49
>
> On Thu, Nov 12, 2020 at 10:21:35PM +0100, Christian Lamparter wrote:
> > Hello,
> >
> > On 12/11/2020 21:07, Nathan Chancellor wrote:
> > > Clang warns:
> > >
> > > drivers/crypto/amcc/crypto4xx_core.c:921:60: warning: operator '?:' has
>
From: Petr Mladek
> Sent: 12 November 2020 16:18
>
> Adding other vsprintf maintainers and reviewes into CC.
>
> On Thu 2020-11-12 11:17:59, Richard Fitzgerald wrote:
> > Number conversion in vsscanf converts a whole string of digits and then
> > extracts the field width part from the converted v
From: Rob Landley
> Sent: 12 November 2020 12:46
>
> On 11/12/20 1:11 AM, kernel test robot wrote:
> >
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
>
> Blah, switched from strlcpy to sprintf due to the lack of spaces and didn't
> adjust the size.
>
> (And yes, t
Due to a coding fubar (in my own driver) I managed to sleep
a process that held a spinlock.
Unluckily all 8 cpus ended up trying to acquire the spinlock
before the process woke.
As might be expected the system froze.
I'd got a serial console connected so could see the kernel messages.
It was almos
From: Steven Rostedt
> Sent: 12 November 2020 00:33
>
> Inspecting the data structures of the function graph tracer, I found that
> the overrun value is unsigned long, which is 8 bytes on a 64 bit machine,
> and not only that, the depth is an int (4 bytes). The overrun can be simply
> an unsigned
From: Dave Martin
> Sent: 11 November 2020 17:58
>
> On Wed, Nov 11, 2020 at 05:39:22PM +, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Nov 11, 2020 at 03:45:23PM +, Andr� Przywara escreveu:
> > > On 11/11/2020 15:35, Arnaldo Carvalho de Melo wrote:
> > >
> > > Hi Arnaldo,
> > >
> > > tha
From: Yang Mingzhe
> Sent: 10 November 2020 14:21
>
> The bottom of the stack is where the first item was added to the stack,
> usually at the zero offset. Actually, the thread_info structure at the
> end of the stack.
Nope, most stacks 'grow down'.
So the first item pushed is at address 8k (for
From: Chao Yu
> Sent: 10 November 2020 06:28
...
> Actually, I think the both results are the same, inode chksum doesn't match
> inode
> metadata, like current case that cluster chksum doesn't match cluster data, it
> doesn't matter how it becomes mismatched.
>
> And also, in those inode corrupte
> -Original Message-
> From: Peter Zijlstra
> Sent: 09 November 2020 12:13
> To: David Laight
> Cc: Steven Rostedt ; Jesper Dangaard Brouer
> ;
> mi...@kernel.org; t...@linutronix.de; linux-kernel@vger.kernel.org;
> kan.li...@linux.intel.com;
> a...@kerne
From: Andy Shevchenko
> Sent: 09 November 2020 10:10
>
> On Mon, Nov 9, 2020 at 11:57 AM Jiri Slaby wrote:
> > On 06. 11. 20, 17:06, Andy Shevchenko wrote:
> > > On Fri, Nov 6, 2020 at 5:35 PM David Laight
> > > wrote:
> > >> From: Andy Sh
From: Andrew Lunn
> Sent: 07 November 2020 22:33
>
> On Sat, Nov 07, 2020 at 09:39:42AM -0800, Joe Perches wrote:
> > On Sat, 2020-11-07 at 20:54 +0800, Alex Shi wrote:
> > > 在 2020/11/7 上午12:39, Florian Fainelli 写道:
> > > > > It is good to remember that there are multiple readers of source
> > >
From: Joe Perches
> Sent: 06 November 2020 21:50
>
> On Fri, 2020-11-06 at 13:32 -0800, Andrii Nakryiko wrote:
> > On Thu, Nov 5, 2020 at 11:12 PM wrote:
> > > Fix following warning from coccinelle:
> > > ./tools/lib/bpf/libbpf.c:1478:43-48: WARNING: conversion to bool not
> > > needed here
> []
From: Andy Shevchenko
> Sent: 06 November 2020 14:36
>
> There are few places when GENMASK() or BIT() macro is suitable and makes code
> easier to understand.
>
...
> - if ((d & ~0xff) == BRL_UC_ROW) {
> - if ((ch & ~0xff) == BRL_UC_ROW)
> + if ((d & ~GENMASK(7, 0)) == BRL_UC_
From: Joe Perches
> Sent: 06 November 2020 06:36
>
> On Fri, 2020-11-06 at 13:37 +0800, Alex Shi wrote:
> > There are some macros unused, they causes much gcc warnings. Let's
> > remove them to tame gcc.
>
> I believe these to be essentially poor warnings.
Indeed.
One 'solution' is to move the
From: Xie He
> Sent: 05 November 2020 22:47
>
> On Thu, Nov 5, 2020 at 12:40 PM Arnd Bergmann wrote:
> >
> > > I think this driver never worked. Looking at the original code in
> > > Linux 2.1.31, it already has the problems I fixed in commit
> > > 8fdcabeac398.
> > >
> > > I guess when people (o
From: Xie He
> Sent: 05 November 2020 19:35
>
> On Thu, Nov 5, 2020 at 1:10 AM David Laight wrote:
> >
> > > This driver transports LAPB (X.25 link layer) frames over TTY links.
> >
> > I don't remember any requests to run LAPB over anything other
>
> >> And the loop can be turned into ndelay:
> >>
> >> /*
> >> * Force at least 170ns delay before clearing
> >> * reset bit. Each read from LCR takes at least
> >> * 30ns so 10 times for 300ns to be safe.
> >> */
> >> for(i=0;i<10;i++)
> >>
From: Xie He
> Sent: 05 November 2020 07:35
>
> This driver transports LAPB (X.25 link layer) frames over TTY links.
I don't remember any requests to run LAPB over anything other
than synchronous links when I was writing LAPB implementation(s)
back in the mid 1980's.
If you need to run 'comms ov
From: Daniel Xu
> Sent: 05 November 2020 02:26
...
> --- a/lib/strncpy_from_user.c
> +++ b/lib/strncpy_from_user.c
> @@ -35,17 +35,22 @@ static inline long do_strncpy_from_user(char *dst, const
> char __user *src,
> goto byte_at_a_time;
>
> while (max >= sizeof(unsigned long))
From: Tong Zhang
> Sent: 03 November 2020 13:53
...
> > Also 'blknum' is only 'unsigned long' so ~0ull is wrong.
> > It can be worth injecting an error and checking the error
> > propagation works.
> >
> > What is the actual maximum file size?
> The maximum file size is 2GB-1, but from my understa
From: Tong Zhang
> Sent: 02 November 2020 23:14
>
> qnx4_block_map() may return -EIO on funny qnx4 fs image, in this case do
> not interpret -EIO as a correct block number
That commit message is now wrong.
Also 'blknum' is only 'unsigned long' so ~0ull is wrong.
It can be worth injecting an erro
From: Chao Yu
> Sent: 03 November 2020 02:37
...
> >> Do we need to change fsck.f2fs to recover this?
>
> However, we don't know which one is correct, compressed data or chksum value?
> if compressed data was corrupted, repairing chksum value doesn't help.
>
> Or how about adding chksum values fo
From: Tong Zhang
> Sent: 02 November 2020 20:16
>
> qnx4_block_map() may return -EIO on funny qnx4 fs image, in this case do
> not interpret -EIO as a correct address
'Block number' not 'address'.
> Signed-off-by: Tong Zhang
> ---
> v2: also check other callers according to Anders Larsen's
> c
From: Greg KH
> Sent: 02 November 2020 20:11
>
> On Mon, Nov 02, 2020 at 02:43:45PM -0500, Alex Deucher wrote:
> > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote:
> > >
> > > Initializing global variable to 0 or NULL is not necessary and should
> > > be avoided. Issue reported by checkpatch
From: 'Greg KH'
> Sent: 02 November 2020 13:52
>
> On Mon, Nov 02, 2020 at 09:06:38AM +, David Laight wrote:
> > From: 'Greg KH'
> > > Sent: 23 October 2020 15:47
> > >
> > > On Fri, Oct 23, 2020 at 02:39:24PM +, David La
From: Andy Shevchenko
> Sent: 02 November 2020 10:59
>
> On Mon, Oct 26, 2020 at 4:23 PM Bartosz Golaszewski wrote:
>
> ...
>
> > +static unsigned int
> > +exar_offset_to_sel_addr(struct exar_gpio_chip *exar_gpio, unsigned int
> > offset)
> > +{
> > + return (offset + exar_gpio->first_pi
From: 'Greg KH'
> Sent: 23 October 2020 15:47
>
> On Fri, Oct 23, 2020 at 02:39:24PM +, David Laight wrote:
> > From: David Hildenbrand
> > > Sent: 23 October 2020 15:33
> > ...
> > > I just checked against upstream code generated by clang 10 a
From: Marc Zyngier
> Sent: 01 November 2020 13:14
>
> Some interrupts (such as the rescheduling IPI) rely on not going through
> the irq_enter()/irq_exit() calls. To distinguish such interrupts, add
> a new IRQ flag that allows the low-level handling code to sidestep the
> enter()/exit() calls.
>
From: Marc Zyngier
> Sent: 01 November 2020 13:14
>
> Vincent recently reported [1] that 5.10-rc1 showed a significant
> regression when running "perf bench sched pipe" on arm64, and
> pinpointed it to the recent move to handling IPIs as normal
> interrupts.
>
> The culprit is the use of irq_ente
From: David Laight
> Sent: 31 October 2020 12:12
>
...
> The gcc 7.5.0 I have handy probably generates the best code for:
>
> unsigned char q_2(unsigned int pc)
> {
> unsigned char rctx = 0;
>
> rctx += !!(pc & (NMI_MASK));
> rctx +
From: Peter Zijlstra
> Sent: 30 October 2020 23:02
>
> On Fri, Oct 30, 2020 at 04:22:48PM -0400, Steven Rostedt wrote:
> > As this is something that ftrace recursion also does, perhaps we should
> > move this into interrupt.h so that anyone that needs a counter can get
> > it quickly, and not keep
From: Song Liu
> Sent: 30 October 2020 23:55
>
> Making perf with gcc-9.1.1 generates the following warning:
>
> CC ui/browsers/hists.o
> ui/browsers/hists.c: In function 'perf_evsel__hists_browse':
> ui/browsers/hists.c:3078:61: error: '%d' directive output may be \
> truncated writing b
From: Benjamin Segall
> Sent: 30 October 2020 18:48
>
> Hui Su writes:
>
> > Since 'ab93a4bc955b ("sched/fair: Remove
> > distribute_running fromCFS bandwidth")',there is
> > nothing to protect between raw_spin_lock_irqsave/store()
> > in do_sched_cfs_slack_timer().
> >
> > So remove it.
>
> Re
From: Arvind Sankar
> Sent: 29 October 2020 21:35
>
> On Thu, Oct 29, 2020 at 09:41:13PM +0100, Thomas Gleixner wrote:
> > On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> > > On 29/10/20 17:56, Arvind Sankar wrote:
> > >>> For those two just add:
> > >>> struct apic *apic = x86_system
From: Arnd Bergmann
> Sent: 29 October 2020 09:51
...
> I think ideally there would be no global variable, withall accesses
> encapsulated in function calls, possibly using static_call() optimizations
> if any of them are performance critical.
There isn't really a massive difference between global
From: Arnd Bergmann
> Sent: 28 October 2020 21:21
>
> From: Arnd Bergmann
>
> There are hundreds of warnings in a W=2 build about a local
> variable shadowing the global 'apic' definition:
>
> arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
> declaration [-Wshadow]
From: Ard Biesheuvel
> Sent: 27 October 2020 20:57
>
> Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
> function scope __attribute__((optimize("-fno-gcse"))), to disable a
> GCC specific optimization that was ca
301 - 400 of 1231 matches
Mail list logo
