[PATCH 0/7] Final BKL removal, take 2

[PATCH 0/7] Final BKL removal, take 2

[Arnd Bergmann]

This is the set of patches that remain from
my previous submission one month ago. I've
dropped the ones that have either gone into
linux-next or got a sufficient number of
Acked-by:s so I put them into my own tree.

I've updated the usbip, hpfs, ufs and appletalk
patches according to the feedback I got.

If possible, I'd like the three networking patches
to go through the net-next tree, and the two
staging patches through the staging tree. I'll
add the other ones to my own series if I hear
no objections.

	Arnd

Arnd Bergmann (7):
  staging/usbip: convert to kthread
  staging/cx25721: serialize access to devlist
  hpfs: remove the BKL
  ufs: remove the BKL
  x25: remove the BKL
  appletalk: remove the BKL
  ipx: remove the BKL

 drivers/net/appletalk/Kconfig           |    1 -
 drivers/staging/cx25821/Kconfig         |    1 -
 drivers/staging/cx25821/cx25821-alsa.c  |    2 +
 drivers/staging/cx25821/cx25821-core.c  |   16 ++---
 drivers/staging/cx25821/cx25821-video.c |    9 +--
 drivers/staging/cx25821/cx25821.h       |    3 +-
 drivers/staging/usbip/Kconfig           |    2 +-
 drivers/staging/usbip/stub.h            |    4 +-
 drivers/staging/usbip/stub_dev.c        |   12 ++--
 drivers/staging/usbip/stub_rx.c         |   13 ++---
 drivers/staging/usbip/stub_tx.c         |   17 +++---
 drivers/staging/usbip/usbip_common.c    |  105 -------------------------------
 drivers/staging/usbip/usbip_common.h    |   20 +-----
 drivers/staging/usbip/usbip_event.c     |   38 ++++-------
 drivers/staging/usbip/vhci.h            |    4 +-
 drivers/staging/usbip/vhci_hcd.c        |   10 ++-
 drivers/staging/usbip/vhci_rx.c         |   16 ++---
 drivers/staging/usbip/vhci_sysfs.c      |    9 +--
 drivers/staging/usbip/vhci_tx.c         |   17 +++---
 fs/hpfs/Kconfig                         |    2 +-
 fs/hpfs/dir.c                           |   23 +++----
 fs/hpfs/file.c                          |    9 +--
 fs/hpfs/hpfs_fn.h                       |   22 +++++++
 fs/hpfs/inode.c                         |    9 +--
 fs/hpfs/namei.c                         |   49 +++++++-------
 fs/hpfs/super.c                         |   23 +++----
 fs/ufs/Kconfig                          |    1 -
 fs/ufs/inode.c                          |   78 ++++++-----------------
 fs/ufs/namei.c                          |   35 +++++-----
 fs/ufs/super.c                          |   64 +++++++++++--------
 fs/ufs/truncate.c                       |    5 +-
 fs/ufs/ufs.h                            |    6 ++-
 fs/ufs/util.c                           |    2 +-
 net/appletalk/ddp.c                     |   40 +++++-------
 net/ipx/Kconfig                         |    1 -
 net/ipx/af_ipx.c                        |   52 ++++++---------
 net/x25/Kconfig                         |    1 -
 net/x25/af_x25.c                        |   58 +++++------------
 net/x25/x25_out.c                       |    7 ++-
 39 files changed, 296 insertions(+), 490 deletions(-)

Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andrew Hendry <andrew.hendry@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Evgeniy Dushistov <dushistov@mail.ru>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-x25@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Max Vozeler <max@vozeler.com>
Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: netdev@vger.kernel.org
Cc: Nick Bowler <nbowler@elliptictech.com>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Palash Bandyopadhyay <palash.bandyopadhyay@conexant.com>
Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>

[PATCH 5/7] x25: remove the BKL

[Arnd Bergmann]

This replaces all instances of lock_kernel in x25
with lock_sock, taking care to release the socket
lock around sleeping functions (sock_alloc_send_skb
and skb_recv_datagram). It is not clear whether
this is a correct solution, but it seem to be what
other protocols do in the same situation.

Includes a fix suggested by Eric Dumazet.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Hendry <andrew.hendry@gmail.com>
Cc: linux-x25@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/x25/Kconfig   |    1 -
 net/x25/af_x25.c  |   58 ++++++++++++++++------------------------------------
 net/x25/x25_out.c |    7 ++++-
 3 files changed, 23 insertions(+), 43 deletions(-)

diff --git a/net/x25/Kconfig b/net/x25/Kconfig
index 2196e55..e6759c9 100644
--- a/net/x25/Kconfig
+++ b/net/x25/Kconfig
@@ -5,7 +5,6 @@
 config X25
 	tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
