On Fri, 22 Jul 2016 17:28:13 +1000
Greg Ungerer wrote:
> On 22/07/16 00:48, Nicolas Pitre wrote:
> > On Thu, 21 Jul 2016, Greg Ungerer wrote:
> >> Hi Nicolas,
> >>
> >> On 21/07/16 05:22, Nicolas Pitre wrote:
> >>> This series provides the necessary changes to allow "flat" executable
> >>> bi
On Mon, 20 Jun 2016 11:29:28 +0200 (CEST)
Jiri Kosina wrote:
> On Fri, 17 Jun 2016, Srinivas Pandruvada wrote:
>
> > > > +config INTEL_ISH_HID_TRANSPORT
> > > > + bool
> > > > + default n
> > > > +
> > > > +config INTEL_ISH_HID
> > > > + bool "Intel Integrated Sensor Hub"
> > >
>
> The fix in the DKMS package you referenced was not written by
> Canonical but by ALPS, as it came from them I think it is reasonable
> they send it to upstream, isn't it? As you can see the patch is non-trivial.
You published it on to milliosn of users, you'd think also mentioning its
existence
> I wonder if it would just be simpler to make it be a CONFIG option
> which causes the irq value to zero in arch/x86/include/asm/serial.h?
That assumes x86 and legacy ports.
For modern boxes its data from elsewhere Devicetree folks can just set
up their devicetree that way, the ACPI afflicted ca
> Serial consoles are already polled for output. So nothing should
> care until userspace starts, and the full serial driver initializes.
At which point it hangs
> So I suspect either "irqfixup" or "irqpoll" would handle this for you.
> If not I am certain a small tweak to some of that code woul
O
> +static int f81534_set_normal_register(struct usb_device *dev, u16 reg, u8
> data)
> +{
> + size_t count = F81534_USB_MAX_RETRY;
> + int status;
> + u8 *tmp;
> +
> + tmp = kmalloc(sizeof(u8), GFP_KERNEL);
> + if (!tmp)
> + return -ENOMEM;
You end up doing huge
> It might make sense to filter non-shared edge triggered interrupts out
> of irqpoll for that reason. Anything that supports a level triggered
> interrupt should be fine.
That would also break some platforms that use it today 8(. We'd need
another irqpoll mode - at which point being able to forc
On Wed, 14 Sep 2016 09:59:42 +0200
Jiri Slaby wrote:
> On 09/09/2016, 12:35 AM, Kees Cook wrote:
> > The ptmx_fops structure is only changed during init, so mark it as such.
>
> Right, but I am missing what is the benefit? You would have to elaborate
> here...
The pages end up marked read onl
On Thu, 15 Sep 2016 14:14:30 +0200
Pavel Machek wrote:
> Hi!
>
> > - Feature is enabled by default for single socket systems
> >
> > With Intel® Turbo Boost Max Technology 3.0 (ITMT), single-threaded
> > performance is
> > optimized by identifying processor's fastest core and running critical
On Thu, 15 Sep 2016 16:19:52 +0300
Andrey Utkin wrote:
> On Thu, Sep 15, 2016 at 03:15:53PM +0200, Hans Verkuil wrote:
> > It could be related to the fact that a PCI write may be delayed unless
> > it is followed by a read (see also the comments in
> > drivers/media/pci/ivtv/ivtv-driver.h).
>
> firmware framebuffer in early boot until a real driver takes over. It's a
> replacement really for all the various uefi/vesa/whatever fbdev drivers.
> Full reliance on the firmware very much intended.
Most of those have firmware interfaces for things like colour setting and
hardware scrolling. I
On Wed, 24 Aug 2016 11:22:09 +0300
"Dan Akunis" wrote:
> When select wakes up on a UDP socket, user is expecting to get data. Getting
> 0 from recvfrom() or whatever read function she uses, is a wrong attitude.
> I agree with David.
>
> The unit test that expects select to wake up is wrong and
On Mon, 22 Aug 2016 17:39:09 -0500
Rob Herring wrote:
> tty_port_open handles much of the common parts of tty opening. Convert
> uart_open to use it and move the serial_core specific parts into
> tty_port.activate function. This will be needed to use tty_port functions
> directly from in kernel c
> So you mean if I do "hciconfig hci0 down", then the uart-bus should
> "down" the tty and only on "hciconfig hci0 up" it should "up" the
> tty? I would expect a uart-bus slave-device takes control of the
> device ("up" it) on probe. It's hardwired anyway.
Today you can switch stacks at runtime, y
> > I see someone did request it 2 years ago:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63479
>
> I don't think this is sufficient. Basically if you write one field in a
> struct after a memset again, the compiler is allowed by the standard to
> write padding bytes again, causing them to
> Either we'd have to call tty_port->rx a character at a time or
> implement some temporary buffer. I don't think we want to call things
> like BT receive code a byte at a time. This needs to be a layer
> higher. flush_to_ldisc either needs to be duplicated to handle
> tty_port->rx or generalized t
On Sat, 6 Dec 2014 13:00:17 +
Grant Likely wrote:
> On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek wrote:
> > Hi!
> >
> >> * /sys/class/fpga_manager//firmware
> >> Name of FPGA image file to load using firmware class.
> >> $ echo image.rbf > /sys/class/fpga_manager//firmware
> >
> > I ..
> I agree with the view that a FPGA is something that can get reprogrammed a
> lot.
> That's a flexibility we want to use. I don't see a problem with using
> firmware
> to do the programming as long as we have a lightweight interface where we can
> load an image, use it, then later reset the FGP
On Tue, 9 Dec 2014 14:14:48 -0600
> +Contact: Alan Tull
> +Description: Read state of fpga framework state machine as a string.
> + Valid states may vary by manufacturer; superset is:
> + * unknown = can't determine state
> + * power_off
On Tue, 6 Jan 2015 08:34:07 +0800
xiaomin1 wrote:
> misc_mtx was used to mutex misc_list.
> But file->f_op->open may be blocked by downloading
> firmware in some devices' open.
> So move file->f_op->open out of mutex (misc_mtx)
> in misc_open to avoid this block.
> It also make code more efficie
> Yes, x86 has the bogomips thing, and it switched to using a TSC. I'm
> willing to bet that on x86, the reported bogomips value is pretty similar
> whether it's using the TSC or whether it's using a software timing loop.
Roughly yes. It's a completely dumb number anyway because any loop timing
b
On Sun, 4 Jan 2015 15:11:51 +0800
Feng Tang wrote:
> There is user case that user only knows the ion_handle idand
> needs to get the physical addr and len. So add this wrapper to
> meet this requirement.
What is the in-tree upstream user of this new function ? I don't see one
in your patches ?
> It would be really nice if the uart would register the line disciple as a
> child device, then the line discipline would register whatever it wants.
For almost every case this doesn't work. You need a tty interface as well
because thats how you manage it.
> But that isn't how it works. The lin
> I tried in all ways to implement this with mmap(), but it does not success,
> because I did not find a way to mmap() file as O_WRONLY. Mapping as O_RDWR
> makes kernel to pre-fill mapped memory with partition data. So, kernel and
> DMA actually compete on the RAM area to fill it - one with garbag
> In the meantime, I created test that actually uses physical memory,
> 8MB apart, as described in some footnote. It is attached. It should
> work, but it needs boot with specific config options and specific
> kernel parameters.
Why not just use hugepages. You know the alignment guarantees for 1GB
On Thu, 18 Dec 2014 18:47:12 +0100
Sebastian Andrzej Siewior wrote:
> This patch invokes add_preferred_console() with ttyS based on ttyO
> arguments if the user didn't specify it on its own. This ensures that
> the user will see the kernel booting on his serial console in case he
> forgot to upda
> anywhere in that translation unit. After all, any non-static function
> in that translation unit might be called from some other translation
> unit that -did- use locking or whatever.
>
> I will let you know how it goes. ;-)
It breaks DEC10 ;-)
If there is kickback over things like optimisat
> 2.a. If task A has sufficient capabilities to send signals to task B, then
> task A is already in position to do anything it wants with task B, including
> killing it outright.
Not entirely true.
- We have securirty models like SELinux
- We have namespaces and being able to send an fd between
On Wed, 3 Dec 2014 11:41:44 +0100
Richard Cochran wrote:
> On Wed, Dec 03, 2014 at 09:17:37AM +0100, Richard Weinberger wrote:
> > Come on guys, get a cup of coffee and relax a bit...
>
> I am relaxed, especially after I had a good laugh reading this:
>
>On a less related note, I hope you w
On Mon, 1 Dec 2014 19:51:18 -0600
Felipe Balbi wrote:
> On Tue, Dec 02, 2014 at 01:13:38AM +0200, Aaro Koskinen wrote:
> > Hi,
> >
> > On Mon, Dec 01, 2014 at 02:09:14PM +, One Thousand Gnomes wrote:
> > > > Well the nightmare userspace switch f
> The functions above are fine for a generic manufacturer bitfile loader,
> ie Xilinx GPIO twiddling, Altera JTAG, Zynq DMA, etc.
>
> But wrappered around that should be another set of functions that are
> bitfile specific.
And also a transport layer. You can have the same FPGA with the same
load
On Mon, 12 Jan 2015 11:06:08 -0700
Jason Gunthorpe wrote:
> On Sun, Jan 11, 2015 at 10:29:00AM -0600, atull wrote:
> > the FPGA image. If someone wants there to be only one FPGA image on
> > the FGPA forever, they will probably not be using this framework; their
> > FPGA will probably be loaded
On Mon, 12 Jan 2015 14:43:14 -0700
Jason Gunthorpe wrote:
> On Mon, Jan 12, 2015 at 09:01:34PM +0000, One Thousand Gnomes wrote:
> > There are plenty of people today who treat the FPGA as an entirely
> > dynamic resource. It's not like flashing a controller, its near
> >
On Tue, 13 Jan 2015 17:16:42 -0800
"Felipe F. Tonello" wrote:
> This driver will basically translate serial communication to i2c communication
> between the user-space and the GPS module.
>
> It creates a /dev/ttyS device node.
It shouldn't. It should use its own name. (ttyubl or something .. )
> Those people have failed to show up and provide input and/or code.
That doesn't excuse failing to design the code properly.
>
> >> It is one thing to context switch a maths algorithm that is built to
> >> be stateless, it is quite another to context switch between, say an
> >> ethernet core wi
> The request_firmware interface should be for the DT overlay path, and
> other schemes shouldn't use it. The name should come from the DT and
> no place else.
For the static bindings agreed (or ACPI but that's a detail) or other
dynamic discovery post boot.
> 2) The bootloader starts the kernel
> Just wanted to point out something :-
>
> Quoting from makelinux website :-
> http://www.makelinux.net/books/lkd2/ch17lev1sec8
>
> "The sysfs filesystem is currently the place for implementing
> functionality previously reserved for ioctl() calls on device nodes or
> the procfs filesystem. The
Which kernel did you see the write_room oops ? and I'll double check its
all fixed.
> >> + ublox_gps_i2c_client = client;
> >> + ublox_gps_filp = NULL;
> >> + ublox_gps_tty_port = NULL;
> >> + ublox_gps_is_open = false;
> >
> > There are some other i2c based tty drivers in the kern
On Wed, 14 Jan 2015 11:12:58 -0700
Jason Gunthorpe wrote:
> On Wed, Jan 14, 2015 at 04:06:17PM +0000, One Thousand Gnomes wrote:
>
> > and I think you effectively have the user usage covered here for such
> > things. It much like GPIO pins - we can describe them but we can als
On Thu, 15 Jan 2015 11:47:26 -0700
Jason Gunthorpe wrote:
> It is a novel idea, my concern would be that embedding the FPGA in the
> DT makes it permanent unswappable kernel memory.
> Not having the kernel hold the FPGA is best for many uses.
If you have a filesysytem before the FPGA is set up th
gt;> > On Mon, Jan 05, 2015 at 11:50:04AM -0800, Andy Lutomirski wrote:
> >> >> On Mon, Jan 5, 2015 at 11:23 AM, One Thousand Gnomes
> >> >> wrote:
> >> >> >> In the meantime, I created test that actually uses physical memory,
> >> &
On Mon, 5 Jan 2015 22:09:45 -0500
Peter Hurley wrote:
> Some arches have no need to create unprobed 8250 ports; these phantom
> ports are primarily required for ISA ports which have no probe
> mechanism or to provide non-operational ports for userspace to
> configure (via TIOCSSERIAL and TIOCSER
On Wed, 7 Jan 2015 15:01:36 +
Catalin Marinas wrote:
> On Wed, Jan 07, 2015 at 01:20:06AM +, Linus Torvalds wrote:
> > On Tue, Jan 6, 2015 at 3:42 PM, Catalin Marinas
> > wrote:
> > >>
> > >> That's what bogomips *is*, for chrissake! It's a bogus measure of how
> > >> many times you go
> Is sysfs 'supposed' to be a read only where various kernel parameters
> are exposed to be read ? Or are they 'supposed' to be writable too ?
You can create either
> Are all drivers in future required to expose interfaces in sysfs ?
Only if they need one (some will appear automatically as you e
On Wed, 7 Jan 2015 14:20:14 -0300
Ezequiel Garcia wrote:
> From: Naidu Tellapati
>
> The Pistachio SOC from Imagination Technologies includes a Pulse Density
> Modulation DAC which produces a form of analogue output according to the
> relative density of output pulses to the intended analogue s
> One idea that has come up in the past but never saw an implementation
> is to make the ttyS namespace and minor numbers completely generic and
> let any serial port driver use it. This would be a major rework, but
> have the added advantage of cleaning up a number of other namespace
> issues as w
> Then configure udev to load right firmware for you, or ln -s
> image-i-want-now socfpga-fpga-image to select the one to read...?
Your conceptual model is wrong. FPGA firmware is dynamic. There are
already people who lazy reload FPGA firmware on taskswitches. This
proposed fpga manager is broken
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
What if you've not been given a resource ?
Otherwise looks fine to me
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
On Tue, 20 Jan 2015 09:13:59 +0800
> That's because people have not done anything really needing performance
> on the desktop over D-Bus in the past due to how slow the current
> implementation is.
The desktop is a performance critical environment, even though certain
desktop developers think 2GB
On Thu, 19 Mar 2015 14:09:29 +0300
Michael Tokarev wrote:
> Half a year passed since my first email in this thread, and current kernels
> (4.0-tobe) still does not work properly. Meanwhile, I found this thread:
> http://www.linuxquestions.org/questions/slackware-installation-40/black-screen-on-i
> Yes, with video=LVDS-1:d boot parameter, kernel boots fine and there is
> graphics/video output on the screen, with the following message from kernel
> when loading gma500_gfx:
>
> [6.472859] [drm] forcing LVDS-1 connector OFF
>
> (and a few others).
>
> There's one funky thing still -- th
> > - Access to the capability bits is guarded with PTRACE_MAY_READ
> > kdbus does not honor that and thus leaks information.
>
> Now, this is likely not a real problem.
>
> Yes, when you try to read other processes capabilities, you need
> PTRACE_MAY_READ to see them. HOWEVER, that's not reall
> Yes, I think we've all agreed we can do it ... it's now a question of
> whether we can stomach the ick factor of actually initiating a
> transaction in close ... I'm still feeling queasy.
NFS does transactions - including figuring out if the data will fit - on
file close. It does that for real d
> Alan, and others, want a tiny, generic, multi-cast IPC method that also
> works across networks. They feel that this is something that D-Bus
I never said - across networks. And locally it has been done, even
microcontrollers have done it.
> Lots of people have said they want something like thi
On Wed, 15 Apr 2015 00:39:22 +0200 (CEST)
Jiri Kosina wrote:
> On Tue, 14 Apr 2015, Greg Kroah-Hartman wrote:
>
> > I don't understand. You can not like the D-Bus model (and accordingly
> > the X11 model),
>
> I thought that the general hatred level of the X11 "model" and the
> protocol lead
> To quote the email that he wrote:
> The reason is that dbus views the world in a stateful way
> assuming that connections, and name ownership, can be tracked
> reliably. This is different from say http, and it's one reason
> that people used to Internet-oriented protocols
> Look, us kernel developers only work on one huge, multithreaded, global
> state binary. Our experience in multi-application interactions with
> shared state and permission requirements is usually quite limited. If
> you don't trust the developers of those programs outside the kernel,
> don't us
> > There is no comparison between the elegance of X11 property setting and a
> > chunk of proposed kernel code that is half the size of a tiny X server!
>
> Hey, take that up with Havoc, he made the comparison :)
And it concerns me you blindly repeat it without realising its wrong.
> > The dbus
On Wed, 15 Apr 2015 14:09:24 +0200 (CEST)
Jiri Kosina wrote:
> On Wed, 15 Apr 2015, Greg Kroah-Hartman wrote:
>
> > 'systemctl reboot' calls a bunch of other things to determine if you
> > have local access to the machine, or permissions to reboot the machine
> > (i.e. CAP_SYS_BOOT), and other t
> operating systems anymore. Those "legacy" oses provide a system bus
> that allows them to send thousands of queries just fine, but when moving
> to Linux, we don't have anything other than D-Bus, so their library is
> ported to use it, and they have to handle their old applications that
> need/w
On Wed, 15 Apr 2015 17:41:28 +0200
Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
Even ext4 is still broken for 2038.
> larger value. When the maximum is reached in normal t
On Wed, 15 Apr 2015 19:55:15 +0200
Greg Kroah-Hartman wrote:
> On Wed, Apr 15, 2015 at 01:20:37PM -0400, Steven Rostedt wrote:
> > > I don't know too many other kernel features/drivers that have taken this
> > > long, or done this "slowly", do you?
> >
> > What other features/drivers that you kn
On Wed, 15 Apr 2015 19:31:45 +0200
> Don't make idle comments, the tty layer is far more complex and larger
> than the kdbus code, with much nastier issues and problems. And we
> handle that just fine :)
The tty layer is the way it is because of design decisions dating back 20
years that were (wi
> When trying to split apart problems, for dbus it's important to keep
> ordering guarantees.
Yes I assumed that - minus disconnection/reconnect and running out of
queue space. Some users also want priority queueing (with or without the
guarantee for the same priority). Many of the other systems t
On Wed, 15 Apr 2015 11:28:58 -0700
Linus Torvalds wrote:
> On Wed, Apr 15, 2015 at 11:18 AM, Linus Torvalds
> wrote:
> >
> > I've seen this claimed, but I have never seen any actual numbers. What
> > speeds up? By how much? is it actually measurable?
>
> And just to clarify: by "what speeds up,
> The reason that 'everyone who works in this area' adopted is not as much
> that the design is sound (I'm not arguing whether it is or isn't in this
> case) as it is that none of them could come up with anything better.
Actually most message passing code uses things like JMS and the various
MQ
> And so does kdbus. By default, strict ordering is enforced when messages
> are received, but optionally, that action may be constrained to messages
> of a minimal priority. This allows for use cases where timing critical
> data is interleaved with control data on the same connection. That's
> des
> We really don't want to have this unmaintainable mixture of:
>
> 128-bit support
>64-bit support (legacy mode)
>32-bit support (compat mode)
>16-bit support (vm86 mode)
> 8-bit support (UART mode)
>
> ... all in the same kernel!
I think a lot of us working
On Fri, 24 Apr 2015 13:08:25 +0530
Sudip Mukherjee wrote:
> On Fri, Apr 24, 2015 at 09:26:08AM +0200, Greg KH wrote:
> > On Fri, Apr 24, 2015 at 12:20:26PM +0530, Sudip Mukherjee wrote:
> > > > What does ddev stand for? Anyway, it's probably better to call it
> > > > bus_dev?
> > > ok.
> > > I t
> +static int parport;
> +module_param(parport, int, 0);
> +MODULE_PARM_DESC(parport, "The parport to be used, default parport0\n");
Minor suggested enhancement: this ought to be an array so you can attach
multiple instances to a system.
Alan
--
To unsubscribe from this list: send the line "unsub
> for your testing I think you will need paride and pcd, I was looking at
> them now, but i suppose it will be little tricky to convert them as it
> is doing its own probing of the parallel port based on the base address.
> I will convert it and give you a patchset for your testing latest by
> mond
> But this is not how authorization with polkit works (or anything
> similar to polkit). The authorization-framework is totally separated
Thats a detail which is changeable
> from the client that accesses a service. The client asks a service
> provider to perform an action. The service provider t
> I can't remember any off the top of my head, but it does say explicitly
> in the GCC manual to be careful with -O3. IIRC, most of the issues
> relate to -O3 enabling -ffast-math (which tends to really mess with code
> that expects strict IEEE 754 compliance), so it may not be as much of an
>
> Unfortunately, the Cadence MACB doesn't support the enabling or
> disabling of checksum generation per descriptor.
So how does packet forwarding work ? If that means the device is
re-checksumming packets it is forwarding then that's really not very good
at all, especially if it takes frames that
On Thu, 30 Apr 2015 10:48:09 +0300
Eyal Reizer wrote:
> tty_hci driver exposes a /dev/hci_tty character device node, that intends
> to emulate a generic /dev/ttyX device that would be used by the user-space
> Bluetooth stacks to send/receive data to/from the WL combo-connectivity
> chipsets.
We
> > Obviously my patch isn't the real solution, the real solution is to
> > make the new function calls use a consistent 64-bit type, or figure
> > out what in my code path is calling these functions and check it for
> > value sanity.
I would be tempted to do both computations and print then input
On Thu, 30 Apr 2015 16:14:06 +0200
"gre...@linuxfoundation.org" wrote:
> On Thu, Apr 23, 2015 at 04:09:28PM +0100, Alan Cox wrote:
> > On Thu, 2015-04-23 at 13:43 +, Gujulan Elango, Hari Prasath (H.)
> > wrote:
> > > This patch removes unwanted semicolon around close braces of code blocks
> >
> On top of that, I think that someone into resource management needs to
> seriously consider whether having a broadcast send do get_user_pages
> or the equivalent on pages supplied by untrusted recipients (plural!)
> is a good idea.
Oh but its so much fun if you pass pages belonging to a device d
> Um, no, they go through the kernel for that model as well, same
> interface, it just depends on the type of message that you are sending
> as to who the recipients are (single or more than one.)
In other words its bog standard classic network layer multicasting. You
don't need much policy for th
> Besides, old code is somewhat like an ancient building. Yes, it needs to be
> kept in a good shape, but you won't replace bricks in it just because they are
> old, will you?
When they matter to the integrity and they are likely to be full of
internal cracks and holes you do.
What concerns me m
On Thu, 9 Apr 2015 13:46:27 +0200
Quentin Lambert wrote:
> Replace occurences of the pci api by appropriate call to the dma api.
>
Drivers/ide is obsolete. It probably ought to go at this point but even
so it exists solely in case of a problem or compatibility issue with
drivers/ata. Cleaning
On Fri, 12 Jun 2015 13:43:27 -0700
Greg KH wrote:
> On Fri, Jun 12, 2015 at 10:20:38PM +0200, julien.de...@gmail.com wrote:
> > From: Julien Dehee
> >
> > comedi/comedi_fops.c
> > use ENODEV following open manual
That should probably be ENXIO by a strict reading, but Linux has always
used
> [1] Yes, it doesn't buy all that much, since if the system is rooted
> the adversary can just replace the kernel in /boot and force a normal,
> slower reboot, but the same could be said for signed modules --- the
> adversary could just replace all of /boot/vmlinux- and
> /lib/modules/. But both
> not true, with a proprietary bios it's a clear "pay this much money and don't
> worry about it" while with GPL there's a nagging fear that someone you never
> heard of may sue you a decade from now claiming you need to give them the
> source
> to your OS.
Not really no - the number of compan
> facts in a dts file. The GPL’d files aren’t stopping anybody from creating
> proprietary software. People that really care will rewrite the files
> from scratch anyway. People that don’t care.. well, one need look
> no further than the difficulty of getting source code to different SoC
> support
On Thu, 4 Jun 2015 13:05:49 +0800
"linux" wrote:
> Dear Tejun Heo,
>
> This is HighPoint Linux Team. We found Linux AHCI driver since kernel 3.16
> has added ID (0x06421103) to support RocketRAID 642L which is not what we
> expected. If we want to load HighPoint RR642L RAID version Linux SCSI
> Remove the low_latency rx steering from tty_flip_buffer_push();
> however, leave the knob as an optional hint to drivers that can
> tune their rx fifos and such like. Cleanup stale code comments
> regarding low_latency.
>
> [1] https://lkml.org/lkml/2014/2/20/434
>
> Reported-by: Beat Bolli
>
> BUG() normally causes a fault and we print helpful messages before killing
> the task, and gcc knows we never continue because of the
> __builtin_unreachable() annotation.
>
> If BUG() is defined as 'do { } while (0)' in the example above, we get
> a warning because the function may end without
On Sat, 22 Feb 2014 17:02:32 -0800
"David E. Box" wrote:
> From: "David E. Box"
>
> Add iosf_mbi_available function for loadable modules.
> Add dummy functions to prevent symbol lookup errors on loadable modules.
> Clarify that the write opcode is to be used for iosf_mbi_modify().
> Changes Kco
> This is a complete pointless test. Use a bog standard 8250 UART on the
> PC and connect a microcontroller on the other end which serves you an
> continous stream of data at 115200 Baud.
>
> There is no way you can keep up with that without the low latency
> option neither on old and nor on new m
On Mon, 24 Feb 2014 05:21:43 -0800
"H. Peter Anvin" wrote:
> On 02/24/2014 05:19 AM, One Thousand Gnomes wrote:
> >
> > Other than _available I would have expected all the others to resolve to
> > returning an error or doing a WARN() in the not compiled in case.
&g
On Tue, 25 Feb 2014 02:45:57 -0800
"H. Peter Anvin" wrote:
> On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> > Pentium M is PAE capable but does not indicate so in the CPUID response.
> > This is an issue now that some distributions are no longer shipping
> > non-PAE kernels (those distribution
On Mon, 24 Feb 2014 06:26:52 -0800
Greg Kroah-Hartman wrote:
> On Mon, Feb 24, 2014 at 03:03:25PM +0100, Michal Simek wrote:
> >
> > BTW: Isn't this a good topic for kernel-summit? :-)
>
> No, lawyers don't go to the summit, developers do.
More of a topic for the LF. Particularly as any attemp
> The reason I mention it is because I've been mulling over something
> Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked
> at the Q&A session whether we could do a release with just stability
> and bug-fixes, and I pooh-poohed it because I didn't see most of us
> having the atte
> So 32-bit x86 is dead, dead, dead. There's absolutely no future to it.
> We're not adding new stuff to "future-proof" it.
I think you underestimate how long it'll be present given the advantages
of 32bit in certain situations like very very small devices. Intel is
still releasing new 32bit proce
On Thu, 13 Mar 2014 20:33:06 +1100 (EST)
James Morris wrote:
> On Wed, 12 Mar 2014, Kees Cook wrote:
>
> > On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett
> > wrote:
> > > On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote:
> > >
> > >> Ok, which tree should take this? I'm happy to, altho
On Thu, 13 Mar 2014 15:59:24 +
Matthew Garrett wrote:
> On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote:
>
> > I'll take it, but there's unanswered review feedback (your response to the
> > first question), and Alan raised some doubts about the patches which I'm
> > not sure have bee
> On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
> functionality - firmware loading and the fibmap ioctl are probably the
> most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
> userspace expectations, so we're kind of stuck there.
Actually I know how to
On Thu, 13 Mar 2014 21:30:48 +
Matthew Garrett wrote:
> On Thu, 2014-03-13 at 21:24 +0000, One Thousand Gnomes wrote:
>
> > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> > trivially and in a fashion well known and documented.
>
> How?
> Creating yet more kernel threads to solve this problem is a bit sad.
> Is there no way in which we can borrow one of the existing threads?
schedule_work()
Surely that's all we need, if we get bunged up for a bit then it ends up
on a work queue item and everyone with a billion disks and a 9600
1 - 100 of 786 matches
Mail list logo
