[10:06] <niluje> let's say I create a pipe from a C program: int pipefd[2]; pipe(pipefd); and I write in this pipe: while (1) { write(pipefd[1], "hello", 6); }. The pipe is full. Why do I get the "hello" when running cat /proc/<pid>/fd/4 (4 being the file descriptor corresponding to pipefd[1], which is the *write* part of the pipe)
[10:07] <niluje> Note cat /proc/<pid>/fd/3 returns what is written too
[10:08] <niluje> (to test from a shell, run "yes | sleep 6000" and "cat /proc/$(pgrep yes)/fd/1": it returns the output of yes, even if 1 is the stdout of yes ; I would expect to get the data by reading on the stdin of sleep instead)
[10:11] <apw> that does seem unexpected indeed, though i wonder if that is simply because the flags on the cheat /proc/fd are wrong, ie yes would not be able to do such a read on a write only fd
[10:13] <niluje> apw: sorry, not sure to understand what you think is going on :x
[10:15] <apw> well it depends on how the fd which is handed to you by opening /proc/*/fd/* works, it might be handing you permissions you would not otherwise have
[10:15] <niluje> http://pastie.org/10955046
[10:16] <niluje> ofc read returns -1 there
[10:16] <niluje> :p
[13:16] <ricotz> hello, is there an ETA for a xenial kernel build which includes 4.4.25-4.4.30 ?
[14:59] <piotr_bh> Hi, did anyone try rt-preempt with Ubuntu 16.04 LTS or 14.04 LTS? Are there any web sources, manuals, tests, suggestions available?
[16:47] <rtg> kees, did I discuss staging driver with you wrt to signed module enfocement ? I'm considering stripping signatures from those drivers so that they cannot be loaded in an SB environment.
[17:33] <kees> rtg: I think you mentioned it. do you have evidence that the staging drivers are that much more risky?
[17:33] <rtg> kees, nothing direct, but it stands to reason that nobody is looking for stupid tricks
[17:34] <kees> I'm certainly not opposed to it. I'd actually be interested in having a general tool I could run that would strip signatures during package install so I could whitelist modules
[17:34] <kees> modprobe.conf doesn't work well for whitelisting, but "strip all but these" would be cool
[17:34] <rtg> kees, cyphermox is developing methods for self signing for DKMS. I think it would be useable for staging module as well
[17:35] <kees> cool
[17:35] <rtg> 17.04 is the target release
[17:35] <kees> oh! btw, what do you think of enabling intel_iommu by default? there seem to be some weird bugs around it, but it'd be nice to turn on vt-d by default.
[17:35] <rtg> though I'd like to retrifit for the HWE and GA kernels in Xenial
[17:36] <rtg> kees, do you mean CONFIG_INTEL_IOMMU_DEFAULT_ON ?
[17:36] <kees> yeah
[17:37] <kees> I found these:
[17:37] <kees> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1428121
[17:37] <ubot5`> Ubuntu bug 1428121 in alsa-driver (Ubuntu) "Intel HDMI Audio not working with IOMMU enabled" [Medium,Confirmed]
[17:37] <kees> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634108
[17:37] <ubot5`> Ubuntu bug 1634108 in linux (Ubuntu) "intel_iommu=on causes iwlwifi to fail" [Medium,Confirmed]
[17:37] <kees> those are NOT related to graphics problems, which gives me pause, but booting with intel_iommu=on works for me. :P
[17:38] <rtg> kees, I can look into it
[17:38] <kees> it'd be especially nice for VM hosts, fwiw. less useful for laptops.
[17:40] <rtg> kees, we're gonna have a true virt flavor in the 17.04 cycle that has it's own config, so I can likely enable it there
[17:42] <kees> rtg: is that a guest kernel or a host kernel? I mean, probably fine in guest too, but likely the MOST useful in host.
[17:43] <rtg> kees, likely focused on guest
[17:52] <rtg> kees, hmm, given the impact of that setting on some desktops we might have to add intel_iommu=on to the the kernel command line for server virt images unless upstream can figure out why it is causing issues.
[17:53] <kees> rtg: yeah, that's probably the better idea. I'm disappointed that intel's iommu support is so poor. :(
[18:09] <phil42> when i change my name i will be Gart Iommu
[18:11] <zma> how do I find out what Linux kernel version does 4.4.0-45 map to? thanks
[19:57] <ricotz> rtg, hi, is there an ETA for a xenial kernel build which includes 4.4.25-4.4.30 ?
[19:59] <ricotz> zma, you can look at https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/
[19:59] <ricotz> which would be 4.4.21
[21:17] <zma> @ricotz, thanks. I'm waiting for 4.4.22 or newer landing in, but right now apt-get update && apt-cache show linux-image-generic-lts-xenial shows 4.4.0-45 being the latest available
[21:30] <apb1963_> I wonder if there's a way to replace the running kernel without having to reboot the machine.
[21:32] <apb1963_> Something similar to how graphics cards allow you to redraw the display before you actually show it to the user and the user only sees it when you toggle the card over to it so it looks instantaneous to the user when it's not really.
[21:33] <trippeh> apb1963_: kexec allows you to skip the bios/grub bits, but its still a boot.
[21:33] <trippeh> it is possible to apply minor patches live, however.
[21:35] <apb1963_> well... I'm thinking more along the lines of replacing one running kernel with whatever comes down the pike in an apt-get dist-upgrade.
[21:36] <apb1963_> So my applications would continue to run, they would simply to whatever re-registrations were necessary to the new kernel.
[21:36] <apb1963_> s/simply/simply re-register/
[21:37] <apb1963_> if that makes any sense :)
[21:37] <trippeh> from an application point of view CRIU may work, ie checkpoint/restore
[21:37] <trippeh> but otherwise, nothing like that in linux
[21:37] <apb1963_> hmmm.  I don't know.  Maybe.  I suppose if it were seamless to the user.
[21:38] <apb1963_> The idea is to toggle over like the graphics card does.
[21:39] <apb1963_> OK, nothing exists now... is it possible to create what I'm suggesting?
[21:40] <apb1963_> Sort of a hot-swappable kernel :)
[21:41] <trippeh> I dont really know, but I'm pretty sure it would be a big undertaking.
[21:41] <apb1963_> Anything worthwhile usually is :)
[21:42] <trippeh> currently you can only swap out very small parts (like what canonicals livepatch service does)
[21:43] <trippeh> mostly to plug invidual bugs
[21:43] <apb1963_> Although truthfully... I don't think it would be all that hard.  It's a matter of pointing your applications at a different kernel... something linux already does.  networking always seems to be the most difficult part of the bootup equation.
[21:45] <apb1963_> And of course doing whatever kernel things need to be done to recognize those applications.  A "hot hand-over".
[21:47] <apb1963_> I don't know what livepatch does, but I can only assume it overwrites pieces of the kernel that are exactly the same size.. so it changes a 1 to a 0 for example... but no real idea how it works.  This would be different.  You'd have to read a new file (the kernel) into a separate "isolated" portion of memory for starters.
[21:48] <trippeh> some router vendors do a handover using virtual machines, but that is very application specific.
[21:51] <apb1963_> well... i'm not familiar with the complete boot process.. but I know a ram disk is made to speed it up.  Why not do the same thing with the new kernel, prior to rebooting.  Then the cpu is instructed to swap kernels.  I think that might be a sticking point.
[21:53] <apb1963_> Ah.  But if you have multiple cores...one could be instructed to run the new kernel and once it takes over, the other core repeats the process.
[21:54] <apb1963_> So that seems to resolve the hot swap from kernel to kernel as far as the cpu is concerned... all that remains is to register the applications and system services to the new kernel
[21:56] <apb1963_> I think it could be done.... maybe someone else will take these ideas and come up with something.  I'll let you all cogitate.
[22:43] <apw> the key problem is that the kernel exists to maintain that state, the state of the application, it is a non-trivial task to reload that
[22:44] <apw> that being what criu does, and it is at best hard, and only works for a subset of applications thus far