[00:09] *** ChanServ sets mode: +v mchehab
[01:27] *** ChanServ sets mode: +v mchehab
[11:59] <mkrufky> ``` (06:58:18 AM) Sigyn: Invitation denied, there are only 61 users in #linuxtv: contact staffers if needed. ```
[11:59] <mkrufky> ?!?
[11:59] *** ChanServ sets mode: +v snawrocki
[11:59] <mkrufky> meh, looks like im going to have to get staff involved
[12:00] <hverkuil> hi guys!
[12:00] <mkrufky> hi hans :-)
[12:01] <syoung> Hello
[12:02] <sailus> Hello!
[12:02] <sailus> Just pinged pinchartl...
[12:05] <hverkuil> mchehab: ping
[12:07] <sailus> hverkuil: Wasn't mchehab travelling these days?
[12:07] <sailus> Did he say whether he'd join?
[12:07] <hverkuil> good question
[12:08] <hverkuil> He's spending two weeks at the brazil office.
[12:09] <hverkuil> but should be able to join the meeting AFAICT.
[12:09] <syoung> During last week's meeting: 12:03 <+mchehab> not sure yet if I'll be able to join for the meetings but I'll likely find a way
[12:10] <syoung> I'm guessing he did not find a way :/
[12:10] <sailus> It's ten past. I guess we could start.
[12:11] <hverkuil> I don't have much to report. I've been working on this: http://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-13166.html
[12:12] <hverkuil> Expect a bunch of patches soon. Besides fixing that CVE I also found a ton of bugs in the compat-ioctl32 code.
[12:12] <sailus> Gosh.
[12:13] <sailus> I should expect to see a flow of patches to stable kernels then?
[12:13] <hverkuil> We'll see. That's a lot of work.
[12:14] <sailus> That seems pretty bad, doesn't it?
[12:16] <hverkuil> I think it's a real security risk that is exploitable. The patch Daniel Mentz came up with has been there for almost half a year, but nobody could be bothered to inform upstream. That really pisses me off.
[12:16] <mchehab> sorry, I had some issues to connect today
[12:17] <sailus> hverkuil: Agreed.
[12:18] <mchehab> yep, they should have pinged us
[12:19] <mchehab> hverkuil: the better would be to apply those patchesets for 4.16, of course c/c stable
[12:19] <mchehab> from my side, I'm still stuck with the softirq issue
[12:19] <mchehab> trying to setup a way to test it at the office
[12:19] <hverkuil> right now they only apply to 4.15 and up.
[12:20] <mchehab> the previous patchset didn't work. A new one was submitted today
[12:20] <mchehab> hverkuil: well, let's solve 4.15+ first
[12:20] <mchehab> then work on backporting it
[12:20] <hverkuil> yup
[12:21] <mchehab> at least the CVE ones should be send to earlier Kernels
[12:21] <mchehab> we should try to simplify the compat32 on V4L
[12:21] <mchehab> i have the feeling that it is more complex than it should be
[12:22] <mchehab> as even compatible ioctls should be listed there
[12:22] <hverkuil> the problem is that v4l2-compat-ioctl32.c changes a lot, so for almost every kernel you'd need to do some manual work.
[12:22] <mchehab> that's due to that: all IOCTLS are listed there
[12:23] <hverkuil> No, only ioctls that need conversion are listed.
[12:23] <hverkuil> It used to be that all ioctls were listed, but that was changed some time ago.
[12:23] <mchehab> ah, OK!
[12:23] <hverkuil> Anyway, because of this I didn't have time to do any patch handling.
[12:24] <mchehab> ok
[12:24] <mchehab> yeah, this has priority over normal patch handling
[12:25] <mchehab> sailus, mkrufky, pinchartl, snawrocki, syoung: anything from your side?
[12:26] <hverkuil> vivid + v4l2-compliance have been incredibly useful to test this. I get good coverage that way.
[12:26] <hverkuil> (ioctl coverage)
[12:26] <mchehab> good!
[12:26] <sailus> mchehab: Thanks for pulling the patches. I think that was it. I'll postpone all non-fix patches until we have rc1.
[12:27] <mchehab> ok
[12:27] <mchehab> my guess is that the merge window will start next week
[12:27] <sailus> On media device refcounting --- I've done some more work on it but lately I've been stuck debugging a crash.
[12:28] <sailus> I've converted some existing drivers for refcounting and I've done testing with a rtl28xxu stick.
[12:29] <mchehab> ok
[12:29] <sailus> That's media device refcounting only; the DVB framework appears to have similar issues but also makes an attept to work with them by waiting until all users are gone, it seems.
[12:30] <sailus> I'll review Alexandre's request patches in the near future.
[12:30] <mchehab> dvb refcounting used to work fine, until 2016
[12:30] <mchehab> it is more complex than V4L, as, on DVB, there is a thread that starts running when frontend is opened
[12:31] <sailus> Some of that seems fine whereas elsewhere there's an apparent assumption of a use case such as a stateless video codec.
[12:31] <mchehab> the refcount logic there has to wait for all users to go
[12:32] <sailus> It's not refcounting, but waiting. :-)
[12:32] <sailus> That was another approach considered for media device btw., and still needed in some cases, for example to shut down hardware.
[12:33] <hverkuil> pinchartl: can you comment on https://www.mail-archive.com/linux-media@vger.kernel.org/msg125078.html?
[12:33] <mchehab> sailus: v4l2 has a waiting logic too for some structs
[12:33] <hverkuil> omap_vout.c is badly broken. Perhaps we should retire that driver?
[12:36] <mchehab> anything else?
[12:38] <hverkuil> not from me
[12:38] <mchehab> (with regards to omap_vout, if it is broken, I'm OK to retire it)
[12:39] <mchehab> send a RFC
[12:39] <mchehab> if none complains, it is probably safe to retire it
[12:40] <hverkuil> will do
[16:47] <hverkuil> I finished my last tests for the CVE fix. I'll post the patch series tomorrow morning.