On Sun, Apr 11, 2021 at 10:14 PM Guenter Roeck wrote:
>
> Qemu test results:
> total: 460 pass: 459 fail: 1
> Failed tests:
> sh:rts7751r2dplus_defconfig:ata:net,virtio-net:rootfs
>
> The failure bisects to commit 0f6925b3e8da ("virtio_net: Do not pull payload
> in
> skb->head").
On Sat, Mar 20, 2021 at 12:28 PM Marc Kleine-Budde wrote:
>
> Good idea. I'll send a pull request to David and Jakub.
I don't think the revert is necessary. The conflict is so trivial that
it doesn't really matter.
Conflicts like this that are local and obvious aren't really
problematic. Any mai
[ I'm checking lkml for at least some of the emails that I'm cc'd on ]
On Sun, Jan 31, 2021 at 2:59 AM Alexander Popov wrote:
>
> There are multiple similar bugs implicitly introduced by the
> commit [...]
Note: this got eaten or delayed by the mailing list issues that seem
to be plaguing lkml -
[ Participants list changed - syzbot thought this was networking and
p9, but it really looks entirely like a slub internal bug. I left the
innocent people on the list just to let them know they are innocent ]
On Wed, Jan 27, 2021 at 6:27 AM syzbot
wrote:
>
> The issue was bisected to:
>
> commit
On Thu, Jan 14, 2021 at 12:05 PM Jakub Kicinski wrote:
>
> Current release - regressions:
> ...
> Current release - always broken:
So I understand what you mean, but it does sound odd with that
"Current release - always broken" thing not being a regression. The
"always broken" makes it sound lik
On Wed, Jan 6, 2021 at 8:45 PM Willem de Bruijn wrote:
>
> But there are three other kmap_atomic callers under net/ that do not
> loop at all, so assume non-compound pages. In esp_output_head,
> esp6_output_head and skb_seq_read. The first two directly use
> skb_page_frag_refill, which can allocat
On Wed, Jan 6, 2021 at 3:01 PM Steven Rostedt wrote:
>
> I triggered the following crash on x86_32 by simply doing a:
>
> (ssh'ing into the box)
>
> # head -100 /tmp/output-file
>
> Where the /tmp/output-file was the output of a trace-cmd report.
> Even after rebooting and not running the tracin
On Tue, Dec 22, 2020 at 2:24 PM Florian Westphal wrote:
>
> strlcpy assumes src is a c-string. Check info->name before its used.
If strlcpy is the only problem, then the fix is to use strscpy(),
which doesn't have the design mistake that strlcpy has.
Of course, if the size limit of the source an
On Tue, Dec 22, 2020 at 6:44 AM syzbot
wrote:
>
> The issue was bisected to:
>
> commit 2f78788b55ba ("ilog2: improve ilog2 for constant arguments")
That looks unlikely, although possibly some constant folding
improvement might make the fortify code notice something with it.
> detected buffer ov
On Thu, Dec 3, 2020 at 12:45 PM Jakub Kicinski wrote:
>
> Networking fixes for 5.10-rc7, including fixes from bpf, netfilter,
> wireless drivers, wireless mesh and can.
Thanks, pulled.
And btw - maybe I've already talked about this, but since next week is
(hopefully) going to be the last week of
On Thu, Dec 3, 2020 at 2:33 AM Dominique Martinet
wrote:
>
>
> Hi Linus,
>
> Someone just reported splice got disabled in 5.10-rc1, here's a couple
> of patches to turn it back on using generic helpers.
Pulled.
> (Thanks for letting me know my mails got flagged as spam last time, I've
> taken th
On Thu, Oct 22, 2020 at 2:48 PM Jakub Kicinski wrote:
>
> Latest fixes from the networking tree. Experimenting with the format
> of the description further, I'll find out if you liked it based on how
> it ends up looking in the tree :)
Looks fine to me. Honestly, the format isn't a huge deal, as
On Thu, Oct 22, 2020 at 5:08 AM Dominique Martinet
wrote:
>
> another harmless cycle.
Quick note: your email got marked as spam for me.
It's probably just gmail doing another round of spam changes, but I do
note that while your smtp setup does spf, it doesn't do dkim. Which I
think makes gmail m
Thanks - applied and pushed out.
Linus
On Wed, Oct 14, 2020 at 3:51 PM Linus Torvalds
wrote:
>
> I think it's this instruction:
>
> addir1,r1,16
>
> that should be removed from the function exit, because Al removed the
>
> - stwur1,-16(r1)
>
> on function entry.
>
> S
On Wed, Oct 14, 2020 at 3:27 PM Jason A. Donenfeld wrote:
>
> This patch is causing crashes in WireGuard's CI over at
> https://www.wireguard.com/build-status/ . Apparently sending a simple
> network packet winds up triggering refcount_t's warn-on-saturate code. I
Ouch.
The C parts look fairly s
On Mon, Sep 21, 2020 at 6:44 PM Jakub Kicinski wrote:
>
> Here are the latest updates from the networking tree:
Pulled.
But I'd ask for a couple of things for future pull requests:
(a) please put "git pull" somewhere in the email (lots of people just
put it in the subject by prepending it with
On Mon, Aug 10, 2020 at 9:59 AM Willy Tarreau wrote:
>
> I took what we were already using in add_interrupt_randomness() since
> I considered that if it was acceptable there, it probably was elsewhere.
Once you've taken an interrupt, you're doing IO anyway, and the
interrupt costs will dominate a
On Mon, Aug 10, 2020 at 4:47 AM Willy Tarreau wrote:
>
> Doing testing on real hardware showed that retrieving the TSC on every
> call had a non negligible cost, causing a loss of 2.5% on the accept()
> rate and 4% on packet rate when using iptables -m statistics.
And by "real hardware" I assume
On Sun, Aug 9, 2020 at 2:10 PM Marc Plumb wrote:
>
> However, I think I'm starting to see your underlying assumptions.
> You're thinking that raw noise data are the only truly unpredictable
> thing so you think that adding it is a defense against attacks like
> foreshadow/spectre/meltdown. You are
On Sat, Aug 8, 2020 at 3:28 PM George Spelvin wrote:
>
> It's not a theoretical hole, it's a very real one. Other than the cycles
> to do the brute-force part, it's not even all that complicated. The
> theory part is that it's impossible to patch.
We'll just disagree.
I'm really fed up with se
On Sat, Aug 8, 2020 at 1:47 PM George Spelvin wrote:
>
> I *just* finished explaining, using dribs and drabs of entropy allows an
> *information theoretical attack* which *no* crypto can prevent.
The key word here being "theoretical".
The other key word is "reality".
We will have to agree to di
On Sat, Aug 8, 2020 at 1:08 PM George Spelvin wrote:
>
> So assuming that once per interrupt equals "often" is completely false.
That's not what people are assuming.
They are assuming it's "unpredictable".
Guys, look up the real and true meaning of "random" some day.
Guess what? It at no point
On Sat, Aug 8, 2020 at 10:45 AM Willy Tarreau wrote:
>
>
> WIP: random32: use siphash with a counter for prandom_u32
siphash is good.
But no:
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1277,7 +1277,6 @@ void add_interrupt_randomness(int irq, int irq_flags)
>
>
On Sat, Aug 8, 2020 at 10:07 AM Andy Lutomirski wrote:
>
>
> > On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
> >
>
> > And apparently switching to the fastest secure PRNG currently
> > in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> > would cause too much performance penalty
On Fri, Aug 7, 2020 at 1:16 PM Andy Lutomirski wrote:
>
> I think this will come down to actual measurements :).
Numbers talk, bullshit walks.
But:
> If the cost of one block of cache-cold ChaCha20 is 100 cycles of actual
> computation and 200 cycles of various cache misses, then let’s do more
On Fri, Aug 7, 2020 at 12:33 PM Andy Lutomirski wrote:
>
> No one said we have to do only one ChaCha20 block per slow path hit.
Sure, doing more might be better for amortizing the cost.
But you have to be very careful about latency spikes. I would be
*really* nervous about doing a whole page at
On Fri, Aug 7, 2020 at 12:08 PM Andy Lutomirski wrote:
>
> > On Aug 7, 2020, at 11:10 AM, Linus Torvalds
> > wrote:
> >
> >
> > I tried something very much like that in user space to just see how
> > many cycles it ended up being.
> >
> > I
On Fri, Aug 7, 2020 at 10:55 AM Andy Lutomirski wrote:
>
> I think the real random.c can run plenty fast. It’s ChaCha20 plus ludicrous
> overhead right now.
I doubt it.
I tried something very much like that in user space to just see how
many cycles it ended up being.
I made a "just raw ChaCha2
On Wed, Aug 5, 2020 at 8:44 AM Marc Plumb wrote:
>
> I thought net_rand_state was assumed to be insecure and that anyone
> could determine the internal state. Isn't this Working as Designed?
I was working as designed - because it wasn't really designed to be
"real crypto" - but sadly it's also th
On Wed, Aug 5, 2020 at 7:34 AM Russell King wrote:
>
> Is this something you're willing to merge directly please?
Done.
That said:
> -K: phylink
> +K:
> phylink\.h|struct\s+phylink|\.phylink|>phylink_|phylink_(autoneg|clear|connect|create|destroy|disconnect|ethtool|helper|mac|mii|of|se
On Tue, Aug 4, 2020 at 5:52 PM Marc Plumb wrote:
>
> TL;DR This change takes the seed data from get_random_bytes and broadcasts it
> to the network, thereby destroying the security of dev/random. This change
> needs to be reverted and redesigned.
This was discussed.,
It's theoretical, not prac
On Sat, Aug 1, 2020 at 2:36 PM David Miller wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
How is this wrt an rc8 or a final?
I have another possible small reason to do an rc8 right now. And this
roughly doubles my current diff.
On a very much related note, I really w
On Fri, Jul 3, 2020 at 8:50 AM Kees Cook wrote:
>
> With 67 kthreads on a booted system, this patch does not immediately
> blow up...
Did you try making read/write inc/dec that thing too? Or does that
just blow up with tons of warnings?
Linus
On Thu, Jul 2, 2020 at 7:35 PM Alexei Starovoitov
wrote:
>
> On Thu, Jul 02, 2020 at 06:05:29PM -0700, Linus Torvalds wrote:
> > On Thu, Jul 2, 2020 at 1:03 PM Alexei Starovoitov
> > wrote:
> > >
> > > The BPF program dump_bpf_prog() in iterators.bpf.
On Thu, Jul 2, 2020 at 4:26 PM Kees Cook wrote:
>
> The kprobe show() functions were using "current"'s creds instead
> of the file opener's creds for kallsyms visibility. Fix to use
> seq_file->file->f_cred.
Side note: I have a distinct - but despite that possibly quite
incorrect - memory that I'
On Thu, Jul 2, 2020 at 1:03 PM Alexei Starovoitov
wrote:
>
> The BPF program dump_bpf_prog() in iterators.bpf.c is printing this data about
> all BPF programs currently loaded in the system. This information is unstable
> and will change from kernel to kernel.
If so, it should probably be in debu
On Tue, Jun 30, 2020 at 12:43 PM Linus Torvalds
wrote:
>
> If you're not willing to do the work to fix it, I will revert that
> commit.
Hmm. I only now noticed that that commit is over two years old.
So I think it's still wrong (clearly others do change passwords
outside
On Mon, Jun 29, 2020 at 1:47 PM Eric Dumazet wrote:
>
> If you want to be able to _change_ md5 key, this is fine by me, please
> send a patch.
Eric, if this change breaks existing users, then it gets reverted.
That's just fundamental.
No RFC's are in the lreast relevant when compared to "this br
On Sat, Jun 20, 2020 at 12:57 AM Alexey Dobriyan wrote:
>
> > If you want to build the kernel with C++, you'd be a lot better off just
> > doing
> >
> >/* C++ braindamage */
> >#define this __this
> >#define new __new
> >
> > and deal with that instead.
>
> Can't do this because of pl
On Thu, Jun 18, 2020 at 2:06 PM Alexey Dobriyan wrote:
>
> Rename
> struct notifier_block *this
> to
> struct notifier_block *nb
>
> "nb" is arguably a better name for notifier block.
Maybe it's a better name. But it doesn't seem worth it.
Because C++ reserved words are entirely
On Tue, Jun 9, 2020 at 9:45 PM Michael S. Tsirkin wrote:
>
> I also upgraded the machine I used to sign
> the tag (didn't change the key) - hope the signature is still ok. If not
> pls let me know!
All looks normal as far as I can tell,
Linus
So I think there's something wrong with wireless networking, and
(likely) in particular turning off wireless. And I think the problem
came in this merge window, because now my machine hangs on shutdown.
My new desktop is otherwise working fine, but it has some unnecessary
wireless capability on th
[ Just a re-send without html and a few fixes for mobile editing,
since that email got eaten by the mailing list Gods ]
On Tue, Jun 2, 2020, 23:02 Michael S. Tsirkin wrote:
>
> Right and we do that, but that still sets the segment according to the
> current thread's flags, right?
But that should
On Tue, Jun 2, 2020 at 1:33 PM Michael S. Tsirkin wrote:
>
> Hmm are you sure we can drop it? access_ok is done in the context
> of the process. Access itself in the context of a kernel thread
> that borrows the same mm. IIUC if the process can be 32 bit
> while the kernel is 64 bit, access_ok in
On Tue, Jun 2, 2020 at 9:33 AM Al Viro wrote:
>
> >
> > It's not clear whether we need a new API, I think __uaccess_being() has the
> > assumption that the address has been validated by access_ok().
>
> __uaccess_begin() is a stopgap, not a public API.
Correct. It's just an x86 implementation det
On Thu, May 21, 2020 at 8:23 AM Christoph Hellwig wrote:
>
> this series start cleaning up the safe kernel and user memory probing
> helpers in mm/maccess.c, and then allows architectures to implement
> the kernel probing without overriding the address space limit and
> temporarily allowing access
On Tue, May 19, 2020 at 9:41 AM Christoph Hellwig wrote:
>
> I had a lot of folks complaining about things like:
>
> #ifdef CONFIG_FOO
> if (foo)
> do_stuff();
> else
> #endif
> do_something_else();
>
> which I personally don't mind at all, so I swit
On Tue, May 19, 2020 at 9:14 AM Christoph Hellwig wrote:
>
> I don't think we need it as the case of
>
> case 'a':
> case 'b':
> do_stuff();
> break;
>
> has always been fine even with the fallthough warnings. And the
> rest of the stuff gets remove
On Tue, May 19, 2020 at 6:44 AM Christoph Hellwig wrote:
>
> - rebased on 5.7-rc6 with the bpf trace format string changes
Other than the critique about illegible conditionals in the result
when doing that bpf/trace conversion, I like it.
Linus
On Tue, May 19, 2020 at 6:45 AM Christoph Hellwig wrote:
>
> +
> + if (IS_ENABLED(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE) &&
> + compat && (unsigned long)unsafe_ptr < TASK_SIZE)
> + ret = probe_user_read(dst, user_ptr, size);
> + else
> + re
On Tue, May 19, 2020 at 6:45 AM Christoph Hellwig wrote:
>
> + if (IS_ENABLED(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE) &&
> + compat && (unsigned long)unsafe_ptr < TASK_SIZE)
> + ret = strncpy_from_user_nofault(dst, user_ptr, size);
> + else
> +
On Tue, May 19, 2020 at 6:45 AM Christoph Hellwig wrote:
>
> + switch (fmt_ptype) {
> + case 's':
> +#ifdef CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
> + strncpy_from_unsafe(buf, unsafe_ptr, bufsz);
> + break;
> +#endif
> + case 'k':
> +
On Thu, May 14, 2020 at 9:18 AM Daniel Borkmann wrote:
>
> However, their use should be restricted to archs with non-overlapping
> address ranges where they are working in their current form. Therefore,
> move this behind a CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE and
> have x86, arm64, arm s
On Wed, May 13, 2020 at 6:00 PM Masami Hiramatsu wrote:
>
> > But we should likely at least disallow it entirely on platforms where
> > we really can't - or pick one hardcoded choice. On sparc, you really
> > _have_ to specify one or the other.
>
> OK. BTW, is there any way to detect the kernel/us
On Wed, May 13, 2020 at 4:21 PM Masami Hiramatsu wrote:
>
>
> For trace_kprobe.c current order (kernel -> user fallback) is preferred
> because it has another function dedicated for user memory.
Well, then it should just use the "strict" kernel-only one for the
non-user memory.
But yes, if there
On Wed, May 13, 2020 at 4:04 PM Daniel Borkmann wrote:
>
> Aside from comments on list, the series looks reasonable to me. For BPF
> the bpf_probe_read() helper would be slightly penalized for probing user
> memory given we now test on copy_from_kernel_nofault() first and if that
> fails only then
On Wed, May 13, 2020 at 3:36 PM Daniel Borkmann wrote:
>
> It's used for both.
Daniel, BPF real;ly needs to make up its mind about that.
You *cannot* use ti for both.
Yes, it happens to work on x86 and some other architectures.
But on other architectures, the exact same pointer value can be a
On Wed, May 13, 2020 at 12:40 PM Christoph Hellwig wrote:
>
> We do export something like it, currently it is called
> probe_kernel_address, and the last patch renames it to
> get_kernel_nofault. However it is implemented as a wrapper
> around probe_kernel_address / copy_from_kernel_nofault and t
On Wed, May 13, 2020 at 9:00 AM Christoph Hellwig wrote:
>
> this series start cleaning up the safe kernel and user memory probing
> helpers in mm/maccess.c, and then allows architectures to implement
> the kernel probing without overriding the address space limit and
> temporarily allowing access
On Wed, May 13, 2020 at 9:01 AM Christoph Hellwig wrote:
>
> + arch_kernel_read(dst, src, type, err_label);\
I'm wondering if
(a) we shouldn't expose this as an interface in general
(b) it wouldn't be named differently..
The reason for (a) is that several users of t
On Wed, May 13, 2020 at 9:01 AM Christoph Hellwig wrote:
>
> +static void bpf_strncpy(char *buf, long unsafe_addr)
> +{
> + buf[0] = 0;
> + if (strncpy_from_kernel_nofault(buf, (void *)unsafe_addr,
> + BPF_STRNCPY_LEN))
> + strncpy_from_user_nofault(
On Wed, May 6, 2020 at 11:15 AM Christoph Hellwig wrote:
>
> That was the first prototype, and or x86 it works great, just the
> __user cases in maccess.c are a little ugly. And they point to
> the real problem - for architectures like sparc and s390 that use
> an entirely separate address space
On Wed, May 6, 2020 at 10:47 AM Christoph Hellwig wrote:
>
> > The fact that we have "probe_kernel_read()" but then
> > "strncpy_from_user_unsafe()" for the _same_ conceptual difference
> > really tells me how inconsistent the naming for these kinds of "we
> > can't take page faults" is. No?
>
> T
On Tue, May 5, 2020 at 11:23 PM Christoph Hellwig wrote:
>
> +#define arch_kernel_read(dst, src, type, err_label)\
> + __get_user_size(*((type *)dst), (__force type __user *)src, \
> + sizeof(type), __kr_err);\
..
> +#defi
On Tue, May 5, 2020 at 11:22 PM Christoph Hellwig wrote:
>
> This matches the convention of always having _unsafe as a suffix, as
> well as match the naming of strncpy_from_user_unsafe.
Hmm. While renaming them, can we perhaps clarify what the rules are?
We now have two different kinds of "unsaf
On Thu, Sep 12, 2019 at 2:10 AM Cong Wang wrote:
>
> On Wed, Sep 11, 2019 at 2:36 PM Eric Dumazet wrote:
> >
> > It seems a similar fix would be needed in net/sched/sch_dsmark.c ?
> >
>
> Yeah, or just add a NULL check in dsmark_destroy().
Well, this was why one of my suggestions was to just mak
Jason and Davem,
with gcc-9, I'm now seeing a number of annoying warnings from the
rdma layer. I think it depends on the exact gcc version, because I'm
seeing them on my laptop but didn't see them on my desktop, probably
due to updating at different times.
The warning is because gcc now looks at
On Wed, Mar 6, 2019 at 5:20 PM Al Viro wrote:
>
> I'll try to massage that series on top of your patch; I still hate the
> post-vfs_poll() logics in aio_poll() ;-/ Give me about half an hour
> and I'll have something to post.
No inherent hurry, I sent the ping just to make sure it hadn't gotten
On Wed, Mar 6, 2019 at 4:03 PM Al Viro wrote:
>
> From: Al Viro
>
> "aio: remove the extra get_file/fput pair in io_submit_one" was
> too optimistic - not dereferencing file pointer after e.g.
> ->write_iter() returns is not enough; that reference might've been
> the only thing that kept alive ob
On Sun, Mar 3, 2019 at 6:36 PM Al Viro wrote:
>
> OK, having dug through the archives, the reasons were not strong.
> So that part is OK...
I've committed the patch.
However, I didn't actually do the separate and independent cleanups:
> > @@ -1060,6 +1071,8 @@ static inline void iocb_put(struc
On Sun, Mar 3, 2019 at 12:30 PM Al Viro wrote:
>
> On Sun, Mar 03, 2019 at 11:44:33AM -0800, Linus Torvalds wrote:
> >
> > I'm assuming you're talking about the second vfs_poll() in
> > aio_poll_complete_work()? The one we call before we check for
> > &quo
On Sun, Mar 3, 2019 at 11:44 AM Linus Torvalds
wrote:
>
> But doesn't it look nice to see
>
> 2 files changed, 41 insertions(+), 50 deletions(-)
>
> with actual code reduction, and a fundamental simplification in
> handling of the file pointer?
A coupl,e of the changes
On Sun, Mar 3, 2019 at 7:18 AM Al Viro wrote:
>
> > Maybe unrelated to this bug, but... What's to prevent a wakeup
> > that happens just after we'd been added to a waitqueue by ->poll()
> > triggering aio_poll_wake(), which gets to aio_poll_complete()
> > with its fput() *before* we'd reached the
On Fri, Feb 22, 2019 at 6:29 PM Alexei Starovoitov
wrote:
>
> imo this kernel release should finish as-is and in the next cycle we can
> change probe_kernel_read() to reject user address [..]
Absolutely. Nothing is going to change right now for 5.0, which is imminent.
It's really a "long-term we
On Fri, Feb 22, 2019 at 3:56 PM Alexei Starovoitov
wrote:
>
> It will preserve existing bpf_probe_read() behavior on x86.
... but that's the worst possible situation.
It appears that people haven't understood that kernel and user
addresses are distinct, and may have written programs that are
fun
On Fri, Feb 22, 2019 at 2:51 PM Alexei Starovoitov
wrote:
>
> That's all fine. I'm missing rationale for making probe_kernel_read()
> fail on user addresses.
Because it already WON'T WORK in general!
> What is fundamentally wrong with a function probe_any_address_read() ?
What part of "the same
On Fri, Feb 22, 2019 at 1:38 PM David Miller wrote:
>
> Don't be surprised if we see more separation like this in the future too.
Yes, with the whole meltdown fiasco, there's actually more pressure to
add more support for separation of kernel/user address spaces. As Andy
pointed out, it's been di
On Fri, Feb 22, 2019 at 11:27 AM Alexei Starovoitov
wrote:
>
> On bpf side the bpf_probe_read() helper just calls probe_kernel_read()
> and users pass both user and kernel addresses into it and expect
> that the helper will actually try to read from that address.
As mentioned earlier in the threa
On Thu, Feb 21, 2019 at 2:20 PM Daniel Borkmann wrote:
>
> In case of gcc, this setting is controlled by case-values-threshold
> which has an architecture global default that selects 4 or 5 (
Ack. For retpoline, that's much too low.
Patch looks sane, although it would be good to verify just whic
On Fri, Jan 25, 2019 at 4:21 PM David Miller wrote:
>
> This is a resend of the previous pull request with the qed changes
> reverted.
Thanks.
I'm trying to be a bit stricter about the rc pulls, even if I normally
don't even look at yours much.
So let's try to keep it to fixes only, or at least
On Fri, Jan 25, 2019 at 1:15 PM Linus Torvalds
wrote:
>
> You don't even *mention* the changes to the qlogic driver that are
> completely new and over a thousand lines.
They look like completely new error handling and recovery code. Very
much new development, not fixes.
And th
On Fri, Jan 25, 2019 at 9:58 AM David Miller wrote:
>
> Please pull, thanks a lot!
Why?
You don't even *mention* the changes to the qlogic driver that are
completely new and over a thousand lines.
What is going on here? There's no explanation for these huge "fixes"
that aren't even mentioned
On Tue, Jan 8, 2019 at 8:31 PM Michael S. Tsirkin wrote:
>
> Linus, given that you just changed all users of access_ok anyway, do
> you still think that the access_ok() conversion to return a speculation
> sanitized pointer or NULL is too big a conversion?
I didn't actually change a single access
On Sun, Oct 28, 2018 at 7:46 PM David Miller wrote:
>
> Please pull, thanks a lot!
Pulled,
Linus
On Fri, Jun 29, 2018 at 6:46 AM Linus Torvalds
wrote:
>
> Hmm. I'll have to think about it.
I took yours over the revert. It's just smaller and nicer, and the
conditional should predict fine for any case where it might matter.
Linus
On Fri, Jun 29, 2018 at 6:37 AM Christoph Hellwig wrote:
>
> The big aio poll revert broke various network protocols that don't
> implement ->poll as a patch in the aio poll serie removed sock_no_poll
> and made the common code handle this case.
Hmm. I just did the revert of commit 984652dd8b1f (
On Fri, Jun 29, 2018 at 6:29 AM Christoph Hellwig wrote:
> No need for poll_table_entry, we just need a wait_queue_head.
> poll_table_entry is an select.c internal (except for two nasty driver) -
> neither epoll nor most in-kernel callers use it.
Well, you need the poll_table for the "poll_wait()
On Thu, Jun 28, 2018 at 4:37 PM Al Viro wrote:
>
> You underestimate the nastiness of that thing (and for the record, I'm
> a lot *less* fond of AIO than you are, what with having had to read that
> nest of horrors lately). It does not "copy the data to userland"; what it
> does instead is copyin
On Thu, Jun 28, 2018 at 3:49 PM Al Viro wrote:
>
> aio_poll() is not a problem. It's wakeup callback that is one.
No, it's not a problem either.
The only thing the wakup callback wants to do is to remove the wait queue entry.
And *that* doesn't need to sleep, and it has absolutely nothing to d
On Thu, Jun 28, 2018 at 3:20 PM Al Viro wrote:
>
> The rules for drivers change only in one respect - if your ->poll() is going
> to
> need to block, check poll_requested_events(pt) & EPOLL_ATOMIC and return
> EPOLLNVAL
> in such case.
OI still don't even understand why you care.
Yes, the AIO
On Thu, Jun 28, 2018 at 2:30 PM Al Viro wrote:
>
> > Again, locking is permitted. It's not great, but it's not against the rules.
>
> Me: a *LOT* of ->poll() instances only block in __pollwait() called
> (indirectly)
> on the first pass.
>
> You: They are *all* supposed to do it.
>
> Me:
Oh, I
On Thu, Jun 28, 2018 at 1:37 PM Al Viro wrote:
>
>
> Speaking of obvious bogosities (a lot more so than a blocking allocation
> several calls down into helper):
>
> static __poll_t ca8210_test_int_poll(
> struct file *filp,
> struct poll_table_struct *ptable
> )
Ok, that's just ga
On Thu, Jun 28, 2018 at 1:28 PM Al Viro wrote:
>
>
> Sure, but...
>
> static __poll_t binder_poll(struct file *filp,
> struct poll_table_struct *wait)
> {
> struct binder_proc *proc = filp->private_data;
> struct binder_thread *thread = NULL;
>
On Thu, Jun 28, 2018 at 11:17 AM Al Viro wrote:
>
> As for what can be salvaged out of the whole mess,
> * probably the most serious lesson is that INDIRECT CALLS ARE
> COSTLY NOW and shouldn't be used lightly.
Note that this has always been true, it's just _way_ more obvious now.
Indire
On Thu, Jun 28, 2018 at 7:21 AM Christoph Hellwig wrote:
>
> Note that for this removes the possibility of actually returning an
> error before waiting in poll. We could still do this with an ERR_PTR
> in f_poll_head with a little bit of WRITE_ONCE/READ_ONCE magic, but
> I'd like to defer that un
On Fri, May 11, 2018 at 5:10 PM David Miller wrote:
> I guess this is my reward for trying to break the monotony of
> pull requests :-)
I actually went back and checked a few older pull requests to see if this
had been going on for a while and I just hadn't noticed.
It just took me by surprise
David, is there something you want to tell us?
Drugs are bad, m'kay..
Linus
On Fri, May 11, 2018 at 2:00 PM David Miller wrote:
> "from Kevin Easton", "Thanks to Bhadram Varka", "courtesy of Gustavo A.
> R. Silva", "To Eric Dumazet we are most grateful for this fix", "This
> fi
On Sat, Apr 28, 2018 at 7:12 PM Fengguang Wu wrote:
> FYI this happens in mainline kernel 4.17.0-rc2.
> It looks like a new regression.
> It occurs in 5 out of 5 boots.
> [main] 375 sockets created based on info from socket cachefile.
> [main] Generating file descriptors
> [main] Added 83 filen
On Tue, Apr 24, 2018 at 12:54 PM, Jesper Dangaard Brouer
wrote:
> Hi all,
>
> I'm experiencing boot failures with net-next git-tree after it got
> rebased/merged with Linus'es tree at v4.17.0-rc1.
I suspect it's the global bit stuff that came in very late in the
merge window, and had been develop
1 - 100 of 458 matches
Mail list logo