-	depends on BKL # should be fixable
 	---help---
 	  X.25 is a set of standardized network protocols, similar in scope to
 	  frame relay; the one physical line from your box to the X.25 network
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index ad96ee9..4680b1e 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -40,7 +40,6 @@
 #include <linux/errno.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>
-#include <linux/smp_lock.h>
 #include <linux/timer.h>
 #include <linux/string.h>
 #include <linux/net.h>
@@ -432,15 +431,6 @@ void x25_destroy_socket_from_timer(struct sock *sk)
 	sock_put(sk);
 }
 
-static void x25_destroy_socket(struct sock *sk)
-{
-	sock_hold(sk);
-	lock_sock(sk);
-	__x25_destroy_socket(sk);
-	release_sock(sk);
-	sock_put(sk);
-}
-
 /*
  *	Handling for system calls applied via the various interfaces to a
  *	X.25 socket object.
@@ -647,18 +637,19 @@ static int x25_release(struct socket *sock)
 	struct sock *sk = sock->sk;
 	struct x25_sock *x25;
 
-	lock_kernel();
 	if (!sk)
-		goto out;
+		return 0;
 
 	x25 = x25_sk(sk);
 
+	sock_hold(sk);
+	lock_sock(sk);
 	switch (x25->state) {
 
 		case X25_STATE_0:
 		case X25_STATE_2:
 			x25_disconnect(sk, 0, 0, 0);
-			x25_destroy_socket(sk);
+			__x25_destroy_socket(sk);
 			goto out;
 
 		case X25_STATE_1:
@@ -678,7 +669,8 @@ static int x25_release(struct socket *sock)
 
 	sock_orphan(sk);
 out:
-	unlock_kernel();
+	release_sock(sk);
+	sock_put(sk);
 	return 0;
 }
 
@@ -1085,7 +1077,7 @@ static int x25_sendmsg(struct kiocb *iocb, struct socket *sock,
 	size_t size;
 	int qbit = 0, rc = -EINVAL;
 
-	lock_kernel();
+	lock_sock(sk);
 	if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_OOB|MSG_EOR|MSG_CMSG_COMPAT))
 		goto out;
 
@@ -1148,7 +1140,9 @@ static int x25_sendmsg(struct kiocb *iocb, struct socket *sock,
 
 	size = len + X25_MAX_L2_LEN + X25_EXT_MIN_LEN;
 
+	release_sock(sk);
 	skb = sock_alloc_send_skb(sk, size, noblock, &rc);
+	lock_sock(sk);
 	if (!skb)
 		goto out;
 	X25_SKB_CB(skb)->flags = msg->msg_flags;
@@ -1231,26 +1225,10 @@ static int x25_sendmsg(struct kiocb *iocb, struct socket *sock,
 			len++;
 	}
 
-	/*
-	 * lock_sock() is currently only used to serialize this x25_kick()
-	 * against input-driven x25_kick() calls. It currently only blocks
-	 * incoming packets for this socket and does not protect against
-	 * any other socket state changes and is not called from anywhere
-	 * else. As x25_kick() cannot block and as long as all socket
-	 * operations are BKL-wrapped, we don't need take to care about
-	 * purging the backlog queue in x25_release().
-	 *
-	 * Using lock_sock() to protect all socket operations entirely
-	 * (and making the whole x25 stack SMP aware) unfortunately would
-	 * require major changes to {send,recv}msg and skb allocation methods.
-	 * -> 2.5 ;)
-	 */
-	lock_sock(sk);
 	x25_kick(sk);
-	release_sock(sk);
 	rc = len;
 out:
-	unlock_kernel();
+	release_sock(sk);
 	return rc;
 out_kfree_skb:
 	kfree_skb(skb);
@@ -1271,7 +1249,7 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
 	unsigned char *asmptr;
 	int rc = -ENOTCONN;
 
-	lock_kernel();
+	lock_sock(sk);
 	/*
 	 * This works for seqpacket too. The receiver has ordered the queue for
 	 * us! We do one quick check first though
@@ -1300,8 +1278,10 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
 		msg->msg_flags |= MSG_OOB;
 	} else {
 		/* Now we can treat all alike */
+		release_sock(sk);
 		skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT,
 					flags & MSG_DONTWAIT, &rc);
+		lock_sock(sk);
 		if (!skb)
 			goto out;
 
@@ -1338,14 +1318,12 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
 
 	msg->msg_namelen = sizeof(struct sockaddr_x25);
 
