[Devel] [PATCH rh7] ve/tty: vt -- Fix nil dereference due to race

2015-08-06 Thread Cyrill Gorcunov
In commit 5571b126368c0153d73eaec0fdf43fbcbae67fd9 we bring in the stabs for virtual terminals but they are race sensitive: all therminals are represented by one per-VE @vz_tty_conm tty peer which can be removed and set to nil if application ask for new terminal when old one is inside "remove" stag

Re: [Devel] [vzlin-dev] [PATCH rh7] ploop: fix race on prealloc request

2015-08-06 Thread Dmitry Monakhov
Maxim Patlasov writes: > kaio_submit_alloc() sometimes piggybacks ploop request with additional work: > set preq->prealloc_size, pass preq to fsync_thread, perform preallocation > there, get it back to kaio_submit_alloc(), move preallocation from > preq->prealloc_size to io->prealloced_size. > >

Re: [Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

2015-08-06 Thread Cyrill Gorcunov
On Thu, Aug 06, 2015 at 02:36:59PM +0300, Vladimir Davydov wrote: > > > > Agreed. VE_CONFIGURE_OPEN_TTY is special unfortunately (and could you > > enlighten me a bit -- when console is attached, is it allowed to > > do c/r in our pcs6, i somehow forget, > > You can attach to the console using `v

Re: [Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

2015-08-06 Thread Vladimir Davydov
On Thu, Aug 06, 2015 at 02:01:57PM +0300, Cyrill Gorcunov wrote: > On Thu, Aug 06, 2015 at 01:48:08PM +0300, Vladimir Davydov wrote: > > > Maybe let gather all ioctls we won't be able to escape using into > > > one place and check what we can do? > > > > I don't think it's strictly necessary - we

Re: [Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

2015-08-06 Thread Cyrill Gorcunov
On Thu, Aug 06, 2015 at 01:48:08PM +0300, Vladimir Davydov wrote: > > Maybe let gather all ioctls we won't be able to escape using into > > one place and check what we can do? > > I don't think it's strictly necessary - we can do it in the course of > porting old APIs. We just need to refine our p

Re: [Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

2015-08-06 Thread Vladimir Davydov
On Thu, Aug 06, 2015 at 01:26:47PM +0300, Cyrill Gorcunov wrote: > On Thu, Aug 06, 2015 at 12:55:41PM +0300, Vladimir Davydov wrote: > > Anyway, if it is difficult for criu to work with ioctls, we should > > probably revise our policy. May be we could move all user API that needs > > to be called

Re: [Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

2015-08-06 Thread Cyrill Gorcunov
On Thu, Aug 06, 2015 at 12:55:41PM +0300, Vladimir Davydov wrote: > On Thu, Aug 06, 2015 at 12:39:14PM +0300, Cyrill Gorcunov wrote: > > On Thu, Aug 06, 2015 at 12:30:46PM +0300, Vladimir Davydov wrote: > > > > > > > > As to me ioctls on its own are not bad at all, but having some > > > > native i

Re: [Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

2015-08-06 Thread Vladimir Davydov
On Thu, Aug 06, 2015 at 12:39:14PM +0300, Cyrill Gorcunov wrote: > On Thu, Aug 06, 2015 at 12:30:46PM +0300, Vladimir Davydov wrote: > > > > > > As to me ioctls on its own are not bad at all, but having some > > > native interface (such as we do with ve.X entries in cgroups) > > > make it open for

Re: [Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

2015-08-06 Thread Cyrill Gorcunov
On Thu, Aug 06, 2015 at 12:30:46PM +0300, Vladimir Davydov wrote: > > > > As to me ioctls on its own are not bad at all, but having some > > native interface (such as we do with ve.X entries in cgroups) > > make it open for scripting at least: any new feature is a way > > easier to test directly f

Re: [Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

2015-08-06 Thread Vladimir Davydov
On Wed, Aug 05, 2015 at 03:52:41PM +0300, Cyrill Gorcunov wrote: > On Wed, Aug 05, 2015 at 03:30:48PM +0300, Vladimir Davydov wrote: > > Why are you so opposed to ioctls? Why did we start to move every piece > > of our user API we could to ve cgroup in the first place? What's the > > point in subs