On Fri, Jan 22, 2016 at 10:42 AM, Al Viro wrote:
>
> BTW, looks like ext4 is the only pending i_mutex-sensitive tree; once
> it's pulled, I'll regenerate the inode_{lock,unlock,trylock,...} patch
> and send it your way.
I have the ext4 pull pending now, I'm doing some test-builds before
pulling t
On Fri, Jan 22, 2016 at 10:26:18AM -0800, Linus Torvalds wrote:
> On Thu, Jan 21, 2016 at 3:04 PM, Al Viro wrote:
> > [trying to use git request-pull; result looks more or less sane, AFAICT...]
>
> Looks fine, if you can just fix this part:
>
> > gitol...@ra.kernel.org:/pub/scm/linux/kernel/gi
On Thu, Jan 21, 2016 at 3:04 PM, Al Viro wrote:
> [trying to use git request-pull; result looks more or less sane, AFAICT...]
Looks fine, if you can just fix this part:
> gitol...@ra.kernel.org:/pub/scm/linux/kernel/git/viro/vfs.git for-linus
and have it point to the public git://git.kernel.o
[trying to use git request-pull; result looks more or less sane, AFAICT...]
Embarrassing braino fix + pipe page accounting + fixing an eyesore in
find_filesystem() (checking that s1 is equal to prefix of s2 of given length
can be done in many ways, but "compare strlen(s1) with length and then do
st
O_TMPFILE ABI changes, Oleg's fput() series, misc cleanups,
including making simple_lookup() usable for filesystems with non-NULL,
which allows to get rid of quite a bit of ugliness. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (
On Thu, May 9, 2013 at 1:34 PM, Al Viro wrote:
>
> Anyway, let's just drop that commit for now; it clearly needs more RTFS.
> Could you pull for-linus^?
Done.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
On Thu, May 09, 2013 at 09:28:15PM +0100, Al Viro wrote:
> The only place checking that sucker is in a fairly large area protected by
> ->b_lock (in mon_bin_event()); I really don't want to dig deep enough to
> tell if having it changed right after it had been checked is safe. OTOH,
> from a curs
On Thu, May 09, 2013 at 01:12:43PM -0700, Linus Torvalds wrote:
> On Thu, May 9, 2013 at 12:26 PM, Al Viro wrote:
> > Regression fix from Geert + yet another open-coded kernel_read().
>
> Hmm. I get one more commit - a racy usbmon thing.
Oops - pull stats not updated... My apologies.
>
On Thu, May 9, 2013 at 1:12 PM, Linus Torvalds
wrote:
>
> Hmm. I get one more commit - a racy usbmon thing. Which looks fine per
> se, but would look even better if it just made mmap_active an atomic_t
> instead, wouldn't you say?
Oh, I see, the spinlock protects the read too and the logic there.
On Thu, May 9, 2013 at 12:26 PM, Al Viro wrote:
> Regression fix from Geert + yet another open-coded kernel_read().
Hmm. I get one more commit - a racy usbmon thing. Which looks fine per
se, but would look even better if it just made mmap_active an atomic_t
instead, wouldn't you say?
So
Regression fix from Geert + yet another open-coded kernel_read().
Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (1):
ecryptfs: don't open-code kernel_read()
Geert Uytterhoeven (1):
xtensa simdisk: Fix proc_create_data()
A couple of fixes + getting rid of __blkdev_put() return value.
Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (4):
hfs: SMP race on directory close()
mtd_blktrans_ops->release() should return void
block_device_operations->
12 matches
Mail list logo