-	lock_sock(sk);
 	x25_check_rbuf(sk);
-	release_sock(sk);
 	rc = copied;
 out_free_dgram:
 	skb_free_datagram(sk, skb);
 out:
-	unlock_kernel();
+	release_sock(sk);
 	return rc;
 }
 
@@ -1581,18 +1559,18 @@ out_cud_release:
 
 		case SIOCX25CALLACCPTAPPRV: {
 			rc = -EINVAL;
-			lock_kernel();
+			lock_sock(sk);
 			if (sk->sk_state != TCP_CLOSE)
 				break;
 			clear_bit(X25_ACCPT_APPRV_FLAG, &x25->flags);
-			unlock_kernel();
+			release_sock(sk);
 			rc = 0;
 			break;
 		}
 
 		case SIOCX25SENDCALLACCPT:  {
 			rc = -EINVAL;
-			lock_kernel();
+			lock_sock(sk);
 			if (sk->sk_state != TCP_ESTABLISHED)
 				break;
 			/* must call accptapprv above */
@@ -1600,7 +1578,7 @@ out_cud_release:
 				break;
 			x25_write_internal(sk, X25_CALL_ACCEPTED);
 			x25->state = X25_STATE_3;
-			unlock_kernel();
+			release_sock(sk);
 			rc = 0;
 			break;
 		}
