lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 28 Sep 2020 09:45:30 -0700 (PDT) From: Palmer Dabbelt <palmer@...belt.com> To: Christoph Hellwig <hch@....de> CC: Christoph Hellwig <hch@....de>, viro@...iv.linux.org.uk, Arnd Bergmann <arnd@...db.de>, Paul Walmsley <paul.walmsley@...ive.com>, linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org Subject: Re: remove set_fs for riscv v2 On Mon, 28 Sep 2020 05:49:28 PDT (-0700), Christoph Hellwig wrote: > On Sat, Sep 26, 2020 at 10:50:52AM -0700, Palmer Dabbelt wrote: >> On Mon, 21 Sep 2020 21:37:52 PDT (-0700), Christoph Hellwig wrote: >>> Given tht we've not made much progress with the common branch, >>> are you fine just picking this up through the riscv tree for 5.10? >>> >>> I'll defer other architectures that depend on the common changes to >>> 5.11 then. >> >> I'm OK taking it, but there's a few things I'd like to sort out. IIRC I put it >> on a temporary branch over here >> >> https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-remove_set_fs >> >> under the assumption it might get lost otherwise, but let me know if that's not >> what you were looking for. > > Well, we'll want it in linux-next and then 5.10. Either a merge through > the RISC-V maintainer, or as part of the base branch from Al would > make sense to me. Sorry, I guess my question was really: does that branch have all the dependencies necessary for the RISC-V stuff to actually work? IIRC this actual patch set depended on some other one, and while I thinK I got everything I don't want to pull in something broken. >> Arnd: Are you OK with the asm-generic stuff? I couldn't find anything in my >> mail history, so sorry if I just missed it. >> >> Al: IIRC the plan here was to have me merge in a feature branch with this >> stuff, but it'd have to be based on your for-next as there are some >> dependencies over there. I see 5ae4998b5d6f ("powerpc: remove address space >> overrides using set_fs()") in vfs/for-next so I think we should be OK, but let >> me know if I'm doing something wrong.
Powered by blists - more mailing lists