=== shuduo_ is now known as shuduo
[08:42] <pixel6692> Hello is there way to get/make/build linux-image-extra for 4.5 (15.10)? I need aufs module and I also need to use 4.5 because of my ethernet driver
[09:06] <xnox> pixel6692, usually one can find ethernet driver as a dkms module on e.g. github and use that with 15.10 kernel.
[09:06] <xnox> pixel6692, note that e.g. even 16.04 has 4.4 kernel, but with some backports
[09:10] <pixel6692> I am currently running 4.5 from here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/ I just need aufs module
[09:10] <pixel6692> that is typicaly in package linux-image-extra (which is not in this tree), I am trying to build it with this module now
[09:11] <pixel6692> my ethernet driver was repaired in 4.5
=== xnox_ is now known as xnox
=== psivaa_ is now known as psivaa
=== inaddy_ is now known as inaddy
=== TJ_Remix is now known as TJ-
[14:19] <cryptohwlinuxhel> what function can I use from the kernel to copy a __user pointer to another __user pointer? can I just do memcpy?
=== shuduo is now known as shuduo-afk
[14:36] <apw> cryptohwlinuxhel, it seems unintuitive to want to copy userspace to userspace (within the same process) in a system call, i beleieve you cannot use mempcy as the kernel handles faults for userspace addresses differently if you are in a call it expects to touch userspace
[14:37] <cryptohwlinuxhel> yeah there is a flag I have to set to bypass what my driver does
[14:38] <cryptohwlinuxhel> so the bypass is to simply do a memory copy from one _user pointer to another
[14:38] <cryptohwlinuxhel> it cannot be done from outside the kernel since it is a driver
[14:38] <cryptohwlinuxhel> also the kernel gives this flag a shared common memory that all processes can see
[14:39] <cryptohwlinuxhel> so what can I use if I cannot use memcpy?
[14:40] <cryptohwlinuxhel> I can always allocate local memory copyfromuser to my local buffer and then copytouser from my buffer but that is not efficient and I would like to avoid it
[14:43] <apw> i am not sure there is one, but i have not looked, you will find copyfromuser etc are marked specially as copiers, so you could look at what other calls are the same
[15:00] <cryptohwlinuxhel> what do you mean they are marked as copiers?
[15:01] <cryptohwlinuxhel> http://lxr.free-electrons.com/source/arch/arm/include/asm/uaccess.h#L552
[15:01] <cryptohwlinuxhel> I see no markings
[16:25] <tych0> i'm trying to build a kernel from xenial's current master, and i'm getting, http://paste.ubuntu.com/15633017/
[16:25] <tych0> any ideas?
[16:47] <genkgo> jsalisbury: nice achievements again on the backup issue
[16:48] <jsalisbury> genkgo, getting closer.  I may have to perform a bisect of the entire tree, which will take a few more days of testing
[17:00] <pesari> hey, have you seen this with xenial-proposed 4.4.0-17 ? https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1564951
[17:00] <ubot5`> Launchpad bug 1564951 in systemd (Ubuntu) "systemd-timesyncd: Failed to call clock_adjtime(): Invalid argument" [Undecided,Confirmed]
[17:02] <genkgo> jsalisbury: i am really really wondering what it is
[17:02] <genkgo> jsalisbury: probably nobody ever thought of
[17:02] <genkgo> *something
[17:02] <genkgo> and might fixes other things too
[17:08] <jsalisbury> genkgo, Yeah, it isn't any of the hv commits or virtio commits between these two releases.  That's why sometimes a bisect is needed to identify the real offending commit.
[17:09] <genkgo> jsalisbury: the virtio commits are also not the problem?
[17:09] <jsalisbury> genkgo, no.  I built a test kernel with them all reverted and I still hit the bug in about an hour.
[17:09] <genkgo> ok
[17:12] <kamal> tych0, your problem there is (I think) that you're trying to build with just 'make' ...  to build an Ubuntu kernel, follow the "Building the kernel" instructions here:
[17:12] <kamal> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[17:12] <kamal> specifically:
[17:12] <kamal> fakeroot debian/rules clean
[17:12] <kamal> fakeroot debian/rules binary-generic
[17:13] <tych0> kamal: ah, interesting, ok
[17:14] <kamal> tych0, that ^^ will build security/apparmor/ just fine.    (whereas, with bare 'make', the thing you reported is indeed the first failure I get too).
[17:14] <tych0> interesting; it used to work with make bindeb-pkg before that patch :)
[17:14] <genkgo> jsalisbury: thanks, looking forward to the end result! you must tired of all these backups by now ;)
[17:14] <tych0> although perhaps i was doing something horribly wrong
[17:15] <jsalisbury> genkgo, heh, not tired yet.  It too much of a fun puzzle.  The wait while testing is the pain.
[17:16] <genkgo> jsalisbury: hehe, alright. glad to hear you still got the spirit!
[17:16] <kamal> tych0, hmmm.  well if it used to work (when exactly?) then it probably should still -- maybe we actually do have a new glitch to sort out.
[17:16] <tych0> kamal: yeah, it used to work as of a few weeks ago with the xenial kernel's master
[17:16] <tych0> let me look for the exact ref
[17:17] <jsalisbury> genkgo, We'll get to the bottom of this. 
[17:17] <tych0> kamal: f35781cd96795075436fde15abfc1b94bdffb99c
[17:18] <kamal> tych0, yup, you've got a point there!
[17:19] <tyhicks> tych0: looks like this would do it: https://paste.ubuntu.com/15634420/
[17:20]  * tych0 builds
[17:21] <tych0> tyhicks: but yeah, that looks suspicious :)
[17:22] <tych0> tyhicks: yeah, that fixes it
[17:22] <tyhicks> tych0: thanks - I'll send a patch to the kteam
[17:22] <tych0> tyhicks: cool, thanks
[17:23] <kamal> tych0, tyhicks: nice job ty-team!  ;-)  thanks
[17:23] <tyhicks> heh :)
[17:24] <tych0> i have to be useful every once in a while if i'm going to troll tyhicks' tab completion everywhere
[17:24] <kamal> :-)
[17:24] <tyhicks> jjohansen: ^ FYI so you know the reason for the patch that I'm about to send out
[17:27] <jjohansen> I'm not sure why our builds didn't catch that
[17:27] <tyhicks> me neither
[17:29] <tyhicks> jjohansen: are you wanting to understand it more or should I go ahead and send out the patch?
[17:29] <jjohansen> tyhicks: just send the patch