diff --git a/net/x25/x25_out.c b/net/x25/x25_out.c
index d00649f..0144271 100644
--- a/net/x25/x25_out.c
+++ b/net/x25/x25_out.c
@@ -68,8 +68,11 @@ int x25_output(struct sock *sk, struct sk_buff *skb)
 		frontlen = skb_headroom(skb);
 
 		while (skb->len > 0) {
-			if ((skbn = sock_alloc_send_skb(sk, frontlen + max_len,
-							noblock, &err)) == NULL){
+			release_sock(sk);
+			skbn = sock_alloc_send_skb(sk, frontlen + max_len,
+						   noblock, &err);
+			lock_sock(sk);
+			if (!skbn) {
 				if (err == -EWOULDBLOCK && noblock){
 					kfree_skb(skb);
 					return sent;
-- 
1.7.1

Re: [PATCH 5/7] x25: remove the BKL

[David Miller]

From: Arnd Bergmann <arnd@arndb.de>
Date: Wed,  2 Mar 2011 00:13:09 +0100

> This replaces all instances of lock_kernel in x25
> with lock_sock, taking care to release the socket
> lock around sleeping functions (sock_alloc_send_skb
> and skb_recv_datagram). It is not clear whether
> this is a correct solution, but it seem to be what
> other protocols do in the same situation.
> 
> Includes a fix suggested by Eric Dumazet.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: David S. Miller <davem@davemloft.net>

Re: [PATCH 0/7] Final BKL removal, take 2

[Greg KH]

On Wed, Mar 02, 2011 at 12:13:04AM +0100, Arnd Bergmann wrote:
> This is the set of patches that remain from
> my previous submission one month ago. I've
> dropped the ones that have either gone into
> linux-next or got a sufficient number of
> Acked-by:s so I put them into my own tree.
> 
> I've updated the usbip, hpfs, ufs and appletalk
> patches according to the feedback I got.
> 
> If possible, I'd like the three networking patches
> to go through the net-next tree, and the two
> staging patches through the staging tree. I'll
> add the other ones to my own series if I hear
> no objections.

I'll queue up the staging patches in the staging-next tree in a day or
so, thanks for digging them up.

greg k-h

Re: [PATCH 0/7] Final BKL removal, take 2

[Mauro Carvalho Chehab]

Em 02-03-2011 01:59, Greg KH escreveu:
> On Wed, Mar 02, 2011 at 12:13:04AM +0100, Arnd Bergmann wrote:
>> This is the set of patches that remain from
>> my previous submission one month ago. I've
>> dropped the ones that have either gone into
>> linux-next or got a sufficient number of
>> Acked-by:s so I put them into my own tree.
>>
>> I've updated the usbip, hpfs, ufs and appletalk
>> patches according to the feedback I got.
>>
>> If possible, I'd like the three networking patches
>> to go through the net-next tree, and the two
>> staging patches through the staging tree. I'll
>> add the other ones to my own series if I hear
>> no objections.
> 
> I'll queue up the staging patches in the staging-next tree in a day or
> so, thanks for digging them up.

Greg,

It is probably better to queue the staging/cx25821 patch via my tree, as this is one
of those staging files that it is handled via media tree. So, if it is ok
for you both, I'll get patch 2/7.

Thanks,
Mauro

Re: [PATCH 0/7] Final BKL removal, take 2

[Arnd Bergmann]

On Wednesday 02 March 2011, Mauro Carvalho Chehab wrote:
> It is probably better to queue the staging/cx25821 patch via my tree, as this is one
> of those staging files that it is handled via media tree. So, if it is ok
> for you both, I'll get patch 2/7.

Fine with me.

Thanks,

	Arnd

Re: [PATCH 0/7] Final BKL removal, take 2

[Greg KH]

On Wed, Mar 02, 2011 at 08:32:15AM -0300, Mauro Carvalho Chehab wrote:
> Em 02-03-2011 01:59, Greg KH escreveu:
> > On Wed, Mar 02, 2011 at 12:13:04AM +0100, Arnd Bergmann wrote:
> >> This is the set of patches that remain from
> >> my previous submission one month ago. I've
> >> dropped the ones that have either gone into
> >> linux-next or got a sufficient number of
> >> Acked-by:s so I put them into my own tree.
> >>
> >> I've updated the usbip, hpfs, ufs and appletalk
> >> patches according to the feedback I got.
> >>
> >> If possible, I'd like the three networking patches
> >> to go through the net-next tree, and the two
> >> staging patches through the staging tree. I'll
> >> add the other ones to my own series if I hear
> >> no objections.
> > 
> > I'll queue up the staging patches in the staging-next tree in a day or
> > so, thanks for digging them up.
> 
> Greg,
> 
> It is probably better to queue the staging/cx25821 patch via my tree, as this is one
> of those staging files that it is handled via media tree. So, if it is ok
> for you both, I'll get patch 2/7.

Yes, you are right, please take it through your tree.

thanks,

greg k-h

Re: [PATCH 0/7] Final BKL removal, take 2

[Mauro Carvalho Chehab]

Em 02-03-2011 11:04, Greg KH escreveu:
> On Wed, Mar 02, 2011 at 08:32:15AM -0300, Mauro Carvalho Chehab wrote:
>> Em 02-03-2011 01:59, Greg KH escreveu:
>>> On Wed, Mar 02, 2011 at 12:13:04AM +0100, Arnd Bergmann wrote:
>>>> This is the set of patches that remain from
>>>> my previous submission one month ago. I've
>>>> dropped the ones that have either gone into
>>>> linux-next or got a sufficient number of
>>>> Acked-by:s so I put them into my own tree.
>>>>
>>>> I've updated the usbip, hpfs, ufs and appletalk
>>>> patches according to the feedback I got.
>>>>
>>>> If possible, I'd like the three networking patches
>>>> to go through the net-next tree, and the two
>>>> staging patches through the staging tree. I'll
>>>> add the other ones to my own series if I hear
>>>> no objections.
>>>
>>> I'll queue up the staging patches in the staging-next tree in a day or
>>> so, thanks for digging them up.
>>
>> Greg,
>>
>> It is probably better to queue the staging/cx25821 patch via my tree, as this is one
>> of those staging files that it is handled via media tree. So, if it is ok
>> for you both, I'll get patch 2/7.
> 
> Yes, you are right, please take it through your tree.

Patch applied on my tree, thanks!
Mauro

Re: [PATCH 0/7] Final BKL removal, take 2

[Arnd Bergmann]

On Wednesday 02 March 2011 21:32:37 Mauro Carvalho Chehab wrote:
> >>
> >> It is probably better to queue the staging/cx25821 patch via my tree, as this is one
> >> of those staging files that it is handled via media tree. So, if it is ok
> >> for you both, I'll get patch 2/7.
> > 
> > Yes, you are right, please take it through your tree.
> 
> Patch applied on my tree, thanks!

I've pushed out everything to my git tree, except for the two staging
patches that go through the other trees.

Once everything is in -next, I'll add the last patch to remove the
infrastructure.

Thanks for the feedback!

	Arnd

Re: [PATCH 5/7] x25: remove the BKL

[Andrew Hendry]

Looks good, put 8gig through it over the past few days and system stable.

Tested-by: Andrew Hendry <andrew.hendry@gmail.com>

On Wed, Mar 2, 2011 at 10:16 AM, David Miller <davem@davemloft.net> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Wed,  2 Mar 2011 00:13:09 +0100
>
>> This replaces all instances of lock_kernel in x25
>> with lock_sock, taking care to release the socket
>> lock around sleeping functions (sock_alloc_send_skb
>> and skb_recv_datagram). It is not clear whether
>> this is a correct solution, but it seem to be what
>> other protocols do in the same situation.
>>
>> Includes a fix suggested by Eric Dumazet.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: David S. Miller <davem@davemloft.net>
>