On Tue, 9 Jul 2019 08:46:32 +0200
Martin Hundebøll wrote:
> Make it obvious how the gsm mux number relates to the virtual tty lines
> by using helper function instead of shifting 6 bits.
>
> Signed-off-by: Martin Hundebøll
> ---
> drivers/tty/n_gsm.c | 16 +---
> 1 file changed, 1
On Mon, 8 Jul 2019 21:02:52 +0200
Martin Hundebøll wrote:
> Guessing the base tty for a gsm0710 multiplexed serial device is not
> currently possible, which makes it racy to use with multiple modems.
>
> Add a way to map the physical serial tty to its related mux devices
> using a ioctl.
That
On Fri, 21 Jun 2019 15:16:04 +0530
Puranjay Mohan wrote:
> This patch series removes the private duplicates of PCI definitions in
> favour of generic definitions defined in pci_regs.h.
Why bother ? It's an ancient obsolete card ?
Do you even have one to test ?
>
> This driver only uses some o
> +static int rpmsg_tty_data_handler(struct rpmsg_device *rpdev, void *data,
> + int len, void *priv, u32 src)
> +{
> + struct rpmsg_tty_port *cport = dev_get_drvdata(&rpdev->dev);
> + u8 *cbuf;
> + int space;
> +
> + dev_dbg(&rpdev->dev, "msg(<- src
O
> +static void mlb_usio_set_termios(struct uart_port *port,
> + struct ktermios *termios, struct ktermios *old)
> +{
> + unsigned int escr, smr = MLB_USIO_SMR_SOE;
> + unsigned long flags, baud, quot;
> +
> + switch (termios->c_cflag & CSIZE) {
> + case CS5:
>
> > If the virtual Sparc emulator is using it does that also mean actual
> > Sparc hardware has it. In which case presumably it needs fixing, or at
> > least moving to the generic driver assuming the firmware sets it up ?
> >
>
> The qemu works perfectly with the new Linux driver.
For some con
On Sat, 16 Mar 2019 10:35:43 +0100
Samuel Thibault wrote:
> Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > Okash Khawaja writes:
> > > Finally there is an issue where text in output buffer sometimes gets
> > > garbled on SMP systems, but we can continue working on it after th
> Suse have a solution for this that I'd like to see pushed again, but
> from a practical perspective enterprise distributions have been
> shipping this for some time without significant obvious customer
> complaint.
Probably because their IT department hasn't noticed 8)
Alan
On Tue, 12 Mar 2019 11:41:02 +0100
LABBE Corentin wrote:
> On Mon, Dec 10, 2018 at 05:52:35PM +0300, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 12/10/2018 04:46 PM, Corentin Labbe wrote:
> >
> > > When playing with a virtual SPARC machine with qemu, I found that the
> > > IDE emulated devic
On Wed, 6 Mar 2019 15:58:55 -0800
Matthew Garrett wrote:
> From: Josh Boyer
>
> There is currently no way to verify the resume image when returning
> from hibernate. This might compromise the signed modules trust model,
> so until we can work with signed hibernate images we disable it when th
On Wed, 6 Mar 2019 09:11:44 -0500
"Theodore Y. Ts'o" wrote:
> On Wed, Mar 06, 2019 at 01:25:17PM +0100, Thomas Gleixner wrote:
> > > It's been 25 years since Linux added support for ELF. Can we just
> > > delete the a.out support entirely now? According to the Linux-ELF HOWTO,
> > > support was
> It's been 25 years since Linux added support for ELF. Can we just
> delete the a.out support entirely now? According to the Linux-ELF HOWTO,
> support was added in 1.1.52 (August 1994). It's pretty much necromancy
> at this point.
In the unlikely event that someone actually has an a.out binar
On Wed, 30 Jan 2019 15:31:20 +1030
Rusty Russell wrote:
> Thanks taking on such a thankless task Thomas,
>
> Might have been overzealous in assuming a verionless GPL string meant
> "or later" (I'm happy for that for my own code, FWIW). My memory is
> fuzzy, but I don't think anyone cared at the
> > > +"GPL and additional rights" Historical variant of expressing that
> > > the
> > > + module source is dual licensed under a
> > > + GPL v2 variant and MIT license. Please do
> > > + not use in new code.
Actu
> This is going to be a mammoth task. The alternatives are to continue
> as things are, which is a mess that cannot be cleaned up by either of
> (mutually exclusive) hardware or software alone.
>
> Thoughts and feedback appreciated.
You need to be talking to the JIT developers not asking here I t
> I think the issue is a bit more complex :
> - linux doesn't support a single libc
> - glibc doesn't support a single OS
>
> In practice we all know (believe?) that both statements above are
> true but in practice 99% of the time there's a 1:1 relation between
> these two components.
The
On Mon, 12 Nov 2018 17:09:56 +0100
Oleg Nesterov wrote:
> Large enterprise clients often times run applications out of networked
> file systems where the IT mandated layout of project volumes can end up
> leading to paths that are longer than 128 characters. Bumping this up to
> the next order of
On Mon, 22 Oct 2018 09:56:42 +0200
Joerg Roedel wrote:
> On Sun, Oct 21, 2018 at 02:37:45PM +0200, Pavel Machek wrote:
> > On Tue 2018-09-18 14:00:30, Alan Cox wrote:
> > > There are pretty much no machines that don't support PAE and are still
> > > even vag
> > Data protection law, reporting laws in some
> > countries and the like mean that anyone expecting an incident to remain
> > confidential from the person it was reported against is living in
> > dreamland and are going to get a nasty shock.
>
> OK - you seem to be talking about keeping the in
> +to the circumstances. The Code of Conduct Committee is obligated to
> +maintain confidentiality with regard to the reporter of an incident.
> +Further details of specific enforcement policies may be posted
> +separately.
Unfortunately by ignoring the other suggestions on this you've left this
On Tue, 16 Oct 2018 20:12:43 +0200
"Gustavo A. R. Silva" wrote:
> On 10/16/18 8:09 PM, Dmitry Torokhov wrote:
>
> >
> > /dev/uinput
>
> I've got it. This explains it all. :)
>
> > must be 0600, or accessible to equally privileged user, or you'll be
> > opening your system to much mischief
> +/*
> + * Returns true if current's euid is same as p's uid or euid,
> + * or has CAP_SYS_ADMIN.
> + *
> + * Called with rcu_read_lock, creds are safe.
> + *
> + * Adapted from set_one_prio_perm().
> + */
> +static bool set_predump_signal_perm(struct task_struct *p)
> +{
> + const struct cred
s allows S0ix modes to
> be entered on e.g. a Chuwi Hi8 Pro and a HP x2 210.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196915
> Signed-off-by: Hans de Goede
Reviewed-by: Alan Cox
Thanks
> > It should be.
>
> You mean that the problem should be purely academic, IOW that registers
> touched
> by the P-Unit are never touched through ACPI Opregions / power-resources?
As far as I am aware. Holding the lock over both is definitely better
regardless
> >> 2) To safely access the sha
> My understanding is that the standard “breadcrumb” is that a cache line is
> fetched into L1D, and that the cacheline in question will go into L1D even if
> it was previously not cached at all. So flushing L1D will cause the timing
> from a probe to be different, but the breadcrumb is still th
> But this really needs to be clarified. Alan said that a bunch of the
> "yet another Spectre variant" attacks would have been mitigated by
> this patch. An explanation of *how* would be in order.
Today you have the situation where something creates a speculative
disclosure gadget. So we run aro
> 1) PMIC accesses often come in the form of a read-modify-write on one of
> the PMIC registers, we currently release the P-Unit's PMIC bus semaphore
> between the read and the write. If the P-Unit modifies the register during
> this window?, then we end up overwriting the P-Unit's changes.
> I bel
> Ugh.
>
> What exactly is this trying to protect against? And how many cycles
Most attacks by speculation rely upon leaving footprints in the L1 cache.
They also almost inevitably resolve non speculatively to errors. If you
look through all the 'yet another potential spectre case' patches peopl
> I'm mostly wondering if it is worth future-proofing for new transports. It
> sounds like we can have a consensus on leaving the upper 4 bits of the speed
> fields reserved, but leave the details of implementation for the future?
It seems reasonable, although I think the reality is that any fut
On Tue, 9 Oct 2018 12:19:04 -0700
"H. Peter Anvin" wrote:
> [Resending to a wider audience]
>
> In trying to get the termios2 interface actually implemented in glibc,
> the question came up if we will ever care about baud rates in excess of
> 4 Gbps, even in the relatively remote future.
Even R
On Wed, 10 Oct 2018 13:10:30 -0700
> +appropriate to the circumstances. The TAB is obligated to maintain
> +confidentiality with regard to the reporter of an incident.
I would add (except where required by law.)
Alan
On Wed, 10 Oct 2018 14:19:17 -0300
Mauro Carvalho Chehab wrote:
> Em Wed, 10 Oct 2018 16:53:08 +0100
> Alan Cox escreveu:
>
> > > -Maintainers have the right and responsibility to remove, edit, or reject
> > > +Maintainers may remove, edit, or reject
> > >
> -Maintainers have the right and responsibility to remove, edit, or reject
> +Maintainers may remove, edit, or reject
> comments, commits, code, wiki edits, issues, and other contributions that are
> not aligned to this Code of Conduct, or to ban temporarily or permanently any
> contributor for
> In any case, this is not the appropriate place for such patches, any
> more than it's the place for patches to the GPL.
I disagree. We had the GPLv2 or GPLv3 discussion on the kernel mailing
list. The syscall clarification was discussed on the list. The
EXPORT_SYMBOL and EXPORT_SYMBOL_GPL stuff
thing. If maintainers decide to carry on
accepting patches from someone what can they do ?
So both patches:
Reviewed-by: Alan Cox
> /* only root can play with this */
> if (!capable(CAP_SYS_ADMIN))
> return -EACCES;
>
> Think about it - if DM control ioctls only require CAP_SYS_ADMIN,
> then if have that cap you can use DM to remap any block in a block
> device to any other block. You don't ne
> > CAP_SYS_ADMIN is also a bit weird because low level access usually
> > implies you can bypass access controls so you should also check
> > CAP_SYS_DAC ?
>
> Do you mean CAP_DAC_READ_SEARCH as per the newer handle syscalls?
> But that only allows bypassing directory search operations, so mayb
> > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview
There is no such product as Valleyview. Some things talk about
Valleyview 2 but shouldn't as that is Baytrail.
> /* "Small Core" Processors (Atom) */
>
> #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview
> */
>
> Well, then I have to repeat myself: Signed-off source code (in form of
> patches) in a well-known programming language for a (nowadays)
> well-known GPLv2 licensed project mailed on "everyone can subscribe"
> mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> mailinglist archive
On Wed, 22 Aug 2018 11:25:35 +0200
Marcus Linsner wrote:
> Hi. How to make the kernel keep(lock?) all code pages in RAM so that
> kswapd0 won't evict them when the system is under low memory
> conditions ?
>
> The purpose of this is to prevent the kernel from causing lots of disk
> reads(effecti
> Trying to depend on task name for anything security sensitive is at
> _really_ bad idea, so it seems unlikely that a LSM would want to
> protect the process name. (And if they did, the first thing I would
> ask is "Why? What are you trying to do? Do you realize how many
> *other* ways the pr
On Wed, 26 Sep 2018 17:49:09 -0400
"Theodore Y. Ts'o" wrote:
> On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote:
> > In almost all cases you don't care so you wouldn't use it. In those cases
> > where it might matter it's almost always the c
On Wed, 26 Sep 2018 11:33:29 +1000
Dave Chinner wrote:
> On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote:
> > Hi,
> >
> > I'm bringing up this issue again to let of LSM developers know the
> > situation, and would like to know your thoughts.
> > Several weeks ago I sent an email to th
> And I think that's fine. The only way we can make any guarantees is
> if we do what Alan suggested, which is to imply that a read on a dirty
> page *block* until the the page is successfully written back. This
> would destroy performance.
In almost all cases you don't care so you wouldn't use
> Unlike O_TMPFILE, this would require file system changes to support,
> so maybe it's not worth having something which automatically cleans up
> files that were in the middle of being written at the time of a system
> crash.
Would it. If you open a file unlink it and write to it and then have a
l
> write()
> kernel attempts to write back page and fails
> page is marked clean and evicted from the cache
> read()
>
> Now your write is gone and there were no calls between the write and
> read.
>
> The question we still need to answer is this:
>
> When we attempt to write back some data from
> The other thing which you seem to be assuming is that applications
> which care about precious data won't use fsync(2). And in general,
> it's been fairly well known for decades that if you care about your
> data, you have to use fsync(2) or O_DIRECT writes; and you *must*
> check the error retu
On Thu, 6 Sep 2018 11:17:18 +0200
Rogier Wolff wrote:
> On Thu, Sep 06, 2018 at 12:57:09PM +1000, Dave Chinner wrote:
> > On Wed, Sep 05, 2018 at 02:07:46PM +0200, Rogier Wolff wrote:
>
> > > And this has worked for years because
> > > the kernel caches stuff from inodes and data-blocks. If yo
On Tue, 18 Sep 2018 21:05:20 -0400
Brian Dodge wrote:
> Hi,
>
> In the linux kernel commit 91ab076e3a2f092254fe5231bbfa92b37fd52e38 the
> vendor prefix "arctic" was added to vendor-prefixes.txt.
>
> The original change I authored used "arc" not "arctic", and the device
> tree bindings were ad
On Tue, 11 Sep 2018 14:12:22 +0200
Joerg Roedel wrote:
> On Tue, Sep 11, 2018 at 02:58:10PM +0300, Meelis Roos wrote:
> > The machines where I have PAE off are the ones that have less memory.
> > PAE is off just for performance reasons, not lack of PAE. PAE should be
> > present on all of my af
On Tue, 11 Sep 2018 22:23:55 +0200
Remi Pommarel wrote:
> This patchset adds a way to have a specific keyboard config (i.e.
> keycode to keysym map) for a vt attached input.
Who actually needs this given that you can't even render most
international symbols in text mode and X and friends already
On Mon, 3 Sep 2018 19:16:39 +0200
Rogier Wolff wrote:
> Hi,
>
> I'm writing a kernel driver. It is not going to be widely used, so I'm
> not motivated to make things nice enough for inclusion in the standard
> kernel.
>
> But lspci shows my device:
>
> 03:01.0 Serial bus controller [0c80]: P
> b) IOMMU can solve this problem for me by providing a device-specific
> contiguous view of a fragmented physical memory allocation
> c) In order to enable IOMMU do the above, I need to allocate DRHDs and
> DMARs in BIOS initialization (I build my own BIOS)
Yes. The EDK2 firmware toolkit has all
> I'm actually not talking about UEFI storage, just the UEFI secure boot
> database. I think we might come up with a viable model for adding keys
> from a UEFI variable that isn't part of the secure boot database.
You also need to be able to remove or not trust the existing ones
including the Mic
and not worry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Alan Cox
Alan
On Fri, 27 Jul 2018 16:39:31 +0300
Anton Vasilyev wrote:
> If number of isa and pci boards exceed NUM_BOARDS on the path
> rp_init()->init_PCI()->register_PCI() then buffer overwrite occurs
> in register_PCI() on assign rcktpt_io_addr[i].
>
> The patch adds check on upper bound for index of regi
> # hdparm --user-master u --security-erase p /dev/sda
> (returns immediately and does nothing).
>
> I've tried hdparm on an SSD connected via USB3 and it secure-erased ok.
>
> Anyone working on this?
Sounds to me like you need to contact the vendor of the interface in
question. If it accepted a
On Tue, 24 Jul 2018 17:51:33 -0700
r...@google.com wrote:
> From: Roman Kiryanov
>
> The driver never mutates this variable - no benefits of
> keeping it mutable.
>
> Signed-off-by: Roman Kiryanov
> ---
> Changes in v2:
> - Replaced "const u32" with "#define".
v1 was IMHO definitely better.
> >> If we determined tsc early in boot using one of the quick methods:
> >> from cpuid/msr/quick_pit, can we assume that frequencies of all other
> >> CPUs will be determined the same way? Or do we still have to fallback
Not on 32bit at least. You can have a mixed slot 1 SMP system such as
an ASU
> >
> > > + if (!port->iso7816_config)
> > > + return -ENOIOCTLCMD;
> >
> > Why this error value?
> >
>
> It was a mimic of RS485.
Which is what you want - it means the upper tty layer knows to offer the
ioctl to other places and then return appropriately.
Alan
On Wed, 18 Jul 2018 05:01:52 +0200
Adam Borowski wrote:
> Hi!
> Here's a patchset with two entangled improvements:
>
> * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
> allows disabling it, rendering such characters with a bright background
> instead.
That's a mat
no_speculation table added by commit
> > > fec9434a12f3
> > > to arch/x86/kernel/cpu/common.c. Is this intentional? Would a
> > > patch
> > > adding it and possibly other omissions be welcome?
> >
> > Probably. Dave?
>
> IIRC, Alan Cox was
> Oops, I was just doing some testing and thought that correct behavior
> for crafted FS is to return arbitrary valid error code (like -EIO) or
> some arbitrary data, say, not larger than FS (not disclosing the
> kernel memory, of course). Please excuse me if I was wrong. If fixing
> this would slo
> Ugh, I thought glibc got support for it, I guess everyone just
> hand-codes it in their applications for now. Sad.
The glibc people actively contributed to its design and then went radio
silent on the subject.
Alan
> The Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel
> framework is a generic, flexible system that supports thin kernel
> drivers. Gasket kernel drivers are expected to handle opening and
> closing devices, mmap'ing BAR space as requested, a small selection of
> ioctls, and han
On Tue, 26 Jun 2018 11:05:21 +0200
Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 04:11:07PM +0100, Alan Cox wrote:
> > On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote:
> > > On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote:
> > > > Fir
On Fri, 22 Jun 2018 12:28:17 -0400 (EDT)
Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Alan Cox wrote:
>
> > > The other point is a quite pointless assumption that existing scrollback
> > > is
> > > "optimized". Even vgacon mostly uses software scroll
On Wed, 20 Jun 2018 11:44:13 +0900
Linus Torvalds wrote:
> On Wed, Jun 20, 2018 at 11:34 AM Steven Rostedt wrote:
> >
> > Perhaps we should do an audit of the console drivers and remove all
> > printk, pr_* , WARN*, BUG* from them.
>
> Only the actual _printing_ parts.
No because they are no
> The other point is a quite pointless assumption that existing scrollback is
> "optimized". Even vgacon mostly uses software scrollback these days, as the
> amount of VGA display memory is really small.
All of our console driver code is horribly unoptimized for most of
todays hardware. Long ago
On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote:
> On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote:
> > Firmware may contain split locked instructions.
>
> I think that's the wrong attitude. You should mandate in your BIOS
> development guide that Firmware _MUST_NOT_ contain una
> But forward bisection (when bug is fixed) unfortunately won't work
> because these commits are not connected to HEAD. And forward bisection
> is very important, otherwise who will bring order to all these
> hundreds of open bugs?
> https://syzkaller.appspot.com/
Bisection isn't so important when
> It doesn't come as a surprise that recursive printk() calls are not the
> only way for us to deadlock in printk() and we still have a whole bunch
> of other printk() deadlock scenarios. For instance, those that involve
> TTY port->lock spin_lock and UART port->lock spin_lock.
The tty layer code
> + } else {
> + while ((lsr & BOTH_EMPTY) != BOTH_EMPTY) {
> + lsr = serial_in(p, UART_LSR);
> + cpu_relax();
> + }
> + }
This still needs a timeout in case some kind of hardwar
> A malicious program most probably won't care about that. Therefore, my
> next question is: which memory regions can be exploited by a malicious
> program? The complete physical memory or only the memory provided to the
> malicious program? Should be the latter if this approach should have any
> i
> Could you describe the performance degradation? Why is this not a
> "doctor it hurts when I do that" situation?
They already know it hurts - the question is why and where.
Alan
On Thu, 3 May 2018 18:27:14 + (UTC)
Grant Edwards wrote:
> On 2018-05-03, Muni Sekhar wrote:
>
> > If I need to set a custom baud rates(e.g. 14400, 128000, 256000), does
> > Linux serial framework has any supporting method?
>
> Sure, use the termios2 structure instead of the termios stru
On Fri, 2018-05-11 at 17:09 +0200, Julia Lawall wrote:
>
> On Fri, 11 May 2018, Christophe JAILLET wrote:
>
> > The use of 'fail1' and 'fail2' is not correct. Reorder these calls
> > to
> > branch at the right place of the error handling path.
>
> Maybe it would be good to improve the names at t
> > I think memory allocation and io waits can't be decoupled from
> > scheduling as they are now.
>
> The scheduler is not decoupled from either, it is intimately involved
> in both. However, none of the decision making smarts for either reside
> in the scheduler, nor should they.
It belongs
> 2) Compiler transformations can elide binary operations, so we cannot
>rely on source level AND (&) or MOD (%) operations to narrow the
>range of an expression, regardless of the types of either operand.
>
>This means that source-level AND and MOD operations cannot be relied
>upo
On Wed, 25 Apr 2018 22:20:50 +0900
DaeRyong Jeong wrote:
> tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
> by th->used and updates tb->used.
> But tty_insert_flip_string_fixed_flag() can be executed concurrently and
> tb->used can be updated improperly.
The tty input l
> The current kernel driver code looks up the physical address of a page of
> user-allocated memory by traversing the page table, and then writing the
> physical address to the external MMU. If we were to move the driver to
> userspace, this procedure would require exposing the physical address to
> But we don't have the full ACPI interpreter up in the early part of
> the kernel. All these 'early' devices have their own setup/config
> which is the source of the issue. Or maybe I am wrong about the full
> interpreter and the early drivers are just not taking advantage of the
> ACPI device bin
> The primary factor affecting UART throughput is the baud rate, apart
> from this any other factors affect the UART throughput?
UART
CPU power
interrupt latency
all the usual suspects.
> > For 400 bps uart baud rate, what should be the theoretical peak
> data throughput?
>
Depends entire
> so an error on the 1st page gets propagated to the caller,
> and that get_user_pages_unlocked eventually calls __get_user_pages
> so it does return an error sometimes.
>
> Would it be correct to apply the second part of the patch then
> (pasted below for reference) or should get_user_pages_fast
> How? When there are random DMA-capable PCI devices that are driven by
> userland tools that are mmap()ing the BARs out of sysfs, how do we
> simultaneously avoid breaking those devices while also preventing the
> majority of users from being vulnerable to an attacker just DMAing over the
> kerne
> Furthermore, there is a fundamental deviation from common security
> sense here, where things like command line parameters and other
> lockdown specific tunables are blacklisted rather than whitelisted,
I've been complaining about this from the start but it appears to be a
write only authorship
On Wed, 04 Apr 2018 00:12:04 +
Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds
>
> wrote:
> > Still better than telling them to disable/enable secure boot, which
> > they may or may not even be able to to.
>
> Users who can boot a non-vendor Linux distribution on th
> But more importantly, it takes roughly half a second to set up the
> device. I understand, that the probing is part of AHCI(?), and in this
> case the Crucial m4 SSD drive/firmware is especially slow. So, I assume
> it will be hard to improve anything in the code to decrease the time.
Probabl
; Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: Dmitry Vyukov
> Cc: Johannes Weiner
> Cc: Alan Cox
> Cc: Christoph Hellwig
> Cc: Michal Hocko
Seems reasonable to me
Alan
On Tue, 27 Mar 2018 12:05:23 -0400
Mathieu Desnoyers wrote:
> Expose a new system call allowing each thread to register one userspace
> memory area to be used as an ABI between kernel and user-space for two
> purposes: user-space restartable sequences and quick access to read the
> current CPU nu
On Mon, 26 Mar 2018 20:56:45 -0600
Aaron Durbin wrote:
> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox wrote:
> >> Sadly, this situation
> >> is not unique to this hardware. There is hardware all over that does
> >> not meet the current assumptions being made in the
> I suspect a large part of the problem is that our device isn't really
> a PCIe device. It's a PCI device retrofitted with a TI
> XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge. Large numbers of this
That really shouldn't be an issue. Just about every PC up to a few years
ago has something that
> Sadly, this situation
> is not unique to this hardware. There is hardware all over that does
> not meet the current assumptions being made in the early uart drivers
> within the kernel.
Is there any fundamental reason you can't just embed dt entries in the
ACPI table to describe the other featur
> Can we probe safely for this device?
99% of the time yes the inb gives us a straight answer. However (and
we've hit this with port 0x81 for real) there are concerns that some
systems will trap those addresses into SMM and do weirdness that makes
the 0xFF check fail.
Alan
> Please explain WHY 2017 is the cut-off date. I still have no clue how
> that
> is decided aside of being a random number.
Because if it's prior to 2017 then it'll almost certainly have those
registers even if the firmware says otherwise. After that point we
think the firmware is going to give va
On Wed, 07 Mar 2018 13:46:24 -0800
Dave Hansen wrote:
> From: Dave Hansen
>
> I think we need to soften the language a bit. It might scare folks
> off, especially the:
>
>We prefer to fully disclose the bug as soon as possible.
>
> which is not really the case. Linus says:
>
>
> FWIW, alpha and m68k are known boot with qemu (even though m68k
> generates a warning traceback with the mainline kernel).
M68K works - people actively use it. Crazy people true 8). Alpha I
believe one or two people boot. I just need to track down some discs for
my Alpha 8)
Alan
On Wed, 21 Feb 2018 09:03:00 +
> The thing I like about rate limiting (for everyone including root) is
> that it does not break anybody's workflow (unless EFI variable access
> occurs on a hot path, in which case you're either a) asking for it, or
> b) the guy trying to DoS us), and that it can
> Regarding the older architectures I mentioned (m32r, frv, mn10300),
> the situation is a bit different as they don't have the problems with
> build testing but they do have problems with using less of the
> standard interfaces (syscall, timer, gpio, rtc, ...), so they do add
> more to the mainten
> Given this is the current state of the code (it's part of btrfs) I believe
> the following could/should be done:
Is there benchmarking data to show that a custom lock is justified
(especiaally given it's going to mean btrfs and rtlinux don't play
together nicely since it won't be able to see th
1 - 100 of 5522 matches
Mail list logo
