1445993961 Q * fstd Remote host closed the connection
1445993972 J * fstd ~fstd@xdsl-84-44-226-123.netcologne.de
1446006806 M * undefined Bertl_zZ: in linux 4.1 (at least), in locks.c, in locks_mandatory_area(), how do you know the statement"error = __posix_lock_file(inode, &fl, NULL, filp->f_xid);", specifically "filp->f_xid" won't dereference a null pointer
1446006835 M * undefined everywhere else in that function where kernel code dereferences filp, it check that filp is not null
1446017854 J * Ghislain ~aqueos@adsl1.aqueos.com
1446019094 M * Ghislain i am back
1446019900 M * Ghislain daniel_hozac, Bertl_zZ tell me if you got any time to discuss the dentry thing
1446023808 J * voegelas ~voegelas@HSI-KBW-078-043-023-119.hsi4.kabel-badenwuerttemberg.de
1446026927 Q * derjohn_mob Ping timeout: 480 seconds
1446028605 J * derjohn_mob ~aj@2001:6f8:1337:0:654f:31c9:43a7:fb85
1446033698 N * Bertl_zZ Bertl
1446033702 M * Bertl morning folks!
1446037161 Q * fstd Remote host closed the connection
1446037172 J * fstd ~fstd@xdsl-87-78-8-151.netcologne.de
1446037424 M * Ghislain hellooooo
1446037455 M * Ghislain i was dying to bother you Bertl ;p with the dentry thing
1446037515 M * Ghislain do you saw my little speach about it ?
1446037777 M * Bertl very interesting I say :)
1446037810 M * Ghislain well i am using google translate to read the patch ;p
1446037855 M * Bertl LOL, obviously google is doing a good job then :)
1446037876 M * Ghislain the first thing i wanted to clean up is the DENTRY numbers in the /proc entry, should it be inferior to the one in /proc/sys/fs/dentry-state ?
1446037877 M * Ghislain lol
1446037900 M * Bertl I will double check the dentry code and see if it makes any sense to keep it around shortly
1446037938 M * Ghislain ok thanks :)
1446038104 M * Bertl undefined: good catch
1446038198 M * Bertl i.e. we should either pass the filp and defer the dereferencing or check if filp is valid and then pass the xid
1446038227 M * Bertl or even better, use the existing filp check to retrieve the xid for the error case
1446038539 M * undefined Bertl: i'm reviewing the code to account for this upstream change (in recent 4.1.12 update, though possibly in all the recent stable updates): http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.1.y&id=b2540f146402c1cf28ea5a84ec5bb1f4c332e59e
1446038621 M * undefined essentially, we are no longer guaranteed all callers of __posix_lock_file() have access to the file so as to pass us the file's f_xid
1446038736 M * undefined specifically fs/locks.c: posix_lock_inode_wait() which is called by fs/nfs/nfs4proc.c: do_vfs_lock() (though i'm concerned because it is also now called by include/linux/fs.h: posix_lock_file_wait() which has filp->f_xid and should probably pass it down)
1446039100 M * undefined i haven't quite discerned the pattern/rules behind f_xid and locks (when to check, when not to check, when to assign to file_lock, when not to assign to file_lock) and i'm not all the familiar with the kernel implementation (as i'm familiar with posix/fcntl locks, but the kernel abstracts it further to also implement flock locks)
1446040306 M * Bertl back then we had some reasons to tie the locks to files, but nowadays I think there are no real use cases where the locks are "shared" between contexts
1446040372 M * Bertl so personally I wouldn't mind tying the locks to the process context instead of the file context
1446040400 M * Bertl but maybe that has some other unforseen implications
1446050399 M * Ghislain i like unforseen implication :)
1446050404 M * Ghislain makes life fun
1446050442 M * Ghislain what happen when you  remove 1 to a uitn32 that is at 0  in c ?
1446050477 M * Ghislain well i guess an erreor silly question
1446051300 M * Bertl it becomes ~0
1446051321 M * Bertl no error, no problem
1446051346 M * Bertl off for now ... bbl
1446051351 N * Bertl Bertl_oO
1446053061 M * undefined Ghislain: in case a concrete example would help: http://pastebin.com/ncYng1ue
1446053207 M * Ghislain ok so no crash then just a counter that goes silly
1446053220 M * Ghislain i  suppose this is the same for max value +1 :)
1446053261 M * Ghislain so the counters are not the issue they may be wrong but cannot crash the kernel
1446053481 M * Ghislain x + 1 = 0x00000001
1446053481 M * Ghislain :)
1446053520 M * Ghislain ousp sorry
1446053634 M * Ghislain no x + 1 = 0x00000000 (x = UINT32_MAX;)
1446053977 M * Ghislain but if the counter hit max+1 it hit 0 then can the limit be reached, __vx_cres_avail ahs a return if num==0 but it  is not the first condition there is 2 other BEFORE that can then trigger even if no limits are set
1446054003 M * Ghislain well 1 as the other return 1 also
1446054113 M * Ghislain well i am lost i reached my codefuu limit for now, i must gain a level to read more
1446054826 Q * derjohn_mob Ping timeout: 480 seconds
1446056040 J * derjohn_mob ~aj@nl8x.mullvad.net
1446056042 Q * derjohn_mob autokilled: This host may be infected. Mail support@oftc.net with questions. BOPM (2015-10-28 14:14:01)
1446056687 Q * voegelas Quit: Leaving.
1446065773 Q * jrklein Quit: No Ping reply in 180 seconds.
1446065794 J * jrklein ~cloud@proxy.dnihost.net
1446068671 Q * sannes Quit: Leaving.
1446071321 Q * Ghislain Quit: Leaving.